敏捷开发你必须知道的 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 (DeliverFeature),每周一个 Patch Release (FixBug)。去年疫情期间,基于疫情状态下的产品需求激增,为了迎合市场,加班加点不说,整个开发出来的功能比平时多出 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 的定义,而其职责由 ProductManager, Deliver Manager,以及 Architect 共同来完成,加上 SM,这四个人会形成固定搭配,然后根据项目来带领多个团队,组成多个 scrum 团队。这就与传统意义上的敏捷团队有很大不同,也未必有可复制性。所以这篇文章,我无法告诉你如何如何从瀑布成功转型敏捷,也无法告诉你具体方法来提升团队的敏捷效率。但是你可以明白,人是敏捷团队的基础,一个 Team(PO+Architect+SM+PM+Members)每个人都是成功的关键。而合理的组合你的团队,让这些团队服务于一个产品。当这些团队在一起,能够一个迭代一个迭代去实现产品的各种功能来满足用户的需求,对企业产生价值,从而证明了他们的价值所在!!!
版权声明: 本文为 InfoQ 作者【华为云开发者社区】的原创文章。
原文链接:【http://xie.infoq.cn/article/db8f806cc9a297512ab3fbab5】。文章转载请联系作者。
评论