アジャイル開発とメトリクス

アジャイル開発とメトリクス
アジャイル開発とメトリクス Jan 08, 2021 荻野恒太郎 Membership Service Section Ecosystem Services Department Rakuten, Inc.
2 本日お持ち帰りいただきたいこと
3 本日お持ち帰りいただきたいこと背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめ
5 本日お持ち帰りいただきたいこと背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめアジャイル開発の歴史と特徴 QAテストのメトリクス生産性改善のメトリクスメトリクスによるフィードバック
9 アジャイル開発の発展の歴史
10 アジャイル開発の発展の歴史トヨタ生産方式（TPS） TQC QC活動ソフトウェアオブジェクトパターンスクラムリーン XP 継続的デリバリー DevOps パイプライン自動化受け入れテスト自動化クラウド IaC 自動化アジャイル
11 アジャイル開発の発展の歴史トヨタ生産方式（TPS） TQC QC活動ソフトウェアオブジェクトパターンスクラムリーン XP 継続的デリバリー DevOps パイプライン自動化受け入れテスト自動化クラウド IaC 自動化アジャイル
12 アジャイル開発の発展の歴史継続的デリバリー DevOps パイプライン自動化受け入れテスト自動化クラウド IaC 自動化トヨタ生産方式（TPS） TQC QC活動ソフトウェアオブジェクトパターンスクラムリーン XP アジャイル・1990年代にスクラム、XPなどの手法が生まれる・アジャイル開発宣言（2001年）・2000年代日本でも普及
13 アジャイル開発の発展の歴史継続的デリバリー DevOps パイプライン自動化受け入れテスト自動化クラウド IaC トヨタ生産方式（TPS） TQC QC活動ソフトウェアオブジェクトパターンスクラムリーン XP アジャイル自動化・テストや運用作業を自動化
14 アジャイル開発の発展の歴史 DevOps クラウド IaC トヨタ生産方式（TPS） TQC QC活動ソフトウェアオブジェクトパターンスクラムリーン XP アジャイル自動化継続的デリバリーパイプライン自動化受け入れテスト自動化・テストや運用作業を自動化 - 継続的デリバリー
15 アジャイル開発の発展の歴史トヨタ生産方式（TPS） TQC QC活動ソフトウェアオブジェクトパターンスクラムリーン XP アジャイル自動化継続的デリバリーパイプライン自動化受け入れテスト自動化 DevOps クラウド IaC ・テストや運用作業を自動化 - 継続的デリバリー - DevOps
16 アジャイル開発の発展の歴史トヨタ生産方式（TPS） TQC QC活動ソフトウェアオブジェクトパターンスクラムリーン XP アジャイル自動化継続的デリバリーパイプライン自動化受け入れテスト自動化 DevOps クラウド IaC
17 アジャイル開発の発展の歴史：手法の特徴トヨタ生産方式（TPS） TQC QC活動ソフトウェアオブジェクトパターンスクラムリーン XP アジャイル自動化継続的デリバリーパイプライン自動化受け入れテスト自動化 DevOps クラウド IaC 繰り返しプロセスを管理する手法プロセスを自動化する手法
18 アジャイル開発の発展の歴史：手法の特徴スクラムリーン XP パイプライン自動化受け入れテスト自動化クラウド IaC 繰り返しプロセスを管理する手法プロセスを自動化する手法
20 繰り返し開発としてのアジャイル
21 繰り返し開発としてのアジャイル分析設計実装テストウォーターフォールアジャイルリーン/DevOps 要求（スコープ）時間要求（スコープ）時間要求（スコープ）時間
22 繰り返し開発としてのアジャイル分析設計実装テストウォーターフォールアジャイルリーン/DevOps 要求（スコープ）時間要求（スコープ）時間要求（スコープ）時間・スコープ全体に対し、分析・設計・実装・テストを順番に実施・・分割されたスコープに対し、分析からテストまでを実施。これを繰り返す・・入力されたスコープに対し順次、分析からテストまでを繰り返し実施していく・
23 繰り返し開発としてのアジャイル分析設計実装テストウォーターフォールアジャイルリーン/DevOps 要求（スコープ）時間要求（スコープ）時間要求（スコープ）時間・スコープ全体に対し、分析・設計・実装・テストを順番に実施・動くソフトウェアに対しプロジェクトの最後にフィードバック・分割されたスコープに対し、分析からテストまでを実施。これを繰り返す・動くソフトウェアに対しイテレーションごとにフィードバック・入力されたスコープに対し順次、分析からテストまでを繰り返し実施していく・動くソフトウェアに対する継続したフィードバック
24 おまけ：テストのスコープについて
25 おまけ：テストのスコープについて分析設計実装テストウォーターフォールアジャイルリーン/DevOps 要求（スコープ）時間要求（スコープ）時間要求（スコープ）時間・（開発とテストが並行していることの便宜的な表現）・テストは過去の要求も当然スコープに入る →イテレーションごとにスコープが増えていくことがアジャイル開発のテストを難しくしている
26 繰り返し開発としてのアジャイル：アジャイル開発の特徴
27 繰り返し開発としてのアジャイル：アジャイル開発の特徴分析設計実装テストウォーターフォールアジャイルリーン/DevOps 要求（スコープ）時間要求（スコープ）時間要求（スコープ）時間・スコープ全体に対し、分析・設計・実装・テストを順番に実施・動くソフトウェアに対しプロジェクトの最後にフィードバック・分割されたスコープに対し、分析からテストまでを実施。これを繰り返す・動くソフトウェアに対しイテレーションごとにフィードバック・入力されたスコープに対し順次、分析からテストまでを繰り返し実施していく・動くソフトウェアに対する継続したフィードバック
28 繰り返し開発としてのアジャイル：アジャイル開発の特徴分析設計実装テストウォーターフォールアジャイルリーン/DevOps 要求（スコープ）時間要求（スコープ）時間要求（スコープ）時間・スコープ全体に対し、分析・設計・実装・テストを順番に実施・動くソフトウェアに対しプロジェクトの最後にフィードバック・分割されたスコープに対し、分析からテストまでを実施。これを繰り返す・動くソフトウェアに対しイテレーションごとにフィードバック・入力されたスコープに対し順次、分析からテストまでを繰り返し実施していく・動くソフトウェアに対する継続したフィードバック
29 繰り返し開発としてのアジャイル：アジャイル開発の特徴 ① 分割されたスコープ ② 短い開発サイクルの繰り返し ③ フィードバックループにもとづいた改善活動アジャイル要求（スコープ）時間
30 繰り返し開発としてのアジャイル：アジャイル開発の特徴 ① 分割されたスコープ ② 短い開発サイクルの繰り返し ③ フィードバックループにもとづいた改善活動アジャイル要求（スコープ）時間・設計からリリースまでを継続的に繰り返す・継続的にソースコード変更・継続的にテストを実行・継続的にバグ修正・継続的にリリース
32 メトリクスから見たアジャイル ① 分割されたスコープ ② 短い開発サイクルの繰り返し ③ フィードバックループにもとづいた改善活動アジャイル要求（スコープ）時間・設計からリリースまでを継続的に繰り返す・継続的にソースコード変更・継続的にテストを実行・継続的にバグ修正・継続的にリリース →実際のプロジェクトのメトリクス
33 メトリクスから見るアジャイル開発：ソースコード変更とテストの継続的な実施① 0 5000 10000 15000 20000 25000 0 5 10 15 20 25 30 35 Commit Commit size 0 50 100 150 200 ０〜４５〜９１０〜１４１５〜１９２０〜２４２５〜２９３０〜３４一日のコミット数コミット数とコミットサイズ日次のコミット数の分布１日で見つかった検出バグ数 0 50 100 150 200 250 0 1 2 3 4 5 日次の検出バグ数の分布変更 LOC 追加 LOC 削除 LOC 0 1000 2000 0 1000 2000 0 1000 2000 LOC 時間時間コミット数コミットサイズ行数頻度頻度
34 メトリクスから見るアジャイル開発：ソースコード変更とテストの継続的な実施② 大きな機能要件システムリファクタリング断続的な小さな要件受け入れテスト受け入れテスト 0 200 400 600 800 1000 1200 1400 0 10 20 30 40 50 60 70 80 90 累積検出バグ数累積コミット数 A B C 開発フェーズ検出バグ数コミット数 99日間 100日間 84日間毎日少しずつソースコーを変更しテスト結果をフィードバックしている
35 メトリクスから見るアジャイル開発：毎日バグ修正 0 2 4 6 8 10 UT/CT ST 0 2 4 6 8 10 UT/CT ST 前 Q3 Q1 中央値 Q3 Q1 中央値 Q3 Q1 中央値 Q3 Q1 中央値最大値 59 最大値 64 最大値 75 最大値 87 ST 後 (10572*） (11453*） *テストメソッド数 (日数) (日数) バグ修正日数バグが検出されてから次の日までに半分程度のバグのバグ修正と確認テストが終了している
36 メトリクスから見たアジャイル ① 分割されたスコープ ② 短い開発サイクルの繰り返し ③ フィードバックループにもとづいた改善活動アジャイル要求（スコープ）時間・設計からリリースまでを継続的に繰り返す・継続的にソースコード変更・継続的にテストを実行・継続的にバグ修正・継続的にリリース →実際のプロジェクトのメトリクス
38 アジャイル開発の品質保証の特徴
39 アジャイル開発の品質保証の特徴特徴①： QAテストとメトリクス特徴②:素早いテストと開発サイクル特徴③：継続的なフィードバック ① QAテストとメトリクス ③ 継続的なフィードバック ② 素早いテストと開発サイクル
46 本日お持ち帰りいただきたいこと背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめアジャイルはプロセスを繰り返す
49 特徴テストとメトリクス
50 特徴テストとメトリクス特徴①： QAテストとメトリクス特徴②:素早いテストと開発サイクル特徴③：継続的なフィードバック
51 特徴テストとメトリクス特徴②:素早いテストと開発サイクル特徴③：継続的なフィードバック・QAテストがアジャイルでも重要な理由・アジャイルでのQAテスト事例・アジャイルのメトリクス特徴①： QAテストとメトリクス
52 テストがアジャイルでも重要な理由
53 テストがアジャイルでも重要な理由要求（スコープ）時間 ✖️ アジャイルではテストや出荷判定をしない（誤解） ○ アジャイルでは -製品出荷の頻度が多い -テストのスコープが広がっていく → きちんとテストを実施しないと不具合流出のリスクが高い
55 アジャイルでのテスト事例：・ [1]誉田直美：”アジャイルと品質会計 –プロジェクトの構成効率を確保するハイブリッドアジャイルへの取り組み-”, 情報処理学会デジタルプラクティス、Vol.7、No.3、218-225 (2016) ・課題：（経験不足や企業文化など）品質確保への不安、日本における高い品質要求・解決手法：品質会計とのハイブリッド・品質会計の品質確保の考え方の特徴 -レビューでのバグ摘出による早期品質確保 -確実なテスト完了判断 -品質会計を軸とした全体的な仕組みの構築
56 アジャイルでのテスト事例：・的確なテスト完了判断・スプリント完了基準・的確なテスト完了判断・結果 -生産性が改善、特に設計・製造工程で -出荷後バグはなし・考察 -数値より中身の確認 -デグレードが品質リスク
57 アジャイルでのテスト事例：楽天・ [2]荻野恒太郎：”継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析”,SQiP 2014、 (2014) ・課題：（システムテスト自動化後）どの程度のレベルのシステムテストが自動化されているか？・解決手法：IPA提供の業界水準のテスト密度とバグ密度との比較
58 アジャイルでのテスト事例：楽天
61 テストがアジャイルでも重要な理由要求（スコープ）時間 ✖️ アジャイルではテストや出荷判定をしない（誤解） ○ アジャイルでは -製品出荷の頻度が多い -テストのスコープが広がっていく → きちんとテストを実施しないと不具合流出のリスクが高い
62 テストがアジャイルでも重要な理由要求（スコープ）時間 ✖️ アジャイルではテストや出荷判定をしない（誤解） ○ アジャイルでは -製品出荷の頻度が多い -テストのスコープが広がっていく → きちんとテストを実施しないと不具合流出のリスクが高い →・きちんとQAテストを実施すれば、安心して次のプロセスの繰り返しに入れる・手戻りを防ぐことでプロセスの繰り返しを安定化させることができる
64 アジャイルのメトリクス
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)
66 アジャイルのメトリクス：一覧アジャイル独自ウォーターフォールと共通サイズフィーチャーストーリー（FP. UCP）品質欠陥数/ (リリースまたはスプリント) テスト密度バグ密度コードカバレッジコードの複雑度コードチャーン DDP（欠陥検出率）テスト実行成功率 MTTD (平均欠陥発生時間) MTTR (平均欠陥修復時間) 進捗バーンダウンチャートテスト進捗率工数ストーリーポイント（人月）生産性ベロシティ（ストーリーポイント/スプリント）サイクルタイムリードタイム待ち時間前倒し率（人月/FP…）バグ修正時間
67 アジャイルのメトリクス：一覧アジャイル独自ウォーターフォールと共通サイズフィーチャーストーリー（FP. UCP）品質欠陥数/ (リリースまたはスプリント) テスト密度バグ密度コードカバレッジコードの複雑度コードチャーン DDP（欠陥検出率）テスト実行成功率 MTTD (平均欠陥発生時間) MTTR (平均欠陥修復時間) 進捗バーンダウンチャートテスト進捗率工数ストーリーポイント（人月）生産性ベロシティ（ストーリーポイント/スプリント）サイクルタイムリードタイム待ち時間前倒し率（人月/FP…）バグ修正時間品質関連のメトリクスはウォーターフォールと共通のものが多い生産性に関するメトリクスはリーンの影響を受けたアジャイル独自のものが多い
68 アジャイルのメトリクス：アジャイル独自のメトリクス①ベロシティとバーンダーンチャート [9]よりベロシティ：１スプリントで実装する/した機能のストーリーポイントスプリントバーンダウンチャート：スプリント内での残りのストーリーポイント
69 アジャイルのメトリクス：アジャイル独自のメトリクス②リードタイム [8]よりチケットが作成されてから完了するまでの時間などバリューストリームマップで、アイデアが生まれてから価値を提供するまでの時間 →アジャイルでは生産性を測る指標としてよく使われる
70 アジャイルのメトリクス：アジャイル独自のメトリクス③ [6]より・プロジェクト終了に対してどれだけ前倒してバグを摘出したかの指標・前倒し率が高いと市場不具合のあるなしに有意差
71 アジャイルのメトリクス：一覧アジャイル独自ウォーターフォールと共通サイズフィーチャーストーリー（FP. UCP）品質欠陥数/ (リリースまたはスプリント) テスト密度バグ密度コードカバレッジコードの複雑度コードチャーン DDP（欠陥検出率）テスト実行成功率 MTTD (平均欠陥発生時間) MTTR (平均欠陥修復時間) 進捗バーンダウンチャートテスト進捗率工数ストーリーポイント（人月）生産性ベロシティ（ストーリーポイント/スプリント）サイクルタイムリードタイム待ち時間前倒し率（人月/FP…）バグ修正時間品質関連のメトリクスはウォーターフォールと共通のものが多い生産性に関するメトリクスはリーンの影響を受けたアジャイル独自のものが多い
72 アジャイルのメトリクス：ウォーターフォールと共通のメトリクス①テスト密度とバグ密度・ある瞬間のスナップショットの品質を評価 →ウォーターフォールのプロジェクトで測定されたメトリクスと比較可能（ただし注意は必要）
73 アジャイルのメトリクス：ウォーターフォールと共通のメトリクス②テスト実行成功率・ある瞬間の自動テスト実行成功率を計測・時系列で並べると中長期での変化も可視化（あとで出てきます。）
74 アジャイルのメトリクス：一覧アジャイル独自ウォーターフォールと共通サイズフィーチャーストーリー（FP. UCP）品質欠陥数/ (リリースまたはスプリント) テスト密度バグ密度コードカバレッジコードの複雑度コードチャーン DDP（欠陥検出率）テストの成功率 MTTD (平均欠陥発生時間) MTTR (平均欠陥修復時間) 進捗バーンダウンチャートテスト進捗率工数ストーリーポイント（人月）生産性ベロシティ（ストーリーポイント/スプリント）サイクルタイムリードタイム待ち時間前倒し率（人月/FP…）バグ修正時間品質関連のメトリクスはウォーターフォールと共通のものが多い生産性に関するメトリクスはリーンの影響を受けたアジャイル独自のものが多い
75 アジャイルのメトリクス：特徴
76 アジャイルのメトリクス：特徴・ある瞬間のスナップショットとしての品質 - スプリント終了時 - 出荷判定時（アジャイルではプロダクト開発は繰り返されるが、動くソフトウェアに対する「反復中のある時点」での品質評価を実施する。この品質評価を継続的に行う） →ウォーターフォールと共通のものが多い・生産性や品質の時系列での変化 - 反復内での変化 - 反復をまたいだ変化（反復を通した、生産性や品質の変化） →リーンから影響を受けたものが多い
77 アジャイルのメトリクス：スナップショットとしての品質をそのまま適用できない例信頼度成長曲線
78 アジャイルのメトリクス：スナップショットとしての品質をそのまま適用できない例信頼度成長曲線 0 20 40 60 80 100 (検出バグ数) 時間 A B C 0 20 40 60 80 100 0 200 400 600 800 1000 A B C (検出バグ数) 累積コミット数毎日ソースコード変更とシステムテストを実施しているプロジェクトで信頼度成長曲線を描くと、、、・時間を横軸に信頼度成長曲線を描くと収束しない →テストと並行してソースコード変更が実施されており、ソースコード中のバグの確率が変化していないことを示唆・累積コミット数を横軸にバグカーブを描くと収束している？ →リリース前にコミットの種類がバグ修正に切り替わっていることを示唆 A B C リリース
79 アジャイルのメトリクス：特徴・ある瞬間のスナップショットとしての品質 - スプリント終了時 - 出荷判定時（アジャイルではプロダクト開発は繰り返されるが、動くソフトウェアに対する「反復中のある時点」での品質評価を実施する。この品質評価を継続的に行う） →ウォーターフォールと共通のものが多い・生産性や品質の時系列での変化 - 反復内での変化 - 反復をまたいだ変化（反復を通した、生産性や品質の変化） →リーンから影響を受けたものが多い
80 アジャイルのメトリクス：特徴・ある瞬間のスナップショットとしての品質 - スプリント終了時 - 出荷判定時（アジャイルではプロダクト開発は繰り返されるが、動くソフトウェアに対する「反復中のある時点」での品質評価を実施する。この品質評価を継続的に行う） →ウォーターフォールと共通のものが多い・生産性や品質の時系列での変化 - 反復内での変化 - 反復をまたいだ変化（反復を通した、生産性や品質の変化） →リーンから影響を受けたものが多い・メトリクスのスコープが限定スプリント内での値にばらつき時系列でメトリクスが収集可能
81 アジャイルのメトリクス：特徴メトリクスのスコープが限定・アジャイルではスコープが限定される →例えば１スプリントで取得されるメトリクスの数が少なく、メトリクスの値がばらつきやすい・アジャイルではメトリクスを反復を通し複数回測定 →時系列での変化を分析可能分析設計実装テストウォーターフォールアジャイルリーン/DevOps 要求（スコープ）時間要求（スコープ）時間要求（スコープ）時間
82 アジャイルのメトリクス：特徴アジャイルでの時系列での変化の分析①
83 アジャイルのメトリクス：特徴アジャイルでの時系列での変化の分析① ・突然の大幅なドロップ・xx日成功率100%をキープ
84 アジャイルのメトリクス：特徴アジャイルでの時系列での変化の分析② 今まで →複数のプロジェクトを並べて相関分析や層別分析を実施アジャイル→一つのプロジェクトの時系列データを並べて相関分析や層別分析を行うことも可能
85 アジャイルのメトリクス：特徴・ある瞬間のスナップショットとしての品質スプリント終了時出荷判定時（アジャイルではプロダクト開発は繰り返されるが、反復中のある時点での動くソフトウェアに対する品質評価を）・生産性や品質の時系列での変化スプリント内での変化スプリントをまたいだ変化（反復を通した、生産性や品質の変化）・メトリクスのスコープが限定スプリント内での値にばらつき時系列でメトリクスが収集可能
87 本日お持ち帰りいただきたいこと背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめ QAは依然重要時系列の変化
90 特徴素早いテストと開発サイクル特徴①： QAテストとメトリクス特徴②:素早いテストと開発サイクル特徴③：継続的なフィードバック
91 特徴素早いテストと開発サイクル特徴①： QAテストとメトリクス特徴②:素早いテストと開発サイクル特徴③：継続的なフィードバック・アジャイルの開発サイクルと素早いテスト・テストプロセスの分析・テストプロセスのソフトウェア化
92 アジャイルの開発サイクルと素早いテスト
93 アジャイルの開発サイクルと素早いテスト・アジャイル開発は短い開発サイクルを繰り返す・品質保証も短期間、高頻度で実施することが求められる →実際には品質保証がボトルネックになりがち＊テストはスコープが増え続ける →各プロセスが敏感に影響 →そのためテストを素早く確実に実施することが求められる特徴②:素早いテストと開発サイクル各プロセスの影響に敏感
95 テストプロセスの分析：①バリューストリームマッピング牛尾剛：日本のDevOps変革を促進するバリューストリームマッピング、 https://gihyo.jp/dev/column/01/devops/2017/value-stream-mapping?page=1 (2021/01/01 アクセス), (2017) ・リーン生産方式のプロセスを分析する技法の一つ・トヨタで使われていた手法をもとにしている・関係者全員で、アイデアを思いついてから本番デプロイまでのステップを見える化・リードタイム、プロセスタイム、無駄な時間を追跡
96 テストプロセスの分析：①バリューストリームマッピングバリューストリームマッピングで探す無駄のリスト無駄の種類マーク定義例欠陥の無駄（Defects） D 誤った，抜けのある，不透明な情報や成果物。システムを破壊し，解決するのに時間と労力が必要壊れたビルド，不正確な設定，不正確な要求マニュアル／モーション（Manual/Motion，Handoffs） M オーバーヘッド，コーディネーション，作業引き渡し，またはセットアップや仕事の実行に関する非効率性ミーティング，手動デプロイ，チーム間の作業引き渡し待ちの無駄（Waiting） W 次の価値のあるステップを開始，または終了することの遅れ承認待ち，リソースの待ち，予定されたミーティング待ち未完了の作業（Partially Done） PD 未完了の作業，何らかの操作。他者からの入力やアクションが必要となる。欠陥とタスク切り替え，待ちを招くデプロイされていないコード，不完全な環境設定，実行中バッチタスクの切り替え（Task Switching） TS タスクの切り替えは，高価なコンテキストスイッチを招き，エラーが発生しやすくなる進捗上限による無駄作業，障害による中断，アドホックなリクエスト余分なプロセス（Extra Process） EP 価値のないステップやプロセス。たいていは，公式，非公式な標準作業に含まれる不要な承認，不要なドキュメント，無駄なレビュー余分な機能（Extra Feature） EF 機能，たいていは実装フェーズで追加されたもの。リクエストされていない，ビジネスに沿っていない，顧客価値がない “次に必要かもしれない”，不要なアップデートや要求，望んでいないヒーローまたはヒロイン（Heroics） H 仕事を完了させる，または顧客を満足させるために，ある人に大変な負荷がかかっている状態。ボトルネック数日必要なデプロイ，長年の知識が必要，極端な調整が必要
97 テストプロセスの分析：② 七つ道具内藤史郎ら：QC七つ道具を利用したDevOpsプラクティスの導入による開発とテストの生産性改善, SQiP 2019, C1-1, (2019) ＊筆者の組織ですが、先ほどまでのものとは別のプロジェクトです。
98 テストプロセスの分析：② 七つ道具安達賢二ら：日本におけるソフトウェアプロセス改善の歴史的意義と今後の展開、 SQuBOK Review 2016, Vol.1, pp.11-24 (2016) ・1971-1990頃、主であったTQCの枠組みの中での改善活動で利用された・1990年ごろから、モデルベースのプロセス改善が主流に SQuBOK GUIDE V2 “品質管理において、数値データを整理・解析し、現象を定量的に分析するために用いる基本的で重要な七つの技法の総称である” ・特性要因図・パレート図・チェックシート・ヒストグラム・散布図・管理図・グラフ・層別・親和図法・連関図法・系統図法・マトリクス図法・アロー・ダイアグラム法・PDPC法・マトリクス・データ解析法
99 テストプロセスの分析：② 七つ道具内藤史郎ら：QC七つ道具を利用したDevOpsプラクティスの導入による開発とテストの生産性改善, SQiP 2019, C1-1, (2019) ＊筆者の組織ですが、先ほどまでのものとは別のプロジェクトです。
100 テストプロセスの分析：② 七つ道具不良のムダ
101 テストプロセスの分析：② 七つ道具：品質のムラ（テスト品質のムラ）
102 テストプロセスの分析：② 七つ道具：手待ちのムダ
103 テストプロセスの分析：② 七つ道具：手待ちのムダタスク・複数のチームをタスクがいったりきたりする場合、「手待ちのムダ」が発生しやすい・例）バグ修正開発チームによるバグ修正期間→テストチームで手待ちのムダが発生テストチームによる再テスト期間→開発チームで手待ちのムダが発生・手待ちのムダはリードタイムに大きく影響するので、見つけ出し改善すると特に効果の大きいムダの一つ
104 テストプロセスの分析：② 七つ道具内藤史郎ら：QC七つ道具を利用したDevOpsプラクティスの導入による開発とテストの生産性改善, SQiP 2019, C1-1, (2019) ・テストプロセスの現状を見える化・ムダを探し出す →プロセスのソフトウェ化によって改善
106 テストプロセスのソフトウェア化テスト要求分析テスト設計テスト実装テスト実行テスト終了作業 Spec/ Design テストレポートテストプロセス現在の自動化対象・現在自動化の対象はテスト実行がほとんど・自動化=ソフトウェア化テスト自動実行ソフトウェアとしての品質特性が重要
107 テストプロセスのソフトウェア化：テスト自動実行ソフトウェアの品質特性井芹洋輝: テスト自動化の品質モデルの扱い、https://www2.slideshare.net/goyoki/ss- 36405244 (2021/01/01 アクセス) (2014) 小井戸享: システムテストの自動化とアーキテクチャ、 https://www2.slideshare.net/koido1961/ss- 39837146 (2021/01/01 アクセス) (2014)
108 テストプロセスのソフトウェア化：テスト自動実行ソフトウェアの品質特性
109 テストプロセスのソフトウェア化：テスト自動実行ソフトウェアの品質特性品質特性説明メトリクスユーザビリティプロジェクト関係者なら誰でも、知識やスキルなどに関係なく自動テストを実行できることまたはテストレポートの内容を誰でも理解できること • テスト実行メンバー数 • テスト結果アクセスメンバー数効率性テスト実行が求められる時間内に完了すること • テスト実行時間信頼性テスト結果が信頼できること Frakyテストの影響が除外できていること • テスト実行成功率並行性複数のテストシナリオを並行して実行できること • テスト実行時間 • 並行実行テストジョブ数再現性何度再実行しても、同じテスト結果が再現できること • テスト結果再現率エラー追跡性テストが失敗した場合に、その原因がプロダクト、環境またはテストのどれか簡単に切り分けられること • テスト失敗調査時間＊ここではテスト実行の動的な品質特性のみを挙げているが、もちろん静的なテストカバレッジも重要
110 テストプロセスのソフトウェア化：テスト自動実行ソフトウェアの品質特性品質特性説明メトリクスユーザビリティプロジェクト関係者なら誰でも、知識やスキルなどに関係なく自動テストを実行できることまたはテストレポートの内容を誰でも理解できること • テスト実行メンバー数 • テスト結果アクセスメンバー数効率性テスト実行が求められる時間内に完了すること • テスト実行時間信頼性テスト結果が信頼できること Frakyテストの影響が除外できていること • テスト実行成功率並行性複数のテストシナリオを並行して実行できること • テスト実行時間 • 並行実行テストジョブ数再現性何度再実行しても、同じテスト結果が再現できること • テスト結果再現率エラー追跡性テストが失敗した場合に、その原因がプロダクト、環境またはテストのどれか簡単に切り分けられること • テスト失敗調査時間＊ここではテスト実行の動的な品質特性のみを挙げているが、もちろん静的なテストカバレッジも重要 ”テストの生産性”の文脈ではユーザービリティと効率性が重要しかし、効率性には「信頼性」「並行性」「再現性」「エラー追跡性」を含む「信頼性」が大きく影響
111 テストプロセスのソフトウェア化：テスト自動実行ソフトウェアの品質特性・自動化されたテストケースが１００件の場合、 1%のテストが失敗したら１件の失敗テストを調査・荻野の組織の場合30万件のテストケースが毎日自動実行されているので、 1%のテストが失敗したら3000件のテストを調査・John MiccoのGoogleの場合、数百万件のテストケースが自動実行されてるので 1%のテストが失敗したら数万件のテストを調査（実際には16%） John Micco: Advances in Continuous Integration Testing @Google, JaSST `18, A0, http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf (2020年01月06日現在)
112 テストプロセスのソフトウェア化：テスト実行成功率
113 テストプロセスのソフトウェア化：テスト終了作業のメトリクステスト要求分析テスト設計テスト実装テスト実行テスト終了作業 Spec/ Design テストレポートテストプロセス John Miccoの自動化対象領域テスト実行結果テスト再実行の割合
114 テストプロセスのソフトウェア化：先ほどの分析した事例の続き解決策・開発環境をスケーラブルに構築可能にするため構築手順をソフトウェア化・テストケースを追加・テストの日次実行を開始
115 テストプロセスのソフトウェア化：先ほどの分析した事例の続き結果・バグ修正日数が中央値で 10日から2日に改善・障害件数が中央値で 3件から1件に改善プロセスを素早く確実に何度も繰り返し可能なものに改善した
116 テストプロセスのソフトウェア化：テストプロセス以外にも適用できる DevOps時代のアーキテクチャ品質特性とプロセス品質概論（個人のブログ記事） DevOps アーキテクチャ検索
117 素早いテストと開発サイクル・アジャイル開発は短い開発サイクルを繰り返す・品質保証も短期間、高頻度で実施することが求められる →そのためテストを素早く確実に実施することが求められる
118 素早いテストと開発サイクル・アジャイル開発は短い開発サイクルを繰り返す・品質保証も短期間、高頻度で実施することが求められる →そのためテストを素早く確実に実施することが求められる →開発サイクルを繰り返すため、プロセス改善のインセンティブが高い何百回、何千回と繰り返す場合、より高いプロセス改善の効果そのため、プロセスを素早く確実に反復するための・プロセス品質の分析・プロセスのソフトウェア化が重要
120 本日お持ち帰りいただきたいこと背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめプロセスの継続的な分析とソフトウェア化
123 特徴継続的なフィードバック特徴①： QAテストとメトリクス特徴②:素早いテストと開発サイクル特徴③：継続的なフィードバック
124 特徴継続的なフィードバック特徴①： QAテストとメトリクス特徴②:素早いテストと開発サイクル特徴③：継続的なフィードバック・シフト・レフトテスト・シフト・ライトテスト
125 シフト・レフトテストとシフト・ライトテスト
126 シフト・レフトテストとシフト・ライトテスト辰巳敬三：ソフトウェアテストのニューノーマル〜テストの新たな常態・常識〜、 VERISERVE NAVIGATION、Vol.13、pp.06-11 (2018) シフト・レフトテスト：テスト活動を前倒し →フィードバックを早期に獲得シフト・ライトテスト：テスト活動を後ろ倒し →本番稼働中のシステムからフィードバックを獲得
127 シフト・レフトテストとシフト・ライトテストシフト・レフトテスト：テスト活動を前倒し →フィードバックを早期に獲得シフト・ライトテスト：テスト活動を後ろ倒し →本番稼働中のシステムからフィードバックを獲得
128 シフト・レフトテストとシフト・ライトテストシフト・レフトテスト：テスト活動を前倒し →フィードバックを早期に獲得シフト・ライトテスト：テスト活動を後ろ倒し →本番稼働中のシステムからフィードバックを獲得
129 シフト・レフトテストとシフト・ライトテストシフト・レフトテスト：テスト活動を前倒し →フィードバックを早期に獲得シフト・ライトテスト：テスト活動を後ろ倒し →本番稼働中のシステムからフィードバックを獲得・PoC ・継続的インテグレーション (単体テストなど) ・継続的デリバリー（受け入れテストなど）・継続的システムテスト（システムテストなど）・ABテスト・モニタリング・カナリアリリース・カオスエンジニアリング
130 シフト・レフトテストとシフト・ライトテストシフト・レフトテスト：テスト活動を前倒し →フィードバックを早期に獲得シフト・ライトテスト：テスト活動を後ろ倒し →本番稼働中のシステムからフィードバックを獲得・PoC ・継続的インテグレーション (単体テストなど) ・継続的デリバリー（受け入れテストなど）・継続的システムテスト（システムテストなど）開発プロセスのあらゆるアクティブティをテストと捉え、あらゆる場面からフィードバックを獲得していく・ABテスト・モニタリング・カナリアリリース・カオスエンジニアリング
132 シフト・レフトテストとシフト・ライトテストシフト・レフトテスト：テスト活動を前倒し →フィードバックを早期に獲得シフト・ライトテスト：テスト活動を後ろ倒し →本番稼働中のシステムからフィードバックを獲得・PoC ・継続的インテグレーション (単体テストなど) ・継続的デリバリー（受け入れテストなど）・継続的システムテスト（システムテストなど）開発プロセスのあらゆるアクティブティをテストと捉え、あらゆる場面からフィードバックを獲得していく・ABテスト・モニタリング・カナリアリリース・カオスエンジニアリング
133 シフト・レフトテスト
134 シフト・レフトテスト永田敦：プロダクト部門での品質保証担当の振る舞いアジャイル開発の場合、 JaSST 2016, C5-1, 2016
135 シフト・レフトテスト：の事例三菱電機細谷泰夫：斥候としてのアジャイルプロセス活用の提案、 SPI Japan 2012 (2012)
136 シフト・レフトテスト：の事例三菱電機細谷泰夫：斥候としてのアジャイルプロセス活用の提案、 SPI Japan 2012 (2012)
137 シフト・レフトテスト：継続的システムテスト（楽天）荻野恒太郎：安心なサービスの品質改善を実現するための継続的システムテスト, 15-B-11先進的な設計・検証技術の適用事例報告書2015年度版(2015. 11) 0 200 400 600 800 1000 1200 1400 0 10 20 30 40 50 60 70 80 90 累積検出バグ数累積コミット数コミット数検出バグ数システムテストを自動化し、実装と並行して毎日実行するようにテストを毎日実行することで、バグが混入されたらすぐに検出できるように
138 シフト・レフトテスト：継続的システムテスト（楽天）バグ修正日数 0 2 4 6 8 10 UT/CT ST 0 2 4 6 8 10 UT/CT ST 前 Q3 Q1 中央値 Q3 Q1 中央値 Q3 Q1 中央値 Q3 Q1 中央値最大値 59 最大値 64 最大値 75 最大値 87 後 (10572*） (11453*） *テストメソッド数 (日数) (日数) ・システムテスト自動化後、バグ修正日数が改善した・テストからのフィードバックの間隔が小刻みになり -原因となるソースコード変更が限定される -実装から時間がたたずにバグ調査が実施されるためと考えられる
140 シフト・レフトテストとシフト・ライトテストシフト・レフトテスト：テスト活動を前倒し →フィードバックを早期に獲得シフト・ライトテスト：テスト活動を後ろ倒し →本番稼働中のシステムからフィードバックを獲得・PoC ・継続的インテグレーション (単体テストなど) ・継続的デリバリー（受け入れテストなど）・継続的システムテスト（システムテストなど）・ABテスト・モニタリング・カナリアリリース・カオスエンジニアリング開発プロセスのあらゆるアクティブティをテストと捉え、あらゆる場面からフィードバックを獲得していく
141 シフト・ライトテスト：テスト
142 シフト・ライトテスト：テストバージョン A バージョン B 50% 50% アプリケーションのバージョンによる違い・UIのデザイン（色、ボタンの大きさなどなど）・レコメンデーションのアルゴリズム効果を測定 CVR (Conversion Ratio) -購買率 -登録率 -ログイン率 -再生率 -いいね率・複数のバージョンのアプリケーションを本番環境にデプロイし、ビジネスへの効果を測定し比較・継続して行うことで、サイトのデザインやアルゴリズムを最適化していく・バンディットアルゴリズム -振り分けの割合を自動で最適化 -悪いバージョンに振り分けることによる機会損失を最小化メトリクス
143 シフト・ライトテスト：テストバージョン A バージョン B 50% 50% アプリケーションのバージョンによる違い・UIのデザイン（色、ボタンの大きさなどなど）・レコメンデーションのアルゴリズム効果を測定 CVR (Conversion Ratio) -購買率 -登録率 -ログイン率 -再生率 -いいね率・複数のバージョンのアプリケーションを本番環境にデプロイし、ビジネスへの効果を測定し比較・継続して行うことで、サイトのデザインやアルゴリズムを最適化していく・バンディットアルゴリズム -振り分けの割合を自動で最適化 -悪いバージョンに振り分けることによる機会損失を最小化メトリクス →新機能についてフィードバック
144 シフト・ライトテスト：モニタリング
145 シフト・ライトテスト：モニタリング・本番環境デプロイ後モニタリングするなんて当たり前、、、なんですが
146 シフト・ライトテスト：モニタリング・本番環境デプロイ後モニタリングするなんて当たり前、、、なんですが 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) 4th tool: Shared metrics in 6 Tools 対立しがちなDevチームとOpsチームが協働するためのツールとしてのメトリクス
147 シフト・ライトテスト：モニタリング DevチームとOpsチームの対立・Devチームは機能追加したいが、Opsチームは本番環境に変更を入れたくない・障害が起きた場合にお互い相手の責任だと言い合う・そもそもDevチームとOpsチームが組織として違う・組織としてゴールを共有していない・変更に対する会話が成立していない
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にフィードバック・変更がもたらした実際のメトリクスの変化はどうだったか？・想定されていないメトリクスの変化は起きていないか？
149 シフト・ライトテスト：モニタリング・モニタリングするメトリクスの例ビジネスメトリクス：アクセス数ログイン数購買額アプリケーションメトリクス：応答時間、遅延件数、同時処理件数、エラー件数システムメトリクス：CPU使用率、メモリ使用率、ネットワーク・リアルタイムにメトリクスダッシュボードを共有する
150 シフト・ライトテスト：モニタリング・モニタリングするメトリクスの例ビジネスメトリクス：アクセス数ログイン数購買額アプリケーションメトリクス：応答時間、遅延件数、同時処理件数、エラー件数システムメトリクス：CPU使用率、メモリ使用率、ネットワーク・リアルタイムにメトリクスダッシュボードを共有する →本番環境についてフィードバック
151 シフト・ライトテスト：カオスエンジニアリング
152 シフト・ライトテスト：カオスエンジニアリング DB Primary DB1 ・マイクロサービスや分散システムによりシステムの信頼性の考え方が変化してきている DB Standby アプリケーションアプリケーションアプリケーション DB2 DB3 DB4 DB5 アプリケーションアプリケーションアプリケーションアプリケーションアプリケーションアプリケーション・高スペック・スケールアップ・障害の発生頻度は稀・障害を許容しない (ACID/CAT) ・障害の影響範囲は全体・低スペック・スケールアウト・障害の発生頻度は高い・障害が起きることを想定例）Eventual Consistency ・障害の影響範囲を限定・障害対応作業のソフトウェア化も進んでる -障害検知 -障害復旧例）クラウド、DockerやKubernetes
153 シフト・ライトテスト：カオスエンジニアリング・マイクロサービスや分散システムによりシステムの信頼性の考え方が変化してきている・障害が頻繁に起きることを許容するが、その代わり -障害の影響を最小化 -障害復旧の最速化を重視。 →（障害が起きないようにすることよりも、障害が起きたときの）耐障害性と復旧性を重視
154 シフト・ライトテスト：カオスエンジニアリングカオスエンジニアリング：障害を引き起こすようなテストを本番環境などで意図的に実施する意味・障害検知や復旧作業のソフトウェアのテスト -クラウドなどではインフラストラクチャーの構築手順が自動化（ソフトウェア化） -障害検知や復旧作業も自動化することができる・障害について継続的に学習（レジリエンス） -レジリエンス：「予測」「監視」「対応」「学習」 -障害が起きないと、障害について学習する機会がなくなってしまう！！
155 シフト・ライトテスト：カオスエンジニアリングカオスエンジニアリングのメトリクス：・障害検知のためのモニタリングのメトリクス障害発生時に、それを検知するためのメトリクス例）-リクエスト数、システムリソース、応答時間など・障害復旧のためのメトリクス障害復旧後に、それが成功したことを判断するためのメトリクス例）同上＊定量的に正常値と異常値を定義できると、機械が判断（=自動テスト）できるようになる・学習のためのメトリクス・障害検知の精度・再現率、障害復旧の成功率・障害検知時間、障害復旧時間 →継続的に障害についてフィードバック
156 シフト・ライトテスト：カナリアリリース
157 シフト・ライトテスト：カナリアリリース・炭鉱で毒ガスを検知するカナリアに由来・すべてのユーザーを一度に切り替えるのではなく、少数のユーザーを新バージョンに切り替える・問題がないことを確認しながら段階的に新バージョンに切り替えていく -OSのパッチ、アップグレード -ウェブブラウザ -スマホアプリ -ウェブサービス、クラウドサービスツールとしてはNetflixのKayentaが有名旧バージョン新バージョン 99% 1% メトリクス
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 期待される結果
159 シフト・ライトテスト：カナリアリリース遅延件数・各カナリー率の肯定で、モニタリング結果と期待結果を比較し、戻し作業をするかどうかを判断する Latency
160 シフト・ライトテスト：カナリアリリースカナリアリリースの長所・本番環境のリリースや運用による変更のリスクを軽減できる・本番稼働している実環境の条件の組み合わせが爆発し、テスト環境での組み合わせ網羅が難しいケース組み合わせ爆発の例：ブラウザの場合 -デバイスの種類 -言語や地域 -OSの種類とバージョン -ブラウザの設定 -プラグインなど・本番環境で取得したメトリクスにもとづいて定量的に、次の段階に進むかの判断ができる
161 シフト・ライトテスト：カナリアリリースカナリアリリースの長所・本番環境のリリースや運用による変更のリスクを軽減できる・本番稼働している実環境の条件の組み合わせが爆発し、テスト環境での組み合わせ網羅が難しいケース組み合わせ爆発の例：ブラウザの場合 -デバイスの種類 -言語や地域 -OSの種類とバージョン -ブラウザの設定 -プラグインなど・本番環境で取得したメトリクスにもとづいて定量的に、次の段階に進むかの判断ができる →新機能についての問題をフィードバック
162 シフト・レフトテストとシフト・ライトテストシフト・レフトテスト：テスト活動を前倒し →フィードバックを早期に獲得シフト・ライトテスト：テスト活動を後ろ倒し →本番稼働中のシステムからフィードバックを獲得・PoC ・継続的インテグレーション (単体テストなど) ・継続的デリバリー（受け入れテストなど）・継続的システムテスト（システムテストなど）・ABテスト・モニタリング・カナリアリリース・カオスエンジニアリング開発プロセスのあらゆるアクティブティをテストと捉え、あらゆる場面からフィードバックを獲得していく
163 シフト・レフトテストとシフト・ライトテストシフト・レフトテスト：テスト活動を前倒し →フィードバックを早期に獲得シフト・ライトテスト：テスト活動を後ろ倒し →本番稼働中のシステムからフィードバックを獲得・PoC ・継続的インテグレーション (単体テストなど) ・継続的デリバリー（受け入れテストなど）・継続的システムテスト（システムテストなど）・ABテスト →新機能についてフィードバック・モニタリング →本番環境についてフィードバック・カナリアリリース →障害についてフィードバック・カオスエンジニアリング →新機能の問題についてフィードバック開発プロセスのあらゆるアクティブティをテストと捉え、あらゆる場面からフィードバックを獲得していく
165 本日お持ち帰りいただきたいこと背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめあらゆる場面からフィードバック
166 まとめ背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめ
167 まとめ背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめアジャイルはプロセスを繰り返すアジャイル開発の歴史と特徴
168 まとめ背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめ QAは依然重要時系列の変化アジャイルはプロセスを繰り返すアジャイル開発の歴史と特徴 QAテストのメトリクス
169 まとめ背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめプロセスの継続的な分析とソフトウェア化 QAは依然重要時系列の変化生産性改善のメトリクスアジャイルはプロセスを繰り返す
170 まとめ背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめあらゆる場面からフィードバックプロセスの継続的な分析とソフトウェア化 QAは依然重要時系列の変化アジャイルはプロセスを繰り返すあらゆる場面からのフィードバック
171 まとめ背景：アジャイル開発についておさらいアジャイル開発の発展の歴史繰り返し開発としてのアジャイル/DevOps メトリクスから見たアジャイル開発アジャイル開発の品質保証の特徴特徴1: QAテストとメトリクス QAテストがアジャイルでも重要な理由アジャイルでのQAテスト事例アジャイルのメトリクス特徴2: 素早いテストと開発サイクルアジャイルの開発サイクルと素早いテストテストプロセスの分析テストプロセスのソフトウェア化特徴3: 継続的なフィードバックシフト・レフトテストシフト・ライトテストまとめあらゆる場面からフィードバックプロセスの継続的な分析とソフトウェア化 QAは依然重要時系列の変化アジャイル開発の歴史と特徴 QAテストのメトリクス生産性改善のメトリクスあらゆる場面からのフィードバックアジャイルはプロセスを繰り返す

アジャイル開発とメトリクス

Check these out next

アジャイル開発とメトリクス

Recommended

More Related Content

Slideshows for you(20)

Similar to アジャイル開発とメトリクス(20)

More from Rakuten Group, Inc.(20)

Recently uploaded(20)

アジャイル開発とメトリクス