敏捷开发
敏捷开发，现在大多数团队都在推崇敏捷开发模式
笔者最开始理解的时候，也在疑惑到底什么是敏捷开发，带来的好处又是什么?
笔者也只是一个入行没多久的新手，以下只是笔者自己对于敏捷开发的一些理解，并不全面，如有不同理解／或更深刻的理解可以回复进行互相学习。更深入的理解仍需要长时间实践的沉淀
1. 敏捷开发是什么?
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。
2. 怎么理解呢?
首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
3. 敏捷代表Scrum和Devops
其实现在大量推崇的敏捷开发主要以Scrum和Devops为主
Scrum扫盲篇 https://www.cnblogs.com/taven/archive/2010/10/17/1853386.html （感谢博主的分享）
Devops扫盲篇 https://www.cnblogs.com/jetzhang/p/6068773.html （感谢博主的分享）
3.1 两者在敏捷开发中分别起到什么作用呢?
个人的理解是:
Scrum是一种开发流程，该流程通过将需求从产生-评审-研发-测试-上线-反馈-产生新的需求闭环的形式，将一个产品分解为一个个互相影响的闭环，就是一个个迭代的版本。
Devops是一种交付理念，主张通过使用CI/CD工具链方式将一个迭代版本中的每个环节都通过工具自动连接，完成每个环节的交付工作，直至上线交付用户。
两者是一个相辅相成的关系，Scrum提供研发流程，Devops提供CI/CD工具链
3.2 对于Scrum理解
（图片来自网络）
个人对于Scrum的理解是：站在产品/项目的角度，怎么让需求得到更快/更好/更准确的实现。
对于产品人员，希望设计的产品功能等能够快速得到实现、上线、验证、更新。传统的瀑布式开发往往是一次性完成所有的需求，如果上线后发现无法满足市场再次进行新的调整，再次上线可能已经是半年后了，对于互联网产品简直是一个致命的伤害。对于产品特性的刨析分解，将特性重点提取出来，快速实现开发上线得到市场用户的验证，再不断丰富特性无疑是互联网产品占据市场的最好方法。
所以在Scrum中对产品人员的要求变得严苛，要求产品人员能够对产品特性进行丰富准确的刨析分解（对产品的定位、用户的画像、数据的分析、特性的分解、市场响应的应对、需求管理都是很大的考验）
对于研发人员，需求的理解偏差／需求变动／Bug修复应该一直都是一个头疼的问题。如果研发人员对于需求的理解存在偏差，也就只有等到测试阶段才能发现需求实现偏差，此时再次进行返工将导致整个产品的上线延期（如果是瀑布式模式，延期时间更长项目成本更高）。如果研发过程中出现需求的变动（因为产品／市场／政策等等因素造成），研发人员将需要重新理解需求，如果需求变更较大之前的编码将进行重新编写，对于整个产品的上线也是一种延期（如果需求变动为主要业务流，在瀑布式模式中可能导致整个项目停工重新设计）。如果测试人员无法快速准确的识别需求偏差／发现系统Bug，将会导致交付延期甚至带来交付隐患，随时带来不可预想的后果。
所以Scrum提倡快速的版本迭代而不是瀑布式模式，目的就是为了将项目成本损失最小化；
同时Scrum也很注重研发人员对于需求的理解，目的就是让研发人员对需求进行详细的理解，根据理解进行需求分解后让产品人员进行评审检查是否偏差遗漏；
并且需要测试人员全程参与产品／研发环节，通过对产品的详细了解／研发的实现逻辑快速分析定位是否满足要求／是否存在Bug，同时也提倡将传统的手工测试自动化，加快测试环节的效率减少工作成本。
3.3 团队融合Scrum
对于Scrum，它本身的研发流程并不一定适用于所有团队，因为每个团队的产品方向/人员配置/团队氛围都不尽相同。
个人认为对于Scrum的学习，不是对于Scrum流程的照搬，而是对于快速迭代交付的理解，然后根据自己团队的其他种种因素结合，输出适合自己团队的研发流程。
当然Scrum中有很多环节／方式是可以直接借鉴进来使用的，比如任务看板／每日站会／工作量评估／需求分解会等。任务看板可以帮助大家快速同步任务进度，方便进行下一步的工作准备；每日站会，可以让大家同步进度并且提出问题风险；工作量评估，可以让大家不断对自己的工作量化表现战斗力；回顾会议，探讨发言改进的地方共同进步。
个人认为团队对于Scrum的融合（１）根据团队现状因素等，拟定一套研发流程（２）对全员进行敏捷概念的普及（３）详细讲解流程各环节作用，试行一个版本迭代后召集全员进行回顾会讨论，集思广益对流程进行近一步优化（４）确定合适的研发流程进行强制推广执行，中间出现的问题于每个版本回顾会讨论记录（５）每版本或月或季，进行一次流程优化并继续推行
让团队去适应一个新的研发流程是一件很难的事情，了解敏捷思想后制定一个适合的研发流程难度不大，难点在于流程的执行监督需要消耗一定的时间／精力，因为敏捷开发的主要驱动核心是人。团队融合Scrum可能会增多一些环节／会议等，想要完成真正的融合一定要加大力度的监督执行，让大家养成习惯才是真正的融入新的研发流程
3.4 对于DevOps理解
（图片来自网络）
（图片来自网络）
个人对于DevOps的理解是：站在集成/交付的角度，怎么让研发流程各个环节无缝连接，同时推动工具链减少人员操作（当然DevOps是一种理念，理解起来肯定不仅如此，只是在落实方面CI/CD思想比较着重）
对于研发流程而言，一个好的研发流程就是一个完整的闭环，每个环节都有其存在的意义并且每个环节的完成都意味着工作交付（产品人员将需求交付给开发人员编码，开发人员将系统交付给测试人员测试，测试人员将系统交付给运维人员上线，运营人员将系统交付给客户使用，客户将使用意见交付产品人员分析）。完整闭环就需要产品／开发／测试／运维／客户等角色共同参与，闭环的形成、多种角色的参与都意味着每个环节、角色的交付都是一个重点。更好的交付将减少下游环节、角色的工作成本；更好的交付将提高研发流程的流畅度（对于研发流程的推进也有帮助）；更好的交付将提高产品的市场、乃至提高产品的收益。
笔者接触到的大多数DevOps的讲解，DevOps是将开发、测试、运维融合起来，但是笔者认为DevOps并不仅仅是这３者的融合，而是整个产品至上线所有环节／角色的融合
DevOps提倡使用工具链，将所有的交付／监控等等环节操作工具化，并通过工具之间的API互相关联形成一套完整的工具链体系。通过工具减少人员的操作，即减少了人员成本又极大的避免了人为操作失误带来的损失。
笔者之前看到过一个比较完整的DevOps工具链概览，分享给大家（同时也感谢作者的分享）https://blog.csdn.net/qq_31977125/article/details/82796739
顺便再分享一个 DevOps BookMarks ，涉及了DevOps方方面面的工具和内容，有兴趣的同学可以去学习下。http://www.devopsbookmarks.com/
（笔者也有简单分享过一些工具相应的介绍／安装／配置文章，后面笔者也会继续学习继续补充）
3.5 团队融合DevOps
对于DevOps，它是一个理念。个人认为对于DevOps的学习，首先是真正的理解集成／交付的思想，然后就是工具链的学习使用（硬核技术）。
团队对于Devops的融合是需要全员参与的，也是对团队整个技术栈的全面提升。首先是组织推广CI/CD的思想，让大家理解交付的意义；然后团队整体寻找适合团队的工具链，进行技术栈的全面提升。
4. 团队走向敏捷开发
个人认为团队想要真正的走向敏捷开发，需要对于Scrum和DevOps进行一个完整的融合。
通过DevOps闭环的思想、Scrum迭代的思想，结合Scrum可以借鉴的环节／方式，制定一套闭环、适合团队的研发流程。
通过JIRA等项目管理工具将研发流程工具化管理，再将研发环节交付工具化执行，然后打通项目管理工具、研发各环节交付工具形成一个完整的工具链。
最最重要的一点还是人，一个团队想要真正的走向敏捷开发，首先也是必须要让团队人员都认同迭代、闭环、集成、交付思想。只有思想上的认同，才会让整个团队共同努力向着敏捷开发的方向不断前进
