文章：《编程的精进之法》
关键词：知识工作、任务列表、PDCA（Plan-Do-Check-Action）、自我记录、总结改进
引子：知识工作者需要自我管理
理由如下：
体力工作的效率提升可以通过外力完成，比如可标准化流程来提高熟练度；比如完善管理和组织劳动者的方式、合理分配任务等。只要管理者能够以足够有效的激励方式激励体力劳动者，比如为之提供足够高的薪水、关注他们的体力和健康状况，那么劳动的效率自然会得到提升。
但知识工作不同，当管理因素和激励因素全部到位，知识工作者的做事方法和工作方式（即个人能力或技术水平）是制约生产效率的重要因素。知识工作的方法和技巧有很多种，且条条大道通罗马，每个人都有自己独特的工作方式。知识工作者要谋求自己生产效率的提升，借助外力要比体力劳动者难：原因是其他人必须深入了解这种工作方式才能为之提供改进的建议，而这个了解的过程要花费很长时间并且有一定难度，远远大于了解一个体力工作者的成本。
方法：可视化工作效率并找到自己生产效率的瓶颈，然后分析、优化
任务列表法+PDCA（Plan-Do-Check-Action）法
一、任务列表法
好的任务列表：不遗漏、不依赖、不重复
（1）不遗漏：工作任务和任务列表完全等价。
即你在工作种中的每一项工作都能在任务列表中找出相对应的任务
如果在任务进行中又出现了新的任务怎么办？
补救方法：立即将之加入任务列表，同时对任务的难度等级、完成时间等标准做相应调整
这里有个任务细化粒度的问题：要把任务细分到什么程度呢？
（2）不依赖：任务之间不能有依赖关系
如果列表中有任务必须在其他任务完成之后才能做，那这个任务就不应该在当前级别的任务列表中出现。如果你发现列出的任务重有好几个都依赖于同一个任务，那么把这个任务列入当前列表，将其他任务置后。
（3）不重复：任务之间不能有交集
不是说任务列表之间不能重复，而是你划分的任务之中不能有相互重复的子任，务，或者这两个子任务之间相互依赖。如果有，那就细分任务，直到它们相互独立为止
二、PDCA（Plan-Do-Check-Action）法
做计划（任务列表)——>实际完成任务——>检查完成任务的成果（找出问题根源）——>行动起来，解决问题，让下一次的计划更合理，更高效
（1）做计划：不必太过严格细致
计划赶不上变化，能很好的控制变化即可。把任务的实际完成量、实际完成时间等做对比，将误差控制在一定范围内。
（2）实际做任务：灵活应对变化，简单快速调整任务列表，把风险消除在萌芽之中
在实际完成任务时，如果遇到新增的任务，简单快速地修改任务列表，重新整理思路后继续投入工作，不能花太多时间。记录的目的是让你的工作过程可视化，以供后续分析改进，只是辅助的方法而已。但也不能什么都不做，这样你实际做的任务会偏离计划太多，会造成不必要的风险。
（3）检查任务完成质量：善于分析，长于挖掘，胜者
不管你善用数据分析也好，逻辑分析也罢，这个分析总结的过程会告诉你你实际的生产力和自己觉得应该达到的生产力还差多少。通过对任务类型和完成质量的综合分析，你就能知道自己做的最快的事情是什么，做的最慢的事情是什么，这就是你的优势和劣势了。当然其他更深层次的东西，靠你了！
（4）让下一次的计划更合理，更高效：把知识转化为生产力，这才是最牛逼的地方
如果你通过上面的步骤已经可以比较准确的了解自己，现在就开始为自己量身定制成长计划，让每个经验都能在下一次任务中发挥作用，总有水滴石穿的一天。
抛出一枚硬币，只有在次数足够多的情况下抛出正面或反面的概率才会接近1/2，统计的力量要在数据样本足够多时才能发挥到极致。所以不能指望一天两天，一月两月就会有明显的变化，前期的积累会给你厚积薄发的资格。
编程：如果你是一枚程序猿，把上面的方法用到自己日常的编码任务中吧！
在现实生活中想做到各项任务都独立挑战还是比较大，但是在编程的世界里，挑战没有那么大，程序世界做到这一点真的太轻松了。优秀的设计都是要求解耦的，如果做不到，基本等于活儿比较烂。
好，现在你拿到一个编程任务，我们开始实践！
任务列表法+PDCA（Plan-Do-Check-Action）法
一、任务列表法
写任务列表难在合理清晰的划分任务，而对编程来说，任务细分、需求澄清更是重中之重
方法一：
需求分析（想不清楚细节）——>写代码（发现需求分析不明确）——>跟业务人员确认需求——>写完所有逻辑——>测试、调试，通过后交给QA——>QA测出bug，debug、打补丁——>完成代码并提交（代码逻辑好像有点混乱，写注释都快把人烦死了）
方法二：
分解任务【1】——>列Example，用实例化需求的方式澄清需求细节【2】——>写测试代码【3】——>写实现代码【4】—>代码重构【5】——>手动测试——>QA测试——>补用例、修复bug——>提交代码【6】
注：【1】分解任务（等价于写任务列表）：用用户场景去覆盖任务的每一个功能点，把每一种可能的输入输出罗列出来，反复执行业务流程，挖掘功能需求
【2】列任务执行场景，考虑各种输入输出限制，力争澄清需求细节
【3】写测试代码时，只关注需求和程序的输入输出，不关注实现过程。为每一个细小的功能点写测试用例，并且保证测试代码可以跑通
【4】写实现代码时，先用简单的方法满足当前的测试用例，保证测试代码的正确性；再写代码完成当前的小需求。
【5】代码重构：不要忘了优化你的代码
【6】QA测试、代码修改和代码提交，留给你的就只有很少的工作量了
注意：以上你只实现了一个小需求，要完成任务，有万年不变的真理：迭代开发，忙而不乱！
如果你对方法二有兴趣，可以参考下面这篇文章，顺便了解下【测试驱动开发】
深度解读TDD（测试驱动开发）
二、PDCA（Plan-Do-Check-Action）法
Plan：由任务列表法辅助实现
Do&Check：两个考察点
1. Plan的时候估计一个时间，然后开始做，做的时候计时，做完就要Check这个时间是否达标，无论快了还是慢了（通常是比较明显的差距才反思，比如20%以上的差距），Check都要反思并产生Action，纳入到未来的Plan中去。
2. 估计的任务列表和实际做的任务列表是否是一样多的？往往是会多出来，这时就要反思，自己在哪里有不足导致了这个差别。
Thinking&Action：发现自己的问题：任务列表扩张，时间估计不准......
（1）任务划分是或否准确，检查自己的任务列表是否是“好的任务列表”，参照“不遗漏、不依赖、不重复”的指标
（2）业务知识不熟悉：在日常任务列表中加入相关任务
（3）技能方法不熟练：在编程能力提升任务列表中加入相关任务
（4）...... ....... .......（列表名叫什么，你随意......）
（5）...... ....... .......（一定要采取行动，别忽略这些问题......）
要具体的例子？点击原文去看看吧！希望你有所收获~
我又贴心的放了链接《编程的精进之法》，哈哈哈！