3

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

 2 years ago
source link: https://www.techug.com/post/seven-things-you-must-know-about-agile-development.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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

2

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

敏捷开发模式是现代软件开发的通用模式,据统计从 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)每个人都是成功的关键。而合理的组合你的团队,让这些团队服务于一个产品。当这些团队在一起,能够一个迭代一个迭代去实现产品的各种功能来满足用户的需求,对企业产生价值,从而证明了他们的价值所在!!!

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK