THE SOFTWARE PROJECT MANAGER’S BRIDGE TO AGILITY 読書会 #10 : Quality Management 株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO 会場提供: PMI日本支部様
THE SOFTWARE PROJECT MANAGER’S BRIDGE TO AGILITY 読書会 #10 : Quality Management
株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO
会場提供: PMI日本支部様
初めての方へのご紹介• 本読書会は、PMI日本支部のアジャイルプロジェクトマネジメント研究会(正確には設立準備中)のサブプロジェクトとして開始したものです。
• アジャイルプロジェクトマネジメント研究会はPMI日本支部会員以外も参加可能です(当面)
興味のある方は → Facebook: “Agile_Study_Group”
News
• この書籍 “The Software Project Manager’s
Bridge to Agility” の新版がamazonで予約可能に!
• http://www.amazon.co.jp/dp/0321734254
• 2015年3月… まだまだ時間はあります!
前回のおさらい Cost Management ( 2 )
Waterfallの見積もりリソース 要件定義 基本設計 開発・単体 結合 UAT
PM 1 1 2 2 1
BusinessAnalyst 3 5 1 1 1
LeadDeveloper 2 2 2 2 2
Developer 3 5 10 5 4
QA 1 8 10 2
Migration 1 4 4
Total 8 13 22 22 13
スコープを固定して、スケジュールとリソースを見積もる
Agileの見積もりリソース Iteration1 Iteration2 Iteration3 Iteration4 Iteration5
ScrumMaster 1 1 1 1 1
BusinessAnalyst 3 3 3 3 3
LeadDeveloper 2 2 2 2 2
Developer 5 5 5 5 5
QA 4 4 4 4 4
SME 1 2
Total 15 15 16 15 17
リソースを固定して、スケジュールを見積もる
Cost Baseline
Feature
Feature
Feature Feature
Feature
Feature
Iteration1 Iteration2 Iteration3
Release Plan by Team
X
=Cost Baseline
Team cost times Iterations…
Cost Control
More Iterations More Cost
Less Features
Expected Team Velocity
HigherLower
Feature Feature
Less Iterations Less Cost
More Features
Quality Management
Chapter8
– P.F. ドラッカー
“製品やサービスの価値は供給者がつくるものではない。顧客が引き出し、対価を
払うものである。”
引用: P.F. ドラッカー著 上田惇生訳 「イノベーションと起業家精神」
– P.F. ドラッカー
“顧客は、自分にとって有用なもの、価値を提供してくれるものに対価を払う。それ以外のものは価値ではない。”
引用: P.F. ドラッカー著 上田惇生訳 「イノベーションと起業家精神」
Qualityとは何か• 等級: standard, grade, class
• - the TV signal is of a poor quality
• 上質: excellence, worth, value
• - work of such quality is rare
• 性質: feature, trait, attribute
• - her good qualities
引用: Oxford American Writer’s Thesaurus
PMBOK®のQuality• Prevention over detection
• 発見するのではなく、計画的・継続的に高めていくような記載
• Waterfallでは
• テスト ≒ 品質
• だいたい最終工程
ワークショップ• プロジェクト中で求められる品質の種類について考えます
• 開発プロジェクト中で求められる「品質」の具体例をそれぞれ1つ以上挙げてみましょう
• 3枚のPost it
• 等級
• 上質
• 性質
Quality Management
Chapter8
Quality Planning
Quality PlanningTraditional PM Agile PM
QAと相談して、品質標準・品質施策を決定する(※意訳)
顧客とチームで適切な品質標準・品質施策を決定する
品質管理とプロセス改善計画の公式ドキュメントを作成する
チーム間の合意ドキュメントとテスト/コーディング標準といった非公式ドキュメントにまとめる
収集する指標についてチームにアドバイスする
どういった指標が品質向上に役立つか、また管理に役立てる指標の利用
方法をチームと合意する
Quality Management
Chapter8
Quality Assurance
Demo, Review, Retrospective参加者 内容
Demo 誰でも 動くコードのデモフィードバックの収集
Review チームプロセスの定量評価改善点の収集
Retrospective チームプロセスの定性評価改善点の収集
Demo, Review, Retrospective Meeting Agenda ( 1 )• 基本ルール、目的とアジェンダの確認(PM)
• 当イテレーションで実施すると約束した全てのフィーチャーは何か(チーム)
• そのうち完了したフィーチャーは何か(チーム)
• 追加で完了したフィーチャーは何か(チーム)
• 完了しなかったストーリーでは、何が起きたのか(チーム)
• 動作するコードのデモ(チームメンバー)
• 製品のフィードバック(プロダクトオーナー)
• フィードバックは次のイテレーションのバックログやゴールにどういう影響を与えるか(プロダクトオーナー)
~~~~~~~~~ デモ完了 ~~~~~~~~~
• どういった指標についてレビューを実施するか。指標から学べることは何か(チーム)
• 他に追跡する指標はあるか(チーム)
~~~~~~~~ レビュー完了 ~~~~~~~
Demo, Review, Retrospective Meeting Agenda ( 2 )• うまくいったことは何か(チーム)
• うまくいかなかったことは何か(チーム)
• 改善点は何か(チーム)
• そのうち、次のイテレーションで何をやるか(チーム)
• やるとしたらどういったアクションになるか。また実施後どういう状態になるか(チーム)
• 今日決めたことはなにか(チーム)
~~~~~~~~ ふりかえり終了 ~~~~~~~~
• 終了:空のパーキングロット、アクションアイテム、次にやることリスト(PM)
監査対応• 監査で必要なインタビューや文書提出にどう対応するか
• 監査人と相談し、最小限の労力で彼らが必要なドキュメントを提出するようにする
• PMが可能な限り作る
• バックログに積み、POに判断を促す(実装できるFeatureは当然減る)
Quality AssuranceTraditional PM Agile PM
ープロジェクトの初期から品質要員をメンバーに加え、プロジェクトの全ての活動に意見を加える。
監査を行うイテレーションデモ、レビュー、ふ
りかえりを行う
プロセス分析を行う プロセス分析を行う
変更要求を明らかにし、修正アクションを推奨する
レビューやふりかえりで変更した方が良い点、変更のための対応アクシ
ョンを明らかにする
Thanks
‣素材: https://openclipart.org/
‣ Keynoteテンプレート: https://github.com/
sanographix/azusa-keynote