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では

• テスト ≒ 品質

• だいたい最終工程

ワークショップ• プロジェクト中で求められる品質の種類について考えます

• 開発プロジェクト中で求められる「品質」の具体例をそれぞれ１つ以上挙げてみましょう

• 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が可能な限り作る

• バックログに積み、POに判断を促す（実装できるFeatureは当然減る）

Quality AssuranceTraditional PM Agile PM

ープロジェクトの初期から品質要員をメンバーに加え、プロジェクトの全ての活動に意見を加える。

監査を行うイテレーションデモ、レビュー、ふ

りかえりを行う

プロセス分析を行う プロセス分析を行う

変更要求を明らかにし、修正アクションを推奨する

レビューやふりかえりで変更した方が良い点、変更のための対応アクシ

ョンを明らかにする

Thanks

‣素材: https://openclipart.org/

‣ Keynoteテンプレート: https://github.com/

sanographix/azusa-keynote