アジャイル開発について
ある請負開発案件のRFPの中に「開発手法はアジャイル開発を指定」、という記載がありました。
なにかとても違和感を感じて、このまま進めると、「アジャイル」だから「仕様が曖昧なままでも進めてよい」「後からいくらでも変更できる」という認識で話が進みそうなことが危惧されて、話し会いの結果、ウォーターフォールでもよいということになりました。
また以前、内製で開発していた職場でも、「アジャイル」だから「ドキュメントなんか作らなくてもいい」という認識で開発が進んでいて、結果として仕様がブラックボックス化され、システムが属人化されてしまうという問題を抱えた職場もありました。
自分の周囲だけかもしれませんが、「アジャイル」の名のもとに、場当たり的な開発の免罪符になってしまっていないかな？と思ってます。
改めて、アジャイル開発についてまとめてみます。
まずは基本的な所から。
アジャイル（Agile）とは？
短期間の開発を反復をすることで、リスクを最小化しようとする開発手法。
- 「イテレーション」と呼ばれる期間ごとに、クライアントにアプリケーションを提供する。
- 「イテレーション」の期間はおおよそ2Week程度。
- プロジェクトの全ストーリーとして、「マスターストーリーリスト」を作成する
- 「マスターストーリーリスト」の個別のストーリーとして「ユーザーストーリー」を作成する。
- イテレーション終了時に、イテレーションで実施可能なユーザーストーリーの量「ベロシティ」が適切だったかを確認する。
スクラム
進め方の一つとして、「スクラム」というものがあります。
スクラムとは
「チームで仕事の進めるための枠組み（フレームワーク）」
役割
プロダクトオーナー
作成するプロダクトに対し、最終決定権と責任を持つ。
スクラムマスター
スクラムでの進行を推進する役割。プロダクトオーナーと兼任しないことが前提にある。
チームメンバー
概要設計者・詳細設計者・実装者・テスターなど役割をわけず、全ての開発に関わる人を『チーム』と呼ぶ。多くとも10人未満で構成されることが望ましい。
スクラムでのプロジェクトの進め方
デイリースクラム
毎朝15分程度、チームメンバーで集まり、現在の進捗、今日やること、問題の共有などを行う。
リリースプランニング
プロジェクト立ち上げ時に、どのようなプロダクトをどのような優先順、どのくらいの期間で開発するか、
チーム全員で認識合わせを行う。
スプリントプランニング
イテレーション期間毎に、全体のスコープからどの範囲までの機能を実現するかを
チーム全員でタスクに落とす。
ふりかえり
前回のイテレーション結果をもとにチームがどのくらいのタスクを消化できるかを検討し、都度精度を高めて行く。主にKPT法などが用いられる。
コミュニケーションに重点をおいて、お互いに情報を補完しあっていくことがポイントといったところでしょうか。
内製で少しずつサービスを育てていくなら、ベストマッチな気もしますが、請負契約で開発する場合、クライアント、ベンダ間で追加工数の管理、リスク分担などを考えると、相性はどうなのだろう？と悩みます。
