こんにちは、斎藤です。
「スクラムガイドを読む」の第２回目です。
第２回目は、スクラムガイドの下記の内容に関して書いていきます。
スクラムイベント
スプリント
スプリント計画ミーティング
デイリースクラム
スプリントレビュー
スプリントレトロスペクティブ
スクラムの成果物
プロダクトバックログ
スプリントバックログ
インクリメント
「完了」の定義
結論
アジャイル開発というと、なんとなくいい加減な開発手法という偏見がもたれているように思われます。（私自身も以前はそう思っていました）
しかし、ここで書かれているイベントは先にも述べたPDCAサイクルにも通じるようなかなり良く考えられたやり方だと感じます。
PDCAサイクルとの対応関係は次のようになります。
- Plan:スプリント計画
- Do:開発作業
- Check：ディリースクラム、スプリントレビュー
- Action：スプリントレトリスペクティブ
また、「時間に上限のあるタイムボックス」ということで、それぞれのイベントに使う上限時間を定めていることも面白いです。
長い会議は良くないとい考え方が徹底していますね。
スプリント
スクラムの中心はスプリントである。これは、「完了」した、動作する、リリース判断可能なプロダクトのインクリメントを作るための、1か月以下のタイムボックスである。スプリントは、開発作業を行う連続した期間である。スプリントが終了すると、新しいスプリントが開始される。
スプリントは、スプリント計画ミーティング・デイリースクラム・開発作業・スプリントレビュー・スプリントレトロスペクティブで構成される。
スプリントでは、次のようなことを行う。
- スプリントゴールに影響するような変更を加えない。
- 開発チームの編成を維持する。
- 品質目標を下げない。
- 学習が進むにつれて、スコープが明確化され、プロダクトオーナーと開発チームの交渉が必要になる可能性がある。
スプリントは1か月以内のプロジェクトと考えることができる。プロジェクト同様、スプリントは何かを成し遂げるために使う。スプリントには、開発対象の定義・開発のための設計や柔軟な計画・開発作業・成果物となるプロダクトが含まれる。
スプリントの期間は1か月以内である。スプリントが長すぎると、開発対象の定義が変更されたり、複雑度が上昇したり、リスクが増大したりする可能性がある。スプリントでは、ゴールへの進捗を少なくとも1か月ごとに検査・適応して、予測可能にしている。また、リスクも1か月分のコストに収まるようにしている。
インクリメントという表現がスクラムの中では使われていますが、これは今回のスプリントで作成され、実装・テストも完了した機能のことを指しています。スプリントを反復しながら開発していくスタイルがインクリメンタルな開発であることから、インクリメントと呼んでいるのでしょう。
ここでは、結構重要なことが書かれています。
「スプリントゴールに影響するような変更を加えない」ということは、仕様変更・追加とか実際に実装してみたら意外と大変であることがわかった場合どうするのか。簡単に言うと、次のスプリントに持ち越すという考え方です。スプリント開始前の予想（計画）が外れたからといって、そのスプリント内で全ての問題を解決しようとして、スプリントゴールに影響するような変更を加えてはいけないということです。
従来のやり方では、スケジュールされた期間内に作成が完了できなかったものは、進捗遅れとして作業が完了するまではやり続け、それが更に後ろのスケジュールに影響するため、リカバリープランの名の下で、長時間残業・休日出勤でカバーするということが多いです。
スクラムではスプリントの期間内で完了しなかった機能があったとしても、スプリントの期間を延長してはいけません。
延長してしまうと、チームのベロシティが計測できなくなり、次のスプリントで開発する機能を正確に見積もる事ができなくなるからです。
スプリント期間内に作成出来なかった機能は、次のスプリントに回し、その中で作成する機能として再見積りを行なっていきます。
決して、長時間残業・休日出勤でカバーするという開発チームの生産性や品質を落とすようなやり方をしてはいけません。
そのためには、開発を発注している顧客の理解も必要になります。
長期的に見た場合、このやり方の方がプロジェクトをデスマーチにしないためには大事なことだという考え方なのでしょう。
スプリントの中止
スプリントはタイムボックスの終了前に中止できる。スプリントを中止する権限があるのは、プロダクトオーナーだけである。このとき、関係者・チーム・スクラムマスターの意見を参考にすることもできる。
スプリントゴールが古くなったらスプリントを中止する。会社の方向性や市場・技術の状況が変化すると、スプリントゴールが古くなってしまう。通常、状況を考えて意味がなくなったと思えば、スプリントを中止すべきである。ただし、スプリントの期間は短いので、中止したからといってさほど意味をなすことはない。
スプリントを中止したら、プロダクトバックログの「完了」した項目をレビューする。出荷判断可能なものであれば、プロダクトオーナーが受け入れる。未完成のものは、再見積もりをしてから、プロダクトバックログに戻す。かかった作業は失われたものとなるので、再見積もりが必要になることが多い。スプリントが中止されると、新しいスプリントのスプリント計画ミーティングが必要となり、それを開催するリソースを消費してしまう。スプリントの中止によって、チームのトラウマになることもある。しかし、中止はめったに起きないことである。
スプリントの中止とは、無駄な開発をズルズルと継続させないためには、時には必要なことなのでしょう。
「会社の方向性や市場・技術の状況が変化」という大きな変化が書かれていますが、実際には顧客の要望が変化してバックログの優先順位が変わった場合や、実際に開発をしてみて思った以上に大変な事が分かった場合なども、一旦スプリントを中止した方が良いという判断もありえるでしょう。
スプリント計画ミーティング
スプリントの作業は、スプリント計画ミーティングで計画する。計画はスクラムチームの共同作業である。
スプリントが1か月の場合、スプリント計画ミーティングのタイムボックスは8時間である。スプリントの期間が短ければ、その長さに比例して時間が短くなる。たとえば、スプリントが2週間の場合、スプリント計画ミーティングは4時間になる。
スプリント計画ミーティングは2部構成となる。それぞれ半分ずつのタイムボックスを使い、次の質問に答える。
- スプリントの成果であるインクリメントに何を入れるか?
- インクリメントを届けるためにどのように作業をするか?
いわゆる計画・スケジュール作成の作業です。スプリントが１ヶ月の場合、８時間ということは計画のための会議は１日と決められています。その１ヶ月内でどの機能を作るか、どうやって作っていくかを計画していきます。
第1部:スプリントで何をするか?
第1部では、開発チームがスプリントで開発する機能を計画する。プロダクトオーナーが順番の付けられたプロダクトバックログを開発チームに渡し、スクラムチーム全体で協力して、スプリントの作業を理解する。
入力は、プロダクトバックログ・最新のプロダクトインクリメント・開発チームがスプリントで発揮する作業能力の予測・開発チームの過去の実績である。プロダクトバックログから選択する項目数については、開発チームが責任を持つ。次のスプリントで何を達成するかを評価できるのは、開発チームだけである。
次に、スクラムチームでスプリントゴールを作る。スプリントゴールは、プロダクトバックログを実装して達成するスプリントの目標であり、開発チームにとっては、なぜそのインクリメントを開発するのかという指針になる。
スプリントで何を作るかを決めるのはプロダクトオーナやスクラムマスターではなく、開発チームが自分達で決めていくところがスクラムの特徴です。プロダクトオーナは優先順位の付いたプロダクトバックログ（作る機能のリスト）を渡すところまでで、どこまで今回のスプリントで作る事ができるかの見積りをするのは開発チームが行ないます。
この見積りではポーカプランニングと呼ばれるやり方が良く使われています。
開発メンバー全員（全員というところが大事）で各機能にかかると思われる作業量をポーカゲームのようにカードを使って見積りを行ないます。
開発チームは自己組織化・機能横断的であるというのが徹底されています。
第2部:選択した項目をどのように完了するか?
スプリントの作業を選択したら、その機能を「完了」プロダクトインクリメントにする方法を開発チームが決定する。スプリントで作業を行うプロダクトバックログの項目と、それを届ける計画を合わせて、スプリントバックログと呼ぶ。
開発チームは、プロダクトバックログを動くプロダクトインクリメントにするシステムや作業の設計から始めることが多い。作業の規模や見積もり工数はさまざまだが、スプリント計画ミーティングでは、開発チームがスプリントで達成できると予測できる作業を計画する。スプリントの最初の数日間で開発チームが行う作業は、このミーティングで1日以下の単位に分解される。スプリント計画ミーティングでは、開発チームが自己組織化してスプリントバックログの作業を受け持つ。必要であればスプリントの最中にも行う。
スプリント計画は、いわゆるWBSを作成する作業のことです。
作業は１日単位まで細分化されなければいけません。また、このような詳細のスケジュールは、今回のスプリント内で開発する機能に対してのみ行うので、次のスプリント以降の作業に対しては行ってはいけないということも重要です。
第2部にプロダクトオーナーが参加して、選択された項目を明確にしたりトレードオフを助けたりすることもできる。作業が多すぎたり少なすぎたりした場合は、開発チームとプロダクトオーナーが、スプリントバックログの項目について話し合う。開発チームは、技術やドメインについて助言してくれる人たちを招待することもある。
開発チームは、スプリントゴールを達成し、期待されたインクリメントを作成するために、自己組織化チームとしてどのように作業を行うのかを、プロダクトオーナーとスクラムマスターに対してスプリント計画ミーティングの終了までに説明できるようにしておかなければならない。
開発チームは、スプリント計画をプロダクトオーナーとスクラムマスターに対して説明するというのが面白いと思いました。
従来のやり方では、スケジュールはリーダが作成し、メンバーに説明するというのが普通ですがスクラムでは逆転しています。
どちらが本当にかかる作業量や時間が分かっているのかということと、自己組織化するためには自分たちで計画することが最も大事だということでしょう。
「予想が外れた場合」という言い方が面白いですね。
見積りとは、結局のところ「予想」です。外れることも多々あります。スプリントは最大でも１ヶ月であるため、外れたとしてもプロジェクト全体への影響は限定的です。外れた時はスプリント内で作成する機能をプロダクトオーナと調整するという柔軟な対応をしていく必要があります。
「プロダクトオーナ」は「顧客」と言い換えられることもあります。開発する会社側の人の場合もあれば、発注する会社側の人の場合もあるのでしょう。どちらにしろ、見積りという予想が外れた場合には、スプリントの期間内に何がなんでも作り上げるんだというやり方では無く、スプリント期間内で作り上げる機能の方を調整するという柔軟な対応をプロダクトオーナはしていかなければなりません。
デイリースクラムはアジャイルではスタンドアップミーティングとも呼ばれます。立ってミーティングをすることにより、ミーティング時間が長引くのを防ぐのです。決まった時間に決まった場所で１５分以内に終えるということが大事です。
開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの作業の進捗を評価する。デイリースクラムによって、開発チームはスプリントゴールを達成する可能性を最適化できる。デイリースクラムが終わったら開発チームはすぐに集まって、スプリントの残作業を再計画する。開発チームは、スプリントゴールを達成し、期待されたインクリメントを作成するために、スプリントの残り時間で自己組織化チームとしてどのように作業を行うのかを、プロダクトオーナーとスクラムマスターに毎日説明できるようにしておかなければならない。
ディリースクラムの後にスプリント内の残作業からどうしたらゴールを達成できるか再計画し、プロダクトオーナーとスクラムマスターに毎日説明できるようにするというのも自己組織化の徹底ぶりが感じられます。
進捗報告や作業の割当に関しては、タスクボード（タスクかんばん）というものが用いられます。タスクボードは未実施（ToDo）、作業中（Doing）、完了（Done）の３区画に分けられて、カード（ポストイット）にタスク（作業）が書かれています。
ディリースクラムでは、自分でサインアップ（自分がこのタスクをやりますと言って署名する）します。誰かにタスクをアサインされるのでは無いところが良いと思います。タスクボードは進捗状況が一目でわかるところも良いところです。
スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにする。ただし、デイリースクラムを開催する責任があるのは、開発チームである。スクラムマスターは、開発チームにデイリースクラムを15分以内に終わらせるように伝える。
スクラムマスターは、デイリースクラムに参加できるのは開発チームのメンバだけというルールを設定する。デイリースクラムは上司への進捗報告会ではない。プロダクトバックログの項目をインクリメントに変える人たちのものである。
「進捗報告会」ではないというところが良いところです。
デイリースクラムは「朝会」とも訳されるが、普通朝会というとリーダへの進捗報告会になっているが、開発チームの人達のものであるという考え方が、やらされてる感の排除に繋がるのでしょう。
デイリースクラムは、コミュニケーションを改善し、その他のミーティングを取り除き、開発の障害を特定・排除し、迅速な意思決定を助長して、開発チームのプロジェクト知識のレベルを向上させるものである。これは、重要な検査と適応のミーティングである。
アジャイル開発はいい加減な開発手法ではありません。FaceToFaceのコミュニケーションを大事にし、検査と適応（CheckとAction）を徹底し、時間を最大限に有効活用しているのです。
スプリントレビュー
スプリントレビューは、スプリントの終わりにインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。スプリントレビューでは、スクラムチームと関係者がスプリントの作業をレビューする。レビュー結果とプロダクトバックログの変更をもとにして、次にできることを議論する。これは非公式なミーティングであり、インクリメントを提示することで、フィードバックとさらなる協力を引き出すことができる。
スプリントが1か月の場合、スプリントレビューのタイムボックスは4時間である。スプリントの期間が短ければ、その長さに比例して時間が短くなる。たとえば、スプリントが2週間の場合、スプリントレビューは2時間になる。スプリントレビューには、次の要素が含まれる。
- プロダクトオーナーは、「完了」したものと「完了」していないものを特定する。
- 開発チームは、スプリントでうまくいったこと・直面した問題点・それをどのように解決したかを議論する。
- 開発チームは、「完了」したものをデモして、インクリメントに対する質問に答える。
- プロダクトオーナーは、現在のプロダクトバックログについて議論する。現在の進捗から完了日を予測する。
スプリントで作成したものの評価を４時間で行ないます。
その中で「デモ」を行う事が重要です。実際に動くものを「デモ」として見せる事により、開発チーム以外の人達に成果を報告するとともに、評価や意見を聞き出す事もできます。
グループ全体で次に何をするかを議論し、価値のある入力を次のスプリント計画ミーティングに提供する。
スプリントレビューの成果は、次のスプリントで選択する可能性のある項目を定義した改訂版のプロダクトバックログである。また、新しい状況に合わせて、プロダクトバックログ全体を調整することもある。
プロダクトオーナはプロダクトバックログ（まだ開発していない機能）に対する完了日の予測も重要な仕事です。
アジャイルでは、どこまで出来たかという進捗よりも、バックログの管理・見積りの方を重用視しています。
これまでの進捗からベロシティ（１スプリント内の生産性）を求めて、バックログ（残機能）の完了日を予測します。
残機能の完了日が最終的な本番稼働のリリース日までに間に合わないのであれば、機能の優先順位をもとに調整していくのもプロダクトオーナの重要な仕事のひとつです。
スプリントレトロスペクティブ
スプリントレトロスペクティブは、スクラムチームの検査とスプリントの改善計画を作成する機会である。
スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリント計画ミーティングが始まる前に行う。スプリントが1か月の場合、スプリントレトロスペクティブのタイムボックスは4時間である。スプリントの期間が短ければ、その長さに比例して時間が短くなる。
スプリントレトロスペクティブには、次の目的がある。スクラムマスターは、スクラムプロセスフレームワークの開発プロセスやプラクティスをより効果的にして、次のスプリントで楽しめるように、スクラムチームに改善を促す。スクラムチームは、「完了」の定義を適切に調整して、プロダクトの品質を向上させる方法を計画する。
スプリントレトロスペクティブが終わるまでに、スクラムチームは次のスプリントで実施する改善策を特定しなければならない。これらの改善策は、開発チームの検査に適応したものだ。改善はいつでも実施できるが、スプリントレトロスペクティブは検査と適応のための公式な機会である。
日本語ではレトロスペクティブは「ふりかえり」と呼ばれています。
QC（QuorityControl）「改善活動」にも通じるところがあります。
スプリントレビューが４時間、スプリントレトロスペクティブも４時間ということは、スプリントが終了したら、次のスプリントを開始する間の１日で行うということになる。結構、短時間でいろんなことを行わなければなりません。
「次のスプリントで楽しめるように」という言い方が面白いですね。何か改善しながら物事を進めるというのは、自分たちが着実に成長している実感が持てて楽しいのでしょう。
PDCAサイクルの中でも、Action（改善の実施）は実際には行われないことが多いですが、ここがプロジェクトを成功させるためにも「きも」となる重要な活動であることは間違いないでしょう。開発をやりっ放しでは無く、レビューして改善していくことを、継続的に反復しながらやっていくことをスクラムでは「公式な機会」としています。
プロダクトバックログは、従来の開発の「要件定義書」や「機能一覧」にあたるものです。
「要件定義書」の場合、そこに書かれている機能は作成しなければならない絶対的なものだという意味合いが強いですが、プロダクトバックログはもっと動的に管理していく「機能一覧」のような目的で使われるところが大きな違いです。
プロダクトバックログは決して完成しない。開発の初期段階には、最初から明確でよく理解できた要求が並べられている。プロダクトバックログは、プロダクトや使用環境に合わせて変化するのである。プロダクトバックログは動的であり、適切で競争力のある有用なプロダクトに必要なものを求めて、絶えず変化する。プロダクトが存在する限り、プロダクトバックログは不滅である。
今回のプロジェクトにおいて、どこまで機能を提供するかは、プロジェクトの実施期間中に絶えず変化していくものだという考え方です。
最初に決められたものを全て作っていくというウォータフォール型の開発とは考え方が大きく違います。しかし、そのやり方が最も良い（適切で競争力のある有用な）プロダクト（アプリケーション）を作成する方法であるという信念に基づいているのでしょう。
プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。プロダクトバックログの項目には、詳細・並び順・見積もりの属性が設けられている。
プロダクトバックログは、価値・リスク・優先度・必要性などで並べられている。1番上の項目から開発を開始する。順番が上の項目ほどよく考えられており、その項目や価値について合意がとれたものである。
順番が上の項目ほど明確で詳細である。明確で詳細であれば、見積もりも正確になる。順番が下の項目ほど不正確で詳細ではない。次のスプリントで開発チームが従事するプロダクトバックログの項目は、スプリントで「完了」できるようにうまく細分化されている。スプリントで開発チームが「完了」にできる項目は、「準備完了(ready)」や「着手可能(actionable)」と呼ばれ、スプリント計画ミーティングで選択できる。
価値・リスク・優先度・必要性で最も高いものから開発をしていくことが、限られたコストと期間とリソースを無駄無く使って、最大限の価値を生むプロダクト（アプリケーション）を開発していくには重要なことなのでしょう。ウォータフォール型の開発では、それを最初に固定化してしまうため、無駄な開発コストを長期間かけてしまうことが多いと思います。見積りも開発初期の段階では、かなり不正確なものであることは経験的にも、研究成果としても実証されており、それがデスマーチの大きな原因となっていると思います。
プロダクトが使用されて価値が増加し、市場からフィードバックを得られると、プロダクトバックログは巨大で包括的な一覧になっていく。要求の変更は止まらない。プロダクトバックログは生きた成果物である。ビジネス要求・市場の状態・技術の変化が、プロダクトバックログの変化につながる。
アジャイルソフトウェア開発宣言に書かれている
「計画に従うことよりも変化への対応を」
がここでも生かされています。
同じプロダクトで複数のスクラムチームが作業をすることがよくある。そうした場合、プロダクトの作業は1つのプロダクトバックログに記述される。また、項目をグループにまとめる属性が追加される。
プロダクトバックログの項目に詳細の追加・見積もり・並び替えを行うことを、プロダクトバックログの手入れと呼ぶ。これは、プロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログの手入れによって、項目のレビューと改訂が行われる。ただし、プロダクトオーナーによって、項目が更新される可能性もある。
プロダクトバックログの手入れは、プロダクトオーナーと開発チームが、スプリントの一環として行う活動である。開発チームは、手入れをするためのドメイン知識を持っている。いつどのように手入れをするかは、スクラムチームが決定する。手入れには、開発チームの作業の10%程度を消費する。
１０％とは結構な作業時間をかけるのだなあと思いますが、いわゆる管理工数も１０％位はあった方が、プロジェクト運営がうまく行くのと同じでしょう。
開発チームは見積もりに対して責任を持つ。トレードオフの理解や選択を手伝うなど、プロダクトオーナーが開発チームに影響を及ぼすこともあるが、最終的な見積もりは実際に作業をする人が行う。
ゴールへの進捗を監視する
いずれかの時点で目標に対する残作業を合計する。プロダクトオーナーは、少なくともスプリントレビューにおいて、この合計残作業を追跡する。プロダクトオーナーは、前回のスプリントレビューの合計残作業と比較して、希望する時間までにゴールに到達するかどうかを評価する。この情報は関係者全員に明らかにされる。
進捗の見通しを立てるために、バーンダウンやバーンアップなどのさまざまなプラクティスが使用されてきた。これらは有用ではあるが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに起きたものだけが、これから先の意思決定に使用できる。
バーンダウンチャートは縦軸が残作業のポイント（理想時間とも呼ばれる）、横軸が日付の折れ線グラフのことで、進捗状況を見える化するのに用いられます。
しかし、「経験主義の重要性を置き換えるものではない」という警告を鳴らしています。実際に起きた事から未来に起きるであろうことを予想するのはチャートだけからは単純には判断できない、人間が出来る複雑で高度な作業なのでしょう。
スプリントバックログ
スプリントバックログは、プロダクトバックログから選択した項目と、その項目をプロダクトインクリメントにして届け、スプリントゴールを達成する計画とを合わせたものである。スプリントバックログは、開発チームが作成するインクリメントに含まれる機能と、その機能を届けるために必要な作業を表した予測である。
スプリントバックログは、開発チームがプロダクトバックログの項目を「完了」インクリメントに変える作業を定義している。スプリントバックログは、開発チームがスプリントゴールを達成するのに必要な作業をすべて見える化している。
スプリントバックログは、デイリースクラムで変更点が共有できる程度に詳細な計画である。スプリントでは、開発チームがスプリントバックログを修正し、スプリントバックログが明確化されていく。これは、開発チームが計画を実行するなかで、スプリントゴールの達成に必要な作業を学習するからである。
新しい作業が必要になれば、開発チームがスプリントバックログに追加する。作業が完了すれば、残作業の見積もりを更新する。計画が不要になれば、削除する。スプリントでスプリントバックログを削除できるのは、開発チームだけである。スプリントバックログには、開発チームがスプリントで行う作業がリアルタイムに反映されている。スプリントバックログは開発チームのものである。
スプリントバックログもプロダクトバックログ同様、動的なものであることがわかります。
スプリントの期間内でも、スプリントゴールの達成に必要な作業がだんだんと明確になり、それに基づいてスプリングバックログの追加・修正・削除を行っていきます。経験主義を重要とし、人間は学習しながら最適な方法を探っていくものだということでしょう。
残作業の見積りも随時更新していくのは開発チームが自ら行っていくところが良いと思います。
毎日残作業を監視するためには、動的に変更されるバックログと作業工数を管理できる便利なツールが必須になります。
インクリメントは常に動く状態になければならないというのも、アジャイルの特徴のひとつで、このためにはJenkinsのようなCIツールや自動テストツールが必須となります。
「完了」の定義
プロダクトバックログの項目やインクリメントが「完了」したならば、全員が「完了」の意味を理解していなければならない。スクラムチームによってその意味は大きく異なるが、透明性を確保するためにも、作業の完了について共通の理解がなければならない。これは、スクラムチームの『「完了」の定義』と呼ばれ、プロダクトインクリメントの作業完了の評価に使われる。
この定義は、スプリント計画ミーティングでプロダクトバックログの項目を開発チームがいくつ選択するかの指針にもなる。スプリントの目的は、スクラムチームの「完了」の定義に沿ったリリース判断可能な機能のインクリメントを届けることである。
開発チームは、スプリントごとにプロダクトのインクリメントを届ける。インクリメントは実際に動くものなので、プロダクトオーナーはすぐにリリースできる。インクリメントは、それまでのインクリメントに追加されたものであり、すべてが正常に動くように十分にテストされたものである。
成熟したスクラムチームでは、「完了」の定義にさらに厳しい品質条件を追加することもある。
ここでは「完了」具体例が書かれていませんが、例えば次のようなものが考えられます。
- デモ手順の通りに動作する。
- ユーザストーリに書かれている機能が動作する。
- publicメソッドに対するテストコードとその結果がある。
- git(ソース管理)から、テスト済みのコードをいつでも取得し、リリースすることができる。
ここに書かれている事全て実践して初めてスクラムと言えるとしているところはなかなか厳しいですね。
アジャイル開発では、実際のプロジェクトに合わせて導入可能なことからやってみると良いという緩やかな考え方もあるため、スクラムと呼べるかどうかは別として、役にたつと思われることからやってみることが大事なことだと思います。
