アジャイル開発と品質保証の密なる関係 #quesqa

アジャイル開発と品質保証の密なる関係
アジャイルチームに寄り添う品質保証部門の考え方
2015/5/14第6回 Ques 「アジャイルと品質」 copyright © A.Nagata1
www.vandalsrugby.ca

自己紹介
 ソニー株式会社永田敦
ソフトウェアテストプロセス改善
SQiP研究会第七分科会副主査
派生開発推進委員会運営委員
第6回 Ques 「アジャイルと品質」 copyright © A.Nagata
2
2015/5/14

品質を良くすることができなければ
アジャイル開発は成功しない

目次
 アジャイル開発の実態
 貢献駆動開発
 アジャイル開発における改善

課題
今度
アジャイルで
開発していくから

課題
今度アジャイルで開発していくから
といわれ
• プロセスはどうなるのか
• 評価はどうするのか
• 品質保証はどうするのか？

アジャイル開発の実態
QAから見たアジャイル開発

8
プロセスとしてのAgile
 短いサイクルで、分析、設計、実装、テストを
並列に行う
 タイムボックス型、進化型開発
分析
設計
実装
テスト
時間時間
要求(スコープ) 要求(スコープ)Waterfall Agile
Beck 2000Royce 1970
ソフトウェア工学の分岐点における、アジャイルの役割、平鍋健児、SS2010

アジャイル開発のプロセス
Agile Testing, Lisa Crispin, Janet Gregory, 2009

スクラム
イテレーションイテレーションイテレーション
プロダクトバックログ
スプリント
バックログ
システムテスト
出荷

バックログインフレーション 1
イテレーションイテレーションイテレーション
スプリント
バックログ
システムテスト
出荷
予定
終わらない

アジャイル？ウォータフォール？
スプリント
バックログ
実施
出荷予定
システム
テスト
テスト分析/設計
バグ
デバッグ
13
実施実施
2015/5/14第6回 Ques 「アジャイルと品質」 copyright © A.Nagata

早期からのシステムテストの実施
イテレーションイテレーションイテレーションイテレーション
スプリント
バックログ
イテレーションイテレーションイテレーションイテレーションシステム
テスト
実施テスト分析/設計実施実施

もっと早いタイミングで
評価しよう
設計フェーズに飛び込む

どのように入ったらよいか
どのようにやっていったらよいか

QAが設計に入ってくる
いろいろ言われるのではないか
あれを出せこれを出せ
あれを測れこれを測れ
あれを直せこれを直せ
設計に余計な負荷がかかる
設計リーダーの憂鬱
固い
ガード
QA

貢献駆動開発
Contribution Driven Development

チームの形成
設計 QA
品質の
見える化
 テスト
o 動的
o 静的
 測定
 フィードバック
サポート
QAはチームとして働く
設計を邪魔しない恐れを取り除く
設計に気づいてもらう
マインドセット

テストスプリントバックログ
スプリント
バックログ
システム
テスト
テストスプリント
バックログ

でも，テストベースは
はどうするの？

理想のアジャイル
設計 QA
品質の
見える化
 テスト
 測定
フィードバック
 Deploy 評価環境
共有
リスク
課題
アクション
信頼関係
テストベース

現実
設計 QA
品質の
見える化
 テスト
 測定
フィードバック
信頼関係
テストベース

暗黙知
24
暗黙知

暗黙知によるコミュニケーション
25
暗黙知

設計のための情報をチームで共有している
26
暗黙知
形式知

どのようにして評価に必要な情報を
得ることができるのだろうか

ユーザストーリと要求の関係
Agile Testing, Lisa Crispin, Janet Gregory, 2009
アジャイルテスティングにおける
テストベースについて

アジャイル開発の要求プロセス: 要求を制覇せよ
ユーザーストーリで、要求と仕様を表現できるか？
形式的な情報形態
暗黙的な情報形態
情報の伝達、変更、トレーサビリティ、記録
バランス合意
中規模、大規模のシステムのアジャイル開発

想定外の暗黙知の齟齬
30
暗黙知

ポリシーが暗黙知の齟齬を抑える
31
暗黙知
ドメイン知識

QAもチームとして情報を共有する
32
暗黙知
形式知
ポリシー
ドキュメント

フィードバック獲得の設計
三菱電機細谷泰夫：斥候としてのアジャイルプロセス活用の提案：SPI Japan 2012

フィードバックを設計，成立させるためには
何をフィードバックするのかを説明する
そのフィードバックするためにどんな情報や
成果物が必要かを説明する
相手が合意すれば
相手はその情報，成果物を時間を割いて
用意してくれるはずである

チームの形成
設計 QA
品質の
見える化
 テスト
 測定
サポート
暗黙的共有
リスク
課題
アクション
信頼関係
合意された形式的情報

テストケースをバックログとして
ツールに入れて管理してしまう
設計者が，何をどのようにテストするかわかる
設計者が，気を付けて設計をする
設計者に，テストケースをレビューしてもらう
設計とテストの一元管理

テスト
 システムテスト：できるところを計画してテストする
 テストに対する計画と戦略が意識される
 インシデントレポートを，バックログとして登録する
 インシデントレポート専用のバックログとプロセスをQA
が提案
 バグの処理も，結局設計が行わなければならない．
 原則は，不具合が起ったらすぐに設計に見てもらう
 再現待ちを減らす
 説明も Face to Faceでやる

バックログインフレーション
スプリント
バックログ
システム
テスト
バグリポート
確認テスト
テストスプリント
バックログ
終わらない
38

アジャイル開発のメトリクス
測定のサポート

測定
 ツールからとれるものでQAが測定する
 目的：設計へのフィードバック
 バックログ情報
 プロダクトバックログ
 スプリントバックログ
 テストスプリントバックログ
 インシデントバックログ
 KPI
 Velocity
 バグ情報
 発生度数
 残件度数
 ランク度数

メトリクス
バーンアップチャート

メトリクスを生かせ、振り回されるな
外挿の魅力と罠
あくまでも目安
うまく心理的に使う
一喜一憂
よいプレッシャー

メトリクス
Velocity 2.2倍の改善

どうしたらVelocityをあげられるだろう
x = vt
x + xw = v(t – tw)
Xw ：手戻り：バグ : 確認テスト : 無駄
tw ：時間の無駄：コミュニケーションロス：待ち
v =
𝑥𝑥
𝑡𝑡

メトリクス
バーンアップチャート１か月の遅れを改善し
オンタイム

バグの特性：計画を持ってやれるところからテスト
インシデント登録度数

計画的にやれ：ブロック承知のテスト
アジャイルほど計画が効く
やってみて計画との違いを修正
テスト計画：品質計画の重要性
メトリクスの解釈
計画の変更を繰り返す

バグの特性：フィードバックでコントロール
Activeなバグ数

出荷判定基準の見直し
いつ
何を対象にして、
どのようなテスト目的で、
どのようなテストタイプで、
どのようなテスト条件でテストするか
信頼性成長曲線は通用しなくなる
出荷判定基準の見直し
でどの性質のどんなバグがどのくらい出るか

振り返り：QAがファシリテーションしよう
 メトリクスの吟味
 緊張感１か月の遅れ
 このままでは間に合わない
 効率を上げるといっても，品質は落とせない
 手を抜けば，インシデントバックログが増える
 自ら課題を洗い出す
 わからないことを人に聞いていない．
 ３分間ルール
 仕様における意思疎通ができていない．
 仕様説明会
 実装よりも設計のパワーが不足してVelocityが出ない
 チーム編成替え

３分悩んだら聞くべし
聞かれた人もまずは受け入れる！！

変化
 設計側で内部品質を高める行動が出てきた
 ユニットテストの拡大
 静的テストの積極的活用
 内部のコミュニケーションの改善
 ツールの自作
 QAにテストの要求をする
 コードレビュー
 RCAに飛びつく
 QAからのフィードバックに迅速に反応
 QAに，設計のところまで来てテストしてもらう
 テストの出前
 信頼関係の確立

アジャイル開発における改善
Agile RCA

毎週改善、毎日改善
アジャイルは、見える化の手法
積極的に品質を見える化することをサポートして
その情報を使って改善する：QAが使っていく
見える化
課題抽出
問題解決
カンバン
バーンダウン
インシデント
朝会
振り返り

成果
 Velocityの改善と安定
 施策の効果がメトリクスに現れる
 例：7 イテレーションで移動平均値が2.2倍となる
 バグ傾向のフィードバック
 例：GUIの境界値バグがなくなる
 ランクの高いバグから減らそうとする
 RCAによるフィードバック
 インシデントバックログを増やさない
 スケジュールの改善：見える化による修正
 例：最大１か月遅れをオンタイムにすることに寄与した
フィードバック，振り返りの重要性の認識

QAにとってのアジャイル
 設計フェーズで
 設計と共有情報を持つことができ，
 イテレーションごとにメトリクスがわかり，
 振り返りで課題がわかり
 課題分析ができ
 チームの改善のきっかけを得られる
QAにとって，アジャイル開発は良いことが多い
やるべきこと：
アジャイル開発を正しく理解し，チームの一員として活動すること

アジャイルにおけるQA
アジャイル開発において
ＱＡはなくてはならない
チームのメンバーである

ご清聴ありがとうございます

アジャイル開発と品質保証の密なる関係 #quesqa

More Related Content

What's hot

Viewers also liked

Similar to アジャイル開発と品質保証の密なる関係 #quesqa

Recently uploaded

アジャイル開発と品質保証の密なる関係 #quesqa