业务动态

CMMI还是Agile:为何不拥抱彼此!(五)

时间:2017-3-16 11:27:35  来源:管理员 打印本文

第五部分 · Agile的真相

敏捷宣言如下:

 “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value [the following]:

individuals and interactions over processes and tools

working software over comprehensive documentation

customer collaboration over contract negotiation

responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

“我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观: 

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划 

也就是说,尽管右项有其价值,我们更重视左项的价值。

敏捷宣言的最后一句经常被忽略(太多的敏捷的支持者和反对者一样出现这样的情况),“右项”(常见于太多的计划驱动,驱动项目合同,标准和审计驱动环境)不仅重视较少,也认为它们有效性也是零价值。因此敏捷宣言经常被敏捷的支持者所引用,作为没有过程、没有工作记录,没有计划的理由。这解释给了他们正当理由,批评者指责敏捷支持者是“散漫的仆人”。然而,这些对于敏捷宣言的解释是不完整的,虚伪的。

在一个真正的论述层次,谁重视“左项”胜过“右项”?记住敏捷宣言试图脱离的范式。在太多的执行中,有计划、流程和标准,过于详细,僵化,只是被人们、项目、产品、客户和技术进行滥用。


与敏捷方法相关的常见做法包括以下内容:

  • 使用迭代和短时间增量开发。

  • 频繁和持续的客户反馈。客户通常嵌入开发人员。事实上,广泛使用隐性知识是敏捷开发和实践的关键。隐性知识的使用是最有利的,在一个高的信任环境,可以直接受益于低交易成本的软件工程活动。使用隐性知识的风险,虽然往往没有明确管理,可以使用以下领域进行缓减:

  • 项目的周期(以及产品的预期生命周期)

  • 代码的自动生成文档

  • 使用的工具,可以重构和持续集成

  • 团队规模小

  • 每个增量潜在价值(例如工作代码)。价值也可以是什么不做。

  • 交付的产品是完全测试的。产品通常是首先通过编写严格的测试,然后通过测试来优化产品。

  • 每个人都拥有质量,包括客户(或客户代表)。开发团队往往是多元化的,其中所有的开发者都是通才,统称为“自己的”产品。客户同样负责确保产品符合他们的期望。当项目的功能、范围、限制性条件都达到一个统一的认识后,项目才可以被推进。错误发现的越早,错误的成本越可以低到可以忽略不计。

  • 随着对产品理解的越来越清晰,需要及时开发详细的需求。工作量不是通过猜测需求和期望来浪费的。随着产品交付的不断推进,产品的需求也越来越详细。

  • 在任何时候,变更时被期望、被拥抱、被欢迎、被接受的。预期的变化驱动设计决策。通过设计,产品和体系结构组件没有被锁定,使得开发人员可以进行连续的权衡,直到所有组件需求可用为止。

  • 使用自我驱动和授权团队。这样的团队任务成熟,训练有素,凝聚力强,高度信任,需要很少的指导,管理,或任务分配。广泛的产品,项目和业务目标与团队共享,以便明智的管理,组织和技术决策,可以由团队来决定什么必须做,由什么时候,由谁,以及什么标准。允许团队应对当前的情况,而不是坚持过度强调,过度详细的计划。因此,计划书和做计划实际上是经常更新,与上级沟通(无论是组织或团队)经常发生,几乎每天都会进行。与管理者或客户的正式状态会议,被替换为与利益里相关者频繁的互动。

  • 定期评估和调整过程。任务成熟的团队拥有调整他们过程的权利,他们基于工作的反馈进行调整。



一般来说,成功的敏捷实现的属性包括以下内容:

  • 由约十人组成的小团队

  • 客户介入

  • “滚动式”或持续规划

  • 合作和跨职能团队

  • 每个成员都可以胜任敏捷的组织

当以下存在时,敏捷是不成功的:

  • 缺乏过程

  • 缺乏原则

  • 没有计划或计划的角色

敏捷宣言有一个附加的总体原则列表。

  • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

  • 欣然面对需求变化,即使在开发后期也一样。善于掌控变化,帮助客户获得竞争优势。

  • 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

  • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。

  • 激发个体的斗志,以他们为核心搭建项目。提供他们所需的环境和支持,相信他们能够达成目标。

  • 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

  • 可工作的软件是进度的首要度量标准。

  • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

  • 对技术精益求精,对设计不断完善,将提高敏捷能力。

  • 以简洁为本,极力减少不必要工作量。

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

  • 团队定期地反思如何能提高成效,并依此调整团队的行为。

在线咨询 x
有什么可以帮到你
点击咨询