精益 VS scrum ——《精益开发实战——用看板管理大型项目》读后感

最新推荐文章于 2022-10-15 17:32:24 发布

weixin_30498921

最新推荐文章于 2022-10-15 17:32:24 发布

阅读量686

点赞数

文章标签：数据库测试

原文链接：http://www.cnblogs.com/cly84920/archive/2012/09/24/4426498.html

版权

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

一口气读完。对比上一本讲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。

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

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

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

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

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

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

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

2）测试团队如何融入scrum。

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

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

<1> 提高代码质量，尽量少产生点bug

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

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

<4> 除了项目组中包含测试人员，在项目开发完成后，还是需要再由测试组进行一轮测试。

<5> 在每个轮次开始时做计划会议时，都预留足够的时间用于修复上个轮次结束时遗留的bug。理想情况下，scrum的情况是这样的：

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

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

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

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

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

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

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

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

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

3）迭代周期 VS 前十的任务。

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

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

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

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

4）估算扑克牌。

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

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

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

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

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

5）任务墙 VS 看板。

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

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

<1>上面会陈列更多的任务，比如总体产品backlog居然也在这面墙上（根据项目需要，可以按自己意愿自由扩展这面墙的栏目），所以看板会比scrum的任务墙更长，更大;

先看个任务墙：

这是我以前在某个项目中布置的一个任务墙：

再看个看板：

怎么说呢？任务墙是看板的一个子集。看板将任务墙这种形式带到了一个更高的高度，一种极致。

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

6）燃尽图 VS 开发速率图

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

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

7）发布计划。

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

8）sprint周期 VS 限额。

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