毎日のレポートは開発者の生産性を低下させることができますか？[閉まっている]

で別の質問、私は、開発者が好きではないかもしれない理由について尋ねた毎日スクラム。開発者と話をして、しばらくの間毎日のスクラムを開催しないことにしました（最初の試みで試してカスタマイズしたスクラムを提供するため）。これは、開発者と直接相談した結果です。

一方、開発者を毎日調整する機会を得たり、主要業績評価指標のように作業の進捗を監視したりして、早期にアクションを起こすなど、毎日のスクラムの良い部分を失いたくありません。

毎日のスクラムに代わるものとして、開発者に次の条件で毎日のレポートを提供するよう依頼することを考えています。

1. 特定の形式に従う必要はありません。すべての形式が受け入れられます。
2. 作業が完了していなくても、進捗状況を聞きたいと思っています。
3. 各タスクに費やされた時間を言及する必要はありません。
4. 開発の障害と調整の要件に言及する必要があります。
5. 毎日のレポートに取りつかれている必要はありません。そんなに厳しくはありません。

これにより生産性が低下すると思いますか？日報の経験はありますか？マイクロ管理を行っていないことを確認できるように、何か提案がありますか？

毎日のスクラムに代わるものとして、開発者に次の条件で毎日のレポートを提供するよう依頼することを考えています。

なんてひどい考えだ。

これにより生産性が低下すると思いますか？

はい。

どうして？ミーティングでの口頭によるプレゼンテーションでは、レポートを書くこととn人がレポートを「読む」ことを組み合わせて、1つの同時アクティビティにします。トーキングとリスニング。以上で終わりました。すぐに質問に答えました。

質問があるので、レポートを書くのは時間の無駄です。そして、（a）質問を持ち、（b）本当に読んでいない人々とレポートをレビューしなければなりません。

日報は読まれません。それらはすぐにボックス内ノイズに移ります。

「日報に取りつかれている必要はありません」。その場合、なぜそうするのですか？

私たちがマイクロ管理していないことを確認できるように、何か提案がありますか？

はい。毎日立ち上がってください。数分で完了です。

毎日の立ち上げに数分（15？）分以上かかる場合、あまりにも多くの詳細を共有しているため、それらの詳細について個別の会議をスケジュールする必要があります。毎日のスタンドアップは簡単です。2分間の要約の後、他のすべてはおそらくチーム全体ではなく詳細であり、フォローアップ会議にプッシュする必要があります。会議はその日の次の人の焦点に移ります。

私はこれらを過去に行いましたが、一日の終わりとは対照的に朝に。記入に通常5分もかからなかったので、いや、開発者の生産性がどのように低下​​するかわかりません。朝にそれをすることの良いところは、それがあなたがその日の残りのために何をしようとしているのかを考えさせたということでした。

それを言って ...

それは何度もあり、前日にやったこととその日に何をしようとしていたかを伝えるのに最も効果的な方法ではないことがわかりました。どうして？人々は一般的にそれらを読みませんでした。これはスケジュールされたOutlookのタスクであったため、全員が毎日送信しましたが、光沢があったか、まったく見逃されていました（リードまたは管理者以外）。

私たちは、人々がお互いに耳を傾ける傾向があるため、毎日のスタンドアップを持つことの方がはるかに価値があることを発見しました。また、誤解があった場合、それはあちこちに流されます。これは、誰かが毎日のステータス電子メールに返信してさらに質問をするよりも起こりやすいです。

正直に言って、誰もが制約なしに報告できるようにすることは、方程式のリベラルな側面からは遠すぎるように思えます。私が働いている場所では、私たちは円を描き、各開発者は以下を提供します：

1. 前日にやったこと。すべての小さな詳細ではなく、全体。
   • 上記が完了していない場合、完了していない場合、完了に必要なものとその所要時間。
   • 上記が完了した場合、次のタスクは何か、必要なものは何か、それにかかる時間。
2. ブロッカー。Barに依存するFooで作業していて、Barが完成していない場合、これを明確にする必要があります。

全員が従う一般的なスキーマを設定すると、特定のレポートを簡単に確認できます。誰もが毎日のレポートで電子メールを受信するための方法を簡単に設定できるため、誰でも何が起こっているのかを知ることができます。

IMOのあらゆる種類の毎日の会議/レポートは、率直に言って、マイクロ管理の悪臭を放つため、生産性を低下させます。はい、私はスクラムを意識してのようだと、それらはあまりにも悪い、彼らがしている短いステータスの更新に提供されていない（「ちょっとどのようにプロジェクトXが来ているの？」）が、私はしっかりとだと信じて侮辱上のタブを保つためにプロの開発者にその低いレベルで私たち。タイムカードを使用して1日8時間オフィスにいることを確認したり、壁がないことを確認したりして、特定の時間に開いているウィンドウを確認するためにユーザーのコンピューターをスパイできます。

すべての人が動作していることを確認するためにすべてを監視する必要がある場合は、それらを信頼しないことを意味します。あなたがそれらを信用しないなら、あなたが心配している問題よりも大きな問題が職場であります。

私のチームは約1年間スクラムを行っています。その前に、週に2回会議を開催しました。その間に、各チームメンバーは、過去2、3日間の活動について報告しました。各会議は30分から1時間続きました。情報を交換し、作業を調整する必要がある場合は、同僚に話をして、彼らに話しかけるだけでした（もちろん、それは今でも行っています）。

現在、スクラムを行っているので、1日1回の会議（15分しか続かない場合でも）が多すぎるという印象を受けます。多くの場合、一部のメンバーのレポートは次のように要約されます。「昨日から新しいものはありません」。1週間に2回の会議がより効果的であるという印象をしばしば受けました。

もう1つの欠点は、毎日の会議が計画的な中断であるということです （たとえば、Paul Grahamの記事、ポイント1を参照してください）。仕事を始めてから1時間半後に実施します）。

最後に大事なことを言い忘れましたが、早期のフィードバックには利点があります（「ああ、その問題に取り組んでいるので、議論する必要があります！」）。 、具体的な質問があり、議論の準備ができていると感じます。代わりに、毎日のレポートは、多くの不要で構造化されていないブレインストーミングをすぐに引き起こす可能性があります。したがって、早すぎるフィードバックに注意してください。混乱を招き、速度が低下する可能性があります。

そのため、場合によっては、毎日のレポートで生産性が低下しました。平均して、彼らが私たちの仕事をより効果的にしたと感じることはありません。

更新

数年前に元の回答を書きましたが、その間にチームを切り替えました。現在のチームでは、オンデマンドで毎日の会議を行っています。つまり、短いステータスの更新が必要だと感じたときです。そのため、毎日そのような会議を開催する可能性がありますが、誰もそれを要求しない場合、私たちはそれをしません。毎週の回顧会議があります。これは、以前の非アジャイルチームで最初に使用していたアプローチと基本的に非常に似ています。週1回のミーティングに加えて、週の残りの時間に追加のオンデマンドミーティングを行います。

あなたが本当に欲しいのが大まかなステータスであり、障害を書き留める最善の方法は、彼らに短い「毎日のステータスメール」を求めることです。それを強調しすぎる場合、または含めるべき/含まないもののリストを作成する場合、少なくとも一部の開発者は要件を満たすために作成に余分な時間を費やします。その代わりに、単純なメールをお願いします。一日中物事が起こるとき、「ああ、一日の終わりのメールにそれを入れて」のようなことを言い、あなたが本当に長い一日の終わりの電子メールを受け取ったら、さりげなく「あなたはその詳細を毎日述べる必要はない」と言ってください。

会議や報告書の目的、特に毎日誰もが行うことについて明確にすることは非常に役立ちます。その理由は次のとおりです。

開発者を毎日調整する機会を得るなど、毎日のスクラムの良い部分を失いたくありません。

コーディネート開発者とはどういう意味ですか？どのような作業に調整が必要であり、開発者とそのマネージャーが必要に応じてアドホックに調整されていないのですか？調整が必要なタスクを特定し、そのような場合にのみ通信できる方法はおそらくありますか？

または、主要業績評価指標のような作業の進捗状況を監視して、早期にアクションを実行します。

多くの優れたKPI（サイトの応答時間や重大なバグの数など）は機械的に測定可能になるため、開発者がそれを行うためにコストをかける必要はありません。

職場では、いくつかの異なる形式で毎日レポートを作成する必要がありました。一般的に、日報は開発者自身ではなく、マネージャーのみに価値をもたらす傾向があると思います。マネージャーは、各プロジェクトの全体的なステータスと各従業員のタスク負荷を短時間で伝えることができるため、毎日のレポートから利益を得ますが、私の経験では、ほとんどの開発者はお互いのステータスレポートを読みません。

ただし、毎日のレポートの形式を強制しないことで、マネージャーと仲間の開発者の両方にとってレポートの読み取りと処理が難しくなり、開発者の時間の問題が悪化しているようです。

開発者向けに日次レポートを進めることにした場合、メールレポートの代わりに内部wikiを使用することをお勧めしますか？そうすれば、すべての人の毎日のステータスの履歴を維持しながら、人々の受信トレイにスパムを送信することはありません。

アジャイルメソッドをカスタマイズして自分に合うようにするのは素晴らしいアイデアです。

ですから、代わりに日報は、これは日次の会議よりもはるかに優れていると思います。それは同じ「あなたがしていることを教えてください」アプローチであり、あなたは誰もがそれを話すのではなく書き留めているだけです。

代替アプローチを次に示します。各開発者にステータスを尋ねるこれらの「ポーリング」手法を使用する代わりに、「プッシュ」手法を使用します。開発者が報告するものがあまりない場合、開発者にはありません。ただし、発生したすべての問題と進行状況を報告するべきです。したがって、モジュールを完了すると、完成したチーム、SCMにあるドキュメント、ドキュメントが見つかる場所、およびモジュールの概要、機能、使用方法についての簡単な要約をメールで送信する必要があります。それ。問題がある場合は、チームに電子メールを送信して、アドバイス、ヘルプ、またはヒントを求めてください。（ええ、今日苦しんでいるマイクロマネジメントなしでチームがうまく通信した昔のように）

これははるかに生産的で建設的であることがわかります。彼らのために無意味なレポートを受け取ることはありませんし、誰もが自分の仕事を同僚に知らせることを好むので、より意欲的なチームを得ることができます。

また、毎日のスタンドアップをレポートに置き換えるのは悪い考えであることに同意します。毎日の立ち上がりは、アイデアや問題を発言するのに最適な場所です。これが、古き良きホワイトボード（Jira + Greenhopperと一緒に使用する）が好きな理由の1つです。ホワイトボードは、グループが「密談」して情報を共有する場所であり、すべてがそこにあり、すべてが見えるようになっています。

他のツールからこの情報を抽出することはできませんか？

• 現在何に取り組んでいますか？私が割り当てたチケット。
• あなたの進歩は？私が1日より長いチケットについては、チケットのコメントを参照するか、ブランチのメッセージをコミットしてください。私が持っているチケット：明日行われる可能性が高い
• 一般的な進捗はどうですか？オープン/クローズドチケット比率を参照
• 何を整理する必要がありますか？チケットは、あなたがステータスで、バック割り当てられます必要なフィードバック、そしてすべてが何であれ、あなたのチームのIRC、キャンプファイヤールームで議論しました。

より具体的な質問に答える場合、特定のレポートが必要になると思いますが、それなしではレポートはそれ自体で終わりのように見えます。