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

スクラム開発を始めよう!
TFS を使った日常コミュケーションとチームワーク
1
ソフトバンク・テクノロジー株式会社（シニアエンジニア）古賀慎一
第10回 Plus Programming .net 勉強会 - 2014年12月20日（土）
Copyright© 2014 Plus Programming .net All Rights Reserved.

セッションのゴール
 スクラム開発での日常コミュニケーションとチームワークを理解する
 TFSでスクラム開発を行う具体的なイメージを持つ
 自社案件にTFSスクラム開発を採用出来るか？検討出来るようになる
TFS を使ってスクラム開発を始められるようになろう！
2

自己紹介
古賀慎一
ソフトバンク・テクノロジー株式会社シニアエンジニア
 クラウドサービス Online Service Gate® 開発部門等の技術主任
今年事例になったときはマネージャを兼務
 前職では某大手情報サイトのデータ入稿システムや FWパッケージを開発
 最近はアーキテクチャ・フレームワークを考えたり、マネージメントが中心
 「仕組み」作りで如何に高品質・低コストで早い開発を実現できるか？
3
TFS RM
導入
Rapid Release

アジェンダ
1. 前提 : TFSとスクラム開発の関係
2. TFS の具体的な使い方 : 日常コミュニケーションとチームワーク
3. まとめ：スクラムの目的と意図・スプリントの流れ
4

前提
Team Foundation Server とスクラム開発の関係
5

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

TFSで開発プロセスを取り扱おう
TFS をソースバージョン管理だけでなく
タスク管理・工程管理に使用して
品質を高く、より簡単に、より柔軟に、
スケジュールの調整が出来るようにならないか？
7
Team Foundation Server
or
Visual Studio Online
Visual Studio
スクラム手法
コレを使ってみよう

ウォーターフォールとスクラムの違い (1)
8
アジャイル
Agile software development
スクラム・反復開発
Scrum, Iterative and Incremental Development
ウォーターフォール
Waterfall development
毎週計画・柔軟に変更事前に全て計画・変更なし
仕様書なし全て仕様書を作成
新しいチャレンジ向きやり慣れた仕事向き
少人数大人数
※わかりやすく説明するために、多少誇張した表現になっています
必要な仕様書を作成
事前に計画・必要に応じて変更

ウォーターフォールとスクラムの違い (2)
9
アジャイル
全員で見積もり最初に見積もり済み
（メンバーは見積もらない）
毎週リリース 1回だけリリース
毎週の成果物が全て WBSで厳密に管理
全員の意欲・スキルが
とても高い事が必須
PM・設計者のスキルが
とても高いことが必須
※わかりやすく説明するために、多少誇張した表現になっています
ある程度の期間毎にリリース
期間ごとに予実を確認

アジャイル
ユーザーストーリー
User Story
バックログ
Backlog
必要条件
Requirement
スクラム手法
（日常コミュニケーションとチームワークのプラクティスやプロセス）
タスクボード
≑ リアルタイム報告
デイリースクラム
≑ 日次報告
スプリント計画・振り返り
≑ 週次報告
情報共有や進捗を確認・管理するベストプラクティス
どの開発プロセスでもスクラム手法を追加可能
10※わかりやすく説明するために、多少誇張した表現になっています

アジャイル
スクラム手法
（日常コミュニケーションとチームワークのプラクティスやプロセス）
MSF for Agile
Software Development 2013.3
Microsoft Visual Studio
Scrum 2013.3
MSF for CMMI
Process Improvement 2013.3
TFS標準機能・テンプレートのイメージ
11※わかりやすく説明するために、多少誇張した表現になっています
どのテンプレートも「タスクボード」などスクラム手法が使える
これを説明します！

TFS の具体的な使い方
日常コミュニケーションとチームワーク
12

日常コミュニケーション
タスクボード（リアルタイム報告 / 見える化）
デイリースクラム（日次報告）
スプリント計画（週次報告）
振り返り（PDCA）
13

タスクボード
リアルタイム報告 / 見える化
14

まず個人の使い方から
タスクの作り方は
後で説明します
15

タスクボードで自分のタスクを確認
 今日～今週中にやるべきタスク一覧
 タイトル
 見積もり上の残時間
 自分の名前
16
ログ出力メソッド
の単体テスト実装
古賀慎一 3
※イテレーションが 1週間の場合
毎朝確認！

タスクの作業開始と作業完了
 TODO が今日やるべきタスク
 IN PROGRESS に移動して作業開始
 完了したら DONE に移動
 マウスで移動可
 設定変更して保存でも可
17
作業開始作業完了
TODO IN PROGRESS DONE
必ず！

Visual Studio でのチェックインと関連付け
 ソースのチェックインにタスクを指定
 どのタスクのための変更か？
 そのまま「作業完了」に出来る
 作業中のままにも出来る
18
作業開始作業完了
TODO IN PROGRESS DONE
チェックイン時に
関連するタスクを選択

タスクボードで自分のタスクの進捗を見える化
個人の視点
 今日、自分が何を完了できればオンスケなのか？理解して作業
チームワークの視点
 各自が進捗をリアルタイムで見える化して報告
 何のためにソース変更したのか？記録を残し、事故を防ぐ
19

スクラムでのタスクボードワンモアポイント
チームワークの視点
 自分が遅れたらすぐアラート阻害要因は？上司に調整を頼めるかな？
 他の人は遅れてないかな？自分の作業が終わったら助けられるかな？
20

デイリースクラム
日次報告
21

デイリースクラムでもタスクボードを確認
 毎日決まった時間に１日１回
 メンバー全員で集まって各自報告
 １日で完了したタスク
 これから１日でやるタスク
 阻害要因、課題
22

TFSならタスクボードだけで準備 OK
 メモなど事前準備無くても
自分のタスクを示しながら報告可能
 タスク DONE への移動は事前に
23
 1人数分間で報告、全体で15分程度
 議論になりそうなら、その話題は別途会議
絶対！

自分のタスクは１日で完了できるか？
 今日やるべきタスクをすべて
IN PROGRESS に移動してしまおう！
 合計時間が大きく超えていたら
（努力で頑張るのではなく）調整を
 合計時間が少なかったら他タスクを
24
作業開始
TODO IN PROGRESS

チームは今週のタスクを完了できるか？
 バーンダウンを見ると、チーム全体の進捗が順調か？わかる
25
3
（タスクの残時間合計の推移）
対策が必要な状態
バーンダウン
手を打つ！
正常

デイリースクラムで現代病=メールを防ぐ
メールで仕事だと
 隣の人にも声をかけずにメールで返事
 結論が言えない、指示が出来ない、長い返信を全員に何度も読ませる
 「以下の通り」「掲題の通り」・・・
 情報共有が適切に出来ず手戻り・コストロスが膨らむ、のを防ぐ
26

デイリースクラムでホウレンソウの頻度を最適化
 ホウレンソウをやり過ぎると上司はパンクする
 やらなすぎると上司には何が起きているか？わからないので、早く手が打てない
 適度なホウレンソウ = １日１回の報告
 毎日報告・相談することで進捗の適切な把握・適切な対応が出来る
 報告の内容・方法も決定
27

スクラムでのワンモアポイント
 リーダーや上司に報告するのではなくメンバー全員に共有
 チームの誰かが問題に気付く！
 個人が、自分の仕事だけに注目して、他人に興味が無くなるのを防ぐ
 リーダーや上司に責任を押しつけず
チーム主体でセルフマネジメントする自立した組織になる
28

スプリント計画
週次報告
29

いよいよ
タスクの作り方
を説明します
30

ウォーターフォールでの開発の流れ
 最初に全行程の「タスク」を決定
PMが工数を見積もる
 事前に計画したスケジュールに従って
「タスク」を実行
 前工程が完了したら次の工程を行う
 進捗の遅れに気付きにくく、早く手を打てない
31全て最初に計画しておく

スクラムでの開発の流れ
 最初にやるべき事「バックログ」を決定
おおよその見積もりと優先度を決める
 週初めに今週やる「タスク」を決定
メンバー全員で見積もる
 週終わりにタスクが終わったか？確認
 終わらなそうなら、日次・週次で手を打てる
32やることは最初におおよそ決めておく
今やることを見積もる
≑ これが完了したか？管理
1Week 1Week 1Week

見積もり方・予実を確認するタイミングが異なる
33PMが全て最初に計画しておくやることは最初におおよそ決めておく
今やることを見積もる
≑ これが完了したか？管理
1Week 1Week 1Week
全員で

TFS の機能・バックログ・タスクの関係
TFS では以下の順に親子関係
機能
Features
バックログ・必要条件・ストーリー
Backlog items, Requirements, Stories
タスク
Tasks
34※タスクが実際に担当者が作業する内容、それを束ねている

バックログ・タスクとイテレーション期間の関係
35
1Week 1Week 1Week
スクラムウォーターフォール
バックログ
Backlog items
必要条件
Requirements
タスク
Tasks
※機能はバックログを束ねる
Features
イテレーション期間
Iterations
一定（１週間） WBSに従いバラバラ

ウォーターフォールでは WBS からタスクを作成
 イテレーション期間をWBSに合わせる
（※出来れば１週間前後になるように検討します）
 WBSから転記して必要条件とタスクを作成
36

まずホームの概要でイテレーション期間を設定
ホーム HOME
概要 Overview
スケジュールおよび
イテレーションの構成
Configure schedule and iterations ...
WBSを見ながら日付を設定します
37

次にバックログ画面で必要条件を全て入力
作業 WORK
バックログBacklogs
必要条件 Requirements
WBSを見ながら入力し、
[ 追加 Add ] します
38

必要条件のイテレーション期間を指定(1)
必要条件をマウスでクリックした
ままドラッグして、
イテレーション期間の上で離すと、
期間が指定できます
WBSを見ながら入力し、全て設定します
※必要条件は複数のイテレーション期間をまたげません。
期間を一致させるか、別の必要条件に分けます。
39

必要条件のイテレーション期間を指定(2)
イテレーション期間を
クリックして、
必要条件が表示されるか？
確認します
40

ここでタスクを登録します
必要条件の横の [＋] を
クリックすると
タスクを入力する画面が
表示されます
41

必要条件を完成させるためのタスクを作成
WBSを見ながら、
全てのタスクを追加します
42
必要条件
Requirements
タスク
Tasks
Iterations※ウォータフォールではここまでPM・PLがひとりでやります

ここまで（ウォーターフォール+TFS）を
タスクの作り方
の基本とします
43

スクラムでは事前にバックログを作ります
44
1Week 1Week 1Week
 イテレーション期間を固定
（※ここでは１週間とします）
 製品を作るのに必要なバックログを全て
洗い出して登録

まずホームの概要でイテレーション期間を設定
ホーム HOME
概要 Overview
スケジュールおよび
イテレーションの構成
Configure schedule and iterations ...
１週間固定で日付を設定します
45

次にバックログ画面でバックログを全て登録
作業 WORK
バックログBacklogs
バックログ項目
Backlog items
バックログを洗い出しながら、
[ 追加 Add ] します
46※バックログの洗い出しは PM・PLがひとりではなく、チームでやりましょう

優先度・作業量・ベロシティから期間を検討
 ベロシティ = チームのキャパ
1週間で出来る作業量
最初は仮で。徐々にわかります。
 バックログの作業量
 バックログの優先度
 TFS が予測の線を引いてくれる
Forecast On
47
A#003
ベロシティ内で作業出来る範囲の予測
Iterations
作業量優先度
※この例では A#003, A#004 となっているのが、他のスライドで Sprint 1, Sprint 2 となっているイテレーション期間です

バックログのイテレーション期間を指定(1)
バックログをマウスでクリック
したままドラッグして、
イテレーション期間の上で離すと、
期間が指定できます
予測に基づいて、必要な分を設定します
※バックログは複数のイテレーション期間をまたげません。
期間を一致させるか、別のバックログに分けます。
48

バックログのイテレーション期間を指定(2)
イテレーション期間を
クリックして、
バックログが表示されるか？
確認します
49この計画で進めて問題ないのか？確認しましょう
ポイント

この計画（バックログ）で
問題ありません
となったら
50※全てのステークホルダーを納得させてください

今週のバックログのタスクを作ります
51
1Week 1Week 1Week
バックログ
Backlog items
タスク
Tasks
 これからイテレーション期間が始まる時
（※週の最初の作業としてタスクを作ります）
 バックログを実現するタスクを作成
全員で！

タスクを登録する方法は同じですが・・・
バックログの横の [＋] を
クリックすると
タスクを入力する画面が
表示されます
52

スクラムでは全員で作業時間を見積もります
 プランニングポーカー（見積もりポーカー）
 全員でカードを一斉に出して見積もる
53
※ http://www.surviveplus.net/ja/archives/137 からPDFをダウンロードして印刷できます
13 を超える場合は
タスクが大きすぎる
分割を検討しよう

このチームではタスクがどのくらいで終わるか？
 実際の時間を予測して出す
 暗黙知（その人しか知らない）による難易度の
違いやかかる時間の違いを浮き彫りにする
 同じ数字を出せ！という空気にしない
逆になぜ数字が違うのか？全員で話し合おう
54
※ http://www.surviveplus.net/ja/archives/137 からPDFをダウンロードして印刷できます
ポイント

今週のバックログのタスクが全部決まったら
55
1Week 1Week 1Week
バックログ
Backlog items
タスク
Tasks
 バックログを実現するタスクを作成完了
 スプリント計画ミーティング完了
作業開始！

「振り返り」はTFSのサポートがありません
 振り返りミーティングはPDCA の CA
 １週間の終わりに、この１週間で問題がなかったか？みんなで確認
KPTを用紙に書いて持ち寄ろう
K (Keep) ：続けたいこと – (C) 良かったこと
P (Problem) : 問題 - (C) 悪かったこと、やめたいこと
T (Try) : 試したいこと – (A) 悪かったことの改善をどうやるか？
57

スクラムの目的・意図を意識して振り返ろう
 毎日、自分のタスクを意識して作業できたか？
 タスクの見積もりと、実際の作業時間はどれだけ差があったか？
 うまく出来ていないなら、その要因はなんだろうか？
なぜ？なぜ？なぜ？・・・と、深掘りして改善出来る方法を見つけ出す
チーム主体でセルフマネジメントする自立した組織になる
58

まとめ
スクラムの目的と意図・スプリントの流れ
59

スクラム開発が始まる前に決めておくこと
 イテレーション期間（1 ～ 3週間）
 何をバックログ、タスクにするか？
 リリースタイミングとブランチのルール
 ソースバージョン管理のルールも変更を検討
 レビュー会を実施
60イテレーション
タスク
1Week 1Week 1Week
バックログ
レビュー・リリース
ルールを策定・明文化 = 自立した組織に導く

スプリント開始～終了１週間の流れ
 今回のバックログを決定（承認）
 スプリント計画で全員でタスク作成
見積もりポーカー
 デイリースクラムを実施
日次で進捗を報告・確認し合う
タスクを元に作業
 振り返りで改善する
61
1Week 1Week 1Week
スプリント計画（週頭）
振り返り（週末）
デイリースクラム（日次）
見積もり

スプリント計画で問題がわかったとき
タスクを見積もった結果、
１週間では終わらないことがわかった時
次回以降にバックログの一部をリスケ
あるいは、そもそも作らない
調整が出来るか？ステークホルダーと確認
62
1Week 1Week 1Week
スプリント計画（週頭）
週１回の計画・報告のタイミングがある

デイリースクラムで問題がわかったとき
タスクの見積もりと進捗が乖離し
１週間では終わらないことがわかった時
次回以降にバックログの一部をリスケ
あるいは、そもそも作らない
調整が出来るか？ステークホルダーと確認
63
1Week 1Week 1Week
デイリースクラム（日次）
１日一回の報告・計画修正のタイミングがある

見える化 : 知らないことには対応できない
 PMが全てを把握していなくても、
メンバーのアラートに気付いて適切に対応出来る
 ルールは少し増えたが、柔軟に対応出来ることでメンバーも納得・安心
64
見積もりのブレ出荷スケジュールの調整人員の調達解決
発見して対応何も手を打てなければ「スクラム」も効果が無いので注意！
TFS で
見える化

スクラム開発採用を検討する人に向けて
 TFS スクラム開発は日常コミュニケーションとチームワークの
具体的な方法を提供
 TFSは機能を自然に使えるところから導入することが最もベスト
 意図がわかればスクラム開発の作業自体はそんなに変わらない
 理解して段階的に始めましょう
65

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

TFSスクラム開発・リリース管理導入事例記事
 http://bit.ly/1m85aYY
 the Microsoft Conference 2014
では「リリースコストを 1/21 に
削減」と紹介されました
68

TFS導入のご相談窓口
 ご利用者数（20名様以上）のご相談窓口
下記担当者まで、ご一報いただければと思います。
日本マイクロソフト株式会社
デベロッパーエクスペリエンス＆エバンジェリズム
統括本部 | 開発ツール推進部
シニアソリューションスペシャリスト
椎野磨美（Shiino Mami) |
mailto:mashiino@microsoft.com
 ご利用者数（20名様未満）のご相談窓口
下記サイトの販売代理店様に直接、ご相談ください。
http://www.visualstudio.com/ja-jp/products/how-to-
buy-vs
69

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

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

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

Mais de 慎一古賀

Mais de 慎一古賀 (12)

Último

Último (11)