チケット駆動開発はプロセス改善を含む

チケット駆動開発を運用してみて、チケット駆動開発と朝会・ふりかえりは相性がよいことに気付いた。
以下メモ書き。

【元ネタ】
朝会について - sakuramateo.

朝会のパターン：立ってるだけじゃないよ

プロジェクトファシリテーション実践編：朝会ガイド

初めてのプロジェクトリーダー（6）
「ふりかえり」でプロジェクトを改善する

オブジェクト倶楽部の「プロジェクトファシリテーション 実践編 ふりかえりガイド」

【1】駄目な開発チームは、コミュニケーションが無い。

例えば、開発者はPCに座ったまま、一言も喋らずに黙々と作業するだけ。
設計から開発と単体テストまで順調であっても、結合テストで必ず火を噴く。

その時に、お互いのプログラムのインターフェイスが合っていないことが判明して、たくさんのバグが出て、そして収拾がつかなくなる。
責任のなすりあいに陥ったりする。

そういうチームは、フィードバックのプロセスが無い。
技術ノウハウや仕様のノウハウをためていくプロセス、問題を皆で解決していくプロセスが無い。

例えば、一人の開発者が問題を抱えている時、その問題を解決する作業をサポートする人がいない。
最終的には現場リーダーがサポートすべきだが、大規模プロジェクトほど数多くのメンバーを抱えて手一杯で、目が行き届かない。

フィードバックプロセスがあるチームは、コミュニケーションが活発。
一人のメンバーに問題が出ると、既に他のメンバーが解決方法を知っているならば、解決方法を共有することができる。
実装上の問題は、他のメンバーが既に解決方法を知っている場合は結構多い。

フィードバックプロセスの本質はプロセス改善。
つまり、プロセスは螺旋構造をなす。
問題解決の数をこなすほど、そのチームは成長していく。

【2】チケット駆動開発とプロジェクトファシリテーションのプラクティスである朝会・ふりかえりは相性がよいと思う。

朝会で最も大事なことは、各自が自分のタスクと役割を認識すること。
朝会が無いチームは、チームとしての一体感が無い。

ソフトウェア開発は、設計する人、プログラミングする人、テストする人、サーバーを構築する人など、色んな役割が必要。
その役割を各自が自覚して、チームとして成果物を出すことが大事。

朝会では、Redmineのロードマップ画面を見ながら、メンバー全員のタスクを確認する。
昨日の実績、今日やるべきタスクは、ロードマップやフィルタリングしたチケット一覧ですぐに分かる。
ロードマップ画面を見れば、チームの進捗が一目で分かるし、何が問題なのか、は一覧にあるチケットから分かる。
チームがイテレーションが終わる日までにタスクがどれだけ残っているか、という毎日の実績が一目で分かることは、チームがソフトウェア開発をコントロールできる自信につながる。

【3】ふりかえりで最も大事なことは、チームやメンバーが問題を解決する能力を保持し続けること。
ふりかえりが無いチームは、何度も同じようなミスを繰り返すから成長が無い。

リリース後にRedmineでサマリや工数レポート、リポジトリ統計、変更履歴などのチケット集計結果を見ながらKPTでふりかえる。

過去のイテレーションでリリースしたチケット数の差から、何故今回はこんなにチケットが多かったのか、どんな作業が多かったのか、などを自然にメンバーが考える雰囲気になる。
また、Redmineサマリ画面で、メンバーごとに起票数、担当数が変わるから、メンバーの貢献度合いも分かる。

僕がチケット駆動開発を運用してみて気付いたことは、Redmineのバージョンで区切られたイテレーションをリリースし終わった後に、自然に今回のリリース作業をふりかえる雰囲気が出てきたことだ。
どうやら、自分たちはこれだけのタスクをこなした、よく頑張ったぞ、みたいな雰囲気みたい。

チケット駆動開発では、チケットの種類に応じてステータスが異なるから、ワークフローをすごく意識する。
基本はバグ修正のフローで、開発者とテスト担当者が交互にチケットをやり取りする。
二人の目を通した成果物は少なくとも品質は確保できる。
つまり、XPのペアプロに似た作業をしているのに気付く。

すると、KPTしたら、メンバー毎のKeep・Problem・Tryの観点が大きく違ってくるのが面白い。
もし、今のワークフローではチケットをこなすのがやりにくかった、というProblemがあがったら、それについて皆で議論して、あるステータスを追加してみよう、などの解決方法に集約されて、Tryになっていく。

例えば、僕のチームでは、TestLinkによるバグ出しとバグ検証をRedmineチケットを紐付けた場合、どのように連携したらやりやすいか？というProblemがあがった。

つまり、Redmineのバグ修正のワークフローは「新規→担当→解決→終了」のため、TestLinkでバグ検証するステータスが無いから不便だ、という意見があがった。

結局、KPTを発端として議論した結果、「新規→担当→解決→検証中→検証完了→終了」のワークフローでTestLinkとRedmineをやり取りすることに落ち着いた。
そして、実際に運用した後のKPTでは、このワークフローで良かったという評価が得られた。

上記の経験は、チケット駆動開発を実践して、メンバー自らがワークフローを編み出し、プロセスを改善した事例の一つだと思う。

チケット駆動開発と朝会、ふりかえりを上手に組み合わせれば、開発プロセスの種類を増やせるし、色んな場面でワークフローを切り替える運用を開発チーム自身が学習する。
プロセス改善とは、そういうことも含むのだろうと思う。