アジャイルとは何が良いのか？

Photo on VisualHuntアジャイル開発を実施する意義(利点)とは？

すごい良いのができる
安くつく
あっという間にできる「⽜丼屋のアジャイル」
⺠間では2010-13年あたりに流⾏

Photo credit: bryan... on Visualhunt / CC BY-SA

アジャイルな開発のプロセス的な特徴
少しずつ反復的に開発を進めることで必要とする⼈から必要なフィードバックを得て調整し続けられる開発

これからの2週間分のやることを決める

この2週間をふりかえり
カイゼン点を決める

毎⽇開発とコミュニケーション（設計〜開発〜テスト）

できたものを確認しフィードバックする2週間を繰り返せば⽬的のものができるのか？
計画の検証やその為の各種活動は必要

これからの2週間分のやることを決める

この2週間をふりかえり
カイゼン点を決める

開発がどこに着地できそうか確認する
やるべきことに優先度をつける

やること決めるのは良いけど本当に開発ができるような状態になっているか？

毎⽇開発とコミュニケーション（設計〜開発〜テスト）

できたものを確認しフィードバックする開発者に丸投げしておくのではなくて、⽇々対話して状況と課題の把握に務める

これからの2週間分のやることを決める

2週間単位なので毎⽇開発とコミュニケーション
この2週間をふりかえり
早く形になるといっても少しずつ（設計〜開発〜テスト）
カイゼン点を決める

できたものを確認しフィードバックする早く(少しだけ)形にできることにどんな良さがあるでしょうか？

早く(少しだけ)形にできることの意義① フィードバックに基づく開発で、⽬的に適したシステムに近づけていく② 形にすることで、関係者の認識を早期に揃えられる③ システム、プロセス、チームに関する問題に早く気付ける④ チームの学習効果が⾼い⑤ 早く開発を始められる⑥ システムの機能同⼠の結合リスクを早期に解消できる⑦ 利⽤開始までの期間を短くできる⑧ 開発のリズムが整えられる⑨ 協働を育み、チームの機能性を⾼める

形にすることで早めに関係者の認識を揃えられる
そもそも、関係者(ビジネス側、ビジネスとチーム間、チーム内で)つくるものの解釈が異なっている。
最初から、完成型が構想できない。
誰かが正解を持っているわけではない。
ドキュメントですべてを書き尽くせない。
それはコードになる。

「形にするためのコミュニケーションの過程」や「形にしたものの動き」から共通理解を育める

つくるものやチームについての問題早く気付ける開発を⼀巡させるのが早いため、プロダクトやチームの問題に早く気付ける。
コードが書けない = バックログの完成の条件を詳細にする。

バックログが消化できない = チームに必要なタレントを巻き込む。
認識の齟齬が多い = コミュニケーションの内容、頻度の調整。
要件の実現⽅法が分からない = 技術的な実現可能性の検証。
改修時のデグレが多い = ⾃動回帰テストの充実。

チームの学習効果が⾼い「常に最初から同じメンバーで継続的に活動」が前提異なる担当者に伝達

伝達

伝達早く始められる
全ての要件を決めきる必要がない = 部分を後回しに出来る結合のリスクを早めに倒すこと常に結合。

Time to marketが短い
早いスプリントからリリースできる = 早く収益化できる。

サンクコストが⼩さくできる
早いスプリントから評価が出来るため、途中でやめられる。

開発チームのリズムを整えられるチームの実状に計画をあわせられる。

2週間を繰り返せば⽬的のものができるのか？
計画の検証やその為の各種活動は必要

これからの2週間分のやることを決める

やること決めるのは良いけど本当に開発ができるような状態になっているか？

こういう開発をやっていく
毎⽇開発とコミュニケーション
この2週間をふりかえり（設計〜開発〜テスト）
カイゼン点を決める
ためにはどんな前提が必要か？
開発がどこに着地できそうか確認する
やるべきことに優先度をつけるできたものを確認しフィードバックする開発者に丸投げしておくのではなくて、⽇々対話して状況と課題の把握に務めるアジャイル開発の前提① 常にカイゼンを指向すること② 対話コミュニケーションの重視（協働という認識）③ 経験者の参画④ プロダクトオーナーが時間を使えること⑤ どのくらいアジャイルな開発でいくのか決めておく⑥ システムの変更容易性を確保し続けるアジャイル開発の前提① 常にカイゼンを指向すること
最初から全ての⾏為が最適化されているわけではない② 対話コミュニケーションの重視（協働という認識）
対話しなければ、思っていたものとは違うモノができる③ 経験者の参画
先に「失敗」を知ることで回避ができる④ プロダクトオーナーが時間を使えることでなければ対話もできないし、出来るものも確認できない⑤ どのくらいアジャイルな開発でいくのか決めておくとはいえ、どのくらい探索的にやるのか？認識あわせる⑥ システムの変更容易性を確保し続ける開発チームの腕の⾒せ所（難易度は⾼い）どのくらいアジャイルな開発でいくか？

どのくらいアジャイルな開発でいくか？

ウォーターフォールか、アジャイルかではなく作るモノの明確さ度合い、チームの練度、PJ制約の強さ等で決める

協働のために最初に必要なこと= これからやることの認識を揃える

Photo on VisualHuntインセプションデッキ
技術的な解決策

エレベーター
ピッチ

期間を見極める

やらないことやることリスト

われわれはなぜここにいるのか
パッケージ
デザイン

プロジェクト
コミュニティ

Whyを明らかにする

トレードオフスライダー

なにがどれだけ必要か

夜も眠れない
問題

Howを明らかにする

Toshihiro Ichitani All Rights Reserved.

なぜインセプションデッキ？
「然るべき人が集まっているか」「プロジェクトが然るべき方向を向いているか」を明らかにする“チームメンバーが誰もいないところで合意したことを前提にしているから、プロジェクトがダメになる”
アジャイルサムライP44
Toshihiro Ichitani All Rights Reserved.

“プロジェクトを始める前に関係者の認識を合わせる”とは？

プロジェクトメンバーが互いに持っている期待を明らかにし適切に調整する。
（期待マネジメント）
Toshihiro Ichitani All Rights Reserved.

我われはなぜここにいるのか• 大事な理由その1• 大事な理由その2• 大事な理由その3<このプロジェクトの根幹に関わる理由を1つ、ここに書く
絶対に実現しなければいけないこととは？

エレベーターピッチ• [潜在的なニーズを満たしたり、潜在的な課題を解決したり] したい• [対象顧客] 向けの、
• [プロダクト名] というプロダクトは、• [プロダクトのカテゴリー] です。
• これは [重要な利点、対価に見合う説得力のある理由(プロダクトにお金を払いたい理由)] ができ、• [代替手段の最右翼] とは違って、• [差別化の決定的な特徴] が備わっている。

誰の何をどうやって解決するのか?

やらないことリスト
やる

やらない

あとで决めるスコープに何が入らないのか?

インセプションデッキ
技術的な
解決策

エレベーター
ピッチ

意外と内容がうすそう…

われわれはなぜここにいるのか期間を見極める

やらないことやることリスト

その通りです。

パッケージ
デザイン

トレードオフスライダー

なにがどれだけ必要かゼロから協働するチームを⽴ち上げるためにはこのレベルから合わせる必要があります。
(とはいえデッキの中⾝は必要なことばかり
プロジェクト
コミュニティ

Whyを明らかにする

夜も眠れない
問題

Howを明らかにする

Toshihiro Ichitani All Rights Reserved.

インセプションデッキ
技術的な解決策

エレベーター
ピッチ

期間を前提は⼀緒にやること 見極める

やらないことわれわれはやること
なぜここにリストいるのか パワポ書いたので⾒て置いて下さい…
パッケージ
デザインではなくトレードオフ
スライダー

なにがどれだけ必要かデッキのテーマをその場で⼀緒に考えることで合わせる認識の解像度を上げる(⾔語化してみること、その過程で認識を交換することで理解が深まる)
プロジェクト
夜も眠れないコミュニティ
問題

Whyを明らかにする

Howを明らかにする

Toshihiro Ichitani All Rights Reserved.

どのようにして学んでいくのか

チームの中で、そしてチームの外との間で共通の語彙を⼿に⼊れよういちばんやさしい “アジャイル・ジャーニー”
1段階⽬

勉強会・研修1ヶ⽉-2ヶ⽉間

・まずは基本的な語彙習得のための機会を作る
・研修のていで組織内外からメンターを招くのがてっとり早い
・諸事情で研修が組めない場合は勉強会を開こう

2段階⽬

サンドボックスPJ

2ヶ⽉-3ヶ⽉間

・チームメンバー以外の関係者が少ない or いないPJで始める
・途中で終わったとしても全く問題がない状況を選ぶ
・諸事情で業務にならない場合は野良プロジェクトを始める

3段階⽬

⼩規模PJ

3ヶ⽉-6ヶ⽉間

・⻑期間に及ぶ規模の⼤きなPJは勿論避ける。いざとなれば途中からいつものやり⽅で巻き返せるような⼩さなPJを選ぶ。
・メンターを招聘し「実践から学ぶ」ことを念頭に置く
Copyright Toshihiro Ichitani

Start with Why

⾏為から学ぶ

価値観

価値観

原則

原則

⾏動

⾏動

何のために(価値観)、どうやって(原則)、やるか(⾏動)型から⼊って、実際にやってみる
やってみる(⾏動)過程と結果から、だから、価値観をあわせるのが⼤事！
…⼤事だけど、容易ではない。

何が⼤事なのかを学び直す(原則)
その学びをより良くするためには？(価値観)Social Change (⾃分から変わる)
思えばXPとは、分断を認めそれを乗り越えるための価値観であった

コミュニケーション
勇気

シンプリティ

フィードバック

リスペクト

リモート

コミュニケーション

シンプリティ

フィードバック

勇気

リスペクト

DX

(状況や感情が⾒えにくい)(組織的な分断、前提や⽅針の不整合)

限られた接点ゆえ分断を直接的により重要つなぎ直す

シンプルでないと複雑なしがらみを伝わりきらない

単純な⽅向へ意識的に伝えないと実験や試⾏による良くならない学習を適⽤する

⾃分から踏み込み変えるという⾏為には切⽋を作る

勇気を必要とする

相⼿が⾒えない中で対⽴軸を作って争う

リスペクトがなければ疑⼼暗⻤になるのではなく、相⼿のイマココの状況を尊重するアジャイルによってアジャイルになる
Be agile by Agile

Photo on VisualHuntアジャイル開発をはじめよう仮説検証型アジャイル開発

選択の幅最⼤（セットベース）

検証
計画

仮説⽴案

スプリントプ(モデル化)

価値探索

ランニング

検証

開発計画
(リリースプラ

MVP特定ンニング)（正しいものを探す）

選択の振れ幅最⼩評価（ポイントベース）

スプリント
開発

アジャイル開発（正しくつくる）
スプリント
レトロスペク
ティブ

MVP検証

スプリント
レビュー

次の検証計画(価値探索)へ

スプリント開発をはじめられるようにする
レディ(準備OK)にする観点は2つ・プロダクト(初期段階として) 作るものが何か分かっている・チーム
お互いが何者かわかっていて、どうやって作るかが分かっている
プロダクトのレディイメージ(理想)理解
初期段階の構想さえ理解できずにスプリントを重ねるたびに最初は想定作り進めているという状況も珍しくないしなかった「作りたいこと」が分かってくレディる
最初の数スプリントで(初期段階として)レディ

何を作りたいのか全容が理解できている
スプリント
123456712345678

スプリント

2つのレディプロダクトのレディイメージ(理想)理解

レディ

レディにするのはプロダクトの理解(What)だけではない。
チームでどのように仕事を進めるのか(How)という理解も必要。
Howの理解が⼀致しないと、個々の活動が噛み合わず、成果につながらない。

チームワーク(How)の理解が進まない
スプリント
1234567

ゆえに、①プロダクトについては「ソフトウェアとして何を実現すればよいのか」の⾔語化②チームについては⼀緒に仕事を実際に⾏うことでやり⽅をあわせることが必要。

プロダクトの理解をレディにする①
ソフトウェア的に何を作るべきかの情報を整理し、理解する

MVP特定からスプリント開発がはじまるまでの期間=スプリントゼロ

プロダクトの理解をレディにする②
整理する対象の情報は「全体」「部分」2側⾯あるプロダクト全体に影響を及ぼす情報(プロジェクトやテーマ単位で検討)

・初期段階のPBL及びリリースプランニング
・アーキテクチャ設計
・ドメインモデル(どういう知識を扱うか)の特定
・上記を踏まえて、UIとしての情報設計・構造設計、概念レベルのデータ設計

部分を開発するために必要な情報(スプリント単位で検討)

・スプリントバックログ(SBL)
・SBLの実装に必要な機能やデータの設計
・各ページのレイアウト設計

全体に影響を及ぼす情報の整理を誤ると、後々の影響が⼤きくなる(部分を作り重ねていくことで分かってくる「全体」もありうる)プロダクトの理解をレディにする③

プロダクトの理解をレディにする④
どこまでスプリントゼロで詳細化するのか？
チームの練度とプロダクトの複雑さによって決まる

チームの練度：⾼いチームの練度：低い

事前の要件定義は詳細には不要。

どの程度の要件定義を⾏うかチームで決める

事前の要件定義は詳細には必要ではないが開発に時間がかかる可能性がある。開発期間に余裕をもたせたい事前の要件定義は詳細に必要。丁寧な⾔語化やイメージ作りができる期間を設ける

プロダクトの複雑さ：低い

プロダクトの複雑さ：⾼いチームの理解をレディにする①
チームビルドのための基本概念「タックマンモデル」

チームの理解をレディにする②チームビルドのための基本概念「成功循環モデル」

チームの理解をレディにする③
基本は仕事を「⼩さく、短く、⼀巡させる」共通理解がより深まる

⼀緒にやる
情報を⼀緒につくる(より時間を必要とする)

場作り
情報を伝え合うようにする(表⾯的な理解で済んでしまっていることがある)

⾒える化
情報を得られるようにする(情報への感度が低い⼈には透明性が⾼まらない)共通理解がより深まる

⼀緒にやる
情報を⼀緒につくる(より時間を必要とする)

場作り
情報を伝え合うようにする(表⾯的な理解で済んでしまっていることがある)

⾒える化
情報を得られるようにする(情報への感度が低い⼈には透明性が⾼まらない)

⼀つのタスクを⼀緒にやることで理解を深める(ペア、モブ)同期イベントを開催し状況及び意思決定を協働で⾏う

ツールを使って情報を⾒えるようにする(共同所有する)

チームの理解をレディにする④
タックマンモデル☓成功循環モデル

チームの理解をレディにする⑤
⾮⽇常と⽇常を使わけるチームビルディング「⼩さく、短く、⼀巡させる」は⽇常におけるチームビルド。
形成期においては意図的なチームビルドも理解を促すためには必要。
⾮⽇常のチームビルドとして、Workshopを意識的に開催する。

共通理解を育むための3つの⽅法
・インセプションデッキ
・ドラッカー⾵エクササイズ
・ワーキングアグリーメント

チームの理解をレディにする⑥
理解するべきことプロジェクト・プロダクトレベル

⽅法

⽬的や⽬標、前提や制約、優先基準
インセプションデッキ

チームメンバーレベル

考え⽅や得意技
トラッカー⾵エクササイズ

チーム活動レベル共同のためのルール、約束事
ワーキングアグリーメント

チームの理解をレディにする⑦

チームの理解をレディにする⑧

チームの理解をレディにする⑨「スプリント1」が基礎になる
プロダクトやチームの理解が⼗分に深まったか計測する⼿段=「スプリント1の結果」
プロダクトやチームの準備を進めて臨んだスプリント1。
その結果が、思うようなものにならなかったときにどう捉えるか？
「最初だから、仕⽅ない。そのうちよくなっていくだろう」では成り⾏き任せ。
スプリントゼロの活動の結果としての「プロダクト」と「チーム」が存在していると捉えて、どういうインプットや時間が⾜りていないのかを分析すること。
例えば…
アウトプットがほとんどなかった = PBLの詰め⽅が⽢いのかもしれない
スクラムイベントがピリッとしない = スクラムへの基本的な理解が⾜りない
デモがまともにできない = 完成の定義が無いあるいはずれているスクラムイベントをはじめようプロダクトオーナー

開発チーム

スプリント
バックログ

プロダクト

スクラムマスター

バックログ

インクリメント

ステークホルダープロダクトオーナー

開発チーム

スプリント
バックログ

プロダクト

スクラムマスター

バックログ

全体の計画
何をどのくらいの期間で作ろうとしているのか？を⾒⽴てる。
インクリメント
おおよそ作りたい範囲(ベース)を実現しようとしたら、何スプリント必要なのか？ これを開発期間中予測し続ける。
ステークホルダープロダクトオーナー

開発チーム

スプリント
バックログ

プロダクトスクラムマスター

バックログ

反復毎の計画
インクリメント
このスプリント(1-2週間)で何を実現したいかを決める会合。

ステークホルダープロダクトオーナー

開発チーム

スプリント
バックログ

プロダクト

スクラムマスター

バックログ

開発
インクリメント
機能のリストに基づき、開発チームが作り進めていく。
状況の同期や問題検出を⾏なうべく、⽇々短い会合を開く(“デイリースクラム”と呼ぶ)

ステークホルダープロダクトオーナー

開発チーム

スプリント
反復毎に確認する
バックログ
スプリントプランニングで決めたことがどのように実現できているかを確認する会合。開発チームが作ったモノをデモし、プロダ
スクラムマスター

プロダクト
クトオーナー及び関係者がそれを確認、フィードバックする。
バックログ

インクリメント

ステークホルダープロダクトオーナー

開発チーム

スプリント
反復毎にふりかえる
バックログ
チーム全体でふりかえりを⾏なう。プロセス、仕事の進め⽅としてどのような問題があるか、またそのためのカイゼン策を全員でスクラムマスター

プロダクト検討する会合。
バックログ

インクリメント

ステークホルダーアジャイル開発運営の2本柱スプリントプランニング
スプリントレビュースプリントプランニング

スプリントの活動
この2週間をふりかえり
カイゼン点を決める

毎⽇開発とコミュニケーション（設計〜開発〜テスト）

スプリントレビュー

なぜ、重要なのか？
この2つが運営の「レバー」そのもの
スプリントプランニング

予測する

スプリント開発

スプリントレビュー

やってみる

結果を確かめる

プランニングへのフィードバック

スプリントプランニングで何がどこまでできるか予測する
スプリントレビューで結果を⾒て、次に⾏うべきことを判断する
つまり、繰り返せば繰り返すほどプランニングの正確性は⾼まるスプリントプランニングを実施しようプロダクトオーナー

開発チーム

スプリント
バックログ

プロダクト

スクラムマスター

バックログ

インクリメント

ステークホルダープロダクトバックログ(機能⼀覧相当)

スプリントバックログ(このスプリントでやる分)
スプリントプランニング
何をやる？

プロダクト

スプリント
ゴール

どうやってやる？

スプリント
ゴール
このスプリ

このスプリ

ントで実現ントで実現するべきするべきことこと？

ベロシティ

プロダクト
オーナー

開発
チーム

スクラムマスタースプリントプランニングとは？(⽬的)⽬的スプリントで実施するべきことの整理と合意形成を⾏う（スプリントの計画づくり）
・スクラムとは、スプリントという時間の箱を繋ぎ続けることで、必要な意味のあるプロダクトを⽣み出すゲームのこと・スプリントプランニングとは、その時間の箱の中で何を実現するかを決めるもの
・計画上「できたら良いね」で構成してしまうと、プロダクト作りは迷⾛する「ここまでならできる」という予想を⽴て、コミットメントを⾼められるよう開発チームおよびPOの両者で、計画作りを⾏う
・プロダクト作りとは持続していくものなので、ムリにムリを重ねるような計画作りにしてはならない。

プロダクトバックログ(機能⼀覧相当)

スプリントバックログ(このスプリントでやる分)
スプリントプランニング
何をやる？

プロダクト

スプリント
ゴール

どうやってやる？

スプリントゴール
このスプリ

このスプリ

ントで実現ントで実現するべきするべきことこと？

ベロシティ

プロダクトオーナー

開発チーム

スクラムマスタースプリントプランニングとは？(参加者)
参加者
開発チームおよびプロダクトオーナー
スクラムマスター・プロダクトに必要なものは何かを決められる役割(PO)・作りたいものをどうやって実現するかその⾒⽴ができる役割(開発チーム)
外野の皆さん(関係者)はご遠慮頂く。計画作りに恣意的な⼒学が働かないように。
専⾨家の知⾒が必要であれば、別の機会に集めるようにしておく。
(POが収集して、参考として取り⼊れるなど)
計画づくりは、⽴てた内容にコミットメントするメンバーで⾏う。

スプリントプランニングとは？(タイミング)
タイミング
スプリントの開始初⽇・スプリントの計画作りだから、スプリントの最初に⾏う・タイムボックスは、2週間スプリントの場合 → 4時間
1ヶ⽉スプリントの場合 → 8時間

プロダクトバックログ(機能⼀覧相当)

スプリントバックログ(このスプリントでやる分)
スプリントプランニング
何をやる？

プロダクト

スプリント
ゴール

どうやってやる？

スプリントゴール
このスプリ

このスプリ

ントで実現ントで実現するべきするべきことこと？

ベロシティ

プロダクトオーナー

開発
チーム

スクラム
マスター

スプリントプランニングとは？(インプット)
インプット
プロダクトバックログ
チームのベロシティ
これまで作ったプロダクト
スプリントゴールと制約
・プロダクトバックログから当該スプリントで何を作るか範囲を決める(ゆえに、プロダクトバックログの整理はプランニング前に⾏っておきたい)・範囲を決めるのに必要なのがスプリントゴール。POがスプリントで達成したいビジネスゴールを⾔語化して、持ってくる。
・どこまでできるかは、チームのベロシティ(速度)が前提となるスプリントプランニングとは？(アウトプット)
アウトプット
スプリントバックログ
洗練されたスプリントゴール
・プランニングを通じて、当該スプリントで何をやるべきなのかが明らかになる・スプリントバックログで、範囲と内容を明確に表現できていること(スプリントでやりきれるかどうかの⾒⽴てを⽴てるためやることがタスクまで落とし込まれている。もちろん誰がやるのかも)・プランニングでのやるべきことの選択を通じてスプリントゴールはよりはっきりとした内容になっていること。チームで何を実現すればこのスプリントが⽩星になるのか、分かるように。

スプリントプランニングとは？(事前準備)
事前準備
バックログリファインメント (バックログの洗練)・スプリントプランニングの前に⾏っておくとプランニングがスムーズに進む
・実施内容は、- プロダクトバックログの順序を⼊れ替える (形にしたいもの順に並び替え)- プロダクトバックログへの追加、詳細化※ 受け⼊れ条件(どういう条件を満たせばできたと⾔えるのか) の記載※ 開発チーム側が内容を⾒て、作れると判断できるか？（”開発レディ”）- プロダクトバックログの規模⾒積もり※ プランニングポーカーなどで開発チームが実施

プロダクトバックログ(機能⼀覧相当)

スプリントバックログ(このスプリントでやる分)
スプリントプランニング
何をやる？

プロダクト

スプリント
ゴール

どうやってやる？

スプリントゴール
このスプリ

このスプリ

ントで実現

ントで実現するべきするべきことこと？

ベロシティ

プロダクトオーナー

開発チーム

スクラム
マスター

スプリントプランニングとは？（内容①）
内容
2部構成／第1部 Whatパート
・第1部では、やるべき範囲を決める。
①プロダクトオーナーがスプリントゴールの達成に必要なプロダクトバックログの提案を⾏う②抽出したリストについて開発規模の⾒⽴てを⾏う※仕様の確認や、受け⼊れ条件のすりあわせを適宜⾏う(バックログリファインメントで実施済にしておきたい)③対象範囲がスプリントに収まりきるかを判断する。収まりきらない場合は、対象を再選別する。
※収まる収まらないはベロシティを⽤いて判断する。
ベロシティ…1スプリントあたりでチームが開発できる規模

スプリントプランニングとは？（内容②）内容
2部構成／第2部 Howパート
・第2部では、どうやって実現するかを⾒⽴てられるようにする。(How パート)
①選んだバックログの実現にあたり必要なタスクを洗い出す。
②タスクの⾒積もりを⾏い、プランニングの調整が必要か判断を⾏う。
※場合によって、スプリントバックログの抜き差しを⾏う③各スプリントバックログへのサインアップを⾏う。
※すべてを決めきる必要はない。スプリント中にもサインアップする。
④最後にスプリントゴールの内容、表現を洗練する。

スプリントレビューで結果を⾒て、次に⾏うべきことを判断する
つまり、繰り返せば繰り返すほどプランニングの正確性は⾼まる

スプリントプランニング

予測する

スプリント開発

スプリントレビュー

やってみる

結果を確かめる

プロダクトバックログ①作るべきものの理解 (何を作るべきか)②全体計画への理解 (あと何スプリント必要か)③チームの理解 (どんなチームか(⼒量、性格))スプリントプランニングをより上⼿く進める⼯夫規模⾒積もりの⽅法
プランニングポーカー
全員で⾒積もりを⾏うことで、「作るものに対する理解を共通にする (何を作るのか？どう作るのか？)」・所要時間ではなく「規模」の⾒積もりを⾏う※ 時間の⾒積もりは難しい。規模は相対⾒積もりがやりやすい。
・⼿順例
1. 最初に「規模=2」の基準となるプロダクトバックログアイテムを決める
2. 次のアイテムに対して、何倍の規模感になるかを全員が個々⼈で考える
3. ⼀⻫に、⾃分が考えた⾒積もりを提⽰する
4. 最⼤の数と最⼩の数を確認し、その差分理由をチームで捉える
5. 再度⾒積もりを⾏うキャパシティプランニング
ベロシティを⽤いたキャパシティ判断
ベロシティとは、「チームが1スプリントで開発できる規模」のこと
・ゆえに、最初のスプリントではベロシティの実績値はない。
最初は仮置をおこなう。数スプリント進んだところで実績値から算出する。
・スプリントバックログ対象として選んだアイテムの規模総数 ÷ ベロシティ= 1以下なら、キャパシティ内。1以上の場合は対象を⾒直す。
・あるいは、1以上の場合は「努⼒⽬標対象(できればここまではやる)」のアイテムを置く。
・ベロシティは3スプリント平均を⽬安に、定期的に再算出を⾏うスプリントゴールの決め⽅「われわれはなぜここにいるのか」を分割する
・われわれはなぜここにいるのかにあげた「ミッション」を実現するためにはどのようなステップがあるか検討する。
「ステップを全てクリアしたらミッションに到達できる」
・「1つのステップ = 1スプリントゴール」のイメージ
・つまり、スプリントゴールとは、実現することでミッション達成に近づけるようなもの。
・スプリントゴールが描けないということは、ミッション達成の道筋が⾒えていないということ。

プロダクトオーナー

開発チーム

スプリント
バックログ

プロダクト

スクラムマスター

バックログ

インクリメント

ステークホルダー