节奏大师：BA
节奏大师：BA 良好运作的团队都是相似的，而问题团队则各有各的问题 如果你走进任何一个流畅运转的敏捷团队，你事实上会发现人们做的事情都很简单，端到端的交付能力，清晰的验收条件，明确的优先级，充足但是不会让人焦虑的backlog，甚至还有友善的、喜欢开玩笑的团队成员。他们会从简单的事情入手，逐步的加强其功能，在过程中还会伴随着重构，甚至部分重写的发生，不过人们有充分的信心，代码的质量也由于一直在维护的大量测试保证。 如果你问这个敏捷团队里任何一个人这样一个问题：“你觉得敏捷的核心理念是什么？”，你会惊讶于答案的种类之多。有人认为各种工程实践比如结对编程，TDD，持续集成等至为关键；另一些人则认为迭代会议，故事墙，尽量频繁的showcase是重中之重；还有人会更抽象的将敏捷的核心描述为拥抱变化，响应变更等。这些回答当然都没有错，每个人在实施过程中，都自然会形成自己对敏捷实践的理解和看法。而在我眼中，敏捷的核心可以归纳成四个字：“渐进增强”。 渐进增强 这里的“渐进增强”可以理解为：先让一部分需求高优先级，而且想清楚了的需求先做起来，在做的过程中让团队建立起自己的节奏和工作文化，最后带动其他需求也被按部就班的完成，最终实现共同富裕……。而这篇文章要讨论的正是：如何让渐进增强在团队里变为可能？特别是在很多项目的各种范围都是固定的前提下。 要让这样的渐进增强变为可能，你事实上需要预先付出一些额外努力的，比如： 需求拆分 正确使用INVEST原则 过程可视化 文化建设 这些额外的努力事实上都需要团队里的BA作为主力来驱动的。就像田忌赛马一样，不同的拆分方法和需求的释放方式可能带来截然相反的结果。不过在进入如何实现的细节之前，我们先来看看节奏在任何一个团队中的重要作用。 反馈，节奏与心流 1975年，心理学家米哈里·齐克森米哈里（Mihaly Csikszentmihalyi）正式将心流概念化并通过科学的方式来研究。 心流（英语：Flow），也有别名以化境(Zone)表示，亦有人翻译为神驰状态，定义是一种将个人精神力完全投注在某种活动上的感觉；心流产生时同时会有高度的兴奋及充实感。 我在《反馈拯救世界》中讨论过反馈机制和心流（Flow）之间的关系。它是一种奇妙而值得追求的境界，或者心理状态，也是知识工作者所一直追求的状态。在这样顺畅的状态下工作，不但个人会获得空前的满足感，而且团队从客观上来看，会更加的高效，成员会更加的团结，不论你将什么样的需求交给他们，他们总是会顺利的将其完成。 要进入理想的，忘我的心流状态，齐克森米哈里提到至少需要满足这三点： 有清晰的目标 有明确且事实的反馈 能力和挑战的平衡（都处于比较高的状态） 既然节奏的建立如此关键，而BA又是建立这种机制的关键，那么如何在实际中实施呢？我们从一个典型的场景来入手 需求拆分 在我看来，通过传统的工具比如INVEST（+SMART）对需求进行合理的拆分，就已经可以在很大程度上确保在团队正确的道路上行进了。当然，前提是你选对了正确的工具，并且完成了正确的拆分。这里面其实包含了两个问题： 怎样就算把INVEST做对了？ 按照教科书般的INVEST划分之后不工作怎么办？ 对于INVEST的正确使用，包括诸如用户故事多大比较合适，常见的拆分模式如工作流，业务规则变种等相关的文章，已经可以算是前人之述备矣，此处不再赘述。在这里我只关注第二个问题：即，在你已经可以熟练运用INVEST拆分比较复杂需求，并且在大部分场景下都可以采用合适的模式，但是这种拆分和开发团队的能力结构又不很契合的场景。 前后端分离 有时候你会发现，你从书上读来的敏捷实践在你的团队里不工作。比如需求要纵向的、端到端的划分。然而实际运作中，在实际进入开发阶段之前，很可能最终的视觉设计已经基本定稿，甚至一些典型页面已经向客户（如果是产品的话，此处替换为产品经理）汇报过了。而且很多时候客户只关注最后结果，过程中的半成品性质的汇报往往只是走过场，最终的验收客户往往会产生新的想法，但是为时已晚。 在这种范围相对固定的场景下，似乎用前后端分离的拆分方式似乎可以更快完成任务，也更合乎直觉，毕竟有专门的UI Dev可以很轻松的将高保真转换为HTML/CSS/JS。而那些关注性能，关注高并发/高可靠的后端开发者似乎也没有必要参与其中。事实上，我见过的很多项目正是这样运作的，而且看起来这种分法在工作内容相对固定的项目中也是可以工作的。 当然，这种划分存在一些无法回避的问题： 前端为了不被阻塞，会开发一套mock 后端需要一个机制来确保实现之后通知前端以保持一致 需要额外的测试来保证集成的正确性 集成会被延后 需求无法端到端交付（必须至少等到最晚的一端完全实现） 如果操作不当，很容易出现前端做完在等后端，或者后端等前端的现象。由于变更的不透明性，又很容易产生相互指责，内部消耗。即使我们有着精湛的工程技巧，比如通过mock后端，契约测试等手段可以使得过程不至于太痛苦，但是在开发过程中，由于迟迟不能集成并做实际演示对于客户和开发团队来说，都会显得难以放心。 端到端交付 另一方面，如果你考虑实施端到端的拆分和交付方式，完整的交付一个功能点。不过这种方式的一个重要的blocker是团队成员能力的不均衡分配（也可能是团队成员的兴趣所在），而且这一矛盾随着前后端的不断精细化变得更加明显。在端到端的划分中，我们往往需要开发同时具备前后端开发的能力，退一步讲也应该具有与前/后端同事结对完成特性的能力。 此外，这种划分方式则需要面对另外一些问题： 各有专长的前后端开发如何合作 单个用户故事交付时间可能过长 开发人员能力磨合/提升需要时间 乍看起来，这两种做法看似互相矛盾，无法调和。甚至在很多情况下，如果从客观的结果上来看，两种做法可能产生的物理结果是一样的：都按时的，按质量的完成了需求。不过，我觉得前后端分离的拆分方法中忽略了一个重要的点：开发体验。就我自己而言，我痛恨那种上不着天，下不着地的开发体验：你负责的永远是系统的中间一环，你有依赖的上游，也有依赖你的下游，每个功能都永远无法真正知道有没有人用，会不会给人们带来价值。因此在项目中，我尽量会尝试端到端的贯穿一个需求，最好可以从界面到数据库表。 我觉得即使在极端的场景下，也应该采用端到端拆分和交付的方式来工作。首先，团队不再以技术为分界线来看待用户故事，而是以功能（或者说业务价值）来划分。毕竟，不管是Fixbid还是人天的项目，客户都是以功能收费的嘛。一个功能可能在实施的时候需要不同的技术细节来支撑，但是功能本身应该被作为原子级别的需求，而不是物理上前后端的割裂。其次，如果从项目交付的另一个成果：人员的能力提升来看，端到端交付方式的问题就反而会变成优势。在一个项目结束之后，前端掌握了一些后端语言/工具的使用，甚至Cloud的维护；而后端则从前端了解到JavaScript中的测试框架，组件化等知识。 此外，你事实上只需要做很小的调整，就可以让团队获得很好的开发体验。即使项目范围在一开始就基本固定，即使关键页面的设计稿都已经经过汇报。仅仅做好符合INVEST原则的将需求拆分就可以很大程度上帮助团队形成高效的，顺畅而稳定的交付节奏。 INVEST原则 INVEST是渐进增强的基础，没有合适粒度、相互独立的用户故事划分，要进行迭代式的渐进增强就成了空中楼阁。事实上，这个基本功需要在很多层次去刻意练习。INVEST事实上在敏捷实践中影响深远：过小的划分会引入更高的管理成本，而过大的划分则可能导致优先级难以界定，而且很容易影响士气：没有人愿意看到在墙上挂一周的卡。 和现实世界中的很多事情一样，对于一名BA来说，划分出合理大小的用户故事需要很多方面的平衡，有时候简直是一门艺术。我们可以通过一个简单的例子来稍作解释 个人主页 比如，我们要实现Jigsaw的个人主页，页面有很多个部分组成：导航，提示信息，项目历史清单，用户Profile入口等等： 假设我们的第一个用户故事：显示提示信息Heading（如下图红框圈定部分所示）。 这个用户故事需要从后台读取数据，并展现在客户端。数据可以从后端数据库中读取，也可以从后台文件中读取，这个取决于后台数据存储的技术有没有选定。作为第一个用户故事，它可能还会关联一个技术卡：搭建前后端的基础代码，比如用create-react-app创建一个前端工程，用gradle创建一个后端工程之类。要不要独立成一个单独的卡可能取决于团队的能力结构。 作为一个有业务价值的用户故事，这个需求需要满足： 端到端实现（即，连通从页面到数据库） UI和Mockup基本一致 另一个好处是它要求开发者在做的过程中建立基本的反馈机制，比如TDD、结对编程/Code Review Session等细节，并体验Kick Off，Desk Check等实践在团队里是如何工作的等等。换句话说，就是尝试从一个简单、实际的需求入手，建立一个可以运作的反馈机制。一旦熟悉了如何做一个用户故事，那么进一步稍微复杂的用户故事（还记得吗？控制节奏）就会相对顺畅很多。毕竟一回生二回熟嘛。...