「アジャイル開発手法FDD―ユーザ機能駆動によるアジャイル開発
」を読んで、Agile開発のスケールアップに必要な概念が揃っている感覚に陥って驚いた。
考えたことをメモ。
間違っていたら後で直す。
【元ネタ】
ユーザー機能駆動開発 - Wikipedia
トカゲの独り言: 『アジャイル開発手法FDD』読了
銀行システムの失敗から生まれた開発方法論 - 日経コンピュータ・コラム：ITpro
Twitter / @akipii: FDD(Feature Driven Development)本を読んだら、まるでデジャブみたいだった。概念モデル設計＝ドメイン駆動設計(DDD)。フィーチャ＝ユーザ機能リストorバックログ。フィーチャの進捗＝パーキングロットチャート。
Twitter / @akipii: FDDのクラスオーナーはConwayの法則の観点からも正しい。SW組織はテクノロジラインではなく、フィーチャ単位でチームを分割して作るべき。OL・BT・サーバー・設計チームのようなテクノロジで分割された組織は統一されたアーキテクチャの無い複雑なソフトウェアを作る。
Twitter / @akipii: FDDがScrumやかんばん(リーン)に影響を与えたものは、パーキングロットチャートではないか？ 要件管理の鍵はパーキングロットチャートにあるような気がする。
【FDDの特徴】
ユーザ機能駆動開発は、概念モデルからユーザ機能(Feature)のリストを抽出して、ユーザ機能をインクリメンタルに開発していく初期アジャイル開発手法の一つ。
オブジェクト指向設計と密接に絡んでいるのが特徴の一つ。
初期アジャイル開発では、XPやScrum以外の例の一つとしてFDDがよくあげられていたが殆ど普及されていないように思える。
FDDの最大の特徴は、ユーザ機能を顧客に価値あるソフトウェアの機能と定義して、ユーザ機能を中心に設計や開発をインクリメンタルに開発していくこと。
ユーザ機能の概念は顧客の観点を重視しているので、顧客に価値あるソフトウェアを届けるアジャイル精神とすごくマッチする。
【概念モデル設計＝ドメイン駆動設計】
FDDで面白いと思ったものはいくつかある。
一つ目は、FDDのプロセスの最初に行われる全体モデル構築プロセスとは、まさにドメイン駆動設計(Domain Driven Development)そのものだ。
実際、「アジャイル開発手法FDD―ユーザ機能駆動によるアジャイル開発」の翻訳では、領域専門家と開発メンバーが領域分野からモデルを抽出すると書いているが、これは、業務知識(ドメイン)をよく把握している業務SEと開発者が、ドメイン駆動設計から概念モデルをオブジェクト指向分析(OOA)によって作り上げる意味だろう。
プロセスの内容を読んでみるとまさに、Eric Evansのドメイン駆動設計の本の内容をそのまま適用しているかのようだ。
FDDを提唱したピーター・コードはOOAの専門家であるから、アジャイル開発とOOAをうまく絡めているのだろうと推測する。
【ユーザ機能リスト＝バックログ】
二つ目は、概念モデルからユーザ機能リストを作成する手法は、まさにバックログを作るのと同じだ。
ユーザ機能リストとは、概念モデルから顧客に価値あるユーザ機能を抽出して一覧にしたもの。
面白いのは、ユーザ機能は＜アクション＞＜結果＞＜オブジェクト＞で表現されるもので、ユーザ機能のサイズは2週間で実装できるサイズまで小さいこと。
OOAではユースケースを作ってからクラス設計していくが、「アジャイル開発手法FDD―ユーザ機能駆動によるアジャイル開発」ではユースケースを暗に批判している。
ヤコブソンいわく、10人年のプロジェクトではユースケースは大体20個レベルと言うぐらいの粒度なのに、ユースケースの粒度は実プロジェクトではバラバラになりやすい。
又、伝統的な構造化設計に慣れたドメイン専門家は、ユースケースを詳細設計書のように、ユーザインタフェースと永続化の詳細、ビジネスロジックをごちゃ混ぜに書いてしまいやすい、と。
僕の経験でもユースケースは書きづらいし、書いたとしてもあまり役立たない。
クラス図やシーケンス図を見た方がプログラム設計が分かるし、ユースケース以前の業務フロー図の方が業務を理解しやすいからだ。
FDDがユーザ機能(Feature)という概念を抽出したことは注目に値する。
XPではストーリーカードという概念があるけれども、開発者の視点が強く、顧客に価値ある機能という観点がはっきりしていないように思える。
ユーザ機能が2週間で実装できるサイズだからこそ、インクリメンタルに開発することも可能になる。
ユーザ機能はばらつきが出やすいだろうから、ユーザ機能を2週間レベルのサイズへ落とすには、オブジェクト指向分析の技術で更に分割することが必要で、ドメイン駆動設計の本が有効だろうと思う。
そして、ユーザ機能リストというバックログを作ることができれば、ビジネスの重要度や作業の優先度から、どのユーザ機能を先に開発していくか、という判断がやりやすくなる。
Scrumのバックログやリリース計画の話と非常に似通っていているので、今となってはむしろ分かりやすいように思える。
【ユーザ機能単位計画＝リリース計画】
FDDでは、ユーザ機能リストというバックログを作ったら、ユーザ機能単位計画を作り、その計画に従って開発していく。
ユーザ機能単位計画はまさにリリース計画であり、Redmineのロードマップに相当するだろう。
計画作りで重要な点は、ユーザ機能に期限(完了予定日)、つまりリリース日を付けることだ。
すなわち、イテレーションの終了日と一致するから、XPのイテレーション計画又はScrumのスプリント計画を作ることと同義。
実際、ユーザ機能単位計画では、ユーザ機能を実装するためにクラスへ更に分割して開発順序を決めていくが、その作業は、フィーチャからストーリーカードへ分割し、更にタスクカードへ分割し、それらの作業順序を決めることと同じ。
FDDが他のAgile開発手法と異なる点は、ユーザ機能を実装レベルのクラスに落とす時に、クラスに開発者を担当させて、クラスの中身(ソースコードそのもの)の最終責任者を決めることだ。
つまり、OOAの責任駆動設計と開発者の実装責任をリンクさせる点に最大の特徴がある。
【ユーザ機能チームとクラスオーナー】
XPでは、ソースの共同所有というプラクティスがあるように、ソースやクラスに責任者はおらず、全員で開発していく。つまり共同担当。
FDDでは、概念モデル(領域オブジェクトモデル)からひとまとまりのクラスの担当としてクラスオーナーが割り当てられる。つまり個別担当。
共同担当の利点は、誰かがソースを修正するまで自分の修正を待つこと無しに自ら直していくことができるので、アジャイルに開発しやすい。しかし、最終責任者がいないから、メンバー数人が主導権を握ってしまい、彼らが全ての仕事を行おうとして、負担が大きくなりがち、と指摘している。
個別担当の利点は、クラスの開発者が最終責任者だから、その業務(ドメイン)やコードの概念的完全性に対する責任に一貫性があるので、クラスの品質は保持されること。
逆に、個別担当の弱点は、Fatなクラスを実装する開発者の責任が重くなりがちで、ボトルネックになりやすいことと、クラスオーナーがいなくなると、クラスに関する業務やコードの知識が抜けてしまうこと。
そこで、FDDではユーザ機能チーム結成とインスペクションで対応しようとしている。
インスペクションはレビュー技法の一種で、インスペクションを通じて、クラスの業務(ドメイン)やコードをチーム全員で共有可能にする。
ユーザ機能チームは、ユーザ機能を担当するチーフプログラマ(リーダー)が、実装に必要なクラスオーナーを集めた開発チームを作ること。
そして、ユーザ機能チーム内部で、チーフプログラマは複数のクラスオーナーの間で発生する諸問題を調整する役割を担うことで、上記の問題を解決しようとする。
特に、Fatなクラスは責任が重過ぎる症状を示しているから、そもそものクラス設計を見直す時もありうる。
FDDでは、実装対象のクラスとユーザ機能を実現するクラス(ドメイン)を故意にリンクさせているので、そういうリスクが発覚しやすい利点があり、そのリスクの解決責任をユーザ機能チーム全体に負わせているのだ。
ユーザ機能チームは特定のユーザ機能を実装するために結成されているので、それを実装する必要なソース全てを担当しているので、クラスオーナーは必ずいるし、コードの変更のために他チームへ依頼する必要もない。
だから、コードの個別担当と共同担当の両方の感覚をユーザ機能チームは持っている特徴を持つ。
「アジャイル開発手法FDD―ユーザ機能駆動によるアジャイル開発」では「ユーザ機能の受付箱を持っているかのようにチームリーダーは、ユーザ機能の達成に責任があり、ユーザ機能の受付箱を持っているものとして考えることができます」というまずい翻訳があるが、多分そういう意味だろうと推測する。
【ユーザ機能チームとマトリクス型組織】
更に、ユーザ機能は2週間で実装できてしまうため、実装完了したらチームは解散して、次のユーザ機能チームを結成していく。
つまり、ユーザ機能を担当するチーフプログラマは必要なクラス担当者(クラスオーナー)を選び出し、開発が完了したら解散するというサイクルを2週間おきに何度も繰り返す事になる。
すると、ユーザ機能チームはクラス担当者の混合編成、つまり、マトリックス型組織の構造を持つ。
PMBOKのマトリックス型組織はラインとスタッフの2つの観点でメンバーは管理されるが、FDDでは、ユーザ機能とクラスという観点で開発者は組織される。
マトリックス組織は確かに柔軟な構造であるが、2つの説明責任が発生するためメンバーの負荷が高くなりがち。
FDDでは、ユーザ機能チームのチーフプログラマがマトリックス型組織で出てくる諸問題を調整する役割を担っているのがミソ。
【Conwayの法則とユーザ機能チーム】
FDDのユーザ機能チームは、Conwayの法則「システムのアーキテクチャは組織構造に従う」の観点から見て、うまく設計されているように思える。
Conwayの法則～アーキテクチャは組織にしたがう: プログラマの思索
Redmineプロジェクトの構造とConwayの法則: プログラマの思索
オブジェクト指向分析には責任駆動設計という概念があり、Fatなクラスは責任が重すぎるため、更に分割して粒度を合わせるべきだというプラクティスが含まれている。
FDDでは、概念モデルのユーザ機能と開発担当のユーザ機能チーム、概念モデルのクラスと開発者(クラスオーナー)が対応付けられているので、システムのアーキテクチャと組織構造がそのまま直接マッピングしている特徴がある。
この特徴によって、システムのアーキテクチャはすごく見通しがよくなるだろうと推測する。
Conwayの法則に反する組織構成の例は、テクノロジラインでチームをつくることだ。
例えば、設計チーム・開発チーム・品質保証部門のように、工程別にバラバラに組織構成してしまうと、チーム間の断絶の部分で必ず認識漏れが出て、システムの構造が複雑化してしまう。
あるいは、業務システム開発でオンラインチーム・バッチチーム・サーバーチームなどのように技術別に分けてしまうと、結合テストで必ず火を噴く。
何故ならチーム内部で完結する機能は認識済みなのでテストもしているだろうが、各チームのインターフェイス部分はテストしていないので必ず認識漏れがあり、その部分にパッチを当てる度にシステムはどんどん継ぎ接ぎだらけになってしまうだろう。
システム開発の大規模化が難しいのは、Conwayの法則に逆らった組織構成にしてしまうのが最大の原因ではないかと最近思っている。
【パーキングロットチャート】
FDDが他のAgile開発にはない特徴を持つものは、パーキングロットチャートを編み出したことだろう。
パーキングロットチャートはフィーチャ(ユーザ機能)の進捗を示すための図だ。
InfoQ: かんばんボードによるプロジェクトの見える化
パーキングロットチャートには、ユーザ機能名とユーザ機能を実装するストーリーカード数、ストーリーカードの完了率、期限(リリース日、マイルストーン)が表示されている。
又、ユーザ機能の状態が色分けされており、進捗が遅れたら赤色、完了したら灰色のように表示されるので、一目で分かる。
Agile開発の進捗報告ビューでは、タスクボード(かんばん)・バーンダウンチャート・パーキングロットチャートなどがあるけれども、顧客の観点では、パーキングロットチャートが一番わかりやすいだろうと思う。
顧客にとって価値あるものはユーザ機能であり、ユーザ機能の進捗状況がパーキングロットチャートから読み取れるからだ。
タスクボードは開発者のタスクカードの進捗状況を示したものであり、粒度が細かすぎる。
バーンダウンチャートは確かに予定と実績の差が分かるけれども、進捗の遅れがどこにあるのか、その詳細は分からない。
バーンダウンチャートはあくまでも集計結果にすぎないからだ。
Redmineでは、@daipresentsさんがタスクボード・バーンダウンチャート・パーキングロットチャートのプラグインを実装してくれていて、僕も実際に使ってみた。
redmine_parking_lot_chart
redmine_version_burndown_charts
redmine_task_board
Redmineに入れたプラグイン一覧part2: プログラマの思索
タスクボードは確かに面白いのだが、リーダーも開発者もRedmineのチケット一覧の方をよく使う。
ステータス別だけでなく、期間や担当者、カテゴリなどの観点で絞りたい時が多いからだ。
また、バーンダウンチャートは、開始日・予定日はもちろん予定・実績工数をきちんと入力してくれないと綺麗なグラフにならない。
Redmineのバージョンは期限しか保持しないため、開始日が遠く離れていると変なグラフになってしまう。
でも、パーキングロットチャートは確かにすごく分かりやすい。
Redmineバージョンをイテレーションに同一視する場合、普通はイテレーションはユーザ機能を実装するために開発するわけだから、ユーザ機能に同一視しやすい。
@daipresentsさんが、パーキングロットチャートをRedmineの運用で「唯一生き残ったプラグイン」と評価した理由が何となく分かったような気がする。
Redmineでアジャイルチームのスピードやパワーを見える化する | 世界 - @daipresents
又、パーキングロットチャートプラグインを使ってみて、これらプラグインを実装された@daipresentsさんはアジャイル開発をよく研究されているなあ、という感想を持った。僕の方がまだまだ足りないと思っている。
【感想】
FDDはピーター・コードが編み出しただけに、TogetherControlのようなツールと一体化されてしまって、あまり流行していないように思える。
でも、FDDが編み出した概念は現在のAgile開発に取り入れられたものもあるし、取り入れた方が良い考え方もあるように思う。
色々考えてみる。
」が絶賛されていたので、立ち読みした感想をメモ書き。
」を読んでみたら、とてもインスピレーションが働いたので、即購入した。
や
を駆使して、OOAのモデリングの過程を詳しく解説してくれているのがとても分かりやすかった。
」は2000年代前半に勉強会で輪読したから、OOAがどういう手法でどんな成果物を作るのか、ということは分かっていたので、「
にあるアジャイルテストの４象限の観点のように、単体テストだけでなく、機能テストや受入テスト、負荷テスト、セキュリティテストなどもある。
では、ソフトウェア品質にディペンダビリティの概念を導入することは本来の概念を曖昧にしてしまうという観点で批判していたけれど、最近の風潮はソフトウェアとそれを取り巻く業務も含んだ品質(つまり、ディペンダビリティ)に変わってきているのだろう。
」を読み返した。
」が詳しく、とても参考になる。
」を昨年秋に出版していたらしい。
」の用語も読みやすくなるし、何故そんなデータモデルが必要になるのか、何故そのようにモデルを変形していくのか、理解しやすくなる。
最近のコメント