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

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

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

用户故事的主要问题

---

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

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

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

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

用户故事究竟是什么？

---

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

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

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

故事讲给谁？

---

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

你的故事是讲给这里面每一个人听的，同时也但愿每一个人都可以在讲故事的时候有所输入，不只仅是在听。

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

怎样讲故事？

---

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

找线索 – 画出故事的主角

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

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

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

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

关于用户画像
http://www.zhihu.com/topic/19647591
http://cdc.tencent.com/?p=4898

你会发现，当团队开始整理不一样的类型的用户的时候，他们已经开始天然的讲述故事，由于要把一个角色说清楚，你就必须考虑他要作的事情，故事天然就出来了。可是在这个阶段，咱们切记不要过于发散，明确咱们的目的是整理用户画像，只要不一样用户类型间的边界清晰了，就能够结束，不要为细节纠缠。另外，在后续的过程当中咱们也会发现可能有些角色还须要添加进去，那么就到时候说。

最终将咱们整理出的每一个用户类型用一张即时贴粘在白板的最左侧，以下图：

通常我会按照距离最终用户的远近来摆放这些即时贴，同时对每一个角色进行编号，以便后续能够很容易的进行引用。

画主线 – 使用影响地图画出故事主线

有了故事的主角，讲故事就相对容易了。在这个阶段，咱们但愿可以帮助团队尽可能将故事的每个步骤的都想清楚，经过在看板上进行可视化，咱们就能够达到这个目的。这里， 咱们可使用简化版的影响地图，以下图：

标准的影响地图上有4个列，分别是WHY WHO HOW和WHAT，这种结构在进行比较大和模糊的目标讨论的时候，如：战略规划，会很好用，由于HOW和WHAT比较容易区分；可是用在讨论用户故事的步骤时候，其实HOW和WHAT区别不大，若是坚持使用规范的影响地图会让团队感到迷惑。因此，我建议将HOW/WHAT合并。具体来讲：

• WHY：咱们这个用户故事是什么？为何咱们要作这个故事？
• WHO：这个故事里面都有哪些角色？
• HOW/WHAT：这些用户为了完成这个故事，须要作些什么，怎样操做？

请参考：【影响地图中HOW的理解与对比】

如上图：是一个标准的“新用户注册”的用户故事，你们必定都很是熟悉。基本上这个故事就是浏览者经过 登陆->注册->填写信息->验证邮件提交注册，管理员审核，成为已注册用户后首次登陆->完善资料。但经过卡片的方式将每一个步骤放入白板后你会发现，整个团队能够很好的聚焦到很细节的问题上，同时又对整个故事具有全局观。若是不借助这种可视化方式，那么团队可能很容易丢失当前讨论的主线，从一个细节延展开到其余的部分去了。

注意这里对每一个用户故事进行了ID标注，一样也是为了后续能够容易进行引用。

你可能会问，那我用个思惟导图一类的工具不是更好么？电子化工具的好处是对信息的保存和分享方便，可是在团队讨论中，咱们更加剧视团队讨论的氛围，聚焦和总体效率，若是使用电子化工具，就没法让每一个人均可以同时对这张图进行操做，而必须由一我的操做，其余人很容易走神，若是工具不熟练还会耽误时间。因此看上白板是个很Low的工具，其实对于团队讨论来讲，它的效率高于任何的电子化工具。

如上图：这是我做为敏捷教练参与的一次用户故事讨论，你能够看到你们都汇集在白板周围，整个讨论都是站立进行，任何人均可以随时发表意见，用手指着某个即时贴就能够开始说：“这个”步骤怎样怎样。若是没有可视化工具，或者使用电子化工具，但愿每一个人均可以用“这个”来聚焦全部人的注意力是很困难的，你可能须要解释“这个”究竟是什么，又或者须要在电子工具中鼠标来点，若是操做者不是讲解者，那会更加麻烦。细节决定效率！

规格化 – 使用用户故事地图进行功能分析

有了故事主线，咱们就能够进行下一步的功能细化。这一步所产出的其实就是传统软件开发过程当中的软件规格说明书。软件规格说明书对于开发人员实现产品功能很是重要，是软件开发中不可缺乏的部分。不少人认为敏捷开发不须要文档，其实这是个巨大的误解。可是敏捷开发中的文档确实和传统的需求文档有不少区别：

• 敏捷开发重视的是文档产生的过程，但愿经过透明化的过程和集体讨论来确保内容的完整性和信息在过程当中的传递。对于文档自己的格式却是没有具体的要求，只要确保讨论中的内容都被记录就能够。
  – 敏捷开发中的文档并非用来传递需求的主体，人才是传递需求的主体。
• 敏捷开发的文档是一份活的文档，因此咱们更但愿经过系统来记录需求，而不是传统的word或者excel等静态文档来记录。这些文档的做用是帮助团队成员来回忆和讲述，同时也做为过程追踪的手段。
• 传统软件开发中每每有2份项目计划，一份列出需求并在需求上进行估算以便推导出预算；另一份是时间和资源计划，这份计划又每每是按照阶段来进行规划的。敏捷开发只有一份项目计划，就是按照用户故事来组织时间，资源和各个阶段的跟踪 – 这其实就是用户故事驱动的敏捷开发的含义。

规格化的过程当中咱们可使用用户故事地图的方式来进行，团队一块儿根据故事主线中的每一个步骤进行讨论，分析出在产品的特定区域（模块）中的功能点，并使用技术人员容易理解的方式来描述这部分的功能。这整个过程就是从将需求从用户角度的描述转换到技术实现角度描述的过程。在这个过程当中你会发现一些在故事主线中看不到的技术细节。

这个过程当中，咱们但愿综合考虑架构和测试的输入，这两个角色须要从本身的角度确保每一个故事的分解都知足架构的要求，而且是能够进行测试的。因为每一个用户故事都会穿越多个功能区域，架构师必须协助团队确保架构的扩展性，复用性以及性能等要求。对于测试来讲，要确保每一个用户故事都是可测试的才能确保后续的测试计划和用例能够配合团队的开发过程，并按照故事逐个交付给用户。

如上图，将以上用户登陆这个故事分解为功能点，展现在用户故事地图上，这是标准的用户故事地图格式：

• 最上面2层是产品的功能区域（模块）
• 每一个模块下面功能点，这些功能点来自于用户故事中的某个步骤的分析
• 每一个功能点的即时贴上标注出用户故事的ID，这样便于咱们比对影像地图找到对应的功能点
• 一些在影响地图中没有明确列出的内容在这张图上被显示出来，好比上图中后台管理和系统功能部分的内容

关于用户故事地图：【用户故事地图(User Story Mapping)之初体验】
注：这篇文章对于地图顶层的解释稍有不一样，这是我当时对用户故事地图的理解还不深刻形成的。

如何组织需求讨论会

---

讲故事的过程咱们通常经过需求讨论会的形式来进行，确保以上应该参与的人员都到场。既然是个会议，咱们就必须确保会议的高效，这里能够参考三星高效会议的8点原则：

（1）凡是会议，必有主题；
（2）凡是主题，必有议程；
（3）凡是议程，必有决议；
（4）凡是决议，必有跟踪；
（5）凡是追踪，必有结果；
（6）凡是结果，必有责任；
（7）凡是责任，必有奖罚；
（8）凡是奖罚，必须透明。

针对需求讨论会，咱们至少须要有如下安排

• 会议主题：XXX产品需求讨论会，目的是在4小时内对XXX产品的XXX内容进行讨论
• 会议议程：
  • 组织者：产品经理XXX或者项目经理XXX
  • 参与者：业务方或最终用户，产品/项目经理，团队技术人员（架构，开发，测试等）
  • 讨论内容（按照优先级排序的故事列表）
• 会议分工：
  • 主持人：由产品经理和项目经理轮换组织
  • 需求记录人：由技术团队内某人承担，负责在讨论过程当中将用户故事和所产生的功能点进行详细记录，造成文档或者录入系统。
  • 问题记录人：由技术团队内某人承担，负责在讨论过程当中将没法现场确认的问题进行记录，造成文档或者录入管理系统。
• 会议交付物：
  • 针对议程中的每一个用户故事所产生的文档或者管理系统记录
  • 讨论过程当中所记录的问题列表或者管理系统记录
  • 针对用户故事文档的下一步操做，如：制定开发计划，预算等等
  • 针对问题的跟踪方式，如：问题列表的状态由谁负责维护，每一个问题由谁负责解决跟进，每一个问题预计解决的时间。

需求讨论会的过程就是按照以上3个步骤讨论故事和分析故事的过程，咱们能够按照如下流程进行

• 讨论会前期准备
  • 能够在进行正式的需求讨论会前先进行一次头脑风暴，邀请用户和技术一同参与，在这个过程当中你们能够自由讨论。目的是让你们现对产品的大体状况有所了解。
• 讨论会过程
  • 首先由主持人（产品经理PO/项目经理ScrumMaster）向团队列出会议所要讨论的故事列表，这个过程不用讨论细节，目的是让你们知道会议的内容和目标，便于控制进度。
  • 根据所列出的故事列表优先级，从第1个故事开始梳理故事主线，分解功能点，并由专人负责记录
  • 重复以上过程直到完成列表中全部故事的讨论
• 注意事项
  • 必定要按照故事列表逐个讨论，每一个讨论都要细化到功能点并完成记录，再进入下一个故事的讨论；不要先讨论全部故事主线，在一并分解功能点。这样作的目的是让团队能够聚焦，避免多条线索交织形成干扰。
  • 在讨论每一个故事的时候，不要讨论与当前主线无关的内容；特别是技术团队容易从一个功能点扩散到其余功能点，由于这是技术团队对产品的视角；这种扩散会下降效率。主持人在看到这种状况的时候应该适时制止，告诉团队其余的功能点能够留到其余故事中讨论，只要的产品的一部分，咱们在后续的故事中确定会涉及。
  • 完成每一个故事的讨论后能够进行短暂休息，在讨论过程当中要确保每一个参与成员都集中精力，避免造成小组讨论的形式。建议每一个故事的讨论都站立在白板前进行。
  • 主持人能够由PO和ScrumMaster按照故事进行轮换，主持人的主要职责是确保过程的顺畅，团队精力的集中。
  • 待确认事项
  • 建议在白板上开辟一片区域对讨论中出现的团队没法当场确认的问题进行记录，避免在这些问题上纠结过久，影响会议效率。

以上是如何使用用户故事来驱动产品规划和设计的过程，后续我会对如何再借助kanban和Scrum来驱动开发和交付过程。

 

 

---

请关注微信公众号 【devopshub】，获取更多关于DevOps研发运维一体化的信息

​