前些天在微博上看到人邮出版社说即将出版《精益开发实战》这本书,而书的作者就是《硝烟中的Scrum和XP》的作者Henrik!立马心动,几天后在china-pub上看到书已经开卖了,马上下单。今天上午书到了。

enter image description here

一口气读完。对比上一本讲Scrum的书,这本书中有很多地方值得注意:

1)团队规模 和 Scrum of Scrums

无论是Scrum之父肯施瓦伯的书《应用Scrum进行软件项目管理》,还是《硝》,都重点讲的是Scrum本身,而Scrum团队的规模都不大,按Henrik在《硝》中的说法,团队规模应该在5~9人之间,最好是7个人。如果人数特别多,就应该使用Scrum of Scrums——将团队拆成几个更小的团队,每个小团队各自使用Scrum,然后各个团队再派负责人参加团队之间的Scrum。两本书关于Scrum of Scrums讲的都并不多,《硝》讲了一些,但它其实变化很大——多团队之间并不是每日站立会议,而是每周一次,全员参与,15分钟以内,沟通的方式不像是“交流”而更像是“汇报”。

《精》中讲的案例则正好填补了这个空白,讲的是一个由60人组成的团队,这个大团队拆成了5支小团队,共同配合。本书很细致地讲解了怎么进行Scrum of Scrums——当然,它管这个叫精益,并不是典型的Scrum。

enter image description here

5支团队分别是:1支产品分析团队,1支测试团队和3支功能开发团队。

其中产品分析团队和测试团队都会派人进入功能开发团队,这些人是交叉团队,即属于垂直的功能开发团队,又属于横向的支持团队。他们是Scrum of Scrums的重要元素。

Scrum中要求团队是跨职能的,所以这样的安排对于三支功能开发团队来说,是非常好的。但产品分析团队和测试团队又该做何解释呢?它们可不是Scrum中所说的跨职能团队呀。书上说之所以会有这两支团队的存在,是因为在产品分析和测试方面,不仅需要深入开发细节的人,也需要站在全局把握进度和方向的人。

Scrum of Scrums的每日站立会议会开三轮,首先是3支垂直功能团队们开自己的站立会议——包括属于这支团队的产品分析人员和测试人员。接着是2支横向团队分别开会,由交叉团队的成员,分别汇报各个功能开发团队的当前进度和瓶颈,横向团队据此了解了全局的进度,进行相应的调整和计划。最后是各个团队的负责人和项目的总负责人碰头。

这三轮会议的时间是串行的,每轮会议的时间都严格控制在15分钟以内。也就是说,每天早上都会开45分钟的会,分三次开完。有些人只会出席一个会议,有些人会出席两到三个会议。其中第一轮和第两轮会议,分别有三支和两支团队同时进行,这些团队都会集中在看板前,相距不过几米,如果有问题需要跨团队沟通,走两步即可。

《硝》中每周一次的全体站立会议,从管理上更加扁平,全员参与,但这个真的感觉不到“每日站立会议”的精神了。《精》中每天早上三次早立会议,不要求全员参加,从管理上来说,让组织架构更深了,多少有点官僚的影子进来了,但至少更能感受到“每日站立会议”的精神。

enter image description here

我知道每日站立会议对于Scrum的重要性,但从没想过Scrum of Scrums时的壮观景象,呵呵。

2)测试团队如何融入Scrum

关注Scrum的人都会问到这个问题,理论上如果一切都那么理想的话,Scrum团队编写出来的代码应该是质量非常高的,团队成员是跨职能的,自己能做测试工作,每个轮次结束时代码都是可马上发布的。但——现实是,专业的QA这一环肯定是必不可少的,专业的测试人员具备一些工程师没有的技能,工程师写单元测试的确可以帮助提高一下代码质量,降低bug数量,但专业的QA是不可替代的。

肯施瓦伯没有讲如何让QA融入进来,《硝》倒是有比较详细的讲解。《硝》中的建议如下。

  1. 提高代码质量,尽量少产生点bug。

  2. 每个轮次少接受一点任务,保证这个轮次完成的功能质量都很高,可发布,不抢功能,重质量,不抢速度。

  3. 把测试人员放到项目组中,让他在日常的工作中就开始检验其他成员的代码,只有他检验通过的,才能放到“完成”一栏去,如果测试工程师没有事情做了,就让他做一些辅助的工作,比如组织文档,编写发布、打包之类的脚本,拆分sprint backlog。

  4. 除了项目组中包含测试人员,在项目开发完成后,还是需要再由测试组进行一轮测试。
    enter image description here

  5. 在每个轮次开始时做计划会议时,都预留足够的时间用于修复上个轮次结束时遗留的bug,理想情况下,Scrum的情况是这样的:

enter image description here

但实际情况,在sprint2的时候,会受到测试团队反馈的关于sprint1的bug困扰。

enter image description here

在“开发新功能”还是“修复bug”这个问题上,采用“可以开始构建新东西,但是要给‘将旧功能产品化’分配高优先级”的策略。

enter image description here

出于这个现实情况的考虑,Scrum所推崇的“每个Scrum周期结束后,代码都可直接发布”,其实是很难做到的,应该说不可能做到。在这一点上,无需过多纠结。

《精》在讲测试这一块时,有类似的建议,希望测试团队能定期进行测试,不要等到最后阶段,等开发团队代码全提测了再进行测试。从第一张图上,三支功能开发团队的队伍中,都含有测试人员,就能看出这点。

这种方式会招来测试人员的反感,认为工作量太大,而且代码会反复修改,并不稳定,测试工作不好做。

《精》比较了一下两种测试方式的时间成本:

enter image description here

enter image description here

白色的部分表示的是测试用去的时间,黑色的部分表示的是修复bug用去的时间。

enter image description here

由这张图可以看出,使用传统的测试方法,测试的时间是比较短,但用于修复bug的时间却会非常地长,因为bug越晚被发现,修复的成本就越高。而后者虽然测试时间变长了,但在修复bug上的用时却会明显变短。

这里谈一下我个人的看法:我虽然认同测试进入项目组,并尽早开始测试,但这事其实很难执行,因为在绝大多数公司里,测试人员都是归属在一个横向支持团队中,而团队和项目组之间是合作的关系,追求“资源池”的感觉,支持完成了某个项目,就直接回到池中等着下一个任务的到来。所以测试一直跟进某个项目,特别是还归属于项目组中去,很难!主要是行政方面会有很大的阻力。

3)迭代周期 VS 前十的任务

在Scrum中,有一个特别重要的概念就是Sprint周期。整个Scrum就是围绕迭代周期来进行的,每个周期之始进行本轮次的计划会议,周期结束时进行验收会议和回顾会议,在周期之内,进行每日站立会议。开发团队会有非常强的节奏感,重视在一个很短的周期内完成一些功能,并且在周期结束时,代码可达到发布状态。

《精》在很大程度上和Scrum有相似的地方,比如也会开会挑选优先级高的用户故事,压入待开发队列栈,但《精》并没有Sprint周期的概念,不要求开发团队估算下个轮次(也就是未来几周内)要开发完成哪几个任务,不要求开发团队估算故事点。《精》认为估算故事点非常耗时,但意义却并不大。在计划会议上,唯一要做的事,就是排出接下来要做的十个任务,而这些任务什么时候完成,并没有时间上的任何估算和承诺。

这一点和Scrum有非常大的区别。而事实上,我更喜欢《精》的方式。Scrum的计划会议,虽然一再对工程师强调在未来的这个周期内,大家只用做一个“估算”,这个不是“承诺”,完不成也没关系,希望借此来让工程师放松,更愉快地进行工作。但在实际执行的时候,“估算”很难不被“承诺”关联上,工程师们总是会对“估算”有压力。而且如果估算过于乐观,在回顾会议上面对没有完成的估算,沮丧感还是很强烈的。

《精》只重视优先级,并不重视“一定周期内完成多少功能”。这可以让工程师毫无压力,其实更符合敏捷的“人性化”精神。

4)估算扑克牌

《硝》和《精》中都提到了估算扑克牌。而且也都是在计划会议中使用的,所以功能大致相同。但其实两者又有区别。《硝》中讲的是Scrum实践,Scrum的计划会议需要工程师们估算出Sprint backlog的耗时,根据团队生产力和各个Sprint backlog的耗时,排出本轮次可完成的任务。《硝》中的估算扑克牌就是用于团队估算每个Sprint backlog需要的故事点的,它的单位是数字。

enter image description here

而《精》的计划会议是用于确定接下来最重要的十个开发任务。有Scrum中,产品backlog拆分成Sprint backlog时,Sprint backlog的粒度有要求,不能太大,如果大了,就需要进一步拆分。有《精》中也一样,产品负责人列出的开发任务,需要被开发团队估算是不是太大了——不用像scrum那样,进行过于细致地拆分和时间估算,《精》并不提倡时间估算。《精》认为开发任务的大小和开发实际使用的时间没有直接关系,有可能一个小功能因为各种原因,前后花了非常多的时间,而一个大功能却可能很快就开发完成了。《精》只是需要在排开发任务时,保证这十个开发任务的粒度不要太大就行。

《精》提供的估算扑克牌,只有这么几张。

enter image description here

其中问号和咖啡的意思和Scrum中一样,但没有了代表故事点的牌,只有表示“小”“中”“大”的三张牌。产品负责人问开发团队某个开发任务的大小时,开发团队抽出自己的牌压在桌上,当大家一起亮牌时,如果意见不一致,那么进一步讨论,如果结论是开发任务粒度太大的话,那么产品负责人进一步将开发任务拆小。

enter image description here

扑克牌玩法还是一样,但意义已经完全不同了。

5)任务墙 VS 看板

无论是任务墙还是看板,都不鼓励使用电子系统,而是使用实体墙,这一点上两者是一样的。事实上,两者非常相似——开发团队的每日站立会议都是在这面墙面前进行的,而且墙上也都会划分“待开发”、“开发中”、“待测试”、“测试中”、“完成”等栏目,也都会配上表示进度的图表。

只是看板比任务墙更进一步。

  1. 上面会陈列更多的任务,比如总体产品backlog居然也在这面墙上(根据项目需要,可以按自己意愿自由扩展这面墙的栏目),所以看板会比scrum的任务墙更长,更大。先看个任务墙:
    enter image description here
    这是我以前在某个项目中布置的一个任务墙:
    enter image description here
    再看个看板:
    enter image description here
    怎么说呢?任务墙是看板的一个子集。看板将任务墙这种形式带到了一个更高的高度,一种极致。

  2. 看板将待开发功能进一步做了个整理,清晰地划分出“下十个新功能”、“下五个技术故事”、“下五个bug”。“新功能”是可以看到的新的功能,“技术故事”是迁移数据库,编写自动构建脚本,重构代码等用户看不到,但技术上确定占开发量的工作,“bug”是遗留的待解决bug。

enter image description here

6)燃尽图 VS 开发速率图

Scrum用一条左上至右下的斜线来表示开发进度,用每轮次多少个故事点来表示团队的开发速度。

enter image description here

而《精》用一条左上至右上的斜线来表示开发进度,用每周或每月多少个开发任务来表示团队的开发速度。

enter image description here

7) 发布计划

《精》和Scrum一样,只保证当前正在进行最重要的功能,开发的代码质量高,可持续将功能集成起来,产品可持续迭代,小步快跑地发布新功能。只保证当前在做最正确的事,但不保证整体的开发时间。所以《精》也需要在一开始就搞定领导,如果领导坚持“x月x日前,xxx功能要全部开发完成”,那就没法玩了。这应该是敏捷所有方法论都会遇到的问题。

8)Sprint周期 VS 限额

Scrum的核心是Sprint,确定一个较短的Sprint周期,然后通过计划会议将优先级最高的需求压到最近的Sprint周期中,然后每日站立会议,最后验收和回顾会议。借Sprint周期来做项目的照明弹,保持团队的成就感和活力,同时保证新增的功能可持续集成至生产环境。

enter image description here

《精》没有sprint周期的概念,不是通过时间,而是通过限额来“降低开发团队在可视范围内的待开发任务量”的,比如看板上只能压入“最新十个新功能”、“最新五个技术问题”、“最新五个bug”。这些“最新”都是优先级最高的,超过这个限额的,就不往看板上放。这样,可以保证开发团队不会承受过大压力。

因为Scrum是有周期的,而且每个周期内都有设计、开发、测试、验收,所以某种意义上来说,Scrum的每个Sprint轮次都是一次小型的瀑布,很完整。而精益没有这种感觉,它更像一种源源不断的“流”,没有起点,也没有终点,任何时候看板上都填满了接下来需要开发的限额任务,但高质量的产出却源源不断。

《精》第17章的一组图很好地反映了看板的精髓。图不好找,建议大家自己买来看看。很棒的一本书。