ThoughtWorks敏捷培训

首先得澄清的是,本文参考了很多文章还有ThoughtWorks的《深入核心的敏捷开发》,不算原创。另外,这是本人在公司内部敏捷培训的讲稿,有地方有些口语化,见谅

如无特殊说明,本部分的敏捷实践以ThoughtWorks为准
ThoughtWorks敏捷被认为是60%scrum+40%XP,先看下scrum的部分,主要是非技术实践部分。
一、非技术实践
一些容易混淆的名词解释:

  • Sprint,这是scrum中的一个概念,通常是为期两周的一个冲刺。在TW还有很多其它公司,这个叫做Iteration,迭代,可能更符合大家认知。

下面进入正题:

  • 三个角色:
    • 产品所有人:PO。PO不仅要决定选择做什么,还要能从商业价值的角度解释为什么做这些
    • 团队:The Team。任务执行团队,通常包括RD,QA,UX,BA等。TEAM一定要自组织,坐到一起。通过大量的面对面沟通,白板沟通,以及3-5人现场组成的微型会议,大大提高工作效率。
    • 敏捷教练:Scrum Master。
  • 三个工件:
    • 产品待办:Product Backlog
    • 迭代待办:Sprint Backlog。基本上可以理解为Kanban,在很多公司的实践中相当于jira。在ThoughtWorks和很多其它公司通常使用物理看板。
    • 增量:Increment
  • 六个会议(并未按照scrum的五会来,根据TW的实践做了调整):

    • 迭代回顾会议(Retro):

    • 参加成员:全部参加。

    • 目的:上个迭代做的好的地方和不好的地方总结一下,除此以外,还要总结每个人的成长,敏捷成熟度,交付质量等等,上个迭代所有遗留问题都在这解决。不是进度会!迭代都结束了还进度啥!敏捷的大部分会议都目的明确,节奏飞快,只有这个会的节奏比较慢,所以,所有其他会上没有机会说的事情此时都可以提出来,所以两个小时并不长。

    • 时间:1-2小时。争取1小时结束。

    • 频率:每迭代一次

    • 迭代计划会议(IPM):

    • 参加成员:全部参加。

    • 目的:下个迭代要做的所有story都要在这里输出,jira上建立epic和sprint。核心目的有两个:1、story价值探讨和认同。PO不仅要传达需求,而且要让大家认同需求的必要性和带来的价值,如不能达成一致,可能需求会被打回重新做。2、story估点(估点是包括了开发+单元测试+联调+可能的bug修复的所有时间),根据经验,快速准确的估点。这会被用来回馈给业务,“我们有30个点,这个需求需要10个点,那个需要15个,那个需要8个,那个需要15个,你们看一下我们下个迭代开发哪几个”。最后,对于恰好填满点数的需求,给业务承诺完成70%。

    • 时间:半小时到一小时。敏捷的会议,时间都非常紧凑,所以就要求有多方面的:1、对PO的要求。story评审时,忽略不必要的细节,关注上述的两个核心目的。2、对RD的要求。忽略不必要的细节,聚焦story所消耗的关键开发资源,快速估计出大略的时间。

    • 频率:每迭代一次。

    • 站会(Daily Standup):

    • 参加成员:全部参加。

    • 目的:对齐进度,调整节奏。

    • 时间:10-15分钟。

    • 频率:每天一次

    • 展示会(Showcase):

    • 参加成员:全部参加

    • 目的:整个团队向PO汇报迭代成果的汇报会议,让PO发现实际开发和需求做的不一样的地方。这个会议相对正式,必须全员参加。除了展示人,最好不要带电脑,你跟领导汇报工作的时候会带个电脑自己写自己的吗?

    • 时间:1小时。

    • 频率:每迭代一次。

    • 开卡会(Story kick-off):

    • 参加成员:PO,负责某个story开发的RD和QA

    • 目的:需求反讲,确定QA、RD、PO三者对需求理解一致。在开发前就将路线错误的情况扼杀在摇篮中。同时,在IPM中没有讨论的需求细节,在这个会全部讨论清楚。

    • 时间:30分钟

    • 技术评审会/任务拆分会:

    • 参加成员:组内所有RD/负责某需求开发的RD。

    • 目的:对于较复杂的需求,需要进行技术评审,在RD内部对齐技术方案。简单的需求,只需拆分任务即可。

Q&A:
Q:这么多会,真的每个都有用吗?

  • 首先,敏捷定义的会议并不多,而且大部分会是每迭代一次的,也就是两周才一次。日常会议很少,大部分日常的会议被TEAM中的现场沟通所替代了。
  • 再看会议人数,敏捷大部分会议都将人数最小化了,大部分会议人数在3-5人,全员会议也就10人左右,效率极高。

Q:敏捷是不是太死板了,定义角色也就算了,连每周要开什么会,每个会开到哪天都要定?甚至每个会的参加角色,每个会的时间长短都要定?

  • 流水线为什么效率高?敏捷跟流水线是不是有些相似。
  • 事实上,规定会议时间,是加快会议节奏的非常好的方式。
  • 规定参加角色,是为了最小化会议参加人数。

Q:关于会议,其它大家可能存在的问题

  • 站会:
    • 为什么站着?为了减少时间。
    • 为什么要现场开?当面沟通更有效。
    • 为什么限制15分钟?限制发散,如果超过了15分钟,很可能讨论了非站会应该讨论的问题了,由于站会频率高,且全员参加,必须缩短时间。
  • 迭代计划会议:
    • 提前两周真的能定下来所有需求吗?PM回答,通常可以。而且敏捷并不拒绝随时更改需求
    • 1小时能开完?瞄准目的,按节奏来开,就一定可以。
    • 小优化怎么办?通常无需评审。
  • 迭代回顾会议:
    • 为什么不过进度?处于两个迭代之间,没什么进度可过。
    • 为什么竟然需要两个小时?回去看看这个会的目的。

Q:从角色的视角重新看一下四会:

  • PO视角和客户视角:
    • 迭代开始前,IPM可以明确每个需求需要的点数和下个迭代的总点数,对于PO和客户来说是很重要的,能够根据优先级和点数选定本迭代的主要开发任务。
    • 日常开发站会可以帮助PO以天为单位掌握整体进度,及时与客户沟通调整。
    • Showcase可以发现开发出来的产品和需求不一样的地方并立即改进。
    • 开卡会和Showcase的作用差不多,但开卡是在开发前,更早发现team对需求的理解问题。
    • AT可以保证交付到线上的代码质量。
  • TEAM视角:
    • 开发前,IPM可以保证本次迭代要做的所有需求都是研发自己估过的,根本上避免所谓的倒排,导致需求做不完,做不完就是自己估的有问题。
    • 开卡会,避免到Showcase才发现需求做错了导致的资源浪费和士气低落。
    • Showcase,TEAM全员向PO和客户汇报进展,有成就感。
    • 站会,让其他人帮助解决遇到的困难,及时同步。
    • 对于team来说,最重要的还是看板,实时追踪团队中所有工作。

总结,敏捷开发的核心就是在一个高度协作的环境下,不断的通过反馈来进行自我调整和完善。

  • TEAM
    • 坐一起这件事,就是协作和反馈的最好体现。有事一抬头就能找到相关人士,走几步就能找到白板完成讨论,及时反馈到工作中进行调整。
    • 看板实时展示团队目前的进度,在协作和反馈上也起了很重要的作用。
  • 会议
    • IPM,在开发开始前,TEAM就对PO和客户做一次工作量的反馈。
    • 紧接着发生的开卡会,是TEAM的部分成员对PO的一次工作内容反馈。
    • 站会+回顾会,存在的意义就是反馈。
    • Showcase,迭代结束时对客户的反馈。

二、下面再看一下敏捷的技术实践部分,包括XP在内:
XP,也就是极限编程,在国内实践的人并不多。ThoughtWorks的敏捷流程,吸取了XP中的很多优秀组成。

  • Pair,结对编程。

    • 这个是XP的核心实践,也是我讲的所有敏捷实践中唯一一项我自己没有实践过的,不过我也心向往之。
    • 而且两个人共用一台电脑,略带私人性质的聊天活动都会很自觉地不去进行了。结果一天下来,新实验结对编程的程序员都会喊累,神经紧绷8个小时的工作不累才怪。
    • 从这个角度看,严格限制结对编程的程序员不准加班是合理的,实际上,开始每天甚至不必限制8小时工作,每天这样工作6小时队项目同样是非常高效的。
    • Pair实践一般难以推进,因为有可能会带来大幅的效率降低,没人愿意承担这个责任。所以,目前我也没有推进的计划。
    • 目的:两个:1、互相学习。这个非常重要,尤其是对于刚加入团队的同学,跟mentor pair一两天之后就可以快速了解整个团队的开发节奏和风格。2、对于重要的需求,也可以快速发现对需求理解不一致的地方,和对技术实现想法不一致的地方。
  • TDD,测试驱动开发。

    • 简单来说就是先写测试,再开发。实践上会更复杂一些。
    • XP和TDD同为Kent Beck提出,所以TDD是XP的核心实践也没啥好说的。Kent Beck目前在FB工作,也带动了FB的敏捷发展。
    • 目的:1、帮助写出可测试的代码。一段代码如果很难添加测试,往往设计就是不合理的。先写测试,后写代码,可以帮助开发同学做出合适的系统设计。2、在测试的保护下进行开发,事实上会提高开发效率。
  • CI,持续集成。

    • 不管XP阵营还是非XP阵营,持续集成都是近年来最没有争议的编程核心实践。
    • 持续集成的本意是,经常地(也就是持续)把代码合并到master中(也就是集成)。
    • 在发展的过程中,逐渐也包括了合并后触发的一系列流程。比如单元测试,集成测试,代码质量分析,压力测试等。
    • CI绝对是敏捷的核心实践,在迭代的最初要做的最重要的事情之一就是建立CI流水线。在CI没有通过的时候,必须全员停止手头工作排查问题,直到通过为止。
  • TBD,主干开发。

    • 既然说到了持续集成,要每天不断的合并代码到master,你想到了什么,对,这跟主干开发的要求是一致的。
    • 因此,大部分敏捷流程成熟的公司,都无一例外的使用主干开发。
    • 我们同样使用了敏捷流程,这是我们一直推进主干开发的重要原因。
  • CR,代码复盘(代码评审)。

    • ThoughtWorks的CR是以Meeting的形式做的,和大部分公司不一样,我也很少实践这种方式,不评价。可以尝试一下。
    • CR的主要目的,是保证代码质量。代码质量,不仅包含代码风格这种意义的代码质量,更重要的是代码能否用最好的方式正确的完成需求。因此,逐字逐句的阅读所有代码,是必须的。我个人通常认为,通读一个组一天的代码需要两个小时,而Meeting形式的话,由于有写代码的人在旁边讲解,会大大加快这一过程,预计可以减少到1小时。
    • 对于TBD而言,CR的重要性更是无法替代——除此以外,没有更好的保证master上代码质量的方法了。

三、最后看一下转型过程
同时,也标注了我们目前所处的位置。

  • 第一步,建立角色和流程,缩短交付周期。——这是本次复盘的侧重点。
    • 角色基本建立。由于疫情的原因,TEAM这个角色还没有坐到一起,白板讨论的氛围和现场3-5人直接开会的氛围还没建立起来。
    • 站会和看板可以认为是建立起来了,虽然由于疫情,站会既不能站着开也不能面对面开,但根据我参加的情况来看,可以接受。
    • 展示会也可以认为建立起来了,存在的主要问题是时间过长,目的不够明确。
    • 验收会没什么问题。
    • 迭代回顾会议和迭代计划会议,这周刚刚开始,效果还不行。
  • 第二步,引入技术实践,保证交付质量。——下个双月结束的时候,可以复盘一下这个。
    • 单元测试(Unit Test):稳步推进中
    • 集成测试(Integration Test):跟QA协商中
    • UI自动化测试,暂无计划
    • 主干开发(TBD):稳步推进中
    • 持续集成(CI):稳步推进中
    • 持续部署和持续交付(CD):业务场景可能不会太常用,存疑
    • 运维相关:SRE很给力,系统虽然bug不少,都能用。再加上字节本身是大公司,有公司的基础支持。
  • 第三步,提升价值交付效率和响应力
    • 前两步是团队逐渐向敏捷方法和实践靠拢的阶段,第三步事实上是在团队适应敏捷的节奏之后向敏捷价值观靠拢的最后一步。前两步还只是加快交付效率,提升交付质量,是“学”;而第三步注重的是价值观落地,以及价值观落地之后的“变”。
    • 鉴于我们到这个阶段预计还要半年,这里不展开。
  • 敏捷转型中,培训非常重要,这也是这个会议的原因之一。

发表评论

电子邮件地址不会被公开。 必填项已用*标注