07. 大厂都在用哪些敏捷方法?(下)

一个应用敏捷开发的小组的日常

小组是做开发网站的,基于微服务负责网站的某些小模块。标准配置7人,4个程序员(至少有一个资深程序员,有架构能力),一个产品经理    ,一个测试,一个项目经理。主要负责网站的某些模块的日常维护。

在分工上:

1.产品经理:写需求文档,将需求整理成Ticket,随时和项目成员沟通确认需求;

2.开发人员:每天从看板上按照优先级从高到低领取Ticker,完成开发任务;

3.测试人员:测试已经部署到测试环境的程序,如果发现Bug,提交Ticker;

4.项目经理:保障日常工作流程正常的执行,让团队成员可以专注工作,提供必要的帮助,解决问题。

在敏捷开发框架下,已经形成了一些很好的敏捷实践,这个小组也是基于 Scrum 方法做过程管理,基于极限编程做工程实践,看板可视化。每周一个 Sprint。

●如何完成需求和Bug修复?

这个小组的日常工作,也是围绕 Ticket 来开展的。所有的需求、Bug、任务都作为 Ticket 提交到项目的 Backlog,每个 Sprint 的任务都以看板的形式展现出来。每个人手头事情忙完后,就可以去看板上的“To Do”栏,按照优先级从高到低选取新的 Ticket。选取后移动到“In Progress”栏。

●每周一部署生产环境

没有人愿意星期五部署,那意味着如果部署后发现故障,可能周末都没法好好休息了。所以即使程序早已经测试好了,除非特别紧急,否则都会留在下一周再部署。所以部署放在上半周,这样后面遇到问题还有足够的时间去应对。

部署很简单,按照流程执行几个命令就可以完成生产环境部署。部署完成后,需要对线上监控的图表进行观察,如果有问题需要及时甄别,必要的话对部署进行回滚操作。但轻易不会打补丁马上重新上线,因为仓促之间的修复可能会导致更大的问题。

像敏捷开发这样一周一个 Sprint 的好处之一就是,即使这一周的部署回滚了,下周再一起部署也不会有太大影响。

●每周二开迭代回顾会议,总结上个 Sprint

每周二的早上,这个小组一般还会预留一个小时的时间,因为常规的站会完成后,还有一个迭代回顾会议 (Sprint Retrospective) ,目的是回顾一下在迭代中,团队有哪些做的好的地方,有哪些做的不好的地方。

对于需要后续改进的,需要创建相应的 Ticket,加入到 Backlog 中,在后续迭代中改进完善。

例如会议上,测试人员反馈说,上一个 Sprint,开发人员上线前几个小时还往预部署的分支里面更新代码,导致测试需要重新做回归测试,但因为时间不够了,没来得及测试完整,导致上线后不稳定,建议以后不要随意在上线前,在部署分支更新代码。

对于这样的问题,可能不止一次发生,说明流程上还是存在问题。所以最后大家商定,以后如果不是紧急的修复,就不要在预部署的分支上更新,确实要加,需要和测试先确认。

如果会议中要形成涉及项目的决策,最好是通过集体表决的方式决策,尽可能避免独裁式决策。因为敏捷的原则之一是要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务

●每周四迭代规划会,计划下周工作

每周四早上,也需要一个小时来组织会议。因为常规站会完成后,还有一个迭代规划会(Sprint Planning Meeting)。这个会议是要大家一起讨论下一个 Sprint 的内容。

在开会之前,产品经理和项目经理会商量好 Ticket 的优先级,会议上,大家一起按优先级高到低从 Backlog 中选出下个 Sprint 的内容。

  团队每个成员都要对候选的下个 Sprint Backlog 中的 Ticket 从 1-5 分进行打分,1 分表示容易 1 天以内可以完成的工作量,2 分表示 2 天内可以完成的工作,5 分表示非常复杂,需要 5 天以上的工作量。这里需要注意,打分时,要大家一起亮分,而不是挨个表态,不然结果很容易被前面亮分的人影响。

评估每条 Ticket 工作量的大概流程如下:

1.会议组织者阅读一条 Ticket,可能是用户故事,可能是 Bug,可能是优化任务。同时会询问大家对内容有没有疑问。

2.大家一起讨论这个 Ticket,确保充分理解这个 Ticket。

3.每个团队成员在心中对 Ticket 进行工作量估算。

4.会议组织者确认大家是否都已经确定估算结果,确认后,开始倒数:“3,2,1”,大家一起伸出一只手,亮出代表分数的手指头。

5.如果估算结果存在分歧,出分最高的和最低的各自说明理由,讨论后达成一致。这种估算工作量的方法有个名字叫估算扑克,因为亮分时用扑克牌亮分而得名,但并非一定要用扑克牌。

这种估算工作量的方法有个名字叫估算扑克,因为亮分时用扑克牌亮分而得名,但并非一定要用扑克牌。

用这种方式评估工作量有几点很明显的好处:

1.大家积极参与,详细了解需求。相比以前,可能只有当某个功能模块分配到自己头上的时候,才会去详细了解那部分需求,而其他开发人员可能都不了解这部分需求。

2.工作量是由实际参与开发的成员作出评估,往往更准确也更容易被接受。以前项目经理代为估算的模式,很容易不准确,或者让开发人员抵触。

3.促进成员的交流和经验分享。我们知道一般经验浅的新手估算工作量都会偏乐观,而经验丰富的老手则会更准确,通过这种方式,新手可以向老手学习到很多工作量估算甚至技术实现的经验。

所以,在经过几个 Sprint 的磨合后,一般一个团队在每个 Sprint 的产出是比较稳定的。比如说这样一个 7 人的小团队,一个 Sprint 预计可以完成 20-30 分的 Ticket。

  • 每周五分支切割

周五标志着一周的工作要结束了,所以下班之前(4 点左右),要做 branch cut(分支切割),也就是要把当前主干上的代码,克隆到一个分支(branch)上。

为什么要做分支切割这一步操作呢?

经过一周的开发,master (主干)已经合并了不少新的 PR(Pull Request,合并请求),但是如果你直接把 master 的代码部署到生产环境,肯定还是不放心,毕竟自动化测试还是不能完全代替专业测试人员的测试。

我们需要把 master 上的代码部署到测试环境进行测试,并且对测试出来的 Bug 进行修复,直到稳定下来为止。由于 master 还需要一直合并新的功能,所以最好的方式就是每次 Sprint 结束,从 master 创建一个分支版本出来,然后基于这个分支部署和修复 Bug。

所以需要基于主干做一个 branch cut,创建一个预部署的分支,将预部署分支的代码部署到测试环境,这样下周测试人员就可以测试新的版本。测试验收通过后,预部署分支的代码会部署到生产环境。


07. 大厂都在用哪些敏捷方法?(下)_第1张图片

  • 每周轮值
小组里面除了日常开发工作以外,其实还有不少琐碎的事情,比如每周部署生产环境,每天部署测试环境,每周的 branch cut(分支切割),回答其他小组的问题,主持每日会议(不一定需要项目经理),这些事情如果都是一个人做难免会有些枯燥。

在敏捷开发中,鼓励发挥每个成员的主动性,所以每周轮值是一个不错的方式,可以让每个人都有机会去体验一下,帮助团队完成这些事情,更有集体荣誉感和责任感。

你可能感兴趣的:(07. 大厂都在用哪些敏捷方法?(下))