CMMI研究所运用敏捷方法的探索


这篇文章概述了SEI 采购方案在美国国防部软件密集型系统开发中运用敏捷方法的探索,我们识别出了遇到的需要克服的问题和挑战,并记录下来。敏捷的定义:敏捷开发是以一种互动的,增量的方法由自组团队进行的高效率团队合作的软件开发方法,以实惠的成本及时地生产高质量的软件产品,更适应相关干系人对产品的需求变化。

敏捷方法经需要不断与最终用户协同合作,频繁的(2 周-4 周)提交产出物,连续的集成和测试开发。虽然所有的敏捷方法是增量的,但并不是所有的增量的方法的具有敏捷开发的属性。美国政府和国防部从SEI 工作伊始,就一直考虑运用一种能充分发挥敏捷方法优势的新的采购过程。

潜在的困难以及与传统方法的区别

通过对运用过敏捷方法的美国国防部 部门的访谈,总结他们遇到的困难如下:

●采购生命周期:敏捷通常不会在每个里 程碑都有很多可评审的文档,因敏捷会增 量地把最新的产品开发出来,所以验收标 准也需要调整;

●团队环境:敏捷是强调一个动态的、跨 部门、高效的团队。相关的政府部门也需 要了解这一点;

●最终用户参与:敏捷是强调与客户的协 作,而非合同的谈判;

●培训和传授敏捷知识:很多人还是对敏 捷的概念不清晰,所以必须要先对相关人 员做培训;

●里程碑评审,文档记录,度量评价:传 统来讲,政府使用里程碑评审,文档记录 和评价度量来监控和评价沟通进度和审查 软件技术方案。里程碑评审和文档记录的 检查和检查准则可能在里程碑发生之前进 行。这个方法不同于敏捷开发的项目。敏 捷开发的项目,文档记录只要满足技术和 方案的需求就可以,实现文档记录最少化。保证达成最终结果的一些关键点如下:

●与对结果负责的责任人或国防科学委员 会各方确认;

●制定哪些与开发无关的文档,有效去监 督敏捷开发项目;

●同意每个文件的目的和内容;

●确保所有的需求满足指南说明和规定;

●奖励和激励: 敏捷关注团队,这与传统独 立基础的奖励机制相反;

●团队组成: 2 个重要职务是敏捷倡导者和 最终用户代表,敏捷倡导者, 上面描述的, 是能实时回答敏捷问题, 最终用户代表, 不仅代表最终用户,必须能够有权利指挥 承包商。

●文化:做一张简要的典型文化元素表格, 为了适应敏捷,政府将不得不修改他们的 思维方式, 使得他们除了传统的比喻,还 可以从其他角度查看软件的生命周期;

●集成和测试:持续集成和测试形式是在 敏捷团队中完成的。这不同于集成在传统 方法中是在最后的发布环节才做。

美国国防部敏捷和传统元素的对比

元素                美国国防部敏捷开发                美国国防部传统开发
组织结构灵活和适应性的结构;              
自组织的团队,                
团队合作或较强的沟通机制
难以改变的指挥和控制结构,              
层次化,以命令和控制为主的团队
奖励制度团队是奖励的重点;                
有时团队本身承认个人
个人是奖励制度的重点
沟通和决策每日晨立会,                               
经常回顾,                                

信息传递,沟通者优先考虑关键        

项目信息;                                

“刚刚够用”的文件;

自上而下的沟通,外部的规定,政策和程序推动工作,活动和过程记录;                
整个开发生命周期中 PMO 用到的传统的代表性文 ,要通过正式和非正式的评审。
人员模式跨职能团队,包括项目的整个生              
命周期的所有角色;                               
敏捷的提倡人或教练                                 最终用户代表
使用传统的瀑布模型,特别是开发和测试;   不同的角色(例如:开发人员,测试人员)除了活跃在不同的生命周期特定阶段中,其他时间都没有实质性参与项目。



敏捷开发运用之路

通过访谈,我们了解到美国国防部推动敏捷开发的两个主要原因:

1、 不少项目存在需要迫切解决的问题 (比如:如果维持现状,不改进效 果的话,可能会取消该项目);

2、 不少项目需要有快速及多轮的产出 物。

我们还发现可能更令人信服的推进敏 捷开发的理由。2010 财年国防授权法案 第 804 节规定了信息技术系统包括:

(A)早期和持续的用户参与; 

(B)多种迅速执行的增量或版本发布的 能力;

(C)早期利用连续的原型来支持增量的 开发;

(D)模块化的开放式系统。 事实上,敏捷方法比传统的 IT 采购更适用并兼容以上4个方面,支持并适当采 用这些方法,未来的结果会更令人鼓舞。

对于已经使用了一段时间敏捷方法的人而 言,持续改变的动力通常有下面几点:

●当他们提交了一个增加了最终用户所需 功能的新版本时,会产生一种真正的成就 感。

●短时间内他们会看到自己的工作对最终 用户的差异。

●鼓励(经常称赞):用户提出反馈意见, 来清晰的讨论方法的价值。

●一贯的达到或超过用户期望的能力。

●以前无法在约定的时间间隔提供价值和 成本。

为了运用敏捷开发方法,需要考虑最 好的实践和组织级管理的改变,典型的包 括:

●理解试用人群:我们需要理解组成团队 的人的特征,也要考虑团队本身的特性。 在美国国防部,采用敏捷开发的人,他们 是这个大环境中探索敏捷合作方式的探路 者,基于传统工作方式来执行文档和证据 的提供。只有当完善的支持更多交流和实 施支持机制建立健全后,敏捷方法才能成 功地在美国国防部跨部门中广泛应用。

●理解循环变化规律:变化需要努力和时 间。从我们的访谈中可以看到,经过一段 时间的阶段性的运用敏捷方法后,可以让 员工开始形成这种新的工作习惯。

●理解运用风险:了解团队中的活动,技 能,倡议和价值。

●建立过渡机制来缓解风险:一些潜在机 制参考 CrossTalk 的相关文章,国防新闻 中关于成功运用敏捷方法的节目,以及运 用敏捷方法的优点。

结论

敏捷方法具有响应及时的好处,比传 统方法更能快速调整当前的状态。运用敏 捷方法也要克服障碍,有些人已经在敏捷 的路上,开始积累信息财富来帮助想要改 变的组织。


评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。