Upload
ryuzee-yoshiba
View
5.404
Download
3
Embed Size (px)
DESCRIPTION
2012/7/18に開催されたAgile Conference Tokyoでのセッション資料です。質問n
Citation preview
吉羽 龍太郎 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の定義 何をもって「完了」とするかを 定義したリスト
毎日の繰り返し
デイリースクラム 毎日チームが以下の3つの質問に答える ・昨日やったこと ・今日やること ・困っていること
バーンダウンチャート スプリントタスクの「推定残り時間」を 更新してグラフにプロットする
タスク 時間で見積もり
組み合わせ
フレームワークなので、他の方法論を取り入れることが可能
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の高い箇所から改善していく(初期、保守、教育のコストを踏まえる)
複数のオプションがあれば評価する
例えば要求の管理に問題?
なにが問題なんだろう?なぜ問題なんだろう?
あるべき要求管理はどんな方法か?
それはプロジェクトに適用可能か?
それはツールによってカバーできる?
いままでより作業が増えたり、効率が落ちることはないか?
投資が必要な場合、どのくらいで回収できる?
大事なこと
ツールによって 対面のミーティングがなくなる
わけではない
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とのうわさ!!!
最後に 伝えたい こと
方法論も ツールも 目的達成の道具!! あなたの目的はなんですか?