敏捷改造（下）：真实案例敏捷改造

上篇分析了我做过的一个真实的项目的研发过程中的种种问题，那么这篇就来讲解一下我们如何针对这些问题做敏捷改造。

怎样用敏捷做改进

小瀑布模式的缺点在于它的沟通成本、等待成本、返工成本依然很高，因此我们可以考虑从这3个角度出发去做改进。

我画了一个图来展示小瀑布模式和敏捷开发的详细对比。

图中紫色管道是小瀑布模式，蓝色管道是敏捷开发，两个管道是相同的团队管道容量，换句话说，两种模式的工作载量是相等的。

横向是时间线，从左到右，按需求提出开始直到此需求上线，即为此需求的生命周期。

首先，先说一下为什么这3个成本很高。

沟通成本

产品经理通常需要1-2小时来与业务方进行需求沟通，沟通完了之后，产品经理会有一个初步方案，然后会与团队内部的技术人员，测试人员等，一起评审这个需求，如果这中间有任何疑问，产品经理就需要不停的反复在业务方与技术人员中间进行沟通。因此沟通成本是比较高的。

产品经理通常也需要1-2小时来与技术人员一起做技术评审，时间比较长，很多问题细节需要来回反复确认，沟通成本很高。

总结一下就是，由于需求粒度比较大，每个环节都比较重，有大量的细节需要讨论和确认，因此带来了较高的沟通成本。

等待成本

开发只有等产品文档完全设计好了，才能开始开发，由于需求粒度过大，此设计过程相对过长，因此开发的等待时间也长，没有充分利用开发资源。

同理，测试也是，只有等开发提测了才能做测试。但测试在此之前，会先写测试用例，因此测试资源浪费还算较小。

但另外一个问题是，测试一次性要写非常多的用例测试，一次性测那么多用例，测试的完整性完全依赖于测试人员的耐心。

返工成本

测试如果发现问题，会让开发返工，由于需求粒度比较大，经常出现测试发现多个问题的情况，那么就会来回的多次返工与测试。

甚至有时候返工会直接返到业务方去重新确认需求的细节。

---

敏捷研发过程改进

那么敏捷是如何改进这个过程的呢？

首先敏捷是提倡小步快跑，拥抱变化。目前由于需求粒度比较大，无法小步快跑，同时开发到中间的时候的，需求突然变化，应对起来也比较慢。

那我们就可以根据下图来进行改造。

上图中最大的变化就是把原来的需求A拆解成了3个story。

敏捷提倡小步快跑，那么管理需求也一样，只有需求足够小，才更利于我们快速理解和分析。而user story（用户故事）则是敏捷里面的一个可以工作的最小单位。

用户故事在软件开发过程中被作为描述需求的一种表达形式；为了规范用户故事的表达，便于沟通；包含角色、活动、价值三个要素。

瀑布式的需求管理和敏捷需求管理的区别在于：

• 瀑布式的需求分析要求在一开始就获取所有需求，分析所有细节，并且假设我们可以对软件项目有个完美的预测。
• 而用户故事则基于我们不能完美预测，不能在一开始就知道所有细节的基础。因为我们对需求的理解是一个逐渐清晰的过程。同时，在项目开始时尝试编写所有的需求忽略了重要的反馈循环。用户故事承认故事的时间维度，随着时间的推移以及功能的增加，会有新的用户故事产生，或者使故事的相关性发生变化。所以要延迟细节，融入业务到整个软件开发过程中，鼓励交流和沟通。
• 另外，做了用户故事拆分之后，产品经理或者BA需要补全细节，不停的做需求澄清，和业务方做sign off。
• 敏捷需求管理会借助JIRA等工具进行可视化的看板或者scrum管理。而不是基于传统的Excel管理。
• 每个故事写好之后，会让业务方做card sign off，比如在卡下面留言ready to go等。如果每张卡做sign off太频繁，可以由产品经理或BA单独找业务方用邮件等的形式针对一个epic统一做sign off。
• 敏捷里其实没有一个专门给业务方和产品经理/BA的需求澄清会，因为默认为已经发生在日常工作中了，按理说应该分析一张卡确认一张卡，才能尽可能减少因一张卡片理解不到位引起的大面积返工。

拆解成小的用户故事之后有如下一些好处：

1. 原来产品经理和业务方的沟通成本随着需求被拆成小的用户故事而变小了。
2. 由于用户故事比较小，分析完成的时间就变快了，产品设计的时间也变快了，那么开发开始的时间也就变快了，减少了等待成本。
3. 由于开发时间更短，第一个用户故事测试时间也就提前了，因此如果出现问题需要返工，那么返工的时间比原来就更早，返工修改的内容也更少，能较快的完成返工并重新测试。整体返工成本就变小了。
4. 由于各方时间都提前了，那么第一个用户故事上线的时间也提前了，业务方就能更早的看到需求的部分功能，就能更早的反馈问题。
5. 由于每个环节的沟通成本，等待成本，返工成本均减少了，因此整个需求的交付时间也就提前了。

从下图就可以看出，每个环节相比之前都是提前的。敏捷的目的是能够让团队拥抱变化，快速响应。

敏捷开发改进

分支改进

原来的分支管理比较混乱，可能造成的问题已经在前面分析过了。

这里就说说分支管理的最佳实践是什么。

1. 现在业界普遍都采用了git flow，具体怎么做可以Google一下，网上有太多文章讲这个，我就不赘述了。这里就展示一张git flow的全景图。
   

2. 每次git的commit message的推荐格式：Card ID: message

   1. Type主要有：feature, refactor, fix等。
   2. 每次git的commit推荐能关联到每个故事卡的卡号，这样方便追溯每个故事卡相关的改动。现在很多工具都支持通过message的卡号直接找到对应的故事卡，反之亦然。

CI/CD

• 从代码的生命周期开始，CI/CD是保证每个环节快速流转的基础，同时也是快速获取反馈的途径。
• 而CI的基础则是自动化测试，比如最基本的单元测试。

• 每完成一张故事卡，理论上都可以持续部署到生产环境。而不应该等待所有需求都完成了，或者等前后端都完成了，再做上线部署。

  • 部署的步子越小，回滚的成本也就越低。

总结

图里的敏捷开发一定比上面的小瀑布快吗？不一定，这里还有几个因素是需要考虑的。

1. 需求A拆解成story是有成本的。根据产品经理或BA的能力不同，以及需求复杂度的不同，拆卡花的时间也不同。
2. 小瀑布模式里面，在没有bug的情况下只会测试一次。在敏捷模式下，相比原来的小瀑布，会针对story1和story2做回归测试。因此增加了测试时间。
3. 另外，决定敏捷开发能否运行很好的因素还有很多，只有不断探寻最佳实践，持续改进，才能无限逼近我们期望的状态。

总结起来，敏捷是通过小步快跑的方式，提升了响应变化的速度，以达到提升整体交付速度与质量的目的。

本文只是通过一个真实的客户案例，来分析如何基于当前现状做敏捷改造，本文并没有写完全部敏捷改造的内容，因为敏捷包含的内容实在太多了，如果大家感兴趣可以给我留言，后面我会继续分享这个案例中涉及到的其他敏捷改造。