软件工程之美学习笔记七 06 | 大厂都在用哪些敏捷方法？（上）

《软件工作之美》材料地址：https://time.geekbang.org/column/article/84652

一 总体策略

大项目拆成小项目，大服务拆成小服务，大团队拆成小团队。

1. 要归功于现在微服务、容器等新技术，可以将复杂的业务逐级拆分，让很多公
   司能真正敏捷起来。
2. 团队要实施敏捷，不仅要小，还要组织扁平化。

二 和敏捷开发相关的主要流程规范

1. 一切工作任务围绕 Ticket 开展

参考文章 阮一峰老师写过两篇文章，
《Git 工作流程》http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
《持续集成是什么》http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html

步骤

• 把要开发的 Ticket 从“To Do”栏移动到“In Progress”栏；

• 从主干（master）创建一个分支（branch），基于分支去开发功能或修复 Bug；

• 编写实现代码和测试代码（单元测试和集成测试），是不是测试驱动不重要，看个人偏好或团队要求；

• 持续提交代码更新到分支，直到完成；

• 创建 PR（Pull Request，合并请求），邀请其他人帮忙 Review 代码，根据 Review 的结果，可能还需要更新几次；

• CI在每一次提交代码到代码库后都会自动运行，运行后主要做这些工作：
  – 检查代码格式是不是符合规范；
  – 运行单元测试代码；
  – 运行集成测试。

• 最终这些检查都完成后，CI 会把执行结果显示在 PR 上。通常绿色表示通过，红色表示失败；

• PR能合并需要满足两个条件：CI 变绿 + 代码 Review 通过；

• PR 合并后，CI 会自动构建 Docker Image，将Image部署到开发环境；

• 将相应的 Ticket 从看板上的“In Progress”栏移动到“Done”栏。

3. 部署上线流程

• 首先，部署的不再是程序代码，而是 Docker 的 image，每次代码合并后 CI 都会自动生成新的 Image，测试也是基于Image 测试。
• 部署生产环境之前，先在内部的测试环境充分测试。
• 部署生产环境前，需要审批确认，有 Ticket 跟踪。
• 部署时，先部署一部分，监测正常后再全量部署。
• 整个过程都有监控报警，出现问题及时回滚。

4. 每日站立会议

讨论内容如下：

1. 成员轮流发言
   每个人轮流介绍一下，昨天干了什么事情，今天计划做什么事情，工作上有没有障碍无法推进。
   问题停车场（Parking lot question），把需要进一步讨论的问题临时放到这里，一会儿再讨论。
2. 检查最新的 Ticket
   决定是放到当前 Sprint，还是放到 Product Backlog
3. 停车场问题

三 我的留言

如何保证每个迭代的交付质量

在一个以Scrum 为方法的敏捷团队里，
首先， Scrum master是呵护develop team的保护神，他的其中一个职责是保护每一次迭代的工作量是dev team能按时完成的，而且保护dev team 能专注于现有sprint back log的实现，不会被其他干系人的新需求所打断。
其次, Dev team是一个T型团队，技术比较全面，许多事情多能自助搞定，比如，开发人员同时又有测试技能，同时如果结合结对开发，测试驱动开发，那么，交付物的质量就更有保障。
再者， 在一个敏捷团队里，人数比较少，dev team的沟通能力都比较强，沟通可以比较充分，所以解决问题的能力就比较强，工作效率比较高
最后， 敏捷模式的开展，也依赖于工具的使用，目前常用的CICD工具，与jira/confluence 需求沟通管理工具的打通，部署次数的提高，无疑大大提高了开发发布效率，同时也提高了发布质量。
综上所述， 只要在人员组织架构、工具产品、流程这三个方面都达到了敏捷的要求，那么交付质量就有了保证。

老师回复: 对敏捷了解已经很熟悉很深入了/p>

你还可以继续考虑考虑还有没有其他手段可以加强质量的其是可以从瀑布模型那边学习借鉴一些。

来源：alpha xu