アジャイル開発における理想と現実と

アジャイル時代のプロジェクトマネジメント入門（3）：「アジャイル」という言葉が一人歩き――アジャイル開発における理想と現実 - ＠IT

大変興味深い連載です。今回の記事では、アジャイルにしてもそれまでのやり方にしても、とにかく形式的に固定的に捉えるとぎくしゃくするよね、ということを思いました。

Webのシステムでしたが、コアな部分を決め、設計・実装を途中まで対応していた時に、根幹に関わる部分に修正が必要なビジネス要件が出てきました。根幹に関わる部分であることから小手先の対応ではなく、設計に立ち返って再度検討からスタートしました。案の定、スケジュールに大きく影響しサービスのローンチ時期の調整が必要になりました。

その段階で「そんなの聞いていない」とクライアントから指摘を受けました。「アジャイルなのだから……」と。

スケジュールに大きく影響するのに顧客に黙って進めたってことでしょうか？それはアジャイルとは関係なくまずかったですね。最後の「『アジャイルなのだから……』」が誰のどういう意図のつぶやきなのか分かりませんが、顧客が「アジャイルなのだから、ちゃんと透明性を確保してよ、私達顧客もふくめてワンチームになってよ」と言ったのかなと思いました。

あるプロジェクトでは基本設計と詳細設計・実装を別の会社で行うケースがありました。このケースでは、設計での“あるべき論”と、プログラマーが考える実装方針などで何回か衝突を繰り返すことになりました。最終的には良い方向に転がりましたが。

すばらしいことです。工程の間に契約の壁を築いたら、しばしば起こることは遠慮と形式主義と無責任と無気力です。

アジャイル開発を行っていると仕様の変更などで、都度ドキュメントを更新する必要にせまられ、進捗（しんちょく）が伸び悩んだり、ドキュメントが最新でなかったり、そんな経験をされた方も多いのではないでしょうか？

Cuonでも同様の問題がたびたび発生し、リーンとウオーターフォールを組み合わせた開発手法をしばしば利用しています。これは、各イテレーション内をウオーターフォールで進めることにより、イテレーション内で確定したことについては、次イテレーション以降では基本変更しないという開発手法です。

ドキュメントを都度最新にするルールならば工数がかかるのは当たり前で、そのせいで進捗が伸び悩むと捉えているなら、そのあたりよく話し合いたいです。見積りに問題があるか、あるいは開発チームが期待に応えられていないということでしょうか。改善して効率を上げて欲しいという指示はありと思います。
ルールなのに最新にしていないならメンバーがルールを守れない理由を分析して対策する必要があります。ルールではないのに最新でないと気にしてる人がいるなら、ふりかえりで取り上げて議論するべきでしょう。

イテレーション内をウォーターフォールで進めるというのは、設計が終わらないと実装せず、実装が終わらないとテストしないということでいいのでしょうか。まとめてやることにより局所的な（＝見かけ上の）効率は上がるでしょう。ですが、手戻りのリスクは増え、バッファの消費も増えます。本当に効率的かは現場次第でしょう。確定したことは基本変更しない、というのは、プロジェクトによってはものすごいリスクです。そういうリスクのないプロジェクトでのみ用いるべきでしょう。プロセス設計は自由にすればいいと思うので、工夫してみましょうというのは合意です。