分享专家： Lucy Liu   Scrum Alliance 认证敏捷团队教练CTC  大家都说现在是VUCA的时代，变化及不确定。那么敏捷Agile，能够更好的应对变化及不确定性，聚焦客户价值，快速的迭代反馈，持续的改进，让人们保持较高的热情投入到工作中。这也是二十年来在IT领域中敏捷盛行的原因，这种趋势在逐步的扩大到传统企业的转型中，汽车制造、快消品、金融等，而且势不可挡。在这些企业敏捷转型中，有一个角色起到了非常大的作用，它就是敏捷教练。据说在国内一份今年的IT行业薪资调查中，敏捷教练高居榜首。今天我们不讨论敏捷教练能够给企业带来的价值，而是来看看敏捷教练的成长之路，或许可窥见它能提供的价值。 2020年，对于我的敏捷之路，是非常关键的一年。我拿到了Scrum Alliance的团队教练，当时是国内的第四位，具备认证Certified ScrumMaster (CSM) 和Certified Product Owner (CSPO) 的资格。这对于我来说，是非常大的肯定和里程碑，也支持我继续走在这条并不好走的道路上。 在转做敏捷教练之前，我在大外企做团队经理，感觉各方面挺不错。但也有对职业发展的忧虑，不清楚自己的下一步去往哪里。在花费了很多精力优化团队流程，提升质量的过程中，偶然接触到了敏捷，申请在团队中尝试。那是在2012年，也是我接触敏捷的开始。边尝试边学习，把一整个业务线做敏捷转型，前前后后做了5年。直到2017年，因为扎实的敏捷转型经验和对敏捷的热情，有机会转做公司亚太区的敏捷教练。一次机缘巧合，在全球敏捷大会中，认识了CST老师，开启了敏捷社区的参与。在那次国际大会中，认识了很多有名的敏捷教练，听了很多经验分享和讨论，收到很多的启发。从那时起，正式开始了专业的敏捷教练的历程和精进。敏捷教练8项必备技能1、团队级敏捷教练的经验        扎实的团队级敏捷教练的经验，接触不同类型、背景、成熟度的团队，给与不同的指导和带领。几十个团队的经验积累，可以大大提升专业技能，应对不同的情况。这部分我是自己真正动手参与的，积累的。我不能确定是否有捷径可以走，但这部分的积累在之后教练工作中一定用得到。 2、敏捷领导力        敏捷转型中，最难的是哪部分？我认为是领导。如果领导是支持的，是有强大意愿推动的，那么就有了很好的基础去做转型。那么敏捷教练需要什么技能？很好的沟通能力，向上管理的能力，影响力，教练能力，可以让老板支持又有一定的耐心，一起朝着目标前进。3、引导技能        初级的敏捷教练，我认为引导技能的需求高于专业教练技能。引导技能在很多场合都可以应用，明显的就是各种会议中，提升效率，激发意愿。如果再熟练掌握心法，在对话中也是可以应用的。我学习引导至少有十年的时间，一开始是自己查一些资料和书籍，边学边用，已经觉得很有效果。后来师从Pepe Nummi，是芬兰引导协会的第一任主席，中正又谦逊，让我的引导技能精进不少，也拿到了Pepe在国内引导课程的认证讲师资格。4、培训技能        这个在我转做教练之后，还真是花费了一番功夫。之前也是做过团队培训的，但连续2天的专业培训没有做过。第一次讲完，觉得自己嗓子都冒烟了，整个人也超级疲惫，内容中也有不满意的地方。另外一位伙伴帮忙把所有上课的过程都录制下来，再基于反馈的基础上回看和再次调整，终于可以把所有的敏捷相关的课程高质量的交付。还专门学了一些发声技巧，结合一些引导技术在课程中，效果也越来越好。5、专业教练        职位是敏捷教练，所以有个教练在其中。大家最常见的是运动教练，那么为什么一个足球队可以赢得胜利？队员是一方面，也要有好的教练。教练可以专业上给与指导，经验上分享，战术上制定，情绪上纾解与鼓励。。。最重要的，教练聚焦于成果和未来，这也是与心理咨询有很大不同的地方。在专业教练上，我没有一开始就选择国际教练联合会ICF的专业课程，而是选择跟Vernon Stinebaker 老师学习，老师是PCC。在老师的指导下，我系统的学习了Scrum Alliance的Path to Coaching的项目，并且老师也对我进行了一对一的长时间的指导。另**加了Coaches Rising这个国际组织提供的教练相关的学习，这里面的老师都是国际知名的，比如前面提到的《领导者的意识进化》的作者Jennifer等。经过大量的练习，基本达到了ACC的专业教练水平，顺利通过了Scrum Alliance关于这方面的考核。那么今年，我又选择去参加专业教练的系统学习，可以在这方面继续精进。6、自我觉察        在最近的两三年，因为专业教练的学习，我发觉自己更加的敏感。发生一些事情，或者脑中有一些想法时，可以去看自己思考的逻辑，自己的着眼点，为什么会产生这样的情绪或者想法？这种想法有可能是不对的吗？对方的出发点是什么？即使我不同意，能否真心感谢和接纳？怎样改变自己的言语创造更好的协作空间？这方面的觉察，不只在工作中得到应用，在个人的生活中也是非常明显的。以往可能一说到什么就生气，现在自己能察觉到模式，那么就可以有效管理和改善。这也打开了自我意识进化的可能，察觉自我的模式，打破旧模式，建立新模式。过程是漫长的，但转化是必然的。7、持续学习        每一位敏捷人，都充满了向上的力量，不管是思想还是行为上。一直都在保持着持续的学习，各种的课程，会议，分享等等。当然我也不例外。每年都在持续的提升自己，今年主要是在专业教练和领导力方面投入很大。8、敏捷社区的投入        我比较明显的是对建设敏捷社区的投入。不只是组织各种的全国敏捷大会，也会有各种小的分享。今年组织了每周一次的教练诊所，希望能提供切实的经验给到敏捷的实践者。我的绝大部分工作外的时间，除了学习，都是在建设社区的工作中。这当然也给了我无穷的回馈，获得社区伙伴的支持和认可。我经常说社区给我力量，所以我也很感恩社区！这可能也跟我的性格相关，外向型性格的人，需要从周围环境中获得反馈和能量。一起打造好社区，是我们每一位伙伴应该做的，因为社区是能让我们长久良性发展的土壤。 想要做好一个教练，上面够了吗？这只是开始，还有很多内容需要修炼。比如创新，绩效体系，大规模的敏捷实施，传统领域的转型，组织进化。。。最后 当把自己的能力逐步提升，扎扎实实的走好每一步，一定会给组织提供更多的价值，也能够让组织认可这种价值。教练这个职业，是一个需要累积的职业，但也是一个长青的职业。很多事情都可以人工智能取代，但跟人打交道的事情，应该是最后被攻克的堡垒吧。一起加油吧！愿我们都能拥有自主选择的权利--- 这也是我一直追求的，自己手握选择的权利！愿我们每一位伙伴都能活出自我，心里有火，眼里有光！ 

背景在一次DevOps线上活动的提问环节中，有这样一个问题：“我们公司刚刚完成了DevOps转型，搭建了一条流水线，流水线确实让我们部署上线的效率提升了，但是也更快的让客户当上小白鼠，因为我们让问题更快的暴露出来了……”可以想象，一个开发人员开心的点了一下流水线的启动按钮，然后就开心的下班了，然后用户看着屏幕的404，然后就没有了然后（坏笑）……其实这真不是开玩笑，如果将项目中的流水线发布权限下放给了开发，那么404真的就是很现实和普遍的问题，因为很多开发认为自己的工作就是开发。像这样的坑你是否也掉进去过，我们一起基于此，来看看什么样的流水线是不坑人的吧。问题分析这些年来，DevOps已经逐渐的深入到软件企业中，尤其是一些互联网的项目中，需要更快的适应市场的变化迎合用户的需求，传统低效的方式来部署生产环境已无法存活， DevOps的流水线（部署流水线）也应运而生。然而在企业追求高效的同时，往往又引入了新的问题——高效的将bug展现给了用户。项目开发的前期，代码都是比较简单的，开发团队的人员也比较少。但慢慢随着时间的推移，代码越来越复杂，团队成员越来越越多，经手变更的也越来越频繁。一旦出现了问题，作为一个开发人员往往首先会想到的是——快速修复上线。DevOps在速度这点上确实帮了大忙，经历过传统部署发布的同学肯定深有体会。但是这样往往却又伴随了新的问题——“打地鼠现象”。何为打地鼠现象? 简单的说，就是一个问题你修复了，可能又会蹦出来几个新的问题。长期下去，不仅开发团队压力大，客户更是成了“小白鼠”。其实，这并不能把问题归结到部署流水线身上（无辜躺枪），借助流水线的快速发布，只是将问题更早的暴露出来，其归根结底上，问题还是出在质量上。那么，我们就不得不谈到——质量内建。戴明（William Edwards Deming）曾提出“问题发现得越早，修复的成本越低”，有数据指出85%的缺陷都是在代码编码阶段引入的，然而大部分的缺陷并不是在编码的时候发现的，而是在之后的测试阶段发现的，甚至是已经上线后。而且随着越往后发现缺陷，修复的成本也越高。来源《Applied Software Measurement:Global Analysis of Productivity and Quality》按照STICKYMINDS网站上上的一篇名为The Shift-Left Approach to Software Testing的文章中所给出的（如上图），假如在编码阶段发现的缺陷只需要1分钟就能解决，那么单元测试阶段需要4分钟，功能测试阶段需要10分钟，系统测试阶段需要40分钟，而到了上线之后再发现可能就需要640分钟来修复，这可以说是很难让人接受的，所以质量内建是至关重要的。在质量问题上，当然离不了我们老生常谈的开发阶段的编码规范、重构、检视等活动，这里不做叙述。随着DevOps的引入，我们需要将质量内建，加入到DevOps的各个环节中，而部署流水线就是贯穿这些环节的重要工具。某种程度上说，部署流水线的质量基本上决定了软件质量——是带伤上阵还是安稳的睡大觉，部署流水线是关键。那么如何算是一条不坑的部署流水线呢？解决方案测试左移（Shift-Left testing）如上面所提到了，在开发完成后，越到生命周期的后面修复的成本越高。那么基于这样的情况，测试应该尽早的开始。在传统的开发周期中，问题都在什么时候发现的呢？如下图所示：来源《Applied Software Measurement:Global Analysis of Productivity and Quality》可以看到传统模式下，问题很少会在开发阶段发现，而现在提出的测试左移，就是在要在开发阶段尽可能的发现更多的问题，而避免问题被发现在之后的阶段。这也就是我们搭建一条不坑的流水线最基本的理念之一。一般来说，在流水线的构建阶段我们会加入静态代码检查，比如使用Findbugs、Sonar等。可按需自行设置是否随代码提交而触发检查（推荐），或伴随持续集成的工程实践开展，可一天一次或多次，这就保障了不会掉进最基本静态代码层面的坑。此外在流水线的设计上一定要有API、UI等自动化测试。一般来说，可按部署到不同的环境，对应创建不同的流水线阶段，如集成环境有对应的流水线的集成阶段，测试环境有其测试阶段。当部署时，就可以在对应的阶段中加入所需要的测试活动。如当开发人员修复某一个bug后，想要保证其他功能的成长，可以通过在流水线的自测阶段通过加入API的测试等。总结来说，就是在流水线的构建阶段加入静态代码的检查，在部署阶段加入自动化的测试活动，以保证代码的质量和功能的可用。质量要求在质量建设中，不能仅停留在质量管控的基本要求——有，还要注重质量的高低。因为某种意义上来说，较松的管控等于没有，这也是最坑的地方——有等于没有，试想如果流水线中只有某个API测试的情况，那么验证的基本就是这个服务有没有成功启动而已。那么，这就需要加入一个质量阀值的要求。质量阀值的高低是一个衡量质量高低的重要标准。这个阀值可以是接口覆盖率达到多少，也可以是静态代码检查出来问题的数量等。一个严格的质量门禁可以说流水线完成后发布上线的定心丸，这也就可以用来解决了上文提到的“打地鼠”现象。一般来说，接口测试的覆盖率建议达到百分之百，而考虑单元测试和接口测试某些程度上的重复以及UI测试的ROI等因素可按需进行配置，因情况不同这里不做叙述。对于代码检查来说，也可设置某一个数值作为阀值，这个数值可以按照某种规则设定。如一般问题记1分，严重问题记5分，安全问题记8分等，当检查后所累积的数值超过10则不能发布或进入下个一个阶段，当然数值越低越好，具体设置（代码检查的维度不再此叙述）也需按实际情况而定。此外，还可以考虑如开源第三方jar包的扫描、安全漏洞扫描等活动。如果考虑划分的更有层级和模块化，相对于接口测试或静态代码检查的质量建设，扫描的可以单独作为一个阶段按需设置。总结来说，质量建设按照项目的实际情况来设置，而且对于团队来说，质量永远不仅仅是某一个人或团队的事情，而是所有人的事情。相对于质量的坑来说，意识上更是我们应该避免掉进的坑。如了解更多请访问华为DevCloud流水线的内容，详见附录。这里提到了意识，意识是关乎人的主观性层面的了，那么应用在流水线上，其实也是需要考虑的。诚然有些时候我们依赖于机器和自动化，如上面说提到的接口测试、安全扫描等。但是也不能完全依赖于自动化，比如我们也需要人工的代码检视活动。这在搭建流水线的时候也可以考虑到把人工环节加入到其中，比如在发布到生产环境的阶段增加一个发布看板，其中包含了是否有人工代码的检视以及检视出来的代码的质量的阀值或要求等。综上，一条流水线除了必须的、按需的自动化+人工以外，还需要在实践的过程中不断的总结结合自身特点加以定制，然后才能放心大胆的点击“启动”而不被坑。最后引用姚冬老师文章中的一句话“流水线确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全的部署到生产环境。”这也是笔者非常认同的，也相信搭建实现这一目标，提供这能力的流水线才能更好的实现持续交付，配合好我们的DevOps转型。参考附录测试左移以终为始，再谈持续交付流水线DevCloud的HE2E DevOps的流水线构建博客

引言：在“DevOps能力之屋（CapabilitiesHouse of DevOps）”中，华为云DevCloud提出（工程方法+最佳实践+生态）×工具平台=DevOps能力。华为云DevCloud将推出“DevOps on DevCloud”系列，针对DevOps领域场景，阐述该场景在华为云DevCloud上的实施方法与实践。在敏捷项目中，用户故事（User Story）是产品团队用来描述用户需求的主要方式。每个用户故事是小的、独立的行为，最好可以在一个迭代中增量式实现，并为最终用户提供价值。Bill Wake提出的INVEST模型，描述了良好的用户故事应该具备的特征，是用户故事应该遵循的原则：•     Independent：独立性•     Negotiable：可协商性•     Valuable：有价值•     Estimable：可估算性•     Small：短小•     Testable：可测试性将业务特性分解成为符合INVEST模型的用户故事，成为每一个敏捷团队的必备技能。LeffingWell在《Agile SoftwareRequirements 》一书中提出了分解故事的10种方法：•     Workflow steps•     Business rulevariations•     Major effort•     Simple/complex•     Variations in data•     Data entry methods•     Deferred systemqualities•     Operations •     Use-case scenarios•     Break-out spike不少人经常会说分解用户故事在增量式开发中既是艺术性又是科学性工作。敏捷产品团队可以参照10种方法进行故事分解，并使之尽量符合INVEST原则。然而敏捷产品团队如何在软件交付中记录故事分解方法，以更好地分享方法或者事后回顾改进或者统计分析呢？当然比较好的方式是采用敏捷项目管理工具，例如华为云DevCloud的项目管理（ProjectMan）。在华为云DevCloud的项目管理中Story并没有缺省字段来记录分解方法，因此需要通过“Story设置”特性来自定义此字段。用户可以在项目中通过“设置”-“项目设置”-“Story设置”-“字段与模板”进入工作项模板页面，如图所示：在工作项模板页面，点击“编辑模板”，并在字段配置处点击“+新建字段”，在下图中输入字段名称、字段类型以及字段选项等。将工作项模板编辑后进行保存。新建字段“故事分解方法”这样，在新建Story或者编辑Story的时候，团队成员可以记录故事分解方法。如下图所示在Story中记录故事分解方法随着敏捷项目的迭代进行，产品团队将不断积累此项目的故事分解方法，团队成员可以基于此数据进行分享与学习，将局部的、隐性的分解方法变为了全局的、显性的分解方法。这也正是DevOps三步法（Three Ways）在持续学习与实验中提倡的实践之一“将局部知识转化为全局知识”。一旦在项目迭代开发过程中，团队积累了故事分解方法的过程数据，那么团队可以在适当的实际进行相应的统计分析。对于故事分解方法的统计分析，目前华为云DevCloud的项目管理的自定义报表特性尚未提供基于自定义字段的维度分析，产品团队可以使用工作项导出特性，将Story导出到Excel进行统计分析，发现分解方法的一些规律，可以指导产品团队更好地有重点地提升分解能力。

作者：黄药师（黄隽） 背景在某开发团队辅导的第二天，一个团队负责人咨询道：“领导经常管我要开发计划，我如何能快速的评估出预计开发完成时间呢，我们目前用工时估算，我听说过故事点估算，不知道适合吗？”问题分析从这个团队负责人那里了解到，领导一般在接到项目大量新需求时会问这个问题。领导需要做到“心里有数”，有一个预计的项目新需求完成时间。加上领导一直做传统的瀑布开发项目，他非常关心项目中远期计划，也就是我们通常讲的里程碑或关键结点的问题。团队目前使用敏捷开发方式初期，团队成员本身也对如何更快、更好地做好估算感到困惑，目前纠结是否应该采用故事点估算。从以上问题分析中可以得出：第一，团队对故事点不了解，需要学习什么是故事点；第二，解决如何快速提供给领导开发计划的问题。 解决措施解决问题我们来分两步走。首先解决不熟悉故事点的问题，先给大家介绍一下故事点的定义及特性。然后大家了解一下两层估算即产品待办列表估算和Sprint待办列表估算的简单区别，解决开发计划的问题。如果有时间，建议可以先看看上篇《如何估算第二篇：利用核心概念理解估算》了解估算的核心概念。然后再来看这篇文章效果更好。这篇文章主要讲故事点。具体的估算方法有没有比较好的实践呢？在《如何估算第四篇：利用2种常见方法做估算》中会介绍几种比较好的估算方法，包括：“计划扑克估算”、“敏捷估算2.0（Agile Estimating 2.0）”等。本篇仍然在为估算做技能储备（磨刀不误砍柴功），即明确什么是故事点。前面文章已经讲过估算的一个核心概念即估算相对大小，这个相对大小我们用故事点为单位。工时和理想人天相信大家都理解，不做过多解释。在这里着重从故事点的定义、故事点的特性两个方面解释下什么是故事点，然后解决给领导提供计划的问题。故事点的定义故事点是表述一个用户故事，一项功能或一件工作的整体大小的一种度量单位。当采用故事点估算时，我们为每个待办项分配一个点数。待办项估算结果的原生数据并不重要，我们只关注最后得到的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另一个估算值为3的用户故事的三分之二。团队不要采用100、200、300，而要使用1、2、3。估算结果是相对值，而不是绝对值。“当使用故事点来估算用户故事的大小时，并没有固定的公式来规定如何计算故事点的数值。故事点估算用于评估为了交付一个用户故事所包含的工作量（team effort），用户故事的复杂度(complexity)，风险，以及所有其他需要考虑的元素。——《Agile Estimating and Planning》, Mike Cohn.故事点的特性说明是相对单位它是一个相对单位。比如，不同的组织团队，对于同样的用户故事的故事点大小一般是不同的；即使同一团队，针对不同用户故事的故事点大小，甚至是针对同一用户故事的故事点大小，都允许是不同的。但同时提醒，不同团队不同用户故事的故事点的设定，有利于组织能力的积累和横向参考。不等同于工作量估算故事点估算不是简单等同于工作量估算。如Mike Cohn所描述，它包含工作量、技术含量、各方面制约等多方面价值因素。有时其他的这些因素，在故事点估算中占有比重会胜过工作量方面的考虑。考虑“完成的定义”故事点估算必须要覆盖直到实现产品待办项待真正完成的所有事项。如果团队的“完成的定义”中包括了创建自动化测试来验证这个故事（并且这是一个好主意）这个事项，那么创建这些测试的工作量也应该包含在故事点估算结果中。以上介绍，有些朋友可能会问：有些团队用工时（单位小时）来估算，不可以吗？上一篇文章末尾提到，有些较成熟的团队，也可以借鉴历史数据和经验，直接应用工时或理想人天估算也并非不可。如果一定要推荐工时（或理想人天）和故事点分别在什么时候应用比较好，那么我一般推荐在做产品待办列表估算时用故事点，而Sprint待办列表估算时用工时（单位是小时）。原因很简单，结合最开始团队负责人的问题，其实老板大多对什么时间点可以交付多少需求（用户故事形式体现）感兴趣。最常见的问题是：“这50个需求什么时间可以做完？”很明显，老板并不是在问本Sprint能做完多少需求，而是在问项目得有一个预计的时间点或里程碑。换句话说就是，需要对某个时间点可以交付什么样价值做出一个长期一点的预测。如果每个故事平均15分钟估算，那么50个用户故事估算需要50*15分钟=750分钟=12.5小时。显然估算所需要花费的时间代价比较高，ROI太低。如果采用准确度差不多的故事点估算，则效率会大大提升。前面提到过为什么故事点估算容易，这里不再重复解释。此时建议团队平均3分钟完成一个用户故事的估算，那么估算需要50*3分钟=150分钟=2.5小时。这样根据团队正常速率，就可以预计完成时间，回答老板的问题了。对于Sprint列表的估算，其目标更多的是要确定团队本Sprint要完成的工作量，故事点显得有点抽象。团队具体执行时，时间概念上有点困难，而小时数就容易得多。通常Sprint列表项也会比产品待办列表项少得多，所以时间上不会花费太多。另外，就Sprint列表中的工作项而言，它会是更具体的需求，通常会进行任务细化和“完成定义”，进而很清楚如何去做，谁来做。这些因素综合看，以工时（小时）来估算成为优势。参考附录1.      Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。

作者：黄隽（Charlie）背景很多团队在应用敏捷开发时，对估算经常感到困惑。这里所说的估算是指产品列表条目（PBI, Product Backlog Item）的估算 。比如，估算以什么标准进行？开发、测试的工作量都要估算进去吗？又比如，估算出了预计工时，但是实际工作中这个预计工时经常不准，为什么还要估算这个预计工时呢？还有，做估算管理时，实际工时也会经常被使用，但很多团队成员不按实际情况做实际工时的更新，它的意义何在？问题分析为什么做估算呢？在规划和管理产品开发过程中，我们需要回答一些重要的问题，例如：“将要完成多少个特性？”“我们什么时候做完？”在使用敏捷时，为了能回答这些问题，我们需要估算产品的工作量大小并测算工作速率。有了这些信息，用特性集的估值除以团队速率，我们就能推算出产品开发的持续周期了。从小目标来讲，做好了估算也可以很好的理解需求，帮助团队成员认领任务。换句话说，团队成员通过估算过程（持续沟通、确认）达成对需求的理解一致，明确完成定义是最重要的。团队之所以做不好估算，首先是因为没有足够细化需求，更不了解敏捷估算的几个重要核心概念 ，即：“团队估算”、“估算不是承诺”、“要准确，而不是精确”和“使用相对值，而不是绝对值”。其次是不了解估算的正确方法 。这篇文章主要解决因为不能很好地理解需求而估算做不好的问题，在这里可以了解下如何利用用户故事了解需求。解决措施估算有这么些重要的意义，以下关于估算的内容是针对认可估算有意义，但是做不好的情况下给予的估算解决方案。如何更清楚的了解和细化需求是第一步，细化需求和估算是一对儿不能拆分的“鸳鸯”。然后再学习准确的估算，解决估算的各种困惑。要想准确的估算，先要了解和细化需求，同时了解需求很好的一种描述方法，即User Story。然后了解故事点以及什么是估算及估算的核心概念。基于以上了解后再研究估算方法的实践，最后选择适合的估算方法完成估算活动。可以参考如下示意图便于理解。本篇主要介绍如何了解和细化需求，后面几篇会分别介绍估算核心概念、故事点、估算实践方法和完成估算等内容,即：《如何估算第一篇：利用用户故事了解需求》、《如何估算第二篇：估算的核心》、《如何估算第三篇：估算故事点》和《如何估算第四篇：常见估算方法》。如何了解和细化需求，要先从用户故事开始聊起。什么是用户故事？用户故事是可用于陈述业务价值的一种简便格式，适合各种PBI,特别是特性。用户故事的制作方式旨在帮助业务人员和技术人员双方都能更好的理解需求。一个编写良好的用户故事是敏捷开发的基础。编写用户故事的过程就是了解需求，一点点细化需求的过程。需求了解清楚了，一定程度上讲估算的工作就已经完成了一大半，在不了解需求的情况下，估算也是没有意义的。需求的了解是渐近明细的，很多情况下用户的角度看是一种情况，开发人员角度看是另一种情况，这种误解在需求了解阶段经常出现，如下图。理解需求误区图我们一起看看，为什么说用户故事写好了就了解需求了呢？一个良好的用户故事应该是相对独立的、详情应该是便于开发者和用户沟通的、应该对用户是有价值的、应该对于开发者来说尽可能的清晰以便进行估算的、应该短小的、通过预定义测试用例的使用确保它是可以测试的。以上的特点具备了，相信写出来的用户故事是在了解了用户最初的需求基础之上。其实，这些特点有一个名称“INVEST原则”，是极限编程（英语简写XP,是敏捷开发方法之一）中对用户故事拆分的指导原则。INVEST原则用于评估用户故事，也就是说，好的用户故事应该具备INVEST特性：即独立的（Independent）、可协商的（Negotiable）、有价值的（Valuable）、可估算的（Estimatable）、大小适合的（Small）和可测试的（Testable）。用户故事究竟是什么呢,如何才能写好用户故事？极限编程（XP）的创始人之一Ron Jeffries给出一个简单有效的方法来帮助我们理解用户故事。他将它描述为3C：卡片、会话和确认。了解了3C也就大概清楚了怎么样才能写好一个用户故事，以及为工作量估算做好基础准备工作。 卡片卡片非常简单，最初可以写在便利贴上，有一个通用的格式，如下面用户故事模板图，即写明用户种类（即用户角色）、这类用户想要达成什么（目标）以及用户为什么想达成目标（收益）。用户故事标题的命名也是有讲究的，在辅导团队过程中发现有些团队的用户故事名称不统一，容易对团队造成困扰。例如，有的名称太长，甚至是长长的一段话；有的太短，不能清晰的识别用户核心内容是什么；有的没有价值，就是普通的任务（Task）。建议采用统一的动宾短语写出较好的用户故事标题：用户角度描述从用户角度看到的功能。例如，查看详细信息、新增查询、删除货品等。系统角度描述从待开发的系统的角度要实现的功能。例如，推送合同信息、发送用户订阅信息等。当然，你也许会有个疑问。这些标题都没有主语，好像也不太能快速识别用户故事的核心内容。Of course，如果你想更清楚表达，也是可以加上主语的。比如，新注册用户查看详细信息、库存管理员查询商品号、HR系统群发助手发送订阅信息等。不过，更想说的是，更详细的信息建议在卡片内容中说明，因为里面写明了用户种类（即用户角色）、这类用户想要达成什么（目标）以及用户为什么想达成目标（收益）。用户故事标题还是以简单、明了为主。用户故事卡片模板图 对话在对话中讨论需求细节。开发团队、产品负责人（PO, Product Owner）利益干系人在对话中发现并探讨需求的细节。用户故事仅仅是进行此对话的承诺。用户故事的一大好处就是它能把关注点从写作转移到会话。对话开启了一个更丰富的信息交换与协作形式，从而确保正确描述需求并使每个人都能理解需求。对话不仅仅是靠口头交流，还可以而且经常借助于文档，也可得出可以记下来的一张用户界面草图或业务规则的一份详细阐述。 确认用户故事还要包含确认信息，也就是我们常说的接收标准（AC, Acceptance Criteria）。有了接收标准，开发团队才更清楚要构建和测试什么，产品负责人也可以确认用户故事的实现是否符合预期。这些定义的接收标准也可以看作是高一级的接收测试。当然，开发故事的时候不会只有这几个测试，这些与故事挂钩的接收测试之所以存在，是因为从产品负责人的角度看，它们是捕获及沟通信息、确定故事是否已经正确实现的重要方式之一。我们了解了用户故事和它的3C原则，现在来看看怎么写一个好的用户故事，来更好地分析和理解需求。我们知道了用户故事的模板内容，看着非常简单，然而越简单的东西，反而越容易让人放松警惕，然后照着模板内容写出来的并不是一个很好的能够理解需求的故事。举例，一个餐饮点评网站的用户故事可能会这样写：作为一个用户，我希望看到某个地址附近的餐馆的公正的评论，这样可以决定去哪里吃饭。其实，这就是一个典型的质量不高的用户故事。写出高质量的用户故事的关键在于是否能够准确地描述用户希望获取的价值。这个观点只对了一部分，就像上面的故事一样。大家可能会问，既然用户希望获取的价值都描述清楚了，为什么客户还不接受呢？主要原因是你高估了自己的理解能力和表达能力，同时也高估了客户的理解能力和表达能力。如上面提到过的理解需求误区图，客户的角度看需求是“6”，需求调研人员角度理解的是“9”，这也是常见的需求理解问题。再来看另外一个例子：作为一个在国贸工作，午休时间短，又追求健康饮食的公司白领，我希望看到某个地址附近的餐馆的客观的评论，这样可以决定去哪里吃饭。可见，第二个故事中，感觉好多了。仔细看看差在哪里呢？熟悉需求调研的伙伴儿们都知道，需求调研是从了解客户是谁开始的，需要弄清楚产品需要获得什么样的客户的认可和接受，利用“对话”原则，充分沟通。这个故事描述了用户的特征，站在用户角度思考，更能够提升最终交付物为客户接受的可能性。同时，还要定义清楚什么是“接收标准”，与客户确认清楚具体的条件。这个故事的接收标准可以参考接收标准参考内容图：接收标准参考内容图现在可以了解怎么写好用户故事，以及如何更好地理解客户需求了。对需求有了更好的理解，接下来需要再了解一下估算的核心，《估算第二篇：估算的核心》以便更好地完成估算。参考附录1. Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。2. Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。----------------------------------------------作者随笔作为敏捷推广者和马拉松爱好者，聊聊敏捷与马拉松。一个胖子想变成瘦子，方法很多，比如无氧器械、疯狂单车、要命波比跳，当然还有马拉松。近年来马拉松被炒得火热，引得大家蜂拥而至。马拉松看似简单，实际上一个优秀的跑者是需要长年的基础训练和日积月累的跑量。有些人参加拉松是为了赶时髦，全凭三分热度，急于求成。往往前者已达终点，后者却在半路怀疑人生，早早弃赛。敏捷转型就像马拉松一样：理论实践vs基础训练，稳定速率vs平稳配速，定期回顾vs适时补给，持续改善vs健康奔跑，团队稳定vs跑得长久，个人有所长，团队全功能vs个人跑得快，群体跑得远。如果没有夜以继日的“内功”修炼，想要一朝练成“碧海潮生曲”，无疑是天方夜谭，必以失败告终。—敏捷江湖桃花岛 黄药师附件：如何估算第一篇：利用用户故事了解需求V1.0.pdf[hide]链接: https://pan.baidu.com/s/1yTVQoyD3gblF5Z6e1Ht7cA提取码: dzjv[/hide]