最近接触了一个正在运行传统瀑布式流程的开发团队，发现不管是开发人员还是项目经理都非常想运用敏捷开发的模式。可惜开发人员有想法，而项目经理并不真正了解敏捷。目前的结果是一团乱，不论是开发的效率还是沟通的有效度都很低。
本文仅记录一下个人对类似团队的建议。
信任团队
敏捷宣言价值观背后有十二条原则，其中有一条是这样写到的：
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
激发每个个体来完成项目。给予他们所需的环境和支持，并且信任他们能完成任务。
当我询问项目经理为什么这个团队不能使用敏捷开发时，得到的答复是：“我们的人员素质不行。”：
- 净做些与工作无关的事
- 推动项目进度很难
- 几个人盯一台电脑，浪费时间
但这几点其实在我的观察中，却变成了不错的敏捷实践：
- 团队会主动重构代码
- 团队会主动的安排工作的优先级
- 团队会结对编程
其实项目经理这几点看法无可厚非，首先说说「重构」，因为重构某种程度上可以理解为一种返工，这对瀑布式项目来说是走回头路，代价很大。开发团队适时的重构可以让后续的工作更轻松的开展，而项目经理经常会忽视这一点。
而「任务优先级」这件事上，传统的模式是项目经理去指派各项任务，这种方式有一些弊端：临时的任务太多，打断工作的连续性；如果任务之间有相互依赖性，项目经理指定的优先级将会失效。而Scrum这一敏捷实践中的“项目经理”——Scrum Master却承担着保护团队在迭代中免受干扰的责任，每个迭代的工作范围是相对固定的，并由团队自行挑选和承诺可交付的内容。
而多个资源做同一件事往往不是浪费时间，「结对编程」对于团队的互相学习和监督、任务的透明化、代码规范化以及增强凝聚力都有非常正向的作用。
组建「自组织」团队
敏捷开发团队是「自组织」的（self-organizing team），自组织的团队是平等的、主动的。很多人说要让团队达到自组织的状态很难，我也非常同意，人难免有惰性。作为一个敏捷的推广者或是项目的管理者，更要善于发现团队中每个个体的闪光点以及不足之处。上面所说的团队已经很有主动性了，而团队如果已经习惯了指令式的管理，主动性匮乏，管理者也可以通过以下几点来营造自组织的氛围：
-
让个体相信自己能在工作中充分发挥和实现价值
团队的目标是需要达成一致的，这没错，但是每个个体想要实现的价值通常不一样。优秀的管理者能让每个个体都发光发热，都有奔头，而不是让某一个或几个个体独占其功。很常见的一个例子就是不要让同一个人一直负责同一个模块，这不仅会让这个模块变得无法维护，也会竖起壁垒让其他成员无法靠近。
-
建立透明的、畅所欲言的沟通渠道
「开放」是Scrum的五个价值观之一，敏捷宣言也强调了「面对面沟通」的重要性。项目知识的透明是绝对必要的，没有对等的沟通，每个个体的工作频率就会搭不上。而畅所欲言的文化的前提是倾听的能力，别抹杀那些创意十足的想法。
-
**确保团队遵循平等的准则 **
自组织不等于无纪律，管理者要建立适当的团队共同遵守的准则。这里所说的团队包括管理者，所有项目的参与者应该是平等的，没有等级、职位的高低之分。如果站会时项目经理坐着翘二郎腿，那就失去站会的所有意义，变成汇报会了，效率之低可想而知。
敏捷没有固定的流程，更多的是一种文化和思想，要全面接纳敏捷，就慢慢从组建团队开始吧。
先写到这里，下一篇会介绍如何用工具减少不必要的工作。
