2016年1月13日、マイクロソフトの製品サポートポリシーの変更に伴い、
・Windows 8
・サポートされているOSにおける古いバージョンのInternet Explorer
のサポートが切れたのは有名(?)ですが、
併せて
・.NET Framework 4／4.5／4.5.1
のサポートも切れていました、、、、
これらのバージョンでは今後セキュリティパッチが提供されなくなり、危険な状態に晒されることになるので、サポート範囲内のバージョンへアップグレードする必要があります。
詳しくはこちらに分かりやすくまとめられています。
http://www.atmarkit.co.jp/ait/articles/1503/04/news141.html
前回は1スプリントの計画と日々の活動について書きました。
今回はプロダクトが完成した後の活動について書いていきます。
日々の活動を経て「リリース判断可能なプロダクト」が完成しました。
そのプロダクトが「リリース可能なプロダクト」かどうかを検証・判断するための会議を「スプリントレビュー」といいます。
■スプリントレビュー
この会議は、開発チームの成果物をプロダクトオーナーが確認する場です。
・開発チームが開発したものをPOにデモをする
・POはリリース可能かどうかを判断する
以前プロダクトバックログを作成する段階で、その要求に対する完了の定義を決めておきました。
今回のスプリント計画で開発することにしたプロダクトバックログ毎に、その完了の定義を満たしているのかどうか、デモを通じて検証します。
その結果を見てPOがリリース可能かどうかの最終判断を下します。
ここでNGになったプロダクトバックログについては、その残作業を次のスプリントに持ち越します。
NGになったプロダクトバックログを、スプリントの期間を延長して完了させるのではなく、次のスプリントに持ち越す点に注意して下さい。
これは開発チームの「ベロシティ」を測るためです。
■ベロシティ
スクラムのルールとして各スプリントの長さは均一にしなければなりません。
また、以前プロダクトバックログの見積もりを行う際にプランニングポーカーの手法を説明しました。
この手法で見積もりが行われた場合、それぞれのプロダクトバックログには、それを実現する場合にどれくらいの工数が掛かりそうかがポイントで表現されています。
つまり、1スプリントで消化できたプロダクトバックログのポイントの総計が、今の開発チームが1スプリントで消化できるポイントであり、今の開発チームの実力を表します。それを「ベロシティ」と呼びます。
このベロシティを測り、また比較するために、スプリントは均一でなければならないのです。
今の開発チームのベロシティがわかれば、今後のスプリント計画も立てやすくなり、プロジェクトの見通しも立ってきます。
開発チームとしてはベロシティ、つまりチームの実力を測る、その目安にもなります。
スクラムでは開発チームがベロシティを向上させるべく、次のスプリントへ向けて今回のスプリントをふりかえるための会議体が用意されており、それを「スプリントレトロスペクティブ」といいます。
■スプリントレトロスペクティブ（ふりかえり会）
次のスプリントを今回のスプリントよりも良くするためのアクションを決める
・プロセスやツールなどの観点で今回のスプリントを検査する
・うまく行ったこと、今後改善すべき点を整理する
・今後のアクションプランを作る
ふりかえりを行って次のスプリントに活かす、つまりPDCAサイクルを回すことで開発チームの業務を改善する仕組みが、スクラムには用意されています。
以上、ここまでが1スプリントで行う活動になります。
まとめますと、
・スプリント計画ミーティング
・デイリースクラムを実施しながらの日々の開発
・スプリントレビュー
・スプリントレトロスペクティブ
を1スプリント内で実施し、それを繰り返すことでプロダクトを作成していき、最終的にはそのプロダクトをリリースする、という流れになります。
今回を含め、今まで５回に渡りスクラム研修のまとめということで書かせていただきました。本連載は今回で終了です。
アジャイル開発におけるマネジメント手法の一つである「スクラム」。
その基本的なルールについては、本連載を書く中で改めて整理できたと感じています。今後はスクラムを実践しながら、更に学んでいければと思っています。
最後に、スクラムをはじめようと思っている方に向けて、スクラムの実践の手引とも言える、すばらしい書籍をご紹介させていただきます。
SCRUM BOOT CAMP THE BOOK
最後まで読んでいただき、ありがとうございました。
前回はプロダクトバックログとスプリントについて書きました。
今回は１スプリントの中で行う活動について書いていきます。
まず、スプリントをスタートするにあたって、
今回のスプリントで何をどう作るのかを決める必要があり、
そのための会議を「スプリント計画ミーティング」といいます。
■スプリント計画ミーティング
このミーティングでは下記の事柄を決めていきます。
・プロダクトバックログを分析・評価し、今回どれを作るのか、POと開発チームで合意する
・プロダクトバックログを具体的なタスクに分割する（このタスクをスプリントバックログといいます）
・具体的な実現方法を検討する（あとは作るだけ、という状態まで詳細を詰めます）
・タスク毎に見積を行う（プランニングポーカーを活用）
このミーティングにかける時間は、
1ヶ月のスプリントであれば、8時間が目安です。
計画が決まれば、後はその計画にそってタスクをこなし、
リリース判断可能なプロダクトを作成していくという、
日々の開発作業に入っていきます。
ただ、皆さんよく御存知の通り、
全てが計画通りに進むとは限りません。
スクラムには、日々の作業が本当にゴールに向かっているのか、
を確認するための会議体が用意されており、
それを「デイリースクラム」といいます。
■デイリースクラム
スプリントの目標を達成できるか、どこかに問題がないか、
を検査するために行う日々のイベントです。
・毎日決まった時間に決まった場所で、開発チーム全員で行う
・15分以内で行う
・その日に何をすべきかを共有する
・作業を進める上での問題点を洗い出す
・問題があれば、対策を決める（別途時間を取って行います）
このイベントではタスクボードを活用します。
ホワイトボードを Todo, Doing, Done の3領域に区切り、
スプリント計画ミーティングで洗いだしたタスクを
ポストイットに書いて貼り付けます。
最初は全て Todo にありますが、タスクが進む毎に
Todo→Doing→Done へ移動させることで、
タスクの進み具合を把握できるようになります。
このタスクボードの前でデイリースクラムを行うことで、
開発チーム全員で状況を共有します。
このように日々の作業を行っていき、
リリース判断可能なプロダクトの完成を目指します。
今回はここまでです。
次回はプロダクトが完成した後の活動について書いていきたいと思います。
前回に引き続き用語の説明をしたいと思います。
今回は前回のまとめの中で登場した用語、
・プロダクトバックログ
・スプリント
について書いていきます。
■プロダクトバックログ
プロダクトバックログとはプロダクト（システム）に対する要求の一覧を指します。
・ユーザのニーズ等からプロダクトオーナーが作成する
・１つの要求についてユーザストーリ形式(※)で記述する
・プロダクトオーナー（PO）が開発する順番に並び替える（順番の最終決定権はPOにある）
・要求は可変なので常にメンテナンスして最新の状態に保つ必要がある（優先順位の高いものから開発することでプロダクトの価値を最大化する）
・要求毎に完了の定義を決めておく（デモ手順とその結果を決めておくことでリリース判断可能にしておく）
・開発チームによって見積が行われる（プランニングポーカー(※)という見積手法が主流）
※ユーザストーリ形式
「誰々としてこれこれがほしい。それは何々のためだ」という役割・機能・価値の３つをストーリとして記述する形式
※プランニングポーカー
開発チーム全員でカードを使って行う、複数人の知見を活かした見積の手法。
フィボナッチ級数（1,2,3,5,8）のカードを全員が持ち、基準となるストーリ（要求）とその数字（ポイント）を決めた上で、その他のストーリについて、下記の手順で見積を行う
・対象を個人で頭のなかで見積もる
・一斉に数字が書かれたカードを出す
・差異が出たら、その差異について、まずは最小と最大の数字を出した人が、その根拠を説明する
・それを踏まえて再度カードを一斉に出す
・これを差が少なくなるまで繰り返す（全て一致しなくても差が少なければ、小さい方を採用する）
■スプリント
全体の工期をスプリントという固定の期間に区切って繰り返し開発を行います。
１スプリントの中で実現するストーリをプロダクトバックログの中から決めて（複数可）、リリース判断可能な動くソフトウェアを開発します。
・最大１ヶ月までのタイムボックス
・各スプリントの長さは均一（延長してはならない）
・開発チームはこの期間の中で、計画、設計、開発、テストなどプロダクトのリリース判断に必要な全てのことを行う（ゆえに開発チームは自己組織化されたチームである必要があります）
今回はここまでです。
次回は１スプリントの中で行う具体的な活動について書いていきたいと思います。
前回はアジャイル開発について簡単に書きました。
今回からスクラムについてまとめていこうと思います。
スクラムというマネジメント手法にはルールがあり、そのルールを理解するためにはまず、スクラムにおける用語を知っておく必要があります。今回はその用語のなかで登場人物（役割）に関するものを書いていきます。
スクラムには登場人物（役割）として
・プロダクトオーナー
・開発チーム
・スクラムマスター
がいて、この３者のグループをスクラムチームと呼びます。
■プロダクトオーナー
・プロダクト（システム）の価値を最大化することに責任を持つ
・プロダクトバックログ（開発要件）の定義や優先順位付けを行い開発チームに伝える
・要件とその優先順位を決める必要があるので基本的にはお客様側の人が担当する
■開発チーム
・スプリントごとの成果物のリリースに責任を持つ
・自己組織化されたチームである（自分たちで判断し仕事を進めることができる）
・チームは10名弱で構成される
・開発ベンダー側が担当する
■スクラムマスター
・スクラムの推進に責任を持つ
・スクラムチームの支援をおこなう
・開発ベンダー側が担当する
私はまだスクラムを実践したことがないのでスクラムマスターの立ち位置や具体的な仕事内容が正直ピンと来ていませんが、ひとつ言えることは、スクラムマスターはプロジェクトマネージャではないということです。あくまでスクラムに沿ったマネジメントが円滑に進むよう力を尽くすのが仕事です。
今回はここまでです。
その他の用語も出てきましたね。次回はその辺りの用語について書いて行きたいと思います。