毎日のスタンドアップ-はい、またはいや?[閉まっている]


40

毎日のスタンドアップミーティングはどれほど価値があると思いますか(またはそうでないと思いますか)?

あなたがそれに慣れていない場合、これはスクラムの支持者の一部である毎日の会議を指します(および他のいくつかのアジャイル方法論)。アイデアは、15分のタイムボックスで毎日会議を開催し、全員が立ち向かわなければならないということです(人々がそのポイントになるように促すため)。

会議では、部屋を歩き回って各自が次のように言います。-昨日あなたがしたこと-本日あなたがすることを計画していること-進行の妨げや障害

この実践には価値があると思いますか?誰かがそれをした場所で働いたことがありますか、あなたはどう思いましたか?


1
毎日のスタンドアップミーティングはひどい習慣です。この記事をチェックしてください:毎日のスタンドアップミーティングは悪いマネージャーにとって良いツールです
-yegor256

回答:


40

私は最初の仕事で毎日立ち上がった。まあ、すべての協同組合/インターン/臨時雇用者と、それは実際に長い側にあった-通常約30分。

しかし、短いタイムボックス付きの毎日の会議というアイデアは、他の人が何をしているのかを知るのに大いに役立ちました-それが私が取り組んでいたものである場合、私は彼らがより早く継続するために必要なものを完了するために私のタスクの優先順位を付けることができました。また、誰もが何をしているのかを知る機会を与えたので、誰かが緊急事態を起こした場合、誰もが少なくとも何が起こっているのかを認識していました。

正直なところ、毎日が極端な場合もあります。しかし、すべての人が同じページにとどまるための短い定期的な会議のアイデアは、あらゆるプロセスに価値のある追加です。


4
これはコミュニケーションにも非常に役立ちましたが、進捗を確認できるほど十分に小さいタスクを定義する必要もあります。それ以外の場合は、1か月間「UIで作業している」と言われますが、それはあまり役に立ちません。スクラム/アジャイルの本を読んで、会議だけでなくプロセス全体を実装することをお勧めします。
JDフリアス

1
誰もが同じことに集中する、生産的で正直な職場環境を奨励することが不可欠だと思います。J8Dの発言に続いて、タスクボードの前でできれば毎日のスタンドアップが大幅に改善されるため、「昨日私はxyzで作業した」と言うと、ボード上のその作業項目を物理的に指し示すことができます。数日後に左から(進行していない)から右に(進行して)進行することを確認してください。ブロッカーを特定することは本当に役立ち、誰もが正直になります。
dwynne

1
あなたの会議はより多くの構造を必要としたように聞こえます。スタンドアップは議論や議論の場ではありません。あなたが取り組んでいることを言い、彼らからの助けが必要かどうかを誰かに伝えてください。人々は、あなたが間違った道を進んだり、必要のないコードをやり直したりしないことを確認するために自由に質問することができますが、それだけです。10分。マックス。
ジャコプレトリアス

2
@Thomas Owensいいですね、すべての状況は独特です。他の17人が何をしているのかを本当に知る必要があるかどうか疑問に思うでしょう。たとえば、テスターをスタンドアップに招待することがよくありますが、ほとんどの場合、彼らは観察するためだけにいます。
ジャコプレトリアス

2
スタンドアップはありますが、3〜7人の小さなグループです。私はスタンドアップにあまりにも多くの人々を持つことは悪いアイデアだと思いません
誰も

30

これらの会議は非常に貴重だと思います。彼らは次の利点を提供します-わずか15分を過ごす代わりに

  • 誰もが話題になります。自分の問題を掘り下げて、他の人が何をしているのかを忘れたり、他の人が行っている作業を繰り返したりするのは簡単です。毎日の会議がこれを防ぎます。
  • 人々がゆるむことを許しません。これらの会議で約束をします。それからあなたそれらを維持しようとする必要があります。
  • 人々を交流させます。プログラマーは通常、人と話すのが好きではありません。ただし、そのような会議では、同僚から励まし(およびre責)を受けます。これは、士気にプラスの効果をもたらします。
  • 全員を1か所に集めます。みんながそこに来ることを知っているとボーナスがもらえます。これは、他の会議の手配、発表、および特定の問題について話し合うための小規模グループでのこの毎日の会議の継続に使用できます。通常、このような会議の開催には多くの注意が必要であり、プログラマが使用したくないスキルが必要です。

26

何時間も耐えられます。それは私をこれ以上ポイントにしたり、短い毎日のキャッチアップミーティングに本当の意味/影響を与えたりしません。

しかし、ちょっと、立ち上がって何かをアジャイルとしてブランド変更できるなら、それは良いに違いない!


定期的なキャッチアップ会議が一般的に良いアイデアであるかどうかについては...他のプロセスが効果的でない場合に役立ちます。

昨日誰かが何をしたか、そして次のタスクが何であるかを知りたい場合は、既に記録されている課題トラッカーを見てください。これをチーム全体に伝える明確なフィルターがない場合は、それを設定します(またはより良いソフトウェアを見つけます)。

誰かがブロッカーを持っているかどうか知りたいなら、あなたのメッセージをチェックしてください(email / im / forum / whatever)。誰かがいる場合は、関係者とプロジェクトリーダーの両方に発生時に通知する必要があります。


プロジェクトの方向性を議論するために定期的な会議を開催することは確かに有益です-全体的な目標などを全員が確実に理解できるようにするために、一般的な意味ではなく-毎週または2週間(物事のペースに応じて)開催します

しかし、アジャイルで素晴らしいものを感じることができるように、毎日15分を費やしていますか?時間の無駄。


1
-1クラシックな「クラシック」回答。悪いことにあなたは逃しています。-立ち上げは、勢いとエネルギーを維持することです-「ステータスミーティング」の時間感覚の無駄を避けるために15分のタイムボックス。- 3 questonsは単なるガイドです、会議の目的は、製品/プロジェクトについて話している
ルディ・

10
÷1実際に仕事をしていて、ステータスミーティングのふりをしないのは、ステータスミーティングではありませんが、勢いを維持しやすいと思います。:)
ピーターボートン

17

私の経験では、スタンドアップはそれだけの価値はありませんでした。それらは、空の儀式、または無向のアドホック会議のいずれかです。

  1. 空の儀式:全員が円を巡り、作業中のタスクと進捗状況を述べます。他の人が取り組んでいることを誰も本当に気にしておらず、問題がある場合は(スタンドアップの結果として)何も行われません。

  2. 無向のアドホック会議:誰か(通常、マネージャー、PM、またはビジネスからの誰か)が来て、脱線します。たぶん、今日の火災について詳細に話したり、期限に間に合うかどうか誰かがどのように心配しているのかなど。15分は30分以上になります。こんなに長くなれば本当に座っているはずなのに、みんな立っています。

また、スタンドアップの「スタンドアップ」部分は、会議の時間制限には役立ちません。ミックスに物理的な不快感を加えるだけです。

正式なスタンドアップよりも、チームメンバー間のアドホックコミュニケーションの方がずっと良い経験をしました。誰かがあなたが取り組んでいることやあなたの進歩を気にかけているなら、彼らはあなたに尋ねるか、あなたが彼らに言うでしょう。問題がある場合、またはブロックされている場合は、そのことを知る必要のある人々が知っていることを確認してください。要件が不明な場合は、ビジネスユーザーまたはBAを追跡し、それについて尋ねます。


1
私は両方の種類のグループに参加しており、スタンドアップ(または座り込み)ミーティングは価値を高めるか、または関連性がありません。私が言う失敗したことは、あなたが与える第2のポイントと同じです、力を持つチームの誰かが会議を脱線させます(そしてそれについて受動的で攻撃的です)。
スポイケ

私も同様に「チームメンバー間のアドホックコミュニケーションについては、正式なスタンドアップよりもずっと良い経験をしました。誰かがあなたの作業や進行状況を気にかけている場合は、尋ねられます。問題がある場合やブロックされている場合は、そのことを知る必要のある人に確実に知らせてください。」....スタンドアップは儀式にすぎません!
ナワズ

8

正しく実行されれば、非常に価値があると思います。私にとってうまくいったフォーマットはこれです。

各人は、次の質問に短い回答をします。
a)何に取り組んでいますか?
b)次の会議(明日)までに何をしますか?
c)前回の会議で達成すると言ったことを達成しましたか?
d)どのような障害が進行を遅らせたり止めたりしていますか?

上記の詳細な議論は、会議中に短くしておくために抑制する必要があります。誰もがその後にとどまる(またはその日の後半に会う)ことができ、関連のある人と、延長されたカバレッジを必要とするものについて話し合うことができます。

これにより、以下の目標が達成されます。a
)チームリーダー/製品の所有者は、遅延の可能性について迅速に対応しています。
b)チームリーダーは障害物を迅速に除去できます。
c)チームリーダーは、車輪を素早く回している人を特定できます。
d)内向的すぎて必要なときに助けを求められないかもしれないチームメンバー間のコラボレーションを促進します。
e)コミットメントを短くすることにより、モメンタムを促進します(プロジェクトで利用可能な時間まで拡大する作業を最小限に抑えます)。


cと答える必要はありません。人々にチームに「報告」するのではなく、お互いに話をするように求めているのではありません。(a、b、d)-ミーティングはチームのリーダーのためではなく、チーム自身のためです!
ルディ

チームリーダーはチームのメンバーです。
JohnFx

8

私の職場で実践されているように、「デイリー15ミニッツスタンドアップ」が30分、その後45分、そして多くの場合60分まで伸びているので、それらは有用ではありません。プロジェクトマネージャーがプロジェクターやネットワーク共有など、その日のランダムな悪魔をいじるのを待つ間、誰もが座っている。彼は、会議の前にステータスの更新を提供するために時間を割くすべての人を主張しますが、その後、再びすべての人にクエリを実行します(最後のいくつかの瞬間に他の何かを達成した場合に備えて)。残っている元の概念の唯一の部分は「毎日」です。

これをしないでください。


1
それらが物事が変わった方法では役に立たないことは明らかです。スタンドアローンである理由の1つは、ミーティングに時間がかかりすぎたり、プロジェクターなどを持ち込んだりするのを防ぐためです。-
ピート

4
日々のスタンドアップを間違っていることで完全に見逃しているということは、アイデアが間違っているという意味ではありません。スタンドアップミーティングをより良くして、タイムボックス、固定された場所、固定された時間、固定された目標に固執してください:チームコミュニケーション、そして彼らはするのが楽しいです。ため息-スタンドアップは、チームやPMではなく、チームのためです。
ルディ

1
プロジェクターを取り除きます。
カークブロードハースト

6

これは便利な場合もありますが、実際には実用的ではありません。

他のチームメンバーに簡単にアクセスできないチームがある場合、または組織がマネージャー/ PM /誰でも見つけられない場合、少なくとも1日1発の質問に答えられることがわかっています。

実際には、問題をすぐに議論しないように人々を励ますことがあり、かなりの時間を費やすことになります。例えば:

1つのアクティブな開発プロジェクト(通常は2つ)のみに参加している場合、通常、少なくとも1つがQAを完了し、1つが同時にスピンアップします。それは1日3回15分のスタンドアップです。私の背中合わせはほとんどありません。各自の前の停止ポイントにいることを確認し、各自の後に同様に軌道に乗ることを確認するのに時間がかかります。これらの損失はそれぞれ10分の1であると仮定した場合でも、これは毎週のスタンドアップで1日の仕事を失うことになります。

コミット会議とデモを追加すると、1日が簡単に終わります。

私見では、チームにコミュニケーションの問題がある場合、毎日の会議が役立ちますが、そうでない場合は、単にリソースシンクが多すぎます。


4

SCRUMとアジャイルが考えられるずっと前に、私は2年かかった人材調査のチームリーダーでした。毎日の会議がなければ、もっと時間がかかりました。そもそも、人間は人間であり、誰も注意を払っていないことを知っていれば、彼らはたるんでしまうでしょう。彼らが毎日進歩を示さなければならないなら、彼らはよりゆるやかになります。ジョーが彼らよりも進歩しているように見える場合、彼らはより緩むことはありません。さらに、問題が危機になる前に、マネージャー(または誰でも)に問題がいつ発生するかを知らせます。したがって、スティーブが1週間遅れてハリーが先を行く場合、いくつかのタスクを移動できます。これにより、1人がスタックしたためにプロジェクトが遅れることがなくなります。さらに、通常、他の誰かがその人のスタックを解くのを助けることができます。

今、私は1つの場所で働き、新しい従業員に大きなプロジェクトを与えました。(私は彼の上司ではありませんでした。)彼が上司に伝えた進捗報告は「すべてがすばらしい、すべてが時間通りに行われる」が、具体的で誰も彼が前日から行った進捗を正確に言う必要はなかった。彼は、経験豊富な方が推測しているように、締め切りの1週間前に予告なしに終了し、彼のタスクはすべて完了しませんでした。これが、毎日の会議が必要な理由です-これらの人々が真の進歩を遂げ続け、プロジェクト全体が失敗する前に彼らがいつでないかを知るためです。私は数百万ドルの顧客を維持できるように、彼の仕事と私の仕事をし、夏の間は残業をしました。

ええ、私たちは皆、開発者はすべて内部的に動機付けられており、常に私たちのために商品を生産していると信じていますが、真実はあなたがチームや組織をこのような人々から守る必要があるということです。あなたは彼らが誰になるのか決してわかりません。時々、それは新入社員ではなく、組織に腹を立てている人(正当かどうかに関係なく)または妻を失ったばかりの人(少なくともこれらの人が誰であるかを知っていますが、誰もが個人的な問題を共有しているわけではありません)。


1
開発者を動かすために開発者にカーソルを合わせる必要がある場合は、あなたまたは開発者のいずれかを交換する必要があります。
異常

4

はいまたはいいえ、そしてそれらは貴重なものです。2つの異なる質問です。答えも異なる場合があります。後者の質問の場合、答えは視点によって異なります。

最初の質問、はいまたはいいえ?それはだそう。スクラムまたはXPの観点から見ると、スタンドアップは不可欠なアクティビティです。毎日のスクラムがない場合、それは実際のスクラムではなく、「スクラムと呼ばれますが、私たちは毎日のスタンドアップを行いません」、または簡単にスクラムします。かんばんの観点を含めたい場合、ほとんどのかんばんチームはスタンドアップを行いますが、その方法はそれらを規定していません。

2番目の質問は、(どのように)価値があるのか​​、より複雑です。スクラムまたはXPを実践している場合、コラボレーション、チームワークを促進し、チームをより効果的にするために、スタンドアップが不可欠であると信じる必要があります。だから答えは間違いなく貴重です。

無駄のない支持者の視点は非常に異なっています。極端な無駄のない見方は、スタンドアップをするかどうかは顧客が気にしないということなので、彼らは無駄です。無駄は何ですか?それを最小限、理想的にはゼロにカットします。

より控えめなリーンビューは、正確に無駄ではありませんが、毎日のスタンドアップは調整コストあり、付加価値のあるアクティビティではないということです。あなたはスクラムの同僚と悪魔の擁護者を演じて尋ねることができます:あなたの15分のスタンドアップが付加価値のある活動だと思うなら、毎日30分または45分それらを行い、付加価値を簡単に拡大してみませんか?

無駄のないルーツを持っているが、アジャイルマニフェストの原則を実現することを目的とするかんばんは、スタンドアップを行うことによってこのパラドックスを解決しますが、従来のアジャイルスタンドアップ形式とは非常に異なる会議構造を使用します。その結果、会議が大幅に短縮され、リーンの観点に沿ったものになります。 この本には、50人のかんばんチームが10分で毎日スタンドアップを行う例があります。

要約すると、毎日のスタンドアップを行うかどうかにかかわらず、答えは間違いなくはいです。しかし、それらは価値があり、どれほど価値がありますか- それは依存します。


50人のチームが10分間で毎日立ち上がるという話は、神話が打ち消されたものです。数学をして本物になりましょう!1人あたり12秒です。それが属するゴミ箱にその本を投げてください!
キャプテンセンシブル

@Seventh Element:あなたの「数学」は、会議の目的がNチームのメンバー全員に話す機会を与えることであるという仮定に基づいています。これは確かに間違った仮定です。否定的なコメントを書く前に建設的な答えを書くと、このサイトに貢献できることは確かです。
アジェグロフ

4

スタンドアップの最も便利なタイプは、かんばんタイプです。

  1. 実際のワークフロー/バリューストリームを反映するタスクボードが必要になります。このタスクボードは、スタンドアップの焦点です。
  2. 人ではなく作業項目に焦点を当てる
    • チームとして開始できるものよりも、タスクボードに基づいて完了できる作業項目に焦点を当てます
    • ボードが示す問題の解決に焦点を当てる-ボトルネック、ブロックなど

(これはおそらく、スクラムの設定ではうまく機能しません。そこでは、人々へのコミットメントとフォーカスが重要なメカニズムです。)

この方法では、多くの人々がいても、スタンドアップミーティングは短時間で済みますが、それでも実際に使用できます。


2

毎日のスタンドアップミーティングはどれほど価値があると思いますか(またはそうでないと思いますか)?

すべてのスクラムフレームワーク会議は重要ではありませんが、毎日のスタンドアップミーティングは、スクラムフレームワークの「最も」重要な会議だと思います。それは身体の心のようなものです。心臓が定期的に血液を送り出さない場合、身体は死に至ります。この場合の身体は、スクラムに続く組織またはプロジェクトであり、心臓はスクラム会議です。

この実践には価値があると思いますか?はい。デイリースクラムは、コミュニケーションを改善し、他の会議を排除し、開発の障害を特定して削除し、迅速な意思決定を強調および促進し、プロジェクトの知識レベルを向上させます。デイリースクラムはステータスミーティングではありません。デイリースクラムは、そのスプリントゴールに向けた進捗状況の検査です(3つの質問)。通常、スプリントの今後の作業に適応するために、後続の会議が開催されます。その目的は、チームが目標を達成する確率を最適化することです。これは、スクラムの経験的プロセスにおける重要な検査および適応会議です。

誰かがそれをした場所で働いたことがありますか、あなたはどう思いましたか?

はい、前回のプロジェクトでは、スクラムフレームワークとアジャイルのプラクティスに従いました。私たちはスクラムフレームワーク全般について非常に真剣であり、心を込めてそれをしませんでした。最初は5人のチームでしたが、その後9人ほどの大きなチームに移り、その後4年の期間で6人のスプレッドに戻りました。毎日のスクラム会議では、全員が同期し、障害が透明であることが確認されました。チームとして、私たちの目の前でバーンダウンがどのように進行しているかを見ることができました。自分自身。チームが6人以下の場合は、間違いなく簡単です。スクラム会議の目的は、自己点検チェックを行うことです。目標の方向に進まないものが見つかった場合、または何かがブロックされた場合、自己組織化チームが適応し、


2

チーム全体で毎日完全にネットワーク化されたコミュニケーションを行う正当な理由がない限り、それは時間の大きな無駄のように聞こえます。

むしろ週刊誌があります。


1

私の経験では、翌日あなたが何をするかを事前に計画することで、生産性が大幅に向上します。そのため、これらのスクラムのようなミーティングを持つことは、その理由だけで時間を無駄にするだけの価値があります。

ただし、それらを短くするか、グループSkypeチャットで毎日同時に実行するようにしてください。ただし、お互いの更新を必ず読んでください。

あなたが帰宅する前の毎日の終わりに毎日のステータスレポートは同じ効果があります。


1

3人と5人のチームで効果があり、約20人のイベントプランナーのチームで効果的に使用されているのを見てきました。あなたはそれを短くしなければなりません、あなたはそれを動かし続けなければなりません。座っていても大丈夫ですが、余分なもの(配布資料、ホワイトボード、ビデオなど)はないはずです


1

毎日のスタンドアップは、どの方法論や分野で作業しているかに関係なく、素晴らしいアイデアだと思います。定期的にそれを守れない場合は、1つのスタンドアップに参加している人が多すぎるか、会議の焦点が十分ではありません。

マーケティングチームが私たちをコピーし始め、今ではスタンドアップも持っています-開発者だけのものではありません!


0

約7年間、アジャイルスクラムであることを知る前に、「スタンドアップ」ミーティングを行ってきました。私の意見では、彼らはプロジェクトがどのように進行しているか、誰かが助けを必要としているかどうかについての一般的な感覚を得るための素晴らしい方法です。私のチームメンバーの何人かは、助けを求めることを好まないが、これがしばしば毎日のスタンドアップで行われたとき、それを受け入れるでしょう。

会議は短くする必要があり、通常は7人のチームメンバーと10分未満で会議を行いました。10時の休憩の直前に計画を立てるのに役立ちます。また、会議ではテクノロジーを使用せず、ポストITタスクといくつかのチャートを備えたスクラムボードのみを使用します。


0

プラス面として、これらの会議は、緊急かつ即時のビジネス目標を達成するという点で生産性を高める効果があります。

マイナス面では、これらの会議(毎日:何をしましたか?何をするつもりですか?あなたのやり方は何ですか?)は、「グーグルタイム」と呼ばれることをやめさせます。ビジネスに即座に影響を与えますが、将来的には重大な影響を与える可能性があります。

プロトタイプを作成した製品の1つが、毎日の会議テストに合格することはなかったでしょう。ありがたいことに、私の昔のマネージャーは、自分で作業するためのボートの自由を与えてくれました。しかし、古いマネージャーが去り、毎日のスクラムの概念を受け入れる新しいマネージャーが入ってきたので、毎日のスクラム環境でプロトタイプをどのように開発できたのかわかりません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.