在协作生命周期管理的帮助下的精益软件开发方法

消除浪费时间并使用 CLM 与集成的 Rational 软件

由精益软件开发原则启发,本文讨论的是在协作生命周期管理(Collaborative Lifecycle Management,CLM)IBM Rational 解决方案的帮助下,如何查看、删除,并最终预防消耗时间的多种方法。

Paula White, 顾问信息工程师, IBM

Paula White 照片Paula White 一直在软件开发领域工作了十九年多。她担任过架构师、软件工程师、培训师、实践指导和咨询师。在 IBM 中,她目前担任 Rational 架构师和协作式生命周期管理(CLM)、架构管理、需求和资产管理的技术专家。在工作之外,她喜欢与家人一起逛花园、听音乐和骑脚踏车兜风。



Steve Arnold, 高级技术顾问, IBM 

Steve ArnoldSteve 与他的妻子和小女儿一起住在伦敦的 Twickenham。他自从 2000 年以后,一直是 IBM Rational 的一名技术顾问,他是一名认证 Scrum 专家,专长于敏捷项目交付、建模和基于模式工程。工作之外,他喜欢与家人一起,以及研究、教习和联系太极拳。他写过几篇文章,涵盖了 Rational Software Architect V7.5 和 V8 的最新特性,还有一些文章,讨论 Rational Software Architect 的不同扩展、Rational RequisitePro 和 Rational Team Concert。


developerWorks 专家作者

2011 年 11 月 21 日

精益 开发是一种文化;降低消耗量就是其中的一个结果。减少消耗量可以提升操作效率,但是比这更重要的在于,它支持更短的开发周期,因此对客户提供了使用的价值。减短的开发周期提高了市场的完整性和响应性。它们还为开发团队的学习和持续性改进提供了一种有价值的机会。

尽管本文关注的是基于 协作生命周期管理(Collaborative Lifecycle Management,CLM) 的 IBM® Rational® 解决方案是如何帮助您降低成本的,但记住对于人们来说它只是一个工具,这一点十分重要。面对面地交流 —— 一起思考产生问题的根源 —— 才是精益文化的关键方面。

确实,丰田老总说精益管理的两大支柱,一是持续性改进,一是尊重员工:

“[丰田系统]的实质在于,赋予每一个员工用他们自己的方式找到问题的机会,以解决问题并作出改进。”—— 在 《丰田公司持续成长管理原则的思想》 里面

本文不会详细讨论精益方法对软件开发行业所带来的哲学,思考以及影响。如果您想详细考虑,我们推荐您阅读 《精益软件开发:软件开发管理的一款敏捷工具箱》 ,作者是 Mary Poppendieck 及 Tom Poppendieck(参见 参考资料)。

我们使用以下作者所定义消耗量类型来安排文章的结构:

等待
花在等待上的时间,这是软件行业中最大的时间消耗量。此时您可能要等待其他人员完成某项工作,而这通常是由团队之间的交接导致的。
 
移动
人员和工件移动所花费的时间。主要专家访问需要多长时间?客户需要多长时间?开发员是否能够找到测试的结果,而不用从一个办公室走到另一个办公室?文件在哪里?交接是如何管理的?
 
额外特性
花在实施一些解决业务问题不需要的操作所浪费的时间。
 
任务切换和交接
在大量的任务之间切换所花费的时间,[因此] 浪费时间切换背景和重设环境,更不要提这将会产生更多部分完成的工作。向多个项目分配人员是消耗量的主要产生源。
 
部分完成的工作
如果实例或者用例场景尚未完成,而且没有缺陷,然后它就拥有少量价值,或者没有价值。您不可能知道工作是否在产品环境之中,或者它是否对业务提供了价值。
 
额外进程
以下不需要进程所花费的时间,或者由于您必须重复一些不必要操作,或者创建不必要任务所浪费的时间。额外的文书工作就是潜在额外过程的经典范例:该文书工作是否确实对客户提供了价值?
 
缺陷
缺陷会阻止工作完成所造成的消耗。同样,还有修复缺陷的工作量,特别是缺陷的数量在不断增长,而项目需要极大的技术支撑时更是这样(查看接下来的 Defects 部分)。缺陷越早发现和修复,产生的消耗量就越少。
 

本文关注的是关键的 Rational CLM 功能是如何处理这些时间消耗的,包括产品的列表。个人产品不会得到引用,因为本文的目的在于关注 CLM 的整体功能,以帮助解决特定的问题。我们推荐您在 Jazz.net 及 IBM.com 上查看优秀的资源以学习关于产品本身的更多信息(参见 参考资料):

  • IBM® Rational® Asset Manager
  • IBM® Rational® Quality Manager
  • IBM® Rational® Requirements Composer
  • IBM® Rational Team Concert™

您可以不按顺序直接浏览自己感兴趣的资源。评价价值链和缺陷部分特别有用,因为它向您提供了一些工具以分析和思考一些进程,缺陷就是一个范例。所以如果您只阅读一个或者两个部分,那么我们建议以下的两个。

等待

有大量的消耗时间可以归因于等待。这通常是因为团队和机构不会根据工作对相互之间的影响而安排优先级。而这又是因为团队或个人没有一个简单的方式来理解哪些方面的工作会影响到其他工作。混合方法通过基于妨碍因素的日常独立会议来解决这个问题。但是,对于地域上分散的团队来说,很难推广使用这种方法。

协作生命周期管理的 IBM Rational 方案或者 CLM,为减少团队和个人相互等待造成的时间消耗量提供了一些关键性的特性。首先,这是将任务标记为其他任务所阻碍的任务的一个简单进程。然后团队和个人会监视三个方面:被阻碍的任务,阻碍别人的任务,以及最近尚未阻碍的任务。

图 1. 阻碍的任务
被阻碍的任务,阻碍别人的任务,以及未阻碍的任务

该方法可以极大地提高阻碍其他团队和个人工作的可视性。而这种可视性就是让团队自我组织以减少等待时间的第一步。在程序或者项目的层次上,监视阻碍任务的数量就成为可能的了。在团队操作板上拥有可视性,可以帮助他们学习和适应各自的方法以将阻碍性因素降至最低。

图 2. 团队阻碍的任务
显示团队阻碍工作项的条形图

在开发之中,有可能处理的任务得到中断,而且没有进展。在这种情况之下,可以暂停一个任务。它允许存储所有与任务相关的代码变更。在暂停一项任务之后,开发员就可以处理另一项任务了。当原始任务不能锁定时,开发员就可以恢复原来的工作了(如有需要,还有来自原始任务更改的合并)。

开发员可以保持大量暂停的变更或者 变更集。(一个 变更集 就是囊括了相关文件,文件夹及构件变更的储存库对象,这样它们就可以应用到一个流程目标上,例如单个操作的工作区或者流)。但是,不用走的太远,因为每个暂停的变更都代表未完成工作形式的消耗,但是如果开发员开始处理有价值的工作,那么这种形式的消耗就不值得关注。这就是回顾起来暂时需要的消耗的一种范例。

最后,评审工件还可以产生大量等待消耗量,因为继续工作之前操作者通常需要等待评审过程完成,而他们可能会花大量的时间催促人们完成评审。通过集中和自动化评审,CLM 使得操作变得更加轻松。这意味着评审的工件(需求,设计,代码,软件资源)可以分配给评审员,而他们的评论会按照简单的方式被获取和实施。评审员会自动得到评审的通知和提醒。任意时刻查看评审的状态也成为可能。这使得理解需要催促什么人来完成一项评审,或者哪些评审项目正在产生问题变得更加轻松。这种方法可以从评审工件的过程中去掉大多数的时间消耗量,包括移动时间消耗还是等待时间消耗。

图 3. 通过在线评审来节省时间
部分完成评审状态的屏幕截图

移动

当人们需要时间进行物理上的移动时,就会产生移动消耗了。例如,如果一个业务分析员一天需要上下楼梯两三次以会见业务专家,那么就会产生移动消耗了。在移动消耗与额外进程消耗之间,还存在较强的联系。另外一个范例:参加并不需要的会议,或者只需要出席一小段时间的会议,团队成员会增加他们的移动消耗时间。这不但会浪费时间,当人们参加会议之后重新转移注意力,也会产生来自任务切换的时间消耗。

降低移动时间消耗的一种方法,是改善项目工件的可视性,并改进团队成员与涉众之间的协作。通过让任意类型的开发工件联系到一起,CLM 可以实现这一点。涉众和团队成员可以通过网络浏览器来查看这些工件(以及关于它们的信息)。然后他们可以从自己的桌面上访问几乎所有项目,而不是参加各个会议评审工件和信息。这减少了大量的移动消耗时间,并改进了不同地域位置之间人们的协作。

现在,因为可以通过浏览器查看所有方面的项目,所以就可以编辑操作板以查看管理员及涉众想要看到的信息。这反过来提示了业务的敏捷性,因为涉众可以在任何他们愿意的时候查看项目。它还降低了团队和团队领导的时间消耗量,因为可以减少花在会议之上的时间。

图 4. 在网络浏览器中显示团队进程
显示私人和团队进程的项目计划

能够访问这些数据,可以减少花在状态会议上的时间。在一些项目之中,这些时间可以降至一半,因为团队可以只关注状态报告的黄色(注意)以及红色(警告)。开始时可能会感觉到一点不舒服,因为数据是真实的!这可以改进决策制定的质量,并使得花在收集数据上的时间最小化,因为状态更新是由 CLM 自动化的。


额外特性

“额外特性”听名字就知道它是多余的。当然,如果特性并没有向业务提供价值,那么开发该特性就变成多余的了。人们甚至都不会使用到它。更为重要的是它们可以对功能产生的延迟,会向客户提供真正的价值。当然,更多实施的特性也意味着更多缺陷的潜在来源,以及在发布之后需要维护更多的软件。

所以我们怎样才能确定我们创建的是额外特性?有一些方法可以帮助您减少额外特性:

  • 拥有一个清晰的视图
  • 涉及到多个涉众的活动
  • 从大型文本文件转移至可视代表,并使用基于场景的需求定义(参见图 5)。
  • 延缓具体的规格,直到实施冲刺为止
  • 创建脱线需求的备份以加入到适应性迭代规划方法,以首先实施重要的需求。

在本文中我们并没有详细介绍所有的方面,所以请查看 参考资料 部分以得到更多信息的链接。但是,大多数的方法都拥有一个共同点,就是将注意力从 遵循 完整的需求规格,转移至只选择交付向业务提供重大价值的需求,从需求到交付的周期越短,意味着根本就不用实施额外特性。

图 5. 可视场景帮助理解
可视和多文本定义的技术

CLM 支持定义来自用户事例或者用例,事例板,UI 草稿,进程图,文本,图形,甚至音频或者视频多种形式的特性。涉众不但能够发现最近什么是新的,什么更改过,它们还可以发现关于外部性工件和内部性工件相关的广泛需求。例如,用户事例是如何看屏幕混合的?在我们的经验之中,使用广泛的可视技术极大地提高了成功的可能性,因为人们理解起来会更加容易。它如何影响日常工作变得更加容易。

正如 Motion 部分中所提到过的那样,拥有单个的储存库能够被所有相关的涉众在线查看,加上大量的机理,使得找到与每一个个人相关的内容变得非常轻松(例如操作板,标记和筛选规则),人们找到与他们相关的内容变得更加容易。涉及到大量的涉众是没有价值的,当这些涉众是业务部门或者客户时更是这样,因为他们可以提供关于功能已经如何有用的回馈。

最后,特性中 CLM 可以获得极大的优势,它可以轻松集成到敏捷开发计划之中,然后可以首先实施最高优先级的特性,因此向业务或者客户端交付很多利益。

总体而言,透明性,协作和背景可以帮助您理解特性。反过来,这又改进了决策制定的质量。优先级从遵循移动至规格,以确认来自大量涉众的特性的价值,并使得实施关键特性变得更加轻松。


任务切换和交接

任务切换和交接是相似类型的消耗。由于 任务切换 造成的消耗是由开发员部分完成了代码和功能,然后进行交接造成的。在可以开始操作新功能之前,开发员可能必须浪费时间以删除所有原始的代码更改。

许多私人写成的书籍(例如 完成工作明天完成以及时间管理的其他秘密 )都强调多线任务不会加快进程。如果您有两项任务要完成,那么一件一件地去做会更快,而不是同时去做两件事。敏捷开发团队遵循这个原则,以最小化一次实施操作的数量。

在一个理想的世界中,有有限的任务切换。管理人员和其他资源的方式,可以帮助您将消耗量最小化。例如,没有忙的团团转的团队,所以他们不用同时涉足到不同的任务之中。同样,按照顺序操作项目,而不是让个人或者团队一次参入到多个项目,可以有效地改善一些任务切换问题。

但是,如果需要进行任务切换,那么 CLM 可以帮助您解决这个问题。将任务切换造成的消耗最小化以加快进程,变得更加轻松,因为所有的工件相互之间都是联系的(业务进程,需求,论坛,评审,注释,测试,设计,编码,规划,以及涉及到的人员)。这赋予他们一定的背景,并缩短了从一项任务转向另一项任务所需要的时间。

CLM 向任务切换提供了有效的支持,因为所有的工件都存储在 CLM 储存库之中。首先,我们会将所有的文件更改(不管更改是针对代码,设计,还是文件)与一项任务相联系。然后我们会将那些变更作为变更集管理。最后,我们允许开发员处理暂停一系列变更的工作(参见图 6),在开始变更之前这会将所有的代码转化为其状态。这意味着开发员可以一次性地并发处理多项代码更改,对私人工作需要极小的工作量。很显然,按这种方式工作并不是理想的,但是如果您一直等待,直到一些其他的工件可以进行编辑,那么这也向您提供了一种方法最小化等待消耗时间,同时使得与任务切换相关的消耗降至最低。

图 6. 暂停变更集以节省任务切换时间
暂停变更集的暂停变更视图

交接会以数种方式引入消耗。在一个理想的小敏捷项目之中,您有小的交接,因为团队成员要扮演所有的项目角色(编写实例,开发代码,测试,等等)。但是对于大型的项目,或者对于没有多种技能的个人,交接就成为必需的了。由于以下几个原因交接可以会引入较大的时间消耗:重构工具或者团队之间的信息,等待 消耗,因为团队成员没有意识到有些事情已经就绪,缺乏足够的具体,过时的工件,或者团队之间不能进行成功地交流更改。

CLM 允许来自各个团队的成员查看信息,并通过 RSS,电子邮件列表,或者网络中的视图遵循其他团队所作的更改(我们意识到,对于一些项目或者机构来说,能够访问所有项目不是合适的,这样 CLM 就可以提供其他的访问控制选项)。

例如,

  • 需求团队可以查看什么需求被转化为运行,测试代码(参见图 7)。
  • 开发团队可以追踪测试团队所报告的新缺陷,并更改需求,以及轻松规划工作以实施新需求并修复缺陷。
  • 测试团队可以看到什么需求被更改了,什么需求为测试已经做好了准备,以前中断的哪些测试为重新测试,以及轻松规划测试活动做好了准备。
图 7. 需求状态总结
显示需求,工作项和测试用例

图 7 的大图

通过让信息更轻松地显示和访问,就可以极大地降低 交接额外进程操作 上所花费的时间,因为团队成员拥有他们需要的时间(参见图 8)。他们可以访问信息,而不用干扰其他的团队成员以更新状态。

图 8. 显示其他团队即时更新的操作板
需求和开发更改的视图

项目与后续阶段之间的交接

前面的部分关注于怎样在项目 之中 降低成本。现在这部分更多地关注项目,构件及第三方 之间 的成本。在这一层中总共有若干种类型的成本:

  • 一个程序会转化为拥有少量开发构件的支持团队,例如需求,设计和测试。这需要支持团队在可以提供满意的支持之前,先行考虑团队是如何发挥作用的。
  • 暂时尚未涉及到的程序需要得到升级,但是有时不能找到原始的需求、设计、测试,甚至代码。
  • 一个程序拥有特定非功能性的需求,该需求可以在公司的任意位置解决问题,但是找到拥有其他需求的程序就变得更加困难,以找到用于解决问题的设计和代码。

软件 资源管理 可以帮助解决这种类型的问题,并降低不能在正确的时间内找到正确信息相关的成本(资源可以用作存储任意类型的工件、背景、元数据,例如代码、文本脚本、服务定义、引用结构、业务模型等)。特别需要指出的是,使用 IBM Rational Asset Manager,通过允许人们使用混合的规范类别,标记及文本搜索,可以降低搜索已存在资源所需要的时间。该方法使得找到高质量资源,并将它们下载到桌面或者开发环境中以便使用变得非常快捷。

通过使用 IBM Rational Asset Manager 作为所有软件资源的定义库,您就可以解决项目和程序层次上交接时产生的成本和无效问题。它为所有的项目文件,代码及工件提供了单个的端口,这样支持团队就可以通过该软件访问所有的开发信息了。这使得快速找到开发工件以维护系统变得更加轻松,而团队就能够快速识别其他的项目,这些项目可以解决相似的问题,并再使用他们的解决方案以节省时间。

图 9. Rational Asset Manager 可视浏览视图
CIM 项目及相关的资源(图)

部分完成的工作

部分完成的工作 是对尚未实施特性所投入的努力。使用瀑布开发方法将会产生大量部分完成的工作,因为大量的时间会花在改善需求和设计之上。这会导致没有可用的工作软件,直到周期的晚期才会改变。这就是为什么团队机构会转向使用迭代方法,这样他们可以更快地完成工作,并考虑部署它们以在不久之后就可以发挥作用。

就算您使用的是迭代性方法,但是由于部分完成的工作所产生的成本仍然值得您考虑。在一个迭代过程之中,如果关注的是完成每一个实例或者有限的实例(或者特定的用例场景),团队一次尽可能少地处理实例。这将会限制部分完成的工作,并意味着有些完成的代码会在迭代或者冲刺阶段进行交付。如果团队的工作会在所有的实例之间扩展,那么现在就有测试会在开发周期的晚期阶段才会进行的风险,而团队在该迭代中可能不会交付任何新的功能,因为缺陷会在晚期被发现,而且就没有时间修复缺陷了。

CLM 可以在以下几个方面发挥作用:

  • 首先,通过使用 Rational CLM 的敏捷规划任务板(参见图 10),如果有大量部分完成的工作,那么就会立即显现出来。
图 10. 显示部分完成工作的敏捷规划任务板
显示处理多个实例的屏幕截图
  • 第二,CLM 可以帮助团队安排大量的开发员处理相同区域的代码(当您试着将部分完成的工作量最小化时,就需要这种功能)。在这种协作性方法中,每一个开发员都得到一个沙箱。这意味着代码可以独立开发,而不用相互影响。但是,如有需要它还向开发员提供了一个机理以相互交付,这样他们就可以构建自己的工作,而不用与整个团队共享。这种灵活性支持亲密的协作,以减少一个项目之内的部分完成工作量。

额外进程

额外进程 就是对向用户交付价值不会产生作用的多余进程。例如:产生没人阅读,更新计划,手动收集工具和进程的文件,组织没人响应的评审,等等。

如果进程没有向客户提供价值,那么就有在没有利益的情况下添加进程的风险。更糟糕的是,如果它延迟了对客户的 价值时间,那么它可能会达不到目标。

那么 CLM 是怎样帮助您的呢?您可以配置 CLM 以执行公司的进程,这样可以通过进程来指导该团队。有时工具使得遵循一个进程变得更加困难,因此增加了消耗量。但是,在这种情况之下,它意味着与不遵循进程相比,遵循进程可以简化程序和操作。CLM 执行进程的范例可以是团队实施。如果不满足标准的话,CLM 可以阻止代码被交付。

如果团队发现一些进程的元素对他们无用时,那么 CLM 还赋予了他们重写进程的灵活性。所以在前面段落的部分之中,团队可以决定他们需要更高层次的特定构件覆盖面,或者提供是否增强规则的灵活性。

正如 Extra 特性中所描述的那样,CLM 支持定义需求的方式,它不再关注大的文件,并等待以具体定义特性,直到实施的迭代时为止。它还支持编写客户测试,作为具体需求定义的替代。

最后,团队使用他们的回顾以分析进程,并决定可以更改什么以提高效率。通过收集所有任务之间的数据,然后提供分析这些数据的功能,CLM 会帮助您进行操作,以决定是否有不会增加价值的进程(参见接下来关于价值链和评价成本的部分)。


缺陷

缺陷会产生两方面的成本:修复缺陷产生的成本,以及软件不能正常发挥作用所产生的成本。通过提高需求的质量,CLM 有助于降低缺陷的产生率,还有助于减少解决缺陷所需要的时间,这样就可以尽可能少地产生成本。搜索,修复,和解决缺陷的过程又叫做 缺陷价值链。这会产生大量的成本,因为它需要若干个团队或者机构进行亲密无间的协作(接下来的部分将会讨论怎样评价您自己公司的价值链)。

CLM 通过提升缺陷价值链的效率来支持精益软件开发。对于敏捷团队来说,这一点很重要,因为他们不应该声明拥有重大 缺陷 的实例点(意味着代码尚未完成仍在进行中,在精益软件开发之中不愿意看到这一点),所以在一个冲刺阶段他们可以快速找到和解决 缺陷,这一点很关键。(实例点 是估算用户实例复杂性的混合单元)。实际上,对于所有团队来说它都很重要,因为拥有足够的缺陷解决过程,对于确保软件开发期间技术能力达标来说十分关键。

例如,在丰田公司,人们并不是仅仅为快速修复缺陷而努力,而是理解问题产生的根源,这样就可以避免在将来产生同样的错误。在其著名的“”实践中,当发现一个缺陷时,可以立即停止整个生产线以修复它。其目标在于减少后续工作的工作量。对软件开发应用该原则,那么一旦构建终止,那么就应该快速修复缺陷。

CLM 有助于实现不同团队之间交接的自动化。通过降低手动交接期间所需要的时间,可以对总体进程效率有极大的提升。

图 11. 使用 Rational Quality Manager 与 Rational Team Concert 检查缺陷工作流程
显示修复缺陷的任务

使用 CLM,在测试员报告一项缺陷时,信息会出现在开发员接受工作的 IDE 框中。假设这是可以得到立即修复的重大缺陷,那么开发员可以暂停单个操作的所有并发工作,载入发现缺陷的基线,并开始修复缺陷。当缺陷得到修复时,开发员可以重返以前的工作,精确地回到以前停止的位置。在修复和构建代码之后,测试员会注意到新构建修复的基础之上,可以返回什么测试。这种方法意味着该团队可以快速解决缺陷。而且,等待任务切换 可以得到极大的降低。

让我们查看一下假设性的范例,一个有,一个没有工具。

图 12. 手动缺陷修复周期
显示工作时间和消耗量的图

在这个假设性的范例之中,一个缺陷需要 16.25 个小时来修复,但是会浪费 12 个小时(几乎占到逃逸时间的 75%),这个极大地增加修复缺陷所需要的时间。当这种情况扩展到整个的项目时,就会导致修复代码产生极大的延迟,并使得对客户交付工作系统也延迟。

现在让我们看一下相同的范例,但是现在使用的是 CLM 以改进协作。

图 13. 使用 CLM 自动修复缺陷
使用 CLM 降低消耗量和工作量

所以在使用 CLM 的假设性范例之中,修复一个缺陷的工作量从 4.75 个小时降低到 3.25 个小时,而消耗量从 12 个小时降低至不超过 2 个小时。更为重要的是,修复一个缺陷现在只需要不到半天的时间,这意味着在一个为时两周的冲刺阶段中,可以更快地完成缺陷周期。对于让技术一直处于控制之中,并产生潜在可部署的高质量软件,这一点非常关键。

如果缺陷不在进程之中,那么由于开发员的人为重启操作,每项缺陷的任务切换会产生更多的消耗量。在这种情况下,可以小批次在短的周期内处理缺陷。精益软件开发为处理这种情况而整合了“暂时需要的消耗量”。


评价消耗量和价值链

在进程和交付价值的背景下,考虑所有的消耗量是非常重要的。价值链 就是帮助团队和机构更好地理解工作的持续时间,以及有多少消耗量。

对于价值链的长度,您可以查看总体工作量与消耗时间之间的比例,以理解效率。在评价进程的过程之中,要同时查看总体逃逸时间以及进程效率。有些更改,例如自动化一个手动任务,可以同时降低效率和逃逸时间,因为可以从价值链中删除已存在的工作量。

考虑这一点的另外一种方法是:

逃逸时间 = 工作量 + 消耗量
效率 = 工作量 / 逃逸时间
图 14. 缺陷价值链范例
显示工作时间和消耗量的价值链图

在这个假设性的范例之中,修复一个缺陷平均需要 4.25 个小时,但是逃逸时间通常需要 16.25 小时。所以我们向您评价两件事情:消耗量(逃逸时间-工作量)以及工作量。

通过关注于降低一个价值链上的平均消耗量和工作量(缺陷修复周期,实例,或者用例场景),您就可以开始使进程变得非常简介,并向业务或者客户更快更多地提供价值。

您可以配置 CLM 来估算工作项目(实例,缺陷,改进需求,用例场景,等等)的每一个阶段中的平均消耗量和工作量。这种评价意味着用很小的负荷改进价值链,并使团队能够看到该信息变得可能起来,这样他们就可以执行更改,以降低特定价值链之中的消耗量和工作量。下一幅图中的屏幕截图就是来自 Rational CLM 的一个报告范例,显示逃逸时间,工作量,消耗量,以及一些缺陷的效率。您可以使用这种类型的报告,来评价已存在的进程,并识别需要在什么地方作出改进。

图 15. 缺陷效率报告
显示缺陷总结,工作量和效率的表格

总结

在本文中,我们查看了在 CLM 的帮助之下搜索并降低成本的不同方式,包括:

  • CLM 改进协作,特别是跨团队,跨地域,跨角色以及不同的公司。这可以极大地降低不同类型的成本。我们会重点关注查看等待,操作,任务切换,以及 CLM 是怎样帮助开发团队,业务,IT,私人和外部团体是如何协作,以及相互交流的。
  • CLM 提供了透明及实时的动态规划和报告 。这使得我们可以看到更多的整体画面,更轻松地查看问题,更快地采取适当的行动。它还有助于降低 额外进程 的需要,降低行动操作的需要,并帮助地域分布式团队实现自我组织。正如讨论的那样,CLM 还有助于减少部分完成的工作,额外特性,以及缺陷,并提供各种涉众之间更高层次上的交流。
  • CLM 还 使得改进使得自动化 。本文并不关注该区域,因为从整体上讲,它不会从软件开发直接映射至本文所讨论过的七种类型的成本。但是它绝对值得我们的识别,因为这有助于实施一些非常重要的实践,例如更小,更频繁的发布,持续性的集成,以及并发测试。这些实践操作还可以降低成本,因为它使得我们可以交付地更频繁,并从业务中得到有价值的回馈。理解总体进程背景下的自动化改进,这一点非常重要。我们会讨论怎样评价和分析价值链部分中的进程,以及查看自动化改进的潜在性陷阱。

总体来说,精益软件开发是一种文化,它提供了宝贵的经验来改进软件开发。对人员的尊重和持续性的改进对于这种文化来说非常关键。在本文之中,我们向您展示了通过支持人民更轻松地查看,删除,并最终预防浪费,从而补充精益方法。


致谢

非常感谢 Anthony Kesterton 和 Tony Grout 对本文所作的评审工作,以及他们的注释和支持。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=776135
ArticleTitle=在协作生命周期管理的帮助下的精益软件开发方法
publish-date=11212011