敏捷开发之工程师素质

前几天和一个刚换工作的同事沟通，他告诉我他所在的新公司领导不喜欢敏捷开发模式，原因是他们领导觉得敏捷开发对工程师素质的要求太高了。我觉得这个想法很新颖，值得讨论一下。

 

1 我常说，敏捷开发模式的基础是代码要敏捷，即如果工程师生产出来的代码本身不够“敏捷”，那也无所谓谈何种开发模式了，从这个角度看，敏捷开发确实对工程师素质有很高的要求

2 对于素质高的工程师，哪个项目经理不喜欢呢？敏捷开发模式也好，传统瀑布开发模式也罢，作为项目的管理者，总是希望项目的开发工程师素质越高越好，从这个角度看，高素质工程师总是受欢迎的，并不是敏捷开发模式特别偏爱

3 现实的项目中，在项目管理者看来，所谓的高素质工程师总是不够的，或者说，素质不高的工程师总是占大多数的，那既然敏捷开发对工程师素质又有那么高的要求，因此，领导们对敏捷开发敬而远之好像也有那么点道理

4 一般而言，敏捷开发模式的推崇者宣称敏捷有着更多的优点，表现出来就是更好的响应变化的需求、更快的开发进度和更高的质量等等，就我个人的体会，敏捷还有一个很突出的优点就是如果某个项目注定要失败，那么敏捷可能可以更早的把这一不幸的结果暴露出来，这个优点有时候我甚至觉得这是敏捷最大的优点

5 敏捷号称的那么多优点，仅仅是因为参与敏捷开发的工程师素质高吗？

6 来看一个实际的例子：某个项目经过任务分解，一共有十个子模块需要开发，在传统的开发模式下，项目经理把这些子模块往开发工程师处一扔，要求他们评估出工作量和制定研发计划，开发工程师做完评估预估和制定完计划后，接下来就开始进入实际开发阶段了；开头几个子模块进展很顺利，每个周的周报都很好写，项目经理也很乐观；开发到最后两个子模块或者是所谓系统联调阶段时，开始出现各种状况了，各种质量问题、各种发布计划 DELAY，项目经理开始纠结了，项目失败的苗头开始显现了。为何会出现这种情况？我是这样认为的：从人情上而言，开发工程师在拿到10个子模块开发任务后，他会选择那些比较熟悉、比较有把握的模块开始先做，而比较麻烦、不太熟悉的子模块会相对的放到最后做。而正是这样的一种开发顺序选择，很容易导致上述例子中的状况

7 在敏捷开发模式 scrum 中，上述状况是可以得到避免的，因为开发模式把子模块开发顺序的权力明确赋予了产品经理，而非研发人员，这样一种职能的分配，可以有效的降低项目的风险

8 当然，如果某一个子模块确实开发难度高，敏捷并不能帮程序员把开发难度降低，程序员在传统模式下无法完成的某些算法的开发，在敏捷模式下依然无法完成，但是，敏捷的好处是，它可以让产品经理或者项目经理很快发现这个事实，再了解到该事实后，他可以暂停或者取消该项目，也可以再增加一些资源的投入，确保技术困难得到解决，这是敏捷一个很大的优点之一

9 从上面的例子可以看到，所谓的传统模式对工程师要求低的看法，其实是以传统开发模式的项目失败率上升为代价的，即如果工程师能力不够完成某项目，在传统模式下，这个项目依然可以立项和推进，直到某一天这个项目走向失败；而在敏捷开发模式下，这个项目可能很快就被公司给暂停或者取消，因为他们很早的就可以发现工程师素质不足以完成工作的事实，而这个事实，工程师自己很可能是知道或者疑虑的，但是工程师自己是很可能不会告诉产品经理或者项目经理的

10 我的看法是，在投入同等资源（人员、时间、其他部门配合等）的情况下，敏捷开发模式的效率更高，即产出的产品功能更多、质量更好；而在完成特定指标（功能点、质量水平等）的情况下，敏捷对资源的要求可能比传统的方式更低