| 敏捷开发现在已经不是新鲜事物了，我们都从各种渠道听到过不同的团队实施敏捷的胜果，听的时候觉得很美，回到家就发现那都是别人家的团队，结合自己的情况一看就发现问题一大堆。就算是最终打算一试，也经常会不知如何开始。这就是我希望编写这份文档的原因，能够找到一个遵循的敏捷项目管理模型，虽然我们都知道没有一个放之四海而皆准的方法，但在更高的层面上我觉得这仍然是可行的。也就是说，管理模型是一致的，但是其中采用的方法可能各有不同，最终目标是唯一的：打造一支可以快速适应变化的高质量团队，并输出高质量的产品！
今天想跟大家分享的是用户故事的规划过程，对于如何使用用户故事驱动团队的开发过程，后续会有更新。
用户故事的主要问题
用户故事可以帮助开发团队从用户的角度来理解需求，同时在交付的过程中按照用户可用的场景进行交付，确保了开发团队可以持续的交付用户关心的功能。但是在实际开发中，团队往往不知道如何入手。
如何用好用户故事需要解决几个关键问题：
如何产生用户故事，让用户将故事讲清楚？
如何将用户故事的内容原汁原味的传递给开发团队？
如何将用户故事中的内容转换为开发功能点，识别与其他功能点的依赖，形成详细的产品规格？
如何在使用用户故事进行增量开发的过程中保持架构的稳定性？同时驱动架构的优化和演进。
如何在开发过程中按照故事进行交付，协同开发，测试，架构以及UI/UE等团队？
如何使用各种开发工具和平台，借助如任务跟踪，分支计划，持续集成，持续发布，自动化测试等工具让开发过程变得更加高效？
用户故事的需求整理方式与传统需求的整理方式有很大的不同，传统软件开发中我们依赖用户需求，技术需求，规格说明书等工具试图使用规范的文档来解决需求收集和传递的问题。在这个过程中，我们将用户的需求转换成技术可以理解并可实施的规格。对于已经习惯了这种方式的人来说，要转换成使用用户故事的方式需要比较大的思维方式转变，大家往往遇到的疑问也是，难道使用用户故事就不需要规格了吗？其实不然，首先我们要了解用户故事到底是什么。
用户故事到底是什么？
大家可能觉得既然我们使用用户故事来替代传统需求，那么用户故事就是记录需求的方式了。其实，用户故事不是用来编写的，而是用来讨论和跟踪的。
使用用户故事，我们的目的是让用户可以自然的讲述需求，这样才能确保信息的真实性。因为任何软件产品都是为了帮助用户完成某种任务，可以说任何的软件产品或者系统都是通过交互来解决问题的，而交互的双方可能是人和系统，也可能是系统和系统，也可能是模块和模块。这样理解的话，任何的需求其实都是某个个体（人，系统或者模块）在和其他个体进行交互的过程中，我们希望的行为方式。用户故事的3个关键点：人，过程和目的；可以帮助我们将这个行为方式讲清楚。在讲故事这个过程中，我们应该专注于故事主线，而不是如何实现。
一旦用户讲清楚了故事，下一步我们需要产生相应的可开发的功能点。这里我们需要专注于如何实现。一般来说，我们很难通过一个功能点来满足一个用户故事，而必须要不同的功能点配合完成。但是我们仍然必须确保讨论的范围是仅仅围绕当前的故事，这时候技术人员非常容易发散，会考虑一些和当前功能点相关，但是和当前故事不相关的内容，如：这个功能可能以后还要用到的，所以我们还要这样这样等等。这时，用户故事可以起到控制讨论范围的作用。你可能会觉得，技术人员的角度是对的，因为可扩展，可复用等是软件设计的基本原则。但是我们应该从发展的角度来看待这些问题，假设我们可以预见的其他用户故事确实会影响这个功能点，那么这样考虑是ok的，但是应该到讨论那个用户故事的时候再去考虑；如果我们没有其他可以预见的故事会影响这个功能点，那么这些所谓的扩展性复用性设计就是浪费，因为你不知道是否会需要。
讨论清楚了功能点，进入开发以后，用户故事是控制技术团队开发进度和交付进度的引线，也就是我们应该按照故事一个个的进行开发测试和交付。这样才能确保我们交付的永远和用户预期一致，所有的开发，测试投入都是可以产生用户认可的价值的。这个时候用户故事起到了跟踪和驱动开发过程的作用。
通过以上分析，我们可以看到用户故事如何编写并不重要，重要的是它所驱动的过程，通过这个过程，我们可以把用户和技术团队紧密结合，并让大家产生对交付内容的统一认识。所以，用户故事是一种沟通工具，而不是编写工具或者需求模板！
故事讲给谁？
在真正开始将故事之前，我们首先要确保正确人都参与进来。对于规划一款产品来说，你至少需要：最终用户代表，产品经理（或类似Scrum中的PO），项目经理（或类似Scrum中的ScrumMaster），团队中的技术骨干（那些对实现的业务很熟悉，对所要使用的技术或者系统很熟悉的技术人员），技术骨干又可以分成架构，开发和测试三个不同技能的人。这样看来，你至少需要6个人参与这个讲故事的过程（除非有些人可以互相替代）。
你的故事是讲给这里面每个人听的，同时也希望每个人都能够在讲故事的时候有所输入，不仅仅是在听。
最终用户代表：这些人一般会作为讲故事的主角，因为他们是最了解故事的人。但是最终用户代表只能用用户的角度来描述故事，这里会缺失很多技术细节。当他们开始讲故事的时候，技术人员就需要补充这些细节，将那些从用户角度看上去可能很简单的故事后面所涉及到的复杂度暴露出来。
产品经理和项目经理：这两名成员基本起到协调人的作用，一般产品经理（PO）偏向用户，项目经理（ScrumMaster）偏向团队。我们希望他们的这种倾向性能够在讨论过程中体现出来，将故事的优先级，重要程度，实现难度等问题进行归纳总结，形成我们的项目计划。同时，这个故事讨论的过程一般都是以会议形式进行，这2个人应该作为会议的组织者（主持人）出现，引导团队高效的完成讨论过程。
技术骨干：首先技术人员要明确自己也是主角，而不仅仅是旁听。很多人都有这样的体会，明明很简单的一个功能，为啥做起来会那么慢？这里面有2个原因，第一个是用户自己就没有吧这个所谓的“简单”功能想明白；第二个是一个对用户“简单”的功能，对于技术来说恐怕没有那么简单，但这个信息一般很难跟用户讲明白，所以很多技术就倾向于不说或者说的很少。结果就是双方对于难度的认知不一致。技术骨干参与这个讲故事的过程的目的，主要就是为了帮助用户从技术实现的角度理解故事，同时自己也能够将技术实现的思路想明白。
怎样讲故事？
讲故事的过程我们通过3个步骤进行：找线索 -> 画主线 ->
规格化
找线索 – 画出故事的主角
用户不知道从哪里开始讲故事，这是我们会遇到的第一个问题。其实这时候用户的内心感觉就如同看完一部电影以后走出电影院，试图给没有看过这个电影的朋友讲述。想一想在这个场景下你会如何开始？比如，大话西游大家都看过吧；那么讲故事的方式是，孙悟空在500年前如何如何….，然后紫霞仙子如何如何…
你会发现，你永远都会从某个角色开始讲述。其实让用户讲故事的方式也一样，我们首先要引导用户说出这个故事里都有谁。一部电影是多个角色的故事线交织的结果，一个产品也是一样。有了这些角色，我们就有了可以抽取故事的线索。
你会发现，当团队开始整理不同的类型的用户的时候，他们已经开始自然的讲述故事，因为要把一个角色说清楚，你就必须考虑他要做的事情，故事自然就出来了。但是在这个阶段，我们切记不要过于发散，明确我们的目的是整理用户画像，只要不同用户类型间的边界清晰了，就可以结束，不要为细节纠缠。另外，在后续的过程中我们也会发现可能有些角色还需要添加进去，那么就到时候说。
最终将我们整理出的每个用户类型用一张即时贴粘在白板的最左侧，如下图：
一般我会按照距离最终用户的远近来摆放这些即时贴，同时对每个角色进行编号，以便后续可以很容易的进行引用。
画主线 – 使用影响地图画出故事主线
有了故事的主角，讲故事就相对容易了。在这个阶段，我们希望能够帮助团队尽量将故事的每一个步骤的都想清楚，通过在看板上进行可视化，我们就可以达到这个目的。这里，
我们可以使用简化版的影响地图，如下图：
标准的影响地图上有4个列，分别是WHY WHO HOW和WHAT，这种结构在进行比较大和模糊的目标讨论的时候，如：战略规划，会很好用，因为HOW和WHAT比较容易区分；但是用在讨论用户故事的步骤时候，其实HOW和WHAT区别不大，如果坚持使用规范的影响地图会让团队感到迷惑。所以，我建议将HOW/WHAT合并。具体来说：
WHY：我们这个用户故事是什么？为什么我们要做这个故事？
WHO：这个故事里面都有哪些角色？
HOW/WHAT：这些用户为了完成这个故事，需要做些什么，怎样操作？
如上图：是一个标准的“新用户注册”的用户故事，大家一定都非常熟悉。基本上这个故事就是浏览者通过
登录->注册->填写信息->验证邮件提交注册，管理员审核，成为已注册用户后首次登录->完善资料。但通过卡片的方式将每个步骤放入白板后你会发现，整个团队可以很好的聚焦到很细节的问题上，同时又对整个故事具备全局观。如果不借助这种可视化方式，那么团队可能很容易丢失当前讨论的主线，从一个细节延展开到其他的部分去了。
注意这里对每个用户故事进行了ID标注，同样也是为了后续可以容易进行引用。
你可能会问，那我用个思维导图一类的工具不是更好么？电子化工具的好处是对信息的保存和分享方便，但是在团队讨论中，我们更加重视团队讨论的氛围，聚焦和整体效率，如果使用电子化工具，就无法让每个人都可以同时对这张图进行操作，而必须由一个人操作，其他人很容易走神，如果工具不熟练还会耽误时间。所以看上白板是个很Low的工具，其实对于团队讨论来说，它的效率高于任何的电子化工具。
如上图：这是我作为敏捷教练参与的一次用户故事讨论，你可以看到大家都聚集在白板周围，整个讨论都是站立进行，任何人都可以随时发表意见，用手指着某个即时贴就可以开始说：“这个”步骤怎样怎样。如果没有可视化工具，或者使用电子化工具，希望每个人都可以用“这个”来聚焦所有人的注意力是很困难的，你可能需要解释“这个”到底是什么，又或者需要在电子工具中鼠标来点，如果操作者不是讲解者，那会更加麻烦。细节决定效率！
规格化 – 使用用户故事地图进行功能分析
有了故事主线，我们就可以进行下一步的功能细化。这一步所产出的其实就是传统软件开发过程中的软件规格说明书。软件规格说明书对于开发人员实现产品功能非常重要，是软件开发中不可缺少的部分。很多人认为敏捷开发不需要文档，其实这是个巨大的误解。但是敏捷开发中的文档确实和传统的需求文档有很多区别：
敏捷开发重视的是文档产生的过程，希望通过透明化的过程和集体讨论来确保内容的完整性和信息在过程中的传递。对于文档本身的格式倒是没有具体的要求，只要确保讨论中的内容都被记录就可以。
– 敏捷开发中的文档并不是用来传递需求的主体，人才是传递需求的主体。
敏捷开发的文档是一份活的文档，所以我们更希望通过系统来记录需求，而不是传统的word或者excel等静态文档来记录。这些文档的作用是帮助团队成员来回忆和讲述，同时也作为过程追踪的手段。
传统软件开发中往往有2份项目计划，一份列出需求并在需求上进行估算以便推导出预算；另外一份是时间和资源计划，这份计划又往往是按照阶段来进行规划的。敏捷开发只有一份项目计划，就是按照用户故事来组织时间，资源和各个阶段的跟踪
– 这其实就是用户故事驱动的敏捷开发的含义。
规格化的过程中我们可以使用用户故事地图的方式来进行，团队一起根据故事主线中的每个步骤进行讨论，分析出在产品的特定区域（模块）中的功能点，并使用技术人员容易理解的方式来描述这部分的功能。这整个过程就是从将需求从用户角度的描述转换到技术实现角度描述的过程。在这个过程中你会发现一些在故事主线中看不到的技术细节。
这个过程中，我们希望综合考虑架构和测试的输入，这两个角色需要从自己的角度确保每个故事的分解都满足架构的要求，并且是可以进行测试的。由于每个用户故事都会穿越多个功能区域，架构师必须协助团队确保架构的扩展性，复用性以及性能等要求。对于测试来说，要确保每个用户故事都是可测试的才能确保后续的测试计划和用例可以配合团队的开发过程，并按照故事逐个交付给用户。
如上图，将以上用户登录这个故事分解为功能点，展示在用户故事地图上，这是标准的用户故事地图格式：
最上面2层是产品的功能区域（模块）
每个模块下面功能点，这些功能点来自于用户故事中的某个步骤的分析
每个功能点的即时贴上标注出用户故事的ID，这样便于我们比对影像地图找到对应的功能点
一些在影响地图中没有明确列出的内容在这张图上被显示出来，比如上图中后台管理和系统功能部分的内容
关于用户故事地图：【用户故事地图(User Story Mapping)之初体验】
注：这篇文章对于地图顶层的解释稍有不同，这是我当时对用户故事地图的理解还不深入造成的。
如何组织需求讨论会
讲故事的过程我们一般通过需求讨论会的形式来进行，确保以上应该参与的人员都到场。既然是个会议，我们就必须确保会议的高效，这里可以参考三星高效会议的8点原则：
（1）凡是会议，必有主题；
（2）凡是主题，必有议程；
（3）凡是议程，必有决议；
（4）凡是决议，必有跟踪；
（5）凡是追踪，必有结果；
（6）凡是结果，必有责任；
（7）凡是责任，必有奖罚；
（8）凡是奖罚，必须透明。
针对需求讨论会，我们至少需要有以下安排
1.会议主题：XXX产品需求讨论会，目的是在4小时内对XXX产品的XXX内容进行讨论
2.会议议程：
组织者：产品经理XXX或者项目经理XXX
参与者：业务方或最终用户，产品/项目经理，团队技术人员（架构，开发，测试等）
讨论内容（按照优先级排序的故事列表）
3.会议分工：
主持人：由产品经理和项目经理轮换组织
需求记录人：由技术团队内某人承担，负责在讨论过程中将用户故事和所产生的功能点进行详细记录，形成文档或者录入系统。
问题记录人：由技术团队内某人承担，负责在讨论过程中将无法现场确认的问题进行记录，形成文档或者录入管理系统。
4.会议交付物：
针对议程中的每个用户故事所产生的文档或者管理系统记录
讨论过程中所记录的问题列表或者管理系统记录
针对用户故事文档的下一步操作，如：制定开发计划，预算等等
针对问题的跟踪方式，如：问题列表的状态由谁负责维护，每个问题由谁负责解决跟进，每个问题预计解决的时间。
需求讨论会的过程就是按照以上3个步骤讨论故事和分析故事的过程，我们可以按照以下流程进行
1.讨论会前期准备
可以在进行正式的需求讨论会前先进行一次头脑风暴，邀请用户和技术一同参与，在这个过程中大家可以自由讨论。目的是让大家现对产品的大致情况有所了解。
2.讨论会过程
首先由主持人（产品经理PO/项目经理ScrumMaster）向团队列出会议所要讨论的故事列表，这个过程不用讨论细节，目的是让大家知道会议的内容和目标，便于控制进度。
根据所列出的故事列表优先级，从第1个故事开始梳理故事主线，分解功能点，并由专人负责记录
重复以上过程直到完成列表中所有故事的讨论
3.注意事项
一定要按照故事列表逐个讨论，每个讨论都要细化到功能点并完成记录，再进入下一个故事的讨论；不要先讨论所有故事主线，在一并分解功能点。这样做的目的是让团队可以聚焦，避免多条线索交织造成干扰。
在讨论每个故事的时候，不要讨论与当前主线无关的内容；特别是技术团队容易从一个功能点扩散到其他功能点，因为这是技术团队对产品的视角；这种扩散会降低效率。主持人在看到这种情况的时候应该适时制止，告诉团队其他的功能点可以留到其他故事中讨论，只要的产品的一部分，我们在后续的故事中肯定会涉及。
完成每个故事的讨论后可以进行短暂休息，在讨论过程中要确保每个参与成员都集中精力，避免形成小组讨论的形式。建议每个故事的讨论都站立在白板前进行。
主持人可以由PO和ScrumMaster按照故事进行轮换，主持人的主要职责是确保过程的顺畅，团队精力的集中。
待确认事项
建议在白板上开辟一片区域对讨论中出现的团队无法当场确认的问题进行记录，避免在这些问题上纠结太久，影响会议效率。
以上是如何使用用户故事来驱动产品规划和设计的过程，后续我会对如何再借助kanban和Scrum来驱动开发和交付过程。
|
