チケット駆動開発が進むべき道part6~ウォーターフォール型開発への適用の方向性
最近、Redmineの話を聞いてみると、チケット駆動開発を、アジャイル開発を導入する手段として使うのではなく、むしろ、従来のウォーターフォール型開発を補完するような形でチケット駆動開発を取り入れて機能強化しているように思える。
考えたことをラフなメモ書き。
【参考】
第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索
「チケット駆動開発」の適用について考える|コラム「ITよもやま話」|特集│株式会社JSOL
[#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば
なぜ日本ではチケット駆動開発が注目されるのか?(ゲストブログ) | Atlassian Japan
チケット駆動開発を上手に運用するためのプラクティス(ゲストブログ) | Atlassian Japan
【1】日経SystemsではRedmineの記事が1年に1回は掲載されているが、その理由を聞くと、読者アンケートを取った結果では、Redmineの読者評価が高いらしい。
第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索に書いたけれども、SIerのマネージャ層がRedmineを導入して、プロジェクト管理を補完しようとしていると思われる。
もちろん、開発者が現場で使いやすいから、という理由もあるだろうが、上司の理解がなければ、そこまで興味を持たれて、実際に導入することもないだろう。
その方向性を考えると、日本のSIが従来から続けているウォーターフォール型開発に、チケット駆動開発を流用して、不足している部分を補完する動きのように思える。
つまり、チケット駆動開発をアジャイル開発の実装例として導入するのではなく、従来型のウォーターフォール型開発を機能強化する流れと言える。
【2】開発者の観点で見た場合、チケット駆動開発は、チケットとソースの相互リンクという機能が最も最優先だろう。
実際、ソースをコミットしながら、チケットを更新してCloseしていく時に、「No Ticket, No Commit」を運用して、チケットとソースをリンクさせる。
この運用ルールはトレーサビリティの強化につながるので、リリース後の保守で、リバースエンジニアリングしたり、仕様を理解するのに役立つ。
git-flowモデルと組み合わせて運用すれば、多数のブランチ管理もチケット管理と連動でき、ソースの変更理由を追跡しやすくなる。
TiDDとgit-flowを合わせた開発手法について | Technology-Gym
ゆえに、開発者としては、ソース管理が最初にありきで、チケット管理と連携させることで、タスク管理をより強化する方向にいく。
「ソース管理が最初にありき」という考え方は、出荷可能な製品を頻繁にリリースしながらアジャイルに開発していくスタイルと相性が良い。
【3】しかし、マネージャの観点の場合は、チケット駆動開発をメトリクス収集ツールとして扱い、進捗報告や品質管理、課題管理といった管理作業を楽にする機能を最優先するだろう。
彼らとしては、プロジェクトの進捗状況や品質をリアルタイムに見たい。
だから、チケット集計機能が最も重要になる。
タスクチケットをガントチャートで進捗管理したり、障害チケットからバグ収束曲線を出力してテストの終了条件を判定したりする。
また、チケットの予定工数と実績工数をwork_timeプラグインで入力してもらって、コスト管理に役立てることもできる。
チケットの集計条件を色々変えれば、いくらでも欲しいビューを出力することができる。
しかし、Redmineのチケット集計機能は、ロードマップ、ガントチャート、クエリぐらいしかなく、正直貧弱だ。
実際は、クエリでチケットをCSVで抽出し、Excelで整形するやり方が多いだろうと推測する。
【4】Redmineをベースにアジャイル開発として運用する場合と、ウォーターフォール型開発として運用する場合では、頻繁に見るビューが決定的に異なる。
アジャイル開発のように運用する場合は、Redmineのロードマップを基本にして、どのバージョンをいつリリースするのか、に力点をおいて進捗管理していく。
ロードマップ画面はリリース計画そのものであり、RedmineのバージョンはXPのイテレーション、Scrumのスプリントに相当する。
だから、ロードマップ画面による進捗管理を実践すると、自然にタイムボックス単位に開発する運用になる。
この運用の利点は、ロードマップを見れば、過去のリリース履歴から修正されたソースや仕様変更の経緯が書かれたチケットへ辿ることができる。
また、将来、どんな機能を優先してリリースするのか、も一目で分かる。
一方、ウォーターフォール型開発で運用する場合、Redmineのガントチャートを基本にして、当初の予定と実績にどれだけの差異が発生しているか、を中心に管理していく。
Redmineのチケットは、先行・後行関係を付けることもできるので、FS関係を実現できるから、ガントチャート上でクリティカルパスを見つけ出すことは実現可能だ。
ウォーターフォール型開発の進捗管理では、クリティカルパスを守るために有限な資源をリソースしていくやり方が多くなる。
RedmineのガントチャートはMS ProjectのWeb版になりうるか?: プログラマの思索
また、Redmineの最新版では、ガントチャート画面でイナズマ線が表示できるようになったので、どのタスクが遅れているのかが一目で分かるようになった。
Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP Blog
【5】以上のように、Redmineの機能強化の方向性を追いかけてみると、ガントチャート画面を強化するなど、エンタープライズ向けを意識した観点が多く見られる。
実際、イナズマ線を実装したチケットのコメントを見ると、
Gantt progress line needs in Japanese enterprise.
Customer always requires it to developer.
と書かれている。
Feature #12122: Gantt progress lines (html only) - Redmine
Feature #3436: Show relations in Gantt diagram - Redmine
また、最近感じるのは、「Redmineによるタスクマネジメント実践技法」の第8章「チケット駆動開発を発展させるアイデア」の内容を実装した事例をちらほら見かけることだ。
例えば、EVMの実装の一部は、下記のEVMプラグインで既に実現されている。
EVMをRedmine上で実現できれば、コスト管理を予測しやすくなるだろう。
【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索
さらに、ITILの実装例としては、holonという会社が「Redmine for ITIL」というサービスで既に売り出している。
hinemosとも連携しているので、Redmine以外にも付加価値を高めている良い例だ。
Redmine for ITILが解決するもの: プログラマの思索
そんなことを考えると、EVMやITILのように既に理論はあるものの、従来のウォーターフォール型開発では運用しにくかった手法や実現しづらかった手法が、チケット駆動開発では簡単に実現できるため、その手法をRedmineの一機能として実現して適用しようとする方向性のように思える。
但し、その方向性は、アジャイル開発の利点を生かす流れではない。
あくまでも、従来のウォーターフォール型開発を変えることはなく、弱点を補完する機能だ。
この点は僕はあまり意識していなかったけれど、「アダプタブルウォーターフォール」とは違っており、ウォーターフォール型開発を改良する別の手法であるように思えるので、その根本原因や今後の動向を色々考えてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- Redmineで持ち株管理する事例(2024.04.21)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「チケット駆動開発」カテゴリの記事
- 第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)
コメント