More Related Content
Similar to SQIP2015講演資料「チケット駆動開発の運用パターン集~問題はチケットに分割して統治せよ」 (20)
More from akipii Oga (20)
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
- 10. Agenda
• Introduction
• 第1部 アジャイル開発への適用
• 【1】ScrumによるAgile開発
• 第2部 構成管理パターンの実現⽅法
• 【2】構成管理パターン
• 第3部 PJ管理の強化
• 【3】PMBOKのEVM
• 【4】PMBOKの要員管理
• 第4部 SW開発以外の業務への適用
• 【5】事務処理の申請承認ワークフロー
• まとめ
copyright2015 akipii@XPJUG関西 10
- 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】
- 19. 【S】基本概念のマッピング
copyright2015 akipii@XPJUG関西 19
基本概念 Redmine or Backlogsプラグインの機能 プラクティス・注意点
ストーリーカード 親チケット(ストーリー) 一件一葉
タスクカード 子チケット(タスク) タスクはチケットに分割
スプリント障害 ブロック元チケット(課題・障害) -
スプリント バージョン Iteration is Version
プロダクトバックログ 期限なしバージョンのチケット リリース計画で実施
スプリントバックログ 期限ありバージョンのチケット スプリント計画で実施
小規模リリース(XP)
かんばん(タスク) ステータス毎のチケット一覧 デイリースクラムで実施
かんばん(ストーリー) スプリント毎のチケット一覧 優先度でソートする
ストーリーポイント
(Spt)
開発規模(チケットの属性) プラニングポーカーを実施
バーンダウンチャート 残Sptの時系列データ -
ベロシティ 1スプリントのSpt実績合計 持続的な開発ペース(XP)
- 25. 【S】スプリント障害を登録
• QAやバグをあげる
• チームからSMへのリクエストになる
• QAは、基本はSMが解決する
• ブロック欄に、ブロックされるチケット
IDを登録する
• 関連チケットに追加される
• ブロック元=スプリント障害
• ブロック先=ストーリーorタスク
• 「その他」ストーリーも登録して良い
• どのストーリーにも紐付かない作業
• 例:開発環境の構築
copyright2015 akipii@XPJUG関西 25
スプリント障害がCloseさ
れなければ、#1,#2のス
トーリーはCloseできない
- 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を計測
・スプリント結果を後で参
照できる
- 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される
- 49. (copyright2015 akipii@XPJUG関西) 49
【P】EVMの工数管理の問題
• ソフトウェア成果物の出来⾼(EV)の定義が難しい
• 進捗率50%と90%のソフトウェアの違いは何か?
• 成果物の完了基準があいまい
• Excelに実績工数を入⼒するのは手間がかかる
• PGの実績工数に入⼒漏れがないかチェックしづらい
• Excelによる工数集計の作業が煩雑
• PMが工数集計するにはExcelマクロの組み込みが必要
• Excelマクロを頑張るほど、一つの工数管理システムになる
- 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)と本質的に同じ
- 54. 【補足】EVMで使われるメトリクス
copyright2015 akipii@XPJUG関西 54
メトリクス 日本語名 公式 意味
SPI スケジュール効率指標 EV/PV >1なら進捗が良い
CPI コスト効率指標 EV/AC >1なら効率が良い
SV スケジュール差異 EV - PV >0なら進捗が良い
CV コスト差異 EV - AC >0なら効率が良い
BAC 完成時総予算 PVの総和 プロジェクト⽴上時の総予算。
ベースラインとして予実比較で使われ
る。
EAC 完成時総コスト⾒積り 次ページ参照 測定時点までの進捗度合から推測さ
れる総コスト。
TCPI 残作業効率指標 (BAC-EV) /
(BAC-AC)
プロジェクト完了までにどれくらい効率
良く働くべきかという指標。
TCPI=1.5なら、今の1.5倍働く必要
がある。
- 57. (copyright2015 akipii@XPJUG関西) 57
【E】Redmine適用の効果
プロセス 改善⽅法 効果
EVの定義 チケットの進捗率や完了チケット数で
EV(出来⾼)を判定する
・EVの定義が明確になる
・EVMの計算に正当性を付与
できる
工数入⼒ 実績工数や進捗率はチケットに登録し
てもらう
・タスク管理の一環としてチケッ
トに入⼒してもらえる
・実績工数の入⼒をサポートす
るチケット機能を活かせる
工数集計 日々の工数集計処理はチケットシステ
ムが代⾏する
・EVM Pluginを使えば、リアル
タイムに集計表示できる
・将来のコストやスケジュールを
予測できる
- 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
- 68. 【E】効果
copyright2015 akipii@XPJUG関西 68
プロセス ⽅法 効果
要員表 ・時系列と担当者で、工数集
計をクロス集計する
・担当者の空き状況を確認して、作業
指示できる
・直近から数カ月先までの作業予定を
確認できる
リソース
ヒストグラム
・担当者ごとに、時系列に工数
集計する
・担当者の作業負荷を過去から数カ
月先まで確認できる
・作業負荷が⾼い状況が続く場合、
早めに対策を打てる
稼働率・
生産性
・時系列と担当者で、稼働率
や生産性をクロス集計する
・担当者の稼働率や生産性の推移を
確認できる
- 69. 【I】主な課題
• 標準工数はどのように決めるか?
• 1人日、1人月の単位は現場で異なる
• メンバーごとに1人月の単位は変わる
• 例:工数委託・派遣社員
• 例:時短の社員
• 警告メッセージを出したい
• 稼働率や実績工数が閾値を超えたら警告表示
• 管理者にメンバーの作業予定を調整させる (山崩し)
• 締めの概念が必要
• 先月末までの予定・実績工数は修正不可
• 今月以降の予定・実績工数はリアル集計で良い
• 日次・月次バッチ処理で集計して出⼒
copyright2015 akipii@XPJUG関西 69
- 80. 【E】効果
copyright2015 akipii@XPJUG関西 80
プロセス 改善⽅法 効果
申請 ・申請書はチケットで代用
・Excel資料はチケットに添付
・申請情報がチケットに集約さ
れる
・いつでも申請情報を参照でき
る
承認状況の
把握
・承認ルートはワークフロー管理で制御
する
・チケット一覧で承認状況を⾒える化
・承認ルートが明確になる
・遅延した申請書のボトルネッ
クが一目で分かる
通知・督促 ・チケット更新時にメール通知
・リマインダーメールで督促
・申請者が手動で通知する必
要がない
- 83. 【F】フィットギャップ分析
copyright2015 akipii@XPJUG関西 83
評価の観点 評価 評価理由
申請 △ ○:申請書のレイアウトにチケットの項目を合わせる
△:申請書の種類が⼤量な場合、トラッカーを選択しにくい
承認ルートの
制御
△ ○:単純な承認ルートはカスタマイズ不要
X:根回し、分岐、動的承認などの発展的なワークフロー機
能はない
△:承認者の選択が使いにくい
承認状況の
把握
○ ○:利用状況に応じたカスタムクエリを作成すれば良い
承認の通知・
督促
△ ○:通知メール、督促メールはデフォルト機能で実現
△:承認ステータスごとに通知メールのCcを選択したい場合、
ウォッチャー機能では不⼗分
- 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