プログラマの思索

SQIP2015チュートリアルの講演資料「チケット駆動開発の運用パターン集～問題はチケットに分割して統治せよ」をCC Attribution ライセンスで公開します。

【参考】
併設チュートリアル 講演テーマ・講演者紹介「チケット駆動開発入門 ～基礎から応用まで～」 | ソフトウェア品質シンポジウム 2015

[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -: ソフトウェアさかば

【1】講演の目的と内容

@sakaba37さんと「チケット駆動開発入門 ～基礎から応用まで～」を話してきました。
参加者は14人と少なかったですが、2人で4時間も講演できて、とても中身の濃い話ができたかなと思います。

僕としては、チケット駆動開発を実現するツールであるRedmineを用いて、どんな利用シーンに適用できるか、その時のメリットや課題は何があるか、という観点で話しました。
具体的には、BacklogsプラグインによるScrum開発、構成管理パターン、EVMや要員管理におけるプロジェクト管理技法、事務処理の申請承認フローの5つの運用パターンをまとめてみました。

つまり、運用パターンの観点としては、アジャイル開発やWF型開発への適用方法という観点と、SW開発とSW開発以外への適用方法という2つの観点です。
今までに実際に自分が考えて、現場で試してみた内容をまとめてみました。

したがって、「Redmineの運用パターン集～私に聞くな、チケットシステムに聞け」の続きの講演イメージになります。

この話がしたかった理由は、僕がSQIP2009で講演した当時に比べると、Redmineなどのチケット管理ツールを用いてチケット駆動開発を運用するのは当たり前の状況であり、今までの知見を整理してみたかったからです。

ソフトウェア開発に適用した場合のノウハウ・メリット・デメリットはかなり出尽くしていると思いますし、ソフトウェア開発以外にRedmineのようなチケット管理を適用すると、どんな利用シーンで効果が出るのか、という試行錯誤した事例も見受けられます。
僕の資料が全てのパターンを網羅しているとは思いませんが、一つの参考事例になると思います。

【2】印象に残った質疑応答

参加者に聞いた所、全員がRedmineユーザでした。
なので、Redmineは知っている、あるいは既に運用していて、色んな問題意識を持っているようでした。
講演中や講演後の質疑応答で印象に残った内容を記載しておきます。

【2-1】チケットとバージョン管理ツールの連携機能がよく分からない。

【A】Redmineの構成管理ツールの連携は、変更理由(チケット)→成果物の後方追跡性と成果物→変更理由(チケット)への前方追跡性というトレーサビリティを実現した機能です。

【2-2】現在、ソースはGit、設計書などのドキュメントはSubversionで構成管理を行なっている場合、Redmineでは、チケットと成果物の連携をどのようにすれば効果的か？

【A】ソースやドキュメントを別々のリポジトリ(Git、SVN)で管理している場合の運用はどうすべきか？という質問でした。
Redmineのマルチリポジトリ機能を使えば、1プロジェクトに複数のバージョン管理リポジトリを設定できるので、それで解決できるでしょう。

Redmine 1.4新機能紹介: 一つのプロジェクトで複数のリポジトリに対応 | Redmine.JP Blog

Redmineの複数プロジェクト機能を使って、別々に管理して運用することも可能ですが、一つのシステムや製品に関する作業情報は、一つのRedmineプロジェクトにまとめた方が後の保守でも運用しやすいからです。
Conwayの法則を連想するといいと思います。

【2-3】親チケットに書いた予定日は、子チケットを作ると消えてしまって困る。
　当初の計画情報は消えて欲しくない。

【A】Ver3.1から、Redmineの親チケットの値に子チケットをロールアップさせない設定が可能になりました。

Redmine 3.1新機能紹介: 親チケットの値(優先度・期日など)を子チケットと連動させない設定 | Redmine.JP Blog

下記の記事にも書きましたが、WF型開発を運用していて、当初のWBSの計画情報を修正したい場合、過去の計画情報が消えてしまうと困る状況があるようです。

Redmineの親チケットの値に子チケットをロールアップさせない設定方法: プログラマの思索

また、下記の記事のように、親チケットや子チケットだけを抽出するクエリも発行できるので、チケットをWBSのように管理する場合は少しは便利になってきています。

Redmine 3.1新機能紹介: 親チケットおよび子チケットによるフィルタ | Redmine.JP Blog

Redmineの親チケット検索機能とCSVインポーター機能: プログラマの思索

【2-4】チケットの粒度はどうあるべきか？
　現場でプロジェクト管理をRedmineでやっているが、Redmineのガントチャートは顧客にそのまま提出できない。
　今の運用では、現場の開発者はRedmineの運用があまり嬉しくなさそうだ。

【A】顧客や上司が見たい管理の観点と、プロジェクトリーダーや開発者が見たい管理の観点は、そもそもチケットの粒度は異なります。
以前書きましたが、親子チケットを上手く使って、顧客や上司には集計された親チケットの情報を見せて、チームでは子チケット全ての情報を見る、という使い分けが必要になると思います。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

但し、実際のチケット管理の運用はそんな理想どおりになかなか上手くいかず、結構煩雑になると思います。
@sakaba37さんの言う通り、顧客向けにはMSProjectやExcelの線表を見せて、その元ネタはチケットにある、という使い分けの方が現実的でしょう。

【2-5】WBSをチケットにすると、複数の担当者の予定が入力できない。
要件単位にチケットを作った場合、一つのチケットに複数の担当者の予定を入力できないのは困る。

【A】問題の本質は、例えば、「画面Aを実現する」という作業をチケットでどのようにマッピングすべきか、という問題に置き換えられます。
やり方は2つあります。

一つは、基本設計→詳細設計→製造→単体テストの流れを1個のチケットでまとめる。
もう一つは、親チケットに要件を書き、子チケットに基本設計～単体テストまでの作業を分割して管理する。

前者はアジャイル開発の観点と同じで、1個のチケットを複数の担当者がキャッチボールのように作業を連携するやり方。
これはチケット管理の基本で、推奨するやり方。

しかし、このやり方では、質問者の言う通り、複数の担当者を一つのチケットにアサインできないし、複数の担当者の開始予定日・終了予定日・予定工数をそれぞれ記録することができない。
WF型開発で、WBSがあらかじめ決まっていて、作業者の予定もほぼ確定している場合は、このやり方は使いにくい。

後者は、WF型開発のWBSの観点と同じで、子チケットにWBSの最下層である作業(成果物)をマッピングする。
すると、子チケットは必ず一担当者が結びつき、子チケットで担当者の作業管理ができる。
親チケットには、子チケットの情報がロールアップされるので、進捗情報をリアルタイムに見れる。

しかし、Redmineのチケットは実績管理の設計思想なので、予定日がデフォルトで保持されていないから、カスタムフィールドで別途作成する必要がある
また、1チケット＝1担当者の場合、「担当者固定」というアンチパターン(松谷さん@redmine.tokyo)が発生しやすいので注意すべき。

講演１ Redmine導入のアンチパターン

WF型開発でWBS管理したい場合は、親子チケットで運用するしかないでしょう。

【2-6】今、Redmineをソフトウェア開発者だけでなく営業担当者にも使ってもらおうと導入を計画している。
　営業担当者にRedmineを使ってもらうにはどうすればよいか？
　運用以外にRedmineの機能で注意すべき点はあるか？

【A】運用上の注意としては、説明会は必須だろう。
営業マンならば、Redmineも知らないだけでなく、Webやパソコンすら慣れていない人も多いので、運用の目的や方法、メリットも十分に説明すべき。

その場合、Wikiにマニュアルを書いておくと便利。
運用マニュアルをWikiで公開しておけば、誰でもアクセスして読める。
また、実際に運用したら、運用方法はコロコロ変わりやすいので、ExcelでまとめるよりもWikiに記載する方が素早く対応できるし、保守もしやすい。
RedmineのWikiなら履歴管理もできる。

Redmineの機能で注意すべき点は、カスタムクエリとウォッチャー機能だろう。
チケット管理を始めたものの、大量のチケットがチケット一覧で出力されるだけでは、誰も使ってくれない。
利用シーンを考慮したカスタムクエリを10個以上事前に登録しておき、運用マニュアルに、どんな運用の時にどのクエリを使ってチェックすべきか、という内容を記載するといいだろう。

例えば、担当者＝自分の未完了チケット、期日遅延の未完了チケット、報告用の全チケットなどのカスタムクエリを事前に登録するといいのでは。

また、申請したチケットを担当者以外にも共有したい時がある。
その時は、ウォッチャー機能がメールのCcに相当するので、使って下さい、と事前に説明するといいだろう。

【3】上記の質問を聞くと、@sakaba37さんの感想である[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -: ソフトウェアさかばの通り、参加者は大規模受託開発にRedmineを導入して運用しようとしており、その背景の元に色んな問題や課題を持っているように思いました。

その辺りもまとめてみたいと思います。