アジャイル方法論におけるスタンドアップの目的とその期間は何ですか?[閉まっている]


13

私はかつてウォーターフォールの方法論で働いていましたが、今ではアジャイルの方法論に従っているチームにいます。彼らはそれを間違っているようです。たとえば、1日25分以上続くスタンドアップがあり、これは非常に面倒です。さらに、私は他の何よりも自分の給料を経営陣に正当化しているように感じます。

このように感じるのは間違っていますか?これは通常、スタンドアップが行われている方法ですか?


3
回顧展で、スタンドアップには時間がかかりすぎると提案しましたか?25分かかる会議中に何が議論されましたか?
dcaswell

チームには何人いますか?
ガイサートン

1
@GuySirton:私はあなたの言っていることを理解していますが、その一方で、毎日30分も過ぎていませんか?
user10326

1
反対票と説明なし
....-user10326

2
@ user10326:経営陣は、明らかにそれが多すぎるとは考えていません。彼らがルールを作り(会社によって異なる)、あなたが彼らにそれが長すぎると納得させることができないと仮定すると、それは30分になります。プログラマーやスクラムマニュアルを参照しても、ほぼ確実に説得することはできません。チーム/仕事の状況に対処する方法は、おそらくWorkplace SEの質問です。ここでは、どのように機能するかについて説明できますが、特定の状況でサポートできるかどうかはわかりません。
ガイサートン

回答:


13

スクラムについては、Ken SchwaberとJeff Sutherlandが説明します

デイリースクラム

デイリースクラムは、開発チームがアクティビティを同期し、次の24時間の計画を作成するための15分間のタイムボックスイベントです。これは、最後のデイリースクラム以降の作業を検査し、次のスクラムの前に実行できる作業を予測することによって行われます。毎日のスクラムは、複雑さを軽減するために毎日同じ時間と場所で開催されます。会議中、開発チームのメンバーは次のことを説明します。

  • 昨日、開発チームがスプリントの目標を達成するのを助けたのは何でしたか?

  • 開発チームがスプリントの目標を達成できるように、今日は何をしますか?

  • 自分または開発チームがスプリントの目標を達成するのを妨げる障害がありますか?

開発チームは、デイリースクラムを使用して、スプリント目標に向けた進捗状況を調査し、スプリントバックログの作業を完了するまでの進捗状況を調査します。デイリースクラムは、開発チームがスプリントゴールを達成する確率を最適化します。開発チームは、スプリントの目標を達成し、スプリントの終わりまでに予想される増分を作成するために、自己組織化チームとしてどのように連携するかを毎日理解する必要があります。開発チームまたはチームメンバーは、詳細な議論のために、またはスプリントの残りの作業を調整または再計画するために、デイリースクラムの直後にしばしば会合します。

スクラムマスターは、開発チームが会議を開催することを保証しますが、開発チームはデイリースクラムを実施する責任があります。スクラムマスターは、開発チームにデイリースクラムを15分の時間枠内に収めるように教えます。

スクラムマスターは、開発チームメンバーのみがデイリースクラムに参加するというルールを実施します。

デイリースクラムは、コミュニケーションを改善し、他の会議を排除し、削除のための開発の障害を特定し、迅速な意思決定を強調および促進し、開発チームの知識レベルを向上させます。これは重要な検査および適応会議です。

他の方法論には異なる儀式があり、異なるスクラムチームでさえ、これを異なる方法で最適化する場合があります。重要なアイデアは、チームが迅速に集まり、チームが確実に提供できるようにすることです。管理ステータスレポートであってはなりません。ただし、より簡単に破壊されるのはアジャイルなアイデアの1つです。


また、Webベースのスタンドアップミーティングがあり、それが誰かを助ける場合に毎日のスタンドアップに使用しています:standup.report
MagExt

8

TL; DR

適切なサイズのスクラムチーム内で適切に実行された場合、毎日の立ち上がりは15分以上かかることはありません。時間がかかる場合は、チームが大きすぎるか、プロセスに問題があります。

スタンドアップの目的

毎日のスタンドアップは、チーム全体のコミットメントおよび調整会議です。これは、チーム全体が障害、完了したストーリーまたは未完了のストーリー、および1つのチームメンバーのTo Doリストから他の誰かのタスクにプルする準備ができているタスクを認識できるように設計されています。

スクラムマスターとプロダクトオーナーがスタンドアップに積極的に参加することが重要ですが、チームがそれらのいずれかに報告している場合は、スクラムプロセスがうまく機能していない可能性があります。Project Management Stack Exchangeの関連する回答には、「プロジェクトの匂い」の10点リストがあります。は、下部、その一部はあなたの場合に当てはまるかもしれません。たとえ当てはまらなくても、次のスプリントレトロスペクティブでスタンドアップの有効性を確実に再評価する必要があります。

タイムボックスを尊重する

「3つの質問」は、ステータスプルに似た会議につながる傾向があるため、具体的な形式として「3つの質問」を嫌いますが、マイクコーンのデイリースクラムの標準的な説明を指さなかった場合、私は失望します。ページには、部分的に言っています:

一人一人が昨日達成したこと、そして今日達成することに焦点を当てることにより、チームはどのような仕事が行われ、どのような仕事が残っているかについて優れた理解を得ることができます。毎日のスクラム会議は、ボスが誰が予定より遅れているかについての情報を収集している状況更新会議ではありません。むしろ、チームメンバが互いにコミットメントする会議です。

そのページには、より多くの詳細といくつかの具体的な例があります。ただし、質問の目的上、次のように明示的に述べられています。

スクラムの毎日のスタンドアップミーティングは、厳密に15分の時間枠で開催されます。これにより、議論は活発になりますが、関連性があります。

タイムボックスはスクラムの基礎です。スクラム内のほとんどのタイムボックスは、検査と適応のサイクルの結果としてチームによって調整できますが、スタンドアップの長さを延長することは不適切なプラクティスと見なされます。タイムボクシングの原則がプロセス内で尊重されていない場合、それは一般的に非常に気まぐれな「プロジェクトの匂い」です。


3

あなたが説明しているのは、チームにとって「スタンドアップ」が失敗する1つの方法です。

誰もが他の全員が何をしているのかを理解し、昨日達成したこと、今日達成することを説明し、約束を果たす能力に影響を与える可能性のあるものにフラグを立てるため、最高のスタンドアップは短いです。チームの他のメンバーは、お互いの障害を迅速に解決できることを示すことができますが、解決策はスタンドアローンの外に参加します。

要するに、彼らはチームを結びつける接着剤でなければなりません。

状況の更新のように聞こえますが、あなたは配達/配達ではないことを説明しなければなりませんが、チームは障害を配達し、除去するためにお互いをサポートするためにスタンドアップミーティングを使用していないため、チームは機能していません。

これが発生した2つの環境では、チームがイテレーションの約束を確実に果たす責任を委任できなかったスクラムマスターがいることが原因です。ある場合には、それは特に逆効果であり、チーム内で私たち/彼らの態度を生み出しました。

スクラムは自己組織化チームに関するものであり、チームは組織を組織して問題を迅速に解決し、コミットメントを達成します


2

すべてのアジャイルプロセスと同様に、この目的は「価値を得るもの」です。

通常、毎日の立ち上げは、影響の少ない方法でチームメンバー間のコミュニケーションを確保するためのメカニズムであり、全員が現在のタスクセットに関するチームの位置を理解できます。だから、みんなが「昨日xをやったから今日はyをやる」と言っている5分間のスタンドアップは問題ありません。15分間のスタンドアップは、チームが次の作業を決定してタスクボードを更新します。

ただし、これらのことを他の方法で伝える場合、たとえば、ローリングソーシャル通知システムを使用する場合など、まったく必要ありません。

同様に、スタンドアップを長くし、より多くのチームが報告するようにしたい場合は、それでも問題ありません。私はそれを疑問に思うだろうが、仕事を与えられるためにより直接的なアプローチを好むチームがあることを知っている。結局、アジャイルはあらゆるタイプのチームに対処できます。

あなたが尋ねるべき本当の質問は、あなたがそれから何らかの価値を得ているかどうか、もしそうでなければ、あなたが価値を得るためにそれを何に変えるのでしょうか?スクラムの聖典に規定されているようにスタンドアップを行うことはアジャイルではありません。スタンドアップを行うことは、チームにとって何かを意味するので、全員が一緒に仕事をすることができます。

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