敏捷开发之热门已达到任何一个开发人员都至少听过,并觉得敏捷方法很好,然而并不是所有的人都学习和实践过,以致于大家谈敏捷的时候其实理解的基准是不一样的,也导致“敏捷”泛滥成灾“,有些看似很敏捷的开发其实并不敏捷。

  近在一个项目中准备采用Scrum开发方法来解决以往开发方法中遇到的一些问题,所以近期将发表一些个人对敏捷的一些看法,欢迎和大家交流。

  过程与工具、面面俱到的文档、合同谈判、遵循计划

  个体与交互    胜过   过程与工具
  可以工作的软件  胜过   面面俱到的文档
  客户协作     胜过   合同谈判
  响应变化     胜过   遵循计划

  2001年2月由17位世界轻量级方法学家提出了一份敏捷联盟宣言 ,这个宣言只是简单的四句话,但却是敏捷方法的精髓,在谈敏捷方法之前必须先对敏捷宣言有所理解。在和一些人员交流中,我发现大家都知道敏捷,但是能说出这个简单的敏捷宣言的并不多,都说当时知道,过了一阵子忘记了。究其原因是靠死记硬背是不行的,需要通过自己的思考形成自己的理解才能够真正记住。上面的敏捷宣言非常简单,仅仅四句话而已,有的项目会出现上面这个漫画所描述的状况,领导说“我们开始尝试使用一种叫做敏捷的方法了,这代表不再需要计划并且不再需要文档,只需要开始编码”。这其实是简单记住敏捷宣言的几个字而出现的严重误解,下面我将对这四句话进行解释,希望大家跟随我的讲解也能对这个宣言有所认识。

  合同谈判   

  项目开发 一般都是跟随着合同开始的。由客户经理同客户交谈,在合同中确定一些法律条文以及交付产品包含的功能,然后客户经理拿着合同回到公司由开发小组经过长时间开发后再交付给客户。在开发期间,如果需要变更合同,则需要经过一系列流程。开发过程中,有些客户可能只是简单的询问一下进度,有的甚至是到后交付日了直接来问你要东西,当产品不能满足合同规定时需要和客户谈判进行解决。仅仅通过合同谈判来开发产品,客户在开发过程中不会进行实质性的反馈,导致终的产品不满意也很正常了。

  产品开发 在早期市场不成熟的时候一般为公司领导(产品经理、LPDT)驱动,后期转变为用户驱动、销售驱动、服务驱动,在矩阵式管理模式下,产品事业部和开发管理部作为两个部门时,在做产品开发的时候会类似在进行合同谈判,从一开始会在两个部门之间产生争执而不是合作,这势必会影响产品的开发。

  遵循计划

  当拿到合同时,公司开始组建项目组进行开发。此时需要项目经理制定出明确的计划,必须详细列出需求、设计、开发、测试、部署的各项任务。当项目组提交看似完整齐全的计划后,公司视这个不变的计划作为项目组对公司的承诺,没有特殊情况时必须遵循制定的计划,如果想要变化,则需要经过公司评审。

  软件复杂度有三个主要因素:业务、技术和人员。

  关于业务和技术的关系我已经写了一些博文,有兴趣的可以去看看( 从横向领域和纵向领域来谈业务和技术的关系 )

  《agile project management with scrum》(中文书名:Scrum敏捷项目管理)一书中有一个复杂度的图。

  X轴表示技术(成熟度),Y轴表示业务(一致度)。从图中可以看到,业务和技术是正交的,各自对复杂度都有影响,我们在开发过程中需要做的通过各种办法尽量确保从Anarchy-Complex-Complicated-Simple进行转移。