敏捷开发现在已经不是新鲜事物了，我们都从各种渠道听到过不同的团队实施敏捷的胜果，听的时候觉得很美，回到家就发现那都是别人家的团队，结合自己的情况一看就发现问题一大堆。就算是最终打算一试，也经常会不知如何开始。这就是我希望编写这份文档的原因，能够找到一个遵循的敏捷项目管理模型，虽然我们都知道没有一个放之四海而皆准的方法，但在更高的层面上我觉得这仍然是可行的。也就是说，管理模型是一致的，但是其中采用的方法可能各有不同，最终目标是唯一的：打造一支可以快速适应变化的高质量团队，并输出高质量的产品！

今天想跟大家分享的是用户故事的规划过程，对于如何使用用户故事驱动团队的开发过程，后续会有更新。

用户故事的主要问题

用户故事可以帮助开发团队从用户的角度来理解需求，同时在交付的过程中按照用户可用的场景进行交付，确保了开发团队可以持续的交付用户关心的功能。但是在实际开发中，团队往往不知道如何入手。

如何用好用户故事需要解决几个关键问题：

• 如何产生用户故事，让用户将故事讲清楚？
• 如何将用户故事的内容原汁原味的传递给开发团队？
• 如何将用户故事中的内容转换为开发功能点，识别与其他功能点的依赖，形成详细的产品规格？
• 如何在使用用户故事进行增量开发的过程中保持架构的稳定性？同时驱动架构的优化和演进。
• 如何在开发过程中按照故事进行交付，协同开发，测试，架构以及UI/UE等团队？
• 如何使用各种开发工具和平台，借助如任务跟踪，分支计划，持续集成，持续发布，自动化测试等工具让开发过程变得更加高效？

用户故事的需求整理方式与传统需求的整理方式有很大的不同，传统软件开发中我们依赖用户需求，技术需求，规格说明书等工具试图使用规范的文档来解决需求收集和传递的问题。在这个过程中，我们将用户的需求转换成技术可以理解并可实施的规格。对于已经习惯了这种方式的人来说，要转换成使用用户故事的方式需要比较大的思维方式转变，大家往往遇到的疑问也是，难道使用用户故事就不需要规格了吗？其实不然，首先我们要了解用户故事到底是什么。

用户故事到底是什么？

大家可能觉得既然我们使用用户故事来替代传统需求，那么用户故事就是记录需求的方式了。其实，用户故事不是用来编写的，而是用来讨论和跟踪的。

• 使用用户故事，我们的目的是让用户可以自然的讲述需求，这样才能确保信息的真实性。因为任何软件产品都是为了帮助用户完成某种任务，可以说任何的软件产品或者系统都是通过交互来解决问题的，而交互的双方可能是人和系统，也可能是系统和系统，也可能是模块和模块。这样理解的话，任何的需求其实都是某个个体（人，系统或者模块）在和其他个体进行交互的过程中，我们希望的行为方式。用户故事的3个关键点：人，过程和目的；可以帮助我们将这个行为方式讲清楚。在讲故事这个过程中，我们应该专注于故事主线，而不是如何实现。
•  一旦用户讲清楚了故事，下一步我们需要产生相应的可开发的功能点。这里我们需要专注于如何实现。一般来说，我们很难通过一个功能点来满足一个用户故事，而必须要不同的功能点配合完成。但是我们仍然必须确保讨论的范围是仅仅围绕当前的故事，这时候技术人员非常容易发散，会考虑一些和当前功能点相关，但是和当前故事不相关的内容，如：这个功能可能以后还要用到的，所以我们还要这样这样等等。这时，用户故事可以起到控制讨论范围的作用。你可能会觉得，技术人员的角度是对的，因为可扩展，可复用等是软件设计的基本原则。但是我们应该从发展的角度来看待这些问题，假设我们可以预见的其他用户故事确实会影响这个功能点，那么这样考虑是ok的，但是应该到讨论那个用户故事的时候再去考虑；如果我们没有其他可以预见的故事会影响这个功能点，那么这些所谓的扩展性复用性设计就是浪费，因为你不知道是否会需要。
• 讨论清楚了功能点，进入开发以后，用户故事是控制技术团队开发进度和交付进度的引线，也就是我们应该按照故事一个个的进行开发测试和交付。这样才能确保我们交付的永远和用户预期一致，所有的开发，测试投入都是可以产生用户认可的价值的。这个时候用户故事起到了跟踪和驱动开发过程的作用。

通过以上分析，我们可以看到用户故事如何编写并不重要，重要的是它所驱动的过程，通过这个过程，我们可以把用户和技术团队紧密结合，并让大家产生对交付内容的统一认识。所以，用户故事是一种沟通工具，而不是编写工具或者需求模板！

故事讲给谁？

在真正开始将故事之前，我们首先要确保正确人都参与进来。对于规划一款产品来说，你至少需要：最终用户代表，产品经理（或类似Scrum中的PO），项目经理（或类似Scrum中的ScrumMaster），团队中的技术骨干（那些对实现的业务很熟悉，对所要使用的技术或者系统很熟悉的技术人员），技术骨干又可以分成架构，开发和测试三个不同技能的人。这样看来，你至少需要6个人参与这个讲故事的过程（除非有些人可以互相替代）。

你的故事是讲给这里面每个人听的，同时也希望每个人都能够在讲故事的时候有所输入，不仅仅是在听。

• 最终用户代表：这些人一般会作为讲故事的主角，因为他们是最了解故事的人。但是最终用户代表只能用用户的角度来描述故事，这里会缺失很多技术细节。当他们开始讲故事的时候，技术人员就需要补充这些细节，将那些从用户角度看上去可能很简单的故事后面所涉及到的复杂度暴露出来。
• 产品经理和项目经理：这两名成员基本起到协调人的作用，一般产品经理（PO）偏向用户，项目经理（ScrumMaster）偏向团队。我们希望他们的这种倾向性能够在讨论过程中体现出来，将故事的优先级，重要程度，实现难度等问题进行归纳总结，形成我们的项目计划。同时，这个故事讨论的过程一般都是以会议形式进行，这2个人应该作为会议的组织者（主持人）出现，引导团队高效的完成讨论过程。
• 技术骨干：首先技术人员要明确自己也是主角，而不仅仅是旁听。很多人都有这样的体会，明明很简单的一个功能，为啥做起来会那么慢？这里面有2个原因，第一个是用户自己就没有吧这个所谓的“简单”功能想明白；第二个是一个对用户“简单”的功能，对于技术来说恐怕没有那么简单，但这个信息一般很难跟用户讲明白，所以很多技术就倾向于不说或者说的很少。结果就是双方对于难度的认知不一致。技术骨干参与这个讲故事的过程的目的，主要就是为了帮助用户从技术实现的角度理解故事，同时自己也能够将技术实现的思路想明白。

怎样讲故事？

讲故事的过程我们通过3个步骤进行：找线索 -> 画主线 -> 规格化

找线索 – 画出故事的主角

用户不知道从哪里开始讲故事，这是我们会遇到的第一个问题。其实这时候用户的内心感觉就如同看完一部电影以后走出电影院，试图给没有看过这个电影的朋友讲述。想一想在这个场景下你会如何开始？比如，大话西游大家都看过吧；那么讲故事的方式是，孙悟空在500年前如何如何….，然后紫霞仙子如何如何… 你会发现，你永远都会从某个角色开始讲述。其实让用户讲故事的方式也一样，我们首先要引导用户说出这个故事里都有谁。一部电影是多个角色的故事线交织的结果，一个产品也是一样。有了这些角色，我们就有了可以抽取故事的线索。

这里我们可以借助2个工具来协助找线索：影响地图和用户画像

关于影响地图：【Impact Mapping 影响地图 读书与演练心得】

TODO: 完善使用影响地图找出故事主角的过程

关于用户画像

海外公司注册、海外银行开户、跨境平台代入驻、VAT、EPR等知识和在线办理：https://www.xlkjsw.com

原标题：用户故事驱动的敏捷开发 – 1. 规划篇

关键词：