1.3 百家争鸣

如果用传统开发方式,也就是瀑布式模型来开发钢笔,将产品的架构划分为数据层、逻辑层、应用层和接口层,团队也划分为相应的4个平行开发团队。每一层的架构和设计都需在代码构造前完美地完成,因而为了实现产品的按期发布,四个团队都不能独立将自己的产出在4个月内的任何时间向外发布,也就无法评估笔杆上的雕花是否比新加入的“节约墨水”功能更吸引用户。所以,最后产出的产品虽然有50+30+15+5=100的评估价值,但在这个过程中投资者只得一次性投入4个月的资金,直至4个月后才等到第一次面向市场的机会;而此时同类产品的竞争优势更加可观,产品实际带来的利润价值并没有预期的大。

图1-2给出传统开发过程与敏捷开发过程的对比。

00072.jpeg

图1-2 传统开发过程与敏捷开发过程对比

在此不过多列举敏捷方法,但值得一提的是核心的敏捷方法Scrum,以及可以与Scrum媲美的敏捷方法论。XP(eXtreme Programming)更加适合3~5人的小型项目团队,DSDM(Dynamic Systems Development Methodology)与Scrum一样更加适合大型团队的项目开发,还有Lean等方法。这些方法其实都可以在IBM的某些项目中窥见一斑,后文将具体讨论。

1.3.1 极限编程

极限编程(XP)是由KentBeck在1996年提出的。XP是一种注重协作、快速和早期软件创建的有技巧的开发实践方法,适合10人以下的团队。XP是一个轻量级的、灵巧的软件开发方法,同时也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气,即任何一个软件项目都可以从四个方面入手进行改善:加强交流,从简单做起,寻求反馈,勇于实事求是。XP是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期,通过积极的交流、反馈以及其他一系列的方法,开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。

极限编程的基本原则:

·通过客户、开发团队、项目经理三方共同参加的会议来确定开发计划。

·小版本发布:尽快发布,尽早发布。

·通过系统隐喻(metaphor)让每个人了解整个系统。

·简单设计:为明确的功能进行最优的设计,不考虑未来可能需要的功能。

·重构(refactoring):不断优化系统设计,使之保持简单。

·单元测试:先写测试,后写代码。

·结对编程(pair programming):系统的每一行代码都是两个人用一个键盘完成的。

·代码集体拥有:开发队伍中任何人可以修改任何其他人的代码,代码不属于某个个人。

·持续集成:至少每天将整个系统集成一次,保持一个能运转的系统。

·40小时工作制:保证休息,保持体力。

·现场客户:客户自己也是软件开发队伍的重要一份子。

·编码标准:必须有统一的编码规范,确保代码的可读性。

关键词 测试驱动,结对编程,持续集成,重构,小版本发布,沟通。

1.3.2 水晶方法

水晶(Crystal)方法论由Alistair Cockburn在20世纪90年代末提出。他把开发看做是一系列的协作游戏,而写文档的目标是帮助团队在下一个游戏中取得胜利。水晶方法的工作产品包括用例、风险列表、迭代计划、核心领域模型,以及记录了一些选择结果的设计注释。水晶方法也为这些产品定义了相应的角色。然而,值得注意的是,这些文档没有模板,描述也可不拘小节,但目标一定要清晰,即满足下次游戏开始的条件。

对于水晶方法论,根据方法论的轻重可以分为透明水晶和橙色水晶等。透明水晶一般适用于轻量级的团队。不管是哪种水晶,都会对团队的角色、团队的工作项和产出、核心实践、支持过程等进行定义。

关键词 协作,角色,文档,迭代,风险管理。

1.3.3 动态系统开发方法

动态系统开发方法(DSDM)倡导以业务为核心,快速而有效地进行系统开发。可以把DSDM看成一种控制框架,其重点在于快速交付并补充如何应用这些控制的指导原则。

DSDM是一整套的方法论,不仅仅包括软件开发内容和实践,也包括了组织结构、项目管理、估算、工具环境、测试、配置管理、风险管理、重用等各个方面的内容。

DSDM的基本观点是,任何事情都不可能一次性圆满完成,应该用20%的时间完成80%的有用功能,以适合商业目的为准。实施的思路是,在时间进度和可用资源预先固定的情况下,力争最大化地满足业务需求(传统方法一般是需求固定,时间和资源可变),交付所需要的系统。对于交付的系统,必须达到足够的稳定程度以在实际环境中运行;对于业务方面的某些紧急需求,也必须能够在短时间内得到满足,并在后续迭代阶段中对功能进行完善。

DSDM的基本原则:

·活动用户必须参与。

·必须授权DSDM团队进行决策。

·注重频繁交付产品。

·判断产品是否可接受的一个基本标准是符合业务目的。

·对准确的业务解决方案需要采用循环和增量开发。

·开发期间的所有更改都是可逆的。

·基本要求是高层次的并区分优先级(以在低优先级的项目上获得一定的灵活性)。

·在整个生命周期集成测试。

·在所有参与者之间采用协作和合作方法。

关键词 以业务为中心,用户参与,迭代,快速交付,团队协作和沟通。

1.3.4 精益生产

精益(Lean)管理的思想起源于丰田公司,旨在创造价值的目标下,通过改良流程不断地消除浪费。这种方法现已被广泛用于生产制造管理,对于IT系统建设,精益开发的常用工具模型是价值流模型,如图1-3所示。

00074.jpeg

图1-3 精益方法的价值流模型(括号内代表浪费的时间)

精益开发的基本原则:

·杜绝浪费:将所有的时间花在能够增加客户价值的事情上。

·推迟决策:根据实际情况保持可选方案的开放性,但时间不能过长。

·加强学习:使用科学的学习方法。

·快速交付:当客户索取价值时应立即交付价值。

·打造精品:使用恰当的方法确保质量。

·授权团队:让创造增值的员工充分发挥自己的潜力。

·优化整体:防止以损害整体为代价而优化部分的倾向。

上述方法都是流行的敏捷方法。图1-4是VersionOne在2013年发布的敏捷方法的使用情况。最主流的敏捷方法仍然是Scrum,下面来看看Scrum是什么。

00075.jpeg

图1-4 敏捷方法的使用情况