チケット駆動開発はまさにチケット管理ゲームだ
Redmineでチケット駆動開発をやっていると、まるでゲームをやっている感覚になってきた。
そのフィーリングをメモ。
【参考】
チケット駆動開発はステータス追跡システム: プログラマの思索
【1】ゲームというモデルには特徴がある。
一つはゴールがあること。
桃太郎電鉄やファイナルファンタジーも、資産が一番大きいこと、全てのステージをクリアすることがゴール。
つまり、成功の終了条件がある。
当然、ゴールに達せずにゲームオーバーする時もある。
完了できずに途中リタイアの時もある。
チケット駆動開発のゴールは、期日までに全てのチケットを終了ステータスにして、システムをリリースすること。
そのために、Redmineバージョン単位にタスクをグループ化して、小刻みに定期的にリリースしながら、システムの品質も機能も拡張していく。
いきなり最終ゴールを目指すのではなく、ステージを踏みながらゴールに近づいていく。
その方が確実なのだ。
とはいえ、チケット駆動開発を運用してもうまく回らず、破綻する場合もある。
チケットが乱発されたり、誰もチケットに対処せずに放置したり、一人がチケットを溜め込んだりして、期日までにリリースできなかったら、ゲームオーバーと同じ。
チケット駆動開発をやっていると、XPの言うドライブ(運転)の感覚が分かってくる。
ソフトウェア開発のプロジェクト管理は、いつもコントロール(ドライブ)しないと、すぐにハンドルで制御できなくなって、デスマーチに陥りやすい。
ゲームオーバーにならないように、チケットを取捨選択しながら、リリースに近づけるのが大事。
ゴールに近づくには、定石があるのだ。
その定石は既に色んなプラクティスが知られているので、うまく当てはめればいい。
【2】二つ目はルールがあること。
何でもかんでも可能なわけではなく、行為がルールによって限定される。
代わりにアイテムがある。
パワーアップできたり、防御できるアイテムがある。
それらアイテムを上手く使いこなすのが大事。
チケット駆動開発では、チケットを起票する時、チケットの内容だけでなく、開始日・終了日、担当者、マイルストーン(バージョン)を入力しなければならない。
又、チケットをCloseする時は、ワークフロー管理機能によって、必ずリーダーがCloseするなどのルールもあるだろう。
チケットのライフサイクルには厳格なルールがある。
Redmineによるチケット駆動開発のアイテムは、リリース計画(ロードマップ)と各種のチケット集計機能、そしてワークフロー管理、トレーサビリティの4つ。
まず、ロードマップで大まかなリリース計画を立てて、イテレーション計画で更にタスクを詳細化する。
当然、リリース計画は、イテレーション実施中も現状に合わせて柔軟に変えて、状況を見える化する。
地図が最新化されていなければ、ゴールまでの距離も分からない。
イテレーション実施中は、ガントチャート、かんばん、サマリなど各種のチケット集計機能で進捗やリスクをリアルタイムに把握する。
自分たちの能力はどれくらいなのか、今どれくらい自分たちは傷ついているのか、今後どんなトラップがありそうなのか、を早めに検知できれば、リスクに対して準備しやすい。
又、チケットの種類に応じてワークフローを変えて、ペア作業するときもあれば、顧客と質問や問合せをキャッチボールする時もある。
あるいは、チケットとソースの相互リンクによって、成果物の履歴管理だけでなく、ソース修正の変更理由を追跡できて、コミュニケーション向上に役立てたりする。
チケット駆動開発のアイテムは、特にRedmineならRubyで簡単にパワーアップできる。
足りない武器は、自分でアイテムを作ってしまえばいい。
【3】何よりもゲームは楽しい。
ゲームをやる事自体が楽しい。
夢中になって我を忘れてしまう。
チケット駆動開発をやっていると、自分たちの作業履歴がタイムラインとして残る。
タイムラインをふりかえるだけでも、結構気づきがある。
特に新人は、作業履歴やコミット履歴を振り返って、自分は半年でこれだけ仕事できたのだ、と自信がつくらしい。
チケット駆動開発はプロジェクトファシリテーション(PF)と相性が良い。
ニコニコカレンダー、かんばん、ソフトウェアあんどんなどのアイテムは全てRedmine上で実現可能だ。
朝会で毎日の自分のタスクを確認するだけでなく、プロジェクトのゴールや各人の役割を共有する。
リリース後のふりかえりで、イテレーションの作業ログを見ながら、自分たちの能力を客観的に直視して、次のイテレーションへ向けて、プロセス改善していく。
KPTによるふりかえりの結果をWikiに残して、数回ふりかえりを続けると、各人の成長、チームの成長が分かるので、モチベーションアップにつながる。
それが楽しい。
下記の記事を読んで、似たような感想を持った。
日々是精進。: 2/17: デブサミ 2011 / チケット管理システム大決戦
(引用開始)
Face To Faceのやりとりの大切さは、スピーカーの皆さんが仰っておりましたが、会話の中で出てきた本当に共有すべきことや、お互いに合意し合った証、アイディアの種は、大切にプラットフォーム上に記していきたいな、と思いました。
きっと、あとでITS上のタイムラインを眺めることで、自分たちのプロジェクトの軌跡をたどることができる、大切な『場』になってくれるんじゃないかな~、と思っています。
(引用終了)
そんなことを考えると、チケット駆動開発は単なるソフトウェア開発のタスク管理だけでなく、チケットをトランプのカードに見立てて、どれだけ早くチケットをこなしながら、リリースと言うゴールに近づけるのか、というゲームをやっている気がしてくる。
XPの「計画ゲーム」というプラクティスは、多分そういうことを意味していたのではないかと直感している。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント