敏捷开发系列——原理篇-敏捷到底是什么?

阅读本系列篇文章后需要了解以下问题

Why:为什么需要做敏捷?

What:什么是敏捷?

How:怎样推荐敏捷?

瀑布模型的三个诟病

  1. 研发周期过长,导致研发跟不上业务发展的节奏。在瀑布模型中,所有的工作都是串行的,只有前序环节完成,才能展开后序环节,大量人力与时间成本都在这段时间里被白白消耗,等产品开发出来推向市场,很有可能市场已经没有了,或者业务已经发生了很大变化。

  2. 研发不能很好地响应需求变化,导致客户满意度低。要知道,我们很难在设计之初就把所有的需求都想清楚,需求又是不断变化的,因此客户在看到真正的产品出来之前,对产品很可能是无感的,正如上面项目中的客户,他们看到并试用了产品后才感觉到这里应该这样,那里应该那样。瀑布模型是在项目最后才一次性地向客户交付产品,当产品被开发出来之后,客户才发现他们需要的不是这个东西,这是非常可怕的事情。

  3. 不能很好地管控风险。因为是研发最后一次性交付,所以项目中的很多风险在前期很难被完全识别出来,最后发现时再想处理就要付出更大的代价。

敏捷的价值观:正确理解敏捷的初心

  1. 个体和交互胜过过程和工具
  2. 可以工作的软件胜过面面俱到的文档
  3. 客户合作胜过合同谈判
  4. 相应变化胜过遵循计划
  5. 虽然右向有价值,但我们更注重左向

需要注意的是,最后一条其实是对前四条价值观的解释说明,很多人在传递敏捷价值观时其实只讲了前面四句,而忽略了最后依据,很大程度上,这导致了大家对敏捷的误解。

结合这一条,前4条价值观中“胜过”一次的意思是:与每一条中右面的内容先比,左面的内容是敏捷更加重视的,但要注意,这并不表示让你停止做右面的内容。

比如说一个误解“敏捷来了,我们只负责开发软件就够了,再也不用做文档,也不用做设计了”为例,我们看看它的误解在哪里。

在敏捷价值观的第二点里,敏捷认为“可以工作的软件比面面俱到的文档更加重要”,然而这并不是说我们就完全不要文档了。对这句话的正确理解应该是:敏捷重视可工作的、有价值的软件,减少一切不必要的文档。注意,是不必要的文档,而不是所有文档

不必要的文档:比如说一些交接类的文档,开发人员开发完毕要提交给测试部门测试,还要写一个体测但,在一级一级批复,我认为这样的文档是可以省略掉的。因为在敏捷里,开发人员和测试人员是在一起工作的,所以提测的工作不需要走麻烦的申请与审批。

必要的文档:比如那些写着重要设计方案的文件,如果在后期遇到问题,其他同事就要回头查看文件,找出问题所在;或者是系统后期开发完成、需要转交给其他人维护时,若想知道这个系统当初是怎么做的,也需要去查看当时的系统设计文档,所以这类设计方案是需要保留下来的。你应该根据自己的项目情况,考虑哪些是重要的文档,哪些是不重要的。

所以说,敏捷的价值观并未否定或贬损”右向“的价值,”流程和工具“、”详尽的文档“、”合作谈判“以及”遵循计划“这些右面的内容也很重要,在敏捷里并不是完全不做。比如在敏捷中也是有计划的,只不过计划的方式与传统瀑布模式的计划方式不一样罢了。

敏捷的价值观体现了敏捷的初心,只有正确理解它,你才能更深层次地理解敏捷。敏捷的初心是通过一系列方法来让我们的研发工作更加灵活、有序和高效,所以敏捷的价值观重视人的能动性,强调人与人之间的协作,也更重视对变化的应对,这些都是为了能够更好、更灵活地组织和管理研发工作,但如果“流程和工具”、“ 详尽的文档”、“ 合同谈判” 以及“ 遵循计划” 同样能让研发工作更有序和更高效,那敏捷是不反对的,也不会放弃不做,这才是敏捷的真谛。

敏捷的原则:正确理解敏捷的基石

上面一段文字让我们理解了敏捷的价值观,但对于敏捷来说,只有价值观还不够具体,为了能更具体的指导工作,由敏捷的价值观又引出了12条敏捷原则,如下所示:

  1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
  2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
  3. 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
  4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
  5. 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
  6. 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
  7. 工作的软件是首要的进度度量标准。
  8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
  9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
  10. 简单——使未完成的工作最大化的艺术——是根本的。
  11. 最好的构架、需求和设计出自于自组织的团队。
  12. 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

这12条原则是正确理解敏捷的基石。

针对“敏捷就是快”这个误解,你要注意的是,在敏捷的原则里,可从来没有说过“敏捷就是快”这句话。所以你需要正确理解“快”这个词。

如果你将“快”理解为采纳了敏捷以后,你的代码编写速度就立即加快了,那是非常不现实的。虽然在敏捷中我们也会使用一些方法来训练整个团队的代码编写能力,但是这并不意味着用了敏捷后,陈煦园敲代码的速度就得到了显著提升。况且即使敲代码的速度加快了,项目整体上线的速度就也一定能快吗?

那么敏捷在交付上会带来什么变化呢?你可以先看一下敏捷原则里的第1条和第3条,总体的意思是:针对交付,敏捷希望能够今早交付可工作的软件给客户,而不是最后一次性交给客户,并希望交付的间隔时间越短越好。所以说,敏捷中的“快”其实指的是反馈更快,反馈更及时。

这样,我们就能更快、更准地得到用户的真是反馈,今早修正,为用户创造有价值的产品和竞争优势。在这一过程中,客户也可能更早一点想清楚想要什么样的产品,你也能比预想时间更早达成客户的目标。这里你也需要注意,是有“可能”,而不是“一定”。甚至,由于客户能够早些看到产品,通过修正,也许在某一个时间节点上,客户觉得目的达成了,项目可以技术了,这或许比客户预想的上线时间还要早。

但这绝不是通过快速写代码来完成的,而是通过不断检视客户的需求,总是优先做最有价值的事,减少浪费来达到的。在瀑布模式的项目管理过程中,我们把原计划的事情全部做完,项目即宣告结束;而在敏捷的原则下,客户的目标达到才意味着项目可以结束,这是因为敏捷是以业务价值和业务目标为导向的,根据业务价值和业务目标,段迭代使客户对自己的需求更清楚了,有可能做的事情更少了,所以时间才减少了,交付也更快了。

同样,“敏捷就是加班”这个理解当然也是有失偏颇的。你可以回到敏捷原则里,重新看看第8条:“敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能保持一个长期的、很定的开发速度。”

你可以清晰地看到,敏捷强调“可持续的开发速度”,这指的是团队能一直以稳定的开发速度持续下去,而不是为了加速开发,本次或几次迭代就一通加班,透支团队成员的健康,后面又由于员工身体不支等原因导致接下来的迭代开发产能下降。试想如果天天加班,员工能保持一直高昂的斗志和较高的工作效率?能否保证一直以这样的开发速度开发下去?我想这是不行的

那怎么才能做到保持“可持续的开发速度”呢?在咨询过程中,我看到能做到这一点的开发团队,通常都是这样做的:

  1. 他们在迭代开始的时候,不会过度承诺,也就是能完成多少,就承诺多少工作
  2. 严格遵守纪律。他们在迭代开始的之后,原则上不再接受需求的增加,如果一定要往他们的迭代待办事项里增加其它需求,就一定要同时从其中拿走等量的需求。

这么做有什么好处?我认为这样做,可以使开发团队聚焦在自己的事情上,不受干扰,效率更高,从而形成稳定的开发节奏;而稳定的开发节奏可以加强我们的预见性,这样我们预计的上线时间才可能是精准的。

所以,如果你的团队采纳了敏捷后加班更严重了,那么你应该参照上面的做法来自我检视一下,看看你的团队是否在一个迭代中承诺的事情太多了,也就是工作范围是否太大了,如果使的话,那你可以结合团队的实际产能,根据需求条目的优先级来进行调整;此外,你的团队是否遵守了几率,如果不遵守纪律,那额外的加班肯定不可避免。

现在,我们回过头再来看看敏捷原则里的内容,会发现它和敏捷宣言一样,重视研发各方的协作,并强调了持续改进、响应变化。只不过在这 12 条原则里,对敏捷重视的价值做了更细致的阐述,涵盖了软件项目管理的所有基本流程,而且这些流程很具体,让大家有了更可参考的标准,将敏捷的价值观落实到具体的、可操作的原则之上。

因此正确理解敏捷的原则,并以此为基准去行事,才能在后面具体的敏捷实践中不偏离,最终取得敏捷项目的成功。

敏捷的方法与实践:正确落地敏捷的基础

但很显然,只有价值观和原则,敏捷是不能落地的,你还需要一系列的敏捷方法和具体实践。

在提出敏捷时,建立敏捷联盟的 17 位大师所创立的敏捷方法包括:极限编程、Scrum、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法等等,这些方法被统称为敏捷方法。到现在还有很多关于规模化敏捷的方法,比如说 SaFe 和 Less;也有更多技术实践,比如说测试驱动开发。可以这么说,凡是符合敏捷价值观和原则的方法论,都可以归到敏捷的大伞下。

怎么样,敏捷是不是包罗万象?但敏捷的方法和实践虽然很多,你一定要结合自己的需求来选择。所以在这里我想和你强调的是,这些方法从共性上来说都遵守了敏捷的价值观和原则,不同的是它们针对了不同的应用场景,比如说 Scrum 在新软件开发中更好用,而看板在维护类的软件开发中更胜一筹。

所以开篇我们提到的 “Scrum 就是敏捷,敏捷就是 Scrum”这一说法,也是相当片面的,是对敏捷的误解。敏捷还有很多如上面讲到的方法,如果只认识这俩,那你在采纳敏捷时,无疑就受到了限制。

Scrum 框架看起来很简单,很多人以为它不过就是“三三五五”:3 个角色(产品负责人、团队、ScrumMaster),3 个工件 (产品待办事项列表、迭代待办事项列表、燃尽图),5 个会议(迭代计划会议、每日站会、迭代回顾会议、迭代评审会议、产品 Backlog 梳理会议),5 个价值(承诺 、专注、开放、尊重、勇气),以为只要把上面这些事情都照搬过来做完就万事大吉,就能用好 Scrum 这一方法了。但其实 Scrum 也是有约束条件的,如果不按照这些约束条件来使用它,是用不好这个方法的。

关于 Scrum 的约束条件,这里我举最重要的两条来说明:

  1. 迭代计划会议开始前,产品负责人需要准备好需求条目,使需求达到准入标准;
  2. Scrum 讲究时间盒,包括迭代的周期、各个会议,这些都要遵守时间盒的约定。

如果不遵守第 1 条约定,你会发现你的团队即使用了 Scrum,仍避免不了研发节奏被打乱的命运;如果不遵守第 2 条约定,你会发现你的团队被耗在各个会议上,会议效率又很低,团队成员很快就会感到厌烦。所以说,Scrum 是有纪律的,如果不遵守纪律,自由自在无约束,那么使用它注定是痛苦的,也达不成既有目的。

从上面 Scrum 的例子我们可以看出,了解敏捷的方法和实践,不能只了解它的表面,更要深度了解它背后的规则和深意,只有这样才能正确地应用它,并让它为我们的研发管理服务。

针对敏捷的每一种方法我建议你在使用前问自己 3 个问题,从下面几个方面去深入了解它

  1. 这个方法能解决什么样的问题?
  2. 有没有使用前提?
  3. 有没有相应的使用规则?

此外你还可以借鉴别人是怎么用这些方法的,看他们在使用过程中有没有遇到什么坑,如果有又是怎么避免的。我希望通过这样的自我提问,能让你深度了解敏捷,并在日后能正确地使用敏捷的方法。

总结

希望通过这篇文章,能够让你了解什么是真正的敏捷,并能够从人们对敏捷的看法中分辨 出哪些是对敏捷正确的理解,哪些是误解。

一句话,敏捷 = 价值观 + 原则 + 一系列符合价值观和原则的方法。单纯说敏捷是一种方法,肯定是片面的;只强调敏捷的价值观和原则而不重视方法也是不对的,因为那样敏捷就飘在空中,不能落地了。

因此对于敏捷,需要冲敏捷的价值观、原则、具体方法和实践上对它有全方位的认识,只从任何单一的方面去谈敏捷,都是片面的。更重要的是,做敏捷不能只关注具体的实践和方法;还要时时刻刻记住做敏捷的初心,不能偏离了它的价值观和原则。

发表评论

发表评论

*

沙发空缺中,还不快抢~