敏捷式开发管理——基于Teambiton平台落地

敏捷式开发管理

目录

• 敏捷式开发管理
  • 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站培训视频

1.背景

在现代软件开发中，软件项目在构建初期被切分红多个子项目，各个子项目的成果都通过测试，具有可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程当中软件一直处于可以使用状态。敏捷式开发管理概念应运而生。

2.敏捷开发管理的由来

2001年，一群大师汇集在美国犹他州，吃吃喝喝头脑风暴，搞出了一个敏捷宣言，阐述了5条价值观，以下图所示。

2.1 文档能省则省

描述类属性文档、接口说明文档（利用swagger自动生成）。而一些有价值的文档，如设计方案文档、架构体系文档等仍然是必须的。

2.2 敏捷的初心

敏捷的初心是建议咱们经过一系列方法来让咱们的研发工做更加高效、灵活和有序，因此它强调团队成员的能动性和相互之间的协做，也更重视应对变化。

3.敏捷的原则

1. 咱们最优先要作的是经过尽早的、持续的交付有价值的软件来使客户满意。
2. 即便到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优点。
3. 常常性地交付能够工做的软件，交付的间隔能够从几个星期到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须每天都在一块儿工做。
5. 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，而且信任他们可以完成工做。
6. 在团队内部，最具备效果而且富有效率的传递信息的方法，就是面对面的交谈。
7. 工做的软件是首要的进度度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该可以保持一个长期的、恒定的开发速度。
9. 不断地关注优秀的技能和好的设计会加强敏捷能力。
10. 简单——使未完成的工做最大化的艺术——是根本的。
11. 最好的构架、需求和设计出自于自组织的团队。
12. 每隔必定时间，团队会在如何才能更有效地工做方面进行检讨，而后相应地对本身的行为进行调整。
    随着时代的变迁，里面的内容有些会变了，如第4点社会分工愈来愈细，提需求的是跟客户一块儿的售前经过工具更新到teambition平台（我司采用TeamBition平台，腾讯的TPAD也是一个很优秀的平台工具）。
    第5点还不是很理解。
    第6点也是经过teambition平台实现。我司主要在武汉与杭州两地开发人员与测试人员进行沟通交流。由于互联网令咱们能远程互动，感谢这最好的时代。
    其余几点应牢记于心不断实践。

4.瀑布式开发与敏捷式开发异同

敏捷式开发，细分需求，侧重每一个需求的生命周期管理。随时提需求，随时撤销，随时变动，每一个需求都有，分析，设计编码，测试，缺陷管理。产品经理，能够在线评审(结合DevOps:CI/DI)，随时开启新需求，结束需求。瀑布式开发只能等功能彻底开发结束进行评审，例如迭代次数较少。

5.敏捷的方法

只要是符合敏捷价值观和原则的方法论，均可以称之为敏捷方法。

5.1 DevOps

我司采用DevOps方法，先后端的开发人员经过不断的迭代代码，经过gitlab的CI/DI持续集成部署，测试人员持续测试反馈，经过teambiton对需求与缺陷的全周期管理实现了快速完成需求变动与开发以及缺陷的修复等。

5.1.1 后台webApi的CI/DI工做流水线

5.1.2 前端CI/DI的工做流水线

综上，经过DevOps CI/DI来持续集成,来提升敏捷开发的效率。能够说DevOps CI/DI是法家里说的术，而敏捷思想是法家的法（规则，思想的抽象或者说是道家的道）。

5.2 Scrum

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个价值，即承诺、专一、开放、尊重和勇气；

我司并不按照此方法执行。

6 我司执行的敏捷流程

6.1 特色：迭代式开发

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

需求分析（requirements analysis）
设计（design）
编码（coding）
测试（testing）
部署和评估（deployment / evaluation）

6.2 任务管理

6.2.1 需求管理

PO(Product Owner): 产品负责人，核心是产品，提需求者能够是产品经理，项目经理，测试人员(适用我司)，最终用户，集成商，代理商；

现代化需求：需求变动快，早上提了，下午就改，敏捷是为了更方便地变动需求，我司很是适用敏捷式开发。

需求管理：关键是要写下来，写到统一的品台teambition里去。写的过程，考虑问题会全面，能溯源。需求文档和开发的代码同样，都要有完整的历史记录，可以追溯到什么时候什么人作了什么修改，这样能够追责到每一次需求变动。

6.2.1.1 一次具体的需求管理

• 何时开始？
• 何时结束？
• 负责人是谁？
• 完成以后交付给谁？@
• 需求生命周期，全周期覆盖，需求的状态管理
  

何为全周期？即需求所有状态的流转以及中止流转。

状态的定义添加

6.2.2 缺陷管理

缺陷即bug, 由测试人员通过测试案例以后，创建，指派给以前完成任务的对应开发人员，开发人员手头工做繁忙，向组长反馈实际状况，再由软件组长指派给其余开发人员。

• 指派流程很重要@
• 测试人员很关键
• 反馈很重要
• 软件组长须要统筹规划
• 根据优先级安排任务
• 一次缺陷的修复成为迭代

6.3 统一的管理工具

我司采用TeamBition平台

• 全周期
  需求，开发，测试，缺陷修复，迭代全覆盖
• 高效
  任务燃尽图，项目状态，成员分工职责一目了然，减小沟通成本
• 积累
  相关文档随项目归档，不易丢失，适合新同事切入
• 任务看板
  使公司领导层，产品，团队对整个任务状态及其周期所有可视化
• DevOps
  结合CI/DI，产品经理，项目经理随时能看网页，随时能修改需求，提升迭代次数，减小沟通成本。给出访问url
• 代码
  给出gitlab url

由测试人员设置完成。而且全部通知信息可由teambition手机App通知。

6.4 角色

• – 产品负责人（Product Owner）
  主要负责肯定产品的功能和达到要求的标准，同时有权力接受或拒绝开发团队的工做成果。

• – 流程管理员（Scrum Master）
  使得每一时刻的需求都能明确，管理每一次需求变更，变更缘由，将变更落实到实处。

• –开发团队（Scrum Team）
  根据任务优先级编排任务

• –测试人员
  需求明确完以后，便可针对需求编写验收文档。测试过程，编写测试案例。

6.5 流程

• 产品需求列表，由PO负责的；
• 召开评审会议，去除没必要要需求，肯定须要开发的需求；
• 简单需求分发任务，复杂需求画原型图；
• 分配任务；
• 测试
• 交付能产生80%效益的20%功能；
• 持续迭代（迭代式开发），持续交付（增量交付）；

6.6 敏捷开发最终定义

敏捷开发以用户的需求进化为核心，采用迭代、按部就班的方法进行软件开发。

6.7 目的

管理好需求，提升开发效率

6.8 B站培训视频

本人B站培训录制视频

---

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处连接和本声明。 本文连接：https://www.cnblogs.com/JerryMouseLi/p/14203881.html