読者の皆様、
Scrum.orgのプロフェッショナルスクラムトレーナー（Professional Scrum Trainer・PST）をしております、グレゴリー・フォンテーヌと申します。このブログでは、今後シリーズとして、海外のPSTが投稿した英文ブログの中から、質が高く日本の読者の皆様に関連性の高い記事の日本語翻訳版をご紹介していく予定です。このシリーズのブログ記事の全リストをご覧になりたい方はAgorax.jpのホームページから見ることができます。また、すべてのブログ記事には、私自身の短いコメントを添えております。
はじめに
スクラムの目的を要約すると、「各スプリントで “完成”したインクリメントを作成する」ということになります。それを実行しようとする場合、まず必要なのは「完成（Done）」を定義することです。「完成の定義（Definition of Done・DoD）」が寛容すぎると、後で高いコストをかけて対処しなければならないリスクが蓄積することになります。しかし、ウオーターフォールモデルしか知らない組織がアジャイル開発を始めようとした時に、スキル、ツール、テスト自動化、コラボレーションなどの面で制約が沢山あるため、DoDの実現可能性を考慮する必要もあります。
この記事では、私の仲間のプロフェッショナルスクラムトレーナーであるマーティン・ヒンシェルウッド氏が、スクラムチームがどのように「完成の定義」を始めて作ることができるのか、また、学習や継続的な改善に合わせてどのように「完成の定義」を更新していくべきなのかを説明しています。
----------------
著者：マーティン・ヒンシェルウッド
英語版：Getting started with a Definition of Done (DoD)
TL;DR;
開発者は、動作するソフトウェアの完成インクリメントを作成する最終的な責任を負います。完成したインクリメント。完成。
開発者は、組織的な文脈とプロダクトドメインの中で、完成が何を意味するかを決める必要があります。彼らは納品するソフトウェアのインクリメントごとに必須な事項のリストを作成しなければなりません。「動く」ソフトウェアとはPBIに固有のものではなく、PBIに関係なく納品全体に適用されます。各PBIに対してだけではありません。
“完成の定義により、作業が完了してインクリメントの⼀部となったことが全員の共通認識となり、透明性が⽣み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提⽰することもできない。そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。”
– 2020スクラムガイド
少なくとも30日ごとに動作するソフトウェアを出荷できないのであれば、その定義からして、あなたはまだスクラムをやっていない。プロのスクラムチームは「動く」ソフトウェアを作るのだから、一旦立ち止まって、あなたの完成の定義（DoD）を満たすソフトウェアの作業インクリメントを作成し、スプリントを開始し、継続的に「動く」とはどういう意味かを少なくとも定期的にレビューするべきです。
完成の定義（DoD）とは？
ほとんどの場合、私たちはグリーンフィールド型のプロダクトを持っていません。既存のプロダクトを渡されるか、そのプロダクトを作ったチームでスクラムに切り替えるかのどちらかです。プロダクトがどこで生まれたものであれ、そのコード、ひいてはプロダクトは、現在動作しているソフトウェアではありません。「動く」とはどういうことかという定義がないのに、どうしてそうなるのか？ではどうするのか？が問題です。
まずコードを一行でも削る前に、あなたのプロダクトや会社にとって「完成」とは何かを決める必要があります。ペースメーカーのファームウェアを作る場合と、eコマースのポータルを作る場合とでは、その定義は大きく異なることでしょう。以下は、「完成の定義」のいくつかの特徴です。
- 短い、測定可能なチェックリスト ー 完成の定義には、測定可能なもの、結果をテストできるもの、できれば自動化されたものを用意しましょう。
- 「出荷可能な状態」が含まれる ― 推奨されたにも関わらずまだプロダクトを出荷していない場合、このような選択肢があるべきです。プロダクトオーナーは、スプリントレビューで 「素晴らしい...出荷しましょう」と言うことができるでしょう
- これ以上の作業は必要ない ー 製品を本番出荷するために、開発者がこれ以上の作業をする必要はないはずです。追加作業は、完成していないことを意味し、次のイテレーションのためのプロダクトオーナーの能力を奪うことになります。理想的なのは、ソフトウェアを納品するためのプロセスを完全に自動化し、納品に時差イテレーションを使用しないことです。
使用可能な状態であり、プロダクトを出荷するためにそれ以上の作業を必要としない、という状態を定義する短い、測定可能なチェックリストを作成する必要があります。これを行う最良の方法は、スクラムチーム（プロダクトオーナー、開発者、関連するステークホルダー）をDoDワークショップに参加させることです。完成の定義がなければ、「動作する」ソフトウェアが何を意味するのか理解できませんし、動作するソフトウェアがなければ、予測可能な納品ができません。プロダクトオーナーはバックログ項目を拒否することはできません、できるのはインクリメントが機能しているかどうかを判断するだけです。
初めての完成の定義
完成の定義は魔法のように現れるものではなく、ソフトウェアも魔法のようにそれに従うものではありません。ソフトウェアをあなたの完成の定義に適合させるのは大変な作業であり、あなたの完成の定義は有機的に成長するはずですが、まずはその土台となる種を作る必要があります。
スクラムチーム全員と他のドメインの専門家などを集めてワークショップを開催することをお勧めします。開発者が完成した後、ソフトウェアが通過しなければならないステージゲートがある場合は、それらのゲートの代表者がワークショップに参加する必要があります。プロダクトにかかわらず、コード、テスト、セキュリティ、UX、UI、アーキテクチャなどの専門知識を持つ代表者が必要です。このような専門家はあなたのチームにすでに存在しているかもしれませんし、またはあなたの組織や組織外部から専門家を連れてくる必要があるかもしれません。
ここで完成の定義に記載すべき項目例をいくつか共有します：
- インクリメントがクリティカルエラーなしでSonarCubeのチェックをパスする ― 時間が経つにつれて増えていくので、「コードが50個以上のクリティカルエラーなしでSonarCubeのチェックをパスする」とする必要があるかもしれません。
- インクリメントのコード カバレッジが変わらない、または高くなる ー コード カバレッジの 90% のような特定の指標を見ても、コードの品質については何もわかりません。しかし、コード・カバレッジの不利な変化を監視し、測定することは有益かもしれませんし、私たちは常にTDDの実践を提唱しています。
- インクリメントは合意されたエンジニアリングの標準を満たす ― メソッド、テスト、変数、そしてその間のすべての名前のルールを決めるべきです。小さく始めて、時間をかけて増やしていきましょう。Wiki上で合意した標準にリンクし、継続的にルールを改善し、拡張してください。可能であれば自動化しましょう。
- インクリメント合格を判断する受け入れ基準 ― 少なくとも所定の基準を満たすことを確認することは称賛に値する目標であり、ATDD のプラクティスでそれらを自動化することはさらに良いことです。
- インクリメントの受け入れテストを自動化する ― すべてのテストを自動化するようにしましょう。何かが壊れると思うのであれば、それに対するテストが必要です。
- インクリメントのセキュリティチェックパス−ビルドの一部として自動化ツールを使い、既知のセキュリティ脆弱性をチェックしましょう。すべてのセキュリティ問題を発見できるわけではありませんが、少なくとも、セキュリティの悪さを看過しないようにしましょう。
- インクリメントが合意されたUX基準を満たしているか − ここでも、Wikiページを用意し、2回チェックするようにしてください。自動化された DoD エントリを使用していない場合は、基準を満たしたことにチームとして同意する必要があります。
- インクリメントが合意されたアーキテクチャーガイドラインを満たしている− Wikiはこのために素晴らしいものですが、できることは自動化してください。
どのような「完成の定義」を考え出したとしても、現在のプロダクト全体がその基準を満たしている可能性は低いでしょう。まだスクラムが始まっていないのですから。スプリントを始める前に、現在のインクリメントが新しい「完成の定義」を満たしているかどうかを確認する必要があります。開発者が責任を負うべき品質に焦点を当て、インクリメントが新しい品質基準を満たしていることを確認してから始めましょう。次のインクリメントが到達できるのは、それ以前のすべてのインクリメントの品質基準だけです。
完成の定義はインクリメントの品質へのコミットメント（確約）です！
完成の定義を満たす使用可能なインクリメントを作成し、スプリントを開始します。ソフトウェアを稼働状態に保つには、優れたDevOpsプラクティスを実装するための機能を提供する最新のソース管理システムが必要です。
完成の定義（DoD）の成長
品質が常に向上することは非常に重要であり、そのために少なくとも定期的に完成の定義を振り返る必要があります。スクラムでは、この周期はスプリントの長さによって定義され、スプリントレトロスペクティブで改善の瞬間を迎えます。だからといって、常に完成の定義を振り返らないわけではありません。インクリメントが現在、完成の定義を満たしているかどうか、そしてそれを達成するために何をすべきかを常に考えるのです。完成の定義がニーズに合っているかどうかを常に振り返るべきです。もし開発者がスプリントの途中で完成の定義に足りないものを見つけたら、スプリントゴールを危険にさらさないことを確認しながら、先に進んで追加すべきです。
前回の投稿でデビッド・コービン氏が指摘したように、プロダクトにパフォーマンスの問題があることがわかるかもしれません。その問題を確実に解決するにはどうすればいいのでしょうか？私が思うに、スプリント開始後、2つの選択肢があります。スクランブル（品質が悪いためにスプリントを中止すること）して修正するか、この新しい知識を製品サイクルに統合するかです。
もしそれが、ソフトウェアを動作させることができないような重大な問題であれば、中断して修正する必要があります。スクラムでは、これをスクランブルと呼び、何かが足りないために開発者がつまずいたことを反映します。スプリントを続けて新しいフィーチャーを追加する前に、新しいフィーチャーを追加するのを止めて、使えるインクリメントを作成すべきです。問題を修復したら、完成の定義を増やして、将来のすべてのインクリメントが新しい要件を満たすようにします。
重要度が低い場合は、作業を続け、必要なものをプロダクトバックログに追加するとよいでしょう。そして、特定された問題を緩和し、解決するための改善を、次の数スプリントにわたって提供することができます。解決したら、完成の定義に何かを追加することで、結果を確定することができます。
常に品質を高める方法を探しましょう。今日のあなたの完成の定義はどのようなものですか？