想用敏捷开发没那么简单

不久前我在朋友圈发表了这样一条状态:

---

跟随一种潮流很简单，打破才需要很大的勇气。在谈软件开发流程便是敏捷开发的今天，管理团队或者我们每个团队成员会去思考敏捷真的适合我们吗？

---

但是有一点是毋庸置疑的，由敏捷理论催生出来的培训课程让很多公司赚到盆满。

这条状态不是要去否定敏捷软件开发，事实上我个人非常认同敏捷开发的理念。但是面对这个从90年代开始逐渐引起关注，到今天全面流行的软件开发方法，很多团队拿来使用，真的有看病下药吗？这篇文章我想从我个人的实际项目经验谈谈为什么想用敏捷开发没有那么简单。

团队成员缺乏敏捷开发的理论知识

如果我们去Agile Alliance网站上去看敏捷相关的东西，你会发现异常的简单。它包含了四条敏捷宣言，以及12条原则。这就会给人一种错觉，敏捷软件开发的理论比较简单。实则不然，这是一个几十年逐渐演化而来的理论，虽然高度抽象，却是经过了很多年的发展。掩藏在高度抽象文字背后的知识，是需要我们花很多时间去学习和体会的。因为我们是软件开发团队，团队成员往往把更多的精力放在学好一门编程语言，一个框架，一个软件开发工具上面，因为这些知识比起敏捷理论来更加实际，学了马上就能用到项目中。敏捷开发的知识就相对很虚，你学了也不见得马上用到项目中。所以在实际项目中，考虑到机会成本，大多数开发人员对敏捷还是缺乏更深入的学习和了解。

开发人员流动比较频繁

目前在软件开发这个行业中，开发人员的流动还是比较频繁的。这跟敏捷开发的原则也是相违背的。在那12条原则中，有一条是这样说的“敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。”这是多么理想的一种状态啊。我所在的项目，人员会时常地变动。甚至有的时候是巨大的变化。这就给敏捷开发带来很大的不确定因素。敏捷宣言第一条告诉我们个体和互动高于流程和工具，它非常强调人的重要性。但是当人员发生变化就意味着团队成员需要重新熟悉彼此，人跟人之间的互动也需要慢慢建立。

地理位置带来的不便

敏捷软件开发倡导面对面的交流，最好团队成员能够始终在一起工作。由于项目的原因我们的团队分布在不同国家。我们无法实现面对面的交流。这给团队成员之间的沟通带来了很大的不便。你可能会说我们可以通过电话会议进行沟通和交流。但是一周一两次的沟通并不能解决太多问题，加上语言和文化上的一些障碍，以及信息在传递过程中的衰减也给互动带来很大的障碍。

形式主义

我们采用敏捷软件开发，很容易进入形式主义的陷阱。譬如我们采用scrum，每天重复站会，sprint结束我们开回顾会议。sprint开始我们开计划会议。但是项目就是没有起色。这就好比婚姻，我们领了结婚证，在一起生活，买菜，做饭......，但是并不能保证婚姻是幸福的。要想保证婚姻幸福还要有良好的沟通，双方能够互相信任并且体谅对方。同样地scrum中的那些流程是为了帮助团队成员更好地沟通，以及提高团队成员自身的能力，从而将项目做好，而不是为了让老板看到我们有这样的形式和各种报告。

上面谈了一些在使用敏捷软件开发的过程中，我们面临的一些问题。下面我们来说说，应该怎么做才能将敏捷软件开发做好。当然这些只是我个人的一些观点。

全情投入

假如我们选择采用敏捷软件开发，那么我们就要相信这种软件开发的方式。用英文描述就是buy in,所有的人都应该buy in。尤其是管理团队，他们在组建团队的时候应该挑选拥有敏捷相关知识，并且信任这种方法论的人作为团队成员。只有大家的理念相同才能和谐地在一起工作。

如果团队成员缺乏敏捷相关的理论知识，我们应该有计划地给予他们相关地培训，你不能期望不懂敏捷理论的人能够很好地运用它。

迅速请走不合适的团队成员

尽管在敏捷软件开发的原则里，我们需要一支稳定的团队。但是当团队中出现不能很好履行自己责任的成员时，我们也应该很快地将他请出项目。这里不合适的成员指的是那些不愿意跟团队其他成员沟通和交流的人。因为你不在第一时间将这些人请出团队，他们会将负面的情绪带到项目中，进而影响整个项目。敏捷软件开发需要团队成员高度自治，团队中的每个人需要有一颗积极向上，并且努力提高自己的心。

专职的scrum master

这个主要针对scrum这种敏捷形式。我们采用scrum开发模式，scrum master是一个非常重要的角色。在实际项目中，往往由于经费问题，很可能是开发人员担任这个角色。scrum master在项目中起到润滑和串联作用，他架起产品和开发之间的桥梁。他还需要帮助团队发现问题以及促进团队成员提高自己。所以这个角色身上有很多的事情要做。一个敏捷团队中最好能有这么一个专职的人可以承担起这个角色。

每个团队由于现实的原因，各有各的不同。在我们实际落地敏捷开发的过程中一定要根据团队成员的不同采用适合自己团队的方式。敏捷理论以及相关的方法并不复杂，复杂的是我们团队成员本身。如果我们团队中的每个人都保持开发的态度，并且有一颗积极向上的心，我相信不论用什么方法论都能将项目做好。