敏捷,准备好了吗?

对敏捷的错误认识、不正确的实施方法，都会造成实施的失败。那么，有哪些误区值得注意?

软件项目开发通常会遇到这样的困难：即使写入了合同，客户的需求总在变化，尤其是项目后期，使开发一再陷入被动；设计一再修改，跟最初的想法相去万里；加班加点终于完成可却不是客户想要的；历尽千辛万苦，软件最终通过验收，客户却把它束之高阁，根本没有实际上线运行……

如果你深受这些情形的困扰，而且想走出这些困境，敏捷就是最好的工具。

通过一系列独立而又相互联系的实践，敏捷可改善代码质量，提高软件交付的成功率。然而敏捷并非“拿来就用，用之就行”的万能工具。对敏捷的错误认识、不正确的实施方法，都会造成实施的失败。

面对敏捷，应该持一种什么样的心态?你觉得这是领导向你压下来的任务，你不过是完成任务而已?或者你认为敏捷只不过是另外一种形式的CMMI?抱有这种敷衍了事、甚至反对的心态，敏捷成功的可能性很低。

敏捷，让我们起步

你可能对敏捷的基础知识有所了解。不过在实施前，还有一些问题你可能会遇到。错误的选择，会使你遇到更大的阻力，带来高风险。

自上而下还是自下而上?顾名思义，自上而下指的是由公司高层发起，逐步向下推进实施敏捷的过程。因为能够得到公司高层各种资源的支持，你对团队所做的各种改革遇到的阻力会较小，成功的几率也较高。

而自下而上是指由员工发起，再逐渐影响上层实施敏捷的一种方法。这种方法只能从一些小的实践开始，收到良好的效果之后，再逐渐说服上级实施更广范围的敏捷。我们强烈建议您采用自上而下的方法，所以，先说服你的领导吧。

小团队开始还是大团队开始?初次实施敏捷，我们建议从小团队开始。因为小团队的交流更简单，更容易在许多问题上取得一致。而且敏捷中的许多实践，都曾经强调了自己合适于小型团队。所以首先在小团队尝试敏捷，让每个人都熟悉了敏捷实践，让每个敏捷实践都成为习惯之后，再考虑大型团队、甚至分布式团队的敏捷实施。大型团队和分布式团队的敏捷，会遇到跨小组交流不便、时差问题、甚至语言不同等多个问题，这也是敏捷领域研究的活跃课题。

全面还是逐步改进?你可能很想立即把所有的敏捷实践用到团队中去，但一旦这么做，你会不断受到团队成员的质疑，为什么要这样呢?或有人直接反对：原来的方法已经很好了，为什么非要推倒重来呢?这给敏捷实施带来了很大的阻力。

敏捷强调自己是一种适应性的方法，你可以根据自己团队的实际情况，找出哪些方面的问题最严重，使用敏捷的方式替代。收到一定效果之后，再逐步采取其它的实践。这种逐渐改善、小步前进的方式，更容易受到团队成员的支持。

我们需要培训吗?关于培训，有两种截然不同的观点，一些人认为培训搞定一切。比如参加Scrum认证，通过2天的培训，拿到ScrumMaster证书，我们就可以敏捷了。这是部分初学者的误区，源于对敏捷的认识太少。事实上，敏捷社区对于Scrum认证也多有诟病。正确的实施来自于不断的实践。

另外一种观点认为培训毫无作用。其实这种观点也不正确。根据经验，一个新人加入到敏捷团队，在很短的时间内就可以适应敏捷的方法；而对敏捷一无所知的团队，实施敏捷困难最大。有了一定的实践经验，难免会遇到种种困难和疑惑，带着这些疑惑参加相关的培训，或在团队中引入经验丰富的敏捷实施专家，效果非常显著。

敏捷，在路上

你的团队已经开始实施敏捷，已经在采用每日站立会议、回顾会议这样的敏捷实践，也把需求划分解成用户故事，根据故事的业务价值迭代开发，但这其中仍然充满了种种陷阱，及时发现这些陷阱可以避免许多不必要的损失。

不要让敏捷实践成为形式。拿每日站立会议来说，这是一个简单易学的敏捷实践。但曾有人提出，我们的团队每天早晨开站立会议，但不久大家感觉无聊且烦人，因为成了每天向PM报告工作的例行公事，这种形式为上的实践，还需要吗?

每日站立会议的主要目的是使每个人知晓项目的最新进展，分享已有的成就，提出自己遇到的困难以寻求解决。如果觉得形式重复无聊，可以想一些点子使每日站立会议更有趣味。曾有一个团队是这样做的：不要讲那些重复、无趣的话题，如果有人觉得内容无聊，可以随时举手。超过3个人举手，发言者必须转换话题或干脆取消发言。其实敏捷有个重要的实践，回顾会议。大家可以在回顾会议上把这个问题提出来，没准能找到更好的解决办法。

依赖整个团队而不是一两个关键人。在估计用户故事点数时，找一两个技术骨干估计就行了吗?或者有些问题需要决定，PM或者团队负责人直接拍板?敏捷强调发挥每个人的主观能动性。估计用户故事点数时，让所有开发人员参加。一些需要决策的问题，也让团队成员一块参与。这些看似不起眼的地方，能让团队成员感觉到自己参与其中而不是被置之不理，并逐渐形成正向的激励，能进一步激发每个团队成员更大的潜能。

Scrum和极限编程并重。Serum是最近敏捷社区讨论的热点，很多团队使用敏捷时就是在使用Serum。造成这种问题的原因在于Scrum是项目管理相关的，很容易被负责人接受，而极限编程相关的实践是与编程相关的实践，容易遭到忽视。

极限编程的实践如结对编程、测试驱动开发、持续集成等，可以大大提高代码质量，减少项目集成的风险。考虑到Scrum支持迭代开发，不同迭代逐渐增加功能，同时敏捷拥抱变化，功能变化务必会修改代码。如果没有自动化的测试做保障，难免会对已有的功能造成影响。所以极限编程是敏捷实践中必不可少的部分。

如何坚持测试驱动开发等比较难的实践?与每日站立会议相比，测试驱动开发这样的实践并不是很好坚持，很多团队实行了一段时间就放弃了。

根据调查，造成难以坚持的原因有不少：没人指导，靠自己摸索比较困难；即使有了相关培训，培训的例子与实际应用差别很大，项目进度有压力，必须抓紧时间写代码……面对这样的困难，测试驱动开发仍然需要坚持。可以从其它团队找一些经验丰富的人指导，团队内部也必须不断提醒坚持。

充分发挥BA和客户的作用。与传统软件开发的瀑布模型相比，BA或客户不再是写完需求说明书就万事大吉，开发人员也不是只拿需求说明书照本宣科。

BA或客户应该与开发人员时刻保持联系：开发人员从backlog中拿到一个新的故事时，先阅读故事描述和验收条件，最好能让BA或者客户进行讲解。因为BA或客户对项目的整体理解更为深刻，开发人员一旦理解有所偏差，可以立即发现。

用户故事开发完成，要先让BA或客户现场验收。现场验收，不需专门部署验收环境，也不需准备复杂的测试用例，可以就在开发现场简单快速的进行。一旦发现没有完成的验收条件，开发人员立即修改。这种验收的时间很短，一般5到15分钟之内就能解决。把它与QA的测试结合起来，具有良好的效果。

另外每个sprint迭代周期结束后要向用户演示，现场听取客户最直接的意见，看做出来的软件是否他们真正需要的，及哪些需要做出修改。此时的反馈可以尽早发现问题，避免你在岔路上越走越远。

敏捷，我们成功了吗

你已经使用敏捷开发了―个项目，怎样判断是否成功了?除了软件成功交付这样的指标，还有什么其它条件吗?你需要看你的团队是否成长为了一个成功的敏捷团队。

一个成功的敏捷团队，是一个可持续发展的有自管理能力的团队，具有很高的项目交付能力。

软件项目开发的最终结果，可实现客户、公司和团队三者的互赢：客户因可运行的软件而获益；公司因项目成功交付而获利；团队成员则可以不断学习而进步。一个成功的敏捷团队，可以让每个队员有自豪感和归宿感，体会到项目成功带来的喜悦。

上面提到的问题，是敏捷实施尤其是初次实施容易遇到的问题。你在敏捷开发过程中是否遇到过呢?如果这些问题曾对你产生了困扰，希望上面的回答能有所帮助。