機能への献身

アジャイル手法では、開発するソフトウェアの機能リスト（多くの場合、ストーリーと呼ばれる）を作成することが一般的であり、おそらく支配的な慣習となっています。これらの機能は、インデックスカード、作業キュー、バーンダウンチャート、バックログ、または選択したツールを使用して追跡されます。

全体として、私はこのアプローチが好きです。やるべきことをすべて、1週間または数週間で完了できる小さなタスクに分割することで、進捗状況を視覚化し、どれだけの作業量をこなせるかを把握できます。反復型開発の主な利点は、ウォーターフォール方式のようにプロジェクトの後半まで（テスト、統合などの）長く管理が難しい作業を残すのではなく、ソフトウェアをチャンクに分割して完了させることでリスクを軽減することであると、私はしばしば述べてきました。

問題は、このリストが突然角と牙を生やし、固定価格・固定範囲の大規模な事前計画プロジェクトになってしまうことです。クレイグ・ラーマンはかつて、ウォーターフォールプロセスには、反復プロセスを拒絶する強力な抗体があり、それらをある種のウォーターフォールに変形させる、と冗談を言っていました。RUPはこれらの抗体の一般的な犠牲者であり、そのフェーズは分析・設計・構築・テストのコンベヤーの変種に変化しています。

ウォーターフォールを打ち負かす鍵は、Danが述べているように、アジャイル開発者は「成果」を「機能」よりも重視することを認識することです。機能リストは貴重なツールですが、手段であって目的ではありません。本当に重要なのは全体的な成果であり、私はそれを顧客への価値と考えています。

この考え方における重要な点は、プロジェクトの進行に伴って機能リストが変更されることを期待することです。これは、新しいことができることを発見し、古いものを再優先順位付けする際に発生します。これは適応型計画の本質であり、常にアジャイル思考の重要な指標となっています。これは、人々が計画について考える方法に大きな変化をもたらします。計画駆動型プロジェクトでは、成功と失敗はしばしば「計画通りに進んだか？」という形で表現されます。アジャイルプロジェクトでは、計画は頻繁に変更されるため、これは意味のない質問です。計画はツールであり、主に変更の影響を測るために使用されます。「この機能を追加すると、私たちの作業にどのような影響がありますか」。計画はFivePoundBagに何が収まるべきかを把握するためのツールです。計画が常に変化していない場合、適応型計画を行っている可能性は非常に低く、したがってアジャイルではないということです。

機能リストにはもう1つの問題があります。機能の価値を高めるコンテキストを見失いやすいことです。アリスティア・コックバーンがユースケースを支持しているのはそのためです。ユースケースは、誰かがシステムを使用する方法の物語に焦点を当てています。Marc NcNeilも、顧客ジャーニーという観点からこれについて述べています。計画におけるユースケースの弱点はその進捗状況を評価できる明確な単位を提供せず、将来の選択肢の影響をプロジェクトに予測できないことです。そのため、計画ツールとしてはあまり役に立ちませんが、良い成果がどうなるかを想像するためのツールとしての価値は否定できません。