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

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

怎样用敏捷作改进

小瀑布模式的缺点在于它的沟通成本、等待成本、返工成本依然很高，所以咱们能够考虑从这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. 另外，决定敏捷开发可否运行很好的因素还有不少，只有不断探寻最佳实践，持续改进，才能无限逼近咱们指望的状态。

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

本文只是经过一个真实的客户案例，来分析如何基于当前现状作敏捷改造，本文并无写彻底部敏捷改造的内容，由于敏捷包含的内容实在太多了，若是你们感兴趣能够给我留言，后面我会继续分享这个案例中涉及到的其余敏捷改造。