BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース アジャイル/スクラムの振り返り - ヒントと秘訣

アジャイル/スクラムの振り返り - ヒントと秘訣

ブックマーク

原文(投稿日:2010/12/16)へのリンク

どのようなアジャイル/スクラムの実践でも、振り返りとフィードバックのループは最重要だ。私たちはいくつかのツールを使ってチームを改善している。しかし2日間のアジャイル入門クラスではこのようなツールの紹介はいいかげんになってしまう。時間のないトレーナーは多くの場合、このトピックをひとつの振り返りの形式の概要だけ示すことで終わりにしてしまう。問題はひとつの振り返りの方法だけでは、振り返りの参加者は退屈して参加への意欲をなくしてしまうということだ。

Brian Lawrence氏は、地味だが大きなグループやまだ一緒に働いたことのない人同士のグループで上手く使える振り返りの形式を提供している。氏はチームに3x5サイズの索引カードか付箋を与える。カードは色が違っても種類が違ってもいい。そして、チームは最初の20分にそのカードにうまくいったことを書き、次の20分に改善が必要なことを書く。まとめ役が壁にそのカードを張り、トピック毎にまとめる。そしてチームは残り時間ですぐに実施できる項目を決める。

Jimmy Bosse氏は振り返りはとても重要なので何が起きても行う必要があると言う。氏の説明では、振り返りは変化と改善の力をチームに与える。振り返りを行わなければ状況を良くしようとするよりも、バグや問題は責任のなすり付け合いのCYAゲームになってしまう。

Yves Hanoulle氏はこう答えている。

私は“振り返りを絶対やめるな”というのは間違いだと思います。
「絶対」とか「いつも」という言葉はアジャイルの言葉ではありませんので使いません。;-)

もしやめたいのなら、チームに根本要因分析をしてほしいと思います。どうしてやめたいのかを明確にするためです。

Doug Shimp氏は振り返りのノートは公にすべきか、と尋ねられた。氏は、チームの目指すことや学ぶべきことはノートを公けにすることより、それを共有することだ、と答えた。また氏は、文脈を無視して解釈された結果、人事領域の問題になってしまうような改善事項もありうることに強く注意を促している。

Jason Little氏は振り返りのための部屋の作成に取りかかっている。ひとりのコーチがあらゆる場所に顔を出せない場合に備えているのだ。氏は

  • 開放感あふれるすてきな部屋
  • 情報がある場所: “振り返りの価値になるような、小さなミーティングの形式や参考にできるTo-Doリストが事前に準備されている”
  • “振り返りツールキット”が入ったバスケット。アジャイルコーチのための道具を含む。付箋やマーカー、さまざまな手法が書かれたハンドアウト。

下記が氏のアジェンダのサンプルだ。

  1. 焦点を決める
  2. アジェンダを提示し、評価を行う
  3. 対象領域で何がうまくいき、なにがうまくいかなかったのか互いに意見を出しながら考える
  4. 何を止め、何を始めるのか議論する
  5. 実行計画を作成する
  6. うまくいった/いかなかったの付箋を貼付ける

アジャイル振り返りウィキにはあまり知られていない活動が多く記載されている。例えば、

Christopher Avery氏は振り返りの捉えにくい効用について書いた。

  1. 振り返りはチームがチームらしく働き、他の人の声を聞き、チームのメンバの見方を統合して、次のイテレーションでどのようなことをするのかについての共通認識を持つための機会である。
  2. “閉じること: 他のことが精神的感情的に気がかりになっている状態で何か新しいことを始めるのは難しい。”

この報告者はよい振り返りを実施するための入門記事を書いた。私は前のスプリント/イテレーションに起こった良いこと(うまくいったことを読み上げ評価する)を重視して、その後改善点に着目する。こうすることでチームを盛り上げて、難しい問題を議論しなければならないときも、積極的な雰囲気の中で議論できるようにする。また、この方法は次のイテレーションの行動の小さなゴールを作成して、それをチームの持ち物にするためにも重要だ。こうしないと改善は行われなくなり、チームのメンバの振り返りに対する興味も失せてしまうだろう。

ScrumDeskのブログではスピードボードイノベーションゲームについて書いている。

このゲームの方針は2つのアンカとエンジンがついたボートを描くことです。ボートは現在着目している領域 (特に大きなグループの問題を分析する場合)を表す名前をつけます。

チームのメンバに何がボートのスピードを遅くしているのかを書くようにお願いします。これはひとつの考えをひとつのカードに書き、アンカの部分に貼付けます。そして、何がボートを速くするするのかについての考えをチームのメンバに書いてもらいます。これはエンジンの部分に貼付けます。そしてその後、アジャイル/スクラムの振り返りと同じようにカードをグループ化したり並べ替えたり評価したりします。

私たちはセッションの間に2台のボートを作成しました。皆慌てることなく多くの考えを発表してくれました。彼らは自由に実現可能な/期待できる解決策を作成しました。すぐにでも実行項目にできるような解決策です。

最後に紹介するのは、Matthew Bussa氏のヒントと秘訣だ。

  • 困惑しないこと。最初の数回の振り返りは長く行い。次第に短くします。
  • チームのメンバが自身の関心事や解決策について発言する場として振り返りを活用します。否定的なことだけを話すのは止めましょう。何がうまくいったか、それをどう持続させるのかについて話しましょう。
  • 取り組む項目 : これは重要で、振り返りがどの程度効果的になるかに反映されます。適度な取り込む項目を用意し、個人に割り当てます。そして、これが最も重要なのですが、次の振り返りでその状況を確認します。チームが項目を制御できているのなら、項目を完了させるために実行可能なあらゆる手段を実行できます。
  • 取り込む項目を3つから5つに抑えます。優先度の高いものに限ります。3つから5つの項目を覚えておくことは20ものやらなければならなそうなことを覚えておくより簡単です。
  • 振り返りの活動を継続的に変えていきましょう。こうすることで会議を新鮮に保ち、マンネリ化しないようにします。"Agile Retrospectives Making Good Teams Great"を読みましょう。
  • 可能な限り活動時間を守りましょう。チームのメンバの時間を尊重するためです。

以前、InfoQでは関連する次の記事を書いた。成功する振り返りの要素: 準備と参加。そして、ふりかえりについてのふりかえり

この記事に星をつける

おすすめ度
スタイル

BT