大厂做项目的策略常见的就是“分而治之”：大项目拆成小项目，大服务拆成小服务，大团队拆成小团队。

一.一切工作任务围绕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栏就知道哪些Ticketzhengzai进行中。

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

二.基于Git和CI的开发流程

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

早些年虽然也用源代码管理，但是大家都是在master（主干）上开发的，所以master的代码特别不稳定，一不小心就可能被人嵌入不稳定的代码。所以在上线前，有一段时间叫“代码冻结期”，意思就是这期间，除非紧急修复，否则谁都不能提交代码。

还有测试环境的部署也是老大难问题，尤其是服务一多，编译时要注意各种依赖，注意各种环境的配置。所以更新测试环境是一个大工程，以至于会有专人负责部署测试环境。

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

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

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

三.部署上线流程

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

1.首先，部署的不再是程序代码，而是Docker的images，每次代码合并后CI都会自动生成新的images，测试也是基于images测试。

2.部署生产环境之前，先在内部的测试环境充分测试。

3.部署生产环境之前，需要审批确认，有Ticket跟踪。

4.部署时，先要部署一部分，监测正常后再全量部署。

5.整个过程都有监控报警，出现问题及时回滚。

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

四.每日站立会议

站会其实形式不重要，重点是要高效沟通反馈。

开会时间在半小时内，半小时内不能完成的应该另外组织会议。

通常是有 Scrum Master（敏捷教练 、敏捷大师），也可以使用轮班制，每个星期换一名团队成员主持。负责主持会议的人，主要职责是组织会议，一个个的环节开展，控制好会议节奏。

开会的议题：

1.成员轮流发言。

每个人轮流介绍一下，昨天干了什么是事儿，今天计划做什么事情，工作上有没有阻碍无法推进。

其中无关的问题，要及时终止，吧问题放入问题停车场。让会议继续。

2.检查最新的Ticket

前面说到所有的工作都是基于Ticket来开展的，这些Ticket可能都是测试宝的BUG，也可能是产品经理提交的需求。

每天例会检查一下新的Ticket，并且要甄别一下优先级，然后再决定放到当前Sprint，还是放到Backlog（任务清单）。

3.停车场问题

在这个环节，大家可以针对之前来不及讨论的问题进行补充讨论，能在会议时间解决的问题，就马上解决，不能解决的会后再私下解决，或者再组织会议。

总结

我们知道，在敏捷开发中有很多概念，像 Backlog、持续交付、每日站会等，这些概念最终要变成实践的话，就必须要通过一定的流程规范来保障这些概念的实施。

这就是为什么很多公司写代码要求你写自动化测试代码，为什么要用一些项目管理软件来管理任务。为什么每天开站立会议，为什么有代码审查。这些不过是为了保障敏捷的实施。

如果你在实施敏捷开发的项目工作，就可以夺取观察平时工作中这些的敏捷有关的流程规范，再结合敏捷开发中的知识点，就能很好的帮助你敏捷开发，理解这些流程规范背后的的理论依据。

此内容极客时间版权所有，本人只是学习之后做一个笔记记录如有用做任何商业用途，极客时间可能追究法律责任，本人一概不负责，分享和转载请注明：https://time.geekbang.org/column/article/e1b490a8fa3aefde517255ee9b92a8be/share?code=mybUYSWKKskrdOz0DM6%2FKO%2F9RDfR5YCw65TVohaq%2FrE%3D&oss_token=30f500e2095984f0