内容


在敏捷项目上有效地管理需求

Comments

插图为什么要写这么多不同风格,像书本一样长的关于软件项目上需求管理的专题论文,有必要吗?1 开发一种足够简单且能够简洁地表达如何处理软件需求的方法——并且还能够在大规模的,复杂的项目以及小项目上进行操作,这有可能吗?

冒险使用的这个可能会搅乱软件工程,需求管理领域的单词其实就是 过程。对这个过程的描述越简单,它就越有可能被应用到现实的软件组织中。这样就宁愿去考虑与管理软件需求相关的每种可能的优势,这篇文章阐述了这种几乎能在所有敏捷软件开发项目上良好运作的方法的实质。2 在附录中,我附加了一个阐述关键观念的具体例子。

缩减您积压需求的规模

大多数软件项目都有庞大的需求积压——通常按照数量级进行排列。一个感觉非常妙的方法是消减您当前积压的规模,使其仅仅包含 在两次发布中就可以完成的需求。您怎样知道在两次发布中能完成需求的数量呢?只需要回顾一下前一次或者两次的发布,就可以估计有多少需求可以在两次发布中完成!如果您的软件还没有发布怎么办呢?除了在第一次发布之前完成,现在已经没有时间来调整需求积压了。

小规模型需求积压最明显的优势是,它们多的不计其数。首先,一个小规模需求积压能大大增强您对客户的响应能力。这很容易理解。如果现在在您的积压非常庞大,那就需要做一个简单的价值流图3 确定一下,完成一个需求从客户那接受到反应在您的软件中所花费的时间(或者甚至包括判断它是否会一直 出现在您软件中的时间)。大量时间的浪费通常是显而易见的。

同样的,如果您的积压非常庞大,那么管理这个积压要花费(比如,浪费)多长时间?您怎样确定您的积压中什么才是真正重要的成分?规模较小且有意义的积压可以缓和这样的问题,而且还是任何需求过程的必要起点。

有效地记下需求

与仅仅简洁地记下需求相反的主要看法(例如,用户场景4) 是:开发人员,测试人员,以及其它利用这些需要生产高质量软件的人们在全面理解需求时缺乏足够丰富的内涵和详细资料。因而,有些人提议以用户场景或者其它机制的形式储存更多的资料,从而确保需求能够被完全理解。

如果这个开发组织像描述用户场景一样描述了所有的需求,那样显得太冗长,您很可能会删掉额外的文档。这就是为什么我要提倡使用用户场景。不需要更多的文档:能够确保对需求完全理解的的良好方法是:通过与终端用户频繁地交流以及通过在每次迭代(或者加速)结束时利用真实的文献与其他涉众进行交流。这样可以为开发组织提供赢得的机会以及保持获得软件如何被使用的第一手资料。

评估需求的大小

有些团队在任何开发之前都要对他们积压中所有条目的大小进行评估。这样与积压联合起来就显得十分庞大,也很浪费时间。为什么从来没有建立评估需求的工作呢?当然, 仅仅是评估需求的大小。对于许多顺利进行的项目来说,这意味着您仅仅对您打算嵌入下一次迭代中的需求大小进行了评估。 5

而对于其它项目,您可能需要对将要嵌入的多次迭代,或者从一开始 您就要负责的整个产品发布中的需求大小进行评估。参考下面这个图 1中所显示的例子。6

放开代表较早与较晚的迭代

放开代表较早与较晚的迭代

图 1:: 需求中重要的备选主题

在发布的规划中,事先确定特定的需求将会在即将到来的发布(重要主题)中处理是非常明智的做法。7 在这个例子中,这些需求将会在前三次迭代中被处理。这意味着您公司剩余的其他人————销售,市场,主管,等——可以讨论一些确定将在下一次发布中处理的关键主题。特别要注意的是,即使是在前三次迭代中,迭代演示过程中接收到的反馈可能会对这些主题在结束的发布中的实际显示效果产生影响。

这种方法可以使您的公司在开发过程中的学习保持灵活性。由于工作软件的演示是在每次迭代结束时进行的,因而可以在以后的迭代中对显示哪个 备选主题 的决定作出最高的评价。

考虑所有涉众的类型

过于单纯地考虑那些为我们制的造软件进行投资人是完全错误的。 我们不能再把这些人看作是单纯的“终端用户”或者甚至是“消费者”了,而应该从他们所代表的各种优势角度来看。 一个有四重身份的涉众,在生活中我们也用类似的角度来看待他:8

  • 负责人 就是那些为了达到特定的商业目的我们的软件投资的决定者,或者那些对决定有着关键性影响的人。.
  • 终端用户 当然就是那些在工作中部分地或者全部地使用我们软件产品的人。
  • 合伙人 就是那些利用我们的软件帮助其他人实现他们商业目的的人;例如,业务合伙人需要为客户安装,维护,或者部署我们的软件产品。另一个例子就是特定的客户 IT 商店:他们可能不购买或者不使用我们的产品,但是他们要运行产品,这样终端用户才会使用。
  • 内部人 就是在我们自己的公司与我们一起工作的人,他们可以对我们的产品提出一些建议。可能包括销售,市场,主管,法人,其他开发人员;我们工作同事中的任何人都可以对我们产品的性能或者功能提出建议。

这种类型的分类可能不会立即体现出来。这是因为通常情况下,我们这些软件开发人员除了终端用户或者内部人员外不会考虑其他人的观点。如果一位负责人正带着某个特殊的目的购买我们的软件(比如,“我的销售联系人告诉我,如果我们安装这个软件我们就可以调遣我们20%的职员”),这个软件在这方面确实能很好地实现—— 在随后的销售决定中这可能比终端用户的实际需求更重要。 类似的情况,如果您的合伙人在部署软件时十分费力——即使它的确比竞争对手的要好——他们以后可能推荐竞争对手的软件,这样他们也可以获利。因此,需求必须从四个角度来考虑,或者用一些其它的方式来看。

创建一个涉众目标的文档

有一个关键的架构——涉众的目标文档——它可能非常先进,可以跟踪我们敏捷软件项目的需求。使用这些分类只需要多考虑,而涉众的目标文档可以反映上面所描述的四个涉众类型的每个的业务目标。一个简单的可以包括涉众目标文档的表格看起来应该是这样的:

  • 项目概述 —— 对于软件特殊发布内容的概述,用业务语言而非技术语言来表述的。
  • 项目非目标—— 确定不属于 发布内容的关键需求。它可以缓和人们对特定软件发布无限大期望的问题。
  • 主要目标的满足因素 —— 需求,正如用户场景中所陈述的那样,将满足购买或者发现我们软件人们的业务目标。9
  • 终端用户的满足因素 —— 需求,正如用户场景中所陈述的那样,将有助于终端用户的工作。
  • 合伙人的满足因素P —— 需求,正如用户场景中所陈述的那样,将帮助合伙人在发布我们软件时获得成功。
  • 内部人的满足因素 —— 需求,正如用户场景中所陈述的那样,将帮助那些与我们一起工作的同事从我们的软件发布中获得利益。

我们建议最好的方法是,涉众目标文档的长度不要超过五页。下面是一个涉众目标文档的例子。

如何运用涉众的目标文档

创建涉众目标文档的最佳时间是在发布的开始。但是如果开始不能创建,那么最佳时间就是“适度地越快越好”。其中一种可能的情况是,在一个运用 Scrum 敏捷方法的团队中,产品所有者也将是这个文档思想的创造者。但是通常情况下,无论谁创建了这个文档,它都必须反映各种涉众所关心的需求,即他们希望在未来发布中看到他们所想要的用业务术语陈述的结果。

一旦这个涉众目标文档被创建,这里有如何将它运用到需求过程的方法。在开发的首次迭代结束时,将会有一个示范和反映(或者回顾)。在这个示范中,它会明智地提出关于在您软件的未来发布中会有什么,以及为什么的问题。10

在首次迭代结束的迭代反映中,这个涉众的目标文档应该被查阅和更新。哪个目标满足因素是属于负责人,终端用户,合伙人,以及内部人的?哪个目标满足因素已经在迭代演示中被揭示?用这种方法,这个涉众目标文档将变成这个团队开发过程的一部分,而这些目标将继续以业务而不是技术的角度被参考。每经过一次迭代,这个文档都应该发生类似的更新。这将会在下一次迭代的开始对这个涉众的目标文档进行彻底修改。

小结

下面这些观念将帮助团队管理他们软件项目的需求:

  • 维持积压在一个适当的大小,使这些需求可能在两次迭代就可以完成。
  • 像用户场景一样记录需求。
  • 只有在完全必要时才对需求进行评估。
  • 在不同的涉众之间区分谁会对您的软件感兴趣。
  • 将业务目标归档将会满足您的涉众们的需求。
  • 通过每次迭代末尾中不断的迭代示范和反映将会更新涉众目标的满足因素。

您可能会有很多疑问,可能会指出在这种方法的许多方面有一些额外的非常有帮助的信息。或许这毕竟可以使这本书更全面。但同时,您也确实可以您在的需求和开发工作中开始执行您自己的意图。这样我也可以知道您是怎样在实践中利用它们的。

附录:一个 Global Cooling 3.0 涉众目标文档的例子

项目概述

Global Cooling 是一个可以销售到下面这些组织的软件产品:

  • 科学研究机构
  • 政府,当地,以及国家政府处
  • 私人环境的企业
  • 在基础设施方面有巨大投资的行业被认为是与全球变暖相关的行业(例如,石化以及公共事业)

Global Cooling Release 3.0 将利用 Global Cooling 2.0 来监控来自当前各种不同格式的数据集合的状态,同时还用可控告的方法监控它的报告和展示。这就需要软件产品要根据性能来调整,从而处理高容量的数据,项目的这种能力将可能产生与关键气候数据相对应的局部影响(伴随着影响的可能性),开放的数据架构就大大增加了政府与商业组织共享信息的可能性。

在美国和欧洲,正起草大量的法律,这样就需要当前被要求执行站监控的商业实体产生极少的数据。据报道日本和印度正在考虑这样的法律,被认为是其它国家的楷模。在这个早期时刻,看起来似乎是在美国 (GC111C) 和欧洲 (TIL enhancement FGB12) 被提议的形式在被要求站监控的内容方面十分相似,但这完全不是要给在多个地域经营的企业施加压力。Global Cooling 3.0 必须足够的灵活,这样不仅可以使数据与这两个出台的标准协调,还会与其它随后提出的标准相一致。

许多站监控人员现分布在隔离的国家,那里的技术支持非常不灵活。因此, Global Cooling 3.0 需要能够根据当前站协议接受输入数据,并且利用这些相同的协议传送请求获取更多的数据。

非项目目标

这些可能非常有价值, Global Cooling 3.0:

  • 不包括合并来自高级站监控的地址灾难相关资料的能力,比如火山,地震,或者海啸
  • 不与来自麻省理工学院 (MIT) 或者加州大学伯克利分校的过时站监控协议相一致
  • 不会将北极圈内冰融化/增加的数据载入全球变冷报告中
  • 不会与我们先前的产品 Weather Watcher 7.2 或者我们的竞争产品 CoolWatch 2000 有完全相同的特征

主要的涉众

一般情况: 对于 Global Cooling 3.0 的主要涉众要分为两大类。首先,政府处将代表两个中的较为重要的一类,因为在美国和欧洲60%以上的站监控都是由政府执行的。对于委托人来说,假设他们被迫管理范围较广的软件,那么最关键的问题是他们内部 IT 工作人员的技术水平。因此,这个应用软件可以轻松地进行部署和维持,而数据集合也将成为关注的重点。对于很多政府机构来说, TCP/IP v6 和可用的需求(比如 US Section 508) 都是没有商量余地的。

其次,商业组织中的直接涉众主要关心在这个项目的实物资产中,哪些地方容易出现难题。比如,在靠近阿拉斯加州北部的地方出现了未曾预料到的冰融化,从而导致地下石油行业修改他们通往远处管道的策略。如果他们能够阻止这种变化的可能性,他们的 CEO Roger Pemsky 估算 Metroil 将可以节省8500万美元。

目标满足因素:负责人

PRI-001 一个对机构实体资产有绝对可能出现风险区域的项目。
PRI-002 利用现存的解决方案在本地客服当前的困难,从而与 TCP/IP v6 保持一致。
PRI-003 从监控点套获取报告,从而获得对天气趋势,记录的最高和最低信息,以及早期融化环境的信息。
PRI-004 获取等压线可视图,它显示了低温走向趋势,从而有助于设备开发作出决定。
PRI-005 用唯一的解决方案满足严格的可用指导方针。
PRI-006 避免将来可能由于 GC111C 和 ITIL enhancement FGB12,以及其它暴露的方式而导致的成本增加。
PRI-007 确保远程监控站在不需要现场出席的情况下可以进行更新和维护。

合伙的涉众

一般情况: 当大量的站监控专家和高级顾问被政府和商业委托人聘请时,他们会利用各种不同的工具。他们代表了一群具备良好条件的能够影响他们的客户对于购买像 Global Cooling 3.0 这样产品的决定,同时还可能了解与我们生产的其它产品相关联的综合性更强的风险管理解决方案的潜在价值,比如我们的 Obsolescence Monitoring 产品以及我们的一套物流工具。

只要这些专家和高级顾问的总成本(尤其是培训和开发成本)能够降到最低,他们很可能成为 Global Cooling 3.0 的忠实用户。

目标满足因素:合伙人

PTR-001 部署 Global Cooling 3.0 比难于部署的 Global Cooling 2.0 要节省50%以上的时间
PTR-002 减少了站监控人员的培训需求,对于新就职的员工可以从六个小时缩减到两个小时的培训。
PTR-003 确保在服务器上从 Global Cooling 2.0 迁移到 Global Cooling 3.0 只需要不到一天的时间,对于远程客户端的暂停期也不会超过十五分钟。
PTR-004 提供了样本数据,可以使基地报告和等压线视图的简单演示立即可用。
PTR-005 为远程站监控发布一 API,从而可以对私有数据格式自定义。
PTR-006 至少提供三个现实可用的,高级脚本,从而通过 API 影响数据并将报告推向 Global Cooling 3.0 主要状况页面.

终端用户涉众

总体背景: Global Cooling 的早期发布曾引起可利用性的高度关注。站监控,跟踪,以及报告通常意味着一套技术复杂的工作任务,而软件只对这种复杂性稍作掩饰。

此外, Global Cooling 2.0 操作者提出的问题与步骤的数量息息相关,比如重启远程站,以及这些活动中的时间和风险。 当远程站安装以后,通常会为用户产生一个标注情况;而且由于还没有提供一个 Web 界面,所以这通常意味着这些操作人员要赶到他们的办公室来访问这个应用软件。

最后,在最近的 Global Cooling User Community 会议上提出了一个按优先顺序排列的问题列表,这不仅是操作人员,而且系统管理员,经理,以及区域用户都可以看到。虽然小组将一些特殊问题已经按照优先顺序进行了排列,但尤为重要的是,大家一致要求减少驱动应用软件时总的按键和点击次数。

目标满足因素:终端用户

EU-001 执行一个基本的安全 Web 界面需要重新启动对方站。11
EU-002 减少输入天气跟踪参数的时间,从三个小时缩减到半个小时。
EU-003 至少减少完成地震摇晃所需要的20%的步骤数量。
EU-004 将 Global Cooling 3.0 主页面的选项数量限制在三个主要操作活动以内,通过将次要功能移到自己菜单或者利用其它的方法。
EU-005 提供一些错误信息,使系统管理员可以鉴定并秘密解决这些在远程站点故障报告中的问题。
EU-006 提高站监控和管理报告的准确度,从而更好地反映控制台时间。
EU-007 引进一个与竞争产品 CoolWatch 2000 类似的天光传感器特性,这样就可以使高温和潮湿的数据结论联系起来。

内部的涉众

一般的背景: 目前在我们的组织内部,根据像 Global Cooling 3.0 这样的产品如何能够适合我们大型软件投资组合,潜在地分为两种竞争观点。

为了支持开发 Global Cooling 3.0,我们的内部销售和市场两个组织为提高加强我们的 Obsolescence Monitoring 产品而相互沟通。虽然所做的决定完全是为了为 Global Cooling 3.0 筹备资金,但是销售和市场小组的功劳在他们的建议书中也是值得一提的——Obsolescence Monitoring 占我们当期收入的45%,因此,Global Cooling 3.0 利用它可以进行完整的开发,我们将加大维护和扩展现有客户基础的可能性。

其次,CTO 办公室认为 Global Cooling 3.0 首先应该朝着采用新架构规范的方向发展,这将成为我们下一个五年中软件工程工作奠定基础。 理想情况下,如果 Global Cooling 3.0 能够与 Obsolescence Monitoring 以及我们的物流工具相互配合,同时构建采用的新架构规范,那么 CTO 的战略方向就更有可能实现。

目标满足因素:内部人员

INS-001 提供错误信息,从而使系统管理员能够鉴定和秘密解决远程站点故障报告中的问题,比如当前的的秘密内部代码就会产生35%的错误。12
INS-002 在 Global Cooling 3.0 和 Obsolescence Monitoring 之间提供一个内部 API,从而比我们的两个关键竞争对手更能显示我们的竞争优势。
INS-003 在公共区域储存日志和跟踪文档。由于这个问题,当前日志和跟踪文档的问题复杂得难以解决,平均要花费一整天时间。
INS-004 提高易受影响功能的稳定性,因为在这个区域比软件的其它部分出现了更高错误报告率。
INS-005 在 Global Cooling 3.0 和我们的后勤工具之间建立流线型的联通装置,支持正反点击的交互。
INS-006 根据新公司的商标指导方针更改版权页。
INS-007 完成可实现的工作,从而使远程站监控包符合 section 508。
INS-008 定下 TCP/IP v6 方案,帮助更新屏幕。
INS-009 为了第三级语言的优化,使用户界面全球化。

注释

  1. 例如,Karl Wiegers,已经编写了两篇文章。 请看 Karl Wiegers, Software Requirements, 2nd ed。 (Redmond, WA, Microsoft, 2003年),以及 Karl Wiegers, More About Software Requirements (Redmond, WA, Microsoft, 2006年)。一些其它的实例包含在这些著作中, Stephen Withall 编著的, Software Requirements Patterns (Redmond, WA, Microsoft, 2007年); Ellen Gottesdiener 编著的, Requirements by Collaboration (Boston, Addison-Wesley, 2002年); Suzanne Robertson 和 James Robertson 编著的, Mastering the Requirements Process (Upper Saddle River, NJ, Addison-Wesley, 2006年); Dean Leffingwell 和 Don Widrig 编著的, Managing Software Requirements (Boston, Addison-Wesley, 2003年)。
  2. 无论是什么议题,几乎都不可能应用在每个大型项目上。然而,可以将这篇文章中所提到的观念看作是一个 “使需求变得有有价值”框架,如 Bittner 和 Spence 在 Use Case Modeling 中说的那样 (Boston, Addison Wesley, 2003年)。
  3. Mary Poppendieck 和 Tom Poppendieck 在 Lean Software Development 中讨论了与软件工程相关的价值流图 (Upper Saddle River, NJ, Addison-Wesley, 2003年); Mary Poppendieck 和 Tom Poppendieck 所著的 Implementing Lean Software Development (Upper Saddle River, NJ, Addison-Wesley, 2007年); 以及 Peter Middleton 和 James Sutton 所著的, Lean Software Strategies (New York, Productivity, 2005年)。
  4. 用户场景中最杰出的资源是 Mike Cohn 所著的, User Stories Applied (Boston, Addison-Wesley, 2004年)。 尤其值得注意的是 Mike 对于“图片”的讨论,图中显示了较大或者复杂的需求。
  5. 规划策略是评估用户场景大小最好的方法。请看 Mike Cohn 所著的, Agile Estimating and Planning (Upper Saddle River, NJ, Prentice-Hall www.planningpoker.com
  6. 这里案例是根据 Mike Cohn 在 Agile Estimating and Planning 中提到的一个案例改编的。
  7. 一个主题可以看作是一套相关的需求,或许与指令十分相似,但是在排列项上完全不同。例如,它可能非常庞大,包含更多的指令。从一个涉众,而非开发人员的角度来看,主题是最有意义的。 不要吃惊,如果您训练您自己的开发团队来用业务的角度而非单纯的技术角度来思考,那么您也会对您的涉众进行同样的训练! 我们已经花了很多年来接受他们技术上的观点,并且其中有十分令人震惊之处。
  8. 在 Carl Kessler 和 John Sweitzer 所著的 Outside-in Software Development 中,这些分类在细节上是相互关联的 (Upper Saddle River, NJ, IBM Press/Pearson, 2008年)。
  9. 正如我们在下面的样本涉众目标文档中所看到的那样, 目标满足因素 并没有如建议的那样为 用户场景 清晰地进行了标注。 涉众的目标文档有一个根本的目的:从业务方面而非技术方面,表达各种涉众对于业务的需求。而用户场景则共享相同的目标,您可以观察到样本涉众目标文档的不同之处在于,有些目标满足因素可以看作是很好的指令(用户场景的集合),而有些则直接对用户场景进行了标注。尽管在特定迭代和实践的执行过程中分解这些指令对于用户场景是非常重要的,但利益关系相关者的目标文档就不必要用这种方式来分解。对于用户场景和指令的清晰度,请看 Mike Cohn 的 User Stories Applied
  10. 要了解在整个过程中跟踪反馈的最好方法,可以在 http://tynerblain.com/blog/2007/10/25/stakeholder-value-matrix/ 中找到答案。Tyner Blain 博客的许多其它入口提供了有价值的额外背景和观点。
  11. 注意涉众的目标要么像用户场景一样渺小,要么跟指令一样庞大,都可以在每次迭代开始的规划会议上进行适当的分解。
  12. 注意确保使目标满足因素与列表上五个终端用户的保持一致。这样不仅可以了解有各种利益不同的涉众,同时还可以了解这个问题需要考虑的多个方面。

相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=360189
ArticleTitle=在敏捷项目上有效地管理需求
publish-date=12182008