2016.06.27 AUGJ TOKYO #18

Continue to commit to overall plan on Portfolio for JIRA

自己紹介

岡 大勝（おか ひろまさ）

株式会社ゼンアーキテクツ

CEO/チーフアーキテクト

Profile

Financial / Manufacturing / Medical

IT Architecture Design / Requirements AnalysisEnterprise Agile Process

Micrsoft Azure / Atlassian / SPARX Systems

ソフトウェア開発は、事業と一体である

•割合の大小はあるが、ソフトウェアが事業の全てを占めることはない。

•ソフトウェア＝事業の中で、最も「軽量（アジリティの高い）」な資源• 軽量な特性を最大限活用したエンジニアリング手法が、アジャイルやリーン

• 人・拠点・設備など「質量」があるものは調達リードタイムが必要

•事業とソフトウェア開発は不可分• 「ビジネス駆動開発」から「ソフトウェア駆動ビジネス」へ• http://www.slideshare.net/tomohn/devsumib-19b6

アジャイルと企業活動のよくあるギャップ

•特に「計画」に注目すると•いつ完成するのか？（期間見積もり）•いくらかかるのか？（規模見積もり）•何ができるのか？（スコープ）•いま、どういう状況か？（進捗）•順調なのか？（リスク）

適切に答えられない

調達リードタイムが必要な他の事業部門との連携・準備を考慮すると、常に全て明確であるべき。

現場でよく見る２つの誤解

アジャイル＝「計画できないこと（不確実性）への対処法」だと思っている

•アジャイル＝「変化に素速く適応できる進め方」

•計画できないなら、プロジェクトを開始してはならない。• 正解が分からなくても、仮説を立て、全力で走る

• プロジェクトの中で試行錯誤しない。

•常に全体計画を持ち続けるが、いざ「変更が発生した」時に素速く適応できることがアジャイルの強み

アジャイルの誤解１

全体計画があるからこそ、全力で走ることができる

アジャイル＝「全体計画を立てられない（もしくは意味がない）」と思っている

•計画の目的は「見通しを立てる」こと• 実施すべきこと

• 事業計画との連携

• 他のプロジェクトとの連携

• リスクの識別

•見積もり前提が同じなら、従来型より精度の高い見積もりが可能

できあがった計画より、計画づくりにこそ価値がある

アジャイルの誤解２

アジャイルプロジェクト管理の4つの利点

1. 全体計画と実施計画の分離

2. プロジェクト内のフィードバックループ

3. 「相対値の積算見積もり」という落としどころ

4. 見積もりコストの低さ

9

10

アジャイルプロジェクト管理①規模見積もり

ストーリー

要求識別

ストーリー

ストーリーの見積もり

作成

ストーリーポイントの設定プランニングポーカー

ストーリー積算による概算レベルの規模見積もり

set

新たなストーリーが識別されなくなるまで

ストーリーポイントの合計が要求の規模

見積もり時の不毛な議論（100か101か）を避けるため、ストーリーポイントにはフィボナッチ数列の利用を

推奨

プロダクトバックログ

+ストーリーポイント合計

ストーリー

+ ストーリーポイント

プロダクトバックログ構築時のボトムアップ見積もり

スプリントスプリント

ストーリー

11

アジャイルプロジェクト管理②期間見積もり

ストーリー

次スプリントの作成

ストーリーストーリー

スプリントバックログの割り当て

前スプリントの実績よりベロシティ設定

プロダクトバックログ

スプリントバックログ

リリース計画による期間見積もり

スプリント

+ 期間+ ベロシティ

+ ストーリーポイント合計

ストーリー

優先順位の高いストーリーから取得

SPがベロシティを超えないようストーリーを割り当て

set

setget

実現するストーリーが全てスプリントに割り当てられるまで

1

1..*

1

1

スプリントの期間合計がプロジェクト期間

チーム編成は基本固定

期間は「２週間」が標準

チーム/組織

+ ベロシティ

メンバー

+ スキル

期間見積もり

+ 総期間

タイムボックスとベロシティによる期間見積もり

タスク

ストーリー

12

アジャイルプロジェクト管理③工数見積もり

ストーリーのタスク分解

タスクアサインと作業時間見積

もり

スプリントバックログ

スプリント計画による工数見積もり + ストーリー

ポイント合計

ストーリーget

タスクの定義

実施スプリントのタスク・工数の見積もり確定

実施スプリントのバックログ

タスク

+ 担当者+予定作業時間

set

スプリントで実現するストーリー全て

全てのタスク

工数合計がスプリント期間を超えるもしくは大きな乖離がある

タスク見積もりの精査

ストーリーの割り当て変更

このスプリントでの1ポイントあたりの作業工数見積もりは算出は可能。

しかし見積もりの数字遊びを避けるためSPを意図的に精緻に見積もらないようにしている（フィボナッチ）ので、見積もりのポ

イントからの実時間算出は無意味

ストーリーポイントの見積もりとのギャップ

エピック1

0..* 任意の分類軸

creates

スプリントバックログでの工数見積もり

タスク

ストーリー

13

アジャイルプロジェクト管理④開発作業と見積もりの改善

タスクの実施

スプリントデモ

スプリントバックログ

スプリント実施とフィードバックによる継続的見積もり改善

+ ストーリーポイント合計

ストーリー

実施スプリントのバックログ

タスク

+ 担当者+予定作業時間

+ステータス

全てのタスク

スプリントタスク完了

リリース計画へのフィードバッ

ク

対象ストーリーは変えない

ステータス更新

タスクボード

未着手→着手中

→完了タスクの追加、変更、削除

仕様化、レビュー、実装、テスト、不具合改修、データ作成、環境構築、リリース、等

ストーリーストーリーストーリー

プロダクトバックログ

• ストーリーの追加・削除・修正• 各ストーリーポイント見直し• 優先順位変更

任意のタイミング

追加変更要求

次のスプリント計画へ

ストーリー単位で完了/未完了を判断未完了のストーリーは実績ストーリーポイントに含めない

実績ストーリーポイント

＝ベロシティ

レポート

活動結果

フィードバックによる製品とチームの精度向上

パラメータに変更がある度に「再計算」して提示することが理想

• プロジェクト• スプリント期間• リリース• 非稼働日

• プロダクトバックログ• エピック• ストーリー• ストーリーポイント

• スプリントバックログ• タスク

• 作業予定時間

• チーム• ベロシティ

• メンバー• 稼働可能時間

• スキル

アジャイルプロジェクト計画のパラメータ

現実問題、全体計画を維持し続けることは手作業では難しい

ツールで全体計画を「導出」する

ツールのスコープは様々

BTS/ITS

アジャイルプロダクト生産活動

アジャイルの企業活動への適合E

C

Enterprise Agile

Core Agile

ツールのスコープは様々

BTS/ITS

アジャイルプロダクト生産活動

アジャイルの企業活動への適合E

C

Enterprise Agile

Core Agile

「全体計画」が可能

プロダクトバックログ

期間とベロシティにより、プロジェクトの長期計画を自動生成

全体計画の使いどころ

プロジェクト企画・予算計画

定例進捗会議

スプリントデモ

事業企画会議（他部門メンバー）

プロダクトオーナーによるリリース戦略

他プロジェクトとの連携

スキル開発・人員調達

チームメンバーに見通しを提供

Portfolio for JIRAで全体計画を扱うポイント

•ビジネスのマイルストーンを「リリース」に設定する

•初期のプロダクトバックログ構築がいちばん大事• 実現性とリスクを考慮したストーリーと見積もり

•業務分類を「テーマ」に設定すると、直感的に理解しやすい

•ベロシティにバッファは積まないこと• ストーリーポイントも水増ししない

•バッファを積むならSRSSストーリーを差し込む• 単位はリリースが望ましい

•スキルの設定はストーリーの粒度に影響する• テクノロジーの切り口でストーリーが分割される方向に行きやすい

•依存関係は適切かつ最小の利用に留める• 粒度の大きなストーリーと同様、計画の柔軟性が失われる

※ SRSS（Square Root Sum of Squares） = 2乗和平方根法

Continuous Release Planning「継続的リリース計画」

Agile Processes in Software Engineering and Extreme Programming

「Continuous Release Planning in a Large-Scale Scrum Development Organization at Ericsson」

アジャイルのプロジェクト計画は「手作り」するものではない。

によって、長期計画も変化に適合し続ける。

イテレーション5

イテレーション6

イテレーション7

・新たなストーリー

・優先順位の入替

・利用技術の見直し

・別チームの支援

継続的リリース計画

常時「見通し」を可視化

影響を反映

影響を反映

・・・

チーム活動の透明化によって事業活動との連携が生まれている

•プロダクトオーナーがリリース計画を調整できるようになった。

•他の事業部の施策を考慮することができるようになった。

•外部プロジェクトとの依存関係調整の自由度が向上。

•他の施策の状況に応じて、リリース優先順位の入れ替えを行うようになりつつある。

ブラックボックスのプロジェクト

「システムの調達」から「事業としての生産活動」へ

要求 システム

ブラックボックスのプロジェクト

事業活動と連携した生産活動

現場の声

25

zenarchitects.co.jp

facebook.com/zenarchitects