请保持专业态度，不要再说“我快完成了！”

上午 10:00 团队站立会议时间到。
每个人都会讲述昨天关闭的工单，并解释今天要做什么。

当轮到你时，敏捷教练/项目经理提到你正在处理的工单，你会说：

我快完成了，只需要做一些最后的润色，但它应该简单而快速

快进几天甚至更长时间，你会发现自己一遍又一遍地重复着这件事。

是的，我很确定我今天会完成，昨天遇到了几个阻碍，但现在我真的快完成了！

说实话，你遇到过多少次这种情况（或者你看到你的团队遇到过这种情况）？你明明说快
完 ​​成了的任务，怎么最后却要多花一两天（甚至一周）的时间？

我无意刻薄或专横。我遇到过很多次这种情况。问题是

为什么我们要对别人和自己说这个几乎要结束的谎言？

害怕评判

我们是否害怕在同事和上级面前承认我们的进度比预想的要慢？

避免冲突

我们是否试图通融并避免说我们都知道不可能按时交付并且估计（管理层强加给团队的）是错误的？

冒名顶替综合症

这与对评判的恐惧有关，但更多的是与内心对无法完全完成任务的恐惧有关，如果我们说我们陷入困境或正在挣扎，其他人可能会认为我们不是我们所假装的专家。

帕累托原则

我们是否意识到，我们远远落后于计划，是因为最难的部分/或者说，耗时最长的部分还没有到来？

帕累托原则，也称为80/20 规则，告诉我们，80% 的功能只需 20% 的时间就能实现，而剩下的 20% 则需要 80% 的时间。细节决定成败：我们可能已经快速构建了表单或 RestAPI，但我们仍然需要所有验证、适当的错误处理或 CSS，而这些都需要花费大量时间！

邓宁·克鲁格效应

我们是否充分了解自己的所有技能，是否清楚要完成的任务、可能隐藏的未知数、可能的阻碍因素、完成任务所需的技术知识，我们是否真的高估了自己的能力？

完美主义的陷阱

也许我们太追求完美了？

我们本来快要完成了（几乎完成了_），但后来我们决定用某种设计模式重构那段丑陋的代码，或者抽象掉所有重复的代码，结果现在重构才进行到一半，所有东西都停止工作了，（当然，我们不想/也不能把所有漂亮的修改都藏起来，然后交付旧版本）

或者也许我们只是真的不知道“完成”是什么意思。

DONE 的定义

“完成”对你、对你的团队、对你的老板、对你的客户意味着什么？
当你正式完成工单上列出的事项，终于可以把工单从“进行中”栏移出来，然后去抽根烟或者踢踢球的时候，是不是就意味着完成了？

什么时候可以认为任务完成了？

50 种完成度

熟度有不同的等级吗？

• 做得很马虎
• 做得足够好
• 完成完成
• 哇！完成了！

你和团队成员以及敏捷教练讨论过这个问题吗？
完成这个任务需要哪些步骤？

• 实现该功能
• 编写单元测试
• 进行一些手动测试来发现使用中的错误
• 为不同的环境做好准备
• 集成测试
• 部署

也许你的团队把这些任务分成了不同的任务，或者交给了不同资历的开发人员？
也许你来自一个团队或公司，那里从来没有人关心单元测试，现在你很难把单元测试视为你的任务的一部分，而实际上，在功能交付过程中，单元测试是理所当然的。

做正确的事

还可能发生这样的情况：你已经完成了，但是你做错了，因为你害怕提问或者你基于错误的假设进行操作。

也许你被要求做的只是一个简单的原型，用来测试一个想法，一个未来的项目。或者是一个MVP（最小可行产品） ——一个经过打磨、可运行、生产就绪、测试过的产品版本，但功能非常基础。
但你仍然需要为所有数据源实现 RESTful API，或者与 CSS 纠结于“发送”按钮的对齐方式或样式。所有这些事情在这个阶段都不会有人关心。

也许您过于关注单元测试覆盖率，并迷失于模拟/存根每一段代码，而实际上一些单元测试和更多的集成测试会更容易、更快捷，而且实际上更有益。

许多谈论10X 开发人员的人只考虑技术技能和速度，却忘记了效率和效力的基本方面。

效率就是正确地做事；效能就是做正确的事。

如果最终交付的是无人要求的东西，那么无论多么快速和完美都是没有意义的。

范围蔓延

提出问题、了解需求和期望对于重新定义任务范围、改进冲刺计划和团队估算也至关重要。
或许应该将任务拆分成更多工单和更细粒度的子任务，这样就能更清晰地了解全局和细节，从而更精确地确定完成任务所需的时间。
目标明确后，在过程中提出其他细微的需求变更（无需调整估算或交付日期）的情况就比较少见了。

代码审查瓶颈

你有多少次以为已经完成了，却在代码审查时被退回，原因可能是代码中充斥着拼写错误、没有编写单元测试、忘记在表单输入框中添加验证、忘记考虑环境变量，以及太多依赖项是硬编码的？ 仅仅因为你在预计时间内将工单移至“待审批”状态，并不意味着工作已经完成，也并不意味着你已经按时交付。现在，这都是那个烦人又挑剔的代码审查员的错，你需要更多时间才能“完成”这些调整。（参见上文“完成”的定义）

错误

我并不是说你推送的所有内容都应该没有错误，但是如果你被要求实现一个表单，并且你忘记为必填字段添加基本验证并且所有内容都崩溃了，你不能只是说......：

好吧，但那是一个bug！我刚刚实现了表单，我们先关闭故事/任务单，再开一个bug单。（可惜我听到了……）

你称此为“完成”？

所以，正如你所看到的，有很多原因导致一项任务无法被视为完成或无法在规定时间内完成。
按时交付对你的团队和公司的成功至关重要，作为一名专业的开发人员也是如此。

这意味着我们绝不能含糊其辞，我们必须清楚目标和进度。如果你发现自己落后于计划，如果你意识到自己无法按时完成，不要撒谎，不要掩盖真相，说一些“简单的收尾工作或无关紧要的小问题”。

这并不是感到内疚和有压力，而是要告知你的团队和项目经理，这样你也许可以得到更多的时间或得到一些帮助。

封面图片：开普敦滨海高速公路大桥 - 始建于 1970 年，1977 年未完工 - 至今仍在那里（去年 10 月我在南非度假期间开车时看到了它，当时非常震惊......）