中小项目敏捷实践之六(关于团队)

**开发方法是一个系统工程，需要所有项目活动的相互配合。**

本心得是基于近两年两个中小项目(一个2000 Manday, 一个1500 Manday)的实践总结，希望能与大家一起探讨和进步。

- 每个团队成员都是项目所有者，促进团队和项目共同成长
- 培养团队的自组织性《硝烟中的Scrum和XP》
- 专家建议团队大小在6-9人《硝烟中的Scrum和XP》
- 保持团队一定的稳定性以形成Group Flow。
- 三个Part Time的团队成员不如一个Full Time的团队成员
- 关于团队组织类型
> 组件型(×)优点：每个成员都对特定组件熟悉。缺点：组件间的整合会耗费很多时间。
> 功能型(√)优点：每个成员都是特定功能的专家，责任明确。缺点：每个成员都需要学习不同的技术组件。
- 关于救火团队
> 成立于Bug过多时
> 解散于Bug解决后
> 保护团队成员专心做事，免受干扰
- 测试团队应尽早入驻团队(项目总结)
- 测试团队应独立于开发团队《硝烟中的Scrum和XP》
- 测试团队应是敏捷团队的一部分

关于项目所有者和项目责任人

这里，暂且不高谈阔论团队的定义，单从为什么会形成团队来说明。

当前的软件环境已经很少会发生那种个人英雄的事了，软件变得越来越大，周期越来越长，需要的知识越来越多，所以就需要将不同知识的人力组织在一起，同心协力完成那些大型的系统。

注意，是同心协力，而不是各怀鬼胎。

相信各位程序猿朋友已经看到太多创业失败的故事，在创业开始时，各个创始人能够竭尽所能、互帮有无、同心协力地去完成既定的目标，他们每个人都是项目的所有者，每个人都向着同一个方向发力。就向下面这张图一样。这也就是Group Flow形成时个美丽场景。



但在创业到达一定程度或一定时期后，项目的目标越来越分散，考虑的事情也越来越多，如利益、权力等等。项目成员就会变成下面这样，你说能不失败吗？



相信各位程序猿朋友的公司里应该或多或少地发现上面的情况。

那么，我们如何才能做到让团队同心协力、互帮有无地去完成项目呢？

作者程序猿觉得，下面是最重要的两点。

1、每位程序猿都是项目的主人。（主人翁意识）
2、每位程序猿都有明确的职责。（责任感）

关于项目所有者

只有当每位程序猿都是项目的主人时，每位程序猿才会像初期的创业项目成员一样竭尽所能地确保项目的成功。那么，在公司环境下，怎样才能让程序猿朋友愿意翻身做主人呢？项目奖金？工作绩效？作者程序猿觉得这些都很重要，但不是最最重要的。各位程序猿朋友试想一下，各位的职业生涯中，什么时刻是最快乐的？升职？No！加薪？No！抱得美人归？这个还没机会尝试，暂且不论。以作者程序猿的经验来看，一定是项目成功的时刻！是荣誉来临的时候！这时候，各级老板对项目的赞美，就如同自己的儿子被人赞美一样，是一种骄傲！是一种自豪！

作为项目经理，这时候千万要敞开胸怀，并记住和大声说出来，这是大家的成功，而不只是项目经理或某些核心成员的成功，这是整个团队的成功！

如果更进一步来说，团队对项目成功的追求，一定也伴随着对美的追求。

每一个成功的项目都是美丽的。每一个好的设计都是美丽的。每一段好的代码都是美丽的。每一个好的流程都是美丽的。每一次良好的沟通都是美丽的。如果是以美为目标，还有什么困难不能克服，还有什么辛苦不能承受？这就是艺术！

关于项目责任人

既然每个程序猿都是项目的主人，那么自然要承担相应的责任。并且是明确的责任。例如某一个特定的功能点一定有一个唯一的所有者和责任人。那么，当产生和这个功能点相关的问题时，团队就可以找到相应的程序猿，以寻求他的帮助。这样，扯皮的事就不会在团队里发生。

所以，在可能的情况下，应当尽量组织功能型的团队，而不是组件型的。因为组件型的团队需要更多的沟通和合作，也不容易为每一个功能点设置唯一的所有者和责任人，也就更容易产生扯皮的事，尽管有时候并不是程序猿主观愿意的。

关于团队效率

毫无疑问，当程序猿专注于某一工作并免受打扰时，工作效率是最高的。既然如此，项目经理的一个重要职责就是“保护”团队成员免受打扰。所以尽量避免Part Time这种安排发生。对Part Time的程序猿来说，不但效率不能得到保证，责任感，归属者都是难以得到保证的。

而在一些万不得以的情况下，例如项目的Bug突然变多，或Support工作突然变多，以至于影响到了正常的开发，可以偿试建立“救火团队”，让这些救火队员在团队外建立起来个保护罩，以保护团队免受打扰。当“打扰”下降到了可接受的范围时，则可以解散救火团队了。

作者程序猿所定义的可接受范围是：功能所有者能应付那些Bug和Support工作，并且开发计划(Sprint)不受影响。