硝烟中的SCRUM-读书笔记

硝烟中的SCRUM-读书笔记(2009-11-21 13:57:11)转载标签： scrum实践 分类： IT项目管理 
产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。我们叫它故事（story），有时候也叫做 backlog条目。



注：对于产品backlog的理解不应该仅仅停留在用户故事层面，产品backlog本身来源于用户故事，体现的是用户能够感知的业务场景。但是产品backlog本身包含了更多的信息，包括优先级，估算，How to Demo(作为测试用例的原型)。产品backlog是有优先级，估算和初步测试的业务场景驱动的需求结合。是后面形成Sprint迭代计划的基础。产品backlog最好的方式就是借助于Excel进行收集，分类和整理。



Sprint计划会议非常关键，应该算是 Scrum中最重要的活动（这当然是我的主观意见）。要是它执行的不好，整个 sprint 甚至都会被毁掉。 举办 Sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心。这么说可能比较模糊。其实，Sprint 计划会议会产生一些实实在在的成果：

sprint 目标。 
团队成员名单（以及他们的投入程度，如果不是 100%的话）。 
sprint backlog（即 sprint 中包括的故事列表）。 
确定好 sprint 演示日期。 
确定好时间地点，供举行每日 scrum会议。


注： 在SCRUM中有三个重要的会议，迭代计划会议(Sprint Planning Meeting)；每日晨会(Daily Scrum Meeting)和迭代回顾会议(Sprint Review Meeting)。Sprint计划就是SCRUM中最核心的计划，是大型IT项目管理中的项目主计划的精炼，对于初步优先级和估算已经前置到产品backlog了，Sprint 计划重点就变成了真正迭代周期，迭代故事列表的确定。变成了工作量，优先级，质量和进度这些重要因素的权衡。SCRUM的一个重要角色产品负责人(Product Owner)必须参加Sprint计划会议，以确认目标，优先级和范围。



为什么不能在质量上让步？我尽力把内部质量和外部质量分开。一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样。松散的沙滩上怎么可能建起精美的楼阁？

外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。 
内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。


注：质量的问题首先要意识到质量包括了外部质量和内部质量。不能因为进度和多做功能点而牺牲了质量，在SCRUM实践中我们没有看到太多的关于代码质量的实践内容，类似CodeReview，前期通用约定。但是我们看到了技术性工作的内容，对于公用性技术工作的内容书里面建议仍然是放到一个具体的业务场景驱动的故事后面。但是产品Backlog直接驱动的Sprint计划，架构设计方面的内容还是需要落地来做。特别是当存在多个Sprint迭代版本的时候，更需要关注总体设计和架构的介入点。(试着避免技术故事。努力找到一种方式，把技术故事变成可以衡量业务价值的普通故事。这样有助于产品负责人做出正确的权衡。)



在 sprint计划会议之前先为它初步制定一个时间表，可以减少打破时间盒的风险。下面来看一下我们用到的一个典型的时间表。这个日程绝不是强制执行的。Scrum master 根据会议进程的需要，可以对各个阶段的子进程时间安排进行调整。

13:00-13:30。产品负责人对 sprint 目标进行介绍，概括产品 backlog。定下演示的时间地点。
13:30-15:00。团队估算时间，在必要的情况下拆分 backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的 backlog 条目都要填写“如何演示”。
15:00-16:00。团队选择要放入 sprint 中的故事。计算生产率，用作核查工作安排的基础。
16:00-17:00。为每日 scrum会议（以下简称每日例会）安排固定的时间地点（如果和上次不同的话）。把故事进一步拆分成任务。


注：sprint计划的另外一个重要任务就是，将产品Backlog里面的用户故事拆分到开发人员理解的任务层面。任务是SCRUM在开发阶段管理的最小单位。在这里又不得不返回考虑产品Backlog里面用户故事的粒度。我们对用户故事的理解应该是一个用户可以理解的一个可以独立实现用户价值的最小活动和行为。如果按照一个sprint的迭代周期为一个月来看，一个故事的工作量应该在1人周内，一个任务的工作量应该在1-3人天左右。注意用户故事和任务本身的粒度和规模，否则后续的Sprint进度跟踪中重要的燃尽图(BurnDown Chart)将没有意义。故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心。



有一点很重要：产品负责人和团队需要对“完成”有一致的定义。所有代码被 check in 以后，故事就算完成了吗？还是被部署到测试环境中，经过集成测试组的验证以后才算完成？我们尽可能使用这样的定义：“随时可以上线”，不过有时候我们也这样说：“已经部署到测试服务器上，准备进行验收测试”。

最开始我们用的是比较详细的检查列表。现在我们常说“如果Scrum团队中的测试人员说可以，那这个故事就算完成了”。然后责任就到了测试人员身上，他需要保证团队理解了产品负责人的意图，要保证故事的“完成”情况可以符合大家认可的定义。



我们曾经尝试过用多种形式来保存 sprint backlog，包括 Jira、 Excel，还有挂在墙上的任务板。开始我们主要使用 Excel，有很多公开的Excel 模板可以用来管理 sprint backlog——包括自动生成的燃尽图等等。在如何改良基于 Excel 的 sprint backlog 方面，我有很多想法，但此处暂且不提，我也不会在这里举例。下面要仔细描述的，是我们发现管理 sprint backlog 最有效的形式——挂在墙上的任务板！








注：SCRUM中的燃尽图是项目管理中的挣值曲线图的简化，通过燃尽图可以看到整个Sprint的生产率情况，当前我们的进度是提前了还是落后了？以分析和评估风险，调整Sprint中的用户故事列表。SCRUM中上图的进度跟踪看板是一种很重要的可视化项目管理方式。



只要让他们坐到一起，就会有立竿见影的成效。过上一个 sprint，团队就会认为挪到一起是绝妙的主意，“一起”意味着：

互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。
互相看到：所有人都可以看到彼此，都能看到任务板—不用非得近到可以看清楚内容，但至少可以看到个大概。
隔离：如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到。反之亦然。  
“隔离”并不是意味着这个团队需要被完全隔离起来。在一个格子间的环境中，如果你的团队拥有自己的格子，而且隔间的墙足够大，可以屏蔽墙内外的大多数噪音，这也就足够了。

转自 http://blog.sina.com.cn/s/blog_493a84550100g2hp.html