Embed Size (px)
Citation preview
スクラム開発を始めよう!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パッケージを開発
最近はアーキテクチャ・フレームワークを考えたり、マネージメントが中心
「仕組み」作りで 如何に高品質・低コストで早い開発を実現できるか？
3TFS 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
アジャイルAgile software development
スクラム・反復開発Scrum, Iterative and Incremental Development
ウォーターフォールWaterfall development
全員で見積もり 最初に見積もり済み（メンバーは見積もらない）
毎週リリース 1回だけリリース
毎週の成果物が全て WBSで厳密に管理
全員の意欲・スキルがとても高い事が必須
PM・設計者のスキルがとても高いことが必須
※わかりやすく説明するために、多少誇張した表現になっています
ある程度の期間毎にリリース
期間ごとに予実を確認
アジャイルAgile software development
スクラム・反復開発Scrum, Iterative and Incremental Development
ウォーターフォールWaterfall development
ユーザーストーリーUser Story
バックログBacklog
必要条件Requirement
スクラム手法（日常コミュニケーションとチームワークのプラクティスやプロセス）
タスクボード≑リアルタイム報告
デイリースクラム≑日次報告
スプリント計画・振り返り≑週次報告
情報共有や進捗を確認・管理するベストプラクティス
どの開発プロセスでもスクラム手法を追加可能
10※わかりやすく説明するために、多少誇張した表現になっています
アジャイル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※わかりやすく説明するために、多少誇張した表現になっています
どのテンプレートも「タスクボード」などスクラム手法が使える
これを説明します！
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
バックログを実現するタスクを作成完了
スプリント計画ミーティング完了
作業開始！
振り返りPDCA
56
「振り返り」は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
Appendix補足資料
66
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:[email protected]
ご利用者数（20名様未満）のご相談窓口
下記サイトの販売代理店様に直接、ご相談ください。
http://www.visualstudio.com/ja-jp/products/how-to-
buy-vs
69
Plus Programming .net 勉強会
http://www.facebook.com/PlusProgramming.net
70Copyright© 2014 Plus Programming .net All Rights Reserved.
