划重点 | 关于“任务分解”，你要重点掌握哪些事？
郑晔
该思维导图由 AI 生成，仅供参考
你好，我是郑晔，恭喜你，又完成了一个模块的学习。
在这个模块中，我主要讲解的是“任务分解”这个知易行难的工作原则。普通人与高手之间的差异，很大程度上取决于任务分解的粒度大小。但真正理解并应用好“任务分解”的原则并不容易，希望你能勤于练习，将知识内化成为你的能力。
重点复习
在这个模块中，我们学习到了一些最佳实践：
测试金字塔
-- 行业中测试组合的最佳实践。
-- 多写单元测试是关键。
测试驱动开发
-- 测试驱动开发的节奏是：红——绿——重构，重构是测试驱动开发区别于测试先行的关键。
-- 有人把测试驱动开发理解成测试驱动设计，它给行业带来的思维改变是，编写可测的代码。
艾森豪威尔矩阵（Eisenhower Matrix）
-- 将事情按照重要和紧急进行划分。
-- 重要且紧急的事情要立即做。重要但不紧急的事情应该是我们重点投入精力的地方。紧急但不重要的事情，可以委托别人做。不重要不紧急的事情，尽量少做。
最小可行产品
-- “刚刚好”满足客户需求的产品。
-- 在实践中，要用最小的代价找到一条可行的路径。
另外，我还提到了一些可以直接在工作中应用的做法和评判标准：
尽量不写 static 方法；
主分支开发模型是一种更好的开发分支模型；
好的用户故事应该符合 INVEST 原则；
估算是一个加深对需求理解的过程，好的估算是以任务分解为基础的；
好的测试应该符合 A-TRIP。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
这篇文章深入探讨了“任务分解”这一工作原则的重要性和实际应用。作者强调了任务分解对于提高工作效率和质量的关键作用，并提供了一些最佳实践和实战指南，如测试金字塔、测试驱动开发、艾森豪威尔矩阵、最小可行产品等概念和方法。此外，文章还涉及了一些重要的思想，如分而治之、软件变更成本、测试框架等。读者可以从中获得丰富的知识内容和实用的工作指导，有助于提升工作效率和质量。同时，文章还包括了一些同学的留言，分享了他们在任务分解实践中的心得体会，为读者提供了额外的学习收获。整体而言，这篇文章为读者提供了深入的技术内容和实用的经验分享，对于工作中的任务分解和执行具有重要的指导意义。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《10x 程序员工作法》，新⼈⾸单¥68
《10x 程序员工作法》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(7)
- 最新
- 精选
西西弗与卡夫卡任务分解，我觉得应该是四大原则（其余三个是以终为始、沟通反馈、自动化）里最关键一环。怎么分解，分解到什么程度，怎么根据当前情况选择合适路径，怎么确定轻重缓急，更进一步说，怎么在压力之下依然能稳住心神坚持自己的路径，都很吃功夫。是一门学到老的功夫作者回复: 工匠功夫，慢慢练
2019-02-1514
lionel作为一个小公司的前端开发+赶鸭子上架的项目经理，花了两天追完了正文。感觉两个身份的收获都很大。 另外自己对这个专栏做了一些笔记和摘抄，以便记忆，请问是否可以分享到自己的小圈子。链接如下： https://www.yuque.com/lionel-6od7c/js/kwtfda作者回复: 很赞的总结！你可以自己决定怎么做。你也可以邀请朋友订阅专栏，加入到我们的学习中。
2019-02-1713
Demon.Lee谢谢老师。前一条下面留言，您可能看不到，我这里再发一条新的。1. 您说的在对象上加一个方法做转换，是指在VO里面加一个方法转成Entity吗，那这样的话，这两个类不就耦合了么？2. 我们现在用的就是一个单独的类，里面写静态方法，把VO传进去，返回Enitity，或把Entity传进去，返回VO，不知道是不是您说的转换类？作者回复: 1. 只有 VO 依赖于 Entity，所以，转换方法都在 VO 里。Entity 不知道 VO。 2.单独的类没问题，不要写静态方法，写成普通的方法就好。
2020-06-1923
丁丁历险记老师的梳理能力不错。 个人这个能力应该是大量实践带来的，很多时候深度理解了，记忆也就不多了，几个点一串，就自成一小体系了。不知猜对了没作者回复: 知识成体系很重要
2019-11-123- Demon.Lee尽量不写 static 方法 ---老师，我们现在用的spring boot，经常对一些模型进行转换（比如VO转成Entity或反过来转换），用的就是静态方法，您有更好的建议么
作者回复: 一种做法是，在对象上加一个方法做转换，一种方法是，做转换类。
2020-06-183 
6点无痛早起学习的和尚
其实看到这里突然想到了，很多时候我们给不了一个需求的排期，那是因为我们对这个需求不完全理解和不会任务分解。 如果对需求理解，并且再对需求进行任务分解。 1. 首先分出来模型 2. 再分功能点 3. 对模型和功能点再分 4. 分到你认为可以预估时间了，然后再把所有时间加起来=开发人力。 因为我平常有时候就不会估算开发人力，交给我的需求，我就是拍脑袋一想，最后有时候就把自己坑了2023-05-19归属地：北京2
ifelse
酷，任务分解我正在练习中2022-04-18
收起评论
