【第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部部部部までまでまでまで増刷増刷増刷増刷しました！しました！しました！しました！

3. Redmine.tokyoにコミュニティ名称変更日本のRedmineユーザ会としてアピールしたいから！ ※@akiko_pusuさん、ロゴ作成ありがとうございます！ copyright2014 akipii@XPJUG関西 3 【ロゴの意味】 ①『波千鳥』で「Tokyo＝日本」をイメージしたかった ※波千鳥は日本の伝統的な紋様 ②『海』で品川Redmineの面影を残したかった ※品川水族館＆海のイメージ ③RubyやRedmineの面影を残すために⾚⾊や⻘⾊を付けた

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チームチームチームチーム・防火壁・防火壁・防火壁・防火壁(組織パターン組織パターン組織パターン組織パターン) 再構想による再構想による再構想による再構想による解決解決解決解決・マルチタスクを排除する・マルチタスクを排除する・マルチタスクを排除する・マルチタスクを排除する・チームの外部にいる利害関係者からチームを守る・チームの外部にいる利害関係者からチームを守る・チームの外部にいる利害関係者からチームを守る・チームの外部にいる利害関係者からチームを守る

9. 【参考】Scrumチーム PLは、外部の利害関係者からチームを守るようにしよう copyright2014 akipii@XPJUG関西 9 プロダクトオーナープロダクトオーナープロダクトオーナープロダクトオーナー(PO) スクラムマスタースクラムマスタースクラムマスタースクラムマスター(SM)チームスクラムチームスクラムチームスクラムチームスクラムチーム顧客上司防御壁・ニワトリとブタ・ニワトリとブタ・ニワトリとブタ・ニワトリとブタ(ニワトリニワトリニワトリニワトリ=外部の人、ブタ外部の人、ブタ外部の人、ブタ外部の人、ブタ=Scrumチームチームチームチーム) ・・・・POががががMANを持つ最終決定者を持つ最終決定者を持つ最終決定者を持つ最終決定者(Money、、、、Authority、、、、Needsの略の略の略の略) ・イベントもプロセスもフレームワーク化・イベントもプロセスもフレームワーク化・イベントもプロセスもフレームワーク化・イベントもプロセスもフレームワーク化・リーダーが・リーダーが・リーダーが・リーダーが育ちやすい育ちやすい育ちやすい育ちやすい協調協調協調干渉

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から出力される帳票単位にトラッカーを作るから出力される帳票単位にトラッカーを作るから出力される帳票単位にトラッカーを作るから出力される帳票単位にトラッカーを作る変種変種変種変種スタンプラリースタンプラリースタンプラリースタンプラリー

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駆動駆動駆動駆動

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駆動駆動駆動駆動(親子チケット方式親子チケット方式親子チケット方式親子チケット方式) ②パーキングロットチャート②パーキングロットチャート②パーキングロットチャート②パーキングロットチャート ③プロジェクト分割③プロジェクト分割③プロジェクト分割③プロジェクト分割

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

【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ

【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

More from akipii Oga

More from akipii Oga(20)

Recently uploaded

Recently uploaded(9)

【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ