チケット駆動開発がWF型開発と相性が悪い理由
「SIの現場で使えるチケット駆動開発|セミナー|Growth xPartners Corporate Site」セミナーをUStreamで聞いて、思ったことをメモ書き。
【元ネタ】
2013/08/24(土)「SIの現場で使えるチケット駆動開発」セミナー #gxptech - Togetter
【1】Excelによるプロジェクト管理は、計画作成時はまだしも、その後の実績管理の運用では、利点よりもたくさんの弊害の方が出てくると思う。
しかし、最近はRedmineを導入したものの、思ったような効果が出ていない事例をよく聞く。
話を聞くと、Redmineによるチケット駆動開発をそのままWF型開発を当てはめようとして、うまくいっていないという事例が多い。
【2】Redmineのガントチャートでタスク管理しようとする場合、MSProjectと異なる点は、チケットの粒度が異なる点と予実管理ができない点があげられる。
顧客やプロマネの観点と開発者の観点でチケットの粒度が異なる理由は、以下に既に書いた。
チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索
予実管理がRedmineではやりにくい理由は、Redmineチケットに、予定の開始・終了日と実績の開始・終了日が区別されておらず、実績管理しかできないように機能実装されているからだ。
つまり、Redmineでは、本来チケット管理で予実管理を厳密に運営することは想定されていない設計思想で作られている。
だから、WF型開発でチケット駆動開発をやろうとすると、予定に合わせるようにタスクを調整するマネジメント手法が正直使いづらい。
WF型開発は、当初の計画で決められた予定をベースラインとして、実績として発生したタスクを合わせようとして、変化を抑えこむやり方。
計画で作成された予定作業がコロコロ変わると、ベースラインとして意味がなくなってしまう。
予実管理によって、予定よりも遅れたタスクに注目して是正対策を取る。
チケット駆動開発では、ロードマップのビューを主に使って、決められた期限までにどれだけのタスクを実現するか、という観点で、スコープ管理する発想。
タイムボックスという箱に、状況に合わせてチケットを詰め込むやり方。
だから、チケットという作業スコープに着目して、チケット管理していく。
チケット駆動開発では、チケットに予定日を入れたとしても、ロードマップに当てはまるように随時調整するため、予定日は意味をなさない。
つまり、チケット駆動開発はアジャイル開発と同様に、計画と実績の偏差(ばらつき)に着目して、タイムボックスに入るようにタスクを調整する。
つまり、プロジェクト管理におけるWF型開発のやり方とチケット駆動開発のやり方は全く発想が違う。
他にもWF型開発に囚われすぎたアンチパターンについては以前まとめた。
WF型開発にとらわれすぎたTiDDのアンチパターン #tidd: プログラマの思索
【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索
このようなアンチパターンが発生する原因は、BTSから生まれたチケット駆動開発が当初の利用範囲から外れた箇所に適用されたためだろうと思っている。
【2】では、WF型開発にチケット駆動開発を適用するには、どんな手法が必要か?
チケットで予実管理をやりたいならば、チケットに予定・実績の開始・終了日を設けるようなカスタマイズが必要だろう。
また、進捗管理が一目でわかるような、ロードマップとは違う別のビューが必要だろう。
多分、ガントチャートをもっとカスタマイズする必要があるだろう。
あるいは、CCPMのような発想を取り入れるといいかもしれない。
つまり、計画作成時に予定されたチケットを作るが、チケットに実績情報を入力する時に、残工数がひと目で分かるようにして、プロジェクト全体の残工数で進捗管理する手法を取ること。
個人的には、純粋なWF型開発をそのままチケット駆動開発に適用した場合、カスタマイズすれば運用できるだろうが、チケット駆動開発の利点が消えてしまうため、恩恵がなくなるのではないかと思っている。
WF型開発へのチケット駆動開発の適用方法については、@sakaba37さんが「アダプタブルウォーターフォール」という概念で説明されているので、そちらを御覧ください。
【3】では、Redmineによるチケット管理は万能なのか?
@yusuke_arclamp さんや@digitalsoul0124さんも話されていたが、担当者が決まらないチケットは、チケットとして起票してもあまり意味を成さない。
例えば、WBS作成時は、詳細なタスクが分からない項目もまずは空き箱として配置できるが、チケットに起票したとしても、そのチケットからどのように作業していけばよいか分からないから、放置されやすい。
Twitter / akipii: #gxptech WBSでは曖昧な課題やタスクを空箱として配置できるが、チケットは曖昧なタスクを登録しても運用しにくい。@yusuke_arclamp さん談。
また、「チケット管理は予実管理しにくい」という特徴から、チケット管理のモデルを考えると、チケットはマスタではなくトランザクションである。
つまり、チケットは、予定というマスタ情報を蓄積するのではなく、実績としてトランザクションを日々記録していく方が向いている。
だから、チケットを元帳のように扱うことには向いていない。
むしろ、GTDのように、次々に発生するタスクをどんどん消化していくやり方の方がチケット管理に向いている。
最近、Redmineによるチケット管理をヘルプデスク管理や顧客管理、資産管理に使う発想が試されている。
日々のトランザクションを管理する点はチケット管理は最強だが、顧客マスタやPC資産マスタというマスタ情報(元帳)はチケットではなく、別のマスタを用意する方が扱いやすい。
つまり、チケット管理がうまく当てはまる業務であるか否かという判断条件は、チケット管理のモデルの特徴に大きく依存していると考えている。
この辺りは今後まとめてみたい。
【追記】
@yusuke_arclampさんや@sakaba37さんも、チケット駆動による進捗管理についてBlogを書かれている。
| 固定リンク
「モデリング」カテゴリの記事
- SQLは画面や帳票のインターフェイス層に相当する(2021.04.10)
- 統計学と機械学習の違いは、データの説明かデータの予測か(2021.04.01)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 「データモデル大全」は良い本だ(2021.03.21)
- 関西IT勉強宴会の感想~コロナワクチン接種管理システムのデータモデリング(2021.02.25)
「プロジェクトマネジメント」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
「Redmine」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- Redmine 4.1.2がリリースされた(2021.03.21)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
「ソフトウェア工学」カテゴリの記事
- なぜInfrastructure as Codeが必要なのか?(2021.04.18)
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
「チケット駆動開発」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
「Agile」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- 要件定義プロセスはDXで終焉するのか(2021.04.01)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
コメント