3.1 重新诠释敏捷宣言

2010年,[email protected]敏捷社区的讨论热点集中在“软件全生命周期敏捷”和“分布式敏捷面临的挑战”这两个话题,使我对敏捷的价值和敏捷宣言又有了新的理解,也促使我放下对“核心敏捷”的纠缠,以开放的心态研究IBM内部不尽相同的敏捷开发过程。

在此,请大家再次回顾敏捷宣言的四条要义:

00073.jpeg

我们用敏捷宣言的四条要义来诠释Scrum方法,同时,用Scrum方法中的实践、策略来反思这四句“语法”不甚完整的宣言,通过新的理解得到了12条“敏捷原则”:

·优先级最高的目标是通过尽早地、持续地交付有价值的软件使客户满意。

·拥抱需求变更,甚至在开发后期,利用变化为客户提供竞争优势。

·经常交付可以工作的软件,从几个星期到几个月,周期尽可能短。

·业务人员和开发人员必须每天一起工作。

·以人为本,激励个人,同时给予他们所需要的环境和支持,并且信任他们能够完成工作。

·团队内部最有效的沟通方法是面对面的交谈。

·“可工作的软件交付”是首要的项目成功度量方式。

·敏捷项目必须注重团队的“可持续性”。投资人、开发者和用户应该能够理解并支撑团队保持一个可持续发展的工作强度。

·持续关注技能的卓越化,优秀的设计会增强团队敏捷能力。

·简约是最大化生产力的秘密。

·最好的构架、需求和设计出自于“自组织团队”。

·每隔一定时间,团队将坐在一起反思如何才能更有效地协作,并做出相应的调整。

这12条原则不但可以诠释敏捷宣言的价值观,而且是对Scrum的坚实支撑。软件工程理论的发展离不开精确的定义,领导团队也的确认为IBM需要一个精确的定义。事实上,业界对于敏捷软件开发一直没有正式的定义,甚至可能永远没有。但IBM团队给出了一个可能有用的工作定义(来自前IBM首席方法论学大师Scott Ambler):

“敏捷软件开发是由价值驱动的、有规律地生产高品质软件的、具有成本效益和时间观念的方法,也是一种进化性(迭代和增量型)的方法。它是一个高度协作的、有规则有纪律的、自我组织的、软件利益关系人积极参与的方法。通过利益关系人的参与,确保团队了解并重视解决利益关系人不断变化的需求。使用此方法的团队,即敏捷软件开发团队,将基于其面临的独特环境,采用适量的敏捷仪式持续地交付。”

让我们来展开定义中的一些关键概念:

·价值驱动。将每个迭代目标均设定为一个潜在可交付的产品或解决方案,持续地为产品注入真正的价值,并且每次均以可用软件的形式体现出来。

·有规律地生产高品质软件。敏捷主义者必注重质量。他们更喜欢早期进入且反复测试,更为严格的敏捷主义者甚至会采取测试驱动的开发方法,这意味着编写一段测试代码,然后用刚刚足够的生产代码来通过测试,以实现每项功能和构建(然后迭代)。很多敏捷开发者已经采用了“重构”方式,即对代码或者架构做简单的修改,以实现兼容扩展的新功能,而不改变其原有功能。通过采用以上这些以提高质量为目标的方法和技术,敏捷团队比传统团队更有可能提供高品质的软件。

·进化。敏捷的共性是迭代和增量。“迭代”的意思是在原有代码版本的基础上,通过一系列的重复过程增加内容,完成每个构建、每个版本直至项目完成。但是,这并不意味着工作本身是重复的。在迭代过程中可能要做需求分析、测试、编程、设计,这些工作过程相似但内容不同。“增量”是指将新的功能和工作代码添加到最新的构建,直至利益关系人确定有足够的价值并发布产品。

·成本效益和时间观念。敏捷团队希望实现的功能,其优先顺序由他们的利益关系人(或能够代表客户的人)定义。因此,能够最大限度地提高投入产出比(ROI),也正是如此,他们更关注工作的高价值功能,从而提高成本效益。敏捷团队更愿意在每一次迭代中产出可交付的软件(迭代是一个时间盒子,长度通常为2~4周),这样利益关系人可根据已交付的成果来决定何时进行正式版本的交付,从而提高了时效性。短迭代周期也缩短了反馈周期,提高了发现问题的速度(无论成功、失败都是快速的),从而能够勇于正面解决问题,即使有些情况下会显得缺乏足够的能力和经验。

·高度协作。系统构建或项目开发获得成功的决定因素是“个人和他们的协同工作方式”。敏捷团队致力于尽可能有效、紧密地合作,这种特质必须每个人都具备,即使是领导团队也不能例外。

·有规则有纪律。敏捷软件开发需要从业者、团队拥有更为严格的纪律性,这点胜过传统研发方式对团队的要求。

·自我组织。自我组织的团队意味着从事工作的人需要自己做计划,自己估算工作量。

·利益关系人积极参与。敏捷团队与他们的利益关系人密切合作,这其中包括最终用户、最终付费人、企业架构师、支付技术工程师、运营业务人员以及其他相关人员。在IBM内部,我们将利益关系人分为四类:赞助商(投资人),合作伙伴(商业伙伴和合作的人),最终用户,内部使用产品的人。利益关系人或他们的代表(产品负责人,或一个客户驻场代表)将持续、及时地提出意见和做出决策。

·利益关系人不断变化的需求。随着项目的进行,利益关系人面前阶段性地呈现了可以工作的产品的部分功能,即使不够完整,他们也将更好地了解自己想要什么。因此,利益关系人很可能在评审过程中改变初衷和需求。而这种可能的变化源自商业环境的不断变化,或者源自团队任务的优先级调整。

·适量的敏捷仪式。“仪式”是指在项目中使用的流程、规范(方法)。例如,结对编程、文档的审阅、对代码质量的讨论。敏捷方法专注于可交付的产品,但不意味着没有流程和规范,不代表破除“仪式”。敏捷团队仍然生产适量的文档、持有恰当的评论,这和传统项目几乎没有不同。

·持续地交付。利益关系人显然不关心产品团队如何实现、如何解决问题,他们只关心阶段性交付了什么。特别是,他们总是对能够满足当下需求的解决方案有兴趣,因为这使得他们的投资更加理性、智慧。这种持续交付是以固定时间盒子作为周期,以更高质量作为目标的行为。总之,利益关系人关注的是持续的交付结果,而不是方法和过程。