BT

Ready for InfoQ 3.0? Try the new design and let us know what you think!

知識の取得を繰り返すこと、それはビジネスの価値だけではない

| 作者: Mike Bria フォローする 0 人のフォロワー , 翻訳者 大田 緑 - (株)チェンジビジョン フォローする 1 人のフォロワー 投稿日 2008年10月30日. 推定読書時間: 4 分 |

一見したところ、大抵のアジャイル方法論で簡単に定義しているのは、ストーリーがビジネスの価値によって順番に開発されることである。しかしながら多くの場合、「知識を取得する」ように計画した段階を、ビジネスの価値を増加させることと混ぜ合わせるのには慎重になる。Alistair Cockburn氏(リンク)は、この混ぜ合わせを効果的に行い(リンク)、適切な時間に適切な機能を納品するためにそれを活用する方法を述べている。

Cockburn氏は、設計活動の重要なアウトプットは知識を創出することだという基本アイデアを主張して、この話題を紹介する。

あらゆるチーム設計活動で、私たちは理解していない問題に取り組み、理解していない解決策を生み出し、通常、理解していない言葉と技術で考えを表現し、これら全てのことが私たちのもとから変化を締め出しています。

ウォーターフォールの世界では、ビックバン型の統合アプローチの特徴があり、その極端なケースが、どのようにして実際に知識を取得することを妨げるのかということを彼は続けて示す。それは、プロジェクトの終了直前まで起こり、必然的に対処する時間がない「大きな驚き」へと導かれることになる。リーン用語で、有効ではない設計の決定が積み重なることは、「在庫」が増えることを意味する。Cockburn氏がそれに付け加える。「リスクを減少する点に関して、このシナリオは終わりまで大きなリスクを残すことが分かります。終わりまでストーリーの中で知識の遅れを生み出し、通常、生き延びるのもおもしろくもないし、楽しい光景でもありません。」

Cockburn氏は、それから1つのアジャイルアプローチについて説明する。それは、「知識の成長」にチームがイテレーションの初めに注目すること、すなわち、学習である

早い段階で統合し、しばしば統合による大きな驚きを理解し、多くのセッションにその驚きを分割するチーム。こうすることによってより早く間違いを発見します。つまり、これらの間違いが何であるか、どうして起こったのかを彼らは「学習する」のです。そうすれば、後の統合でひどく失敗する可能性が低くなります。言い換えれば、「学習」要素はやがて小さくなります。これは良いことです。

これを促進するために、Cockburn氏がアドバイスする。「私たちが心配するもの/恐れるものは何か?」と尋ね、「ビジネスの価値があるものを先に」という信念に独断的に従うよりも、これらの恐れを減らすために初期の開発の努力に注目するのだ。この間の作業は、「費やしたお金の分だけもっとも速く知識を増やすという結果と、プロジェクトリスクをもっとも減らすという結果を除いて」、重要な結果をもたらすようには見えないかもしれないことに彼は言及する。

この記事で重要なことは、大きなリスクが緩和されるとビジネスの価値の順序がうまくいくことである。

いったん知識のカーブが平たくなり始めると、ビジネスの価値を第一とする順序で機能を開発するのがよいでしょう。これは、普通のアジャイルの提案と一致します。原則として、ビジネスの価値はいつも知識を集中的に取得する期間に発達することに注目してください。それはまるでビジネスの価値を手に入れていないようですが、ビジネスの価値を手に入れることが支配的なドライバではないというだけなのです。

また注目すべきなのは、「BDUF(Big Design Up Front)」で「知識を取得」することのメッセージが混乱しないように、Alistair氏が読者にはっきりと警告するのに時間を割いていることである。

Cockburn氏は次のように説明して議論を締めくくった。機能を少なくした(リンク)効率的なアプリケーションでこのアプローチをどのように組み合わせるかが、チームを効率的に「きちんと終わらせ(リンク)」、最終的に効率的なアジリティを可能にさせるのだ。

知識とビジネスの価値のカーブが平らになると、少ない機能セットで納期通りに納品する(または、早くする。競合他社の動きに合わせて。)か、機能セット全部を後で納品するかを決める立場にスポンサーはいます。

どれを選択するかは、それが属するところ、スポンサーの手にあります。いつものように、簡単な要約としてだけこのニュースを利用するようにしよう。ストーリー全体を読むには、Alistair氏の(リンク)記事を参照しよう。これらの概念を支援するとても有用なグラフや、2つの別々の実際にあったプロジェクトでこのアプローチを使ったAlistair氏の経験に関する記述が含まれている。

また、あなたはどのように思うだろうか? これは、あなたの経験に合うだろうか?これは、過去のプロジェクトのいずれかを手助けできたことだろうか?現在のプロジェクトでは? また、次のプロジェクトではどうだろうか?もしそうならば、どのように? もし違うならば、なぜ?たぶんあなたは、これが「アジャイルではない」と思うのだろうか?ここであなたの考えを議論しよう。

原文はこちらです:http://www.infoq.com/news/2008/10/iterating-for-knowledge

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション
BT