スクラムチーム（Scrum Team）の開発者（Developers）は、インクリメント（Increment）を開発します。開発者がスプリントごとに作成するものがインクリメントです。スプリントごとに、前のスプリントで作成したものに追加していくことから「インクリメント＝増分」と呼ぶのですね。
Scrum.org のスクラムガイドによると、開発者について次のように書かれています。
各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。
https://www.scrum.org/resources/scrum-guide
このシンプルな説明文の１行だけでも、かなり重要なポイントがあります。
スクラムがなんとなくうまくいかない時や、スクラム・アジャイルに対する誤解が大きい時には、この部分のイメージがうまくできていないのかもしれません。
目次
スプリントごとにコミットする（アジャイルはコミットしないのではない、コミットする期間が違う）
スクラムのよくある誤解として、「アジャイルは柔軟にやるから全然コミットしないよね」「結局何もできないでずるずる進むじゃん」というのをよく聞きます。それは大きな誤解です。
スクラムでは、現在の１スプリントでインクリメントを作成することをコミットします。ただ、次のスプリントやその先のスプリントのことは、まだ、コミットしていません。今はまだ計画もしていないし、コミットしていないだけで、次のスプリントになったらその時にちゃんと計画もするしコミットもするのですね。
もし何スプリントも動作するインクリメントが完成しないのであれば、（それはアジャイルやスクラムが悪いとかではなくて）そのチームが単に完成させられていない。計画が甘かったり、技術力が足りていなかったり、スクラムチームに対して他からの邪魔（障害）が多くて集中できていなかったり、いろんな理由でインクリメントがいつまでたっても完成しないのかもしれませんが、それがスクラムの当たり前の状態というわけではなくて、それはスクラムがうまくいっていない状態です。あるいはそんな難しい話ではなくて、もしかしたらそのチームが「インクリメントを作ることをコミットする」のだということを知らなくて、単純に開発期間をスプリント（１週間とか２週間とかの決まった期間）で区切って、「繰り返し開発」をしていることをスクラム・アジャイルと呼んでいるのかもしれませんね。開発期間を単に区切ることをスクラムとは呼びません。そうではなくて、それぞれのスプリントの終わりにインクリメントを必ず完成させるのがスクラムのあるべき姿です。
スプリントレビューでは、完成して実際に動作させられるインクリメントを使って、プロダクトオーナー（PO）がステークホルダーにデモをします。そしてステークホルダーからもらったフィードバックを、PO が整理して、プロダクトバックログに更新していきます。ここで動作するソフトウェアを見せられなければ、適切なフィードバックを得ることが出来ません。そのため、スプリントの終わりまでというよりも、実際にはもっと前の、スプリントレビューのデモの練習を、POと開発者が行うまでにはインクリメントが完成していなければなりません。現実的には受け入れ条件や受け入れ試験などもあるはずなので、さらにもっと前に完成しています。
わかっていてもスプリントの終わりまでにインクリメントが完成しないようであれば、そうならないようにレトロスペクティブで問題点を確認して、次のスプリントからは完成させられるように改善していきましょう。
利用可能である ＝ リリース可能である
完成したインクリメントは必ず利用可能でなければなりません。それはつまりリリース可能であるということです。
完成したソフトウェアやサービスが、スプリントの終わりに実際にリリースされている必要はありません。実際のリリースのタイミングはプロダクトオーナー（PO）がステークホルダーと話し合って調整したいはずです。プレスリリースなどの発表だけをして、実際のリリース日は後日とか、先行して一部のユーザーにだけリリースをして、全体へのリリースは段階的に、というケースもあります。Azure DevOps のパイプラインと機能フラグをうまく使って、デプロイのタイミングとリリースのタイミングをずらせるようにしておくのも重要になってきます。
スプリントの終わりに、完成したインクリメントが実際にユーザーにリリースされている必要はありませんが、リリース可能であることは必須です。実装や開発環境での開発者のテストはもちろん、ユーザー受け入れ試験などもすでに完了していて、あとは Azure DevOps のパイプラインでPOがリリースを承認すればすぐにリリースされる状態であったり、Azure の設定やどこかのDBの値を変えれば対象のユーザーが使える状態になる、そいう状態になっていることが必要です。
スプリントレビューでは、ユーザーがこれから使えるようになるものをデモして確認できることで初めて、本当のフィードバックが得られます。逆に未完成のソフトウェアや動画などの資料でのデモでは、ステークホルダーからの「こういう時はどうなりますか？」に対して「それはこうなっているはずです」といった仮定（想像）や、言葉でのイメージだけでの確認になってしまします。それでは（本当に動作するソフトウェアと比べて）適切なフィードバックが得られるとは言えません。
また、実際に完成していないソフトウェアのでもでは、スプリントレビューのフィードバックが終わった後に、何か微妙に変わったものがリリースされてしまって「そんな話聞いていないぞ」となることもあるかもしれません。
開発者は必ず利用可能なインクリメント＝そのままリリース可能なものを、スプリントごとに完成させなければなりません。
インクリメントは必要な全てを含む（アジャイルはドキュメントを書かないのではない、必要ならドキュメントも書く）
インクリメントはWebサービスやアプリなど実際に動くソフトウェアそのものと、それを保守運用するためのドキュメント類など必要なものすべてを含みます。単にソースコードやそれをビルドしたものだけがインクリメントというわけではありません。
よくあるアジャイルの誤解で、「アジャイルではドキュメントを書かないんでしょ」「設計書や運用ドキュメントを書いてくれないから、スクラムチームは開発も運用も品質が低いんだ」というのを聞くことがありますが、それは誤解です。もし、スクラムチームがドキュメントを書いていないとするならば、それは必要のないドキュメントだから書いていないか、あるいは「ドキュメントが必要」ということがプロダクトバックログや完成の定義に書かれていないのではないでしょうか？
従来のウォーターフォールのプロジェクトでは、開発のプロセスとそれに必要なドキュメントが定義されていて、必ずそれらの全てのドキュメントを用意しして、プロジェクトを開始するようにというルールが一般的でした。例えば、要件定義や基本設計・詳細設計、テスト仕様書など、多くのドキュメントを Word や Excel のファイルで作成していました。しかし、現代ではこれらの多くのドキュメントは、Azure DevOps などのツールの基本的な機能として提供されるようになったので、（ファイルとして作成しなければならないという明確な理由がなければ）ファイルで作成するのではなくツールに入力する方が良いです。例えば Azure DevOps Boards にプロダクトバックログアイテムの Description に要求・要件・設計の詳細を記載すれば、それに関連付けられた Task やソースコードの変更からも容易に参照できて、トレーサビリティが確実に担保されます。
また、アジャイルでは素早さが大事なので、「どんなプロジェクトでも必ず同じドキュメントを記載する」と決めるのではなく、プロジェクトによって必要なドキュメントだけを記載するようにします。大人数で開発をするプロジェクトなら、開発者同士でコミュニケーションをしたり設計を共有するために、より詳細な設計書や開発標準などのドキュメントが必要かもしれません。しかし少人数のプロジェクトで、開発者全員がすでに同じ文化や認識を共有している場合には、これらのドキュメントはなくてもソースコードさえ綺麗に書いていれば大丈夫かもしれません。そういう少人数のチームでも詳細な設計書を Office ファイルで作成してから実装しなければならないのだと、コストが無駄になってしまいます。そういう意味で、ドキュメントは必要なものだけを記載する必要があります。
また例えば、作成したソフトウェアやサービスを長期的に運用するには、気を付けなければならない点や、必ずやらなければならない作業があるなど、保守運用に適した読みやすいドキュメントが必要な場合があるかもしれません。それは印刷されて目次や索引のある冊子だったり、ラミネート加工されたカードで現場の特定の場所にぶら下げられるものだったりするかもしれません。こういった特別なドキュメントが必要であれば、やはり、スクラムであってもそれは作成する必要があります。どういうドキュメントが必要であるかは、プロダクトバックログに記載されて、プロダクトオーナー（PO）から開発者に伝えられ、開発者によって確実に作成されなければなりません。これはプロダクトバックログアイテム（PBI）の受け入れ基準（Acceptance Criteria）です。
もしそのスクラムチームが作成するインクリメントには、必ずそういったドキュメントが必要ということであれば、特定の PBI の受け入れ基準としてではなく、完成の定義（DoD : Definition Of Done）として記載することが必要です。
もしスクラムチームの開発者のドキュメントが不足しているとか、品質が低いと感じたら、PBIの受け入れ基準や、完成の定義を見直してみると良いかもしれません。
Azure DevOps をトータルで使用してトレーサビリティを担保して安全に自動化（効率化）
Azure DevOps の基本は、インクリメントを作成するためにソースコードバージョン管理として Repos を使用することです。しかし、Repos 以外の Boards、Test Plans、Pipelines、Artifacts をトータルで使用することで、簡単にトレーサビリティが担保されて、安全に自動化・効率化することが出来ます。
プロダクトオーナー（PO）はプロダクトゴールを表現するために、Boards にプロダクトバックログアイテム（PBI）を作成・入力して、その詳細を開発者に伝えます。開発者は PO に詳しく PBI の内容を聞いたうえで、タスク（Task）を作成して、タスクとReposのソースコードの変更を関連付けながら開発を行います。
開発者がソースコードの変更を保存すると、Pipelines に作成されたパイプラインによって自動的にソースコードがビルドされて、また単体テストが自動的に実行されます。これはプログラムコードでプログラムコードをテストする、いわゆる自動テストです。自動テストに成功したモジュールは、検証用のステージにデプロイされ、もしその検証ステージでのテストに問題がなければ、承認ワークフローで承認された後、本番ステージなど次のステージにデプロイ・リリースされます。
また開発者は Test Plans に、各 PBI をテストするテストケースを作成します。これは開発者が自分で操作してテストを行う、いわゆる手動テストです。スプリントの期間中に開発者がテストを実施して、テスト結果を保存します。このとき Pipelines にパイプラインが用意されていれば、検証ステージにデプロイされたモジュールを使ってテストを実施します。またもし、テストに問題があれば、どのパイプラインでデプロイされたモジュールか？どのソースコードの変更によるものか？どの PBI とタスクのための変更だったか？が、即時に確認することができます。自動的に常にトレーサビリティが担保されているので、開発者は安心をして開発をすることが出来ます。
Artifacts は少し特殊で、必ず使わなければならないものではありませんが、もし開発者が、何度も再利用可能な部品としてソースコードを共有しているのであれば、ソースコードを共有する代わりに、ソースコードをビルドしたライブラリとして参照できるようにすることが出来ます。ちょうど NuGet パッケージをインターネット上で見つけてきて使用するのと同じように、自分たちのスクラムチーム用のライブラリを共有できる場所として Artifacts が動作してくれます。ソースコードを直接共有すると、壊してしまったり、問題がどのバージョンで発生しているのか？誰の責任で修正するのか？などを管理するのが、だんだん大変になってきます。Artifacts を使用すると、ビルド済みのバージョン番号が付いたライブラリを参照することになるので、ソースコードを直接共有するよりも、それらの管理が少し楽になります。必要に応じて使用します。
もし、Azure DevOps を使用しない場合には、Jira や Jenkins などの似た機能を持ったサービスをうまく連携させて、同じようにトレーサビリティの担保や自動化ができるように工夫します。
プログラムのソースコードは Repos に保存することができます。ドキュメントはどのように扱えばいいでしょうか？
Office ファイルの履歴機能は、ファイル自体に履歴を持っていてローカルで作業するときに利用できる他、SharePoint 上で開くとそれをうまく扱えるようになっています。しかし、残念ながら Azure DevOps には Office ファイルの履歴機能をうまく扱う機能はありません。諦めて Repos にバイナリファイルとして保存するか、SharePoint に保存してプロダクトバックログアイテム（PBI）からリンクするなどの、トレーサビリティをカバーできる運用方法を考えなければなりません。PBI にはファイルを添付できるので、SharePoint で作業中の Office ファイルを管理しておいて、完成したファイルを PBI に添付するという運用も可能です。
もし、編集するのを Word ファイルにこだわらないのであれば、Markdown でドキュメントを書くという方法が有効です。
Markdown はテキストファイルなので、Repos で適切にバージョン管理できます。もし、納品物や印刷物として Word ファイルや PDF ファイルにしなければならないのであれば、Markdown ファイルを Pipelines のパイプラインで Word ファイルやPDFファイルに変換するようにすれば、他のソースコードと同じようにインクリメントの一部として扱うのが表示に簡単になります。
コメント
