借助持续交付建立高效的敏捷研发流程

打算建立标准化研发流程的你具备以下这些基本条件吗？
 
借助持续集成&持续交付建立标准化流程，至少需要满足以下四点要求，否则，可能会导致改进偏离原有方向：
 
1.技术驱动改进
2.系统思维
3.数据支撑
4.行政支撑
 
一、技术驱动改进
 
梳理当前研发流程的过程并不仅是为了增加标准化的研发流程，而且，我们也需要摒弃现存的一部分不合理，不恰当的流程。如果在这一环节与研发脱节，你将无法理解现有研发流程的所有环节。如果，你混淆了Windows的应用程序开发和iOS的应用程序开发，那么你将无法正确的思考iOS研发过程该如何与应用签名的结合问题。
 
《吕氏春秋·荡兵》有言：“譬之若水火然，善用之则为福，不善用之则为祸。”工具的使用也是同样的道理，选择和使用正确合适的工具能够帮助我们解决很多问题，反之亦然。在流程改进中，除了研发部分的内容外，编码、测试、构建、打包、发布、配置、监控等环节所需要使用的技术和工具，能否被正确合理的使用，也是持续集成&持续部署成功的必要条件。如果将Windows记事本用于编码，则没有语法高亮、断点调测等IDE必备功能。目前，市面上针对其中每个环节都有多种可供选择的工具，并且每天都有新的出现。如果，你希望流程和工具更加契合，你必须分析所有的这些解决方案，衡量其性能和功能，并在适当的时候使用它们。
所以说，工欲善其事，必先利其器。我们需要把技术驱动改进作为持续交付的核心点。
 
二、系统思维
 
改进并不仅仅是针对研发流程中的某一个点，而是一个从点到面的改善过程。需要团队成员抛弃原有的研发、测试、管理等职位的自我定位，将整个产品研发过程看作整体，理解从需求获取到产品交付的整个过程，而不是仅仅局限于职责范围内。
 
产品工程师的核心是客户需求向产品功能的转化，研发工程师的核心在于编码效率和准确率，测试工程师则专注于验证新功能、验收新产品，而运维工程师会思考如何保障产品运行时环境的稳定。从整个研发团队的角度，团队的核心能力既不是需求的转化，也不是编码，更不是验证和运维，而是持续的交付客户价值。
 
从价值流的角度来看，客户的价值既不是在合同签订时产生，也不是在交付的那一瞬间产生的。价值的产生和增长，贯穿着从业务需求到交付客户的整个过程中，最终在交付客户的时候体现出来。在这其中，并不是所有的流程都会创造价值，但是，部分不创造价值的流程同样不可或缺。
 
所以，系统思维是要转变团队的思考方式，进而改变团队的工作方式，不再以完成岗位任务为目标，而是需要将目标确定为确保整个团队能够持续的交付客户价值。
 
三、数据支撑
 
并不是所有针对流程的改动我们都将其称为流程改进。流程改动并不需要针对结果有任何的保障。但任何的流程改进都是对现有流程全部或者部分的否定！如何证明新的流程优于的现有流程——研发过程数据。
 
新的方案是否降低了缺陷比例，或者提升了生产率，或者降低了总体成本……任何的改进都需要使用数据进行论证。数据的收集方式有很多种，参考企业历史数据、现有项目过程数据等。部分团队在数据搜集、分析方面甚至会采用六西格玛，在敏捷的Planning Meeting中，采用六西格玛预测下个Sprint中可能会找到的Bug数量和所需人力。
 
通过数据的收集和分析，我们可以对流程执行结果进行评，为流程的改进提供基础数据支撑。
 
四、行政支撑
 
流程改进并不是一触而就的，虽然最终会从时间、成本、质量等方面获得不错的收益。但是，在这中途可能会遇到挫折，失败，甚至倒退的现象。因此在进行流程改进之前，需要从行政方面得到支持，包括研发、市场、财务、主管部门等方面。
 
改进会从研发团队建立持续实验和持续学习的文化入手。持续学习让研发团队能够接触到最新的理论&技术，对行业有更深刻的理解。持续实验可以将持续学习所得到的知识经验应用到实际研发中，让最终交付的产品有更好的功能、性能等特性。当然，这一切的正常运作，和行政方面的全力支持是紧密联系的。
任何的创新和改进都具有风险，也可能会给团队带来意想不到的收益。管理层需要在理解风险的同时，支持研发团队的技术创新和系统改进，将其作为研发构成的一个部分，分配相应的人力、物力等资源，通过管理和控制去规避不必要的损失，而不是拒绝改进，或者因为某一次的失败，来否定团队或者是个人在改进上的努力。
 
有了流程改进的四大支撑，接下来，就可以开始进行流程改进了。下面，会告诉你如何选择合适的时机进行改进。