チケット駆動開発の面白さ #tidd
@nobiinu_andさん、@two_packさん、@naitohさん、@haru_iidaさんと第0回関東Redmine飲み会を開催しました。
Redmineに関するマニアックなお話ができて楽しかったです。
またこういう機会を作りたいなと思っています。
皆と話していて、Redmineの背後にあるチケット駆動開発の面白さについて考えたことをメモ。
【1】チケット駆動開発は、Tracのチケット管理の経験を元にまちゅさんが提唱された。
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)
チケット駆動開発(TiDD)が障害管理(BTS)や単なる課題管理(ITS)と異なる点は二つある。
一つは、「No Ticket, No Commit!」と呼ばれる運用ルールでチケットに構成管理情報を付与することで、ITSとSCMを連携する機能に着目したこと。
もう一つは、「Ticket First」「No Ticket, No Work!」と呼ばれる運用ルールでソフトウェア開発のプロジェクト管理をチケット管理に置き換えることで、マネジメントの問題をプログラミングで解ける問題に変換できること。
【2】前者は、OSSのツールを連携することによって、新しい使い方が判明して、その使い方によってソフトウェア開発の生産性が大きく上がる事実を示している。
RedmineはSVNが同一サーバー上だけでなく他サーバーへリモートで接続可能という機能のおかげで、チケットとSVNコミットログを簡単に連携できる。
そして、SCM連携と呼ばれるRedmineの機能によって、要件や仕様からチケットを経由してソースのリビジョン、更にはビルドモジュールまでのトレーサビリティを実現できる。
トレーサビリティによって、過去のパッチの変更理由を追跡できるだけでなく、現在修正中のソースが過去のチケットでどのような変更履歴を持つのかを調べることによって、ソースの意図をより深く理解することも可能になる。
従来のAgile開発、ひいてはソフトウェア開発では実現できなかったトレーサビリティという性質によって、ツール上で厳格な変更管理を運用することも可能。
つまり、トレーサビリティという性質は、ITSとSCMの連携によって生まれたが、同様に他のツールとITSやSCMが連携することによって、新しい使い方を発見できる可能性がある。
@haru_iidaさんは、ITS・SCM・CIの三つのツールを「ソフトウェア開発の3種の神器」と呼んで、ツール同士の連携でソフトウェア開発のインフラを拡張できることを示唆されている。
又、古いツールを使って新しい使い方で利用する現象を、上田さんは「チケット駆動開発はAjaxみたいだね」と話されて、なるほどと思った時がある。
僕は、Redmineの対象バージョンをXPのイテレーションと同一視する運用によって、初めて自然にAgile開発を経験できた。
ITS・SCM・CIだけでなく、テスト管理や品質管理、コードレビューのツールも連携できれば、新しい使い方を見つけることができて、更に開発の生産性を高めることができるだろう。
【3】後者は、ソフトウェア開発のプロジェクト管理を主導する役割がマネージャからプログラマへ移ってきた事を示唆している。
ソフトウェア開発をツールでサポートする発想は従来から試されており、そのようなツールも販売されたり、ツールとセットで開発プロセスが提唱されたりした。
IPA(情報処理推進機構)も昔から、メトリクスを収集するツールはフリーで公開している。
EPMツール:情報処理推進機構:ソフトウェアエンジニアリング
しかし、結局普及しなかったのが現状ではなかろうか?
普及しなかった理由は、ツールそのものが使いづらい点もあるが、「上から目線」の発想にあると思う。
下記のBlogに書かれているように、PMOや品質管理部門が開発チームを教育しようという発想が根底にあり、現場の開発者が顧客(マーケット)であるという発想がそもそもなかったのが最大の原因だったのだろうと思う。
「プロジェクトが遅れない理由」も数値化できる - @IT情報マネジメント
チケット駆動開発はTracのチケット管理から生まれた経緯もあって、現場の試行錯誤の中から生まれた開発プロセス。
だから、開発者が作業しやすいように、作業履歴を残しやすくしたり、タスクとソースのコミット情報を連携したり、進捗が分かるような仕掛けがITSに自然に実装されている。
チケット駆動開発は決して、PMOや品質管理部門、あるいは高尚な理論から生まれたアイデアではない。
チケット駆動開発では、SCMと連携する機能を持つITSをソフトウェア開発のタスク管理へ適用すると、スコープ管理をAgile開発のイテレーション管理へ置き換えたり、タスクの順序入れ替えをチケットの取捨選択に置き換えるなど、まさにXPの計画ゲームっぽいことが簡単に運用できる。
そして、マネージャや開発者から寄せられる苦情や改善要望は、ITSの一機能として実現すればいい。
特に、進捗報告や課題一覧は、マネージャやユーザの観点と開発者の観点で大きく異なるけれど、その問題はチケット集計機能というビューを使い分けることで解決できるはず。
チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索
Redmineが使いづらいと言う質問~開発業務をRedmineへマッピングできていない: プログラマの思索
プログラミングに携わる者としてチケット駆動開発が面白いのは、ITSの機能にベストプラクティスが含まれているため、その機能に慣れると自然に良い習慣が身に付くこと。
逆に言えば、ソフトウェア開発で利用するツールが古いと、最新のベストプラクティスが使えないために、開発の生産性が停滞してしまうこと。
つまり、より拡張された概念であるソフトウェア構成管理のツールがソフトウェア開発の作業手順、プロセス、生産性に制約をかけているのだ。
Excelのプロジェクト管理から脱却せよ~SW構成管理を見直そう: プログラマの思索
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「Redmine」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- Redmine 4.1.2がリリースされた(2021.03.21)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
「ソフトウェア工学」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「プロジェクトファシリテーション」カテゴリの記事
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- プログラマとスクラムが社会実装を変えていく #Findy_GovTech(2021.03.02)
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
「Git・構成管理」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
- 第16回東京Redmine勉強会の感想 #redmineT(2019.05.19)
「チケット駆動開発」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
「Agile」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- 要件定義プロセスはDXで終焉するのか(2021.04.01)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
コメント
うちで使おうとした当時 EPM ツールが対応するバージョン管理システムは CVS で、SVN コネクタはあったみたいですが、うちが Visual Source Safe だったもので、その開発途上のコネクタの (多分唯一の) ユーザー (= 事実上のテスター) をやってました。
相談に乗っていただいた IPA の担当者の方は、上から目線という感じではなく、非常に腰の低い方でしたが...
その VSS コネクタですが、うちのプロジェクトが大きめだったこともあるのですが、3日間くらい Core2 の私のマシンの CPU ファンがうなりっぱなしでようやく EPM に食わせる XML ができるという感じでしたから、周囲から次第に白い目で見られるようになって、採用できずにそのままになっています。
当時対応するチケット管理システムが Bugzilla とか 影舞とかで Trac がはいっていなかった (当時 Redmine は多分なかったと思います) のも痛かったです。
うちが EPM ツールを使えてない理由は、かように単純なものだったので、その後あまり聞かなくなった理由は非常に気になっていました。
投稿: 柴田雅之 | 2011/07/15 09:22
柴田雅之さん
EPMツールは一度入れようとしてすぐに断念しました。
インストールが難しいだけでなく、ユーザインターフェイスも実際の使い勝手も、開発者が実際の開発に役立つような発想で作られていないからです。
「ツールを使う人は誰なのか?」という初歩的な問いに答えていないと思いました。
オブジェクト指向やAgile開発のように、現場の開発者が試行錯誤して生み出したアイデアが結局生き延びているのは、他の開発者も同様に役立つという事実があるからだろうと推測してます。
投稿: あきぴー | 2011/07/15 23:31