这篇文章的来源是我在知乎上回答的相关问题~~。

项目就是一个很复杂的事，涉及到: 时间，成本，周期，技术栈等等。我们是乙方，所以我们从不考虑成本的原因。然后先说说我们在软件工程方面的实践，我不敢说是国内最好的，但我相信至少是数一数二的。我们采用的是敏捷的工作流程，不过我相信那些对于尝试过敏捷的人来说可能会有些反感。

先说说我们平时是怎么做的：

1. 每日站会。大概会有十几分钟的沟通时间，主要看有没有遇到什么问题。
2. 结对编程。这意味着两个人做一件事情。我们大概两天会换一次Pair。
3. 测试(TDD)与测试覆盖率。大部分公司的代码都是没有测试覆盖的，即使是BAT也是一样的。如果我们花一天写功能代码，那么至少还要有半天的时间要写测试。
4. 持续集成。你要经常提交你的代码，还要有测试，还要和别人的代码集成——而且是一天多次。
5. 进行Code Review。每天大概会有三十分钟到一小时的Code Review时间，而且是集体Review今天的代码。
6. 技术债。在我们的上个项目中，由于是新的开发框架。在后期，我们发现我们积累了一些技术债——主要是代码质量问题。然后，我们一周抽时间来一起重构代码。
7. 每周两次的技术Session。技术Session的主要目的是提高团队成员的技术水平。

我就不对上面的优点展开了。现在，让我们来算一下我们需要多付出多小的成本。

假设，我们现在有四个人，每个人独立工作，可以在一周内完成。即一个人需要 8*5 小时的工作时间。

如果采用上面的工程会多出来多少的成本？

一天480分钟 - 60分钟Code Review - 15分钟站会 - 平均的技术债修复时间 15分钟 - Session花费30分钟 = 360分钟 = 6小时。

接着，再减去写测试的时间，就只剩下 4 小时。

然后，因为是结对编程，所以每个人只有2小时的时间。。。

这就意味着，我们可能要四周才能完成这个项目！！对于一个短期的项目来说，这简直是不可接受的。

但是需要注意的是：

采用敏捷就意味着，生产力是固定的、代码质量较高、技术平均水平较高！

采用敏捷就意味着，生产力是固定的、代码质量较高、技术平均水平较高！

采用敏捷就意味着，生产力是固定的、代码质量较高、技术平均水平较高！

这一点特别适合大的、长期的项目。请再听我慢慢道来：

因为采用结对编程，所以每个人对整个项目的代码都很熟悉。这就意味着，不用担心有人离职要影响项目的稳定性。当有一个人离职时，整个项目的产出率也不会因此而变化。并且新人会因为采用结对编程而上手更快。因此只要不是一起离职，即使一年后，这个项目的人都已经换了一遍，项目仍然可以继续下去。

同样的有Code Review、测试和结对编程的存在，组内的代码质量会达到相当高的水平。虽然这在早期可能意义不大，但是请注意一点：Bug在越后期的修复成本越大。

除了结对编程，还有技术Session可以提高组内成员的技术水平。

最后，你会发现在这里，取主要因素的是人以及流程。