完了の力

作者 Chris Sims , 翻訳者 沼田 暁子 投稿日 2008年11月10日

セクション

プロセス/プラクティス,

設計/アーキテクチャ

トピック

Agile ,

Delivering Value ,

Delivering Quality

タグ

Best Practices ,

Podcasts

Scott Schimanski氏(リンク)は先ごろ、「完了（done）」の明確な定義のもたらす力について、さらに声高に主張(リンク)した。Scott氏は「完了」の明確な意味には企業的価値と個人的価値の両方があることを指摘している。企業は追加投資をすることなく完了した機能の出荷をあてにすることができ、同時に個人は「完了」にともなう達成感を本当に楽しむことができると思われる。

アジャイル開発のもっとも強力な側面のひとつは反復的な開発です。大きな開発作業を、明確なもっと小さな作業に分割するという考えです。それらの作業は計画され、コミットされ、取り組まれ、完了します。みなさんは正しい方法をご存知です。しかし、コーディングだけではなく、テストやドキュメント作成、パッケージのインストール、最終的な目的地で使用可能にするために必要なものすべてを含む、あらゆる作業があります。

Ken Schwaber氏(リンク)はChicago Scrum Gathering(リンク)で、チームが「完了」の意味することを知る価値を語ることに多くの時間を割いた。彼は、広く一般に理解された「完了」の定義は非常に強力かもしれず、スクラムのスクラムはもはや不要となるかもしれないとさえ主張した。「すべての受け入れテストが通っていて、プロダクトオーナーが満足している」という一般的な考えに加え、「完了」の定義には以下のものが含まれるべきであるとKenは述べている。

• コードレビュー
• 設計レビュー
• リファクタリング
• 性能テスト
• 単体テストが通っていること
• ことによると、さらに多くのこと

完了の定義に関する彼の意見は、彼がScott Hanselman氏(リンク)と行ったインタビュー(リンク)で、詳しく聞くことができる。

Mishkin Berteig氏(リンク)は、繰り返されるタスクを特定(リンク)し、それらを「完了」の定義に含めることを提案している。つまり、もしチームがストーリー毎に「○○（ストーリー名がここに入る）を国際化する」というようなタスクを繰り返し作成していることに気づいたら、おそらく「国際化する」はチームの完了の定義に追加する必要がある。

Aaron Ruhnow氏(リンク)は、「完了」を定義するために次のチェックリストを使用し、彼のチームがどのようにして「完了のニルバーナ（Done Nirvana）(リンク)」を見出したかを説明した。

1. コーディング済みである／実装済みである
2. ピアレビュー済みである（ペアプログラミングはピアレビューとみなす）
3. ソース管理上の最新バージョンでコードが動く
4. ソース管理上のコードにコメントが書かれていてチェックイン済みである
5. Public／Friendメソッドには、VB Commenterでコードにコメントが書かれている
6. ストーリー／ユースケースのマニュアルテスト計画が更新されている
7. （SQA担当者と協力して）適合テストが書かれている
8. UML図が更新されている
9. 単体テストが書かれ、通っている
10. コードカバレッジが90パーセントに達している
11. ビルドやパッケージの変更がビルドマスタに伝えられている（例えば新しいファイルの追加や何か）
12. タスクリストの時間が更新され、タスクがクローズされている
13. コード中のすべてのTO-DOアイテムが完了している

軽く締めくくると、Tony Clark氏(リンク)が「完了」を描いた(リンク)漫画を見てほしい。Implementing Scrumのブログ(リンク)に掲載されている。

コメントを残し、あなたにとっての「完了」の定義を教えてほしい。

 

原文はこちらです：http://www.infoq.com/news/2008/10/PowerOfDone

• 次へ >