InfoQ

News

ふりかえりを改善するための秘訣

作者 Mark Levison , 翻訳者 沼田 暁子 投稿日 2008年12月26日 午後12時28分

コミュニティ
Agile
トピック
アジャイル技術,
変化
タグ
継続的な改善,
Retrospectives,
Productivity

「Agile Retrospectives: Making Good Teams Great(邦訳:アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き)」の共著者であるEsther Derby氏(リンク)は先ごろ、ふりかえりを改善するためのテクニックについて書いた。

  1. グループのメンバに仕事をさせる - 部屋の前に立ってあらゆる書き物をすることは、チームのメンバがアイデアを自分のものにすることを妨げる。そのかわり、彼らに(濃いマーカーを使って)大きなポストイットに書いてもらう - そうすることによって、関係者全員が何かを提供し続けるし、最も寡黙な人でさえもそうすることを促される。
  2. 正確に記録する - ファシリテータ(あるいはスクラムマスタ)はグループのアイデアをとらえるためにいるのであって、それらにフィルタをかけたり、自分自身の意見を挟まない。
  3. 並列処理を利用する - いくつかの議論しなければならない問題点がある場合は、2つか3つのグループに分けて根本的な原因を分析する。ものごとのスピードが上がるほか、この方法によってチームに1人か2人いる持論を言い立てる人の影響が減る。
  4. グループのメンバに結論を出させる - 時々、ファシリテータ(あるいはスクラムマスタ)はチームから出された生のデータを見て、チームに自分達の仕事をさせることなく結論を告げるだろう。実質的にファシリテータは、チームの意見を尊重しないと言っているのだ。チームが自分達でデータを分析するためにはもっと長い時間がかかるだろうが、それによって彼らはより優れた結論を出し、その結果生じたアクションアイテムを自分達のものにする。
  5. 合意した内容を吟味する - 短時間の議論の後で、チームが基本的合意(いつも最終決定というわけではなく、中間地点の場合もある)に達したのかを吟味するのは有益である。結論は出されなければならないし、全員が明確な質問をしたら、私達は「Fist of Five(リンク)」を使用してテストを行う。この手法では、支持の度合いを指の数で示す。5 - このアイデアが私のものだったらと思うし、変化を導くのを手伝う。3 - 私はグループの意思に従う。1 - まだ議論すべきことがある。握りこぶし - 反対する、私はこの合意を阻止し、もっと議論を押し進めたい。

George Dinwiddie氏(リンク)は、ふりかえりから行動を起こし、それらをストーリーカードに書き、プロダクトバックログに追加することを提案している。これにより、それらが可視化された状態が保たれ、実行されやすくなる。さらに、最大の問題や最も重要な問題は - 自信を失うこともあるので - 取り組んではいけないこともある、と彼は述べている。そのかわり、チームに彼らが取り組む力のあるタスクを選択してもらう。

Jo Geske氏(リンク)は次のように提案している。

スプリントを表すかなり抽象的なスケジュールの重要なイベントにポストイットをつけるかわりに、私達は各スプリントのバーンダウン・チャートに直接貼り付けます。

 利点:

  • 考えることを促す(なぜこの日はバーンダウンが高かった/低かったのだろうか?)
  • スプリントやチームに関係のあるイベントへの集中力を高める
  • 原因と結果の相関関係を明らかにするのを助ける
     

Mike Sutton氏は、それをさらに一歩進めている。「スプリントのスケジュール帳としてバーンダウン・チャートを拡張し、タスクのバーンダウンだけではなく、(上記のように)障害となるものや、より良いふりかえりを可能にする重要なイベントをとらえることができます。」Mike氏(リンク)は次に、障害の追跡や、振り返りを行う時まで問題を覚えておくことに苦労しているチームを使って、これを説明している。
bdc_impediments_on_graph

Mike氏が使用したひとつのアプローチは次のものである。障害にポストイットをつけ、その中には日付、理由、その他のヒントや背景を含めた。問題が解決されると、ポストイットにさらに注釈がつけられた。
 

ふりかえりを支援するのに加え、このアプローチにより、緊急度のバランスが保たれてデイリー・スクラムに集中できるようになることにMike氏は気付いた。
 

Ilja Preuss氏(リンク)は、これは間違いなく興味深いアイデアであるが、バーンダウン・チャートに関する事柄にふりかえりを集中しそうなので、もっと捉えにくい問題や良いものをスプリントから引き上げるために、その他の手法も使用されたことを保証するだろう、と述べている。最終的に、彼は時間をかけて自分のふりかえりの進め方に変化を持たせているので、チームが溝にはまって動けなくなることは無い。

原文はこちらです:http://www.infoq.com/news/2008/12/retrospective-tips

ブックマーク
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をベースとしたフレームワーク)内でのそれらの使用について取り上げます。