吉羽 龍太郎 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

環境の変化

ビジネスの速度が爆速に

– 新しいことを

– 競争相手がやる前に

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

– R&D

– 新規サービス

– それ儲かる？

物事の予測の精度は？

– 高いはずがない…

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

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

http://bit.ly/LT89jU

作り過ぎのムダ

手待ちのムダ

運搬のムダ

加工のムダ

在庫のムダ

動作のムダ

不良をつくるムダ

システムの機能の利用割合

45 %

19 %

16 %

13 %

7 %

Standishの2000年の調査より

いつも使う

よく使う

たまに使う

ほとんど使わない

まったく使わない

64% の機能は、使われない

http://bit.ly/olku51

アジャイルマニフェスト 2001年に、ケント・ベック、マーティン・ファウラー、ケン・シュウェイバーら、17人によって採択されたAgileソフトウェア開発の原則を指す。

アジャイルマニフェスト

1. プロセスやツールより人と人同士の相互作用を重視する。

2. 包括的なドキュメントより動作するソフトウェアを重視する。

3. 契約上の交渉よりも顧客との協調を重視する。

4. 計画に従うことよりも変化に対応することを重視する。

アジャイルマニフェスト

1. プロセスやツールより人と人同士の相互作用を重視する。

2. 包括的なドキュメントより動作するソフトウェアを重視する。

3. 契約上の交渉よりも顧客との協調を重視する。

4. 計画に従うことよりも変化に対応することを重視する。

顧客満足を最優先し、 価値のあるソフトウェアを 早く継続的に提供します。

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

リソース

と期間で

総量規制

Scrum

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

フレームワーク

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

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

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

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

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

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

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

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

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

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

出荷可能な 製品の増分

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

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

毎日の繰り返し

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

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

タスク 時間で見積もり

組み合わせ

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

State of Agile Survey 2011 ©VERSIONONE

大事なものから先に！

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

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

1番目にほしい

2番目にほしい

3番目にほしい

4番目にほしい

5番目にほしい

・・・

99番目にほしい

100番目にほしい

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はあり得ない。

開発チームのミッション

チームは出荷可能な

製品の増分を作り続ける

出荷可能？

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

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

共通理解

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

コード レビュー

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

カバレージ

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

!!!! ツールの助けが必要 !!!! などなど

毎日何回も本番環境にデプロイできているか？ 顧客に頻繁に価値を届けられているか？

継続的デリバリー

継続的デリバリーとは、ソフトウェア全体のライフサイクルを通じて常にソフトウェアが本番環境にリリース可能であるということを意味する。 すなわちどのビルドもボタン一発で、完全に自動化されたリリースプロセスを通じてリリースする。 それによってビジネス側がビジネス状況に応じてリリース判断できるようになる。

繰り返し型の 開発

継続的 インテグレーション

継続的 デプロイ

継続的デリバリー

継続的デリバリー

繰り返し型の 開発

継続的 インテグレーション

継続的 デプロイ

継続的デリバリー

Scrum 要求に順位付け タイムボックス

による制御 検査と適用によ

る継続的改善 透明性の確保 自己組織型チー

ム 技術的プラク

ティスの定義なし

Scrum＋XP xUnit等による

テスト自動化 テスト駆動開発 コーディング規

約 ペアプロ等 常時出荷可能な

品質を保持 主に技術的プラ

クティスから構成される

Lean Just in Timeで

顧客が必要なものを必要なときに。

サイクルタイムを測定し改善する。

ビジネス活動そのもの

全体最適

フィードバックループ

短い時間間隔で 頻繁に確認と調整を行い 製品をよりよくする

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

Visual Studio ALM

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

顧客への継続的な価値の提供

What’s ALM

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

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

継続的フィードバック

製品価値を高めるために、プロダクト オーナーだけでなく、ステークホルダー からも継続的にフィードバックを受け取る

ステークホルダーに製品フィードバックを要求し一元管理する

Storyboardingを使って、要求を視覚的に整理し、フィードバックを得やすくする。

Feedback Clientをインストールすることで音声、画面ショット等とともにフィードバックする

Team Foundation Server

Team Explorer

Web Access

SharePoint

Office

Team Foundation

Server

プロジェクト 管理

要求管理

バージョン 管理

テストケース管理

ビルド自動化

レポート

Process Template

SQL Server

クライアント

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

Visual Studio

Team Foundation Server

Team Explorer

Web Access

SharePoint

Office

Team Foundation

Server

プロジェクト 管理

要求管理

バージョン 管理

テストケース管理

ビルド自動化

レポート

Process Template

SQL Server

クライアント

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

Visual Studio

データが一元管理され、再利用可能でどこからでもアクセスできるプラットフォーム

プロセス中心のアプローチで、プロジェクト特性にあわせてどのプロセスを選択するかを決める

その上で継続的にプロセス改善を行える

プロセステンプレート

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

プロセスのイメージ

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

例) Visual Studio Scrum 2.0

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

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

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

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

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

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

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

プロジェクト 管理

要求管理

バージョン 管理

テストケース管理

ビルド自動化

レポート

Process Template

プロセスの実装

何故XPの概念が混ざっているか？

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

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

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

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

何故XPの概念が混ざっているか？

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

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

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

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

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

ツール導入アンチパターン

全社で標準を作成したので○○を使え！

○○で他の会社はうまくいったらしいので使おう！

http://bit.ly/vj0b0v

No Silver Bullet

http://bit.ly/sygcE9

自分たちのプロセスは自分たちで進化させるしかない！

http://bit.ly/sygcE9

自分たちのプロセスは自分たちで進化させるしかない！

もちろん、現代のソフトウェア開発プロセスの方向性については、知識

を獲得しておく必要はある！

ツール導入のプロセス

いまのプロセスがどうなっているかを明らかにする(現状分析)

改善したいポイントをチームで整理する

ツールでカバーした方がよい箇所と、それ以外の箇所の整理

ROIの高い箇所から改善していく(初期、保守、教育のコストを踏まえる)

複数のオプションがあれば評価する

例えば要求の管理に問題？

なにが問題なんだろう？なぜ問題なんだろう？

あるべき要求管理はどんな方法か？

それはプロジェクトに適用可能か？

それはツールによってカバーできる？

いままでより作業が増えたり、効率が落ちることはないか？

投資が必要な場合、どのくらいで回収できる？

大事なこと

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

わけではない

MSにおけるデイリースクラム

http://bit.ly/LGDhk6

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では使えません)

指標データ

ツール導入を成功させる

みんなが分からない状態での導入は大変

ツールとプロセスの同時学習のコストへの考慮

導入バックログ(優先順位付け)

社内外からのプロジェクト支援体制の確立

とりあえず試してみる

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

2012年8月RTMとのうわさ!!!

とりあえず試してみる…

https://tfspreview.com/

最後に 伝えたい こと

方法論も ツールも 目的達成の道具!! あなたの目的はなんですか？