あなたは明日からイテレーティブ開発を回せますか?
今回は、アジャイル開発の導入を成功させるための秘策を伝授します。前回、アジャイル開発は書籍にかかれた手法をそのまま現場に適用しても上手く行かないことを説明しました。
必要なのはアジャイル開発がどんな原理に従って動いているかを知ること。それさえわかれば、状況が異なるプロジェクトにも応用できますし、細かいプラクティスに惑わされなくなります。既存の手法が上手く適用できない場合に、代替案を考えることさえできるようになるでしょう。
今回は、われわれが慣れ親しんできたウォーターフォール型開発と最も異なるアジャイルの特徴「イテレーション」を取り上げます。短期間(1週間~4週間程度)の開発を繰り返しながら機能を充実させていきます。口で言うのは簡単ですが、大抵の人は初めてのイテレーションで失敗します。それが上手く回るための仕組みがわかっていないからです。
アジャイル開発の仕組みをおさらい
まずは、教科書的な観点からウォーターフォール型とアジャイル型の仕組みの違いを見てみましょう。図は両者の比較をしたものです。アジャイル開発の方では、一つのイテレーションで実施する内容と簡単な役割分担を示しています。
リリース計画
アジャイル開発は、最初に「リリース計画」を立てます。これは、「何番目のイテレーションでこんなことをしよう」ということをざっくりと想定したものです。
アジャイル開発は様々なスタイルがありますので、プロジェクトによっては異なる場合もあります。例えば、イテレーションへの割当をせずリリースタイミングやマイルストンのみ決めるケースもよく見られます。なお、アジャイル開発では人日単位で見積もるケースはあまり多くありませんが、ここではわかりやすさを優先しています。
顧客と開発チーム
アジャイル開発のメンバーは、要求を決めて優先順位をつける「顧客」と開発を実施する「開発チーム」側に分かれます。
リクエスト
イテレーションが始まると、最初(1日目)にそのイテレーション期間(例えば2週間)で開発チームに実施して欲しいリクエストを「顧客」側が出します。
作業見積もり
それを受けて、それぞれのリクエストを実現するために必要な作業や工数などを開発チームが算出し、「作業見積り」として提出。顧客はその見積りをもとに、チームが2週間でこなせる作業量に収まるよう要求を取捨選択して、チームに作業を依頼します。そして、2週間後に、ちゃんと思ったアプリケーションができているか確認。ここまでが大まかな流れです。
各イテレーションごとにリリース
2週間ごとにアプリケーションがアウトプットされますので、顧客側の要求と開発側の理解にギャップがあってもすぐにわかります。また、次のイテレーションからは、前回のイテレーションで作ったアプリケーションを見ながら仕様を考えることもできます。
アプリケーションが完成したか否かで進捗を測ることができるので、途中までは順調に進んでいると報告されていたのに、最後になって急に問題を告げられるようなことも起こりえません。実際にアプリケーションを作ってみないとわからない、気づかないことに関するリスクも早期に発見できます。
* * * * *
ここまで読まれていかがですか? 「繰り返し」をつかったアジャイル開発はなんだか良さそうなイメージがしますよね。しかし、「イテレーティブ型」の開発を「教科書」を読んだだけで導入すると失敗してしまうケースが多いのです。(次ページへ続く)