この記事はNishi Grover Gargによるゲスト投稿です。

チームとリリースの成功は、全員がそれぞれの担当分をスケジュールどおり完了できるかどうかにかかっています。ところで、「完了」をどのように定義しますか？タスクが完了済みであることを示し、途中のタスクと完了済みのタスクを区別するものは何なのでしょうか？

すべては、完了の明確な定義を確立し、プロジェクト開始時からチーム内で合意を取るということに尽きます。この後、具体的に説明していきます。

チームでブレーンストーミング

言うまでもなく、タスクをいつどのようにクローズするかについてコメントするのに最適な人間は、各タスクの作業予定者でしょう。ですから、最初の一歩は、何が終われば担当タスクが完了したと言えると関係者が考えているか、自明のことを議論し、リスト化することです。ときには、この「自明」な点が、人によってどれほど違うかに驚かされるかもしれません。

たとえば、テスター1は、ユーザーストーリーのテスト実行を終了し、さらに1時間の探索テストを行ったらテストタスク完了だと言ういっぽうで、テスター２は、探索テストをタスクの一部とみなしていませんでした。スクリプトで記述されたテストを行ったらテスト実行タスクを完了とし、後で時間が許せば、ある程度の探索テストを行います。

このようなブレーンストーミングを行うことで、各タスクのオーナーが誰であるかに左右されずに、タスクから期待される結果のベースラインを引くことができます。

品質目標を考慮する

完了の定義をまとめようとしているなら、おそらく、改善したい領域や達成したい品質目標があるでしょうから、それを考慮します。何がチームの問題領域、あるいは最終的な遅れのもとだと考えていますか？そういった品質目標の一部を関連タスクに追加しましょう。

たとえば、ビルドの失敗が多すぎて、それがスプリント内でのひんぱんな手戻りや再テストにつながっているとします。解析の結果、ビルドが失敗する理由は、開発者がバグの多いコードをチェックインしており、たいていは統合テストを行っていないせいだと判明しました。

これを克服するため、基本的な統合テストを行うというサブタスクを各開発タスクに追加できます。また、コードレビュータスクを追加して、各開発者がリポジトリにコードをチェックインする前に、正式なレビューとはいかないまでも、同僚にコードをレビューしてもらうよう義務付けることもできます。

これらのタスクを作成することで、時間が逼迫しているときでもタスクを実行し、省略しないという合意を開発者と結ぶことになります。

可視性の確保

チームで合意した「完了」の定義がどのようなものであれ、すべてのメンバーが条件をもれなく意識し、常にタスクの進捗を確認することが重要です。

完了のすべての定義をチェックリストにまとめ、壁に貼り出すことができます。タスクボードでチームのタスクの一部として定義を追加することもできます。仮想タスクボードであれば、チームのタスク内のサブタスクとして追加できる場合もあります。さらに、物理的なタスクボード上でアイテムを進める前に、毎日のスタンダップミーティングで各サブタスクについてディスカッションするよう義務付けることも考えられるでしょう。

何を選択するにしても、明確な可視性があることは、チームメンバーがしなければならないことをすべて行う責任を維持するほか、必要な時間をメンバーに与えることにもつながります。期日が迫っている状況では、作業を進めなければならないというプレッシャーを感じることもあるかもしれませんが、進める前にはサブタスクを完了する必要があることを皆が了解しています。このことは、品質面で妥協するのを避けるためにもっと時間が必要なとき、チームメンバーが交渉するのに役立つ可能性があります。

徹底して従う

完了の定義を決定し、チームでプロセスを設定したら、徹底して従うことが重要です。タスクの進捗を継続的にチェックし、サブタスクが完了しているかを確認します。スプリントの期間中、品質タスクやその重要性について活発な会話を維持し、関連するサブタスクをすべて完了しないうちに作業が進められることがないよう注意します。

プロセスが守られていなければ失敗とみなし、なし崩しになるのを許してはいけません。1つでも未完了のサブタスクがあれば、親タスクがクローズされていないということを意味するため、未完了のタスクがあるユーザーストーリーは、現在のスプリントで完了していないとみなされ、次のスプリントにはみだします。わたしたちはこのようなルールに従っています―そして実際のところ、テストレビュータスクが完了していないというような小さなことでスプリント全体の速度が失われるのを経験すると、みな自分のこととしてくやしい気持ちを感じるものです。

時が経つにつれて、チームはこのフローに従って作業を完了させることの利点を理解し、より習熟していきます。プラクティスと完了の定義を順守することによって、チームは品質のチャンピオンになります。

Nishiは企業トレーナー、アジャイルの信奉者、そして根っからのテスターです。業界で11年以上の経験を持ち、現在はSahi Proでエバンジェリスト兼トレーニングヘッドとして働いています。トレーニングに情熱を注ぎ、テストコミュニティイベントやミートアップを主催したり、多数のテストイベントやカンファレンスで講演を行っています。アジャイルおよびテスト分野での最近のトピックを取り上げたブログをご覧ください。

（この記事は、開発元Gurock社の Blog 「Defining Your Definition of Done」2020年9月4日の翻訳記事です。）