我眼中的敏捷团队

从2000年在美国工作的时候，就开始知道敏捷开发流程，随着后来自己开始管理技术团队，对敏捷开发的理解也越来越透彻了。

敏捷开发其实就是软件开发流程当中的特种部队，以前的战争讲求兵力的多少，武器的多少，而现代战争更加强调小规模性和快速应变能力。以前的软件开发模式，设计阶段需要写很多文档，文档写好了，发现需求可能又变了，然后又去修改文档，大量的精力花费在文档上面，开发进度很慢。设计阶段，文档劳动量很大，开发和测试很闲，到了后期，产品经理又变得清闲，开发和测试很忙，而且产品,开发和测试3者之间的沟通成本很高。有的人玩笑说，当需求设计好，开发到一半，发现需求过时啦，白开发了。

前几年开始，敏捷开发在国内流行起来，于是出现了很多的敏捷培训师，传授敏捷开发流程技术。如果团队的单兵技术不行，硬要上敏捷开发，就和教一帮新兵蛋子特种部队战法似的。我们知道特种部队的人员来源一般都是来自普通部队的老兵，可见特种部队的成功是和单兵素质分不开的。

个人认为，能够成功实现敏捷开发，并且在高速开发中能够保证产品质量的团队，必须具有下面的特质：

1.    优秀的团队领导，他是团队的灵魂人物，就和一个冠军球队需要一个灵魂人物一样，他是整个团队的粘合剂，需要有跨界的综合性能力。

他必须懂业务，我们知道软件是为业务服务的，不懂业务搞软件就是耍流氓，当然不一定是最精通业务的那个，但必须有很强的沟通能力，能够通过和业务专家交流，迅速理解业务，并且有能力发现业务当中存在的问题，及时和业务专家反馈交流，在业务方面对业务专家是个协助作用。其实，因为他是跨界的，有时候能够有很多新发现，业务专家都可能没有想到，这也表现为卓越的学习能力。

全面的技术能力，因为需要统一规划设计整个软件系统，很多大型软件系统，需要涉及到很多技术领域，如安卓开发，IOS开发，WEB开发，后台开发，数据库和运维等等，当然这些技术不一定是团队里面最强的，但很多时候，不同角度的思维可能会更有效的解决问题。本人对运维技术也是有涉猎的，对于LINUX命令，我不如公司的运维熟练，安装监控工具，远不如他熟练，但有一次他安装JAVA服务器，怎么也搞不好，我帮他一下子解决了，因为他没有编程经验，JAVA的异常日志看不懂，对我来说这是很简单的事情，看了异常日志，我就找到问题原因了。因为有全面的技术能力，在设计软件的时候，就能考虑的更全面。其实很多问题都会出在接口的上面，因为技术全面，这些接口上面的问题都可以被及时发现，可能在设计阶段就发现了，根本不需要到测试阶段才发现。

放权的能力，诸葛亮是一个非常伟大的军事家，但他致命的弱点就是不能放权，所以自己搞的很累，团队管理的艺术在于知人善任。我看到打着放权旗号，其实是很昏庸的管理者，底下烂成一团了，自己都不知道，而且把权利放给错误的人，搞得团队是小人得志的气氛。放权能力和管理者自身的全面能力分不开的，因为能力强，他才能识别团队当中的英才，并给予重任。我一直认为很多时候一个公司技术团队领导人的高度，决定了一个公司技术的高度。我的一个朋友跟我讲，他们公司CTO水平很一般，但是就是不招水平高的人，因为他怕水平高的人来了挤走他，这让我想到了水泊梁山的那个王伦，当然也有大度的可以接纳良才的，一般这样的人都是公司重要股东，他自己不担心有被边缘化的忧虑。

选拔和培训属下的能力，这也是诸葛亮的一个巨大的弱点。团队管理者必须把招聘当一个大事来抓，团队质量的源头需要把好关，发现有潜力的人，能够激励他们，培养他们，而且需要有能力营造一个大家学习技术的氛围，让大家感觉到来到这个团队不光光挣了钱，还学到了很多东西。通过团队技术交流，大家可以充分了解对方的长处，在团队协作过程当中，可以更加密切，也可以同时发现自己的不足，进行提升。当然这个学习气氛建立的前提是，你的团队成员是有强烈学习欲望的，我也遇到很多程序员是不思进取的，做程序完成就行，不管完成的质量和效率。作为团队领导人，需要在招聘环节就发现这种人，对已经在团队里面的成员也需要通过代码审核，日常技术会议，发现那些人积极上进，那些人安于现状，通过制度设计来激励大家，如果实在不行的，就请出团队，让其另谋高就。优秀的团队领导是允许属下探索犯错的，如果不给他们犯错的机会，你的团队成员就不会成长和学会独立思考，但这种错误必须是可控范围之内的，不能给团队造成重大的损失，这也就是一个平衡的艺术，需要做到恰到好处。

优秀的沟通协调能力，很多时候，在任务安排上面，一个功能调整，哪方需要调整来适应对方，大家都希望自己省事，希望对方调整，这时候就需要团队领导从全局平衡出发，找到有利于产品长期发展的解决方案，对需要调整的一方讲清楚利害关系。

优秀的产品架构能力，能够想得很细，想得很远，尤其一个大型软件产品，是需要考虑长远持续发展能力的，不能因为赶进度只顾眼前利益，当然也需要合理安排轻重缓急，平衡好产品开发时间和业务的关系，产品可以规划好，业务紧急需求的可以优先开发，不急的可以延后开发。在看电视剧《戚继光》的时候，我知道了戚继光算定战这个思想，大仗之前，这场战役在他的头脑里面已经打了无数次了，当开始打的时候，已经是胸有成竹了。

2.    具有产品思维和测试思维的开发人员，具有良好的沟通能力，良好的代码风格和做事习惯，有强的产品主人翁意识，追求完美意识，懂得合理安排和规划时间，有良好的学习主动性，喜欢看技术论坛，喜欢记录技术心得。

传统的开发团队，开发人员只负责按照文档进行开发，具体为啥这样做，这样做好不好，都不需要管，在合作当中是一个被动的角色，这样就需要产品经理把文档写的很细，什么类图，时序图，验证条件说明等等，一堆东西。我们团队最初推行敏捷开发的时候，按照敏捷理论，减少文档，结果IOS和安卓团队理解完全不同，做出的东西不一样。一个公司的产品，安卓版和IOS版本有明显不同，这是不允许的。其实减少文档的前提，是开发能够从被动角色转变为主动角色，需要具备产品的思维，即使文档简单，也能够理解产品的意图。特种部队协同作战的时候，我们看到他们常常使用手语，非常简洁高效，但使用手语是建立在团队成员互相了解，能够密切配合的基础上面的，这种配合已经变成了一种习惯，一种本能。开发团队具有产品思维，可以把这种沟通变得简洁高效，而且开发可以帮助产品发现错误，形成互补关系，错误如果在设计阶段被发现，可以节省很多的成本。没有产品思维的开发人员，需要更多的沟通时间，你告诉他做1,2,3,4,5，好的可能把5个都做了，差的可能就把2,4落下了，因为他没有能够真正理解产品设计的意图。没有产品思维的开发人员，在敏捷团队里面会成为猪队友。

我发现很多开发人员认为测试是测试团队的事情，开发只管写代码，开发团队为了赶进度，不重视质量，测试团队发现一大堆BUG，然后又退回给开发，测试指出一个问题，开发修改一个，完全是被动角色。其实软件开发理论里面有单元测试和白盒测试，但我看到国内绝大多数团队，都不做单元测试，很多工作好几年的面试者，都不知道单元测试是什么东西。作为创业公司，我们团队很难招聘到优秀的开发人员，即使经过精挑细选的人员进入公司，也不知道怎么做单元测试。虽然我想培训大家做单元测试，但是任务多多，大家根本没有时间学习这个，其实很多时候，国内的商业大环境就是这样。个人认为，国内可能也只是超一流的公司这样做吧。但本人认为，单元测试可以不做，但测试的思想必须是有的。很多程序员在做表单的时候，根本不去考虑验证的事情，表单验证这个可以简单也可以复杂，详细的验证和提示，可以给用户很好的体验，而且降低后台出错的概率，当然后台自己的验证也是需要的，防止有人使用工具进行提交，绕开前端验证。很多安全事件，都是因为开发者没有测试思想导致的，开发者根本不知道SQL注入是什么，认为程序只会按照你设定的路径运行。其实一个软件当中，90%的代码，我们都是在防止程序错误运行，如果什么东西都能按照我们设定的路线走，这个世界就变得很美好啦，飞机就不会掉下来啦。微软要求开发人员做开发之前，做2年测试工作，敏捷开发要求开发者编码之前，要想好怎么测试程序。国内我听到这样一个故事，毕业学生去面试，能力不强，做不了开发，那么去做测试吧，测试被当做了一个低端的活儿。据说淘宝测试总监薪水有100多万，测试是很具有技术含量的，而且现在的自动化测试趋势，更需要测试和开发的融合。实际上一个优秀的开发人员，不但可以做好开发，也可以做好测试，优秀的开发人员把程序交给测试的时候，明显的错误就已经没有了，测试团队只是对他工作的检验和补充，协助他发现一些难发现的错误。当测试发现了错误，作为开发者，需要思考发生的原因，并且能够发现同类型的问题，这些问题，测试可能还没有发现。

不当的异常处理方式，没有命名规则，变量太多，命名不清晰，不注意作用域，大段大段的IF-ELSE循环嵌套，导致代码可读写极差。这样的代码就像一堆胡乱堆放的麻绳，很难让人清晰的看到来龙去脉，代码的最高境界不是把代码做复杂，而且使用简单的方法解决问题，大道至简，清晰有条理的代码，自己和他人都容易发现问题，代码风格其实代表了一个程序员的思维方式。

主人翁意识在团队协作当中非常非常重要，和其他团队成员做对接的时候，需要对对方的工作进行检查，因为任何人都会犯错误，这种二次核查对于减少BUG是很有必要的，而且发现问题应该及时反映出来进行讨论解决，而不是抱着反正不是我的错的思想，是产品让我这样做的，做错了也不是我的事情，协助团队成员进行核查其实就是一种追求完美的表现，只有在这种相互协助相互督促相互帮助的环境下，产品质量和开发效率才会不断提升。

很多程序员都遇到过同时有多个任务在手的情况，合理安排时间，合理安排轻重缓急，就显得非常重要。对于一个敏捷团队这个能力非常重要，敏捷团队成员不应该不知道自己该做什么，需要能够在几个任务自由切换，如果主要任务因为他人情况停顿了，可以利用这个时间做其它次要的任务，敏捷团队成员应该是一个多任务操作系统，知道合理的安排时间片，及时的应答紧急任务，不急的时候做优先级低的事情，不应该出现突然忙得要死，又突然闲的要死的情况。开发任务不紧了，可以多学习学习，多写写工作总结，总结归纳自己工作当中那些需要做的更好的。有任务就是上阵杀敌，无任务就是刻苦练兵，拓展自己的技能宽度和深度。

没有学习主动性的人，是不可能成为一个敏捷队员的，敏捷队员需要掌握复合型技能，需要有向全栈工程师发展的勇气和决心，不想当将军的士兵不是好士兵。一个有学习主动性的人，只要你给他一个良好的环境，他就迅速成长为参天大树，反之，再多的机会和培训都是浪费。有学习主动性的人，会积极关注技术论坛，写自己的技术心得，把这当做自己生活和工作的一部分。

很多程序员都是宅男，不善于沟通，我听到很多取笑程序员不会沟通的笑话。善于沟通的产品经理和不善于沟通的程序员进行合作，确实会有很多误解和矛盾。一个善于沟通的程序员会从产品经理那里学习到产品思维，使他们的之间的沟通变得准确和高效，而且他更能帮助产品经理发现问题，在协助当中会从被动转向主动。善于沟通的程序员可以成为开发额中坚力量，帮助团队其他成员成长。善于沟通会大大提升开发的效率，把很多问题在开发之前就发现，大大降低开发成本。很多时候，我把任务交给下面开发的时候，我都希望他们能够讲讲他们打算怎么做的思路，但很多情况下，对方都是支支吾吾，说不清楚，我把我的思路讲给他，他也只是点头，没有啥问题，当代码完成我审核代码的时候，我发现很多问题，其实这些问题，如果当初他能够表达出来，我当时就会帮他纠正。因为不会沟通，问题只能在代码编写以后才能发现，又需要花时间去修改代码，来来回回时间就这样浪费了。编码的效率就在于你在编码之前能够想到多少问题，预见到的问题越多，代码质量就越高，代码反复修改的次数就越少。其实，善于沟通的程序员就是善于思考的程序员，你是用手写代码还是用脑写代码，最后就会体现在你的代码质量上面。小时候学下象棋，发现高手是不需要看着象棋来下的，程序员如果能够把自己的思路通过图和简单语言表达出来，就最终可以实现这种境界。

3.    团队成员在技能上面需要有一定广度，不能只有深度，尤其团队领导广度是必须具备的，其实在软件开发当中，很多问题都出现在接口部分，很多时候因为对接口理解的错误导致很多BUG出现。如果团队成员能够具备一定对方的知识，能够准确理解对方意图。