インタビュー: Emmanuel Bernard氏にBean Validation仕様について聞く
Bean Validationフレームワークの初期ドラフトに関する以前の記事に続き、InfoQは専門家グループが求めているコミュニティの関与と提案について理解を深めるため、Emmanuel Bernard氏と対談しました。
- Java,
News
「完了」は「シップ可能」ということか？
作者 Vikas Hazrati, 翻訳者 編集部 投稿日 2008年2月16日 午前12時45分
「完了」と「シップ可能」との相違について、アジャイルに関するさまざまなフォーラムやブログで活発な討論が起こっている。両者は同じことを意味するよう な気がするが、リストやさまざまなブログ上での討論が提言するのは、この2つはいまなお広範囲にわたって誤解されており、誤使用されている用語であるとい うことである。これは「完了」の取り扱い方についての提案をまとめたものである。チームでは作業が終了したというとき、単に「完了」したのかまたは、「シップ可能」でもあるのかとどのようにして知るのか。
Alistair Cockburn氏が、最近あった討論についてコメントしている(source)。
最近の( InfoQに要約された)記事(参考記事・英語)で、Jeff Patton氏(ブログ・英語)がシップ可能の特性について以下のように要点を述べた。
ソフトウェアを売ったり使用したりしようとしている顧客に、シップ可能はソフトウェアを実際に売ったり使用できることを意味する。それは、必要最低限の機 能がすべてそろっていることである。使用目的上、ソフトウェアは便利なものでなければならない。少なくともそれに取って代わる旧式のソフトウェアや紙ベー スによる作業と同じくらい。ソフトウェアは、外観および振る舞いがよくなくてはならない。上質な適合と仕上がりである。これが市販ソフトウェアで、競合相 手が常に見張っているときは特にそうである。
シップ可能は、完了を意味する。すっかり準備完了していること。繰り返して何かを完了する必要がない。本当にシップ可能な状態が整っていることである。
Alistair Cockburn氏は、シップ可能なこととは完全に「すっかり準備完了」しているということで納得しているようである。完了からシップ可能への遷移は繰り 返し作業であると説明している。1つではなく3つの話のカードを書く(source)という策略を例えに出し、詳細を述べている。1つ目のカードは、実際の話が書かれてい る。2つ目のカードは、確認後に話に避けられない変更があった場合の代替物である。3つ目は、それらの変更後の微調整用である。3つすべては未処理分とな り、予定が決められて繰り返される。
また、コミュニティでシップ可能と「潜在的にシップ可能」という話題がのぼるとき、認識の違いがあるようだ。Agileを使用している人によっては、「潜 在的」とは「シップ可能から1スプリント離れている」と考える人がいる。Matt Wynne氏の提案は以下のとおりである(ブログ・英語)。
ここでおそらく1つ見逃していることは、「潜在的にシップ可能」が「実際にシップされる」に変わるまでにどれくらいの時間を必要とするのかということであ る。コードをビルドしてそれをシステムテストやユーザテスト環境にデプロイすることは、潜在的にはシップ可能であるように感じるが、本当の意味でシップ可 能な状態からは依然として程遠い場合もある。
Mike Cohn氏は、以下の点において同意しているようである(ブログ・英語)。
「...潜在的にシップ可能」と「シップ可能」は 同じものではない。大規模または複雑なプロジェクトによっては、リリース周期の終わり(6つの2週間のスプリントそして2週間のリリーススプリント)に 「リリーススプリント」または「スプリントの硬化」の使用が必要な場合もある。リリーススプリントは杜撰な作業の廃棄場ではない。むしろシステムの硬化が おこなわれる場である。
Mike Kirby氏は、以下のように同様のひとくだりを付け加えた(source)。
われわれの会社では、正式に開発において3つの段階を認識している(agile技術の使用とは無関係である)。「コードの開発」、「硬化」および「プログラムによる最終受諾」である。「シップ可能」は3段階目の最後にくる。
実行者は潜在的にシップ可能とシップ可能の相違について、意見が一致しているようである。その隙間を埋める方法としては、リリース周期の最後に向けてスプ リントの硬化をすることかもしれない。
完了とシップ可能の隙間を狭めるために、チームとして覚えておくべきことは他に何があるか。以下のようにChris Spagnuolo氏(source)が意見を述べている。チームは「完了」が分析からライブに至るあらゆることを意味すると決めることができる。チームにとっての目標は、「完了」の範囲をできるだけ大きく拡大す ることである。われわれのチームは最近、「完了」が分析、設計、コード化、テスト、そして文書化すべてが済んだことを意味すると定義した。
いったん、完了を正しく定義してしまえば、株主と一緒になってシップ可能状態にどれだけ近づいているかという考えを得ることができる。
Alistair Cockburn氏は、以下のように同様のひとくだりを付け加えた。
スプリントを十分長くして、
(a) ユーザがスプリント期間で機能を確認したり、訂正することができるようにする。
(b) すべての人が、スプリント期間内に機能を完全にシップ可能で、消費者等級(必要なものなら何でも)にすることができるようにする。それにより、討論および計画は大いに簡略化される。
非常に多い割合で、完了とシップ可能の間には大きな食い違いがあるようだ。この状況にもかかわらず、多くの人が完了という言葉で十分間に合うと感じており、そこにシップ可能の意味も含めるべきだと賛成している。
Agileのチームは、完了の定義に取り組む必要があり、シップ可能にできるだけ近づける努力が必要である。それを一晩で達成するのは不可能かもしれな い。チームは完了を徐々に拡張して、最終的にスプリント内でシップ可能を実現する必要がある。チームは、製品のオーナーや顧客と提携して取り組み、関連するコンテキストでシップ可能を定義する必要がある。
原文はこちらです：http://www.infoq.com/news/2008/02/done-shippable-quality
No comments
返信