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

copyright2014 akipii@XPJUG関西 1
【第7回redmine.tokyo勉強会】
RedmineのFAQと
アンチパターン集
〜WBS駆動からチケット駆動へ
2014/11/15
あきぴー@Redmine.tokyo

自己紹介
• ハンドルネーム
• あきぴー(@akipii)
• スタッフとして所属するコミュニティ
• XPJUG関⻄、SEA関⻄
• RxTStudy、redmine.tokyo
• 著書
• 「Redmineによるタスクマネジメント実践技法」 (with @sakaba37)
• 「チケット駆動開発」 (with @sakaba37)
• 「Redmine超入門」
(with redmine.tokyoスタッフ)
おかげ様でおかげ様でおかげ様でおかげ様で
第第第第7刷刷刷刷9500部部部部までまでまでまで
増刷増刷増刷増刷しました！しました！しました！しました！

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

本日のテーマ
• チケット駆動のアンチパターンを紹介
• チケット管理は、従来のPM手法と違う特徴がある
• Redmineの豊富な機能を使いこなせていない
• 下記の前提で、アンチパターンを紹介
• 前提①：自分でRedmineサーバーを⽴ち上げられる
• 前提②：チーム運営やプロジェクト運営の経験が少ない
• 前提③：前作のアンチパターン集以外の事例(2011/7)
(http://www.slideshare.net/akipii.oga/redminefaq)
• チームや案件の制約条件(Force)によって、チケット管理
を微妙に変える手法を議論したい
• 5人の小規模チーム x 20人の複数チーム
• 自社開発 x オフショア開発
• 大規模な受託開発案件 x 小規模な保守案件

Agenda
• 本日のテーマ(済)
• 【1】小規模保守案件のプロジェクト管理
• 【2】大規模受託案件のプロジェクト管理
• 【3】オフショア開発の構成管理
• まとめ
(1)FAQ
【【【【Q】】】】のつくタイトルです。
(2)アンチパターン
【【【【反例反例反例反例】】】】のつくタイトルです。
(3)再構想解のプラクティス
【【【【参考参考参考参考】】】】のつくタイトルです。

【1】小規模保守案件の
プロジェクト管理

【反例】ヤミ作業(@g_maeda)
名前名前名前名前ヤミ作業ヤミ作業ヤミ作業ヤミ作業
頻出場所頻出場所頻出場所頻出場所初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営
症状と結果症状と結果症状と結果症状と結果チケット化されない作業は、手順漏れやミスが多い。チケット化されない作業は、手順漏れやミスが多い。チケット化されない作業は、手順漏れやミスが多い。チケット化されない作業は、手順漏れやミスが多い。
挿話証拠挿話証拠挿話証拠挿話証拠「チケット化されない作業は、ポロポロ抜け漏れが多いね」「チケット化されない作業は、ポロポロ抜け漏れが多いね」「チケット化されない作業は、ポロポロ抜け漏れが多いね」「チケット化されない作業は、ポロポロ抜け漏れが多いね」
根本原因根本原因根本原因根本原因チームに必要なタスクがチケットに記載されていないチームに必要なタスクがチケットに記載されていないチームに必要なタスクがチケットに記載されていないチームに必要なタスクがチケットに記載されていない
再構想解の再構想解の再構想解の再構想解の
プラクティスプラクティスプラクティスプラクティス
・・・・Ticket First
・・・・No Ticket, No Work
・・・・No Ticket, No Commit
再構想による再構想による再構想による再構想による
解決解決解決解決
①チケットを起票してから作業を始める①チケットを起票してから作業を始める①チケットを起票してから作業を始める①チケットを起票してから作業を始める
(No Ticket, No Work)
②チケット無しで作業を完了にしない②チケット無しで作業を完了にしない②チケット無しで作業を完了にしない②チケット無しで作業を完了にしない
(No Ticket, No Commit)
変種変種変種変種一人ヤミ作業一人ヤミ作業一人ヤミ作業一人ヤミ作業

【反例】一人ヤミ作業
名前名前名前名前一人ヤミ作業一人ヤミ作業一人ヤミ作業一人ヤミ作業
頻出場所頻出場所頻出場所頻出場所初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営初心者リーダーのプロジェクト運営
症状と結果症状と結果症状と結果症状と結果チケットにない作業に従事する人がいるため、チームに一体感チケットにない作業に従事する人がいるため、チームに一体感チケットにない作業に従事する人がいるため、チームに一体感チケットにない作業に従事する人がいるため、チームに一体感
がないがないがないがない
挿話証拠挿話証拠挿話証拠挿話証拠「残業している割には、彼の成果が見えないね」「残業している割には、彼の成果が見えないね」「残業している割には、彼の成果が見えないね」「残業している割には、彼の成果が見えないね」
根本原因根本原因根本原因根本原因・案件掛け持ちの担当者の作業負荷が高い・案件掛け持ちの担当者の作業負荷が高い・案件掛け持ちの担当者の作業負荷が高い・案件掛け持ちの担当者の作業負荷が高い
・メンバー全員の作業が・メンバー全員の作業が・メンバー全員の作業が・メンバー全員の作業が見える化されて見える化されて見える化されて見える化されていないいないいないいない
・・・・Scrumチームチームチームチーム
・防火壁・防火壁・防火壁・防火壁(組織パターン組織パターン組織パターン組織パターン)
・マルチタスクを排除する・マルチタスクを排除する・マルチタスクを排除する・マルチタスクを排除する
・チームの外部にいる利害関係者からチームを守る・チームの外部にいる利害関係者からチームを守る・チームの外部にいる利害関係者からチームを守る・チームの外部にいる利害関係者からチームを守る

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

【反例】モンスターチケット
名前名前名前名前モンスターチケットモンスターチケットモンスターチケットモンスターチケット
頻出場所頻出場所頻出場所頻出場所チケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チームチケット管理に慣れていない初心者チーム
症状と結果症状と結果症状と結果症状と結果チケットが何度も差し戻しされて、チケットが何度も差し戻しされて、チケットが何度も差し戻しされて、チケットが何度も差し戻しされて、Closeされずに残るされずに残るされずに残るされずに残る
挿話証拠挿話証拠挿話証拠挿話証拠「このチケットは何度も差し戻しされてるね」「このチケットは何度も差し戻しされてるね」「このチケットは何度も差し戻しされてるね」「このチケットは何度も差し戻しされてるね」
根本原因根本原因根本原因根本原因チケットの完了基準があいまいチケットの完了基準があいまいチケットの完了基準があいまいチケットの完了基準があいまい
・・・・Doneの基準の基準の基準の基準
・チケット無しで・チケット無しで・チケット無しで・チケット無しでCloseしないしないしないしない(No Ticket, No Commit)
スプリント計画を作るたびに、スプリント計画を作るたびに、スプリント計画を作るたびに、スプリント計画を作るたびに、Doneの基準を定義し直すの基準を定義し直すの基準を定義し直すの基準を定義し直す
※※※※Doneの基準は、チームが成長するたびに変わっていくの基準は、チームが成長するたびに変わっていくの基準は、チームが成長するたびに変わっていくの基準は、チームが成長するたびに変わっていく
変種変種変種変種・放置されたチケット・放置されたチケット・放置されたチケット・放置されたチケット
・停滞したチケット・停滞したチケット・停滞したチケット・停滞したチケット

【参考】Doneの基準
• チケットの完了基準を明確にする
• 作業範囲と成果物を明確にする
タスク #12
ショッピングサイトの
カート画面を開発する
【Scrumの知恵】
Doneの範囲は、チームの成⻑によって拡大する
⇒毎回、イテレーション終了時にチームで再定義し直す
・チケットの完了基準は、
カート画面に商品を登録するだけ？
・商品の削除は必要？
・使いやすいUIにすべきか？
・大量アクセス時の性能は保証され
ているか？

【反例】サイロ型プロジェクト
名前名前名前名前サイロ型プロジェクトサイロ型プロジェクトサイロ型プロジェクトサイロ型プロジェクト
頻出場所頻出場所頻出場所頻出場所数多くのシステム保守の案件管理数多くのシステム保守の案件管理数多くのシステム保守の案件管理数多くのシステム保守の案件管理
症状と結果症状と結果症状と結果症状と結果 Redmineプロジェクトが階層化されておらず乱立している。プロジェクトが階層化されておらず乱立している。プロジェクトが階層化されておらず乱立している。プロジェクトが階層化されておらず乱立している。
チーム全体のタスクの進捗状況が見えにくい。チーム全体のタスクの進捗状況が見えにくい。チーム全体のタスクの進捗状況が見えにくい。チーム全体のタスクの進捗状況が見えにくい。
挿話証拠挿話証拠挿話証拠挿話証拠「各案件の進捗を一覧できないね」「各案件の進捗を一覧できないね」「各案件の進捗を一覧できないね」「各案件の進捗を一覧できないね」
根本原因根本原因根本原因根本原因 Redmineプロジェクトで階層化していないプロジェクトで階層化していないプロジェクトで階層化していないプロジェクトで階層化していない
Conwayの法則の法則の法則の法則(アーキテクチャは組織構造に従うアーキテクチャは組織構造に従うアーキテクチャは組織構造に従うアーキテクチャは組織構造に従う)
案件の性質ごとに、案件の性質ごとに、案件の性質ごとに、案件の性質ごとに、Redmineプロジェクトを階層化するプロジェクトを階層化するプロジェクトを階層化するプロジェクトを階層化する
①派生パターン：共通基盤①派生パターン：共通基盤①派生パターン：共通基盤①派生パターン：共通基盤PJ・製品カスタマイズ・製品カスタマイズ・製品カスタマイズ・製品カスタマイズPJ
②保守パターン：保守②保守パターン：保守②保守パターン：保守②保守パターン：保守PJ・一時的開発・一時的開発・一時的開発・一時的開発PJ
③③③③CCBパターン：課題管理会議パターン：課題管理会議パターン：課題管理会議パターン：課題管理会議PJ
変種変種変種変種工程単位のプロジェクト工程単位のプロジェクト工程単位のプロジェクト工程単位のプロジェクト
【サイロ型PJの例】

【参考】派生パターン、保守パターン(「チケット駆動開発」)
【派生パターン】
親プロジェクト：共通基盤
子プロジェクト：派生製品
派生パターン、保守パターンも、寿命の⻑いPJは親プロジェクトにする
【派生パターン】
親プロジェクト：保守
子プロジェクト：派生開発

【参考】CCBパターン(「チケット駆動開発」)
【CCBパターン】
・親プロジェクト：複数チーム
横断の課題管理
・子プロジェクト：各チームの
タスク管理
【変種】
CCB＋派生パターン
の組合せもある

【反例】乱発されたトラッカー
名前名前名前名前乱発されたトラッカー乱発されたトラッカー乱発されたトラッカー乱発されたトラッカー
症状と結果症状と結果症状と結果症状と結果似たような意味で、同じステータス遷移のトラッカーが多くて、似たような意味で、同じステータス遷移のトラッカーが多くて、似たような意味で、同じステータス遷移のトラッカーが多くて、似たような意味で、同じステータス遷移のトラッカーが多くて、
開発作業が混乱する開発作業が混乱する開発作業が混乱する開発作業が混乱する
挿話証拠挿話証拠挿話証拠挿話証拠「「開発」「管理」「タスク」はどう使い分けるの？」「「開発」「管理」「タスク」はどう使い分けるの？」「「開発」「管理」「タスク」はどう使い分けるの？」「「開発」「管理」「タスク」はどう使い分けるの？」
「課題と「課題と「課題と「課題とQAは何が違うの？」は何が違うの？」は何が違うの？」は何が違うの？」
根本原因根本原因根本原因根本原因業務フローや開発プロセスが整理されていない業務フローや開発プロセスが整理されていない業務フローや開発プロセスが整理されていない業務フローや開発プロセスが整理されていない
・チケットはワークフローに従う・チケットはワークフローに従う・チケットはワークフローに従う・チケットはワークフローに従う
・チケット集計はワークフローに従う・チケット集計はワークフローに従う・チケット集計はワークフローに従う・チケット集計はワークフローに従う
・似たようなトラッカーは、運用を統一する・似たようなトラッカーは、運用を統一する・似たようなトラッカーは、運用を統一する・似たようなトラッカーは、運用を統一する
・・・・Redmineから出力される帳票単位にトラッカーを作るから出力される帳票単位にトラッカーを作るから出力される帳票単位にトラッカーを作るから出力される帳票単位にトラッカーを作る
変種変種変種変種スタンプラリースタンプラリースタンプラリースタンプラリー

【参考1】チケットはワークフローに従う
• 同じワークフローを持つトラッカーは、抽象化して一つにま
とめる (知識操作パターンで統一) (「チケット駆動開発」)
• 「タスク」は作業のインスタンスを抽象化した概念
• トラッカーが多すぎると、メンバーが混乱する

【参考2】チケット集計はワークフローに従う
• Redmineから出⼒される帳票単位にトラッカーを作る
• ワークフローやチケットの属性をトラッカー単位に揃える
進捗一覧進捗一覧進捗一覧進捗一覧
Redmine
障害一覧障害一覧障害一覧障害一覧課題一覧課題一覧課題一覧課題一覧
タスクタスクタスクタスクバグバグバグバグ課題課題課題課題
帳票出力帳票出力帳票出力帳票出力
各種帳票各種帳票各種帳票各種帳票
トラッカートラッカートラッカートラッカー

【2】大規模受託案件の
プロジェクト管理

【Q】MSProjectからの移⾏
質問質問質問質問 MSProjectからからからからRedmineへ移行できますか？へ移行できますか？へ移行できますか？へ移行できますか？
頻出場所頻出場所頻出場所頻出場所大規模受託案件の大規模受託案件の大規模受託案件の大規模受託案件のWBS登録登録登録登録
根本原因根本原因根本原因根本原因 WF型開発や型開発や型開発や型開発やWBS駆動にこだわり過ぎている駆動にこだわり過ぎている駆動にこだわり過ぎている駆動にこだわり過ぎている
回答回答回答回答 ①小規模リリースによるチケット駆動開発に乗り換える①小規模リリースによるチケット駆動開発に乗り換える①小規模リリースによるチケット駆動開発に乗り換える①小規模リリースによるチケット駆動開発に乗り換える
②②②②WBSを親子チケット方式で階層化するを親子チケット方式で階層化するを親子チケット方式で階層化するを親子チケット方式で階層化する
③タスク管理は従来の③タスク管理は従来の③タスク管理は従来の③タスク管理は従来のMSProjectで運用し、こぼれ落ちたで運用し、こぼれ落ちたで運用し、こぼれ落ちたで運用し、こぼれ落ちた
作業は補完チケット方式でサポートする作業は補完チケット方式でサポートする作業は補完チケット方式でサポートする作業は補完チケット方式でサポートする
※※※※MSProjectととととRedmineで二重管理するで二重管理するで二重管理するで二重管理する
関連プラクティス関連プラクティス関連プラクティス関連プラクティス ①小規模リリース①小規模リリース①小規模リリース①小規模リリース
②チケットで分割統治②チケットで分割統治②チケットで分割統治②チケットで分割統治
③アダプタブル③アダプタブル③アダプタブル③アダプタブルWF (@sakaba37)
関連関連関連関連
アンチパターンアンチパターンアンチパターンアンチパターン
・担当者固定・担当者固定・担当者固定・担当者固定
・・・・Excel管理管理管理管理

【参考】アダプタブルWF(@sakaba37)
WF型開発の各⼯程で管理しづらい作業をチケット駆動開発(TiDD)で補完する
⇒PJ管理では、進捗管理から漏れるリスク管理の⽅が重要！
要件要件要件要件
定義定義定義定義
設計設計設計設計
開発開発開発開発
テストテストテストテスト
リリースリリースリリースリリース
シスシスシスシス
テムテムテムテム
テステステステス
トトトト
WF型開発型開発型開発型開発
課題・レビュー管理課題・レビュー管理課題・レビュー管理課題・レビュー管理障害管理障害管理障害管理障害管理
補完型補完型補完型補完型
TiDD
補完型補完型補完型補完型
TiDD

【反例】担当者固定(松谷)
名前名前名前名前担当者固定担当者固定担当者固定担当者固定
頻出場所頻出場所頻出場所頻出場所大規模大規模大規模大規模WF型開発の型開発の型開発の型開発のWBS管理管理管理管理
症状と結果症状と結果症状と結果症状と結果 1チケット＝チケット＝チケット＝チケット＝1担当者で運用すると、担当者で運用すると、担当者で運用すると、担当者で運用すると、90%シンドロームになりシンドロームになりシンドロームになりシンドロームになり
やすく、進捗を管理しにくいやすく、進捗を管理しにくいやすく、進捗を管理しにくいやすく、進捗を管理しにくい
挿話証拠挿話証拠挿話証拠挿話証拠「「「「WBSで管理すると、いつも進捗が遅くなるね」で管理すると、いつも進捗が遅くなるね」で管理すると、いつも進捗が遅くなるね」で管理すると、いつも進捗が遅くなるね」
根本原因根本原因根本原因根本原因・・・・1つのつのつのつの作業を設計・開発・テスト・レビューに分割しすぎ作業を設計・開発・テスト・レビューに分割しすぎ作業を設計・開発・テスト・レビューに分割しすぎ作業を設計・開発・テスト・レビューに分割しすぎ
・・・・WF型開発に固執しすぎ型開発に固執しすぎ型開発に固執しすぎ型開発に固執しすぎ
・ペア作業・ペア作業・ペア作業・ペア作業
・・・・Doneの条件の条件の条件の条件
①チケットのステータスごとに担当者を変える運用にする①チケットのステータスごとに担当者を変える運用にする①チケットのステータスごとに担当者を変える運用にする①チケットのステータスごとに担当者を変える運用にする
※※※※チケットのやり取りを「ペア作業」で行うチケットのやり取りを「ペア作業」で行うチケットのやり取りを「ペア作業」で行うチケットのやり取りを「ペア作業」で行う
②作業を親子チケットに分割し、チェックリスト化する②作業を親子チケットに分割し、チェックリスト化する②作業を親子チケットに分割し、チェックリスト化する②作業を親子チケットに分割し、チェックリスト化する
変種変種変種変種・停滞したチケット・停滞したチケット・停滞したチケット・停滞したチケット(90%シンドロームシンドロームシンドロームシンドローム)
・・・・WBS駆動駆動駆動駆動

【参考】ペア作業
• チケットは2人以上の担当者がキャッチボールして終わる
• 開発者がバグ修正後、テスターがバグ検証する
• 開発者が作業完了後、管理者が承認する
• 開発者が仕様を質問後、設計者が回答する
担当者の作業を
チケットの状態遷移図で
管理できる
「〜中」「〜完了」ステータス
は「混乱させるステータス」の
アンチパターン！

【反例】混乱させるステータス
名前名前名前名前混乱させるステータス混乱させるステータス混乱させるステータス混乱させるステータス
症状と結果症状と結果症状と結果症状と結果「～中」「～完了」ステータスにすると、担当者が不明確になり「～中」「～完了」ステータスにすると、担当者が不明確になり「～中」「～完了」ステータスにすると、担当者が不明確になり「～中」「～完了」ステータスにすると、担当者が不明確になり
やすく、作業が停滞するやすく、作業が停滞するやすく、作業が停滞するやすく、作業が停滞する
挿話証拠挿話証拠挿話証拠挿話証拠「検証中、検証完了のステータスは、誰がボールを持っている「検証中、検証完了のステータスは、誰がボールを持っている「検証中、検証完了のステータスは、誰がボールを持っている「検証中、検証完了のステータスは、誰がボールを持っている
のかね？」のかね？」のかね？」のかね？」
根本原因根本原因根本原因根本原因「～中」「～完了」というステータス名は、作業のトリガーになっ「～中」「～完了」というステータス名は、作業のトリガーになっ「～中」「～完了」というステータス名は、作業のトリガーになっ「～中」「～完了」というステータス名は、作業のトリガーになっ
ていないていないていないていない
・・・・Doneの基準の基準の基準の基準
・ペア作業・ペア作業・ペア作業・ペア作業
・ステータス名は「～待ち」「～前」に統一する・ステータス名は「～待ち」「～前」に統一する・ステータス名は「～待ち」「～前」に統一する・ステータス名は「～待ち」「～前」に統一する
・ステータスが作業のトリガーになるように運用する・ステータスが作業のトリガーになるように運用する・ステータスが作業のトリガーになるように運用する・ステータスが作業のトリガーになるように運用する
変種変種変種変種・足りないステータス・足りないステータス・足りないステータス・足りないステータス
・停滞したチケット・停滞したチケット・停滞したチケット・停滞したチケット(90%シンドロームシンドロームシンドロームシンドローム)

【反例】スタンプラリー
名前名前名前名前スタンプラリースタンプラリースタンプラリースタンプラリー
頻出場所頻出場所頻出場所頻出場所ソフトウェア開発・保守のソフトウェア開発・保守のソフトウェア開発・保守のソフトウェア開発・保守の変更管理プロセス変更管理プロセス変更管理プロセス変更管理プロセス
症状と結果症状と結果症状と結果症状と結果ワークフローが複雑すぎて、チケットが停滞しているワークフローが複雑すぎて、チケットが停滞しているワークフローが複雑すぎて、チケットが停滞しているワークフローが複雑すぎて、チケットが停滞している
例：あるトラッカーには、ステータスが例：あるトラッカーには、ステータスが例：あるトラッカーには、ステータスが例：あるトラッカーには、ステータスが10個もある個もある個もある個もある
挿話証拠挿話証拠挿話証拠挿話証拠「チケットを完了させるには、ステータスが多すぎるね」「チケットを完了させるには、ステータスが多すぎるね」「チケットを完了させるには、ステータスが多すぎるね」「チケットを完了させるには、ステータスが多すぎるね」
根本原因根本原因根本原因根本原因 1個のワークフローで複数の作業を完了させようとしている個のワークフローで複数の作業を完了させようとしている個のワークフローで複数の作業を完了させようとしている個のワークフローで複数の作業を完了させようとしている
・トラッカーライフサイクル・トラッカーライフサイクル・トラッカーライフサイクル・トラッカーライフサイクル
・サイクルタイム・サイクルタイム・サイクルタイム・サイクルタイム
・プロセスのフェーズごとに、トラッカーを使い分ける・プロセスのフェーズごとに、トラッカーを使い分ける・プロセスのフェーズごとに、トラッカーを使い分ける・プロセスのフェーズごとに、トラッカーを使い分ける
・ワークフローのリードタイム・ワークフローのリードタイム・ワークフローのリードタイム・ワークフローのリードタイム(チケット平均完了日数チケット平均完了日数チケット平均完了日数チケット平均完了日数)を短縮を短縮を短縮を短縮
化するように運用する化するように運用する化するように運用する化するように運用する
変種変種変種変種・放置されたチケット・放置されたチケット・放置されたチケット・放置されたチケット
・停滞したチケット・停滞したチケット・停滞したチケット・停滞したチケット(90%シンドロームシンドロームシンドロームシンドローム)

【参考】トラッカーのライフサイクル(「チケット駆動開発」)
Redmine
ライフサイクルに応じてライフサイクルに応じてライフサイクルに応じてライフサイクルに応じて
ワークフローは変わるワークフローは変わるワークフローは変わるワークフローは変わる
登録登録登録登録
分割分割分割分割
更新更新更新更新
Application Lifecycle
Management(ALM)のののの
概念概念概念概念に繋がるに繋がるに繋がるに繋がる

【Q】複数システムを横断する案件管理
質問質問質問質問複数システムを横断する短期案件の複数システムを横断する短期案件の複数システムを横断する短期案件の複数システムを横断する短期案件のPJ管理は、管理は、管理は、管理は、Redmineでどでどでどでど
のように管理すべきか？のように管理すべきか？のように管理すべきか？のように管理すべきか？
頻出場所頻出場所頻出場所頻出場所複数システムを横断複数システムを横断複数システムを横断複数システムを横断するが、短期の案件するが、短期の案件するが、短期の案件するが、短期の案件
例：消費税対応、例：消費税対応、例：消費税対応、例：消費税対応、WindowsOSののののVerUp対応対応対応対応
根本原因根本原因根本原因根本原因複数システムのタスク管理を複数システムのタスク管理を複数システムのタスク管理を複数システムのタスク管理をRedmineにマッピングできていないにマッピングできていないにマッピングできていないにマッピングできていない
回答回答回答回答管理対象の案件の規模によって、チケット管理を変える管理対象の案件の規模によって、チケット管理を変える管理対象の案件の規模によって、チケット管理を変える管理対象の案件の規模によって、チケット管理を変える
①小規模の場合、親子チケットで一元管理する①小規模の場合、親子チケットで一元管理する①小規模の場合、親子チケットで一元管理する①小規模の場合、親子チケットで一元管理する
②中規模の場合、②中規模の場合、②中規模の場合、②中規模の場合、Redmineバージョンで機能単位に管理するバージョンで機能単位に管理するバージョンで機能単位に管理するバージョンで機能単位に管理する
③大規模の場合、複数プロジェクト機能を使って、案件ごとに③大規模の場合、複数プロジェクト機能を使って、案件ごとに③大規模の場合、複数プロジェクト機能を使って、案件ごとに③大規模の場合、複数プロジェクト機能を使って、案件ごとに
Redmineプロジェクトで管理するプロジェクトで管理するプロジェクトで管理するプロジェクトで管理する
関連プラク関連プラク関連プラク関連プラク
ティスティスティスティス
①①①①WBS駆動駆動駆動駆動(親子チケット方式親子チケット方式親子チケット方式親子チケット方式)
②パーキングロットチャート②パーキングロットチャート②パーキングロットチャート②パーキングロットチャート
③プロジェクト分割③プロジェクト分割③プロジェクト分割③プロジェクト分割

【参考1】WBS駆動(親子チケット⽅式)
• 親チケットの下に、タスクを子チケットでぶらさげる
• 【利点】親チケットで子チケットの進捗状況を集計できる
• 【課題】タスクが増えると、階層が深くなり保守しにくくなる
親チケットの下記の項目に、子チ
ケットの値が集計される。
・開始日、終了日
・進捗率
・予定⼯数、実績⼯数

【参考2】パーキングロットチャート
• サブシステムのタスク管理をRedmineバージョンに対応付ける
• 【利点】ロードマップやパーキングロットチャート画面で、進捗管理
しやすい
• 【課題】チーム数が多くなると、Redmineプロジェクトごとにタスク
管理したくなる
パーキングロットチャートは、ロードマップの別
の表示⽅法である。
(https://github.com/daipresents/redmine_parking_
lot_chart)

【参考3】プロジェクト分割
• サブシステムのタスク管理をRedmineプロジェクトに対応づける
• 【利点】チーム単位にサブシステムを担当する時に管理しやすい
• 【課題】サブシステム単位の進捗が分かりにくい
• プロジェクト単位の進捗を表示するプラグインを使う(下記参照)
【プロジェクト単位の進捗を表示するプラグイン】
redmine-progressive-projects-list
https://github.com/stgeneral/redmine-progressive-projects-list
親プロジェクトの下にある
子プロジェクトの進捗を
集計して表示してくれる

【3】オフショア開発の
構成管理

【Q】ブランチの対応付け
質問質問質問質問ブランチはブランチはブランチはブランチはRedmineのどの機能に対応づけるべきか？のどの機能に対応づけるべきか？のどの機能に対応づけるべきか？のどの機能に対応づけるべきか？
例：例：例：例：Redmineプロジェクト、バージョン、チケットプロジェクト、バージョン、チケットプロジェクト、バージョン、チケットプロジェクト、バージョン、チケット
頻出場所頻出場所頻出場所頻出場所ブランチ管理ブランチ管理ブランチ管理ブランチ管理
根本原因根本原因根本原因根本原因ブランチの性質を理解していないブランチの性質を理解していないブランチの性質を理解していないブランチの性質を理解していない
回答回答回答回答ブランチの性質によってブランチの性質によってブランチの性質によってブランチの性質によってRedmineの以下の機能に割り当てる。の以下の機能に割り当てる。の以下の機能に割り当てる。の以下の機能に割り当てる。
①長い寿命のブランチ①長い寿命のブランチ①長い寿命のブランチ①長い寿命のブランチ(trunk)は、は、は、は、Redmineプロジェクトプロジェクトプロジェクトプロジェクト
※※※※Redmineは、プロジェクトとリポジトリを対応付ける設計思想は、プロジェクトとリポジトリを対応付ける設計思想は、プロジェクトとリポジトリを対応付ける設計思想は、プロジェクトとリポジトリを対応付ける設計思想
②リリースバージョンは、②リリースバージョンは、②リリースバージョンは、②リリースバージョンは、Redmineバージョンごとにタグ付けバージョンごとにタグ付けバージョンごとにタグ付けバージョンごとにタグ付け
※※※※保守期間中だけ存命するリリースブランチは、保守期間中だけ存命するリリースブランチは、保守期間中だけ存命するリリースブランチは、保守期間中だけ存命するリリースブランチは、Redmineの複の複の複の複
数リポジトリ管理機能で数リポジトリ管理機能で数リポジトリ管理機能で数リポジトリ管理機能で1プロジェクトにまとめるプロジェクトにまとめるプロジェクトにまとめるプロジェクトにまとめる
③短い寿命のトピックブランチは、③短い寿命のトピックブランチは、③短い寿命のトピックブランチは、③短い寿命のトピックブランチは、Redmineチケットチケットチケットチケット
※※※※Redmineチケットとブランチを対応づける思想は、チケットとブランチを対応づける思想は、チケットとブランチを対応づける思想は、チケットとブランチを対応づける思想は、Redmine
に基本的にないに基本的にないに基本的にないに基本的にない
関連プラク関連プラク関連プラク関連プラク
ティスティスティスティス
ブランチライフサイクル、製品とリポジトリの一致ブランチライフサイクル、製品とリポジトリの一致ブランチライフサイクル、製品とリポジトリの一致ブランチライフサイクル、製品とリポジトリの一致
小規模リリース、小規模リリース、小規模リリース、小規模リリース、Iteration is Version

【参考】ブランチのライフサイクル
ブランチの寿命に応じて、Redmineの機能へのマッピングを変える
リリースブランチは、リリース時に生成され、次Verリリース
時に消滅する。
→リリースバージョンはRedmineバージョンでタグ付する
【関連パターン】
・小規模リリース、Iteration is Version
メインラインは製品の生存期間中、残り続ける。
→メインラインは、Redmineプロジェクトに対応付け、
リポジトリブラウザで⾒る。
・製品とリポジトリの一致
トピックブランチは、トピック発生時に生成され、マージ
時に消滅する。
→トピックブランチは、Redmineチケット単位に作る。
トピックブランチがマージされるとRedmineチケット
はCloseされる。
・No Ticket No fork, No Ticket No Merge
Redmine
バージョンバージョンバージョンバージョン
Redmine
プロジェクトプロジェクトプロジェクトプロジェクト
Redmine
チケットチケットチケットチケット

【Q】トピックブランチの実現⽅法
質問質問質問質問トピックブランチはどのようにトピックブランチはどのようにトピックブランチはどのようにトピックブランチはどのように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

【参考】「No Ticket, No fork」「No Ticket, No Merge」
• チケットIDごとにトピックブランチをforkする(No Ticket, No fork)
• チケットをCloseするタイミングで、トピックブランチをmergeする(No
Ticket, No Merge)
• 【利点】チケットにパッチを添付して、やり取りしなくても良い(手順1→2、3→4)
メインラインメインラインメインラインメインライン
(trunk)
トピックブランチ
【【【【手順手順手順手順1】】】】
#10 機能機能機能機能追加追加追加追加
(新規新規新規新規)
【【【【手順手順手順手順3】】】】
(終了終了終了終了)
【手順2】
fork
【手順4】
merge
(作業中作業中作業中作業中)
• 【課題】GitHubのような手軽さがない
• 例：forkやmerge、pull requestの操作後に、チケット登録・Closeのフック処
理を自動で実⾏する(手順2→1、手順4→3にしたい)

まとめ

まとめ
• Redmineを利⽤して、PJ運営能⼒を⾝に付けよう
• チケット管理はプロジェクトの問題を⾒える化してくれる
• PM経験が不⾜していても、RedmineでPJ管理を実験できる
• Redmineの豊富な機能を利⽤場面に応じて使い分けよう
• チケット管理はAgile開発を参考にしよう
• 「チケットは柔軟で変化に対応しやすい」特徴を活かそう
• WBS駆動のタスク管理は変化に弱い
• リスク管理はチケットで追跡していく
• Redmineの課題の一つは「Git連携の機能強化」
• Git-flowモデル、プルリクエスト機能は不⼗分
• Git連携を機能強化して、RedmineをAgileな開発基盤にしたい
• 【試案】Redmine＋GitLabでGitHub機能を実現する(@_shimada)

ご清聴
ありがとう
ございました

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Mehr von akipii Oga

Mehr von akipii Oga (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (11)

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