チケット駆動開発は計画の変更を恐れない #tidd
チケット駆動開発でのリスケについての質問を見つけたのでメモ。
下記はあくまでも僕の一意見。
ラフなメモ書き。
【元ネタ】
チケット駆動開発でのリスケジュール方針について | OKWave
【1】チケット駆動開発をAgileに運用しているなら、チケットのDoneの条件はリリースする事。
すなわち「バージョンをCloseする=リリースした」「バージョンをCloseできない=リリースしていない」になる。
もし、遅れたチケットを無視してリリースしたなら、チケットは延期されたことを意味している。
つまり、遅れたチケットは次のバージョンへアサインされることと同義だ。
チケット駆動開発において、リスケのタイミングといつだろうか?
Agileに開発しているなら、朝会だ。
Scrumならデイリースクラム、XPならスタンドアップミーティングに相当する。
PLは課題解決マシーン。実作業はメンバーにお任せ。
課題の無いプロジェクトは、メンバーが自己解決する順調なプロジェクトなのか、PLが裸の王様なのか、どちらかだ。
タスクが1MDでも遅延したら、そのタスクは2度と元のペースに戻ることは無い。
TOCの言う通り、スケジュールは遅延が伝播するだけだ。
朝会で課題を見つけて、チーム内で調整するか、上司や顧客へ調整するか、早く判断しなくてはならない。
【2】チケットが遅延した原因を分析するのが大事。
その原因は色んなパターンがある。
例えば、割り込み作業のためにチケットのタスクに専念できない人もいる。
つまり、その人はヤミ作業している。
チケット駆動開発の根本ルールである「チケットに起票してから作業を開始する」「No Ticket, No Work」に既に違反している危険な兆候。
PLはメンバーの作業を完全にコントロールできてないわけだから、体制そのものに問題がある。
あるいは、先行のチケットが終わらないので、タスクを完了できない場合もある。
つまり、タスクに先行・後行の依存関係(PMBOKの言うFSなど)がある。
この場合、基本はクリティカルパスに専念するのが最良の解決パターンだろう。
Agile開発はタイムボックスによる開発なので、チケットの総数を少なくすることで、依存関係を見やすくする利点がある。
プロジェクト内部の作業を見える化することで、自分の作業が誰に影響を与えているか、メンバー自身に喚起させることが自然にできる。
あるいは、TOCの言うクリティカルチェーンに従って、クリティカルパス上のタスクにバッファを作っておき、遅延が伝播しないような仕掛けを入れてもいいだろう。
遅延したチケットで危険なパターンは最低3つは経験している。
一つ目は、リファクタリングしないと機能追加できないチケット。
二つ目は、仕様変更に対応したら、デグレしたチケット。
三つ目は、バグを直したら、他画面の同類バグ調査が漏れていたチケット。
一つ目は、派生開発で起きやすい症状で、当初の設計が調査不足で、見積もりが甘かったことを意味する。
3MDで終わる予定が5MD以上も起きてしまうのはざらだ。
その場合は、リファクタリングのチケットと新規追加のチケットを分ける時が多い。
開発者も、リファクタリングの帽子と新規追加の帽子をかぶり直した方が、頭を切り替えやすくなる。
二つ目と三つ目は、ソース修正の影響範囲の調査漏れ、あるいは、テスト漏れを意味している。
いずれにしても、原因は根深いので、時間をある程度確保して、抜本的な調査を行わないと、バグがモグラ叩きのように出てきて、チームが疲労してしまう。
遅延したチケットに対する抜本的な対策は、最終的にはリスク管理につながる。
チケットが遅延しないように、あらかじめ何らかの対策を用意しておくわけだ。
PMBOKの言うリスクバリュー分析図では、影響度と発生確率の4象限で、リスクに対する態度を決める。
リスクが低ければ、無視 or 却下してもいいわけだ。
つまり、リスクを受容する場合もある。
【3】上記の質問を読んで思ったことは、何故、リスケを恐れているのだろうか?
PMBOK、WF型開発では、ベースラインを設定して予定・実績比較で管理していく。
予定がコロコロ変わっては、実績と比較しても差がなくなるので、差異分析がやりにくくなるからだ。
逆に、Agile開発は計画の変更を恐れない。
むしろ積極的に計画を変更して、プロジェクトをドライブする。
完璧な計画作りよりも、プロジェクトの成功を重視するのだ。
だから、Agile開発では、ロードマップというリリース計画をあらかじめ作るけれども、あくまでも大まかに作っておき、詳細な計画はイテレーション実施前に作り、イテレーションの実施中も頻繁に変更していく。
ITSによるチケット管理の利点は、チケットですべての作業が見える化されるだけでなく、状況の変化をチケットに即座に反映しやすい点もある。
優先度や作業内容、担当者、作業の開始日や終了日が変わったら、チケットの属性を変更すればいいだけのことだ。
ロードマップやチケットを現状に合わせて、チームの現状を誰もが同一に認識出来るようにすれば、自ずから何を解決しなければ前進しないのか、見えてくる。
ファシリテーションが教えるように、問題がはっきりして解ける問題へ変換すれば、人は自然に問題を解決しようとする。
変更されたチケットの内容はリアルタイムに反映されて全員に見える化されるので、部外者の上司や顧客もITSを閲覧できるとなおいいだろう。
丁度、下記のようなTwitterを見つけた。
まさに、ロードマップを第三者が見れば、プロジェクトの状況が単なる遅延だけでなく、遅延したチケットをどのように処理しようとしているのか、というチームの意思も見えてしまうわけだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
「Redmine」カテゴリの記事
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
- PMO観点でRedmineの使い方とは何か(2020.12.20)
「ソフトウェア工学」カテゴリの記事
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
コメント