目录
敏捷式开发管理
1.背景
2.敏捷开发管理的由来
2.1 文档能省则省
2.2 敏捷的初心
3.敏捷的原则
4.瀑布式开发与敏捷式开发异同
5.敏捷的方法
5.1 DevOps
5.1.1 后台webApi的CI/DI工作流水线
5.1.2 前端CI/DI的工作流水线
5.2 Scrum
6 我司执行的敏捷流程
6.1 特点：迭代式开发
6.2 任务管理
6.2.1 需求管理6.2.1.1 一次具体的需求管理
6.2.2 缺陷管理
6.3 统一的管理工具
6.4 角色
6.5 流程
6.6 敏捷开发最终定义
6.7 目的
6.8 B站培训视频
在现代软件开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷式开发管理概念应运而生。
2001年，一群大师聚集在美国犹他州，吃吃喝喝头脑风暴，搞出了一个敏捷宣言，阐述了5条价值观，如下图所示。
描述类属性文档、接口说明文档（利用swagger自动生成）。而一些有价值的文档，如设计方案文档、架构体系文档等仍然是必须的。
敏捷的初心是建议我们通过一系列方法来让我们的研发工作更加高效、灵活和有序，所以它强调团队成员的能动性和相互之间的协作，也更重视应对变化。
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
不断地关注优秀的技能和好的设计会增强敏捷能力。
简单——使未完成的工作最大化的艺术——是根本的。
最好的构架、需求和设计出自于自组织的团队。
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
随着时代的变迁，里面的内容有些会变了，如第4点社会分工越来越细，提需求的是跟客户一起的售前通过工具更新到teambition平台（我司采用TeamBition平台，腾讯的TPAD也是一个很优秀的平台工具）。
第5点还不是很理解。
第6点也是通过teambition平台实现。我司主要在武汉与杭州两地开发人员与测试人员进行沟通交流。因为互联网令我们能远程互动，感谢这最好的时代。
其他几点应牢记于心不断实践。
敏捷式开发，细分需求，侧重每个需求的生命周期管理。随时提需求，随时撤销，随时变更，每个需求都有，分析，设计编码，测试，缺陷管理。产品经理，可以在线评审(结合DevOps:CI/DI)，随时开启新需求，结束需求。瀑布式开发只能等功能完全开发结束进行评审，例如迭代次数较少。
只要是符合敏捷价值观和原则的方法论，都可以称之为敏捷方法。
我司采用DevOps方法，前后端的开发人员通过不断的迭代代码，通过gitlab的CI/DI持续集成部署，测试人员持续测试反馈，通过teambiton对需求与缺陷的全周期管理实现了快速完成需求变更与开发以及缺陷的修复等。
综上，通过DevOps CI/DI来持续集成,来提高敏捷开发的效率。可以说DevOps CI/DI是法家里说的术，而敏捷思想是法家的法（规则，思想的抽象或者说是道家的道）。
Scrum不是敏捷的全部，它只是敏捷的一个落地方法之一。
Scrum就是3355。
什么是3355？
第一个3代表3个角色，即Product Owner（产品负责人）、Scrum Master 和 团队；
第二个3代表3个工件，即Product Backlog（产品待办事项列表）、Sprint Backlog（迭代待办事项列表）和 Product Increment（产品增量）；
第三个5代表5个事件，这也是大家感受最深刻的，即Sprint Planning（迭代计划会议）、Daily Scrum（每日站立会议）、Sprint Review（迭代评审会议）、Sprint Retrospective（迭代回顾会议）、Backlog Refinement（产品Backlog梳理会议）；
第四个5代表5个价值，即承诺、专注、开放、尊重和勇气；
我司并不按照此方法执行。
每次迭代都必须依次完成以下五个步骤。
需求分析（requirements analysis）
设计（design）
编码（coding）
测试（testing）
部署和评估（deployment / evaluation）
PO(Product Owner): 产品负责人，核心是产品，提需求者可以是产品经理，项目经理，测试人员(适用我司)，最终用户，集成商，代理商；
现代化需求：需求变更快，早上提了，下午就改，敏捷是为了更方便地变更需求，我司非常适用敏捷式开发。
需求管理：关键是要写下来，写到统一的品台teambition里去。写的过程，考虑问题会全面，能溯源。需求文档和开发的代码一样，都要有完整的历史记录，能够追溯到何时什么人做了什么修改，这样可以追责到每一次需求变更。
什么时候开始？
什么时候结束？
负责人是谁？
完成之后交付给谁？@
需求生命周期，全周期覆盖，需求的状态管理
何为全周期？即需求全部状态的流转以及停止流转。
状态的定义添加
缺陷即bug, 由测试人员经过测试案例之后，建立，指派给之前完成任务的对应开发人员，开发人员手头工作繁忙，向组长反馈实际情况，再由软件组长指派给其他开发人员。
指派流程很重要@
测试人员很关键
反馈很重要
软件组长需要统筹规划
根据优先级安排任务
一次缺陷的修复成为迭代
我司采用TeamBition平台
全周期
需求，开发，测试，缺陷修复，迭代全覆盖
高效
任务燃尽图，项目状态，成员分工职责一目了然，减少沟通成本
积累
相关文档随项目归档，不易丢失，适合新同事切入
任务看板
使公司领导层，产品，团队对整个任务状态及其周期全部可视化
DevOps
结合CI/DI，产品经理，项目经理随时能看网页，随时能修改需求，提高迭代次数，减少沟通成本。给出访问url
代码
给出gitlab url
由测试人员设置完成。并且所有通知信息可由teambition手机App通知。
– 产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，同时有权力接受或拒绝开发团队的工作成果。
– 流程管理员（Scrum Master）
使得每一时刻的需求都能明确，管理每一次需求变动，变动原因，将变动落实到实处。
–开发团队（Scrum Team）
根据任务优先级编排任务
–测试人员
需求明确完之后，即可针对需求编写验收文档。测试过程，编写测试案例。
产品需求列表，由PO负责的；
召开评审会议，去除不必要需求，确定需要开发的需求；
简单需求分发任务，复杂需求画原型图；
分配任务；
测试
交付能产生80%效益的20%功能；
持续迭代（迭代式开发），持续交付（增量交付）；
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
管理好需求，提高开发效率
本人B站培训录制视频
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接：https://www.cnblogs.com/JerryMouseLi/p/14203881.html
The Sky is the limit.