InfoQ

News

完了の力

作者 Chris Sims , 翻訳者 沼田 暁子 投稿日 2008年11月10日 午後12時1分

コミュニティ
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

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
slashdot+
Hatena

特集コンテンツ一覧

Flex 4の新機能トップ10

今週(2009年6月1日)AdobeはFlex 4の正式な初ベータ版をリリースしました。Flex 4はGumbo(オクラ)というコードネームで開発されています。今回のリリースには大きな変更が多数含まれています。このRIAフレームワークの最新バージョンにおいて変更された事柄についての概要を以下のリストで見ていきましょう。

Domain Driven Design(ドメイン駆動設計) Quickly 日本語版

ビジネス領域の深い理解を反映したドメインモデルを設計するための、ヴィジョンとアプローチです。この本は、Eric Evans氏の「Domain Driven Design」の主要点を短く読みやすく要約しました。

JavaプログラマがFlexとBlazeDSを学んだ方がいい13の理由

この記事ではJavaプログラマがなぜFlexとBlazeDSを学ぶべきなのかについて13の理由を述べています。なぜ高度にインタラクティブなWeb サイトからJavaで開発されたバックエンドをもつエンタープライズ・アプリケーションまでを含む、リッチ・インターネット・アプリケーション(RIA)の開発にFlexとBlazeDSの組み合わせが最適な選択肢となるのかについて述べています。

仮想パネル: バックログは重要な成果物とプラクティスか、それとも無駄か?

Mary Poppendieck氏、Ron Jeffries氏、Jeff Patton氏、David West氏、Steve Freeman氏、Jason Yip氏が、バックログに関する彼らの意見とアジャイルチームを成功させるために必要な事を語った。

Perf4Jを使ったパフォーマンス解析とモニタリング

この記事ではAlex Devine氏が、Java開発者がPerf4Jをどのように利用できるかと、タイミングステートメントにコードを追加し、ロギング、結果の解析とモニタリングを行うオープンソースツールセットの説明をします。

複雑な外部DSLを開発する

本稿では、Vaughn Vernon氏が内部DSLと外部DSLの違いを説明し、複雑な外部DSLを開発する際のステップを示します。

J2EEアプリケーションにおけるAOPを使ったフェッチ戦略の実装

この記事では低レベルのサービス・レイヤやリポジトリ・レイヤを肥大化させることなく、フェッチング・ストラテジによってモジュール化された方法でバックエンドにあるシステムからデータを取得する処理を最適化する方法について説明します。

実証済みのアイデアの融合: S#arp Architectureの裏側

この記事では、Web開発における多数の成熟傾向と、クライアントに価値を提供することに対するそれらのメリット、およびS#arp Architecture(最善の手法と技術を活用しようとするASP.NET MVCをベースとしたフレームワーク)内でのそれらの使用について取り上げます。