[#TiDD] yaXPでXPのハードルを下げ、自律的な組織を実現する
先日の説明では、詳細をXP祭り関西のライトニングトークスのスライドに振っていましたが、やはりネタはネタなので、yaXPについてまとめておこうと思います。XP(eXtreme Programming)にTiDDを適用した事例は、小川さんと共著で書いたSQiPの論文(PDF)にあり、今度のデブサミ2011でも小川さんが語られる予定です。ここでは、私の経験からyaXPの可能性について語ってみたいと思います。
1. yaXPとは
yaXPはBTSを用いたXP(eXtreme Programming)です。XP版のチケット駆動開発と言ってもよいでしょう。
- タスクカードをBTSのチケットにする
- タスクボードをBTSのチケット一覧(レポート)にする
- イテレーションのタイムボックスをマイルストーン(バージョン)で管理する
- スタンドアップミーティングではなく座ってBTSを使って朝会をする
というものです。それ以外は、XPと同じです。
2. XPのハードルとyaXPのメリット
XPにはいくつものハードルがありますが、yaXPと関係するものは以下の3つです。
a) タスクボード
ホワイトボードや掲示板を新たに用意することは困難です。先日の説明のようにエクセルを使ってしまった場合の問題のほか、購入などの決済が必要になることからトップダウンでXPを始めてしまい、XP自体が目的となってしまう可能性のあることが、自律的な活動を妨げます。
エクセルで仕事がトップダウンに与えられるなら、それは作業指示であり、進捗報告のまとめにすぎません。最初に見て、時々誰かが更新するだけです。それによって自分の作業は管理されません。
yaXPなら場所の問題がないだけでなく、より自律的に運用することができます。メンバーがメンバー自身のチケット一覧を表示することができるからです。チケットはチームのスケジュールを管理するものであるだけではなく、個人の作業も管理するものです。
yaXPでは、チケットはコミットされた計画です。担当者が見積もり、約束した結果がチケットなのです。チケットの運営方針によっては、チケットはリーダが作成するかもしれませんし、オープンに誰でも登録できるのかもしれません。いずれの場合でも、担当するチケットを一覧して実現不可能なら、不可能であることを宣言してチーム内で調整する必要があります。
このようにタスクボードを用いなくても、担当するチケットへのコミット(約束)によって自律的な行動が行われます。コミットされたチケットは、妥当な見積もりに基づき、約束されています。無理な計画をやらされるのではなく、自ら約束したスケジュールをメンバー自身が守ることで、安定した開発が行われるのです。
b) トップダウン文化のベテラン
ベーム先生の「アジャイルと規律」では、アジャイルには技術力が必要とされていますが、ベテランが良いとも限りません。トップダウンの組織に慣れている場合があるからです。トップダウンの文化ベテランは、任せられたことはきっちりこなしますが、言われていないことに口を出しません。作業指示をしなければ、何も始まりません。
そこで、リーダーがすべての権限を掌握するのではなく、プロジェクトの特性や状況、メンバーの能力に合わせて権限を委譲します。
yaXPでは、チケットの運用を徐々にオープンにすることで自律的なプロジェクトを目指します。仕様の管理にかかわることは専任者が行うとしても、個人の作業は個人が管理し、抜けている作業があれば自主的に追加するようにします。すると、プロジェクトの雰囲気は大きく変わるでしょう。
オープンな運用により、メンバーはよりチケットを中心に作業するようになります。チケットは管理に都合の良い粒度のものだけでなく、担当者によって作業の重要度によって細かな作業も登録されるようになります。やがて、必要な作業がすべてチケットに登録されるようになります。
チケット一覧はチーム全体の一覧だけでなく、メンバーごとに担当するチケット一覧が使えます。プロジェクトが、チケットの優先順位によってリリースのスコープを変更するように、個人もその日のスコープ(ゴール)を変更しながら、担当作業に集中することができます。メンバーは担当するチケット一覧に基づいて、(1)ゴールを決める、(2)作業を実施する、(3)進捗を登録する、という個人のリズムに集中できるようになります。
このようにして、XPにあるタイムボックスというチームのリズムのほか、個人の日々のリズムという2重構造のリズムが形成されます。与えられた作業がリーダにより管理されるものではなく、個々人の作業を本人が管理するものとしてチケットが用いられるようになります。こうして、プロジェクトはより自律的に運用されるようになります。
c) 構成管理
SQiPの論文(PDF)にあるように、リリースを行いながら開発をすることは、構成管理を難しくします。すでにリリースしたコードに不具合があると、リリースされているのコードだけでなく、開発中のコードにも修正が間違いなく行われなければならないからです。
yaXPで用いるBTSは構成管理ツールと連携して、不具合の履歴や修正に関する議論なども残されるほか、チケットのワークフローによって作業が管理されますので、作業の抜けを防ぐことが可能です。
3. まとめ
yaXPならXPの問題を解決するだけでなく、組織をより自律的にすることが可能です。ただし、それは可能性があるだけです。リーダーが自律的な組織をめざし、そのメッセージをメンバーに伝えることができないなら、実現できないでしょう。
これは従来法にTiDDを適用したとしても、SCRUMにTiDDを適用しても(yaCRUM)、KANBANにTiDDを適用しても(yaKANBAN)同じです。リーダの強い意志とメンバーへのアプローチが必要なのです。
4.補足説明
先日のLTに関して2点補足説明があります。
・タスクカードが剥がれてなくなる
その経験はありません。でも、わかりやすいように並べ替えたり、進捗に応じて貼りなおせば、きっと剥がれることもあるだろうと思って、ネタとして入れました。実際には、セロテープで補強するなり、掲示板なら押しピンでとめておけば問題ないでしょう。それよりも、まずは場所があるかどうかだと思いますので、剥がれるかどうかは本質的な問題ではないでしょう。
・やってみなければいけません
これは私の本心とは違います。あの構成はいわゆる「天丼」というもので、天丼にエビが2本あるように同じことを繰り返すことで、笑いを誘っています。参考文献を紹介する導入としてうまくつながらなかったので「やってみなければいけません」と入れました。本心としては、先日の記事のように実証するか、確信がなければ実施すべきではないと思います。プロジェクトの実施には説明責任があり、私物化は許されないからです。
« [#TiDD] ちょっとまじめにyaXP(yet another eXtreme Programming) | トップページ | やっぱり枝雀さん!「落語 昭和の名人完結編(1) 桂枝雀(壱)」 »
「チケット駆動開発」カテゴリの記事
- 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)
この記事へのコメントは終了しました。
« [#TiDD] ちょっとまじめにyaXP(yet another eXtreme Programming) | トップページ | やっぱり枝雀さん!「落語 昭和の名人完結編(1) 桂枝雀(壱)」 »
コメント