我们的政策要求我们的开发人员要快速。§36部分支付更快的交付，而§8则惩罚慢动作者，如果他们在十天内没有完成任务（撰写时）。为什么要十天，如果我们的任务是如此小？完成一个平均任务到底需要多长时间？我们能做些什么来更快地完成任务吗？
这是一个非常常见的困惑，这也是我决定写这篇博客文章的原因。当我与我们的新客户交谈时，他们通常会问我，为什么一个小半小时的任务需要五天才能完成，这难道不是整个项目的严重瓶颈吗？他们更习惯于认为程序员说需要一周来实现，然后在一个日历周内，或多或少，结果就会交付。
在我们的情况下，一个程序员说需要30分钟，结果在七天内交付。然后程序员会为他或她的30分钟工作时间而获得报酬。对于那些不了解按结果付费的微任务工作方式的人来说，这听起来很奇怪。让我来解释一下。
每个任务中有两个几乎没有直接关联的不同事物：预算（成本）和持续时间（时间）。我们程序员是项目购买的资源，用来完成其工作包，这些工作包在组装在一起后会产生一个工作软件模块。建房子时，资源是砖头、水泥、窗户、瓦片和建筑工人的双手。创建软件产品时，资源是…程序员的双手，几乎没有别的。
这些资源是项目多维矩阵的第一个轴，而日历时间是第二个轴。要建一座房子，我们需要，比如说，五个人连续工作80小时，相当于400个员工小时。当然我们还需要砖头、水泥和其他一切。例如，如果送砖的卡车延误几天，十天日历时间是不够的。如果我们的工作没有得到正确组织，或者只是因为人们是人类，我们可能会耗费这400个员工小时很多次。
对于软件项目也是如此，但没有砖头和水泥。只有人，而他们经常迟到。当一个30分钟的任务交到一个程序员手上，这并不意味着他或她可以在30分钟内完成。有许多依赖关系，有时需要等待的东西，有时需要等待几天。这里是一个非详尽总结，说明一个普通程序员为了完成一个相当普通的微任务需要经历的事情：
请向工单报告人要求进一步完善描述；
打开代码存储库；
找到需要更改的地方；
如果代码不够清晰和干净，请提交其他几个工单。
讨论在这些工单中所做的更改；
关闭这些工单，也许可以提交新的。
创建一个Git分支；
Make changes;
运行构建并确保它是绿色的;
提交并推送更改；
创建一个拉取请求;
回应代码审查人员的评论；
对分支进行所需的更改;
回复建筑师的评论并进行修改；
确保PR通过合并流程；
请询问票务作者关闭它;
与作者争论；
如果问题没有解决，请重新开始。
正如您所见，实际的代码编写行在这个列表的中间某处，名为“进行更改”。其他一切与代码编写无直接关系。一切都是关于交付更改并确保它们被接受。
最聪明的程序员知道如何尽可能地减少和加快“进行更改”的部分，以便留更多时间和精力处理其他事情。此外，最聪明的程序员知道如何以更快速被接受的方式进行更改。这似乎是纪律、热情和艺术的结合。很难解释需要做什么和如何做。这就是社会技能所涉及的内容。
关键是我们最优秀的程序员在4-5天内完成30分钟的微型任务。Zerocrat同时给他们分配多个任务，根据第3节的规定，期望每位程序员每天完成六到八个任务。
Translated by ChatGPT gpt-3.5-turbo/42 on 2024-05-27 at 01:24
