敏捷开发你必须知道的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）每个人都是成功的关键。而合理的组合你的团队，让这些团队服务于一个产品。当这些团队在一起，能够一个迭代一个迭代去实现产品的各种功能来满足用户的需求，对企业产生价值，从而证明了他们的价值所在！！！
