BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース デイリースタンドアップのコツ - まとめ

デイリースタンドアップのコツ - まとめ

原文(投稿日:2010/01/30)へのリンク

デイリースタンドアップを良いものにするためには、どのようなコツやテクニックがあるだろうか。ほとんどのアジャイルチームではデイリースタンドアップが実施されている。しかし、Joakim Karlsson氏は次のように言う。 「世の中のデイリースタンドアップのほとんどは、はっきり言って退屈なものです。」全員が参加を強制される単なるミーティングと化しており、ひどい時には日次に加えて伝統的な週次ミーティングにも参加しなければならないのだ

Paul Wynia氏は、プロジェクトリーダがアジャイルのトレーニングを受けたこともアジャイルを経験したこともなく、デイリースタンドアップを日次進捗ミーティングとして扱った例を挙げている。

そのリーダが各参加者に対して詳細に説明させたのは、各機能、バグ、前日に行った認識合わせとこれから行う見積もりを含む作業でした。参加者は作業詳細がびっしりと書かれたメモ帳を持参し、リーダから割り当てられる新しいタスクもそこに記入しました。たった5名のチームにおいて、リーダはデイリースタンドアップを30分から40分も続け、恐ろしく退屈なものにしてしまったのです。

Wynia氏は続けて、ミーティングは10分から長くても15分に抑えるように勧める。さらに氏は、コーチを行っているチームに対して、もし制限時間がオーバーしたらそこから立ち去ってもよいと言う。これはスクラムマスタに対して、ミーティングの実施方法に問題があることを伝えるためだ。

Joakim氏は次のように勧める。

  • 目的に集中せよ ・目的とは、チーム全体がそのイテレーションでやるべきことを行う上で、役に立つ情報をチームメンバと共有すること。ォ
  • チームに集中せよ ・情報は一人のマネージャと共有するのではなく、全員と共有せよ。・
  • 議論は別の場所で ・問題はスタンドアップで解決せず、関係者が参加できる時間を別途スケジューリングせよ。・
  • 準備して参加せよ ・スタンドアップを短くするために、何が完了し何が残っているかについて、チームメンバは知っておく必要がある。・
  • 達成したものに集中せよ ・Joakim氏は次のことに気づいた。「達成したものについて語ることで、システムのどの部分に対して作業したかという情報を提供するだけよりも、一層ポジティブな姿勢を生み出すことができる。」・
  • 約束しろ ・次の24時間で何をするのかを機械的に言うだけではなく、成し遂げようとするものについてチームの他のメンバに約束するようにと氏は言っている。ョ
  • 妨げになるものを挙げろ - わずかな変更のために60個のファイルを触らなければならないということがなかっただろうか

Mike Cohn氏の勧めによれば、チームはデイリースタンドアップをタスクボードの前で行い、作業中のストーリーを指差すよう話し手に頼むのが良いという。加えてCohn氏が述べているのは、チームが9人以上になるとチームの別のメンバが何について作業しているのかが追跡できなくなりやすいということだ。

Drew Stephens氏は、自分たちのチームが「ユーザストーリに焦点を絞ったスタンドアップ」を用いていると報告している。ほとんどのアジャイルチームと同様に、Stephens氏のチームもいたって伝統的なスタンドアップから開始したのだが、チームが大きくなるに伴って苦労したのだ。

ひとつのストーリーについてチーム全体を巻き込む時間がなくなってしまったので、ストーリーを平行させはじめました。同じく気がついたこととして、多くのストーリーが以前よりも長く完了しないままとなり、われわれが「タスクテール」と呼ぶものができ始めたということです。(タスクテールとはストーリが停滞し、はっきりしないタスクがいくつもだらだらと何日も続くことを指します。)タスクテールが発生する原因として、主要なものを2つ特定しました。

  1. コードの品質が低く、結果としてバグがぽたぽたと常に流れ出していることにQAが気づくことになる。
  2. ストーリーが完了に近づいているように見えるが実は終わっていない時に、開発者が他のストーリーに移ってしまう。

このような事実によって、私たちのスタンドアップミーティングは混乱し始めました。ある人がその前の人とは異なるストーリーについて語ることが常となり、これによって各ストーリーの現在の状況を把握するのが難しくなったのです。アクティブなストーリーを完了させるのに何が必要なのかに集中する代わりに、それぞれが何をしているのか、あるいは何をしようとしているのかに注意が向けられました。これはわずかな違いですが、徐々に問題となっていったのです。

彼らの取った解決策はウォークスルーだった。進行中のストーリーに対してウォークスルーを行い、そのストーリーに関して作業したことのある人がそれぞれストーリーに関する質問に3つ答えるのだもし1つ以上のストーリーについて作業していたら、それらすべてについて話すことになる (これは潜在的な危険な匂いだ)。スクラムマスタは誰が話をしたかを記録しておく。もし終わるまでに誰かが話をしたとしたら、それはおそらく、妨げとなるものがあるということなのだ。

Artem Marchenko氏はいくつかの提言をしている

  • PCで議事録をとらない ・誰かがラップトップ(あるいは、その他)で議事録を取っていると、チームメンバが言ったことを再解釈しているにもかかわらず、権力を握ってしまう。・
  • もしチームが報告をスクラムマスタに対して行っていたら、スクラムマスタはそっぽを向くか、極端な場合には後ろを向かなければならない。

Henrik Larsson氏とのインタビューにおいて、 Jason Yip氏 (「It's Not Just Standing Up: Patterns of Daily Stand-up Meetings」の著者)はスタンドアップに対する見方がどう変わったかを記している。

かつては状況について見ようとしていました。しかし、今では約束について見るようになってきました。これは主にMike Cohn氏が書いたものによる影響です。かつては、問題解決であると考えていましたが、今の好みは、タスク/ストーリーボードが使える時には「ウォーク・ザ・ボード」スタイルを強く好むようになっています。また以前は、仕事を終わらせようとしているのか、単に忙しくしようとしているだけなのかに注意することの重要性を強調する傾向がありました。

それでも、何年経っても全く変わらない側面もありました。それが、儀式の活気を保つことやリーダに対して報告するのではなく、リーダと共有することの重要性です。

あなたのチームでは、どのようなことをするとうまく行っただろうか?

以前のInfoQの記事に「よい朝会はどう作るか」がある。

この記事に星をつける

おすすめ度
スタイル

BT