至于客户要求，如果他们绝对坚持这种细节[并且我例如，知道某些政府机构会这样做]那么最好的选择是提供一个 Web 界面或其他应用程序来自动完成繁琐的工作，为您完成汇总。 您仍然会浪费开发人员的时间，但至少您不会浪费时间;-)
哦，从字面上回答您的问题：完美的状态报告说“符合项目计划的目标”，但什么也没有更多的 ;-）
you probably do not want to hear this, but here is it anyway -
i have been in this situation on both sides of the desk, and come to the conclusion that these kinds of rolled-up status reports are a complete waste of time for you and the developers. Here's why:
the developers should be working on features/deliverables with specified deadlines
the developers should be asking questions when they occur
communication should flow in both directions as needed
if these things are not happening, no amount of passive status reporting is going to fix the problems that will inevitably arise
on the developer side of the fence - a "quick five minute status" [i hate that phrase, five minutes is not quick!] interrupts the developer's flow, causing a loss of fifteen minutes (or more) of productivity (joel even blogged about this i think). But even if it really is only five minutes, if you have a dozen developers then you're wasting five man-hours per week on administrivia (and it's probably more like 20)
on the manager side of the fence - rolling up the status reports of individuals into teams by project etc. is non-productive busywork that wastes your time also. Chances are that no one even reads the reports.
but here's the real problem: this kind of reporting and roll-up may indicate reactive management instead of pro-active management. In other words, it doesn't matter what methodology is being used - scrum, xp, agile, rational, waterfall, home-grown, or whatever - if the project is properly planned and executed then you should already know what everyone is doing because it was planned in advance. And it doesn't matter if it was planned that morning or six months ago.
ignoring client requirements for a moment, if you really need this information on a daily basis to manage the projects then there are probably some serious problems with the projects - asking the developer every day what they're going to work on next and how long it will take, for example, hints that no real planning was done in advance...
as for the client requirements, if they absolutely insist on this kind of minutia [and i know that, for example, some government agencies do] then the best option is to provide a web interface or other application to automate the tedium that will do the roll-up for you. You'll still be wasting the developers' time, but at least you won't be wasting your time ;-)
oh, and to answer your question literally: the perfect status report says "on target with the project plan", and nothing more ;-)
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)
Use Scrum. Create the sprint backlog, have a spreadsheet with the tasks and a column for each day of the sprint. Ask people to fill out the hours worked on each task every day. Send daily report starting with the burndown chart for the sprint and then short two one liners for each member - last worked on and next working on. Send weekly report with the burndown chart, red/yellow/green status for each major feature (and blocking issues and notes if it's not green) and the remaining items on the sprint backlog.
I don't have a link to samples, but here are some drafts:
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)
Just give them a template laid out in a format that you expect to see the data returned in. You may also consider increasing the time they are going to devote to this and removing the "not thinking too much" clause if you are requiring estimates for future work. I wouldn't trust an estimate that someone came up with in 5 mins. without thinking.
If you are currently using any project management software, it should be trivial for the developers to record and review (or even just remember) what they have done compile it for you. Ideally they would be recording issues or questions throughout the day and not trying to come up with them just to fill in the report.
It seems like your "I want to learn" list is an excellent starting point to generate a template from. Only you will know what the perfect format for you is.
另一种选择是使用承包商在工作时填写的一些项目管理工具，您可以随时报告。 我会推荐 Thoughtworks Studio Mingle，但它确实依赖于类似敏捷的流程。
Generally I have just relied on e-mail as a means of providing status reports, it provides the simplicity and speed of completion but does not enforce any sort of uniformity.
There are a number of options to achieve this but they all risk making the process more complex and time consuming. Some of these could be:
An online form with sections for each or a multi sheet spreadsheet, with each sheet being a section.
All of these require some effort by yourself to create them, do you need the uniformity for some purpose? e.g. to automate the summary reports.
An alternative to this would be to use some project management tool which the contractors filled in whilst they were working and that you could report on at any time. I would recommend Thoughtworks Studio Mingle, but it does rely on an agile-like process.
发布评论
评论（5）
你可能不想听这个，但无论如何 -
我在桌子两边都经历过这种情况，并得出结论，这些卷起的状态报告对你来说完全是浪费时间和开发商。 原因如下：
，再多的被动状态报告也无法解决问题 不可避免地会出现问题
开发人员方面 - “快速五分钟状态”[我讨厌这句话，五分钟并不快！] 打断开发人员的流程，导致十五分钟（或更长时间）的生产力损失（我认为乔尔甚至在博客中提到过这一点）。 浪费 5 个工时（而且可能更像是 20 个工时）。
但即使真的只有五分钟，如果您有十几个开发人员，那么您每周都会在管理方面 栅栏 - 按项目等将个人的状态报告汇总到团队中是非生产性的忙碌工作，也会浪费您的时间。 很可能根本没有人阅读这些报告。
但这是真正的问题：这种报告和汇总可能表明被动管理而不是主动管理。 换句话说，无论使用什么方法 - scrum、xp、敏捷、理性、瀑布、本土开发或其他任何方法 - 如果项目得到正确的规划和执行，那么你应该已经知道每个人都在做什么正在做因为它是提前计划好的。 不管是那天早上还是六个月前就计划好了。
暂时忽略客户的要求，如果您确实每天都需要这些信息来管理项目，那么项目可能存在一些严重的问题 - 每天询问开发人员> 例如，他们接下来要做什么以及需要多长时间，暗示没有提前进行真正的计划......
至于客户要求，如果他们绝对坚持这种细节[并且我例如，知道某些政府机构会这样做]那么最好的选择是提供一个 Web 界面或其他应用程序来自动完成繁琐的工作，为您完成汇总。 您仍然会浪费开发人员的时间，但至少您不会浪费时间;-)
哦，从字面上回答您的问题：完美的状态报告说“符合项目计划的目标”，但什么也没有更多的 ;-）
you probably do not want to hear this, but here is it anyway -
i have been in this situation on both sides of the desk, and come to the conclusion that these kinds of rolled-up status reports are a complete waste of time for you and the developers. Here's why:
if these things are not happening, no amount of passive status reporting is going to fix the problems that will inevitably arise
on the developer side of the fence - a "quick five minute status" [i hate that phrase, five minutes is not quick!] interrupts the developer's flow, causing a loss of fifteen minutes (or more) of productivity (joel even blogged about this i think). But even if it really is only five minutes, if you have a dozen developers then you're wasting five man-hours per week on administrivia (and it's probably more like 20)
on the manager side of the fence - rolling up the status reports of individuals into teams by project etc. is non-productive busywork that wastes your time also. Chances are that no one even reads the reports.
but here's the real problem: this kind of reporting and roll-up may indicate reactive management instead of pro-active management. In other words, it doesn't matter what methodology is being used - scrum, xp, agile, rational, waterfall, home-grown, or whatever - if the project is properly planned and executed then you should already know what everyone is doing because it was planned in advance. And it doesn't matter if it was planned that morning or six months ago.
ignoring client requirements for a moment, if you really need this information on a daily basis to manage the projects then there are probably some serious problems with the projects - asking the developer every day what they're going to work on next and how long it will take, for example, hints that no real planning was done in advance...
as for the client requirements, if they absolutely insist on this kind of minutia [and i know that, for example, some government agencies do] then the best option is to provide a web interface or other application to automate the tedium that will do the roll-up for you. You'll still be wasting the developers' time, but at least you won't be wasting your time ;-)
oh, and to answer your question literally: the perfect status report says "on target with the project plan", and nothing more ;-)
使用Scrum。 创建冲刺待办事项列表，制作一个包含任务的电子表格以及冲刺每一天的一列。 要求人们填写每天每项任务的工作时间。 发送每日报告，从冲刺的燃尽图开始，然后为每个成员短写两个单行代码 - 上一个工作和下一个工作。 发送每周报告，其中包含燃尽图、每个主要功能的红色/黄色/绿色状态（以及阻止问题和注释，如果它不是绿色的）以及冲刺待办事项中的剩余项目。
我没有示例链接，但这里有一些草稿：
Use Scrum. Create the sprint backlog, have a spreadsheet with the tasks and a column for each day of the sprint. Ask people to fill out the hours worked on each task every day. Send daily report starting with the burndown chart for the sprint and then short two one liners for each member - last worked on and next working on. Send weekly report with the burndown chart, red/yellow/green status for each major feature (and blocking issues and notes if it's not green) and the remaining items on the sprint backlog.
I don't have a link to samples, but here are some drafts:
只需给他们一个以您希望看到返回的数据的格式列出的模板即可。您还可以考虑增加他们为此投入的时间，并删除“不要考虑太多”条款（如果您需要估计）未来的工作。 我不会相信有人在 5 分钟内得出的估计。 想都没想。
如果您当前正在使用任何项目管理软件，那么开发人员记录和审查（甚至只是记住）他们为您所做的编译工作应该是微不足道的。 理想情况下，他们会全天记录问题或问题，而不是仅仅为了填写报告而试图提出它们。
看来您的“我想学习”列表是生成模板的绝佳起点。 只有您自己知道最适合您的格式是什么。
Just give them a template laid out in a format that you expect to see the data returned in. You may also consider increasing the time they are going to devote to this and removing the "not thinking too much" clause if you are requiring estimates for future work. I wouldn't trust an estimate that someone came up with in 5 mins. without thinking.
If you are currently using any project management software, it should be trivial for the developers to record and review (or even just remember) what they have done compile it for you. Ideally they would be recording issues or questions throughout the day and not trying to come up with them just to fill in the report.
It seems like your "I want to learn" list is an excellent starting point to generate a template from. Only you will know what the perfect format for you is.
一般来说，我只是依靠电子邮件作为提供状态报告的一种方式，它提供了简单性和完成速度，但不强制执行任何形式的统一性。
有多种选择可以实现这一目标，但它们都有使过程变得更加复杂和耗时的风险。 其中一些可能是：
一个在线表单，其中每个或多个工作表电子表格都有多个部分，每个工作表都是一个部分。
所有这些都需要你自己付出一些努力来创造它们，你是否需要为了某种目的而统一？ 例如，自动生成摘要报告。
另一种选择是使用承包商在工作时填写的一些项目管理工具，您可以随时报告。 我会推荐 Thoughtworks Studio Mingle，但它确实依赖于类似敏捷的流程。
Generally I have just relied on e-mail as a means of providing status reports, it provides the simplicity and speed of completion but does not enforce any sort of uniformity.
There are a number of options to achieve this but they all risk making the process more complex and time consuming. Some of these could be:
An online form with sections for each or a multi sheet spreadsheet, with each sheet being a section.
All of these require some effort by yourself to create them, do you need the uniformity for some purpose? e.g. to automate the summary reports.
An alternative to this would be to use some project management tool which the contractors filled in whilst they were working and that you could report on at any time. I would recommend Thoughtworks Studio Mingle, but it does rely on an agile-like process.
看起来您想要召开极限编程站立会议。
http://www.extremeprogramming.org/rules/standupmeeting.html
你可以谈谈使用带扩音器或某些 VOIP 的电话向异地团队成员发送。
Looks like you want to do Extreme Programming stand up meetings.
http://www.extremeprogramming.org/rules/standupmeeting.html
You can talk to off site team members using the phone with laudspeaker, or some VOIP.