[#TiDD] チケット駆動開発の「ライトウィング」と「レフトウィング」

チケット駆動開発で考慮すべきバランスと視点を書きましたが、実際に進める場合には２つの戦略を意識すると良いと思います（平鍋さんのアジャイルの「ライトウィング」と「レフトウィング」（An Agile Way）を参考にまとめてみました）。

チケット駆動開発ではプロジェクトの透明化を高めて、業務を効率化し、顧客の満足とチームの仕事への満足感を得る事が目的と考えています。しかし、現状から一気に完成されたプロセスに移行できませんので、いわゆる「巨人の肩に乗る」事が必要です。

チケット駆動開発の巨人は２人います。一人はツールの設計思想で、もう一つは社内文化です。

ライトウィング（設計思想に乗る）

ツールによる自動化などで環境を整えて業務を効率化する「ライトウィング」では、ツールを導入する事でツールの背景にある設計思想を実現します。

No Ticket, No Commit!は、チケットのないコミット（構成管理上の更新）は禁止するというチケット駆動開発のプラクティスです。導入によってチケットに全ての情報を紐づけるという文化ができていきます。

継続的統合・テストを行えば、常に動作可能なコードが維持され、その動作が保証される様になります。テストコードを常に書く文化が根付きますし、 継続的デリバリー も導入すれば「現地・現物」が実現されます。

継続的統合ツールやチケットの情報を利用してメトリクスの収集をすれば、定量的なデータが常に得られる様になり、リファクタリングする際の参考情報や、プロジェクトの異常な状態の検出にも役立つでしょう。

レフトウィング（社内文化に乗る）

一方、人が能力を最大限に発揮できる様にチーム作りをするのが、ライトウィングです。現状の社内文化を見極めて、少しずつモグラたたきをしていきます。

チケット駆動開発によって自主的なコミュニケーションが支援される様になると、トップダウンな管理をやめてサーバントリーダーシップを発揮すれば、自律的組織を目指せます。近年のソフトウェア開発では、すでに一人で全ての技術要素の詳細を把握する事は困難ですので、チーム内の気付きや懸念、アイデアを共有して、チームで挑戦しなければいけません。

また、アジャイル開発のタイムボックス管理によるスコープの変更や、TOCのCCPM(CCPMのグッときた話 - TOC/TOCfE関西分科会 -) におけるバッファ管理など、これまでのプロジェクトの管理方法を変更する場合も、現状の文化を考慮した上で、何を固定して何を変化させるかを明確にした上で、新しい方法を導入しないといけないでしょう。

このほか、顧客と同じ方向を向くことも大切です。要望を満たせば納期が遅れても良いと誤解したり、形だけの営業トークだけでは意味がありません。お互いの業務と利益構造を理解した上で、提案し、助け合えるような関係は、単純にチケットのやり取りだけでは構築できません。互いの担当者の個性や契約上の利益相反もありますので、互いを認め合う事から時間をかけてはじめないといけないでしょう。

ツール導入

ライトウィング・レフトウィングに関わらず、これらの大元になるのはツールの導入です。チケットシステムで何ができるか、どのように運用するかをイメージできなければ、チケット駆動によるプロセス改善は始まりません。

まずは、障害管理から初め、備忘録的なタスク管理をし、必要に応じて進捗なども管理すると良いでしょう。

さらに、wikiなどを含め、チケットシステムをコミュニケーションの基盤として使い、社内のワークフローを見直すと、チケット駆動開発の可能性も徐々に見えてくるでしょう。

ご参考；
[#agileto2012] 『チェンジ！』の考え方 ～マネしやんと！～

【告知】大阪/東京のRedmineの勉強会

6/22 第8回RxTstudy Redmineやタスク管理を考える勉強会＠大阪

6/29 第5回 shinagawa.redmine勉強会