07 | 大厂都在用哪些敏捷方法?

发布于 2021-11-25  681 次阅读


我今天分享的主题是:大厂都在用哪些敏捷方法?我将分为上下两篇,来与你一起讨论这个话题。在我还是一个野路子程序员,到处接私活做网站时,就开始好奇:大厂都是怎么开发软件项目的?直到毕业后,我前前后后加入了若干大中小型企业,包括这些年在美国高校、公司的一些经历,对大厂的项目开发有了比较多的了解。

其实大厂做项目也没有什么特别的,无非就是工程中常见的“分而治之”的策略:大项目拆成小项目,大服务拆成小服务,大团队拆成小团队。

服务之间通过商定好的标准协议进行通信,架构上将大的服务拆分隔离成微服务,大团队按照业务或者服务拆分成小组,按照一定的流程规范保障协作。最终,各个小组要负责的内容其实就不多了。

就像淘宝这种网站,不需要一个庞大的项目组,通过逐级分拆,一个小组可能就只需要负责一个页面中的一个小模块。

所以,也要归功于现在微服务、容器等新技术,可以将复杂的业务逐级拆分,让很多公司能真正敏捷起来。

 

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

一切工作任务围绕 Ticket 开展

早些年的项目开发,都是围绕着项目计划开展的,把甘特图打印贴在墙上,方便团队成员看项目进展到什么地步了。自从敏捷化后,开始变成了看板。

所谓的看板,就是把白板分成几个栏,每一栏为一类,分别写着“To Do(待选取)”、“In Progress(进行中)”、“Done(完成)”等,再把工作任务变成一个个五颜六色的即时贴,根据状态贴在不同的栏下面。

慢慢的物理的看板变成了电子看板,通过各种项目管理软件来管理跟踪这些任务,即时贴也变成了 Ticket(也有叫 Issue 的)。逐渐的,所有与开发相关的任务也都和 Ticket 挂钩了:

  • 报一个 Bug,提交一个 Ticket ;
  • 提一条需求,提交一个 Ticket ;
  • 要重构一下代码,提交一个 Ticket 。

看板这种基于 Ticket 来管理跟踪任务的方式,看起来繁琐,但确实是很高效的一种方式。

  • 每一个任务的状态都可以被跟踪起来:什么时候开始做的,谁在做,做完没有。
  • 整个团队在做什么一目了然。
  • Ticket 和敏捷开发中的 Backlog(任务清单)正好结合起来,通过 Ticket 可以收集管理整个项目的 Backlog 和当前 Sprint(迭代)的 Backlog。

有了看板后,大家每天上班第一件事就是打开看板,看看当前 Sprint 还有哪些 Ticket 没有完成,哪些已经完成,哪些正在进行中,非常直观。

作为项目成员来说,做完手头的事情也不用去问项目经理该干什么事情了,直接从 To Do 栏选一条 Ticket 做就是了;对于项目经理,看看 To Do 栏还有多少没有被选取,就知道还剩多少 Ticket 没完成,看看 In Progress 栏就知道哪些 Ticket 正在进行中。

如果有 Ticket 在这一栏待太久或者这一栏 Ticket 太多,那可能就有风险了,就可以及时介入。

 

基于 Git 和 CI 的开发流程

如果你的团队应用瀑布模型来开发,大概会有两大烦恼:代码不稳定和部署太麻烦。

好在基于 Git 的开发流程结合 CI 的自动测试部署,很完美的解决了这两大问题。

我们假设现在 master 的代码是稳定的,那么怎么保证新加入的代码也稳定呢?

答案就是代码审查(Code Review)和自动化测试。如果代码有严格的审查,并且所有自动化测试代码都能测试通过,那么可以认为代码质量是可靠的。当然前提是自动化测试代码要有一定的覆盖比率。

Git 本来只是源代码管理工具,但是其强大的分支管理和灵活的权限控制,结合一定的开发流程,却可以帮助你很好的控制代码质量。

接下来还剩下自动化测试的问题。这时候该 CI (持续集成)出场了。如果你不了解 CI 是什么,可以把它想象成一个机器人,每次你提交一个 PR(严格来说是 Commit,这里略作简化)到源代码服务器,这个机器人马上就知道了。然后它创建一个干净的运行环境,把你提交的代码下载下来,再下载安装所有依赖项,然后运行你的所有测试代码,运行完后,把测试结果报告给你。测试结果直观的反馈在 PR 上,绿色表示通过,红色表示不通过。

关于 Git 和 CI,我在之后的文章中会展开讲解,这里只是为了展现敏捷开发方法的流程。另外,阮一峰老师写过两篇文章,《Git 工作流程》《持续集成是什么?》,你也可以先行阅读了解。

http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html

http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

至此,代码审查和自动测试的问题都解决了。当一个 PR 代码审查通过,以及 CI 通过了所有自动化测试,就可以合并到 master 了,而且我们也可以认为合并到 master 后的代码也是稳定的。(PR---合并分支,CI---持续集成)

至于自动部署测试环境,反倒是简单,就是 CI 这个机器人,在你代码合并到 master 的时候,再次运行自动化测试代码,测试通过后直接运行自动部署的脚本,把 master 代码部署到开发环境或测试环境上。

在这里以一个开发任务为例,大致讲解一下应用敏捷开发方法的基本开发流程:

  • 把要开发的 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”栏。

正常来讲,你是需要严格遵守开发流程的,但偶尔肯定也有紧急任务,来不及写测试代码,这种情况下,一定要再创建一条 Ticket 跟踪,以确保后续完成测试代码

 

部署上线流程

最早的时候,程序员都是自己管服务器,但是由于这样过于随意,就会导致很多问题出现。

于是后来有专门的运维团队,将开发好的程序,编译好,数据生成脚本写好,然后写成部署文档,交给运维去手动部署。这个过程无比繁琐、无比慎重,通常几周才部署一次,遇上打补丁才隔几天部署。

这些年随着容器化、微服务、DevOps 这些技术或概念的兴起,部署已经变得越来越高效,大厂已经开始在部署流程上融合这些理念。

以前是运维人员按照文档部署,现在已经变成了 DevOps 写自动化部署工具,然后开发人员自己去部署生产环境。

现在大厂的部署也都实现了自动化,但是流程上还是有一些控制。

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

如果一切顺利的话,整个生产环境的服务部署过程通常几分钟就完成了,这在以前简直是不敢想象的事。

 

每日站立会议

是不是站着开会其实不重要,重点是要高效沟通反馈。开会时间控制在半小时以内,半小时内不能完成的应该另外组织会议。

1. 成员轮流发言

2.检查最新的 Ticket

3.停车场问题(在这个环节,大家可以针对之前来不及讨论的问题进行讨论,能在会议时间内解决的问题,就马上解决,不能解决的会后再私下讨论或者再组织会议。)

 

总结

分治策略是应对庞大复杂系统的惯用思路,但它的难点或精髓在于如何确保形散神聚。

详细计划(甘特图)VS任务状态(Ticket)

代码不稳定&环境部署麻烦
VS
代码审查&自动测试&自动部署(GIT、CI、DevOps)

上传下达VS频繁沟通、提醒、分享

大厂的敏捷开发实践,把枯燥的编码变得跟玩游戏一样。借助有效的流程与工具,能够有效节约团队成员的精力,聚焦于任务或角色,不会因频繁“统一思想”导致“技术动作变形”。而另一面,在大厂里每个人通常都是螺丝钉,长此以往也许会养成不谋全局的习惯。如果能从自己的角色中跳出来,俯瞰整个组织协作的全过程,并站在这个视角上思考问题,一定会有更喜人的收获。


她喜欢所以就做咯