当敏捷开发正被世界各地的公司广泛采用的时候，仍有有许多团队，尚未从phased-and-gated的开发方式过渡到敏捷方式。正如伊丽莎白•亨德里克森说，一个敏捷的团队，它能够经常实现商业价值，每月至少一次，保持可持续的发展步伐。这给那些成功实现了敏捷开发团队的公司带来许多好处，但转型需要投资大量的时间，学习和训练。

　　我们从哪里开始敏捷开发团队？

　　目前，我们有几个框架，能够帮助一个团队转移到敏捷开发。 根据我的经验，Scrum提供一个很容易实现的框架。你可以决定明天开始你的第一天的第一个迭代周期，然后坚持一周，两周，做任何你想尝试的。举行冲刺计划会议，把故事和任务写在板上，开始一个冲刺燃尽图，选择一个时间举行每日立会。

　　实施框架很简单。其他框架如看板的使用也是一样的。最困难的部分，也是成功的关键，是学会成为一个自我组织的团队。这需要比你预期更多的时间。我们企业的利益相关者和客户希望现在就交付功能。我们如何平衡学习时间并让我们的客户满意？

　　不要承诺

　　我看到在新的敏捷团队里最常见的问题是，他们太急于向自己的管理层展现，敏捷是多么伟大的事务，他们对于年底能实现多少冲刺变得过于乐观。这不能阻止利益相关者的请求，“你不就是做了一个额外的小故事？”

　　在Clean Coder一书中，鲍勃•马丁解释说，作为一个团队成员不能对管理层的每一个要求都说“我会尽力”去满足那个不切实际的最后期限，或者说“再做一点点”。我们是团队成员，当我们接触到现实并且为我们能够交付的设置合理的期望时。并让我们诚实面对——即使我们在迭代周期结束时只发表了一个小的用户故事，这不也比他们在旧的开发过程中得到的多吗？

　　你需要花大量的时间来学习如何成为一个自我组织的团队，并且学习了许多新的实践方法，将让你的团队提供高质量的代码。如果你现在不建立这个基础，你将积累技术债务，并可能长期失败。如果你现在通过花时间学习和实践的方式来投资质量，你就将能够长时间做得更多。

　　在一个迭代周期里，通过故意计划安排比你觉得能够完成的工作更少的量来战胜你的自然乐观主义。推动更多的故事比告诉利益相关者，你不得不放弃一个故事来的更好。记住预算时间来完成每一个故事的所有测试活动，包括自动化回归测试和探索性测试。当你评估故事和计划任务的时候，请记住，包括重构和其他做法，来控制住你的技术债务。你可能需要写故事，以学习新的做法，尝试新的工具，或做减少技术债务工作。

　　我的团队计划是,只为几天保持忙碌的工作量。我们常常在“甲板”上计划有额外的故事，但我们不承诺完成。有趣的是，当我们从传统的Scrum“承诺”到这个过程时，我们的速度显著上升。

　　学习关于敏捷的知识

　　根据我的经验，一个团队需要一些核心的做法，以保持其技术债务的可管理性和长期成功。也许最重要的是一个简短的循环反馈。你需要知道在几分钟之内，一个新的代码录入是否破坏一部分代码。因此，你需要一个持续集成（CI）的过程，可以开始每一个代码的检查。编译代码，创建可部署软件，并运行自动化的回归测试。如果你的团队没有一个CI过程，马上停止你现在正在做的一切，并去取得一个。好消息是，这对于你的开发人员和系统管理员来说，是非常容易的。

　　所有的回归测试自动化是另一个核心实践。它开始与测试驱动开发和自动化单元测试和集成测试。应用程序的每个阶段的自动回归测试，包括应用程序接口（API）或服务水平和GUI水平，都是从建立和减缓肩负新功能来保持技术债务的重要组成部分。如果你不采取自动回归测试，你很快会背负沉重技术债务，你将不会有时间做重要的探索性测试，你的团队将会发现很难打破产生的死亡螺旋。

　　一个自我组织的团队检查和调整：回顾最近发生了什么事，并畅想将要来临的新实验的障碍以及如何提高。这对于一个团队来说，如何解决它自身内部的问题不是件容易的事。预算充足的时间，在你的敏捷过渡的头几个月，甚至你的第一年。

　　培训和指导敏捷团队

　　我谈到过的技能，是很难学习的。找到合适的人，能够为你的团队提供有用的培训。一个理想的解决方案是聘请一个永久雇员，他曾在成功的敏捷团队工作并且能够指导团队的其它成员。如果你决定聘请外面的教练或顾问，要知道，不管是谁，不管有没有才华，可以进来并“修理”你。这可以得到很好的帮助，但是你得找到一个愿意至少在很长一段时间经常回来并且帮助你的团队走上正轨的人。

　　预算充足的时间来学习。我目前的团队于2003年开始其敏捷的过渡，但我们仍然需要不断学习和提高。近日，从谷歌等公司得到启示，公司在每一个冲刺都实施一个“学习日”。每个冲刺的第一个星期五是每个团队成员尝试新工具，新技术的实验，了解我们域名的时间，不管我们觉得我们需不需要。这似乎昂贵，但它意味着我们能够更快的响应业务需求，并想方设法不断提高，缩短了从概念到兑现的周期。

　　实验

　　每一个迭代周期至少停下来做一次状态评估。你最大的障碍是什么？你的团队是否有不适合敏捷处方的成员？识别你最大的问题，并构思一个实验，这将使它更好一点。写一个故事或任务卡，以确保完成实验，并在下一次迭代周期进行结果评估。如果你问我团队的任何人，我的团队这些年我们改善如此之多的最大的一个原因，他们会告诉你，那是我们不断地回顾并做实验。

　　尽量设计小实验，并限制时间。在一次或两次迭代周期尝试一些新的做法或采取行动项目，然后花时间去评估它是如何工作的。如果它没有帮助，就构想另一个实验。以较小的增量和短迭代周期来解决你的问题，就像你写代码并测试它们一样。

　　仆人领袖

　　你的团队需要学习如何自我组织和解决自身问题。然而，你需要有人来帮助消除障碍，并干预团队直接控制范围之外的区域。Scrum主管，教练员和管理人员可以充当“仆人领袖”角色。有时需要一个管理者介入，例如，如果有一个个人问题，导致团队不能正常工作。Scrum主管填写Scrum框架模糊的中间部分，促进讨论，帮助解决冲突，并根据需要从顾客那里获取帮助或投入。其他框架中也有类似的仆人领导职位。

　　Scrum是简单的项目管理框架。你团队成功或失败取决于你的团队成员。是否允许他们做他们最好的工作吗？是否有人鼎立支持你？你的团队可能要作出一些艰难的决定——不是每个人都可以做到从传统无秩序的软件开发环境到敏捷团队的过渡。敏捷带来的透明度，不是每一个人都能承受的。

　　这是一个旅程

　　请记住，项目的成功或失败的根本不在于方法或工具。他们有合适的人，并被允许做最好的工作时，他们就成功了。

　　对你的团队学习新的和更好的方法来开发好的——甚至更好的，杰出的软件时，要有耐心。慢慢来。检查和不断适应。解决你最大的问题，并使其更好一点。参加本地用户组和联机邮件列表，以获取意见和支持。尽可能多的阅读。不要担心失败——他们是学习的经过，如果你怕他们，你将不会创新或成长。

　　我热爱我的工作，因为我很满意和一个杰出的团队一起工作，交付产品，其质量在每个迭代周期都一点一点不断的提高。让你的团队学会经常发表商业价值，而不要建立繁琐的技术债务，记得享受这段旅程。

　　您可以在Twitter通过@ SoftwareTestTT联系我们，并告诉我们您对这篇文章的看法。

　　注：

　　冲刺计划会(Sprint Planning Meeting)：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。

　　冲刺燃尽图(Burndown Chart)：在冲刺长度上显示所有剩余工作时间逐日递减的图，因整体上总是递减而得名。

　　每日立会(daily stand-up and go)：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。