《Scrum团队转型记》摘录及备注

Posted 2021-04-25 BA随思 Agile随想

最近看了一本书《Scrum团队转型记》(著者杨蕾 郑江)。这是一本关于敏捷和Scrum的实践类入门书，不厚，写得也有点意思，值得一读。以下是从书中摘录下来的我认为需要仔细品味和思考的部分内容。

• 《转型记》写道：“当团队跨国或者是有外包参与的时候，Scrum的项目就很难管理。一些对需求很清晰的项目，也不必非要使用Scrum。” (猪邦备注：敏捷方法或者Scrum是有其适用范围的，虽然现在敏捷的概念和应用好像挺火，但是并非所有的项目都需要用到敏捷。假如一个项目的需求比较清晰明确，以及它所使用的技术比较成熟稳定，那么应用传统的瀑布模型开发方法反而可能会更好。若项目团队跨地域或者有Vendor参与，敏捷的效果难以预料，这一点我是深有体会。)

• 《转型记》写道：“用户故事是一种优秀的工具，可以承载客户或用户价值的条目贯穿于Scrum的价值创造流程。然而，如果故事的大小都一样，就很难做好概要计划并体会到逐步细化的好处。例如，如果在冲刺阶段使用的故事太多、太小，是无法为概要产品规划和发布规划提供支持的。在这些层级上，我们需要更少、更不详细、更抽象的条目，否则，我们就会淹没在大量无关的细节中。因此，根据详略程度，用户故事是分层的。最大的故事约为几个月的大小，可跨越一整个或多个版本，就是我们之前说的Epic（史诗级故事）。第二个级别的故事的大小通常以周为单位，对单个冲刺来说还是有点儿大，有些团队称之为特性。最小的用户故事就是我们通常说的‘故事’，或者冲刺故事，它足够小，可以放入一个冲刺完成。任务处于故事下面一级，通常是一个人独立完成的工作，或者也有可能是两个人结对完成。完成任务所需要的时间一般以小时记。在任务这一级，我们要详细地说明如何构建而非构建什么（以Epic、特性和故事为代表）。任务不是故事，因此我们在写故事的时候必须要避免任务级的细节。” (猪邦备注：用户故事有粗有细。优先级高的故事需要细化，优先级低的故事可以粗一点。在项目规划时多数使用高层级的比较简略的用户故事。PMP里提到的滚动式规划也是类似的概念。与该知识点相关的“用户故事地图”这个技术工具可以学习一下。）

• 如何对用户故事进行优先级排序，《转型记》写道：“推荐一个叫做MoSCoW的技术来解决你的问题，它将需要做的产品功能分成4类：Must Have（必须有的功能），Should Have（应该有的功能），Could Have（可以有的功能）和Would Have（也许有的功能）。通过这个技术，可以将产品列表中的用户故事强行分成4个级别，并且集中所有资源完成Must Have和Should Have的用户故事。” (猪邦备注：这是经典的排序方法，常用。）

• 关于技术故事，《转型记》写道：“除了提交给用户‘新功能’的用户故事以外，技术故事也是任何一个Scrum项目无法避免的。所谓技术故事，是指客户不感兴趣但又不得不做的事，例如，升级数据库，清除没用的代码，重构混乱的设计或者实现一个老功能的测试自动化。” “不到万不得已，不要写独立的技术故事，最好尝试在与这个技术相关的某个功能性用户故事里面把它作为一个技术需求以任务的形式表达出来。这样做，产品负责人就不会因为客户对技术故事不感兴趣而忽视它。通过在功能性故事中体现技术，技术工作肯定不会被漏掉，而且产品负责人还会开始理解故事本身的技术复杂性。” “怎么通过用户故事常用的格式来表述技术故事呢？答案是你没有必要非这么做。只要确保技术故事的格式尽可能一致就可以了。同理，这也适用于软件错误的描述。请记住，用户故事只是一个描述需求的技术，在使用的时候要灵活，不要被这个技术所局限。” （猪邦备注：技术故事不直接显示客户价值但是又不可或缺。这里联想到PMP提及的需求跟踪矩阵Requirements Traceability Matrix，此工具用以杜绝需求遗漏。表述包含技术故事的用户故事时不必拘泥于常用的格式。这里有个问题，技术故事的来源主要是开发团队，也许极少数来自于客户。如果技术故事要由产品负责人来写的话，那么产品负责人就应该懂技术并且要从开发团队那里得到与技术故事相关的需求信息。也许技术故事由开发团队来写并以任务的形式嵌入到功能性用户故事里会比较好。）

• 关于对产品待办列表的梳理，《转型记》写道：“Scrum框架里没有强调何时、如何做梳理。在实践过程中，很多Scrum团队都会在Scrum框架已有的基础之上添加“梳理”会议。梳理会议一般是在计划会议之前进行的，经常在上一个冲刺的过程中，就会召开为下一个冲刺做准备的梳理会议（梳理用户故事优先级，大小估算，接受标准明确，拆分大号用户故事都可以是梳理会议的内容）。原则上，梳理用户故事列表是一个不间断的行为，因此在冲刺开始之前做一次梳理，然后根据实际需要，Scrum团队需要不停地做梳理。” “也许有团队成员会问，我需要看产品待办列表中的所有条目吗？其实也不用。对于产品待办列表的梳理只要能够梳理出足够团队工作2～3个迭代的内容就足矣了。对于优先级较低的条目，团队不需要花太多时间在上面。” （猪邦备注：这里提及的梳理会议不在经典Scrum的3355-5个仪式Ceremonies之列，但也是值得尝试的实践，可以视为对经典Scrum框架的一个补充。）

• 关于冲刺待办列表中的任务，《转型记》写道：“Sprint待办列表是团队当前Sprint的任务清单。和产品列表不一样，它的寿命是有限的，仅在一个Sprint的时间里存活。它里面包含所有团队已承诺的故事以及相关联的任务，以及此外的附加工作，例如，在回顾会议中所发现的团队改进任务，团队计划要在当前Sprint完成。团队一旦发现想要交付已经承诺的故事还有些新的任务需要完成，就会把它们也添加进Sprint列表。有时候团队也会发现某个现有任务已经毫无意义，那他们就会从Sprint列表中把它剔除掉。” “用户故事是要有用户交付价值的，但任务不是，任务就是工程师们具体的工作，例如设计、编码、更改数据库、测试等。这种任务级别等工作的确是有点儿像瀑布模型的工作顺序了。但是，以前瀑布模型是整个项目这样顺序工作，Scrum是到了任务级别这样顺序的工作，这就是巨大的区别了。” （猪邦备注：即使是践行敏捷，当来到任务级别工作时，还是要遵循常用的具体软件开发过程，所以学好传统的软件工程课程还是有必要的。当然敏捷也包含一些独特的工程实践例如结对编程等。但总的来说，敏捷和传统并非矛盾，而是可以互相学习借鉴。）

• 关于用户故事完成的定义DOD和接收标准，《转型记》写道：“完成的定义和接收标准不同（当某个“接收标准”里的需求适合于所有的用户故事，那么它就是完成定义里的一项；但如果该需求只是适用于所有用户故事的一个子集，那么它就是这个用户故事子集里的故事的验收标准）。” “建议在Scrum实施一开始就定义清晰的“完成的定义”，这样可以帮助团队少走很多弯路。”  （猪邦备注：其实不仅在敏捷，无论是什么工作或任务，分配任务和接收任务的人都应该就完成的定义有个协商并达成一致，这样完成任务的人才知道具体的要求是什么，做到什么程度为止，避免做出来的东西不是对方想要的结果。）