作者：黄药师（黄隽）背景在某开发团队辅导的回顾会议上，团队成员对于优化估计具体方法上达成了一致意见。询问是否有什么具体的估计方法来做估算。问题分析回顾意见上大家对本次Sprint的效果做回顾，其中80%的成员对于本次Sprint的估算效果不满意，最终团队希望在下一个Sprint中，估算活动能有所改善。经了解，团队目前的估算方法很简单，基本上是架构师和团队中有丰富开发经验的成员一言堂。估算的速度也很快。对于有些有疑问的需求，开发成员也是保持沉默，草草认领了任务。团队迫切希望学习新的估算方法来优化目前的估算活动，因此分享几个具体的估算方法给团队实践，让他们自己选择适合、喜欢的估算方法是解决问题的关键。解决措施上篇《如何估算第三篇：利用故事点做估算》了解了什么是故事点后，我们来学习下具体的故事点估算的实践，感受一下估算。这里介绍最常用的两种估算方法：一个是计划扑克估算，另一个是敏捷估算2.0。下表内容展示了这两种估算方法在什么情形下选择。估算方法选择理由计划扑克估算ü  使不同技术水平和工作速度的人在估算结果上保持一致。ü  激发对工作项细节的思考，让所有假设都显露出来，充分了解工作项。ü  需要估算的用户故事量不是非常大（例如，500个就非常大，采用此方法会非常耗时）。敏捷估算2.0ü  通常耗费的时间会缩短。ü  需要估算的用户故事非常多。计划扑克估算在敏捷开发中，最典型的使用故事点做估算的方法是计划扑克（Planning Poker）。计划扑克由James Grenning在2002年首次提出。计划扑克集合了专家意见（Expert Opinion），类比（Analogy）以及分解（Disaggregation）这三种常用的估算方法，使团队通过一个愉快的过程快速而准确的得出估算结果。计划扑克的参与者是团队的所有成员。典型的敏捷团队规模推荐为7±2人，如规模比较大可以考虑拆分成为多个小团队各自独立进行估算。Product Owner也需要参加，但不参与估算。计划扑克开始时，每个参与估算的组员都会得到一副计划扑克，每一张牌上写有一个Fibonacci数字 （典型的计划扑克由12张牌组成：?，0, ½，1, 2, 3, 5, 8, 13, 20, 40, 100,∞，其中?代表信息不够无法估算，∞代表该用户故事太大）。开始对一个用户故事进行估算时，首先由Product Owner介绍这个用户故事的描述。过程中Product Owner回答组员任何关于该用户故事的问题。展开讨论时主持人(通常由Scrum Master担任)应注意控制时间与细节程度，只要团队觉得对用户故事信息已经了解到可以估算了，就应当中止讨论开始估算。所有问题都被澄清后，每一个组员从 扑克中挑选他／她觉得可以表达这个用户故事大小的一张牌，但是不亮牌，也不让别的组员知道自己的分数。所有人都准备好后，主持人发口令让所有人同时亮牌，并保证每个人的估算值都可以被其他人清楚的看到。经常会出现不同组员亮出的分值差距很大的现象。当出现有很多不同分值的时候，出分最高的人和出分最低的人需要向整个团队解释出分的依据。（主持人需要注意控制会议氛围，避免出现意见不一导致的攻击性言论。）所有的讨论应集中于出分者的想法是否值得团队其他成员进行更深入的思考。随后全组可以针对这些想法进行几分钟的自由讨论。讨论之后，团队进行下一轮的全组估算。一般来说，很多用户故事在进行第二轮估算的时候就能得到一个全组统一的分值，但是如果不能达到全组意见一致，那么就重复的进行下一轮直到得到统一结论。敏捷估算2.0（Agile Estimating 2.0）计划扑克是Scrum团队应用最广泛的敏捷估算方法，但是有时候计划扑克玩起来耗费比较多的时间，尤其是在十人左右的团队中。Ken Schwaber在他的书《Agile Project Management with Scrum》中指出，在进行迭代规划时，迭代计划环节应该控制为一个4小时的固定时间，但是从战术的角度看，如果一个会议持续4小时，大部分的参会者会有精疲力竭的感觉，并且很难保持持久的注意力。为了解决这个问题，Brad Swanson 和 Björn Jensen在上海Scrum Gathering （2010/4/19）上介绍了Agile Estimating 2.0技术。这个新的估算技术同样基于的专家意见，类比和分解，同样适用Fibonacci数列，但是它可以显著地缩短会议时间。它的估算过程大致分为主要四步，如下图所示：第一步：由Product Owner向团队介绍每一个用户故事，确保所有需求相关的问题都在做估算前得到解决。第二步：整个团队一起参与这个游戏。只有一个简单的游戏规则：一次仅由一个人将一个用户故事卡放在白板的合适位置上：规模小的故事在左，大的在右，一样大的竖向排成一列。整个团队轮流移动故事卡，直到整个团队都认同白板上的故事卡的排序为止。  第三步：团队将故事点（Story Point）分配给每个用户故事（列）。最简单的做法是使用投票来决定每个用户故事分配到哪一个Fibonacci数字。最后一步：使用不同颜色来区分影响估算大小的不同方面，并且重新考虑是否需要修改估算值。例如，我们使用红色来表示那些无法被自动化测试脚本覆盖的用户故事，因此那些用户故事需要一个更大的数字来容纳手工回归测试的代价。在国内一些企业多次实践Agile Estimating 2.0之后，反馈的结果还是令人兴奋。据称，团队对于估算的准确性更有信心了，并且只耗费原先的1/2时间。通过以上介绍，相信了解了如何使用用户故事来分析了解需求。在学习了估算的核心概念及故事点后，对于估算方法的实践也有了更深的体会。不论是计划扑克估算还是敏捷估算2.0都只是估算的一种实践，不是固定的唯一方法。只要理解估算的意义和核心概念，选择适合的方法就是没有问题的。另外补充一下，这里讲的估算偏重于用故事点估算，如果团队成员一致达成共识，用工时或理想人天效果更好，便可以尝试，给予团队试错的机会，说不定也有意想不到的收获。完成了估算后，我们需要对估算的内容进行管理。华为云DevCloud在用户故事或者Task中均有一个记录估算结果的属性，比如预计工时。所有工作项估算结果记录以后就可以以列表的方式进行查看。可以按处理人排序，查看每个成员认领的任务是否饱和。开发团队完成的工作内容可以时时更新实际数据，这样每轮迭代也可以就估算准确度进行统计和分析。看看估算结果和实际结果的差别，以便可以后续做估算调整和改善。参考附录Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。估算系列文章【DevCloud · 敏捷智库】估算第一篇：利用用户故事了解需求【DevCloud · 敏捷智库】估算第二篇：利用核心概念解决估算常见问题【DevCloud · 敏捷智库】估算第三篇：利用故事点做估算

背景拜访企业的过程中，不少企业领导提到过一个相似的问题：“我们团队有个人平时总是和我（或者其他成员）对着干，把团队氛围搞得很差，Scrum Master应该怎么引导他们，让他们好好工作？”本文就针对这样的问题来聊聊，团队中遇到“刺头”应该怎么办？问题分析学生时代班级里总有几个刺头，他们惹是生非，扰乱课堂纪律——课堂上讲话，接老师话茬，让老师很是头疼。企业中，很多团队也有一两个成员，他们难以合作，常常捅娄子，给团队交付带来不良影响，令管理层也很头疼。在交流过程中，笔者从不同人口中了解到不同类型的刺头，分别有：技术骨干技术骨干通常掌握着项目的核心技术，是开发交付不可或缺的关键角色，项目少了他很可能会产生较大的影响。有的技术骨干对其他人，甚至是领导都爱答不理，和团队很难沟通协作。原地踏步的“老人”同一时期入职的员工，有的人做上了项目经理，有的人还在原地踏步写一些基础代码做同一个项目的团队成员，有的人绩效一直是A，奖金丰厚，有的人一直作为“吊车尾”混迹于团队尾端两种情况的后者会存在一部分人表现出对工作消极懈怠，在团队内传播负面能量。比如经常抱怨、不满、碎碎念，对其他团队成员尤其是新人加以冷嘲热讽。有离职打算的员工大多数人做事讲究善始善终，离职时都会做好交接工作。但有小部分人在离职时喜欢破罐子破摔——反正都要走了，还遵守什么规矩，于是不认真交接，消极怠工，就等着离职办手续。工作经验少的“新人”正所谓”初生牛犊不怕虎“，有些应届毕业生在学校做过几个项目，便感觉自己懂得很多，比其他同学高一等，步入职场后，对其他同事不尊重；还有一些工作经验少的年轻员工做过几个技术框架简单的项目，便感觉自己的技术能力很强，心里有了“开发就那么点东西”的错误想法，进而轻视日常工作，不服从领导安排。除个别极端情况比如天生性格不好，大多数刺头不配合都是有原因的。以上几种情况总结起来有如下几点原因：性格外冷内热笔者接触过的技术骨干性格很多都是外冷内热——他们本身是乐于助人的，但由于他们日常工作很忙或者工作太投入，没有太多精力去顾及自己对别人的态度，所以给人造成爱答不理的错觉。自负有少数技术牛人因为自己能力突出而变得自负，看不起公司其他人。在这部分人看来团队成员都应该很轻松的完成任务，团队成员问的问题都没有技术含量，懒得回答；而且这部分人技术至上，很多公司管理层因为不会开发技术而被他们轻视。和他们类似，有些年轻员工因为阅历有限，没有接触过复杂的场景，做两个项目就以为自己能力很突出，表现同上。对工作存在怨念做同样工作，评价有的高有的低，如果不懂得正视自己的缺点，那获得低评价的人难免心中不服。经常如此，就会感觉自己怀才不遇，对周遭事物存在怨念。如果员工在一家公司工作的很开心，通常离职时也会站好最后一班岗；离职前捣蛋的员工则多数是因为工作憋了一肚子气或者和团队闹不愉快，离职前这几天正好把憋得气全撒出去。常见的怨念来源还有工作中与其他成员的冲突未得到解决，个人未被团队关注等。针对这些问题，Scrum Master应该如何引导呢？解决措施很多人对于Scrum Master的理解是Scrum Master的工作就是帮助团队召开各种会议，其实这是对Scrum Master工作的一种误解。Scrum Master除了组织团队召开会议，还有帮助团队扫除障碍，促进团队沟通等工作要做。《Scrum精髓》一书中将Scrum Master的职责总结为六类：敏捷教练，服务型领导，“保护伞”，“清道夫”，过程权威，“变革代言人”。作为“保护伞“，Scrum Master应该保护团队免受任何干扰，当然也包括团队内冲突，成员关系等。敏捷开发中，Scrum Master应该帮助团队成员建立共同的愿景与集体价值观，帮助每个成员成长并实现其自身价值，同时鼓励成员们相互尊重、信赖。当遇到上文的问题时，Scrum Master可通过引导的方式加强团队协作改变团队现状。对于之前提到的问题，Scrum Master可以参考如下措施。组织团建，拉近团队成员之间的距离外冷内热型的团队成员通常没有机会与其他成员交流，定期抽出时间比如每次完成发布计划或者两个月为间隔，搞一次团队建设（以下简称团建），团建可以让整个团队放松身心，团建本身也是一个很好的拉近团队成员之间距离的方法。团建通常会策划一系列团队运动：参与团建的成员以组为单位进行PK，每组成员在团建中为了团队荣誉，尽情的释放自己的能量。团建考验团队协作，工作中看起来很难合作的人，可能在游戏中就很容易合作。如果游戏中合作愉快，这次合作的经历很容易就会被带到工作中，从而推动团队向一个更积极的方向发展，让团队更有凝聚力。让刺头知道人外有人自信的人通常对自己的能力有一个正确的判断，清楚自己的能力范围；而自负的人则会高估自己的能力，轻视他人。自负常常源于自己认知有限，自负的刺头通常认为自己技术能力已经处于行业巅峰，如果让刺头意识到自己并没有比他人强太多，就可以让其认清事实，调整心态，具体有如下几种做法：让刺头与能力更强的人一起共事，一方面可以认识到自己的不足，另一方面可以提高自己的境界。如果刺头是一个刚工作的年轻人，与老员工一起工作通常会发现老员工思考问题方式，代码编写习惯等都和自己不同，Bug也更少。两人对比如同《卖油翁》里的陈康肃和卖油翁，“无他，唯手熟尔”，习惯源自多年工作经验的积累——走过的坑多了就知道如何避开了。差距会让刺头认识到自己能力不足，还有很多方面需要提升，同时也是年轻人学习的一个好机会。技术骨干和能力相当的人共事，可以了解到自身并没有比其他人强太多，在团队内也并非无可替代，进而消除其自负心理。如果公司内没有比刺头更强的人，可以让其处理更难的工作更强的人应该接受更强的挑战。Scrum Master可以建议刺头认领更难的工作，而非其擅长的工作，比如让其使用行业新技术优化现有产品或者开发一系列工具提高团队工作效率，建议的同时可以说“你觉得这工作有困难么，大概多久能完成”，或者“我听说XXX用了一周就作完了，你技术这么强应该也没问题吧” 之类能够刺激到他的话。如果刺头能够按时完成工作，项目一定程度上会从中获益；如果不能，刺头自身也会有一种挫败感——原来自己并非无所不能，自己和别人比还是有差距的，自负的情况也会有所改善。倾听刺头心声，耐心疏导对工作存有怨念的刺头，我们应该找到怨念的根因，想办法疏导。面对既将离职的刺头，Scrum Master可以通过称赞其以往对团队做出的贡献，缓和其不满情绪。虽然双方合作关系即将结束，但刺头多少对团队有些感情，Scrum Master动之以情，晓之以理，在维持其情绪稳定的同时，鼓励其做到善始善终，站好最后一班岗。刺头没有离职打算：如果Scrum Master清楚其怨念的根因Scrum Master可以通话一对一谈话的形式，为其打开心结。比如可以从最近状态切入，引出根因（比如绩效不如别人好，晋升没有别人快），然后解析其他人状态，将刺头与其他人形成对比，并列举差异；Scrum Master可以在最后进行鼓励比如“如果你能完成XX目标，我觉得你就可以获得更好的绩效，而且你绝对有这个能力完成”，让刺头了解与别人差距的同时也得到认可，并且获得前进的动力。讲一个亲身经历的故事，故事发生在笔者步入职场后的第一个团队。团队的项目经理A和技术人员B同年入职，两人对项目贡献都很多。论技术A不如B，但是A的职级比B高一级（职级直接影响待遇），B大为不满，工作中处处与A对着干，消极怠工，严重影响项目交付。公司总部领导了解情况后，给B制定了目标，只要B完成目标就提升其职级，最后B努力完成了目标，领导兑现诺言，给B提升了职级。对于B来说，职级上调，其目的已经达到，工作状态也慢慢变得积极。如果Scrum Master不清楚其怨念根因Scrum Master也可以找刺头单独谈话。如果感觉直奔主题不好的话，可以在闲暇之余对其进行重点关注，比如午休一起打打游戏等，建立一定社交基础后再尝试询问，然后逐步引导。如果刺头负面情绪来源于冲突没有得到很好解决，Scrum Master可以担任冲突调解员。Scrum Master站在客观角度，和冲突双方一起重新审视冲突，并客观的给出建议，解决冲突。在日常工作中，Scrum Master应该多认可，多鼓励团队成员，多与成员沟通，营造出轻松，融洽的工作氛围，避免团队成员因工作产生负面情绪。岗位调整如果刺头始终无法改变，双方互相耗着必将是一个双输的局面。调整其岗位，让其在能力范围内选择自己想做的工作也是企业中常见的做法。参考附录Kenneth S.Rubin:Scrum精髓. 北京：清华大学出版社文章博客地址：【DevCloud · 敏捷智库】Scrum Master如何引导团队中的刺头

背景有些团队践行敏捷一段时间后，感觉回顾会议（Retrospective Meeting）时间太长，动辄2-3个小时，而且会议上走形式，会后无效果，那么如何才能让回顾会议有效果呢？问题分析在敏捷十二原则中提到：团队定期地反思如何能提高成效，并依此调整自身的举止表现。所以回顾的目的是为帮助团队定期改善工作，发现障碍和处理问题，从而实现持续改进。回顾想要实现的效果就是持续改进。回顾会议走形式，就无法保证改进计划的质量，没有计划后面的环节就都无从谈起。回顾会后没有执行、检查和调整，都会影响到改进的落地，就出现前面提到的会后无效果的情况。综上所述，要想回顾有效果需要具备两方面的条件：可行的改进项，也就是首先要保证改进计划（Plan）的质量；改进的落地执行，包括执行（Do）、检查（Check）和调整（Act）这几个环节。这样才是一个完整的过程，想要有效果就要做好回顾改进的PDCA。解决措施结合回顾的过程，我们首先需要通过做好会前和会中部分来保证产生可靠的计划；其次回顾会后要做好计划的执行、检查和调整来保证落地执行的效果。第一步：做好回顾的会前和会中工作，保证Plan的质量要保证Plan的质量，就要开好回顾会；开好回顾会，可以从会前和会中两个环节来考虑。会前可以从数据准备、会议设计和会议公约三个方面来考虑会议设计：确定回顾的重点。我们的会议不是大而全，而是小而精，要聚焦，在规定的时间盒内（建议1-1.5小时）产生可行的方案。会议的流程环节设计是为了保证会议按时完成和让会议有好的氛围，让大家都能积极参与。比如会议开始时的签到活动可以让大家聚焦到会议上，ESVP（Exploer,Shopper,Vacationer,Prisoner）的选择可以了解大家的心态；中间数据收集的时候通过事件时间线、表情图可以让团队对迭代情况建立共同背景，通过头脑风暴可以帮助大家发散思维，通过投票排序实现全员参与，共同承诺等等。关于会议的活动方式有很多，团队可以多积累一些。 数据准备：首先要准备迭代内改进情况的度量数据，这是为了回顾的Check和Act做准备的。其次要准备迭代内的度量数据，根据前面确认的回顾重点来准备数据，数据要客观真实。会议公约：公约制定最关键的要团队共创，而不是领导或者管理者一言堂。让每个人都参与制定，其实是为了形成团队的承诺，这样增加公约的效力。公约的内容是为了保证会议的顺利进行，比如守时，不玩手机，不开小会等，关键还是要团队共创。会中可以从引导者要求，营造氛围，改进项确定和结束回顾四个方面来参考引导者要求：这是很关键的一个角色，引导者的能力会决定会议时间和会议效果。可以是有经验的ScrumMaster或者团队成员。在引导的时候注意要中立，不要给出观点，参与讨论，这样会让自己忘了身份，忽视流程和时间的掌控。 营造氛围：会议的氛围影响团队成员的感受，决定他们的参与度和积极性。要营造一个安全的环境，确保团队成员可以放心的说出自己的心里话，不会瞻前顾后、欲言又止。通常参会人建议是团队和Scrum Master，关于管理者和PO或者其他外部人员想要参加，需要看团队的接受度，他们之间是否相互信任。还要营造一个放松的环境，可以准备团队喜爱的零食，还有做好会议设计和选择合适的引导者都会保证好的氛围。改进项确定：在确定改进项的时候，要团队共同决定，保证全员皆知，形成共识；其次要聚焦，选择可执行的1-2项，不要冒进贪多；最后是改进的目标要SMART(Specific,Measurable,Achievable,Relevant,Time-bound)。结束回顾：回顾的收尾也很重要。团队可以通过感谢卡的形式相互感谢，或者心流笔记表达感受，让团队成员之间彼此相互了解和感知，这是一个非常好的团队建设时机。还有就是要再次明确会议达成的改进项，并确认负责人，为后续的执行活动做好准备。第二步：做好回顾会后改进计划的Do、Check和Act，保证改进落地执行的效果有了高质量的Plan，回顾会后的Do、Check和Act也非常重要，每个环节缺一不可。Do的过程根据改进内容不同执行方式会有不同，同时在执行过程中增加一些实践，可以提高执行过程的效果。执行方式按照规则&纪律类、执行类和障碍类三种改进项类型进行阐述规则&纪律类：需要Scrum Maser和团队共同反复重申，慢慢形成团队统一的工作习惯和方式。比如工作项状态的及时更新，开会不迟到等。执行类：需要团队花费时间去执行，所以要放入Backlog。比如团队编码规范的改进，需要制定出统一标准，然后全员展开，并且跟踪检查执行情况。障碍类：是指对团队冲刺形成阻碍的事情，不需要团队成员花时间去改进，可以放入Scrum Master的管理清单中。如PO在计划会议前准备好Product Backlog，团队白板申请等，这些Scrum Master要和外部团队去沟通协作，并跟进行动的进展。执行过程中为了保证效果，可以参考以下几种做法可视化改进项：将改进的内容在团队的公共区域展示出来，让团队都清楚当前处在哪些阶段，需要做什么，如何做，注意什么。设立贡献墙：改进的工作都是迭代任务外的工作，大家关注度可能不同。对改进中积极参与者或者是取得进步大的人要进行公开鼓励，从而去带动大家的积极性，提升改进动力。预留改进时间：执行类的改进进入Backlog，就需要预估时间，因此要预留出改进的时间。不能既要求团队全力冲刺完成迭代任务，还要求团队额外做好改进，这是不现实的。某项工作完成的好坏取决于成员的能力和意愿两个方面，首先是需要有意愿，才能保证取得好的效果，不能在已经饱和的迭代任务外强加给团队改进工作，那样即使推行了也不会取得好的效果。结对实施改进：可以参考XP(eXtremeProgramming)中的结对编程的做法，结对实施改进。通过设立实施人和监督人，目的是保证改进的准时和高质量的完成。实施这个做法的前提还是要团队同意，一言堂强加不可。Check是落地执行的总结检查可以在执行改进所在的迭代回顾会进行，也可以单独设立改进回顾会。建议在执行改进所在的迭代回顾会，这样可以减少团队会议的频次。会上先对改进回顾，团队可以感受到回顾给团队带来的改变，团队的改进动力和参与度都会得到提升，会让大家对接下来的回顾会有更多的期待，会更有意愿去继续回顾和改进。Act是对总结检查的结果进行处理成功的经验加以肯定，并予以标准化；失败的教训也要总结，引起重视；没有解决的问题，在回顾会上团队决定是否提交给下一个PDCA循环中去解决。所以回顾带来的改进是阶梯式上升。整个PDCA循环不是在同一水平上循环，每循环一次，就解决一部分问题，取得一部分成果，团队就前进一步，水平就提高一步。到了下一次循环，又有了新的目标和内容，更上一层楼。如下图所示。改进是无止境、无终点的，在这个过程中团队会越来越好。最关键是开始的一点点进步。只有让团队看到效果，才会激发参与度和改进动力，让团队坚持去回顾，坚持去改进。敏捷回顾会议对团队非常重要，否则团队就可能在相同的问题上重蹈覆辙。愿我们都能坚持回顾，从一小步开始，不断进步。敏捷路上，你我同行！参考附录1.  敏捷原则2.  Esther Derby. Diana Larsen.敏捷回顾：团队从优秀到卓越之道[M].3.  Kenneth S. Rubin. Scrum精髓[M].4.  MBA智库：戴明循环5.文章博客地址：https://bbs.huaweicloud.com/blogs/163478附件：【DevCloud • 敏捷智库】如何让敏捷回顾会议有效果，这样做就对了.pdf[hide]链接: https://pan.baidu.com/s/1-sFwsbIZdLi4851mje17SQ提取码: 5pxp[/hide]

背景某公司在二手房交易平台项目中采用了敏捷开发模式，项目的一个需求为通过输入关键字可以为用户检索对应的房源信息。产品经理将这个需求编写成用户故事如下：“我想通过输入一些词，查询相关的房源信息”开发团队拿到用户故事后，有很多疑问：输入的信息包含哪些？搜索完成后，给用户展示什么信息？在展示效果上，只做一个查询房源信息的搜索框，能否满足用户需求？这条用户故事要实现得价值是什么？很多团队都遇到过这样的情况。用户故事可以帮助开发人员更好的理解需求，让开发人员形成以用户为中心的思维模式，从而开发出更符合用户期望的产品。那么应该如何有效的编写一个用户故事呢？问题分析什么是用户故事分析问题之前，我们先了解下用户故事。用户故事维基百科给出的定义是：“In software development and product management, a user story is an informal, natural language description of one or more features of a software system.”即在软件开发和产品管理过程中，对系统的一个或多个功能进行非正式，自然的语言描述。用户故事是为了表述用户渴望的功能和价值。与需求规格说明书对比同样是用来记录需求，用户故事和传统的需求规格说明书有什么差别呢？需求规格说明书是软件开发过程的范围标准，通常会很正式客观的说明系统需求范围，功能实现要点等，说明书的好处是可以让产品完全符合约定规范，达到交付标准；但是说明书要求做到的和客户内心期望的可能并不一样，比如：说明书中写“产品logo是黑豹”，产品经理是一个漫威粉丝，他希望产品logo是漫威的黑豹；只看说明书，很难看出产品经理的真实需求，于是研发人员就画了一个动物黑豹作为logo；从结果来看，按照说明书做出的产品与用户期望之间存在着很大偏差。用户故事通常比较短小，其核心是围绕用户期望的价值；它不像说明书那样事无巨细的记录下产品想要实现的功能，而是提醒研发人员正在开发或者待开发的功能要实现什么价值（理论上，用户故事应该由用户或用户代理如产品经理录入）。用户故事的三要素为角色、功能、价值，编写用户的通用模板如下：“作为一个<角色>, 我想要通过 <功能>, 以便于实现 <价值>。”使用用户故事来写描述刚才的需求可能就会写成，“作为产品经理，我想制作一个黑豹的logo，以便于利用漫威品牌去吸引用户。”研发人员通过用户故事的“价值”，可以知道这个logo应该是漫威的人物；如果不知道，也可以去问产品经理，这豹子和漫威有啥关系，经过产品经理解释，需求也可以被正确理解（体现了用户故事“可以商讨的”的原则），简而言之，需求规格说明书强调：“功能”，而用户故事比起“功能”更注重“价值”。根本原因了解了上述信息，再看背景中用户故事存在的问题。这条故事虽然有用户故事的样子，但是本质上更像一条需求说明——没有体现用户期望的价值，它只写了“作为 一个<角色>, 我想要通过 <功能>”，没有后半部分的“以便于实现 <价值>”， 所以这条用户故事不合格的根本原因是没有体现价值，这是一条无效的用户故事。这种无效的用户故事一方面会导致研发人员很难理解需求要实现的目的，做出的产品令用户不满意；另一方面，这个用户故事写的太粗略，研发人员不知道从哪下手。无效的用户故事只是一种形式，对需求澄清起到的作用微乎其微。接下来看下合格的用户故事应该怎么写。解决措施要写好用户故事，首先应该了解用户故事的必备条件，或者说用户故事的原则。用户故事的原则一个用户故事通常具备6个原则：独立的（Independent），可以商讨的（Negotiable），有价值的（Valuable），可以估计的（Estimatable），合适的小（Small），可测试的（Testable），6个原则取英文首字母会组成一个单词“INVEST”，所以用户故事的6个原则也被称为“INVEST原则”。独立的（Independent）：避免故事之间的依赖；这样做的好处是便于故事优先级排序以及估算。A故事：“作为购房者，我想要通过学区搜索房源，以便买到学区房，方便孩子上学”，B故事“作为购房者，我想要通过学校名称搜索房源，以便于生活在有文化气息的地方”，一定程度上来说，B故事对A故事有依赖，学校的范围包含学区内的公立学校外，还有学区外的私立学校和大学等。如果A故事需要1天，B故事需要3天，总体估算两个故事完成应该是4天，可是A故事完成后，B故事相当于完成了一部分，最后B故事可能只需要2天就完成了；而且本来优先级相同的两个故事，A故事优先级无形之中提高了。用户故事之间的依赖会让估算不准确，即不符合“独立的”原则；想解决这个问题，我们可以对故事重新划分，比如：重新划分成三个故事：“作为购房者，我想要通过私立学校名称搜索房源，以便于孩子将来得到不一样的教育”，“作为购房者，我想要通过大学名称搜索房源，以便于生活的地方有文化气息”，“作为购房者，我想要通过学区搜索房源，以便买到学区房，方便孩子上学”，这样故事之间就没有耦合性，每个故事都是独立的，便于优先级排序和估算故事点。可以商讨的（Negotiable）：用户故事只提供适量信息，让开发人员和用户（产品经理）针对一些细节进行讨论；“作为购房者，我想要通过学校名称搜索房源，以便于生活的地方有文化气息 ”，常规理解，这条需求包含：小学，中学，那大学是否包含呢，这样就形成了讨论性。这种情况我们可以在故事中加一段注释：“注释：包含小学，中学，是否包含大学待确认”。与客户的讨论过程在可能会挖掘新的需求，比如艺术学校等。用户故事注释不建议写的面面俱到，因为会减少故事的可商讨性。有价值的（Valuable）：敏捷开发以价值为导向，所以故事应该体现对用户的价值。“有价值的”原则在问题分析里面已经做了部分解释；还有一种情况“作为研发人员，我希望给后台数据库创建XX表，以便于我实现XX模块的功能”，这条用户故事看似ok，但实际上该用户故事只对研发人员有价值，换句话说用户不关心后台表结构，只关心系统是否可用，所以这条故事不符合“有价值的”原则。技术实现方面的需求可以适当转化成对用户有价值的故事，或者把它作为“作为购房者，我希望通过XX功能，以便于实现XX价值”这条故事下面的一个Task。可以估计的（Estimatable）：每个故事都应该可以估算出故事点，以便于对个人工作量以及团队速率进行估算；一个用户故事估算的工作量不能超过一个迭代，如果故事太大难以估算，可以将大的故事进行分解，分解成多个小的可估算的故事。“作为购房者，我需要按交通线路搜索房源，以便于找到方便搭乘公共交通的房源”，公共交通种类繁多：公交，地铁，轻轨等，假设实现每种交通工具搜索需要4天，要一下子实现这个故事至少需要12天，一个迭代开发不完，这不符合“可以估计的”的原则。针对这种情况，我们可以将这个大的故事拆分成三个小的用户故事，每种交通工具分别对应一个故事，这样一个故事就是4天，就符合了“可估计的”原则。合适的小（Small）：故事分解的小，便于估算也便于交付，但是如果故事分解的太小，以至于难以估算故事点，就需要对多个实现共同功能的小故事进行整合。“作为购房者，我希望搜索框背景是红色，以便于我可以更好的找到搜索框”这种用户故事工作量很难估算，可能少至十分钟，多则半小时就完成了；如果迭代中有很多这种小的故事，那对于整体速率估算是非常不利的。小故事可以和其他故事进行整合，形成可估算大小的故事；或者将小故事作为一个Task挂到其他类似用户故事下。可测试的（Testable）：用户故事必须要有一个明确的完成标准，以判断开发的功能是否满足用户期望。“作为购房者，我希望搜索到大房子，以便于我和父母孩子居住”，“大房子”是一个模糊的概念，面积90㎡还是140㎡算大房子？是不是三室两厅就符合条件？这种用户故事很难进行验收，也不符合“可测试的”原则。正确描述是：“作为购房者，我希望搜索到90㎡以上，三室两厅的房子，以便于我和父母孩子居住”这样标准就清晰很多，评审会议时也好判断功能是否符合用户期望。用户角色好的用户故事除了满足它的基本原则，还应该考虑一个问题：对于不同的“角色”，实现同样“价值”所需要的“功能”是否也不同？我们来对比两个用户故事：“作为购房者，我想要通过总房款的范围搜索房源，以便于找到我能买的起的房子”和“作为月薪5000，手头有30万存款的职场新人，我想要通过总房款的范围搜索房源，来确定我能负担得起的房子”，开发相同的“通过总房款范围搜索房源”功能，前者需求描述比较模糊：在搜索栏中输入比如100万，然后展示100万左右的房源信息？100万左右的“左”和“右”分别是多少？按这个需求做出来的产品，很大概率是模棱两可的产品，也很难被用户认可；而且在这个用户故事中，“角色”并没有起到该有的作用；第二个故事相对就好很多：30万做首付， 5000月薪可以作为月供的参考，通过这些参数可以大概的推测出总房款的范围，这个范围也可以作为这类人预算的参考；再深一点考虑：房屋总价做成可选区间，代替从搜索栏输入，也许用户体验会更好。由此可见，如果对用户角色进行细致划分能起到意想不到的效果。敏捷以用户为中心，不了解用户就无法掌握用户真正期待的价值。而研发时每个人对用户的理解是不同的，用户角色可以帮助团队形成统一的用户形象，研发人员可以聚焦目标用户，重点挖掘该角色需要的价值；同时使用用户角色会更有代入感，便于研发人员站在用户角度去实现产品该有的价值。用户角色可以通过头脑风暴或其他形式进行识别：按实际需求对用户群体进行细致分类；分类完成后，对有共性的用户适量整合形成具有代表性的用户。比如，对于购房者我们头脑风暴后，可能形成如下群体：年轻人，中年人，老年人，每个群体自身条件和期望都会有差异。年轻人群体中大多数个体财富积累较少，上班时间早，从他们角度会写出特定的用户故事，比如：“在市中心上班的小王，想要通过地跌线路搜索房源，以便于解决上班堵车导致迟到的问题”，要怎么做，为什么这样做，一目了然。同样对于已经成家的中年人，可能更关注孩子的教育（学区）；对于老年人群体，可能更关注附近是否有菜市场便于买菜，是否有公园便于日常锻炼，从这些群体的角度出发，搜索功能会形成不一样的用户故事。还应该想到一些极端情况，比如：“作为一个事业有成的企业家，我想要在空气清新的郊区买一个独栋别墅，以满足私人会谈和休假”，所以房源类型是别墅还是普通住宅也要考虑。接下来看一个例子。实例操作用户故事通常以手写的方式写在纸质卡片上，但是纸质卡片很难提供准确的数据用来进行相关分析，所以现在很多企业都选择使用电子卡片。华为云DevCloud是基于敏捷思想设计的DevOps研发平台，接下来在华为云DevCloud中写几个规范的用户故事，故事呈现的需求是背景提到的搜索功能。首先对年轻的上班族群体进行需求划分，比如有些年轻人工作单位在市中心，市中心房子太贵，离市中心稍微远一点开车或坐公交时间不可控（容易堵车），所以他们希望按照地铁线路搜索房源，以解决上班迟到的问题。用户角色就是：早晨八点要到单位（单位位置在市中心）的小王，小王想要做的事是：在这个网站里通过地铁线路搜索地铁站附近的房源信息，他这样做的目的是为了减少上班迟到的风险，写成用户故事：Tips：华为云DevCloud支持填写故事的各种属性，比如所属迭代，优先级，估算工时，故事点等。通过规范的用户故事，研发人员发现原来用户想要的搜索并不是无目的的搜索，而是想找到和自己特定需求相匹配的房源，如果在搜索框基础上，加上若干CheckBox会更有利于用户搜索，最后产品搜索页面如下。总结站在不同用户的角度，遵循用户故事的“INVEST”原则，可以更深层次的挖掘用户的需求，写出更有效的用户故事。参考附录Mike Cohn:用户故事与敏捷方法.北京：清华大学出版社文章博客地址：【DevCloud · 敏捷智库】“用户故事等于需求说明”——你一定没有写好用户故事

背景在传统开发模式下，开发任务是由项目经理指派给个人的，而在敏捷开发模式中，开发任务是团队领取的。很多企业在转型中遇到过这样的问题：“计划会议认领开发任务的时候，有几个任务没人认领怎么办？”问题分析首先，相对于传统开发模式的指派开发任务，我们需要知道为什么在敏捷开发中是领取任务。在敏捷中，不管是敏捷宣言还是Scrum指南，都没有指派（assign）一词，而是使用了一个术语“自组织”，如下：最佳的架构、需求和设计出自于自组织的团队（敏捷宣言12项原则）自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导（Scrum指南）他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量（Scrum指南）那么“自组织”是什么呢？从字面的意思来理解，“自组织”就是：安排分散的人或事物使具有一定系统性或整体，而安排的人就是他们自己。在敏捷开发中，自组织团队就是具备自我管理、自我驱动、自我学习等能力的敏捷开发团队本身，这样的团队一般具备如下特点：团队成员自己“拉”工作，不是被动等待他们的领导分配工作；团队作为一个整体管理他们的工作；团队仍然需要辅导和指导，但不需要指挥和控制；团队成员彼此沟通紧密互通有无；团队主动发现和提出问题并共同解决；团队不断提高自己的技能，鼓励探索和创新。更多关于“自组织”的相关内容不在此FAQ的范围内，如感兴趣请参阅更多文献。从敏捷宣言和Scrum指南关于任务的工作方式上来看，在我们践行敏捷的时候，主要发挥的是开发团队自身的主观能动性，开发团队由原来的控制性转变成了自组织性，而开发任务也就由原来的指派变为了领取。这样的好处是，领取任务就是发挥了人的主动性，而自主性是人们从事创造性和解决问题的动力之一，良好的自我组织能给团队和个人带来高绩效、出色的工作成果以及喜欢的工作环境。另外，每个人都是最了解自己的，也擅长为自己分配任务，相对于传统的指派开发任务所带来的易主观臆断、分配不当等更具有合理性。然后再回 “计划会议认领任务的时候，有几个任务没人认领怎么办？”这个问题上。不过在此之前，需要先澄清的一个观点就是，在计划会议中，不一定非要全部领取完开发任务。在Scrum指南中指出“领取工作在Sprint计划会议和Sprint期间按需进行。”这个期间，可以理解为在每日Scrum站会上基于目标领取任务。另外，Mike Cohn 也表示过，不建议在计划会议中领取开发任务，这样可能会导致目标由团队变为了个人，进而违背了敏捷的本意，降低了灵活性。更多请详见参考附录“Should Team Member Sign Up for Tasks During Sprint Planning？”。一般来说，开发任务没人认领的原因主要有：开发任务的难度大：当开发任务比较难以解决，超出了团队大部分成员的能力时，团队成员可能会存在担心加班加点，甚至“996”的情况而不愿意认领。开发任务超范围：当开发任务的内容超出团队成员所掌握的范围时，如 Android 不会 IOS，开发不会测试等，就可能会出现“我是想认领的，但实例它不允许啊”的情况。担心受到他人指责：工作内容存在一定的挑战性，担心由于自己没有做好，导致团队目标没有达成而受到指责。那么应该如何解决呢？解决方案在一个敏捷Scrum团队中，Scrum Master扮演着重要的角色，该角色一部分的作用就是要帮助团队成为自组织型团队，以便让团队能以积极的心态去面对冲刺的开发任务。此外，当出现任务没有人愿意认领的情况时，首先 Scrum Master应该帮助团队弄清楚没有人认领的原因是什么再对症下药，下面基于分析中的三种情况分别给出解决措施。开发任务难度大对于开发任务难度大的情况，Scrum Master应该组织团队进行有效的任务分解，使用探针Spike技术，探索出解决措施以降低任务的难度，再由团队去认领(更多关于Spike的解释请见附录)。或者鼓励技术能力较一般的成员和技术大牛通过结对编程的方式来一同认领任务(更多关于结对编程的解释请见附录)。在华为云DevCloud中，可以对该类难度大的用户故事通过子工作项的方式进行拆分，同时在基本信息中通过设置处理人和抄送人的方式以记录结对编程的人员配对情况，如下图。除此以外，在每日Scrum站会的时候,要留意和了解该开发任务的情况，进行风险评估，如有问题及时帮助协调解决。在回顾会议中,应对该类情况问题进行分析并能输出基于团队的一套标准工作方式方法，然后将解决方案记录在团队知识库中，华为云DevCloud提供了Wiki的功能，可以为团队很好的整理和记录工作方式，如下图。开发任务超范围敏捷提倡的团队是跨职能团队，但是团队的跨职能并不意味着个人能做所有的事情，我们希望的跨职能团队往往是由掌握多项技能的T型人才（每个成员在一个专业领域具有深度，而在其他领域具有广度）所组成的。那么首先，需要Scrum Master能够和团队整理和维护成员技术矩阵，把个人技能掌握情况对团队公开（知道团队欠缺什么、知道可以和谁学等），然后定期组织技术分享等活动以帮助团队成员学习（主要以学习一项新的技术后的分享方式），这样可以在一定程度上提升成员在冲刺中愿意领取其他任务的热情（学完了当然是想去用一下咯）。另外，还可以由专长成员和意愿成员组队，采用结对编程的方式领取任务，以实现个人技术的扩充。团队成员的T型能力建设，不仅仅能让团队领取任务的时候有更多的选择，也提供了成员的backup能力，减少无人认领的情况发生。此外，同样也需要Scrum Master留意日常评估风险和引导团队回顾该事项并维护团队知识库。担心受到他人指责工作内容存在一定的挑战性，担心由于自己没有做好，导致团队目标没有达成而受到指责。Scrum Master应该对团队贯彻以团队为整体的思想，并指导和强调Scrum的价值观,尊重团队的每一个成员的背景、经验，当然也包括开发任务的选择，还要鼓励成员能有勇气去选择和尝试。在实际的工作中，我们可以通过在墙上、白板等贴上标语（如“尊重他人”、“只有团队没有个人”等）的方式，让团队从思想意识方面发生转变，慢慢敢于去领取有挑战性的任务。此外，Scrum Master要充分保护好成员对有挑战工作认领的热情。如，防止在回顾会议上出现指责和批斗的情况，回顾和总结永远应该聚焦的是做事的方式方法而不是对人的苛刻和指责。总结以上三种没有人认领任务的情况，是比较常见的。但在真正的实际项目中，每个公司或团队的情况都不尽相同，无法穷举所有，应具体情况具体分析。比如，当一个公司首要考虑的是存活问题时，又比如一个刚刚转型的敏捷团队，在开发任务的领取上可能会更偏向于半指派半领取的方式，就像FAQ《从敏捷管理的角度来说，是团队主动认领任务好还是通过管理任务分发好》中所提到的，当团队敏捷成熟度较低时，可先由团队认领再让领导管控。这就好比中国经济一样 “以市场经济为导向，适当进行宏观调控”。但不管这个“调控”的力度如何，我们都应该鼓励团队成员能积极主动地领取任务,并随着任务的进展情况灵活调整，及时做好风险把控，必要的时候需要其他渠道的协调帮助或相关领导的介入，以保证迭代的目标不受影响。参考附录spike华为云DevCloudShould Team Member Sign Up for Tasks During Sprint Planning?文章博客地址：https://bbs.huaweicloud.com/blogs/152629

我们常见到Epic、Feature、Story和Task这些和敏捷相关的概念，它们之间的关系是什么？我们如何灵活使用这些概念，从而让敏捷的需求管理更为高效？本文为你解答，建议收藏。什么是Epic、Feature、Story和TaskEpic、Feature、Story和Task用来划分需求颗粒度的标签，可以看作需求占位符，分别代表需求颗粒度从大到小。每个层级的需求本身又承载着一些意义，在进行需求划分的时候可以进行参考。Epic：史诗，是项目的愿景目标。通过Epic的落地达成，使公司可以获得相应的市场地位和回报，具有战略价值。通常需要数月完成。Feature：可以带来价值的产品功能和特性。相比Epic，Feature更具体，更形象，客户可以感知，具有业务价值。通常需要数周，多个Sprint才能够完成。Story：通常所说的用户故事，是User Story的简称。是从用户角度对产品功能的详细描述，承接Feature，并放入产品Backlog中，持续规划，滚动调整，始终让高优先级Story交付给客户，具有用户价值。Story要符合INVEST原则（Idependent, Negotiable,Valuable,Estimable,Small,Testable），通常需要数天，并在一个Sprint中完成。Task：是团队成员要完成的具体任务。在Sprint计划会议上，将Story分配给成员，然后由成员分解为Task，并预估工时，通常在一天内完成。  将上面的描述简单整理，如下表所示。它们之间关系是什么Epic-Feature-Story-Task是一种将需求进行结构化管理的方法，在使用时是从上到下逐层分解，形成自下而上的依赖。如下图所示。在实际的开发过程中，需求会发生变化，我们要不断的调整，在调整中避免偏离目标方向，每次新建需求的时候都要记得向上对齐到Epic，保证所添加的Story和Task和它们上层是有关联的，这样就可以在一定程度上保证团队在朝着目标前进。更多关于需求结构化管理的内容，请阅读【参考附录】【DevCloud· 敏捷智库】如何进行需求结构化管理？。我们如何灵活使用这些概念，让需求管理更为高效为了帮助大家加深对 Epic、Feature、Story和Task的理解，我们对一个案例进行需求拆分，过程中会结合项目管理平台进行展示，以华为云DevCoud为例。案例：某大型商超受互联网的冲击，营业额大幅下滑。为了减少门店消费者流失，保有市场地位和份额，决定用6个月的时间建立自己的网上商城。第一步： Epic确定和创建根据前面的介绍，在进行需求确认的时候先看颗粒度，然后再考虑其承载意义。※思考：一个产品是一个Epic吗？产品的每个业务模块是Epic还是Feature？产品通常具有战略意义，从这个角度看，产品适合作为一个Epic。但是不是所有的产品都适合，还要看产品是什么，它的颗粒度有多大。在本文的实例中，网上商城周期是6个月，目的是保有市场份额，从颗粒度和战略意义上，网上商城适合作为一个Epic。每个业务模块具体是Epic还是Feature要分情况。比如：构建智慧城市是一个愿景目标，下面包括智慧交通，智慧政务，智慧社区等，这些每个业务模块都很大，用Epic进行需求占位合适一些。我们在DevCoud创建一个Scrum项目，命名为某大型商超网上商城，进入到【需求规划】的界面，在【Epic】下面新建，如下图所示。新建之后，点击进入到详细编辑界面。将描述信息填写完整，可以使用DevCloud提供的模板，如下：作为 <用户角色> ，对于这个Epic来说，用户角色是整个公司。我想要 <结果>，想要的结果就是建造网上商城。以便于 <目的> ，目的是想要减少消费者流失，保有市场地位和份额。同时在基本信息中设定这个Epic的起止时间，优先级，重要程度，预计工时等信息。这些信息对于团队理解产品、理解项目起到至关重要的作用，所以要填写详细。编辑界面如下图所示。第二步：将Epic分解为Feature客户要求在6个月内交付5个功能模块：促销管理、会员管理、订单管理、配送管理和客户端。团队的一个Sprint是2个星期，每个模块大概需要2-3个Sprint完成，从颗粒度和承载的意义，这5个模块适合作为Feature。创建如下。创建之后，如需要填写详细信息，可以在详细页面进行编辑。界面信息项和前面Epic的相同，此处不再赘述。第三步：Feature分解为Story敏捷开发是渐进明细的，不要求所有需求在相同时间做到同样详细，只要求当前Sprint和未来的一个或两个Sprint的Story是详细的。将来Sprint的Story可以是一个大概的情况。进入到当前Sprint的Story要符合INVEST原则。开发团队要在Sprint结束时完成交付。客户优先级中，会员管理Feature优先级高，会员管理这个Feature就要在需求梳理会议上详细分解为Story放入到产品Backlog中。经过分解后，需要包含和管理员相关的以下功能: 积分管理、会员级别管理、用户分析、用户管理。这些具体的功能就可以作为Story。需要注意的是，我们分解出的Story要尽量在一个迭代内完成交付，如果无法完成就尝试继续分解。因为只有交付的Story才是有价值的，无法交付的Story对于当前Sprint来说就是浪费。分解后的Story如下图所示。第四步：将Story划分为Task在Sprint计划会议上，团队和PO要共同从产品Backlog中按照优先级顺序选择本次Sprint需要完成的Story，进入到冲刺Backlog中。团队成员认领后，将Story分解为Task，并进行估算。※思考：Story和Task如何区分？Story聚焦价值，需要在Sprint中完成，要用数天的时间，要符合INVEST原则。Story的描述是一个名词，如积分管理这个Story的完整描述是：作为管理员，我能够进行会员的积分管理，以此来划分消费等级提供不同增值服务。Task聚焦实现价值，通过过程性的任务来实现Story的功能。通常是1-8个小时。Task的描述是一个动作。如积分管理这个Story，功能的实现需要通过业务逻辑开发，积分规则设计和积分数据库设计这几个过程来完成。这些就是Task。如下所示。这样，从Epic开始，到Task结束，我们完成了网上商城的需求拆分。总结：使用Epic、Feature、Story、Task管理需求时，需要注意以下几个方面。1.敏捷开发中需求是逐步细化的，遵循自上而下的方式去分解需求。2.Epic和Feature都是颗粒度比较大的需求，是用户对于产品的期望和功能特性的描述。3.分解为Story的时候，目前正在进行的Sprint需要分的更小更细，将来的Sprint需求（可能是3个及以上）就不需要那样细分。当进行到某个Sprint时，再进行分解，细分成一组更小、更细的条目。4.只有当前Sprint的Story进行Task分解。5.所有这些粗略和详细的Story都放在产品Backlog中，整个列表要遵循DEEP( Detailed appropriately, Emergent , Estimated , Prioritized )原则，定期梳理和排序优化，保证高优先级的需求优先实现和交付。6.在整个过程中需要和客户一直保持沟通合作，这样才能保证我们实现的功能是客户真正想要的。写在最后本文通过一个用户场景来帮助大家理解Epic、Feature、Story、Task的含义以及如何使用。因为没有相同的项目，所以在开发过程中还要结合产品和业务本身的特点，进行具体问题具体分析。为了更好的分析问题，我们需要扎实的掌握Epic、Feature、Story、Task的含义并理解他们之间的关系。相信随着大家深度使用，一定能运用的得心应手。敏捷路上，你我同行！参考附录1、Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。2、Mike Cohn.用户故事与敏捷方法[M].北京：清华大学出版社。3、【DevCloud· 敏捷智库】如何进行需求结构化管理？4、文章博客地址：https://bbs.huaweicloud.com/blogs/142259附件：【DevCloud•敏捷智库】读懂敏捷需求管理的4个关键词.pdf [hide]链接: https://pan.baidu.com/s/1O6viir4TtSoC2jWmRDfe_w提取码: diq8[/hide]