每个人都有惰性，每个人都很自负，特别是对于软件开发人员，他们总是过高的估计自我的能力，在任务的最后期限已经逐渐临近的时候才会真正的全身心的投入任务，而往往造成的任务的延期和90%完成这种进度游戏现象。而这也往往称呼为学生综合症。
敏捷方法论用很简单的实践来解决了这些问题，包括每日构造，每日的站立会议，短周期的迭代和细化到1-2天粒度的任务。所有这些都是为了每天可视化的进度，可检验的进度。任何进度问题都会在每天暴露无遗。
帕金森定律强调，一份工作所需要的资源与工作本身并没有太大的关系，一件事情被膨胀出来的重要性和复杂性，与完成这件事怕花的时间成正比。你以为给自己很多很多的时间完成一件事就可以改善工作的品质，但实际情况并非如此。时间太多反而使你懒散、缺乏原动力、效率低，可能还会大幅度降低效力。关键链项目管理的核心思路也正是基于这一点。
敏捷方法论中对于这点仍然是需要考虑关键链项目管理的特点和看板管理的文化，首先是要尽量讲缓冲保留在项目最后，其次是对于每个任务是否完成都要有清晰准确的验收定义，最后仍然是细粒度的粒度和任务计划。
康威定律（Conway’s Law）：“让四个人开发编译器，你就会得到四个（4-pass）编译器”。原始表述更具有一般性：“产品必然是其组织通讯结构的缩影”。简言之就是“方法决定结果”或是“过程变为产品”。这个定律无非也在告诉我们开发人员间的高效面对面的沟通对于好的产品和设计是至关重要的，由于沟通不顺畅分布式的团队往往会损害到软件设计。
在敏捷方法论中我们强调，较之于过程和工具，应更注重人及其交互的价值。因此敏捷方法论更加强调站立会议，面对面沟通，结对编程，可视化进度等最佳实践的应用。
在人月神话里面谈到的布鲁克斯定律大家都必须熟悉了，往往进度落后的项目中投入更多的人手往往使进度更加落后。这一方面是由于新人进来后的培训成本时间，一方面是沟通不畅引起的消耗时间。
敏捷方法中强调的结对编程，迭代开发，小型团队都是为了解决这些问题。通过迭代版本规划将大项目规划为了多个细化后的迭代版本，每个迭代版本都可以保持更加明确的输入，输出和接口。
相关资源：wsltools:Web扫描惰性工具-Python软件包-其它代码类资源-CSDN文库
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！