【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ
•
46 likes•20,748 views
【事前公開】【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ #redmineT: プログラマの思索 http://forza.cocolog-nifty.com/blog/2014/11/7redminetokyore.html 第7回勉強会 - redmine.tokyo http://redmine.tokyo/versions/13
【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ
- 2. 自己紹介 • ハンドルネーム • あきぴー(@akipii) • スタッフとして所属するコミュニティ • XPJUG関⻄、SEA関⻄ • RxTStudy、redmine.tokyo • 著書 • 「Redmineによるタスクマネジメント実践技法」 (with @sakaba37) • 「チケット駆動開発」 (with @sakaba37) • 「Redmine超入門」 (with redmine.tokyoスタッフ) copyright2014 akipii@XPJUG関西 2 おかげ様でおかげ様でおかげ様でおかげ様で 第第第第7刷刷刷刷9500部部部部までまでまでまで 増刷増刷増刷増刷しました！しました！しました！しました！
- 4. 本日のテーマ • チケット駆動のアンチパターンを紹介 • チケット管理は、従来のPM手法と違う特徴がある • Redmineの豊富な機能を使いこなせていない • 下記の前提で、アンチパターンを紹介 • 前提①：自分でRedmineサーバーを⽴ち上げられる • 前提②：チーム運営やプロジェクト運営の経験が少ない • 前提③：前作のアンチパターン集以外の事例(2011/7) (http://www.slideshare.net/akipii.oga/redminefaq) • チームや案件の制約条件(Force)によって、チケット管理 を微妙に変える手法を議論したい • 5人の小規模チーム x 20人の複数チーム • 自社開発 x オフショア開発 • 大規模な受託開発案件 x 小規模な保守案件 copyright2014 akipii@XPJUG関西 4
- 5. Agenda • 本日のテーマ(済) • 【1】小規模保守案件のプロジェクト管理 • 【2】大規模受託案件のプロジェクト管理 • 【3】オフショア開発の構成管理 • まとめ copyright2014 akipii@XPJUG関西 5 (1)FAQ 【【【【Q】】】】のつくタイトルです。 (2)アンチパターン 【【【【反例反例反例反例】】】】のつくタイトルです。 (3)再構想解のプラクティス 【【【【参考参考参考参考】】】】のつくタイトルです。
- 7. 【反例】ヤミ作業(@g_maeda) copyright2014 akipii@XPJUG関西 7 名前名前名前名前 ヤミ作業ヤミ作業ヤミ作業ヤミ作業 頻出場所頻出場所頻出場所頻出場所 初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営 症状と結果症状と結果症状と結果症状と結果 チケット化されない作業は、手順漏れやミスが多い。チケット化されない作業は、手順漏れやミスが多い。チケット化されない作業は、手順漏れやミスが多い。チケット化されない作業は、手順漏れやミスが多い。 挿話証拠挿話証拠挿話証拠挿話証拠 「チケット化されない作業は、ポロポロ抜け漏れが多いね」「チケット化されない作業は、ポロポロ抜け漏れが多いね」「チケット化されない作業は、ポロポロ抜け漏れが多いね」「チケット化されない作業は、ポロポロ抜け漏れが多いね」 根本原因根本原因根本原因根本原因 チームに必要なタスクがチケットに記載されていないチームに必要なタスクがチケットに記載されていないチームに必要なタスクがチケットに記載されていないチームに必要なタスクがチケットに記載されていない 再構想解の再構想解の再構想解の再構想解の プラクティスプラクティスプラクティスプラクティス ・・・・Ticket First ・・・・No Ticket, No Work ・・・・No Ticket, No Commit 再構想による再構想による再構想による再構想による 解決解決解決解決 ①チケットを起票してから作業を始める①チケットを起票してから作業を始める①チケットを起票してから作業を始める①チケットを起票してから作業を始める (No Ticket, No Work) ②チケット無しで作業を完了にしない②チケット無しで作業を完了にしない②チケット無しで作業を完了にしない②チケット無しで作業を完了にしない (No Ticket, No Commit) 変種変種変種変種 一人ヤミ作業一人ヤミ作業一人ヤミ作業一人ヤミ作業
- 8. 【反例】一人ヤミ作業 copyright2014 akipii@XPJUG関西 8 名前名前名前名前 一人ヤミ作業一人ヤミ作業一人ヤミ作業一人ヤミ作業 頻出場所頻出場所頻出場所頻出場所 初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営 症状と結果症状と結果症状と結果症状と結果 チケットにない作業に従事する人がいるため、チームに一体感チケットにない作業に従事する人がいるため、チームに一体感チケットにない作業に従事する人がいるため、チームに一体感チケットにない作業に従事する人がいるため、チームに一体感 がないがないがないがない 挿話証拠挿話証拠挿話証拠挿話証拠 「残業している割には、彼の成果が見えないね」「残業している割には、彼の成果が見えないね」「残業している割には、彼の成果が見えないね」「残業している割には、彼の成果が見えないね」 根本原因根本原因根本原因根本原因 ・案件掛け持ちの担当者の作業負荷が高い・案件掛け持ちの担当者の作業負荷が高い・案件掛け持ちの担当者の作業負荷が高い・案件掛け持ちの担当者の作業負荷が高い ・メンバー全員の作業が・メンバー全員の作業が・メンバー全員の作業が・メンバー全員の作業が見える化されて見える化されて見える化されて見える化されていないいないいないいない 再構想解の再構想解の再構想解の再構想解の プラクティスプラクティスプラクティスプラクティス ・・・・Scrumチームチームチームチーム ・防火壁・防火壁・防火壁・防火壁(組織パターン組織パターン組織パターン組織パターン) 再構想による再構想による再構想による再構想による 解決解決解決解決 ・マルチタスクを排除する・マルチタスクを排除する・マルチタスクを排除する・マルチタスクを排除する ・チームの外部にいる利害関係者からチームを守る・チームの外部にいる利害関係者からチームを守る・チームの外部にいる利害関係者からチームを守る・チームの外部にいる利害関係者からチームを守る
- 10. 【反例】モンスターチケット copyright2014 akipii@XPJUG関西 10 名前名前名前名前 モンスターチケットモンスターチケットモンスターチケットモンスターチケット 頻出場所頻出場所頻出場所頻出場所 チケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チーム 症状と結果症状と結果症状と結果症状と結果 チケットが何度も差し戻しされて、チケットが何度も差し戻しされて、チケットが何度も差し戻しされて、チケットが何度も差し戻しされて、Closeされずに残るされずに残るされずに残るされずに残る 挿話証拠挿話証拠挿話証拠挿話証拠 「このチケットは何度も差し戻しされてるね」「このチケットは何度も差し戻しされてるね」「このチケットは何度も差し戻しされてるね」「このチケットは何度も差し戻しされてるね」 根本原因根本原因根本原因根本原因 チケットの完了基準があいまいチケットの完了基準があいまいチケットの完了基準があいまいチケットの完了基準があいまい 再構想解の再構想解の再構想解の再構想解の プラクティスプラクティスプラクティスプラクティス ・・・・Doneの基準の基準の基準の基準 ・チケット無しで・チケット無しで・チケット無しで・チケット無しでCloseしないしないしないしない(No Ticket, No Commit) 再構想による再構想による再構想による再構想による 解決解決解決解決 スプリント計画を作るたびに、スプリント計画を作るたびに、スプリント計画を作るたびに、スプリント計画を作るたびに、Doneの基準を定義し直すの基準を定義し直すの基準を定義し直すの基準を定義し直す ※※※※Doneの基準は、チームが成長するたびに変わっていくの基準は、チームが成長するたびに変わっていくの基準は、チームが成長するたびに変わっていくの基準は、チームが成長するたびに変わっていく 変種変種変種変種 ・放置されたチケット・放置されたチケット・放置されたチケット・放置されたチケット ・停滞したチケット・停滞したチケット・停滞したチケット・停滞したチケット
- 11. 【参考】Doneの基準 • チケットの完了基準を明確にする • 作業範囲と成果物を明確にする copyright2014 akipii@XPJUG関西 11 タスク #12 ショッピングサイトの カート画面を開発する 【Scrumの知恵】 Doneの範囲は、チームの成⻑によって拡大する ⇒毎回、イテレーション終了時にチームで再定義し直す ・チケットの完了基準は、 カート画面に商品を登録するだけ？ ・商品の削除は必要？ ・使いやすいUIにすべきか？ ・大量アクセス時の性能は保証され ているか？
- 12. 【反例】サイロ型プロジェクト copyright2014 akipii@XPJUG関西 12 名前名前名前名前 サイロ型プロジェクトサイロ型プロジェクトサイロ型プロジェクトサイロ型プロジェクト 頻出場所頻出場所頻出場所頻出場所 数多くのシステム保守の案件管理数多くのシステム保守の案件管理数多くのシステム保守の案件管理数多くのシステム保守の案件管理 症状と結果症状と結果症状と結果症状と結果 Redmineプロジェクトが階層化されておらず乱立している。プロジェクトが階層化されておらず乱立している。プロジェクトが階層化されておらず乱立している。プロジェクトが階層化されておらず乱立している。 チーム全体のタスクの進捗状況が見えにくい。チーム全体のタスクの進捗状況が見えにくい。チーム全体のタスクの進捗状況が見えにくい。チーム全体のタスクの進捗状況が見えにくい。 挿話証拠挿話証拠挿話証拠挿話証拠 「各案件の進捗を一覧できないね」「各案件の進捗を一覧できないね」「各案件の進捗を一覧できないね」「各案件の進捗を一覧できないね」 根本原因根本原因根本原因根本原因 Redmineプロジェクトで階層化していないプロジェクトで階層化していないプロジェクトで階層化していないプロジェクトで階層化していない 再構想解の再構想解の再構想解の再構想解の プラクティスプラクティスプラクティスプラクティス Conwayの法則の法則の法則の法則(アーキテクチャは組織構造に従うアーキテクチャは組織構造に従うアーキテクチャは組織構造に従うアーキテクチャは組織構造に従う) 再構想による再構想による再構想による再構想による 解決解決解決解決 案件の性質ごとに、案件の性質ごとに、案件の性質ごとに、案件の性質ごとに、Redmineプロジェクトを階層化するプロジェクトを階層化するプロジェクトを階層化するプロジェクトを階層化する ①派生パターン：共通基盤①派生パターン：共通基盤①派生パターン：共通基盤①派生パターン：共通基盤PJ・製品カスタマイズ・製品カスタマイズ・製品カスタマイズ・製品カスタマイズPJ ②保守パターン：保守②保守パターン：保守②保守パターン：保守②保守パターン：保守PJ・一時的開発・一時的開発・一時的開発・一時的開発PJ ③③③③CCBパターン：課題管理会議パターン：課題管理会議パターン：課題管理会議パターン：課題管理会議PJ 変種変種変種変種 工程単位のプロジェクト工程単位のプロジェクト工程単位のプロジェクト工程単位のプロジェクト 【サイロ型PJの例】
- 15. 【反例】乱発されたトラッカー copyright2014 akipii@XPJUG関西 15 名前名前名前名前 乱発されたトラッカー乱発されたトラッカー乱発されたトラッカー乱発されたトラッカー 頻出場所頻出場所頻出場所頻出場所 チケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チーム 症状と結果症状と結果症状と結果症状と結果 似たような意味で、同じステータス遷移のトラッカーが多くて、似たような意味で、同じステータス遷移のトラッカーが多くて、似たような意味で、同じステータス遷移のトラッカーが多くて、似たような意味で、同じステータス遷移のトラッカーが多くて、 開発作業が混乱する開発作業が混乱する開発作業が混乱する開発作業が混乱する 挿話証拠挿話証拠挿話証拠挿話証拠 「「開発」「管理」「タスク」はどう使い分けるの？」「「開発」「管理」「タスク」はどう使い分けるの？」「「開発」「管理」「タスク」はどう使い分けるの？」「「開発」「管理」「タスク」はどう使い分けるの？」 「課題と「課題と「課題と「課題とQAは何が違うの？」は何が違うの？」は何が違うの？」は何が違うの？」 根本原因根本原因根本原因根本原因 業務フローや開発プロセスが整理されていない業務フローや開発プロセスが整理されていない業務フローや開発プロセスが整理されていない業務フローや開発プロセスが整理されていない 再構想解の再構想解の再構想解の再構想解の プラクティスプラクティスプラクティスプラクティス ・チケットはワークフローに従う・チケットはワークフローに従う・チケットはワークフローに従う・チケットはワークフローに従う ・チケット集計はワークフローに従う・チケット集計はワークフローに従う・チケット集計はワークフローに従う・チケット集計はワークフローに従う 再構想による再構想による再構想による再構想による 解決解決解決解決 ・似たようなトラッカーは、運用を統一する・似たようなトラッカーは、運用を統一する・似たようなトラッカーは、運用を統一する・似たようなトラッカーは、運用を統一する ・・・・Redmineから出力される帳票単位にトラッカーを作るから出力される帳票単位にトラッカーを作るから出力される帳票単位にトラッカーを作るから出力される帳票単位にトラッカーを作る 変種変種変種変種 スタンプラリースタンプラリースタンプラリースタンプラリー
- 16. 【参考1】チケットはワークフローに従う copyright2014 akipii@XPJUG関西 16 • 同じワークフローを持つトラッカーは、抽象化して一つにま とめる (知識操作パターンで統一) (「チケット駆動開発」) • 「タスク」は作業のインスタンスを抽象化した概念 • トラッカーが多すぎると、メンバーが混乱する
- 17. 【参考2】チケット集計はワークフローに従う copyright2014 akipii@XPJUG関西 17 • Redmineから出⼒される帳票単位にトラッカーを作る • ワークフローやチケットの属性をトラッカー単位に揃える 進捗一覧進捗一覧進捗一覧進捗一覧 Redmine 障害一覧障害一覧障害一覧障害一覧 課題一覧課題一覧課題一覧課題一覧 タスクタスクタスクタスク バグバグバグバグ 課題課題課題課題 帳票出力帳票出力帳票出力帳票出力 各種帳票各種帳票各種帳票各種帳票 トラッカートラッカートラッカートラッカー
- 19. 【Q】MSProjectからの移⾏ copyright2014 akipii@XPJUG関西 19 質問質問質問質問 MSProjectからからからからRedmineへ移行できますか？へ移行できますか？へ移行できますか？へ移行できますか？ 頻出場所頻出場所頻出場所頻出場所 大規模受託案件の大規模受託案件の大規模受託案件の大規模受託案件のWBS登録登録登録登録 根本原因根本原因根本原因根本原因 WF型開発や型開発や型開発や型開発やWBS駆動にこだわり過ぎている駆動にこだわり過ぎている駆動にこだわり過ぎている駆動にこだわり過ぎている 回答回答回答回答 ①小規模リリースによるチケット駆動開発に乗り換える①小規模リリースによるチケット駆動開発に乗り換える①小規模リリースによるチケット駆動開発に乗り換える①小規模リリースによるチケット駆動開発に乗り換える ②②②②WBSを親子チケット方式で階層化するを親子チケット方式で階層化するを親子チケット方式で階層化するを親子チケット方式で階層化する ③タスク管理は従来の③タスク管理は従来の③タスク管理は従来の③タスク管理は従来のMSProjectで運用し、こぼれ落ちたで運用し、こぼれ落ちたで運用し、こぼれ落ちたで運用し、こぼれ落ちた 作業は補完チケット方式でサポートする作業は補完チケット方式でサポートする作業は補完チケット方式でサポートする作業は補完チケット方式でサポートする ※※※※MSProjectととととRedmineで二重管理するで二重管理するで二重管理するで二重管理する 関連プラクティス関連プラクティス関連プラクティス関連プラクティス ①小規模リリース①小規模リリース①小規模リリース①小規模リリース ②チケットで分割統治②チケットで分割統治②チケットで分割統治②チケットで分割統治 ③アダプタブル③アダプタブル③アダプタブル③アダプタブルWF (@sakaba37) 関連関連関連関連 アンチパターンアンチパターンアンチパターンアンチパターン ・担当者固定・担当者固定・担当者固定・担当者固定 ・・・・Excel管理管理管理管理
- 20. 【参考】アダプタブルWF(@sakaba37) WF型開発の各⼯程で管理しづらい作業をチケット駆動開発(TiDD)で補完する ⇒PJ管理では、進捗管理から漏れるリスク管理の⽅が重要！ copyright2014 akipii@XPJUG関西 20 要件要件要件要件 定義定義定義定義 設計設計設計設計 開発開発開発開発 テストテストテストテスト リリースリリースリリースリリース シスシスシスシス テムテムテムテム テステステステス トトトト WF型開発型開発型開発型開発 設計設計設計設計 開発開発開発開発 テストテストテストテスト 設計設計設計設計 開発開発開発開発 テストテストテストテスト 課題・レビュー管理課題・レビュー管理課題・レビュー管理課題・レビュー管理 障害管理障害管理障害管理障害管理 補完型補完型補完型補完型 TiDD 補完型補完型補完型補完型 TiDD
- 21. 【反例】担当者固定(松谷) copyright2014 akipii@XPJUG関西 21 名前名前名前名前 担当者固定担当者固定担当者固定担当者固定 頻出場所頻出場所頻出場所頻出場所 大規模大規模大規模大規模WF型開発の型開発の型開発の型開発のWBS管理管理管理管理 症状と結果症状と結果症状と結果症状と結果 1チケット＝チケット＝チケット＝チケット＝1担当者で運用すると、担当者で運用すると、担当者で運用すると、担当者で運用すると、90%シンドロームになりシンドロームになりシンドロームになりシンドロームになり やすく、進捗を管理しにくいやすく、進捗を管理しにくいやすく、進捗を管理しにくいやすく、進捗を管理しにくい 挿話証拠挿話証拠挿話証拠挿話証拠 「「「「WBSで管理すると、いつも進捗が遅くなるね」で管理すると、いつも進捗が遅くなるね」で管理すると、いつも進捗が遅くなるね」で管理すると、いつも進捗が遅くなるね」 根本原因根本原因根本原因根本原因 ・・・・1つのつのつのつの作業を設計・開発・テスト・レビューに分割しすぎ作業を設計・開発・テスト・レビューに分割しすぎ作業を設計・開発・テスト・レビューに分割しすぎ作業を設計・開発・テスト・レビューに分割しすぎ ・・・・WF型開発に固執しすぎ型開発に固執しすぎ型開発に固執しすぎ型開発に固執しすぎ 再構想解の再構想解の再構想解の再構想解の プラクティスプラクティスプラクティスプラクティス ・ペア作業・ペア作業・ペア作業・ペア作業 ・・・・Doneの条件の条件の条件の条件 再構想による再構想による再構想による再構想による 解決解決解決解決 ①チケットのステータスごとに担当者を変える運用にする①チケットのステータスごとに担当者を変える運用にする①チケットのステータスごとに担当者を変える運用にする①チケットのステータスごとに担当者を変える運用にする ※※※※チケットのやり取りを「ペア作業」で行うチケットのやり取りを「ペア作業」で行うチケットのやり取りを「ペア作業」で行うチケットのやり取りを「ペア作業」で行う ②作業を親子チケットに分割し、チェックリスト化する②作業を親子チケットに分割し、チェックリスト化する②作業を親子チケットに分割し、チェックリスト化する②作業を親子チケットに分割し、チェックリスト化する 変種変種変種変種 ・停滞したチケット・停滞したチケット・停滞したチケット・停滞したチケット(90%シンドロームシンドロームシンドロームシンドローム) ・・・・WBS駆動駆動駆動駆動
- 22. 【参考】ペア作業 copyright2014 akipii@XPJUG関西 22 • チケットは2人以上の担当者がキャッチボールして終わる • 開発者がバグ修正後、テスターがバグ検証する • 開発者が作業完了後、管理者が承認する • 開発者が仕様を質問後、設計者が回答する 担当者の作業を チケットの状態遷移図で 管理できる 「〜中」「〜完了」ステータス は「混乱させるステータス」の アンチパターン！
- 23. 【反例】混乱させるステータス copyright2014 akipii@XPJUG関西 23 名前名前名前名前 混乱させるステータス混乱させるステータス混乱させるステータス混乱させるステータス 頻出場所頻出場所頻出場所頻出場所 チケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チーム 症状と結果症状と結果症状と結果症状と結果 「～中」「～完了」ステータスにすると、担当者が不明確になり「～中」「～完了」ステータスにすると、担当者が不明確になり「～中」「～完了」ステータスにすると、担当者が不明確になり「～中」「～完了」ステータスにすると、担当者が不明確になり やすく、作業が停滞するやすく、作業が停滞するやすく、作業が停滞するやすく、作業が停滞する 挿話証拠挿話証拠挿話証拠挿話証拠 「検証中、検証完了のステータスは、誰がボールを持っている「検証中、検証完了のステータスは、誰がボールを持っている「検証中、検証完了のステータスは、誰がボールを持っている「検証中、検証完了のステータスは、誰がボールを持っている のかね？」のかね？」のかね？」のかね？」 根本原因根本原因根本原因根本原因 「～中」「～完了」というステータス名は、作業のトリガーになっ「～中」「～完了」というステータス名は、作業のトリガーになっ「～中」「～完了」というステータス名は、作業のトリガーになっ「～中」「～完了」というステータス名は、作業のトリガーになっ ていないていないていないていない 再構想解の再構想解の再構想解の再構想解の プラクティスプラクティスプラクティスプラクティス ・・・・Doneの基準の基準の基準の基準 ・ペア作業・ペア作業・ペア作業・ペア作業 再構想による再構想による再構想による再構想による 解決解決解決解決 ・ステータス名は「～待ち」「～前」に統一する・ステータス名は「～待ち」「～前」に統一する・ステータス名は「～待ち」「～前」に統一する・ステータス名は「～待ち」「～前」に統一する ・ステータスが作業のトリガーになるように運用する・ステータスが作業のトリガーになるように運用する・ステータスが作業のトリガーになるように運用する・ステータスが作業のトリガーになるように運用する 変種変種変種変種 ・足りないステータス・足りないステータス・足りないステータス・足りないステータス ・停滞したチケット・停滞したチケット・停滞したチケット・停滞したチケット(90%シンドロームシンドロームシンドロームシンドローム)
- 24. 【反例】スタンプラリー copyright2014 akipii@XPJUG関西 24 名前名前名前名前 スタンプラリースタンプラリースタンプラリースタンプラリー 頻出場所頻出場所頻出場所頻出場所 ソフトウェア開発・保守のソフトウェア開発・保守のソフトウェア開発・保守のソフトウェア開発・保守の変更管理プロセス変更管理プロセス変更管理プロセス変更管理プロセス 症状と結果症状と結果症状と結果症状と結果 ワークフローが複雑すぎて、チケットが停滞しているワークフローが複雑すぎて、チケットが停滞しているワークフローが複雑すぎて、チケットが停滞しているワークフローが複雑すぎて、チケットが停滞している 例：あるトラッカーには、ステータスが例：あるトラッカーには、ステータスが例：あるトラッカーには、ステータスが例：あるトラッカーには、ステータスが10個もある個もある個もある個もある 挿話証拠挿話証拠挿話証拠挿話証拠 「チケットを完了させるには、ステータスが多すぎるね」「チケットを完了させるには、ステータスが多すぎるね」「チケットを完了させるには、ステータスが多すぎるね」「チケットを完了させるには、ステータスが多すぎるね」 根本原因根本原因根本原因根本原因 1個のワークフローで複数の作業を完了させようとしている個のワークフローで複数の作業を完了させようとしている個のワークフローで複数の作業を完了させようとしている個のワークフローで複数の作業を完了させようとしている 再構想解の再構想解の再構想解の再構想解の プラクティスプラクティスプラクティスプラクティス ・トラッカーライフサイクル・トラッカーライフサイクル・トラッカーライフサイクル・トラッカーライフサイクル ・サイクルタイム・サイクルタイム・サイクルタイム・サイクルタイム 再構想による再構想による再構想による再構想による 解決解決解決解決 ・プロセスのフェーズごとに、トラッカーを使い分ける・プロセスのフェーズごとに、トラッカーを使い分ける・プロセスのフェーズごとに、トラッカーを使い分ける・プロセスのフェーズごとに、トラッカーを使い分ける ・ワークフローのリードタイム・ワークフローのリードタイム・ワークフローのリードタイム・ワークフローのリードタイム(チケット平均完了日数チケット平均完了日数チケット平均完了日数チケット平均完了日数)を短縮を短縮を短縮を短縮 化するように運用する化するように運用する化するように運用する化するように運用する 変種変種変種変種 ・放置されたチケット・放置されたチケット・放置されたチケット・放置されたチケット ・停滞したチケット・停滞したチケット・停滞したチケット・停滞したチケット(90%シンドロームシンドロームシンドロームシンドローム)
- 25. 【参考】トラッカーのライフサイクル(「チケット駆動開発」) copyright2014 akipii@XPJUG関西 25 Redmine ライフサイクルに応じてライフサイクルに応じてライフサイクルに応じてライフサイクルに応じて ワークフローは変わるワークフローは変わるワークフローは変わるワークフローは変わる 登録登録登録登録 分割分割分割分割 更新更新更新更新 Application Lifecycle Management(ALM)のののの 概念概念概念概念に繋がるに繋がるに繋がるに繋がる
- 26. 【Q】複数システムを横断する案件管理 copyright2014 akipii@XPJUG関西 26 質問質問質問質問 複数システムを横断する短期案件の複数システムを横断する短期案件の複数システムを横断する短期案件の複数システムを横断する短期案件のPJ管理は、管理は、管理は、管理は、Redmineでどでどでどでど のように管理すべきか？のように管理すべきか？のように管理すべきか？のように管理すべきか？ 頻出場所頻出場所頻出場所頻出場所 複数システムを横断複数システムを横断複数システムを横断複数システムを横断するが、短期の案件するが、短期の案件するが、短期の案件するが、短期の案件 例：消費税対応、例：消費税対応、例：消費税対応、例：消費税対応、WindowsOSののののVerUp対応対応対応対応 根本原因根本原因根本原因根本原因 複数システムのタスク管理を複数システムのタスク管理を複数システムのタスク管理を複数システムのタスク管理をRedmineにマッピングできていないにマッピングできていないにマッピングできていないにマッピングできていない 回答回答回答回答 管理対象の案件の規模によって、チケット管理を変える管理対象の案件の規模によって、チケット管理を変える管理対象の案件の規模によって、チケット管理を変える管理対象の案件の規模によって、チケット管理を変える ①小規模の場合、親子チケットで一元管理する①小規模の場合、親子チケットで一元管理する①小規模の場合、親子チケットで一元管理する①小規模の場合、親子チケットで一元管理する ②中規模の場合、②中規模の場合、②中規模の場合、②中規模の場合、Redmineバージョンで機能単位に管理するバージョンで機能単位に管理するバージョンで機能単位に管理するバージョンで機能単位に管理する ③大規模の場合、複数プロジェクト機能を使って、案件ごとに③大規模の場合、複数プロジェクト機能を使って、案件ごとに③大規模の場合、複数プロジェクト機能を使って、案件ごとに③大規模の場合、複数プロジェクト機能を使って、案件ごとに Redmineプロジェクトで管理するプロジェクトで管理するプロジェクトで管理するプロジェクトで管理する 関連プラク関連プラク関連プラク関連プラク ティスティスティスティス ①①①①WBS駆動駆動駆動駆動(親子チケット方式親子チケット方式親子チケット方式親子チケット方式) ②パーキングロットチャート②パーキングロットチャート②パーキングロットチャート②パーキングロットチャート ③プロジェクト分割③プロジェクト分割③プロジェクト分割③プロジェクト分割
- 27. 【参考1】WBS駆動(親子チケット⽅式) • 親チケットの下に、タスクを子チケットでぶらさげる • 【利点】親チケットで子チケットの進捗状況を集計できる • 【課題】タスクが増えると、階層が深くなり保守しにくくなる copyright2014 akipii@XPJUG関西 27 親チケットの下記の項目に、子チ ケットの値が集計される。 ・開始日、終了日 ・進捗率 ・予定⼯数、実績⼯数
- 28. 【参考2】パーキングロットチャート copyright2014 akipii@XPJUG関西 28 • サブシステムのタスク管理をRedmineバージョンに対応付ける • 【利点】ロードマップやパーキングロットチャート画面で、進捗管理 しやすい • 【課題】チーム数が多くなると、Redmineプロジェクトごとにタスク 管理したくなる パーキングロットチャートは、ロードマップの別 の表示⽅法である。 (https://github.com/daipresents/redmine_parking_ lot_chart)
- 29. 【参考3】プロジェクト分割 • サブシステムのタスク管理をRedmineプロジェクトに対応づける • 【利点】チーム単位にサブシステムを担当する時に管理しやすい • 【課題】サブシステム単位の進捗が分かりにくい • プロジェクト単位の進捗を表示するプラグインを使う(下記参照) copyright2014 akipii@XPJUG関西 29 【プロジェクト単位の進捗を表示するプラグイン】 redmine-progressive-projects-list https://github.com/stgeneral/redmine-progressive-projects-list 親プロジェクトの下にある 子プロジェクトの進捗を 集計して表示してくれる
- 31. 【Q】ブランチの対応付け copyright2014 akipii@XPJUG関西 31 質問質問質問質問 ブランチはブランチはブランチはブランチはRedmineのどの機能に対応づけるべきか？のどの機能に対応づけるべきか？のどの機能に対応づけるべきか？のどの機能に対応づけるべきか？ 例：例：例：例：Redmineプロジェクト、バージョン、チケットプロジェクト、バージョン、チケットプロジェクト、バージョン、チケットプロジェクト、バージョン、チケット 頻出場所頻出場所頻出場所頻出場所 ブランチ管理ブランチ管理ブランチ管理ブランチ管理 根本原因根本原因根本原因根本原因 ブランチの性質を理解していないブランチの性質を理解していないブランチの性質を理解していないブランチの性質を理解していない 回答回答回答回答 ブランチの性質によってブランチの性質によってブランチの性質によってブランチの性質によってRedmineの以下の機能に割り当てる。の以下の機能に割り当てる。の以下の機能に割り当てる。の以下の機能に割り当てる。 ①長い寿命のブランチ①長い寿命のブランチ①長い寿命のブランチ①長い寿命のブランチ(trunk)は、は、は、は、Redmineプロジェクトプロジェクトプロジェクトプロジェクト ※※※※Redmineは、プロジェクトとリポジトリを対応付ける設計思想は、プロジェクトとリポジトリを対応付ける設計思想は、プロジェクトとリポジトリを対応付ける設計思想は、プロジェクトとリポジトリを対応付ける設計思想 ②リリースバージョンは、②リリースバージョンは、②リリースバージョンは、②リリースバージョンは、Redmineバージョンごとにタグ付けバージョンごとにタグ付けバージョンごとにタグ付けバージョンごとにタグ付け ※※※※保守期間中だけ存命するリリースブランチは、保守期間中だけ存命するリリースブランチは、保守期間中だけ存命するリリースブランチは、保守期間中だけ存命するリリースブランチは、Redmineの複の複の複の複 数リポジトリ管理機能で数リポジトリ管理機能で数リポジトリ管理機能で数リポジトリ管理機能で1プロジェクトにまとめるプロジェクトにまとめるプロジェクトにまとめるプロジェクトにまとめる ③短い寿命のトピックブランチは、③短い寿命のトピックブランチは、③短い寿命のトピックブランチは、③短い寿命のトピックブランチは、Redmineチケットチケットチケットチケット ※※※※Redmineチケットとブランチを対応づける思想は、チケットとブランチを対応づける思想は、チケットとブランチを対応づける思想は、チケットとブランチを対応づける思想は、Redmine に基本的にないに基本的にないに基本的にないに基本的にない 関連プラク関連プラク関連プラク関連プラク ティスティスティスティス ブランチライフサイクル、製品とリポジトリの一致ブランチライフサイクル、製品とリポジトリの一致ブランチライフサイクル、製品とリポジトリの一致ブランチライフサイクル、製品とリポジトリの一致 小規模リリース、小規模リリース、小規模リリース、小規模リリース、Iteration is Version
- 32. 【参考】ブランチのライフサイクル ブランチの寿命に応じて、Redmineの機能へのマッピングを変える copyright2014 akipii@XPJUG関西 32 リリースブランチは、リリース時に生成され、次Verリリース 時に消滅する。 →リリースバージョンはRedmineバージョンでタグ付する 【関連パターン】 ・小規模リリース、Iteration is Version メインラインは製品の生存期間中、残り続ける。 →メインラインは、Redmineプロジェクトに対応付け、 リポジトリブラウザで⾒る。 【関連パターン】 ・製品とリポジトリの一致 トピックブランチは、トピック発生時に生成され、マージ 時に消滅する。 →トピックブランチは、Redmineチケット単位に作る。 トピックブランチがマージされるとRedmineチケット はCloseされる。 【関連パターン】 ・No Ticket No fork, No Ticket No Merge Redmine バージョンバージョンバージョンバージョン Redmine プロジェクトプロジェクトプロジェクトプロジェクト Redmine チケットチケットチケットチケット
- 33. 【Q】トピックブランチの実現⽅法 copyright2014 akipii@XPJUG関西 33 質問質問質問質問 トピックブランチはどのようにトピックブランチはどのようにトピックブランチはどのようにトピックブランチはどのようにRedmineチケットと対応づけチケットと対応づけチケットと対応づけチケットと対応づけ るべきか？るべきか？るべきか？るべきか？ 頻出場所頻出場所頻出場所頻出場所 ブランチ派生、ブランチ派生、ブランチ派生、ブランチ派生、masterへマージ、プルリクエストへマージ、プルリクエストへマージ、プルリクエストへマージ、プルリクエスト 根本原因根本原因根本原因根本原因 トピックブランチがトピックブランチがトピックブランチがトピックブランチがRedmineの機能に対応づけられてないの機能に対応づけられてないの機能に対応づけられてないの機能に対応づけられてない 回答回答回答回答 【【【【一つの解決策一つの解決策一つの解決策一つの解決策】】】】 ①トピックブランチ名はチケット①トピックブランチ名はチケット①トピックブランチ名はチケット①トピックブランチ名はチケットIDにするにするにするにする (No Ticket, No fork) ②トピックブランチが消滅する時に、チケットも②トピックブランチが消滅する時に、チケットも②トピックブランチが消滅する時に、チケットも②トピックブランチが消滅する時に、チケットもCloseするするするする (No Ticket, No Merge) 関連プラクティス関連プラクティス関連プラクティス関連プラクティス ・・・・No Ticket, No fork ・・・・No Ticket, No Merge 関連ツール関連ツール関連ツール関連ツール https://github.com/mikoto20000/redmine_git_branch_hook https://github.com/bleis-tift/Git-Hooks https://github.com/coiled-coil/git-redmine https://github.com/nvie/gitflow
- 34. 【参考】「No Ticket, No fork」「No Ticket, No Merge」 • チケットIDごとにトピックブランチをforkする(No Ticket, No fork) • チケットをCloseするタイミングで、トピックブランチをmergeする(No Ticket, No Merge) • 【利点】チケットにパッチを添付して、やり取りしなくても良い(手順1→2、3→4) copyright2014 akipii@XPJUG関西 34 メインラインメインラインメインラインメインライン (trunk) トピックブランチ 【【【【手順手順手順手順1】】】】 #10 機能機能機能機能追加追加追加追加 (新規新規新規新規) 【【【【手順手順手順手順3】】】】 #10 機能機能機能機能追加追加追加追加 (終了終了終了終了) 【手順2】 fork 【手順4】 merge #10 機能機能機能機能追加追加追加追加 (作業中作業中作業中作業中) • 【課題】GitHubのような手軽さがない • 例：forkやmerge、pull requestの操作後に、チケット登録・Closeのフック処 理を自動で実⾏する(手順2→1、手順4→3にしたい)
- 36. まとめ • Redmineを利⽤して、PJ運営能⼒を⾝に付けよう • チケット管理はプロジェクトの問題を⾒える化してくれる • PM経験が不⾜していても、RedmineでPJ管理を実験できる • Redmineの豊富な機能を利⽤場面に応じて使い分けよう • チケット管理はAgile開発を参考にしよう • 「チケットは柔軟で変化に対応しやすい」特徴を活かそう • WBS駆動のタスク管理は変化に弱い • リスク管理はチケットで追跡していく • Redmineの課題の一つは「Git連携の機能強化」 • Git-flowモデル、プルリクエスト機能は不⼗分 • Git連携を機能強化して、RedmineをAgileな開発基盤にしたい • 【試案】Redmine＋GitLabでGitHub機能を実現する(@_shimada) copyright2014 akipii@XPJUG関西 36