敏捷开发中的一些教训和感悟

工作一年多了，所在的公司采用敏捷开发。作为小团队里一名普通的开发者， 既体会到了敏捷的优点，也收获了很多经验教训。在此记录一下自己地感悟，如果有朝一日自己去领导一个敏捷开发团队，要尽量想办法避免和解决这些问题。

背景介绍：

公司的开发进度是大概每5－7周发布一个小版本，这里面包括了1周的各种测试时间和1周的上过渡服务器的时间，所以实际上code freeze一般是每个开发周期开始后的3－5周。本人所在的小团队大约有5到6名开发，其中包括一名Team Leader，4名QA。 团队也有一名PM, 但是远在美国，一年见面沟通时间不足一个月。公司采用JIRA作为项目管理和追踪的系统。每个开发周期会有很多Feature, 通常是每个Feature由一名开发负责coding，一名QA负责测试，而每名开发和QA会负责多个Feature. 某些非常大的Feature, 会由多名开发和QA组成一个更小的团队共同开发。

Feature的复杂度和开发时间评估

在我加入公司的前半年，正好团队在进行人事调整，除了Team Leader外，其他开发人员对每个Feature几乎都没有背景知识，更无从评估复杂度和所需时间, 所以所有Feature的评估几乎都依赖于Team Leader一人。Team Leader经常性地估少了Feature所需时间（或者高估了开发的能力），过分乐观的结果是开发和测试人员经常性地加班或者赶工，背负了过多的压力。另一方面，因为开发时间的仓促，也导致了Feature质量不高。

在后半年，由于Team Leader管理能力地提升，团队成员逐渐了解自己负责的各个模块，加上团队成员对之前评估不准确的种种抱怨，在Feature评估上有了一些改善。在每个开发周期开始前的例会上，Team Leader会和开发人员一个个地过这些Feature, 开发人员如果认为评估时间不准确，会给出自己的意见，然后Team Leader再跟高层管理者沟通，进行Feature的调整。个人认为，这件事情说明高质量高效率的敏捷开发对Team Leader和团队成员的个人能力要求很高，并不是一个低门槛的开发方式。

与PM的沟通

团队的PO (Product Owner) 职责主要由 PM 来担任。我记得以前在看敏捷开发的一些成功经验时，其中很重要的一条是说PO要和团队天天在一起工作。但公司的情况是，PM都在美国，虽然会通过邮件甚至skype来联络，但是总有时间上的延迟以及沟通上的误会和信息的缺失。对于一些小Feature还没有太大的影响，但是本人亲身经历了2个需求复杂，工程量和时间跨度巨大的Feature, 无法和PM在一起工作就带来了各种个样的问题。有一次，按照需求文档花了2周时间做完的部分，在和PM电话讨论时被告知文档写错了，因而对底层代码又花了1周时间进行了大换血，浪费了宝贵的时间。更经常的场景是，因为无法实时地面对面地与PM沟通，当Feature大体完工后，PM会对各种细节给出超过20个修改意见，又是本可避免的巨大的时间开销。 个人曾经非常希望在做其中一个大型Feature的时候去美国与PM一起工作，不过公司似乎完全没有考虑过，所以只能咬牙坚持。不过如果以后自己做事情的话，一定会尽量避免这种“异地”问题。

团队激励与士气

这是所在团队最严重的问题之一。管理者没有做出足够的努力去了解每个团队成员，很少进行team building之类的活动（一年好像只有2次），更没有采用任何有效的激励方式，直接造成了一些成员没有积极性、情绪低落，甚至对工作完全失去兴趣。所表现出来的就是产品质量低、效率差、不稳定。如果我是管理者，哪怕自己掏钱，也要隔一小段时间就带其他成员去吃饭喝酒谈心，去了解他们的想法和情绪，然后在工作中做出适当调整。如果有条件，更会给予优秀者丰厚的激励，给非常不上进的人严厉地处罚，保持团队士气向上。

个人英雄主义完全不可取？

几乎每个公司都在说要注重团队合作，杜绝个人英雄主义，但本人的实践感悟是，普通情况下团队合作是对的，但是在一些时间紧、项目大的场景，个人英雄主义可能更能带来更好的结果。从最后一个季度，我主要做了两个大项目。第一个用时一个开发周期，只有我一个人负责。第二个用时3个周期，第一个周期主要我一个人，第二个周期4个开发人员，第三个开发周期还在进行中。因为第一个项目和第二个项目的第一个周期基本上就我一人，所以不存在什么‘不同意见’的情况，都是我自己思考和做决定。虽然也会犯错误，但是都能保证在最短的时间完成最多的Feature，同时保证系统的performance和stability维持在一个高标准上。

问题就出在第二个项目的第二个开发周期，这时候其他几位成员陆续进入共同开发，本以为能为我分担很多工作，让我更专心攻坚一些框架上的问题。结果由于大家在一些问题上的见解非常不一致，同时因为我没有任何权力和资历去做任何决定，所以造成了在很多问题上无休止地争吵，以及一些实现上地互相妥协和返工，完全打乱了我自己的计划和节奏。就个人标准而言，对第二阶段的产品非常不满意，在accuracy, performance, stability上都远没有达到我的预期。思考良久，觉得如果当初让我主做这个项目时，赋予我一票决定权、一票否定权，然后给每个人的工作职责一个非常明确的划分，不允许大家越界干扰其他人的工作，只可以定义‘接口‘来沟通，相信会比现在有一个更好的结果。

一言堂固然不可取，但过度Team Work有时带来的更是负面作用，不仅耽误了时间和进度，同时使产品因为各人不同的理念而变得四不像。其实敏捷开发很像打仗，因为要在有限时间和资源下攻取一个个阵地。这时，如果要派人带兵去作战，就一定要赋予这个人兵权，否则如果因大家意见不同而不听命，互相扯皮，甚至互相拖后腿的话，会陷入很尴尬的境地。