2013年4月2日火曜日

アジャイル開発は全体スケジュールにコミットすべき



アジャイルソフトウェア開発について極端な議論をされています。極端に話すと議論がわかりやすい。議論を見ていると7つの理由のうち「全体スケジュールにコミットできない」「アーキテクチャ上の無駄が生じる」の2点が興味深い。「全体スケジュールにコミットできない」は自分の仕事にも絡むので書いてみます。

ちなみに、私はアジャイルのコンサルタントでもないので利害関係ありませんし、開発者ではなく企画の立場。できれば全てのソフトウェア開発がアジャイルソフトウェア開発でやった方が良いのではと思っています。

・全体スケジュール
スクラムでは直近の期間(スプリント)についてのみ計画する事になっており全体計画がありません。これについては確かに企画側は困ります。全体計画がなければ予算取りができませんし、変化に対して対処できません。

開発側からみて意味のある計画が作れないとか、後のことを考えてもしかたないというのは一理ありますが、企画側はあきらかに必要。
アジャイル開発のやり方として、「全体スケジュールは計画しなければならない」と明言してどのように計画すべきか議論した方がよいのではないでしょうか。
企画側が欲しい全体スケジュールは詳細なタスクではなく、最終成果物のスコープがどう変化するか。よって、どのイテレーションにどの機能が実装予定になっており、追加要求によって最終成果物がどのように変化するか大枠がみえれば十分です。

・コミットメントできない
全体スケジュールは作れば良いだけなのでいいのですが、全体スケジュールにコミットできるかどうかは厄介。
アジャイルソフトウェア開発では最終成果物についてコミットをおこないません。これは契約問題を含め大きなポイント。

「昔プログラマーはマジシャンと思われていた。動くソフトを作るだけで認められていた。しかしいまや普通の人。普通の人が約束を守らなければならないように、開発者も約束を守らなければならない」ケントベックが講演していた話しです。この発言からアジャイル開発は約束をしないというものではないでしょう。

問題はどうすれば約束を守られるのか。我々は誰も未来を正確に予測できません。よって計画に約束するためには必ずバッファが必要です。バッファはコスト・スコープ・時間といった形がありますが、いずれにしろバッファをもっていないと約束することは不可能です。
このことはアジャイル開発だろうがウォータフォールだろうが開発以外の業務であろうが同じです。

私のアジャイルソフトウェア開発の理解は「QCDにはコミットしなければならないが、スコープは柔軟に調整可能である。これを具体的に実現するための開発プロセス」であり、スコープにバッファをもたせる方法だと思っています。
このやり方は企画側からもメリットがあります。事前に全ての要求を洗い出すことは不可能ですから。

であれば
100機能開発する全体計画だが、70機能は必須で開発。30機能は変更可能なバッファスコープとする。
こういう全体計画すれば開発側も企画側もコミットはできるでしょう。バッファなんてお金の出元の方が認めてくれないと思うかもしれませんが、普通は大丈夫です。

以上の通りで「全体スケジュールにコミットできない」のでアジャイルが駄目なら、「バッファをもった全体計画を作る」という事で問題解決ではないでしょうか。

どのぐらいのバッファを、どのように誰が持つとバッファは最小化できるのか。こちらの議論が必要かと。

0 件のコメント:

コメントを投稿