プログラマの思索

要件管理をRedmineやTrac上で試しているが、しっくりこない原因をメモ。

【元ネタ】
チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

RedmineへScrumのアイデアを注入: プログラマの思索

まちゅさんは、「チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)」で下記のようなコメントを残している。

TiDD は開発プロセス全体を網羅するものではない。開発プロセスを補完するもの。
* チケットの粒度が細かいことと、構成管理ツールと密接な関係があることから、アウトプットが明確な領域に適用しやすい。
* 要件定義などの不確定要素が大きいタスクに適用するのは難しいかも。

まちゅさんが言うように、TiDDは構成管理ツールと相性がよいので、成果物の管理とチケットを連携させると効果的。
特に、実装やバグ修正、リリース作業で威力を発揮する。

しかし、要件定義や設計のプロセスでは、TiDDはしっくりこないのが僕の実感。
チケットに要件や仕様を書いても、それで漏れなく十分足りているのか分からない。
要件も仕様も、設計して実装して動かしてみて、初めて間違いや漏れが分かる。
設計工程の品質が悪いのが元々の原因だが、その設計の質をアップするのにチケットが役立っていない。
設計プロセスで重要なのは、設計という作業を通じて、本来の要件を緻密に詳細化することだから。

むしろ、要件定義や設計工程で、要件や仕様の確認などの課題管理にチケットを使うと、上手に回る。
例えば、顧客と要件を質問したり、設計者と開発者で仕様のやり取りをする場合、チケットで作業状態を管理すれば、進捗やリスクを追跡しやすくなる。
つまり、設計そのものではなく、要件定義や設計と言う作業はチケットで管理した方がスムーズに回る。

以前、顧客向けの進捗報告を作るために、ストーリーカードをチケットに落として、進捗や作業状態を集計しやすくする方法を考えて、実践してみた。
実際の運用では、ストーリーカードへタスクカードの状態を手作業で反映するのが面倒で、あまり有り難味が感じられなかった。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

RedmineのScrumプラグインのように、チケットの親子関係をRedmine上で実現してくれれば、その作業は自動化できるだろうと思う。

RedmineへScrumのアイデアを注入: プログラマの思索

ところで、派生開発プロセスXDDPでは、設計プロセスでソースからリバースエンジニアリングして、要求仕様書や変更仕様書を作る。
ここで、要求仕様書は今回限りの要件を洗い出したドキュメントであり、変更仕様書はソースの修正手順まで書いた今回限りのドキュメントである。
システムの外部設計や内部設計を書いている機能仕様書には、派生開発が終わり次第、要求仕様書や変更仕様書から変更箇所がマージされて、最新の仕様が反映される手順になる。

つまり、機能仕様書はVerUpしていく。
機能仕様書は構成管理の管理下に置かれるべきものであるから、チケットで管理できる。

しかし、今回限りの成果物である要求仕様書や変更設計書はVerUpの対象ではない。
これらは仕様化プロセスの一時的な成果物。
もし、これらをチケットで管理した場合、作業は管理できるが、仕様化して詰めていく作業はチケットとは別物だ。

XDDPが示唆することは、要件定義や設計のプロセスは、チケットではなく別の何かで管理すべきと示唆しているように思えてならない。

要件管理や設計という上流工程をいかに制御するか？
まだその実現方法が分からず試行錯誤中。