敏捷开发管理

目录

3. 敏捷原则 4. 瀑布式开发与敏捷开发的异同 5. 敏捷方法 5.2 我司实施的敏捷过程 6.2.2 缺陷管理 6.3 统一管理工具 6.4 角色 6.5 过程 6.6 敏捷开发最终定义 6.7 目的 6.8 B站培训视频

一、背景

在现代软件开发中，一个软件项目在建设初期被分成多个子项目，每个子项目的成果都经过测试，使其可视化、可集成、可操作。 换句话说，就是将一个大项目拆分成多个相互关联又可以独立运行的小项目，分别完成，软件在这个过程中始终处于可用状态。 敏捷开发管理的概念应运而生。 2.敏捷开发管理的起源

2001年，一群高手齐聚美国犹他州，吃喝玩乐，集思广益，得出敏捷宣言，阐述了五个价值观，如下图。

2.1 文档能存则存

描述类属性文件、接口描述文件（使用自动生成）。 但一些有价值的文件，如设计方案文件、架构体系文件等，还是很有必要的。 2.2 敏捷的初衷

敏捷的本意是建议我们采用一系列的方法，让我们的研发工作更加高效、灵活和有序，所以强调团队成员的主动性和协作性，也更注重对变化的响应。 3. 敏捷原则 我们的首要任务是通过尽早和持续交付有价值的软件来满足客户。 即使在开发后期，也欢迎不断变化的需求。 敏捷流程使用变化为客户创造竞争优势。 定期交付工作软件，从几周到几个月不等，交付间隔越短越好。 在整个项目开发期间，业务人员和开发人员必须每天一起工作。 围绕有动力的个人构建项目。 为他们提供所需的环境和支持开发管理工具，并相信他们能够完成工作。 在团队内部，最有效、最快捷的信息传递方式是面对面的交谈。 工作软件是主要的进度指标。 敏捷过程促进可持续的发展步伐。 所有者、开发商和用户应该能够保持长期、恒定的发展步伐。 持续关注良好的技能和良好的设计可以提高敏捷性。 简单——最大化未完成工作的艺术——是根本。 最好的架构、需求和设计来自自组织团队。 每隔一段时间，团队就会反思如何才能更有效地工作，并相应地调整其行为。

随着时代的变化，有些内容会发生变化。 比如第4点社会分工越来越细。 需求是在销售前通过工具跟客户更新平台（我们公司用的平台，腾讯的TPAD也是一个很好的平台工具）。

第5点还不是很明白。

第6点也是通过平台实现的。 我公司主要与武汉和杭州的开发人员和测试人员进行交流。 因为互联网让我们可以远程互动，感谢有你的美好时光。

其他要点要牢记在心，不断练习。 4.瀑布式开发与敏捷开发的异同点

敏捷开发，细分需求，关注每个需求的生命周期管理。 随时提出要求，随时撤回，随时更改。 每个需求都有分析、设计编码、测试和缺陷管理。 产品经理可以在线审核（合并：CI/DI），随时打开新需求和结束需求。 瀑布式开发只有在功能开发完成后才能进行，比如少量的迭代。 5. 敏捷方法

任何符合敏捷价值观和原则的方法论都可以称为敏捷方法。 5.1

我公司采用该方法。 前后端开发人员不断迭代代码，通过CI/DI持续集成部署，测试人员不断测试反馈。 通过对需求和缺陷的全周期管理，实现需求变更和开发及缺陷的快速完成。 修复等 5.1.1 后台CI/DI工作流水线

5.1.2 前端 CI/DI 工作流管道

综上所述，通过CI/DI持续集成可以提高敏捷开发的效率。 可以说CI/DI是法家的艺术，敏捷思维是法家的法则（规则，思想抽象或道家）。 5.2 敏捷

Scrum并不是敏捷的全部，它只是敏捷的一种落地方式。

Scrum 是 3355。

什么是3355？

前3代表3个角色，分别是Owner（产品负责人）、Scrum和team；

第二个3代表3个工件开发管理工具，分别是（ ）、（ ）和（ ）；

第三个5代表5个事件，大家感受最深的，分别是（迭代计划会议）、Daily Scrum（每日站立会议）、（迭代回顾会议）、（迭代回顾会议）、（产品梳理会议） ;

第四个5代表5种价值观，即承诺、专注、开放、尊重和勇气；

我们公司不遵循这种方法。 6 我司实施的敏捷过程 6.1 特点：迭代开发

每次迭代必须依次完成以下五个步骤。

需求分析( )

设计（）

编码（）

测试（）

部署与评估（/） 6.2 任务管理 6.2.1 需求管理

PO（Owner）：产品的负责人，核心是产品，请求者可以是产品经理、项目经理、测试人员（适用于我公司）、终端用户、集成商、代理；

现代需求：需求变化更快。 早上养，下午换。 敏捷就是更方便的改变需求。 我们公司非常适合敏捷开发。

需求管理：关键是写下来，写到统一的产品平台上。 在写作的过程中，对问题的考虑会全面、有迹可循。 需求文档和开发的代码一样，必须要有完整的历史记录，可以追溯到什么时候、谁做了什么改动，做到每一次需求改动都有迹可循。 6.2.1.1 特定需求管理

什么是全周期？ 即需要所有状态的流和停流。

添加状态定义

6.2.2 缺陷管理

缺陷是缺陷，是测试人员在通过测试用例后产生的，并分配给之前完成任务的相应开发人员。 开发人员忙于手头工作，将实际情况反馈给组长，软件组长再分配给其他开发人员。 6.3 统一管理工具

我公司采用平台

由测试人员设置。 并且所有的通知信息都可以通过手机App进行通知。

6.4 角色 6.5 流程 6.6 敏捷开发最终定义

敏捷开发以用户需求的演进为核心，采用迭代、循序渐进的方法进行软件开发。 6.7 目的

管理好需求，提升开发效率6.8 B站培训视频

我的B站训练录制视频

版权声明：本文为博主原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 本文链接：////p/.html