スタンドアップ会議を文書化する必要がありますか？

私の会社の別のチームが彼らのスタンドアップミーティングを文書化し始めますが、それは時間の無駄だと思います。私が知っている限りでは、スタンドアップミーティングはステータスレポートのためではなく、コミュニケーションのためのものです（間違っている場合は修正してください）

それでは、スタンドアップミーティングを文書化する必要がありますか？

アジャイルの利点の1つは、各チームが自分に最適なものを決定し、それに取り組むことができることです。

ただし、メモを取る必要がありますか？番号; 私の経験では、チームが次のような中核的な原則のバックトラックを開始することに決めた瞬間に：

• プロセスおよびツールを介した個人および対話（非スクラムのようになり始める文書化されたスクラム）および
• 包括的なドキュメンテーション上の作業ソフトウェア（1日のスクラム分、次はどうなるかを知っている人）

その後、そのチームはアジャイルから離れて、よりドキュメントの多い、低速の作業アプローチに移行し始めます。

Martin Fowlerの「It's Not Just Standing Up」では、メモを取ることや、スタンドアップミーティングの「議事録」を文書化することについては言及していません。スタンドアップミーティングから持ち帰るべきはギフトだけです。

• 一日をうまく始めるために
• 改善を支援するために
• 適切なことに集中するために
• チームの感覚を強化する
• 何が起こっているかを伝えるため

ニーモニックデバイスとして、ギフトを考えてください：グッドスタート、改善、フォーカス、チーム、ステータス

しかし、誰かがあなたが彼または彼女の仕事を手伝う必要があるブロッカーを持っている場合、あなたは彼らが言っていることについてメモを取る場合、それは全く異なっています。-それで自分をノックアウトします。

参考として、私はプロダクトオーナーであり、現在、会社でスクラムマスターを指導しています。分はレトロスペクティブです。これは、チームが次のスプリントに向けて取り組むための具体的なものを与えるためです（これらの「分」は短い箇条書きのセットです）。

スクラムは次のとおりです。

• 私が取り組んだこと
• 私が次に取り組んでいること
• ブロッカー

それでおしまい。迅速かつ要点。最大5〜10分 文書化する必要はまったくありませんが、誰かが何かを行動に移す必要がある場合、それは問題になりません。

私が働いていた最後の会社では、スタンドアップミーティング中に行われた大規模な決定のみを文書化していました。

あなたが言ったように、スタンドアップミーティングは少数の人々のグループ内でのコミュニケーションのためのものであり、それは特定の人々のグループに関係するだけです...とにかく...時々...誰かが重要で、最終的にはできるかもしれない興味深い何かを言うプロジェクトの作成方法に影響を与えます（注意が必要なトリッキーなバグに関する警告や、知っておくべき非常に重要な技術的ポイントがしばしばありました）。それが、「より良い未来のための重要な」ポイントのみを文書化し始めた理由です。

コンテンツの重要性について完全に確信しており、近い将来または遠い将来にチームに役立つと言える場合にのみ、ドキュメントスタンドアップミーティングは賢明だと思います。

スタンドアップをカジュアルな会議として扱います-声明が正式なもの、最終的なものなど、まだ慣れていないトピックを取り上げる可能性が低いという期待はありませんが、重要なことは議論する必要があるということを理解しているだけですチームへの単なるメールであっても、他の場所で続行します。これにより、スタンドアップが完全なプロジェクト会議にならないようにするだけでなく、特定のスタンドアップに参加できなかった人を除外することも避けられます。

私の経験では、スタンドアップは、チームがプロジェクトのどこにいるかの「ハートビート」を得るための素晴らしい方法です。私が出席するものはそれぞれ数分であり、文書化するのに十分な長さではありませんが、物事がプロセスに沿っている場所を把握し、私に影響を与える可能性のあるものについて私にヘッズアップを与えるのに最適です即時用語。

スタンドアップミーティングで特に注目に値する何かが浮かんだ場合は、それだけを文書化して個別にブロードキャストする必要がありますが、毎日すべてのミーティングを文書化する習慣にはなりません。

それに対する絶対的な答えはありません（ほとんどありえません）-それは非常に依存しています...

実用的には、あなたが「私がしたこと、私がやろうとしていること、ここに私の問題がある」をしている場合、それを記録することでいくつかの（概念的に担当する）メリットがあるかもしれませんそれは次の会議で（「作業中」も他の手段で明らかにする必要があります）-特にそれ以上ではありません。つまり、次の会議が終了すると価値がなくなるはずの情報です。

さらに、スタンドアップから生じる問題/会議がある場合、フォローアップが実際に行われたかどうかを追跡するためにそれらを記録することには潜在的に価値があります（ただし、これは主に他の手段で明らかになるはずだと言われますが）。

正式な議事録？物の精神に反するものだと思っていた。

私の現在の会社では、独立したスタンドアップを備えた2つのスクラムチームがあり、各スタンドアップの終わりに概要メールを送信して文書化します。それは非常にうまく機能し、重要な情報を他のチームのすべてのメンバーにすぐに知らせます。ただし、アーカイブの目的でメールの履歴は特に保持しません。

だから私のアドバイスは：

• 単一のチームにとって、スタンドアップを文書化することは時間を費やす価値がないかもしれません。スクラムマスターは、アラートまたは重要な情報を口頭で中継することができます。

• 仕事が密接に関連している複数のチームにとって、スタンドアップを記録することは、スクラムオブスクラムの発生を待たずに、会議の直後にゲームを変える可能性のある情報をブロードキャストする方法です。

そのような会議から行進し、行われた重要な決定またはアクションのリマインダー/クラリファイアとしてグループにメールを送信する問題はないと思います。結局のところ、議論したことの記憶を忘れたり、時間を忘れさせる危険を冒したくはありません。

しかし、会議を正式に文書化することに関しては、より伝統的な会議のためにあなたがするかもしれないように...まあ、それは直感に反するようです。このような会議は無駄がなく機敏であると想定されているため、「プロセス」が多すぎると会議が行き詰まってしまい、逆効果になります。

付加価値はありますか？人々は後で会議の文書を見ますか？そうでない場合は、時間の無駄です。そして、私は彼らがそうであることを真剣に疑います。誰も読まないドキュメントを書くのは時間の無駄です。

ある時点で、日常のスクラム、つまり、どのタスクに取り組んだか、ピアレビューを行ったかなど、ステータスの変更を実際に文書化およびアーカイブしました。これは、誰かが医療機器用のソフトウェアを開発していたため、システム要件からコードまでのトレーサビリティの要件。

後で、これは実際にはそうではないことを経営者に納得させることができました。そして、この文書を担当する人たちにとって、この慣行は大喜びで放棄されました。

はい。

（a）作業項目の責任者、および/または（b）他の項目と比較した作業項目の重要性について決定していますか？

もしそうなら、これらの決定を書き留めてください。さもなければ、あなたはそれらを再ハッシュします、そして、彼らのような決定は無限に。

そうでない場合は、会議を開催しないでください。