60％ 70％
50％
30％ 40％
20％
0 10％ 80％ 90％
75％
72％
69％ 58％
55％
70％
60％
50％
47％
44％
30％ 28％ 22％
25％
45％
41％
39％
29％
55％
38％
56％
74％
85％
17％ 15％
12％
1 Daily Standup 3 Iteration Planning 2 Retrospectives ⇗１ 10 Unit Testing ⇘１ 17 Release Planning
8 Burndown/ Team-Based Estimation 23 Velocity
14 Continuous Integration Automated Builds 20 Coding Standards ⇘２ 26 Dedicated Product Owner
Integrated Dev /QA 24 Refactoring
9 Digital Taskboard ⇗２ 25 Open Workarea
21 Story Mapping
44 Kanban
60％ 70％
50％
30％ 40％
20％
0 10％ 80％ 90％
79％
71％
65％ 56％
50％
69％
65％
48％
46％
38％
29％
24％
21％
24％
43％
36％
34％
27％
53％
31％
53％
79％ 80％
13％ 9％
Daily Standup Short iterations Prioritized backlogs Iteration Planning Retrospectives Unit Testing Release Planning
Team-Based Estimation Iteration reviews
Taskboard
Continuous Integration Dedicated Product Owner Integrated Dev&testing Coding Standards Open Workarea Refactoring TDD
Kanban
Story Mapping
Collective Code Ownership Automated Acceptance Testing Continuous Deployment
Pair Programming Agile Games BDD
（VersionOne社 アジャイル開発の現状調査第9回2015より）
参考データ
調査事例：活用されているプラクティス （海外 _2015年 ）
58 48
44 44 39 30
29 25 23 11
0 10 20 30 40 50 60 70
On-time delivery Product quality Customer/user Business value Product scope Project visibility Productivity Predictability Process improvement Don't know
アジャイル開発の成功の尺度
参考データ
VERSIONONE®: 9
thANNUAL STATE of AGILE DEVELOPMENT SURVEY, 2015 http://www.versionone.com/pdf/state-of-agile-development-survey-ninth.pdf
%
分からない プロセス改善 予測性
生産性
プロジェクトの可視性 プロジェクトのスコープ ビジネス価値
顧客 / 利用者 製品の品質 納期遵守
やはり，「納期」が一番
ITプロジェクト一般とは異なる結果
0 10 20 30 40 50 60 70
Velocity Iteration burndown Release burndown Pianned vs. actual stories per iteration Burn-up chart Pianned vs. actual release dates Customer/user satisfaction Work-in-Process (WIP) Defects in to production Defects over time Budget vs. actual cost Defect resolution Estimation accuracy Business value delivered Individual hours per iteration/week Cycle time Test pass/fail over time Scope change in a release Cumulative flow chart Earned value Customer retention Revenue/sales impact Product utilization
参考データ
VERSIONONE®: 9
thANNUAL STATE of AGILE DEVELOPMENT SURVEY, 2015 http://www.versionone.com/pdf/state-of-agile-development-survey-ninth.pdf
アジャイル開発の成功を測る（日々の）指標
%
開発速度(59%)，
反復バーンダウン(51%)，
リリースバーンダウン(39%)
の順
42 40 39 35 31
0 5 10 15 20 25 30 35 40 45
Consistent process &practices Executive sponsorship Implementation of a common tool across teams
Agile consultants or trainers Internal agile support team 参考データ
VERSIONONE®: 9
thANNUAL STATE of AGILE DEVELOPMENT SURVEY, 2015 http://www.versionone.com/pdf/state-of-agile-development-survey-ninth.pdf
大規模開発へのアジャイル手法適用の成功要因
%
首尾一貫したプロセスとプラクティスが重要
付録
アジャイル開発のメトリクス
<
出典> John Kammelar: Agile Metrics, Nesma, 28/04/2015.
http://nesma.org/2015/04/agile-metrics/
ソフトウェア・メトリクスの用途（一般）：
計画，予測 Planning, forecasting
監視と制御 Monitoring & control
パフォーマンス改善，ベンチマーキング
Performance improvement, benchmarking
5つのコア・メトリクス（一般）：
規模 Product(size)
品質（信頼性） Quality
工数 Effort
工期 Duration
生産性 Productivity
開発手法とメトリクス
<出典> John Kammelar: Agile Metrics, Nesma, 28/04/2015.
http://nesma.org/2015/04/agile-metrics/
コア・メトリクス アジャイル開発 ウォーターフォール型開発 規模
Product(size) features, stories FP, CFP, UCP 品質(信頼性)
Quality
defects/iteration, defects,
Mean Time to Defect (MTTD)
defects/release, defects,
Mean Time to Defect (MTTD) 工数
Effort story points *) person months 工期
Time duration (months) duration (months) 生産性
Productivity
velocity
(story points/iteration) hours/FP
*) Story points are subjective and only apply to this project and this team
計画・予測用メトリクス
<出典> John Kammelar: Agile Metrics, Nesma, 28/04/2015. http://nesma.org/2015/04/agile-metrics/
指標(Metric) 目的 測定方法
フィーチャー数
(number of features)
1.Insight into the size of the product (and the entire release).
2.When status applied to features:
insight in progress.
The product comprises features that in turn comprise stories. Features are grouped as ‘to do’, ‘in progress’, and ‘accepted’.
反復/リリース当りの計画ス トーリー数
(number of planned stories per iteration/release)
1.Insight into the size of the product (and the entire release).
2.When status applied to stories:
insight in progress.
The work is described in stories, which are quantified in story points.
Stories are grouped as ‘to do’, ‘in progress’, and ‘accepted’.
反復
/
リリース当りの受入れ ストーリー数(number of accepted stories per iteration/
release)
To track progress of the iteration/release
Formal registration of accepted stories.
チームの開発速度
(Team Velocity) Refer to Monitoring & Control
コード行数(LOC)
Indicates amount of completed work (progress), calculation of other
metrics i.e. defect density.
According to rules agreed upon
which LOC’s to count.
監視・制御(進捗，パフォーマンス)用メトリクス(1/2)
<出典> John Kammelar: Agile Metrics, Nesma, 28/04/2015. http://nesma.org/2015/04/agile-metrics/
指標(Metric) 目的 測定方法
反復のバーンダウン
(Iteration Burn-down)
Performance per iteration, ‘are we on track?’.
Effort remaining (in hrs) for the current iteration (effort spent/
planned expresses performance).
反復当りのチーム開発速度
(Team Velocity per
Iteration)
To learn historical Velocity for certain Team. Cannot be used to compare different teams.
Number of realized story points per iteration within this release. Velocity is team and project specific.
リリースのバーンダウン
(Release Burn-down)
To track progress of a release from iteration to iteration ‘are we on track for the entire release’.
Number of story points ‘to do’ after completion of an iteration within the release (extrapolation with certain velocity shows the end date).
リリースのバーンアップ
(Release Burn-up)
How much ‘product’ can be delivered within the given time frame.
Number of story points realized after completion of an iteration over the total number of story points (of the release). On a time line it shows the progress of ‘scope completion’.
反復当りのテストケース数
(Number of test cases per Iteration)
To learn amount of test work per iteration. To track progress of testing.
Number of test cases per Iteration recorded as ‘sustained’, ‘failed’ and
‘to do’.
監視・制御(進捗，パフォーマンス)用メトリクス(2/2)
<出典> John Kammelar: Agile Metrics, Nesma, 28/04/2015. http://nesma.org/2015/04/agile-metrics/
指標(Metric) 目的 測定方法
開発サイクル時間(チームの 受容力)
(Cycle Time
(Team’s capacity))
To determine bottlenecks of the process; the discipline with the lowest capacity is the bottleneck.
Number of stories that can be handled per discipline within an iteration (i.e. analysis- UI-design-coding - unit test- syst.-test).
リトルの法則
(Little’s Law – ‘cycle times are proportional to queue length’.)
Insight into duration; we can predict completion time based on queue length.
Work in progress (# stories) divided
by the capacity of the process step.
改善（プロダクト品質，プロセス改善）用メトリクス
<出典> John Kammelar: Agile Metrics, Nesma, 28/04/2015. http://nesma.org/2015/04/agile-metrics/
指標(Metric) 目的 測定方法
累積不具合数
(Cumulative number of defects)
To track effectivity of testing. Logging each defect in defect management system.
テストセッション数
(Number of test sessions)
To track testing effort and compare it to the cumulative number of defects.
Extraction of data from the defect repository.
不具合密度
(Defect density)
To determine the quality of the software in terms ‘lack of defects’.
The cumulative number of defects divided by 1000LOC’s (KLOC).
不具合の原因分布
(Defect distribution per origin)
To decide where to allocate quality assurance resources.
By logging the origin of defects in the defect repository and extract the data by means of an automated tool.
不具合のタイプ分布
(Defect distribution per type)
To learn what type of defects are the most common and help avoid them in the future.
By logging the type of defects in the defect repository and extract the data by means of an automated tool.
不具合の解決時間
(Defect Cycle Time)
Insight in the time solve a defect (speed of defect resolution).
The faster the resolution, the lesser coding ‘on top’ will be produced.
Opening date of the defect minus the
resolution date (usually the closing
date in the defect repository).
ドキュメント内
プロローグ ビジネスを取り巻く状況と IT 2
(ページ 130-142)