2.3 传统团队践行

迄今为止,社会上有许许多多敏捷培训课程,但是说起敏捷转型,团队既需学习成熟的敏捷方法,又需要资深的敏捷实践者、敏捷教练引导团队循序践行。敏捷的开发者、测试者、业务和需求研发者或者是管理者都需要找到自身的重新定位。事实上,我们在重新构建一套项目研发管理流程和方法,这个过程中,我们或多或少都会有疑惑:项目管理方法PMBOK和敏捷项目管理有什么区别和关系?传统软件研发体系中的项目管理过程和敏捷项目管理过程有什么区别?传统项目的项目经理在敏捷环境中是否需要学习新的技能或面临淘汰?

简单地说,敏捷方法的一切努力都基于一个目标:节省研发成本,降低运维费用,提升利润点。敏捷方法因此才得以推广。需要长期的投入过程、由厚重而具体的计划驱动的传统项目研发方式很难适应变化的市场,因为,再好的设计也会过期,也需要发生变化,计划投入成本的首要考虑是节省。对此,传统项目经理并不会站在对立面,面对新模式,管理者需要做的仅仅是将项目的庞大计划拆分成细小的迭代计划,并且认可调整期待目标的必要性。

2.3.1 挑战传统管理

传统项目经理的华丽转型还需要一点点“破茧而出”的勇气。在敏捷转型完成之前,需要传统项目经理一步步完成自适应的转型,将原来惯于为团队做出裁决、管理团队的高姿态慢慢放下,从“管理”过渡到“支持”,放弃约束和命令,迎合和培养一支能够自适应、自我管理的团队。

2.3.2 PMBOK理论

敏捷和计划驱动的开发方式都符合“项目的金三角”理论(见图2-5),也就是成本、进度和范围的三重约束。但是,传统项目基于的是计划驱动的需求,因为只有这样,进度和成本才可以估算,风险才可以控制。而敏捷方法的项目范围总是在不断变化,即使客户没有要求这个范围发生必然变化,我们也不得不做好变化的准备。在敏捷方法中,由于范围的灵活性,进度和成本不可能保持固定。如果假设进度或成本不变,则这个范围的变化一定是动态平衡的,即变化后又回到了原点。总之,规律谁也逃不过,因为,只有符合规律的项目才不会成为“死亡竞赛”。

00106.jpeg

图2-5 项目的金三角约束理论

但是,现实中让项目经理头疼的事情是,利益关系人和客户压根就不买金三角理论的账,项目经理的责任不再是做出独立决策,而是更好地配合持续改进,配合团队在更短的时间内产出更多的价值。用三角理论的方式讲,就是保证范围扩大的前提下,不对进度和成本进行修改。

为了突破金三角的诅咒,项目经理、团队、利益关系人必须做好一件事,那就是提升团队的责任感,增加团队的自我管理空间,界定项目经理的工作,不需要项目经理对太多的事情进行控制,以更好地适应自我管理的团队环境,这也正是核心敏捷原则之一。

项目经理的角色需要从管家型“控制”转变成仆人式“领导”,重点在于促进和合作。下面通过PMBOK知识领域映射到敏捷实践方式,讨论项目经理应该有怎样的专业变化,以及如何使之自然过渡到敏捷软件开发方法。

项目经理要善于观察,并学习如何引导团队在全新环境中可靠地应对变革,而不是强迫团队符合规划的安排。这需要有勇气让团队自己做出决定,而不是被告知该怎么做。这意味着团队成员有了更多的个人责任,并要求项目经理有更强大的协调和配合技能。在开始阶段,最难的就是让项目经理适应新角色。项目经理的责任是培养团队凝聚力,营造良好的团队沟通氛围。虽然并不是每个人都愿意做出转变,但是,我看到了许多项目经理的成功转变,其努力也让团队收获了巨大的回报。而任何时候,我们都必须清楚,总有人不喜欢敏捷,总有人拒绝变化,所以不要强求所有人都参与。

有意思的是,在深知项目管理协会(PMI)和敏捷理念有所差异的前提下,我和PMI的资深顾问,CMMI5的认证评审委员会成员进行了多次讨论,发现项目管理知识体系指南(PMBOK)确定的做法都与敏捷实践可以很好地兼容,当然也有不同。

例如,能力成熟度模型(CMMI)指数指出,PMBOK是最佳的实践方针,组织必须行使自由裁剪的权力,如项目管理、需求管理,团队管理等。事实上,敏捷方法,以及我们提出的纪律和风险与价值驱动模型,都将符合CMMI,就像传统的瀑布方法和CMMI兼容一样。如果非要说有什么不同(除了基本的命令、控制与自我管理),那也仅仅是何时以及如何将这些行为可靠地执行,以及敏捷实践中的新词汇罢了。

PMBOK指出,初始化、反复计划、监管、执行和退出是标准的项目管理流程(见图2-6)。而IBM的DAD更能反映真实的软件项目开发过程,其项目管理流程为初始化、反复计划、迭代审视与改进、迭代构造、迭代交付过程(见表2-1)。初始化阶段兼顾考虑商业视野和初步的功能计划列表,确定构造过程中需要做什么。到了反复计划阶段,这个商业视野定义过的先进产品列表将作为一系列可以实现的功能,并被规划到迭代周期中去。迭代构造是产品通过一个增量迭代过程,从无到有的产生过程。迭代审视与改进过程是项目负责人和团队实际完成项目后,对项目的利益关系人做出总结性汇报的过程,当然还有不间断地对项目风险、结果监控和管理的过程。最后是交付和退出,在这个过程中,团队有机会看到客户对工作成果的真实反馈,了解利益关系人对产品的进一步需求。

00109.jpeg

图2-6 PMBOK过程

表2-1 PMBOK与DAD的异同

00112.jpeg

阅读PMBOK可以发现,五个主要的知识点在项目管理领域受到了足够的重视,它们是集成管理(Integration Management)、范围管理(Scope Management)、项目时间管理(Project Time Management)、质量管理(Quality Management)和人力资源管理(Human Resource Management)。对于每个知识点,PMBOK所定义的实践活动与敏捷软件研发各阶段的实践活动有着截然不同的定义(见图2-7和图2-8)。

00114.jpeg

图2-7 PMBOK与敏捷迭代阶段映射

00119.jpeg

图2-8 PMBOK与敏捷版本发布阶段映射

1.集成管理vs敏捷多级计划管理

在集成管理领域,最为重要的交付物是项目的计划文档,这个文档由项目经理负责和交付。而敏捷研发过程中,因为尊重仅仅足够和及时的原则,所有的计划和设计都是在团队中历练出来的。计划文档也是有的,但只不过是一个简单的发布计划文档和一些迭代计划文档。敏捷计划文档不会详尽解释范围、工作分解结(WBS)、进度、假设和管制,敏捷项目的项目经理更关注计划的过程而不是结果,因此将轻量级的文档仅仅作为项目团队理解目标,达成一致的手段。为了符合流程上的标准,我们将白板、录音作为“文档”或者“计划”保留在项目公共区域里,例如,通过Rational协同工具和工具视图做到“自动化”与“品质”同在(见图2-9)。

再如,只用简单的白板加上有颜色的便签,就可以将计划的关注目标呈现清楚(见图2-10)。这种方法适用于集中的团队开发,在一间封闭开发的房间(war room)将所有重要的资源和信息公开,使大家在行动和思想上达成统一。

00122.jpeg

图2-9 使用Rational工具使计划和项目透明化

00125.jpeg

图2-10 使用白板和各种颜色即时贴做计划和项目跟进

如果既没有足够的资金购进高级工具也没有华丽的war room,用EXCEL做出简易的产品清单并记录每日团队的工作量,自动绘制燃尽图,效果也很好(见图2-11)。

2.PMBOK范围管理和项目时间管理vs敏捷范围管理和时间管理

“规模扩张”一直是传统项目的祸根,如要求项目经理积极响应客户的业务需求、响应行业的点滴变化、响应突破瓶颈的新技术,并在开发过程中不断学习和改变,这样的项目经理一定要得“变化恐惧症”。在PMBOK中,范围规划、定义、验证和控制都被给予极大关注,并且是计划驱动的,不希望更改的范围变大。不同的是,敏捷方法希望拥抱范围变化,迎接业务需求,响应市场、行业、技术的变革,并对过程和效率有着持续改进的热情。在尽量稳定成本和进度的前提下,努力实施客户定义或者接受的最高价值。

00129.jpeg

图2-11 使用EXCEL做计划和项目跟进

项目的范围变更和时间管理常常使项目经理陷入慌乱。假设项目是由一个个固定的时间周期——时间盒子构成的,失败的项目管理便是将堆砌功能的“砖头”一个接一个地扔到单一脆弱的时间盒子里,直到时间盒子爆炸。实际上,我们往往会关闭这个对话框,让迭代发生,并生产另一个时间盒子,将“砖头”扔进新的盒子里。由于我们一次只做一个盒子的装载,极致地完成一个盒子的工作,因此我们很难预计在未来的一段时间里能够完成多少工作。事实上,项目经理经常会疑惑:用这种新的、灵活的方法来规划和管理范围听起来很不错,但问题是,当老板和客户问我需要多少时间来完成项目的时候,我该如何回答?

对于时间管理和范围管理,不管使用什么办法,当被问到长远目标或计划时,项目经理往往要扮演先知和算命者。项目经理不可能真正准确地回答这个问题,即使使用传统的项目管理方法,也不过是基于专家判断和历史分析的猜测罢了。罗恩·杰弗里斯,敏捷和极限编程的共同创始人之一,曾告诉项目经理可以这样回答这个问题:

“现在,这似乎是一个200点工作量的项目。根据我们在其他项目上的工作速度和效率(或随机猜测),考虑N位全职程序员的团队规模,并考虑您将亲自参与这个项目,这种规模的项目将需要4~6个月的时间。然而,我们将每两个星期交付一版软件,并以“您满意为止”作为这些功能实现的标准。一个好消息是,如果感到不满意,您可以让团队停下来。还有个更好的消息,如果在所有预计的功能完成之前就已经非常满意,您也可以让我们停下来。而您也有更多的责任,就是与我们积极合作,让团队理解您满意的是什么。最后,也是最好的消息,只要现有功能足以使程序看起来非常有用,您可以要求我们随时准备软件的部署。在项目进展的同时,我们将看到交付效率,且对项目时间估计的准确度也会提高。”

在敏捷软件开发中,范围规划是作为发布计划(Release Planning)的一部分完成的。项目工作范围的定义,和项目时间管理领域中定义的实践活动都是敏捷开发领域迭代计划(Iteration Planning)的一部分。迭代计划对其中的每个功能进行阐述、优先级设定、工作量估计和工作分发。敏捷软件开发与PMBOK定义的关键区别在于,规划和设计工作只是针对独立工作的一个功能或者一段完整代码而言,并不是针对整个系统上某个层面的技术、架构、文档和函数。对应于PMBOK的定义,敏捷开发也有“范围核实”,在迭代结束时,由产品的利益关系人/客户进行审查,用户测试/体验通过即代表工作完成。

3.PMBOK质量管理vs.敏捷质量管理

另一个发生了巨大思想变革的团体是软件研发团队的质量评估(QA)和测试人员。习惯了根据开发者提供的设计文档和详细说明来验证产品正确性的过程,就仿佛置身于无人驾驶飞机的机舱,只能通过感官感受飞机的状态而无所作为。在PMBOK定义下的QA和测试人员所期望的测试是对所交付产品的不规范进行校正,在等待产品交付的时间中陷入焦虑,而在产品交付的最后紧要关头冲锋陷阵。

敏捷测试和质量评估在软件周期时间表上开始渐渐左倾。质量评估和测试人员从产品的需求分析阶段就已经开始参与,一直保持充沛的精力和积极的影响,参与决策整个产品生命周期。由于采取增量开发方式,在每个迭代中,质量评估都在集中测试当下最为重要的可交付功能和有价值的非功能点,而不是等待某事务被“扔过围墙”而开始工作。而且,随着迭代工作和产品功能的累积,质量评估需要不断寻找更为高效和便捷的技术,将自身从低价值的重复劳作中解放出来,关注最有价值和新价值的质量保障工作。因此,必须在GUI、API、系统集成等方面研发自动化测试。

通常情况下,PMBOK要求的质量管理计划应该包括:定义质量保障的目标和范围,确定执行标准质量保证工作的技术和方法。敏捷的质量保障团队成员仍应满足这一要求,并与项目团队一起工作,确定使用的工具和技术,以书面形式提交测试结果。同开发人员一起验证定义并确定执行目标是很重要的,因为单元测试将有助于自动化回归和验收测试。产品负责人也必须参与,因为他们应该帮助团队明确定义并运行验收测试。在敏捷实践中,每个人都有责任定义、维护和提高产品的质量保障体系。

质量保证的重点之一是预防缺陷。在敏捷研发中,QA团队与开发团队有着相同重要的决策影响,QA对质量保障工作的承诺在整个项目生命周期中起着至关重要的作用,关乎发布的成败。在项目前期,QA对需求的充分分析可以帮助开发人员编写更好的代码,更多的假设场景被程序员和测试人员作为后续开发、测试计划的有益参考。测试人员站在用户体验的角度,为产品负责人对整个产品的准确规划和定位提供更有效的保证。

质量保证的另一个重点是找到质量缺陷,通过与开发者和程序员的合作将这些缺陷消除掉。敏捷研发中,这类工作也是在迭代内完成的。与PMBOK中定义的缺陷发现和消除工作一样,一般团队会使用自动构建、冒烟测试、自动化回归测试、单元测试、功能性测试、探索性测试、验收测试来完成对缺陷的消除工作。不同的是,敏捷研发中,质量缺陷的发现和消除工作人人有责,没有人能够免于因为缺陷而未能满足客户期望而产生的问责。

4.PMBOK人力资源管理vs.敏捷人力资源管理

一旦收购完毕,公司需要对新团队和每位新员工做出组织规划和团队发展计划,这也正是PMBOK定义的组织规划和团队发展过程。PMBOK组织规划明确指出,需要为员工定义角色与职责,团队发展就是要发展个人技能和个人竞争力(PMI,2000)。在敏捷领域,团队发展计划的重点是组织一个跨职能团队,使其能够在各种环境下正常运转,实现团队自我管理。

建立跨职能的团队意味着开发团队不再有“门派”区分,而只有角色区分。敏捷开发团队的目标清晰,即创建可工作代码,增量并产生可用的产品。这个过程需要所有关键角色:测试人员、分析师、架构师、技术信息开发者、行业专家、客户/产品负责人,以及团队领导(项目经理,团队负责人等)。这些人具备不同的特定技能,但作为团队一员,以及后续成熟的敏捷团队发展计划的一员,每个人均会更多地了解他人的工作并理解他人的努力,逐渐变得更愿意帮助和自己不同角色的人,进而拥有多项专长。拥有一个跨职能的团队,意味着有一群人致力于让客户满意,并能够通过互助和协作来实现目标。

敏捷团队能够完成自组织的转变,归因于对于团队目标的共识,和持续地、规律地改进产品和产品研发过程。在这个过程中,团队合作紧密,并坚持不懈地寻找解决问题的方案和完成目标的途径。团队负责总计划、总执行,以及审视产品研发和过程改进,自我导向地将团队不断推向新水准。

对于项目经理而言,这又是一个艰难的思想转变,当项目经理认识到不再需要指挥一个团队时,他们开始紧张焦虑,不清楚自己的角色将会怎样变化。实际上,在敏捷团队中,项目经理将从“指挥官”变成以支撑团队为主要工作的“仆人领袖”。团队机制不会自行发生转变,尤其在团队还未熟悉敏捷方法时,需要强有力的领导帮助他们学习如何做出“团队决策”。作为一个“仆人领袖”,需要学习如何促进协作,培养团队持续反思的习惯,帮助团队做得更好。