吉羽 龍太郎 Ryutaro YOSHIBA

アジャイルコーチ Web: http://www.ryuzee.com Twitter: @ryuzee 認定スクラムプロフェッショナル 認定スクラムマスター 認定スクラムプロダクトオーナー Microsoft MVP for Visual Studio ALM

Scrum Boot Camp

http://bit.ly/LtunLe

2013/1/15-16 at Akihabara UDX

Scrum Regional Gathering Tokyo 2013

絶賛発売中

絶賛発売中

絶賛発売中

絶賛発売中

絶賛発売中

絶賛発売中

絶賛発売中

ざっくりわかるSCRUM

http://www.scrum.org/scrumguides/

スクラムの公式ルールブック 今日の内容はこれに記載されている内容です

Scrumとは？

可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのもの

複雑で変化の激しい 問題に対応するための

フレームワーク

組み合わせ

フレームワークなので、他の方法論を取り入れることが可能

State of Agile Survey 2011 ©VERSIONONE

特徴

軽量

理解が容易

習得が非常に困難

環境の変化

ビジネスの速度が爆速に

– 新しいことを

– 競争相手がやる前に

チャレンジングな領域が増える

– R&D

– 新規サービス

– それ儲かる？

物事の予測の精度は？

– 高いはずがない…

必要なものはなんだろう？

全てを予測することはできない

http://bit.ly/LT89jU

従来型と異なるアプローチ

リソース

と期間で

総量規制

大事なものは先に！

欲しいものをリストにして 順位をつける。

順位は状況によって変わる。

1番目にほしい

2番目にほしい

3番目にほしい

4番目にほしい

5番目にほしい

・・・

99番目にほしい

100番目にほしい

プロダクト バックログ

http://bit.ly/N2WbSn

プロダクトオーナー

プロジェクトに１人必ず必要

製品の責任者(結果責任)

チームを活用してプロダクトの価値を最大化する

プロダクトバックログの管理者

優先順位の意思決定の最終決定権限をもつ

チームに相談できるが干渉はできない

http://bit.ly/ujXAf3

開発チーム

出荷可能なモノを作る

３人〜９人で構成

全員揃えば製品を作れる能力が揃う

上下関係なし

http://bit.ly/N39KRB

自己組織化

最良のやり方を 自分たちで決める

一定のリズムで仕事する

一定間隔で意思決定と作業と確認を行う。

–最大４週間の固定の期間

スプリント http://bit.ly/N35OjS

同じペースで!!

正

#1 #2 #3 #N

#1 #2 #3 #N

誤

スプリント計画会議

スプリントで開発 をするためには 計画が必要

プロダクトオーナーは何をほしいか（第一部）

開発チームはどれくらいできそうか（第一部）

開発チームはどうやってそれを実現するか（第二部）

1番目にほしい

2番目にほしい

3番目にほしい

4番目にほしい

5番目にほしい

・・・

99番目にほしい

100番目にほしい

スプリントバックログ

プロダクトバックログを具体的なタスクに分割する

タスクは後から増えることもある

1番目にほしい

2番目にほしい

3番目にほしい

4番目にほしい

5番目にほしい

・・・

99番目にほしい

100番目にほしい

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

タスク

さぁ開発だ

チームは出荷可能な

製品の増分を作る

出荷可能？

部品だけでは出荷できない

小さくても使えるものを作る

出荷可能？

ここまでできれば終わりだと思って

たんだけど… これもあれもできてないじゃない？

共通理解

完了の定義を作り、何をもって出荷可能かを定める。

コード レビュー

チェックイン ユニット テスト

カバレージ

ドキュメント セキュリティ 性能 デプロイ

!!!! 途中の縮小禁止 !!!! などなど

モノを作る

http://bit.ly/N4I8LV

チームで進める

http://www.flickr.com/photos/karthikc/333796551/

毎日！

デイリースクラムで チーム状況を確認

チームがスプリントゴールに向かって進んでいるかを検証。 残作業を追跡する。

http://bit.ly/N5MUJa

デイリースクラム

毎日、同じ時間、同じ場所で

15分一本勝負（延長戦はなし）

開発チームによる自分たちのための会議で開発チーム全員が参加

– SM/POはオプション

コミュニケーションの改善と意思決定

定型フォーマット

–昨日やったこと、今日やること、困っていること

スプリント終了まで進め!!

スプリントレビュー

開発チームの成果物を プロダクトオーナーが確認する

スプリントレビュー

1番目にほしい

2番目にほしい

3番目にほしい

4番目にほしい

5番目にほしい

・・・

99番目にほしい

100番目にほしい

よし頼んだ通りなのでOKです。完了だ！

あれ、ここクリックすると遷移先が違うね。これは未完了

あ、こうなるのか。頼んだ通りだから完了だけど、次のスプリントで機能追加しようか！

この感じだと、秋ごろリリースかな。次のスプリントはこの内容でどう？

フィードバックループ

短いスプリント単位で 頻繁に確認と調整を行い 製品をよりよくする

もちろん仕事の やり方ももっと うまくできるはず

スプリントレトロスペクティブ

人、関係、プロセス、ツールなどの観点で今回のスプリントを検査する

うまくいったこと、今後の改善点を整理する

今後のアクションプランを作る

繰り返す…

タイムボックスを繰り返して

POがほしいものから順に

出荷可能な製品を届け続ける

うまく届けられるように改善し続ける

#1 #2 #3 #N

スクラムマスター

このプロセスがうまくまわるようにする

妨害の排除

支援と奉仕（サーバントリーダーシップ）

教育、ファシリテート、コーチ、推進役

ワークショップ

ここまで説明した内容を１枚の絵に描いてみましょう。

– 4人でグループになってください。

– 絵は2人で１枚作ってください。

– 5分で書き、3分でグループ内で議論します。

– これを2回やります。

プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プランニングポーカーで相対見積もり。 項目の追加はいつでも自由だが実施有無や優先順位はPOが決める。

チーム (6±3人) プロダクトの開発を行う。 製品の成功に向けて最大限 の努力をコミットする

スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る

プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける

ステークホルダー 製品の利用者、出資者、管理職 などの利害関係者。鶏と称す

スプリントバックログ そのスプリント期間中に行う タスクのリスト

スプリント 最大4週間までのタイムボックス 各スプリントの長さは同一。この間は外部からの変更を受け入れない

スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する

ふりかえり スプリントの中での改善事項 を話合い次に繋げる

複数回スプリントを繰り返す

出荷可能な 製品の増分

スプリント計画会議 プロダクトバックログを再度分析・評価し、そのスプリントで開発するプロダクトバックログアイテムを選択する。また選択した項目をタスクにばらす

Doneの定義 何をもって「完了」とするかを 定義したリスト

毎日の繰り返し

デイリースクラム 毎日チームが以下の３つの質問に答える ・昨日やったこと ・今日やること ・困っていること

バーンダウンチャート スプリントタスクの「推定残り時間」を 更新してグラフにプロットする

タスク 時間で見積もり

ざっくりわかるTFS

What’s ALM

アプリケーション・ライフサイクル・マネジメント（ALM）とは、 ソフトウェア開発・保守を各アプリケーションのライフサイクルにわたって継続的にプロセス管理をする考え方である。 ALMは、業務管理とソフトウェア開発の融合により、要件管理、設計、実装、検証、バグトラッキング、リリース管理を、 ツールを使用してそれらの促進と統一化を実現することである。

Wikipediaより引用 http://bit.ly/N3LUbj

Visual Studio ALM

http://www.microsoft.com/visualstudio/11/ja-jp/products/alm

Team Foundation Server

Team Explorer

Web Access

SharePoint

Office

Visual Studio

Team Foundation

Server

プロジェクト 管理

要求管理

バージョン 管理

テストケース管理

ビルド自動化

レポート

Process Template

SQL Server

クライアント

プロセスベースの アプローチ

プロセステンプレート

Scrum / Agile / CMMIの3種類のプロセステンプレート

プロセスのイメージ

http://msdn.microsoft.com/en-us//library/ms400752%28v=vs.110%29

Visual Studio Scrum 2.0

プロジェクト 管理

要求管理

バージョン 管理

テストケース管理

ビルド自動化

レポート

Process Template [Scrum]4週間までのスプリントの繰り返し

[Scrum]プロジェクトの妨害事項(Impediments)の管理

[Scrum]プロダクトバックログによる要求の優先順位付

[Scrum]スプリントバックログによる作業の分割

[Scrum]バーンダウンやタスクボードによる進捗可視化

[XP]バージョン管理とコードの共同所有

[XP]テスト自動化と継続的インテグレーション

なんでXPの概念が混ざってるの？

Scrumではフレームワークの定義のみで、テスト自動化については触れられていない.しかしアジャイル開発においてはテスト自動化は必須

小規模リリースのたびに手動でテストするとコード

ベースが大きくなるにつれてテストコストが膨らむ

自動化しないとソフトウェア規模に応じて、テスト工数の占める割合が増加してき価値への投資が減少する

アジャイルかウォーターフォールかという話ではなく、現代のソフトウェアのライフサイクルを考慮すると、テスト自動化は当然の流れと言える

スプリント期間の設定

チームエクスプローラーの設定で、イテレーション(スプリント)期間を設定する。

スプリントの期間は、要求やビジネス環境の変化の度合いを考慮して決める プロジェクトの最初に決め、途中で変更しない 短い方がフィードバックプロセスは働きやすいが、チームへの負荷は大きくな

りやすい傾向にある チームのサイズにも依存する

プロジェクトの開始時点で、プロダクトオーナーとしてどの時期にどの程度の内容でリリースしたいかを決める（約束ではない）

プロダクトバックログ

タイトル、PBI（デフォルトはストーリー形式）、見積、受け入れ基準、ビジネス価値、優先順位を設定可能

PBI一覧

ストーリー （誰々が○○できる）

受け入れ基準 （何をもって完了か）

プロダクトバックログ

プランニングポーカーの結果を入力

見積は開発チーム全員で、スプリント計画第一部にて行う。 プロダクトオーナーとスクラムマスターは同席

必要に応じてバックロググルーミングやスプリント計画会議中にプロダクトオーナーに確認した受け入れ基準等を追加

スプリント計画会議の結果を受

けて入力

最初から全ての入力を詳細に行う必要はない。直近実施予定のバックログは詳細に（Readyに）。

ReadyなPBI • 受け入れ基準が明確 • デモ手順を決められる • 可能な限り独立 • 見積可能 • 適切な大きさ

スプリント 計画会議第1部

WHAT

スプリント 計画会議第2部

HOW

#1

#2

ReadyではないPBI • 受け入れ基準が不明確

またはない • デモ手順が分からない • 見積不可能 • 巨大なサイズ

バックログ グルーミング

#1

#2

#3

#4

#5

#6

POを中心に、製品の開発に必要なPBIを作成したり、更新し、並べ替える

POとチームを中心にスプリントで何を作るか選択し相対見積を行う。不明点も明確化

チームを中心に選択したPBIをどのようにこなすのか決め実時間で見積もる

開発チームにバックログを供給するのに必要十分なだけ新たに作成したり更新する。それがないと開発チームは仕事ができない

開発チームの過去の速度(ベロシティ)をもとに取り組むPBIを決定。開発チームは内容に関する質問をPOに行う。第2部で作成したタスクの合計時間がキャパシティを超える場合は下から除外 受け入れ基準とスプリントレビューで成果を検証

実際の作業タスク。何が出来たらタスクが完了するか明らかにする。個々のタスクはDoneの定義の該当箇所を満たす必要がある

Doneの定義 チームとして定めた「出荷可能な製品」を作成するために実施しなければいけないことの一覧。例えば、ユニットテストする、カバレージN％、リリースノートを書く等。Doneの定義なくしてのScrumはあり得ない。

相対的に規模を見積もる

プランニングポーカー

プロダクトバックログの管理

• Excelをクライアントとして利用することで、容易な更新を可能に。 • 再利用や加工しやすい（ただしその加工がムダではないか検討する） • マクロを組み、PBIを壁にも貼るというアプローチも！

タスク

PBI毎にタスクを出す PBIはWhat タスクはHow

タスク＝スプリントバックログ項目

タスクの入力

どうなったらそのタスクが完了なのか、成果物は何かを明らかに

タスクを実施する際に実施者が自ら

サインアップ

残り何理想時間で終わるかを常に更

新する （最低限デイリースクラムまでに） それによってバーンダウンが更新さ

れる

着手するときにIn Progressに。完了したらDoneに

TFSのboard上でのドラッグアンドド

ロップでもOK

タスクボード(TFS)

妨害(Impediment)リスト

チームがもっとうまく仕事をするために妨害になっている

ことを登録する (Scrumでの正式な成果物ではない)

• チームで解決できないものはスクラムマスターが解決に向けて取り組む • このリストにも優先順位が必須。大きな問題から解決すること • リスト内の項目の数を多くし過ぎたり滞留時間を長くし過ぎてはいけない

問題は具体的に記述する(障害解消の定義をする)

優先順位をつける (問題解決のROI)

大事なこと

ツールによって 対面のミーティングがなくなる

わけではない

デイリースクラム

http://bit.ly/LGDhk6

スプリント計画会議

順序の入れ替え、網羅性の確認の容易性

手間の軽減、再利用性、検索性

コミュニケーション・会話の誘発

★これらを踏まえてやり方を考える http://www.flickr.com/photos/fronx/3467961947/

http://msdn.microsoft.com/ja-jp/library/dd380678(v=vs.110).aspx http://msdn.microsoft.com/ja-jp/library/dd380674(v=vs.110).aspx

ふりかえり

改善に必要なデータをレポートから抽出して、対面で議論する！ (SQLServer Expressでは使えません)

指標データ

とりあえず試してみる…

https://tfspreview.com/

とりあえず試してみる

http://www.microsoft.com/visualstudio/11/ja-jp/downloads

最後に 伝えたい こと

Scrumも TFSも 目的達成の道具!! あなたの目的はなんですか？