选敏捷试点团队就像谈恋爱，最怕遇到“吴秀波”，会坐牢滴！

挑选试点团队，就像选择恋爱对象：

感情要专一投入（项目规模），

持续时间不宜长（项目持续时间），

态度要非常端正（项目重要性要高），

介绍人的推荐力度要有保证（发起人的保证）。

编辑 Ⅰ小π姐姐

来源 Ⅰ Scrum敏捷软件开发

小A是一家敏捷咨询公司的商务，两年来陪同教练参与敏捷项目的招标，去客户现场学习等，小A对不同客户关注的问题已经有了一些总结。

有一天从客户答标回来，小A和教练聊天：我发现几乎每个客户都在问，如何挑选试点团队。这个问题好像很简单，具体操作时又好像有许多考虑，您有什么好的回答吗？ 

教练微微一笑，手机搜了搜，递给她：“吴秀波的事儿知道了吧，参透了自然就懂”。

划定潜在对象范围——

如何选择试点项目 

选择试点项目实施Scrum到底有什么含义？

试点项目承担着为后续项目提供指导的任务，它是对新的做事方法进行试点。 

即试点项目是引导做事的方法，而不是进行某种试验。谈恋爱是一段感情的真心投入，而不是进行爱情买卖。 

不是每个项目都适合做Scrum试点项目，理想的试点项目要综合考虑多方面因素：项目规模，项目持续时间，项目重要性和发起人的投入程度等。 

然而，完美的爱人是不存在的， “完美”的试点项目也几乎不可能存在，所以，综合目前存在的项目，从以下四个因素中做出利弊权衡，或许是你的最好选择：

项目持续时间

时间不宜过短，否则容易会让员工产生一种误解“Scrum只适用于短小的项目”。 

而持续时间过长，又将面临着到项目结束时才能告知项目的风险。

选择的最好持续时间，一般来说是企业内项目普通持续时间一半左右的项目，大概为3-4个月。

这样不仅能够保证项目拥有足够的时间展示出Scrum带来的好处，而且3-4个月的项目也足以证明Scrum可以在更长周期的项目中获得类似的成功。

规模

尽量选择只有一个团队的项目作为开始，而且要让团队的所有成员坐在一起工作。 

即使这个试点项目会壮大到多个团队，也要选择从一个团队开始；即使有很多团队数量超过5个的项目，也尽量不要选择可以壮大到5个或者更多团队的试点项目。 

这样做的好处是，不仅可以节省团队间的沟通成本，若以持续时间为3-4个月来开展项目，那么这个时间段很少会让团队从1个壮大到5个。

重要性

如果我选择了一个特别重要的项目作为试点，那岂不是所有人的眼光都盯着我，我们如果失败了多难堪啊！

所以我们还是选择一个低重要性和低风险的项目吧，即使进展不顺利，也损失不大嘛。

NO！

一旦团队成员都知道这个项目没那么重要了，

会不会觉得每日站会是累赘呢？

为什么一定要每日都开呢？

可不可以隔日站会？

有这个必要吗？ 

这些必需的仪式他们都会产生怀疑，究其根本，他们想的是：这个项目本来就不那么重要嘛。 

所以，请选择重要性高的项目，不重要的项目是无法获得公司其他人必要的关注。

发起人的保证

这就联系到我们上一篇文章《我们正在转型敏捷，领导说他忙没时间参与，我们怎么办?》，拥有一名有时间和意愿与团队一起工作的发起人是非常重要的。 

在团队需要推动，或是改变那些不易改变的业务流程、部门或个体时，一位积极投入的发起人很有帮助。

他可以帮助你调动需要的资源，而且当他看到项目的收益时，他能够借助他的影响力，向其他更多的人宣扬项目的成功。

试想，A总监告诉B总监：我们最近尝试Scrum的那个项目比过去交付速度快了不只一倍耶，而且加班的恶性循环明显好转很多。

B总监听到以后想不想尝试用一下Scrum呢？即使不马上用，他也会去了解一下Scrum到底是什么。 

而Scrum作为一套成熟的体系，已经拥有足够的数据证明它是有效的，那么我们在实施Scrum时，需要关注的重点应该是：如何在自己的企业内有效应用Scrum，因地制宜，创造成果。 

选择合适的项目作为试点是有挑战性的，而人作为项目中非常重要的因素，使得选择合适的团队成员更富有挑战。 

勾勒恋爱对象标准——

如何挑选试点团队成员 

这里就涉及到一个问题：如果我们可以将选择项目和选择团队两件事独立开来，这将是完美的组合。

即我们先选择一个最好的项目，然后看看需要配备哪些人，再四处寻找合适的人组建一个优秀的团队，让对的人干对的事情，完美！ 

听起来固然是好，大家也能猜出来，这样操作的话，需要面对的困难不会少：

比如你选择研发人员A，他很优秀，他在之前和你合作的某个项目中表现特别好，然而如果他现在转入试点团队，他手上正好有两个同样需要他的项目，他现在的团队如果换掉他对交付周期或者质量会有担忧，怎么办？和他的团队领导去理论？ 

诸如此类的难点还有很多，企业里面人多事多，很容易牵一发而动全身。 

一般来说，选定项目时就已经定下了这个项目目前所在的团队。

项目和团队的选择相辅相成。 

在团队的选择中，我们关注成员间的融合度，他们有没有建设性的辩论，学习和适应方面的主观意愿与能力，他们的技术能力，沟通能力等等。 

最关键的是：团队中的成员尝试新事物的主观意愿有多强。

比如： 

高举Scum旗帜者：他告诉别人Scrum很棒，鼓励大家用Scrum，推崇Scrum的好处，他相信这个项目使用Scrum会成功。

那么，邀请他到团队来吧，这样的人参与到团队，对Scrum的实施有积极的效应。 

积极的乐观者：他也听过敏捷，听过Scrum，但是没有很积极地推动过团队要使用Scrum。

现在知道自己的团队要实施Scrum了，他们是抱有希望的，刚好尝试一下这个传说中的Scrum。

不反对，愿意参与，挺好的！ 

曾经怀疑过Scrum的人：他见过尝试新方法浪费时间浪费金钱又没有很大效用的情形，他对Scrum不了解，持有怀疑的态度，但他又确实是一位谨慎，公正的工作者，邀请他进入试点团队吧，因为一旦这类人群亲身体验过了Scrum的好处后，他会更富有热情，更坚定地宣传，支持Scrum。 

选择人员很重要，事实上，我们目前选择团队主要可总结为这两种情况：

你找一个现有的完整团队成为试点项目团队；或者你将曾经合作愉快的小伙伴们聚在一起，重新开始一段光辉岁月。 

失恋了怎么办？——

试点如果不成功怎么办 

我根据标准选择了项目和团队，我做了所有的计划，我们辛勤工作了三个月，然而，我们的项目还是失败了，怎么办？ 

你是将所有希望都放在一个重要的试点项目上？

不不不，多做几个试点项目。

并且牢记试点项目的意图是：阐明Scrum项目应遵循的方式。

最成功的试点项目其实是提供两种形式的建议：做这些，不做那些。

只要参与试点项目的团队能够学习到什么是可能有效的，或者无效的，Scrum的哪些方面更容易被引入公司，企业有哪些具体的阻力类型和来源，或其他类似的信息，我们就不应该说这个试点项目失败了。 

可是试点项目确实无法如期地交付成果，怎么办? 

遇到这种情况，我们首先要做的是对项目的期望进行评估，期望是否现实。

可能项目开始前我们的约定是这样，结束时发现不是那么回事了，发生这样的情况时，将期望与所有的项目干系人沟通清楚，当然，不要把这个作为项目不能交付的借口。  

如何设定一个合理的期望，又如何管理这个期望，这是一个很大的学问。 

还有一类情况，将试点Scrum的项目与设想中如果此项目按照瀑布的执行进行比较。

瀑布中可能有一份完美的计划书，你会说：我们就是用瀑布也和现在的完成时间差不多的，而且还会有更详尽的设计和长时间更好的维护。 

NO NO NO！

请不要允许将实际项目和虚构项目进行比较。 

小结

恋爱有多甜的蜜，就存在多大的风险，选择试点团队或许不会让你堕胎，也不会让你坐牢，但，也不容许你：不主动，不拒绝，不负责！