简洁、高效、简单，是当代文化所高度推崇的。或许这是因为和以前相比，现代社会变得相对丰富和复杂了。代码简洁、流程高效的Wb应用会让最终产品易于维护、易于修改，最终会帮助获取更高的利润。同样，程序员的工作流程和工具也应该高效，避免无谓的复杂。由于选择太多，开发者暂时从编码中抽身，认真思考一下工作流程是否优化、是否高效，就变得特别重要了。
随着Wb开发方式向客户端-服务器端架构的转变，开发流程也面临不断的改变和提高。通过去掉很少用到的配置选项、使用合理的缺省值，减少了大量不必要的工作。简化的工作流程带来更紧凑及时的反馈循环，频繁的反馈让人及时发现和解决产品中的问题。及早发现和修复缺陷提高了生产效率——也让程序员更加开心。更进一步说，它让原本需要大量时间和资源才能开发维护的复杂且高质量的软件，现在有可能花费较少的时间和资源就能做到。
大多草草了事……
众所周知，衡量程序员的生产效率很难。工作时间、每日代码量或者解决的缺陷数目，这样的指标虽然可量化，但不是很有用。由于项目的目标、时间和其预期寿命的不同，很难对它们做比较。没有一个指标能适用于所有项目，足够客观、公正，准确地反映出程序员的工作效率。在实践中，大多数软件开发经理根据开发者给出的估计和实际产出，“艺术地”维护着一张电子表格以准确估计这两者之间的关联度。这样就能理解，为什么通过改进流程会提升个人和组织的效率这个假设会被大家所接受了。
敏捷开发最早是以纠正瀑布式开发的缺陷的形式出现的，瀑布式开发倾向于一开始就负重前行，花费大量精力，组织大量活动，项目反而不会取得有意义的进展。这种趋势再发展就是“分析瘫痪”，当敏捷开发被初次引入时，其立即着手开发一个可工作的产品的观点令人耳目一新。遗憾的是，随着时间的推移，这一概念被发展成为一种“做了再说”的方式，早期的很多活动都没有一个定义清晰的目标。因此，如果想要生产提高效率需要，可能这样说有违直觉，需要先放下工作。显然，这不是指让你真的放下工作，这是为了项目的质量和长期生产效率，而对暂时的衡量指标和可见进度做出牺牲的能力。
这样做很有挑战性。管理层希望看见手头的项目进展，开发者喜欢编写代码，客户希望看到前者真的着手开始工作了。但是过早开始可能会导致工具和开发方式选型错误（或者不是最理想的）。将不适用的约定或传统引入项目遗害无穷。早期的一点点偏差，都会让项目偏离正确的轨道，随着项目的进展，问题会越积越多。认识到暂时放下工作，先做一些分析，会让工作效率更高，产品质量更高，这是需要一些远见的。
预先分析因为采用伪敏捷开发（psudo-agil）而饱受诟病（“伪”字是指这里所讲的并不违背敏捷开发实践）。凡事要三思而后行，这适用于多个层面。开发团队领导者需要做出项目相关的决定，每一个开发者需要了解最佳实践和新兴技术，这对他们的手头工作可能有用。有了正确的工具和方法，会减少完成初始工作的时间和精力，如果做对了，从长远看会开发出一套简单、易于维护的系统。不可将全部精力和注意力放在最紧急的任务上，而应做出根本性调整以高效地工作。在项目中可以采用敏捷开发中欢迎变化的方式，但基础的技术决策和相关开发流程不应有大的改动。
避免孤立地看待生产效率
显而易见，只