 |
||||||||||||||
|
||||||||||||||
| 1 2 3 次のページ | ||||||||||||||
|
||||||||||||||
| 事例紹介 | ||||||||||||||
|
前回は、アジャイルプロセスを従来のシステム開発に活かせることをお話しました。今回は、実際にアジャイル開発の事例を紹介し、最後に全体のまとめをします。 筆者の濱の会社では、クライアント企業からソフトウェアの開発と保守を受託しています。これらの受託開発のすべてのプロジェクトにアジャイル開発を適用しています。 多くの場合はWebアプリケーションですが、過去にはアプリケーションフレームワークやスタンドアローンのアプリケーションへもアジャイル開発を適用してきました。アプリケーションのビジネスドメインも画一されたものではなく多種多様で、クライアントの業種は金融が最も多く、製造業やSIerなどからも依頼されています。その中から、いくつかのプロジェクトの事例を紹介したいと思います。 |
||||||||||||||
| 事例1 | ||||||||||||||
|
アジャイル開発を導入したばかりの2001年頃に実施した保険会社のWebサイトのリニューアルプロジェクトです。このプロジェクトは、チームの全メンバーをクライアントに常駐させて開発しました。開発者が7人のチームで、その中の一人がプロジェクトマネージャーを兼務するという形で4ヶ月間実施されました。 開発時は、イテレーション期間は特に決めずにクライアントの要望に合わせてリリース時期を決定していました。計画ゲームは実施していませんでしたが、ペアプログラミングでの共有とタスクボードによる残タスクの管理、コードの共同所有によってチームを管理しました。 チームがオンサイトでユーザの側にいることができたので、要求をいつでも問い合わせることができたことがプロジェクトの成功の大きな要因になったと思います。オンサイトのチームは、受け入れテストもユーザと一緒に計画し、実施するという形をとっていたので問題もなくスムーズに実施できました。 開発終了後も数年に渡って保守を担っていますが、その間は1週間から1ヶ月の短期リリースを繰り返しながら、機能の拡張や障害への対応をしています。 |
||||||||||||||
| 事例2 | ||||||||||||||
|
次の事例は、証券会社の企業間のポータルWebサイトの開発プロジェクトです。このプロジェクトは、立ち上げ当時にほとんど内容が決まっていなかったため、インクリメンタルなアジャイル開発に向いていたプロジェクトでした。 当初、このプロジェクトは半年間の開発だけでしたが、それ以降も1年以上の間、継続してシステムの保守を担っています。開発期間よりも保守期間の開発者の人数は減らしていますが、どちらの場合も全体のプロセスおよび2週間のイテレーションは維持されています。 チームのメンバには、プロジェクトマネージャと開発者のほか、チームもユーザもオンサイトにすることができなかったため、代理ユーザという役割を設けました。また、このプロジェクトからプロジェクトファシリテータという専任の役割も新たに設けて、プロセスラインの管理を徹底して実施しました。開発者の人数はピーク時で6人、平均すると4人でした。チーム構成のイメージを図1に示します。  図1：チーム構成 このプロジェクトでは、週40時間（No残業）を徹底させました。No残業を実施することでチームを計測できるようになりました。計測できるようになると計画ゲームの正確性が増してきて、チームの問題がよく見えるようになりました。さらに、プログラミング以外のすべての作業もペアで実施させるセルという概念を採用することにより、プロジェクトの管理が容易になり、さらなる共有化と平準化を得ることができるようになりました。 先のプラクティス以外にも、ソフトウェア看板やバーンダウンチャートをはじめとする「見える化」を多く導入することによりチームの問題を最小限に抑えることができるようになりました。「見える化」を正確に維持していく作業は開発者にとっては負担となるので、プロジェクトファシリテータを導入することで、開発者の「見える化」に対する作業コストを減らすことができるようになりました。 |
||||||||||||||
|
1 2 3 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
