杨 鹏
(陕西工业职业技术学院,陕西咸阳 712000)
为了能够在变幻莫测的现实环境中以可预期方式交付结果,“迭代”方法应运而生。“不确定性”将持续存在,需要采用一种与之抗衡的技术,这种技术就是迭代和增量开发,借助这种技术赋予的力量,能够克服不确定性,或至少能系统降低不确定性,使其处于可控范围,以达到预期的目标。
迭代——反复说念和执行动作。
增量——(1)增加量;(2)变大、增加。
如何在软件开发领域应用此方法呢?在某种意义上,软件开发项目的很多方面是“理论”,更准确地讲是需要予以评估的“断言”。“计划”本身由多个描述任务用时的断言组成。“要求”是描述适当解决方案的特点的断言。不能仅凭某些利益相关方或主题专家的判断来确定要求是否有效。甚至,需要评估这些要求,判断它们是否针对当前问题提出了合理的解决方案。
此推理引导采用这样一种软件开发风格:通过设计和开发多个可论证的系统版本,来反复验证和评估计划的断言;会客观地评估每一版本确认它是否降低了项目风险;在前一版本的基础之上构建新的版本,直至完成解决方案。
通常更多地将这种开发风格定义为迭代和增量开发,它具有以下特点:
迭代运用一组活动来评估一组断言、消除一组风险、完成一组开发目标,并逐步生成和提炼有效的解决方案。
之所以称为“迭代”,是因为它通过反复运用核心开发活动,不断增进对问题的理解程度、完善解决方案的定义和促进实现解决方案。
之所以称为“增量”,是因为每经历一个迭代循环,都可以增进对问题的了解,增强解决方案的能力。
通过连续多次应用迭代循环来打造一个项目。
真正有效的开发活动必须兼具迭代和增量特点。如果开发活动仅有迭代特点,没有增量特点,那么,虽然可以一次次地迭代执行活动,却不能朝着项目既定目标前进;换句话说,不能降低风险,也不能逐步构建解决方案。循序渐进地降低风险和稳步迈向项目目标是迭代和增量开发的品质保证。
1.软件开发存在巨大的风险,但问题到底出在哪里呢?这对于问题的解决至关重要。
1)在没有深刻理解业务需求的情况下就必须完成需求分析;
2)客户在没有弄明白自己的真正需求的情况下就被要求确定软件的业务需求;
3)在没有与客户再次沟通的情况下埋头苦干,直到完成开发并交付客户。
2.既然问题出在这里,就可以制订解决办法:
1)业务需求的分析不再是一蹴而就,而是贯穿软件开发的始终。一方面,在与客户的持续沟通中加深业务领域的理解,进而加深对业务需求的理解,另一方面,客户也在加深对软件的理解,进而完善自己的需求。
2)软件开发的过程不再是单反面的埋头苦干,而是双方的良性互动。定期的用户体验,可使用户及时了解项目进度,发现软件问题,并及时提出来予以纠正,使软件的开发不断朝着正确的方向前进。
这就是迭代式开发。它是对以往开发模式的一种革新,但不是对以往开发模式的完全否定与摒弃,而是一种改造。
以往的瀑布式软件开发模式将整个软件开发过程分为四个阶段:需求分析、设计、开发、测试。与瀑布式软件开发不同,迭代式软件开发首先将整个开发过程分为一个又一个的小段,每个小段大概在20个工作日左右,被称为“迭代(Iteration)”。一个迭代就是一个小的开发过程,如同瀑布式开发一样被分为四个阶段:需求分析、设计、开发、测试。
采用迭代式开发,就是将以往的一个瀑布,变成了数个循环往复的瀑布,使软件以进化的方式逐渐推进。
最初的迭代,开发的是软件最基本最主要的功能,经过第一次迭代以后交付给客户。这时候客户看到的,不再是虚无缥缈的需求描述,而是实实在在的软件界面。在此基础上,客户可能会认可设计,也可能提出一些改进意见。修改这些意见,开始进入第二次迭代。第二次迭代可能是在第一次迭代的基础上进一步丰富和完善功能,也可能是进一步实现其它第一次迭代还未实现的功能,之后再次交付客户。
如此循环往复,使不断在需求分析、设计、开发、测试,以及交付中,推进软件开发。这样的开发过程,注定最终交付给客户的是他们满意的软件。这就是迭代式软件开发。
迭代开发的本质是一种以团队为基础的解决问题和开发解决方案的方法。它需要各参与方(包括开发团队、客户团队和管理团队)采用多种协作技术。为了研究这种理念,需要考虑迭代开发对参与软件开发项目的最常见角色的影响。
想一想参与软件开发的角色,会发现这些角色分为三大类。
核心开发团队 这些人员关注于按照要求设计和开发解决方案,包括应用核心开发原理(架构、分析、设计、实现和测试等)开发优质组件和解决方案。
客户团队 这些人员关注于确定要解决的问题以及要构建的内容(包括更改业务流);他们必须确保完成的解决方案为委托方提供足够大的利益。
管理团队 这些人员关注于确保客户、业务和开发目标是一致的,确定问题是正确的,构建了解决这些问题的正确方案,开发工作正以高效和受控方式进行。
1.站在核心开发团队的角度分析迭代
站在核心开发团队的角度分析项目的变化。该团队负责应用开发原理生成满足客户要求的系统的发布版本,开发原理包括分析、设计(包括架构)和实现(包括单元和集成测试)。即使分配客户代表或业务分析师直接参与工作或永久加入开发团队,也认为应由客户团队提出要求。下一节将站在客户团队的角度分析迭代。
2.站在客户的角度分析迭代
为了兑现迭代和增量开发的所有承诺,您必须确保这种实践的影响超出了技术和开发社区。在理想情况下,应用的迭代实践将深入地、持续地影响到参与项目的所有业务人员,还从根本上改变了这些人描述、支付和实现商业利益(由成功开发软件解决方案带来)的方式。
如果迭代和增量开发的采用没有影响到业务,也不影响实现迭代开发解决方案提供的利益的方式。那么这种采用仅起技术保障作用,对开发团队之外的圈子几乎没什么影响。为了释放全部潜力,还必须改变项目与利益相关方的交互方式。
绝大多数迭代和增量开发文献都浓墨重彩地分析开发人员和开发团队领导者。虽然此方法对开发团队的影响至关重要,但迭代和增量开发的真正价值在于其极大地提升商业效果的潜力。为了取得这样的利益,客户代表、业务分析团队、系统的最终用户、业务领导者(赞助方)等业务人员必须积极参与到项目中来,而且需要改变他们与开发团队的交互方式。本节将分析这些变化及影响。将分别考虑这四类客户的观点,以及采用迭代和增量的变化如何对整个业务产生积极影响。
3.站在管理团队的角度分析迭代
前面介绍了在一系列迭代(专注于提供业务价值)中开展协作的业务团队和开发团队,下来需要站在管理人员的角度分析迭代,并了解这种做法的重要性。
首先,设想一个缺乏管理指导的软件开发项目(可能亲身经历过这样的项目)的场景。这样的项目通常缺少中长期发展规划,进展方向随意而为,几乎没有哪个团队成员了解要去往何方。如果没有迭代计划,将无从了解项目将在何时结束,完成项目需要哪些资源,或者何时需要这些资源。没有估算系统来帮助判断项目成本,客户和投资方只会为最小的项目注资,人们几乎不知道项目如何发展,以便达到交付解决方案的目标。
落入理想主义的陷阱将认为,如果团队致力于实现目标,将会自行组织、履行对组织的所有承诺,并快速高效地交付高质量的软件。在现实中,即便是最优秀的团队也需要进行必要的监督才能确保日复一日的工作向着长期目标迈进。更重要的是,通过管理才能将团队拧成一股绳。
缺乏管理往往是造成很多项目失败的根本原因。人们(特别是那些非管理者)很容易误认为,管理基本上就只需要一些官僚主义,管理者的职责就是保持这种官僚色彩,而让其他团队成员去努力工作。实际上,许多平庸的管理者在一定程度上也确实是这样做的;如果管理者所做的就是这些,项目将很可能失败。
管理不仅是做笔记、监督时间表和留意预算;领导力和工作方向是取得成功的基础。正确的管理为以下基本问题给出了清晰的答案。
“正在解决正确的问题吗?”
“有资源交付解决方案吗?”
“正在做正确的事吗?正在逐渐靠近最终目标吗?”
“在愚弄自己,误认为们真的可以在规定的时间内,使用分配的资源交付解决方案吗?”
规划和评测不会自行发挥作用,它们是帮助管理者回答上述问题的工具。有人会指出,优秀的管理者是怀有进取心的怀疑论者:他们找出问题并在问题仍处于管理和控制范围时克服问题。管理是一门智能预测艺术。
采用迭代和增量的开发技术不完全是技术决策,不只影响参与到项目中的开发人员和其他技术人员。它代表项目构思和进展方式的根本变革,变化影响着参与项目的每个人。迭代开发要求改变整个项目团队的工作和交互方式,其中包含改变项目管理方式。
在开发团队成员看来,迭代和增量开发赋予他们力量,使他们能使用自认为最恰当的方式积极主动地消除项目风险和挑战。通过设定清晰目标和客观度量结果(而非规定活动细节)来管理迭代,确保开发成员找到交付结果的最佳途径。
从客户和商业团队角度看,由于引入了清晰、有意义的目标,而且能够评审可演示的结果,新软件的最终使用者将在项目开发中扮演积极角色,并与开发团队共享所有权。迭代对于所有参与到项目的商业人士都有着深远持久的影响,从根本上改变了他们指定、支付和实现软件解决方案的商业利益的方式。
在管理团队看来,每个项目都分成了一系列较小项目(称为迭代),后一个迭代基于前一个迭代的结果进行构建,以循序渐进地实现宏观项目目标。这种划分方法引入了可以按标准方式加以评估的里程碑,使项目一直在正确轨道上前进,同时使开发团队能够创建具有革新意义的高效解决方案,尽量确保项目取得成功。