Más contenido relacionado La actualidad más candente (20) Similar a アジャイル開発とメトリクス (20) Más de Rakuten Group, Inc. (20) アジャイル開発とメトリクス27. 27
繰り返し開発としてのアジャイル :アジャイル開発の特徴
分析
設計
実装
テスト
ウォーターフォール アジャイル リーン/DevOps
要求(スコープ)
時間
要求(スコープ)
時間
要求(スコープ)
時間
・スコープ全体に対し、
分析・設計・実装・テストを
順番に実施
・動くソフトウェアに対し
プロジェクトの最後に
フィードバック
・分割されたスコープに対し、
分析からテストまでを実施。
これを繰り返す
・動くソフトウェアに対し
イテレーションごとに
フィードバック
・入力されたスコープに対し順次、
分析からテストまでを
繰り返し実施していく
・動くソフトウェアに対する
継続したフィードバック
28. 28
繰り返し開発としてのアジャイル :アジャイル開発の特徴
分析
設計
実装
テスト
ウォーターフォール アジャイル リーン/DevOps
要求(スコープ)
時間
要求(スコープ)
時間
要求(スコープ)
時間
・スコープ全体に対し、
分析・設計・実装・テストを
順番に実施
・動くソフトウェアに対し
プロジェクトの最後に
フィードバック
・分割されたスコープに対し、
分析からテストまでを実施。
これを繰り返す
・動くソフトウェアに対し
イテレーションごとに
フィードバック
・入力されたスコープに対し順次、
分析からテストまでを
繰り返し実施していく
・動くソフトウェアに対する
継続したフィードバック
55. 55
アジャイルでの テスト事例:
・ [1]誉田直美 :”アジャイルと品質会計 –プロジェクトの構成効率を
確保するハイブリッドアジャイルへの取り組み-”,
情報処理学会デジタルプラクティス、Vol.7、No.3、218-225 (2016)
・課題:(経験不足や企業文化など)
品質確保への不安、日本における高い品質要求
・解決手法:品質会計とのハイブリッド
・品質会計の品質確保の考え方の特徴
-レビューでのバグ摘出による早期品質確保
-確実なテスト完了判断
-品質会計を軸とした全体的な仕組みの構築
57. 57
アジャイルでの テスト事例 :楽天
・ [2]荻野恒太郎:”継続的システムテストについての理解を深めるため
の開発とバグのメトリクスの分析”,SQiP 2014、 (2014)
・課題:(システムテスト自動化後)
どの程度のレベルのシステムテストが自動化されているか?
・解決手法:IPA提供の業界水準のテスト密度とバグ密度との比較
65. 65
アジャイルのメトリクス:一覧 参考文献
・[3]誉田直美ら:アジャイル品質保証の動向, SQuBOK Review 2016, Vol.1, pp.1-10 (2016. 09)
・[4]伊藤宏幸:アジャイルメトリクス実践ガイド, https://www2.slideshare.net/ssuser968fab/ss-70489058
(2021/01/01 アクセス), (2017)
・[5]kz_suzuki:アジャイル開発におけるメトリクスには、どういうものがあるのか,
https://www.kzsuzuki.com/entry/agileMetrix (2021/01/01 アクセス), (2018)
・[6]松田元輝ら:アジャイルプラクティスを導入した開発における品質メトリクスの提案, SQiP 2019, A4-2,
(2018)
・[7]内藤史郎ら:QC七つ道具を利用したDevOpsプラクティスの導入による開発とテストの生産性改善, SQiP
2019, C1-1, (2019)
・[8]坂田 晶紀:アジャイル開発の品質管理技法,
https://www.fujitsu.com/jp/group/fst/about/resources/featurestories/about-agile-05.html (2021/01/01 アクセス),
(2020)
・[9]Altexsoft: Agile Software Development Metrics and KPIs that Help Optimize Product Delivery
https://www.altexsoft.com/blog/business/agile-software-development-metrics-and-kpis-that-help-optimize-
product-delivery/ (2021/01/01 アクセス)、(2017)
67. 67
アジャイルのメトリクス:一覧
アジャイル独自 ウォーターフォールと共通
サイズ フィーチャー
ストーリー
(FP. UCP)
品質 欠陥数/ (リリースまたはスプリント)
テスト密度
バグ密度
コードカバレッジ
コードの複雑度
コードチャーン
DDP(欠陥検出率)
テスト実行成功率
MTTD (平均欠陥発生時間)
MTTR (平均欠陥修復時間)
進捗 バーンダウンチャート テスト進捗率
工数 ストーリーポイント (人月)
生産性 ベロシティ(ストーリーポイント/スプリント)
サイクルタイム
リードタイム
待ち時間
前倒し率
(人月/FP…)
バグ修正時間
品質関連のメトリクスは
ウォーターフォールと共通のものが多い
生産性に関するメトリクスは
リーンの影響を受けた
アジャイル独自のものが多い
71. 71
アジャイルのメトリクス:一覧
アジャイル独自 ウォーターフォールと共通
サイズ フィーチャー
ストーリー
(FP. UCP)
品質 欠陥数/ (リリースまたはスプリント)
テスト密度
バグ密度
コードカバレッジ
コードの複雑度
コードチャーン
DDP(欠陥検出率)
テスト実行成功率
MTTD (平均欠陥発生時間)
MTTR (平均欠陥修復時間)
進捗 バーンダウンチャート テスト進捗率
工数 ストーリーポイント (人月)
生産性 ベロシティ(ストーリーポイント/スプリント)
サイクルタイム
リードタイム
待ち時間
前倒し率
(人月/FP…)
バグ修正時間
品質関連のメトリクスは
ウォーターフォールと共通のものが多い
生産性に関するメトリクスは
リーンの影響を受けた
アジャイル独自のものが多い
74. 74
アジャイルのメトリクス:一覧
アジャイル独自 ウォーターフォールと共通
サイズ フィーチャー
ストーリー
(FP. UCP)
品質 欠陥数/ (リリースまたはスプリント)
テスト密度
バグ密度
コードカバレッジ
コードの複雑度
コードチャーン
DDP(欠陥検出率)
テストの成功率
MTTD (平均欠陥発生時間)
MTTR (平均欠陥修復時間)
進捗 バーンダウンチャート テスト進捗率
工数 ストーリーポイント (人月)
生産性 ベロシティ(ストーリーポイント/スプリント)
サイクルタイム
リードタイム
待ち時間
前倒し率
(人月/FP…)
バグ修正時間
品質関連のメトリクスは
ウォーターフォールと共通のものが多い
生産性に関するメトリクスは
リーンの影響を受けた
アジャイル独自のものが多い
96. 96
テストプロセスの分析:①バリューストリームマッピング
バリューストリームマッピングで探す無駄のリスト
無駄の種類 マーク 定義 例
欠陥の無駄(Defects) D 誤った,抜けのある,不透明な情報や成果物。システム
を破壊し,解決するのに時間と労力が必要
壊れたビルド,不正確な設定,不正確
な要求
マニュアル/モーション
(Manual/Motion,Handoffs)
M オーバーヘッド,コーディネーション,作業引き渡し,
またはセットアップや仕事の実行に関する非効率性
ミーティング,手動デプロイ,チーム
間の作業引き渡し
待ちの無駄(Waiting) W 次の価値のあるステップを開始,または終了することの
遅れ
承認待ち,リソースの待ち,予定され
たミーティング待ち
未完了の作業(Partially Done) PD 未完了の作業,何らかの操作。他者からの入力やアク
ションが必要となる。欠陥とタスク切り替え,待ちを招
く
デプロイされていないコード,不完全
な環境設定,実行中バッチ
タスクの切り替え(Task Switching) TS タスクの切り替えは,高価なコンテキストスイッチを招
き,エラーが発生しやすくなる
進捗上限による無駄作業,障害による
中断,アドホックなリクエスト
余分なプロセス(Extra Process) EP 価値のないステップやプロセス。たいていは,公式,非
公式な標準作業に含まれる
不要な承認,不要なドキュメント,無
駄なレビュー
余分な機能(Extra Feature) EF 機能,たいていは実装フェーズで追加されたもの。リク
エストされていない,ビジネスに沿っていない,顧客価
値がない
“次に必要かもしれない”,不要なアッ
プデートや要求,望んでいない
ヒーローまたはヒロイン(Heroics) H 仕事を完了させる,または顧客を満足させるために,あ
る人に大変な負荷がかかっている状態。ボトルネック
数日必要なデプロイ,長年の知識が必
要,極端な調整が必要
98. 98
テストプロセスの分析:② 七つ道具
安達賢二ら:日本におけるソフトウェアプロセス改善の歴史的意義と今後の展開、
SQuBOK Review 2016, Vol.1, pp.11-24 (2016)
・1971-1990頃、主であったTQCの枠組みの中での改善活動で利用された
・1990年ごろから、モデルベースのプロセス改善が主流に
SQuBOK GUIDE V2
“品質管理において、数値データを整理・解析し、現象を定量的に分析するために
用いる基本的で重要な七つの技法の総称である”
・特性要因図
・パレート図
・チェックシート
・ヒストグラム
・散布図
・管理図
・グラフ
・層別
・親和図法
・連関図法
・系統図法
・マトリクス図法
・アロー・ダイアグラム法
・PDPC法
・マトリクス・データ解析法
109. 109
テストプロセスのソフトウェア化:テスト自動実行ソフトウェアの品質特性
品質特性 説明 メトリクス
ユーザビリティ プロジェクト関係者なら誰でも、知識やスキルなどに関
係なく自動テストを実行できること
またはテストレポートの内容を誰でも理解できること
• テスト実行メンバー数
• テスト結果アクセスメン
バー数
効率性 テスト実行が求められる時間内に完了すること • テスト実行時間
信頼性 テスト結果が信頼できること
Frakyテストの影響が除外できていること
• テスト実行成功率
並行性 複数のテストシナリオを並行して実行できること • テスト実行時間
• 並行実行テストジョブ数
再現性 何度再実行しても、同じテスト結果が再現できること • テスト結果再現率
エラー追跡性 テストが失敗した場合に、その原因がプロダクト、環境
またはテストのどれか簡単に切り分けられること
• テスト失敗調査時間
*ここではテスト実行の動的な品質特性のみを挙げているが、もちろん静的なテストカバレッジも重要
110. 110
テストプロセスのソフトウェア化:テスト自動実行ソフトウェアの品質特性
品質特性 説明 メトリクス
ユーザビリティ プロジェクト関係者なら誰でも、知識やスキルなどに関
係なく自動テストを実行できること
またはテストレポートの内容を誰でも理解できること
• テスト実行メンバー数
• テスト結果アクセスメン
バー数
効率性 テスト実行が求められる時間内に完了すること • テスト実行時間
信頼性 テスト結果が信頼できること
Frakyテストの影響が除外できていること
• テスト実行成功率
並行性 複数のテストシナリオを並行して実行できること • テスト実行時間
• 並行実行テストジョブ数
再現性 何度再実行しても、同じテスト結果が再現できること • テスト結果再現率
エラー追跡性 テストが失敗した場合に、その原因がプロダクト、環境
またはテストのどれか簡単に切り分けられること
• テスト失敗調査時間
*ここではテスト実行の動的な品質特性のみを挙げているが、もちろん静的なテストカバレッジも重要
”テストの生産性”の文脈ではユーザービリティと効率性が重要
しかし、効率性には「信頼性」「並行性」「再現性」「エラー追跡性」を含む
「信頼性」が大きく影響
142. 142
シフト・ライトテスト: テスト
バージョン A バージョン B
50% 50%
アプリケーションの
バージョンによる違い
・UIのデザイン
(色、ボタンの大きさなどなど)
・レコメンデーションのアルゴリズム
効果を測定
CVR (Conversion Ratio)
-購買率
-登録率
-ログイン率
-再生率
-いいね率
・複数のバージョンのアプリケーションを
本番環境にデプロイし、
ビジネスへの効果を測定し比較
・継続して行うことで、
サイトのデザインやアルゴリズムを
最適化していく
・バンディットアルゴリズム
-振り分けの割合を自動で最適化
-悪いバージョンに振り分けることに
よる機会損失を最小化
メトリクス
143. 143
シフト・ライトテスト: テスト
バージョン A バージョン B
50% 50%
アプリケーションの
バージョンによる違い
・UIのデザイン
(色、ボタンの大きさなどなど)
・レコメンデーションのアルゴリズム
効果を測定
CVR (Conversion Ratio)
-購買率
-登録率
-ログイン率
-再生率
-いいね率
・複数のバージョンのアプリケーションを
本番環境にデプロイし、
ビジネスへの効果を測定し比較
・継続して行うことで、
サイトのデザインやアルゴリズムを
最適化していく
・バンディットアルゴリズム
-振り分けの割合を自動で最適化
-悪いバージョンに振り分けることに
よる機会損失を最小化
メトリクス
→新機能についてフィードバック
148. 148
シフト・ライトテスト:モニタリング
John Allspawら:10 deploys per day Dev & Ops coorporations at Flickr 、
https://www2.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr (2021/01/01
アクセス)、Velocity 2009、(2009)
DevがOpsに
・変更がもたらす影響を
メトリクスを使って説明する
・期待しない問題発生を示す
サインは何か?
・問題が発生した際のリスクは?
代替手段は?
リリース後に
OpsからDevにフィードバック
・変更がもたらした実際の
メトリクスの変化はどうだったか?
・想定されていないメトリクスの変化は
起きていないか?
158. 158
シフト・ライトテスト:カナリアリリース
・カナリアリリース導入のポイント
→モニタリングするメトリクスと期待される結果を事前に準備する
テスト: テスト入力 → システム → 出力 = 期待される結果
カナリアリリース カナリア率 → システム → 出力 = 期待される結果
Time Ratio カナリア環境への
アクセス数
リクエスト
成功率
遅延件数 CPU
使用率
Latency
(99 pecentile)
1日目 0.01% 1 rps 90% 1件未満 5% 未満 1000ms
10日目 0.1% 10 rps 90% 1件未満 5% 未満 1000ms
20日目 1.0% 100 rps 90% 1件未満 5% 未満 1000ms
30日目 10.0% 1000 rps 90% 1件未満 5% 未満 1000ms
60日目 100.0% 10000 rps 90% 10件未満 50%未満 1000ms
期待される結果