SQIP2015講演資料「チケット駆動開発の運用パターン集～問題はチケットに分割して統治せよ」
•
13 likes•13,745 views
併設チュートリアル7「チケット駆動開発入門 ～基礎から応用まで～」 | ソフトウェア品質シンポジウム 2015 (2015/9/16) http://www.juse.jp/sqip/symposium/2015/detail/tutorial/#tutorial_7 【公開】SQIP2015講演資料「チケット駆動開発の運用パターン集～問題はチケットに分割して統治せよ」 #Redmine: プログラマの思索 http://forza.cocolog-nifty.com/blog/2015/09/sqip2015-redmin.html
SQIP2015講演資料「チケット駆動開発の運用パターン集～問題はチケットに分割して統治せよ」
- 2. 自己紹介 • 講演者： • あきぴー、技術士(情報工学) • 関心のあるテーマ • アジャイル開発 • OSSのプロジェクト管理ツール「Redmine」 • チケット駆動開発(Ticket Driven Development：TiDD) copyright2015 akipii@XPJUG関西 2
- 3. 主な著書 • 「Redmineによるタスクマネジメント実践技法」 (with 阪井さん) • 「チケット駆動開発」 (with 阪井さん) • 「Redmine超入門」(with redmine.tokyoスタッフ) ・ 「Redmine 実践ガイド」 (with (株)アジャイルウェア) ・ 「Ultimate Agile Stories -Iteration 1〜5」 (同人誌 with 細谷さん) copyright2015 akipii@XPJUG関西 3
- 4. 過去の講演 • SPES2009(ソフトウェア・プロセス・エンジニアリング・シンポジウム) • 「チケット駆動開発：BTSによるアジャイル開発の改善」 • SQIP2009(ソフトウェア品質シンポジウム) • 「チケット駆動開発：BTSでeXtreme Programmingを改善する」 • http://www.juse.jp/sqip/symposium/2009/day1/files/ippan_2-1.pdf • デブサミ2011(Developers Summit) • 「【17-B-3】チケット駆動開発〜タスクマネジメントからAgile開発へ」 • http://www.slideshare.net/akipii.oga/2011agile • 「【17-B-4】チケット管理システム⼤決戦 JIRA vs Redmine vs Trac 〜ユーザーが 語る、なぜ私はこのツールを使うのか」 • http://www.slideshare.net/SeanOsawa/jira-vs-redmine-vs-trac • ベストスピーカー賞2、3位受賞 http://codezine.jp/article/detail/5900 • AgileJapan2012 • 「チケット駆動開発の課題と展望」 http://www.slideshare.net/akipii.oga/agilejapan2012-12034567 • デブサミ2013(Developers Summit) • 「【14-B-5】チケット駆動開発のフレームワーク〜現場の経験知からパターン⾔語へ」 • http://www.slideshare.net/akipii.oga/devsumi-ogawa-20130214 copyright2015 akipii@XPJUG関西 4
- 6. 【再掲】Redmineとは • OSSの汎用的なPJ管理ソフトウェア • 最新版：Ver3.1 (2015/8) • Googleトレンドでは日本で一番人気 copyright2015 akipii@XPJUG関西 6 【主な特徴】 ①チケットでタスク管理 ②ワークフロー管理で変更管理 ③バージョン管理ツールと連携して 構成管理 ④ガントチャートで進捗管理
- 7. 【再掲】チケット駆動開発(TiDD)とは copyright2015 akipii@XPJUG関西 7 ソフトウェア開発の全ての作業をチケット(小さな単位のタスク)に 分割して管理する開発手法。 次の3つのプラクティスを実践するとうまくいく。 No プラクティス 説明 効果 1 Ticket First (No Ticket, No Work) プロジェクト内の全ての作業はチ ケットに起票してから作業を始める (チケット無しで作業しない) ③PJ管理を強化できる ④SW開発以外の業務に 適用できる 2 No Ticket, No Commit チケット無しで構成管理の配下に ある成果物のコミットを許さない ②構成管理を厳格に実現 できる 3 Iteration is Version ①イテレーション、②マイルストーン、 ③リリース予定バージョン を同一視する ①アジャイル開発と相性が 良い
- 8. 今回のテーマ TiDDは色んな特徴と効果があって⾯⽩いので、内容を整理したい。 Redmineを使って、下記のテーマと事例を紹介する。 copyright2015 akipii@XPJUG関西 8 No テーマ 事例 第１部 アジャイル開発への適用 【1】Scrumによるアジャイル開発 第２部 構成管理パターンの実現⽅法 【2】構成管理パターン 第３部 PJ管理の強化 【3】PMBOKのEVM 【4】PMBOKの要員管理 第４部 SW開発以外の業務への適用 【5】事務処理の申請承認フロー
- 9. FG分析の⽅針 • Redmineによるチケット駆動開発の適用結果をFG分析で評価する • 【P：問題】 • Redmine導入前の問題点 • 【S：解決策】 • Redmine導入による解決策 • 問題点に対し、Redmineをどのように導入して解決するのか • 【E：効果】 • Redmine導入によるメリット • 【I：課題】 • 現状では解決できていない課題 • 【F：FG分析】 • FG分析のまとめ • 考察 copyright2015 akipii@XPJUG関西 9
- 10. Agenda • Introduction • 第1部 アジャイル開発への適用 • 【1】ScrumによるAgile開発 • 第2部 構成管理パターンの実現⽅法 • 【2】構成管理パターン • 第3部 PJ管理の強化 • 【3】PMBOKのEVM • 【4】PMBOKの要員管理 • 第4部 SW開発以外の業務への適用 • 【5】事務処理の申請承認ワークフロー • まとめ copyright2015 akipii@XPJUG関西 10
- 11. 【補足】今回の講演の補足資料 • 今回の講演は、2013/9の下記の資料の続きのイメージです • 「Redmineの運用パターン集〜私に聞くな、チケットシステム に聞け」 http://www.slideshare.net/akipii.oga/sea-west- ogawa201309open copyright2015 akipii@XPJUG関西 11
- 14. • インクリメンタル ＆ イテレーティブなAgile開発プロセス • プロジェクト運営活動に特化したシンプルなフレームワーク • 30日間サイクルのスプリントを反復して開発していく Scrumとは copyright2015 akipii@XPJUG関西 14 https://en.wikipedia.org/wiki/File:Scrum_process.svg 【Daily Scrum】 【Sprint Review】 【Sprint Retorispective】 【Sprint Planning】【Release Planning】
- 15. Scrumの構造 copyright2015 akipii@XPJUG関西 15 Scrum プロセス プロダクトバックログ バーンダウンチャート スプリントバックログ 成果物 ロール プロダクトオーナー(PO) チーム スクラムマスター(SM) スプリント計画 デイリースクラム スプリントレビュー 重要なテクノロジーは10名以下のチームで作られた ～ Innovation Sprint 2011（後編） － Publickey http://www.publickey1.jp/blog/11/10_innovation_sprint_2011.html
- 16. 【P】問題提起 • RedmineではAgile開発がやりにくい部分がある • ストーリーポイントがデフォルトでは入⼒できない • バーンダウンチャートをExcelで集計する必要がある • Velocityを計測しにくい • Scrumをプロセスとしてどのように運用するのか？ • ScrumのルールはRedmineにどのようにマッピングされるか？ copyright2015 akipii@XPJUG関西 16
- 17. 【S】Backlogsプラグインとは • RedmineのScrumプラグインで最も有名(のはず) • Scrumの細かな部分まで機能として実現している • Redmineの公式の対応バージョンはVer2.3.2 • 非公式だが、Ver2.6.xも動作するみたい copyright2015 akipii@XPJUG関西 17 Redmine Backlogs :: Home http://www.redminebacklogs.net/
- 19. 【S】基本概念のマッピング copyright2015 akipii@XPJUG関西 19 基本概念 Redmine or Backlogsプラグインの機能 プラクティス・注意点 ストーリーカード 親チケット(ストーリー) 一件一葉 タスクカード 子チケット(タスク) タスクはチケットに分割 スプリント障害 ブロック元チケット(課題・障害) - スプリント バージョン Iteration is Version プロダクトバックログ 期限なしバージョンのチケット リリース計画で実施 スプリントバックログ 期限ありバージョンのチケット スプリント計画で実施 小規模リリース(XP) かんばん(タスク) ステータス毎のチケット一覧 デイリースクラムで実施 かんばん(ストーリー) スプリント毎のチケット一覧 優先度でソートする ストーリーポイント (Spt) 開発規模(チケットの属性) プラニングポーカーを実施 バーンダウンチャート 残Sptの時系列データ - ベロシティ 1スプリントのSpt実績合計 持続的な開発ペース(XP)
- 20. 【S】Backlogsプラグインを設定 copyright2015 akipii@XPJUG関西 20 「ストーリー」「タスク」のトラッカーを 設定する ストーリーポイントをフィボナッチ数 で設定する
- 22. 【S】スプリント計画 • SMがストーリーをスプリントに割り当てる • Velocityに合うように、SMはストーリーを調整する • スプリントはRedmineバージョンに相当する • スプリント名は「スプリント番号_そのスプリントの到達目標点」でも良い copyright2015 akipii@XPJUG関西 22
- 23. 【S】かんばん画⾯ • チームは、かんばんで進捗管理する • タスクをドラッグ＆ドロップするだけ • 終了に移動すると、自動的に残り時間が「0」に なる • SMが勝手にステータスを更新しない • チームが決める • チームの役割は、スプリントの全ストーリーを リリースすること • SMの役割は、スプリントを完了させるために POやチームを支援すること copyright2015 akipii@XPJUG関西 23
- 24. 【S】タスク登録 • ストーリーからタスクを成する • SMはチームと相談しながら作業分割 • タスクはストーリーの子チケット • 原則として、担当者はスプリント計画の 時点では入⼒しない • デイリースクラムで担当を決める • 残作業時間でバッファ管理 • 開発者と相談して記録する • 作業時間に実績工数を付ける • 作業者＝実績工数を付ける人 copyright2015 akipii@XPJUG関西 24
- 25. 【S】スプリント障害を登録 • QAやバグをあげる • チームからSMへのリクエストになる • QAは、基本はSMが解決する • ブロック欄に、ブロックされるチケット IDを登録する • 関連チケットに追加される • ブロック元＝スプリント障害 • ブロック先＝ストーリーorタスク • 「その他」ストーリーも登録して良い • どのストーリーにも紐付かない作業 • 例：開発環境の構築 copyright2015 akipii@XPJUG関西 25 スプリント障害がCloseさ れなければ、#1,#2のス トーリーはCloseできない
- 27. 【S】スプリント終了 • スプリントの終了は、バージョン設定画⾯でステータス更新 • SMはベロシティを保守する • 却下したストーリーはストーリーポイント＝0にする • 終了しないストーリーは、次スプリントへチケットをコピーする (Redmineのチケットコピー機能を使う) copyright2015 akipii@XPJUG関西 27
- 28. 【S】スプリントレビュー • スプリントのWikiに記録する • 打合せ議事録 • レビューやフィードバック • チームのふりかえり • スプリントの議事録テンプレート をWikiに作っておくと良い • プラグイン設定画⾯で設定する copyright2015 akipii@XPJUG関西 28 Ruby - redmineのプラグインredmine_backlogsの (個人的な)設定のお話 - Qiita http://qiita.com/ex_SOUL/items/be91f0a06bb 38a6b2b87
- 30. 【E】効果 copyright2015 akipii@XPJUG関西 30 プロセス ⽅法 効果 プロダクト バックログ管理 ・ストーリーを親チケットで作成 ・ストーリーの優先順位は並び順 ・「リリース」機能でグループ化 ・POは、プロダクトバックロ グの保守に専念できる スプリント計画 ・スプリントをバージョンで作成 ・タスクを子チケットで作成 ・ストーリーポイントで⾒積り ・ストーリーをスプリント単位 にグループ化する作業がや りやすい デイリー スクラム ・かんばんで進捗管理する ・バーンダウンチャートで進捗確認 ・スプリント障害をブロック(関連)で実現 ・SMやチームはタスク管理 に専念できる スプリントレビュー & スプリント レトロスペクティブ ・レビューやフィードバックはWikiに記録 ・スプリントごとのVelocityを計測 ・スプリント結果を後で参 照できる
- 31. 【I】主な課題 • BacklogsプラグインのVerUpが止まっている • Redmine3.xに未対応 • OSSなので対応したい • バーンダウンチャートを綺麗に表示させるのが⼤変 • EVMと同じく、綺麗に運用するのが難しい • ストーリーポイントの精度にバラつきが出やすい • ベロシティを安定させるのが難しい • ベロシティからスプリント計画の精度を上げたいが、上手くいかない場合も ある copyright2015 akipii@XPJUG関西 31
- 32. 【F】フィットギャップ分析 Redmine BacklogsプラグインはScrumプロセスを忠実に 実現しようとしている copyright2015 akipii@XPJUG関西 32 評価の観点 評価 評価理由 プロセス ○ ○：スプリント計画(作成・実⾏・完了)を保守しやすい ○：かんばんやバーンダウンチャートで、デイリースクラムを支援 してくれる ○：スプリントレビューの結果をWikiに記録して参照できる ロール ○ ○：POは、プロダクトバックログの保守に専念できる ○：SMは、Backlogsの全画⾯をモニタリングすることで、プロ セス遵守を確認できる ○：チームは、カンバンを保守するだけでリリースに専念できる 成果物 ○ ○：PBLは、バックログ画⾯の操作だけで完結できる ○：SBLは、かんばん画⾯を保守する ○：バーンダウンチャートは、残Sptや残り時間をリアルタイムに 表示してくれる
- 34. Scrumにおけるチケット駆動開発の戦略 copyright2015 akipii@XPJUG関西 34 • ロードマップをリリース計画のように扱い、小規模リリースを運 用する開発プロセス • チケットをスプリント単位にグループ化して、小刻みにリリースしていく • アジャイル開発のプラクティスをチケット管理に組み込んでいく
- 37. 【P】問題点 • 複数のブランチのタスク管理が煩雑 • 本番運用と開発中の2本のブランチを持つ並⾏開発 • 常に本番運用・開発中の二つのブランチを保守するのは⼤変 • 継続的な修正が多い • 継続的なリファクタリングや機能追加を制御するのは難しい • 頻繁なリリース管理が⼤変 • 短期間に順次リリースするプロセスはやっぱり⼤変 copyright2015 akipii@XPJUG関西 37
- 39. 【S】リリースブランチ • Trunkから派生された本番運用中のブランチ • ブランチ管理の⽅法 • ①Redmineの複数PJ機能を使う • trunk＝親PJ、リリースブランチ＝子PJ • 利点：ブランチごとにタスク管理が明確 • 弱点：タスクが散在して管理しにくい • ②Redmineのマルチリポジトリ機能を使う(Ver1.4以降) • 各ブランチは1PJに含まれる • PJとリポジトリは1対多の関係 copyright2015 akipii@XPJUG関西 39
- 40. 【S】トピックブランチ • 仕様変更や障害修正などの特定目的で修正するブランチ • チケットの作業をトピックブランチ上で⾏う • トピックブランチ名はチケットIDにする(No Ticket, No fork) • トピックブランチが検証完了になったら、trunkへmerge(rebase)する • トピックブランチが消滅する時に、チケットもCloseする(No Ticket, No Merge) • ブランチの作業状態をチケットのステータスで管理できる • チケットの作業順序とリリース順序が異なる場合に有効 copyright2015 akipii@XPJUG関西 40
- 41. 【E】ブランチのライフサイクル ブランチの寿命に応じて、Redmineの機能へのマッピングを変える copyright2015 akipii@XPJUG関西 41 リリースブランチは、リリース時に生成され、次Verリリース 時に消滅する。 →リリースバージョンはRedmineバージョンでタグ付する 【関連パターン】 ・小規模リリース、Iteration is Version メインラインは製品の生存期間中、残り続ける。 →メインラインは、Redmineプロジェクトに対応付け、 リポジトリブラウザで⾒る。 【関連パターン】 ・製品とリポジトリの一致 トピックブランチは、トピック発生時に生成され、マージ 時に消滅する。 →トピックブランチは、Redmineチケット単位に作る。 トピックブランチがマージされるとRedmineチケット はCloseされる。 【関連パターン】 ・No Ticket No fork, No Ticket No Merge Redmine バージョンバージョンバージョンバージョン Redmine プロジェクトプロジェクトプロジェクトプロジェクト Redmine チケットチケットチケットチケット
- 42. 【E】効果 copyright2015 akipii@XPJUG関西 42 項目 Redmineに対応する機能 効果 trunk (master) 親プロジェクト ・ブランチの細かなタスクをチケット管 理できる ・trunkが常に最新機能になる リリースブランチ 子プロジェクト Or trunkのプロジェクト ・trunkを凍結する必要がない ・並⾏で新規開発できる トピックブランチ チケット ・trunkに影響させずに開発できる ・リリース順序に合わせてマージしや すい リリースバージョン (タグ) バージョン ・アジャイル開発と連携しやすい
- 44. 【参考】GitHubフロー • GitHubで使われるGitのブランチ管理フロー • 利点：Web画⾯上でfork, mergeなどを全て操作できる • マージは必ずPull Requestを通す • 利点：パッチのやり取り、コードレビューがプロセスとして手順化される copyright2015 akipii@XPJUG関西 44 メインラインメインラインメインラインメインライン (master) トピックブランチ fork merge ①masterは常時デプロイ可能 ②ブランチのfork元は必ず masterにする ③定期的にprivate branchからRemoteへPush ④WIP Pull Requestで議 論や事前レビュー ⑤Pull RequestがOKなら masterにmergeされる
- 45. Redmineの課題はGit連携の強化 • 【Redmineの利点】チケットにパッチを添付して、やり取りしなくても良い (手順1→2、3→4) copyright2015 akipii@XPJUG関西 45 メインラインメインラインメインラインメインライン (master) トピックブランチ 【【【【手順手順手順手順1】】】】 #10 機能機能機能機能追加追加追加追加 (新規新規新規新規) 【【【【手順手順手順手順3】】】】 #10 機能機能機能機能追加追加追加追加 (終了終了終了終了) 【手順2】 fork 【手順4】 merge #10 機能機能機能機能追加追加追加追加 (作業中作業中作業中作業中) • 【課題】GitHubのような手軽さがない • 例：forkやmerge、pull requestの操作後に、チケット登録・Closeのフック 処理を自動で実⾏する(手順2→1、手順4→3にしたい)
- 48. EVMとは copyright2015 akipii@XPJUG関西 48 • プロジェクトのスケジュール管理やコスト管理を「出来⾼(Earned Value)」で把握する手法 • PMBOKのコストマネジメント領域の技法の一つ
- 49. (copyright2015 akipii@XPJUG関西) 49 【P】EVMの工数管理の問題 • ソフトウェア成果物の出来⾼(EV)の定義が難しい • 進捗率50％と90％のソフトウェアの違いは何か？ • 成果物の完了基準があいまい • Excelに実績工数を入⼒するのは手間がかかる • PGの実績工数に入⼒漏れがないかチェックしづらい • Excelによる工数集計の作業が煩雑 • PMが工数集計するにはExcelマクロの組み込みが必要 • Excelマクロを頑張るほど、一つの工数管理システムになる
- 50. (copyright2015 akipii@XPJUG関西) 50 【S】チケットでアクティビティを追跡 アクティビティアクティビティアクティビティアクティビティプロジェクト計画プロジェクト計画プロジェクト計画プロジェクト計画 詳細化 出来高出来高出来高出来高(¥)価値価値価値価値 等価 実現 チケットチケットチケットチケット (ストーリーカードストーリーカードストーリーカードストーリーカード) チケットチケットチケットチケット (タスクカードタスクカードタスクカードタスクカード) チケットチケットチケットチケット (タスクカードタスクカードタスクカードタスクカード) 詳細化 対応 等価 実績入力計測 集計 出来高出来高出来高出来高 (MD) 出来高出来高出来高出来高 (MD) TiDDでEVMを 実現する方法
- 51. (copyright2015 akipii@XPJUG関西) 51 【S】EVMの基本概念のマッピング メトリクス PV AC EV 英語名 Planned Value Actual Cost Earned Value 日本語名 計画値 実績値、実コスト 出来⾼ 意味 該当期間までに完 了していると計画 された作業の予算 該当期間までに実 際に投入した実績 値 該当期間までに投入した成果 物の実績値 Redmine における 実装⽅法 チケットの予定工 数 チケットの実績工 数 ①WF型開発の場合、 PV ＊ チケットの進捗率(%) ②Agile開発の場合、 (1)未完了⇛ 0 (2)完了 ⇛ PV
- 52. 【例】EVの計測⽅法 copyright2015 akipii@XPJUG関西 52 • 出来⾼の考え⽅は、WF型開発とアジャイル開発では、根本的に 異なる EVの観点 EVの定義 計算の具体例 (例：PV＝10) 効果と注意点 WF型開発 作業の進捗率 で計測する 着手済=50% ⇛ EV=5 レビュー前=80% ⇛ EV=8 完了=100% ⇛ EV=10 ・進捗率をステータスで紐づ ければ、工事進⾏基準にも 使える。 ・レビュー未済の成果物に本 当の価値があるのか疑問が ある。 アジャイル開 発 顧客へ納品した 成果物で計測 する 着手済 ⇛ EV=0 レビュー前 ⇛ EV=0 完了 ⇛ EV=10 ・完了基準が明確 ・成果物が完成するまで、進 捗が遅れているように⾒える ⇛ EVの定義は、Doneの定義(Scrum)と本質的に同じ
- 53. (copyright2015 akipii@XPJUG関西) 53 【S】Redmineチケットに工数入⼒ PVPVPVPV＝チケットの予定工数＝チケットの予定工数＝チケットの予定工数＝チケットの予定工数 ACACACAC＝チケットの実績工数の和＝チケットの実績工数の和＝チケットの実績工数の和＝チケットの実績工数の和 EVEVEVEV＝＝＝＝PV *PV *PV *PV * 進捗率進捗率進捗率進捗率(%)(%)(%)(%) (WF(WF(WF(WF型開発の場合型開発の場合型開発の場合型開発の場合))))
- 54. 【補足】EVMで使われるメトリクス copyright2015 akipii@XPJUG関西 54 メトリクス 日本語名 公式 意味 SPI スケジュール効率指標 EV/PV ＞1なら進捗が良い CPI コスト効率指標 EV/AC ＞1なら効率が良い SV スケジュール差異 EV - PV ＞０なら進捗が良い CV コスト差異 EV - AC ＞0なら効率が良い BAC 完成時総予算 PVの総和 プロジェクト⽴上時の総予算。 ベースラインとして予実比較で使われ る。 EAC 完成時総コスト⾒積り 次ページ参照 測定時点までの進捗度合から推測さ れる総コスト。 TCPI 残作業効率指標 (BAC-EV) / (BAC-AC) プロジェクト完了までにどれくらい効率 良く働くべきかという指標。 TCPI=1.5なら、今の1.5倍働く必要 がある。
- 55. 【S】RedmineにEVMを実装したイメージ(1) 現在の開発ペースで、完成時総コスト⾒積り(EAC)が 当初予算(BAC)の範囲内に収まるか否かを予測できる copyright2015 akipii@XPJUG関西 55 ※EACは以下で計算できる。 EAC=BAC/CPI 即ち、「現在の開発ペースで進捗が 進む」と仮定して計算している。 フォーカスを当てれば、 完成時総コスト見積り(EAC) も表示される (株)アジャイルウェア EVM Plugin | Lychee Enterprise http://lychee-redmine.jp/evm.html
- 56. 【S】RedmineにEVMを実装したイメージ(2) SPI・CPIの安全圏は⻘色、危険圏はピンク色、注意圏は⻩色 で表示する ⇒現在の開発ペースから、納期遅延やコスト増のリスクを事前に 検知できる copyright2015 akipii@XPJUG関西 56 例では、SPI＞1なので、ほぼスケジュル通りに進んでいる。 しかし、CPI＜1なので、想定よりもコストがかかっている。 (株)アジャイルウェア EVM Plugin | Lychee Enterprise http://lychee-redmine.jp/evm.html
- 57. (copyright2015 akipii@XPJUG関西) 57 【E】Redmine適用の効果 プロセス 改善⽅法 効果 EVの定義 チケットの進捗率や完了チケット数で EV(出来⾼)を判定する ・EVの定義が明確になる ・EVMの計算に正当性を付与 できる 工数入⼒ 実績工数や進捗率はチケットに登録し てもらう ・タスク管理の一環としてチケッ トに入⼒してもらえる ・実績工数の入⼒をサポートす るチケット機能を活かせる 工数集計 日々の工数集計処理はチケットシステ ムが代⾏する ・EVM Pluginを使えば、リアル タイムに集計表示できる ・将来のコストやスケジュールを 予測できる
- 58. (copyright2015 akipii@XPJUG関西) 58 【I】Redmine適用の課題 • 予定日と実績日の区別がない • 厳密な予実管理はチケットのカスタマイズが必要 • 工数入⼒、工数チェックの運用ルールが⼤切 • 入⼒した工数と作業した工数に⽭盾がないかチェック • 出来⾼と工数の概念を等価にする基準を明確化する • 詳細な集計処理は締め処理やバッチ処理が必要 • 締め日(マイルストーン)以前は、過去の実績は修正不可 • 最終的にはマイルストーンごとにバッチ処理で工数集計する
- 59. (copyright2015 akipii@XPJUG関西) 59 【F】工数管理とのフィットギャップ分析 工数管理の 機能 機能概要 評価 工数収集 ・入⼒した工数を収集する ・工数の種類を入⼒する (例：活動基準原価計算) △ (○：チケットで工数入⼒、 △：活動分類で工数を種類付け する) 工数集計 ・予実管理に基づいて集計する ・日次、月次バッチで実績工数を 確定する △ (○：リアルタイム集計、 ✕：集計バッチ処理) 原価管理と 連動 ・原価管理システムへデータ取り込 み ・会計システムにデータ取り込み ✕
- 61. 【P①】担当者の空き状況が分からない • 今日や明日は誰が空いているか、予定表を知りたい • 突発的な作業、緊急の本番障害対応で、作業を依頼できるメン バーをすぐに知りたい • 複数プロジェクトを横断して、担当者の空き状況を⾒たい • 優秀なメンバーの空き状況を知りたい • 優秀なメンバーはいつも忙しいので、予約したい copyright2015 akipii@XPJUG関西 61 No 担当者担当者担当者担当者 12月第月第月第月第2週週週週 12月第月第月第月第3週週週週 1 山田太郎 A案件 A案件(忙しい) 2 伊藤次郎 B案件、出張 C案件(実はヒマ) 問題：担当者の作業予定表が最新化されていない
- 62. 【P②】リソース管理の精度が悪い • ガントチャートを作っても、担当者ごとのリソースにムラが発生する • 例：ある日のメンバーは20時間働くような計画 • プロジェクト計画時に、リソース管理の精度を良くしたい • プロジェクト計画の⾒積りの精度を上げたい copyright2015 akipii@XPJUG関西 62 ガントチャート リソースヒストグラム 1日の標準時間よりも予 定工数が超過している 問題：ガントチャートを作ると、リソースにムラが発生しやすい
- 63. 【P③】稼働率を⾒たい • 受注⾒込みの案件に、誰をアサインできるか？ • 会社や事業部で、案件を引き受けるだけのリソースがあるか？ • 稼働率が低いなら、作業を受け入れる余裕がある • 翌月〜1年後の稼働率から組織編成を考える • 受注⾒込みの案件の多い部署もあれば、暇な部署もある • 社員の稼働率が均等になるように、組織を編成し直す copyright2015 akipii@XPJUG関西 63 担当者名担当者名担当者名担当者名 1月1月1月1月 2月2月2月2月 ・・・・・・・・・・・・ 11月11月11月11月 12月12月12月12月 山田太郎山田太郎山田太郎山田太郎 120120120120 110110110110 ・・・・・・・・・・・・ 100100100100 102102102102 伊藤次郎伊藤次郎伊藤次郎伊藤次郎 62.562.562.562.5 70707070 ・・・・・・・・・・・・ 80808080 94949494 鈴木三郎鈴木三郎鈴木三郎鈴木三郎 100100100100 85.585.585.585.5 ・・・・・・・・・・・・ 102.5102.5102.5102.5 62.562.562.562.5 単位：％ 問題：Redmineチケットから、稼働率を表⽰できるか？ 表：2014年のメンバーの稼働率
- 65. copyright2015 akipii@XPJUG関西 65 【S】要員表 or リソースヒストグラムのイメージ ①作業予定(⻘色)と作業実績 (赤色)を棒グラフで表示。 ②作業負荷が⾼いと赤色・⻩色 で警告表示。 (株)アジャイルウェア Resource Management Plugin | Lychee Enterprise http://lychee-redmine.jp
- 66. 【S】稼働率のイメージ copyright2015 akipii@XPJUG関西 66 担当者別・日別に稼働 率を表示する (株)アジャイルウェア Resource Management Plugin | Lychee Enterprise http://lychee-redmine.jp
- 67. 【補足】稼働率・生産性の計算式 • チケットの予定・実績工数を元に計算できる • リーダーは、稼働率や生産性を元にPJ運営が⾏える • 例：特定の担当者の稼働率が⾼ければ、タスクを調整する • 例：特定の担当者の生産性が落ちていれば、支援する copyright2015 akipii@XPJUG関西 67 メトリクス 過去日 未来日 備考 稼働率 Σ実績工数 /標準工数 Σ予定工数 /標準工数 ＞１：負荷が⾼い ＜１：負荷が低い 生産性 ΣEV/Σ実績工数 なし CPIと同じ。 ＞１：生産性が⾼い ＜１：生産性が低い ※標準工数＝契約上の1人月 or 1人日の時間
- 68. 【E】効果 copyright2015 akipii@XPJUG関西 68 プロセス ⽅法 効果 要員表 ・時系列と担当者で、工数集 計をクロス集計する ・担当者の空き状況を確認して、作業 指示できる ・直近から数カ月先までの作業予定を 確認できる リソース ヒストグラム ・担当者ごとに、時系列に工数 集計する ・担当者の作業負荷を過去から数カ 月先まで確認できる ・作業負荷が⾼い状況が続く場合、 早めに対策を打てる 稼働率・ 生産性 ・時系列と担当者で、稼働率 や生産性をクロス集計する ・担当者の稼働率や生産性の推移を 確認できる
- 69. 【I】主な課題 • 標準工数はどのように決めるか？ • 1人日、1人月の単位は現場で異なる • メンバーごとに1人月の単位は変わる • 例：工数委託・派遣社員 • 例：時短の社員 • 警告メッセージを出したい • 稼働率や実績工数が閾値を超えたら警告表示 • 管理者にメンバーの作業予定を調整させる (山崩し) • 締めの概念が必要 • 先月末までの予定・実績工数は修正不可 • 今月以降の予定・実績工数はリアル集計で良い • 日次・月次バッチ処理で集計して出⼒ copyright2015 akipii@XPJUG関西 69
- 74. 【P】問題提起 • 申請書をメールでやり取りするのは煩雑 • メールに添付された申請書が散乱 • 申請書の最新版が不明 • Excel台帳は管理しにくい • 承認状況を把握しにくい • 承認フローのボトルネックが分かりにくい • 承認ルートが煩雑 • メール＋Excel申請書は承認ルートが曖昧 • ボトルネックの承認者が気づきにくい • 通知や督促を⾏う専任者を別途設けるコストがかかる copyright2015 akipii@XPJUG関西 74
- 75. 【S】申請書はチケット管理 copyright2015 akipii@XPJUG関西 75 チケット(申請書) 申請申請申請申請 承認承認承認承認 通知メール通知メール通知メール通知メール ・督促メール・督促メール・督促メール・督促メール 未承認一覧画面未承認一覧画面未承認一覧画面未承認一覧画面 メール通知メール通知メール通知メール通知 リアル表示リアル表示リアル表示リアル表示 承認フローは チケットのワークフロー管理で制御する 申請者申請者申請者申請者 承認者承認者承認者承認者
- 77. 【S】承認ルートはワークフロー管理 • 承認ルートはワークフロー管理機能で一元化する • トラッカーは申請書の種類ごとに作成する • 煩雑なワークフローは整理する copyright2015 akipii@XPJUG関西 77
- 78. 【S】チケット一覧で承認状況を把握 copyright2015 akipii@XPJUG関西 78 • 状況に応じてカスタムクエリを用意しておく • 例：自分が承認すべき未承認チケット
- 79. 【S】リマインダーメールで督促 • 督促メールはRedmineのリマインダー機能で使う • 例：期日遅れ or 期日3日前の承認待ちチケット • 督促の専任者を設ける必要がない copyright2015 akipii@XPJUG関西 79 督促メール送信処理は Cronでrakeコマンドを 設定しておく
- 80. 【E】効果 copyright2015 akipii@XPJUG関西 80 プロセス 改善⽅法 効果 申請 ・申請書はチケットで代用 ・Excel資料はチケットに添付 ・申請情報がチケットに集約さ れる ・いつでも申請情報を参照でき る 承認状況の 把握 ・承認ルートはワークフロー管理で制御 する ・チケット一覧で承認状況を⾒える化 ・承認ルートが明確になる ・遅延した申請書のボトルネッ クが一目で分かる 通知・督促 ・チケット更新時にメール通知 ・リマインダーメールで督促 ・申請者が手動で通知する必 要がない
- 81. 【I】承認者を設定しにくい • 承認者の絞り込み機能がない • 担当者に⼤量のメンバーが表示されて使いにくい • 承認者をデフォルト設定したい • 次ステータスへ更新したら承認者を自動設定したい copyright2015 akipii@XPJUG関西 81 例えば、担当者が50人も いると選択しづらい
- 82. 【I】発展的なワークフロー機能がない 汎用ワークフローシステムの機能が不足している ※下記の不足機能は全てではなく一例 copyright2015 akipii@XPJUG関西 82 No 不足している機能 機能の詳細 1 根回し 複数人の承認者が全員承認するまで先に進めない 2 代理承認 同じステータスの権限を持つ人が代理で承認できる 3 動的承認 既定のワークフローとは別のワークフローを途中のステー タスに追加する(例：別部署の承認) 4 承認ルートの分岐 ワークフローに分岐条件を入れる(例：決済⾦額) 5 組織マスタ設定 ユーザと承認ルートに組織情報を持たせる 6 トラッカーのグループ化 申請書の種類でトラッカーをグループ化する 7 電子印鑑による承認 紙の判子の代わりに電子印鑑を用いて承認の証跡を 残す
- 83. 【F】フィットギャップ分析 copyright2015 akipii@XPJUG関西 83 評価の観点 評価 評価理由 申請 △ ○：申請書のレイアウトにチケットの項目を合わせる △：申請書の種類が⼤量な場合、トラッカーを選択しにくい 承認ルートの 制御 △ ○：単純な承認ルートはカスタマイズ不要 X：根回し、分岐、動的承認などの発展的なワークフロー機 能はない △：承認者の選択が使いにくい 承認状況の 把握 ○ ○：利用状況に応じたカスタムクエリを作成すれば良い 承認の通知・ 督促 △ ○：通知メール、督促メールはデフォルト機能で実現 △：承認ステータスごとに通知メールのCcを選択したい場合、 ウォッチャー機能では不⼗分
- 86. チケットの二⾯性 チケットは「ストック」「フロー」の二⾯性を持つ copyright2015 akipii@XPJUG関西 86 機能 TODO Doing Done ストーリー1 ストーリー2 チケット 集計結果 【1】チケット＝ストックの場合 ①チケットは記録媒体 ②チケットは集計されて計測される ③チケットは蓄積されて ナレッジ資産になる 【2】チケット＝フローの場合 ①チケットは流通媒体 ②チケットは流通させる ③ステータス遷移を ワークフロー管理で制御 記録 出力
- 87. ストックとフローの比較 copyright2015 akipii@XPJUG関西 87 観点 ストック フロー 利用シーン BTS、ITS、 ｿﾌﾄｳｪｱ保守、ﾍﾙﾌﾟﾃﾞｽｸ管理、 PC資産管理、 PMBOKのEVM・要員管理 Agile開発、かんばん駆動、 申請承認フロー 主な メトリクス ・ソフトウェア工学の品質管理(バ グ収束曲線etc.) ・PMBOKのスケジュール・コスト 管理(EVM・要員管理etc.) ・Velocity ・サイクルタイム ・チケット完了率(スループット) メリット ・ナレッジ資産になる ・タスクがサクサク流れる デメリット ・チケットの入⼒項目が多くなる ・管理の度合いが強まる ・チケットの入⼒内容がおろそかになり やすい ・情報量が少ないので、ナレッジ資産 になりにくい
- 89. 本日のまとめ • アジャイル開発と相性が良い • チケット発⾏から自動ビルドまで一元管理 • 小さな修正の繰り返し作業を管理できる • 並⾏開発を強化してくれる • ブランチ管理は複数PJ機能やチケット機能で実現 • コミットやマージの変更理由がチケットに残る • トレーサビリティの実現によって、並⾏開発に自信を持てる • PJ管理を強化してくれる • TiDDはメトリクス収集ツール • PMBOKの領域の殆どをカバーできるはず • SW開発以外の業務に適用できる • TiDDは汎用的な帳票WFシステム • チケットはフローorストックの両⾯を持つ copyright2015 akipii@XPJUG関西 89