日次レポートは開発者の生産性を低下させる可能性がありますか？
別の質問 で、なぜ開発者がdaily scrumを好まないのかについて尋ねました。私たちは開発者と話をし、毎日スクラムをしばらく保持しないことを決めました（最初の試みで試してカスタマイズしたスクラムを与えるため）。これは、開発者に直接相談した結果です。
一方で、開発者を毎日調整する機会を得たり、主要業績評価指標のように作業の進捗状況を監視して早期に行動を起こしたりするなど、毎日のスクラムのかなりの部分を失いたくありません。
毎日のスクラムの代わりに、次の条件で毎日のレポートを提供するよう開発者に依頼することを考えています：
- 特定の形式に従う必要はありません。すべての形式が受け入れられます。
- 仕事が終わっていなくても、進捗状況を聞きたい。
- 各タスクに費やされた時間について言及する必要はありません。
- 開発の障害と調整要件に言及する必要があります。
- 日報にこだわる必要はありません。それほど厳格ではありません。
これにより生産性が低下する可能性があると思いますか？日報の経験はありますか？ micromanaging でないことを確認できるように、何か提案はありますか？
毎日のスクラムの代わりに、次の条件で毎日のレポートを提供するよう開発者に依頼することを考えています：
なんてひどい考えだ。
これにより生産性が低下する可能性があると思いますか？
はい。
どうして？会議での口頭発表では、書き込みとn人がレポートを "読んで"同時に1つのアクティビティに結合します。トーキングとリスニング。以上で完了です。質問はすぐに答えました。
質問があり、（a）質問があり、（b）本当に読んでいない人々と一緒にレポートをレビューする必要があるため、レポートの作成は時間の無駄です。
日報は読まない。それらは急速にインボックスノイズに発展します。
「日報にこだわる必要はない」。その場合、なぜそれらを行うのですか？
マイクロマネージメントではないことを確認できるように、何か提案はありますか？
はい。毎日立ち上がる。数分で完了です。
毎日のスタンドアップに数分（15？）分以上かかる場合、あまりにも多くの詳細を共有しているため、それらの詳細について個別の会議をスケジュールする必要があります。毎日のスタンドアップは簡単です。 2分の要約の後、他のすべてはおそらくチーム全体ではなく詳細であり、フォローアップ会議にプッシュする必要があります。会議はその日の次の人の焦点に移ります。
私は過去にこれらをやったことがありますが、一日の終わりとは対照的に朝に。通常、記入にかかる時間は5分未満なので、いいえ、開発者の生産性がどのように低下するかはわかりません。午前中にそれを行うことの良い点は、それがあなたがその日の残りのために何をしようとしているのかを考えるようにさせられたことでした。
言ったことがある ...
それは何回もあることがわかりました、それは私たちが前日に行ったことと私たちがその日に作業するつもりであったことを伝える最も効果的な方法ではありませんでした。どうして？人々は一般的にそれらを読みませんでした。これはOutlookの予定されたタスクだったため、全員が毎日それらを送信しましたが、見落とされたか、完全に見落とされました（リードや管理者以外による）。
人々がお互いに耳を傾ける傾向があったので、毎日のスタンドアップを持つことははるかに価値があることがわかりました。また、誤解があった場合はその場でフラッシュされ、日常のステータスメールに返信してさらに質問するよりも起こりやすくなります。
正直なところ、誰もが制約なしにレポートできるようにすることは、方程式のリベラルな側面には少し遠すぎるようです。私が働いている場所では、私たちは輪になっており、各開発者は以下を提供します：
- 前日に行われたこと。細かい詳細のすべてではなく、全体的なものです。
- 上記が終了していない場合、終了していない場合は、何を完了する必要があり、どのくらい時間がかかります。
- 上記が終了したら、次のタスクは何か、何が必要か、そしてそれにかかる時間。
- ブロッカー。 Barに依存するFooで作業していて、Barが終了していない場合は、これを明確にする必要があります。
誰でもフォローできるように一般的なスキーマを設定すると、特定のレポートを簡単に処理できます。誰もが毎日のレポートをメールで受け取る方法を簡単に設定できるため、誰もが何が起こっているのかを知ることができます。
IMOあらゆるタイプの毎日の会議/レポートは、率直に言って、マイクロマネージメントの悪臭であるため、生産性を低下させます。はい、私はスクラムなどを認識していますが、それらは短いステータス更新（「プロジェクトXはどうですか？」）であれば、それほど悪くはありませんが、それは侮辱プロの開発者が私たちをその低いレベルに保つために。タイムカードを使用して1日8時間オフィスにいることを確認したり、壁がないことを確認したりして、人々のコンピューターを監視して、特定の時間に開いているウィンドウを確認するのと同じです。
全員が機能していることを確認するためにすべての人を監視する必要がある場合、それは彼らを信頼していないことを意味します。それらを信頼しない場合、あなたが心配しているものよりも大きな問題が職場で発生しています。
私のチームは約1年間スクラムをやっています。その前に、私たちは週に2回の会議を行っていました。その間、各チームメンバーは過去2、3日間の自分の活動について報告しました。各会議は30分から1時間の間続きました。情報を交換して仕事を調整する必要がある場合に備えて、同僚のところまで行って話をしていました（もちろん、私たちはまだそうしています）。
私たちはスクラムをやっているので、1日1回の会議（15分しかかからないのに）が多すぎるという印象をよく持っています。多くの場合、一部のメンバーのレポートは次のように要約されます。「昨日から何も新しいことはない」。週に2回の会議のスキーマの方が効果的だという印象をよく受けました。
別の欠点は、毎日の会議が計画的な中断であるということです（例 Paul Grahamの記事 を参照してください、ポイント1）。中断が来ることがわかっているので、会議の前に困難なことを開始することはありません（毎日の会議は、仕事が始まってから1〜1時間半かかることがあります）。
最後に重要なことですが、初期のフィードバックには利点がありますが（「ああ、あなたはその問題に取り組んでいるので、それについて話し合う必要があります！」）、すでにアイデアを頭に入れて整理している場合にのみ、話し合いを開始する方が効果的な場合があります。 、具体的な質問があり、話し合う準備ができていると感じています。代わりに、毎日のレポートは、多くの不要で構造化されていないブレーンストーミングをすぐに引き起こす可能性があります。したがって、早すぎるフィードバックに注意してください。混乱を招き、遅くなる可能性があります。
したがって、場合によっては、毎日のレポートで生産性が低下することがあります。平均して、私は彼らが私たちの仕事をより効果的にしたと感じています。
[〜＃〜]更新[〜＃〜]
私は数年前に元の回答を書きましたが、その間にチームを切り替えました。私の現在のチームでは、オンデマンドで、つまり、短いステータスの更新が必要だと感じたときに、毎日会議を行っています。ですから、毎日そういうミーティングをする可能性はありますが、だれかからの要請がない限り、そういうことはしません。私たちは毎週回顧会議を持っています。これは基本的に、以前のアジャイルでないチームで最初に使用していたアプローチと非常によく似ています。毎週の固定会議と、その週の残りの期間中の追加のオンデマンド会議。
また、毎日のスタンドアップをレポートに置き換えることは悪い考えであることにも同意します。毎日のスタンドアップは、アイデアや問題を発声するのに最適な場所です。これが私が古き良きホワイトボード（Jira + Greenhopperと一緒に使用する）が好きな理由の1つです。ホワイトボードは、グループが「ハドル」して情報を共有する場所です。すべてがそこにあり、すべてが表示され、誰もが自分の作業した付箋を動かして変更します。これもまたとても楽しいです。
あなたが本当に欲しいのは大まかなステータスであり、障害があればそれを書き留めるのが最善の方法は、短い「毎日のステータスメール」を彼らに尋ねることです。強調しすぎたり、含まれるべき/含めるべきでないもののリストを作成したりすると、少なくとも一部の開発者は、要件を満たすためにそれを作成するために余分な時間を費やします。代わりに、単純なメールをお願いします。一日の終わりに「ああ、それを一日の終わりのメールに入れて」のようなことを言い、本当に長い一日の終わりのメールを受け取った場合は、「毎日、そのように詳細にする必要はない」と気軽に言ってください。
会議やレポート、特に毎日全員が行う会議の目的を明確にすることは非常に役立ちます。その理由は次のとおりです。
開発者を毎日調整する機会を得るなど、毎日のスクラムの良い部分を失いたくない
コーディネート開発者とはどういう意味ですか？どのような種類の作業が調整を必要とし、必要に応じて開発者とそのマネージャーによってその場で調整されていませんか？おそらく、調整が必要なタスクを特定し、それらの場合にのみ通信できる方法はありますか？
または、主要業績評価指標のように作業の進捗状況を監視して、早期に行動を起こす。
多くの優れたKPI（サイトの応答時間や重大なバグの数など）は機械的に測定可能であり、開発者がそれを行うためにコストをかける必要はありません。
私は職場でいくつかの異なる形式で日報を作成しなければなりませんでした。一般的に言って、日報は開発者自身ではなく、マネージャにのみ付加価値をもたらす傾向があると思います。マネージャーは、各プロジェクトの全体的なステータスと各従業員のタスクロードを短時間で伝えることができるため、日次レポートからメリットを得られますが、私の経験では、ほとんどの開発者はお互いのステータスレポートを読む必要がありません。
ただし、日次レポートの形式を強制しないと、マネージャーと他の開発者の両方にとってレポートの読み取りと処理が困難になり、開発者の時間の損失の問題が悪化します。
開発者向けに日次レポートを進めることにした場合、電子メールレポートの代わりに内部Wikiを使用することをお勧めしますか？そうすることで、みんなの毎日のステータスの履歴を維持しながら、人々の受信トレイにスパムを送信することはありません。
アジャイルメソッドをカスタマイズして自分に合うようにするのは素晴らしいアイデアです。
ですから、代わりに毎日のレポートは、これは毎日の会議よりもはるかに優れているとは言えません。それでも、「何をしているのかを教えてください」というアプローチは同じです。話しかけるのではなく、全員に書き留めるだけです。
ここに別のアプローチがあります。各開発者にステータスを尋ねるこれらの「ポーリング」手法を使用する代わりに、代わりに「プッシュ」手法を使用します。開発者が報告すべきことが何もない場合、彼らはそうではありませんが、発生したすべての問題と進行状況を報告する必要があります。そのため、モジュールが完成したら、すべてのチーム、SCM内、ドキュメントのある場所、およびそれが何であるか、どのように機能するか、および/または使用方法についての簡単な概要をメールで送信する必要があります。それ。問題がある場合は、チームにメールを送って、アドバイス、ヘルプ、またはヒントを求めます。 （ええ、チームが今日苦しんでいるマイクロマネージメントなしでチームがうまくコミュニケーションしていた昔のように）
これははるかに生産的で建設的であることがわかります。あなたは彼らのために意味のないレポートを取得することはなく、誰もが同僚に彼らの仕事を知らせるのが好きなので、よりやる気のあるチームを得るでしょう。
他のツールからこの情報を抽出できますか？
- 現在何に取り組んでいますか？私が割り当てたチケット。
- あなたの進歩は何ですか？チケットが1日より長い場合は、チケットのコメントまたはブランチのコミットメッセージを参照してください。短いチケット：明日行われる（5日以上の大きなチケットは作成しない、そうですか？）
- 一般的な進捗状況を教えてください。 open/closed-tickets-ratioを参照してください
- 何を整理する必要がありますか？チケットあなたに割り当てられ、ステータスフィードバックが必要です、およびチームのIRC、キャンプファイヤールームなどで話し合ったすべてのこと。
より具体的な質問があると、具体的なレポートが必要になると思いますが、それがないと、レポート自体が目的のように見えます。