チケット駆動開発によるチーム力向上の事例 #Redmine

最近、Redmineの運用事例をSlideshareでたくさん見かける。
その中でも、参考になった資料をリンクしておく。

【1】

チーム力を向上させた３つのこと from Masayuki Kometani

チーム力向上のために、取り組んだ活動は3つ。

①チーム力向上活動
②Redmineの活用
③信頼貯金の蓄積

そのうち、Redmineの活用では、次の3つを実施。

a)Wikiでノウハウ蓄積
b)チケットでコミュニケーション
c)フォーラムで見積り根拠

参考になったのは、フォーラム機能を使って、顧客とのやり取りや仕様変更のやり取りを記録するだけでなく、見積り根拠も残すようにした運用だ。
SIならば、顧客からの要望に対して、必ず見積もりし、その見積り工数と金額で同意を取ってから、作業を開始する。

しかし、顧客から、過去に同じような仕様変更を頼んだのに、なぜ今回はこんなにお金がかかるのか、とよく質問される場合が多い。
その時、過去の案件の見積もり根拠は普通は記録されていない場合が多いので、交渉に手間取りやすい。
小規模案件ほど、見積もり根拠となる資料はきちんと作成せず、口頭やメモ、他人の頭にしか残っていない。

興味深いのは、顧客とのやり取りをチケットではなくフォーラム機能を使った点だ。
顧客の要望をチケットで登録すると煩雑になると考えたのだろう。
フォーラム機能は、チャットのようにラフにやり取りを記録できる点がいい。

Redmineフォーラムからチケットを起票するプラグインもあるので、例えば、フォーラムで議論したり、やり取りしている最中に、タスクが発生したらチケットを起票する、という運用も可能だろう。

Redmineプラグインあれこれメモ: プログラマの思索

Issue from message - Plugins - Redmine

それから、信頼貯金を蓄積するという発想もすごくいい。
最近のSIでは、受注前の営業活動で、開発チームのSEが自由に問合せ対応できない運用が多くなっている。
その理由は、内部統制上セクションごとに担当を分けるべき、とか、開発SEの工数が無駄になる、とか、様々だ。
その分、顧客の満足度は落ちるし、顧客への対応も遅くなってしまう。

最近のソフトウェア開発の流れは、DevOpsや自己組織化のように、組織のセクショナリズムを廃止し、組織を横断して技術者が自由に行動できるようにする方向へ発展している。
それなのに、今の日本企業は、ビジネスプロセスを複雑化し、サイロのような組織構造にこだわり過ぎている。
日本の企業は、世界の流れから遅れている。

【2】

チケットを利用したプロダクトの健康確認 from kazuto kawahira

チケット管理について的確な表現をしている。

(引用開始)
・チケットはワークフローで制御される開発プロセス
・開発プロセスは問題を発見してくれる
・自動化や見える化の促進にITS を利用出来る
※開発プロセスやツールは問題を解決してくれない点に注意！
(引用終了)

チケット駆動開発の利点は、開発プロセスや製品の健康診断を実施してくれることだ。
例えば、チームのパフォーマンス、工数の予実管理、チーム状態の消化率や達成率や見積もりなどを表示できる。

このチームは、個人の残りチケット一覧、チームの一週間の予定工数、チームの曜日毎の終了工数合計、 バーンダウンチャート(理想値 現在値)、チケットの内訳と終了数、などをレポートで見ているようだ。
そのたびに、棚卸しして、対策を実施している。
他のチームがどんなレポートを使っているのか、を見るのはすごく参考になる。

しかし、チケット駆動開発は、問題を見える化するだけであり、問題を解決してくれるわけではない。
問題解決の方法はチームによって様々だ。

チケット管理ツールが見つけた問題を、チームがどのように解決していくべきか？
成熟したチームは、問題が発見されると同時に、どんな対策を取ればよいか、すぐに判断できて、すぐに実行できる。
未熟なチームは、経験者からコーチングを受けなければ、何が問題なのかも把握できず、どんな対策があるのか、も思いつかない。
つまり、逐一指導を受ける必要がある。

「(チケット駆動開発は)有名なプロセスの良い所が活用出来る」指摘で、デブサミ2013の私と@sakaba37さんの発表資料を紹介してくれているのは嬉しい。
少しは役に立てただろうか。

【3】

少人数チームにおけるプロジェクト管理のベストプラクティス from Cake YOSHIDA

Redmine＋Git＋GitLab＋Jenkinsを使って、障害修正や仕様変更などの小規模開発をトピックブランチで実施した運用例。
資料を見ると、Redmineはmasterのソース管理、GitLabはソース修正が完了していない状態でのマージ作業と役割を変えているようだ。
普通はRedmine＋Gitだけで運用しているだろうが、GitLabを運用フローに入れた点が興味深い。

では、RedmineだけでなくGitLabを入れている理由は何なのか？

おそらく、トピックブランチをチケット単位で作業する時、Redmineチケットには、最後の完成したパッチのみをコミットするようにしたいのだろう。
masterがパッチをPullで取り込むとき、それまでのパッチ作成の経緯は記録が不要なのだろう。
パッチ作成に至るまでの修正やフィードバックの経緯があると、チケットのに内容が煩雑になると判断したのだろう。

チケットは最終パッチの記録だけでいい、という運用は、例えば、結合テストで元請けがmasterを管理していて、下請けが障害修正している場合、元請けは最終パッチだけ受入すればよく、最終パッチの修正の経緯は不要な場合もあるだろう。
つまり、Redmineの運用で、2つの役割の違うチームがチケット管理している場合が当てはまるだろうと思う。

この辺りは、それぞれの運用プロセスに依存すると思う。

【4】

チケット利用時のルール確認 from kazuto kawahira

「放置されたチケット」「停滞したチケット」が多くなった状況をどのように解決したのか、という運用事例。
読んでみると分かるが、Redmineに問題があるのではなく、Redmineのチケットをどのように運用すれば作業がサクサク進むのか、という方向で対策を実施している。

僕は、チケット駆動開発を効果的に運用するにはアジャイル開発と組み合わせるのが良い、と思っているので、アジャイル開発のプラクティスを実践する方が良いと思っている。
WF型開発でもチケット管理できるが、チケット駆動開発の利点が十分に出ないのだ。
その理由は以前たくさん書いた。

チケット駆動開発がWF型開発と相性が悪い理由: プログラマの思索

「「チケット駆動開発とメトリクス」の感想」の感想 - Some Days You Get the Bear

他にもあれば探してみる。