3 敏捷管理模式在软件开发项目中的应用
　　敏捷最早出现于1995年,相比于“分析—设计—实现”这种“重量级”(heavyweight)瀑布式软件开发方法,敏捷提倡“轻量级”(lightweight)的开发模式。“轻”与“重”的差异不是说敏捷丢弃分析、设计这些过程,敏捷要求分析和设计要适度而不是过度,而且敏捷更强调迭代,要求迭代的周期不要太长,通常是2~4周,这样软件产品是通过一次一次的较短周期迭代而成,每次迭代都有交付成果,而不是经历漫长的过程等待,等待软件最终的“破茧成蝶”。敏捷历史上最为重大的事件是“敏捷软件开发宣言”(Manifesto for Agile Software Development)的发表,宣言制定了4个核心价值观:
　　“我们正在通过实践和帮助其他人实践,揭示更好的开发软件的方法。我们的价值观是:
　　①人和相互交流胜于过程和工具;
　　②可以工作的软件胜于求全责备的文档;
　　③与客户协作胜于合同谈判;
　　④随时应对变化胜于按部就班。也就是说,虽然右边的条目有价值,但我们更看重左边的条目。”
　　正如敏捷所提倡的,它的宣言也异常“轻量”。敏捷宣言强调在实践中揭示好的方法,并且认为人(开发者与客户)、可交付成果(软件)、适应变化这三者在软件开发中更为重要,它的核心是“变革”,也就是从“重量级”的过程式开发变革到“轻量级”的敏捷开发,对过程式开发过度倚重的过程、文档、计划进行精简,一个组织、一个团队、一个项目是否敏捷,判断的唯一依据　就是是否遵循这四条原则,敏捷的项目管理同样需要遵循这四条原则。
　　在软件开发项目中引入敏捷之后,将会引发管理上的一系列变革。首先,关注重点由过程转向人,过程是死的,人是活的,敏捷管理将充分调动人的自主能动性,对于依靠人这一最主要生产要素才得以实现的软件产品来说,敏捷管理的这一做法真正回归到了前面分析的“管理的本质”,即充分发挥各个组织以及成员的潜能,敏捷管理将关注客户与开发人员间的协作和交流,以及开发人员之间的协作和交流;其次,它将管理控制对象由项目计划转向项目的交付成果———软件,这一转变统一了客户方与开发方的期待,而不是象过程管理强调了计划却忽略了客户的期待和项目的最终目标,这种统一消除了双方内在隐含的“此消彼长”逻辑关系,成为促进项目成功的“共同动力”;再次,敏捷要求在软件开发过程中随时可以适应变化,甚至在项目快要结束的时候也能够接受变更,这种能力解决了软件产品由于“渐进认知”特点进而引发需求变更的难题,而且除了流程、技术具备这种适应能力之外,敏捷更要求开发人员拥有适应变化的正确态度,拥抱变化而不是拒绝变化,这种态度转变消除了客户方和开发方之间关于“变更”存在的矛盾,进一步扫清了项目成功道路上的“人为”障碍;最后,敏捷鼓励创新,创新不是去创造一件前所未有的产品,而是为客户“挖掘”新的价值,敏捷鼓励新思维、使用新技术,只有这样才能适应变化的环境,为客户带来价值,另一方面敏捷要求消除浪费,凡是不能为客户提供价值的合规活动———比如冗余的开发文档,这些活动就应该坚决摈除,消除浪费可以把更多开发重心放在为客户创造价值的活动上,这是一个“反向增值”的举措。
　　因此,敏捷4个核心价值观的核心就是一个词:变革。敏捷宣言发起人之一的Jim Highsmith在《敏捷项目管理》中提出了几个重要观点:
　　①敏捷是促进变革并响应变化以便在动荡的商业环境中创造利润的能力;
　　②敏捷是平衡灵活性和稳定性的能力;③敏捷更多的是一种态度而不是一个流程,是一种氛围而不是方法。这几个观点给敏捷管理指出了方向:敏捷管理应该转变人的思维和态度,应该营造敏捷的团队氛围,应该培养敏捷的应变能力,最终在多变的环境下创造利润,而转变的关键在于对灵活性和平衡性的把握。在软件项目开发中,敏捷的范围管理首先要做的是转变态度,去适应范围的变化,而不是去控制;对于变更,应该是乐于接受,而不是盲目排斥。
　　除了价值观作为指导,敏捷同时提供最佳的实践做法,比如测试驱动开发(TDD)、特征驱动开发(FDD),结对编程(Paring Coding)等,并且提供给软件开发组织各种敏捷的开发和管理框架,其中应用最为广泛的是SCRUM。
　　SCRUM的英文意思是英式橄榄球队,SCRUM这个开发框架将软件团队比作橄榄球队,有明确的最高目标,熟悉开发流程中所应具备的最佳典范和技术,拥有高度自主权,紧密沟通与协作,高适应性地迎接各种挑战,确保每天、每个阶段都明确地朝目标推进。SCRUM的实施过程是:
　　(1)制定产品Backlog,Backlog是软件产品的一个需求列表。
　　(2)将整个产品的Backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。Sprint意思是冲刺,代表一次迭代周期(通常为30天),开发团队需要完成一个制定的Spring Back-log,并且最终成果是一个增量的、可以交付的产品。
　　(3)召开Sprint Planning Meeting,确定这个Sprint内需要完成的任务,标注任务的优先级并分配给每个成员。
　　(4)进入Sprint开发周期,在这个周期内,每天需要召开Daily Scrum Meeting(站立式会议)。
　　(5)整个Sprint周期结束,召开Sprint ReviewMeeting,将成果演示给Product Owner。
　　(6)团队成员最后召开Sprint Retrospective Meet-ing,总结问题和经验。
　　(7)这样周而复始,按照同样的步骤进行下一次Sprint。
　　从SCRUM实施过程可以看出,产品Backlog的制定对应于传统过程管理的范围定义(Scope Defining),产品Backlog是客户期待包含进项目的软件特征列表,在制定这个特征列表的时候,最需要注意的是确保这些特征能够彼此独立,这样的划分使得随时做优先排序或者进行变更成为可能。
　　作为项目管理者,有几点是在制定产品Backlog中要明确的:第一,产品Backlog　SCRUM实施过程允许随着项目进展而进行变更,或者增加,或者修改,或者删减其中的一些特征;第二,产品Backlog的制定需要客户参与,并且由客户做出选择;第三,产品Back-log有一个拥有者,即Product Backlog Owner,这个拥有者可以是开发方的产品经理,或者直接来自客户,他拥有该特征列表的最终决定权;第四,产品Backlog的优先排序原则将取决于特征的价值,也就是说,如果不是现在就实现这个功能,会存在哪些风险,或者要丢失什么样市场机遇,应该根据价值原则做出决定;
　　第五,需要对产品Backlog的各特征项进行大小和复杂程度进行估计。
　　传统过程管理通过范围分解(WBS)来建立工作分解结构词汇表,获得范围基准,并且为制订项目进度计划提供输入,这在敏捷开发当中没有专门对应的技术和方法。在实际操作中,SCRUM将一个完整项目划分为若干个小项目,每个小项目称为一个发布(Re-lease),然后一个发布又分为多个Sprint,Sprint有自己的Sprint Backlog,每个Sprint Backlog包含完成任务所需的Backlog Item,这个过程有些类似于任务分解,但是分解的目的并不是为了接下去做一个“庞大而务求精准”的项目计划,而是在一个Sprint当中具体地细分任务,实现任务并且交付成果。敏捷的做法其实是将分解的任务以及能力转移到敏捷的团队开发当中,这种转移化解了信息输入不够而可能造成的计划不当风险,并且由开发团队的成员协作完成,使开发人员更明确各自的任务和交付成果,增强了自主性。
　　基于这种增量和迭代的方法,采用敏捷方法的项目经理可以制订更高层次的计划来控制项目范围和进度。当一次迭代完成后,客户可以立即参与到交付成果评估当中,客户评估的对象是可用的功能,而不是一个空泛的文件说明,客户要么接受这一迭代的成果,要么提出改进意见,要么可以拒绝这个成果。这种验收方式,即范围核实(Scope Verification)较传统的“一次性验收”显得更为具体和可行,它及时获得客户的反馈,而吸纳反馈后改进的软件功能才有可能为客户提供更多价值。
　　在范围控制上,实施敏捷的项目团队更有信心面对变更,因为适应性已经成为团队最为突出的能力,提供客户价值、正确的态度、迭代、协作、创新是这种信心的有力保障,项目经理面对变更需要把握的处理原则就是:客户价值在什么地方,应该在可获得的时间与资源中,交付什么样的成果从而为客户带来最大的价值。　变更的结果有可能是为了增加更高价值的功能,而另一些则需要抛弃,这就是Jim Highsmith提到的敏捷的“平衡能力”。
　　4 结语
　　最后再将目光重新投向“项目三角形”,在引入敏捷之后,或许不能再这么简单地利用三个因素去考虑和衡量一个项目,美国项目管理专家Johanna Rothman提出了这么一个“项目新三角”。
　　在这个新三角形当中,由成本(cost)、工作环境(work environment)、人以及人的能力(People and theirCapabilities)三条边决定三角形的大小,从三角形内部的一个点向三角形的顶点各引一条线,分别是范围(Feature Set)、时间(Time to Market)、质量(Low De-fects),很明显内部的这三条线受到双重约束,第一重约束是由外部三条边所构成的这个三角形,第二重约束就是内部的三条线之间的制约:如果拽住这三条线的联结点进行拉伸,任何一条线的长短变化都会引起其他两条线的变化。
　　这个新“项目三角形”带来很大的启发,假如能够扩大整个三角形,那么范围、时间、质量这三个因素间的矛盾就将从根本上得以缓解甚至消除!这是一个崭新的视角,该如何去扩大这个“三角形”,答案在哪里?
　　当一个软件项目引入敏捷之后,就能找到这个答案,因为正如Jim Highsmith的精辟见解一样———“敏捷更多是一种‘态度’,是一种‘氛围’”,而态度足以改变一个人,足以改变整个团队,足以改变客
　　户方与开发方的关系,氛围则是敏捷所创造的平等、自主、协作、适应和创新的工作环境,这不正是新三角形中People and their Capabilities与Work Environment这两条边吗?
　　最后,几乎可以很肯定地说,拥有敏捷团队的项目经理将是一个非常幸运的人。