为持续功能改进制定计划的步骤

来自 Rational 专业架构师的应用系统交付团队指南

本文描述了 Rational 专业架构师在工作中所使用的过程,以改进 IT 公司内的功能。我们使用程序交付来包含所有类型的软件开发与交付,不管它是 COTS 还是完整的通用开发以适应您的业务需求。

Lee Reid, Rational 专业架构师, IBM

Author photoLee Reid 自从 2003 年一直在 IBM,在 IBM Great Northeast 业务单元担任一名 Rational Specialty Architect。他和 Rational 客户一起帮助引入最佳实践,解决方案和加强应用交付团队。Lee 拥有多个 IBM,Open Group 和 Rational 软件的专业和产品认证。他持有 General Motors Institute 的机械工程 BME 学位,以及密歇根大学的计算机信息和控制工程 MSE 学位。Lee 居住在伊利诺斯州芝加哥,他喜欢骑自行车,游泳,并且在天气允许时沿着芝加哥湖畔跑步。他尝试三项全能运动和长跑运动,长期目标是在其年龄组获得最终胜利。



Sanjeev Sharma, Rational 专业架构师, IBM

Author photoSanjeev Sharma 从 1995 年加入 Rational 软件,并且在 IBM 收购 Rational 后成为 IBM 的一部分。他是 IBM 中亚特兰大业务单元的一名 Rational 专业架构师。他和 Rational 客户一起帮助引入最佳实践,解决方案和加强应用交付团队。Sanjeev 是一名发明家,IBM 已经在美国已经为其四个发明申请了专利。他拥有 IBM 和 Open Group 的认证,并持有印度 NIT Kurukshetra 的电子工程学士学位,以及 Villanova 大学的计算机科学硕士学位。他也在攻读华盛顿特区的乔治华盛顿大学的计算机科学博士学位。Sanjeev 住在北弗吉尼亚,与妻子和两个聪明活泼的小孩一起生活。他喜欢听音乐,看电影和阅读。



Joel Sundman, Rational 品牌技术推动负责人, IBM

author photoJoel Sundman 自从 1995 年一直在 IBM,管理北美 Rational 软件的区域活动程序。他监管北美所有 Rational 销售代表和 Rational 客户技术专家推动工作的计划和预算运营。. 他也负责领导北美地区的 Rational 产品 Specialty Architect 团队,其成员咨询管理层客户,通过促进行业最佳实践的过程和工具,帮助解决负责 IT 问题。Joel 已经出版了多篇 developerWorks 文章,在西密歇根大学教书,在商业信息系统部门的咨询委员会。Joel 拥有多个 IBM,Sun 和 Open Group 软件的专业和产品认证。他持有西密歇根大学计算机信息系统的学士学位,东北大学的信息系统硕士学位,以及密歇根州立大学的 MBA 学位。他住在密歇根 的 Portage, Michigan,喜欢与他的两个儿子打曲棍球,足球和棒球。



2011 年 11 月 30 日

今天,业界内 IT 程序交付项目的成功率只有不到 50%。从事 IBM® Rational® 软件的我们花费了数十年的时间,与应用过程,工具以及启动策略的多个行业的客户协同工作。我们对客户的成功做了巨大的贡献,同时总结了一系列已被证明是卓有成效的业界最佳实践方式,以便程序交付。

本文是我们对帮助程序交付公司中许多客户创建视图和路线图中知识的总结。我们希望它能给您一些建议,更清楚地查看公司,并采用最佳实践方式,以帮助您完成业务目标,克服公司内存在的障碍。

创建一个视图以及路线图的需要

通过我们与采用 Rational 软件的多家公司打交道的经验,我们已经发现了大多数成功的公司都会开发一个长期的视图以及路线图,并努力地实现视图,持续性地做出改进。本文就讨论了可以帮助您起草视图和路线图的方法。

正如在很多重大的活动中那样,有很多可能的选项看起来对公司好像有同样的价值。但是,有了 Rational Specialty Architect 的帮助,帮助您应用公司的知识与指南,IBM Rational 客户通常会为采用什么锻炼而决定一系列的优先级顺序。

例如,您可以考虑一下以下的类比:

随着您 40 岁生日的接近,您可能有一个目标去完成一项马拉松赛跑。您兴奋起来。您可以看到您正在接近终点线,穿上带有比赛号码的衣服,让您的家人成为观众,建立自信心,并对您的物理状态有良好的感觉。

这就是您的 视图。这就是您的 North Star 与前进动力。您需要视图来保持关注,因为前面有大量的工作要做。

现在,您是否为完成马拉松赛跑做好了准备?您要开始赛跑,但是做准备工作的最佳方式是什么?您有很多问题要问:我是要穿新的自然跑步运动鞋,还是标准跑步运动鞋来进行训练?我们应该对营养配方做什么更改?我是不是应该做补充性训练?我需要什么补充性训练?我应该采用多长的训练距离,以及什么时候训练?

有很多种选项,首先要做什么,以及怎样实现目标有时候并不是很明晰。这就是为什么您需要一个 路线图,一个计划,以及一个前进的方式。

最后,为了完成类比,因为您 40 岁的生日只有一次,所以您需要确定到那时您已经实现了目标。既然您只有一次机会去证实它,所以您最好从类似环境下帮助其他人的那些人那里获得帮助。所以您可能要雇用一个私人培训员,他拥有帮助其他想参与马拉松赛跑的运动员的丰富经验。培训员会询问大量的问题,并试着理解您的动力是什么,所以您要将最佳的计划规划到一起,还有增值里程碑,例如沿线上 10k 和半程马拉松的标志以确保您实现了您的目标。

如同马拉松赛跑的类比一样,您的团队需要定义公司功能改进的视图与路线图。一个 Rational Specialty Architect 可以作为您的私人培训员,以帮助您理解应用到视图之上的选项以及软件工程最佳实践。Rational 专业架构师是 Rational 工具及方案方面的专家,所以有时把它们叫做 Solution Architects。您可以联合使用业务,IT 动机,公司限制因素(阻碍因素)的视图,工作间参与者将会定义视图和路线图,帮助您的公司做出进展并实现视图。

平衡的重要性

就像一个潜在的马拉松选手需要将跑步与适当的营养和恢复技术平衡起来一样,公司应该计划引入程序交付功能改进,以平衡进程,工具以及支持。我们使用工作间和结果路线图之中以下的符号,来提醒我们维护平衡的重要性。

图 1. 过程,工具的平衡以支持程序交付
IT 组织改进的三个区域

平衡对于成功来说非常重要。例如,如果公司将改进的重要性集中到工具之上,而不用平衡相应的过程更改和员工训练,那么这通常会导致更改的不平衡引入,并最终导致采用失败。相反,当一个公司在以下三个领域都引入持续性改进的话 -- 过程,工具,以及启动-- 那么通常就是高度的采用性,接下来就是成功。

不断的改进

当我们与客户协作时,我们要开发一个带有不断进行和平衡改进的路线图。我们使用以下的图表,来帮助描述这种工作间所产生路线图的类型。

图 2. 持续性程序交付改进的路线图
持续性功能改进的路线图

在这个路线图之中,当每个增值目标实现时,每一步都会分配一个不断提高的目标,工具以及时间线。

谁应该参与到创建视图和路线图的活动中去

我们建议由那些对程序交付机构负责的人来领导这个过程。您的 CIO,指导人,以及项目管理员都可以扮演这个角色。在为程序交付机构开发视图以及路线图时,支持业务线上的所有经理人员都可以参与进来。让拥有不同经验,不同地位的人,作为一个团队来加入机构,是更明智的选择。


理解的基线:当前的进程

第一步是让的团队成员从对程序交付进程,工作流程以及工件理解的似是而非的状态中走出来。从项目初始化那里映射软件开发生命周期,您的团队会使用这些步骤来交付程序(维护,新开发,COTS,等等),以帮助所有人轻松理解当前的状态。

对于理解从大视角查看事情的所有人来说,这一点十分有用。有些人可能对部分程序交付进程负责,但是他们不知道总体工作流程的细微差别。这对起草路线图来说具有重要的信息价值。

在团队起草当前的实践活动之后,每个人都能很好地理解到当前事情的进展状态。


业务驱动

我们建议您去识别影响公司程序交付的业务驱动因素。它包括内部性动机以及外部性驱动因素。该练习的目标是明白公司的目标是什么。对于程序交付机构来说,业务 就是 您的客户(在有些情况下,或者是业务线)。因此,公司所做的所有努力都应该处理业务线或者公司的需要。除了那一点,还有外部性因素会影响到程序交付公司组织的方式。它包括治理规则,内部性和外部性遵循需要,销售-或者参与者驱动的动机,等等。

我们建议您做个五到十个业务驱动的列表,并将其排序。该练习能够帮助团队退回去,并从业务优先级的视角出发形成一个较宏观的看法。它支持团队查看处理业务存在的问题和需要,而不用受到程序交付活动的日常操作性挑战的限制。这种练习同样有助于熟悉工具和技术的传统,帮助您处理业务需要。


IT 动机,障碍,以及限制性因素

在这个阶段之中,我们建议您查看两个相关的话题。

  • 首先是识别内部性程序交付机构规划的 IT 动机。目标是查看公司当前正在做什么,或者由 IT 动机正在计划什么。公司应该再次列出一到五个首要动机的列表,并将它们排序。作为该次练习的一部分,然后您要将这些 IT 动机映射回前面练习中识别的业务驱动。这里的目标在于识别异常因素。在这里的情境下,所谓异常因素是不能映射回业务驱动的程序交付动机。
  • 第二点是识别障碍以及限制性因素。有一些情况会阻碍公司有效的程序交付。在这里,公司应该做一个含有五到十个障碍以及限制性因素的列表,并将它们进行排序。

行业最佳实践与映射

这部分的过程有助于 Rational Specialty Architect 描述行业最佳实践。然后您的公司可以讨论什么可以帮助您关注业务驱动,并处理上述步骤没有涉及到的动机。

在过去的数年间,Rational 员工以及咨询员收集并发布了程序交付团队已被行业证明的最佳实践。这些非常有用,因为它可以帮助我们理解公司内有什么正在发生,并支持我们走向成功。

最佳实践还可以处理问题产生的根源。例如,一个团队可能报告他们总是不能满足发布的截止日期,并面临业务涉众开发项目晚期时期的压力。这种形式的问题通常是更深层次问题的症候。症候 就是团队所面临的难题。在这里的范例之中:晚期的更改会引入大量的重复劳动。但是,原因可能是团队使用贫乏的需求定义和管理技术来执行开发项目。当我们在解决症候时,我们通常会陷入这样一种境地,就是将大量的资源投入到晚期阶段的团队之中以支持发布。当我们在修复根源起因时,我们会引入已被证明的最佳实践,例如带有事例板,事例卡驱动开发以及迭代回顾的需求,以帮助确定我们正在处理真实的需求。修复根源起因通常是最佳的方法。

Rational Specialty Architect 可以提供主要最佳实践组的概述,尽可能详细地确定您了解了实践选项可以得到。就像一个马拉松赛跑的个人训练员可能会列出一般的训练列表以训练运动员,例如跑步技巧,体重训练,营养,肢体伸展,以及补充,而 Rational 专家可以宣称训练能够增加成功的可能性,例如敏捷开发,需求定义,质量管理,结构管理,构建与开发,以及工具。

接下来,更改映射训练所要做的就是查看能够克服前面描述限制性因素,以及支持 IT 操作性活动的措施。就像马拉松培训员一样,Rational Specialty Architect 可以帮助您评价什么锻炼对公司最有利,并构建已经就位的最佳实践。


查看程序交付公司

对于主要改进的种类来说,查看公司在完成改进计划时的进展非常重要。在未来的 18 到 24 个月份内实现这种视图是很常见的。我们建议您创建一个简短的声明,由该声明描述了您的公司在未来是什么样的。该视图,或者 North Star,有助于提醒所有人为什么路线图中的步骤会被执行。同样,视图声明通过描述改进步骤中的结果,有助于实现路线图之中的管理步骤。跟马拉松选手一样,看到终点线是非常重要的,保持一定的动力沿着路线每天努力。


通往成功的路线图

在本文接下来的一部分中,您要生成一个 采用 路线图。我们建议您将路线图作为通往前面练习中所识别的五种最佳实践方式创建。对于最佳实践或者计划采用相关的最佳实践,路线图应该有单独的路径。然后您可以按照这些步骤操作,如果公司愿意的话,您可以采用并发的操作。对于其中的每一种路径,让公司去识别中间目标。然后,对于其他的步骤,识别以下的四个内容:

  1. 成功或者成就的评价(您怎样知道中间目标已经达到?)
  2. 完成的时间(中间目标什么时候达到?)
  3. 拥有者(谁拥有这个目标?)
  4. 对成功的潜在障碍(是什么在阻止您走向成功?)

该练习的结果成为采用过程之中识别最佳实践的“通往成功的路线图”(见于接下来表格之中的范例)。您可以使用该路线图来规划开始的活动与项目,以帮助您采用最佳实践,并评价采用率和结果的成功情况。

增值路线图的范例
阶段 1 2011 年 4 月 15日阶段 2 2011 年 4 月 30日阶段 3 2011 年 5 月 15日阶段 4 2011 年 6 月 15日阶段 5 2011 年 7 月 15日
实践定义需求格式与使用定义引入技术决定项目的格式与使用调整需求实践展开到其他的业务区域
产品Rational Requirements ComposerRational Requirements ComposerRational Requirements Composer
服务3-5 天的监视服务3-5 天的监视服务10 天的 Quickstart 服务2-3 天的监视服务
优势稳定的方法以及定义的进程获取需求的稳定方法质量上 10-15% 的改进成本与时间上 5-10% 的降低范围控制与更清晰的项目目标

注意:
当 IBM Rational 专业架构师帮助您通过这个过程时,他们使用的是路线图,以及其他练习的结果,以向公司提供一系列的推荐方法,以适应这些最佳实践的成功试用。接下来的部分解释了您所使用它的方式。


Capability Improvement Workshop 选项

Rational Specialty Architect 还有一个补充性的日常 Capability Improvement Workshop,带您执行完这个练习。工作间是为那些对业务和业务线交付软件负责的经理人员设计的。实践人员可能要参加,但是可能并不能完成工作间中的一些练习,因为他们缺乏大视图下的全局观。回答 IT 业务人员需要做什么事情,交付什么,超出了很多实践人员所掌握的信息。

工作间 并不是 The Rational Edge 2004 年 10 月中所描述的深入功能 评价(见于 参考资料 部分以得到对本文的链接)。但是,该工作间是探讨和发现公司所做的对交付软件最重要的改进。当您是一个 IBM Rational 客户时,情况更是这样。一个可能的结果是部署已存在 Rational 工具更好的方式,这样您就可以使用已存在的资源来实施最佳实践。

“一个可能的结果是部署已存在 Rational 工具更好的方式,这样您就可以使用已存在的资源来实施最佳实践。”

工作间议程遵循本文中介绍的内容:

  1. 引言与工作间目标
  2. 理解的基线:客户当前进程
  3. 业务驱动练习
  4. IT 练习
    • IT 动机练习
    • IT 障碍与阻碍因素练习
  5. 行业最佳实践讨论与映射
  6. 视图练习
  7. 路线图练习

在了解工作间之后,我们将会创建一个报告与执行总结,以实施工作间中没有涉及到的最佳实践。我们并不推荐您使用“大爆炸”方法来实施这些最佳实践。相反,我们所关注的是那些对公司业务贡献最大价值的人。

为了得到更多信息,您可以联系 IBM Rational 代表,并向其中任意一个作者发送电子邮件。

参考资料

学习

获得产品和技术

讨论

条评论

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=777457
ArticleTitle=为持续功能改进制定计划的步骤
publish-date=11302011