• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
RedmineのFAQとアンチパターン集
 

RedmineのFAQとアンチパターン集

on

  • 48,996 views

20110730_Redmineでのタスク管理を考える勉強会@大阪 ...

20110730_Redmineでのタスク管理を考える勉強会@大阪
第1回 (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

Statistics

Views

Total Views
48,996
Views on SlideShare
25,227
Embed Views
23,769

Actions

Likes
60
Downloads
0
Comments
0

28 Embeds 23,769

http://forza.cocolog-nifty.com 13690
http://app.m-cocolog.jp 4915
http://tech-gym.com 3969
http://d.hatena.ne.jp 568
http://10.55.24.155 202
http://cptl.corp.yahoo.co.jp 131
http://webcache.googleusercontent.com 83
http://s.deeeki.com 57
http://49.212.185.170 54
http://ikedori.gungle.tk 37
http://vm-ci 18
http://nanami73test.mydns.jp 11
https://twitter.com 11
http://news.google.com 5
http://localhost 4
http://www.google.co.jp 2
http://app.cocolog-nifty.com 1
https://www.google.co.jp 1
http://forza.cocolog-nifty.com&_=1398818134494 HTTP 1
http://forza.cocolog-nifty.com&_=1398785064835 HTTP 1
http://127.0.0.1 1
http://hydrogen.digion.com 1
http://twitter.com 1
https://si0.twimg.com 1
http://paper.li 1
http://feeds.feedburner.com 1
http://www.slideshare.net 1
http://202.210.131.235 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    RedmineのFAQとアンチパターン集 RedmineのFAQとアンチパターン集 Presentation Transcript

    • RedmineのFAQと アンチパターン集 No Ticket, No Work ! 2011/07/30 あきぴー@XPJUG関西 (copyright2011 akipii@XPJUG関西) 1
    • 自己紹介 HN:@akipii チケット駆動開発の本を出 版 (with @sakaba37) Redmineを使って、  チケット駆動開発による  Agileな開発方法について  解説しました 現在 絶賛販売中 (copyright2011 akipii@XPJUG関西) 2
    • Agenda Redmine運用の諸問題 チケット編 構成管理編 (1)FAQ バージョン編  【Q】のつくタイトルです。 【 】 プロジェクト編 (2)アンチパターン まとめ  【反例】 【反例】のつくタイトルです。 【反例】 (3)補足説明  【参考】 【参考】のつくタイトルです。 【参考】 (copyright2011 akipii@XPJUG関西) 3
    • Redmine運用の諸問題 開発業務をRedmineへマッピングできてない プロジェクトで発生する全ての情報をチケット化できてない チケット管理が上手く運用できてない 構成管理と連携していない 管理の為のExcelがまだ残っている 顧客観点のViewはExcelで手作り 顧客向け進捗報告、課題一覧、工数集計 ライブラリアンがリリース管理台帳で作業している WF型開発に固執している チケットやリリースの完了基準、リリース計画が不明確 開発のリズムが無い (copyright2011 akipii@XPJUG関西) 4
    • チケット編 No Ticket, No Work! (copyright2011 akipii@XPJUG関西) 5
    • 【Q】チケットは仕様書ですか? 質問 チケットは仕様書ですか? 頻出場所 チケット管理 根本原因 BTS→ITS→TiDDへ進化した歴史を理解してない → → へ進化した歴史を理解してない 関連 アンチパターン 関連プラクティス 回答 タスクがチケットに書かれない ・Issue Tracking ・Ticket First ・No Ticket, No Work (@mrgoofy33) ・チケットをバグだけでなく、課題やタスクも扱う ・チケットをXPのタスクカードのように扱う ・チケットを のタスクカードのように扱う(@sakaba37) ・実績工数が発生するタスクは、チケットなしの作業不可 (copyright2011 akipii@XPJUG関西) 6
    • 【参考】チケット駆動開発とは チケット駆動開発は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
    • 【Q】チケットの粒度 質問 類似質問 チケットの粒度はどう決める? ・MS Projectと連携しにくい と連携しにくい ・課題一覧やガントチャートを出したい ・工数集計がやりにくい 頻出場所 チケット管理 根本原因 チケット集計機能を使いこなしていない 関連 アンチパターン Excelのプロジェクト管理に戻る のプロジェクト管理に戻る 関連プラクティス ・チケットで分割統治 ※関連チケット、Subtasking、private ticketも使う ※関連チケット、 、 も使う 回答 ・顧客とPGの観点で ・顧客と の観点でViewを分ける の観点で を分ける ・親チケットを集計用に使う ・ private ticketをToDoに使う を に使う (copyright2011 akipii@XPJUG関西) 8
    • 【参考】チケットの属性×集計の関連表 表:Redmineの各機能で使われるチケットの属性  縦:機能×横:属性 の各機能で使われるチケットの属性 (縦:機能×横:属性 表: の各機能で使われるチケットの属性  縦:機能×横:属性) トラッカー ステータス ワークフロー ◎ カテゴリ サマリ ◯ ロードマップ ◯ ◯ ◯ ◯ レポート 作業開始 /終了日 終了日 予定/ 予定 実績工数 作業 分類 ◎ △ (進捗率) ガントチャート バージョン ◯ ◎ ◯ ◎ ◯ ◯ ◎ ◯ (完了のみ) ◯ バグ収束曲線 ◯ (完了のみ) ◎ ◯ バーンダウン チャート ◯ かんばん ◯ ◎ ◎ Redmineは、チケットの属性と集計機能の関連性がよく考えられている は、チケットの属性と集計機能の関連性がよく考えられている (copyright2011 akipii@XPJUG関西) 9
    • 【参考】Agile開発のView (copyright2011 akipii@XPJUG関西) 10
    • 【参考】WF型開発のView WF型開発の 型開発のViewは 型開発の は 意外に貧弱! (copyright2011 akipii@XPJUG関西) 11
    • 【参考】チケットの親子関係 親チケット=ストーリーカード、 子チケット=タスクカード   でグループ化する 子チケット=タスクカード   でグループ化する ※親チケットの情報(開始日~予定工数 は集計項目なので修正不可 ※親チケットの情報 開始日~予定工数)は集計項目なので修正不可 開始日~予定工数 (copyright2011 akipii@XPJUG関西) 12
    • 【参考】プライベートチケット プライベートチケットを使う(v1.2.0以降 以降) プライベートチケットを使う 以降 顧客へ見せる必要がなく、自分だけのToDoタスク (copyright2011 akipii@XPJUG関西) 13
    • 【Q】顧客の問合せ 質問 顧客の問合せが管理しにくい 頻出場所 ワークフロー管理 根本原因 ・問合せをバグ修正と同じワークフローで管理している ・ワークフローの種類が少ない 関連 アンチパターン ・問合せはバグ修正なり ・足りないステータス 関連プラクティス ・ワークフロー管理 ・ペア作業 回答 ・トラッカーはワークフローと同一 ・問合せ用のトラッカーを別に作る (copyright2011 akipii@XPJUG関西) 14
    • 【参考】ワークフローで変更管理 (copyright2011 akipii@XPJUG関西) 15
    • 【参考】ワークフローで変更管理 ソフトウェア開発のワークフローは BTSのワークフロー機能で 制御できる ユーザ権限と チケット種類の単位で ステータスの現在・移行先を 指定する ステータスの移行先 現 在 の ス テ ー タ ス (copyright2011 akipii@XPJUG関西) 15
    • 【参考】トラッカーの運用例(@akipii) No トラッカー 作業内容 1 バグ テストで発覚したバグ修正と検 新規→担当→解決→検証中→検証 完了→終了 証 2 タスク ソース修正、設計書の作成、 諸々の作業 新規→担当→解決→終了 3 リリース 定期的に実施する本番リリー ス作業 新規→担当→解決→検証中→検証 完了→終了 4 課題 プロジェクト全体、顧客向けの 課題 新規→問合せ中→回答済→解決→ 終了 5 QA チーム内の課題、設計者への 質問 新規→問合せ中→回答済→解決→ 終了 6 気づき タスクや課題ほどではないが 忘れたくない作業 新規→担当→解決→終了 7 テーマ 集計用の親チケット。子チケッ トにタスクを登録する。 新規→担当→解決→終了 基本のワークフロー (copyright2011 akipii@XPJUG関西) 16
    • 【反例】放置されたチケット 名前 放置されたチケット 頻出場所 タスク管理 症状と結果 数えられないぐらいチケットが溜まっている 挿話証拠 「タスクがどんどん溜まっていくね」 根本原因 ・スコープ管理ができてない ・チケットの納期が不明確 再構想解の プラクティス 棚卸し、朝会、ふりかえり、小規模リリース、バックログ、 Velocity 再構想による解 決 ・朝会、ふりかえりで定期的に棚卸し ・イテレーション単位に順次リリース ・リリース未定のチケットはバックログで一旦保留 ・Velocityを超えたチケットは後回し を超えたチケットは後回し 変種 ・乱発されたチケット ・Redmineがゴミ箱 がゴミ箱 (copyright2011 akipii@XPJUG関西) 17
    • 【参考】棚卸しとVelocity (copyright2011 akipii@XPJUG関西) 18
    • 【反例】停滞したチケット 名前 停滞したチケット 頻出場所 チケット管理 症状と結果 ・進捗90%のチケットが多い のチケットが多い ・進捗 ・課題やQAがあるためにチケットを があるためにチケットをCloseできない ・課題や があるためにチケットを できない 挿話証拠 「いつも進捗が90%のままだね」 のままだね」 「いつも進捗が 根本原因 ・作業の完了基準が不明確 ・チケットの粒度が大きい 再構想解の プラクティス ・チケットはシンプルに ・棚卸し 再構想による解決 ・ステータスと進捗率を紐づける ・残課題や別作業は、チケットを分割する 変種 ・責任が重過ぎるチケット ・放置されたチケット (copyright2011 akipii@XPJUG関西) 19
    • 構成管理編 No Ticket, No Commit ! (copyright2011 akipii@XPJUG関西) 20
    • 【Q】チケットとリビジョンの関連づけ 質問 チケットとリビジョンを関連付ける方法は? 頻出場所 SCM連携 連携 根本原因 変更管理が不十分 関連 アンチパターン 関連プラクティス 回答 SCMとチケットが連携されてない とチケットが連携されてない ・No Ticket, No Commit! (@machu)   ・トレーサビリティ (チケットから成果物の変更を追跡できる チケットから成果物の変更を追跡できる) チケットから成果物の変更を追跡できる ・post-commit-hook、pre-commit-hookを使う 、 を使う ・コミットログに「refs #12」「 」「fixes #23」と書く ・コミットログに「 」「 」 (copyright2011 akipii@XPJUG関西) 21
    • 【参考】トレーサビリティ 成果物の変更をチケットで追跡する(Traceability) チケットへ構成管理情報を付与する チケット無しのソースコミット不可 (No Ticket, No Commit !) (@machu) 変更理由をチケット経由で要件からビルドモジュールまで追跡可能 リバースエンジニアリングや仕様変更の影響調査に適用できる (copyright2011 akipii@XPJUG関西) 22
    • 【反例】trunk1本のソース管理 名前 trunk1本のソース管理 trunk1本のソース管理 頻出場所 構成管理 症状と結果 ・Excelのリリース管理台帳が必須 のリリース管理台帳が必須 ・ライブラリアンの作業負荷が大きい 挿話証拠 「リリース作業に手間がかかりすぎだね」 根本原因 ・並行開発の構成管理が不十分 ・CVSやVSSを未だに使っている や を未だに使っている 再構想解の プラクティス ・メインラインモデル ・継続的インテグレーション 再構想による解決 ・メインラインモデルを活用する ・SVN, Git, Mercurialを使う を使う ・常時リリース可能なビルド環境を作る 変種 ・リリースブランチのないソース管理 ・野放図にたくさんあるブランチ (copyright2011 akipii@XPJUG関西) 23
    • 【参考】メインラインモデルと並行開発 トピックブランチ (Topic branch) (copyright2011 akipii@XPJUG関西) ブランチの目的 を明確に分ける 構成管理手法 24
    • 【反例】trunk1本だけでソース管理 (copyright2011 akipii@XPJUG関西) 25
    • 【反例】リリースブランチが無い マージ後、コードフリーズ の期間が発生する (copyright2011 akipii@XPJUG関西) 26
    • バージョン編 チケット駆動開発の肝は イテレーションにあり (copyright2011 akipii@XPJUG関西) 27
    • 【Q】バージョンとマイルストーンの違い 質問 バージョンとマイルストーンの違いは? 頻出場所 チケット管理 根本原因 本番リリースや進捗報告の基準があいまい 関連 アンチパターン ・空っぽのロードマップ ・工程単位のバージョン 関連プラクティス 小規模リリース 回答 ・マイルストーンは進捗報告する日 ・バージョンは本番リリース日 ※Redmineバージョンには期限しか設定できない バージョンには期限しか設定できない ・バージョンとマイルストーンは1対多の関係 ・バージョンとマイルストーンは 対多の関係 (copyright2011 akipii@XPJUG関西) 28
    • 【Q】ロードマップ 質問 ロードマップは何ですか? 類似質問 Redmine・Trac・Mantisのロードマップ機能の違いは? ・ ・ のロードマップ機能の違いは? 頻出場所 リリース計画 根本原因 リリース計画の意味を理解していない 関連 アンチパターン ・空っぽのロードマップ ・工程単位のバージョン 関連プラクティス ・小規模リリース ・イテレーションで分割統治 ・バックログ 回答 ・ロードマップをリリース計画として扱う ・バージョンとリリース予定バージョンを対応付ける ・リリース未定のチケットはバックログで一旦保留 (copyright2011 akipii@XPJUG関西) 29
    • 【参考】小規模リリース バージョンを2~ 週間ごとに順 バージョンを ~4週間ごとに順 次リリースしていく バージョンに紐づく全てのチケットが 完了になればリリース 長期計画はリリース計画、短期計画 はイテレーション計画で使い分け リリース済みバージョンとSCMタ リリース済みバージョンと タ グを同一視 バージョン→チケット→ソース修正 履歴へ追跡可能 期限のないバージョンはバックロ グや内部課題のように扱う Scrumのバックログは要望の貯蔵庫 リリースの優先順位によってイテレー ション間を移動する (copyright2011 akipii@XPJUG関西) 30
    • 【参考】TiDDとAgileの関係 ロードマップをリリース計画のように扱い、小規模リリー スを運用する開発プロセス Redmineによるチケット駆動開発は、XPの開発ライフサイク ルに似たアジャイル開発! アジャイル開発! (copyright2011 akipii@XPJUG関西) 31
    • 【反例】空っぽのロードマップ 名前 空っぽのロードマップ 頻出場所 リリース計画 症状と結果 ・バージョンやロードマップの機能を運用してない ・数えられないぐらいチケットが溜まっている ・開発のリズムが無い 挿話証拠 「残業や休日出勤が多いね」 根本原因 チケットの納期がなく、リリースが1回だけ 再構想解の プラクティス ・小規模リリース ・バックログ 再構想による解 決 ・イテレーションをリリース予定バージョンに紐づける ・リリース計画を立てて頻繁に改良する 変種 ・放置されたチケット ・Closeされないバージョン されないバージョン (copyright2011 akipii@XPJUG関西) 32
    • 【反例】工程単位のバージョン 名前 工程単位のバージョン 頻出場所 リリース計画 症状と結果 ・Redmineバージョンを工程で分けている バージョンを工程で分けている ・障害や仕様変更のたびにバージョンがReopenされる ・障害や仕様変更のたびにバージョンが される 挿話証拠 「いつになってもリリースできないね」 根本原因 ・WF型開発にこだわりすぎ 型開発にこだわりすぎ ・リリースの終了基準が不明確 再構想解の プラクティス ・小規模リリース ・イテレーションで分割統治 再構想による解決 ・イテレーション単位に順次リリースしていく ・リリースの終了基準を明確にする 変種 ・Closeされないバージョン されないバージョン ・ゴールの見えないバージョン (copyright2011 akipii@XPJUG関西) 33
    • プロジェクト編 アーキテクチャは組織構造に従う (Conwayの法則) (copyright2011 akipii@XPJUG関西) 34
    • 【Q】プロジェクトの単位 質問 Redmineのプロジェクトはどの単位で作る? のプロジェクトはどの単位で作る? 頻出場所 プロジェクト立上げ 根本原因 Redmineの設計思想を理解してない の設計思想を理解してない 関連 工程単位のプロジェクト アンチパターン 関連プラクティ ス ・プロジェクトで分割統治 ・Conwayの法則 の法則 回答 プロジェクトを1リポジトリで対応づける ・Redmineは1プロジェクトを リポジトリで対応づける は プロジェクトを 製品単位にRedmineプロジェクトを作る ・製品単位に プロジェクトを作る ※リポジトリからビルドされるモジュール(製品 と対応する ※リポジトリからビルドされるモジュール 製品)と対応する 製品 (copyright2011 akipii@XPJUG関西) 35
    • 【参考】Conwayの法則 の法則) 「アーキテクチャは組織構造に従う」(Conwayの法則 の法則 http://patterns-wg.fuka.info.waseda.ac.jp/japanplop/Translations/GDP/pattern14.htm ソフトウェアのどの部分であれ、それを作った組織の構造を反映する 例:コンパイラを4つのグループで作れば、4パスコンパイラになる Redmineプロジェクトはアーキテクチャ重視で製品単位に作る方が良いと思わ れる Redmineプロジェクト単位のロードマップが製品単位のリリース計画になる メンバーが複数プロジェクトに所属するマトリクス型組織になる(→自己組織化) 製品(派生元 製品 派生元) 派生元 SCMリポジトリ リポジトリ 派生製品 リリース ブランチ (copyright2011 akipii@XPJUG関西) 36
    • 【Q】CCBの運用 質問 CCB(変更管理委員会 はどう運用する? 変更管理委員会)はどう運用する? 変更管理委員会 類似質問 大規模プロジェクトで、全チーム共通の課題の棚卸しはどう運 用する? 頻出場所 プロジェクト運営 根本原因 エスカレーションをRedmineにマッピングできてない にマッピングできてない エスカレーションを 関連 アンチパターン 工程単位のプロジェクト 関連プラクティス ・プロジェクトで分割統治 (Redmineの複数プロジェクト機能を有効に使う の複数プロジェクト機能を有効に使う) の複数プロジェクト機能を有効に使う ・ Scrum of Scrum 回答 ・全チーム共通の課題管理と各チームのタスク管理を分けて、 プロジェクトの親子関係にする ・CCBをScrum of Scrumのように運営する を のように運営する (copyright2011 akipii@XPJUG関西) 37
    • 【参考】Scrum of Scrum 週次追跡 チーム間の課題の棚卸し会議 Scrumマスター(リーダー)同士でチーム横 断の課題を調整する Scrumマスターが集合 マスターが集合 した課題管理会議 した課題管理会議 →「課題プロジェクト」 ステアリング コミッティー スクラムオブスクラム 日次追跡 各チームの 「タスク管理プロ ジェクト」 日次追跡 日次追跡 日次追跡 ScrumチームA ScrumチームB ScrumチームC アジャイルコンポーネントチーム (copyright2011 akipii@XPJUG関西) 38
    • 【反例】工程単位のプロジェクト 名前 工程単位のプロジェクト 頻出場所 プロジェクト運営 症状と結果 ・Redmineプロジェクトを工程で分けている プロジェクトを工程で分けている ・製品単位のリリース計画が分かりにくい ・成果物の変更履歴を追跡しにくい 挿話証拠 「今回対応の成果物一覧が散らばって分かりにくいね」 根本原因 WF型開発にこだわりすぎ 型開発にこだわりすぎ 再構想解の プラクティス ・プロジェクトで分割統治 ・Conwayの法則 の法則 再構想による 解決 ・製品単位にプロジェクトを作る ・全チーム共通の課題管理と各チームのタスク管理を分けて CCB(Scrum of Scrum)を運用する を運用する 変種 アーキテクチャと対応しない複数チームのタスク管理 (copyright2011 akipii@XPJUG関西) 39
    • まとめ Redmine導入はERP導入と同様に考えてみる 開発の全業務をRedmineへ移行できるわけではない Redmineの特徴と現行Excelの運用を天秤に掛ける 顧客向け報告はチケット集計機能を強化してみる 顧客とチームのI/FはExcelでも構わない 顧客とチームのViewは意識的に使い分ける WF型開発にAgileの要素も入れてみる もっと本番リリース日を意識したプロセス 本番リリース日を意識したプロセスを作る 本番リリース日を意識したプロセス チケット駆動開発の面白さを追求してみる ツールによる規律と作業のAgilityの絶妙なバランス(@quicy) ツール連携による新しい使い方の発見 (copyright2011 akipii@XPJUG関西) 40
    • Shinagawa.redmine発足! 東京でもredmineコミュニティができました shinagawa.redmine Facebook コミュニティページ http://www.facebook.com/groups/shinagawa.redmine/ (copyright2011 akipii@XPJUG関西) 41
    • ご清聴 ありがとう ございました (copyright2011 akipii@XPJUG関西) 42