20110730_Redmineでのタスク管理を考える勉強会＠大阪 第１回 (2011/07/30) - RxTstudy https://sites.google.com/site/rxtstudy/home/20110730 【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索 http://forza.cocolog-nifty.com/blog/2011/07/redminefaq-rxts.html RxTstudy Redmineでのタスク管理を考える勉強会＠大阪 - Togetterまとめ http://togetter.com/li/168362

1. RedmineのFAQと
アンチパターン集
No Ticket, No Work !
2011/07/30
あきぴー＠XPJUG関西
(copyright2011 akipii@XPJUG関西)
1

2. 自己紹介
HN：@akipii
チケット駆動開発の本を出
版 (with @sakaba37)
Redmineを使って、
チケット駆動開発による
Agileな開発方法について
解説しました
現在 絶賛販売中
(copyright2011 akipii@XPJUG関西)
2

3. Agenda
Redmine運用の諸問題
チケット編
構成管理編
(1)FAQ
バージョン編
【Q】のつくタイトルです。
【 】
プロジェクト編
(2)アンチパターン
まとめ
【反例】
【反例】のつくタイトルです。
【反例】
(3)補足説明
【参考】
【参考】のつくタイトルです。
【参考】
(copyright2011 akipii@XPJUG関西)
3

4. Redmine運用の諸問題
開発業務をRedmineへマッピングできてない
プロジェクトで発生する全ての情報をチケット化できてない
チケット管理が上手く運用できてない
構成管理と連携していない
管理の為のExcelがまだ残っている
顧客観点のViewはExcelで手作り
顧客向け進捗報告、課題一覧、工数集計
ライブラリアンがリリース管理台帳で作業している
WF型開発に固執している
チケットやリリースの完了基準、リリース計画が不明確
開発のリズムが無い
(copyright2011 akipii@XPJUG関西)
4

5. チケット編
No Ticket, No Work!
(copyright2011 akipii@XPJUG関西)
5

6. 【Q】チケットは仕様書ですか？
質問
チケットは仕様書ですか？
頻出場所
チケット管理
根本原因
BTS→ITS→TiDDへ進化した歴史を理解してない
→
→
へ進化した歴史を理解してない
関連
アンチパターン
関連プラクティス
回答
タスクがチケットに書かれない
・Issue Tracking
・Ticket First
・No Ticket, No Work (@mrgoofy33)
・チケットをバグだけでなく、課題やタスクも扱う
・チケットをXPのタスクカードのように扱う
・チケットを のタスクカードのように扱う(@sakaba37)
・実績工数が発生するタスクは、チケットなしの作業不可
(copyright2011 akipii@XPJUG関西)
6

7. 【参考】チケット駆動開発とは
チケット駆動開発はTracのチケット管理から生まれた(@machu)
http://www.machu.jp/diary/20070907.html#p01
正式名称：Ticket Driven Development
(@machu, @hiroe316)
BTS/ITSを障害管理だけでなくタスク管理に使う(@machu)
チケット駆動開発の運用ルールは二つだけ
BTSチケットをXPのタスクカードのように扱う(Ticket First)(@sakaba37)
チケット無しのソースコミット不可 (No Ticket, No Commit !) (@machu)
BTSの運用対象を
の運用対象を
拡大する
(copyright2011 akipii@XPJUG関西)
7

8. 【Q】チケットの粒度
質問
類似質問
チケットの粒度はどう決める？
・MS Projectと連携しにくい
と連携しにくい
・課題一覧やガントチャートを出したい
・工数集計がやりにくい
頻出場所
チケット管理
根本原因
チケット集計機能を使いこなしていない
関連
アンチパターン
Excelのプロジェクト管理に戻る
のプロジェクト管理に戻る
関連プラクティス
・チケットで分割統治
※関連チケット、Subtasking、private ticketも使う
※関連チケット、
、
も使う
回答
・顧客とPGの観点で
・顧客と の観点でViewを分ける
の観点で
を分ける
・親チケットを集計用に使う
・ private ticketをToDoに使う
を
に使う
(copyright2011 akipii@XPJUG関西)
8

9. 【参考】チケットの属性×集計の関連表
表：Redmineの各機能で使われるチケットの属性 縦：機能×横：属性
の各機能で使われるチケットの属性 (縦：機能×横：属性
表：
の各機能で使われるチケットの属性 縦：機能×横：属性)
トラッカー ステータス
ワークフロー
◎
カテゴリ
サマリ
◯
ロードマップ
◯
◯
◯
◯
レポート
作業開始
/終了日
終了日
予定/
予定
実績工数
作業
分類
◎
△
(進捗率)
ガントチャート
バージョン
◯
◎
◯
◎
◯
◯
◎
◯
(完了のみ)
◯
バグ収束曲線
◯
(完了のみ)
◎
◯
バーンダウン
チャート
◯
かんばん
◯
◎
◎
Redmineは、チケットの属性と集計機能の関連性がよく考えられている
は、チケットの属性と集計機能の関連性がよく考えられている
(copyright2011 akipii@XPJUG関西)
9

10. 【参考】Agile開発のView
(copyright2011 akipii@XPJUG関西)
10

11. 【参考】WF型開発のView
WF型開発の
型開発のViewは
型開発の
は
意外に貧弱！
(copyright2011 akipii@XPJUG関西)
11

12. 【参考】チケットの親子関係
親チケット＝ストーリーカード、
子チケット＝タスクカード でグループ化する
子チケット＝タスクカード でグループ化する
※親チケットの情報(開始日～予定工数 は集計項目なので修正不可
※親チケットの情報 開始日～予定工数)は集計項目なので修正不可
開始日～予定工数
(copyright2011 akipii@XPJUG関西)
12

13. 【参考】プライベートチケット
プライベートチケットを使う(v1.2.0以降
以降)
プライベートチケットを使う
以降
顧客へ見せる必要がなく、自分だけのToDoタスク
(copyright2011 akipii@XPJUG関西)
13

14. 【Q】顧客の問合せ
質問
顧客の問合せが管理しにくい
頻出場所
ワークフロー管理
根本原因
・問合せをバグ修正と同じワークフローで管理している
・ワークフローの種類が少ない
関連
アンチパターン
・問合せはバグ修正なり
・足りないステータス
関連プラクティス
・ワークフロー管理
・ペア作業
回答
・トラッカーはワークフローと同一
・問合せ用のトラッカーを別に作る
(copyright2011 akipii@XPJUG関西)
14

15. 【参考】ワークフローで変更管理
(copyright2011 akipii@XPJUG関西)
15

16. 【参考】ワークフローで変更管理
ソフトウェア開発のワークフローは
BTSのワークフロー機能で
制御できる
ユーザ権限と
チケット種類の単位で
ステータスの現在・移行先を
指定する
ステータスの移行先
現
在
の
ス
テ
ー
タ
ス
(copyright2011 akipii@XPJUG関西)
15

17. 【参考】トラッカーの運用例(@akipii)
No
トラッカー 作業内容
1
バグ
テストで発覚したバグ修正と検 新規→担当→解決→検証中→検証
完了→終了
証
2
タスク
ソース修正、設計書の作成、
諸々の作業
新規→担当→解決→終了
3
リリース
定期的に実施する本番リリー
ス作業
新規→担当→解決→検証中→検証
完了→終了
4
課題
プロジェクト全体、顧客向けの
課題
新規→問合せ中→回答済→解決→
終了
5
QA
チーム内の課題、設計者への
質問
新規→問合せ中→回答済→解決→
終了
6
気づき
タスクや課題ほどではないが
忘れたくない作業
新規→担当→解決→終了
7
テーマ
集計用の親チケット。子チケッ
トにタスクを登録する。
新規→担当→解決→終了
基本のワークフロー
(copyright2011 akipii@XPJUG関西)
16

18. 【反例】放置されたチケット
名前
放置されたチケット
頻出場所
タスク管理
症状と結果
数えられないぐらいチケットが溜まっている
挿話証拠
「タスクがどんどん溜まっていくね」
根本原因
・スコープ管理ができてない
・チケットの納期が不明確
再構想解の
プラクティス
棚卸し、朝会、ふりかえり、小規模リリース、バックログ、
Velocity
再構想による解
決
・朝会、ふりかえりで定期的に棚卸し
・イテレーション単位に順次リリース
・リリース未定のチケットはバックログで一旦保留
・Velocityを超えたチケットは後回し
を超えたチケットは後回し
変種
・乱発されたチケット
・Redmineがゴミ箱
がゴミ箱
(copyright2011 akipii@XPJUG関西)
17

19. 【参考】棚卸しとVelocity
(copyright2011 akipii@XPJUG関西)
18

20. 【反例】停滞したチケット
名前
停滞したチケット
頻出場所
チケット管理
症状と結果
・進捗90%のチケットが多い
のチケットが多い
・進捗
・課題やQAがあるためにチケットを
があるためにチケットをCloseできない
・課題や があるためにチケットを
できない
挿話証拠
「いつも進捗が90%のままだね」
のままだね」
「いつも進捗が
根本原因
・作業の完了基準が不明確
・チケットの粒度が大きい
再構想解の
プラクティス
・チケットはシンプルに
・棚卸し
再構想による解決 ・ステータスと進捗率を紐づける
・残課題や別作業は、チケットを分割する
変種
・責任が重過ぎるチケット
・放置されたチケット
(copyright2011 akipii@XPJUG関西)
19

21. 構成管理編
No Ticket, No Commit !
(copyright2011 akipii@XPJUG関西)
20

22. 【Q】チケットとリビジョンの関連づけ
質問
チケットとリビジョンを関連付ける方法は？
頻出場所
SCM連携
連携
根本原因
変更管理が不十分
関連
アンチパターン
関連プラクティス
回答
SCMとチケットが連携されてない
とチケットが連携されてない
・No Ticket, No Commit! (@machu)
・トレーサビリティ
(チケットから成果物の変更を追跡できる
チケットから成果物の変更を追跡できる)
チケットから成果物の変更を追跡できる
・post-commit-hook、pre-commit-hookを使う
、
を使う
・コミットログに「refs #12」「
」「fixes #23」と書く
・コミットログに「
」「
」
(copyright2011 akipii@XPJUG関西)
21

23. 【参考】トレーサビリティ
成果物の変更をチケットで追跡する(Traceability)
チケットへ構成管理情報を付与する
チケット無しのソースコミット不可 (No Ticket, No Commit !) (@machu)
変更理由をチケット経由で要件からビルドモジュールまで追跡可能
リバースエンジニアリングや仕様変更の影響調査に適用できる
(copyright2011 akipii@XPJUG関西)
22

24. 【反例】trunk1本のソース管理
名前
trunk1本のソース管理
trunk1本のソース管理
頻出場所
構成管理
症状と結果
・Excelのリリース管理台帳が必須
のリリース管理台帳が必須
・ライブラリアンの作業負荷が大きい
挿話証拠
「リリース作業に手間がかかりすぎだね」
根本原因
・並行開発の構成管理が不十分
・CVSやVSSを未だに使っている
や
を未だに使っている
再構想解の
プラクティス
・メインラインモデル
・継続的インテグレーション
再構想による解決 ・メインラインモデルを活用する
・SVN, Git, Mercurialを使う
を使う
・常時リリース可能なビルド環境を作る
変種
・リリースブランチのないソース管理
・野放図にたくさんあるブランチ
(copyright2011 akipii@XPJUG関西)
23

25. 【参考】メインラインモデルと並行開発
トピックブランチ
(Topic branch)
(copyright2011 akipii@XPJUG関西)
ブランチの目的
を明確に分ける
構成管理手法
24

26. 【反例】trunk1本だけでソース管理
(copyright2011 akipii@XPJUG関西)
25

27. 【反例】リリースブランチが無い
マージ後、コードフリーズ
の期間が発生する
(copyright2011 akipii@XPJUG関西)
26

28. バージョン編
チケット駆動開発の肝は
イテレーションにあり
(copyright2011 akipii@XPJUG関西)
27

29. 【Q】バージョンとマイルストーンの違い
質問
バージョンとマイルストーンの違いは？
頻出場所
チケット管理
根本原因
本番リリースや進捗報告の基準があいまい
関連
アンチパターン
・空っぽのロードマップ
・工程単位のバージョン
関連プラクティス
小規模リリース
回答
・マイルストーンは進捗報告する日
・バージョンは本番リリース日
※Redmineバージョンには期限しか設定できない
バージョンには期限しか設定できない
・バージョンとマイルストーンは1対多の関係
・バージョンとマイルストーンは 対多の関係
(copyright2011 akipii@XPJUG関西)
28

30. 【Q】ロードマップ
質問
ロードマップは何ですか？
類似質問
Redmine・Trac・Mantisのロードマップ機能の違いは？
・
・
のロードマップ機能の違いは？
頻出場所
リリース計画
根本原因
リリース計画の意味を理解していない
関連
アンチパターン
・空っぽのロードマップ
・工程単位のバージョン
関連プラクティス
・小規模リリース
・イテレーションで分割統治
・バックログ
回答
・ロードマップをリリース計画として扱う
・バージョンとリリース予定バージョンを対応付ける
・リリース未定のチケットはバックログで一旦保留
(copyright2011 akipii@XPJUG関西)
29

31. 【参考】小規模リリース
バージョンを2～ 週間ごとに順
バージョンを ～4週間ごとに順
次リリースしていく
バージョンに紐づく全てのチケットが
完了になればリリース
長期計画はリリース計画、短期計画
はイテレーション計画で使い分け
リリース済みバージョンとSCMタ
リリース済みバージョンと
タ
グを同一視
バージョン→チケット→ソース修正
履歴へ追跡可能
期限のないバージョンはバックロ
グや内部課題のように扱う
Scrumのバックログは要望の貯蔵庫
リリースの優先順位によってイテレー
ション間を移動する
(copyright2011 akipii@XPJUG関西)
30

32. 【参考】TiDDとAgileの関係
ロードマップをリリース計画のように扱い、小規模リリー
スを運用する開発プロセス
Redmineによるチケット駆動開発は、XPの開発ライフサイク
ルに似たアジャイル開発！
アジャイル開発！
(copyright2011 akipii@XPJUG関西)
31

33. 【反例】空っぽのロードマップ
名前
空っぽのロードマップ
頻出場所
リリース計画
症状と結果
・バージョンやロードマップの機能を運用してない
・数えられないぐらいチケットが溜まっている
・開発のリズムが無い
挿話証拠
「残業や休日出勤が多いね」
根本原因
チケットの納期がなく、リリースが１回だけ
再構想解の
プラクティス
・小規模リリース
・バックログ
再構想による解
決
・イテレーションをリリース予定バージョンに紐づける
・リリース計画を立てて頻繁に改良する
変種
・放置されたチケット
・Closeされないバージョン
されないバージョン
(copyright2011 akipii@XPJUG関西)
32

34. 【反例】工程単位のバージョン
名前
工程単位のバージョン
頻出場所
リリース計画
症状と結果
・Redmineバージョンを工程で分けている
バージョンを工程で分けている
・障害や仕様変更のたびにバージョンがReopenされる
・障害や仕様変更のたびにバージョンが
される
挿話証拠
「いつになってもリリースできないね」
根本原因
・WF型開発にこだわりすぎ
型開発にこだわりすぎ
・リリースの終了基準が不明確
再構想解の
プラクティス
・小規模リリース
・イテレーションで分割統治
再構想による解決
・イテレーション単位に順次リリースしていく
・リリースの終了基準を明確にする
変種
・Closeされないバージョン
されないバージョン
・ゴールの見えないバージョン
(copyright2011 akipii@XPJUG関西)
33

35. プロジェクト編
アーキテクチャは組織構造に従う
(Conwayの法則)
(copyright2011 akipii@XPJUG関西)
34

36. 【Q】プロジェクトの単位
質問
Redmineのプロジェクトはどの単位で作る？
のプロジェクトはどの単位で作る？
頻出場所
プロジェクト立上げ
根本原因
Redmineの設計思想を理解してない
の設計思想を理解してない
関連
工程単位のプロジェクト
アンチパターン
関連プラクティ
ス
・プロジェクトで分割統治
・Conwayの法則
の法則
回答
プロジェクトを1リポジトリで対応づける
・Redmineは1プロジェクトを リポジトリで対応づける
は プロジェクトを
製品単位にRedmineプロジェクトを作る
・製品単位に
プロジェクトを作る
※リポジトリからビルドされるモジュール(製品 と対応する
※リポジトリからビルドされるモジュール 製品)と対応する
製品
(copyright2011 akipii@XPJUG関西)
35

37. 【参考】Conwayの法則
の法則)
「アーキテクチャは組織構造に従う」(Conwayの法則
の法則
http://patterns-wg.fuka.info.waseda.ac.jp/japanplop/Translations/GDP/pattern14.htm
ソフトウェアのどの部分であれ、それを作った組織の構造を反映する
例：コンパイラを4つのグループで作れば、4パスコンパイラになる
Redmineプロジェクトはアーキテクチャ重視で製品単位に作る方が良いと思わ
れる
Redmineプロジェクト単位のロードマップが製品単位のリリース計画になる
メンバーが複数プロジェクトに所属するマトリクス型組織になる(→自己組織化)
製品(派生元
製品 派生元)
派生元
SCMリポジトリ
リポジトリ
派生製品
リリース
ブランチ
(copyright2011 akipii@XPJUG関西)
36

38. 【Q】CCBの運用
質問
CCB(変更管理委員会 はどう運用する？
変更管理委員会)はどう運用する？
変更管理委員会
類似質問
大規模プロジェクトで、全チーム共通の課題の棚卸しはどう運
用する？
頻出場所
プロジェクト運営
根本原因
エスカレーションをRedmineにマッピングできてない
にマッピングできてない
エスカレーションを
関連
アンチパターン
工程単位のプロジェクト
関連プラクティス ・プロジェクトで分割統治
(Redmineの複数プロジェクト機能を有効に使う
の複数プロジェクト機能を有効に使う)
の複数プロジェクト機能を有効に使う
・ Scrum of Scrum
回答
・全チーム共通の課題管理と各チームのタスク管理を分けて、
プロジェクトの親子関係にする
・CCBをScrum of Scrumのように運営する
を
のように運営する
(copyright2011 akipii@XPJUG関西)
37

39. 【参考】Scrum of Scrum
週次追跡
チーム間の課題の棚卸し会議
Scrumマスター(リーダー)同士でチーム横
断の課題を調整する
Scrumマスターが集合
マスターが集合
した課題管理会議
した課題管理会議
→「課題プロジェクト」
ステアリング
コミッティー
スクラムオブスクラム
日次追跡
各チームの
「タスク管理プロ
ジェクト」
日次追跡
日次追跡
日次追跡
ScrumチームA
ScrumチームB
ScrumチームC
アジャイルコンポーネントチーム
(copyright2011 akipii@XPJUG関西)
38

40. 【反例】工程単位のプロジェクト
名前
工程単位のプロジェクト
頻出場所
プロジェクト運営
症状と結果
・Redmineプロジェクトを工程で分けている
プロジェクトを工程で分けている
・製品単位のリリース計画が分かりにくい
・成果物の変更履歴を追跡しにくい
挿話証拠
「今回対応の成果物一覧が散らばって分かりにくいね」
根本原因
WF型開発にこだわりすぎ
型開発にこだわりすぎ
再構想解の
プラクティス
・プロジェクトで分割統治
・Conwayの法則
の法則
再構想による
解決
・製品単位にプロジェクトを作る
・全チーム共通の課題管理と各チームのタスク管理を分けて
CCB(Scrum of Scrum)を運用する
を運用する
変種
アーキテクチャと対応しない複数チームのタスク管理
(copyright2011 akipii@XPJUG関西)
39

41. まとめ
Redmine導入はERP導入と同様に考えてみる
開発の全業務をRedmineへ移行できるわけではない
Redmineの特徴と現行Excelの運用を天秤に掛ける
顧客向け報告はチケット集計機能を強化してみる
顧客とチームのI/FはExcelでも構わない
顧客とチームのViewは意識的に使い分ける
WF型開発にAgileの要素も入れてみる
もっと本番リリース日を意識したプロセス
本番リリース日を意識したプロセスを作る
本番リリース日を意識したプロセス
チケット駆動開発の面白さを追求してみる
ツールによる規律と作業のAgilityの絶妙なバランス(@quicy)
ツール連携による新しい使い方の発見
(copyright2011 akipii@XPJUG関西)
40

42. Shinagawa.redmine発足！
東京でもredmineコミュニティができました
shinagawa.redmine Facebook コミュニティページ
http://www.facebook.com/groups/shinagawa.redmine/
(copyright2011 akipii@XPJUG関西)
41

43. ご清聴
ありがとう
ございました
(copyright2011 akipii@XPJUG関西)
42