我与许多异地开发商和承包商合作。我要求他们每天给我发送他们当天工作的5分钟快速状态。为了向客户报告期末，我有时必须将个人的状态合并为团队，有时还要将一周的状态合并。

我想学习：

• 完成的项目以及在每个项目上花费了多少时间
• 遇到的问题以及在每个问题上花费了多少时间
• 接下来要处理的项目，它们的估计值(以工时为单位)和目标日期
• 他们对工作有疑问

我正在寻找一种可以在以下情况下提供此信息的格式：

• 快速地为开发人员完成(5至10分钟，无需过多考虑)
• 方便我快速阅读和浏览
• 对于每个开发人员都是统一的

你有什么建议？

解决方案

只需给他们提供一个模板，该模板以我们希望看到返回数据的格式布置。我们还可以考虑增加他们专门用于此目的的时间，如果我们需要估算以下内容，则可以删除"考虑不多"子句未来的工作。我不会相信有人在5分钟内提出的估计。想都没想。

如果我们当前正在使用任何项目管理软件，那么对于开发人员而言，记录并查看(甚至只是记住)他们为我们进行的编译工作应该是微不足道的。理想情况下，他们会整天记录问题或者疑问，而不是仅仅为了填写报告就提出问题。

似乎"我想学习"列表是从中生成模板的绝佳起点。只有我们会知道哪种格式适合我们。

使用Scrum。创建sprint积压，创建一个包含任务的电子表格和sprint每一天的一列。要求人们填写每天完成每个任务的时间。发送每日报告，从冲刺的燃尽图开始，然后为最后一个工作和下一个工作的每个成员短接两个一对衬板。每周发送报告，其中包括燃尽图，每个主要功能的红色/黄色/绿色状态(并阻止问题和注释(如果不是绿色的话)以及sprint待办事项中的其余项目)。

我没有链接到示例，但是这里有一些草稿：

10/02/2008 - Product A daily status

<Burndown chart>

Team member A
Last 24: feature A
Next 24: feature A unit tests

Team member B
Last 24: bug jail
Next 24: feature B

Team member C
Last 24: feature C
Next 24: feature C
Blocked on: Dependency D - still waiting on the redist from team D

10/02/2008 - Product A weekly status

<Burndown chart>

**Feature A** - Green
[note: red/yellow/green represents status; use background color as well for better visualisation]
On track

**Feature B** - Yellow
[note: red/yellow/green represents status; use background color as well for better visualisation]
Slipping a day due to bug jail
Mitigation: will load balance unit tests on team member A

**Feature C** - Red
[note: red/yellow/green represents status; use background color as well for better visualisation]
Feature is blocked on external dependency from team D. No ETA on unblock.
Mitigation: consider cutting the feature for this sprint

**Milestone schedule:**
Planning complete - 9/15 (two weeks of planning)
Code complete - 10/15 (four weeks of coding)
RC - 10/30 (two weeks stabilization and testing)

看起来我们想参加极限编程站会议。

http://www.extremeprogramming.org/rules/standupmeeting.html

我们可以使用带扩音器的电话或者某些VOIP与场外团队成员进行交谈。

通常，我只是依靠电子邮件来提供状态报告，它提供了完成的简单性和速度，但并没有实现任何形式的统一性。

有许多选项可以实现此目的，但是它们都有使过程更加复杂和耗时的风险。其中一些可能是：

一个在线表单，其中包含每个或者多个工作表电子表格的部分，其中每个工作表都是一个部分。

所有这些都需要我们自己付出一些努力来创建它们，我们是否出于某些目的需要统一性？例如自动执行摘要报告。

替代方法是使用一些项目管理工具，承包商在工作时填写此文件，我们可以随时进行报告。我会推荐Thoughtworks Studio Mingle，但它确实依赖于类似敏捷的过程。

我们可能不想听到此消息，但是无论如何这里都是-

我一直在办公桌两边处于这种情况，得出的结论是，这些汇总的状态报告对于我们和开发人员都是完全的时间浪费。原因如下：

• 开发人员应在指定的期限内从事功能/交付品的工作
• 开发人员应该在发生问题时提出问题
• 交流应根据需要双向流动

如果这些事情没有发生，那么无源的状态报告将无法解决不可避免地会出现的问题

在开发人员方面，"快速的五分钟状态" [我讨厌那个短语，五分钟不是很快！]中断了开发人员的流程，导致十五分钟(或者更多)的生产力损失(乔尔甚至在博客中谈到了这一点)我认为)。但是，即使实际上只有五分钟，如果我们有十几个开发人员，那么我们每周就要在管理上浪费五个工时(可能更像是20个工时)

在篱笆的经理一侧，将个人的状态报告按项目等汇总为团队，这是非生产性的工作，也浪费时间。可能甚至没有人看过报告。

但这是真正的问题：这种报告和汇总可能表示被动管理，而不是主动管理。换句话说，使用scrum，xp，敏捷，理性，瀑布式，自行开发的方法，或者如果计划和执行计划正确，那么我们就应该已经知道每个人在做什么，这无关紧要。提前计划。计划是在早上还是六个月前计划都没有关系。

暂时忽略客户需求，如果我们确实每天需要此信息来管理项目，那么项目可能会存在一些严重问题，询问开发人员每天他们下一步将要做什么以及需要多长时间？例如，暗示没有提前进行真正的计划...

对于客户的要求，如果他们绝对坚持这种细节[例如，我知道某些政府机构这样做]，那么最好的选择就是提供一个Web界面或者其他应用程序来自动执行烦琐的乏味操作。为我们汇总。我们仍然会浪费开发人员的时间，但至少不会浪费时间;-)

哦，从字面上回答问题：完善的状态报告说"在项目计划的目标上"，仅此而已；-)