敏捷开发你必须知道的7件事

摘要:从个人的经历来谈一谈敏捷开发你必须知道的一些事。

敏捷开发模式是现代软件开发的通用模式,据统计从2018年开始,有90%以上的软件开发都采用敏捷开发模式。先不讨论敏捷开发模式与瀑布开发模式优劣,就当前数据统计以及各大公司的转型结果来说,特别是连SPACEX这种公司连整火箭这种超级硬件都采用敏捷开发,采用敏捷开发肯定是有一定的优势。

作者本人参与软件开发20年,经历过传统的瀑布开发模式,参加过专业的敏捷开发培训,拿过认证的证书,带领团队经历过瀑布转敏捷的整个过程,从小到10个人的Scrum团队,到几百人共同参与的多Scrum团队合作。先分享一段很有意思的经历,最早公司尝试做agile,老板把不同领域的人加上1个QA组成了一个10-12人的Scrum团队(我作为PO兼职PM、QA兼职SM),老板的要求就是这个团队能够完成从需求、设计、研发、测试的所有事情(那时候还没流行DevOps,运维不归我们管)。接到的第一个项目就是跨Web、Server、client以及复杂场景的测试,由于本身项目的领域分工不均衡,这时候要求在项目中一边工作,一边跨领域学习新知识,就这样慢慢的做了3个月,团队在过程中快速成长。后来由于特殊事件,我带着这个团队接了一个新的项目,而这个项目的开发管理流程与整个公司都不一样。 整个团队增加了一个PM(该PM管的事情很多,我们只是一块),而做的事情本身就是End2End的feature,包含客户端(偏多)以及服务器和Web API端(偏少),同时客户端跨多个平台(Win/Mac/iOS/Android), 没有专门的团队给我们做测试,我们团队必须自己完成发布前的所有测试工作(开发者测试+系统级别的测试)。在整个研发过程中,还需要和美国爱尔兰团队一起协作沟通,那段经历对于团队的每个人成长非常大。当年一个普通的开发人员,现在在微软也在短短几年做到了Senior Manager的位置。

这篇文章,聊的不是Agile流程本身该怎么做,而是从个人的经历来谈一谈敏捷开发你必须知道的一些事。

1、搞清楚团队为什么要转Agile开发模式!

敏捷开发与瀑布开发的根本区别是“迭代开发” + “增量开发”。这里要着重说的是增量开发,如果你的团队开发的项目或产品采用敏捷开发,然而不是通过增量开发的方式,团队会很困惑为啥要敏捷,敏捷带来了什么?笔者所在的项目最早采用瀑布开发模式,通常3-6个月一个release。当转向敏捷时,团队受到最大的鼓舞是客户的肯定,因为6个月的项目,在2个月的时候,客户就可以试用最初级功能的版本,客户对于几个月以后的产品充满了兴趣,即使在使用中遇到了很多问题,但是他们还是很乐意的去使用,并且在使用中提出很多意见和反馈。而这些反馈对于团队来说是巨大的帮助,而在每个月的迭代过程中,客户一步一步看到功能的完善和变化,当产品release之前,客户已经对于即将拿到的产品有了全面的认识和了解,对他们来说,这种产品就是他们想要的,甚至一些产品功能和使用习惯都是他们自己提出来的。这种开发模式所带来的变化是很多团队转向敏捷的根本原因。如果你对团队采用敏捷,然后开发的模式只是把产品开发的6个月的工作划分到每1-2周中,实际上并没有真正理解敏捷,也享受不到敏捷带来的好处,这时候你去转敏捷,可以说意义不大。

2、产品质量的好坏和Agile本身无关!

我在不同的文章中不止一次说过,产品质量的好坏与开发流程关系不大,至少和敏捷瀑布模式无关。产品的质量需要人+时间。合适的人加上充足的时间,才能提升产品质量。笔者在之前公司是做在线协作产品的(Welink + 视频会议),我们的产品发布模式是每个月一个Feature Release (Deliver Feature),每周一个Patch Release (Fix Bug)。去年疫情期间,基于疫情状态下的产品需求激增,为了迎合市场,加班加点不说,整个开发出来的功能比平时多出100%不止。在这种情况下,产品的质量可想而知,很多问题都是发布前就已经已知的,由于市场需要,很多时候是在VP批准下,产品带着上百个bug上产线。然后后续通过一个个Patch Release来慢慢fix这些bug。产品质量的好与坏最终决定于你的测试,不管是开发者测试还是QA团队测试,最终你的产品发布之前经过完善的测试才能保证质量。当然开发者测试的重要性咱们这里就不再讨论了。

3、Agile很重要的一件事情就是管理好你的backlog!

敏捷开发很重要的一点就是即将做的事情总是在变化的,在变化中决定未来一段时间的做什么。而所要做的事情就是我们常说的backlog,管理好你的backlog是极其重要的。整个敏捷高速运转的基础就是backlog的管理。

backlog的管理通常参考以下几个方面:

  • 未来两年之内,你可能会做的所有事情,并且给每一个事情打上一个预估的优先级(可以是数字,也可以是字母)以及预估的工作量(T恤Size,XS, S, M, L, XL, XXL...)。
  • backlog有用户需求相关的,也有研发代码重构,架构演进技术相关的。
  • 团队定期坐下来决定未来3-6个月要大致做什么,包含需求及技术的backlog,这时候要平衡技术类与用户类的需求。
  • 当决定要做的东西,架构师要从技术上做到Design Ready(通常用wiki来记录),包含架构设计(Design)以及工作划分(US/Task)都可以确定,这时候才会真正拿到项目迭代中去实施。
  • 每个迭代计划时,再有团队坐下来决定,从Ready的backlog中拎出哪些做。

从backlog的管理上来看,产品经理与架构师是非常重要的角色,2者除了正常的迭代过程外,承担了整个迭代的准备工作。而整个团队更像高速运转的机器一样去一个一个迭代去“生产”出“商品”。说到这你可能就明白为什么那么多企业要转向敏捷开发,除了第一点以外,就是最大化利用人力资源来产生价值。

4、大型项目尽可能的End2End的来拆分Agile团队

通常公司会按照一定的规则来划分组织结构,以我之前的公司为例,最早按照地域(上海、合肥、杭州、苏州)划分,后来按照领域(Client、Web、Server)划分。即使在一个领域内,也有不同的细分。但是一般来说,做一个产品功能,会涉及到不同领域,同一个领域的不同子领域。很难做到一个组织结构内部的所有人可以搞定所有事情。特别是大型的项目,如果把每一个Scrum团队按照领域划分,做一个功能需要多个领域团队共同一起完成,这样的项目会遇到很多问题。而我之前的经验是一个大型项目,每个迭代会规划处很多不同的功能,把功能分配到不同的scrum团队里,而每一个scrum团队是根据功能来组合人员,保证每个团队都可以相对独立的完成几乎所有的工作,End2End的来deliver feature。这时候团队的组成有2大特色:1是来着不同的组织(不同的LM),2是团队人员经常变动。这种模式其实极具挑战性,对人的协同工作能力要求很高。

5、Agile团队PO和SM是团队的保障

在整个产品迭代过程中,很多事情是非常繁琐的,同时也会受到各种各样的干扰,还有各方面的压力。这时候PO与SM是整个团队的运转核心,对于PO来说,只要能抗的责任,都由他来抗,不要让团队有任何顾虑,通常可以有管理岗位的人来担任PO的角色。SM是帮助团队管理项目的,这里强烈建议由合适的女性担任。对于SM来说,只要她能做的和项目相关的事情,就不要推诿,主动去帮助团队来完成,比如会议的组织,状态的更新,团建等各种事物,让团队的精力更Focus,动力更足。PO + SM的共同任务就是保障团队的在迭代周期内的全部精力都是在做事。

6、Agile的成败、效率决定因素最终是人

我们在说3、4、5的时候,你会发现我们讲到了PM、Architect、PO、SM以及Team,我们在讲人,而不是讲流程。Agile流程给了整个团队更多的自主性,要求团队每个人从意思到能力都要比较强。说到这你会发现,这种团队很像一个小的创业团队,没错这也就是为什么创业团队效率高的原因。而实际上在大公司,很多时候由于各种各样的原因无法做到这种团队,那么就需要根据自身人的情况来调整流程本身。

7、我们要的是演进式敏捷,而不是标准式敏捷!

如果你去不同的公司,每一个公司的团队在进行敏捷开发过程中,都会有不同,而且其自身也是在不断演化之中。原因在于不同的公司有不同的文化,以及人员的组成各不相同,一个团队即使全是牛人,未必可以把敏捷搞好。敏捷团队本身也是在运转过程中,根据自身的成长,以及人员的变更,甚至是组织结构的调整,像架构一样不断地去演进。以我之前的团队为例,我们的Scrum团队没有PO的定义,而其职责由Product Manager, Deliver Manager,以及Architect共同来完成,加上SM,这四个人会形成固定搭配,然后根据项目来带领多个团队,组成多个scrum团队。这就与传统意义上的敏捷团队有很大不同,也未必有可复制性。所以这篇文章,我无法告诉你如何如何从瀑布成功转型敏捷,也无法告诉你具体方法来提升团队的敏捷效率。但是你可以明白,人是敏捷团队的基础,一个Team(PO+Architect+SM+PM+Members)每个人都是成功的关键。而合理的组合你的团队,让这些团队服务于一个产品。当这些团队在一起,能够一个迭代一个迭代去实现产品的各种功能来满足用户的需求,对企业产生价值,从而证明了他们的价值所在!!!

 

点击关注,第一时间了解华为云新鲜技术~

posted @ 2021-10-18 11:36  华为云开发者社区  阅读(76)  评论(0编辑  收藏  举报