3.PO如何给开发团队讲好故事

    敏捷开发系列文章目录

    讲出符合开发团队味口的故事。

    上一章说了敏捷开发团队的构成与迭代过程，本章重点说一下迭代第一天的计划会议。熟话说“好的开始就成功了一半”，一个迭代的计划会议作得好很差确实直接注定着迭代的成功与失败。迭代开始以前，PO确定都已经提早准备好了本次迭代的全部故事，而且提早都发给了团队熟悉，后来咱们通常都会在前一个迭代快要完成的时候开一个下个迭代的熟悉会议，组织你们一块儿熟悉下个迭代的故事，一开始并无这么作，是在过去的多个迭代中，发现每一个迭代计划会议都会拖得很长，有时候会开整整一天还没开完，须要晚上加班继续把故事讲完，任务安排好。在回顾会议的时候咱们有总结为何会这样？咱们发现每一个故事消耗的时间都特别的长，你们会提针对这个故事提不少的问题，PO会跟你们解释这个故事的需求，有时候PO也没有想到的地方你们就会讨论，这样深刻下去，那么时间就这样消耗掉了。最后你们就会以为迭代会议开得太累，确定不是长久的法子。若是团队能在计划会议以前作一次提早的沟通，这样团队会提早把本身的想法告诉PO，PO也能提早想好抉择故事的业务。如此一来后来的迭代计划会议确实高效多了，还可以节约下来时间提早作一些功能设计。

 

    PO为了把故事讲明白，确定提早都把全部的故事都想过一遍，流程是通的，也不会存在相互矛盾。PO有一个本身的用户故事地图，而后把故事地图中的故事按优先级放入Product Backlog排好顺序，从Product Backlog 进入迭代的故事列表就是Sprint backlog。PO必定不能拿出本身都还没弄明白的史诗级的故事拿进Spring backlog给开发团队。

    计划会议的流程是这样的，PO把故事列出来，能够在白板上贴卡片，咱们直接用的leangoo，一个电子版的看板。而后PO会一个个讲解这些故事，讲完一个故事，SM就会让团队成员提问，若是没有问题就开始估点，估点用扑克牌。如今摆在PO面前最大的问题就是故事怎么讲？你们以为讲故事可能很容易，其余没那么简单，为何了，由于PO和开发团队不多是站在同一个频道上思考的，PO常常是跟市场、客户、老板打交道的，从他们那里获取到产品的需求，因此他讲得更可能是这个功能的重要性，这个功能的价值，而开发人员是跟机器打交道更多的，他们更多的是站在技术层面如何来实现这个需求，因此PO若是讲的时候越偏向于实现方式上面，开发人员就更容易理解，才会以为这个故事符合他们的味口。

 

    我到目前为止还在纠结这个故事描述的方式和详细程度，我以为这个胃口确定是某个团队的胃口，不必定适合全部团队，只有团队之间造成一种默契，那么交流起来确定是事半功倍的，因此PO写故事需求，必定不要拘泥与某一种形式，必定得多尝试多思考。

    故事不要写太多的文字，写太多开发人员也不多会认真的去看，写太详细也不行，会让有些人产生依赖，也不本身思考。以前就有一个测试人员，一个小时就写了几十个测试用例，怎么可能这么厉害，后来一评审他的用例发现用例的内容都是成段成段从需求中拷贝过来的，一问他这段什么意思，根本还没来得及搞清楚。因此太详细就容易产生依赖，也浪费PO太多精力在文字工做上。太少了确定也不行，以前就见到过别的团队，故事就是一句话，做为一个用户，我但愿能有某某功能，以便于我某某方面会更好。这样的需求开发人员确定看着都是木的，就算你口才再好也难以有条理的把这个需求讲出来，就算讲出来了，开发人员也不必定有条理的接收了，开发人员确定以为你至少有张图吧，对着图讲也好有个消化过程。因此咱们通常故事中的需求会涉及到业务说明、业务流程图、界面草图、验收条件，因此了很少很多刚恰好。

    一个完整的故事，首先在卡片上会对这个故事有一个总体的说明，好比“做为一个药剂师，我但愿能够查询到待配药或已配药的记录，以便于我对指定患者进行配药或取消配药的操做”。这是一个标准格式，做为...我但愿...以便于...，三个省略的地方，第一个说出了这个需求的提出者，第二个说出了他须要一个什么功能，第三个说出了为何须要这个功能，它有什么价值。而后在卡片后面咱们有一个连接地址，进一步来描述这个故事，这个连接里就包含了该有的业务说明、流程图、界面草图和验收条件。

故事举列：

US993 查询配药记录

一、故事

    做为一个药剂师，我但愿能够查询到待配药或已配药的记录，以便于我对指定患者进行配药或取消配药的操做

二、验收标准

    一、功能要求：（1）系统支持按收费时间，配药窗口，患者就诊卡号、门诊流水号、发票号查询当前登陆药房的待配药处方信息；（2）系统支持按配药时间，患者就诊卡号、门诊流水号、发票号、配药窗口查询当前登陆药房的已配药处方信息；

    二、录入约束：卡号、门诊流水号、发票三个检索条件在同一个文本输入框内录入；

    三、交互要求：（1）若是系统参数设定的是自动或手动配发模式，而当前用户未指定当前工位对应的配药窗口时，系统会自动在右下角弹出提示，要求用户设定当前工位对应的配药窗口。（2）全部功能按钮上要求有小图标标示做用。

    四、执行结果：（1）查询到的结果必须与界面设计的内容一致，与后台数据库中的归档信息一致；（2）查询到的结果集必须按配药窗口号，患者挂号序号、收费时间（配药时间）依次降序排列；

三、需求说明

    一、待配药界面

    二、已配药界面

    敏捷开发系列文章目录