チケット駆動開発はプロセス改善を含む
チケット駆動開発を運用してみて、チケット駆動開発と朝会・ふりかえりは相性がよいことに気付いた。
以下メモ書き。
【元ネタ】
朝会について - 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では、このワークフローで良かったという評価が得られた。
上記の経験は、チケット駆動開発を実践して、メンバー自らがワークフローを編み出し、プロセスを改善した事例の一つだと思う。
チケット駆動開発と朝会、ふりかえりを上手に組み合わせれば、開発プロセスの種類を増やせるし、色んな場面でワークフローを切り替える運用を開発チーム自身が学習する。
プロセス改善とは、そういうことも含むのだろうと思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
「Redmine」カテゴリの記事
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
「ソフトウェア工学」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
「TestLink」カテゴリの記事
- テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか(2020.11.02)
- TestLinkにExcelのテスト項目書をインポートする方法(2017.06.01)
- TestLink Tutorialのリンク(2016.03.12)
- TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法(2016.01.31)
- エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること(2015.03.14)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか(2021.02.15)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
コメント