敏捷过程成熟度的真正价值

Bob Aiello 探讨了在您的组织中可靠地实现成功的敏捷实践所需的一些关键成功因素。然后,他讨论了如何实现健壮和成熟的敏捷过程(agile processe)。

Bob Aiello, 顾问兼总编辑, CM Best Practices Consulting

Bob Aiello 是面向开发人员的 CM Crossroads 网站的顾问兼总编辑,而且是 Configuration Management Best Practices: Practical Methods that Work in the Real World(Addison-Wesley Professional,2010,cmbestpractices.com)的合著者之一。他拥有超过 25 年在数家纽约顶级金融服务公司担任技术经理的经验,在这些公司中,他承担了全公司范围内的 CM 责任,经常为企业的源代码管理工具、SOX/COBIT 合规性、构建工程、持续集成和自动化应用程序部署提供实际技术支持。Bob 担任了 IEEE828 Standards 工作组(CM Planning)的副主席,而且是 IEEE Software and Systems Engineering Standards Committee(S2ESC)管理委员会成员。他持有 New York University 的工业心理学硕士学位,以及 Hofstra University 的计算机科学和数学学士学位。您可以通过电子邮件或在 LinkedIn 上联系他。



2013 年 2 月 18 日

在较大的组织中实现敏捷开发,这可能是一项非常复杂和具有挑战性的工作。敏捷实践可以扩展和处理企业工作(包括任务关键型系统)的需求,敏捷实践涉及的远远不只是每日站立会议(stand-up meeting)和固定时间段的冲刺。成功的组织希望看到采用敏捷过程的每一个项目在生产率和质量方面都能获得成功。本文探讨了在您的组织中可靠地实现成功的敏捷实践所需的一些关键成功因素。此外,本文还讨论了如何实现健壮和成熟的敏捷过程。

以工具为焦点

几十年来,许多流程改进大师们都在挑战工具的重要性。一直以来,人们获得的常识是,流程比所涉及的工具更重要。这似乎是显而易见的,经验丰富的 IT 专业人士经常看到,成功的高绩效团队尽管受限于现有的(通常是旧的)工具集,但他们仍然做得相当不错。我可以证明,虽然只有有限的遗留工具或(有限的)开源工具集可供使用,但许多优秀的技术团队仍然可以做好其本职工作。经验表明,尽管 他们只有现有的工具集,团队仍然可以获得成功。同样是事实的是,拥有优异的工具并不能保证成功。就像流行的谚语所说的,“一个有工具的傻瓜仍然是一个傻瓜。”但前一段时间,我的生活体验极大地改变了我对于工具的重要性的看法。

这件事涉及我母亲的心脏病突发,这让她在未来一年内将无法生活自理。我们最初将起居室改建为她的私人复健室,然后着手扩建房子,为妈妈提供一个配有残疾人专用卫生间的私人公寓。很快。在我们的后院中都摆满了推土机等专业设备。我很快就醒悟到,熟练的工匠需要合适的工具和流程来创造其最佳作品。良好的工具是必需品!


成熟的敏捷过程

大多数流程改进大师专注于可以同时适用于大型和小型项目的可靠的、可重复的方法。有很多非常成功的跨职能团队都接受敏捷实践,并提供非常好的成果。许多项目都由小团队圆满地完成。但仍然有一些其他项目需要更多资源才可以满足其产品上市时间要求和功能要求。大型银行系统、医疗设备和任务关键型工程系统往往需要非常大的团队在可接受的时间范围内满足其最后期限。

可扩展

敏捷实践具有可扩展性。尽管很多组织报告对规模较小的项目使用敏捷方法可以获得极大的成功,不幸的是,当这些公司尝试对较大的项目使用敏捷实践时,往往会遇到挑战。我们需要的是在小型项目和较大型项目中都可行的敏捷实践。

扩展敏捷包括采取在典型小团队中获得成功的实践,在大型项目中利用它们获得同样的效果。在更大的上场景中使用敏捷方法要求以一致的方式培训成员。它还需要工具来帮助指导团队使用敏捷过程。虽然敏捷方法对个体和交互的重视超过了对流程和工具的重视,但它的扩展取决于使用正确大小的流程与合适的工具来获得成功。

流程本身需要提供对工作流自动化的支持,确保它们是可重复的和可追溯的。这意味着您需要实现合适的流程和正确的工具,然后才能把工作做好。这些工具还必须有助于支持个体和交互,提供协作、透明度和可追溯性。成功的组织还会适度关注 IT 治理。

可重复

应用程序生命周期管理(Application Lifecycle Management,ALM)可以提供帮助,支持整个软件或系统交付生命周期(System Delivery Lifecycle,SDLC)。(参见 参考资料 中引用的“Configuration Management Best Practices”)成熟的敏捷实践是可重复的、可预测的和可扩展的,可以支持团队规模的要求。成熟的敏捷过程必须严格遵守敏捷的价值观和原则。这是非常重要的,因为经常能听到,有些项目声称所采用的方法是敏捷项目,但经过更仔细地检查后发现,该属性仅仅是没有明确已定义需求的代码的一个借口。我喜欢将开发方法遵循敏捷实践的程度称为敏捷过程纯度

敏捷过程纯度

敏捷过程应该坚持敏捷宣言(参见 参考资料 中的链接)所信仰的价值。显然,这意味着我们应该重视以下价值:

  • 个体和交互胜过流程和工具
  • 可行的软件胜过全面的文档
  • 客户协作胜过合同谈判
  • 响应变化胜过遵循计划

敏捷宣言指出,“虽然我们重视右侧的项目,但同时我们更重视左侧的项目。”就价值观和优先事项而言,这是完全正确的。也就是说,有些企业需要更多的流程,而另一些则需要较少的流程,但选择合适的工具对于您的成功始终是不可或缺的。合同、文档和详细的计划,这些往往也是一个必要要求。无论您是在利用风险投资的资金、是一家互联网创业公司,还是在申请批准用于实现大规模交易系统的预算,除非在一个可以接受的程度上解决所谓的“右侧项目”(在上面列出的),否则许多组织根本不会批准该项目。

虽然我已经握握手就完成了很多交易(没有遗憾),但合同肯定也会有其发挥作用的地方。成熟的敏捷过程有助于将重点放在左侧的项目上,但同时仍然满足右侧项目的最低要求。这种全面的、均衡的方法对于扩展敏捷过程(在许多组织中,特别是在高度管制的行业中,这是一个关键的要求)是必不可少的。


IT 治理

我的许多同事抱怨说,他们的高级管理人员与普通雇员完成的日常工作是脱节的。事实上,有时高级管理人员似乎并不完全了解构建复杂的技术系统真正需要些什么。实质上,技术工作人员可以做很多事情,向其上司提供清晰的、有用的信息,帮助他们制定更好的决策,并提供更有效的领导。管理传给高级管理人员的信息,帮助确保他们能够根据准确的信息制定出明智的决策。

这并不意味着高级管理人员必须制定所有决策。在一个成熟的敏捷环境中,自我管理的团队在许多关键决策的制定中也发挥着至关重要的作用,但在理想情况下,其前提是所有重要信息都是可用的。许多敏捷精益爱好者将这称为最后责任时刻,指示将制定决策的时间推迟到所有事实都可用,这样,决策就是基于最新信息而制定出来的。

透明度的文化

成熟的敏捷组织具有共享必要信息的文化。如果您曾经带着小孩子长途旅行,“我们到了吗?”这个问题可能会根深蒂固地留在您的记忆中。同样,每一个项目利益相关者都希望了解项目是否在推进,当然也希望了解项目在以什么样的速度推进。

许多敏捷实践者都使用燃耗(burnup)燃尽(burndown)图表来显示最新的进度(例如,已完成的功能),以及计划完成迭代或发布的剩余时间。产品积压(product backlog)维护一份需求列表,其形式往往是史诗(epics)用户故事(user stories)(其中故事是最终用户所期望的功能的描述)。对话通过叙述故事的细节来提供帮助,应该记录这些故事细节,并测试这些故事细节是否有助于确定故事何时完成(参阅 User Stories Applied)。史诗 通常是更大篇幅的描述,一般可以分成两个或多个故事。

完成史诗和故事的进展率通常使用称为速度 的指标来衡量(参阅 The Software Project Manager's Bridge to Agility)。高度可见的信息辐射器 有助于实时沟通基本信息。所有这些形式的通信都有助于创建和支持透明度文化,从而帮助整个组织提高生产率和质量。

您的工具需要能够支持实时信息共享,这一点很重要。当涉及到项目规划时,有效的沟通特别重要。


项目规划

关于敏捷开发的一个误解是,它不需要规划。敏捷宣言指出,响应变化的优先级高于遵循计划。话虽如此,但在成熟的敏捷环境中,往往需要详细的,甚至是全面的计划。

因此,在敏捷开发环境中,规划范围可以从简单的发布和迭代计划到与瀑布式生命周期计划的任何产品进行竞争的全面的、详细的计划。我看到在许多组织中,规划是取得成功的一个绝对要求。

有时候,管理人员被迫在所有信息可用之前做出决定。我曾看到根据错误假设做出决定的一些极端情况,出现这种情况只是因为要求在所有必要事实已知前进行估计。敏捷方法鼓励在规划时要诚实,因此可以在“最后责任时刻”做出决定。根据建议,应该尽可能晚地制定决策,这非常重要,尤其在使用新技术时,过早制定决策会存在许多不易控制的未知情况或风险。

还需要规划发布来确保透明度,比如哪些特性可以在一个指定的时间范围内完成。在敏捷上下文中,固定时间段 迭代的概念对规划的影响尤为严重,在这个概念中,每个冲刺必须保持在一个特定的时间段中,通常是两到四个星期。

发布和迭代规划

发布规划包括确定对于特定版本要求哪些功能被认为是完整的。迭代规划指定在固定时间段冲刺 中要求完成的特性。从开发和测试的角度来看,每一次迭代的完成可能都是有用的,但只有在已经完成的功能达到可供最终用途测试的成熟点时,才应该将里程碑发布本身提供给客户。任何时候都不应该将“半桶水”的版本提供给不知情的顾客,若功能不完整,则无法对它合理地进行测试。

有时,在固定时间段冲刺中创建的版本显示给用户的功能可能仅足以作为一种工具来验证要求,并帮助澄清需要建立什么功能。但是,我也曾见到一些案例,客户收到的代码完全没有办法成为正常运作的里程碑。这种情况对于客户和供应商之间的关系有很大的影响,因为客户感觉像是(并表明)自己收到了一个不完整的、无法工作的系统。

相反,客户应收到已完成产品积压中合理数量的故事的基线里程碑版本。恰恰是在这些地方,配置管理最佳实践可以支持团队在高生产效率时交付以可靠方式构建的基线版本。


配置管理和敏捷实践

配置管理(Configuration Management,CM)在敏捷上下文中发挥着一个令人兴奋的作用。在成熟的敏捷上下文中,CM 有助于智能地管理源代码,包括支持基线里程碑、自动化的独立版本,以及代码中的多个变体(例如,错误修复)。

构建工程可以增加价值,它创建可重复的程序,以可靠的方式生成可执行的二进制文件(通常称为配置项),这些文件易于识别,可确保构建、包装并部署了正确的版本。

版本工程创建了一个可靠的包,包括一个清单,其中列出了构建的内容(通常被称为材料清单 或 BOM)。在许多环境中,创建发布包的方式可以确保它是防篡改的,并且可以促进应用程序的部署过程。

更重要的是,这些程序提供一种机制来审计和验证正确的配置项目已经按要求得到构建、包装和部署。利用强大的构建框架,可以更轻松地实现这些最佳实践。利用这些技术的帮助,CM 在促进快速迭代开发中起着至关重要的作用。CM 规划有助于为用于处理源代码管理(以及构建、发布和部署工程)的所有必要活动指定一个明确的路线图。

理想情况下,您可以使用一个自动化流程,在创建配置项,将它签入到源代码存储库中,然后自动建立单元测试(甚至代码分析)之后,使用实时反映的当前状态跟踪配置项。这将通过消除干扰帮助开发人员集中精力于自己最擅长的工作上,并且向所有利益相关者提供透明度,使管理层能够基于最新信息制定最佳决策。

这种自动化水平还有利于快速迭代开发。

快速迭代开发

敏捷开发需要多次迭代。这制造了可以证明自动化应用程序构建、包装和部署的价值的一种情况。很多团队利用持续集成(Continuous Integration,CI)来构建应用程序,往往需要在白天迭代无数次。在很多时候,夜间构建就已足够用,但迭代开发能够很快地显示出对自动化的、可重复的应用程序构建、包装和部署流程的需求,该流程采用了成熟的部署框架,最终将完整版本推送到测试环境中。

快速迭代开发非常重视整个应用程序开发生命周期。它还会将必要的关注放在软件质量上,同时支持自动化的单元测试和代码分析。

这种开阔的视野有助于支持整个软件和系统开发生命周期。

完整的软件开发生命周期

应用程序生命周期管理(ALM)是一项涉及整个生命周期的工作,需要采用支持敏捷 ALM 的工具帮助引导整个生命周期,从规划、收集需求和设计,一直到应用程序的构建、包装和部署。在成熟的敏捷上下文中,每个人都知道自己每天需要完成的工作。

这是另一个示例,正确的工具通过为工作项的综合处理创建了一个自动化的框架,其中包括与有关构件(包括史诗、故事和测试用例)链接的任务和缺陷,可以提供帮助。

任务和缺陷也可以有它们自己的关系结构。

任务和缺陷的层次结构

任务和缺陷等工作项是具有层次化关系的,这很常见。在某些情况下,这可能意味着,一个任务具有一个或多个子任务,其中可能包括需要加以解决的任务或相关缺陷。史诗可能使用故事作为其子项,这些故事可能有分配给它们的任务和缺陷。以层次化的方式安排工作项,可以为组织工作提供一个很好的方法,并显示哪些项目已完成,哪些工作尚未完成。

成熟的敏捷过程的另一个方面是与非敏捷过程共存的能力。


与非敏捷过程共存

成熟的敏捷软件开发还需要与非敏捷过程共存,为 IT 治理与合规性提供支持。

团队在需要与瀑布式方法共存的环境中采用敏捷方法,这很常见。这种情形的最常见的形式涉及每天在敏捷上下文中工作的团队,但每个团队都通过传统的瀑布式软件或系统生命周期向高级管理人员报告。

目前的工具需要能够支持包含敏捷和非敏捷软件开发流程在内的混合开发模型。正如敏捷和非敏捷方法需要和谐共存那样,敏捷方法往往也需要同时存在,并符合行业标准和框架所规定的监管要求。

符合行业标准和框架

许多组织都必须遵守美国联邦政府监管要求,这些要求中包括 Sarbanes-Oxley Act of 2002 的 Section 404 或 HIPAA CFR 21。行业标准包括 IEEE、ISO 或 ANSI 等组织的指南,以及备受尊重的 ISACA COBIT 或 itSMF ITIL v3 等框架。这些最佳实践往往需要职责分离,完全自动化的应用程序构建、包装和部署过程极大地促进了职责分离。

从工作项到原子变更集的可追溯性同样重要,可以识别所完成的精确变更,并直接链接到工作项(变更请求)授权的变更。工作项通常在工作流自动化工具中进行管理,而且它们会经过预定义的状态,如创建、审查、批准、关闭和验证。

成熟的敏捷过程会保持敏捷开发的所有卓越效率,同时仍然满足被制定并接受为权限和指南的具体标准或框架中所描述的所有行业监管要求。流程改进有一个过程,成熟的敏捷过程也强调持续改进应用程序开发方法。


回溯和变更

最重要的流程改进方法之一是定期检讨我们过去的行为,并反省我们应该如何改进。回溯 提供了适当的机制,以检讨我们的现有流程,并讨论哪些流程效果良好,哪些流程可以改进。有时,可以在一个特定位置执行这些回溯,但在其他时间,团队可以分散在一个或多个位置,因此他们常常需要采用一些工具来支持协作和通信。

无论是您可以奢侈地让大家聚在一起吃比萨饼和讨论观点,还是您必须以不太传统的方式获得每个人的输入,回溯都有助于推动整个流程的改进工作。它们为诚实的反省、不断的沟通和持续改进提供了一个框架。

结束语

成熟的敏捷过程需要具有可重复性可扩展性,以满足组织的需求。虽然有这么多惊人的成功,但仍然需要通过做一些工作,让敏捷方法在组织内的每一个项目中都取得同样的成功,这些项目中包括团队成员分布在不同地理位置上的较大型项目,他们经常工作在不同的时区,甚至有可能讲不同的语言。

成熟的敏捷软件开发还需要与非敏捷过程共存,提供对于支持 IT 治理与合规性必不可少的清晰准确的信息,从而提供透明度。敏捷是可行的!成熟 的敏捷开发会将这些实践带到一个新的水平,提供了巨大的价值和更大的竞争优势。

参考资料

学习

  • 了解与本文有关的更多信息:
    • Configuration Management Best Practices: Practical Methods that Work in the Real World,作者为 Bob Aiello 和 Leslie Sachs(Addison-Wesley Professional,2010)。
    • 敏捷开发中的持续集成 敏捷方法、持续集成和测试驱动如何增强复杂系统的设计和开发,作者 Martin R. Bakal、Jennifer Althouse 和 Paridhi Verma(developerWorks,2012)。
    • 《敏捷宣言》
    • The Software Project Manager's Bridge to Agility,作者 Michele Sliger 和 Stacia Broderick(Addison-Wesley Professional,2008)。
    • User Stories Applied: For Agile Software Development,作者 Mike Cohn(Addison-Wesley Professional,2004)。
  • 访问 developerWorks 上的 Rational 软件专区,获得 Rational Software Delivery Platform 产品的技术资源和最佳实践。
  • 订阅 developerWorks 每周电子邮件时事通讯,并选择要关注的主题。
  • 随时关注 developerWorks 技术活动和网络广播,了解各种 IBM 产品和 IT 行业主题。
  • 参加 developerWorks Live! 技术讲座,快速了解 IBM 产品和工具以及 IT 行业趋势。
  • 观看 developerWorks 点播演示,那里提供了面向初学者的产品安装和设置演示,以及面向经验丰富的开发人员的高级功能演示。

获得产品和技术

  • 下载 免费试用版本 的 Rational 软件。
  • 以最适合您的方式 评估其他 IBM 软件:下载产品试用版、在线试用产品、在云环境中使用 产品,或在 SOA 沙盒 中花几小时学习如何高效地实现面向服务的架构。

讨论

条评论

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=858446
ArticleTitle=敏捷过程成熟度的真正价值
publish-date=02182013