在我们开发软件的时候，经常会看到任务发生堆积的状况出现。
开发团队中的每个人都有做不完的的工作，且都不停的在多个任务之间切换。
虽然每个人都很忙碌，但这其实并不是一种高效的工作方式。
人们之前互相牵制和等待，会造成极大的资源浪费，项目交付是等不起的。
一件工作拖的时间越长，发生的变数也就越大，还要花费更大的成本进行调整和修改。
软件一天不交付到用户手中，那些开发中的半成品就没有意义。
所以，如何让自己的开发任务不产生堆积，如何快速的完工，提高团队整体研发效能，
成为了软件开发过程管理的重中之重。
产能
在刚入行进行软件开发的前几年，我总是在想 —— 如何才能把代码写好。
不惜一切代价，仔细的打磨自己的 “作品”，正是当时工作状态的真实写照。
这从当时的个人发展和工作状态来看，并不能说是一件坏事，
因为新人恰好需要这样的一种钻研精神，才能不断的提升自己满足岗位的需要。
但随着工作时间越来越长，负责的事项也越来越多之后，想法就发生了转变。
就会思考另外一个问题了 —— 如何在单位时间内创造更多的价值。
代码写的好固然重要，但也许在把精力用在了现阶段不是最重要的事情上。
正确的做事，不如做正确的事情。
考虑做正确的事情，就得把自己的视角从个人调整到团队、部门、公司甚至行业。
把软件开发活动理解为一种商业竞争。
商业竞争要考虑行业趋势、商业模式、产品定位、以及产能。
堆积
任务之间天生是容易产生堆积的，所以堆积是缺乏管理的一种体现。
换句话说，我们应该对任务进行管理，以避免发生堆积。
- 将堆积状态明示出来，将决策权往上抛
任务发生的堆积的主要原因之一是，添加任务的人，不知道任务产生了堆积。
甚至还对完成的任务者抱有不切实际的期待。
- 将任务进行拆分，让每件任务尽可能快的结束
任务拆分成更小的粒度之后，跟其他任务之间的次序调整就变得更加容易了。
小任务更容易管理，让每一个小任务在 1~2 天之内结束。
- 不要迟迟无进展，应迅速拿到阶段性成果
以成果角度，而不是完成度角度看待任务。
我们应该尽一切可能向外交付可见的工作成果，加速与用户、需求方之间的反馈。
链路
任务发生堆积，其实并不全是个人原因造成的，我们还应从任务链路角度进行审查。
因为一件任务其实很少是孤立存在的，与其他任务、其他人处理的任务之间有千丝万缕的联系。
至少我们应看到任务的上游和下游，即问题的来龙去脉。
这个任务是怎么来的，是谁的任务完成后导致了我这件任务发生？
我这个人任务完成后会怎样，会导致谁产生了新的任务？
因此，任务产生堆积的另一个原因可能是，任务上游完成的太快，下游消费的太慢。
我们应该看清这一切，把整个任务链路理顺，把任务看成一条 “河流”。
明朝治河专家 潘季驯，在一生四次治河经验过程中提出了 “束水攻沙” 的治河方略。
水分则势缓，势缓则沙停，沙停则河饱，尺寸之水皆有沙面，止见其高。
水合则势猛，势猛则沙刷，沙刷则河深，寻丈之水皆有河底，止见其卑。
筑堤束水，以水攻沙，水不奔溢于两旁，则必直刷乎河底。
是说河水如果比较分散，流速就慢，流速慢了就容易沉积泥沙，河道就会变浅，水就容易溢出来。
而把水 “束” 住之后，流速就会变得迅猛，迅猛的河水会带走泥沙，使得河道变深，反而不容易溢出来。
任务管理也是如此，任务之间流转的速度变快了，就更不容易产生堆积。
结语
开发者自身的任务产生堆积之后，个人产能只是被任务切换成本所影响，看起来影响并不大。
但从团队角度来看，堆积之间的任务相互牵制，会无形中增加很多等待成本。
造成了极大的资源浪费。
所以要想让团队的产能提升，就得做好每个团队成员的任务管理。
避免多个长时间的任务堆积在每个人身上。
持续不断的切分任务，调整优先级，并优化任务流转速度，才能将团队产能带到新高度。
潘季驯 治河所用的 “束水攻沙” 方略，有很多值得借鉴的地方，
这也是能印证丰田公司 “精益生产” 的想法。
增强 “流动性” 确实是破解 “不确定性” 的一个好办法。