2009年3月30日,星期一20:00

敏捷世界中的创作要求

撰写者

装备和赋予现代学士学位

敏捷开发的原理在敏捷(作为一种定义的方法)成为流行之前就得到了证明。 在大多数组织中,敏捷原则被不同程度地实践,作为对围绕刚性瀑布方法的问题的自然反应。

软件项目中的每个单独任务都会带来一定程度的风险。 这些风险的来源很多-某些第三方组件可能无法像广告中所宣传的那样工作,您的工作所依赖的某些模块可能无法按时提供,任务的输入内容不明确,并且您在填空时做出了错误的假设',列表是无止境的。 单个任务中的所有这些风险都构成了整个项目的风险,并且很简单,只有完成任务后风险才可以消除。 换句话说,与构建事物相关的风险实际上只有在构建事物时才消除。 这就是迭代和增量开发的原理。

因此,与其将新应用程序或增强型应用程序的首次发布推迟到项目结束之前,不如对其进行分解,以便可以逐步构建部件(功能部件)。  虽然这并不总是意味着这些部分是完整且可交付的,但利益相关者可以看到它们正在工作并进行尝试。 这具有几个优点:如前所述,它可以消除风险。 它通常还会暴露其他隐藏的风险。 这些风险将在某个时候浮出水面,越早越好。 尽早暴露隐藏的风险和消除风险可以使估算过程更加准确。 这样就增加了交付具有价值的应用程序的可能性,这些应用程序可以满足功能,预算和计划需求方面的业务需求。

尽管敏捷已成为中小型项目的主流,但在其他方面确实存在挑战,例如如何在大型项目和分布式开发中管理这种方法。   许多人面临的另一个挑战是如何将需求生命周期应用于敏捷项目。  违反“直觉而又没有更多”,“在所有需求完成之前就开始开发”,“首先测试”等许多敏捷原则可能是违反直觉的。  另外,非功能性需求又如何呢? 如何测试独立性? 如果我们不知道需求是什么,我们该如何收费?

本文试图描述一些应对这些挑战的方法。 它基于一个真实,持续且非常成功的产品开发示例,该示例使用敏捷和遍布全球的团队进行开发。 它描述了一组已知有效的技术。

工艺概述

敏捷有许多“风味”,但在较高层次上,它们基本上都遵循以下基本原则:

原理

描述

迭代式

需求和软件都是经过小的迭代开发的

进化的

的增量进化 需求和软件

足够的“需求详细信息”

定时盒装

固定需求和软件构建迭代的持续时间

客户驱动

我们积极吸引客户参与功能优先级划分

在构建需求/软件时,我们会接受更改

适应性计划

我们希望计划是错误的

随着发布的进行,需求详细信息以及宏级别范围有望发生变化。

出于本文的目的,我们的示例使用基于Scrum的敏捷流程1。 在这种方法中,迭代(冲刺)持续两周。 冲刺是一个完整的开发周期,其目标是构建最终应用程序的某些可证明部分。 应该注意的是,尽管最初的sprint确实涉及构建应用程序的一部分,但是通常这是基础结构级的软件,它需要支持在以后的sprint中开发的功能。这意味着利益相关者可能没有太多可以“看到”的东西。 

每个组织都需要确定最适合他们的冲刺持续时间。 它需要足够长的时间才能实际构建某些东西,但又不能足够长的时间使人们散焦并偏离轨道(从而浪费时间和精力)。 我们发现两周最适合我们的环境。

在该过程的第一部分中,关键是确定并就项目范围达成一致,也称为“发布积压”。 确定发布积压本身可能是一系列冲刺,产品所有者和其他利益相关者通过确定功能的相对优先级或价值以及这些功能的高成本计算来迭代发布积压,从而反复进行。  

在项目的另一端,新代码的开发不会扩展到最后一次冲刺的最后一天。 我们通常会根据发布的数量来保留最后几个冲刺,以保持稳定。  换句话说,在最后的sprint中,仅完成了错误修复,并且未开发任何新的净功能。  这在理论上倾向于与敏捷纯粹主义者的软件开发方法相违背,因为从理论上讲,每个sprint应该开发可生产的代码。 但是,要真正实现这一目标,需要进行大量测试和构建自动化,而大多数组织都没有这样做。 这始终是努力奋斗的好目标,但不要指望马上实现。

此过程中的需求定义

您可以通过多种方式在敏捷过程中执行需求定义,但是我们的目标还是要介绍一个已经尝试过并且可以正常工作的示例。  本示例首先假设您已经对“业务需求”有很好的了解,或者固有地是在一个小而团结的团队中,或者是通过对业务流程进行建模并以一种大家都理解的方式进行沟通。 因此,我们从定义应用程序需求的级别开始。

开始时的要求

从高级功能列表开始。 每个功能都由产品管理或业务分析师(取决于您的组织)确定优先级。 然后通常将这些功能分解以进一步详细说明并提供详细信息,并按文件夹分组和类型进行组织。  如果需要更好地沟通,则应创建低保真度的模型或用户界面(或部分)的草图,甚至是高级用例或抽象方案来表达用户目标。 我们有时会做这些事情,有时会不做,这取决于所表达内容的性质以及考虑与我们交流的受众。 例如,如果我们交流的是一个非常简单的概念(如何选择航班),并且我们的听众熟悉问题空间(他们之前已经建立了航班预订应用程序),那么清晰的文字陈述可能“足够”满足我们现阶段的目标。  这些目标是建立粗略估计(差异为50-100%),并基于这些和优先级,就发行的初始范围达成共识(哪些功能已投入使用,哪些功能已退出)。 

一经审查,此功能列表将成为发行积压。 然后根据优先级和开发考虑因素将功能分配给前几个sprint。

authoring1_small.png
点击图片查看大图
具有属性的示例高级功能

冲刺期间的要求

关于要求,“足够”的原则至关重要。 如果已将需求表达到足以进行交流并按预期构建的程度,那么您就完成了。 走得更远没有任何附加价值。  这意味着您将在整个产品的整个范围内获得不同级别的详细需求。 对于产品的某些部分,中等程度的细节可能“足够”,而对于其他更复杂的区域,可能需要非常精细的细节。 

在每个冲刺中,每个学科都有任务在进行。 需求,设计,编码,集成和测试任务都是针对系统的不同方面同时执行的。  在一个Sprint中定义的要求将在随后的Sprint中推动设计和编码。 最终结果是,所有这些学科在生命周期的每个冲刺阶段都是活跃的,但是相对重点会根据您处于项目的哪个阶段而变化。 例如,需求任务正在所有sprint中执行,但在较早的sprint中将重点强调它们。

在每个sprint中,高级功能都被细化为更高级别的细节。 需求的这种更详细的表达通常从使用场景/故事和/或视觉效果开始,并以模型的形式表达。 这些模型可以强调用户界面,用例,场景,业务规则以及它们的组合,具体取决于所表达内容的性质。 有时这些是协作创建的,但根据我们的经验,通常是一个人创建一个初始版本,然后与他人进行审核以获取反馈。  在我们的案例中,通常由产品经理和/或业务分析师来创建这些模型,并且通常与开发人员,测试人员和其他利益相关者进行一到三次审核。 该审查具有多个目的,包括:

  • 为了促进知识向所有利益相关者的转移,包括建筑师,UE设计师,开发人员,测试人员和执行发起人
  • 为了让架构师,UE设计师和开发人员评估可行性
  • 确定需求中是否有足够的细节以允许进行开发

使用适当的技术,可以从需求自动生成与需求100%一致的测试中生成测试,并能够立即测试在sprint中开发的代码。

持续和适应性计划

使用这种方法,可以在整个生命周期中进行连续且自适应的计划,从而可以根据每次冲刺期间发现的新发现重定向资源。 这种在飞行途中进行纠正的能力使项目具有“敏捷性”。  在每次冲刺结束时,我们都会评估在冲刺过程中取得的成就并记录实际进度。 在此基础上,还可以根据测试结果,测试结果,对该Sprint的构造进行审核的反馈,任何新出现的风险或问题或已淘汰的其他问题以及业务条件的任何外部变化,根据需要调整下一个Sprint的工作。 估计和优先级将相应调整,并对发布范围和冲刺计划进行任何更改。 通常,我们在冲刺过程中尽量不要进行飞行中的重大修正,这就是我们喜欢两周冲刺的原因之一。 如果冲刺是四个星期,那么我们将失去敏捷性。 同样,两周的冲刺比四周的冲刺更容易,更准确地估算。

authoring2_small.png 
点击图片查看大图
带有任务和估算值的示例故事

关于需求,对于分配给sprint的那些功能以及任何高级需求模型,开发人员会为特定功能创建高级目标并进行估算。  目标表明,在一次冲刺期间,他们将尝试构建功能的哪些方面,因为认识到一个冲刺通常不足以实现整个功能。 该功能及其高级目标成为“故事”的内容。 一旦定义了故事,开发人员便会详细说明并估计在接下来的两周内要为该故事执行的任务(冲刺),并继续进行开发,在敏捷的项目管理工具中跟踪这些任务的每日进度,并涵盖项目中的问题。每日混乱。

非功能需求呢?

各种敏捷方法已经发展了多种技术来表达系统功能。 这些是诸如用户故事,用例或使用场景之类的事物,它们代表“可观察到的系统行为和为用户提供价值的工件”,如屏幕,报告,规则等。  这些功能要求表达了系统要做什么。 例如“生成库存报告”,“预订汽车”,“注册网络研讨会”或“提取现金”。

与系统功能相关的是其“质量”。 这些表示系统应该“完成”什么工作-快,快,可靠,可用等等。 有时,这些非功能性需求与某些功能性需求相关联,而有时它们会应用于系统的整个部分或整个系统。  那么在我们的敏捷过程中如何考虑这些非常重要的要求呢?

它们以文本陈述的形式在高层表达。  For example: “任何预订交易都应由用户(按照a节中的定义)在不到三分钟的时间内(95%的时间)完成”。 

随着功能需求的分解和推导,任何相关的非功能需求也应类似地分解,推导并关联到较低级别。 例如,以上性能要求与所有“预订交易”功能要求(预订汽车,预订航班,预订酒店)相关联。 如果将功能需求分解为较低级别的需求,例如“选择汽车”,“选择租赁选项”和“退房”,则可以将非功能需求分解为少于30的汽车选择需求秒,不到一分钟即可选择选项,不到1.5分钟即可签出。

在审查会议期间,功能要求占据中心位置。 但是,在进行这些审查时,也需要提出和审查任何相关的非功能性要求。 通常依靠可追溯性来识别它们。与故事的功能需求相关的任何非功能需求都需要作为故事的一部分来表达,因此开发人员可以在开发过程中将其考虑在内。 

质量检查人员需要创建测试以验证所有需求,包括非功能需求。 有时,在功能完全实现之前,可以对非功能性需求进行部分测试或对趋势进行测试,但通常直到功能完全实现(可能需要数次冲刺)才能完全测试非功能性需求。

那测试呢?

敏捷过程中的高度并发性意味着在生命周期的每个冲刺中都进行测试。 与传统方法相比,这可能是一个很大的变化,并提供了许多好处。 首先,随着测试人员尽早介入,它倾向于营造更加协作的环境。 当然,这也意味着直到生命周期后期才被捕获的项目会以较便宜的价格被早期捕获。

在敏捷中,产品负责人在测试过程中扮演着非常重要的角色,他们在整个开发生命周期中都扮演着重要的角色。 尽管许多传统方法通常将需求规范作为产品所有者的“代理”,但敏捷更直接地依赖产品所有者,有效地绕过了由不完善的规范引起的许多问题。 除产品所有者外,开发人员还进行测试。 测试驱动的开发是开发人员在敏捷方法中使用的一项杰出技术,在该方法中,测试是预先编写的,可用于指导应用程序编码以及执行自动测试,从而有助于代码的稳定性。 为了增强测试驱动的开发,该开发主要侧重于开发人员完成的代码级测试,可以根据功能需求自动生成功能测试的新技术 使质量检查团队能够根据与需求规范不“不同步”的测试用例进行功能测试。 由于可执行代码和测试用例在整个生命周期中都可用,因此这使QA团队可以连续进行测试。 在我们的示例中,所有三个职位(产品所有者,开发人员和独立的质量检查人员)都是连续工作的。

在本示例中,我们开发的需求是高级文本语句的分解,并由更详细的需求模型增强,这些模型对要构建的内容进行了丰富的表达。 需求审查基于这些模型的模拟,由于多种原因,它们具有不可思议的价值。 首先,正如通过为利益相关者可以看到并与之交互的每个sprint生成工作软件提供巨大收益一样,模拟可以使利益相关者更加频繁地查看“虚拟”工作软件并与之交互。 第二,今天人们经常创建原型,试图做很多相同的事情。 但是,与原型的不同之处在于,为需求定义而构建的仿真引擎是基于用例或场景的,因此可以指导利益相关者如何实际使用未来的应用程序,从而为需求审查会议提供结构和目的。  另一方面,原型(包括简单的交互式用户界面模型)只是“存在”的部分系统,并且不提供有关如何使用的指导。 利益相关者必须尝试自己发现这一点,而永远不知道自己是否正确或是否错过了某些事情。 重要的是要注意,在生成这些模型时,“足够多”的原则仍然适用。我们依靠与设计师/开发人员举行的需求评审会议来确定何时“足够”。 这种方法产生了很高的质量要求,正是根据这些要求自动生成了测试。 实际上,在没有自动生成测试的情况下,以如此快速的速度进行彻底的测试是不可能的。

尽管我们努力在每个sprint的末尾都提供可交付的代码,但这个目标并不总是可以实现的,我们可能需要使用最后一个sprint来稳定代码。 由于在这些最终冲刺之前已经进行了连续测试,因此进入稳定阶段时该应用程序的质量已经相当高,这意味着风险是可控的,很少错过发货日期。

估计呢?

请记住,敏捷通常是固定在时间,功能和质量三者中的“时间”。 在我们的方法中,还请记住,通过连续测试和保留最终的冲刺以保持稳定,质量也往往是众所周知的。 这会将功能保留为变量,因此我们实际估计的是将要提供的功能集。 

与往常一样,估算的准确性是几个因素的函数,但我将仅关注三个因素

  • 您必须基于估算的信息质量,
  • 您估计的固有风险,以及
  • 您可以借鉴具有代表性的历史示例。

在我们的方法中,从最初的范围界定冲刺开始,在整个开发周期中进行估算。 如前所述,一旦候选特征列表已知并以高(范围)级别表示,便对其进行估算。  很自然,在这一点上,估计将是项目生命周期中最“不准确的”,因为需求没有被分解为详细级别(信息质量)。这意味着要完成的工作中仍有很大的风险。 过去完成的类似项目可能有助于减轻这种风险,并有助于提高估算的准确性(例如,我们已经完成了十个这样的项目,它们的结果相当一致)。  

初始估算是范围界定和冲刺计划流程的关键输入。  随着项目的进行,每次冲刺都会暴露和处理风险,需求会分解为更详细的细节,并且估算自然会变得更加准确。  您可能会猜到,估计是在每个冲刺结束时进行的,并用于未来冲刺的规划中。

分布式团队呢?

如今,分布式开发已成为常态。 出于效率,降低成本,增加技能或减少能力的原因,分布式开发和外包已成为现实。 但是,没有免费的午餐-与这种方法相关的成本,其中许多成本都在需求生命周期中承担。 其中最主要的是“沟通”。 有一些实践和技术可以缓解此问题,从而可以实现分布式开发的预期收益。 例如,我们在这里研究的方法使用以下方法,并且非常成功:

  • 齐心协力实现更频繁的沟通(每日打扰和其他预定的每日通话)
  • 通过网络会议技术自由使用需求模拟
  • 通过中央服务器直接访问共享需求模型
  • 自动生成测试并根据要求进行检查,以证明产品需要提供的另一种观点。

结论

“您是否听说过英格兰正在改变其交通系统以在道路的右侧行驶? 但是为了简化过渡,他们决定逐步实施- 他们将从卡车开始”。

开发组织从瀑布式转向敏捷的一个常见错误是,他们的组织 要求他们仍然制作大量笨重的文档,并按照相同的里程碑对其进行审查,并坚持使用这些熟悉的资产(如安全毯)。没用 似乎令人恐惧的是,该方法的所有重要方面(如文档)都必须统一更改才能成功,而需求就是这些重要方面之一。 

但是,如果您仍然希望获得安全防护,并且希望从敏捷中受益,那么至少要以敏捷的方式(迭代,演进,限时,客户驱动,自适应计划)生成您的需求规范,其中包括通过使用集成和驱动的模拟案例追溯到功能。 这是在不立即实现飞跃的情况下获得一些敏捷优势的一种方法。

风险是软件项目的“敌人”。 项目的高风险状况会带来不确定性,使估算不准确,并可能破坏最佳计划。  敏捷的一大优点是其高度迭代的特性不断“翻过石头”以尽早且经常暴露风险,因此可以对其进行处理。    

另一方面,对于规模较大且分散的团队来说,最大的挑战之一是在逐个冲刺过程中进行路线更正时,使每个人保持一致。  其中很大一部分是生产和更新资产所需的时间和精力,以及不完善和紧张的通信所造成的延迟。好消息是,现在存在工具和技术可以自动生产许多资产,并且还可以极大地提高通信效率,从而实现敏捷扩展。

通过正确的方法,技术和技术,可以实现分布式敏捷。  We've done it.  So can you.


托尼·希金斯 是副总统  Blueprint产品营销部门的负责人,该公司是业务分析师的需求定义解决方案的领先提供商。 Blueprint被领先的分析公司Gartner任命为应用程序开发的“凉爽供应商”,并获得了设计和建模卓越卓越的设计奖,Blueprint通过提供专为业务分析师设计的业界领先的需求套件来使业务和IT团队保持一致。可以在到达Tony [email protected].

参考文献

1  The Scrum Alliance   http://www.scrumalliance.org/

2 在敏捷团队中定义需求的方法
Martin Crisp,从2009年2月21日从Search Software Quality检索, 
http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1310960,00.html 

3 超越敏捷项目的功能要求
斯科特·安布勒(Scott Ambler),2009年2月22日从多布博士的门户网站检索, 
www.ddj.com/architect/196603549

4 敏捷需求建模
Scott Ambler,于2009年2月22日从敏捷建模中检索, 
http://www.agilemodeling.com/essays/agileRequirements.htm 

5 敏捷软件开发的10个关键原则
从All 关于 敏捷 (2009年2月22日)检索, 
http://www.agile-software-development.com/2007/02/10-things-you-need-to-know-about-agile.html

6 敏捷需求方法
Dean Leffingwell,2002年7月,《理性边缘》         

7 要求诚实
巴西利亚大学的弗朗西斯科·A·C·皮涅罗

8 赢得比赛的需求文件
柯斯汀·科勒(Kirstin Kohler)&Barbara Paech,德国弗劳恩霍夫研究所

9 使用敏捷方法设计不稳定的需求
卡内基梅隆大学James E. Tomayko

10 通过需求协商对XP进行补充
保罗·格伦巴赫&克里斯蒂安·霍弗(Christian Hofer),约翰内斯·开普勒大学,奥地利

11 及时需求分析-推动计划游戏的引擎
迈克尔·李(Kevera Enterprise Solutions Inc.)                                                            03/09

©BA Times.com 2020

麦格雷戈徽标白色网站