ざっくりわかるScrum and Team Foundation Server #tfsug

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

Scrum Boot Camp

2013/1/15-16 at Akihabara UDXScrum Regional Gathering Tokyo 2013 http://bit.ly/LtunLe

絶賛発売中絶賛発売中絶賛発売中絶賛発売中絶賛発売中絶賛発売中絶賛発売中

ざっくりわかる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はオプションコミュニケーションの改善と意思決定定型フォーマット – 昨日やったこと、今日やること、困っていること

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

スプリントレビュー開発チームの成果物をプロダクトオーナーが確認する

スプリントレビューよし頼んだ通りなのでOKです。完了だ！ 1番目にほしい 2番目にほしいあれ、ここクリックすると遷移先が違うね。これは未完了 3番目にほしいあ、こうなるのか。頼んだ通りだ 4番目にほしいから完了だけど、次のスプリントで機能追加しようか！ 5番目にほしい・・・この感じだと、秋ごろリ 99番目にほしいリースかな。次のスプリントはこの内容でどう？100番目にほしい

フィードバックループ短いスプリント単位で頻繁に確認と調整を行い製品をよりよくするもちろん仕事のやり方ももっとうまくできるはず

スプリントレトロスペクティブ人、関係、プロセス、ツールなどの観点で今回のスプリントを検査するうまくいったこと、今後の改善点を整理する今後のアクションプランを作る

繰り返す… #1 #2 #3 #Nタイムボックスを繰り返してPOがほしいものから順に出荷可能な製品を届け続けるうまく届けられるように改善し続ける

スクラムマスター このプロセスがうまくまわるようにする 妨害の排除 支援と奉仕（サーバントリーダーシップ） 教育、ファシリテート、コーチ、推進役

ワークショップここまで説明した内容を１枚の絵に描いてみましょう。 – 4人でグループになってください。 – 絵は2人で１枚作ってください。 – 5分で書き、3分でグループ内で議論します。 – これを2回やります。

プロダクトオーナースクラムマスターチーム (6±3人) ステークホルダー製品に対して責任をもち機能スクラムプロセスがうまくプロダクトの開発を行う。製品の利用者、出資者、管理職に優先順位を付けるいくようにする。製品の成功に向けて最大限などの利害関係者。鶏と称す外部からチームを守るの努力をコミットするプロダクトバックログデイリースクラム製品の機能をストーリー形式で記載毎日チームが以下の３つの質問に答えるプロダクトオーナーが優先順位を付け、プラ・昨日やったことンニングポーカーで相対見積もり。・今日やること項目の追加はいつでも自由だが実施有無や優・困っていること先順位はPOが決める。バーンダウンチャート Doneの定義スプリントタスクの「推定残り時間」を何をもって「完了」とするかを更新してグラフにプロットする定義したリストスプリント計画会議プロダクトバックログを再度分析・評価し、スプリントそのスプリントで開発するプロダクトバック最大4週間までのタイムボックスログアイテムを選択する。また選択した項目各スプリントの長さは同一。この間は外部をタスクにばらすからの変更を受け入れない複数回タスクス時間で見積もりプリン毎日の繰り返しトをスプリントバックログスプリントレビューふりかえり出荷可能な繰そのスプリント期間中に行うスプリント中の成果であるりスプリントの中での改善事項製品の増分返タスクのリスト動作するソフトウェアをデモを話合い次に繋げるするす

ざっくりわかる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 Process プロセスベースのクライアント Template アプローチ Team Explorer プロジェクト管理 Office 要求管理バージョン Visual 管理 Team SQL Studio テストケース Foundation Server Server 管理 Web ビルド自動化 Access レポート SharePoint

プロセステンプレート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に）。

スプリントスプリントバックログ計画会議第1部計画会議第2部グルーミング WHAT HOWPOを中心に、製品の開発に POとチームを中心にスプリチームを中心に選択したPBI必要なPBIを作成したり、更ントで何を作るか選択し相対をどのようにこなすのか決め新し、並べ替える見積を行う。不明点も明確化実時間で見積もる開発チームの過去 #1 #1 の速度(ベロシティ)をもとに取り #2 #2 組むPBIを決定。 #3 開発チームは内容開発チームにバッに関する質問をPO クログを供給する #4 に行う。第2部でのに必要十分なだ作成したタスクの実際の作業タスク。け新たに作成した #5 合計時間がキャパ何が出来たらタスクり更新する。それシティを超える場が完了するか明らかがないと開発チー #6 合は下から除外にする。個々のタスムは仕事ができな受け入れ基準とスクはDoneの定義の該いプリントレビュー当箇所を満たす必要で成果を検証があるReadyなPBI ReadyではないPBI Doneの定義• 受け入れ基準が明確 • 受け入れ基準が不明確チームとして定めた「出荷可能な製品」を作• デモ手順を決められるまたはない成するために実施しなければいけないことの• 可能な限り独立 • デモ手順が分からない一覧。例えば、ユニットテストする、カバ• 見積可能 • 見積不可能レージN％、リリースノートを書く等。Done• 適切な大きさ • 巨大なサイズの定義なくしてのScrumはあり得ない。

相対的に規模を見積もる

プランニングポーカー

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

タスクタスク＝スプリントバックログ項目 PBIはWhatPBI毎にタスクを出すタスクはHow

タスクの入力タスクを実施する残り何理想時間で際に実施者が自ら終わるかを常に更サインアップ新する（最低限デイリー着手するときにIn スクラムまでに） Progressに。完それによってバー了したらDoneにンダウンが更新されるどうなったらそのタス TFSのboard上でのドラッグアンドドクが完了なのか、成果ロップでもOK 物は何かを明らかに

タスクボード(TFS)

妨害(Impediment)リスト優先順位をつける (問題解決のROI) チームがもっとうまく仕事を問題は具体的に記するために妨害になっている述する(障害解消ことを登録するの定義をする) (Scrumでの正式な成果物ではない)• チームで解決できないものはスクラムマスターが解決に向けて取り組む• このリストにも優先順位が必須。大きな問題から解決すること• リスト内の項目の数を多くし過ぎたり滞留時間を長くし過ぎてはいけない

大事なことツールによって対面のミーティングがなくなるわけではない

デイリースクラム http://bit.ly/LGDhk6

スプリント計画会議順序の入れ替え、網羅性の確認の容易性手間の軽減、再利用性、検索性コミュニケーション・会話の誘発★これらを踏まえてやり方を考える http://www.flickr.com/photos/fronx/3467961947/

ふりかえり指標データ改善に必要なデータをレポートから抽出して、対面で議論する！ (SQLServer Expressでは使えません) http://msdn.microsoft.com/ja-jp/library/dd380678(v=vs.110).aspx http://msdn.microsoft.com/ja-jp/library/dd380674(v=vs.110).aspx

とりあえず試してみる… https://tfspreview.com/

とりあえず試してみる http://www.microsoft.com/visualstudio/11/ja-jp/downloads

最後に伝えたいこと

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

http://www.ryuzee.com	1186
http://a-hum.unoke.pfu.co.jp	34
https://confluence.livesense.jp	19
https://twimg0-a.akamaihd.net	3
http://127.0.0.1	2
https://si0.twimg.com	1
http://webcache.googleusercontent.com	1

ざっくりわかるScrum and Team Foundation Server #tfsug

by Ryuzee YOSHIBA on Jul 13, 2012

Accessibility

Categories

Upload Details

Usage Rights

7 Embeds 1,246

Statistics