機能の専念

http://martinfowler.com/bliki/FeatureDevotion.html

一般的な（おそらく最も使用されている）アジャイル方法論のプラクティスは、構築するソフトウェアの機能リスト（ストーリーカード）を作ることだろう。 リスト化された機能は、インデックスカード、作業キュー、バーンダウンチャート、バックログなど、あなたにとって最適なツールで追跡することになる。

こういったやり方は、私は好きである。やるべきことをすべて数週間程度で完遂できる小さなタスクに分解し、進捗を見える化し、成し遂げたことを一目見て分かるようにする。 反復開発の利点は、ある程度まとまりのあるソフトウェアを完遂させることにより、リスクを低減することにある。これは、期間が長く管理しにくいアクティビティ（テスト、結合）をプロジェクトの後半まで残しておくウォーターフォール開発とは異なる点だ。

ただし、この機能リストが突如としてツノを生やし、牙を剥き、固定価格、固定スコープ、前払い設計プロジェクトになってしまうときが問題だ。 Caraig Larmanは、かつて「ウォーターフォールプロセスには、反復開発を何らかのウォーターフォールに変形させる強い抗体がある」というジョークを言った。 RUPはその抗体の犠牲になった一例だ。 RUPの「フェーズ」は「分析、設計、実装、テスト」コンベアの変種へと形を変えてしまった。

ウォーターフォールを跳ね返すカギは、Danも言っているように、アジャイラ(agilist)の価値である「機能よりも成果¹にある。 機能リストは有用なツールである。だが、それは手段であって目的ではない。 重要なのは、最終的な成果である。私はそれを「顧客価値」だと考えている。

重要なのは、機能リストはプロジェクトが進むにつれて変わりうるものだということを、あらかじめ認識しておくところにある。 その都度、新しくできることを発見し、再度、優先付けを行う。 これが適応型計画の肝であり、アジャイルな考え方の指標である。 これにより、計画に対する考えに大きな変化がもたらされた。 計画駆動プロジェクトでは、成功（あるいは失敗）は「計画通りだったか？」という観点で語られることが多い。 しかしアジャイルプロジェクトでは、これは意味のない質問である。 その計画が頻繁に変更されるからだ。 計画とは、主に変更による影響（「この機能を追加したら、どれだけ影響がでるか」）を測るために使用するツールである。 計画とは、FivePoundBagにどれだけ入るかを見積もるためのツールである。 計画が頻繁に変更しないのであれば、適応型計画をしていないのであり、つまりは、アジャイルではないということである。

機能リストには他にも問題がある——機能に価値をもたらすコンテクストを容易に見失ってしまう点だ。 Alistair Cockburnがユースケースを提唱しているのはそのためだ。 ユースケースは、システム利用者の利用方法をナラティブ（物語）として描写しているからだ。 Marc NcNeilも「Customer Journeys（顧客旅行）」という言葉を使って同様のことを述べている。 計画時におけるユースケースの弱点は、 進捗をチェックしたり、プロジェクトの★したりできるような明確な単位に分かれていないことだ。 そのため、ユースケースは計画ツールとしてはあまり役に立たない。 しかし、最適な成果は何なのかを想像するには良いツールであることを否定してはいけない。