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

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

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

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

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

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

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

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

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

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

20. 【反例】混乱させるステータス名前混乱させるステータス頻出場所チケット管理に慣れていない初心者チーム症状と結果「～～～～中」「～～～～完了」ステータスにすると、担当者が不明確になりやすく、作業が停滞する挿話証拠「検証中、リリース完了のステータスは、誰がボールを持って copyright2014 akipii@XPJUG関西20 いるのかね？？？？」根本原因「～～～～中」「～～～～完了」というステータス名は、作業のトリガーになっていない再構想解のプラクティス・Doneの基準・ペア作業再構想による解決・ステータス名は「～～～～待ち」「～～～～前」に統一する・ステータスが作業のトリガーになるように運用する変種・足りないステータス・停滞したチケット(90%シンドローム)

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

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

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

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

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

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

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

33. 【Q】トピックブランチの実現⽅法質問トピックブランチはどのようにRedmineチケットと対応づけ copyright2014 akipii@XPJUG関西33 るべきか？？？？頻出場所ブランチ派生、masterへマージ、プルリクエスト根本原因トピックブランチがRedmineの機能に対応づけられてない回答【一つの解決策】 ①トピックブランチ名はチケットIDにする (No Ticket, No Folk) ②トピックブランチが消滅する時に、チケットもCloseする (No Ticket, No Merge) 関連プラクティス・No Ticket, No Folk ・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 Folk」「No Ticket, No Merge」 • チケットIDごとにトピックブランチをFolkする(No Ticket, No Folk) • チケットをCloseするタイミングで、トピックブランチをmergeする(No Ticket, No Merge) • 【利点】チケットにパッチを添付して、やり取りしなくても良い(手順1→2、3→4) copyright2014 akipii@XPJUG関西34 メインライン (trunk) トピックブランチ【手順1】 #10 機能追加 (新規) 【手順3】 #10 機能追加 (終了) 【手順2】 folk 【手順4】 merge #10 機能追加 (作業中) • 【課題】GitHubのような手軽さがない • 例：folkや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

http://forza.cocolog-nifty.com	1,007
http://app.m-cocolog.jp	603
https://twitter.com	22
https://pyxis.sega.co.jp	13
http://www.peeep.us	2
https://www.chatwork.com	2
http://app.cocolog-nifty.com	1
http://www.open.sh	1
http://webcache.googleusercontent.com	1

SlideShare for iOS

Views

Actions

Embeds 1,652

Report content

Transcript