[#TiDD] 手分けするより助け合い - FDDとチケット駆動開発 -
仕事を手分けするのがリーダーの仕事、単純にそう思っていきなり作業を手分けすると失敗しますよ。というお話です。これを書籍「アジャイル開発手法FDD」を元に説明し、チケット駆動開発との関連についても述べます。
原因はコミュニケーション
遅れを取り戻そうと増員するとデスマーチになリ易い事は有名です。新しい人がそれなりの生産性を発揮するには教育期間が必要ですし、単純に見える作業をうまく切り出せてもコミュニケーション量が増大するなど、投入工数に比較してあまり効果が出ないからです。
作業を手分けする場合も同じです。チーム内で関連技術や業務知識が共有され、さらにゴールが明確でなければ、手分けしてもうまくいきません。リーダーが一人のところに人手が足りないからと、増員しただけだからです。
「アジャイル開発手法FDD」にはこうあります。
より多くの人が並列で働くようにすると、ますますコミュニケーションと調和の問題に突き当たるでしょう。解決中の問題に重要な依存性がある場合、適正な場合に必要とする情報をだれもが持てるように、適正なコミュニケーション経路を適所に配置することに勤めなければなりません。(p.14)
これはチケット駆動開発でも同じです。とりあえずWBSができてもプロジェクトの成功が保証されないように、作業がチケットに分割されたからといって作業結果が正しいものである保証はないからです。
まずは共通理解
コミュニケーションの基本は言葉です。「人月の神話」にも出てくるバベルの塔は、傲慢な人間に、神様が言葉を通じなくして塔の完成を失敗させる話です。
古くはデータディクショナリ、最近ではドメイン駆動設計のユビキタス言語のように、言葉の定義は基本です。FDDではモデル駆動型らしく、こう書かれています。
ある言語から他の言語に変換するたびに、情報を損失したり間違った情報を伝達したりする可能性があります。<中略> そのため、情報を変換する回数を増加させないことと、情報が欠落する機会を限りなく減少させるように多くの変換を自動化することを望みます。(p.11)
もちろん、これらの言語で書かれたモデルは確証と検証のフィードバックループが必要です。
チケット駆動開発なら、Wikiも活用すると良いでしょう。用語集をまとめたり、関連情報を体系的に整理しておけば、知識の底上げができてコミュニケーションが容易になるでしょう。
全貌を共有する
言葉が通じるようになっても、プロジェクトをはじめる前に全体像を共有しておかないと、プロジェクトはとんでもない方向に向かいます(少なくとも直近の目標がずれていては、いつまでたってもムービングターゲットをとらえることはできません)。
XPで始まったアジャイル1次ブームでは、プロジェクト開始時に実施すべき内容があまり知られていませんでした。そこで、すぐに開発をはじめるにはモデリングの理解が欠かせないと、XPJUG関西ではビジネスモデリング分科会が立ち上げられるなどしました(これが後のチケット駆動開発勉強会に繋がりました)。
近年は、ビジネスに必要なソフトウェアを明確にするIMPACT MAPPINGやアジャイルマーケティング/リーンスタートアップのリーンキャンパスのほか、インセプションデッキなどが紹介されています。
FDDは、領域専門家と共同して領域オブジェクトモデルを作成することから開始します。実行されたモデリングアクティビティとそれ以外の要件定義のアクティビティから得られた情報を使用して、開発者はユーザ機能リストの作成に進みます。それで計画の概略が作成され、責任が割り当てられます。(p.61)
この場面でチケット駆動開発は、課題やQAの管理、スパイク(ラピッドプロトタイピング)などの管理で活躍するでしょう。
失敗への不安:気になる点は助け合う
「アジャイル開発手法FDD」には、失敗への不安についてこう書かれています。
情報を保留するという誤りになると思われることを極端に恐れていると、明確なコミュニケーションが明らかに危うくなり、しばしば長い間に誤りが増幅されます。(p.12)
独立性の高い構造を実現して、作業を手分けしてもコミュニケーションの問題は存在します。もし、なんらかの危険を感じたなら、その問題をいつ解決すべきかを決め、適切な時期に解決する必要があります。その際には担当の壁を打ち破ることも必要です。
失敗を恐れて守りに入るのではなく、気付いたことを報告して助け合うことが重要です。チケットは口べたな人との情報共有にも有効です。起票を柔軟にして意見を集約できれば、大きな効果が得られるでしょう。
ゴールはプロジェクトの成功
リーダーになると、効率的な作業、見た目の進捗、人を遊ばせない、と言ったことが気になります。しかし、時を見て作業を手分けしなければそれは逆効果になります。
目指すべきゴールはプロジェクトの成功です。プロジェクトの成功に向けてどうすれば、ゴールを共有し、メンバーの能力を最大限に発揮し、どのようにリスクを見極め、高品質で信頼性を高められる設計できるか、をしっかり考えることです。
手分けすることよりも助け合うこと。それがゴールに近づく方法だと思います。チケット駆動開発を活用すれば、情報を共有し、問題を見える化できます。
プロジェクトの状況に合わせて、チケット駆動開発を活用しましょう。手分けして進捗を管理するよりもより多くの効果が、チケット駆動開発の支援で得られるはずです。
« [#TiDD] アジャイル開発のバリエーションからチケット駆動開発を考える | トップページ | [#TiDD] チケット駆動開発によるメトリクス収集のメリット【勉強会告知】 »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
この記事へのコメントは終了しました。
コメント