agile pm10 quality_2a

THE SOFTWARE PROJECT MANAGER’S BRIDGE TO AGILITY 読書会 #10 : Quality Management （後半）

AgilePM研究会和良品文之丞 Bunnojo Warashina

2014/6/17 Agile PM Reading Circle, PMI 1

会場提供: PMI日本支部様

Quality Control


p.137

すでに入り込んだ欠陥の発見に重点

発見された

欠陥の除去

Traditional

イテレーションごとに

バグのチェックが完了テスト・検証のしくみ

Agile

毎日のビルドとスモークテスト

フィーチャーのコードが、顧客の期待に合っているか

自動的なテスト：回帰テスト、単体テスト、

機能・探索的テスト、受入れテスト

Quality Control


p.138

イテレーション・バックログ

フィーチャ1

フィーチャ2

フィーチャ3

:

フィーチャn

受入基準1

受入基準2

受入基準3

:

受入基準n

ここがポイント

フィーチャごとの受入基準を定義することによって、チームメンバは作業に対する明確なビジョンを持つ

Quality Control


p.138

そのフィーチャを取り除き、

低い優先度を与える

後のイテレーションで再度取組む

イテレーションの終了時にまだ欠陥が残っているときは・・・

そのフィーチャのコードがあれば、欠陥を高い優先度にする

バックログに入れ、次のイテレーションで扱う

ささいな欠陥であれば、そのまま継続する

将来のイテレーションに向け低い優先度でバックログに入れる

フィーチャの一部が受入れ可能であれば、フィーチャがイテレーションに対して大き過ぎる

受入可の部分を分離し、受入不可の部分をより小さい単位でバック

ログに戻す

Quality Control


p.139

PMBOKガイド掲載：品質レベルをモニタリングするツール

図8-7.QC七つ道具の個々の例を概念的に示したストーリーボード（プロジェクトマネジメント知識体系ガイドPMBOKガイド第5版 p.239）

Quality Control


p.139

Agile で共通に使われる品質モニタリングツール

PMBOKガイドに掲載された品質レベルをモニタリングするツール群も、状況に応じて使うことができる

バーンダウンチャート

根本原因分析テスト自動化ツール

欠陥追跡ツール

特に新しくAgileを実施したり、欠陥のバックログを持つチームは、欠陥追跡ツールを使おうとするかも知れない。

ただし、チームはそのイテレーション内で、欠陥を見つけて修正すべきであり、欠陥が残ったとしても少しで、以降の作業のためにバックログに単に追加するだけで良い。

Quality Control


p.139

Iteration burndown chart：

どのくらいの作業が残っているのか日々確認することで、必要に応じて調整する機会となる

以前のburndown chartと違う

Q?

おさらい： Time Managementのburndown chart


p.92 Figure 6-3 This release burndown chart represents the GERT team’s progress through iterations 1 and 2 of its project.

p.103 Figure 6-6 An example of a team’s burndown chart . The project manager and the team can tell early on that the team’s velocity is not as high as originally thought. This will impact what is planned for the next iteration in the agile release plan.

p. 92 p.103

Quality Control


p.139

先にテストを書き、自動化を行う

機能に関するコードを書く

TDD: Test Driven Development （テスト駆動型開発）

testdriven.com のFAQは次の文章で始まる

・小さなテストを書きなさい

・テストを成功させるために十分なコードを書きなさい

・コードをきれいにしなさい（訳者補足：リファクタリング）・（以上を）繰り返しなさい

Quality Control Table8-3 品質コントロールに関する比較1/2


p.140

アジャイル用語において品質コントロールは、「受入れ、レビュー、振返り（レトロスペクティブ）」のことを指す

Traditional Agile

プロジェクトの終わりで、バグを見つけるためコードをテストする

各イテレーションで、バグを見つけるためコードをテストする

大量のテストを手作業で行うことが許される

（訳者補足：あらかじめ計画されたテスト工程で、テストを手作業で行える期間と工数が確保されているため）

大量のテストを手作業で行うことは許されないテストはボトルネックになる

デリバリーのスピードを高め、品質コントロールを保てるように、多くのテストを自動化する

何をテストし、何が期待されるかを知るために、文書を参照する（例：システムがどのように機能するか）

各フィーチャの何をテストし、何が期待され、何が受入基準を理解するため、品質担当が顧客や開発者と一緒に、開発チームの一部のように作業する

Quality Control Table8-3 品質コントロールに関する比較2/2


p.140

Traditional Agile

欠陥をログに記録するテスターは開発者に、バグを見つけたことと修正するためにステップのウォークスルーを提案する

（このイテレーションで解決できない）未解決の欠陥は、バックログに記録する

製品の品質をモニタするために多様なツールを使用する（PMBOKガイド、品質7つ道具）

製品の品質をモニタするためにテストをパスするための主要なツールと顧客の受入れを使用する

プロセスの品質をモニタするために、監査を含む多くのツールを使用する

プロセスの品質をモニタするために、バーンダウンチャート、メトリクス、根本原因分析の主なツールを使い、各イテレーションの終了時のレビューと振返りミーティングで、レビューを実施する

Quality Control サマリ

• 品質保証は、アジャイルソフトウェア開発において現実的なものとなる – プロジェクトの本当の初期から品質スタッフがアジャイルチームの主要なパートとなる

• 顧客とチームはプロジェクトのために品質方針と標準を定義する

• 製品における品質は自動化されたテストと顧客の受入れによる確認でモニタされ、プロセスにおける品質はメトリクスと振返りによる“監査”、レビューによって確認される

• バーンダウンチャートと根本原因分析は、アジャイルチームによって行われる標準的な品質コントロールツールである


p.141

Quality Control Table8-4 プロジェクトマネジャーの振る舞い比較1/2


p.142

Agile PM’s change list for Quality Management

今まで使ってきたもの今（以降）やること

公式的な品質マネジメント計画の策定チームを誘って品質を保障するための細目（※）を定義し、決定を非公式に記録するためにフィリップチャート、ホワイトボード、Wiki他を使う

（※自動テストツール、周期的でアクセス可能なビルド・テスト環境、トラック（追跡）のためのメトリクス、完了の定義、他）

QA監査を設定するデモ、レビュー、振返りミーティングを各イテレーションの終わりに主宰し、次のイテレーションレビューと振返りミーティングで審査するために推奨された変更に対するアクションと結果を追跡する

Quality Control Table8-4 プロジェクトマネジャーの振る舞い比較2/2


p.142

Agile PM’s change list for Quality Management

今まで使ってきたもの今（以降）やること

欠陥を追跡する；バグをFixするための活動をとりまとめ、割り当てる

各イテレーションで欠陥を発見しFixする

ために必要とされることがあれば、チームをアシストする；

前回受入れたフィーチャに対する欠陥の有無を顧客に確認する

変更制御のログを維持する顧客からの質問に答えられるようにするため、更新されたバックログを維持する

コラム：技術的負債の代償 Paying on Technical Debt 1/2


p.138

システムが正しく機能しない

既存の問題解決より新たなフィーチャの追加

技術的負債

チームの不注意

旧来の

思考習慣

旧来の手法と

同じ問題

プロジェクトの終わりでバグFix

欠陥の優先度を低く設定し、バックログから落とす

慌しく行動

長時間労働

欠陥プロダクト

納品

スクラップ

コラム：技術的負債の代償 Paying on Technical Debt 2/2


p.138

各フィーチャを完了させることができる

まで

各イテレーションのコミットを減らす

チームのベロシティに注意を払

う

予防策既存のプロダクトを出荷可能で安定した状態にする

（多くのチームが

3イテレーションで改善）

製品の品質が悪いならば

新たなフィーチャの追加を止

める

技術的負債はクレジットカード負債に似ている積み重なると、各請求のサイクルで支払っていくのが大変になる

コラム：品質コントロールにおけるトラディッショナルアプローチの影響


p.141

テスターと開発者は、互いに近くに座るべし！

極めて伝統的なソフトウェア開発環境に凝り固まったチーム

テスタ開発者

壁欠陥記述の体裁欠陥ログメールによる送付

3週間前の報告

フィーチャ完成３週間送れ

グループワーク

• Agileプロジェクトで有効なメトリクスや、品質をモニタ

リングするためのツールは、どのようなものが良いと思いますか？


pp.112-113

Agile プロジェクト品質メトリクス

Agile プロジェクト品質モニタリングツール

THE SOFTWARE PROJECT MANAGER’S BRIDGE TO AGILITY 読書会 #10 : Quality Management （後半）

Thank you


agile pm10 quality_2a

Documents