近来美国和英国政府的会计监管机构均就政府资助的开发项目采用敏捷实践发布了相关的报告以及指南。美国审计总署(GAO)以及英国国家审计署(NAO)都推荐敏捷方法作为政府部门开发软件产品的最佳方法,同时他们还就敏捷实施以及监管提供了相关指南。
NAO 在报告中指出:
为了降低项目失败的风险,政府打算在信息和通信技术(ICT)采购以及交付项目中采用敏捷方法。在 2011 年 5 月的公共账户委员会的听证会上,很明显,政府不仅仅将敏捷当作一种改进软件开发的方法,它还是一项可以成功实施 ICT,让业务发生改变的技术。内阁办公室常务秘书表示“没有所谓的 IT 项目,只有涉及 IT 的商业项目”。同时他还指出,尝试“在一天内将整个国家的系统改头换面——也就是所谓的‘大爆炸式’实施——在任何情况下几乎都是注定要失败的。”
GAO 在报告中也谈到了同样的话题:
在 2011 财政年度,联邦政府机构依靠信息技术来支持多项工作目标,并且在这上面花费了不下 760 亿美元。然而,长久以来,国会的关注点只是去找出那些超支并且延期的 IT 项目,而很少关注与工作目标相关联的产出。为了降低这一风险,美国行政管理和预算局(OMB)推荐使用与敏捷方式一致的模块化软件交付,它提倡小规模、短周期增量式发布。
2011 年 3 月,英国政府研究院主张在政府的 ICT 项目中采用敏捷方法,因为现有的“最佳实践”流程不能够解决传统模式下出现的系统性缺陷。
NAO 的报告旨在为敏捷项目找到有效的监管模式以及方法,其中阐明了四项原则:
- 监管应该遵循敏捷方法的理念——只做对业务有价值的事情而且绝不导致延期。
- 敏捷交付团队应该决定他们团队采用的,并且比我监督的经验性绩效指标。
- 高级管理人员、外部评估人员、商业用户、以及 ICT 团队之间在确保产品质量上应该是合作伙伴关系,而这种协作模式本质上是思维方式的转变。
- 针对敏捷发布的外部评估或者评审应当聚焦团队行为而不仅仅是关注过程以及文档。
GAO 报告列举了一些曾经在联邦项目中获得成功的实践和方法:
- 从一开始就要制定好敏捷指南以及敏捷实施策略。
- 利用敏捷术语来增强敏捷观念的过度,比如用户故事(用于表达需求),以及敏捷实例,比如示范如何写一个用户故事。
- 在项目层面以及组织层面持续改进敏捷实施。
- 力图发现并指出组织以及项目层面的阻碍。
- 频繁获得利益关系人 / 客户的反馈。
- 授权小型的、跨职能的团队。
- 在未完成工作(backlog)列表中记入与安全以及进展监控相关的需求。
- 在每次迭代结束时通过展示所实现的价值以赢取信任。
- 使用工具和度量指标来跟踪进度。
- 每日可视化地跟踪进度。
它同时还识别出了一些在做联邦政府项目时,实施及应用敏捷方法所面临的常见挑战:
- 团队密切协作有困难。
- 采购实践或许并不支持敏捷项目。
- 团队难以过渡到自我管理的工作方式。
- 客户不信任迭代解决方案。
- 职员很难承诺更及时的、频繁的交流。
- 团队管理迭代式的需求有困难。
- 行政部门在委任职员时有难度。
- 在一个迭代时间范围内进行合规性审核比较困难。
- 及时采用新工具有困难。
- 联邦政府的报告机制与敏捷不相一致。
- 难以建立和维护技术环境。
- 传统的工件审查方式与敏捷不相一致。
- 敏捷指南不明晰。
- 传统的状态跟踪方式与敏捷不相一致。
你有什么政府项目的敏捷经验可以分享呢?
Shane Hastie 是一位敏捷方法的教练、培训师,同时她也是澳大利亚和新西兰的 Software Education 公司的一名顾问。
查看英文原文: Government Guidelines for Agile Adoption
感谢金毅对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。
评论