敏捷开发团队管理.docx

《敏捷开发团队管理.docx》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、敏捷开发团队管理  作者：cheny_com 本系列会专门从团队管理的角度，一方面将曾经提到过的内容加以贯穿，另一方面则会提及之外的一些未提及的内容，比如产品团队与开发团队的互动，测试团队与开发团队的关系与工作方式，等等，以供专门从事团队管理的读者借鉴。出发点：结果导向敏捷开发团队的外在行为是“结果导向”，而内在支撑则是“团队工作”（TeamWork）。所谓结果导向，就是直指结果，而不拘泥于形式。可以被拘泥的“形式”各式各样，比如方式、方法、流程、文档、部门、分工、职责……都是形式。这些形式本来是设立来帮助实现更好的结果

2、的，但是如果拘泥于此，则可能起到反作用。如果仔细审视敏捷宣言中右侧的内容，就会发现他们都属于形式，而非结果：·个体与交互重于过程和工具·可用的软件重于完备的文档·客户协作重于合同谈判·响应变化重于遵循计划这些形式曾经保证了众多早期军工、航天、航空项目的成功，但若在任何行业任何项目——比如敏捷开发出现时的互联网行业——拘泥于此，就可能导致失败。可怕的是，左侧的4条，也是形式而非结果。所以对敏捷宣言的正确理解是：在现今的多数行业中，如果以结果导向为出发点，则左侧的形式胜过右侧的形式。支撑点：团队工作为什么说团队工作利于结果导

3、向的实现？有一个兄弟射雁的例子可以说明：三个兄弟看着大雁飞过，一个说要射下来烤着吃，一个说要炖着吃，另外一个则要炒着吃，三人争执不下，大雁都飞走了。比如有一个Bug，人们不去分析怎样改正怎样预防，而是讨论是谁的责任；比如有一个任务，人们不去分析怎样做最快，而是讨论应该谁做；比如有一个变更，人们不去分析变更前后甲乙方是否有利，而是讨论应该哪些部门走怎样的流程；比如有一个产品，人们不去分析怎样做才能成功，而是讨论成功后应该怎样考核……就很难直指结果，而陷入部门和个人的纷争之中。这里倒不是说后者不需要考虑，而是说出发点问题。如

4、果思考问题的第一念头是“我”“我们”“他”“他们”，那么团队协作就建立不起来，敏捷开发也做不好。本系列的内容本系列将涉及几种常见团队的关系问题：产品团队与开发团队，设计团队与编码团队，编码团队与测试团队……以及团队内部的工作方式。其间会引用几个以往见过的以及现在身在其中的团队的做法，并分析其应用的环境、潜在的风险。几个真实案例这几个团队都是我自己亲身经历的团队，从质量的角度来分析敏捷团队的工作方式。第一个是一个较为大型的团队，约有25～30人，研发一个单一产品。这个团队在一年半的时间里边，从5个人成长为25人，其中有一半

5、人员来自刚毕业不到半年的本科或硕士（在2001年，还很难找到“有10年经验的编程人员”）；在这个团队拥有25名成员的时候，只有1～2个测试人员。按一般的常理而言，这个产品应该面临很大的质量问题，因为这些新来者应该编写大量的缺陷，而测试人员又严重不足，不足以发现这些缺陷。但实际情况是，这个产品是我后来经历的所有大型团队中最好的一个，包括后来拥有众多测试人员的团队；此产品运行于CCTV，属于高度实时性和可靠性的产品；此产品在上市7年左右的时候占有市场的60%份额（之后数据不详）……第二团队个可以说是个团队，也可以说是个个人，

6、是我之后为某家军工企业开发的一个小软件。“无损检测系统”项目历时3.5个月，涉及步进电机、超声波扫描卡等各种软硬件，尽管就这么多人工，最后甲方说做了个“国内领先的无损检测系统”（只能说可见国内行业底子之差）。一个人开发，当然只能自己开发自己测试，但是质量却是有史以来最好的，整个项目的测试期只有几天，而交付后一年中客户没有发现过缺陷，只在更换硬件平台后发现一个水土不服的时序问题。这两个软件，是我自己亲自或近距离参与的项目中质量最好的两个，但奇怪的是他们都没有专业测试人员。编程人员的降低缺陷的方法这里先不分析编程人员与测试人

7、员的分工、合作问题，先看看编程人员除了被“测试”之外，自己有哪些方法可以提高质量。第一个项目的经验在第一个团队中，由于团队很年轻扩张又很快，所以推行了代码审查的方法，简单而言，就是高手/老手要看新手的代码，后期的制度则是每个人的代码必须有人看过之后，才能提交。在这些提交过程中，很多可能带来日后维护困难或缺陷的代码都被踢了回去。在这个团队扩张的后期，这种审查制度被凝结在师徒制度中，以把原来“帮忙”做审查变成“审查义务”。这一变化的原因是中间曾经发生过一次“不负责任”的审查，造成一大段两个月的代码未经充分审查就进入代码库，酿

8、成后来的一次现场故障。这种“不负责任”来自于本来就没有设定责任，只是帮忙，所以才发生了组织结构的变化。在建立师徒制度后，师傅们将对小组的成败包括质量负责。实际上，新人的流动率很高，如果留下垃圾代码，还是要师傅来维护，所以师傅“被迫”很尽责。师傅们普遍的做法是不只在最后才审查代码——因为那时候肯定面临一个烂摊子——而是