如何向我的雇主（不是程序员）报告项目（敏捷）的进度？

我向雇主报告进度有问题。我是兼职程序员，为我学校的（非技术）部门处理一个软件项目。

联系人：
1.实际使用该软件并提出功能要求的员工；
2.我的老板（非程序员），她不是软件的用户。

该项目的性质：
它是一种现成的软件，已从第三方购买。我必须修改或添加此软件的功能才能满足部门的需求。这是整个学期需要使用的软件。并非一开始就需要使用所有功能。

因此，我们使用的是敏捷模型：当员工需要某个功能时，他们会提出一个请求，然后我进行更改。在本学期末，我认为所有必需的功能都将得到提高和实现。

问题：
每次老板问我进度如何时，我都无法回答，因为我不知道如何回答。我没有所有必需功能的完整列表。尽管我已经完成了上周提出的功能，但是我仍然不能告诉老板我已经“完成”了，因为新功能也即将推出，我也不知道要增加多少。我不能说“我们有多少完成率”，也不能说“我们要在xxx之前完成”。有时候，在3个请求中，我设法完成2个，我会告诉老板“我已经完成2个，但是其中一项功能尚未完成”。过了很长一段时间，我听起来像是“经过这么长时间，我总是有些事情没有完成”。

无法报告进度使我看起来非常糟糕。这不关我做了多少，而是关乎如何让人们知道。如果我是经理，而我的员工几个月都没有向我报告进度，那么我也会觉得这个人也无能为力。

你们有任何想法如何报告，或回答诸如“软件修改的状态/进度是什么”这样简单的问题吗？

更新 我的老板没有直接参与开发任务，因此她对我在做什么或程序如何工作一无所知。由于她很忙，我们不定期开会，我觉得这会浪费时间，因为她不是主要用户，她也不知道程序的细节。

我会定期与使用和了解该软件的人员会面。

我很难向老板解释进度。

当您是一个独立工作的程序员并且向非技术人员报告时，这是一个常见的问题。

像这样的老板大多希望能够找出一些事情：

• 用户有多高兴？
• 用户想要完成的事情吗？
• 您所做的事情值得您付出的钱吗？

如您所说，您的老板真的很忙，所以他们没有时间去学习它，反正对此也不感兴趣。

因此，如果我是您，我会每周通过电子邮件向他们发送一份报告，其中包含：

• 开始时有一个“执行摘要”：“本周完成了3个功能，并收到了2个新功能请求。本周初，有11个未完成的功能请求，最后有10个。”
• 功能状态列表，每组简短说明，分为三组：
  1. 您在一周内完成的功能
  2. 一周内收到的功能请求
  3. “积压”中的其他功能
• 简要讨论任何复杂或不寻常的事情，最好使用非技术性语言。

如果我是你的老板，而且还没有收到任何报告，那么我很高兴每周都能收到。如果我想要不同的东西，我会问你。

听起来您无法知道自己是否已经完成或完成需要走多远。好的，可以。

保留请求的功能列表，列出已完成，正在进行或未启动的功能。将它们作为每个类别中每周总计的图表进行跟踪。这将为您提供一组可以推断到结束日期的点。即（仅查看“完成的”功能计数）

• 第1-2周完成
• 第2-5周完成（第1周2个，第2周3个）
• 第3-8周
• 第4-12周

如果您有16周的时间，则可以完成48项功能（不必担心某些功能会比其他功能大/小，在4-5周后通常会得出平均值）。然后，您可以向所有人报告您只能处理X个功能。在项目结束时，绝对最重要的是，您已经交付了所需的功能，并且在最近两周内没有自杀。通过这种方式进行报告，您可以尽快提出关键要求。

您将要报告的另一件事是您有多少容量。“我只收到2个功能请求，但本来可以处理3个...您能要求工作人员早些时候提出更多功能吗？”

不确定我是否已完全回答您的问题，请随时提出后续问题...

三个字...烧毁图表。

您的雇主，无论他们是敏捷上瘾者，还是仅仅是负责开发人员的人，都将不胜枚举。

每个人都喜欢了解项目何时完成，并且利用昨天的天气将提供最准确，最现实的方式来预测项目的完成。

我假设您每周至少进行一次一对一的交流，并且可以在那时与您的经理讨论您的优先事项-从他/她的角度来看重要的是（某某人之前需要他的功能） -其他人等），并因此可以报告使您的经理看起来不错的工作量与总工作量的关系。

您的经理可能不会在寻找分钟的故障。他/她只是想看看工作是否已经完成，重要的事情是否正在得到更多的关注，并且您不会因为工作被阻而淹没在负载之下或闲置。

请注意，在一个真正的敏捷过程中，确实确实总是有很多东西进来，但是您和您的经理就最重要/最需要什么以及在当前工作期间能容纳多少东西达成了共识（无论是一周，两个星期，一个月...），如果需要，可以将工作分解成较小的部分，以使这些部分适合该时期。

可能需要花费几周的时间对大型数据库进行大修，例如：建立备份，验证备份是否良好，设计新的数据库布局，编写转换软件并进行测试，设置回滚和测试，尝试转换登台计算机，尝试在同一位置回滚，然后最终进行转换。其中的每一个都可以分解为1周（或更少）的块。如果某些步骤可能需要2到3周的时间，则可以报告下一次会议的进展情况（目标是2周50％，3周33％，等等）。

理想情况下，您将拥有一个图表，其中包含您需要做的事情与现在要做的事情，并且您会在进行过程中选中“立即做”项目。这样，您的经理就可以走过去，查看标记了多少东西以及清单上要做的事情。

每周一次（为示例起见，我假设您的敏捷过程中的迭代/冲刺时间为一周），请执行以下操作：

• 向员工演示新工作，以确保他们的要求已完成
• 向老板报告您在一周内完成的请求数量，并识别/描述这些请求。做一个简短的总结
• 向老板报告在一周中添加到您的积压/队列中的新请求数以及请求总数
• 告诉老板你打算在下周工作什么（要求什么）；换句话说，当前的优先事项。这是她确认或更改它们的机会，而您两个则很清楚
• 告诉老板那之后1-2周的计划是什么。

我感觉你的老板是不是技术不够照顾或理解敏捷的术语如速度，产品所有者或燃尽图。上面的模板避免了这样的行话，在常识上使用了诸如“积压”和“队列”之类的更简单的词，因此应该使与老板的沟通更加容易。

我将用自己的速度作为他/她的主要统计数据。这将显示我“同意”在一个特定星期（或其他时间段）进行交谈的任务/功能有多少，以及我完成了多少任务/功能。由此，我将提到一些更重要的功能实现，以及为什么它与过去的迭代有所不同。您还可以提及遇到和超越的任何障碍，以及这些障碍如何影响您的速度。

您的老板可能想知道的其他统计信息可能包括提出的新错误报告数量，已关闭的错误报告以及提交的新功能请求。您将不得不直接询问或使用最佳判断来确定哪些是最重要的。最后，我将概述进展情况，并询问他（她）是否还想知道其他事情。老板只想知道你正在进步，还有什么需要尽力而为。

建议您提交每周报告：列出所需的功能。记录更改的功能。报告您的工作。

我会尝试以经理们理解的方式来强调这一点。

Total Recieved Feature Requests:
Requests Completed:
Requests since last Update:
Estimated Time to required to complete remaining Requests:

仅仅因为您的经理不是程序员，就不要认为这意味着他们希望您知道确切的完成日期。显示您的号码。在经理看到收到的请求和完成的请求数量之后，经理看到进度。如果您的请求数量失控，经理可以在超载之前安排优先级并帮助您。而且，如果您没有工作要做，他们也许可以找到一些小的附带项目。毕竟，在似乎没有尽头的情况下在项目上稍作休息总是很高兴的，而且工作日变得越来越快，并且当您忙于工作时，会得到更多的回报。