|
项目管理者联盟
作者简介：金明，ThoughtWorks咨询师，InfoQ中文社区编辑，SCJP，系统分析师。他在机械模具、数字安全证书，以及海洋航运等行业拥有超过4年的企业应用开发经验。他对敏捷方法学，特别是敏捷咨询和项目管理，以及面向对象分析和架构设计等方面有浓厚的兴趣。项目管理者联盟
在软件行业，大部分经理们都希望自己率领的团队能像军队一样具有铁的纪律性。在一次敏捷培训中，我们与众多来自国内软件公司的项目经理们讨论了敏捷，以及他们现在各自的开发方法和问题。闲谈中，一位学员冒出一句，“开发团队应该像军队，不仅要整体阵法严密，而且每个兵都要纪律分明。”这次培训主要是介绍敏捷的技术实践，比如测试驱动开发、持续集成、用户故事等，该学员认为这些敏捷实践不仅可以提高员工的技战术，还可以塑造团队成员的纪律性。如果这些敏捷实践在日常开发中都能落在实处，势必将提高团队成员的“战斗素养”和“战术素养”。一言以蔽之，相较于其他软件开发模式，敏捷方法对团队成员的纪律性提出了更高的要求，鼓励团队成员成长为项目经理心中的“合格军人”。项目管理者联盟
其实，抛开敏捷方法，哪一种软件开发方法又何尝不强调团队成员的纪律性?计划驱动的传统型开发方法给软件过程制定了严格的计划书和检验标准，希望能提高团队的纪律性。它们的出发点是对的，但因为缺少了具体的技术实践导致计划书并不能匹配团队的真实状态;检验标准大多是着眼于与最终交付软件无关的中间文档，这些都使得成员在工作中对项目开发的约束力感受不深。比如，很多项目里面的规范说明书、WBS表和甘特图都画得非常详细，但大多数时候这些东西与项目真实情况的落差太大，很难指导督促成员的日常开发工作。而且，这些文档与需要交付的软件产品的关联性不强，也很难能让成员和其他人通过这些文档建立对软件交付的信心。长期看到团队的表现与计划的不相符，项目经理们往往会感叹团队的纪律性不行。那么，为什么说敏捷方法能相对一定有效地提升团队成员的纪律性呢?我们先来看看纪律的定义。项目管理者联盟
纪律项目管理者联盟
一般来说，纪律有三种基本涵义：1.纪律是指惩罚;2.纪律是指通过施加外部约束达到纠正行为目的的手段;3.纪律是指对自身行为起作用的内在约束力。这三层意思概括了纪律的基本内涵，同时也反映出良好纪律的形成过程是一个由外在的强迫纪律逐步过渡到内在自律的过程。从纪律的含义来看，达到自律是最终的目标，也是施加外部约束的目的所在。通过奖惩来达到一定的纪律性，比如程序员开发过程中的bug率等等，这是生活中最常见的一种形式。这种方法因为检查的结果与具体生产过程差得太远，而且评判标准还是比较粗放，所以应该是最低级的方式。施加外部约束，比如检查列表，指导产品的具体生产，可以评判成员的各个环节是否符合标准，应该算中级方式。只有自律，真正让成员把纪律的观念贯穿在生产的每个环节，主动改进，从而改善生产。而这，也是纪律性的高级方式。项目管理者联盟
对比这个标准，我们可以看到：计划驱动型的软件方法学强调更多的是奖惩，也涉及到一些外部约束(代码复审等)，这也是为什么它们在培养团队成员纪律性上难度比较大。而敏捷方法，通过强调承诺，强调每个成员都是“理性人”的事实，借助于成员的自律性来达到严明的纪律性。国内有一家业内非常有名的技术网站InfoQ，四月份在北京举行的QCon Beijing就是由InfoQ主办。除了有限的几位全职员工，大部分的中文编辑都是社区的活跃分子，他们走到一起，通过之间的承诺和信任维持着日常工作，也给全国技术爱好者传播国内外的业界最新新闻和技术。撇开具体项目团队而言，这就是敏捷团队最好的写照。但是，我们也应该看到，InfoQ类型的团队是可遇不可求的。现实中，大部分的开发团队还是良莠不齐，项目经理们很难去完全授权给手下的员工。为什么敏捷方法又能有效地提升成员纪律性呢?答案在于敏捷方法不仅仅强调承诺，也包含了丰富的技术实践：不仅给个人带来更短更频繁的反馈，也给团队和组织带来了多层次较全面的反馈。而反馈的频繁程度，则是外部约束发挥作用的重要基础，也即提升纪律性的重要手段。项目管理者联盟
戴明环(PDCA)项目经理博客
我们来看看被认为是组织或团队改进或解决质量问题的基本准则的戴明环。戴明环(PDCA)是由美国质量管理博士戴明在20世纪50年代提出，PDCA是英语单词Plan(计划)、Do(执行)、Check(检查)和Action(行动)的第一个字母，PDCA循环按照“计划-执行-检查-行动”的顺序进行，并且循环不止地进行下去，是一个立体多层级的螺旋式的演化过程。PDCA循环最开始是用在质量管理领域，但实际上它是有效进行任何一项工作的合乎逻辑的工作程序，是放之四海而皆准的指导性原则。下面我们就用它来说明外部约束对纪律养成是如何影响。项目管理者联盟
PDCA循环里面的Action是一个循环的关键，对Check的结果进行处理，成功的经验加以肯定并适当推广、标准化;失败的教训加以总结，未解决的问题放到下一个PDCA循环里，但它必须以上一环节的Check结果为基础。如果Check不到位，不能具体到实际工作，Action的正确性和出发依据就很值得商榷。软件开发是一个以不确定性为主要特征，强调知识的活动。为了采取的Action具有较高的正确几率，更需要强调开发过程的Check比较频繁、具体，不断给团队提出直接的反馈，这样才能减少不断累积的不确定性最后带来成不可控制的后果。如此来看，短而频繁的反馈对外来约束真正施加到个人的效果是非常重要的。项目管理者联盟
PDCA循环还有一个特点是多层级性：各层级质量管理都有一个PDCA循环，形成一个大环套小环，一环扣一环，互相制约，互为补充的有机整体。软件开发通常会把个人、团队和组织都牵扯进来：个人完成功能的开发，团队完成软件的开发，组织负责完成客户需求的完成。传统的软件开发方法更多的是强调团队、组织层级的计划、图表等文档，关注于团队与组织层级的反馈。对于真正创造产品质量的日常开发环节，则缺少必要的检查和反馈。与之相反，支撑敏捷方法的敏捷实践，就从“个人-团队-组织”的几个层面都提供了相应的反馈：低层次的反馈，为上一层次的反馈提供了依据，同时也作为上一层次反馈的落实和具体。talent.mypm.net
敏捷实践项目管理培训
下面，我们从“个人-团队-组织”的不同层次分别选取几个突出实践简要解释它们是如何提供频繁、直接的反馈。项目管理者联盟
个人层级项目经理圈子
测试驱动开发能给开发人员提供最直接也是最快捷的反馈：先写测试，再用最简单的方式实现，再重构代码以符合简单设计的原则。如此短间隔的反馈能很快地告诉开发人员刚才增加的代码是否破坏了已有的功能。而且，已完成test case的列表能很清晰地告诉其他人开发任务的完成情况。对比着用户故事的验收条件，开发人员很容易评估剩余的工作量，并不至于破坏已有的功能。service.mypm.net
团队层级项目管理者联盟
敏捷实践中的持续集成，强调尽可能快尽可能频繁地提交代码，与系统的其他部分进行集成。在提交新代码之前，必须保证本地的构建过程是成功无误的。谁提交代码使得持续集成服务器构建失败，必须立即停下手中的活，负责修复构建直到成功。下班之前必须要保证持续集成服务器上的集成构建状态是成功的。这样，开发人员和团队很容易检查新功能与其他模块的集成，另外也把未来的集成风险降到最低。pmp.mypm.net
组织层级项目管理者联盟
用户故事是开发团队与客户之间讨论需求的基础。用户故事必须对客户有真实可见的业务价值，并且必须包含对该需求完成的验收条件。用户故事作为业务分析人员、测试人员、项目经理与客户一起确定的用户需求，具有经过验证的确切性。开发人员开发故事之前，必须和业务分析人员、测试人员沟通理解需求;开发完故事之后，必须要由业务分析人员与测试人员根据验收条件进行验收。组织和客户之间可以针对达成共识的故事列表来分析项目状态，从而验证或者修改项目计划。service.mypm.net
上面只是从“个人-团队-组织”的层次分别挑出了测试驱动开发、持续集成，以及用户故事的实践阐述了敏捷实践如何在不同的层次提供频繁的反馈，一孔窥豹，还有其他若干实践在这里就不再赘述。总之，敏捷众多的实践就像组成了一张全面立体的安全网，时时刻刻从各个角度给项目成员、团队，以及组织提供短周期的反馈，帮助团队成员不仅感受到开发过程中的同伴约束，而且也可以感受到来自整个团队的约束，甚至是来自组织之间的约束。这些外来约束也像是缠绕在个人周围的催化剂，纠正或改善个人的行为，达到提升个人的纪律性。talent.mypm.net
实际团队项目管理者联盟
经过几天魔鬼般的技术实践培训，我们在第三天给学员们安排了全天的模拟项目演练。在演练中，由学员自行组织自己的团队：选出自己的团队名称和口号、推选出项目经理、各自分配开发任务，所有人都信心满满。在刚开始接触开发任务的时候，他们还是有一些不好的习惯，这时候，我们鼓励他们把前几天学到的敏捷实践都用起来。于是就出现了这样的形式：当结对中的一人先写实现，而不是先写测试时，另一个人会指出问题，然后重新使用测试驱动的方式;在提交代码时，会有培训讲师监督着他们按照正确的方式来提交;开发用户故事，要求开发人员必须跟分析人员沟通清楚细节，验收故事时，开发人员必须与分析人员和“现场客户”同时参与验收......虽然有些磕磕碰碰，但整体上团队还是有条不紊地进行下去，而且每个人只需要关注自己手头的那部分工作，也易于让他们把事情做得正确。项目管理者联盟
到了下午，随着学员对技术和业务理解的加深，他们也开始自觉地维护起开发过程，使其保持顺畅。开发过程中，结对的两人激烈地讨论实现的方法，达成一致后又一起开怀大笑;碰上了问题，主动招手找业务分析师询问需求细节，如果业务分析师也弄不清楚，再找现场客户来解答，直到三方都满意;多人开发遇上了冲突，主动找到对方，商量沟通解决方案，实在不行，就找项目经理进行沟通协调;当有人提交了代码使得持续集成服务器构建失败，所有人会善意地提醒犯错的人，督促他们修复;谁遇上了技术问题，有人听见了他们的讨论就会自发上前提供自己的信息;项目经理因为团队自组织也就从繁杂的管理工作里面脱身而出，饶有兴趣地与开发人员一起结对干起了开发的活......整个团队像一列火车一样，前轮带动后轮，后轮推动前轮，井然有序，毫不停歇地往前行进。项目管理者联盟
最后，我们作为模拟客户参加了这个团队的show case会议，惊讶地看到这个团队的士气和活力，以及他们完成的工作。特别是他们表现出来的团队集体感，让人会以为他们是一个磨合很久的团队。项目经理还在为没有完成更多的工作任务觉得惋惜，但对于“如果给更多时间，是否有信心这个团队可以更好地完成更多的任务”这一问题，他表达了明确的认同。然后再问“为什么”，他说，这个团队的士气和纪律让他刮目相看，目前完成任务的质量让他对未来的任务充满信心。最后问“愿意率领这样的团队么?”，答案是“为什么不?”项目管理者联盟
项目管理者联盟
|
