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