这里是Z哥的个人公众号

每周五11：45 按时送达

当然了，也会时不时加个餐～

我的第「230」篇原创敬上

大家好，我是Z哥。

最近在想一个问题，为什么大多数软件开发的工作都深陷在“吃力不讨好”的困境中。为什么这么说呢？因为我看到很多程序员小伙伴工作很辛苦，但是往往最终获得的结果或者说外部评价并不好。

这个问题本质上就是一个「预期和实际不相等」问题，或者说「投入和产出不成正比」问题。

众所周知，度量程序员的工作是个世纪难题，没有一把尺可以将众多程序员们分为三六九等。因此，程序员日常开展的软件开发工作的好坏，更加难以度量了。

不过，虽然无法通过度量来解决这个问题，但是我们身为程序员大军中的一员，还是得想办法让自己尽量避免陷入到“吃力不讨好”的困境之中。

否则我们的工作状态很容易陷入到恶性循环中：因为努力得不到好结果，所以是否努力并不重要，索性就不努力了，因此结果只可能更不好，不断陷入到一个负反馈回路中。

最近，我们团队中针对这个问题找到的突破点是通过重视「任务拆分」来缓解甚至是解决这个问题。

任务拆分其实每个人都会做，但是要你说说为什么这么拆的理由，大概率你说不上来。因为我们很多人平时拆任务其实就是根据自己过去的习惯，甚至是凭自己的感觉在拆。

之所以如此，是因为大家觉得任务拆分有什么难的，不就是「分而治之」嘛，做软件开发的谁还不懂这个。

但是不同的人，对如何“分”的依据不同，因此针对同一个需求/功能的拆分方案其实有很多种，自然有优劣的区分。所以，今天我就想来和你分享一下我对如何做好任务拆分这件事的看法。

在我看来，大家以「分治」拆分任务的思路其实像是把一块蛋糕竖着切，你负责这几块，我负责那几块，他负责剩下的几块。

这个思路方向上肯定是没错的，但是我觉得不全。我觉得任务拆分还得多做“横切”的考虑。“横切”我的理解就是阶段性交付，我们可以将一个功能/子功能的完整能力识别出核心和非核心，然后多次交付。如此一来，任务的颗粒度会更细一些，同时也不会破坏交付物的「完整性」。

理论上，更小的交付单元，大家对它的认知相对会更容易达成一致。这就好比，不同的人对如何造一辆车的认知差异远比如何制作一个轮胎甚至是螺丝钉的差异大得多。

另外，做好任务拆分这件事我们还可以获得不少好处：

1. 降低复杂度。通过提前的分析对复杂度有更深的认识，再通过任务拆分将复杂的大任务变成一个个更简单的子任务。

2. 便于与其他人的认知一致。一看就知道具体的行动是什么。比如，“把玩具放到箱子里”比“整理玩具”表达的含义更清晰。

3. 降低对工作时间连续性的要求。如果一个任务很大，需要几天才能完成，那么无法避免大脑上下文切换的时间损耗。但是如果一个任务只要2小时就能完成，我们还是比较容易在工作中找出一个完整的2小时来全身心完成这个任务。

4. 便于实现小步快跑的持续交付。毕竟小步快跑的关键不是“快跑”，而是“小步”。

5. 可对“零部件”进行充分地测试，提升被组合使用后的整体鲁棒性。这就好比，如果每个汽车零部件的质量都制作得刚刚好，不留余地，那么组装而成的汽车必定经常出现故障。因为并不是所有零部件都承受得了所有意料之外的情况。

但是，要做好全员的任务拆分这件事，挺难的。不同的人有不同的拆法，为了让整体上步调一致，我提炼了一些原则供大家参考。

• 独立性：单个任务的完成不依赖其它任务。我认为这事最重要的一点，缺少了这个，后面的很多原则就会失效。
• 完整性：任务完成后可提供某种完整的能力而非一个半成品，该能力可以被外部调用或者自我运行。注意，能力不等于业务需求，但是支撑需求实现的一部分。
• 可估算：任务需要能够估算其时间成本。无法估算意味着无法衡量复杂度，是一个任务拆分不合理的信号。我们可以通过“是否可以通过一句话描述清楚这个任务是做什么的”来判断是否做到了这点，这一句话往往也就是这个任务的标题。
• 适度大小：如果任务的颗粒度太小，会增加管理和协作成本；如果颗粒度太大，会增加复杂度和不可控的风险。一般来说DevOps玩得越成熟的团队，适度的定义可以更小一些。我认为合理的区间在1～6小时之间。
• 可测试：每个任务都必须有一个明确的结束点和判断是否成功的标准，以便可以测试和验证它是否完成。
• 区分主次：哪怕是同一个功能，也需要识别主要能力和次要能力。如果可以，将次要能力单独创建一个任务，分批交付。

还有一个能做到则更好的原则：

通用性：拆分任务的时候，需要尽量让每个拆出来的任务具有更好的通用性，如此才能在更高层面提高整体的可复用性，提升整体效能。

在我看来，任务拆分这件事，本质上体现了一个人的工程化能力。如果你能做好任务拆分，其实也意味着你的软件工程能力也不会太差。

另外，做完任务拆分后，我们还得重视“如何准确清晰地把任务讲清楚”，这会使得任务拆分的价值进一步放大。清晰准确的任务标题和针对任务要点的描述能够提高任务这个信息在团队内的传递效率。

好了，我们总结一下。

今天呢，Z哥和你聊了做好「任务拆分」这件事对程序员日常工作的影响。以及分享了一些如何进行「任务拆分」建议。

希望对你有所启发。同时祝各位程序员们能够早日摆脱“码农”的定义，成为名副其实的“工程师”，多做工程师该做的事。

---

原创文章，转载请注明本文链接: https://zacharyfan.com/archives/1599.html

关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描二维码~

定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。

如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。

如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。