需求分析

<article class=“article fmt article-content”><table><thead><tr><th>版本</th><th>日期</th><th>备注</th><th> </th></tr></thead><tbody><tr><td>1.0</td><td>2024.3.4</td><td>文章首发</td></tr></tbody></table><p>需要剖析是工程师的必备技能之一。咱们常说一些架构师多少多少牛逼，零碎设计的多好多好——而零碎设计的底座正是需要剖析。基于具体的需要剖析底座加上已知的业界实践下限，能力让咱们更好得去设计好一个零碎。本文笔者想基于程序设计以及生存中的例子，聊一聊需要剖析。</p><h2>开胃菜：让你导100个G的数据到线上，你会怎么做？</h2><p>这个能够说是一个比拟常见的面试题了。</p><p>小白工程师看到这个可能就比拟懵了，或者间接带入本人遇到的场景了。沿着这样的思路，显然很难让面试官称心。</p><p>略微老道点的工程师可能就会问：</p><ol><li>大略多久要实现？</li><li>数据是什么类型的？</li><li>可不可以丢数据？可不可以反复？</li></ol><p>下面这些问题其实是围绕着技术的点去询问的。和实在的业务场景还是有一点的间隔，这点间隔就是<strong>在业务需要到技术实现的剖析上</strong>。</p><p>所以这个时候就要和面试官做一个探讨：具体是什么样的场景，导100个G的数据到线上？或者说这100G的数据导到线上的用处是什么？</p><p>举个例子，商家侧有一个报表，外面有个指标的口径要变更，历史数据都要刷。那么就须要持续探讨：</p><ul><li><p>是DM层数据还是宽表、两头表的数据？离线还是实时？</p><ul><li>DM层的数据是否要思考以商家为单位or整体的原子性？不然商家看到数据始终在来回横跳，会引起报障，减少解释老本</li><li>两头表则须要思考变更时对外的可读性，比方50%的数据是新口径，50%的数据是老口径，那么上游的表这样去读数据是否会遇到问题？</li><li>实时数仓的话，大量数据的刷入要思考提早问题；有些数据引擎可能是HTAP，引擎的承受能力须要思考，数据热点的问题须要思考。</li></ul></li></ul><p>上述的探讨就会比拟贴近理论的状况了。产品给研发提需要，研发依据目前的状况去剖析需要，设计方案。当然在面试的时候面试官可能会诘问一些细节技术问题——比方数据热点个别是怎么去解的？</p><h2>生存中的例子：千万别既要又要</h2><p>在生活中，咱们常常会买货色。尤其是一些电子产品，大家都晓得越贵越好，很多货色垫起脚来够一下是够失去，无非就是钱包出点血。回头再感叹钱难赚屎难吃。</p><p>但我置信大多数人的钱都是一个子儿一个子儿挣来的，因而在这一节我想聊聊如何依据本人的理论需要登程，来防止花额定的钱——也就是如何基于理论需要登程去<strong>谋求性价比。</strong></p><h3>例子1：买冰箱</h3><p>买大家电这种，如果间接去实体店的话，很容易被导购忽悠买一些冤种玩意儿。在网上看销量吧，在网上适合公众（忽视了天文、寓居环境等条件）的未必适合你。</p><p>所以咱们须要确认本人的需要，比方搁置冰箱地位的大小、容量要求、估算、功能性等等。</p><p>举个例子，在杭打工人三口之家，会怎么选冰箱。从硬性条件来剖析需要：</p><ul><li>对应地位的大小，决定了冰箱的长宽高。</li><li>容量。一个人个别100L，如果存储量大的话150。这样算的话400高低个别够用。</li><li>功能性。得防串味吧， 不然夏天吃个腊肉味的西瓜多好受啊，所以至多是双循环系统。</li><li>不想手动除霜，所以必定买风冷的。</li><li>留神乐音问题，买变频的。</li><li>能效必定是要一级的。不然长此以往电费很难顶。</li></ul><p>这样根本就把本人的需要明确了，能够在这个框架上来精确的抉择适合本人的产品。</p><p>而后也能够依据以下的价格表，在购物时疾速定位到适合本人的那批产品：</p><ul><li>3000以下：主打经济。容量个别，个别都是单循环系统，能效也有差。</li><li>3000～6000：常见冰箱价位。容量下来了，双循环必须的，能效个别都是一级的。</li><li>6000～10000：面向要求较高的群体。零嵌、好看都开始有了。</li><li>10000+：面向土豪群体。好看、设计细节拉满。</li></ul><p>具体细节能够看我在语雀里写的洽购冰箱笔记。</p><h3>例子2：买保险</h3><p>买保险的人个别都是对于危险思考比拟周全的人。打工人最怕就是一场意外，导致家里积蓄全副花完，还失去工作，分分钟返贫。</p><p>那么保险应该选什么品种呢？应该买多少额度呢？</p><p>我来举个例子，还是以杭州打工人三口之家为例，男方是个程序员，女方在家带孩子：</p><ol><li>依据男方的身材状态、以及压力状况，思考配置重疾险（重疾险的适应范畴真的很小很小，买之前最好理解分明）。</li><li>医疗险必配，配置额度个别在50w左右（依据以往的教训来看，50w花上来人还没治好，根本也差不多了）。</li><li>意外险和寿险必配。意外险次要是意外大残、逝世的状况。寿险是避免全残、身故。额度倡议依据债权状况来配置——比方还有房贷200w，那就配200w的额度。防止出事当前，家里人饭都吃不起还要还贷，太惨了。</li></ol><p>因为配置保险往往是为了抵挡危险嘛，所以会依据理论危险状况，来配置适合险种与额度。千万别想把保险当“理财”来玩，保险公司的那帮人比咱们精太多太多。</p><h3>例子3：洗烘套装、洗烘一体机</h3><p>洗烘套装、洗烘一体机当初十分的风行。一些相干的外围参数我就不贴了，网上有很多，大家能够自寻寻找。</p><p>从需要登程，我认为烘干性能的存在是为了解决三种场景：</p><ol><li>所在地区、地位晾衣服常常不容易干：比方湿度高、阳光个别。</li><li>对于阳台有空间需要：自身阳台不大，人又常常喜爱在窗边。衣服晾满很煞风景。</li><li>这人懒的一批。就喜爱甩干完事，不喜爱晾衣服晒衣服收衣服。</li></ol><p>如果确实是为了解决这三种场景，那么确实能够思考购买洗烘套装or洗烘一体机。那么这两者如何抉择呢？从两者的差别就可以看进去：</p><ol><li>洗烘一体机在烘干上会花较长的工夫，超过洗烘套装</li><li>洗烘一体机外部容易攒毛，洗烘套装则不会</li></ol><p>听起来洗烘一体机被完爆啊。其实不然，因为洗烘一体机个别价格会远低于洗烘套装。所以如果你是偶然有烘干需要的，比方：</p><ol><li>该地区、地位某个时间段晾衣服常常不容易干</li><li>周期性犯懒or节日家里来住很多人</li></ol><p>这种场景下是十分适合洗烘一体机。但如果是高频应用烘干的场景且有足够的空间，更适宜购入洗烘套装。</p><h2>小结</h2><p>在本文中，笔者举了几个例子来阐明如何做需要剖析。咱们能够发现，需要剖析的思维能够用在生存各处。</p><p>在计算机系统设计中：</p><ul><li>设计者的需要剖析能力间接影响着这个零碎的上限。</li><li>设计者的眼界（理解到的业界实践：比方零碎设计TradeOff，常见实际与实现等等）间接影响着这个零碎的下限。</li></ul><p>同样，在生活中花钱买货色也是：</p><ul><li>剖析分明本人的需要能够买到更适合本人的品类。</li><li>理解相干品类的“外围参数”能够防止花冤枉钱。</li></ul></article>

洞察用户需要的过程和谈恋爱一样。你不能简简单单地问客户，你想要什么？你有什么痛点？这样的问法是无奈失去任何有价值的信息。这就好比谈恋爱的场景，如果你问对方想吃什么，大概率会失去“轻易”“都行”这类的答案，但如果你真的轻易找了一家店：“吃冒菜吧”，对方又可能会不称心：“算了，我最近不吃辣。” 轻易得来的需要不是需要，且客户给的需要就肯定是他们想要的吗？ 一、轻易失去的需要不是真需要客户之声经常被误会，认为就是间接询问客户须要什么、痛点是什么？这就像结尾你问对象想吃什么一样。如果真的依照客户说的去设计和开发产品，则节约了企业的策略资源，产品过期，造成巨大损失。 Sony在推出Boomboxes音箱之前，在思考产品应该生产什么色彩比拟适合：黄色or彩色？于是招集了七八个人组成无领导小组，进行焦点访谈。通过探讨，最终所有人都认为消费者应该更偏向于黄色。 会议完结后，为表感激，组织者让每个人都能够收费带走一个Boomboxes音箱，他们能够在黄色和彩色之间任意筛选，后果所有人拿走的都是彩色音箱。 如果Sony真的依照这个调查结果来开发产品，销量必定受到很大影响。所以不要听用户说了什么，而要看用户做了什么。 二、分清虚实需要，不做冤大头需要也分虚实。收集来的用户需要甚至可能不是用户的实在需要，因为用户有时也不分明本人到底须要什么。 世界出名福特汽车公司创办人亨利福特曾说：“如果我最后问消费者他们想要什么，他们会通知我要一匹更快的马。”如果真是这样，那汽车大王就不会呈现了。 福特为什么没有给用户一匹马，而是给了用户一辆车？因为在一匹更快的马这个外表需要背地，是更快、更舒服的出行形式，福特汽车显然是更好的产品。只有明确了实质需要，能力确定更好的产品方向，更好地满足客户。 三、如何辨别真需要和伪需要？用英文就能够清晰地区分：伪需要叫Want，真需要叫Need。Want的货色用户不肯定会掏钱，Need的货色用户肯定违心掏钱。所以辨认出Need的需要是须要优先实现和满足的，缩小或者不做What需要。 要想取得真需要，就要搞清楚用户要通过产品达到什么样的目标，产品经理须要跳脱既有的思维和主观的断定，同时也不能轻信用户间接反馈的解决方案，要一直地问为什么，去开掘背地真正的起因。对单个需要通常能够问以下问题，辨认出需要的不同，进而进行优先级排序： 需要强度：用户是否痛？有多痛？ 需要频次：多久痛一次？持续时间：是否继续地痛？广度：有多少用户有相似的痛点？付费志愿：用户为此痛点付费的志愿如何。开掘真需要的实践办法开掘需要的实践办法有很多，比方用户调研、数据分析、竞品剖析等等。其中用户调研蕴含外围用户反馈、问卷法、访谈法、实地调研。 用户调研要注意以下三点： 不要听用户说了什么，而是看做了什么。要看实质需要，而不是外表诉求。器重用户说的形容词，而非名词，比方“想要一匹更快的马”，外围诉求是“快”。那些未被提出来的隐性需要除了那些被说进去的需要，还有一些是用户也临时不晓得的需要。所以产品团队不仅要提炼用户表述出的显性需要，还须要开掘用户未提出的隐性需要。能够通过 5Why分析方法，挖掘出用户的隐性需要。 5Why分析方法，单来说就是对一个问题连着问5个“为什么（why）”，通过间断发问，逐渐深刻，直到确定问题的本源，也是咱们常说的“刨根问底”。 5Why剖析应用的大抵思路： 首先确认问题，分明形容目前景象。探讨为什么会有目前这后果。失去起因后，接着探寻为什么会有这起因存在。失去起因后，再往下诘问，为什么会有这个起因存在。不停往下诘问，直至失去最终起因为止。随着不断深入分析，咱们每答复一个“为什么”，就更靠近问题的外围。一旦咱们有了一个明确的答案，问问本人为什么这个答案是正确的。反复这个过程，直到咱们失去最初那个俄罗斯套娃式的答案，问题的根本原因能力逐步浮出水面，用户被暗藏起来的需要也就分明可见了。 结尾在剖析客户的需要的时候，要懂得忽视他们想要的货色，去探索其心田真正的渴望，如此能力给出更好的解决方案，或者说是用户真正须要的货色。与客户交换就像谈恋爱，你必须将心比心的感触对方的感触，身临其境的感触客户的环境与体验，才不被原始需要所误导，能力洞穿客户的外表需要，找到他们的实在需要，即痛点，发明出一个更有客户价值的产品。所以下次对象再说“轻易”的时候，可不能真的轻易了。

1 前言面对需要评审，无论是发起人产品经理，还是参加人研发、测试都是有苦难言： 在会议上，产品间接被研发工程师怼计划不合理，技术无奈实现。参加人员没有围绕评审会的指标去探讨而是衍生到其余问题，导致效率不高。需要评审会议顺利完结，但在理论开发中却一直发现需要破绽，导致不能依照打算顺利执行。怎么可能让需要评审更高效、保质呢？作为测试人员又如何在其中施展价值呢？依据本人的工作教训，下文介绍如何在需要评审中做到更标准，来缩小评审过程呈现的问题，以此进步需要评审效率、晋升需要评审会议品质，来营造一个比拟轻松的产研单干气氛。 2 什么是需要评审通过将需要规约文档公布给利益相关者进行查看，发现需要规约中存在缺点（如谬误、不完整性、二义性等）的过程。简略点来说，就是在产品布局完之后，把团队人员汇集一起探讨并评审计划的会议。如计划通过，则按布局的计划，持续往下施行；如计划不通过，依据意见进行改善。 2.1 需要评审的参加人员每个公司的团队构造不统一，但通常包含：产品经理、开发工程师（前端、后端）、测试工程师、设计（UI、UE）、需要提出方。 2.2 为什么要做需要评审产品眼中的需要，交互眼中的需要，视觉眼中的需要，开发眼中的需要，测试眼中的需要天壤之别,须要让团队中每位人员对需要有对立的理解，通过需要评审来拉齐大家的认知。次要作用是： 有助于团队中每个角色理解用户需要，了解产品需要的由来，思考需要合理性及用户体验感。对需要文档进行评审，尽早发现需要中的问题，缩小前期批改缺点的老本。使开发团队中每个角色对需要的了解保持一致，缩小了前期的沟通老本。沟通需要细节，确认需要是否能够实现以及实现形式，有利于测试人员对性能实现逻辑的了解，欠缺测试用例。确认交付内容和预期工夫。3 如何进行需要评审做好一场需要评审，大抵分为三个阶段：评审前、评审中、评审后。 []() 3.1 评审前3.1.1 做好产品基本功角色：产品经理 和业务方认真推演产品要解决的问题，深挖业务述求，置信本人的产品设计能力，业务方提供的产品计划能够作为参考，不能作为指南。充分准备需要原型和PRD，反复推敲产品计划，确保所有的性能点都能实现闭环，失常和异样场景都要思考。任何一个脱漏的场景，都可能成为评审会上的“雷点”，产品们须要提前扫雷。提前找到此我的项目对应的技术负责人，认真的和他们沟通你的计划和想法，技术的小伙伴们不是被动的执行者，让他们参加到你的后期设计中来，驱动技术前置。提前将残缺的原型和PRD发给相干人员，以便他们提前浏览相干文档，深刻理解需要，有疑难的点提前标注进去，不便在散会的过程中踊跃地去参加这个会议，抛出疑难点。3.1.2 技术人员提前染指角色：研发、测试，倡议提前2天 团队制订好标准，利用各自碎片化工夫，提前染指进来了解需要。后期理解过程中除了关注性能要求，还须要关注数据类型、接口定义、性能要求、安全性等，这个依据具体业务进行评估，例如高并发场景，频繁申请的场景等。同时还须要思考一些隐性需要。技术负责人能够前置到需要沟通和设计阶段，给产品经理提供必要的技术支持，帮助评估产品计划的可行性。3.1.3 提前进行会议邀请角色：产品经理，倡议提前1天 给出会议工夫、地点、预计须要工夫。一方面，这样能够让参加人员得悉你对整个需要评审会议内容的掌控；另一方面，参加人员能依据工夫安顿手头上的其余工作，以致于节奏不被打乱。 3.2 评审中3.2.1 节奏把控角色：产品经理 产品是会议主持人，那么天然就担当着会议节奏把控和主持的角色。当角色泛滥时，其实是比拟容易呈现探讨内容溢出的问题，大家一聊开就上头了，后果导致会议开了足足几个小时都还没有产生定论。需要评审中产品要做的第一件事就是把控整个会议的节奏，既要及时把聊得起兴的大家拉回评审中，还要尽量依照参会人的精力去做好节奏的布局，让整场会议高效而轻松。 3.2.2 情绪治理和争执解决角色：全员 很多产品都害怕需要评审，感觉研发、测试在找茬，有针对本人的感觉。这个时候最重要的一点，首先，做好本人的情绪治理，有问题抛出是坏事，阐明大家都听了并且在思考。其次，换位思考，尝试先依据对方表白的认识去梳理他的思路，而后用本人的了解复述一遍，看对方是否认可你的了解。接下来，再依据你的了解去进行判断并论述本人的观点，看是否可能失去对方的认可。最初，如果切实在会上没法沟通，那就告知大家：本人会先记录下待探讨的问题，会后再进行探讨，后续的议程持续。“下来再探讨”真的是一句解决会上抵触的万能金句。 3.2.3 关注解说办法和策略角色：产品经理 不要上来就讲计划，大家肯定会懵圈，集体总结下来，能够依照以下的步骤推动： 需要背景：传播本次需要的背景，为什么有这样的需要，解决了什么问题。需要价值：为什么要做本次需要，做完后会给产品带来哪些价值（例如：进步用户留存、进步转化率或者是晋升用户体验等)。需要概述：需要提出方想实现什么，形容该产品计划如何解决业务述求。计划详解：具体的进行产品计划解说，让与会人员都充沛的理解产品计划，判断是否会牵一发而动全身。倡议分模块解说，一个模块解说完后，能够略微进展一会，询问大家是否有疑难，并进行答疑（如果是一个比较复杂的问题，解说的工夫比拟长，能够思考会议后独自和相干的人员进行沟通）；会议中如果呈现一些本人未思考到的点，肯定要记录下来，会后进行欠缺。3.2.4 刻意关注、沉迷式参加到评审中角色：研发、测试 需要评审的时候不要在会议下面玩手机或者干其余事件，因为如果需要了解不粗浅，前面相干的工作就很难发展。需要中产品设计不合理、很难了解、逻辑有问题、以及可能影响原性能的中央，对于这些点咱们要抛出疑难进行廓清，从而推动产品进行批改，最終达成统一。 需要评审会上，前端、后端和测试别离都关注什么？ 后端： 关注计划可行性的评估，重点在需要逻辑可行性、技术难度、工作量和改变老本上关注需要逻辑的覆盖度，帮忙产品经理做好逻辑的查漏补缺关注研发过程中的实现危险前端： 关注需要场景及业务合理性关注页面款式交互，为产品经理提出一些更正当的款式交互倡议关注技术计划和老本评估，尤其关注新页面中交互与已有统一标准组件的评估测试： 关注需要的逻辑性及合理性关注需要形容的精确水平、是否排除二义性等关注整个迭代的品质危险及进度，保障交付的稳定性3.3 评审后3.3.1 评审会议纪要角色：产品 会议完结之后，的确能够长舒一口气，开始筹备下一阶段的工作了，但留神：会后还是须要做好 会议纪要、会议同步和后续问题的跟进。会议纪要次要分为三个局部： 待探讨：指会上的遗留问题待欠缺：指会上确认要改的问题，后续要欠缺在文档中已确认：指会上探讨得出要做/不做的论断的点3.3.2 待办项跟进角色：产品+相干人员 整顿会议中记录的问题，在原型和PRD中进行调整和补充，有需要的话，能够拉上相干的人员针对这些问题，进行二次评审。好的产品肯定得有项目管理能力，在整个开发过程中，肯定要定期跟进开发进度，防止需要延期或者需要缺失。另外，开发过程中，如果波及到需要的调整.肯定要在原型和 PRD中标记批改记录，并且及时告诉相干的人员，确保了解统一4 总结如何高效、保质、愉悦的进行需要评审，各角色业余能力是根底，但更须要大家相互配合，相互尊重，通力合作能力打造更好的产品。 作者：京东物流 王敏  起源：京东云开发者社区 自猿其说Tech

前两天咱们在做我的项目复盘的时候，发现其实在整个过程中还是遇到了不少需要变更的问题，不过还好咱们算是比拟圆满地解决了这些从天而降的问题。置信也会有很多敌人和咱们团队一样，常常遇到客户这边的需要变更，的确这是一个十分辣手的问题。不过在麻利项目管理过程中，咱们还是有一些办法能够解决需要变更这个问题的。 只管咱们对需要变更“疾恶如仇”，但毕竟，该面对的还是要面对的。 在 麻利项目管理中，咱们要如何应答需要变更的问题呢？ 一、设置Product Backlog与Sprint BacklogScrum框架针对需要变更，设置了Product Backlog（产品待办列表）和Sprint Backlog（迭代待办列表）。在每个迭代开始时，产品负责人须要在Product Backlog中，通过优先级排序来筛选、整顿出这一迭代的Sprint Backlog，也就是这一迭代须要实现的产品需要。也就是说，Product Backlog是一直变动的，而Sprint Backlog是以后迭代中曾经确定的产品需要，是不变的。这样就会保障需要的变更不会影响到以后迭代的产出。 二、做好需要排序设置Sprint Backlog就意味着咱们要做好需要排序，那需要的优先级由哪些维度来决定呢？ 一个维度是需要的重要紧急水平，比拟重要且紧急的需要要往前排，绝对不重要不紧急的需要往后排。如果咱们要交付一个电商平台的MVP版本，那下单领取的需要会比珍藏某一商品的需要重要的多，所以咱们天然须要优先解决下单领取的性能。 那 另一个维度其实是需要的明确性，因为在我的项目的后期阶段，客户需要其实也不是那么清晰明确。所以咱们要考虑一下优先做曾经明确了的需要，同时和客户一直地沟通确认，将那些绝对含糊、可能会产生变动的需要确定下来，而后再排进相应的Sprint Backlog中。 客户在形容需要的时候，咱们能够用极限编程中的用户故事实际，将需要以“作为一个<用户角色>，我想要<实现流动>，以便于<实现价值>”的模式进行表白，这样更有利于单方沟通、廓清需要。 三、对需要变更进行限度确认好Sprint Backlog后，原则上不容许再变更需要。所以这就要求产品负责人须要对Sprint Backlog进行负责，提前与客户进行需要的沟通、确认。 如果遇到必须变更、优先级比拟高且对迭代影响较小的需要，咱们能够将这个需要放入迭代中，而后将本来迭代中优先级较低的需要替换进去；如果遇到必须变更、优先级比拟高且对迭代影响较大的需要，则须要和客户同步并确认后，将以后进行中的迭代暂停，产品负责人从新布局新一期的Sprint Backlog。在这种状况下，我的项目团队和产品负责人要做好足够的应急预案，例如产品负责人要提前布局出接下来的几期Sprint Backlog，以便呈现需要变更时，更疾速地响应。“怅然面对需要变动，即便在开发前期也一样。为了客户的竞争劣势，麻利过程掌控变动。”麻利 项目管理的过程是一个动静过程，在这一过程中，波及客户、我的项目团队、利益相关者等多方因素，而且这些因素的变动会影响其余因素的流动。所以在变动不可预知的状况下，咱们就须要化被动为被动，踊跃应答我的项目过程中的各种需要变动。以进步客户的竞争劣势为目标，在变动中寻找解决的办法，寻求单方对立意见的达成，将需要变更的老本降至最低，实现提高效率与保证质量的对立。 往期文章举荐：如何无效进行回顾会议（上）？如何无效进行回顾会议（中）？如何无效改良回顾会议（下）？

在麻利开发中，采纳 SPIDR 框架中的 5 种办法能够很好地实现需要的垂直切片，将大的需要纵向拆分成小但有价值的、可独立交付的用户故事。 // 回顾「需要垂直切片」和「拆分第一招：SPIDR 框架」，请戳 如果需要拆分像切蛋糕一样简略 。 本期内容将持续揭秘麻利开发中的需要拆分全流程，倡议珍藏⭐先码后看。 需要拆分第二招：用户故事切分流程图听下来仿佛与「如何把大象放进冰箱里」有殊途同归之妙，但它并不是什么「废话文学」。 《用户故事切分流程图》（下文简称《流程图》）介绍了 9 种常见的垂直切分模式，并具体地阐明了每一种模式的具体思考门路和判断规定；此外，它还提供了许多需要拆分实战的细节倡议： 待拆分的需要必须是有价值的且尽量合乎 INVEST 准则（除了短小准则）；垂直拆分后的故事大小应该大抵相等，最好是团队研发速率的 1/10 ~ 1/6 。关注 LigaAI 公众号，回复关键词【需要拆分】即可获取中文版《流程图》。 《用户故事切分流程图》by Richard Lawrence | 起源：https://www.humanizingwork.com 一、 了解待拆分需要的价值在正式开始拆分需要之前，麻利团队应该花一些工夫梳理和确定工作指标，充沛了解工作范畴，比方波及的利益相关者、需要验收规范等等。其中，明确需要价值是最为重要的。 将研发需要拆分到用户故事，实质上是对交付增量做出的进一步细分。如果待拆分的需要没有明确的价值疏导，那么研发工作就极有可能进入谬误的方向或者「死胡同」，导致半途而废。 举个简略的例子：重构企业官网的用户注册页面。 在该形容下，「重构注册页面」到底是为了让网站管理者更好地治理注册信息，还是为了让访问者领有更好的应用体验？如果是后者，那么须要优化的「应用体验」具体指什么，是更好看好用的用户界面，还是更简洁的注册流程？ 用户故事的「WHO-WHAT-WHY」语言构造要求故事必须阐明需要价值，即清晰传递用户能取得的益处。这个标准，同样实用于待拆分的大需要。甚至能够说，不足价值形容的需要是有效的，因为研发团队必须知悉工作指标和需要价值，能力更疾速、正确地推动后续工作。 那么无效的需要应该怎么写？其实，只有对上述形容稍作改良，补充重要的价值信息，说分明「WHO」和「WHY」就能使其成为一条合格的待拆分需要： 【需要】重构企业官网的用户注册页面，以便让访问者疾速取得感兴趣的内容。 除了强调价值形容外，《流程图》还要求待拆分的需要要尽量合乎除 Small 准则外的 INVEST 准则，即待拆分需要应是独立的、可协商的、有价值的、可估算的和可测试的。 对于不满足此条件的需要，能够尝试将其与另一个需要合并，或者从新构思失去另一个需要，再将这个符合条件的新需要作为拆分终点。 二、 垂直切分的 9 种模式明确了待拆分需要的交付价值和工作大小后，研发团队可使用以下 9 种切分模式进行布局和拆分。 01 按工作流程步骤切分按照工作流程的步骤程序，将大需要拆分成一个个逻辑间断的、有独立价值的用户故事是最常见的拆分模式。在麻利实际中，构建欠缺、 周全的工作流程罕用以下两种形式： 先找出残缺流程的头尾环节，逐渐退出更多的两头流程和非凡案例解决；先用最简略的方法构建主流程闭环，即 Happy Path，再进一步丰盛和欠缺非凡状况和异样判断。在理论工作中，咱们能够借用高兴门路（Happy Path）示意最常见的主流程，是没有任何异常情况的胜利门路；用异样门路（Unhappy Path）示意异常情况的解决门路，它代表了用户没有依照操作预期顺利到达起点的各种谬误状况。 二八定律指出，最有价值的流程往往只占 20%，其余的 80% 通常是主要的。因而，遵循「局部到整体」的准则，先抓取最重要的工作流程，再逐渐扩充和丰盛需要的故事集是操作重点。 02 按用户操作切分当大需要与「治理」或「配置」等形容词相干，能够将其依照不同的用户操作切分成更小的故事。这里借用 CRUD 操作概念作为用户操作分类的底层逻辑是个不错的抉择。 CRUD 操作是四种基本操作的首字母缩略词缩写，别离代表了减少 Create、读取 Read、更新 Update 和删除 Delete。在需要拆分畛域，能够这样利用： ...

在上周的文章中，咱们理解了用户故事的 INVEST 准则，以及研发需要拆分的两个规范： 大需要拆分的起点是用户故事，而故事要能在一个迭代中实现；用户故事下的开发子工作应尽量满足 0/1 判断规范，且工作量倡议设置为 0.5~1 人/天。本篇内容，Liga 将进一步介绍需要拆分的两种常见形式和具体拆分流程。 一、 需要拆分的两种形式01 程度切片 Horizontal Slice如果将一个史诗级需要视作一个千层蛋糕，那么程度切片意味着将千层蛋糕逐层合成，每个人只能吃到其中某一层的滋味。 在传统研发工作中，人们通常会依照职能和组织架构，将整个需要横向地拆分成「每个职能小组的工作」，且每局部工作只被对应档次的成员所了解。例如： 工作 1：创立新的数据库表格 工作 2：创立传输协定 工作 3：创立 DAL 以拜访存储过程 工作 4：构建 UI/UX 页面 02 垂直切片 Vertical Slice需要的垂直切片则像是将大蛋糕纵向切分成一块块小蛋糕，每块小蛋糕都能尝到「千层」的残缺口感。 垂直切片要求将残缺需要分解成若干个小但有价值的、可独立交付的用户故事。 每个故事只交付需要中的局部价值，但须要每个切片始终蕴含残缺的开发架构，且能被小组的全体成员通晓和了解。 以「重构账户治理性能」为例，它能够被垂直切分成多个用户故事，交付多个价值： 故事 1：用户能够领有多个账户 故事 2：用户能够更换账户头像 故事 3：用户能够查看头像应用的历史记录 故事 4：用户能够增加邮箱作为联系方式 03 垂直切片更适宜麻利开发在之前的文章中咱们说过，麻利开发更实用于需要多变的、性能耦合度低的、价值可继续叠加的我的项目，或迫切需要推动市场反馈和验证的产品。点击回顾：麻利之道 | 麻利开发真的过期了么？ 程度切片将需要横向地拆分成了各个架构层中的开发工作。对软件团队来说看似清晰，但每个局部的工作并不能独立交付给客户，不同工作间存在很强的依赖性。 如果采纳这种不甚合乎 INVEST 准则的需要拆分形式，又想要试行麻利开发，就可能遇上许多问题： 难以对立工作指标：每个职能小组仅从本身具体工作登程推动工作，难以就「用户价值」认知达成对立，堆高团队沟通老本；优先级排序难度加大：麻利办法的外围就是继续滚动的优先级评估和价值排序，但横向切片带来的高耦合度，使得各项工作不仅有时序依赖，还难以量化价值和优先级，进而导致团队的交付速度降落，甚至会重大影响企业的市场竞争力；试错老本进步，项目风险不可控：因为程度切片的工作无奈独立交付，管理者和业务相干方很难在我的项目过程中依据已实现的工作判断推动方向的正确性，或者及时觉察架构中存在的问题。这不仅减少了开发团队的试错老本，更可能因为无奈响应市场的疾速变动，而承当更大的项目风险。为了防止上述种种问题，做到指标对立、灵活应变、升高试错老本、晋升交付效率，麻利团队势必要采纳全新的办法，突破组织架构间的「隐形墙」，更快地向用户提供价值。 比方说：将残缺的性能需要拆分成多个可独立交付价值的用户故事。这正是麻利开发中的最佳实际——垂直拆分。 二、 需要拆分第一招：SPIDR 框架麻利教练兼 Scrum 联盟的联结创始人 Mike Cohn 指出：“简直所有需要都能够通过五种办法实现拆分”。他用首字母缩略词「SPIDR」总结了这五种办法。 01 Spikes 探针Spike 探针，或称技术预研，通常指性能的小型原型实现，或是对新技术的调研和可行性评估。 探针法通常实用于需要不明确或太简单，团队须要更多信息以供决策的状况。通过技术预研充沛了解需要外延，疾速探知可能的技术计划，初步判断工作量，以反对需要的细化拆分。 02 Paths 门路如果残缺需要存在多个实现门路或场景（通常由 和/等/或 等形容词体现），那么拆分时不用遍历所有状况，只须要选取局部门路并将它们编写成用户故事即可。 ...

在上篇文章《怎么简洁明了地说分明产品需要？》中，咱们介绍了用于形容需要的两个「结构化语言工具」，别离是「工作规格书 Job Spec 」和「工作故事 Job Story 」。本篇文章心愿进一步跟大家分享： 语言工具三：冀望成绩 Desired Outcome如何串连三个工具？ 工具三：冀望成绩 Desired Outcome如果很纳闷「工作故事」中的 Expected Outcome 要写什么，别想太多，间接来看 「ODI 翻新流程 Outcome-Driven Innovation 」中的 Desired Outcome Statement。我感觉这是整个理论界的外围要害之一，有承先启后的作用，也给了用处实践（Jobs To Be Done，即 JTBD 实践）极大的差异性。 ODI 创始人 Tony Ulwick 可能比 Christenson 更早开始钻研、利用用处实践，他口中的用处实践，跟 Christenson 有个重大差别： 工作「就是」用户在特定「场景」中，能取得「晋升」。A job is the progress that an individual seeks in a given situation.在 Christenson 的版本中，他则说：工作「使得」（enables）用户取得晋升。由此可见， Ulwick 特地重视晋升，因而提出「冀望成绩」这个语言工具，并间接认定「晋升」能力代表用户需要。 上面这张图，简洁阐明了「冀望成绩」的构造： Ulwick 阐明 Desired Outcome Statement 是「用户定义的指标，让晋升变成可被掂量、被把握、被预测的过程」，必须透过访谈开掘用户期待的晋升，再转化成「冀望成绩」的语言构造。 换句话说，尽管咱们难以掂量体验自身（毕竟设计与美感带有主观成分），但能够掂量「体验带来的后果」。除此之外，掂量「冀望成绩」和「目前成绩」的差距，就成了 ODI 翻新流程中的要害办法。 在 Christensen 在《创新者的用处实践》中也提出相似概念。他认为，用处实践不仅改善流程精进的方向，也会扭转掂量功效的形式。它把要害的绩效规范从「外部的财务绩效指标」转变成「内部的顾客效益指标」。 我感觉下面两个说法太简短、太绕口，改用以下形式称说： ...

在《为什么咱们总是说不清「需要是什么」》中，咱们介绍了「需要的实质」，并大抵介绍了三个形容需要的「结构化语言工具」。这篇文章，心愿进一步跟大家分享其中两个工具： 工作规格书 Job Spec工作故事 Job Story工具一：工作规格书 Job Spec「工作规格书」是比拟残缺又简单的语言工具，实务中较少用到。响应后面「产生需要的过程」，《创新者的困境》一书的作者Clay Christensen 将工作界定为「用户在特定场景下想取得的晋升」，工作肯定和特定的情境脉络无关，他进一步说： 工作「使得」用户在特定「场景」中，能取得「晋升」。A job enables the progress that an individual seeks in a given situation.如果要记录一个工作，他提出了「工作规格书」这个语言构造，其实也是个「文件构造」： 用户处在什么「场景」中？想达成什么「晋升」？想要的晋升，有哪些性能面、社会面、情感面的工作？有哪些提高的「妨碍」？有哪些焦虑和妨碍？用户勉强承受哪些「不完满的计划」？咱们必须赢过哪些计划？如何定义良好晋升的「品质」？为了品质，用户违心做哪些「取舍」？如果咱们做完需要摸索、用户钻研，能够依照以上五个问题，做成一份 1–3 页的 A4 文件。因为这个构造绝对残缺、简单、不够简洁，所以更适宜以下情境： 当作「介绍用处实践」的工具。产品或钻研团队「交接、稀释钻研后果」的工具，先让读者看完较短的文字摘要，再进入各种 UX 工具、图表、影音出现的钻研后果，减速读者的了解速度。专案或产品启动时，先提供更稀释、更简短的叙述，而后提供前项摘要的连结，给「想进一步理解用户需要」的队友参考。工具二：工作故事 Job Story「工作故事」是目前最被宽泛应用的工具，但也蒙受很多用处实践研究者的批评，因为它适度简化，容易被误用。同时，提出者 Alan Klement 是个充斥争议的人物，因而得罪了很多用处实践的开创者。不过，Job Story 依然是个实用的语言工具。 上面这张图，简洁地阐明了 Job Story 工作故事的构造： 工作故事的格局，用工作故事代替用户故事。 这个办法进一步被 Intercom 发挥，他们进一步解释 Job Story 工作故事： When (Situation)：引发需要的场景I Want to (Motivation)：用户在场景中的抉择动机So I can (Expected Outcome)：在场景中的期待晋升而后，他们会用 1–2 页 A4，提交一个名为 “Intermission” 的文件，当作一份产品/性能提案。在这份文件中，其中一段就是 Job Story，要能在几百字内讲完用户需要。揣测 Intercom 之后就用这几百字的 Job Story 代表此产品/性能，在外部疾速解释用户需要、沟通开发目标。 ...

在产品开发团队的咱们，是否都遇过以下情况？ 每天面对超多产品反馈、需要申请，花很多工夫厘清、沟通？加入有数的会议，冒出各种需要，发散的无边无际？终于提出产品路线图，面对各方质疑，后果改到四不像？... 这些收集、整顿、协商需要的过程，是不是很令人头痛，又耗费咱们贵重的工夫？不仅难获得共识，咱们最怕的更是产出无奈推动功效？ 为什么需要形容这么难？到底卡在哪里？演绎出以下这几种情况： 情况一：形容需要时语意不清，没有厘清的过程，产生误会情况二：针对雷同的性能、接口、流程，因为每人代表不同用户，或遇到不同情境，提出相互独立的需要，产生抵触情况三：针对雷同需要，因为负责不同指标，或站在不同的解读角度，产生僵局 因为以上三种情况，导致咱们必须重复沟通，耗费很多工夫，也难以确立指标、推动功效。 举例 | 经营电商网站的团队探讨：如何优化商品详情页情况一市场 Abby：咱们要提供更多商品照片，我看电商网站的时候最爱看照片了。 语意不清：「商品照片」是指主商品的照片，还是相干商品的照片？为什么须要照片，能达成什么成果？情况二工程师 Bob：放大图片的接口也很难用，点击图片还另开分页，又不能切换图片。图片设计师 Cindy：但我感觉是排版有问题，很难找到信息，令人怄气，我敌人因而罗唆不买了。图片客服 David：可是 ，顾客说「商品评估」最重要，又说咱们的评估性能很难用，不能筛选评估。 情境差别：同样针对商品资讯页，在「什么情境」，感觉放大照片、或产品资讯、或商品评估，很难用？情况三市场 Eddie：我感觉最重要的是升高跳出率，因为这是站上流量最高的页面。图片工程师 Fiona：咱们不是有首购优惠吗？能够在商品页上强调，吸引顾客购买！图片业务 Greg：对对对，卖家始终跟我说「优惠券性能」很重要，心愿显示各种优惠，在商品旁边。图片工程师 Henry：如果能够让顾客分享优惠给敌人，说不定还能带进更多流量！图片市场 Iris：说到分享优惠，购物季要到了，能够实现「分享优惠」和「赠送购物金」的性能吗？ 指标或角度差别：同样针对商业需要无关的「优惠」显示，但各自期待达成什么指标？这些指标别离遇到什么挑战、哪些限度？如何改良？晓得这些问题后，咱们该如何致力，朝什么方向改良呢？ 面对情况一，咱们心愿：升高「形容需要」时「语意不清的状况」；面对情况二，咱们心愿：升高「沟通需要」时「被本身立场、情境侷限的状况」；面对情况三，咱们心愿：升高「提出需要」时「遗失或误会个别指标的状况」。如果有一套语言构造，除了让咱们朝以上方向改良，还能额定产生以下成果： 缩小建设办法时破费的工夫或遭逢的排挤，融入现有办法，相辅相成；缩小叙述需要时破费的工夫，口头沟通时可稀释成 3 句话，文字沟通时可稀释成 1 页 A4 文件；缩小依情境重置沟通素材所破费的工夫，能够有弹性的重组、合并、拆分。那是不是很令人期待呢？ 为了介绍这个语言构造，咱们先回顾一下「需要」的实质。 需要与设计的实质援用 《设计思考怎么扭转世界? 》的这段话： 设计就是「现况」到「指标」的过程。在这里我为了好记，简略的说，设计就是 A→B如果咱们认同以上这段话，那么反过来说： 因为「使用者处于一个情境」，进而「心愿达成某个指标」，所以产生了「需要」先有「产生需要的过程」，咱们能力「捕获需要」，并根据需要来设计。合乎「需要驱动设计」的「用处实践」，基于一个重要的假如： 人是「指标导向」的行为者，而「情境」会影响指标，但「伎俩」并不会为了捕获、形容需要，咱们基于以上假如，产生了各式各样的工具，都为了达成以下子目标： (A) 升高团队「了解顾客情境」所「破费的工夫」或「认知门槛」(B) 缩小团队「形容指标」所「破费的工夫」或「误会的状况」(C) 升高团队「沟通产品计划」所「破费的工夫」或「误会的状况」(D) 升高团队「验证计划」所「破费的工夫」或「经济老本」举例来说：用户旅程地图、用户画像、故事板、同理心地图、价值主张画布等等，多少都心愿能达成以上子目标 (A)、(B)。而辅助产品设计与开发的工具中，PRD、用户故事、用户流程图、线框图、流程图等等，都心愿能达成子目标 (C)。 若咱们野心更大，心愿达成子目标 (D)，则须要众人通力合作，进一步导入原型图、可用性测试、A/B测试等办法。 而后咱们就发现，这也是一个「工具氾滥」的时代。咱们有「上千种工具」，帮助咱们厘清「上万种需要」，听起依然让人无奈？在工具氾滥的时代，咱们如何抓取「团队无限的注意力」，传播最重要的信息？如何给一个无效的摘要，疾速复盘上次的阶段成绩？有没有通用的框架，能够串连泛滥工具？ 终于，我意识了「用处实践」，以及一套精简的「结构化语言」工具。 结构化语言工具工具一：用处规格 Job Spec工具二：用处故事 Job Story工具三：渴望成绩 Desired Outcome 简略的来说，咱们能够这样使用三个工具：口头沟通时，先传播渴望成绩，再用用处故事补充，厘清指标和顾客需要；短文沟通时，以渴望成绩和用处故事结尾，放在 PRD 或产品/性能提案中；长文沟通时，把渴望成绩和用处规格融入现有的钻研报告中，搭配 UX 工具箱中「稀释研究成果的图表」，图文并茂、相辅相成。在渴望成绩、用处故事、用处规格中替换雷同内容，善用三者相似的构造，疾速重组、合并、拆分。 下一期，小编将持续为大家具体介绍这三个工具，并进一步阐明他们的神奇之处。 本文作者: Jason HOU文章起源: Medium 理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的sf账号-LigaAI~ 或者点击LigaAI-新一代智能研发合作平台，在线申请体验咱们的产品。 ...

在很多研发团队中，都会存在一个问题：研发团队超负荷运行，但如同仍然无奈交付一个令人满意的残缺性能。 人们在迭代跟进和日常站立会时的焦点，集中在看板和工作积压上。用户故事（或者说需要）的实现状况是整个团队关注的外围问题，大家的探讨集中在：怎么能疾速实现所有的需要，事务之间的依赖关系和程序是怎么的。 然而这是有问题的：团队会因为眼中只有树木而失去对森林的认知。咱们很容易遗记：用户故事只是实现一项打算所需的一个或一组工作项，而非价值自身。 但工作只有在交付了最终价值时才是重要的。 只见树木不见森林一个团队中，如果大家只关注本人以后的需要积压状况，是很难将本人的工作与公司的整体策略分割起来的。（就算有Okr也很难 by 小编） 我的项目负责人们常常发现自己处于一种艰巨的地步：看不到实在的进度看板。他们往往难以确切地晓得我的项目何时能实现开发，毕竟看板≠交付进度。有时候工作早就实现了，看板还停在todo阶段；有时候工作还没收尾，工作卡就曾经被拖到了实现列…… 于此同时，当需要被拆分成N个用户故事后，在迭代布局中产研团队常常会疏忽掉「胶水步骤」，即：在故事开发实现后到能够正式公布前的“最初一公里”，对产品性能进行润色、微调，使之具备更高可用性的步骤。 这就好比拼乐高。在一月份，团队达成了统一的指标：Q1咱们要建设一座神话般的城堡。接着，咱们估算了搭建城堡所须要的乐高积木的类型及数量（就像用户故事），并把它们都挑出来堆在房间里。而后，咱们开始疯狂拼装，并置信等到到三月快完结的时候，只有把各个局部组装到一起，城堡就能成型。后果是到了三月份，城堡各部件可能进度不一，其连接计划也并未真正就绪。 在这篇文章中，我心愿给研发团队提供一种新的思路：让阶段指标成为迭代布局的牵引绳。 在做迭代布局和跟进开发节奏的时候，这是一种奥妙但贵重的转变，让「阶段指标」去主导大家的交换。用户故事对于估算、调配、协调工作，依然是至关重要的，但整个团队都须要意识到，用户故事只是一种工具，是开发的过程，而不是交付的起点。 「故事」和「阶段指标」一堆“用户故事”是很难间接拼合成“产品价值”的。 如果一个研发团队认为本人的工作就是翻来覆去地“做需要”，那么他们将给其余岗位的共事（通常是项目经理或产品经理）带来相当惨重的累赘去填补空白、修改问题、适应变动。后果往往是我的项目会在“简直实现”的状态下停留过长时间。 当迭代布局会只是为了从积压列表里砍需要的时候，“咱们曾经决定要做某个需要”的想法会压过“咱们须要交付怎么的价值”。也因而，“打造一个绝对欠缺的性能并对客户公布”的指标就可能被弱化，甚至变得遥遥无期。 但「阶段指标」是不同的，它在有目的地叙述：“咱们想做这件事，是为了达到什么指标、交付怎么的价值。”「阶段指标」的外围信息是：专一于价值。 填补需要之间的空白，将成为每个人工作的一部分。团队成员将能根据价值指标，回绝不相干的工作，或者自在地做出正当的调整。这时，成员们能力感知到我的项目整体状态，并能对此持有更踊跃的态度。 咱们能够将「阶段指标」看做一系列小的里程碑，他们是产品实现价值交付的根本单位，也利于简略地向外部成员和内部利益相关者解释本身的进度。这些小的里程碑像是你要求团队攀登的山；当他们达到一个高峰时，团队能够一起庆贺阶段的胜利，并把眼光投向下一座平地。 为什么不必「史诗」？看到这里，一些相熟麻利概念的人或者曾经想问：这不就是史诗（Epic）吗？ 肯定意义上，是的。如果用法正确，史诗Epic的确能够用于标识「阶段指标」。毕竟史诗的定义就是：一个由故事汇合而成的可交付指标。 然而，在实践中，史诗或者被误会或者被滥用，导致它的概念变得含混不清。许多团队并不在用史诗治理指标，而是把它们视为执行打算。甚至因为史诗这个舶来词难以了解，导致很多国内的麻利团队间接跳过了这个概念；或简略粗犷地将其了解为产品模块、功能集等等。 在布局迭代时，大多数团队只是应用史诗作为项目管理机制的一部分，来过滤看板信息或显示甘特图式的停顿。那么问题来了：如果史诗中8个故事有5个是残缺的，这真的意味着咱们曾经实现了实现价值的63%吗？答案可能是否定的。毕竟在交付过程中必定会有一些额定的步骤或工作量。 因为在理论工作场景中，史诗曾经被谬误了解的这一特殊性；为了防止歧义，我决定用用「阶段指标」这个词，让文章更好了解。换句话说，当然，你的团队能够用史诗来治理阶段指标。 如何治理好「阶段指标」通过「史诗」或「阶段指标」来治理的团队，能够肯定水平上缩小额定工作步骤。 作为一名项目经理，我保护着一份动静文档，其中列出了咱们以后阶段所关怀的几个要害指标；同时，我还有一份将来的「布局指标」或者你能够了解为里程碑，以向业务方或客户证实咱们正在跟进他们的需要。 每个节点上都会形容咱们打算交付的价值；哪个我的项目或模块将更多地与指标相干；在必要时，提供一些具体任务（用户故事）的参考。 例如： 指标：与Sendrid集成，并应用它发送咱们的欢送邮件。这为将为营销部门自助编辑营销邮件模板奠定了根底； 阶段1、咱们将让Sendrid在开发和生产中工作；阶段2、决定模板将如何工作；阶段3、由营销部门自主设计咱们的第一个模板。在每次迭代中，我和我的产研团队都会回顾这些交付阶段，并依据须要从新确定优先程序。咱们常常把利益相关者拉到一起探讨，这有助于他们更好地参加我的项目过程。 迭代打算从探讨咱们的阶段指标开始，这样每个人都晓得“为什么”；而后咱们将围绕反对这些指标，为用户故事建设一个跟进看板。为了更准确地预估工作规模，也为了激励人们说出缺失的细节或提出更好的实现目标的办法，将小工作合成还是很重要的。 划重点！咱们只思考撑持咱们「阶段指标」的故事，而不是让积压决定咱们的工作。值得一提的是，放弃团队的良性运行也很重要也是一个要害指标，因而，团队须要就迭代完结时将朝着「阶段指标」后退多远达成统一。 一旦迭代完结，咱们应该依据最后的冀望评估理论停顿。咱们将此作为数据来从新校准咱们对下一次迭代的布局，并向利益相关者传播最新的状态。这种继续的可见性和反馈机制能够建设内外部相干人员的信赖和信念。 最初可能也是最重要一点：在沉重的积压中机械地“做需要”只会让咱们遗记最后的幻想。 咱们人类是善于和酷爱讲故事的物种，但所谓的“用户故事”并不能以这种形式激励咱们。只有当人们专一于指标，将工作视为有方向性的和局部性的过程，而非单纯的工作对象时，他们才真正被赋予了实现自我价值的能力和能源。 如果你想建造一艘船，不要怂恿人们去收集木头，分工，发号施令。相同，求教会他们向往广大而无边无际的大海。— 安托万·德·圣·埃克苏佩里 原文编译自：https://cgroom.medium.com作者：Chuck Groom

前言测试作为整个我的项目中的一环，在我的项目流程中起着不可或缺的作用。局部团队是短少项目管理角色的，这个时候，测试对我的项目流程的推动、我的项目品质的保障显得尤为重要。好的测试，能在整个我的项目流程中以QA角度做好项目管理和及时的危险预警，让我的项目如期上线且保障品质。业界始终强调测试前置，那么测试在我的项目中，如何依据我的项目状况做前置工作推动我的项目流程，让大家都开心工作呢？本文以本人所在的项目组为例讲述我的项目流程中的一些事，心愿能够与大家一起探讨~ 一、QA在我的项目中表演的角色【why】明确指标是什么：明确做这个我的项目的指标是什么，可适当依据指标对需要实现、我的项目品质、研发提测工夫点等做一些调节。 【when】我的项目的deadline：思考项目组的特殊性，咱们须要晓得我的项目须要什么时候上线，明确我的项目deadline，依据工夫节点制订适合的测试计划 【what】各阶段咱们须要做什么：能够重点关注我的项目流程中，QA参加与输入的环节。有输出才会有输入，所以输入的环节往往是须要QA破费工夫去思考的中央。 【how】遇到危险点时怎么做：测试阶段，除了QA环节的危险点须要及时裸露和push外，这个阶段研发和产品也在做一些工作。在我的项目流程治理中，作为最上游的参与者，须要关注这些危险点，及时裸露和push解决。 【who】QA、RD、PM 二、咱们面临的挑战2.1挑战点1.发版频率在排名第二，2021全年发版71次，相当于每周都有一个版本在进行迭代，疾速迭代的节奏， 对人效和团队协同效率要求高。2.整个2021年，研发人均bug数为123个，bug较多， 提测品质不高。为了不拉长我的项目周期， 保障较短的bugfix工夫十分要害，同时要思考如何进步提测品质。 3.整个2021年，测试人均提bug量最多，在我的项目节奏缓和的状况下，发现和提bug的效率必须晋升。 2.2对于提测品质针对上述挑战的内容，咱们能够看到提测品质上，咱们存在不足之处。咱们之前做过进步冒烟用例比例、冒烟穿插执行、工夫预估减少冒烟工夫等尝试，最初发现播种的成果无限。次要起因如下： 多方单干、我的项目有固定deadline：因为我的项目特殊性，局部需要是多方单干的模式且有固定的deadline，就须要我的项目尽快上线，在对我的项目效率有极高要求的状况下，咱们容许带一些层级深的bug上线，针对上线状况做hotfix。我的项目节奏缓和，需疾速迭代更新：现有研发团队是串行的节奏，能继续高效迭代，为保障我的项目节奏的稳定性，避免出现因一个我的项目周期拉的过长导致节奏错乱，咱们承受分步提测的模式，就有可能呈现冒烟性能不残缺的状况，导致提测品质不如预期。基于以上起因，咱们能够看到在品质与效率之间须要做肯定的抉择时，须要向我的项目效率歪斜，所以咱们既然无奈更好地扭转提测品质，那就去扭转咱们能扭转的。 三、面对这些挑战，QA能够做什么QA能够做什么让整个迭代周期变短，在bug很多的状况下还能疾速迭代且线上问题较少呢？先来看下咱们的我的项目流程： 从整个我的项目流程上看，可能与很多团队一模一样。在流程上，QA作为上游的一个局部，能够看到QA参加输入的内容其实有很多，这些局部就是咱们能够尝试去扭转晋升的点。那么咱们从这些输入内容看下，面对上述挑战，QA都做了哪些扭转以及还有哪些窘境。 3.1我的项目排期打算我的项目排期打算模板： 【when】我的项目排期个别是需要评审完后，依据需要拆分需要模块和开发模块。排期打算中，QA的工作：相熟需要，拆分需要模块，制订测试计划QA同学退出进模块拆解，能更好的理解需要，拆分的开发模块也能更快的晓得当有bug时，bug是属于哪个端的，提给哪位对应的开发。依据各模块的提测工夫和大抵开发周期，QA同学也能制订对应的测试计划。 【what】-- QA具体须要做什么 帮助开发拆分功能模块，确保模块都有对应的开发负责人确认我的项目deadline、开发总预计工夫和提测工夫3.2测试计划制订我的项目测试计划模板： 【when】测试计划个别在我的项目排期给出后1天内提供，后续依据排期动静调整 测试计划中，QA的工作：依据需要预估工夫和人力，明确测试环境与策略，制订正当的测试计划，预估危险 【what】-- QA具体须要做什么 1.拆分功能模块，模块明确好对应的测试。（蕴含用例编写安顿、一、二轮测试安顿和兼容测试安顿） 2.预估好我的项目的总体测试工夫和各轮次的测试工夫 3.一轮靠近序幕时，与开发明确好上预发工夫；二轮靠近序幕时，与开发明确好上online环境的工夫 4.如有数据配置项，二轮测试开始前与产品明确好配置所需内容和实现工夫节点 以上1、2两点尽早提供，其余可在对应工夫点给出。当然，如遇到需要变更、人力变更等须要及时提出和调整。　【how】-- 具体怎么做 依据开发排期，动静制订和调整正当测试的打算。 依据提测工夫，决定用例执行程序与调配：如下图拆分的测试计划，后盾配置（星火）与用户端提测工夫不统一，联合两个提测工夫点，咱们利用用户端提测前的工夫，先执行后盾配置的用例，这样即便是分步提测，咱们也能确保每次提测时测试资源能跟上。依据性能制订测试轮次对于骨干性能：须要屡次执行测试用例，个别制订三轮的测试，一轮在测试环境，二轮预发环境，三轮线上环境对于对内的、不影响用户应用的性能：制订一轮测试，在测试环境测一轮。比方星火等配置后盾是给经营应用的，做一轮测试，上预发后产品走查验证+配置内容即可流动类的性能：根据流动的复杂程度和应用频次，制订测试轮次。比方新年流动，是一次性的流动且流动工夫紧，评估后咱们在预发做了一轮测试就上线了，上线品质也一样较好。具体测试流程：流动类测试流程尝试依照模块、用例量与难度划分，制订每人每天用例执行指标一轮测试模块划分依据用例编写与相熟度划分履行穿插测试，防止因不相熟导致脱漏或效率升高 二轮进测试进行穿插，利用TC平台的工作指派，也能够分明看到组员的工作数量与实现状况。如下图，测试计划的拆解与人员调配，粗疏划分到每人每日的工作指标，且各模块的调配会进行穿插，一轮测试人员发现用例不欠缺或测试不不便的中央也即便提供了文档以便二轮人员尽快上手测试。 【小结】：咱们能够看到，调整测试计划的4种形式，次要目标都是通过这些方法去更高效地去实现测试工作，保障我的项目如期上线；更欠缺、全面地去发现bug，晋升我的项目品质。测试计划的正当调整调配，是面对我的项目过程中各种挑战的无效形式之一。 3.3jira定制化流程定制化的jira我的项目流程：版本公布治理三部曲： jira版本公布治理：从产品建设版本开始，到最终复盘，整个流程和数据统计都体现在jira看板中，不便对立治理我的项目进度主动同步：如下，我的项目组成员能很清晰的晓得以后我的项目进度，且版本进度每天都会主动在大群同步；完结的我的项目，也会依据我的项目状况主动同步复盘信息【小结】： 1.定制化的流程，让流程更加对立标准和智能化。 2.要害信息的及时同步，能缩小每日站会、信息同步会等反复会议，节约了工夫。各团队之前的合作更加顺畅，那团队协同效率和人效也就自然而然能进一步提高。 QA高效提bug、研发疾速修bug秘诀：2021Q1 效率工具的需要收集提效探讨中，提bug流程的优化倡议一一实现了，每个人提bug 的速度大幅晋升，次要汇总如下： bug辨别问题类型 —— 使bug分类更精准，能更好地剖析数据，push对应人员bug状态展现优化 —— 各状态高深莫测，更快找到须要解决的bugbug形容预置版本、步骤、设施等信息 —— 缩小反复内容输出，提bug效率更高 jira挪动版接入应用 —— 附件内容更不便上传，bug形容更精确，缩小因无奈复现、形容不清等起因带来的反复沟通老本bug流程新增：一轮漏测、fix bug引入选项、bug形容不清的状态 —— 当然这些指标目标不是为了查究是开发或是测试的责任，是为了剖析bug，总结起因，从中找出有余的中央（比方用例设计不欠缺、开发修复bug未自测等问题），大家共同进步，晋升我的项目品质，从而让我的项目进行更晦涩与高效。主动揭示开发QAfix和验收bug：—— 精准找到须要解决bug，解决效率大大晋升我的项目流程复盘中，咱们约定p1bug当天须要fix，p2bug原则上fix周期不超过T+1天，验收不超过T+2天。如下图，就是依据造成的标准主动揭示研发、测试的内容：【小结】： 1.即便是预置的一些提bug信息和界面优化，也让测试更“优雅”地工作，提bug和验bug也更有劲儿了。 2.T+1修复周期的约定与音讯推送，给了研发一个心里预期，正如咱们依据我的项目状况调整测试策略个别，研发也依据咱们给的预期调整了工作模式，从而使研发fix bug周期保障到最短，高效且有品质地修复了bug。　工作流程的调整与满满预期的加持，让整个团队的工作效率极大进步。　3.4测试报告测试日报【when】个别我的项目提测后，须要每日上班前发送日报 【what】-- QA具体须要做什么 汇总其余QA的进度，依据我的项目状况发送日报or周报。日报中危险项一环节可依据我的项目状况批改，同步打算、揭示事项等都能够写入。push开发fix bug：p1 修复周期不超过T+1天，bug数量较多时，可依据测试状况适当催开发批改（比方一轮测试靠近序幕，还有很多服务端前端bug，就须要催一下了） 【how】-- 具体怎么做 在galaxy平台工具上，实现了日报主动生成工具，每日可主动生成日报内容，不便大家看进度，且日报中还有以后bug状态和链接，研发也能更快找到本人的bug。日报一键生成成果如下：【小结】： ...

前言本期向大家介绍一个在产品设计中的重要工具——商业画布。在产品研发中，产品经理经常将精力重点放在用户体验局部，设计了貌似完满的性能和极其花哨的界面，而在产品上线后却发现用户寥寥无几。究其根源，是因为对产品的商业模式没有一个清晰的认知和布局，在设计产品时没能找到正确的路径。本文将简要介绍商业画布这一工具及其绘制思维与办法，帮忙咱们防止陷入产品叫好不叫座的难堪场面。 什么是商业画布？商业画布，是指一种可能帮忙创业者催生创意、升高猜想、确保他们找对了指标用户、正当解决问题的工具。它是以图形形式形容了商业模式的九大模块，系统地反映了企业的商业模式。上面咱们举个例子来让大家对商业画布先有个初步意识： 通过这张摩拜单车APP的商业画布曾经可能清晰的反映了这款APP软件所要面向的客户和价值主张，以及老本形成和将来的盈利点等元素。 商业画布绘制思维办法要绘制出适宜企业经营方式，满足企业用户需要和产品设计要求的商业画布须要从以下三方面思考。 传统建模商业画布包含9个内容模块，各模块之间有很强关联性，由此造成系统化的构造。最后绘制商业画布要考究价值链准则、应用演绎性形容、模块之间要考究彼此有分割、故事性、关联性。即咱们要做的产品是为谁提供，提供什么、如何提供以及付出多少又有哪些播种（为谁提供是要明确客户细分、客户关系，提供什么即价值主张及由此产生的要害业务，如何提供是要明确渠道通路、重要搭档以及外围资源）。 剖析“痛点”构建好模型后，紧接着能够使用头脑风暴法进行剖析，找出商业画布中的“痛点”。痛点是什么？通常大家都会认为应该是思考所生产的产品是否能挣钱？如何找对指标客户？咱们的合作伙伴是否给力？等等。针对这些，咱们能够采纳老本效益剖析、市场调研、综合评估的办法找出痛点问题，其最终目标是尽可能帮忙客户排除痛点满足客户的冀望。在做产品设计时，痛点能够是任何烦扰因素或阻碍，它在待实现我的项目指标工作之前、之中和之后都会存在，往往一个环节上的痛点来自于上一个环节的“办事不利”，这个就是痛点。可能清晰的梳理出这些痛点，对于整个我的项目团队意义重大。 我的项目研发中的痛点如映射到咱们研发畛域，对于痛点的演绎，往往关注着更多的细节。其中关注各个我的项目角色成员的痛点是什么？就很重要。通常的待研发产品次要用户角色有产品经理、设计、开发、测试、项目经理等。如联合工作环境，通常能够剖析出产品经理的诉求是在书写需要文档以及变更沟通等方面；开发的诉求是在业余能力造就，高质量工作，与设计的高效沟通；项目经理的诉求是在我的项目进度方面等等。 发散思维和集中探讨依据后面造成的痛点，我的项目成员须要展开讨论。然而因为每一位我的项目成员的常识、教训的不同，其对商业画布每一结构模块的内容必然有各自的想法与见解。为防止在开始时的想法有可能被否定或者脱漏，采取首先进行想法的发散，而后进行想法汇聚探讨的形式，以保障各成员想法收集的完整性和全面性。产品经理应疏导大家对商业画布的劣势与劣势进行思考并对各模块的内容进行概括并达成意见的对立。 总结：下面咱们曾经根本理清了商业画布的绘制思路，当然商业画布的绘制形式多样，依据你我的项目团队的性质和规模大小能够绘制多张画布。通过绘制商业画布，咱们对于产品在特定阶段的商业因素更加聚焦，同时也对产品中长期布局有了更精确的意识。另外须要留神的是，在产品成长的过程中对于商业模式的摸索应该是继续的，能够进行无效的迭代降级，在这个过程中须要不同角色的我的项目成员独特参加。 结束语无关商业模式马云曾不止一次的谈起卖梳子给和尚的话题，一个小故事就能折射出不同商业模式，不同的商业模式就会产生不同的商业后果。而商业画布就是这样一种应运而生的思维工具办法，它能够帮忙企业正确的设计产品，从而抉择最无利的商业模式，实现价值最大化。当然商业画布的应用领域是可拓展的，它除了能够使用在企业经营方面，还能够使用于职业规划领域，造成集体商业画布。如果大家感兴趣，能够上网理解更多内容，说不定你能够因为这个支点撬动整个地球呢！ IDCF【冬哥有话说】收费直播，关注公众号回复“冬哥”获取地址 12月23日（周四）晚8点 王梓晨 《会成长的OKR——互联网如何用OKR驱动团队挑战「不可能」》

1.前言 1.1 什么是测试需要？ 确切地讲，所谓的测试需要就是在我的项目中要测试什么。咱们在测试流动中，首先须要明确测试需要（What），能力决定怎么测（How），测试工夫（When），须要多少人（Who），测试的环境是什么（Where），测试中须要的技能、工具以及相应的背景常识，测试中可能遇到的危险等等，以上所有的内容联合起来就形成了测试计划的基本要素。而测试需要是测试计划的根底与重点。　就像软件的需要一样，测试需要依据不同的公司环境，不同的业余程度，不同的要求，具体水平也是不同的。然而，对于一个全新的我的项目或者产品，测试需要力求具体明确，以防止测试脱漏与误会。 1.2 为什么要做测试需要？ 如果要胜利的做一个测试项目，首先必须理解测试规模、复杂程度与可能存在的危险，这些都须要通过具体的测试需要来理解。所谓知己知彼，百战不殆。测试需要不明确，只会造成获取的信息不正确，无奈对所测软件有一个清晰全面的意识，测试计划就毫无根据可言。活在本人世界里的人是可悲的，只凭感觉不做具体理解就下定论的我的项目是失败的。　测试需要越具体精准，表明对所测软件的理解越深，对所要进行的工作内容就越清晰，就更有把握保障测试的品质与进度。　如果把测试流动比作软件生命周期，测试需要就相当于软件的需要规格，测试策略相当于软件的架构设计，测试用例相当于软件的具体设计，测试执行相当于软件的编码过程。只是在测试过程中，咱们把“软件”两个字全副替换成了“测试”。这样，咱们就明确了整个测试流动的根据来源于测试需要。 2.测试需要分析方法   2.1 测试需要剖析根据 通常是以被测产品的需要为原型进行剖析转变而来，测试需要次要通过以下路径来进行收集：　与待测软件相干的各种文档资料。如软件需要规格、Use case、界面设计、我的项目会议或与客户沟通时有对于需要信息的会议记录、其余技术文档等。　与客户或系统分析员的沟通。　业务背景材料。如待测软件业务畛域的常识等。　正式与非正式的培训。　其余。如果以旧零碎为原型，以全新的架构形式来设计或欠缺软件，那么旧零碎的原有性能跟个性就成为了最无效的测试需要收集路径。 2.2 测试需要架构划分 测试需要剖析应首先进行测试需要架构划分并先进行评审，通过后才进行后续的测试需要开展剖析，从产品整体上思考有哪些性能、测试类型须要进行剖析，列出测试个性列表，也不便下一步开展具体分析。　首先，这里须要对性能进行一下定义以达成共识，性能是指能独立实现一个根本业务解决要求，为了升高测试需要设计的复杂性及依赖性，测试需要架构列举的性能是指最小性能点，即不可再持续合成。　(1)应用程序：　A.个别是最底层的菜单项为最小性能点，若最底层的菜单项不能体现一个独立的业务流程时，可采纳上一层　的菜单项为最小性能点。　B. 还有某些比拟非凡没有体现在菜单项的性能也须要作为最小性能点思考，如POS应用程序中交易的冲正性能　等。　(2)驱动：个别是以一个API为最小性能点。　而后，再思考产品理论用户应用的场合及用户特点思考哪些测试类型，如故障及复原、性能集成、性能要求、装置测试、软硬件兼容性等，此处须要从产品层面思考，而不是从性能点层面思考。 2.3 测试需要剖析过程 2.3.1 测试需要收集 测试需要的收集次要通过对测试根据进行剖析整顿，最初生成一个以测试的观点登程的checklist（检查表），用来作为测试该软件的次要工作内容。检查表的查看要点包含需要的正确性、必要性、优先级、明确性、可测性、完整性、一致性、可修改性：　在整个信息收集过程中，务必确保软件的性能与个性被正确理解。因而，测试需要剖析人员必须具备优良的沟通能力与表达能力。   2.3.1.1 测试类型划分 依据测试需要收集取得的checklist(检查表)，对每一条测试需要，从GB/T16260.1定义的软件品质子个性角度登程，确定所对应的品质子个性。即，从适用性、准确性、互操作性、窃密安全性、成熟性、容错性、易恢复性、易了解性、易学性、以操作性、吸引性、工夫个性、资源利用性、易剖析性、易扭转性、稳定性、易测试性、适应性、易装置性、共存性、易替换性和依从性方面的定义登程，确定每一条测试需要所对应的品质子个性。从而对这些品质子个性进行测试类型划分，如：功能测试、易用性测试（装置测试、性能易用性测试、用户界面测试、辅助零碎测试）、兼容性测试、可靠性测试、文档测试、性能测试，强度测试等。 2.3.1.2 测试类型细化 对划分的每个测试类型进行细化。软件测试需要是开发测试用例的根据，测试需要合成得越具体精准，表明对软件的理解越深，对所有要进行的工作就越清晰，对测试用例的设计品质的帮忙也越大，具体的测试需要还是掂量测试覆盖度的重要指标，测试需要是计算测试笼罩的分母，没有具体的测试需要就无奈无效的进行软件测试笼罩计算。最好达到细化的后果是分支的最末端（测试项）针对的测试目标是繁多的最小的性能点的测试，即每个测试项为一个测试性能点。 2.3.1.3 生成测试需要树 已细化的测试需要中，因为在提取时，可能存在着反复或冗余，须要进行删除和合并需要。删除测试需要中存在的反复的、冗余的含有关系的测试项。如果有相似的测试项，则须要对其进行合并。最终生成测试需要树。 2.3.2 测试危险剖析 因为软件的输出、输入、解决存在肯定的限度和束缚，另一方面因为测试树中进行了必要的删除和合并，这导致测试需要不可能是全面的笼罩，从而造成了肯定的测试危险。测试需要中必须对不剖析或不测试局部给出相应的危险剖析阐明。　3.总结 以上次要形容了测试需要相干实践和取得测试需要树的个别过程。为具体我的项目施行测试中提供了一套获取测试需要树的参考计划。理论的测试类型划分和测试需要树生成的模式或粒度，因我的项目而不同，需灵便利用。 ...

本文转自台湾的Ruddy Lee老师的博客，Impact Mapping 真是令人惊艳的可视化工具。等你看完这篇文章，你会爱上它的。 典故继2011年6月Example of specification《实例化需要》一书的平凡奉献之后(取得 2012年 Jolt Award 年度最佳图书大奖)，Gojko Adzic 说我会更致力地在需要这个畛域里做出问题来的，请期待。 他果然没有让大家等太久，2012年10月他发行了 Impact Mapping《影响地图》这本只有三个部份，共73页的小册子。 小册子只阐明了一件事：如何把概念可视化 – Impact Mapping影响地图。它展示了一种「让需要可视化的能力」，用简略的 Why-Who-How-What的分析法，搭配结构化的显示方式，让工程师可能看见辛辛苦苦开发进去的性能是对应到哪一个业务的指标上。 哈哈! 其实是倒过去的，因为它非常适宜使用在需要还是极度形象(概念)的期间，他让业务指标可能清晰化，让大家都能以较形象的形式看出须要那些性能能力达成这样的业务指标。它可能串联进去一条相干的影响门路，并借着关联的图示化，让需要被看得见，这一点对产品的晚期，还在做雏型设计的作业上有着极大的奉献。 原文版: Impact Mapping: Making a big impact with software products and projects中文版: 影响地图：让你的软件产生真正的影响力用Impact Mapping来剖析电影 — 另类的诠释这是我的最爱，使用电影来论述演讲的情节内容(大略是2005年开始的，我记得过后讲的第一部电影是基诺.利瓦伊的驱魔神探 康斯坦丁，技术上要探讨的是微软 Message Queue 的实践)。手法是在演讲中拨放一段2到3分钟的电影精彩片段，让学员透过可视化的影像，试着联想着跟演讲主题的种种关联性，达到一种比独自听讲者演说更为无效的共鸣。这招用多了当前，就自然而然成为了本人演讲时的特色。一些熟识的学员，总会在上课前顺道问一下明天会放哪一部片子啊?! 但这回采纳impact mapping，则是真的用来剖析电影用，与技术无关，假借着使用它可视化的能力，让没有看过这部电影的人也能像剧务一样的相熟着每个场景(仿佛讲得太夸大了，本质上只是画出它的门路而已，若是想要齐全理解它，还是要配合着去看剧本吧，至于所有的性能形容，那是每个参加上演人的”脚本”)，理解各个场景试图要带给观众的成果是什么，以及它所想达成的指标。以下便是电影白日梦冒险王（The Secret Life of Walter Mitty国内的翻译叫做《白日梦想家》）的影响地图(或者是它的主题曲太吸引人了，所以就选它的电影来当范例了。它叫: Stay alive)。 由左往右；依序排列的是电影要达成的指标，有哪些重要的角色，而这些角色要强调的是那些特色，这些特色所须要的形成因子，最初是用怎么的剧情上演才能够取得这样的成果。(有一条能够依循的门路，如同就能够勾画出the whole picture，这是咱们在思维含糊期所最最想要的，寻找条能够依循的思路，这须要练习，来动动手吧!) 试着用这些数据，开始说故事吧: 配角的指标(Why): 找到第25张底片，来做杂志最初一期的封面故事。人物配角(Who): 华特.米堤 Walter Mitty(由班·史提勒饰演)配角的共性特色(How): (1)爱做白日梦。(2)是典型的宅男。影响这个共性的形容(What): (1)体现得常常发愣、空想。(2) 非常容易触景生情。(3)少年时打工后遗留下来的创伤，等等。场景(Scenario): 这是我本人加上的。因为要做这样的共性形容，该有怎么的布景来做配合，准备动用多少演员，筹备拍摄多长的底片(也就是准备破费的老本)及脚本。只是一张简洁的图示，针对 一个指标，陈说着。 第一层、谁Who：指出配角人物第二层、怎么How：格性特色的形容第三层、什么What：列出影响的因素再针对这些个因素设计出可能展示达成让观众引起共鸣的场景片段。最初再测验这些个片段是否能达成咱们所默认的指标。这样便OK了!一出戏的极度形象轮廓便能够成形了。 ...

咱们在麻利开发中始终强调要将Backlog按优先级排序，迭代的时候也严格依照这个优先级来开发，这样就能够保障咱们当下是在交付最高价值的用户故事（User Story，以下简称US）了，就像下图这样，最高优先级的故事最先被实现： 然而咱们很多团队理论的迭代过程却是下图这样的，高优先级的故事未被实现甚至并未开始，然而低优先级的故事曾经开始甚至曾经实现了： 那咱们应该怎么对Sprint Backlog进行排序，能力让高优先级的故事最先被实现呢？本文将介绍一个优先级排序工具：MoSCoW法令，来帮忙大家对Sprint Backlog做出一份正当的优先级排序。 一、什么是MoSCoW法令1.1 MoSCoW中的四个大写字母MoSCoW的四个大写字母，M、S、C、W别离对应以下四个词汇的首字母： Must have：必须有。如果不蕴含，则产品不可行。Must have的性能，通常就是最小可行产品（MVP）的性能。 Should have：应该有。这些性能很重要，但不是必须的。尽管“应该有”的要求与“必须有”一样重要，但它们通常能够用另一种形式来代替，去满足客户要求。 Could have：可能有。这些要求是客户冀望的，但不是必须的，并且能够以很少的老本改善用户体验，或进步客户满意度。如果工夫短缺，资源容许，通常会包含这些性能。但如果交付工夫缓和，通常现阶段不会做，会挪到下一阶段做。 Won’t have（this time）：（这次）不会有。最不重要，最低回报的我的项目，或在当下是不适宜的要求。不会被打算到以后交付打算中。“（这次）不会有”的需要会被删除，或被放入Product Backlog以便当前的Sprint重新考虑（留神：有些中央会应用Would like to have这个术语，然而这种用法是不正确的，因为最初这个优先级分明地表明有些需要超出了本次交付的范畴）。 1.2 MoSCoW中的两个小写字母MoSCoW法令中，除了上述四个词汇的首字母外，还有两个o，这两个o是做什么的？其实莫斯科法令的全称是： Must or Should, Could or Won't.为什么Must和Should两头有一个or，Could和Won't两头也有一个or，而Should和Could两头却没有？是不是老外为了读起来有朗朗上口的感觉，顺便这么设计的？ 其实不是的，实在起因是因为要辨别一个US是Should have还是Could have是很容易的，然而要辨别一个US是Must have还是Should have，或者是Could have还是Won't have的时候，不同的人会有不同的认识，即便是同一个人，不同工夫、不同环境下看同一个US，也可能会得出不一样的论断。这段形容是不是看得有点头晕？没关系，举个例子你应该就明确了： 假如一个电商APP有以下2个US： 1.作为一个电商APP的用户，我想注册一个账号，以便能够买到我心仪的商品。（以下简称注册账号） 2.作为一个电商APP的用户，我想编辑我的个人资料，以便能够个性化我的个人信息。（以下简称编辑材料） 如果从Should have还是Could have的角度来划分以上2个US，你们会得出怎么的判断？ 我在公司组织过一个10人的小组投票，后果如下： 投票后果简直是一边倒，注册账号是应该做的（Should have），编辑材料是能够做的（Could have）。 而后我又问了以下两个问题： 注册账号是必须做的（Must have），还是应该做的（Should have）？ 编辑材料是可能做的（Could have），还是可能不做的（Won't have）？ 而后大家就吵起来了。 比方对于注册账号的争执如下： 甲：没有注册性能，我怎么晓得是哪个用户下的单呢？所以我感觉是Must have。 乙：干嘛非要有个注册性能呢？用户能够用三方账号受权登录啊，比方微信或微博受权登录不就能够了吗？所以我感觉注册性能不是Must have，应该是Should have。 甲：登录性能强依赖第三方APP，会被App Store回绝上架的。 乙：那能够接入苹果账号的受权登录啊！ 甲：那Android和网页版怎么办呢？ ...

影响地图是什么？一个简略却极高效的协作性的策略布局方有的产品，它还活着，它曾经死了；有的产品，还没公布，就曾经死了。太多的产品失败的案例，源于方向性谬误，基于谬误的假如，性能与业务指标/价值之间不足必然的关联与一致性，在做的事与冀望的指标背道而驰。影响地图试图通过结构化、可视化、合作化的形式来从源头解决上述问题。 周六加入了 王立杰@Agile1001 组织的影响地图工作坊，学习体验了一把，这两天又认真研读了GOJKO ADZIC的《影响地图》一书，书摘、Workshop体验以及本人的一些思考分享进去，欢送一起探讨。 影响地图是一门战略规划技术，通过清晰的沟通假如，帮忙团队依据总体业务指标调整其流动，以及做出更好的里程碑决策，影响地图能够帮忙组织防止在构建产品和交付我的项目的过程中迷失方向。确保所有参加交付的人对指标、冀望影响和要害假如了解统一。 同时，影响地图能够无效的评估交付，作为品质反馈的规范之一：如果一个需要没有无效的反对冀望的行为影响，那么即便在技术上正确，性能交付给用户了，也依然是失败的。 影响地图试图去解决组织面临的范畴蔓延、适度工程、不足整体视图、开发团队和业务指标不能保持一致等困扰。 影响地图的构造简略的讲，影响地图是这样的一个思维逻辑和组织构造：为什么（Why）-->谁（Who）-->怎么（How）-->什么（What） 也就是：咱们的指标是什么（Why），为了达成指标须要哪些人（Who）去怎么（How）影响，为此咱们须要做什么（What）。影响地图通过构建产品和交付我的项目来产生本质影响，从而达到业务指标。 为什么（Why）？答复：咱们为什么做这些？也就是咱们要试图达成的指标。 找到正确的问题，要比找到好的答复艰难得多。把本来刻画在文档中，更多的是暗藏在高层利益干系人头脑中的业务指标，定性定量的疏导进去。指标形容要遵循SMART准则：Specific明确，Measurable可度量，Action-Oriented面向口头，Realisitc事实的，Timely有时限的。确保每个人晓得做事的目标是什么，帮忙团队合作，针对真正/适合的需要设计更好的计划。 谁（Who）？答复：谁能产生须要的成果？谁会妨碍它？谁是产品的消费者或用户？谁会被它影响？也就是那些会影响后果的角色。 思考波及到的这些决策者、用户群和生态系统，留神角色同样有优先级，优先思考最重要的角色。 角色定义应该明确，防止泛化，能够参考用户画像Persona的形式进行定义。 怎么（How）？答复：思考角色行为如何帮忙或障碍咱们达成指标？咱们冀望见到的影响。 只列出对靠近指标有帮忙的影响，而不是试图列出所有角色想达成的事。影响是角色的流动，是业务流动而不是产品性能。现实状况下应展示角色行为的变动，而不仅仅是行为自身。不同的角色可能有不同的办法，帮忙或妨碍业务指标的实现，这些影响彼此之间可能是互相参考，互相补充，相互竞争，或者互相抵触的。既要思考到侧面的影响，也要思考负面或妨碍的影响。 留神：业务发起方应该针对角色Who以及影响How，而不是交付内容What进行优先级排序。 什么（What）？答复：作为组织或交付团队，咱们能够做什么来反对影响的实现？蕴含：交付内容，软件性能以及组织的流动。 实践上这里是最不重要的一个档次，防止试图一开始就将它残缺列数，而应该在迭代过程中逐步完善。同时留神，不是所有列出来的货色都是须要交付的，它们只是有优先级的交付抉择。 “永远不要试图实现整个地图，而是要在地图上找到达到指标的最短门路。” 影响地图足够简略，操作性强，又有足够的收益：可能帮忙创立更好的打算和里程碑布局，确保交付和业务指标统一，并更好的适应变动。影响地图的首要任务是展现互相的关联，主要工作是帮忙发现代替线路。 正如作者所言：影响地图合乎软件产品治理和公布打算的发展趋势——包含面向指标的需要工程、频繁的迭代交付、麻利和精益软件办法、精益守业产品开发循环，以及设计思维。如果你认同上述趋势，那么影响地图会是你的菜。 影响地图的特点结构性：从业务指标到交付的结构化梳理和开掘的办法，指标--角色--影响--交付物；整体性：连贯指标和具体交付物之间的树状逻辑图谱；协作性：利益相干人一起沟通探讨合作，把暗藏在集体头脑中的默认的思维逻辑开掘共享进去；动态性：动静调整、迭代演进、教训证的学习；可视化：对立共享的视图，构造清晰易读；它将各个部门/角色不同的视角，不同的思维逻辑，不同的前提假如，通过可视化和合作的形式进行梳理、廓清和导出。通过连贯交付内容、影响和指标，影响地图显示了之所以去做某个性能的因果链，同时也可视化了各利益相干人做出的假如。这些假如包含：业务交付的指标，波及指标干系人，视图达到的影响。 同时，影响地图沟通了两个层面的因果关系假如： 交付会带来角色行为的变动，产生影响；一旦影响达成，相干的角色会对整体指标产生奉献。影响地图分层是否能够将影响地图分层？ 我认为齐全能够而且正当。《影响地图》也提到倡议打算两次会议：第一次定义预期的业务指标和度量；第二次来制作一张地图。第一步就是确定使命，而一个策略目 标往往太大，无奈疾速奏效，须要拆分成可短期达成的战术指标，依据优先级排序的战术指标，逐次进行影响地图分析，期间动静调整更新，定期决定是否须要持续。 因而能够有两层的影响地图：“一份针对整体产品愿景，一份针对中期交付。” 同时，通过分层，也能够无效的管制参加两个会议的人员组成。高阶的领导者未必须要加入所有的影响地图流动，尤其是战术影响地图会议。 参加人员Decision Maker，留神肯定要有决策者参加，包含：商业决策、技术决策、营销决策（原书中为高级技术和业务人员）。如果发现一个问题探讨很久没有决定，兴许是因为不足适合的参加人员，应该找更高阶的人员决策。 参加人数：原书的倡议是将第一次会议人数限度在不超过5-6人，确保要害的业务决策者和技术人员参加进来。随后的会议能够适当扩充规模分组讨论，随后汇总，但人数越多，会议的节奏和范畴就越须要管制。 影响地图与用户故事的关联影响地图能够作为用户故事列表的无效输出影响地图的输入物，能够作为用户故事的输出，作为Epic、UserStory的起源。这些输出曾经通过了价值判断，角色开掘，优先级排序，甚至曾经有了一 局部的验收规范（是否影响了受众同时为达成指标作出贡献），同时也因为有资深技术人员的参加，初步做过技术可行性判断。因而这些backlog的输出，往 往更加靠谱，对交付团队更具价值。 输出模式《影响地图》书中有明确的形容，把三段式的用户故事与影响地图几个层级进行mapping：作为一个Who，我心愿What，以便于How。 影响地图能够很好的管制用户故事列表有限蔓延看似动静调整的故事列表，依据精益打消节约的思维，保护残缺的故事列表，事实上也是节约。存在的问题有两点： 第一，看不到用户故事与业务价值间接的分割，往往为了实现性能去做，而不是思考其背地交付的价值，以及这个价值是否被用户认可；第二，故事列表往往是各方头脑风暴的后果，同时还在不断更新，却很少剔除，这个长长的列表不仅须要定期维护，其背景、内容、优先级、价值等都在随着商业环境的变动而一直变动；事实上保护一个三个月或者半年当前才可能实现的需 求就是节约。指标/里程碑与公布打算业务指标能够与迭代的公布打算关联，每次迭代只解决大量的指标；《影响地图》倡议一次 只解决一个指标，目标在于疾速反馈和调整；集体认为基于团队规模、迭代步速，一次迭代能够蕴含几个指标决定于指标的颗粒度以及工夫估算，不可一概而论。当 然在具体执行时，这里会是一个争执以及变数较多的点。 如何避免思维蔓延，地图扩张先发散再收敛实战练习中，咱们40多人分成6组，别离绘制本人的影响地图；理论场景中，如果每组都基于同一个指标，绘制进去的地图会各具特色而发散，最终须要疏导将发散的地图进行收敛，在此过程中，会发现更好的实现或是新的假如导出，最终失去成型的影响地图。 分层和分拆时，把握80/20准则，不求八面玲珑，只须要波及最要害重要的因素。思考到大部分团队会应用物理板+即时贴的形式进行影响地图的设计，集体以 为，本来因为物理空间受限以及可读性起因存在的物理白板的弊病，反而能够作为细化水平的一个无效限度准则（正如驰名的两个披萨准则）：以物理墙/白板为影 响地图的最大边界。 绝对于咱们通常关怀的业务性能/营销流动，即影响地图的第四层What，咱们更应该把把注意力放 在前三层指标、角色和影响上，尤其是角色和影响上，关注点如此，优先级排序也是如此；先不要关注在What即本人要做什么事件上，这往往会让咱们陷入执行 的细节，埋头做事，而疏忽了事件的初衷。 少数的门路最终不会被执行，是否须要保留？首先要防止过早陷 入过多的细节，将来一切都是未知的，所有的都是基于以后的假如，所以保护一份残缺的地图，试图将所有想法都演绎在地图上，是没必要的。其次，指标导向，避 免在那些对整体指标没有作用的影响上破费过多的工夫。整理出来的门路，当然能够保留下来，作为下一次影响地图的局部输出。 此外，须要留神的是，What蕴含交付内容、软件性能和组织的流动，如果交付的所有条目都是技术性，兴许要从新扫视影响地图，尤其是角色Who与影响How两局部，并非所有的指标都是须要通过产品性能达成，更多状况下，兴许一个简略的营销流动就能够疾速实现目标。 什么工夫完结影响地图会议何时完结“当要害想法曾经呈现在地图上”，当曾经达成指标，并且确定最快/小门路，临时也想不出更好的代替计划时，就能够完结。倡议设定严格 的timebox，一旦呈现工夫点超时，或者是团队陷入太过细节的探讨，或是没有找对适合的人，不足适合的决策者，兴许是业务决策者，兴许是技术决策者。 影响地图何时生效如同打算，在制订进去的那一刻兴许影响地图就曾经生效，因而须要适时调整（留神是适时，未必是实时）。影响地图更像是迭代打算，每个影响达成，进行反馈评估，对影响地图的内容以及优先级进行调整；一旦指标达成，兴许这张影响地图就实现了使命。 影响地图能够在哪些方面利用集体认为影响地图的思维办法和逻辑构造是广泛实用的，因而能够利用到很多畛域，诸如旅行，健身，减肥，教育，学习打算， 战略目标，营销策略，销售打算等；但理论执行的过程未必要残缺的按四个阶段进行。 对影响地图实际的集体领会，演绎为“三心二义”不忘初心始终牢记做事的初衷是达成业务指标，而不是实现性能，甚至不是达成影响（如果影响最终不能帮忙实现目标）； 不要贪婪不要试图一次实现好几件事，而应该分拆成多个里程碑，多张地图；不要试图一件事做完满，冀望把所有列出来的事件都实现是不事实且没必要的；把握80/20准则，达成指标即可，业务环境始终在变，业务关注点也会随之变动； 赤子之心不偏不倚，不卑不亢，边走边学边调整，对指标和将来抱着一颗坦诚、恭敬与摸索的心，不否定、不自卑、不盲从。 批判主义狐疑所有，多问几个为什么；把假如疏导进去，通过剖析和实际来验证假如； 实用主义所有以实用登程，价值导向，指标导向，后果导向，放弃简洁。 起源：AgileRunner作者：IDCF导师 冬哥 6月每周四晚8点，【冬哥有话说】开心一“夏”。公众号留言“开心”可获取地址 ...

明天的知识点 (2021.05.22) —— 第767天 (我也要出题)[html] 应用html画一个热气球[css] 应用纯CSS实现多行文本开展收起成果[js] 你有理解过javaScript Debugger的原理吗？[软技能] 你如何对待一句话需要？如何应答一句话需要？《论语》，曾子曰：“吾日三省吾身”（我每天屡次检查本人）。前端面试每日3+1题，以面试题来驱动学习，每天提高一点！让致力成为一种习惯，让奋斗成为一种享受！置信 保持 的力量！！！ 欢送在 Issues 和敌人们一起探讨学习！ 我的项目地址：前端面试每日3+1【举荐】欢送跟 jsliang 一起折腾前端，零碎整顿前端常识，目前正在折腾 LeetCode，打算买通算法与数据结构的任督二脉。GitHub 地址 微信公众号欢送大家前来探讨，如果感觉对你的学习有肯定的帮忙，欢送点个Star, 同时欢送微信扫码关注 前端剑解 公众号，并退出 “前端学习每日3+1” 微信群互相交换（点击公众号的菜单：交换）。 学习不打烊，充电加油只为遇到更好的本人，365天无节假日，每天早上5点纯手工公布面试题（死磕本人，愉悦大家）。心愿大家在这虚夸的前端圈里，放弃沉着，保持每天花20分钟来学习与思考。在这变幻无穷，类库层出不穷的前端，倡议大家不要等到找工作时，才狂刷题，提倡每日学习！（不忘初心，html、css、javascript才是基石！）欢送大家到Issues交换，激励PR，感激Star，大家有啥好的倡议能够加我微信一起交换探讨！ 心愿大家每日去学习与思考，这才达到来这里的目标！！！（不要为了谁而来，要为本人而来！）交换探讨欢送大家前来探讨，如果感觉对你的学习有肯定的帮忙，欢送点个[Star]

本指南内容一、为什么故事拆分很重要二、什么样的用户故事才算是失当的故事？2.1 用户故事格局2.2 失当的故事应遵循INVEST准则2.3 用户故事是垂直切片三、故事拆分流程图 步骤1：筹备好要拆分的故事/个性步骤2：套用拆分模式3.3 步骤3：评估拆分成果四、Cynefin和故事拆分五、练习故事拆分六、垂直切片和规模化6.1 是否应该让100+的人去开发一个产品？6.2 规模化垂直切片的基线 一、为什么故事拆分很重要从优先级最高的、工作量较小的用户故事开始开发，能够让产品团队继续输入高价值的产物，并取得高质量的反馈。许多团队都在致力将较大的用户故事和个性（feature）拆分成失当的小故事，然而他们没有从业务的垂直切片来拆分，而是从整个技术架构的的角度，拆分出了很多看起来更像研发工作（Task）或组件（Component）的故事，最终导致他们未能体验到小故事应有的价值或反馈。 侥幸的是，故事拆分是一种能够在较短的工夫内学会的技能。咱们曾经看到，团队仅需几个小时的练习和一些简略的工具，就能够从挣扎中解脱进去，疾速地拆分故事。稍后，咱们将介绍如何组织这种练习。 二、什么样的用户故事才算是失当的故事？在探讨拆分用户故事之前，咱们须要确保咱们对什么样的用户故事才算是失当的故事、以及能够将哪些内容拆分为故事有一个独特的了解。 首先，让咱们看下用户故事的定义：用户故事是从用户的角度形容零碎行为的变动。它形容的是用户想通过零碎做的事件，或者心愿零碎为他们做的事件，而这些事件当初的零碎里还没有。 顺便说一下，请留神，用户故事位于计划域（solution space）而不是问题域（problem space）。它不是一个人想在某个中央实现一个工作的形容（就像JTBD[Job to be Done，待实现的工作]一样），而是一个人想要在你的零碎中实现某件事情的形容。JTBD在问题域中能够与客户产生很好的共鸣，而用户故事能够很好地将客户的共鸣转化为对软件系统的一系列扭转，同时在整个交付过程中放弃客户的视角。 2.1 用户故事格局你可能常常会看到以如下特定格局书写的用户故事： 作为角色我想要性能或口头以实现价值或指标或者有的是这样： 为了价值或指标作为角色我想要性能或口头该模板的长处在于它要求你答复用户故事中的三个问题： 它是给谁（WHO）应用的？他们想要做什么（WHAT），或者让零碎做什么，而这些性能当初都还没有？他们为什么（WHY）要这样做？不过，重要的不是模板，而是答复这三个问题。 实际上，咱们很少会用残缺的模板来写故事。无论是在便签纸的顶部还是在在线项目管理工具的题目字段里，一个写着“WHAT”的简短题目都会是比拟好的抉择。“WHAT”由题目提供，而“WHO”通常由产品愿景或版本指标提供，它形容了外围指标客户。如果故事是为该指标客户筹备的，咱们就不反复撰写了，咱们只有在为非核心指标客户撰写用户故事时，才把“WHO”加上。最初，咱们将确保在在线工具的“详细描述”或相似的字段中，或者在便签纸上用较浅的字体写明“WHY”。 因而，如果咱们要做一个公共图书馆的网站，并且图书馆的读者是咱们的默认用户，则咱们不会这样来书写用户故事： 作为图书馆的读者，我想按书名搜寻一本书，以便我能在搜寻后果中毫无烦扰地找到我想要的书。咱们会这样来写： 按书名准确查找因为我晓得我想要的具体书籍，所以我不心愿在搜寻后果中呈现烦扰有时咱们会遇到将独自的研发工作或架构组件伪装成用户故事的状况。即便你应用了诸如“作为开发人员，我想要一份数据库关系图，以便我能理解数据库的构造”这样的神奇形容，它依然只是一个开发工作。 2.2 失当的故事应遵循INVEST准则几年前，极限编程先驱Bill Wake提出了一个很好的首字母缩略词，用来示意一个失当的用户故事应具备的6个要害属性：INVEST。让咱们来挨个看一下： I代表INDEPENDENT（独立的）。这意味着一个失当的故事可能足够的独立，它能够不必思考技术依赖就能够排定优先级。有时，这意味着须要临时提供一些Mock数据或接口，以便能够独立测试故事，让你在我的项目的晚期就能更快地取得价值或升高危险。N代表NEGOTIABLE（可协商的）。一个失当的故事会为做什么、如何做等细节留下协商的空间。当然，随着协商的进行、更多细节的敲定，故事的可协商性就会升高。V代表VALUABLE（有价值的）。每个故事都应该为用户减少一些可见的价值增量。现阶段这仿佛是不可能的，因为你的Product Backlog里可能有大量的技术组件和基础架构的工作，这些技术工作伪装成了用户故事，但这并不能间接为用户减少价值。随着你故事拆分技能的一直成长，你能更好地找到能间接提供价值的、短小的性能切片。（故事并不需要独自提供足够的价值来间接公布。你可能须要积攒多个故事，能力从有价值转变为可销售。我喜爱最小可销售个性（MMF，Minimum Marketable Features）作为故事的容器。） E代表ESTIMABLE（可估算的）。一个失当的故事应该定义到足以让团队可能估算它的工作量，这个工作量个别是绝对于一个基准故事所做的绝对估算。S代表SMALL（短小的）。教训通知咱们，对于一个已排序的Product Backlog，你应该可能将优先级最高的6到10个故事排入下一个Sprint中。这样做既能常常取得反馈和治理危险，同时也不须要治理太多的故事。不过这个故事数量只是一个倡议，它会随着Sprint长度、团队规模、团队速率等因素按比例缩放。T代表TESTABLE（可测试的）。咱们应该有方法晓得咱们曾经实现了某个故事。它不能只是一个含糊的冀望，而须要是零碎行为的具体变动。当然，这些属性之间存在着肯定的互斥关系。比如说，随着故事的规模变小，使其变得独立且有价值的难度就会变大；随着故事的可协商性变大，其可估算和可测试的难度就会变大。 不过侥幸的是，不同的属性在不同的工夫起次要作用。例如在进入Sprint打算后，更重要的是故事要短小、可估算和可测试。这时咱们依然须要故事有肯定的独立性、可协商性和有价值，但这些属性这时曾经变得不那么重要了。而在Product Backlog中的故事，状况恰恰相反。 2.3 用户故事是垂直切片在提到失当的故事时，你常常会听到垂直切片（vertical slice）这个词。这是失当的故事在软件架构方面的要求。 垂直切片是指“一个能给零碎行为带来变动的有价值的工作项，它可能要涉及多个架构层级（architectural layers）来实现这个变动”。当你把这个切片（slice）称为“实现”时，该零碎对于用户而言显然更有价值。程度切片（horizontal slice）与垂直切片刚好相同，它是指“对一个组件（component）或架构层级（architectural layer）进行更改的工作项，它须要联合其余组件或架构层级的扭转，能力对用户交付可感知的价值”。咱们来看一个非常简单的零碎架构，这里有UI层、业务逻辑层和长久层。你的零碎可能比这更简单，但它可能至多蕴含这三层。 （零碎架构示意图） 要想取得INVEST的大部分属性，故事必然会波及这3个架构层级。如果不进行某些UI的扭转、逻辑的扭转、长久存储的扭转，咱们可能就无奈交付价值。因而，故事就是零碎的一个垂直切片。 有时候，这些垂直切片十分宽。当咱们进行故事拆分时，咱们将探讨如何在较宽的垂直切片中找到较薄的垂直切片。然而到目前为止，咱们只须要晓得故事应该在必要时逾越架构层级来提供价值就足够了。 许多刚组建的麻利团队会尝试依照架构层级来拆分故事：一个故事用来实现UI，另一个故事用于更新数据库等等。尽管这个故事可能也很小，但在独立性和价值交付上是失败的。当团队以垂直切片的形式拆分时，他们将会失去如下收益： 使Backlog的价值明确进行更多对于价值的对话有助于防止意外地建设低价值的变更更快取得价值更早取得更高质量的反馈更容易看到束缚和待办，并能做出相应的响应交付价值时变得更加可预测（因为可工作的软件是进度的首要度量规范）咱们还能够持续说上来，但这些应该曾经能够给你一些启发了。当咱们一起坐下来，写下咱们在胜利的麻利团队中看到的各种习惯，以及各个习惯之间的关系时，咱们发现垂直切片简直与所有其余习惯无关，或至多与局部习惯无关。 看看Product Backlog中的故事，有些是你最近实现的，有些是未来要做的。依据INVEST规范评估每一个故事，找出垂直切片和非垂直切片的故事。而后，看看你是否能够改良这些故事。 三、故事拆分流程图为了不便咱们更好地领导团队，Richard创立了一个故事拆分流程图，该流程图介绍了咱们在帮忙团队拆分故事时要问的问题。 （用户故事拆分流程缩略图） 让咱们别离看一下图中的三个步骤： 步骤1：筹备好要拆分的故事/个性 （筹备待拆分的故事） 首先要确保你要拆分的故事/个性满足INVEST规范（短小的（Small）除外）。大多数状况下，有价值的（Valuable）是问题所在。当人们把他们认为是“不可拆分”的故事带给咱们时，它们其实是伪装成故事的开发工作或架构组件。如果你不从减少价值的角度动手，就无奈将其拆分并取得价值增量。在这种状况下，下一步就是将非故事（non-story）与其余程度切片联合起来，这样，它们才能够独特代表一个价值增量。接下来，是不是切片太大了？如果是的话，就能够开始拆分了。 步骤2：套用拆分模式 （套用拆分模式） 模式1：按工作流程步骤拆分 （按工作流程步骤拆分） 这是我的客户在创立一个内容管理系统的故事： 作为内容管理员，我能够将新闻公布到公司网站。听起来故事并不大——直到咱们深入研究了发布新闻的工作流程。后果发现，仅仅是把一个几句话的新闻公布到公司网站上，就须要编辑和法律部门的批准，以及在预公布网站上做公布前的最终审核。像这样的6-10个故事不可能在一次迭代中实现。 在这样的工作流程中，最大的价值往往来自于结尾和结尾。两头的步骤会减少增量价值，但并不独立。所以先构建简略的端到端案例，而后再增加两头步骤和非凡案例，成果会很好。 新的故事包含： …我能够间接将新闻公布到公司网站上。…我能够在发布新闻前做一下编辑审核。…我能够在发布新闻前做一下法律审核。…我能够在预公布网站上查看新闻。…我能够将一篇新闻报道从预公布网站公布到正式网站。 ...

导读：做用户，绕不开画像！画像不仅能够晋升对用户的认知，还能够通过落地赋能业务。明天咱们聊聊用户画像在用户生命周期中的利用，次要介绍用户画像在电商场景下如何驱动产品链路优化。将依照用户生命周期，对用户进行划分并采取相应的措施；通过逆向的程序介绍用户画像在用户的不同阶段，如何在认知定位、渠道优选、个性化服务、再触达以及营收中发挥作用。 一、了解用户的两条门路1.1 AARRR与RARRA 宏观上，AARRR模型，也称海盗模型，是业内罕用的模型，可能无效推动业务倒退与迭代，能够对用户各个生命周期内的行为进行干涉。 宏观上，依据RARRA模型，落地到用户侧，则能够从认知定位、渠道优选、个性化服务、再触达和营收这五个维度内对用户的各个阶段进行认知、剖析、开掘和干涉。上面将围绕上述几点进行案例开展。 1.2 触达伎俩 在用户来之前能够进行渠道优选与新客引流，用户来了之后能够对用户进行精准举荐、展现，用户来过走了之后能够对用户进行复购引流，在每个阶段，画像都能够施展重要作用。 1.3 买通技术与业务 为了促使用户画像在业务中有更大的效力，必须同时具备技术思维和业务思维。目前，在画像的业务利用中面临的问题是：技术人员对业务不够理解，只是单方面的理解画像的技术实现，因而对于画像利用方面会有思维局限；而业务人员有强烈的业务晋升需要然而不分明画像在业务中能施展何种作用，因而同样思维受限。所以，要充分发挥画像的业务效力就必须买通业务和技术。上面咱们别离按阶段开展，进行利用的介绍。 二、来过走了2.1 走了当前：找破绽，花钱测试买数据 逆向察看RARRA模型，从用户"走了当前"登程，对全链路业务进行复盘，剖析目前的产品是否存在问题，并对问题进行定位和优化。依据问题在细粒度的划分之后，再针对不同用户发展不同工作，如高价值客户寻找、自定义客户放大 ( 用户look-like相干的工作 )、针对不同客户群体采取不同营销和生产激活策略、依据客户群体散发优惠券、激活休眠客户和挽留散失客户。对于曾经走了的用户，一部分还会回来，还有一部分不会回来，对于这一部分不会回来的用户，能够充沛应用他们所留下的数据，帮忙咱们将来的业务倒退给予指导作用；比方后续的召回操作无法挽回的用户，对其在站内的行为与被召回或未散失用户进行比对，可能能够洞察他们生产的内容是否合乎其需要 ( 能够与搜寻行为联合一起来看 ) 等。 2.2 维度与拆分 刚刚说到，要对用户群进行拆分，能够从多种不同维度登程，例如对现状的统计，有PV、UV、GMV、回访、留存等，对趋势的统计如环比、同比、流动趋势等。具体的如何对用户进行拆分，要从业务登程，做到逻辑自洽，业务可解释，比方依据性别、年龄段、设施平台对用户进行拆分，这就波及了粒度问题，比方年龄段是将15~25岁还是将15~30岁划分为一个区间，安卓或iOS版本号如何划分区间。 以一个例子阐明如何实现逻辑自洽：对于举荐零碎中用户冷启动问题，咱们会剖析不同用户群在冷启动过程中，如男性与女性用户或者iOS与安卓用户，偏好的商品类目或者购买的商品类目是否有大的不同。比方咱们在业务中发现男性和女性存在不同，喜爱用订单或者转化率来定义，则统计之后发现男性和女性最喜爱的1000个商品中有60%是不同的。换言之，性别粒度的划分对于以后的统计维度有显著的区分度，因而应用性别标签是在理论业务中是具备可解释性的。粒度的划分同样能够采取此类的思路来进行决策。除了性别、平台，还能够应用机型、地区、新老用户标签、活跃度 ( 用户沉闷的天数 ) 等维度进行拆分。对用户进行划分后能够持续就具体问题进行剖析。 2.3 画像在投放业务中的利用 以一个投放业务中的例子阐明。有两个系列，一个是前一个月，一个是近30天的，统计投放的数据能够发现扩量之后留存变差，用户散失变得显著。依据上文提出的思路，咱们抉择依照平台和年龄对用户进行划分，划分之后，在系列1、系列2比拟中能够发现Android的用户占比降落，iOS用户占比回升，且20~30岁之间的用户占比变高，咱们猜想20~30岁的用户/iOS用户自身天然的留存状况会更好，这部分用户占比的降落会带来整体留存的降落。用户散失的次要起因是用户体验不够好，用户的需要没有失去满足。针对这一猜测，进一步剖析用户的用意。咱们在搜寻场景下对用户用意进行剖析，比方剖析不同用户群体Query匹配后果量的环比数据，统计搜寻无后果呈现的次数，剖析不同整体对搜索词的偏好，群体间的差别，以及搜索词下行为的次数。 剖析之后发现两个景象： 一是在用户留存率低的这部分用户中搜寻无后果的量减少了；二是呈现了一些奇怪的Query如BTS，这类词匹配不到搜寻后果。进一步在举荐场景线下排查用户行为状况，统计之后咱们发现用户在举荐后果的类目展示维度上与大盘靠近，阐明用户的偏好扭转，然而在被动用意场景和非被动用意场景下的用户需要都没有失去满足。根据察看到的景象，咱们进行了一个试验，针对低流存用户的用意或者偏好进行了专门的补货，比方针对BTS ( 防弹少年团组合 ) 进行了周边产品的补货以及聚合触达，之后用户的转化率有显著晋升，阐明当用户找到须要的商品时，所能达到的转化率比大盘要高。 2.4 Query被动用意 剖析Query场景是剖析用户用意的无效办法。 在业务方面，通过统计Query场景下的流量和业务趋势，能够发现用户对于明星、品牌、品类的偏好，流量的集中水平能够无效的反映出用户的偏好水平。同时用户流量的集中水平能够驱动咱们去发现供应端是否有问题，例如热搜内容无后果就属于供应端呈现问题。 在用户需要上，能够进行环比的比拟，如每周搜寻量环比比拟，例如连衣裙在搜寻量环比增长显著，那么能够进一步进行某些梳理，判断后劲品类在举荐等场景下进行后劲产品推送。对于平台商家、商品，联合用户画像标签，能够依据用户搜索词剖析平台内商家、商品的影响力，对商家进行划分，找出比方特色商家、优质商家、黑产商家等，进一步去剖析平台是否将优质的流量调配给了优质的商家。 2.5 画像在渠道优选中的利用 在渠道优选中画像能够用于解决引流问题和商品定位问题。进入站内的用户都能够称为大盘用户，其中有购买行为的用户称之为成交用户，成交量达到一定量级、留存高的用户称之为高价值用户。 以性别来对3类用户进行划分，能够发现从下到上三类用户中女性占比越来越高，对于平台收益而言最重要的是高价值用户，那么在用户引流过程中咱们冀望联合用户划分剖析后果能引流到更多的高价值用户，如果以后的高价值用户中女性占比更高，那么在引流时，优先思考女性用户更多的渠道进行投放。同时能够进一步剖析商品定位是否有问题，如男性用户比例升高是否是因为男性用户被男性商品吸引进入平台，但在平台内男性商品占比很少或者是价格段不现实，联合画像标签能够对站内商品定位问题进行进一步的剖析。 三、没来之前依据已有用户的数据，去领导对于新用户的策略制订。 联合已有的画像标签数据后果，和经营、投放或市场专家一起能够进行渠道或者标签的优选，例如比照Google和Facebook两个不同渠道的投放成果，或比照Google和Facebook的各自男性标签的投放成果，依据比照后果抉择更优渠道。通常状况下，一个渠道的用户群体不可能全副优于另一渠道，不同渠道往往在不同的用户群上各有劣势。 数据分析的后果能够给投放师肯定的领导，目前的AI在利用中会面临各种对接，如API对接等问题，理论的体验不够好，然而AI在规模化上具备显著劣势，作者认为AI+经营+市场专家可能达到更好的成果。一方面能够依据站内高互动率内容标签、竞品、热卖商品、以及站内热搜等去洞察用户的需要，进而驱动平台对于品类布局的优化。另一方面能够在投放前优化用户群体以及对应商品的圈选，依据渠道内用户需要针对性的进行投放，而非海量投放。 四、来了之后4.1 做好服务与用户洞察 用户来了之后，须要疾速反馈，不能只对已有用户群体做文章，当扩大到某一个新的用户群体，必然会有第一个用户，第二个用户，算法无奈依据大量用户给出论断，然而当用户达到1万，100万时须要疾速的反馈出用户体验不好或用户散失的起因。 新用户来了之后，须要做好服务和用户洞察。新用户面临着举荐中的冷启动问题，首先要帮忙新用户做好定位，抉择有区分度的标签对新用户进行划分，区分度能够用不同群体偏好的交加来掂量，如男性女性最喜爱的1000个商品的交加，而后依据划分的用户群给新用户举荐该用户群体最喜爱的商品，再依据用户实时行为获知用户的用意，对举荐后果进行调整。 用户进入平台后，有过搜寻行为的用户能够分为两类，一类是强用意用户 ( 用户搜索词是某一个品牌具体的型号，具备明确的属性信息，如iPhone 11 256G彩色 )；一类是弱用意用户 ( 搜索词比较简单，如裙子 )，强用意用户进入站内后同类目商品的点击比例衰减显著慢于弱用意用户，弱用意用户则靠近大盘用户。依据这一标签能够去干涉用户举荐后果，更好的做好用户服务，使用户体验更好。 4.2 做好内容区隔 做好新用户服务的同时，要保障老用户的体验不会变差。在内容平台的举荐场景下中，这类问题变得尤为显著。在产品笼罩用户十分大的状况下，平台必然会呈现趣味偏好差别十分大的群体，针对不同群体，要考量其不同需要，在内容上做好区隔。 ...

上篇剖析了我做过的一个实在的我的项目的研发过程中的种种问题，那么这篇就来解说一下咱们如何针对这些问题做麻利革新。 怎么用麻利做改良小瀑布模式的毛病在于它的沟通老本、期待老本、返工老本仍然很高，因而咱们能够思考从这3个角度登程去做改良。 我画了一个图来展现小瀑布模式和麻利开发的具体比照。 图中紫色管道是小瀑布模式，蓝色管道是麻利开发，两个管道是雷同的团队管道容量，换句话说，两种模式的工作载量是相等的。 横向是工夫线，从左到右，按需要提出开始直到此需要上线，即为此需要的生命周期。 首先，先说一下为什么这3个老本很高。 沟通老本 产品经理通常须要1-2小时来与业务方进行需要沟通，沟通完了之后，产品经理会有一个初步计划，而后会与团队外部的技术人员，测试人员等，一起评审这个需要，如果这两头有任何疑难，产品经理就须要不停的重复在业务方与技术人员两头进行沟通。因而沟通老本是比拟高的。 产品经理通常也须要1-2小时来与技术人员一起做技术评审，工夫比拟长，很多问题细节须要来回重复确认，沟通老本很高。 总结一下就是，因为需要粒度比拟大，每个环节都比拟重，有大量的细节须要探讨和确认，因而带来了较高的沟通老本。 期待老本 开发只有等产品文档齐全设计好了，能力开始开发，因为需要粒度过大，此设计过程绝对过长，因而开发的等待时间也长，没有充分利用开发资源。 同理，测试也是，只有等开发提测了能力做测试。但测试在此之前，会先写测试用例，因而测试资源节约还算较小。 但另外一个问题是，测试一次性要写十分多的用例测试，一次性测那么多用例，测试的完整性齐全依赖于测试人员的急躁。 返工老本 测试如果发现问题，会让开发返工，因为需要粒度比拟大，经常出现测试发现多个问题的状况，那么就会来回的屡次返工与测试。 甚至有时候返工会间接返到业务方去从新确认需要的细节。 麻利研发过程改良那么麻利是如何改良这个过程的呢？ 首先麻利是提倡小步快跑，拥抱变动。目前因为需要粒度比拟大，无奈小步快跑，同时开发到两头的时候的，需要忽然变动，应答起来也比较慢。 那咱们就能够依据下图来进行革新。 上图中最大的变动就是把原来的需要A拆解成了3个story。 麻利提倡小步快跑，那么治理需要也一样，只有需要足够小，才更利于咱们疾速了解和剖析。而user story（用户故事）则是麻利外面的一个能够工作的最小单位。 用户故事在软件开发过程中被作为形容需要的一种表达形式；为了标准用户故事的表白，便于沟通；蕴含角色、流动、价值三个因素。瀑布式的需要治理和麻利需要治理的区别在于： 瀑布式的需要剖析要求在一开始就获取所有需要，剖析所有细节，并且假如咱们能够对软件我的项目有个完满的预测。而用户故事则基于咱们不能完满预测，不能在一开始就晓得所有细节的根底。因为咱们对需要的了解是一个逐步清晰的过程。同时，在我的项目开始时尝试编写所有的需要疏忽了重要的反馈循环。用户故事抵赖故事的工夫维度，随着工夫的推移以及性能的减少，会有新的用户故事产生，或者使故事的相关性发生变化。所以要提早细节，融入业务到整个软件开发过程中，激励交换和沟通。另外，做了用户故事拆分之后，产品经理或者BA须要补全细节，不停的做需要廓清，和业务方做sign off。麻利需要治理会借助JIRA等工具进行可视化的看板或者scrum治理。而不是基于传统的Excel治理。每个故事写好之后，会让业务方做card sign off，比方在卡上面留言ready to go等。如果每张卡做sign off太频繁，能够由产品经理或BA独自找业务方用邮件等的模式针对一个epic对立做sign off。麻利里其实没有一个专门给业务方和产品经理/BA的需要廓清会，因为默认为曾经产生在日常工作中了，按理说应该剖析一张卡确认一张卡，能力尽可能减少因一张卡片了解不到位引起的大面积返工。拆解成小的用户故事之后有如下一些益处： 原来产品经理和业务方的沟通老本随着需要被拆成小的用户故事而变小了。因为用户故事比拟小，剖析实现的工夫就变快了，产品设计的工夫也变快了，那么开发开始的工夫也就变快了，缩小了期待老本。因为开发工夫更短，第一个用户故事测试工夫也就提前了，因而如果呈现问题须要返工，那么返工的工夫比原来就更早，返工批改的内容也更少，能较快的实现返工并从新测试。整体返工老本就变小了。因为各方工夫都提前了，那么第一个用户故事上线的工夫也提前了，业务方就能更早的看到需要的局部性能，就能更早的反馈问题。因为每个环节的沟通老本，期待老本，返工老本均缩小了，因而整个需要的交付工夫也就提前了。从下图就能够看出，每个环节相比之前都是提前的。麻利的目标是可能让团队拥抱变动，疾速响应。 麻利开发改良分支改良原来的分支治理比拟凌乱，可能造成的问题曾经在后面剖析过了。 这里就说说分支治理的最佳实际是什么。 当初业界广泛都采纳了git flow，具体怎么做能够Google一下，网上有太多文章讲这个，我就不赘述了。这里就展现一张git flow的全景图。每次git的commit message的举荐格局：Card ID: message Type次要有：feature, refactor, fix等。每次git的commit举荐能关联到每个故事卡的卡号，这样不便追溯每个故事卡相干的改变。当初很多工具都反对通过message的卡号间接找到对应的故事卡，反之亦然。CI/CD从代码的生命周期开始，CI/CD是保障每个环节疾速流转的根底，同时也是疾速获取反馈的路径。而CI的根底则是自动化测试，比方最根本的单元测试。每实现一张故事卡，实践上都能够继续部署到生产环境。而不应该期待所有需要都实现了，或者等前后端都实现了，再做上线部署。 部署的步子越小，回滚的老本也就越低。总结图里的麻利开发肯定比下面的小瀑布快吗？不肯定，这里还有几个因素是须要思考的。 需要A拆解成story是有老本的。依据产品经理或BA的能力不同，以及需要复杂度的不同，拆卡花的工夫也不同。小瀑布模式外面，在没有bug的状况下只会测试一次。在麻利模式下，相比原来的小瀑布，会针对story1和story2做回归测试。因而减少了测试工夫。另外，决定麻利开发是否运行很好的因素还有很多，只有一直探寻最佳实际，继续改良，能力有限迫近咱们冀望的状态。总结起来，麻利是通过小步快跑的形式，晋升了响应变动的速度，以达到晋升整体交付速度与品质的目标。 本文只是通过一个实在的客户案例，来剖析如何基于以后现状做麻利革新，本文并没有写齐全部麻利革新的内容，因为麻利蕴含的内容切实太多了，如果大家感兴趣能够给我留言，前面我会持续分享这个案例中波及到的其余麻利革新。

背景最近我去一家科技公司做麻利征询，通过梳理该公司的研发过程，发现了该公司的研发过程中许多能够改良的中央，于是我便记录下来，与大家分享学习。 本文会分析该公司的研发过程，把每个环节详细分析一遍，以找出研发过程中的问题和能够改良的中央。而后再解说如何做麻利革新。 研发过程剖析全景图下图是该公司的研发全景图，从工夫线来看，下面一条工夫线能够看出整个需要流转的生命周期，上面一条工夫线能够看出整个代码流转的生命周期。 上面咱们就把每个环节拆开来仔细分析一下。 需要治理现状 当初是通过共享Excel来治理所有的需要，业务方在表格外面填写想要的需要，包含新需要或bug等，并为每个需要生成一个序号不便追踪。 大略长下图的样子。这是十分典型的传统需要治理形式。 问题 大颗粒的需要能够这样治理，然而不能所有阶段都这样治理，会造成需要粒度太大，细节太多，边界太含糊。如果不做story拆分，这样的需要离能开发还有很多空间，须要做拆分、细化、转化，最初能力开发。这样的需要表格不足很多细节，比方UI长什么样子，某个业务逻辑有多少条分支等。这样的表格无奈晓得业务方和研发方对需要的了解是否统一，很容易呈现返工。此类表格治理需要，不便于业务方追踪需要进度和状态，以及可视化需要的转化过程。需要评审现状 产品经理会和业务方一起散会，针对表格外面的某个需要，来确定这个需要的细节，以及怎么做。确保单方的了解是统一的。 问题 需要评审会的时候没有记录过程中确认的论断，导致会后大家又遗记过后的论断是什么。因为需要粒度过大，很多细节无奈详尽的确认分明，容易导致返工。因为需要粒度过大，须要比拟长的工夫来实现需要评审，通常会花2小时以上。没有sign off，无奈断定需要是否通过了业务方的认可。需要廓清是一个随时随地的动作，但该公司不足能随时做需要廓清的气氛或文化。产品设计现状 拿到需要后，产品经理会依据需要以及和业务方的沟通，达成统一后开始设计产品文档，把需要波及到的原型图，业务逻辑等全副画到产品文档上，以提供给开发人员进行开发。 问题 需要通常都很大，产品经理很少把需要拆分成story，也很少在JIRA等工具上拆卡建卡来治理所有的需要。导致产品设计周期很长，细节很多，无奈一次性思考全面。产品经理设计产品文档的时候，通常是本人设计，设计好了再给业务方或者开发看。没有频繁反馈和需要廓清，导致需要可能被脑补，并不是业务方想要的。产品文档目前是用版本管理工具来治理的，比方git，不便与查找和归档。需要、产品文档、代码没有关联关系，不不便前期查找某个需要相干的产品文档和代码。技术评审现状 目前，产品经理设计实现后，会拉上开发和业务一起进行技术评审，确保设计的产品文档三方能达成统一。 问题 因为需要太大，评审工夫太长，通常超过2小时，长此以往大家会越来越恶感这样的评审会议，并且会议前期大家的注意力也不集中了。细节太多，容易疏忽某些细节，导致最初开发仍然有不确定的开发细节，并且开发的后果和业务方的冀望不匹配。开发现状 拿到产品文档之后，后端会依据文档中的业务逻辑，开发实现服务端的性能，前端会依据文档中的原型图或者高保真UI设计图，开发实现客户端的性能。 再来说说该公司的分支管理模式。 他们把分支分为了：线上分支（master），测试分支（stable），开发分支（dev）等。 保障不同的分支做不同的事件，避免分支净化。 线上分支（master）：是预上线环境和线上环境的分支，以这个分支为准，其余分支都是以这个分支为根底拉取。测试分支（stable）：测试环境分支，是给测试团队测试应用，如果有些性能在本地及开发不容易测试，开发人员能够到测试分支进行自测。开发分支（dev）：开发人员自测。分支命名标准：姓名+需要名+日期 分支会依据上线须要，merge到stable进行测试，或者merge到master进行上线。如下图。 问题 分支管理混乱，每个分支既可能合并到dev，也可能合并到master，起因是因为这样能够解决仅局部性能要上线的问题，哪个性能要上线，就合并哪个分支到master。 实践上，拉了分支开发的代码都是应该要上线的，不上线的代码会节约开发资源。分支开发的工夫也不应该太长，太长会导致代码抵触变重大，回滚老本变高。如果是因为测试没做完而临时不上线，那可能是因为分支所代表的性能粒度太大了，测试工夫太长，应该从源头开始拆解需要。如果是因为业务变更而临时不上线，应该应用feature toggle来解决。性能分支尽管写了开发者名字和需要名，但仍然很难关联具体的需要是哪一个。尽管规定了从master拉取分支，但大家有的从dev拉取，有的从stable拉取，没有对立标准。分支命名中的日期意义不大，因为分支实践上存在的工夫应该尽量短，能力防止更多的抵触，缩小review的工作量，以及缩小回滚的老本。其次分支拉进去的工夫在git上都能清晰的看到。开发很少做需要廓清，会依照本人的想法实现某个需要，遇到不确定的中央没有和团队探讨，没有找产品、业务确认。会导致最终实现和业务方的冀望不匹配。没有code review，无奈对立开发团队成员对代码的标准，无奈及时发现代码中的问题，无奈做代码层面的常识传递。没有写单元测试，无奈做到研发自测与品质内建，无奈保障代码的正确性，无奈保障其他人不会毁坏原有代码性能，无奈继续集成。没有CI/CD，无奈及时获取反馈，无奈疾速部署，无奈疾速发现问题。提交测试现状 开发实现开发工作之后，本人测试通过了之后，会交给测试人员进行测试。测试人员在提测之前会依据产品文档先写测试用例。 问题 提测的过程靠口头传递，测试人员无奈可视化的晓得开发进度，做了哪些改变，能够部署哪个环境，应用哪个版本。测试现状 测试会依据写好的测试用例对性能进行测试，如果发现问题，会返回给开发，让开发修复。 问题 测试用例目前是用独自的工具来治理，没有和需要关联起来。测试实现之后，没有对业务方的showcase，无奈获取业务方的验收反馈。上线现状 每个需要基本上都蕴含了前后端，因而会等前后端都开发测试实现后，再一起做上线。 问题 上线内容比拟多，一旦出了问题，会导致回滚老本比拟高，定位问题比较慢。上线工夫比较慢，不能让业务方疾速看到最终的性能。总结这样的研发过程梳理完了之后，会发现其实这样的过程就是咱们俗称的小瀑布。它的特点是相比传统的瀑布模式它更轻量级，但相比麻利，它又更重量级。目前很多公司都在采纳这样的小瀑布模式。 小瀑布模式的毛病在于它的沟通老本、期待老本、返工老本仍然很高，还有能够优化的空间。同时整个过程中，需要评审、技术评审、用例评审都做得比拟重，每次评审的内容都十分多，工夫十分长，细节十分多。整个过程中的所有产出物并没有明确的关联关系，也没有对立的管理工具和存储地位，随着工夫的推移，所有常识治理将变得越来越难，新人的学习老本将变得越来越高。软件我的项目中的信息量会在耳濡目染中变成异样高的复杂度。环节与环节之间没有文字记录明确一个环节的完结与开始，比方开发到测试。基本上是靠成员之间的口头传递。最初还发现该公司不是全功能团队模式，而是按角色分的，一个角色可能会同时负责几个我的项目，比方A开发上午在写X我的项目的代码，下午可能在写Y我的项目的代码了。依据这些现状问题，具体怎么革新，将在下篇来具体解说。

大学校园里流传最广的一句话是什么？“防火防狼防师兄”。为什么师兄这么可怕？其危险水平仅次于洪水猛兽。为什么不论本人什么吊样的师兄总能拿下如花似玉的师妹？这个问题直到走上工作岗位，并开始做产品研发接触到“用户画像”才豁然开朗。 原来每一个俘获芳心的师兄都是画像高手啊！师兄在向师妹表白之前通过了一些列的过程对其进行画像。和她一起上食堂打饭理解她吃饭的口味，和他探讨豆瓣上的评分理解她看电影的品尝，跟她探讨业余问题理解她的思维习惯，组织实验室团建理解她的性格特征，跟她的闺蜜打听她的兴趣爱好。所有这些信息收集结束后，对师妹造成了一张残缺的用户画像，从而有针对性的开展谋求守势，在貌似无意间体现出本人满足她所有对于将来伴侣的设想特色，这时候哪个妹子还能把持得住，无一不成囊中之物，师兄果然高超啊！ 咱们在做产品开发中采纳用户画像和师兄谋求师妹的情理和思路一样。要设计出合乎用户情意，最大限度满足用户需要的产品，须要对用户做全面粗疏的理解，绘制出精准的用户画像，能力开发出高满意度的产品。和师兄的指标对象不同，用户画像不是针对单个用户，而是对整个用户群体进行共性特色的提取，也就是给用户“打标签”。用户画像针对指标用户的实在特色进行勾画，从而造成指标客户的综合原型。下图为某手机游戏开发商设计的用户画像。 通过这张用户画像能够很分明的确定该款手机游戏须要单手可能操作，因为上下班的地铁或公交中上须要腾出一只手来握紧扶手及进出站刷卡；此外还须要游戏工夫不长，最好一局游戏可能3分钟解决，否则在厕所蹲坑的工夫过长容易引起身材部分的不良反映…… 上图只是一个简略的用户画像，而咱们产品设计前的实在画像往往要比这简单得多。用户画像的绘制是一个从具体到形象再到具体的过程。个别状况下能够分为三步进行 一、信息采集数据是实现用户画像的外围根据，没有数据撑持的用户画像都是夸夸其谈。数据采集的起源有很多种，其中较为罕用的几种是考察问卷、用户访谈、统计数据和参考报告。前三类数据属于一手材料；而最初一类是二手材料。 二、剖析建模剖析就是在数据采集的根底上进行统计分析，不同的数据起源分析方法有所不同。例如方才提到的用户访谈，其后果剖析个别采纳关键词提炼法。即提取访谈对象对每个问题答复中的关键词，而后对每个问题答案中的关键词进行频次排序，最初选出其中高频词作为共性剖析后果。 数据统计须要依照当时设计好的维度来进行，这就须要进行建模。下图是某商家对用户特色设计的模型，它依照用户根底属性、社会关系、生产能力、行为特色、心理特征对用户进行建模。 三、双向验证在通过了具体的数据获取到形象的模型剖析后用户画像最终要有一个具体的出现。用户画像的出现须要有以下几个特色： 用户画像要在事实中去验证和欠缺，这种验证是双向进行的。既要验证模型是否反映了事实也要验证事实是否在模型中失去体现。前者的重点是精确，而后者的重点是全面。 构建用户画像的目标是为了充沛理解咱们的用户，进而为产品设计和经营提供参考。如果做出的画像无奈领导产品设计并为经营布局及策略制订提供参考的话，那么这个用户画像肯定是失败的。如果你的领导让你负责做一张用户画像，那么他想要的相对不是画像自身，而是针对用户画像的论断而提出的经营倡议和设计思路。 此外，咱们在做用户的时候很容易进入两个误区：其一是把本人当作用户。咱们每个人都有本人的用户，大家总是不盲目的把本人当作用户。根据本人的爱好来判断用户的爱好，用本人的特色来形容用户的特色。用户画像的根底数据起源肯定要主观、实在，自以为是的态度是没法做好用户画像的。其二是满足更多人的需要。设计产品的时候咱们总是雄心勃勃的想要一统天下，让所有人都成为产品的忠诚用户。而商业教训通知咱们没有用户聚焦的产品就没有用户。瓜子网针对的是二手车买家；滴滴面向的是打车一族；知乎的用户群体是知识青年；市场上能存活下来的产品没有哪个是针对所有群体的。 以上咱们对用户画像过程以及容易呈现的误区做了一个简略的介绍，更多业余的内容还须要各位进行深刻的学习。用户画像所提倡的用户思维不仅仅能利用于产品设计，同时对于咱们研发人员来说也能使用他更好的与业务需求方单干。 最初，列车长心愿各位学员可能融汇贯通、学以致用，更好的理解咱们的用户。 起源：IDCF社区作者：陈炯系统集成项目管理高级工程师某大型国有银行高级品质治理师从事IT项目管理工作十余年具备丰盛的开发与治理教训公司外部麻利转型的发起者之一深度参加麻利实际与总结

需要文档是咱们在开发中罕用的一类沟通形式和媒介，它承载着需求方的冀望，同时也标记着一系列事项的生命周期。 不同部门、不同受众的需要文档各异，例如经营人员向产品人员提出的流动需要、产品人员向开发人员提出的性能需要、开发人员向运维人员提出的服务撑持需要、各小组外部共事之间相互提出的需要等等。 为何须要需要文档？大部分场景下需要提出方和需要承接方都存在不小的信息差，需要提出方罕用的语句是“我须要做成这样”、“越快越好”、“怎么用你不必管，给我就行”、“这不是我想要的”、“我想要的其实是那样”。 一个人常常否定本人的抉择和语言的景象是存在的，无论无意或无心，但这无疑会消耗单方的工夫和精力。需要文档不仅能够作为单方沟通过程中的清单，还能够作为单方抉择和执行的日志，有了需要文档，就可能防止因前后矛盾导致空耗的问题。同时，需要文档能够清晰地体现参加人员的劳动成果与劳动价值，是自我总结的良好根据。 需要文档通用模板参考一百种需要有一千种提法，但需要中的事项相差却无几。这里给出了一份需要文档模板，大家能够将其用在工作当中，作为不同人员之间的信息传递媒介。 要留神的是，需要和执行是双生相伴的，因而这里的上面这份参照文档与其说是需要文档，不如说是工作执行记录，因为它记录着这个工作从产生到执行结束的残缺生命周期。 为了不便大家了解，文档选用不同色彩来帮忙咱们辨别阶段，其中： ???? 浅粉色区块出现的是文档的根本信息；???? 浅蓝色区块出现的是需要主体与需要生命周期主体；???? 浅绿色区块出现的是需要生命周期靠近开端，行将达成目标； 为什么要这么设计？置信各位见过不少的需要文档，因而对下面这份参考也有不同的认识，可能不禁会问： 为什么设计成这样的构造？怎么不必在线需要文档管理工具呢？必填项和非必填项如何体现？这份参考如同不能满足所有开发场景？为什么设计成这样的构造？需要文档该当涵盖从需要产生到需要实现交付的残缺过程，例如需要是在什么样的场景下产生的、到底要做成什么样、须要什么时候实现、以什么模式交付、需要是否可能实现、需要实现过程中做了哪些、交付的后果是否达到预期等。 咱们能够将残缺过程分为以下几个阶段，以便更好地开展工作： ???? 需要形容???? 需要调研???? 需要评审???? 开发/施行???? 阶段验收???? 测试/数据验证???? 上线 依照这个构造，咱们可能设想工作流大抵如下： 首先需要提出方给出需要的背景、具体事项形容等信息，帮忙需要承接方更好地了解，同时提出对交付工夫、交付形式的冀望。需要承接方收到需要信息后须要做初步的调研，理解需要实现过程中的要害项并记录不明确的事项。 接着，单方初步接触后约定工夫对需要进行评审，单方的探讨将基于调研期间取得的信息开展，在评审讨论会完结后通常会确定需要是否能实现、需要改变项、交付形式、交付工夫、最终参加人员等。 而后评审通过，需要承接方开始进行开发/施行。需要承接方要记录这个过程中谁在什么工夫做了什么事并失去怎么的后果、期间是否呈现了哪些变动。 需要提出方可能会阶段性地跟进事件停顿，并帮忙需要承接方确认工作和工作后果没有呈现偏差，同时单方调换一些信息。 开发/施行靠近序幕或实现后，需求方组织人员测验成绩，测验通过则告诉需要承接方交付/公布上线，测验未通过则做相应调整。 版权水印 - 微信公众号 Python 编程参考除了需要背景、开发/施行相干的信息外，需要文档自身也须要提供一些根底属性，用以对需要进行整顿、分类、追溯、总结等，所以在需要文档的结尾设定了一些重要信息栏，例如： ???? 需要重要等级；???? 需要发动日期；???? 需要完结日期；???? 需要发起人及对应部门；???? 需要承接人及对应部门；???? 需要所属的业务类型；???? 需要关键词；???? 也求所属业务的名称；???? 需要关注者；???? 需要编号；???? 需要名称； 团队外部能够定义对立的需要等级，例如紧急且重要的设为 A、紧急但不重要的设为 B1、重要但不紧急的设为 B2、不重要也不紧急的设为 C 等，这样大家在参加需要的时候可能正当地调配工夫和资源，优先解决那些等级高的需要。 怎么不必在线需要文档管理工具呢？市面上的需要文档管理工具繁多，Python 编程参考心愿在不依赖特定工具的状况下向大家介绍需要文档，各位在了解需要文档后再联合工作中用到的管理工具，效率定会更高。 实际上工作中总是会用到各式各样的管理工具，工具能够很好地帮忙咱们关联文档、汇总信息。例如一个编号为 TK2020120101 的需要实现后，后续又衍生出针对它的保护类需要 TK2021010103 时，能够将保护类需要 TK2021010103 与 TK2020120101 关联起来，这样在治理需要文档的时候就可能直观地看到需要之间的关系和变动，具体如下图所示。 理论工作中大概率会用到管理工具，工具能够进步咱们的效率，便于咱们治理事件，借助工具是十分好的抉择必填项和非必填项如何体现？实际上这份文档蕴含的区块都是必要信息，但区块中的子项能够依据理论状况省略。 首先，浅粉色区块的需要文档根底信息局部是必填的，这里的内容是整个需要的缩影，所以一个格子也不能少。 其次，浅蓝色区块的主体局部是能够省略的，例如有时候需要调研和需要评审能够放在同一时间开展，划分到需要评审即可；例如子项详细描述中的注意事项、交付要求等选项也是能够依据理论状况省略的；如果需要并不简单，或者说工夫周期也不长，那么子项阶段验收能够省略，在数据验证阶段校验即可；如果没有预上线，或者需要并不需要上线，那么能够省略浅绿色区块局部的项。 最初，如果感觉下面的阶段还不足以记录残缺的需要生命周期，能够依据理论状况减少阶段或子项； 这份参考如同不能满足所有开发场景？当然，开发场景千千万万，Python 编程参考提供的这份需要文档作为根底，各位在具体应用的时候能够依据团队状况和业务状况自行调整文档项。 ...

任何产品的更新迭代都离不开用户的应用反馈。产品经理日常须要奔波到一线部门理解用户的应用反馈；一线经营或业务团队日常须要向产品经理转述用户的问题场景及督促需要的进度。两头须要耗费大量的精力来进行信息转达。 为了突破一线经营与研发团队之间的信息流通壁垒，CODING 一站式软件研发治理平台与腾讯兔小巢用户意见反馈平台在产品上进行了单干买通：兔小巢的用户反馈帖子与 CODING 中的开发工作或缺点互相关联，产品研发人员可疾速对用户的问题溯源，一线经营人员即时可见问题的解决进度。通过该服务促成经营与研发严密合作，实现从用户端到产品端需要迭代流转闭环，进步产品迭代速度。 对于腾讯兔小巢兔小巢是一个轻量、收费的用户意见反馈服务平台，能够疾速搭建用户反馈社区，帮忙产品团队更好的凝听用户。目前反对 APP/小程序/web/公众号等多种应用场景，曾经有 7000 多个产品正在应用兔小巢，包含腾讯 QQ，腾讯文档，扇贝单词，CODING 等。每个月有 200 万的用户反馈在兔小巢平台上进行。 突破壁垒，无间合作简略操作轻松绑定注册 CODING 与兔小巢账号后，CODING 用户可在 CODING 「我的项目设置 - 集成配置」中受权绑定兔小巢账户，操作方便快捷。 TIPS：兔小巢新用户第一次应用时须要实现反馈社区产品的创立。 兔小巢用户可在已建设的兔小巢产品「产品设置 - 平台关联 - CODING」中点击新增绑定，跳转 CODING 平台创立团队及我的项目，并实现初始化我的项目后即可开启无间合作。 TIPS：绑定流程须要从 CODING 发动，CODING 老用户可间接应用 CODING 侧绑定流程。 用户反馈与需要/缺点联动，信息实时同步绑定后，从兔小巢反馈详情页即可发动创立事项、关联事项或解除关联等操作，并具体展现事项状态、解决人等信息。一线经营服务团队在用户反馈的工单内即可疾速给产品研发团队创立需要/缺点，即时可见关联需要的解决进度及负责人。让经营与研发沟通更加高效，治理反馈更加简洁有序。 疾速对用户反馈的问题溯源，聆听用户的声音同时在 CODING 「我的项目协同 - 事项详情页」中也可查看以后关联的兔小巢反馈，帮忙产品研发人员疾速理解用户原始反馈，追溯需要的上下文情境，缩小来回沟通老本以及信息失落危险，聆听用户最实在的声音。 CODING 与腾讯云兔小巢的集成买通，实现了产品从用户需要到开发上线过程的端到端信息流转，为您的团队提供残缺研发管理工具链的同时，补齐了一站式解决用户反馈、需要收集的场景能力，让产品迭代和用户反馈之间的连贯更加间接、简略，促成产品的正向倒退。 点击开启高效云端研发工作流

摘要：企业在做麻利转型中，需要无奈按时交付的困扰你是否也遇到过呢？背景在之前组织的一次麻利线下流动中，有家企业问道：“咱们公司刚做麻利转型不久，遇到一个比拟头疼的问题——团队每天都很忙，从转型到当初曾经两个多月了，根本没有一个迭代能做齐全部工作，问题出在哪？”该问题一提出后，引发了强烈探讨： “咱们公司也是，总有那么几个人完不成手头工作，每次拖后腿让客户不称心”； “最近咱们我的项目用了个新框架，很多人他没用过啊，不晓得从哪下手，我的项目评审的时候一片惨淡”。 其实上述几种状况归根到底都属于需要无奈按时交付，相似这样的困扰你是否也遇到过呢？ 问题剖析在交换中，笔者理解到每家公司的状况： 背景中第一家企业在第一个迭代认领了15个故事，团队很容易就实现了；老板感觉以团队的能力能够做到每个迭代实现30个故事，于是后续每个迭代都心愿团队认领30个故事，团队认领30个工作后，累死累活只能实现20左右的故事；第二家企业研发团队8人，每个迭代总有两个成员工作完不成：团队每天早会失常开，然而总感觉那两个成员整个迭代都在做那一两个故事，做的性能也没啥停顿，有时候还做不完；第三家企业应用了一个新框架，近两个迭代团队按以往的速率进行工作认领，后果因为团队对框架不熟，每个迭代只实现了冲刺待办列表中一半的故事。笔者联合交换后果及以往教训，对需要延期交付的起因进行了如下剖析： 需要延期交付通常有两方面起因——团队主观原因以及客观原因。客观原因通常是由过程方面的阻塞造成的，比方团队须要购买一批云资源，公司规定资源洽购须要老板最终审批签字方可施行，刚巧赶上老板出差无奈签字，导致工作卡在最终审批环节无奈交付。 没有客观因素烦扰，需要无奈按时交付通常就是指团队手头工作在迭代完结前无奈全副实现，这是主观原因。造成团队手头工作完不成的起因有很多，背景中提到的起因可概括为以下三种： * 冲刺待办列表故事过多冲刺待办列表是打算会议的输入之一，打算会议上团队依据团队速率认领故事，造成冲刺待办列表；如果团队速率被高估或者个别故事估值偏小，则冲刺待办列表中的故事点数绝对团队实在速率就会偏多，最终导致工作过多，迭代完结时局部需要无奈按时交付。 冲刺待办列表中故事过多还有一种可能：打算会议输入的冲刺待办列表是正当的，可是因为一些突发因素，产品负责人向迭代插入了新的工作，导致冲刺待办列表故事太多。 * 工作技术难度较高我的项目应用了新的框架、语言、工具等，团队之前没接触过，须要肯定工夫去磨合，所以后期不免呈现提早交付。工作技术难度较高是绝对于团队平均水平来说的，如果团队整体技能程度偏单薄，比方都是团队成员都是刚入行的新人，一般研发工作绝对这个团队来说都很艰难，这种状况也很容易呈现提早交付。 * 个别员工工作完不成团队某位成员销假了，本来打算实现的工作因为销假只做到一半，所以最初无奈按时交付；另外如果团队成员没做到自组织，在我的项目中收工不出力，也容易导致迭代完结手头工作没有实现；最初如果团队成员工作遇到阻碍被卡住，该成员不向团队裸露阻碍，而是始终本人孤军奋战，也会导致需要延期交付。 除销假外，其余两种状况都能够通过麻利的危险管控办法（如每日站会）防止产生，所以这种状况也能够总结为团队危险管控没有做好。 解决措施针对剖析中客观原因局部，团队能够通过建设Backup的模式进行防止。以洽购为例，项目经理或老板秘书做老板的Backup，当老板因为本身起因无奈亲自审批时，Backup可向老板汇报，征得老板批准后代替老板审批，防止流程方面的因素影响团队交付，也体现了麻利宣言中的“个体与交互胜过流程与工具”。 针对团队主观原因局部，本文基于正当发展麻利流动给出如下措施。 针对冲刺待办列表故事过多冲刺待办列表故事过多的次要起因是高估团队速率，故事大小估算谬误以及迭代中有新需要插入。针对这三种状况，给出如下解决方案： 正当估算团队速率，依照速率认领故事团队速率是团队在迭代中认领多少故事的根据。 在麻利转型初期，因为团队没有历史数据做参考，很容易估算错团队速率，导致冲刺待办列表中故事过多或过少——故事过多则可能导致延期交付；故事过少，则会节约开发资源。如何估算团队速率呢？ 确定开发团队每天在开发工作上投入的工夫（刨除会议，接打电话，收发邮件等工夫），将工夫乘以迭代天数，即可得出迭代中团队用于开发冲刺工作的生产力。而后团队从产品待办列表中抉择一系列故事，预估这些故事的实现工夫和用于开发冲刺工作的生产力相近，而后统计这些故事的点数，即可估算出团队速率。起初估算后果可能不精确，然而通常团队对速率的估算会随着迭代进行而更加精确。 举个例子：团队5个开发人员，其中三个人每天有6.5小时用来工作，其余二人每天有6小时能够工作，迭代两周（10 工作日），那么团队可工作的工夫总和就是（6.5×3+6×2）×10=315。咱们从产品待办列表中抉择315小时左右的故事放入冲刺待办列表。冲刺待办列表详细信息如下（本文故事由华为云DevCloud进行治理）： 由图可看出团队速率大略是33左右。也就是说，打算会议中团队从产品待办列表中抉择30个故事点的故事放到冲刺待办列表，进行开发，团队有可能全副交付，而抉择50个，则全副交付是有艰难的。 依据团队速率认领故事，能够让团队不自量力，无效地缩小延期交付。 正确估算故事大小除了对团队速率估算谬误，对故事大小估算谬误也容易导致提早交付，对于故事大小的估算办法能够参考【DevCloud · 麻利智库】如何估算第二篇：利用外围概念解决估算常见问题 需要置换麻利迭代中因为工夫盒和工作量都固定，如果有新需要退出迭代——比方生产环境忽然发现一个之前没测出的Bug，须要修复，迭代工作量可能会超出团队生产力，导致提早交付。 呈现这种状况时，团队应该如何应答？首先团队须要向产品负责人确认新需要是否应纳入本轮迭代，做到需要起源惟一；当确定需要要做，产品负责人将新需要以用户故事模式放入冲刺待办列表中，而后和团队一起从新梳理冲刺待办列表；将工作量与新故事相近的低优先级故事移出本轮迭代，放回产品待办列表，以确保以后迭代团队工作总量不变，造成需要置换。 Tips：团队在打算会议支付工作时，不要支付的太满，最好预留一些缓冲工夫，以便于应答突发状况。 如果产品负责人迫于领导或客户压力，不容许需要置换，只能向冲刺待办列表中硬塞故事，这时候应该怎么办呢？在麻利中，Scrum Master作用之一是表演团队的“保护伞”，让团队集中精力去实现迭代指标。如果产品负责人强制的向迭代中增加故事，Scrum Master可与对方沟通，弄清楚对方为什么向迭代中插入故事——之前整顿故事有脱漏或者发现了以前未测出的Bug，还是对方不晓得Scrum不倡议向进行中的迭代插故事。如果是需要脱漏，应该在回顾会议上总结经验，日后防止；如果对方不理解Scrum，能够通过解说Scrum相干常识，让对方了解为什么Scrum不倡议向进行中的迭代退出新故事，当前防止这种状况产生。 加班也是一个应答突发问题的抉择，然而钻研表明短期加班会提高效率，长期加班团队成员会因劳动有余，注意力不集中等起因升高效率。长期加班除了不利于团队建设之外，不定时的加班对团队速率也有很大影响，而麻利提倡可继续倒退，所以加班解决突发问题属下策。 针对工作技术难度较高对于我的项目技术难度要求超出团队能力，成员无奈估算工作量或无从下手导致我的项目交付延期的状况，能够利用“探针（Spike）”技术评估我的项目。 探针是一种麻利实际。当遇到无奈估算，或无从下手的故事时，团队能够从这个大故事中宰割出一个小故事，而后对小故事进行开发，这个小故事就是探针。探针的开发实现工夫可作为估算整个故事实现工夫的根据，后续估算有了根据，就会精确很多，提早交付的危险也会随之缩小。 当然除了探针技术，团队成员的技术培训也是必不可少的——团队内技术分享或培训，能够进步团队整体技术水平，从而进步研发效率、缩小个性提早交付的危险。 针对个别员工工作完不成每日站会是一个很好的危险管控工具。迭代中的每一天都能够看成是一个小迭代，每日站会通过保障小迭代失常运行，进而保障整个迭代的稳固进行。每日站会如果只汇报工作，通常会变得浮于模式，各种危险可能也无奈被确认，最初导致每日站会施展不了本身作用。认真开好每日站会能够预防提早交付。 团队成员在每日站会“前一天做了什么”，“明天要做什么”的根底上，陈说工作详细情况以及具体进度，这样能够让团队的工作状态更加通明。从团队危险管控角度来看“我昨天用了5小时开发A性能，目前A性能开发了50%，明天预计再投入5小时，开发至80%”比“我昨天开发了A性能，明天要持续开发A性能”要好得多。 另外借用一些项目管理工具，能够更直观的看出员工的工作状态。以华为云DevCloud项目管理性能为例，在故事中，能够分明地看到员工的理论工时和故事的完成度，便于理解和把控故事提早交付的危险。 没做好危险管控会影响故事的按时交付，每日站会通过“我遇到什么危险”辨认团队遇到的危险。遇到危险时，首先团队成员能够指定团队中某一成员，让其帮忙分明危险；当然团队成员也能够被动帮忙革除危险。如果团队内没有人可能革除危险，这时候Scrum Master就应该施展“清道夫”的作用，通过协调外部或内部资源来解决危险，帮忙团队扫清阻碍，以确保我的项目能够按时交付。 想理解更多对于每日站会的内容能够参考：【DevCloud · 麻利智库】如何玩转每日站会？ 参考附录【DevCloud · 麻利智库】如何估算第二篇：利用外围概念解决估算常见问题 【DevCloud · 麻利智库】如何玩转每日站会？ Mike Cohn 麻利软件开发实际——估算与打算 北京：清华大学出版社 点击关注，第一工夫理解华为云陈腐技术~