成熟したチームにとって良い「完了の定義」はどのようなものですか？

さまざまなソースで行われた定義の例を見ると、通常、次のような点が含まれています。

• コード完成
• 単体テストの実行
• ピアレビューまたはペアリングされたコード
• チェックインされたコード
• ドキュメントが更新されました
• …

私たちのチームにも同様のリストがありますが、これらのポイントが非常に明白であるため、これらの手順のいずれかをスキップすることは誰にも起こらないため、誰もそれを確認することはありません。つまり、それが主にアジャイルプロセスに移行するチームのためのツールであるのか、それを取り除くだけではいけないのかと考えていました。

一方、多くの文学は、すべての高性能チームが完了の強い定義を持っていると主張しています。この種のヒントは、ここで改善する機会を逃す可能性があることを示しています。

では、成熟したチームの完了の強力な定義の例は何ですか？一般的にどのような点が含まれていますか？

ガイドラインは皆のためにあります。成熟したチームでは、あなたが言ったように、誰もがそれをしているので、それのための場所がないということではありません。今までこの方法論に触れたことのない新しいメンバーが加わったとしましょう。構造を整えることは、彼にとって不可欠です。彼は他のメンバーを悩ませたり、成果物を「忘れたり」する必要はありませんでした。

私の意見では、明白なものを含め、すべてをリストアップします。おそらく、より短いリストが必要な人には役立つが、自明ではないリストには「短いチートリスト」を用意しますが、新しいメンバーが参加する場合を考慮してください。

それは反復的なプロセスであり、改善できるものが見つかるたびに、それを完了の定義に追加します。時間の経過とともに、あなたの会社に関連するリストを作成します。アナンはすでに価値のあるいくつかのことを述べました。

ポイントが露骨に明白であるからといって、人々が常にそれらを実行することを意味するわけではありません。他の2つの例を見てみましょう-パイロットと外科医。民間旅客機や手術室のコックピットには複数の人がいて、それらの間には十分な教育と経験があります。ただし、それでも問題は解決しません。手順が順不同で行われ、何かが忘れられ、何かが正しく行われません。私は、パイロットエラーに起因する航空機インシデントの大部分（最大70％）がチェックリストで防げた可能性のある多数の情報源サイトを見てきました。医学界では、オランダの医療過誤訴訟の最大29％がチェックリストを使用することで防止できた可能性があると研究者は述べています。これらの人々は訓練されており、後から考えるとおそらく彼らが間違ったことを簡単に特定できるでしょうが、何かが起こって彼らは失踪しました。まだ読んでいませんが、チェックリストマニフェストが関連するはずです。それは医学の専門家から書かれていますが、何をすべきかを思い出させるためにチェックリストやフローチャートを可視化することの利点は、どの専門職にも当てはまります。

したがって、最初のステップは、完了の定義の一部であるもののリストを作成し、それを可視化することです。そのタスクがどれほど明白であるかは関係ありません。ストーリーが完了したと見なされるために完了する必要がある場合は、そのリストに含まれている必要があります。リストは、チームのどこかに表示される必要があります。派手で形式的なものである必要はないことに注意してください。ストーリーが完成したと言えるようになる前に、全員が自問する必要のある一連の質問だけかもしれません。

ステップ2は、完了の定義についてそのチェックリストで何を行うかを決定することです。タスクを完了するために必要なことはすべて、具体的で、明確で、受け入れ可能で、現実的である必要があります。また、完了を検討するために、時間のコンテキスト内にある必要があります。たとえば、doneの定義に「コードの変更」や「デザインの変更」を含める必要はありません。作業成果物を変更する必要がない場合は、ストーリーは必要ありませんでした。

完了の定義の基礎として役立つ適切なチェックリストは次のようになると思います。

• 関連するすべてのユニット、統合、システム、および受け入れテストが更新されましたか？
• 作業成果物は解放可能な形式に変換されましたか？たとえば、ビルドされたコード、エクスポート可能なファイル形式のドキュメントなど。
• 関連するすべての成果物はピアレビューされていますか？作業成果物の例には、ソースコード（生産とテスト）、コメント、設計ドキュメント、テスト手順、およびユーザーマニュアルが含まれます。
• すべての関連するテスト（すべてのレベルのテスト）が実行され、合格していますか？
• コードは統合リポジトリにマージされましたか？

もちろん、チームと顧客が付加価値を感じているその他の活動を含む、完了の適切な定義を考え出す必要があります。チェックリストに記載されている場合は、誰か（チーム、顧客、ユーザー）に価値を付加するために実行する必要があります。自分が行っていることを明確に列挙することにより、無関係な活動を特定して排除し、プロセスを改善することもできます。

これは実際にはあなたが幸運な人のように聞こえます

私たちのチームにも同様のリストがありますが、これらのポイントが露骨に明白に見えるため、誰もそれを見ていない

あなたのチームはすでに「成熟」しています;-)。しかし、常に改善の余地があります！

あなたの質問に：

では、成熟したチームの完了の強力な定義の例は何ですか？一般的にどのような点が含まれていますか？

リストの上に、次のものを追加できます。

さまざまなコード品質メトリック：-不安定性、抽象化-LOC対DLOC（文書化）-など...

経験則として、コミットによってメトリックが悪化することはありません。さらに、誰かが実際にメトリクスを改善する場合は、「done：withExcellence」を作成できます。ただし、これ（メトリックが向上する）は通常、開発フェーズ（新機能）の一部ではなく、リファクタリングフェーズです。

私の過去の会社の1つでは、「完了」の定義がありました。これは、メトリックが特定のしきい値を下回る必要があることを意味します。上に行くと、まだ完了していません。（複雑な計算のように非常に非常に良い言い訳がない限り、Cyclomatic Complexityが15を超えることはありません。）

Checkstyleタイプの違反についても同様です。特に、チームのコードスタイルをチェックするカスタムルールセットがある場合はそうです。コーディング標準に違反している場合は、まだ完了していません。

次に、UnitTestを実行できるだけでなく、コードカバレッジを測定できます。少なくとも50％がカバーされていない場合は、完了していません。コア/メイン/クリティカルメソッドのテストが必要であり、必ずしもコードベースの100％に対するテストではないため、これは完了したとは言えない定義です。

そうそう...そして、自動ブランチ統合を備えたCIサーバーがある場合（あるはず）は、DEVブランチでのコミットが現在のLIVE-Branchとマージされ、エラーも発生しない場合にのみ完了します。（単体テストなど）

うーん...それは私が過去の会社/プロジェクトから知っていることを覚えているすべてです、それはあなたのリストには記載されていません。

それがあなたにいくつかのアイデアを与えたことを願っています;-)

乾杯、

アナン

TDD / BDD環境では、「完了」の定義（技術的には「コード完了」、マットSの「本当に「完了」の定義が正しいため）は非常に簡単です。

• すべての自動テストに合格する（これらの自動テストには、必要な機能または動作が存在し、機能することを確認するために、問題のストーリー用に作成された新しいテストが含まれている必要があります）
• コードレビューに合格しました（チームの少なくとも1人の上級開発者が、あなたの仕事をコードベースの一部にするための内容であり、ストーリーを「騙し」たり「ハック」したりしていません）
• 成功したコミット（すべての自動テストに合格したビルドボット、コードカバレッジメトリック、スタイルcopチェックなどを含む）

この時点で、先に進むことができます。これらの3つのポイントは重要ですが、平均的なチームコーダーが考慮しなければならないすべてのことです。書かれている、または書かれていない、それらはTDD環境では不可侵です。ドキュメンテーションは、コーダーがドキュメンテーションを行う人である場合、追加のポイントです。私の最後のアジャイルチームでは、ドキュメントはBA / QAによって処理されました。彼らは、クライアントが何を望んでいるかを知っていて、UATを実行していたため、クライアントにとって意味のある方法で新機能を文書化できたため、ドキュメントはコーダーの「完了」の定義の一部ではありませんでした。チームの定義の。