Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
スクラム開発を始めよう!
TFS を使った日常コミュケーションとチームワーク
1
ソフトバンク・テクノロジー株式会社(シニアエンジニア)古賀 慎一
第10回 Plus Programming .net 勉強会 - 2014年12月20日(土)
...
セッションのゴール
 スクラム開発での 日常コミュニケーションとチームワーク を理解する
 TFSでスクラム開発 を行う具体的なイメージを持つ
 自社案件にTFSスクラム開発を 採用 出来るか?検討出来るようになる
TFS を使って スク...
自己紹介
古賀 慎一
ソフトバンク・テクノロジー株式会社 シニアエンジニア
 クラウドサービス Online Service Gate® 開発部門等の技術主任
今年事例になったときは マネージャを兼務
 前職では 某大手 情報サイトのデータ...
アジェンダ
1. 前提 : TFSとスクラム開発の関係
2. TFS の具体的な使い方 : 日常コミュニケーションとチームワーク
3. まとめ:スクラムの目的と意図・スプリントの流れ
4
前提
Team Foundation Server とスクラム開発の関係
5
TFSを使っていますか?
 Team Foundation Server(TFS) を既に 導入済みの チーム を想定
 TFS には オンプレ版 と クラウド版 があります
 msdn あれば無料
 Visual Studio Onl...
TFSで開発プロセスを取り扱おう
TFS をソース バージョン管理だけでなく
タスク管理・工程管理に使用して
品質を高く、より簡単に、より柔軟に、
スケジュールの調整が出来るようにならないか?
7
Team Foundation Server
...
ウォーターフォールとスクラムの違い (1)
8
アジャイル
Agile software development
スクラム・反復開発
Scrum, Iterative and Incremental Development
ウォーターフォール
...
ウォーターフォールとスクラムの違い (2)
9
アジャイル
Agile software development
スクラム・反復開発
Scrum, Iterative and Incremental Development
ウォーターフォール
...
アジャイル
Agile software development
スクラム・反復開発
Scrum, Iterative and Incremental Development
ウォーターフォール
Waterfall development
ユー...
アジャイル
Agile software development
スクラム・反復開発
Scrum, Iterative and Incremental Development
ウォーターフォール
Waterfall development
スク...
TFS の具体的な使い方
日常コミュニケーションとチームワーク
12
日常コミュニケーション
タスクボード(リアルタイム報告 / 見える化)
デイリースクラム(日次報告)
スプリント計画(週次報告)
振り返り(PDCA)
13
タスクボード
リアルタイム報告 / 見える化
14
まず個人の使い方から
タスクの作り方は
後で説明します
15
タスクボードで自分のタスクを確認
 今日~今週中にやるべきタスク一覧
 タイトル
 見積もり上の残時間
 自分の名前
16
ログ出力メソッド
の単体テスト実装
古賀 慎一 3
※イテレーションが 1週間 の場合
毎朝確認!
タスクの作業開始と作業完了
 TODO が今日やるべきタスク
 IN PROGRESS に移動して作業開始
 完了したら DONE に移動
 マウスで移動可
 設定変更して保存でも可
17
作業開始 作業完了
TODO IN PROG...
Visual Studio でのチェックインと関連付け
 ソースのチェックインにタスクを指定
 どのタスクのための変更か?
 そのまま「作業完了」に出来る
 作業中のままにも出来る
18
作業開始 作業完了
TODO IN PROGRE...
タスクボードで自分のタスクの進捗を見える化
個人の視点
 今日、自分が何を完了できればオンスケなのか?理解して作業
チームワークの視点
 各自が進捗をリアルタイムで見える化して報告
 何のためにソース変更したのか?記録を残し、事故を防...
スクラムでのタスクボード ワンモアポイント
チームワークの視点
 自分が遅れたらすぐアラート 阻害要因は?上司に調整を頼めるかな?
 他の人は遅れてないかな? 自分の作業が終わったら助けられるかな?
20
デイリースクラム
日次報告
21
デイリースクラムでもタスクボードを確認
 毎日決まった時間に 1日1回
 メンバー全員で集まって各自報告
 1日で完了したタスク
 これから1日でやるタスク
 阻害要因、課題
22
TFSならタスクボードだけで準備 OK
 メモなど事前準備無くても
自分のタスクを示しながら報告可能
 タスク DONE への移動は事前に
23
 1人数分間で報告、全体で15分程度
 議論になりそうなら、その話題は別途会議
絶対!
自分のタスクは1日で完了できるか?
 今日やるべきタスクをすべて
IN PROGRESS に移動してしまおう!
 合計時間が 大きく超えていたら
(努力で頑張るのではなく)調整を
 合計時間が少なかったら他タスクを
24
作業開始
TOD...
チームは今週のタスクを完了できるか?
 バーンダウンを見ると、チーム全体の進捗が順調か?わかる
25
3
(タスクの残時間合計の推移)
対策が必要な状態
バーンダウン
手を打つ!
正常
デイリースクラムで現代病=メール を防ぐ
メールで仕事だと
 隣の人にも声をかけずにメールで返事
 結論が言えない、指示が出来ない、長い返信を全員に何度も読ませる
 「以下の通り」「掲題の通り」・・・
 情報共有が適切に出来ず 手戻り...
デイリースクラムでホウレンソウの頻度を最適化
 ホウレンソウをやり過ぎると上司はパンクする
 やらなすぎると上司には何が起きているか?わからないので、早く手が打てない
 適度なホウレンソウ = 1日1回の報告
 毎日報告・相談することで...
スクラムでの ワンモアポイント
 リーダーや上司に報告するのではなく メンバー全員 に共有
 チームの誰かが問題に気付く!
 個人が、自分の仕事だけに注目して、他人に興味が無くなる のを防ぐ
 リーダーや上司に責任を押しつけず
チーム主...
スプリント計画
週次報告
29
いよいよ
タスクの作り方
を説明します
30
ウォーターフォールでの開発の流れ
 最初に全行程 の「タスク」を決定
PMが工数を見積もる
 事前に計画したスケジュールに従って
「タスク」を実行
 前工程が完了したら次の工程を行う
 進捗の遅れに気付きにくく、早く手を打てない
31全...
スクラムでの開発の流れ
 最初にやるべき事「バックログ」を決定
おおよその見積もりと優先度を決める
 週初めに今週やる「タスク」を決定
メンバー全員で見積もる
 週終わりにタスクが終わったか?確認
 終わらなそうなら、日次・週次で手を打...
見積もり方・予実を確認するタイミングが異なる
33PMが 全て最初に計画しておくやることは最初におおよそ決めておく
今やることを見積もる
≑ これが完了したか?管理
1Week 1Week 1Week
全員で
TFS の機能・バックログ・タスク の関係
TFS では以下の順に親子関係
機能
Features
バックログ・必要条件 ・ストーリー
Backlog items, Requirements, Stories
タスク
Tasks
34※タ...
バックログ・タスク とイテレーション期間の関係
35
1Week 1Week 1Week
スクラム ウォーターフォール
バックログ
Backlog items
必要条件
Requirements
タスク
Tasks
※機能 はバックログを束ねる...
ウォーターフォールでは WBS からタスクを作成
 イテレーション期間をWBSに合わせる
(※出来れば1週間前後になるように検討します)
 WBSから転記して必要条件とタスクを作成
36
まずホームの概要でイテレーション期間を設定
ホーム HOME
概要 Overview
スケジュールおよび
イテレーションの構成
Configure schedule and iterations ...
WBSを見ながら日付を設定します
...
次にバックログ画面で必要条件を全て入力
作業 WORK
バックログBacklogs
必要条件 Requirements
WBSを見ながら入力し、
[ 追加 Add ] します
38
必要条件のイテレーション期間を指定(1)
必要条件をマウスでクリックした
ままドラッグして、
イテレーション期間の上で離すと、
期間が指定できます
WBSを見ながら入力し、全て設定します
※必要条件は複数のイテレーション期間をまたげません。
期...
必要条件のイテレーション期間を指定(2)
イテレーション期間を
クリックして、
必要条件が表示されるか?
確認します
40
ここでタスクを登録します
必要条件の横の [+] を
クリックすると
タスクを入力する画面が
表示されます
41
必要条件を完成させるためのタスクを作成
WBSを見ながら、
全てのタスクを追加します
42
必要条件
Requirements
タスク
Tasks
イテレーション期間
Iterations※ウォータフォールではここまでPM・PLがひとりでやります
ここまで(ウォーターフォール+TFS)を
タスクの作り方
の基本とします
43
スクラムでは事前にバックログを作ります
44
1Week 1Week 1Week
 イテレーション期間を固定
(※ここでは1週間とします)
 製品を作るのに必要なバックログを全て
洗い出して登録
まずホームの概要でイテレーション期間を設定
ホーム HOME
概要 Overview
スケジュールおよび
イテレーションの構成
Configure schedule and iterations ...
1週間 固定で日付を設定します
45
次にバックログ画面でバックログを全て登録
作業 WORK
バックログBacklogs
バックログ項目
Backlog items
バックログを洗い出しながら、
[ 追加 Add ] します
46※バックログの洗い出しは PM・PLがひとり...
優先度・作業量・ベロシティから期間を検討
 ベロシティ = チームのキャパ
1週間で出来る作業量
最初は仮で。徐々にわかります。
 バックログの作業量
 バックログの優先度
 TFS が予測の線を引いてくれる
Forecast On...
バックログのイテレーション期間を指定(1)
バックログをマウスでクリック
したままドラッグして、
イテレーション期間の上で離すと、
期間が指定できます
予測に基づいて、必要な分を設定します
※バックログは複数のイテレーション期間をまたげません。...
バックログのイテレーション期間を指定(2)
イテレーション期間を
クリックして、
バックログが表示されるか?
確認します
49この計画で進めて問題ないのか?確認しましょう
ポイント
この計画(バックログ)で
問題ありません
となったら
50※全てのステークホルダーを納得させてください
今週のバックログのタスクを作ります
51
1Week 1Week 1Week
バックログ
Backlog items
タスク
Tasks
 これから イテレーション期間 が始まる時
(※週の最初の作業としてタスクを作ります)
 バックログを...
タスクを登録する方法は同じですが・・・
バックログの横の [+] を
クリックすると
タスクを入力する画面が
表示されます
52
スクラムでは全員で作業時間を見積もります
 プランニングポーカー(見積もりポーカー)
 全員でカードを一斉に出して見積もる
53
※ http://www.surviveplus.net/ja/archives/137 からPDFをダウンロ...
このチームではタスクがどのくらいで終わるか?
 実際の時間を予測して出す
 暗黙知(その人しか知らない)による難易度の
違いやかかる時間の違いを浮き彫りにする
 同じ数字を出せ!という空気にしない
逆になぜ数字が違うのか?全員で話し合お...
今週のバックログのタスクが全部決まったら
55
1Week 1Week 1Week
バックログ
Backlog items
タスク
Tasks
 バックログを実現するタスクを作成完了
 スプリント計画ミーティング完了
作業開始!
振り返り
PDCA
56
「振り返り」はTFSのサポートがありません
 振り返りミーティングはPDCA の CA
 1週間の終わりに、この1週間で問題がなかったか?みんなで確認
KPTを用紙に書いて持ち寄ろう
K (Keep) :続けたいこと – (C) 良かった...
スクラムの目的・意図を意識して振り返ろう
 毎日、自分のタスクを意識して作業できたか?
 タスクの見積もりと、実際の作業時間はどれだけ差があったか?
 うまく出来ていないなら、その要因はなんだろうか?
なぜ?なぜ?なぜ?・・・と、深掘りし...
まとめ
スクラムの目的と意図・スプリントの流れ
59
スクラム開発が始まる前に決めておくこと
 イテレーション期間(1 ~ 3週間)
 何を バックログ、タスク にするか?
 リリースタイミングとブランチのルール
 ソース バージョン管理のルールも変更を検討
 レビュー会を実施
60イテ...
スプリント開始~終了 1週間の流れ
 今回のバックログを決定(承認)
 スプリント計画で全員でタスク作成
見積もりポーカー
 デイリースクラムを実施
日次で進捗を報告・確認し合う
タスクを元に作業
 振り返りで改善する
61
1W...
スプリント計画で問題がわかったとき
タスクを見積もった結果、
1週間では終わらないことがわかった時
次回以降にバックログの一部をリスケ
あるいは、そもそも作らない
調整が出来るか?ステークホルダーと確認
62
1Week 1Week 1We...
デイリースクラムで問題がわかったとき
タスクの見積もりと進捗が乖離し
1週間では終わらないことがわかった時
次回以降にバックログの一部をリスケ
あるいは、そもそも作らない
調整が出来るか?ステークホルダーと確認
63
1Week 1Week...
見える化 : 知らないことには対応できない
 PMが全てを把握していなくても、
メンバーのアラートに気付いて適切に対応出来る
 ルールは少し増えたが、柔軟に対応出来ることでメンバーも納得・安心
64
見積もりのブレ 出荷スケジュールの調整 ...
スクラム開発 採用を検討する人に向けて
 TFS スクラム開発は日常コミュニケーションとチームワークの
具体的な方法を提供
 TFSは機能を自然に使えるところから導入することが最もベスト
 意図がわかればスクラム開発の作業自体はそんなに変...
Appendix
補足資料
66
TFSスクラム開発とリリース管理 MS事例 動画
 Architect Jump Start セミナー
2014.11.17 登壇
 Microsoft Virtual Academy
にスライド資料公開中
 Channel 9
でも見ら...
TFSスクラム開発・リリース管理 導入事例記事
 http://bit.ly/1m85aYY
 the Microsoft Conference 2014
では「リリースコストを 1/21 に
削減」と紹介されました
68
TFS導入のご相談窓口
 ご利用者数(20名様以上)のご相談窓口
下記担当者まで、ご一報いただければと思います。
日本マイクロソフト株式会社
デベロッパー エクスペリエンス&エバンジェリズム
統括本部 | 開発ツール推進部
シニアソリューショ...
Plus Programming .net 勉強会
http://www.facebook.com/PlusProgramming.net
70Copyright© 2014 Plus Programming .net All Rights R...
Upcoming SlideShare
Loading in …5
×

スクラム開発を始めよう!TFS を使った日常コミュケーションとチームワーク

6,610 views

Published on

第10回 Plus Programming .net 勉強会「TFSで エンタープライズ・アジャイル スクラム開発 ~Team Foundation Server でスクラム開発を始めよう!~」のセッションスライド

「TFSでソース管理はやっているけど、次はどうしたらいいの?」
スクラム開発やウォーターフォールの進捗管理・工程管理をTFSで取扱いたいけれど、具体的な操作方法がわからない。知りたいという声にお応えして、TFSでの実際のユーザーの操作を中心に解説します。

スクラムやウォーターフォールの考え方を整理しながら、具体的なイメージを持って、自社案件にTFSスクラム開発を採用できるか?検討できるようになることがゴールです。

Published in: Technology
  • Be the first to comment

スクラム開発を始めよう!TFS を使った日常コミュケーションとチームワーク

  1. 1. スクラム開発を始めよう! TFS を使った日常コミュケーションとチームワーク 1 ソフトバンク・テクノロジー株式会社(シニアエンジニア)古賀 慎一 第10回 Plus Programming .net 勉強会 - 2014年12月20日(土) Copyright© 2014 Plus Programming .net All Rights Reserved.
  2. 2. セッションのゴール  スクラム開発での 日常コミュニケーションとチームワーク を理解する  TFSでスクラム開発 を行う具体的なイメージを持つ  自社案件にTFSスクラム開発を 採用 出来るか?検討出来るようになる TFS を使って スクラム開発 を始められるようになろう! 2
  3. 3. 自己紹介 古賀 慎一 ソフトバンク・テクノロジー株式会社 シニアエンジニア  クラウドサービス Online Service Gate® 開発部門等の技術主任 今年事例になったときは マネージャを兼務  前職では 某大手 情報サイトのデータ入稿システム や FWパッケージを開発  最近は アーキテクチャ・フレームワーク を考えたり、マネージメントが中心  「仕組み」作りで 如何に高品質・低コストで早い開発を実現できるか? 3 TFS RM 導入 Rapid Release
  4. 4. アジェンダ 1. 前提 : TFSとスクラム開発の関係 2. TFS の具体的な使い方 : 日常コミュニケーションとチームワーク 3. まとめ:スクラムの目的と意図・スプリントの流れ 4
  5. 5. 前提 Team Foundation Server とスクラム開発の関係 5
  6. 6. TFSを使っていますか?  Team Foundation Server(TFS) を既に 導入済みの チーム を想定  TFS には オンプレ版 と クラウド版 があります  msdn あれば無料  Visual Studio Online なら5人まで無料 http://www.microsoft.com/ja-jp/dev/products/visual-studio-online.aspx 6 TFS on-premises Visual Studio Online
  7. 7. TFSで開発プロセスを取り扱おう TFS をソース バージョン管理だけでなく タスク管理・工程管理に使用して 品質を高く、より簡単に、より柔軟に、 スケジュールの調整が出来るようにならないか? 7 Team Foundation Server or Visual Studio Online Visual Studio スクラム手法 コレを使ってみよう
  8. 8. ウォーターフォールとスクラムの違い (1) 8 アジャイル Agile software development スクラム・反復開発 Scrum, Iterative and Incremental Development ウォーターフォール Waterfall development 毎週計画・柔軟に変更 事前に全て計画・変更なし 仕様書なし 全て仕様書を作成 新しいチャレンジ向き やり慣れた仕事向き 少人数 大人数 ※わかりやすく説明するために、多少誇張した表現になっています 必要な仕様書を作成 事前に計画・必要に応じて変更
  9. 9. ウォーターフォールとスクラムの違い (2) 9 アジャイル Agile software development スクラム・反復開発 Scrum, Iterative and Incremental Development ウォーターフォール Waterfall development 全員で見積もり 最初に見積もり済み (メンバーは見積もらない) 毎週リリース 1回だけリリース 毎週の成果物が全て WBSで厳密に管理 全員の意欲・スキルが とても高い事が必須 PM・設計者のスキルが とても高いことが必須 ※わかりやすく説明するために、多少誇張した表現になっています ある程度の期間毎にリリース 期間ごとに予実を確認
  10. 10. アジャイル Agile software development スクラム・反復開発 Scrum, Iterative and Incremental Development ウォーターフォール Waterfall development ユーザーストーリー User Story バックログ Backlog 必要条件 Requirement スクラム手法 (日常コミュニケーションとチームワークのプラクティスやプロセス) タスクボード ≑ リアルタイム報告 デイリースクラム ≑ 日次報告 スプリント計画・振り返り ≑ 週次報告 情報共有 や 進捗を確認・管理するベストプラクティス どの開発プロセスでもスクラム手法を追加可能 10※わかりやすく説明するために、多少誇張した表現になっています
  11. 11. アジャイル Agile software development スクラム・反復開発 Scrum, Iterative and Incremental Development ウォーターフォール Waterfall development スクラム手法 (日常コミュニケーションとチームワークのプラクティスやプロセス) MSF for Agile Software Development 2013.3 Microsoft Visual Studio Scrum 2013.3 MSF for CMMI Process Improvement 2013.3 TFS標準機能・テンプレート のイメージ 11※わかりやすく説明するために、多少誇張した表現になっています どのテンプレートも「タスクボード」などスクラム手法が使える これを説明します!
  12. 12. TFS の具体的な使い方 日常コミュニケーションとチームワーク 12
  13. 13. 日常コミュニケーション タスクボード(リアルタイム報告 / 見える化) デイリースクラム(日次報告) スプリント計画(週次報告) 振り返り(PDCA) 13
  14. 14. タスクボード リアルタイム報告 / 見える化 14
  15. 15. まず個人の使い方から タスクの作り方は 後で説明します 15
  16. 16. タスクボードで自分のタスクを確認  今日~今週中にやるべきタスク一覧  タイトル  見積もり上の残時間  自分の名前 16 ログ出力メソッド の単体テスト実装 古賀 慎一 3 ※イテレーションが 1週間 の場合 毎朝確認!
  17. 17. タスクの作業開始と作業完了  TODO が今日やるべきタスク  IN PROGRESS に移動して作業開始  完了したら DONE に移動  マウスで移動可  設定変更して保存でも可 17 作業開始 作業完了 TODO IN PROGRESS DONE 必ず!
  18. 18. Visual Studio でのチェックインと関連付け  ソースのチェックインにタスクを指定  どのタスクのための変更か?  そのまま「作業完了」に出来る  作業中のままにも出来る 18 作業開始 作業完了 TODO IN PROGRESS DONE チェックイン時に 関連するタスクを選択
  19. 19. タスクボードで自分のタスクの進捗を見える化 個人の視点  今日、自分が何を完了できればオンスケなのか?理解して作業 チームワークの視点  各自が進捗をリアルタイムで見える化して報告  何のためにソース変更したのか?記録を残し、事故を防ぐ 19
  20. 20. スクラムでのタスクボード ワンモアポイント チームワークの視点  自分が遅れたらすぐアラート 阻害要因は?上司に調整を頼めるかな?  他の人は遅れてないかな? 自分の作業が終わったら助けられるかな? 20
  21. 21. デイリースクラム 日次報告 21
  22. 22. デイリースクラムでもタスクボードを確認  毎日決まった時間に 1日1回  メンバー全員で集まって各自報告  1日で完了したタスク  これから1日でやるタスク  阻害要因、課題 22
  23. 23. TFSならタスクボードだけで準備 OK  メモなど事前準備無くても 自分のタスクを示しながら報告可能  タスク DONE への移動は事前に 23  1人数分間で報告、全体で15分程度  議論になりそうなら、その話題は別途会議 絶対!
  24. 24. 自分のタスクは1日で完了できるか?  今日やるべきタスクをすべて IN PROGRESS に移動してしまおう!  合計時間が 大きく超えていたら (努力で頑張るのではなく)調整を  合計時間が少なかったら他タスクを 24 作業開始 TODO IN PROGRESS
  25. 25. チームは今週のタスクを完了できるか?  バーンダウンを見ると、チーム全体の進捗が順調か?わかる 25 3 (タスクの残時間合計の推移) 対策が必要な状態 バーンダウン 手を打つ! 正常
  26. 26. デイリースクラムで現代病=メール を防ぐ メールで仕事だと  隣の人にも声をかけずにメールで返事  結論が言えない、指示が出来ない、長い返信を全員に何度も読ませる  「以下の通り」「掲題の通り」・・・  情報共有が適切に出来ず 手戻り・コストロスが膨らむ、のを防ぐ 26
  27. 27. デイリースクラムでホウレンソウの頻度を最適化  ホウレンソウをやり過ぎると上司はパンクする  やらなすぎると上司には何が起きているか?わからないので、早く手が打てない  適度なホウレンソウ = 1日1回の報告  毎日報告・相談することで進捗の適切な把握・適切な対応が出来る  報告の内容・方法も決定 27
  28. 28. スクラムでの ワンモアポイント  リーダーや上司に報告するのではなく メンバー全員 に共有  チームの誰かが問題に気付く!  個人が、自分の仕事だけに注目して、他人に興味が無くなる のを防ぐ  リーダーや上司に責任を押しつけず チーム主体でセルフマネジメントする自立した組織になる 28
  29. 29. スプリント計画 週次報告 29
  30. 30. いよいよ タスクの作り方 を説明します 30
  31. 31. ウォーターフォールでの開発の流れ  最初に全行程 の「タスク」を決定 PMが工数を見積もる  事前に計画したスケジュールに従って 「タスク」を実行  前工程が完了したら次の工程を行う  進捗の遅れに気付きにくく、早く手を打てない 31全て最初に計画しておく
  32. 32. スクラムでの開発の流れ  最初にやるべき事「バックログ」を決定 おおよその見積もりと優先度を決める  週初めに今週やる「タスク」を決定 メンバー全員で見積もる  週終わりにタスクが終わったか?確認  終わらなそうなら、日次・週次で手を打てる 32やることは最初におおよそ決めておく 今やることを見積もる ≑ これが完了したか?管理 1Week 1Week 1Week
  33. 33. 見積もり方・予実を確認するタイミングが異なる 33PMが 全て最初に計画しておくやることは最初におおよそ決めておく 今やることを見積もる ≑ これが完了したか?管理 1Week 1Week 1Week 全員で
  34. 34. TFS の機能・バックログ・タスク の関係 TFS では以下の順に親子関係 機能 Features バックログ・必要条件 ・ストーリー Backlog items, Requirements, Stories タスク Tasks 34※タスクが実際に担当者が作業する内容、それを束ねている
  35. 35. バックログ・タスク とイテレーション期間の関係 35 1Week 1Week 1Week スクラム ウォーターフォール バックログ Backlog items 必要条件 Requirements タスク Tasks ※機能 はバックログを束ねる Features イテレーション期間 Iterations 一定(1週間) WBSに従いバラバラ
  36. 36. ウォーターフォールでは WBS からタスクを作成  イテレーション期間をWBSに合わせる (※出来れば1週間前後になるように検討します)  WBSから転記して必要条件とタスクを作成 36
  37. 37. まずホームの概要でイテレーション期間を設定 ホーム HOME 概要 Overview スケジュールおよび イテレーションの構成 Configure schedule and iterations ... WBSを見ながら日付を設定します 37
  38. 38. 次にバックログ画面で必要条件を全て入力 作業 WORK バックログBacklogs 必要条件 Requirements WBSを見ながら入力し、 [ 追加 Add ] します 38
  39. 39. 必要条件のイテレーション期間を指定(1) 必要条件をマウスでクリックした ままドラッグして、 イテレーション期間の上で離すと、 期間が指定できます WBSを見ながら入力し、全て設定します ※必要条件は複数のイテレーション期間をまたげません。 期間を一致させるか、別の必要条件に分けます。 39
  40. 40. 必要条件のイテレーション期間を指定(2) イテレーション期間を クリックして、 必要条件が表示されるか? 確認します 40
  41. 41. ここでタスクを登録します 必要条件の横の [+] を クリックすると タスクを入力する画面が 表示されます 41
  42. 42. 必要条件を完成させるためのタスクを作成 WBSを見ながら、 全てのタスクを追加します 42 必要条件 Requirements タスク Tasks イテレーション期間 Iterations※ウォータフォールではここまでPM・PLがひとりでやります
  43. 43. ここまで(ウォーターフォール+TFS)を タスクの作り方 の基本とします 43
  44. 44. スクラムでは事前にバックログを作ります 44 1Week 1Week 1Week  イテレーション期間を固定 (※ここでは1週間とします)  製品を作るのに必要なバックログを全て 洗い出して登録
  45. 45. まずホームの概要でイテレーション期間を設定 ホーム HOME 概要 Overview スケジュールおよび イテレーションの構成 Configure schedule and iterations ... 1週間 固定で日付を設定します 45
  46. 46. 次にバックログ画面でバックログを全て登録 作業 WORK バックログBacklogs バックログ項目 Backlog items バックログを洗い出しながら、 [ 追加 Add ] します 46※バックログの洗い出しは PM・PLがひとりではなく、チームでやりましょう
  47. 47. 優先度・作業量・ベロシティから期間を検討  ベロシティ = チームのキャパ 1週間で出来る作業量 最初は仮で。徐々にわかります。  バックログの作業量  バックログの優先度  TFS が予測の線を引いてくれる Forecast On 47 A#003 ベロシティ内で作業出来る範囲の予測 イテレーション期間 Iterations 作業量優先度 ※この例では A#003, A#004 となっているのが、他のスライドで Sprint 1, Sprint 2 となっているイテレーション期間です
  48. 48. バックログのイテレーション期間を指定(1) バックログをマウスでクリック したままドラッグして、 イテレーション期間の上で離すと、 期間が指定できます 予測に基づいて、必要な分を設定します ※バックログは複数のイテレーション期間をまたげません。 期間を一致させるか、別のバックログに分けます。 48
  49. 49. バックログのイテレーション期間を指定(2) イテレーション期間を クリックして、 バックログが表示されるか? 確認します 49この計画で進めて問題ないのか?確認しましょう ポイント
  50. 50. この計画(バックログ)で 問題ありません となったら 50※全てのステークホルダーを納得させてください
  51. 51. 今週のバックログのタスクを作ります 51 1Week 1Week 1Week バックログ Backlog items タスク Tasks  これから イテレーション期間 が始まる時 (※週の最初の作業としてタスクを作ります)  バックログを実現するタスクを作成 全員で!
  52. 52. タスクを登録する方法は同じですが・・・ バックログの横の [+] を クリックすると タスクを入力する画面が 表示されます 52
  53. 53. スクラムでは全員で作業時間を見積もります  プランニングポーカー(見積もりポーカー)  全員でカードを一斉に出して見積もる 53 ※ http://www.surviveplus.net/ja/archives/137 からPDFをダウンロードして印刷できます 13 を超える場合は タスクが大きすぎる 分割を検討しよう
  54. 54. このチームではタスクがどのくらいで終わるか?  実際の時間を予測して出す  暗黙知(その人しか知らない)による難易度の 違いやかかる時間の違いを浮き彫りにする  同じ数字を出せ!という空気にしない 逆になぜ数字が違うのか?全員で話し合おう 54 ※ http://www.surviveplus.net/ja/archives/137 からPDFをダウンロードして印刷できます ポイント
  55. 55. 今週のバックログのタスクが全部決まったら 55 1Week 1Week 1Week バックログ Backlog items タスク Tasks  バックログを実現するタスクを作成完了  スプリント計画ミーティング完了 作業開始!
  56. 56. 振り返り PDCA 56
  57. 57. 「振り返り」はTFSのサポートがありません  振り返りミーティングはPDCA の CA  1週間の終わりに、この1週間で問題がなかったか?みんなで確認 KPTを用紙に書いて持ち寄ろう K (Keep) :続けたいこと – (C) 良かったこと P (Problem) : 問題 - (C) 悪かったこと、やめたいこと T (Try) : 試したいこと – (A) 悪かったことの改善をどうやるか? 57
  58. 58. スクラムの目的・意図を意識して振り返ろう  毎日、自分のタスクを意識して作業できたか?  タスクの見積もりと、実際の作業時間はどれだけ差があったか?  うまく出来ていないなら、その要因はなんだろうか? なぜ?なぜ?なぜ?・・・と、深掘りして改善出来る方法を見つけ出す チーム主体でセルフマネジメントする自立した組織になる 58
  59. 59. まとめ スクラムの目的と意図・スプリントの流れ 59
  60. 60. スクラム開発が始まる前に決めておくこと  イテレーション期間(1 ~ 3週間)  何を バックログ、タスク にするか?  リリースタイミングとブランチのルール  ソース バージョン管理のルールも変更を検討  レビュー会を実施 60イテレーション タスク 1Week 1Week 1Week バックログ レビュー・リリース ルールを策定・明文化 = 自立した組織に導く
  61. 61. スプリント開始~終了 1週間の流れ  今回のバックログを決定(承認)  スプリント計画で全員でタスク作成 見積もりポーカー  デイリースクラムを実施 日次で進捗を報告・確認し合う タスクを元に作業  振り返りで改善する 61 1Week 1Week 1Week スプリント計画(週頭) 振り返り(週末) デイリースクラム(日次) 見積もり
  62. 62. スプリント計画で問題がわかったとき タスクを見積もった結果、 1週間では終わらないことがわかった時 次回以降にバックログの一部をリスケ あるいは、そもそも作らない 調整が出来るか?ステークホルダーと確認 62 1Week 1Week 1Week スプリント計画(週頭) 週1回の計画・報告のタイミングがある
  63. 63. デイリースクラムで問題がわかったとき タスクの見積もりと進捗が乖離し 1週間では終わらないことがわかった時 次回以降にバックログの一部をリスケ あるいは、そもそも作らない 調整が出来るか?ステークホルダーと確認 63 1Week 1Week 1Week デイリースクラム(日次) 1日一回の報告・計画修正のタイミングがある
  64. 64. 見える化 : 知らないことには対応できない  PMが全てを把握していなくても、 メンバーのアラートに気付いて適切に対応出来る  ルールは少し増えたが、柔軟に対応出来ることでメンバーも納得・安心 64 見積もりのブレ 出荷スケジュールの調整 人員の調達 解決 発見して対応 何も手を打てなければ「スクラム」も効果が無いので注意! TFS で 見える化
  65. 65. スクラム開発 採用を検討する人に向けて  TFS スクラム開発は日常コミュニケーションとチームワークの 具体的な方法を提供  TFSは機能を自然に使えるところから導入することが最もベスト  意図がわかればスクラム開発の作業自体はそんなに変わらない  理解して段階的に始めましょう 65
  66. 66. Appendix 補足資料 66
  67. 67. TFSスクラム開発とリリース管理 MS事例 動画  Architect Jump Start セミナー 2014.11.17 登壇  Microsoft Virtual Academy にスライド資料公開中  Channel 9 でも見られます 67http://www.microsoftvirtualacademy.com/training-courses/jumpstart_nov http://channel9.msdn.com/Events/Architect-Jump-Start-Seminar/20141117
  68. 68. TFSスクラム開発・リリース管理 導入事例記事  http://bit.ly/1m85aYY  the Microsoft Conference 2014 では「リリースコストを 1/21 に 削減」と紹介されました 68
  69. 69. TFS導入のご相談窓口  ご利用者数(20名様以上)のご相談窓口 下記担当者まで、ご一報いただければと思います。 日本マイクロソフト株式会社 デベロッパー エクスペリエンス&エバンジェリズム 統括本部 | 開発ツール推進部 シニアソリューションスペシャリスト 椎野 磨美(Shiino Mami) | mailto:mashiino@microsoft.com  ご利用者数(20名様未満)のご相談窓口 下記サイトの販売代理店様に直接、ご相談ください。 http://www.visualstudio.com/ja-jp/products/how-to- buy-vs 69
  70. 70. Plus Programming .net 勉強会 http://www.facebook.com/PlusProgramming.net 70Copyright© 2014 Plus Programming .net All Rights Reserved.

×