读《用户故事地图》

    近两周，读完了《用户故事地图》1~14章，后四章未完待续...（￣︶￣）↗

    读之前，一看书的名字”用户故事地图”，不就是我们常说的User Story Mapping嘛，这么小的一个工具，为何能讲整本书？读之后，才认识到这么一个概念在Scrum实践中的核心地位，讲述的是一种思维方式和做事方式，给出了一套方法论，远超过工具的范畴。

    Jeff Patton采用了渐进式的结构来讲解“用户故事地图”，前1~5章搭了全书的骨架，从是什么、为什么、怎么做三个层次阐述了user story mapping；6~12章，深入阐述了用户故事，特别是在团队中怎么实践user story的3C原则，怎么对用户故事做合理拆分；13~18章，更像是阐述用户故事的生命周期，起源于机会，通过discovery & inception阶段建立共识、进行验证性学习，然后交给delivery交付团队，在交付过程中时常查阅、时常讨论当前的用户故事地图，根据现有需求变化和交付状况更新地图，保证地图能时刻反应未来预期产品的全貌。

    全书内容很多，不是一篇读书笔记能概括的，所以就在这里阐述最有感触的几个点，整本书的大致框架见文末的思维导图（缺少14~18章，待更... 跳过了“用户故事”的某些章节）。

    用户故事是激发沟通的火花，团队应把沟通作为高效团队的核心价值 。故事，是程序员和其它角色沟通的必备要求，故事地图以结构化方式来组织这些要素，以此来强化软件开发中最关键的部分——沟通。

    正常情况下，人每天都会跟他人交流，却很少思考沟通的有效性。如果只是闲聊，对方听听、表达一下共情基本就算对话完成，到底获取了多少信息，获取的信息的准确性，也就不那么重要了；在工作沟通中，获取信息的数量、质量都可能影响到最终的工作产出。特别是在敏捷开发里，常常以一个团队为单位，共同完成某一项目，如果不能达成共识，不能对彼此所想的内容以及要解决的业务问题达成一致的理解，会导致彼此磨合的过程痛苦，最后产出的结果难堪。共享文档不代表达成共识，我们就用用户故事替代了它，但是只有card的用户故事还不如一个共享文档，要辅之coversation & confirmation，才可能达到比共享文档更好的效果。当讨论结束的时候，讨论的业务价值没有发生变化，变化的是具体的实现方式、变化的是我们对这些功能特性的一致理解。我们能感觉到目标一致，并且对前进方向有信心。

    我们开各种会，用各种可视化方法（包括用户故事地图），私底下的讨论，都是为了达成共识。

    计划，为了更少的开发；计划，为了更快的学习。

    敏捷开发就是一种迭代的、增量式的开发，这是正确的。另一方面，在我看来，敏捷开发也是一种先做减法、再做加法的开发。做加法并不难，只要存在需求，就存在做加法的可能性，如果时间和资源都是无限的，那么做加法可以一直进行下去，没有完美的软件，只有更好的软件。而在软件初期，特别是划分MVP的阶段，做减法是需要智慧的。做减法从表面上看是在砍系统的功能，深入来看，一定是项目核心团队反复思考系统外的预期成果，思考产品发布后用户能使用和感知的东西，再来决定系统内需要什么功能，为成果排优先级，而不是功能。MVP里存在的backlog不是一堆功能的堆砌，而是现实世界的实际收益。

    MVP完成后，我们开始开发周边功能，关注非功能性需求（当然MVP里也需要关注），通过真实的数据或用户调研对产品进行持续评估和打磨，这就是在做加法。甚至不等MVP完成，每轮迭代结束后，我们都会找客户/用户做评估，评估就意味着学习和改变，每次只加一点点，每次加的一点点是到位的。

    要求一个产品负责人来写所有故事和展开所有故事对话，显然是行不通的。

    在乙方的敏捷团队中，BA更像是一个产品负责人的角色，他的目标是为客户打造一个有价值的、可用的、可行的产品。在打造这个产品之前，必须确定一个方案，这个方案对客户/用户有价值，客户/用户可以使用，且在给定的时间和资源条件下可以完成。

    有价值的，就要求对客户的业务愿景、业务模式有深度理解；可用的，就要求理解用户，可以自如跟用户合作，力求了解他的工作方式，开发出UI原型；可行的，就要求设计未来产品的架构，知道哪些技术方案可以用来解决目前的难题。所以，设计这样一个方案需要对业务问题、用户问题和技术问题都有所洞察。一般人不会同时具备这三种能力，但这并不影响他成为一个优秀的BA。优秀的BA会借力做出好的决策，他可以包容许多人的知识技能和观点，领导一个小型的、跨职能的团队来协作寻找正确的方案。

    比较有感触的就是这几点了，前1~14章思维导图贴上︿(￣︶￣)︿