BlazeDSとAMFでWebとデスクトップのアプリケーションを構築する
現在のRIAアーキテクチャにおいて、クライアント/サーバーの通信は重要な位置を占めています。本稿では、James WardとShashank TiwariがアドビによるオープンソースのBlazeDSメッセージングサーバーの世界へ飛び込みます。
- Java,
News
レトロスペクティブの第一(忘れられた?)ルール：やり遂げること
作者 Mike Bria, 翻訳者 編集部 投稿日 2008年4月16日 午前6時4分
非常に経験の浅いアジャイルチームでさえ、「Retrospective」という言葉を明確に理解している。しかし、悲しいことに、チームが実際に最後ま でやり遂げるような改善をおこなうために使用されないと、レトロスペクティブは無駄な努力になる可能性があることが、多くの場合見落とされている。 Gordon Pask Award(source)の受賞歴のあるJim Shore氏(サイト・英語)が、レトロスペクティブを最大限に活用(source)する方法についてアドバイスをし、アジャイルハートビートでのアクティビティーの究極の場所を教えてい る。氏の著書であるThe Art of Agile Development(source)の紹介があるWebサイトへの「bonus material」(source)の最近の投稿記事で、Shore氏は、始めにレトロスペクティブを操作するための方法を簡潔に要約している。
Shore氏の「bonus material」に関する好ましい傾向が繰り返されてきているので、上記フローで役立つビジュアル(source)を盛り込んでいる。
- Kerth's Prime Directive(source)から開始する。間違いをしない人はいない。Prime Directiveは、同僚を責めずに、サポートするように促す。
- 6つのカテゴリーで、参加者に意見を出し合ってもらう。楽しめる、イライラする、困惑する。カードにそれぞれの考えを書き出す。
- 次に、そのカードをホワイトボードに張り出す。カードを動かしたりして、最も似ている同士を近くにする。皆が参加し、誰もしゃべってはいけない。
- できたカテゴリーを丸で囲み、名前をつける。1つを選び、その根本的原因およびソリューションについて意見を出し合う。1つを選べば、それがレトロスペクティブの目的である。繰り返しておこなう。
それからShore氏は、提案されたフォーマットの最後の項目に注意を向けることで、続けている。繰り返しておこなう。
レトロスペクティブの最重要部分は、部屋を立ち去った後に何が起こるかである。レトロスペクティブでは過去を省みて、未来を想像する。根本的原因の分析を おこない、それに対するソリューションを考え出す。それでよい。しかし、ソリューションから1つを選択して、それを最後までやり通すことを忘れてはいけな い。
Shore氏の解説で示唆していること、および繰り返しアジャイルの指導者によって引用されているのは、レトロスペクティブに不幸にも目に見える改善がな いことはよくあるということである。Shore氏は、提案された改良がそれ自体は困難な作業ではないが、それでも実装には失敗が伴うことが多いと指摘して いる。これは、その項目がチームの通常業務に対する普通の取り組みの一部ではないという事実にすぎないためであることを主張している。このため、「big visible chart」(source)にある繰り返し計画の一部を改善すべきだと提案している。
ちょっとしたお楽しみとして、Shore氏の自分の「ミス」からの教訓をどのようにして応用しているのかを検討してみるのもよい。
また、Josh Kerievsky氏のContinuous Learning(PDF・英語)に関する論文およびEsther Derby氏とDiana Larsen氏による著書、Agile Retrospectives: Making Good Teams Great(source)も参考にしてみるとよい。
原文はこちらです：http://www.infoq.com/news/2008/04/retro-follow-thru
No comments
返信