敏捷开发

以后软件行业的趋势偏向于使利用程序开发和部署成为业务经营的重要组成部分。这些公司开始专一于实现像DevOps解决方案这样的办法，这有助于缩短产品开发工夫。应用DevOps进行开发缩小了交付软件所需的阶段。软件交付工夫短容许用户尽早部署软件，并通过更多的反馈为业务减少价值。 DevOps与麻利的联合DevOps的施行次要集中在软件的各个方面，例如重视软件的可操作性、软件过程的自动化、可扩展性，以及每个版本的更好的部署形式以及它的监督和长期保护。DevOps的毛病是它不能反对麻利开发中反对的代码的继续测试。与DevOps不同，麻利次要关注产品是否满足客户的需要，因而专一于严格的测试。 与其独自应用DevOps和麻利来进行开发，不如将它们联合在一起作为一股力量来吸取二者的短处，从而使软件行业受害。这能够通过将麻利的冲刺与DevOps提供的集成团队单干来实现。因而，在软件开发中混合DevOps和麻利办法是进步生产力和交付高质量软件产品的要害要求。这种办法能够优化软件的增量开发及其保护。 DevOps和麻利联合的劣势●为公布过程创立了一个模式，并进步产品价值。 ●容许更好的合作。 ●升高公布版本的危险。 ●解决谬误和修复Bug的速度更快。 ●减少透明度。 ●产品质量进步，满足用户冀望。 二者联合需思考的问题为了防止遇到阻碍，让咱们来看看对DevOps和麻利开发的顺利联合和实现更高的生产率构成威胁的挑战。 1、在团队外部建设良好融洽的关系，确保工作流程顺畅进行。团队成员应该了解如何协同应用DevOps和麻利开发方法，并且应该拓宽本身视线，找出在不引起抵触的状况下充分利用二者的办法，并为减少软件的业务价值做出奉献。团队成员不应该只关注开发周期，还应该关注软件的保护、可操作性和交付等方面。团队应该是富有经验的，并且应该领有每个版本、服务、适应变更、如何治理变更、工具自动化的常识。 2、概述生命周期随着DevOps和麻利的集成，团队当初关怀整个开发生命周期中的操作。因而，应该制订一个适当的开发生命周期来进步一致性，最小化开发工夫，对每个版本提供全面的测试，并放慢产品交付的过程。开发生命周期应该包含开发阶段晚期的DevOps办法。 3、为冲刺调整DevOps麻利办法将开发过程划分为多个Sprint，然而当初无妨联合团队具体情况来设计一种策略，将DevOps正确地蕴含在Sprint中。 在sprint中遵循这些领导准则来集成DevOps●在打算冲刺时，征求经营和反对人员的意见并将这些意见纳入计划内。 ●同时思考产品的个性、性能及操作。 ●在接下来的冲刺阶段要思考到DevOps。 ●试着让devops团队参加scrum的每日站会、打算会议、回顾会议等麻利开发流程中。 蕴含质量保证麻利包含对每个版本的继续测试和集成，然而除了功能测试之外，它不提供性能和负载测试，这是DevOps所须要的。因而对于每个版本都应该包含这些测试。所以QA应该蕴含在开发的每个阶段。 在DevOps下执行待办列表在合作期间，在DevOps框架下构建待办列表，须要思考到：软件可扩展性、监控服务、部署能力、日志记录、警报设置、测试软件、平安问题、经营效力。 设施自动化工作流自动化是将DevOps和麻利办法联合在一起的一个重要局部。为了防止潜在的破绽，需自动化所有的编码过程。 提供文档麻利办法并不执着于文档；相同，他们更专一于开发，而DevOps记录了软件版本的设计和其余标准。因此，文档的提供仍然不可或缺。 禅道DevOps解决方案基于麻利开发方法论Scrum的禅道项目管理软件提供了DevOps解决方案，有助于布局和集成DevOps和麻利。 禅道对DevOps和继续集成的反对，包含Git、Subversion版本系统集成，Jenkins构建工作触发，以及ZTF自动化测试调度几个方面。通过禅道自研的ZTF自动化测试工具，可很好地驱动8种单元测试框架、3种自动化测试框架来执行测试，并把最终后果回传给禅道，进行对立的报告展现。禅道ZTF买通了项目管理和继续集成工具之间的沟壑，贯通继续集成、继续测试、继续部署等DevOps生命周期的不同阶段。 禅道，为您提供业余的DevOps解决方案。

作为麻利开发中测试团队的一员，在微服务测试过程中，你是不是也遇到同样困惑：服务不具备独立验证能力、自动化用例开发效率很低等？ 华为云DevCloud API全场景测试技术来支招~围绕API的全场景，打造6大测试服务为微服务的上线品质护航，快来看看吧~【传送门】 点击关注，第一工夫理解华为云陈腐技术~

作为麻利开发中测试团队的一员，在微服务测试过程中，你是不是也遇到同样困惑：服务不具备独立验证能力、自动化用例开发效率很低等？ 华为云DevCloud API全场景测试技术来支招~围绕API的全场景，打造6大测试服务为微服务的上线品质护航，快来看看吧~【传送门】 点击关注，第一工夫理解华为云陈腐技术~

技术人的发愁可不少 咱们的爆笑故事行将开始 看包不同如何乘风破浪 爆笑迎接工作中的诱（欺）惑（骗）与挑战~ 点击查看视频：《砸锅卖铁买兰博》 包不同：入行半年的码畜；精通多种支流语言的Hello Word写法；乐于助人，常常被动为团队提供各种BUG。 《包不同的沙雕麻利》故事次要讲述立志成为麻利大咖的技术小白包不同在麻利工作中的日常，与共事之间舒适搞笑的生存故事。是不是还没过瘾，别着急~~~ 下一期，咱们不见不散哦~~~

摘要：在前两篇文章中咱们对影响地图有了一个认知，本篇文章将持续为大家带来技术大咖在利用麻利开发过程中的想法和思考。1. 影响地图的作用影响地图，它能够很好得把战略目标（不论是公司级的或产品、我的项目级的）和工程师的日常工作有机联合起来。并且以可视化的形式出现在所有人背后。这样一来，当有新工作涌现进去的时候，咱们只须要对照影响地图，看看它是否满足某个角色对于指标的影响。如果不是的话，那么这个工作就须要当前解决或摈弃掉。 另外，影响地图也是策略和公布、迭代之间的良好润滑剂。它能够使团队更分明地做正确的事件，而不是正确地做事。 还有，影响地图不适宜用于保护我的项目，比拟适宜新产品的摸索（不确定性较高的我的项目）。并且影响地图须要资深的技术人员和业务人员独特参加编制。 2. 如何编制影响地图在这次工作坊中，大家在编制影响地图的时候碰到几个问题。整顿如下： 影响地图中的影响（HOW）怎么写？首先咱们要了解影响地图的构造：指标，角色，影响和性能。那么影响是什么？影响就是某个角色对于咱们指标所产生的影响（能够是正向或负向的影响）。比方这几个问题可能会帮忙你更好的了解影响。_角色的行为应该如何产生扭转？某角色如何帮忙咱们实现目标？他们如何障碍或阻止咱们实现目标？_这些都是影响。同理，对于性能（WHAT），就是对于某个角色为指标所产生的影响，咱们能够通过什么办法实现。 影响地图中的指标怎么确定？对于一个残缺的影响地图，指标是至关重要的。那么个别状况下，如果指标不明确的话，我个别倡议能够为了指标而独自筹备半小时或更长的工夫（视指标的复杂度而定）。对于指标的大小，能够是公司的策略级指标，也能够是某个产品或我的项目级别的指标。对于指标的规模，如果是互联网公司，倡议能够设定3个月到6个月工夫的指标。如果是传统行业，能够是6个月到12个月的指标。当然，这个只是一个参考，须要依据具体的状况而定。 3. 最初还要介绍一个十分重要的办法——帕累托法令。帕累托法令，也是咱们常说的二八定理。为什么介绍这个法令呢？这是因为咱们在做事的时候不可能尽如人意，做到非常完满。那么咱们可能会须要花20%的精力来致力取得80%的后果，就能够了。最初那20%的后果，往往是不值得付出（投资）的。对应于影响地图中，也是一样的情理。咱们要记住，影响地图是动静的，涌现的。这个地图不是说画好了，大家照着办。而是时刻揭示咱们这是假如，须要去验证。一旦验证失败了，疾速的转到其余假如。如果验证胜利，那么基于此咱们还须要深度验证并坚固咱们的后果。 总之，影响地图是一个十分好的工具。它能够无效地链接指标与工作。举荐大家都看看这本书。 想要理解更多麻利开发中影响地图的内容，请关注7月30日19：30《兴妖作怪的哥哥们对于麻利开发的PK》直播，看华为云大咖们如何通过简略易用工具一举突破业务和研发间接的壁垒， 戳这里→理解详情。

摘要：团队用于估算时间过多，留给开发的时间会相应减少，大家工作紧张，状态不佳。团队过度承诺直接造成迭代目标不能完成，士气低落。以上弊端直接伤害敏捷团队，是敏捷团队保持稳定健康节奏的阻力。背景敏捷江湖桃花岛社区下线会议时，敏捷实践者问了很多关于估算的问题。作者在这里把具有共性的问题简单做了梳理。问题主要集中在团队只关心估算结果，也就是数字。再则团队经常在外界压力下过度承诺迭代目标。这两个比较集中的问题描述如下： 问题一：团队只关心数字。计划会议大家只关心估算的数字，经常花费大量时间做估算，怎么办？ 问题二：团队过度承诺。有时候，团队被迫承诺过多的工作，迭代目标完不成，怎么办？ 团队用于估算时间过多，留给开发的时间会相应减少，大家工作紧张，状态不佳。团队过度承诺直接造成迭代目标不能完成，士气低落。以上弊端直接伤害敏捷团队，是敏捷团队保持稳定健康节奏的阻力。 问题分析以上两个问题也是敏捷初始团队经常遇见的问题，现简单分析发生原因如下： 问题一：团队只关心数字。 团队从瀑布开发方式转为敏捷开发后，学习了敏捷Scrum框架，然后开始使用敏捷开发。他们知道其中有一个事件是迭代计划会议。在会上团队成员经常耗费大量时间做估算。常见对话：“这个估算数字合理吗，我们要不要再好好想想清楚？”因此团队常常陷入无休止的讨论中。团队狭隘的理解为，计划会议中最重要的事情就是估算，而估算最重要的事情就是得到每个用户故事完成所需要花费的精确时间，即数字。也就是说，团队过于追求数字的准确性，忽略了估算的真正核心价值。 问题二：团队过度承诺。 团队经常在产品上市日期已经确定的情况下过度承诺。因为时间紧迫，领导施压（与资金和绩效挂钩）。比如，领导经常说：“大家加把劲儿，我相信大家的能力，努力一下，这些需求你们是可以做完的，大家的表现会影响绩效评估，年底咱们多发点资金。”所以团队常常了了估算、一言堂（架构师说的算）、猜测工作量，最后造成过度估算，经常完成不了迭代目标。 小结“团队只关心数字”和“团队过度承诺”两个问题是敏捷初始团队经常遇见的问题。从以上问题分析中可知，团队成员并没有了解估算的真正核心意义，导致团队狭隘地理解成估算就是要最后的数字，而且在有外部压力的情况下团队也顾不上认真估算，盲目地过度承诺工作内容。 其实估算并不只是为了得到估算数字和不靠谱的承诺。我们先一起学习和了解什么是估算的核心内容，这样可以更好地理解估算，然后再针对以上2个问题进行解答。 解决措施利用核心概念树立正确认识 在这里，我们只考虑不了解核心概念而导致估算活动不理想的情况。还有其它情况可以导致估算活动不理想。比如，不会利用故事点估算、不会估算具体方法等。这两种情况我们在后续的2篇文章中给予解答。 通过上一篇《估算第一篇：利用用户故事了解需求》相信了解了如何利用用户故事理解需求。如果对用户故事不太了解的朋友，建议可以花一点时间阅读上篇文章，也会有助于做好估算。 现在我们一起了解一下估算的4个核心概念，以便理解估算，树立正确认识，然后才能更好地解答以上2个问题。估算的4个核心概念所对应解决的问题如下表所示： 区分准确与精确 估算应该准确，但不必过分精确。比如，我们估算某产品是10888人时（是怎么做到这么精确的？）。其实这是很荒唐的，过于精确的估算纯属浪费。我们需要应该投入刚好够用的工作量，得到一个刚好的、大致正确的估值，如做估算时工作量和准确度的对比图所示： 做估算时工作量和准确度的对比图 在做估算时，有一个收益递减的点，在这个点之外，额外投入任何时间和精力都不会使估算更准确。在这个点之外，就属于浪费时间。 团队成员在做一项工作的同时，难免会遇到各种各样的问题，所以为了做到准确估算，在做估算时，任务的拆分一定要适当细，只有细化后，团队成员才清楚每项工作预计会花多少时间。当然细化也是有个度的，如前面提到的做估算时工作量和准确度的对比。当团队成员反馈超过预计工时时，需要了解是不是遇到了什么困难，需不需要帮助解决。超过16小时的任务建议需要再细化。 在做估算时，我们经常会填写预计工时和实际工时。预计工时是我们估算的结果，实际工时是对估算结果的检验。我们允许预计工时的不准确，但是一定要填写准确的实际工时，这样才有助于我们在估算不准的问题上有充分的证据做分析，然后改进，进行良性循环。随着团队成熟度的提高和对业务的越来越了解，估算准确度经过几个Sprint会有所提高。 估算相对大小 建议使用相对大小而不是绝对大小来估算PBI。比较所有条目，然后确定某个条目和其它条目的相对大小。如下图所示，讨论一个杯子相对于另一个有多大比较容易，但对于杯子中可以盛多少绝对数量的液体，我们可能没有概念。 相对大小对比图 人们更擅长对大小进行估算，而不是绝对大小。让团队成员做估算，建议用大家都擅长的技术。当然，有些较成熟的团队，也可以借鉴历史数据和经验，直接应用工时或理想人天估算也并非不可。更多关于相对大小的内容介绍，可以阅读下一篇《如何估算第三篇：估算故事点》，其中会介绍一个具体实践，即故事点估算。 团队一起估算而不是个别人估算 在估算活动中，团队成员一起估算，而不是仅仅由项目经理、架构师、主要程序员估算。简单说，是负责完成工作的所有人，也就是指实际动手设计、构建并测试PBI的开发团队来估算。产品负责人和Scrum Master这两个角色都在场，但并不实际参与估算。产品负责人负责阐述PBI，并回答团队要求澄清的有关需求的问题。Scrum Master负责帮助指导和引导估算活动。最终的目的是开发团队能够一起确定每个PBI的大小，当然包括开发和测试的所有工作量。团队成员一起估算也是为了确保工作没有遗漏，不管怎么拆分任务，甚至是不拆分任务以story为最小颗粒度，那就按照story可以上线为标准来估算。如果团队非常关注每个人手头上的task，比如测试和开发人员手头上的task，那就没有统一标准，根据具体task内容估算。 记录工作项工时，可以参考华为云DevCloud，工作项工时显示如下图所示。 需要客观估算而不是盲目承诺 估算不是承诺，重要的是我们不能这样认为。举一个例子，如果在估算的时候告诉团队成员他们的估算正确性直接影响着他们的奖金和绩效，那么每个人都会给出一个比开始大得多的估值。估算应该是较为实际的估值，应该靠谱，我们不想因为外因而人工放大估算值，变成团队成员往上加和管理层往下减的抛球游戏。 所以，团队成员在没有外因干扰情况下，大胆、放心的估算工作量，也就是估算预计工时。预计工时不仅仅是用于安排任务和估算本Sprint PBI在哪个时间点完成的,它还可以用于持续改进。预计工时就是估算需要多少时间可以完成，在Sprint进行中，会让团队成员根据实际情况去更新实际工时。例如，昨天更新4小时，今天又更新4小时，那就把实际工时更新为8小时。当Sprint结束后复盘时，我们会整体看这些预计工时和实际工时的数据，主要是为了提升团队/个人估算水平。如果估算和实际有明显差距，是需要深入分析的。本身也是期望通过估算促进做简单设计。 应用正确认知处理问题，做好估算以上是估算的核心内容。现在我们回头看看之前的两个问题。 问题一：团队只关心数字。 面对这个问题，作者主张团队成员不要只是关心数字，还要关心投入产出比（ROI），避免浪费。另外还可以考虑采用更快、更易于理解的方式来进行估算。 从估算的核心概念“准确与精确”中了解到，在做估算时，有一个收益递减的点，在这个点之外，额外投入任何时间和精力都不会使估算更准确。在这个点之外，就属于浪费时间。另外从估算的另一个核心概念“估算相对大小”中了解到，人们更擅长对大小进行估算，而不是绝对大小。让团队成员做估算，建议用大家都擅长的技术。因此，我们在做估算时：首先，要把握一个估算的适度准确原则，不要过度浪费。其次，为了降低难度，团队更好的达成一致意见，可以采用相对大小方式进行估算。 问题二：团队过度承诺。 面对这个问题，作者主张估算由真正完成工作的成员在安全的环境下大胆、放心地估算，避免过度承诺。 从估算的核心概念“团队估算”中了解到，估算活动是负责完成工作的所有人，也就是指实际动手设计、构建并测试PBI的开发团队来完成。也就是说，真正完成工作的人才会对工作需求内容更用心，也更了解团队的速率，他们的承诺更客观。估算另一个核心概念“估算不是承诺”中提到，估算应该是较为实际的估值，应该靠谱，我们不想因为外因而人工放大估算值，变成团队成员往上加和管理层往下减的抛球游戏。团队成员在没有外因干扰情况下（不建议奖金、绩效明显挂钩），大胆、放心的估算工作量。如果能做到以上相信至少在估算的结果上更为客观和靠谱。 有些朋友可能会问，如果得到的估算结果是靠谱的，完成需求就是那么多工作量，产品上市日期也已经确认，那么怎么办？如果真的是因为产品上市日期已定，有上线压力，团队一定要承诺过多的工作内容，那么就确保团队把故事拆分得更细，即使他们交付不出设想中的高档理想的全功能版，至少也能每个典型的功能领域多少交付一些内容。说到这里，还是不建议这样做，尽量采用高价值的事情优先做原则，与客户协商，产品经理对需求排好优先级，优先实现高优先级的PBI。 了解更多以上是针对不了解估算核心概念而导致估算活动不理想的解决措施。朋友们看到这里，相信对估算的核心有了基本了解。也许对什么是故事点估算以及具体估算方法感兴趣，欢迎阅读接下来的关于估算的另外两篇文章，即《如何估算第三篇：利用故事点做估算》和《如何估算第四篇：利用2种常见方法做估算》。 参考附录 Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。Rachel Davies. Liz Sedley.敏捷教练[M].北京：清华大学出版社。点击参与评论，获取下载资料]

敏捷开发实行中的工作职责敏捷开发前期产品在指定需求时需要保证需求的完整性，保证每一个需求是独立的、完整的、可上线的将需求池中的需求按优先级排序根据优先级&关联性选取本次迭代的需求（Sprint Backlog）对需求清单进行预热，将本次迭代的需求清单在计划会议（Sprint Plan Meeting）前发放给参会人员在计划会议（Sprint Plan Meeting）中能清晰描述需求并应对其他成员的疑问在计划会议（Sprint Plan Meeting）中给出验收标准开发在计划会议（Sprint Plan Meeting）前预习本地迭代的需求清单（Sprint Backlog）在计划会议中（Sprint Plan Meeting）能提出质询，给出意见，进行合理的工时规划在计划会议后开发进行前需要熟悉自己所负责的开发任务（Task）相关的业务，如果是在原有业务上改动则需要阅读原有的设计文档，进行合理设计规划撰写设计文档&接口文档master组织相关人员参会（Sprint Plan Meeting）对Sprint Backlog、Task工时 给出合理建议敏捷开发进行中产品追踪Sprint Backlog的进度若有需求变更需要在站会（Daily Meeting）中提出并更新在看板上开发每天的站会（Daily Meeting）上更新负责的Task的进度在站会（Daily Meeting）上及时提出开发中遇到的阻塞及问题配合测试测试站会上及时更新测试进度，提出测试中遇到问题master组织站会（Daily Meeting）&站会发言协调组内成员之间的配合疏通开发&测试中遇到的阻塞更新本次迭代的燃尽图（Sprint burn down chart ）敏捷开发收尾产品验收参与回顾会议（Sprint Retrospective Meeting）开发参加评审会议（Sprint Review Meeting）参加回顾会议（Sprint Retrospective Meeting）测试参加回顾会议（Sprint Retrospective Meeting）master组织并主持回顾会议（Sprint Retrospective Meeting）

Scrum是由Ken Schwaber和Jeff Sutherland在20世纪90年代提出的概念，并在1995年首次正式确定。起初Scrum是为了解决产品和软件开发固有的复杂性，然而现在Scrum被成功地应用于市场营销、组织变革和科学研究等多个领域的复杂问题。 Scrum主要建立在以下三个原则的基础上： 透明度：你需要收集数据（比如一些指标、团队成员的反馈或其他团队的经验之谈），从而找到你的目标。检查：你需要和大家一起监督迭代的进度，并决定迭代完成的标准是什么。适应：你需要做出改变，希望能更好更快地完成你的目标。 在实施Scrum之前首先要用一段时间来定义和调整这些规则，以发现工作中的问题，找到可以改善的方向，这里说的问题不是那种一年一次或项目完成时才发生的问题，而是每天、每周或每月都在持续发生的问题。我们不是将我们的决策建立在对可能永远不会发生的潜在风险的假设上，而是根据我们收集到的数据来做决策，这就是所谓的经验主义。 Scrum的价值？当你需要接受你并不了解和无法控制一切的时候，Scrum提供的经验方法就会变得非常有用。也正因如此，你会改变之前的想法，虽然可能会犯错，但也会有新的、有价值的想法出现，而这些是你从未考虑过的。与其在前期制定一个精确的计划，然后无论如何都要坚持下去，不如把你的想法当作假设或假说，用Scrum的方式来验证。 Scrum可以让你快速了解自己是否偏离了轨道，是否需要做出调整，而不是简单地按照计划行事，你可以先解决你目前面临的最大风险。当你在一个不确定的、不断变化的环境中工作时，这一点尤为重要。你一开始的假设在当时可能是绝对正确的，但是当你在开发产品的时候，环境可能会发生很大的变化，以至于你的整个方案都失败。在一个漫长的项目结束的时候，经验主义的方法并不是灾难性的失败，而是将其降低为一个小的减速带，需要你修正一下方向。 所以，实际上Scrum是降低了复杂的、适应性问题、固有的不可预测性和不确定性的风险。它允许你不断地验证你仍然在做正确的事情，并朝着解决你设定的目标前进。更好的是，你现在有了一个积极发现更好想法的过程，并将其纳入到下一步的塑造中。现在，不确定性反而变成了一件好事，因为其中蕴含着所有的可能性。 "Scrum降低了复杂的、适应性问题固有的不可预测性和不确定性的风险。"Zombie Scrum和效率思维模式那么，Zombie Scrum与这一切有什么联系呢？我们发现一个现象：人们使用Scrum的起因很多都是错误的。当你问一个Zombie Scrum组织中的人，他们希望从Scrum中得到什么时，你会听到诸如 "更快"、"更多的大脑"、"更多的产出 "和 "更高的效率"。这与 "敏捷 "这个词的实际含义是非常不同的。这与Scrum的设计目的也大相径庭。这种矛盾从何而来？ 传统的组织管理和产品开发方式是为了实现与敏捷性相反的目标，这种心理模式通常被称为 "效率思维模式"。它的目的是尽可能地减少不确定性，提高可预测性，推动效率的提高。这通常表现为会制定详细的计划，通过协议和程序使工作标准化，高度的任务专业化，以及衡量效率（如每天的工作量、出现的问题） 。这种思维模式当然可以在工作相当重复和简单的环境中发挥作用，比如流水线化的工作或某些行政工作，但在人们处理复杂的、适应性强的问题的环境中肯定行不通，因为这些问题本身就具有不可预测性和不确定性。 "效率思维模式的目的是尽可能地减少不确定性，提高可预测性，推动效率的提高。" Zombie Scrum与领导强烈关注绩效和工作量是有很大关系的，但最终客户是否满意？是否交付了有价值的东西？却无人问津。而且，这种思维模式在很多企业中是根深蒂固的，它已经成为一个我们不需要讨论的 "真相"。这样的企业是想试图用Scrum来影响效率、速度和产出的角度来理解它是有道理的，只不过当发现Scrum似乎并没有做到这一点时，人们就会感到失望。 从非常广泛的意义上来说，Scrum关注的更多是效率，而不是高效。效率是为了尽可能多的完成工作（产出），而高效则是为了工作的价值和有用性（结果）。虽然完全有可能通过Scrum提高效率，但这既不是承诺也不是目标。 在充斥着 "Zombie Scrum"的环境中，大家是很看重“效率思维”的，以至于人们只看到Scrum的结构性元素：角色、事件和工件。他们没有看到也没有体会到这个过程的价值。这就是为什么Zombie Scrum只是看起来像Scrum，但没有其精髓。 "Scrum更关注的是有效（结果），而不是高效（产出）。"在这篇文章中，我们提到了Scrum的三个原则，如何在必要的时候重复进行，以捕捉工作中出现的偏差、意外发现和潜在机会。Scrum中的所有内容都是围绕这三个支柱设计的。这也是经验主义发挥作用的原因。采用Zombie Scrum的组织，往往有一种效率思维，目标是尽可能减少不确定性，提高可预测性，推动效率。这与在复杂工作中学习和发现的经验主义过程相矛盾。 原文作者：Barry Overeem 翻译整理：Worktile Worktile 官网：worktile.com 文章首发于「Worktile官方博客」，转载请注明出处。

原文地址： https://medium.com/startup-pa... 翻译君：敏杰小王子上周，我站在一家市值 200 亿美元的公司的会议室里，推动了一个关于敏捷的研讨会。出席会议的小组由这家大公司的一个产品线中的每个职能部门的董事和部门经理组成。从 UX、工程和产品管理的岗位中挑选出来的十几位领导者组成了一支团队，他们代表着约 150 人的产品线。作为一个团队，他们踏上了“敏捷”的旅程。 这不是我们平时认为的企业转型。他们的高层既没有明确支持也没有明确阻挠这次转型，这家公司对敏捷的官方态度最准确的描述是“良性冷漠”。因此，这个团队基本上只能靠自己来尝试，无论最终结果是成功还是失败。 我在那里的唯一原因，是因为到目前为止敏捷旅程还不顺利，我的任务是帮助他们找出症结并解决它。好巧不巧，他们出现的问题与我在过去 5 年中遇到其他团队的原因相同。为简单起见，以下都是直言不讳的事实陈述，但也并非都适用于您的情况。 不明确的愿景如果你在办公室走廊拦住任何团队成员，问他：“同学，我们产品的长期愿景是什么？”他们能否用一两句话来回答？八成不行。他们可能对目标客户有所了解，也可以明确地知道解决方案的功能。但是，他们真的可以说出客户想要解决的痛点吗？我猜不会。 一些高级管理人员在权利更迭期间，以临别顿悟为基础传达了自己的“突发奇想”。这个“想法”被投入了预算计划角逐会议中，这位特别的高管最终赢得了影响力战，并得到了 12 个月的项目资助。紧接着这一消息的所有内容通过一个既成事实的 PPT 传递给你，功能和时间表提前计划好了，你被正式告知“请实现它”。现在你正试图完成那个不可能完成的任务，并希望敏捷能帮到你。 解决方案：花一些时间阐明产品的清晰愿景，使用业务模型或精简图片表达您的设想，邀请团队中的每个人参与，将这些设想反馈给高层管理人员（如果他们拒绝参加），并确保你的相关信息出现在同一页面上。 PS：如果他们找你麻烦，给我打个电话。 被混淆的业务指标该团队不会考虑日常的成本和收入。事实上，团队可能不知道公司要让他们赚多少钱，他们也不知道他们需要拓展多少客户，每个时间段需要支付多少钱，以便他们在这个疯狂的想法上实现收支平衡。他们基本上不太关心自己的工资来自何处。 但如果你问大多数初创公司，他们对自己整体燃烧率和销售业绩会有更好的了解，因为收入和盈利能力对于他们来说始终是最重要的。 其实这个成本在任何情况下都不难计算。直线经理（Line Manager）通常可以在几分钟内得出工程团队燃烧率的准确数字。然后当我们将这个数字（实际成本）与我们当前的销售数据（我们作为一个团队实际产生的收入）进行比较时，这就会是一个全新的业务竞赛。 译者注：直线经理（Line Manager）是指诸如财务、生产、销售等职能部门经理，每一个直线经理肩负着完成部门目标和对部门进行管理的职责。 解决方案：计算您的产品成功所需的团队收入和成本，并确保每个人都知晓。它很有可能会让人大开眼界。您应该在下一次业务规划会议上与您的团队一起尝试。 持续不断的干涉由于方向上的某些紧急变化，您最后一次中断正常工作流是什么时候？它可以是最近的客户投诉或请求，也可以是来自首席执行官措辞强烈的电子邮件——邮件涉及团队在上周产品演示中使用的配色方案。 无论如何，如果你总是打破团队的正常工作流，会给团队带来巨大的压力。这种压力转化为吞吐量降低、士气低落、人员流动率增加、航运延误、工艺粗劣、以及对团队绩效的普遍拖累。所以把这个坏习惯丢弃掉吧，您并没有因为在组织中的管理地位而拥有在事务优先级排序方案中的特权。 解决方案：每周为计划外工作分配一些容量，比如总容量的 20％，只安排 80％ 的团队时间，而不计划其余的时间。可以在发生“紧急情况”时使用此容量，而不会影响原来的正常计划。无人认领的话可以用它来偿还技术债务。您可以轮换团队成员来执行此操作。 不够专注的团队我工作过的每个大公司都有这个问题。项目中的大多数人被分配到多个其他项目当中。当我问团队中都有谁时，我得到的答案一般是某位工程师分配了 50％ 在这个项目上，而某位工程师与我们在一起的时间占 20％，超过一半的项目人员将一半以上的时间花在其他项目上。难怪项目的最终结果往往是事故，因为这种工作方式不管用。 产品开发是一项团队活动，团队成员之间需要极大的关注和大量的沟通和协调。您团队中的每个人在部分时间内被分配到其他项目，这会使交付日期常常延迟数周或数月。 关于这一点我从企业管理者那里得到了更多的案例，举一个具体的例子，你也许会问：“我们真的需要在团队中设置专门的产品体验人员吗？如果他们一半闲着怎么办？我们不是在浪费钱吗？” 让我们思考一下： 假设你有十个工程师和一个交互设计师（本来不应该是这个 1/10 的比例，但你可能会这样做，所以我们姑且先这么选着）。设计师为工程师构建了 100 个线框，现在你有 10 名工程师开始工作，设计师又回到了其他项目。工程师几乎立即向设计师提出了要求，但设计师此时被其他项目束缚，所以工程师必须等待（延迟）。也许工程师选择打开另一项任务并开始工作。当设计师重新上线时，工程师必须暂时放下第二个任务以重新打开第一个任务（延迟）。 现在，第二位工程师需要帮助，可能还有第三个工程师，他们都在等待（延迟）。设计师再次有空并开始与第一位工程师合作，而其他两位排队等候（延迟），后两者的任务未完成（延迟）。所有三位工程师都失去了他们正在研究的一些事情的背景（延迟）。 在与第一位工程师合作时，设计师发现了设计中的错误，需要更新所有 100 个线框（大延迟）。现在，每个工程师都必须停止并重新检查他们的工作以应对新设计（大延迟），已经完成的一些工作必须废弃并重新开始（更大的延迟）。 所以你是选择固执己见还是有所改变？您可以试试把上面的示例中替换成后端 API 开发人员，事情的结果会变得更糟。 解决方案：请组织小型、跨职能、专注的团队，将一小组作为一个单元一起工作，并不断获得双方关于事务进展的反馈与澄清。 分散各地的团队大型企业团队往往由一个地理位置分散的大型池的“资源”组成（原谅我用“资源”这个词）。因此，企业产品团队的成员处于不同的时区和地区，这使得沟通协调效率低下且成本昂贵，结果就会发生很多延迟等待和错误传达。远程通信的保真度绝对不如面对面沟通，视频通话确实让沟通变得更容易一些，但它与能够一起走到白板前讨论出来的东西并不相同。 解决方案：将所有团队成员放在同一个房间，或至少在同一建筑物的同一楼层。如果您必须与远程人员一起工作，请根据康威定律分解任务，按地理划分（具有明确定义的接口的模块）而不是按功能划分（设计、工程）。 太过臃肿的团队通常情况下，在企业中找到大型团队来构建产品不是那么复杂的事情。但由于各种原因，团队规模常常大得惊人，这主要与高管倾向于通过指挥大群人来建立自我的事实有关。 100 名工程师构建一个 SaaS 产品？你确定？较大的团队效率更慢，因为协调成本是巨大的。您需要更多层次的管理，更多会议和更多文档。大型团队对其速度的负面影响随着其增长而渐渐变得更强烈。 解决方案：您应该使用尽可能小的团队在企业中构建产品。如果你可以把它减少到几十个，甚至一打，那就更好。 太重的技术债务企业往往有很多旧的代码库。然而这并不是企业敏捷团队积累技术债务的真正原因。我敢打赌，您当前项目中的大部分技术债务是从您当前项目开始以来由您的团队创建的，而不是通过来自较旧的遗留系统的继承。 这是因为，尽管敏捷社区重复了 15 年： （1）结对编程技术实践的重要性 （2）测试驱动开发 （3）对代码的持续集成但非常少的企业团队真正去做这些事情。出于各种原因（主要是因为那些专注于流程而非卓越技术的大型咨询公司向高管出售的所谓“敏捷”），企业敏捷团队很少接受：核心技术实践使得敏捷出色。结果大型的工程团队开始设计和执行有缺陷的系统，然后在漫长而痛苦的发布周期中相互折磨。 ...

官方《Scrum指南》中定义：Scrum Master在Scrum团队中属于服务型领导，负责践行和支持《Scrum指南》中定义的Scrum，要帮团队的每个人理解Scrum理论、实践、规则以及价值观。 最近我们进行了一次调查，其中92％的受访者表示他们正在实践的scrum是按需定制的，而非“按章办事”。这让我们想知道，这对扮演训练和帮助团队理解scrum角色的scrum master来说意味着什么？ 这些scrum master是如何适应不断发展的且有别于官方规定实践的敏捷世界的？ 为了回答这些问题，我们对敏捷行业的无名英雄——scrum master的角色和责任进行了深入研究。 Scrum Master是什么？Scrum Master是scrum的推动者。scrum是一种轻量级敏捷框架，专注于实现固定时间的迭代，也被称为sprint。作为推动者，scrum master充当团队其他成员的教练，在《Scrum指南》中被称为“服务型领导”。优秀的scrum master致力于构建scrum的基础和价值观，同时保持一定的灵活性和开放性让团队有机会改进工作流程。 1.Scrum Master的职责在理想的敏捷世界中，团队可以管理自己的流程和工具。然而，我们发现许多团队通常需要依赖scrum master作为其流程的主导者才能实现敏捷的飞跃。要实现对团队的掌控，并履行职责，scrum master需要花费大量的时间。在这种变革性的背景下，scrum master的工作可以很轻松，如仅安排scrum相关仪式；也可以很繁重，像团队的其他成员一样深度参与整个过程。尽管《Scrum指南》列出了scrum master应该如何为其他角色提供服务，但关于scrum master的责任义务并没有详细列出来。事实上，我们发现，scrum master通常需要执行下面部分或全部并没有在scrum中定义的工作： 1.站会 ——根据需要促成每日站会（或每日scrum会）。2.迭代/sprint规划会 ——确保团队不会承担过多或超出能力范围。帮助团队进行估算及子任务的创建。3.sprint评审会 ——参加会议并记录反馈。4.回顾会议 ——记录需要改进的领域和后续sprint的行动项目。5.委员会管理 ——承担Scrum委员会的管理工作。并且保证信息的即时性及Scrum工具（Worktile或其他工具）运行良好。6.一对一谈话 ——根据需要与团队成员和利益相关者单独谈话。化解团队对在流程和工作方式等方面的分歧。然而许多scrum从业者都反对一对一谈话，因为他们认为这些交流应该在每日站会上进行，一些团队，特别是新团队，更倾向于请scrum master与个别团队成员定期进行面对面交流。scrum master则认为这些单独的交流互动对于团队发展和成员之间的彼此了解至关重要。7.内部协商 ——scrum master应该与团队成员和内部利益相关者进行协商，就如何更好地与Scrum团队合作达成一致。8.报告 ——定期分析燃尽图和其他投资组合规划工具，以了解团队正以什么样的节奏构建产品。9.护航者 ——scrum master通过消除外部障碍和改进过程或工作流管理内部障碍等方式为团队提供支持。10.代劳杂务 ——如果scrum团队没有处于忙碌的状态，那就是scrum master的问题。因为这意味着团队可能在修理坏掉的电脑、挪动周围的桌子甚至调整恒温器。Scrum master应该随时准备好做任何可以帮助团队的事。如果团队真的需要的话，scrum master甚至需要为成员准备咖啡和零食，以确保成员不需要在此类杂事上浪费时间或趁机磨洋工。 2.你的团队是否需要一个scrum master？任何一个scrum培训师都会告诉你，每个scrum团队都应该有一个scrum master。如果没有，那么你们的scrum就算不上真正的scrum，经常被叫做scrum-but。 在团队刚开始尝试scrum的时候，有一个具备scrum工作经验的scrum master可以带来很大的帮助曾，当然，曾经见证过很多scrum成功案例者更佳。也正因为这个原因，很多scrum master经常被聘用来担任顾问，而非全职员工。 但每个scrum团队都是独一无二的。很多经验丰富的团队承担前面列出的所有关于scrum master的责任，享受由团队成员共同管理的流程并为此感到自豪。这种情况下，scrum master的角色将由团队成员轮流承担，并轮流组织召开每日站会和回顾会议。 而对于一些团队来说，正确的做法就是请一个专业人员来担任scrum master。 不幸的是，由于对scrum master角色存在误解，所以经常导致现任管理者认为scrum master是他们岗位职责的一部分。为了更好的理解为什么这样做会造成问题，以及为什么要在组织中单独设立scrum master的角色，我们将scrum master的角色与组织中现存的非scrum角色来做一个对比。 Scrum Master和产品经理正如我们在《敏捷产品管理概述》中提倡的那样，产品经理与开发团队之间的互动越多越好。这种互动应该与产品负责人的想法保持一致：支持客户需求且清楚为什么开发这款产品。但如果这种互动模糊了任务-即团队该怎么实现功能，那就说明互动存在问题。尽管出发点很好，但这种利用型心态会导致问题被隐藏或掩盖，如：缺陷、交接和未知问题等。交错范围和进程很容易锁定范围、进度和质量，而这注定导致失败。 这就是为什么scrum master和产品负责人在scrum团队中分别满足两个不同需求的原因，但这两个角色在传统软件管理中通常是由一个人来担任。规模较小的团队也很容易就为了节约支出而省掉scrum master这个职位。只是，一旦有障碍出现或变动发生，团队就需要在流程管理和产品方向之间进行明确划分。 团队中如果有scrum maser就可以帮助团队实现因改变产品方向所带来的消耗和由效率提升所带来的收益二者之间的平衡。一个优秀的scrum master通过赋予团队权利，让他们自行决定如何通过自组织的方式以最好的方式实现目标。Scrum Master和项目经理在非技术（或非敏捷）领域与scrum master角色对应的是项目经理的职位。这两种角色都专注于“如何”完成工作并通过过程和建导解决工作流程的问题。那么我们是否同时需要这两个岗位呢？大多数情况下是不需要的。传统的项目经理和scrum master都有责任帮助他们的团队完成工作，但他们的方法却截然不同。项目经理设定时限和里程碑、报告进度并协调团队沟通。从控制的角度实施工作，扮演一个比较传统的管理者角色。Scrum Master则旨在帮助团队强化和精简实现目标的流程。理想状态下，他们是以团队成员或协作者而不是控制者的身份开展工作。最好的Scrum团队是自组织的，因此自上而下的管理不会取得好效果。 ...

近日，CODING 在 KubeCon 2019 上海站上正式推出了 DevOps 的一站式解决方案：CODING 2.0。 CODING 2.0 进行了产品、产品理念、功能、首页的升级，对用户服务进行了整体升级。从代码托管到 DevOps 全流程覆盖，CODING 作为国内 EAP 工具的代表，一直立志于探寻最适合中国软件研发团队的研发管理方式。此次 CODING 2.0 的推出也标志着 CODING 在为用户创造更高价值的基础上，通过强化研发工具的深度和拓宽部门协作的广度，实现软件研发流程的全覆盖并打破部门之间的隔阂，真正聚焦大型项目 DevOps 实践，助力企业实现从战略到产品的落地并达成持续性交付的研发模式。 点击下方，了解所有 CODING 2.0 升级资讯： CODING 2.0 企业级持续交付解决方案 CODING 2.0：为什么我们需要 DevOps CODING 2.0 服务升级：一站式服务体系助力企业研发上云 CODING 2.0：如何通过设计给品牌创造价值？ 打通 DevOps 任督二脉 CODING 2.0 制品库全新上线 拥抱自动化，CODING 2.0 持续集成全新上线 十分钟 CODING DevOps 全链路体验 点击使用 CODING 2.0 体验 DevOps 全工具链敏捷研发

近期 CODING 团队在 2019 KubeCon 大会上发布 DevOps 一站式解决方案：CODING 2.0。此次 CODING 全新上线了持续集成与制品库模块，通过自动化与标准化的方式来帮助开发者摆脱编译、构建、集成、制品管理等重复劳动，旨在打造沉浸式开发体验。在 KubeCon 大会现场，我们以一个基于 Spring 的模版项目为例，展示了开发者如何基于 CODING 轻松完成编码到构建制品的过程。 新项目创建首先新建一个项目，选择一个您熟悉的开发语言预置模版。预置代码模版提供了从代码生成、持续集成、制品库的自动配置，并已预置了 Dockerfile ，实现 Docker 容器化的打包方式。目前代码模版已内置了包括 Java、Ruby、Android、Node.js、Python 等主流语言开发框架的网页或移动端应用。 只需几分钟，项目即可创建完毕。CODING 为您创建了一个代码仓库，并将一个简单 Java 网页应用的代码推送到仓库 master 分支，还为您创建一条可直接运行的构建流水线，产物为 Docker 镜像。基于创建好的代码仓库和构建流水线您可以立即进行代码开发，并且快速集成代码。 接下来我们基于创建好的模版项目 spring-demo ，通过三个环节：代码托管、持续集成、制品管理，来看看 CODING 的 DevOps 配置具体是什么样的。 代码托管CODING 提供代码托管能力，并支持 Git 与 SVN 的代码提交方式。在自动生成的代码仓库中我们看到了 Maven 编译脚本、Jenkins 构建脚本、Docker 镜像打包脚本、网页应用的源码。在 README 文件中详细介绍了各个源码文件的作用以及如何运行该网页应用，对于开发新手来说可以说是手把手程度的详细介绍。您可以通过本地 Git/SVN 客户端来提交代码。 持续集成修改后的代码如何集成到软件当中来？我们来看看预置模版下生成好的构建任务，并学习如何修改持续集成配置以满足更多的场景需求。 在下图中可以看到系统已自动运行过第一次的构建，在持续集成首页您可以清晰地看到每次构建结果的状态、触发原因、持续时长等基本信息。CODING 的持续集成支持多 Job 并发运行，如果您的研发团队有这方面的需求，在持续集成页面按需创建多个构建任务即可。 在构建记录中您可以看到每次构建结果的详细信息。比如构建过程的运行状态，如果遇到构建失败的情况，您就可以在该页面查看失败环节的日志信息以便快速修复构建流水线。您还可以看到改动记录、测试报告、还有生成的构建产物（比如 Jar/War/脚本/配置文件等构建半成品）。最终的构建产物（比如 Docker 镜像）通过简单配置即可自动推入制品库中，稍后我们会详细介绍制品库。 接下来我们来看看构建任务的具体配置是怎样的。在触发方式中您可以按需设置触发方式、邮件通知人员。在持续集成过程中您可以选择通过图形化编辑器或者文本编辑器（如果您对 Jenkinsfile 脚本熟悉）的方式来详细配置构建的每个环节。针对一些持续集成过程中无法明文展示或者易变的信息，您可以通过环境变量或者凭据注入的方式来进行设置。如果想要加快构建速度，您可以打开缓存配置，同时还支持清空重置。 ...

李子骅--石墨文档技术总监。 一个产品有需求的提出、评审、确定，以及实际的开发测试和交付这几个阶段。从2001年敏捷被提出开始到现在已经有越来越多的项目在使用敏捷。现在的敏捷已经变成一种常态，这个时候讨论敏捷实践中被大家的忽略点就变得非常有意义。 今天我们会围绕两个关键的点来讨论：一个是关注非功能需求，另一个是DevOps相关的策略。 关注非功能需求 这是一个网站的截图，上面有两个文本块，第一个是标题，第二个是答案。 看到这个图，首先大家会想它是什么东西，其次是为什么会有人问这个问题。 这是现在最流行的前端开发框架 React 的新一代的核心算法，Fiber的提出有两个背景原因。 第一个原因 是现在越来越多的产品和网站非常复杂，尤其体现在交互和功能方面。就比如石墨文档可以让很多人同时在线编写 Word 文档，这和之前传统的类似博客和新闻的Web 应用不一样，现在我们会有更复杂的交互，所以复杂交互带来什么呢？越来越多的用户发现虽然网站功能越来越多，但是好像网站也随之变得更卡了。滚动的时候会有一些延迟，打开一个网页会越来越慢。Fiber专门是为了解决这个问题，也就是说当你的网站很复杂的时候它可以让你的网站速度响应更快一些。 第二个原因是什么呢？ 经过长期的发展，React是现在最流行框架之一，全世界用户都在向它提各种需求：我想加这个功能，要那个功能，但是长期发展过程中也积累了很多技术债，也有很多没有完成的重构的东西，所以他们也希望能够通过Fiber的开发可以把这些技术债还上，把它变成更容易维护一些。 到现在，Fiber开发了满打满算两年时间，它已经推出了。推出之后大家惊喜的发现我的网站好像变快了，我们也可以看到React市场占有率在逐渐升高，迭代频率也在逐渐加快。所以其实Fiber的开发就是一个很明显的非功能需求，大家收到很多需求反馈，但是最终团队还是选择开发这样一个Fiber的工具。 所以，我们当提到非功能性需求的时候，会有几个常见类别，包括响应的速度、负载能力和测试覆盖。每个团队根据不同的情况会有不同的处理方式，把非功能的需求放到Acceptance Criteria里面，也可以放到Definition of Done里面作为这个用户故事是否完成的标准。 不同的方式其实各有利弊，如我们在开发石墨文档过程中支持多个人在一篇文档实时编写内容，同时每一个人看到编辑的东西，这是很明确的功能需求。 怎么去约定它背后的非功能需求呢？大部分情况下应该把它放到我们的验收准则里面，就是说我们可以约定一些通用性能需求。就多个人实时编写这个例子来讲，可能会约定一个人数，比如希望能够十个人都能够去实时编写，然后每个人的保存时间可以控制在一秒钟之内。这样当我们去完成这个用户故事的时候，我们会看验收准则，如果它支持了在一秒钟之内保存，那我们就确定它是完成的，所以这是一个对于事情有没有完成的很清晰的量化标准，不会让人忽略掉非功能的方式。 但其实也有另一种做法。有些团队会把这种非功能需求当成一个独立的项目，然后放在Backlog里面，这会造成什么问题呢，在时间宽松的情况下没有什么问题，但是当开发遇到一些阻碍的时候会发生什么事呢？就是我们常常会倾向于优先解决客户能看到的东西。因为当我去交付这个项目的时候，客户看到有这个功能觉得还挺不错，你们工作很快，然后你们也很卖力，这些功能对我也很有用处。 可实际上隐含的非功能性需求非常重要：能够承载多少人、能不能在公司范围内使用我们的产品以及安全性怎么样等等，还有一个很容易被忽略的点就是项目的可维护性是如何的。 长期迭代中，敏捷强调越来越频繁的跟客户沟通，去了解客户需求，响应用户的需求，所以开发速度会非常快，交互周期非常短。 在这个时候，很容易发现就是我们会忽略掉我们产品的可维护性，就比如我们会引入很多技术债，会有很多投机取巧方法把这个东西快速上线。到下一个迭代的时候，却继续关心客户反馈的其他需求了，没有再去解决之前的技术债。这就会导致一个产品开发的时候，初始阶段速度很快，但是越到末尾越会发现速度越来越慢了，直到不能不得不停下来大家坐在一起讨论解决这个问题。 两个“负责人”这个负责人是打引号的。为什么打引号呢? 最近很火的一部电影 《绿皮书》 ，看过这部电影的同学应该都知道《绿皮书》有两个男主角。 坐在后排的这个人获得了最佳男配角奖。其实大家很难想象他是配角，因为如果这部电影少了他，我们很难想象这部电影怎么能拍得下去，怎么能把这个故事讲完。所以，虽然我们会有主角，会有配角，但实际上很有可能这两个人缺一不可，我们应该做到不能忽略其中任何一个人。 在一个敏捷团队项目里面，我们很关注PO的决策，很关注PO的倾向，他会去把我们做的事情按照优先级排列。其实，我们还需要另一个负责人，就是说他需要能够很清晰地了解我们现在的状态，我们现在团队的情况，我们的开发的速度，我们对一些非功能需求的深刻理解。 就比如可维护性到底是如何，需不需要停下来做一些重构，还是继续前进。 对石墨来讲这个「负责人」不是一个角色，因为我们不会设置一个职位做这个事情，如果专门设置一个职位这个事情的时候，整个团队其他人很容易说：「好像这个职位的人他只要做这个事情就可以了，我们其他人不需要关心。」这反而会造成对整个非功能性需求理解的一个倒退，会起一些反作用，对于我来讲更重要的是从文化角度把非功能性需求的灌输给整个团队可以使得团队透明的理解和推动NFR，非功能需求。 什么叫透明的？ 简单留有一定比例的NFR时间不能帮助透明化。很多团队会有另一种做法，就是我可以有很多功能性需求，可能有很多用户的反馈，但是我也要做一些可维护性的东西，我要做一些重构，我要去还一些技术债，我要去做团队的提升，我要做一些方便部署的事情。为此我需要在每个迭代周期预留固定的10%或20%的时间来做这些事情。 这样会有什么问题呢？ 一个敏捷团队，或者正常一个团队，我们最关注它是能不能自我成长，自我提高，自我进步，自我反馈。所以当讨论非功能性需求的时候，其实是一个很好的契机，整个团队，包括我们的PO、包括我们的整个的开发团队，可以坐在一起一起讨论为什么我们要花这些时间去做这个重构；为什么现在去做，而不是下一个迭代去做；这些会对我们的用户、商业产生什么样的价值。我们会发现这些讨论可以让整个团队能够更快地去得到一些反馈，更快地知道我们的产能到底是什么，而不是说我们尽快地去完成客户所有的的事情，直到因为技术债的各种包袱导致我们不得不停下来。 所以透明地和整个团队讨论这件事情，使得团队可以自我提升，这是一个很重要的事情。 DevOps 的左移提到非功能性需求，我们很自然就会联想到DevOps，这是一个很自然的关联。 DevOps左移，看这个图就知道了： 我们知道大部分的敏捷框架或者敏捷方法都会很关注软件迭代开发的部分，就是左边这个部分，我们要有敏捷团队、我们让开发团队和业务团队坐在一起、我们能够实时去了解客户的需求、尽早根据不同的环境做不同的改变，我们希望能够尽早地频繁地去交付可以工作的软件给客户。 但是，右面是什么？ 右面是我们传统的IT实施运维，他们最关心的是稳定，这个东西如果没有问题，就尽量不要搞，上线的次数不要太频繁。我们每次上线可能都会有风险，我们要盯着这个上线的过程，然后运维同学也要去，所以对于运维来说，上线是一个很痛苦的事。 于是，你能发现，这个绿色的和黄色的好像是有一种冲突在里面，左边是希望能够更加频繁一点，尽快交付，右边是冷静一点，不要这么快。所以，大家会发现当采用了敏捷的时候，如果我们在运维层面不做任何改变的话，整个交付给客户的时间有可能并没有缩短。 我要怎么做呢？就是标题所说的，我们要将运维向左移，这个就回到我演讲这个话题，敏捷思想在产品周期的延伸，我们什么时候延伸，当我们敏捷的时候关注的是沟通，就是我们会和环境沟通，我们会和客户沟通。 那其实也一样的，开发团队要做什么？运维团队要做什么？这个其实也需要尽早沟通，就像这个图一样，我们可以在更早的时间，比如说开发的第一天，或者是我们在开发之前，就让大家坐在一起沟通。 DevOps最重要是什么，其实很难有一个确切的定义。 我们可以说它是一种方式，一种工具，也是一种文化，所以最根本的就是沟通。就是说我们在敏捷时已经证明了沟通的重要，我们可以快速的把软件交付给客户，更快速地去确保我们这个东西满足用户的需求。而不是以前那样埋头苦干一两年，丢给用户，用户却说这不是我想要的。所以项目部署也是一样，像过去如果我们做埋头开发，最后丢给运维团队，运维团队说这可能不是我们想要的，我们可能部署不了。其实之前石墨经常会遇到这样的问题，就是我们其实迭代会非常的频繁，客户需求也会非常多。所以对当时的我们来讲最痛苦的时候就是当一个迭代结束，要部署的时候，发现部署是一件很可怕的事情，我们经常在部署时发现部署脚本有问题、代码好像有点问题、部署上线了但各种错误扑面而来，运维电话响个不停。 实践：石墨服务开发流程现在去看之前，我觉得石墨开发的最重要的一个基础的产品，就是我们内部使用的交付平台。通过它，我们的迭代周期可以更短，交付频率可以更快，部署上线的整个流程也会更稳定。 因为石墨是面向企业在线协作的软件，所以我们自己也会用石墨写一些文档。这个截图可以看到及我们会用石墨写一些案例、写一些值班计划、写一些工作日志、技术分享和假期安排。 石墨每个员工都是自己产品的重度用户。刚才提到的敏捷，我们最关心的是怎么能够接受反馈。其实内部员工的反馈往往比用户甚至种子用户来得更快，这是因为大家都坐在一个办公室里，天天见，也会更了解产品。 所以，我们就在想两个事情: 第一个事情是我们怎么能够尽早地收到我们内部员工的反馈；第二个事情就是怎么能够把我们最害怕的问题，部署的问题解决掉。 所以，我们做了一个这样的功能。 “随时测试和部署每个功能” 这个功能是怎么用的呢？石墨在开发每个项目的时候，每个小组开发每个项目的时候都会创建一个特性分支，然后我们所有的功能都会在这个特性分支里去开发。每个石墨的员工，访问石墨的时候都会有一个特殊的页面，如截图所示，通过这个页面，每个人都可以去配置每个微服务使用哪个特性分支来相应自己的请求。 ...

在文章开始前，做一个小调查，在您的软件项目中集成一行新代码平均需要花多长时间？ 15 分钟一小时半天一天及以上注意这里的集成是指将源码放在一起，并验证源码可以作为一个一致、运行可靠的软件的过程，而不只是完成编译。 如果在软件集成阶段耗费的时间经常让您的研发团队加班加点，那么是时候考虑落地持续集成了。我们都知道软件只有从代码生成制品，最终部署到生产环境中可靠运行才会给公司带来收入。持续集成是一种以“反馈”为核心的实践，为了达到短周期、高质量的交付目标，研发团队需要频繁且自动化地发布软件。每次修改代码都进行集成可以让上线的时间尽可能短，开发人员也可尽早发现缺陷以便快速修复。 拥抱自动化，打造沉浸式开发体验CODING 持续集成（CCI）全面兼容 Jenkins 的持续集成服务，支持 Java、Python、Node.js 等所有主流语言编译环境，并且支持 Docker 镜像的构建。只要几步配置，就可以开启 Git 代码仓库的持续集成，包括 CODING 代码托管、GitHub、GitLab 等等。帮助您控制每一次从引入代码变更到发布的整个过程，从而更好地优化软件交付的速度和质量。 人力资源是非常有价值的，所以研发团队应该把人力放在开发新功能上，而不是那些枯燥且易出错的重复劳动上，比如像编译、打包、质量检查这类工作可以考虑都由 CODING 的持续集成来完成。 即使项目规模不大，我们也相信研发组织能从 CODING 的持续集成中受益。因为小项目会逐步成长为大项目，一开始就使用规范、自动化的方式进行软件集成，可以减少团队更替或者新人加入带来的沟通成本；尽早卸掉流程债务与管理债务，可以避免项目庞大失控后陷入交付沼泽中无法上岸。 深度优化，助力企业加速落地持续集成CODING 的持续集成在构建效率、使用门槛、构建物管理等方面都进行了深度优化。包括支持图形化编排以提高开箱即用的体验；高配集群多 Job 并行构建提速您的构建任务；统一的构建产物管理真正打通持续集成与持续交付的枢纽；凭据注入让持续集成更加安全易用。接下来我们来具体看看这些优化： 更友好的新手体验：图形化编排可视化的图形编排对于用户快速直观地理解、编排工作流水线是非常必要的。CODING 在基于编辑 Jenkinsfile 的核心功能之上设计了可视化视图，针对构建的每一个步骤提供丰富的构建脚本模板供用户选择。同时也兼容绝大部分自定义操作，实现了边写边看、所见即所得的直观编辑体验，降低了 Jenkinsfile 新手的使用门槛。 更快速的构建效率：多 Job 并行与缓存加速CODING 支持在一个项目当中并行构建多个 Job，以满足重度持续集成用户的需求。后端的服务器集群可以根据用户的需求实施调度响应的计算资源，保证用户的构建任务快速开始，减少排队时间；同时支持在不同的构建任务之间开启缓存，以提高反复构建的速度。开启缓存功能可以平均提高 300% 的构建速度。 更完整的构建流程：制品库管理CODING 制品库支持 Docker Image、Maven/Jar、Kubernetes Helm、Node.js NPM 包等常见软件包类型。制品库可以跟源代码协同进行版本化控制，可以与本地各构建工具和云上的持续集成、持续部署无缝结合，帮助您以标准化的方式管理构建产物。 更安全的鉴权机制：凭据注入在持续集成之后需要将构建产物自动存入制品库当中。不放心将制品库的账号密码配置在脚本或者是环境变量当中？CODING 提供了更为安全便捷的凭据注入方式，开发者通过服务连接的方式新建连接，配置好连接 ID 即可将持续集成产物推送到制品库中。 持续集成让开发者甩掉软件集成过程中的重复劳动并提高了代码质量。在这样的安全环境中，开发者更敢于创新，尝试新的想法。对于专业的软件研发组织来讲，版本控制、敏捷开发、持续集成等等都是非常重要的研发实践。CODING 通过日益完善的 DevOps 工具链，将前沿研发理念注入其中，帮助企业研发组织提高研发效率，让开发更简单。 点击下方，了解更多 CODING 2.0 升级资讯： 《CODING 2.0 企业级持续交付解决方案》 《CODING 2.0：为什么我们需要 DevOps》 《CODING 2.0 服务升级：一站式服务体系助力企业研发上云》 《CODING 2.0：如何通过设计给品牌创造价值？》 《打通 DevOps 任督二脉 ，CODING 2.0 制品库全新上线》 ...

CODING 在近期的 KubeCon 2019 大会上发布了 CODING 2.0，同时发布了最新功能——制品库。CODING 不断完善 DevOps 工具链，旨在持续提升研发组织软件交付的速度与质量。 什么是制品库软件制品是指由源码编译打包生成的二进制文件，不同的开发语言对应着不同格式的二进制文件，这些二进制通常可以直接运行在服务器上。 制品库用来统一管理不同格式的软件制品。 除了基本的存储功能，还提供了版本控制、访问控制、安全扫描、依赖分析等重要功能，是一种企业处理软件开发过程中产生的所有包类型的标准化方式。 制品库：DevOps 的枢纽中心当下不少研发组织依然使用着粗粒度的制品管理（比如搭建简易 FTP 来提供制品下载 ），甚至没有进行基本的制品管理。在这种粗放式的制品管理方式下，不同类型包的存储与获取是一件头疼的事情，版本追踪极其混乱，团队协作也是障碍不少。 标准化的制品管理帮助企业组织解决上述困扰。在 DevOps 自动化流水线当中，持续集成的构建物自动存入制品库中，在部署时按需获取对应的版本，制品库让研发团队真正做到 deploy anytime anywhere。制品库给企业带来的好处还包括： 可追溯的版本控制制品库当中存储了更加完善的元数据，包括每个制品的版本号是什么，哈希值式、构建时间、上传者、下载次数等，有助于确保制品的正确版本和来源始终可用且可验证。 开箱即用的多类型包管理不同的制品类型（Docker/Maven/NPM 等）对应着不同的上传、存储、获取方式。制品库提供开箱即用的私有制品库管理，用于存储不同类型的制品。 高效有序的协作团队各角色例如开发、测试、运维、CI/CD 人员，通过统一的制品库，按需获取版本（快照版本、测试版本以及稳定版本），减少不必要的沟通，增强团队内部协作。 精细化的安全管控研发组织可以按需设置制品库的开放程度，以及按需设置各成员的制品访问权限，提高企业数字资产保密性、安全性的同时，又保留一定的开放性。 制品库是 DevOps 当中的重要枢纽，是连接持续集成与持续交付的关键实践。它提高了开发人员的工作效率和协作，同时推动 DevOps 和持续交付目标。 CODING 制品库：无缝的部署交付，便捷的软件分发CODING 制品库支持 Docker Image、Maven/Jar、Kubernetes Helm、Node.js NPM 包等常见制品类型。制品库可以跟源代码协同进行版本化控制，可以与本地各构建工具和云上的持续集成、持续部署无缝结合。企业可按需将制品库设置为企业内部公开、项目内部公开、外部公开。同时 CODING 在制品库支持类型、软件漏洞扫描、访问速度上都进行了深度优化，让企业用户享受更快、更可靠、更方便的标准化制品管理体验。接下来我们来看看这些具体的优化： 多种制品的类型支持针对技术栈丰富的研发团队，CODING 制品库满足其单项目多类型制品的诉求，可实现同一个项目中既支持 Docker 镜像又支持 Maven/Jar 的制品存储。 无缝衔接常见构建工具制品库兼容所有常见的制品格式标准，开发者不用更换任何构建工具、安装任何其它本地软件或者插件，即可无缝使用。 极速分发支持公开仓库和私有仓库，依托腾讯云强大的 CDN 能力，团队可以在全球范围内安全地、极速畅享制品库上传和下载。 漏洞扫描存放在制品库的构建产物可以使用预先提供的镜像安全扫描功能，或自定义的安全扫描策略进行质检。 上下游整合不管是与上游的代码仓库版本匹配，还是与持续部署和运维系统的接口兼容，都提供了良好的适配接口，使得 DevOps 可以上下游一体化。 制品库作为 CODING 提供的一站式 DevOps 解决方案当中重要的一环，为企业 DevOps 转型提供了更加完善的全链路工具，我们用每一次产品的迭代更新来践行“让开发更简单”。 ...

“瀑布式开发是一种老旧的，正在过时的计算机软件开发方法。最开始的软件行业普遍采用这种方法，但是这种方法套用自传统工业生产，不适应计算机软件开发的具体情况。”来自百度百科的一段话，确实它用在软件开发会出现很多问题。使用瀑布式开发经历过2、3个产品的研发，问题很有共同性，《30天软件开发：告别瀑布拥抱敏捷》帮我完美总结： 版本发布所需时间越来越长。无法按时发布。在版本发布的最后阶段，软件达到稳定状态需要的时间越来越长。制订计划的时间太长，而且计划得不准确。在版本发布中期很难做更改。质量持续恶化。“死亡行军”损伤士气。正因为这些问题，所以渴望开发流程的改变。偶然（或许是必然的结果，只是时间点的问题）的机会，让我的团队转向敏捷开发。 敏捷开发是什么？本节内容基本上都是摘自《30天软件开发：告别瀑布拥抱敏捷》。 敏捷开发以用户的需求进化为核心，拥抱变化，采用快速迭代、循序渐进的方法进行软件开发。衡量整个过程的三个指标：生产效益：指团队开发的效率。质量：指产品增量的质量。价值：指开发出来的产品增量的市场价值。流程如图： 从「愿景」开始，只有时时刻刻铭记迭代的初心才不会偏离航向。由产品经理梳理需求，形成「产品待办列表」。在「Sprint计划会议」上，产品及开发团队一起讨论出最优先的需求形成「Sprint待办列表」进入迭代。在定期的迭代周期中，每天同一时间同一地点的进行「每日站会」，交流上一天做什么，下一天做什么，遇到什么问题，其目的是让团队知道整体进度。期间禁止超期（包括插入其他事务）或修改验收标准。最终形成一份可发布的产品增量。客户、产品经理、开发人员等涉及人员进行「Spring评审会议」，主要是开发人员进行Demo演示，产品经理验收需求是否达标，未达标则产生新的产品待办项。客户观察是否达到自己的要求。最后，开发团队自己进行「Sprint回顾会议」，对该迭代出现的问题进行分析及总结，避免下一迭代中出现。文章最后附上敏捷开发的3个角色、3个工作和5个事件。 我们怎么落实？一般来说，都是团队按照一个标准流程执行。因为团队中都是对敏捷开发一知半解的，这样的话，得统一学习，然后一起制定流程，然后在按照流程执行。这样既耽误时间又耽误版本发布。所以我们就反过来，让流程也来个迭代。要实施敏捷开发，对人的要求挺高，能不能落实很大取决于Scrum Master，落实得顺不顺利很大取决于开发团队，落实得好不好很大取决于Scrum Master和开发团队。 第一阶段：人让团队有敏捷开发基础，这样反过来执行流程，很多问题就迎刃而解。 自身作为团队的Leader，也就理所当然的落在Scrum Master这个角色上。我得从以下方面提升： 首先，得有一个接纳、积极的态度。打心里坚信我可以带着这个团队成功转型。遇到问题，我有这个能力解决。其次，提高自我认知、我在团队的定位及与下属的关系。我花1个月时间精读《30天软件开发：告别瀑布拥抱敏捷》，以它作为蓝本进行入门。我也认识到我的主要精力应该由考虑方案变成帮助团队实现他们的任务。他们，才是主力！最后，我得改变方式。我慢慢让自己淡出，把机会留给团队的每一个人。我让他们自己提方案，我参与评估。我审视团队的每个人，我把迭代过程中看到的问题记录，然后找合适的时间跟他们面对面并且很直接的沟通。团队由于团队人员能力参差不齐，做事方式也都不一样。比较有共性的就是养成惰性习惯，所以主要从两方面提升： 提高执行力，聚焦于任务。遇到问题给他们引导技术方向，梳理方法以提高执行力。死盯任务，卡死2周的迭代时间，曾经好几次加班到深夜2、3点，目标就是想表明一个态度——时间是神圣的，不可侵犯，来打消惰性及退缩。提高「自组织」。执行力提高之后，慢慢培养他们的积极性，把主观能动性激发出来，让他们自己思考。第二阶段：流程一开始，我们的流程只有：需求评审->迭代->发布，加上拖了很久的总结。刚好我们团队接到公司一个内部工具的新研发，我们在这个工具的开发上尝试。当进度和质量可控时，我们调整流程让它往标准的敏捷开发靠近。我们把总结放在迭代时间内，不在隔很久。当我们信心满满，我们落实在旧的产品研发上时，虽然团队还是这个团队，但是因为团队接手旧的产品也才2、3个月，所以需求评估有误，导致延期一周。从结果上看我们失败了，但是这个延期我们深入的分析，总结出很多改进的点，其中就包括需求评估不明确。所以我们在流程上，把需求评审拆成产品经理讲需求，然后开发团队理解需求、理需求涉及代码的系统流程、最后需求反讲产品经理确认。在接下来的迭代中，果然按时发布。之后，我们又陆陆续续加入「每日站会」、「Sprint目标」、「Sprint评审会议」，还制定了完成核心编码、开始测试、完成编码的参考时间点。也规范了最终除了产品增量还有「测试用例报告」、「核心功能测试报告」、「Sprint回顾报告」、「项目日志」和「版本迭代检查表」。在加入每一项之前，我都会跟团队分享它是什么，有什么作用。最终制定了我们的流程规范v0.1：当然，在过程中会遇到很多问题，比如任务做不完，我们预留了几个需求作为弹性需求。再比如开发团队觉得需求不够明确，我们就跟产品经理沟通等等。方法总比问题多，拥抱问题，不断迭代优化。 第三阶段：规范化这个阶段处于计划阶段，还未执行。打算严格按照流程规范来执行，然后对每一个过程进行精细化管理，形成规范。这样后续可以通过一些源数据进行分析问题。 我们遵循什么原则原则及是一种态度！之前有一个版本在周五时面临难产，一位开发人员理不清一段逻辑的思路，而下一周还没安排事情。此时他很大程度上觉得下周做也没事。但是我坚持，我帮他写了逻辑（不会出现下次），那天我们测试到凌晨3、4点搞定。之后跟他私底下聊天，他说确实是觉得下周做也没事，但是经过那晚，一直压着的压力一下子释放，然后版本又可以发布，感觉挺好。所以，原则还是要有。原则一、时间和质量不可侵犯保证质量的前提下，2周一个版本的迭代时间不会变，可以调整需求。原则二、坚持原则一时时刻刻提醒自己和团队、坚持原则一。 总结敏捷开发有人说好，有人说不好，对于我们来说，没有好与不好，只有适合不适合。能让我们团队成长，持续产出，就是适合的。我们会坚持，也坚信我们可以做到v1.0。 附敏捷开发的3个角色产品负责人：负责最大化产品以及开发团队工作的价值。决定每个迭代要开发的功能，并在每个Sprint结束时评审软件增量是否符合要求。清晰地描述产品待办列表项对产品待办列表项进行排序，最好地实现目标和使命。优化开发团队所执行工作的价值。确保产品待办列表对所有人可见、透明、清晰，并且显示Scum团队的下一步工作。确保开发团队对产品待办列表项有足够的理解。开发团队：负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量。他们是自组织的，没有人（即使是Srcum Master都不可以）告诉开发团队如何把产品待办事项列表变成潜在可发布的功能增量。开发团队是跨职能的。团队作为一个整体，拥有开发产品增量所需要的全部技能。Scrum不认可开发团队成员的头衔，无论承担哪种工作他们都叫做开发人员。此规则无例外。Scrum不认可开发团队中的所谓“子团队”，无论是测试还是业务分析的成员都不能划分为“子团队”。此规则无例外。开发团队中的每个成员可以有特长和专注领域，但是责任属于整个开发团队。Scrum Master：负责保证项目按照Scrum的方式进行。要确保Scrum团队遵循Scrum的理论、实践和规则。（1）服务于产品负责人 找到有效管理产品待办列表的技巧帮助 Scrum团队理解“清晰精炼的产品待办列表项”的重要性在经验主义的环境中理解长期的产品规划确保产品负责人懂得如何安排产品待办列表项来最大化价值理解并实践敏捷按要求或需要引导 Scrum事件（2）服务于开发团队 在自组织和跨职能方面给予团队指导协助开发团队开发高价值的产品移除开发团队工作中的障碍按要求或需要引导 Scrum事件在 Scrum还未被完全采纳和理解的组织环境中指导开发团队（3）服务于组织 带领并指导组织采用 Scrum。在组织范围内计划 Scrum的实施。帮助员工及相关干系人理解并实施 Scrum和经验型产品开发。发起能够提升 Scrum团队生产效率的改变。与其他 Scrum Master一起工作，增加组织中 Scrum实施的有效性。敏捷开发的3个工作产品待办列表产品待办列表是一个有序的列表，其中包含一切产品可能需要的东西，也是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。演进。待办列表是动态的，需要持续更新以反映出产品需要什么来保持其合理、有竞争力以及有用。只要产品存在，产品待办列表就存在。产品待办列表列出了未来发布的产品在特性、功能、需求、改进和修复上所要进行的所有改变。产品待办列表项包含描述、次序、估算和价值。随着产品的使用，价值的获取以及市场反馈的获得，产品待办列表变成了更大、更详尽的列表。因为需求永远不会停止改变，所以产品待办列表是个不断更新的工件。业务需求、市场形势和技术的变化都会引起产品待办列表的改变。“产品待办列表细化”指的是为列表项补充细节，估算和排序。这是一个持续不断的过程，产品负责人和开发团队协作讨论产品待办列表项的细节，并对列表项进行评审和修改。何时如何进行细化的工作由 Scrum团队决定。细化的工作通常占用开发团队不超过 10%的时间。然而，产品负责人可以根据自己的判断随时更新产品待办列表。排序越高的产品待办列表项通常比排序低的更清晰、更具体。根据更清晰的内容和更详尽的信息就能做出更准确的估算；排序越低，细节信息越少。开发团队在接下来的 Sprint中将要进行开发的产品待办列表项是细化过的，因此，任一列表项都能够在 Sprint的时限内“完成”。我们把这些能够在 Sprint中“完成”的列表项称为“准备就绪的”（ Ready），它们将作为 Sprint计划会议中的待选列表项。监控实现目标的进度，在任何时间，达成目标的剩余工作量是可以累加的。产品负责人至少要在每次 Sprint评审会议的时候追踪剩余工作总量。产品负责人比较这个数量与之前 Sprint评审时的剩余工作量，来评估在希望的时间点达成目标的进度。这个信息对所有的相关干系人都透明。Sprint待办列表一组为当前 Sprint选出的产品待办列表项，外加交付产品增量和实现 Sprint目标的计划。开发团队在 Sprint待办事项列表中预测哪些功能要包含在下一个增量中，以及交付这些功能到“完成”的增量中所需的工作。当新工作出现时，开发团队需要将其追加到 Sprint待办列表中去。随着任务的进行或者完成，团队需要估算并更新剩余的工作量。如果计划中某个部分失去开发的意义，就可以将其删除。在 Sprint期间只有开发团队可以修改 Sprint待办列表。 Sprint待办列表是高度可见的，实时反映了团队计划在当前 Sprint内完成的工作，该列表由开发团队全权负责。监控 Sprint进度，在Sprint中的任意时间点都可以计算 Sprint待办列表中所有剩余工作的总和。开发团队至少会在每日会站时跟踪剩余的工作量，预测达成 Sprint目标的可能性。团队通过在 Sprint中不断跟踪剩余的工作量来管理自己的进度。产品增量增量是一个 Sprint完成的所有产品待办列表项，以及之前所有 Sprint所产生的增量价值的总和。在 Sprint的结尾，新的增量必须是“完成”的。这意味着它必须可用并且达到了 Scrum团队“完成”的定义的标准。无论产品负责人是否决定真正发布它，增量必须可用。敏捷开发的5个事件Spring计划会议目的是要为这个Sprint的工作做计划，这份计划由整个Scum团队共同确定。为期两周的Sprint的计划会议应该不能超过4个小时。Scrum Master确保会议顺利举行，并且每个参与者都明白会议的目的，同时还要教导大家遵守时间盒的规则。（1）接下来的 Sprint交付的增量中要包含什么内容？ 开发团队预测这个 Sprint中要开发的功能。产品负责人讲解 Sprint的目标以及达成该目标所需要完成的产品待办列表项。整个 Scrum团队为了更好地了解 Sprint的工作进行讨论。Sprint会议的输入是：产品待办列表、最新的产品增量、开发团队在这个 Sprint中预计可接受的工作量和以往的表现。开发团队自己决定选择的待办列表项的数量。只有开发团队本身可以评估接下来的 Sprint可以完成什么工作。在开发团队预测完这个 Sprint中可交付的产品待办列表项后， Scrum团队会制订一个 Sprint目标。通过实现 Sprint产品待办列表可以达成 Sprint目标。（2）要如何完成交付增量所需的工作？ ...

会议，或“仪式”是敏捷开发的重要组成部分。作为重要元素之一，会议不应该脱离其他元素独立存在。（很多人倾向于在瀑布流项目中添加类似仪式，然后将其称为“敏捷”，这种做法根本就是无稽之谈。）下面，让我们来看看敏捷的这些仪式，了解它们如何实现团队赋权并推动敏捷的发展。 注意：其中一些仪式来自Scrum。Scrum是一种需要在限定时间内，以迭代的方式实现敏捷的方法。这些仪式背后的概念也可以应用于其他形式的敏捷，如kanban或精益。Sprint是一个仅用于Scrum的术语，而其他形式的敏捷则使用更通用的术语“迭代”来表示在限定时限内进行的开发。Sprint规划与会者：开发团队、Scrum Master、Product Owner召开时间：Sprint启动时持续时间：时限为一周的迭代，会议持续时间通常为一小时——例如，为期两周的Sprint将在启动时进行两小时的规划会议。敏捷框架：Scrum（当然，Kanban团队也有计划，但他们没有采用正式的Sprint规划会议来制定迭代计划）目的：Sprint规划会议为整个团队制定计划，以确保团队在整个Sprint中取得成功。会前，Product Owner将准备一个按优先级排列的Product Backlog。他们与开发团队共同讨论每个列表，并预估工作量。 然后，开发团队将进行Sprint预测，大概估计团队可以完成Product Backlog中的哪些工作，而这部分工作也就是Sprint Backlog。 专家提示：团队通过Sprint规划会议来充实需要完成的工作的具体细节。鼓励团队成员为Sprint中的所有用户故事、错误和任务勾画工作任务。会议的目的在于促进讨论，并就行动计划达成共识。有效的规划能提高团队达成Sprint目标的概率。每日站会与会者：开发团队、Scrum Master、Product Owner召开时间：每天一次，通常在早上。持续时间：不超过15分钟。不要让大家坐着在会议室开会。站着开会可以缩短会议时间。敏捷框架：Scrum和Kanban。目的：站会的目的在于让团队成员快速了解当前进度。这不是一个详细的状态汇报会议。会议整体氛围应该轻松有趣，但信息丰富。会议上团队成员应该回答以下问题：• 昨天完成了什么？• 今天要做什么？• 遇到了什么障碍？向团队同伴汇报自己昨天的进度是一种非常隐蔽的问责方式。没有人愿意成为团队中那个拖后腿的人——每天重复同样事情，且毫无进展。 专家提示：有些团队会使用计时器，确保每个人的发言都言简意赅、言而有物。还有一些团队可能会选择让队员一边开会一边互相传球，以此保证团队的注意力集中。而许多存在地理差距的团队则会选择使用视频会议或群聊来完成每日站会。每个团队都有其独特性，因此每日站会也会有所不同！迭代评审会与会者：必须参加：开发团队、Scrum Master、Product Owner建议参加：项目利益相关者召开时间：sprint或里程碑结束时持续时长：30-60分钟。敏捷框架：Scrum和kanban。与规划会议一样，kanban团队的评审应该与团队里程碑保持一致，而不是以固定的节奏召开。目的：迭代评审是展示团队工作成绩的时候。它们可以采用“周五demo演示会（demo Fridays）”等相对比较轻松的形式，也可以采用更正式的会议形式。不管采用何种形式，评审会都是团队庆祝工作成就，演示在迭代中完成的工作，并从项目利益相关者那里获得反馈的机会。记住，只有符合演示要求，且满足团队的质量标准的成果，才可以被认为是完整的，才可在评审会上进行展示。 迭代回顾会与会者：开发团队、Scrum Master、Product Owner召开时间：迭代结束时持续时长：60分钟敏捷框架：Scrum和Kanban。Scrum团队会定期召开回顾会议。Kanban团队也可以从偶尔举行的回顾会议中受益。目的：敏捷的核心是要从快速反馈中不断优化产品和开发文化。回顾会议可以帮助团队了解哪些方面做得好，哪些方面需要提升。回顾会议不是只抱怨没有解决方法的嘴炮会议。团队可以利用回顾会议来找出哪些是行之有效的方法，是团队可以持续关注和使用的。以及哪些方面需要做出改进，并在会议上讨论出创造性的解决方案并制定行动计划。持续改进是支持和推动敏捷团队发展的动力，而回顾会议是实现持续改进的关键行动。 专家提示：即使整个团队的工作进展顺利，也不要停止进行回顾会议。因为回顾会议能为团队提供持续的指导，以保持良好的运行状态。一个团队的敏捷性需要扎根于实实在在的开发实践，依赖于战术和战略性的变革方法和出色的团队写作。敏捷仪式只不过扮演了简化整个团队沟通过程的角色。 文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

近日，CODING 在 KubeCon 2019 上海站上正式推出了 DevOps 的一站式解决方案： CODING 2.0，除了进行 产品 及 产品理念 的升级，还对用户服务进行了整体升级，主要涵盖以下四个方面： CODING 2.0 正式对五人及以下团队免费。工具+培训，一站式服务体系。与腾讯云账号打通，让研发管理更加轻松。深度服务超大型客户，赋能企业数字化转型。CODING 2.0 正式对五人及以下团队免费CODING 一直以来的愿景都是 “让开发更简单” ，帮助中国更多的研发团队提高软件研发效率，交付出更优秀的产品。 同时 CODING 在过去一年以来也一直关注着学生群体和非盈利组织，并通过如 CODING CSR 计划等方式为他们提供服务。在 CODING 2.0 正式推出之际，CODING 也希望能通过 CODING 2.0 所包含的一站式 DevOps 工具链，帮助更多的中小企业和研发团队搭建自动化可持续交付的研发流水线，提高研发效能。 于是，在 CODING 2.0 发布和 CODING 成立五周年之际，正式宣布 CODING 企业版对 5 人及以下团队免费，让更多的团队开启崭新的研发管理方式，拥有更高效的数字时代企业研发协作方式。同时开发者也可以更方便地使用 CODING 2.0 来开发一些兴趣项目。 CODING 希望能和你们一起成长，在未来实现更多更伟大的目标。同时，CODING CSR 计划也为公益组织及校园团队提供了更高额度的免费服务，点击立即申请。 客户支持+客户成功，一站式服务体系从 2014 年起，CODING 持续为软件研发团队提供了五年的 SaaS 工具服务，积累了丰富的平台服务经验。除了详尽的帮助文档、视频演示和场景化工作指南外，客户支持团队还为用户提供 5x12 小时标准服务，及 7x24 小时快速响应服务，解答用户问题，协助用户无障碍的使用 CODING 的各项服务。 ...

CODING 在前两天的 Kubecon 2019 大会上发布了 CODING 2.0。这背后是 CODING 对研发管理和研发团队组建的思考。从 CODING 成立以来，我们一直在探索“让开发更简单”的方式。把“让开发更简单”这个大愿景进行拆分，具体到可量化的产品目标上去，实际上是希望通过工具的形式，可以减轻开发过程中的重复劳动，提高软件交付的速度与质量。 云端开发的初心最开始做 CODING 的时候，脑海中的蓝图是开发者在这里讨论需求、布置任务、写代码，改代码，演示代码，完成相关任务，整套的开发操作都在这里。 所以当时的产品结构是：轻量级的任务管理 - 讨论 - 代码版本管理 - 演示平台在这套产品体系下，产品经理会把任务指派给设计师，设计师完成设计后，产品经理验收后再把任务指派给研发人员，研发人员推送代码后，可以在演示平台做演示给产品经理验收。这是一套非常适合小团队的工作模型，流程简单，反应快速，CODING 自己团队也在使用，并且支撑了 CODING 产品前期的快速起步，快速上线，快速响应反馈的开发节奏。 企业在成长过程中碰到的实际问题很快，随着 CODING 业务的发展，CODING 的产品线越来越多，团队也越来越大，当团队到达 100 人的时候（其中 60% 都是研发），我们发现团队开始"管不动"了，最终的上线质量非常依赖部门 Leader 的管理能力和开发者的自我修养。为了保证产品达到预期，我们制定了大量流程和规范，但这让我们的进度越变越慢了。我们一度非常苦恼，创业公司的优势在于极高的效率与极快的产品迭代，但如果我们在发展的过程中丢失了这样的优势，将会很轻易的被别人超过。 所幸我们并不是第一个碰到这个问题的人。《人月神话》中有个很著名的观点： Adding manpower to a late software project makes it later.-- Fred Brooks, (1975)“如果希望用增加人力的方式解决软件的进度问题，只会让进度变得更慢。”因为： 沟通成本= n(n-1)/2 n=团队人数举例而言 10 个人的团队将有 45 个沟通管道，当人数到达 50 人时，这个数字将上升为 1225 个。随着人数的增多，团队内的沟通成本将指数级上升。了解到问题出现的原因，也就知道了解决方案：“我们需要更多更小的团队”——通过将团队分成若干个内部闭环的小团队来降低沟通成本。于是我们有了一个稍微敏捷一点的组织架构： 这个工作方式敏捷的很不彻底，问题在于运维。考虑到线上稳定性及系统的耦合程度，无法将运维拆到各个团队中去，各个产品线虽然有独立的产品经理、设计师和开发者，但需要运维协助上线测试环境，再由测试进行 testing 和 staging 两个环境进行测试验收。大量的时间被无用的等待浪费掉了。 ...

"The key to DevOps transformation is that there is no end-state—we must continuously evolve." —— MIRCO HERING, DevOps 全球领袖 今日，CODING 受合作伙伴腾讯云邀请参加 KubeCon、CloudNativeCon 和 Open Source Summit 在上海举办的 KubeCon 2019 技术论坛，并于论坛上正式发布了专注于大型项目 DevOps 实践的产品：CODING 2.0。 会场照片 如今互联网行业已经进入了深水区，新一代信息技术开始对传统企业进行更深层次的改造，对企业而言，现在仅仅 “拥抱互联网”是远远不够的。在全球经济进入数字化的时代，数字化转型已经成为企业必须付诸行动的不可忽视的选项。正如同 Hering 所说，企业需要不断地进行迭代和自我革新，能否拥有可持续发展和进化的业务能力将变得至关重要。 这也让越来越多的企业开始接受敏捷和 DevOps 的研发管理方式，来获取更灵敏的市场反应速度和创新能力，因此企业需要采用更有弹性的研发管理模式和培养快速迭代的软件交付能力。知名技术咨询公司 Gartner 也基于这个现象提出了企业敏捷规划（Eenterprise Agile Planning） 的概念，来评估企业敏捷规划发展。这也意味着开发生命周期管理工具（ADLM）从传统的以项目为中心的方式向敏捷和 DevOps 的方向演变，软件交付的方式也从以单个项目的形式转化为了持续性交付。 CODING 同事为客户讲解 CODING 2.0 的产品特性 但是通常，由于研发团队本身与其管理层和业务部门的需求不同，导致企业内部使用的工具不同，这也造成了不同工具间的信息传递不流畅，大量的研发效能被浪费。CODING 作为 EAP 工具的先行者，深耕研发管理领域已久，客户涵盖了互联网、金融、游戏、科研机构、高校、教育等多个重要领域。在为客户服务的过程中，深知企业缺乏完整成熟的工具体系所带来的弊端。 因此在过去的一年中，CODING 和腾讯云等重要合作伙伴及各个领域中大型企业 CTO 进行了深度交流，梳理了企业研发管理中的难点和痛点，并于今天正式推出了 CODING 2.0。 CODING 2.0 提供的企业级 DevOps 解决方案是基于多年项目级 DevOps 经验演化而来，专门为大型企业和项目而设计，CODING 2.0 中包含的 DevOps 全工具链和完整的项目管理功能能将业务、开发、运营团队和管理层整合在一起，并应用自动化流程来简化软件研发流程和管理，从而帮助企业以最低的成本和精力推行大规模 DevOps 实践，实现软件研发的持续性交付。 ...

CODING 为您的企业提供从概念到软件开发再到产品发布的全流程全周期软件研发管理，为您的研发团队提供全程助力，帮助研发团队捋清需求、不断迭代、快速反馈并能实时追踪项目进度直到完成。同时 CODING 还为研发团队中每个角色根据其工作的性质设定了相应的工作流程，帮助每一个人快速上手，助力研发团队，提高研发效能，更高效更快速地进行软件交付。 什么是测试管理软件开发项目中的一项关键工作就是测试，通过创建和执行测试并管理测试结果，从而制定高效的开发决策。然而在技术日新月异的今天，传统瀑布流式的交付形式已经不能满足业务的需求，企业的敏捷转型迫在眉睫。而测试管理的改革是企业能否实践 DevOps 实现小步快跑的关键。传统的软件开发团队的开发流程是先把功能开发完，然后再交付给测试团队进行测试，开发和测试是相对独立的两个过程，导致中间会有大量时间和效能的浪费。而在 DevOps 的理念中，测试应该随着版本迭代速度的加快而提速，因此把测试集成到开发的过程中来，成为开发过程中重要的一个环节是实现敏捷的重要步骤。CODING 秉承着一站式 DevOps 解决方案的理念，将测试管理集成研发管理系统，通过敏捷测试缩短软件交付周期，让测速和研发同步迭代，帮助企业实现数字化转型，用更高效的方式为客户带来价值。 点击观看《使用 CODING 进行测试管理》实操视频 测试人员权限设置随着数字化转型浪潮的开始，越来越多的企业开始使用信息化的管理系统取代传统办公工具。在转型的过程中最大的挑战之一就是如何给相应信息设置权限管理，确保不同职能部门的员工只能使用特定的功能，浏览与自身业务相关的信息，不能擅自查看或修改超越权限的内容，保证企业数字资产的准确性、保密性、安全性。 测试人员默认权限： 创建测试用例在进入 CODING 的测试管理模块后，即可开始创建测试用例。除了直接创建测试用例以外，CODING 的测试管理模块还支持从 Excel 和 TestLink 直接导入用例库，同时也支持从用例库直接导出 CSV 文件，方便测试工程师进行数据迁移。 点击右上角创建用例按钮，进入创建测试用例页。 创建测试用例依次操作如下： 输入标题；输入测试前置条件；选择测试步骤类型并输入相应的测试步骤内容或文本用例内容；点击保存并关闭按钮，则完成一个测试用例的创建。创建测试计划在项目首页点击测试计划图标进入测试计划列表页。CODING 测试管理中的测试计划可以与迭代管理相关联，方便项目负责人进行全局统筹。 页面左侧展示所有测试计划列表，右侧展示选中测试计划的测试任务列表。点击上方 + 号按钮，弹出创建测试计划窗口。 创建测试计划依次操作如下： 输入测试计划标题；输入描述信息；选择是否包含全部用例：若选择包含全部用例，则项目下所有用例都将成为当前测试计划下的测试任务；若选择手动圈选用例，则需点击圈选范围按钮选择需要纳入测试计划的用例；点击创建计划按钮，则完成测试计划的创建。执行测试任务在测试计划列表页，从左侧选择一个测试计划，点击右上角的开始测试按钮，则进入测试任务执行页。 记录测试结果步骤如下： 点击记录结果；选择结果状态，可选择通过、受阻、重测和失败；输入备注信息，若测试用例为步骤用例，则可输入每个步骤的实际结果和测试状态；点击添加结果按钮，则完成该测试任务的一次测试。生成测试报告CODING 测试管理可自动生成定制化的大师级测试报告，涵盖了测试结论、图表、工作分布、耗时等关键信息。帮助项目负责人对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下坚实的基础。 立即点击使用 CODING 快速上手，高效交付！

马晓宇 --环信联合创始人/执行总裁 我们是一个做云服务的创业公司，所以我就云服务创业公司的角度，来谈谈我们是怎么去实践敏捷开发的。确切地说，就是讲讲我们这几年的这些教训... 1-创业公司敏捷开发流程有哪些？ 日本企业：我的第一份工作，我发现它这个文化，或者它这个流程设计的是和他们的特点非常相关，如果大家接触过日本，就会知道他们有一个特点，两个字—“变态”。 为什么这么说呢？这可能是褒义，因为他们对文档，对质量，对流程，对测试要求就是两个字：变态。所以他们的整个流程就是非常变态。 大家如果写过概要设计、说明书这些的，你可能写程序花最多一周，但是写文档至少两三个月才能通过。但是这个好处是说保证随便的一个普通工程师，刚大学毕业，他进到这个企业，进到这个组织，他就能产出同样质量的一个软件，所以这个是很多公司其实做不到的。核心团队人员离职了，尤其创业公司，有时候面临挑战就会比较大。但是在这种变态流程里，它其实不缺人，因为每一个人都是螺丝钉。 电信软件：发现又不一样，我们一般做系统，出问题重启，但是电信它的要求是，希望这个系统一年不重启... 开源社区：一般一年开一次会，整个一个团队大概七八个人，多的十几个人在世界各地，每年年初或者年底开一个会，这个会上就讨论今年什么，都比较虚。组织形式非常松散，因为大家可能有一个共同的目标，客户的期待也特别大，所以就是没日没夜的去工作。 手机软件：挑战和其他的不一样，就是多了一个兼容性。因为手机系统当时我们有一个参数，就是说你一个软件发出来之后，你有多少个客户，升级之后，它要回厂，回到服务站去解决问题。 具体指标我记不清，每次都会检查，就是如果回到服务站的用户多了，这个软件就赔钱了。我们原来做移动的APP、SDK也面临同样挑战。 创业公司：生存挑战，我们找各种流程，找一个能适应我们文化的，最关键的其实想找一个能帮助我们生存下去的流程。 其实创业的话，就会觉得每个月有一天特别难受，那就是每个月给员工发工资的时候。几百人怎么去赚到这个钱，然后去给大家发工资。 那这个生存挑战怎么解决呢？可能就是四个字，“降本增效”，但这个比较虚了，都知道降本增效，但是实际怎么做啊？我给大家送一句话：“降本增效，就用Worktile” 我们用Worktile比较早，在2014年左右就开始用，早期的付费用户，觉得挺好用的，之后又在敏捷大会看了新版本新界面，感觉功能更加强大了。 2-SaaS需求管理，有何轻重缓急之分？ 创业公司的需求来自 项目经理、研发、客户 等方方面面，也会经常面临各种各样的bug。 就bug的轻重缓急而言，我总结了三种类型的bug： 严重bug： 需要团队立刻去执行，去解决； 功能性bug： 需要团队进行排期，可能会花几周的时间去迭代修复的； 性能bug： 这是最难解决的，举例来说，当我们在设计的时候，系统一上线就能支持百万用户甚至亿级用户的自由伸缩，往往是不现实的。所以，在SaaS需求管理上需要去平衡不同功能的需求程度。 3-关于SaaS迭代开发，应注意什么？ 创业公司在服务端上线周期基本上是一个月，上线有两个注意事项： 一个是回退方案， 即做到要求的方案都可以回退，遇到问题时可以及时做到回退。 另一个是兼容性问题， 一个产品面对不同的用户存在这不同的兼容性问题，这时我们需要做开关，如果产品上线可能造成某方面的损失，可以选择做降级开关来处理，保证部分功能实现。 移动端的上线需要注意发版问题，当做工具云时，在很短的周期内出了一版，但是没有测到严重的bug，随即上线后续更新的版本，这就会在用户体验上大打折扣。 4-SaaS 云服务的自动测试如何做？ 如果现在做互联网服务越来越的是避不开移动端，除非用微信 H5，否则怎么测应用的在百万及甚至几百万用户的压力下，你应用的响应，如果做测试知道这个是特别花钱的，因为你实际模拟一个用户，这个一台机器基本上是六万，一台机器模拟六万个客户，这是我们的常规测试，如果模拟百万用户实时连接，要求二十台机器，十台是60万，二十台机器，但这个对创业公司服务器的成本还是有的。 所以我们怎么做呢？ 阿里云是现在也支持了，早期是10%，现在已经按量付费，去使用服务器资源，计费周期是到秒的，所以我们真正去做移动端压力测试的时候，建议大家搞这么一套系统，这个还花的我们一段时间，我们整个有一套脚本，这个脚本从运行就启动一个阿里云，是有API，申请ECS，比如跑一个百万的，可以把服务器申请出来，我们把所有的模板部署上，部署之后先做一个简单验证，整个环境通了，这样就可以去真正模拟，因为一般的模拟场景是百万用户，同时先登服务器，建一个百万的TCP连接，之后模拟一些场景，有的是发消息，有的是客服业务，有的送花有的点赞这些场景模拟完之后，要把测试结果报告，这套有了，这个测试就完了。 但是提醒一下，你可以自动释放服务器，但一般我们做这个操作的时候，我们整个测试结果出来之后，我们看一下，如果说不达到期待，调一下脚本，甚至去改一下服务再测一下。如果没问题，后边就有一个脚本能自动释放，所以整个其实可以全自动的，而且当时我算了一下，如果你是使用，比如按天，不到三天，费用肯定是比包月便宜，即使拿到一个比较高的折扣，大家做移动端自动测试，尤其是这种要做并发的话，我建议就用这种按量，这个是给我们省了不少钱。 5-部署和运维的敏捷保障 做云服务，做SaaS的有一个，基于租户的灰度发布。 1.AB测试 AB测试是一种用于提升产品转化率、优化获客的方法。当我们想测试哪个注册页面转化率高时，我们就可以上线两个版本的页面，通过一周、一月的注册数据监测比例来衡量哪个页面效果好。在做云服务，SaaS时，就是基于租户的验证，同样可以适用这种方法。 2.前后端灰度 所有的前端根据cookie中的租户id，转发到不同版本的后端服务。如果进来之后，cookie解决这个租户ID，就可以写个脚本，根据当前给的配置对应的版本打造对应的服务，这是一个常用的功能。 3.移动端灰度 移动端登录后，从路由服务器请求访问地址。以做移动端的经验来说，某一个用户想登到指定的版本如何来做？我们可以做DNS解析，就是手机端不是先去试图访问服务，而是先去访问我们做的解析入口，当前是哪个租户，用户ID是多少，移动端什么版本，应该访问哪个后台版本，然后整个服务会打造相应的后台版本。 如果公司有海外客户，就可以通过DNS解析到海外的配置，移动端的路由可以根据不同用户的区域做不同的配置，链接到不同的服务和版本。 6-学费/教训 说说学费，从现在看，不管是流程，现在要保证最重要的四个方面： 1-核心要保持稳定， 即自身系统的上线流程不能影响到客户的业务流程，可以采用错峰上线、降级开关等措施; 不管是做即时通讯，还是做客服，如果这个系统出问题，都会影响它的业务。 2- 善于提炼客户需求 产品功能需要满足大多数客户的需求; 如果你客户比较多的话，跟销售打交道，容易被忽悠，销售说“你把这个做了就给钱了”或者“如果你把这个做了就行了”。我说哪个重要，销售都说重要。 所以这里面有个技巧，你得需要真正对这个产品有理解，对这个业务理解了，就是用户要的只是他现在想要的，但是如果能把不同的需求，提升到通用的需求，里面加一些开关，能满足大多数的需求，这个是很重要的。 3-成本控制 可以从架构设计出发，尽量用成熟的组件，设计一个低成本的架构; 如果你们做云服务，一开始不觉得，但是如果突然运维给你一个七位数的帐单，一个月。你就认识到，你的架构需要改了，但是如果你看到这个帐单的时候，可能有点晚了 4-注重用户的体验 ...

互联网时代，IT技术飞速发展，市场瞬息万变，产品经理如何进行敏捷管理？团队如何快速高效交付软件产品？如何拥抱变化？ 下面我给大家推荐一款敏捷开发工具，可以协助大家在最短的时间内完成开发任务，以最快的速度交付有价值的软件，使客户满意。 一个好的开发流程，对于项目的进行，更新和维护都起着至关重要的作用。CORNERSTONE敏捷开发工具适用于一些开发周期长，需求不明确，或者随时间渐进明确，频繁更新的项目。 产品与设计 项目决定启动后，第一步就是项目组准备需求，整理出需求文档。通过建立一个公开需求池，向项目组所有成员广泛收集需求，通过分析、评审去确定排期与安排，合理并有效的把控需求生命周期管理，避免因为不明确或重复造成协作效率低下、变更等无效劳动力。 1、 建立需求扭转周期 为需求生命周期搭建流程，可以自定义更改按收集、评审、排期、设计、开发、发布设立多个阶段，在不同阶段把任务分发给产品、设计或者开发人员，让需求完成无缝衔接。 2、 收集阶段 在单个项目，由项目组所有成员收集需求。提交流程十分便捷，方便各方业务及时反馈。 3、 需求评审与排期 收集到的需求将由产品经理梳理后，召集相关人员对需求开展评审。达成共识的需求可以进入到排期阶段，通过选定“责任人”为需求添加执行者，并明确“截止时间”设定需求的完成期限，同时设定需求优先级进行排序；被添加的负责人可以通过工作台查看自己的待办事项。 4、 需求跟进 CORNERSTONE平台共设有七种视图模式，全方位满足不同场景的使用需求 产品经理可通过看板视图快速实现需求状态的扭转；表格视图可以跨越不同维度的筛选快速找寻目标；甘特视图更易于整个项目计划与进度的管理；统计视图去了解每个任务的完成情况以及成员实际的解决情况；同时周汇总视图极大的方便开会所需内容。 5、 文件管理 CORNERSTONE平台的文件功能就像一个分隔开的在线文件库，组内的成员可以将与项目相关的所有文件与设计稿上传到文档内，并通过文件夹的方式进行分类。 研发管理 上述资料都准备完成后，就可以进行第二步项目开发阶段了。借助CORNERSTONE专业的开发工具，落实研发流程，支持瀑布+敏捷开发不同的模式。 1、代码助手 在开发过程中，使用代码助手，可依据前后端框架模板，自动生成代码，节省大量重复开发时长，提升产能。 2、自定义状态 研发过程中企业可根据自身特性去设定本次迭代中要完成所有任务的状态。比如“未开始”、“进行中”、“不确定需求”、“已取消”、“已完成”或其他。 借助看板，开发团队可以清楚的了解其他成员的工作状况以及和自己相关工作的进展，同时可作为开发团队每周例会的讨论核心，有益于团队的自我指导。 3、自DevOps与自动化部署 CORNERSTONE支持依赖脚本pipeline实现的DevOps，支持持续集成与自动化部署，可直接在可视化的服务器上进行操作，同时满足多种开发语言，彻底解决敏捷开发在运维层面的瓶颈，方便开发人员对项目开发生命周期进行全盘管理。 4、CMDB CORNERSTONE嵌⼊一体化监控运维平台，实现IT环境的数字化、标准化，直接运维分析的基础，减少⼈⼯干预，降低⼈工成本。 5、持续集成 CORNERSTONE⽀持将持续集成等结果部署到对应的测试环境，所有部署版本在测试 环境中可随时访问，⽀持灰度发 布到⽣产环境中。 测试与缺陷管理 终于一个阶段开发完成，可以顺利进入第三步测试阶段了。只有科学的通过测试流程，快速、准确的处理这些bug，才能提升产品质量，不断更新迭代产品。 1、测试用例编写 可依据思维导图一键生成测试用例或单独创建，可批量或单个设定用例分类与责任人。 2、测试计划 嵌入一体化的测试解决方案，可以一键执行用例，通过即计划完成，否则可一键关联缺陷。 3、缺陷管理 发现问题即提交缺陷，选定责任人、优先级以及任务状态等相关信息。 所有信息可随时查看，附带统计功能能全局查看修复情况，有效预防风险。 四、项目管理 用CORNERSTONE实践敏捷开发的全流程，任务管理→规划迭代→进度管理→缺陷追踪→总结沉淀 1、任务管理 通过思维导图⾃动⽣成或创建任务，确定责任⼈、任务状态、优先级、类别、时间等多维度 信息，帮助企业快速⾼效的对项⽬进⾏全周期管理； ...

你好，欢迎使用CODING！这份最佳实践将帮助你通过 CODING 更好地实践瀑布流式开发流程。 什么是瀑布流式研发1970 年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到 80 年代早期，它一直是唯一被广泛采用的软件开发模型。瀑布模型要求软件开发严格按照【需求→分析→设计→编码→测试】的阶段进行，每一个阶段都可以定义明确的产出物和验证准则。瀑布模型在每一个阶段完成后都可以组织相关的评审和验证。严格的瀑布模型每一个阶段都不能重叠，需要在评审通过后才能进入下一阶段，遵循自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 瀑布模型的优点是可以保证整个软件产品的质量，保证缺陷能够被提前发现和解决。采用瀑布模型可以保证在整体上充分把握系统，使系统具备良好的扩展性和可维护性。 如何使用 CODING 进行瀑布流式研发管理博弈论（Game Theory）告诉我们看起来利益最大化的策略并不能帮我们达到最好的目标，而是要根据实际情况来制定最合适的策略。同样的，在软件研发管理的战略上，企业并不需要把所有的系统都换成最新、最快的，更重要的是根据业务模式的不同来匹配相应的管理模式和管理工具，让研发和业务能同频共振，而不是互相拖累。 不同部门的 IT 需求侧重点各不相同。比如类似手机 APP 类应用，往往需要更灵敏的市场反应速度和创新能力，因此需要更有弹性的 IT 架构和快速迭代的软件交付能力。相对而言，后台支持性部门比如 ERP、数据库等部门，其业务重心在于保持运营稳定、风险管控以及成本控制。因此，他们的 IT 需求偏重稳定、安全，对于快速响应能力和弹性架构的要求相对较低。这也是瀑布流式研发管理经久不衰的原因。 一、创建项目第一步是在 CODING 中创建一个项目，之后所有的工作都在这个项目中完成。在确认好团队成员后，就可以邀请所有人加入到项目中来。每一个项目都对应独立的代码仓库，因为很多中后台的研发项目会涉及到外部供应商的参与，独立的代码仓库可以确保数据的相对隔离，确保企业数字资产安全。 二、配置权限在邀请完所有成员后，项目经理就需要为不同的角色配置相应的权限。瀑布流研发模式的核心在于安全和可控性，CODING 权限管理功能可以帮助项目管理员方便地根据项目成员的角色来分配相应的权限，减少误操作带来的安全隐患，同时还支持自定义用户组，增加研发管理的可控性。在项目开始的时候，由项目经理先行配置好所有成员的权限，确保团队更有序地进行软件开发。 三、需求文档撰写在配置完所有权限后，项目便正式进入研发阶段。此时由项目经理开始文档的撰写，瀑布流式研发管理模式的特点就是各个阶段都需要完备的文档支持。 如果团队中有产品经理的话，产品经理会通过 CODING 的需求管理功能创建一个需求池。产品经理将规划上线的功能、用户的反馈以及市场调研的结果整理出来，通过需求管理中需求的形式统一归纳，形成需求池。同时项目经理对需求池中的需求进行进一步分析，根据团队习惯将需求分为技术问题、设计问题和产品问题。每一条需求下都会根据需求的复杂程度创建一系列子任务。 产品经理亦可在 Wiki 中根据需求撰写完整的产品功能文档。 同时可以使用 CODING 的文件功能上传分享产品的原型图。 CODING 的文件功能和 Wiki 功能为研发团队提拱了内置的文档协作和团队知识沉淀工具。 四、产品研发 完成产品的原型设计和功能说明文档后，项目经理开始邀请研发团队加入项目，由研发工程师开始进行相关功能的交付开发。如果需求中涉及设计团队，研发工程师可以直接在需求管理页面通过关联功能关联相应的设计任务。 CODING 研发管理系统的代码仓库支持 Git 和 SVN 两种主流版本控制方式，方便各类研发团队快速上手。 瀑布流式研发管理中最看重的一点就是质量。CODING 内置的 Code review 功能和持续集成模块是确保软件研发质量的关键。 Code Review研发工程师开发完成后通过提交 Merge Request 进行代码评审，通过代码评审后 merge 进入 master 分支，确保代码质量。 ...

翁云峰 --稿定科技敏捷教练，厦门敏捷社区组织者 在印度有这么一个神奇的团队，他们有5000名左右的员工，每天要运送20多万份餐，一份盒饭要经过3-4个人的手才能抵达目的地，交通工具只有火车，自行车，板车和双腿，没有任何单据，甚至都不需要客户填写地址。 在这样的状况下，每6百万次运送中只有1次错误，准时正确到达率却超过99.99999%，这远超六西格玛的标准。在业界，如果一个企业能达到 六西格玛，就说明它能接近完美地达成顾客要求。在这一点上，达巴瓦拉甚至远远超过了联邦快递等使用现代技术和工具的快递公司。 大家可能在想，能够把事情做到这么好，他们一定很贵吧？他们团队的管理水平这么高，是不是成员的基础素质很高？ 答案却不是如此，这个团队基本上都是半文盲或者文盲，每个月的收入也很低，平均每人400-500人民币。 这个神奇的团队，叫做达巴瓦拉。 大家有没有注意到，外卖的每一个饭盒上都有编号？没有英文单词或者太复杂的词，只有一串编号而已（因为他们很多人都是半文盲，所以编号信息也力求简单）。这些彩色代码告诉这些外卖小哥饭盒来自何处，输送过程中经过了哪些火车站，最终要投递到哪个建筑物的哪一个办公室。这个代码就是他们的通讯协议，可以保证饭盒并准确无误的送达。如果出错了，是谁出了错可以非常精准被定义到。 他们获得成功的法宝是时间管理，简单的色彩分类体系和团队协作。 我们很多的研发团队，文化程度都很高，我们能不能做到这样的准时交付率？很难。我们的团队可以在发生问题的时候，能不能非常精确的定位问题和处理？也很难。 虽然达巴瓦拉是属于另外一个行业的案例，相信也会对我们软件研发有重要的参考意义。我想通过这个案例的分析提出一个关于团队协作的观点，也是我今天想谈的东西。 1-团队协作的境界现在我们来看一张图，大家试着想一想，我们团队目前经常沟通的频道是哪一个？ 我们大部分的时候，都是在公开象限里进行协作。而公开象限的大小，反映了团队协作中的“信息披露”和协作水平。 假如我们都在一个团队里，一般大家都很乐意谈隐私象限，因为你需要把你知道的跟别人进行沟通，让他们配合你。你需要贡献一些秘密，一些私人的信息，让别人更加了解你。 当你不太清楚你自己的时候，比如你不知道有哪些东西需要改善，你需要请求反馈。你不知道你的代码写的如何，这时候有个人跟你说你的代码写得还不错，他是在给你反馈，接触你的潜能象限，这样的人是教练。 教练在鼓励你做自我揭示，你在不断请求教练给你反馈，让你知道你的潜能是什么。 喜欢天文学的人应该都知道“熵增”这个概念。举个例子，大家觉得你家是PPT左边的样子还是右边的样子？如果是左边，那就特别好。如果你是右边的状态，怎么办？你需要整理。 大家有没有意识到，你的团队也可能是右边的这种状态？出了问题不知道原因是什么，效率很低不知道怎么改进，流程无法预估，交付总是看天气。我们需要做的事情是什么？教练除了帮你揭示自我帮你反馈之外，还需要帮你做整理，把过去无序的东西变得有序。梳理流程，梳理团队，梳理产出，暴露问题并推动问题的解决，这个过程是“反熵增”，防止协作系统陷入到混乱和无序中。 增强沟通，反熵增之后，我们希望团队协作达到什么样的境界呢？ 我想要用八个字来总结，叫做“既定规则，无脑执行”。 规则是什么？规则就是做事的方法和标准，比如DoR（就绪的标准）, DoD（完成的标准）和很多的working agreement（团队一起制定的工作公约）。 为什么是无脑执行？这里不是真的说在执行的时候，我们只需要找到一堆idiot来按部就班执行就行了。这里的意思是，当我们有了协作的规则和方法的时候，根本不需要占用大脑的带宽，不需要让团队在执行过程中耗费宝贵的计算资源，把有限的精力投入到最需要全神贯注的工作事项中去。 无脑执行的另外一个意思是，事情必须非常流畅，减少在执行过程中的摩擦，减少无谓的人力物力投入。 “以神御刀，不以目视刀。”《庄子》 为了让协作更加顺畅，我建议大家可以参考这个“协作金字塔”。也就是教练，或者团队管理者，或者有志于改善团队协作的任何一个人，需要关注的一些要点。 我们需要定义一些规则和方法。 我们需要不断提高信息饱和度（提高团队的公开象限）。 让信息流可视化（提高公开象限；无脑执行） 及时反馈，及时校准。 2-敏捷教练是什么这是一个教练在分享会提到的，他说敏捷就是快速迭代，他分享的主题是《敏捷是骗人的》。 这个事情告诉我们什么？有一些说法认为敏捷是万能的，或者说敏捷可以做很多事情，但真的是这样吗？不一定。 上面我也提到了一些教练需要做的事情，比如需要不断扩大沟通视窗，制定规则，减少执行摩擦等，我再提出几个观点。 敏捷教练应该是好销售。我们卖什么？卖“概念”。如果你在团队推敏捷方法和敏捷流程，你可以参考以下的销售思路，会让你的整个过程更容易，大家不妨试试。 敏捷教练应该是防火队员，更侧重于做防火的事情，而不是做救火队员（在问题发生前，提前感知到，提前准备预案，最好提前解决掉。） 教练应该是算法工程师，为什么？概念只是概念，最终落地的效果好不好，是需要在真实环境下，根据实际情况来做“调参”，通过不同管理算法的引入，通过不同的实践和结果反馈，不断迭代优化的过程。 3-管理的算法敏捷教练是算法工程师，那么，他应该负责什么样的算法？ 比如我们应该要确保团队持续不断的做正确的事情，如何做？ 我们可以把敏捷和精益创业、设计思维做链接，形成一套从问题发现，到问题的分解和试验，到敏捷交付用户价值的闭环。 比如我们有各种各样的模式。 包括瀑布流程，PMBOK流程。 敏捷流程，看板流程。 敏捷界的网红Scrum流程和精益流程。 ...

你好，欢迎使用 CODING！这份最佳实践将帮助你通过 CODING 研发管理系统来更好地实践 DevOps 流程。 DevOps 的本质是打破各个部门之间的隔阂，打通企业的前中后台，推进跨部门协作。CODING 研发管理系统涵盖了企业从需求管理、迭代规划、产品研发，到测试管理、部署管理等软件研发全周期。辅以 Wiki、文件管理等功能，帮助企业打破各个研发小组甚至企业部门之间的边界，让产品经理、研发团队、测试工程师、运维乃至于市场运营、销售、行政等部门共享同一个协作平台，让信息流通更加顺畅，让跨部门协作更加紧密，帮助企业提高研发效能，创造更多的商业价值。 使用 CODING 实践 DevOps从需求构思到产品落地，CODING 研发管理系统引入硅谷最先进的理论，再结合符合中国研发团队的长期积累，为企业提供最优秀的 DevOps 实践，帮助企业将研发效能提升到全新的标准。 同时通过 CODING 的企业微信小程序，还能实现随时随地的同步与协同，通过小程序可以直接查看任务详情、评论任务还能实现允许代码合并（MR）等功能，做到 Coding Anytime Anywhere。 DevOps 的核心在于速度和可控性，CODING 权限管理功能，可以帮助项目管理员方便地根据项目成员的角色来分配相应的权限，减少误操作带来的安全隐患，同时还支持自定义用户组，增加研发管理的可控性。在项目开始时，由项目管理员先行配置好所有成员的权限，确保团队更有序地进行软件开发。 一、迭代规划在邀请所有项目成员加入并配置好相应权限后，正式进入研发阶段。首先要由本项目的产品负责人在需求管理模块中制定项目的产品规划，并负责维护和更新。之后产品团队会通过 CODING 研发管理系统的需求管理功能创建一个需求池。 收集与管理需求产品经理将规划上线的功能、用户的反馈以及市场调研的结果整理出来，通过需求管理中的需求形式统一归纳，形成需求池。同时产品负责人对需求池中的需求进行进一步分析，根据团队习惯将需求分为技术问题、设计问题和产品问题。每条需求下都会根据需求的复杂程度创建一系列子任务，越重要的需求需要撰写越完整的需求描述。 制定版本迭代计划在分析完需求后，通过 CODING 研发管理系统中的迭代功能来制定版本发布计划。此时产品团队需要与研发和设计团队召开产品会议，在会议中，产品经理对各个需求进行优先级排序，明确每次版本迭代中需要包括哪些需求、缺陷、工作和任务并设定好迭代周期。一个项目按照开发顺序可以分成不同的迭代。 事务中包含需求、任务和缺陷，迭代提供完整的概览功能，可以清晰地展示每个迭代中的事务进行情况和分布。 在会议结束后，每个项目成员应该对自己的事务有清晰的认知。 需求文档和原型文件在完成迭代规划后，产品经理即可在 Wiki 中根据迭代中的需求撰写完整的产品功能文档。 同时可以使用 CODING 的文件功能上传分享产品的原型图。CODING 的功能和 Wiki 功能为研发团队提拱了内置的文档协作和团队知识沉淀工具。 二、产品研发在迭代开始后，拿到产品的原型设计和功能说明文档，研发工程师开始进行相关功能的交付开发。如果需求中涉及设计团队，研发工程师可以直接在需求管理页面通过关联功能关联相应的设计任务。 代码托管CODING 的代码托管服务提供高速、稳定且更易用的代码仓库，高性能远端 Git 仓库支持分布式计算和存储，并具有保护分支权限控制等功能。研发团队可以使用 Feature Branch Workflow、Gitflow 和 Forking 等并行研发流程，让团队成员共用一个私有项目仓库进行管理协作，开发者可以选择适合自身的开发流程进行开发。这样的并行开发可以大幅缩短等待时间，提高研发团队的研发效能。 Code ReviewDevOps 的主旨在于快速迭代，在注重速度的同时，质量也是重要的指标之一。开发完成后通过提交 Merge Request 进行代码评审，确保代码质量。通过代码评审后 merge 进入 master 分支。 ...

点击观看视频教程带你一步一步搞定 CODING 持续集成 持续集成加速软件交付持续集成这个概念是由 Grady Booch 在 1991 年首次提出，随后成为了 DevOps 的核心实践之一。持续集成使得开发人员不断地将各自分支的源代码集成到共享的主干中，同时对代码进行验证（执行静态测试用例）、编译和测试（执行动态测试用例），以避免集成出现问题。 持续集成为研发组织带来了多重好处： 自动化构建流水线将开发人员从重复劳动中解放出来，比人工集成更加高效。花费更少的时间调试，告别长时间和紧张的集成。提高集成效率的可视性，让每个人都能看到集成结果和获取最新构建的可交付成果，减少沟通成本。及早发现问题并将其扼杀在萌芽状态，更加快速地交付软件。基于 CODING 轻松搞定持续集成业界推荐的持续集成最佳实践要点包括：研发组织按照项目情况共同维护一个代码库，支持代码自动化构建，并且在构建过程当中可以进行自检；每次提交必须进行一次构建、保持构建的高效；确保研发团队易于取得最新构建的可交付成果，并且支持自动化部署。 落地持续集成最佳实践的方式有多种，可以选择基于开源工具自建，例如 Jenkins，或者使用 CODING 这类 SaaS 化的解决方案。这两种方式究竟哪种更适合你呢？接下来我们通过视频看看两种方式搭建流水线的效率—— 线上视频地址：https://v.qq.com/x/page/f0877pg1r9w.html 除了视频中展示的开箱即用体验之外，CODING 的持续集成还提供了： 全面的构建类型CODING 支持包括 Docker 镜像、Jar、APK 等软件包的构建，预置了主流开发语言的构建环境：Java、PHP、Go、Python、NodeJS 等。 缓存加速与构建依赖拉取优化CODING 持续集成支持在不同的构建任务之间开启缓存，开启缓存功能可以平均提高 300% 的构建速度。在构建依赖拉取方面，对于包括 Maven，NPM 在内的主流镜像源有专用网络优化，保证拉取速度，进一步提升构建的速度。 多 Job 并行构建CODING 支持单项目并行构建，以满足重度持续集成用户的需求。后端的服务器集群可以根据用户的需求实施调度响应的计算资源，保证用户的构建任务快速开始，减少排队时间。 图形化编排完善的图形化编排能力，以降低使用门槛。针对构建的每一个步骤提供丰富的构建脚本模板供用户选择。 全面兼容 JenkinsCODING 持续集成的构建脚本在语法上全面兼容 Jenkins。Jenkins 用户可以无缝迁移 Jenkins File 到 CODING。 近期 CODING 的制品库功能已上线，开发者可以在制品库中统一管理持续构建产物。目前制品库已支持 Docker 镜像的制品管理，后续会逐步支持多种主流的软件包类型来进一步完善 DevOps 工作流，敬请期待。 点击此处立即体验开箱即用的 CODING 持续集成

阿里妹导读：当小团队的产出跟不上业务需要，团队就面临规模化的问题。从1个团队到3个团队，仍可以通过简单的团队沟通保持高效协作。当产品复杂到需要5个以上团队同时开发时，我们需要一定的组织设计来保证团队间的顺畅协作，使得多团队共同开发一个产品时仍能保持敏捷性。这时候的组织该如何设计？今天，我们听听阿里敏捷教练怎么说。1、保持小团队在初创企业或产品刚起步时，团队通常都不大。随着业务的发展，需求越来越多，产品越来越复杂，很多团队的第一反应都是加人。事实上，加人并不是唯一选择，也未必是最优选择。很多时候，小团队能交付惊人的业务成果。 一方面，通过保持专注：Do one thing and do it well，小团队可以聚焦于核心业务，摒除不必要的干扰。有一款微处理器 ARM 比英特尔先做出来，团队的一个leader 说：“回过头来看，当时我们决定做一款微处理器的时候，我认为我做了两个重要的决定。我信任我的团队，并且给了团队两件英特尔和摩托罗拉永远不会提供给他们员工的东西：第一是缺钱，第二是缺人。他们不得不保持简单”。[2] 类似的，创办于2009年的 WhatsApp 于2014年被 Facebook 收购时，公司只有55名员工，全球活跃用户达到4.5亿人，日发送短消息达160亿条。 另一方面，随着开源运动、中台技术和云化技术的发展，很多非核心业务逻辑可以借助外力快速搭建，在业务高速发展的同时，继续保持一支精干的团队。例如，在阿里巴巴研发协同平台“云效”上，二十分钟就可以搭建一套 Spring Boot web application 的持续集成流水线，包含静态代码扫描、单元测试、编译、打包、部署、接口测试。不仅操作方便快捷，还省去了采购机器、部署和管理 build farm 的开销。 2、业务单元特性团队即便努力保持专注并用尽了技术红利，有时业务的发展还是远远超出预期，此时组建多个团队势在必行。 比较理想的选择是按照业务单元来组建特性团队。一个业务单元类似于一家小型创业公司，有自己的长期使命和愿景，有相对清晰的业务边界和盈利模式。人员方面，各业务单元有独立的业务、产品和研发团队。技术方面，各业务单元可以独立完成产品开发的全流程，包括业务决策、产品设计、开发、测试和发布，尽量避免业务单元之间的依赖。 作为一个超级 app，手机淘宝分为几条业务线，同一条业务线内还分为几个独立业务。例如，微淘和淘宝直播都属于内容平台业务线，二者的内容生产、传播渠道、受众和盈利模式不同，因而是相对独立的业务单元。二者有独立的业务、产品和研发团队，业务目标也分开设定和衡量。 技术上解耦是各业务单元能够独立发展的前提。为了解决团队间的依赖，手机淘宝对架构做了容器化改造：一些必要的初始化操作放在 common 容器中，各业务在自己的 bundle 中。各业务 bundle 按需加载，只能依赖底层的 common 架构，不能相互依赖。这样各业务 bundle 可以并行开发，互不干扰。 按照独立的业务边界来组建特性团队，团队能独立发布新功能，迅速获得市场反馈，通过不断试错找到业务发展的方向。 全球第一大音乐平台、音乐流媒体公司 Spotify 也按照业务单元组建团队。 在" Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds "[1] ，敏捷教练 Henrik Kniberg 详细介绍了 Spotify 模式。 Spotify 的30多个“小分队”（squad）分布在全球的三个城市，每个 squad 负责产品的特定方向（例如搜索或 radio）。每个 squad 相当于一个小创业公司，squad 没有特定的主管，只有一位产品负责人（Product Owner）。PO 负责业务方向，squad 成员组成跨职能团队交付业务结果。PO 帮助 squad 制定目标和管理优先级，也会定期维护公司层面的产品路线图并确保 squad 的目标与公司战略相匹配。squad被鼓励应用精益创业原则，例如先交付 MVP（minimum viable product），并通过 A/B 测试来验证假设。此外，squad 可以得到敏捷教练的帮助，敏捷教练引导 squad 持续改进并帮助团队移除障碍。 ...

Hi,大家好，我是MadPecker，一款免费，好用的缺陷(Bug)管理SaaS软件！ 今天，小啄给大家介绍一下如何使用MadPecker进行敏捷开发！ 1.如何进行需求管理 点击页面下方的“+”号按钮新建需求，在输入需求名称、优先级（选填）之后，点击确定按钮，完成需求创建。 需求总共分为五个状态，分别是需求池、待评审、待开发、开发中、已完成。一般情况下，可以先在需求池中创建需求，再根据实际情况改变需求的状态。 2.如何进行迭代管理 点击界面右上角的【新建迭代】按钮，输入迭代名称、迭代日期、迭代版本（选填）、关联需求（选填），点击【确定】按钮，完成迭代创建。 创建完迭代之后，点击【关联需求】按钮，可以将“待开发”状态下的需求和本次迭代关联。 3.如何进行任务管理 在关联需求之后，就可以根据需求拆分任务了。任务初始状态分为三种，包括待处理、开发中、已完成。如果开发团队在开发过程中需要更多的任务状态的话，可以点击【新建列表】按钮，输入列表名称，完成任务状态的创建。同时，任务列表支持左右拖拽，可以根据自身的需要排列顺序。 左侧的“已关联需求池”主要方便用户在计划会中拆分任务，在开发过程中，如果开发人员不需要看到“已关联需求池”，可以点击“已关联需求池”左下角的小箱子隐藏“已关联需求池”。 点击“待处理”状态下“+”号新建任务，输入任务标题、处理人（选填）、日期（选填），点击【确定】按钮完成任务创建。如果填写更多内容的话可以点击【更多】按钮，选择标签、优先级、关联需求，输入工作量。 点击其中一个任务，可以对当前任务进行编辑、删除操作。 在实际项目开发过程中，开发人员可以根据实际情况拖拽任务到其它任务列中变更任务状态，直到所有任务都在“已完成”状态中。 4.如何开启一次迭代 在录制完任务之后，点击迭代列表中的小箭头开始迭代。开始迭代之后，本次迭代关联的需求会自动移动到“开发中”状态下。 当任务全部到“已完成”状态下的时候或是迭代结束的时候，可以点击打勾完成迭代，同样的，本次迭代关联的需求会自动移动到“已完成”状态下。

Hi,大家好，我是MadPecker，一款免费，好用的缺陷(Bug)管理SaaS软件！今天，我给大家介绍一下如何用MadPecker进行BUG管理！网址：www.madpecker.com一、提交BUG点击界面右上角的【提交】按钮，输入标题，选择模块信息、处理人、任务类型、优先级，填写任务描述，上传图片等，完成任务创建。在选择模块信息之后，会带出之前设置的默认处理人，处理人只能选择一个，如果这个任务需要其他人关注的话可以点击处理人旁边的【@】按钮进行@人操作。上传图片时，MadPecker支持点击上传、拖拽上传和粘贴上传。                                                               提交BUG                                                                编辑BUG 二、处理BUGBUG创建完成之后，处理人可以在【我的待办】中查看到这个BUG并进行处理。点击BUG进入BUG详情页，可以看到任务流程走到处理人的节点，处理人可以对任务进行指派或完成操作，点击【指派】按钮，当前处理人可以把任务指给下一步处理人；点击【完成】按钮，当前处理人可以把任务指给下一步审核人。                                                                处理BUG ...

本文囊括2076字 Git 作为一个强大的分布式版本控制系统，对比 SVN、CVS 等版本控制系统，其架构和设计在研发管理和协作上有着极大的优势。在个人开发的代码管理和团队协作过程中，合理使用分支能在极大程度上提升管理效率。这篇文章根据张三、李四、赵六开发成长历程改编，解读了在企业开发过程中进行协作开发的分支模型。 从不用版本管理 到 使用 Git分支管理的故事，也就是从这个时候开始的。。。 某公司只有一个程序员，一开始并没有版本管理的概念。项目开发只有一个人在参与，所以也没用版本管理工具。 后来，老板又招了两个程序员，老板说：“研发管理要规范！”，经过一番调研，选用了 Git，三个人开始使用 Git 进行开发上的协作。 一开始，三个人都是通过一个仓库，在 master 分支上进行协作。每天上班第一件事就是先把最新的代码从服务器上拉到本地的 master 分支，下班前再把代码给推到服务器上的 master 分支，项目就这样展开了协作。 3人通过本地仓库 master 分支向远程仓库 master 分支提交代码 解决频繁的代码提交冲突 协作了几天，团队发现提交代码 master 时候，经常产生代码冲突，要么张三和李四的代码冲突，要么李四跟赵六的代码冲突。这时总要有人把代码拉下来解决冲突。才能保证后续开发工作顺利进行。同时，由于缺少代码审查。部分质量较差的代码和无关内容也时不时被提交上去。 团队在解决冲突和代码重构的问题上花费了不少精力。。。 为了解决单一分支频繁更新容易发生冲突的问题，三人开始研究使用分支的方式进行协作。通过在本地 master 检出新分支，修改后将新分支推送到远程仓库，再通过 拉取合并请求（Pull Request）在远程仓库上合并分支到 master 分支。最后再把代码从远程 master 拉取到本地 master 进行更新。在这个基础上，团队也开始展开相互的 代码审查（Code Review）工作。本地 master 分支检出新分支开发推送到远端仓库后，通过 Pull Request 合并到 master，然后拉回本地 master。 初步解决代码迭代版本问题 经过一番折腾，几个人的协作总算能比较稳定地进行。在后续数周内，团队开发工作顺利展开，项目也得以落地，进入快速迭代阶段。为了解决迭代的版本问题，团队使用分支对每次版本发布检出一个分支进行保留。通过远程仓库 master 分支在版本发布时，检出一个以版本号命名的分支，作为特定版本管理。 团队增长带来的困扰 两个月后，公司迎来了业务的快速增长。技术团队从原来三个人快速增长到十来个人。原来的成员开始带着新人做业务，随着团队的增长，原有的协作方式再次遇到各种各样的问题。经过短短一周的磨合，三人无比疲惫地坐到一起，对过去一周遇到的问题进行了复盘： 随着协作人数增多，远程仓库分支数量快速增长，查找起来很麻烦，经常出现分支重名问题。分支命名混乱，提交新功能的分支和修复Bug的分支经常混淆在一块。版本迭代的速度太快，产生了一大堆的 Realease 分支，又带来了一堆的管理问题。还没来得及合并或独立维护的分支，时间久了容易出现管理遗漏和维护混乱。虽然有 Code Review，但程序的 Bug 数和 Crash 频率明显随团队规模而增长，生产事故发生率和回滚率提高。还有人把手头未完成开发的分支扔到远程仓库进行托管。经过讨论三个人都意识到了问题所在，但无奈三人对于多人协作开发经验不多，讨论无果后，决定各自调研，再对比讨论。两天后，三个人带着方案展开了探讨。✗ℨ ...

一个完整的软件研发全流程要经历需求、迭代、任务、编码、审查、部署、测试、发布等阶段。码云企业版是如何支撑所有流程实现的呢？码云企业版软件研发管理过程全景全流程管理 Step1：需求管理 从 0 到 1产品经理运用码云企业版的「需求管理」提出「需求」，需求经确认可纳入「项目」管理，由技术管理者转化成技术实现方案，通过「里程碑」规划迭代；接下来，将里程碑拆分为具体任务，安排给技术团队成员，实现从需求产生到落地的管理。码云企业版需求管理看板全流程管理 Step2：迭代规划 统筹全局技术管理者提出技术方案开始规划迭代，并分配团队任务，在线协作实时反馈。及时优化任务安排并落实到人，实现更高效的闭环管理。码云企业版的「里程碑」展示了迭代计划、任务状态和层级关系、时间安排、相关负责人、相应交付的代码及其审查测试情况，充分发挥团队协作的灵活性。码云企业版里程碑 迭代规划 统筹全局团队成员根据 「燃尽图」自发了解工作全局、关注项目进展。图中纵坐标代表任务量，横坐标代表时间。灰色曲线是最理想情况的任务完成线，橘色曲线是实际进度，如果实际低于计划，说明工期朝前；如果实际高于计划，说明工期延后，项目进展一览无余。码云企业版燃尽图 一展工作全局全流程管理 Step3：任务管理 层次分明软件开发过程管理的核心就是对任务进行管理。相比平铺式的任务展示，将需求拆分成一个系统的树状任务分布，同时，多个任务又能相互关联，纵横管理更灵动。码云企业版的「任务管理」可对需求进行父子层级关系的细化管理。「任务看板」自由切换状态、类型、成员看板三种模式，状态看板便于快捷管理任务进度，通过拖拽快速变更任务状态；类型看板便于分类查看和规划，自定义任务类型；成员看板便于迅速了解成员任务。明确显示时间安排、优先级、负责人、任务标签等关键信息。码云企业版 任务看板还可把任务看板从「看板模式」切换成「列表模式」，便捷筛选“本周/本月任务”，各周期任务一目了然。当任务有了新动态，码云 Gitee 服务号会第一时间推送消息，及时掌握进展。 说到这里，忍不住预告一下码云企业版即将推出的最新功能「甘特图」。全流程管理 Step4：代码托管 精细管控将代码托管在码云企业版，统一管理代码资源，方便随时随地访问，完整、清晰、可视化地记录代码变更过程。码云企业版支持细粒度的权限管理，在 Git 的便捷协作基础之上，又可实现更精细的权限管理：从代码的角度，支持“项目-仓库-分支”三级管理，支持分支保护，灵活适配各种开发架构。从成员的角度，支持“超级管理员-管理员-普通成员-人事管理员”，其中，普通成员又可分为“管理员-开发者-观察者-报告者”四种权限，并可区分「内部」与「外包」成员。支持 IP 访问限制，可设置 IP 白名单，进一步增强代码安全性。企业代码仓库定期自动备份，并可禁止强推，最大程度避免误操作导致的代码丢失问题。全流程管理 Step5：代码评审 提升质量质量审查在于找出及修正软件开发初期忽略的错误，提升代码质量。码云企业版的「 Pull Request 」可在开发者提交代码后，自动触发代码质量分析，减少人工审核，提升效率。同时，「 Pull Request 」可指定审查、测试，需指定审核人员的某一位或是全数通过审核，该代码才可合并。还可以通过双栏对比查看修改文件和源文件的异同，对指定代码进行提问+评论，通过聚焦讨论提升代码质量。全流程管理 Step6：部署测试 持续集成安装码云企业版的 Jenkins 插件 Gitee Jenkins Plugin，配置 Jenkins 触发器，接受平台发送的 WebHook 触发 Jenkins 进行自动化持续集成或持续部署，将构建状态及时反馈至平台。全流程管理 Step7：缺陷管理 蓄力迭代对于 Bug 和反馈，需要及时安排处理。码云的「缺陷管理」，可以用「优先级」标注 Bug 处理的顺序与严重程度，同时用「标签」对 Bug 进行清晰地归类与存档管理。产品上线后，收集到的用户反馈又会统计到 [需求管理]中，作为下一轮迭代的需求来源。 码云企业版 https://gitee.com/enterprises企业级软件协作开发的管理平台有序规划和管理软件研发全生命周期往期精彩推荐 戳原文，更有料！初创企业限时特惠，999 即可购买码云标准版重磅更新：码云企业版之项目多仓库功能上线！码云 Gitee 新增仓库访问之 IP 白名单功能码云如何保护你的数据——内部安全治理篇

近日，巴黎圣母院失火，而我们当中的许多人都还没来得及去欣赏它的真容。我们曾以为美好的事物会等待我们，伟大的目标也会等待我们。世事无常，唯一不变的就是变化。在软件研发领域，敏捷研发就是这么一个小步快跑来积极面对变化的工作方式。敏捷研发带动企业小步快跑敏捷研发是涉及整个软件工程的理念与实践，它的核心是迭代和增量式软件开发方法。开发者快速发布一个可运行但不完美的版本投入市场，在后续迭代中根据用户的反馈改进产品，新增一到多个用户可以感知的完整功能，从而逼近产品的最终形态。敏捷实践帮助企业以一个低预算迅速展开业务。在瞬息万变的市场下，需求通常是紧急且不确定的，过大的前期规划可能造成更多浪费。敏捷研发的关键在于拥抱持续改进的心态。 通过迭代让团队在一到三个星期就能看到产品功能的直观变化，给团队带来持续激励的同时，也让团队在迭代和增量中快速成长。通过 CODING 开启敏捷研发从需求构思到软件发布，CODING 将先进的敏捷研发方法融入到工作流当中来。维护需求池产品经理将产品需求、用户反馈、缺陷转换而来的需求录入到需求池。需求是指用户解决某一问题或达到某一目标所需的软件功能。当产品经理创建一个需求后，可以设置优先级、截止日期、需求分类等基本信息，并指定处理人员处理。较大粒度的需求需要分解为较小的子需求。规划迭代团队成员进行迭代会议，对迭代的目标、内容、周期、负责人达成共识。迭代的生命周期按先后顺序依次为未开始、进行中和已完成三个阶段。跟踪迭代各成员按照优先级处理自己负责的事务，每日通过 15 分钟左右的站立会议，沟通迭代进度和期间发生的问题，迅速同步信息。团队所有成员可在迭代概览中跟踪迭代进度、事务处理趋势和速度。回顾迭代在迭代完成后，团队对本次迭代进行复盘，反思出现的问题、评估迭代质量、总结经验、并将复盘后的经验和解决方案应用到下一次迭代中。同时，针对迭代遗留事务进行评估，决定哪些事务需要移入“未规划”，哪些可规划进未来的迭代中。若存在未完成的子需求，可将其升级为父需求，并决定下一次迭代。CODING 敏捷研发管理涵盖了从产品规划、需求管理、迭代规划、任务进度跟踪、开发测试、持续部署整个研发生命周期的管理，满足不同大小团队或企业的协作和管理。我们鼓励 CODING 的用户敢于想象，大胆行动，希望 CODING 能够成为企业在荆棘之路上的创新引擎。点击试用 CODING 研发管理系统，体验敏捷研发，拥抱变化！

之前我们分享过《CODING 如何使用 CODING 开发 CODING》的文章，时过境迁，现在 CODING 研发管理系统已经上线了如持续集成、缺陷管理、测试管理等 DevOps 中的重要功能，并增加了对 SVN 的支持。借此机会我们以自身的研发流程为例，来展示一下 How CODING uses CODING to build CODING 2.0。企业级一站式软件研发协作平台CODING 现在的团队有 100 多人，分布在全球各地（深圳、北京、成都、西雅图等），均使用 CODING 研发管理系统作为云端协作平台。在 CODING，不仅研发相关的团队使用 CODING 来进行研发管理，市场、运营、行政的部门也同样使用 CODING 进行任务分配与追踪、文件分享等日常工作。同时通过 CODING 的企业微信/微信小程序，还能实现随时随地同步与协同任务，小程序可以直接查看任务详情、评论任务，还能实现代码合并（MR）等功能，真正做到 Coding Anytime Anywhere。CODING 研发管理系统是基于项目进行的，我们依据组织架构建立了相关项目并使用【成员管理】添加相应部门的人员。通过项目这种扁平化的管理形式，帮助企业加快反应速度，提高自身敏捷性。下周即将上线的 CODING 权限管理功能，可以帮助项目管理员方便地根据项目成员角色来分配相应的权限，减少误操作带来的安全隐患。同时支持自定义用户组，增加研发管理的灵活性。Push Everything,Review Everything,CI EverythingworkflowCODING 研发部门的工作流都是在项目内进行：我们使用任务功能来管理需求，使用文件来保存产品原型，使用代码功能进行开发，使用持续集成来进行自动化测试，使用缺陷管理来收集反馈，同时还使用 wiki 模块对知识进行储存与共享。通过在任务中添加关注者的方式来方便相关同事随时 follow 和 review 任务动态。CODING 强大的任务系统支持标签、跨项目引用、版本控制等多项功能，并会实时记录用户的每一次操作。同时 CODING 需求管理功能也即将上线，将在任务系统之外为用户提供更细分更场景化的使用方式。产品CODING 的产品经理在正常的产品功能排期之外，会定期在缺陷管理中查看用户的使用反馈并对相关问题的修复进行排期。当产品经理研究决定我们要实现某一个功能/修复缺陷时，会以任务的形式发布该需求。但是在发布需求之前有几件事情需要先做。给任务定性产品经理会把任务放入“需求反馈池”看板，并给任务定性：纯技术问题（含纯技术 Bug），则指派给研发负责人进行跟进。纯设计问题，则指派给设计负责人进行跟进。（真）产品问题，则准备与发任务的源头沟通分析此问题。问题分析伪需求，或者反馈方理解有误，则直接在相关任务中回复，并关闭任务即可。真需求，则完善对应的背景信息，并将任务拖入“已分析需求池”。Bug 类，可以内部请测试人员来尝试复现此问题。如果可复现，则给此任务打上“Bug 池”、“已确认”标签，再将任务放入“已分析需求池”。分析完需求后即可创建任务，如该任务涉及大型产品改动，则会由相应产品经理撰写完整的产品说明文档和必要的原型图等文件；方案完成之后，产品经理会根据任务的紧急程度给任务设定优先级，方便后续设计和开发的同事更方便的安排工作。在产品设计过程中，我们使用 CODING 的文件管理功能对产品进行原型管理和版本管理。功能开发完成后，产品经理还会配合研发进行 Staging 环境的验收。如在 Staging 环境中发现问题，则需要与发布负责人协商回退或是重新发版，成功完成验收则通知运维上生产环节。开发在产品经理完成原型图和产品说明后，便会把任务移交给研发负责人，进行评估和排期，完成排期后研发负责人会根据任务情况安排里程碑。开发人员开始基于自己的里程碑任务进行开发，其后的代码评审也是通过项目内提交 MR （合并请求）进行的。CODING 使用了 Feature Branch Workflow，即团队成员共用一个私有项目仓库进行管理协作，开发者在各自的 feature-branch 中进行开发。Code Review开发完成后通过提交 Merge Request 进行代码评审，通过代码评审后 merge 进入 master 分支（master 分支是可部署到 staging/生产环境的分支）。持续集成当开发人员 push 代码时，将会自动触发已设置好的持续集成，CODING 的持续集成会自动编译并测试该 commit。CODING 持续集成支持在任意阶段触发并支持 cvm 模式。当测试通过后，我们会更新代码到 Staging 环境。测试更新 Staging 的代码后，测试人员开始进行相关测试。现在 CODING 的测试管理功能由 18 年收购的专业测试工具飞蛾（ FEIE.WORK）承载，已实现了企业账号打通，可直接在测试管理中点击跳转到飞蛾的工作界面。接到测试任务后，测试的同时会先在飞蛾中制定相应的测试计划。制定好测试计划后，即可开始编写相关测试用例并开始执行测试计划。Staging 环境测试无问题后，该功能会以 Feature Flags（内部测试新功能）的形式发布其到生产环境，通知相关的产品或设计人员开启 Feature Flags 进行内部 Review，如果存在问题或缺陷，我们会新建一个任务进行产品反馈，确保功能及设计细节的正确性。运营产品正式上线后，CODING 的运营同事会开始收集用户反馈，通过各个渠道反馈的问题都会在 CODING 缺陷管理功能中以创建缺陷的方式进行归纳。运营会定期将收集来的缺陷进行分析，将 Bug 类的缺陷转给产品经理进行排期。如在生产环节发现重大 Bug 则会立即和产品经理沟通并通知运维，协商回退版本或者临时修复。市场在确认功能顺利上线后，产品经理会在 CODING Wiki 中更新 Roadmap，提示功能已经上线。方便市场部进行 Campaign 的计划。市场部的同事使用 CODING 任务管理中的讨论功能，可以实时讨论和跟踪项目进度。让开发更简单工欲善其事，必先利其器，在现在数字化的商业环境中，企业对于软件的依赖已经达到了前所未有的高度。如何选择一套适合中国软件研发团队的开发工具和高效的研发流程，以解放开发人员的效能，打造更好的产品，已经成为每个企业必须要思考的问题。逆水行舟，不进则退，我们自身使用 CODING 进行开发，旨在不断完善 CODING 的功能，优化提升 CODING 的使用体验，让 CODING 成为最适合中国式敏捷的研发管理系统，真正做到让中国的软件研发团队开发更简单！欢迎试用 CODING 研发管理系统，同时我们也欢迎各种反馈，如果你有任何需求或建议，请不要忘了提交给我们 :D官方反馈渠道：联系电话：400-930-9163 邮箱：enterprise@coding.net ...

摘要： Scrum等敏捷开发框架，最初都是为5到9人的小团队设计的。通过保持专注和合理利用新技术，在相当长的时间里小团队仍然可以支撑业务发展。 随着业务成长，小团队的产出可能跟不上业务需要，团队就会面临规模化的问题。Scrum等敏捷开发框架，最初都是为5到9人的小团队设计的。通过保持专注和合理利用新技术，在相当长的时间里小团队仍然可以支撑业务发展。随着业务成长，小团队的产出可能跟不上业务需要，团队就会面临规模化的问题。从1个团队拓展到3个团队，仍然可以通过简单的团队间沟通保持高效协作。当产品复杂到需要5个以上团队同时开发时，我们需要一定的组织设计来保证团队间的顺畅协作，使得多团队共同开发一个产品时仍能保持敏捷性。保持小团队在初创企业或产品刚起步时，团队通常都不大。随着业务的发展，需求越来越多，产品越来越复杂，很多团队的第一反应都是加人。事实上，加人并不是唯一选择，也未必是最优选择。很多时候，小团队能交付惊人的业务成果。一方面，通过保持专注：Do one thing and do it well，小团队可以聚焦于核心业务，摒除不必要的干扰。有一款微处理器ARM比英特尔先做出来，团队的一个leader说：“回过头来看，当时我们决定做一款微处理器的时候，我认为我做了两个重要的决定。我信任我的团队，并且给了团队两件英特尔和摩托罗拉永远不会提供给他们员工的东西：第一是缺钱，第二是缺人。他们不得不保持简单”。类似的，创办于2009年的WhatsApp于2014年被Facebook收购时，公司只有55名员工，全球活跃用户达到4.5亿人，日发送短消息达160亿条。另一方面，随着开源运动、中台技术和云化技术的发展，很多非核心业务逻辑可以借助外力快速搭建，在业务高速发展的同时，继续保持一支精干的团队。例如，在阿里巴巴研发协同平台“云效”上，二十分钟就可以搭建一套Spring Boot web application的持续集成流水线，包含静态代码扫描、单元测试、编译、打包、部署、接口测试。不仅操作方便快捷，还省去了采购机器、部署和管理 build farm的开销。业务单元特性团队即便努力保持专注并用尽了技术红利，有时业务的发展还是远远超出预期，此时组建多个团队势在必行。比较理想的选择是按照业务单元来组建特性团队。一个业务单元类似于一家小型创业公司，有自己的长期使命和愿景，有相对清晰的业务边界和盈利模式。人员方面，各业务单元有独立的业务、产品和研发团队。技术方面，各业务单元可以独立完成产品开发的全流程，包括业务决策、产品设计、开发、测试和发布，尽量避免业务单元之间的依赖。作为一个超级app，手机淘宝分为几条业务线，同一条业务线内还分为几个独立业务。例如，微淘和淘宝直播都属于内容平台业务线，二者的内容生产、传播渠道、受众和盈利模式不同，因而是相对独立的业务单元。二者有独立的业务、产品和研发团队，业务目标也分开设定和衡量。技术上解耦是各业务单元能够独立发展的前提。为了解决团队间的依赖，手机淘宝对架构做了容器化改造：一些必要的初始化操作放在common容器中，各业务在自己的bundle中。各业务bundle按需加载，只能依赖底层的common架构，不能相互依赖。这样各业务bundle可以并行开发，互不干扰。按照独立的业务边界来组建特性团队，团队能独立发布新功能，迅速获得市场反馈，通过不断试错找到业务发展的方向。全球第一大音乐平台、音乐流媒体公司Spotify也按照业务单元组建团队。在" Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds “[1] ，敏捷教练Henrik Kniberg详细介绍了Spotify模式。Spotify的30多个“小分队”（squad）分布在全球的三个城市，每个squad负责产品的特定方向（例如搜索或radio）。每个squad相当于一个小创业公司，squad没有特定的主管，只有一位产品负责人（Product Owner）。PO负责业务方向，squad成员组成跨职能团队交付业务结果。PO帮助squad制定目标和管理优先级，也会定期维护公司层面的产品路线图并确保squad的目标与公司战略相匹配。squad被鼓励应用精益创业原则，例如先交付MVP（minimum viable product），并通过A/B测试来验证假设。此外，squad可以得到敏捷教练的帮助，敏捷教练引导squad持续改进并帮助团队移除障碍。在squad之上，spotify还有两层组织架构：具有相关专业知识的人横向组成“分会”（chapter），工作在相似领域的squad组成“部落”（tribe）。此外，具有相同兴趣的人组成“行会”（guild）。这套架构的主要目的，是促进全公司范围的信息和知识共享。员工向chapter lead汇报，在转换squad时汇报线不变。尽管看上去像普通的矩阵式组织，这个矩阵是向产品交付倾斜的。同一个squad的成员坐在一起，组成高度自治的跨职能敏捷团队，共同决定产品目标以及如何交付产品。横向的chapter维度只是为了更方便地共享知识、工具和代码。chapter lead的工作是引导和支持信息流动和知识共享，而不会像传统职能经理那样负责分配工作。注：图片来自于https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify与此类似，淘宝直播的业务、产品和研发团队也汇报给不同的职能经理。高度统一的业务目标把团队成员凝聚在一起，团队共同决定业务方向、业务目标以及如何达成目标。职能经理为业务发展提供支持和帮助，并帮助团队成员在职业道路上成长，并不会把主要精力放在具体的产品交付上。淘宝直播敏捷实践参见《阿里敏捷教练，全面解析淘宝直播敏捷实践之路》。无限制特性团队有时团队在业务发展时壮大了，但是经过了一段高速发展，原有的业务方向遇到了瓶颈，新的业务方向还在摸索中。此时，业务方向还不明朗，难以按照明确的业务单元组建团队，团队需要快速适应业务方向的变化。此时，要鼓励团队广度学习，避免局部优化。不同于围绕业务单元组建的特性团队，无限制特性团队没有相对独立的业务领域，多个特性团队共享一份产品代办列表（Product Backlog），按照统一的优先级交付产品功能。无限制特性团队，并非所有团队都相同的无差别特性团队，每个团队还是可以有自己的特色和专长，只要多个团队组合起来能够按照Product Backlog的优先级交付特性即可。2018年3月，我支持阿里健康互联网医疗业务线时，正遇到这样的情况：互联网医疗业务经过两年多的摸索，找到了一些可能的发展方向，但是还没有找到非常明确的盈利模式，多个方向都需要进一步尝试。研发团队包括服务端开发、H5开发、Android开发、iOS开发、测试等30多位同学。在原有的资源池模式下，每月职能经理按照产品经理的输入，分配研发同学到各个项目中。由于业务的复杂性，产品涉及的核心应用有15个以上，除了电商平台的商品、库存、营销等基本功能，还包含互联网医疗特有的问诊、挂号等服务，并涉及到算法和AI。人员技能的瓶颈非常突出：部分核心应用只有一位同学特别了解。2018年4月至5月，商品模块负责人和AI问诊模块负责人先后休假，相应模块的技术方案设计几乎停滞，严重拖累进度。为了平衡复杂的人员技能和项目需要，职能经理经常绞尽脑汁，仍然不免捉襟见肘，一线同学身兼多个项目非常普遍。多个项目都依赖同一位团队成员时，不得不串行等待。在多个项目间频繁切换也增加了上下文切换成本。为了解决人员技能瓶颈的痛点，同时考虑到互联网医疗特定的业务发展阶段，尝试了无限制特性团队共同交付一个产品的协作模式：30人自由组合成两支特性团队。组队只需满足约束条件：人数均衡，核心应用在每个团队都有人了解，新老结合，男女搭配。组队成功后，两支团队从同一份Product Backlog里按照优先级领需求。如果某个团队无法独立完成当前最高优先级的需求，先由这个团队认领，另一个团队派师傅指导。师傅主要是培养徒弟，具体工作由认领团队的同学动手完成。由于资源瓶颈的限制，2018年5月1日到6月14日需求交付的累计偏差（需求实际交付日期与计划交付日期的偏差累加）达到了151天。经过两个月的努力，两支特性团队都具备了完成各类需求的能力，团队可以完全按照Product Backlog的优先级领需求，既不需要团队成员并发支持多个项目，也不需要等待资源瓶颈的释放。6月15日到7月31日的累计交付偏差缩短到了3天。8月1日到8月31日继续保持准时交付，累计交付偏差为2天。团队成员的个人能力得到了充分锻炼，主动拓展技能承担重任的同学获得了晋升，得到了认可。团队的自组织能力也得到了发展，遇到问题和阻碍，团队成员会主动想办法解决，不再事事依赖职能经理。职能经理的角色从派活变成了辅导和帮助团队，减少了救火时间，有更多时间考虑团队的长远发展。综上，无限制特性团队方案解决了业务需求等待资源瓶颈的痛点，不是让业务发展来匹配人员的技能，而是人员拓展技能匹配业务发展的需要。与此同时，团队成员的个人能力得到了锻炼，团队的自组织能力得到了发展，也解放了职能经理。无论是业务单元特性团队，还是无限制特性团队，每个团队都要具有独立交付产品特性的能力。一个复杂的产品特性，通常都需要修改多个模块才能实现。多个团队修改同一个模块时，如何保证模块设计的一致性，并及时清理代码偿还技术债？引入模块守护者通常是个有益的实践：每个模块最好有两位模块守护者互相backup，修改模块代码需要请模块守护者做code review，一些复杂的修改最好预先进行设计评审。模块守护者可以是兼职的，只要保证每周抽出一定比例的时间维护模块代码即可。随着业务方向越来越清晰，业务模式逐渐稳定，无限制特性团队会逐步找到相对固定的分工合作模式，每个特性团队会逐步找到自己最擅长和最感兴趣的产品方向。明确的产品方向，为团队提供了长期深耕的条件，团队逐步成为某一领域的专家。此时，无限制特性团队就完成了向业务单元特性团队的过渡。小结通过手机淘宝、Spotify和阿里健康的案例，我相信多团队开发一个产品仍然可以保持敏捷。在业务方向明确的情况下，按照业务单元组建特性团队是最理想的选择。在业务方向不明朗的情况下，可以先组建无限制特性团队，再逐步过渡到业务单元特性团队。无论采用何种组织设计，目的都是快速跑通业务闭环：持续地交付业务价值，并在真正的市场环境中检验假设，通过快速试错找到在一定的利润水平上为企业或终端用户提供产品和服务的可行方法。参考文献：[1] https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify作者：张迎辉，花名问菊，阿里巴巴敏捷教练，罗汉堂讲师，开发和讲授多门敏捷课程。先后支持手机淘宝、优酷、阿里文娱广告、阿里健康等多个部门的团队敏捷转型。亲身感受到敏捷给团队带来的改变，立志成为敏捷践行者.阅读作者更多内容：阿里敏捷教练，全面解析淘宝直播敏捷实践之路敏捷团队的病与药——阿里健康B2B团队敏捷转型手记打造真正的One Team，持续快速交付价值——阿里文娱广告团队敏捷实践阿里敏捷教练如何优化优酷需求分析流程？本文作者：云效鼓励师阅读原文本文为云栖社区原创内容，未经允许不得转载。

编程一开始就需要明确项目的输入、输出建立一个良好的测试用例，使用测试驱动开发熟悉运行的逻辑，考虑边界条件与特殊值先确保代码能够运行，再考虑软件设计的原则需求要厘清，概念要明确，确保需求和开发一致先实现功能，再重构代码，修改变量名等图示有时是不需要的，在创建了它们而没有验证它们的代码就打算去遵循它们时，图示就是无益的最好的设计师是首先编写测试，一小步一小步前进时逐渐形成的

7月7日，Scrum社区聚集在阿姆斯特丹（荷兰）参加第5届Scrum Day Europe。目标是从Scrum社区生成见解并定义Scrum框架的改进。白天我们要求大家回答5个问题：在过去的20年里，Scrum的实力已被证明是什么？未来20年Scrum应该关注什么？到目前为止，Scrum最让你感到沮丧的是什么？什么连接你到Scrum？什么是可以添加到Scrum的小改进？每位参与者都贡献并提供了意见 因此它被证明是一个真正的社区活动！今年的主题是“下一次迭代”。因此我们回顾了Scrum在过去20年中给我们带来了什么，同时也期待着Scrum的未来。当然，评估是通过回顾展进行的。根据参与者，Scrum的优势是什么？这是一个简单轻巧的框架（6x）这是一个透明度促成因素（5倍）它提供了一个可持续和持续改进的框架（4x）它吸引了普遍基本的人类需求和价值观（3x）它提供短反馈循环，连续计划（3x）它消除了客户 - 供应商的界限（2x）这很有趣也很成功（2x）它是个人成长的推动者的使用时间盒它改善 了所有层的通信这不是一颗银弹 (尤指人们寄予厚望的某种新科技)它强调多学科团队合作根据参与者的说法，Scrum在未来几年应该关注什么？支持创造价值驱动型组织，关注客户满意度（9）加强整个组织的框架（9）保持简洁（3）在下一个sprint开始之前设置进程/网关（2）提供更多支持扩展Scrum的实践（2）证明Scrum工作的指标！（2）不断创新和适应提供工作 增量解决与非Scrum组织的接口问题建立实践以发展文化拥抱精益 思想整合DevOps 原则专注于Sprint 目标提供工具来检查产品的神智逐渐与多个独立组织合作为企业高管提供Scrum将Scrum应用于其他“慢速发展”行业，例如制药行业与评论家进行更多讨论，以了解他们在Scrum中缺少的感受研究敏捷是多么“敏捷”。因为有些组织滥用敏捷。根据参与者的说法，Scrum最让你感到沮丧的是什么？Scrum看起来很简单，但实在太难了（6）Scrum 僵尸 变体（5）对Scrum Master角色的误解（4）没有 授权的产品所有者（4）管理层不愿意改变（2）角色需要高于普通人Scrum和当前组织的值不匹配纯粹专注于软件开发不知道如何处理投资组合/产品管理缺乏做到这一点工作水 - 摔倒团队沟通根据参与者，您将什么与Scrum联系起来？Scrum工作，开始整理！（5）合作成瘾（5）令人敬畏的工作氛围（3）邀请人们不断改进，一次一小步（3）我个人得到了乐趣回到我的工作生活！（2）权力下放的决策（2）我在瀑布工作了21年Scrum的常识活下去！在工作和个人使用它活下去！处理unknows使用自动化软件帮助掌握Scrum流程Scrum Process Canvas是一个用于帮助您管理Scrum项目的Scrum工具 - 从识别项目愿景到最终产品交付，使敏捷项目更加简单有效。Scrum Process canvas可帮助您：在一个设计精美的Scrum流程画布中无缝导航整个Scrum流程。快速，轻松，无缝地执行Scrum活动。让整个团队充分参与。（开放Scrum Process Canvas快速导览 - 视觉范例）为每个Scrum团队打造。借助scrum流程画布，scrum工作项，敏捷管理工具和直观界面，Scrum Process Canvas可帮助您的Scrum团队在每个Scrum项目中取得最大成功。优先产品积压。通过识别业务目标（作为用例），Epics和用户故事，逐步构建产品backlog。整个项目中的新郎产品积压很容易。用例用户故事地图积压优先排序在用户故事地图中整理用户故事将用户活动，史诗和用户故事保存在结构良好的用户故事地图中。通过拖放轻松重新排列用户故事。点击编辑用户故事。通过Web访问故事地图，随时随地工作，节省时间并完成更多工作。通过更好的计划开始冲刺。sprint backlog管理器为敏捷团队提供了一个直观的界面，用于讨论和选择要包含在sprint中的故事，创建和估计任务。更快地创建Sprint Backlog借助表格界面和选择工具，快速将用户故事包含在sprint积压中。结果是一个明确的积压故事列表，整个团队可以在整个sprint中关注这些故事。努力估计任务列表从包含的故事中轻松维护开发任务列表。通过列表视图，准确地估算比较任务所涉及的工作量。让你的团队回到整个冲刺阶段。所有scrum工具都支持您的团队在整个sprint中将承诺的用户故事转化为功能性可交付成果。每日ScrumBurndown图表障碍日志Scrumboard进度跟踪回顾与回顾记录每日Scrum会议保留每个团队成员在每日Scrum会议中报告的工作，计划工作和遇到的障碍的记录。创建任务以管理每日Scrum会议中标识的操作项。轻松检索早期日常Scrum会议的内容。无缝迭代。一次执行一个sprint的sprint活动。轻松切换到任何早期的冲刺，随时查看其历史记录。敏捷发布管理。通过用户故事地图，您可以随时轻松地将故事添加和排列到发布分区中。项目可交付成果的状态也可以以临时方式更新。发布交付项目回顾轻松发布管理用户故事地图提供了一种可视化的发布管理方法。作为发布计划的一部分，您可以通过拖放将用户故事添加到发行版中。将每个人都放在同一页面上。有效管理团队成员的角色和职责。从一开始就将scrum master，产品所有者，业务分析师，UXers和开发人员放在同一页面上。即时文档，自动存档。生成产品待办事项，sprint积压，任务列表，各种会议等的报告。从可视化的Scrum cabinet中检索文档。内置任务管理平台。一站式敏捷解决方案提供了积压和任务管理之间的无缝集成。您可以在一个地方创建任务，报告和监控进度。单一软件，多种用途。使用UML，BPMN，ERD，DFD，UX（线框，原型设计），代码工程，ORM，思维导图等来加强您的Scrum项目。敏捷敏捷方法论敏捷开发ScrumScrum敏捷

雖然這篇文章討論了Scrum中的一些常見指导原则，但重要的是要記住這些指南是靈活的，應根據您團隊的需求進行塑造。當我提到規則時，我指的是那些無法修補以適應特定背景的方面。例如，沒有產品負責人，開發團隊和Scrum Master，您就無法做Scrum。當我提到指南時，我指的是那些可能被改變以適應特定背景的方面; 但是，影響只能在實施後進行驗證。然後我們相應地檢查和調整。例如，Product Backlog細化消耗不超過團隊容量的10％。容量是小時數，故事點數還是天數？嗯，沒有規則。Scrum團隊自我組織並選擇最適合他們背景的東西; 遵循我們消耗的指導方針，不超過團隊容量的10％。在這篇文章中，我將探討一些將11個要素綁定在一起的指南，並讓Scrum團隊靈活地將這些方面融入其背景中。＃1。開發團隊規模建議開發團隊的規模為3-9名成員。根據具體情況，可能會有更多人或更少。它的影響因團隊環境而異。不到三個開發團隊成員減少了交互，導致生產率降低。較小的開發團隊可能會在Sprint期間遇到技能限制，導致開發團隊無法提供可能可釋放的增量。擁有超過九名成員需要太多的協調。大型開發團隊為實證過程提供了太多的複雜性。＃2。開發團隊的標題/角色Scrum無法識別開發團隊中的任何標題/角色。在開發團隊中，每個人都是開發團隊成員。雖然在組織內，團隊成員可能擁有頭銜/角色。根據我的經驗，我沒有遇到任何只有一個頭銜/角色的團隊。＃3。每日Scrum的三種問題格式我使用過的大多數團隊都使用了每日Scrum的三個問題的格式：昨天我做了什麼幫助開發團隊實現Sprint目標？今天我將做些什麼來幫助開發團隊實現Sprint目標？我是否看到任何妨礙我或開發團隊滿足Sprint目標的障礙？這三個問題只是以Scrum開頭的團隊的模板。只要他們專注於Sprint目標的進展，開發團隊就可以按照他們認為合適的方式構建他們的Daily Scrum。＃4。活動時間表事件的時間框表示一個月Sprint事件允許的最長時間。指南是：對於較短的Sprint，時間限制通常較短。這是否意味著，對於為期兩週的Sprint，Sprint Planning的時間限制為四小時，Sprint Review為兩小時，Sprint回顧為一個半小時？沒有。只要滿足其目的，事件可以根據需要调整短/長，但它們不能超過最大分配時間。例如，Sprint計劃為期兩週的Sprint計劃活動如果達到目的可能會在兩小時內結束，如果不滿足，則可能會持續八個小時。＃5。進展趨勢Scrum指南建議使用燒毀圖表和累積流量等實踐來監控進度。但是，團隊可以完全自由選擇他們認為合適的任何練習。根據我的經驗，我見過團隊創建視覺路線圖，基於里程碑的進度，旅程線，釋放燃燒圖表等。我們還需要記住，在復雜的環境中，只有經驗數據才能幫助我們做出正確的決策。＃6。估計在 Scrum的指南介紹了需要積壓的產品項目來進行估計。如何估算它們完全取決於Scrum團隊。故事點，理想日，T卹尺碼，狗尺碼是一些方法。Scrum團隊可以做“沒有估計”嗎？當然，只要Scrum團隊能夠起草支持經驗主義的計劃，創建透明度，並幫助團隊在Sprint結束時創建可能可釋放的“完成”增量。Scrum團隊自行組織選擇適合其背景的內容。＃7。工作分解在“選擇的工作將如何完成？”部分下。對於Sprint計劃，Scrum指南提到：開發團隊在Sprint的頭幾天計劃的工作在本次會議結束時進行分解，通常分為一天或更短時間。然而，這通常有助於發展團隊這樣做。根據我的經驗，我看到幾個團隊沒有將他們的工作項目細分到如此細緻的水平。他們了解如何將功能轉換為“完成”增量。＃8。Sprint評論這是一項重要的檢查和調整活動，Scrum團隊與主要利益相關方就Sprint期間取得的成果進行合作，以及在下一個Sprint中可以做些什麼來優化產品的價值。Scrum指南還描述了Sprint Review中的元素：與會者包括Scrum團隊和產品負責人邀請的主要利益相關者。產品負責人解釋了產品待辦事項項目已“完成”且未完成的內容。開發團隊討論Sprint期間的情況，遇到的問題以及這些問題是如何解決的。開發團隊演示了它“完成”的工作，並回答了有關增量的問題。產品負責人會討論產品Backlog。他或她根據迄今為止的進展（如果需要）預測可能的目標和交付日期。整個小組就下一步做什麼進行合作，以便Sprint Review為後續的Sprint Planning提供有價值的信息。回顧市場或產品的潛在用途如何改變下一步最有價值的事情。審查下一個預期的產品功能或功能發布的時間表，預算，潛在功能和市場。對於已經獲得資助一年的Scrum團隊來說，在每兩週一次的Sprint評審中審查其預算是否有意義？也許不吧。並非所有上面提到的元素都適用於所有Scrum團隊。它們作為指導提供，以便Scrum團隊可以選擇在Sprint審核期間討論和触及產品交付的各個方面，因為他們認為適合他們的上下文。＃9。發佈到生產每個Sprint的目的是創建一個可能可釋放的“完成”增量。這意味著增量需要處於可用狀態並滿足Scrum團隊的完成定義（DoD）。然而，將增量釋放到生產中的選擇由產品負責人決定。根據團隊的上下文及其創建的增量，Scrum團隊可能決定每個Sprint執行多個版本，每個Sprint發布一個版本，或者累積發布多個Sprint; 無論如何優化產品的價值。＃10。完成的定義“完成”的定義有助於提高透明度，並對完成工作的含義達成共識。根據Scrum指南，Scrum團隊有望擴大他們的國防部並使其更高質量的更嚴格。同樣，這不是一個規則。取決於團隊的背景; Scrum團隊可能會在每次回顧中重新審視它的國防部，或者可能繼續使用相同的國防部，除非它學會了新的東西以提高產品的質量。結論這些只是Scrum指南中的一些指導原則。我想提出這種區別，因為我經常發現Scrum團隊與Scrum規則和指南混淆。幾乎沒有什麼是常見的 - 將Sprint計劃的時間安排為兩個星期的Sprint或開發團隊花費太多時間和精力將PBI分解為“任務” - 其他人並不常見。我相信這篇文章將幫助團隊確定Scrum的一些方面，他們可以修改這些方面以適應他們的背景。Scrum参考What are the Scrum Events?What are Scrum Ceremonies?What is Product Backlog Grooming?What are the 3 Important Questions in Daily Scrum?Scrum Sprint Cycle in 8 StepsWhat is a Sprint in Scrum?Heartbeat of Scrum - The Daily StandupDaily Scrum Meeting - A Quick GuideWhy Fixed Length Sprints in Scrum?What is Scrum Release Planning?What is Sprint Planning?What is Sprint Review? ...

什麼是僕人式領導？雖然僕人式領導的觀念是一個至少可以追溯到兩千年的永恆概念，但現代僕人式領導運動是由Robert K. Greenleaf於1970年發表的，當時他發表了他的權威文章“僕人作為領袖 ”，他創造了這些文字。 “僕人式領袖”和“僕人式領導”。僕人式領導是一種非常社會化的領導風格。雖然傳統的領導力是關於“金字塔頂端”的人積累，囤積和鍛煉（通常會墮落為濫用）權力，但僕人式領導是與團隊分享權力，識別，優先考慮和滿足他人和幫助人們盡可能地發展和表現。必須強調的是，在說“仆人领导 - 是仆人第一”時，Greenleaf並不意味著僕人領袖應該順從，而是要真正想要服務，幫助他人。Greenleaf在AT＆T擔任管理髮展總監近四十年，當他於1964年退休時，他被認為是世界領先的企業領導專家之一。傳統領導與僕人式領導為什麼僕人式領導是一種強大的管理風格僕人式領導是一個在過去十年中吸引了一些研究人員注意力的概念，他們的研究結果一致表明了這種領導風格的力量。綠葉的“僕人式領導的最佳測試”：多層次分析是2011年的研究由內布拉斯加-林肯大學的羅伯特·W·海登，美國即說：“這項研究實證檢驗羅伯特·格林里夫（1970）的僕人領導的開創性的銜接。他理論化的四個個人成果（健康，智慧，自由自主和服務導向）都是根據僕人式領導的既定維度進行測試的。所有相關性都是顯著且積極的。“領導者對領導者的信任和對組織的承諾的影響2013年由地中海社會科學期刊發表的南非瓦爾理工大學的理查德·奇諾莫納的研究得出結論：“結果表明，僕人領導積極地影響員工對領導者的信任以及員工對組織的重大承諾。“僕人領導和員工對主管的承諾，由美國德克薩斯州康考迪亞大學的Shane Sokoll於2014年在國際領導力研究期刊上發表的一項研究表明，“發現僕人領導對員工對主管的承諾產生了重大影響。" 以下是簡單的指導方針。它能幫助你作為Scrum Master成為一名僕人領袖。1.承諾將自己放在最後僕人式領導者和其他類型的領導者之間的區別，僕人式領導者首先是僕人而不是領導者。成為僕人領袖意味著您致力於將您的個人利益放在最後。換句話說，僕人式領導是對謙卑的承諾。成為僕人領袖不是關於你的成功，而是關於你所服務的人的成功。你不是關注的中心，你所服務的人應該成為關注的焦點。我們目前生活在一個人們喜歡吹噓他們在社交媒體上取得成功的世界，僕人式領導不是吹噓你的個人成功。如果您吹噓自己的成功或作為Scrum Master的能力，或者您使用Scrum成功交付的項目，我很遺憾地說這不是僕人式領導。這些成功都不屬於你，它屬於你所服務的那些人，你沒有權利宣稱它是你的並吹噓它。我經常對其他人的公司Scrum Master的職業道路有疑問，看來他們擔心Scrum Master會在他們的餘生中保持同樣的位置。Scrum Master的成長不應該通過她在組織結構圖中的排名來看待，而應該通過她的服務的影響來看待。雖然公司中有許多領導者在組織階梯上奮戰，但我很遺憾地說，但僕人式領導並不是要在組織結構圖中奮鬥。記住這一點，你將以激光為重點服務他人，遠離公司政治，保持中立和不偏不倚。把自己放在最後，讓別人成功的方式需要很大的謙虛。2.關注他人的偉大我見過很多人問過我，“ 如果我的團隊沒有按預期交付我不應該懲罰他們嗎？“很多人還問我，” 如果有一個團隊成員沒有像其他團隊成員一樣快或多快地交付，我不應該懲罰那個人嗎？“許多公司和領導人多年來一直堅持”獎懲“模式。這種領導風格不再適用於21世紀，因為它不具有人性化。用棍棒和胡蘿蔔來懲罰表現不佳的工人的時代已經結束。我們已經通過它，我們應該在上個世紀留下它。懲罰表現不佳的傳統模式對我個人來說從未有任何意義。這只是感覺不對。僕人領袖應該幫助一個表現不佳的人，並將他們提升到更大的水平。僕人領袖總是在服務於讓別人變得偉大，而不是懲罰，指責或判斷他們。一個Scrum Master會問一個表現不佳的團隊成員，“ 我能為你做些什麼，這樣你才能成為偉大的並讓你擺脫這種局面？“你作為僕人領袖的目標不是你的偉大，而是其他人的偉大。您可能需要加倍努力或犧牲您的個人資源才能使它們變得更好。“ 但是，但是，如果我們試圖指導那個人並且他仍然沒有改變怎麼辦？“我個人認為人類是成長的動力。沒有人在早上醒來只是為了最壞。我們應該通過他們的鏡頭而不是我們的鏡頭來看待故事，而不是根據我們所看到的結論得出結論。我們應該先看看自己。僕人式領導者是一種領導者，他積極主動地解決問題的核心，這樣她就可以讓其他人變得很棒，而不是根據她所看到的結果做出結論。通過關注他人的偉大，我們對別人的評價就會減少，我們會讓別人感到安全。僕人式領導者專注於創造一個人們可以茁壯成長並成為自身最佳版本的環境，而不是人們變得具有防禦性和自尊心低的環境。3.尊重他人需要完全人性化我們一直生活在工作場所只是工作場所的信念之下，在那個系統之外我們可以完全是人。許多公司都提倡工作與生活平衡的概念，因為他們認為工作場所是關於工作的，而在該系統之外的是生活。你沒有在工作場所生活。在這種信念中，人們需要關閉他們的人性，並在每次進入工作場所時將其留在家中。我個人認為，完全是人類是一項基本需求，不應該被關閉。無論是在工作場所還是在工作場所之外，人們都需要成為人。僕人領導者不區分工作場所內外的人。僕人領導關心員工在工作場所的福祉。僕人領袖個人對她的人民作為人類感興趣。她是一個人。憐憫可能不是我們在公司環境中聽到的常見詞彙，但作為僕人式領導者，我們需要富有同情心和好奇才能對我們所服務的人產生個人興趣。要有同情心和好奇，你需要是真誠的，你不能偽造它。我還記得我的老闆告訴我的一句話，“ 不要帶著問題來找我，帶著解決方案來找我。“每當我聽到有人這麼說時，我總覺得不舒服。這聽起來不對，儘管我認識的很多人都認為這是管理層的標准信念。這種信念讓我感到氣餒，因為我覺得我需要獲得老闆的批准。如果我不能帶著問題來找我的老闆，我還能信任誰來幫助解決我的問題？在這種信念中，似乎我需要完美，我不能錯，我不能犯錯誤。僕人式領導者創造了一個環境，人們可以在工作中感到安全，完全是人，就像人們在他們的朋友和家人中感到安全，完全是人。她的人民應該說“ 我不知道 ”或“ 我失敗了，我需要幫助 ”，而不必擔心工作中的判斷或懲罰。當一個僕人領導有問題而不是告訴他們稍後帶著解決方案回來時，會邀請他們。我們隨時為他們服務。她的人民可以創造空間和時間來反思他們的錯誤。人們可以做一個能為公司帶來價值的實驗，而不必擔心失敗。勇敢說出真相僕人領袖有勇氣說實話，即使這會讓別人感到不舒服甚至抵抗。她沒有給她發送的任何信息加糖，因為她希望她的員工能夠改進並獲得新的體驗。她走的是講話，她的每一條信息都有完整性。真相可能不是過去人們習慣聽到的，因為真理沒有為政治創造空間。僕人領袖不是安全的，也不擔心說實話，因為她知道她的目標是他人的偉大。無論她做這件事有多困難，僕人領袖都會說實話。僕人式領導者不偏不倚，沒有任何收藏，否則會降低她為整個組織帶來的服務質量。告訴真相對於許多人來說永遠不會感到舒服，因為我們擔心真相會傷害他人，否則會使我們在工作場所的未來付出代價。有時候我們只告訴老闆他想听到什麼，因為我們害怕受到懲罰，或者我們不會得到他的認可。僕人領袖是不同的。僕人領袖是真誠的，她沒有隱藏的動機，也沒有個人對她的信息感興趣。說出的真相將把她所服務的人民和組織帶到一個新的高度，而不是傷害他們。事實將促使人們以不同的方式思考而不是保持現狀或住在舒適區。僕人領袖創造了一個人們可以安全地說出真相並說出真相的環境。5.開放性關於你自己的漏洞我們從上面的觀點中看到，僕人式領導者如何專注於為更大的利益服務他人。僕人式領導者也是一位對自己的弱點持開放態度的領導者。一個僕人領袖謙虛地說她沒有所有問題的所有答案，她給出的任何建議都不能作為絕對真理。僕人式領導者謙虛地不吹噓她自己，同時對她的不完美持開放態度。許多人認為，當領導者對她的脆弱性持開放態度時，這表明她很脆弱。有些人甚至可能會說她沒用。畢竟，在企業環境中，我們以我們的能力來衡量，因此在公開場合公開我們自己的漏洞會被其他人視為我們作為領導者的無能力。對我們自己的漏洞保持開放是對他人的一種服務形式，以便其他人也可以安全地對他們開放。這是我們從服務對像那裡獲得信任的唯一途徑。當我們獲得他們的信任並且他們對自己的脆弱性持開放態度時，我們可以為他人服務。當領導者有勇氣對自己的脆弱性持開放態度時，人們會感到舒適並且不會害怕判斷。人們會信任領導者，並且當領導者首先對她的人民表現出對她的脆弱性的開放態度時，他們會對自己的漏洞保持開放態度。成為僕人領袖需要謙虛。當僕人式領導不是我們社會中許多公司或領導者所採用的標準時，成為僕人領袖並不容易。對我個人而言，這對我個人來說從未如此簡 我個人仍然在努力成為一名僕人領袖。作為僕人領袖並不容易。但我相信，作為一名僕人領導者，與其他領導者相比，使我們與眾不同，是什麼能夠為這個世界帶來變化。我使用上面的指導作為我自己的動力，繼續提高我的僕人領導能力。期待在未來多年看到你作為僕人領袖的美麗工作的結果。綜上所述Scrum Master 采用僕人式領導需要將团队的需求放在首位。僕人式領導者主要關注团队的成長和福祉：首先為他人服務，對於希望在團隊成員中發揮最大作用的現代管理者來說，僕人式領導是一個強大的工具。

在转向敏捷之后，很多团队开始使用“用户故事”一词。用户故事是一种简单而优雅的技术，可以收集客户需求。然而，它需要一定的理解和实践才能用User Stories构建出色的软件。让我们仔细看看用户故事是什么以及如何使用这种技术取得成功。什么是用户故事？用户素材是对功能的简短描述，它为用户或客户带来价值，团队可以在迭代中提供这些功能。用户故事应该回答3个问题：我们为谁建造它？ - 作为<用户类型>我们在建什么？ - 我想<feature>我们为什么要建造它？ - 这样<值或利益>在此之后，用户故事的典型格式是：作为<用户类型>，我想要<feature>，以便<value或benefit>。用户故事示例：作为注册用户，我希望能够将我的图片下载到我的个人资料中，以便其他用户可以看到我的样子。有没有创建用户故事的程序？没有正式的过程来创建用户素材。尽管如此，还是应该遵循一条准则来创建一个好的用户故事。它被称为3 C，由极限编程的创始人之一Ron Jeffries提出。该卡是用户故事的书面说明。它没有捕获有关应该构建的内容的所有详细信息。相反，它是一个提醒，是对必须进行的后续通信的承诺。对话用于讨论用户故事的细节。它可能会被一些文档补充。确认由用户验收测试表示，确保用户故事满足用户/客户的验收标准。如何撰写高质量的用户故事确保用户故事具有适当质量的良好做法是遵守Bill Wake的INVEST首字母缩略词的标准。INVEST还有助于确定用户故事是否已被充分理解并为开发团队开始工作做好准备。独立 - 用户故事不应该依赖于另一个用户故事，因此用户故事可以按任何顺序开发。可协商 - 用户故事的详细信息通过产品负责人和开发团队之间的口头对话进行协商。有价值 - 用户故事应该为用户/客户带来所需的价值。估计 - 开发团队应该很好地理解用户故事来估计它。小 - 用户故事应足够小，以适应迭代。可测试 - 应为用户故事编写正确的验收标准，以便进行验证。什么不是用户故事？让我们对自己说实话：用户故事不能通过其定义成为“技术用户故事”，因为在这种情况下它不会给用户/客户带来直接价值。不过，许多团队喜欢在需要执行代码重构等技术任务时创建用户故事。我建议将其他工作项用于此类任务，并与您的产品负责人就此类工作达成一致，以便了解为何需要这样做。这同样涉及非功能性需求任务，界面设计任务，复杂的用户交互任务或错误。您可以自由地为这些任务创建其他工作项。例如，Constraint Story可用于表示非功能性需求。用户故事是捕获产品功能的绝佳技术，但我们没有义务将其用于所有目的。谁是用户？在编写用户故事之前，应该清楚地了解创建用户素材的用户是谁。有时它被新用户故事技术的团队所忽视，他们最终创建了具有不必要功能的软件。因此，做一个适当的用户研究，让你的所有用户类型或用户角色或角色写下来并描述。可以帮助您解决此问题的两种技术是用户角色建模和角色。谁负责撰写用户故事？通常，客户代表（例如产品负责人）负责用户故事。尽管如此，用户故事并不是从顶级到团队的规范，而是产品负责人和团队之间的协作技术。这就是为什么如果用户故事是协作编写的话会更好。一个很好的方法是做一个故事写作研讨会。细节在哪里？由于用户故事不是规范，因此详细信息以不同方式传达：3 C指南中的第二个“C”是Conversation。对话是敏捷最重要的方面之一。因此，大多数细节都是通过客户代表和开发团队之间的口头沟通来传达的。第三个“C”是确认。用户验收测试确认用户故事满足用户/客户的验收标准，并且它们用作正式的文档详细信息。BDD（行为驱动开发）是一种编写验收测试的好方法。如果需要，某些用户故事可能包含其他书面详细信息。你怎么知道用户故事何时完成？使用“完成定义”技术。简而言之，Done的定义是团队成员之间对工作完成意义的共同理解。完成的定义通常以活动清单的形式创建，其表明商定的价值（用户验收测试以满足用户验收标准）和质量（以满足质量标准）。团队有时会忽略最后一个，在迭代结束时，什么可以使用户故事不可能发送给客户。完成技术的定义有助于避免这种情况。完成定义的示例：完成时间：单元测试通过代码经过同行评审用户验收测试通过集成测试通过回归测试通过用户指南已更新如何开始定义产品范围？在项目开始时，我们需要定义产品的粗略范围，以便对其有全局视野。这可以通过Epics完成。史诗是一大块工作，有一个共同的目标。Epic可以被视为占位符，用于稍后创建的更详细的用户故事。Epic通常需要多次迭代才能完成。什么是组织用户故事的最佳方式？使用由Jeff Patton发明的故事映射技术 (User story Mapping)。故事映射代表了一种自上而下的需求组织方法，也是确定优先级和规划的好方法。对BABOK®Guidev2的敏捷扩展指出：“故事映射提供了解决方案支持的活动序列的视觉和物理视图。它使用二维网格结构来显示产品在水平维度上的关键方面的顺序和分组，详细信息和优先级关于垂直维度的故事。故事映射是一种分解技术，它允许从端到端视图开始逐步理解解决方案，并深入到详细的用户故事。故事映射示例 (Visual Paradigm User Story Mapping)：https://www.youtube.com/watch…

3C’s = 卡 (Card)，会话 Conversation)，确认 (Confirmation)”;这个模板（来自Ron Jeffries）捕获了用户故事的组成部分：第一个C (Card) 是原始形式的用户故事，即卡片。用户故事手动写在索引“卡”上，以保持简洁。标准格式有3个基本组件：作为[用户类型]，我想/需要[目标]，以便我可以完成[理由/商业价值]。该卡只是一个占位符。第二个C (Conversion) 是对话。对话有必要获得有关卡的更多详细信息。该对话促进了敏捷团队之间的增量和持续协作，以便围绕问题和潜在解决方案建立共同理解。第三个C (Confirmation) 是确认。确认是接受标准，它捕获基本要求并将其转换为测试标准，以便我们知道何时成功交付了用户故事。1.卡 (Card)用户故事应该能够放在3“x5”便条卡上，有效地捕获最重要的信息。虽然这个“C”有时指的是实际的记录卡，但我们的意思是它指的是用户故事的最佳尺寸。正如杰弗里斯所写，卡片不应包含有关要求的所有信息，而是足以用于规划识别要求并提醒项目团队的故事。每个用户故事都应遵循以下标准化格式：“作为[特定用户]，我想[执行此操作]，以便[我可以实现此目标。]” 专注于收集每种用户类型的用户故事，以创建一组最具代表性的用户故事。用户故事应尽可能直接由用户编写。但是，根据项目类型和组织细节，用户故事也可以由项目团队成员和/或产品所有者编写。可以使用常见的启发技术（如访谈，问卷调查，观察和用户故事撰写研讨会）收集完整的用户故事集，以确保用户故事准确反映用户需求。2.对话 (Conversation)在用户故事即将被放入sprint之前，产品所有者应该与客户讨论他们的用户故事（或与其业务领域相关的用户故事）以进行详细说明和验证。与用户的协商对话是必要的，因为用户故事可能难以解释，可能需要一些背景知识来实现，或者自编写故事以来需求可能已经改变。对话代表项目团队与产品所有者或其他利益相关者和商业中小企业之间的讨论。在这些对话中，产品所有者告知利益相关者正在发生的事情，利益相关者或团队成员交换想法，意见和感受。对话应在整个项目生命周期中进行。虽然我们主要讨论口头讨论，但对话还可以包括通过电子邮件，内部聊天程序或通过需求管理和业务分析工具（如Enfocus Requirements Suite™）进行的电子通信。3.确认 (Confirmation)用户故事的最后一个组成部分是用于确认用户故事是否已正确实施并成功交付的验收标准。必须在开发开始之前定义验收标准，以确定每个用户故事何时完成并按用户的意图工作。验收标准可用于演示用户故事的界限，并且通常在产品所有者，项目团队和用户之间进行对话时进行考虑。建议用户是编写验收标准的用户，因为每个用户故事都是从用户的角度编写的 - 因此确保用户故事完成和满意的测试也应由用户编写。最好是这样定义验收标准的细节正是时候用户故事被放置在一个冲刺前。提供太多细节是浪费和耗时的，因为如果用户故事发生变化，则还需要更改细节。但是，提供太少的细节通常会导致重大的返工，并迫使开发人员做出错误的假设。它们应该被写成勉强够用; 也就是说，用户故事应该只包含启用开发所需的绝对最小信息量，并允许测试以合理的效率进行。这样做的理由是最大限度地减少在不增加最终产品价值的任何事情上花费的时间。敏捷软件开发文章什么是敏捷软件开发？什么是用户故事？什么是用户故事映射？用户故事与敏捷软件开发的使用案例

短跑运行在短在一段有限的时间距离。它被用于许多包含跑步的运动中，通常用作快速到达目标或目标的方式，或避免或抓住对手。为什么短冲刺？你应该有一个足够短的迭代，以保持团队的注意力，但足够长，以提供有意义的工作增量。在Scrum的指南限制了冲刺长度为一个月。失败快 - 太小导致不会失败短Sprint的优势来自于尝试某些事情（快速失败），获得快速反馈，然后快速检查和调整的策略。在存在高度不确定性的情况下，开始研究产品通常会更便宜，了解我们是否做出了一个好的决定，如果没有，在花更多的钱之前快速杀死它。快速失败：为什么短跑长度必须短？类似于Kaizen（改善）的想法，它是日语中的“改进”。在商业领域，改善是指不断改进所有职能并让所有员工从首席执行官到装配线工人的活动。分析这些变化的结果并重新开始微调。以这种方式，可以提高正在执行的任务的生产率或质量。一点一点地做出微小改变远比一次性解决所有问题更有效。我们的想法是让变更变得如此简单，以至于在实施过程中很难失败。首先，我们养成了改变的习惯。然后我们添加新的更改或稍微改变更改的里程碑，以便我们可以逐步改进。一个接一个地应用调整很重要。这个想法是为了避免选择应用和何时应用的复杂性。这样我们就能够分析每个小改进的结果。如果我们同时申请几个，我们将不知道哪个有效，哪个没有。或者一个人的效果是否已经抵消了另一个人。Scrum - 持续改进Scrum框架基于经验主义，它依赖于透明度，检查和适应性。在Scrum事件和工件协助定期检查和调整，导致持续改进。在sprint计划期间，scrum团队会检查产品积压并调整sprint目标，预测和sprint积压。在每日Scrum期间，开发团队会检查sprint目标的进度并调整sprint backlog。在冲刺审查期间，Scrum团队和利益相关者检查增量，冲刺和产品积压并调整产品积压。Scrum - 持续改进最后，sprint回顾展是scrum团队改进的正式活动，scrum团队通过实施可行的，可持续的改进来检查围绕人员，关系，流程和工具的冲刺。

(Source: Scrum.org)Scrum Developer是一个T形人一个T-型的人有两种特性的，因此使用字母“T”来形容他们。字母“T”的垂直笔划描述了他们所具有的特定领域的深层技能，而水平笔划描述了跨多个学科的协作处置。它由两件事组成，即对其他人的学科的同理心和热情，以至于他们可能真正开始练习它们。只熟悉某个特定领域的人称为I形人。下图解释了I形人和T形人之间的差异。T-形Scrum开发人员从上图中可以看出，Scrum开发团队的测试工程师需要具备的技能不仅仅是“点击测试”，他们应该有_一些_编程，分析，设计，开发，技能等。分析师应该有技能超越“分析”，他们有望进行_一些_编程，测试工程，设计，营销，技能等。设计师有望拥有“设计”技能，预计会有一些编程，测试和分析技能。嗯，你明白了。因此，我们认为分析师不会比程序员和程序员更高的位置，而不是测试工程师。在像软件开发这样的创意产业中，在开发团队中拥有T形人员非常重要。James Shanteau做了一项研究，发现专家（I-Shaped people）的判断既不符合该领域专家的判断，也不符合内部一致性。在开发团队中拥有许多T形人员可提供创意行业急需的广泛见解。IDEO - 着名设计公司的首席执行官蒂姆·布朗表示，拥有一个T形人很重要，因为他们能够建立在其他人的想法基础之上，并不会立即抛弃你自己的竞争理念。T形人从另一个角度想象这个问题 - 站在别人的鞋子里。T-形人也非常热衷于其他人的学科，以至于他们可能真正开始练习它们。T-形人不是一个真正的新概念，在文艺复兴时代，有很多T形人，仅举几例着名人物：莱昂纳多达芬奇 - 画家，雕塑家，建筑师，音乐家，数学家，工程师，发明家，解剖学家，地质学家，制图师，植物学家和作家。Galileo Galilei - 物理学家，数学家，工程师，天文学家和哲学家。Nicolaus Copernicus - 数学家，天文学家，医师，经典学者，翻译，州长，外交官和经济学家。T-形人不是通才，他们在一个领域拥有深厚的技能，但也有其他技能可以帮助他们与其他开发团队成员合作。例如，伽利略和哥白尼是众所周知的天文学家。哇，你可能认为开发人员拥有的技能太多，这些开发人员是否存在？是的，他们存在，但不幸的是，他们中的大多数人已经很高兴与一家好公司合作。而且由于软件正在吞噬世界，软件的作用越来越重要，我们需要提高游戏的门槛。

第一个极限编程项目于1996年3月6日启动。极限编程是几种流行的敏捷过程之一。事实证明，它已在全球各种规模和行业的许多公司中取得了巨大成功。极限编程是成功的，因为它强调客户满意度。而不是在将来某个日期提供您可能想要的所有内容，而不是在您需要时提供您需要的软件。极限编程使您的开发人员能够自信地响应不断变化的客户需求，甚至在生命周期的后期。极限编程强调团队合作。经理，客户和开发人员都是协作团队中的平等合作伙伴。极限编程实现了一个简单而有效的环境，使团队能够高效地工作。团队围绕问题进行自我组织，以尽可能高效地解决问题。 极限编程以五种基本方式改进软件项目; 沟通，简单，反馈，尊重和勇气。极端程序员经常与他们的客户和程序员沟通。他们保持设计简洁。他们通过从第一天开始测试他们的软件获得反馈。他们尽早将系统交付给客户，并按照建议实施变更。每一个小小的成功都会加深对每个团队成员独特贡献的尊重。有了这个基础，Extreme程序员就能够勇敢地响应不断变化的需求和技术。极限编程最令人惊讶的方面是它的简单规则。极限编程很像一个曲线锯拼图。有很多小件。单独的碎片敏捷流程图毫无意义，但当结合在一起时，可以看到完整的画面。规则可能看起来很尴尬，一开始可能甚至天真，但都是基于合理的价值观 和原则。我们的规则设定了团队成员之间的期望，但不是最终目标。您将意识到这些规则定义了一个促进团队协作和授权的环境，这是您的目标。一旦取得成效，即使规则发生变化以满足公司的特定需求，团队合作仍将继续。这个 流程图 展示了极限编程规则如何协同工作。客户喜欢成为软件过程中的合作伙伴，开发人员无论经验水平如何都积极贡献，管理人员专注于沟通和关系。非生产性活动已被削减，以减少所涉及的每个人的成本和挫败感。从这里开始，按照小按钮的轨迹，参加极限编程

(Source: XP - Iteration Planning)在每次迭代开始时调用迭代计划会议，以生成该迭代的编程任务计划。每次迭代为1到3周。 客户从发布计划中按照对客户最有价值的顺序选择用户故事进行此次迭代。还选择了要修复的失败验收测试。客户选择的用户故事的估计总计达到上次迭代的项目速度。用户故事和失败的测试被分解为支持它们的编程任务。任务记录在索引卡上，如用户故事。虽然用户故事是客户的语言，但任务是使用开发人员的语言。可以删除重复的任务。这些任务卡将是迭代的详细计划。开发人员注册执行任务，然后估计他们自己的任务需要多长时间才能完成。对于接受任务的开发人员而言，重要的是估计完成任务所需的时间。人们不可互换，而且要完成任务的人必须估计需要多长时间。每项任务应估计为1,2或3（如果需要，添加1/2）持续时间的理想编程天数。如果没有干扰，理想的编程日期是完成任务需要多长时间。短于1天的任务可以组合在一起。超过3天的任务应该进一步细分。现在再次使用项目速度来确定迭代是否超过预定。在任务的理想编程天中总计时间估计值，这不得超过上一次迭代的项目速度。如果迭代次数太多，那么客户必须选择要推迟的用户故事，直到稍后的迭代（也叫雪耕 - Snow Plowing）。如果迭代太少，则可以接受另一个故事。任务天的速度（迭代计划）会覆盖故事周的速度（发布计划）因为它更准确。看到用户故事被雪覆盖通常令人震惊。不要惊慌。记住单元测试和重构的重要性。任何一个领域的债务都会让你失望。在安排之前避免添加任何功能。只需添加您今天所需的内容。添加额外的东西会减慢你的速度。不要试图改变你的任务和故事估计。规划过程依赖于一致估计的冷现实，将它们勉强降低会产生更多问题。密切关注您的项目速度和积雪。您可能需要重新估算所有故事并每三到五次迭代重新协商发布计划，这是正常的。只要您始终首先实施最有价值的故事，您将始终尽可能为您的客户和管理层做好准备。迭代开发风格可以为您的开发过程增加灵活性。通过不比当前迭代更远地规划特定的编程任务来尝试及时规划。

编写用户故事后，您可以使用发布计划会议来创建发布计划。发布计划指定 将为每个系统版本实现哪些用户故事以及这些版本的日期。这给出了一组用户故事供客户在迭代计划会议期间进行选择，以便在下一次迭代期间实施。然后将这些选定的故事翻译成单独的编程任务，以在迭代期间实现以完成故事。在迭代期间故事也被转化为验收测试。这些验收测试在此迭代期间运行，并且随后的迭代将验证故事何时正确完成并继续正常工作。当项目速度 在几次迭代中发生显着变化时，或者在任何情况下，在几次迭代之后继续进行，并安排与客户的发布计划会议并创建新的发布计划。发布计划以前称为承诺计划。更改名称以更准确地描述其目的，并与迭代计划更加一致。

(Source: User Stories)用户故事与用例具有相同的用途，但不尽相同。它们用于为发布计划会议创建时间估计。它们也用于代替大型需求文档。用户故事由客户编写，作为系统需要为他们执行的操作。它们与使用场景类似，不同之处在于它们不限于描述用户界面。它们的格式为客户在客户术语中编写的大约三个句子，没有技术语法。用户故事也推动了验收测试的创建。 必须创建一个或多个自动验收测试以验证用户故事是否已正确实施。用户故事最大的误解之一是它们与传统的需求规范有何不同。最大的区别在于细节层次。用户故事应该只提供足够的细节，以便对故事实施的时间进行合理的低风险估计。在实施故事的时候，开发人员将转到客户并获得面对面的要求的详细描述。 极限编程流程图开发人员估计故事可能需要多长时间才能实现。每个故事将在“理想的开发时间”中得到1,2或3周的估计。这个理想的开发时间是在代码中实现故事所需的时间，如果没有干扰，没有其他任务，并且您确切知道该做什么。超过3周意味着您需要进一步打破故事。不到一周的时间，你的水平太过细致，结合了一些故事。大约80个用户故事加上或减去20是在发布计划期间创建发布计划的完美数字。故事和需求文档之间的另一个区别是关注用户需求。您应该尝试避免特定技术，数据库布局和算法的详细信息。您应该尝试将故事集中在用户需求和优势上，而不是指定GUI布局。

“水桶估计系统”是一种用中小型人群估计大量物品的方法，并且可以快速完成。水桶估计系统具有以下特性，使其特别适用于敏捷环境：它 很快！可以在一小时内估算几百件物品。这是 合作的。一组中的每个人大致平等地参与。它提供 相对结果而不是绝对估计（点数与小时数）。结果无法追溯到个人，因此它鼓励 小组负责。与 团队合作估算工作量或与 利益相关者合作估算价值。水桶估计系统流程水桶估计系统的估算工作如下：按照下图设置物理环境。确保所有要估算的项目都写在卡片上。从集合中随机选择一个项目。把它读给小组。将它放在“8”桶中。这个项目是我们的第一个参考项目。从集合中随机选择另一个项目。把它读给小组。该小组讨论了其在规模上的相对位置。一旦 共识已经达成，把该项目在适当的桶中。随机选择第三个项目，经过讨论并达成共识后，将其放入适当的桶中。如果随机物品已经明显地将刻度朝向一端或另一端倾斜，则重新缩放物品（例如，如果第一物品实际上非常小并且应该在“1”桶中）。分而治之。将所有剩余项目均等地分配给所有参与者。每个参与者将项目放在规模上而不与其他参与者讨论。如果一个人有一个他们真正不理解的项目，那么该项目可以提供给其他人。完整性检查！每个人都悄悄地审查规模上的项目。如果参与者发现他们认为不合适的项目，欢迎他们提请小组注意。然后该小组讨论它，直到达成共识并将其置于其中一个桶中。在卡片上写下桶号，以便记录估算值。需要考虑的一些要点：多个项目可以在同一个存储桶中。项目不能放在“桶”之间以表示更精确的估计。如果项目的分布倾斜到比例的任何一端，那么在完整性检查步骤期间，该组还应该讨论项目是否可以并且应该在比例尺上更均匀地展开。如果是这样，那么该小组就会集体进行。辅导员应注意确保在“健全检查”步骤之前没有人移动已经放置的物品。参与者之间的项目划分不需要完全相同 - 不要担心“处理”项目。相反，只是粗略地划分它们。如果“分而治之”阶段有一两个人通过他们的项目工作非常缓慢，建议他们与已经完成的人分享剩余的项目是可以接受的。个人完全弃权是不可接受的。如果有人想要投弃权票，他们应该被告知这意味着他们将不会在估计中有任何未来的发言权。在“分而治之”阶段，保持绝对沉默至关重要。特别是，不应对项目进行双边讨论。这是为了保护尽可能多地放置物品的个人的匿名性。水桶估计系统是一种很好的替代估算方法，可以尝试代替规划扑克。它比规划扑克快得多，但仍能获得合理的结果。

根据INVEST原则，对用户故事的要求是它必须“足够小”或具有合适的大小。用户故事应该足够小，可以在冲刺中完成6-10个。当然这也取决于开发团队的速度。为了原则上实现这一目标，必须相应地分割大型故事。在下文中，我想向您介绍Mike Cohn的简单快速的SPIDR方法。他总结了五种技术，几乎每个大型用户故事都可以分为几种。钉鞋Spike是敏捷软件开发中使用的术语。尖峰是功能的小型原型实现，通常用于新技术的评估和可行性。该方法涉及调查和建立知识。如果其他SPIDR方法效果不佳，则应该使用它。借助这些新获得的知识，可以更好地理解一些故事，并可能更容易地分裂。然而，该方法相对抽象，因此比其余方法更难应用。路径如果用户故事中有多个可能的备用路径，则一个选项是从这些路径中的某些路径创建单独的用户故事。为每条路径写一个故事并不是绝对必要的，只要它有意义。例如，让我们看一个用户想要在线商店购买的用户故事。现在有两种可能的途径：使用信用卡付款或使用Paypal付款。理论上，信用卡付款可以进一步细分，但你需要权衡每种类型的信用卡是否有自己的故事。然而，支付购买的首要任务分为上述两种备选方案。因此，新创建的故事更小，更容易估计。接口在该上下文中的接口可以是例如不同的设备或设备类型，例如由iOS或Android供电的智能电话。用户故事也可以根据这种多样性进行划分。让我们坚持使用不同操作系统的示例：例如，在项目中，可能存在仅与Android设备的使用相关的用户故事，或者专注于Web浏览器的其他用户故事。为了避免使故事过于庞大和全面，您应该问自己要开发哪些设备或接口。也许第一个开发结果应该只引用iOS设备，因为可能更大的目标组。数据当初始故事仅涉及相关数据的子范围时，可以使用另一种用于分割用户故事的技术。以一个旨在吸引游客到特定城市的网站为例。例如，如果它是以博物馆而闻名的城市，那么第一个故事可能包括该地区不同博物馆的信息。随后的故事可能包括穿越城市的各种旅游，以及另一项户外活动。规则业务规则或技术标准可能是另一个分裂因素。以在线购买电影票为例。通常存在约束，例如基于相应电影的业务要求，例如每个电子邮件地址最多五个票的在线购买限制。有了这个故事，可以想象开发团队省略了这个限制，允许每个访客购买尽可能多的门票。然后可以在第二次迭代步骤中添加限制。像这样的增量交付意味着初始故事不会立即完全实现，而是以几个较小的步骤提供。有时忽略技术规范或业务规则是有意义的，如果通过这样做，您可以更快地实现满足用户或客户的可呈现结果。可以在以后检索省略的故事。小用户故事 - 更容易实现用户故事分裂并不总是那么容易：许多初学者倾向于将他们的故事过于全面而且过于庞大。但是，当涉及到开发团队的改进，并最终实现故事时，很快就会发现必须制作更小的故事。在我之前关于写（好）用户故事的博文中，我坚持认为故事应该是“可估计的”和“小的”。如果您知道如何分割大型故事，则更有可能发生这种情况。正如编写用户故事一样，练习也是完美的。敏捷软件开发什么是敏捷软件开发？什么是用户故事？什么是用户故事映射？用户故事与敏捷软件开发的使用案例

在这篇文章中，我们将介绍如何编写好的用户故事以及应该包含哪些内容。用户故事代表一小部分功能，具有团队可以在冲刺中提供的业务价值。用户故事和传统需求文档之间的区别在于详细程度。需求文档往往包含大量文本并且非常详细，而用户故事主要基于会话。我们可以将用户故事的结构分解为：需要的简要说明在积压修饰和sprint计划期间发生的对话以巩固细节确认故事圆满完成的验收测试在编写用户故事时要记住的一个重点是，它们是从最终使用该产品的用户的角度编写的，因此在编写用户故事时我们必须清楚地识别用户是谁。如何写好用户故事根据经验，一个好的用户故事应该遵循INVEST的缩写：I ndependent - 用户故事不应该相互依赖，因此它们可以按任何顺序开发。N egotiable - 避免太多细节; 保持灵活性，以便团队可以调整实施的故事数量。V aluable - 故事应该为其用户提供一些价值。E stimable - 团队必须能够估计故事。S商城 - 用户故事应足够小，以适应冲刺; 大型故事很难估计和计划。T estable - 确保正在开发的内容可以得到充分验证和测试。用于编写用户故事的格式是什么？用户故事通常具有以下格式：作为<用户类型>，我想<feature>以便<benefit>。示例：作为 abc.com 的客户，我想要一个登录功能，以便我可以在线访问我的帐户详细信息。As a customer of abc.com, I want a login functionality so that I can access my account details online.如前所述，要特别注意产品的用户是谁，并避免“用户”的一般角色。如果你不知道谁是用户和客户，以及为什么他们会想要使用的产品，那么你应该没有写任何用户故事。叙述用户故事的第一部分是叙事。用2-3个句子来描述故事的意图。这只是意图的总结。对话用户故事最关键的方面是开发团队，客户，产品负责人和其他利益相关者之间应该不断进行的对话，以巩固用户故事的细节。验收标准验收标准代表满意的条件，这些条件被写为场景，通常采用Gherkin（Given，When，Then）格式。验收标准还提供故事的完成定义。谁应该写用户故事？在大多数情况下，用户故事由产品负责人或业务分析师编写，并在产品待办事项中进行优先级排序。但是，这并不是说只有产品负责人才能编写用户故事。实际上，任何团队成员都可以编写用户故事，但产品负责人有责任确保存在积压的用户故事并确定其优先级。重要的是，用户故事不应该被视为需求文档，在撰写时将被交给开发团队实施。用户故事应被视为鼓励产品负责人和开发团队之间进行对话的一种手段，因此应在产品待办事项修饰会话期间进行协作编写。让开发团队参与编写用户故事的一个优点是，如果存在任何技术限制，可以提前突出显示它们。测试人员可以特别增加构建有效验收标准的价值，并提前计划需要测试的内容和方法。用户故事的详细程度如何？用户故事关注客户价值。用户故事与其他形式的需求规范之间的基本区别在于详细程度。用户故事是正在进行的工作的隐喻，而不是对工作的完整描述。随着系统开发的进展，通过协作围绕用户故事进行充实的实际工作。如果描述变得过于冗长（超过索引卡上的描述），您应该重新访问用户故事。您可能想要包含太多细节。请记住，用户故事的目的是鼓励协作。它并不意味着记录工作的每个方面，因为传统的需求声明通常就是这种情况。此外，描述中的过多信息可能导致接受标准中缺少信息。在同意处理故事之前，团队必须了解验收标准。这些对于了解需要做什么以满足用户故事至关重要。接受标准应该足够详细，以定义用户故事何时满足，但不是那么详细，以至于无法进行协作。编写用户故事时常见的错误太正式或太多细节。 有良好意图的产品所有者经常尝试编写非常详细的用户故事。如果团队在迭代计划中看到一个看起来像IEEE需求文档的故事，他们通常会认为所有细节都在那里并且将跳过详细的对话。编写技术任务的用户故事。 敏捷的大部分功能来自于每次迭代结束时软件的工作增量。如果您的故事实际上只是技术任务，那么在每次迭代结束时，您通常不会使用工作软件，并且在优先级排序方面会失去灵活性。跳过对话。 在迭代计划之前，故事是故意模糊的。如果您跳过验收标准对话，则可能会向错误的方向移动，缺少边缘情况或忽略客户需求。敏捷软件开发什么是敏捷软件开发？什么是用户故事？什么是用户故事映射？用户故事与敏捷软件开发的使用案例

構建服務時可以使用許多敏捷方法，每種方法都有自己的一套工具和技術。本指南介紹了3種最流行的敏捷方法：Scrum看板Lean流行的敏捷方法解釋了ScrumScrum是最常用的敏捷方法。它允許高度結構化的模型具有明確定義的角色和職責。這對於正在轉向敏捷的傳統結構化組織尤其有用。在Scrum指南中了解有關Scrum功能的更多信息，由Scrum，Ken Schwaber和Jeff Sutherland的開發人員撰寫。看板 (Kanban)看板作為一種開發方法的靈感來自於生產系統，這些系統專注於減少浪費和提高質量，就像豐田創造的那樣。看板是一種可視化和改進當前工作實踐的方式，以便工作快速流經系統。快速，順暢的工作流程意味著您可以：快速，可預測地提供價值及早獲得反饋，了解您的產品或服務是否滿足用戶需求精益 (Lean)精益軟件開發，如看板，改編自豐田生產系統等精益生產原則。精益原則旨在幫助您的團隊專注於：減少浪費迅速交付學習和提高使用證據和數據做出決定使用多種敏捷方法您不必只使用一種方法，您可以從多種方法中選擇工具和技術來滿足您的團隊需求。每種方法都有自己的語言來描述基本的工具和技術，重要的是要理解：為什麼你選擇了一種工具或技術敏捷的目標找到您可以使用的其他敏捷方法。確定使用哪些方法Scrum如果您的團隊不熟悉敏捷工作，那麼Scrum是一個很好的起點。您的團隊通常會在以下情況下找到最有用的Scrum：建立新產品或服務增強現有功能在每個’sprint’中添加新功能（固定的時間段）當您運行實時服務並有緊急請求時，您可能會發現sprint約束並希望轉向基於流程的方法，如看板。但您仍然可以繼續使用與Scrum相關的許多活動，例如每日站立會議，回顧會議和定期審查進度。看板 (Kanban)看板幫助您的團隊：找到流程中的瓶頸控制你正在做的工作量根據實際交付預測您的輸出當您的團隊需要快速響應不斷變化的優先級時，它尤其有用。精益 (Lean)精益使您的團隊能夠盡快專注於學習。當您的團隊首次發現用戶的需求並決定如何滿足這些需求時，精益工具和技術尤其有用。更多推荐的Scrum文章如何使用Scrum Board进行敏捷开发？Scrum boards (also known as scrum task boards) are tools that help teams visualize backlogs of sprint work items. The board can use many manual (whiteboard and sticker) and virtual forms (software tools), but it can perform the same function regardless of appearance. (Scrum 板 (也称为 scrum 任务板) 是一种工具, 可帮助团队使冲刺积压工作项可见。该板可以采用许多手动 (即白板和贴纸) 和虚拟表单 (即软件工具), 但无论外观如何, 它都能执行相同的功能。)如何为Scrum项目撰写产品愿景？模板和示例The product vision is not part of the Scrum process. Why is it so important? Schwaber believes that vision is two necessary illusions, starting the Scrum project by stating: “The smallest plan starts the vision of the necessary Scrum project composition and product backlog” (产品愿景不是Scrum流程的一部分，为什么它如此重要？Schwaber的认为，愿景是两个必需的一个假象，开始Scrum项目，通过陈述道：“ 最小的计划开始了必要的Scrum项目组成的愿景和产品Backlog ”)Scrum: 什么是产品Backlog中的DEEP？Product Backlog projects have described attributes (D appropriate details), Story points (E stimated), order (P rioritized), and they are constantly added, deleted and updated (E merged) in the backlog to reflect the backlog of teams in a timely and appropriate manner. (产品Backlog项目具有描述的属性（D适当的详细说明），Story points（E stimated），order（P rioritized），并且它们在积压中不断被添加，删除和更新（E合并）以反映到对以及时和恰当的方式积压团队的积压。)如何为用户故事撰写SMART和INVEST目标?SMART is a set of standards for creating goals such as Sprint goals. While INVEST reminds you of the characteristics of high-quality product backlog (PBI) (or user stories) typically written in user story format. (SMART是一套创建目标（如Sprint目标）的标准。虽然invest会提醒您高质量产品积压工作（PBI）（或用户案例）的特征，通常以用户案例格式编写。)Sprint Increment (冲刺增量) vs Potential Shippable Product (潜在可发货产品) vs MVP vs MMPScrum requires the team to build an incremental function in each sprint, and the increment must be deliverable, because the product owner may decide to release it at the end of the sprint. This article explains and clarify the related key concepts of: sprint increment, potential shippable product MVP and MMP. (Scrum要求团队在每个sprint中构建一个增量的功能，并且增量必须是可以发送的，因为产品负责人可能决定在sprint结束时发布它。 This article explains and clarify the related key concepts of: sprint increment, potential shippable product mvp and mmp。)什么As / I want / so that 用户故事模板？The most common technology is the role-feature-reason template, which is used by teams and product owners to start writing user stories in three parts: (1) As a (role); (2) I want (feature); So that (reason). (最常见的技术是角色 - 特征 - 理由模板，用于团队和产品所有者开始编写用户故事，分为三个部分：（1）作为 As a（角色）; （2）I What 我想要（特征）; So that（理由）。)Scrum中的Burndown图表是什么？Burndown chart is a graphical representation of the remaining work and time. It is usually used in agile software development methods, such as Scrum. However, burning charts can be applied to any project that contains measurable progress over a period of time. (Burndown chart 是剩余工作与时间的图形表示。它通常用于敏捷软件开发方法，如Scrum。但是，刻录图表可以应用于任何包含一段时间内可衡量进展的项目。)Scrum中的Sprint目标是什么？Sprint goals show the expected results of iterations that provide shared goals for the team, which must be defined before the team starts Sprint in order to focus on achieving this goal. This ensures that everyone is on the same page. After choosing goals, the team must strive to implement them. (Sprint目标显示了为团队提供共享目标的迭代的期望结果，必须在团队启动Sprint之前定义该目标，以便专注于实现此目标。这可确保每个人都在同一页面中。选择目标后，团队必须努力实施目标。)如何使用MoSCoW方法确定产品积压的优先次序?MoSCoW (also known as MoSCoW prioritization or MoSCoW analysis) is a prioritization technology designed to reach a consensus with stakeholders on its importance for the delivery of each requirement. (MoSCoW方法（也称为MoSCoW优先级划分或MoSCoW分析）是一种优先级技术，旨在与利益相关方就其对每项要求的交付的重要性达成共识。)Sprint Backlog在Scrum中是什么意义？Sprint Backlog is a set of product backlog projects selected for the current Sprint and a plan to provide product increments for achieving Sprint goals. (Sprint Backlog是为当前Sprint选择的一组产品Backlog项目，以及为实现Sprint目标而提供产品增量的计划。) ...

“持续关注卓越的技术和良好的设计提高了灵活性。” “Continuous attention to technical excellence and good design enhances agility.”下一句话很有趣。许多人可能把敏捷软件项目团队想象成一群“牛仔”，他们只是聚在一起，敲出代码，而没有太多的设计计划，也没有任何编码标准。通常情况并非如此。敏捷认识到需要以正确的方式做事情，以避免以后不必要的返工。然而，敏捷的方法不应该导致产品过度设计或“镀金”。在敏捷环境中，你经常听到的一条评论是“仅仅是够好 (“just barely good enough.)”的概念。换句话说，这项工作应该在完整性和质量方面达到一个成功的水平，以充分实现它预期的目的，而不是更多。超过“勉强够好”的水平被认为是浪费。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“简单——最大化未完成工作量的艺术至关重要。” “Simplicity—the art of maximizing the amountof work not done—is essential.”“简单——最大化未完成工作量的艺术至关重要。”这个原则强调简单。有多少次我们看到项目失去了控制，因为需求变得太复杂，很难实施，并且需求变得过度设计，试图满足你能想象到的每一个可能的需求？这也与“仅仅是够好 (just barely good enough)”的概念有关 —— 不要过度设计；尽可能简单。在某些情况下，从一些非常简单的东西开始，看看它是否满足需要，然后在以后仅在必要时扩展功能可能是有意义的。敏捷的另一个概念是“最小可行产品 (minimum viable product)”，它定义了产品在市场上必须可行的功能特性的最小集合。一般来说，采用增量方法从简单的东西开始，然后在必要时扩展它，而不是从可能对需求造成过度破坏的过于复杂的东西开始，会更有效。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“最佳架构、需求和设计来自自组织团队。” “The best architectures, requirements, anddesigns emerge from self-organizing teams.”敏捷很大程度上基于自组织团队的思想，但这需要一些解释。有时，开发人员使用“自组织”的概念作为无政府状态的借口，但这并不是他们想要的。其目的是，如果你在一个跨职能的团队中有合适的人，并且团队被授权以协作的方式集体使用团队中的所有技能，那么它通常会比一个单独的人能够提供更好的结果。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“团队定期反思如何提高效率，然后相应地调整和调整其行为。” “At regular intervals, the team reflectson how to become more effective, then tunes and adjusts its behavior accordingly.”敏捷在两个方面具有适应性：设计适应不确定和不断变化的用户需求，它可以从需求的高级视图开始，并在项目启动后逐步细化需求。过程本身是适应性的，而不是高度规定性的。敏捷很大程度上建立在持续改进的基础上，利用短时间间隔来重新判断什么是有效的，什么是无效的，并在必要时采取快速的纠正措施。在Scrum中，这称为回顾，它发生在每个冲刺的末尾。随着项目的进展，团队将根据需要不断改进和调整敏捷过程。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“工作软件是进度的主要衡量标准。” “Working software is the primary measure of progress.”衡量软件开发项目的进展可能是困难和有问题的。传统的方法是将一个项目分解为任务，并跟踪这些任务的完成百分比，以此来衡量进度；但是，这可能会产生很大的误导，因为通常任务列表不完整，并且完成水平通常需要一些主观判断，这很难做出，而且往往不准确。测试是这方面的另一个因素，在过去，整个开发过程和测试过程可能是连续的。结果是，即使软件的开发看起来是完整的，但在测试和验证它是完整的之前，您不知道它到底有多完整。敏捷方法强调在开发软件时更同时地进行测试。敏捷中有一个概念叫做“完成的定义”，你会经常听到。团队应该清楚地定义“完成”的含义，这通常意味着软件已经过测试并被用户接受。在其他环境中，done的定义可能会更加模糊，并受到解释的影响。如果您没有明确定义“完成”，则任何对完成百分比的估计都可能是可疑的。更准确的进度度量方法是将一个软件项目分解为多个功能块，其中每个软件块都有一个明确的“完成”定义，并且可以向用户演示以获得反馈和接受。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“经常交付工作软件，从几周到几个月，优先选择较短的时间范围。”下一个原则强调使用迭代方法将项目分解为非常小的增量，称为冲刺或迭代，通常在两到四周的范围内。这很有道理的原因有两个：所有敏捷开发过程（如scrum）都基于持续改进。我们希望团队采用一种经验的方法 (empirical approach) 来了解随着项目的进展，哪些是可行的，哪些是不可行的，并在必要时进行调整，而不是采用一个永不改变的严格定义的过程 (defined process)。如果将项目分解为很短的增量 (increments)，并且在每个增量结束时进行学习，那么学习和持续改进可以更快地发生。一个流行的敏捷口头禅是:“及早失败，经常失败”。 “Fail early, fail often.”换句话说，在许多情况下，最好快速尝试一些东西，从中学习并做出调整，而不是花费所有可能需要的时间来尝试设计一种第一次毫无效果的方法。人们工作效率更高，只需在短时间内完成任务。如果做得正确，团队会发展出一种节奏和节奏，这种节奏和节奏对于快速而有效地产生确定的工作量增量非常有效，就像制造装配线一样。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“在整個專案過程中, 業務人員和開發人員必須每天一起工作。” Business People and Developers MustWork Together下一個原則強調專案團隊和業務贊助者之間的夥伴關係。這與敏捷宣言中 “合作而不是合同 (collaboration over contracts)” 的價值非常一致。為了落實這一原則, 業務贊助者 (business sponsors) 和專案團隊都需要對專案的順利完成承擔共同責任。這就需要業務贊助者的參與程度遠遠高於許多傳統專案中的常見水準, 在這些專案中, 專案的實施幾乎可能完全委託給專案團隊。當然, 參與的程度應適合專案的性質, 企業主辦人的參與方式可能因情況而異。例如, scrum 有一個名為 “產品擁有者 (Product Owner)” 的角色 (Role), 它為專案提供日常業務方向, 但方向可能並不局限于此。在一個大型的企業級專案中, 可能還有其他一些利益攸關方者 (other stakeholders) 需要提供投入, 需要以某種方式參與。設計一種讓合適的人在合適的時間參與進來的方法, 對於專案的成功非常重要。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“围绕有动机的个人构建项目。为他们提供所需的环境和支持，并相信他们能够完成工作。” “Build projects around motivated individuals. Give them the environment and support they> need, and trust them to get the job done.”下一个原则强调了在项目中适当激励个人的重要性。在过去，有些项目经理经常使用高压、指挥和控制策略来迫使项目团队更快地交付结果。在我们的职业生涯中，很多人都参与过“死亡行军 (Deatch March)”项目，在这个项目中，人们被赋予完成某件事情的绝对期限，如果有必要的话，他们必须在晚上和周末工作。当你处在一个需要高度创造力和创新的环境中时，这种方法就不能很好地工作。敏捷的哲学是建立在项目人员的高度授权和个人主动性的基础上的。敏捷团队没有被明确地告知该做什么，也没有被强制去做以满足最后期限的要求，而是被赋予了一般的指导，并期望自己能够确定如何最有效和高效地完成它。使这种方法发挥作用需要一种以人为本的领导风格。然而，这并不意味着不需要任何领导。一个敏捷的项目经理需要调整他或她的领导风格来适应这种情况，这通常取决于几个因素，包括项目的性质、团队的成熟度和经验水平。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“向项目团队传递信息的最有效方法是面对面交谈。” “The most efficient and effective method of conveying information to and within a project team is face-to-face conversation.”这原则强调面对面的交谈。这是另一种说法，你不能把它当作绝对的，而是把它当作相对的。分布式团队 (distributed team) 并不总是能够进行面对面的交流，但如果可能的话，这当然是可取的。这一声明也不意味着唯一的交流形式是直接的面对面的交流。它是对瀑布式项目历史的一种反应，瀑布式项目严重依赖文档化的需求作为一种沟通方式。有许多方法可以以各种形式交流信息，您需要选择最佳组合来确定给定的情况。正确的组合将取决于许多因素，包括项目的范围和复杂性以及项目团队的分布。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“敏捷过程促进可持续发展。赞助商、开发人员和用户应该能够独立地保持恒定的速度。” Promote Sustainable Development敏捷的许多基础来自精益制造和全面质量管理（TQM）。许多年前，在一个制造环境中，公司了解到，像血汗工厂这样的制造工厂，强迫工人在恶劣条件下加班，通常不会产生高质量的产品。在敏捷环境中，同样的事情尤其如此，因为工作的成功如此关键地依赖于团队的创造力和动力。在这种情况下，更重要的是要创造一个长期可持续工作的环境。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

“欢迎不断变化的需求，即使是在开发后期。敏捷流程利用变化来获得客户的竞争优势。” “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”下一个原则强调创造一个期望和欢迎变化的环境，而不是严格控制和限制；当然，这并不意味着项目是完全不受控制的。基于与客户的合作关系，有很多方法可以有效地和协作地管理变更。重要的是，项目团队和客户应该事先就如何管理变更达成共识。更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

这四个价值陈述构成了敏捷宣言的基础。敏捷宣言中的原则扩展了价值, 并提供了更多细节。同样, 与值语句一样, 这些语句也应被视为相对偏好, 而不是绝对偏好。这些原则概述如下, 并在以下各节中进行更详细的讨论:我们的首要任务是通过早期和持续交付有价值的软件来满足客户。欢迎不断变化的要求, 即使是在开发后期。敏捷流程利用变化来获得客户的竞争优势。经常交付工作软件, 从几周到几个月不等, 优先考虑较短的时间刻度。在整个项目过程中, 业务人员和开发人员必须每天一起工作。围绕有积极性的个人建立项目。给他们所需的环境和支持, 相信他们能完成任务。向项目小组和在项目小组内传达信息的最有效率和效力的方法是面对面的对话。工作软件是衡量进展的主要标准。敏捷进程促进可持续发展。赞助商、开发者和用户应该能够无限期地保持不变的步伐。持续关注卓越的技术和良好的设计可提高敏捷性。简单性–最大限度地增加未完成的工作量的艺术–是必不可少的。最好的架构、要求和设计来自自组织团队。团队定期反思如何变得更加有效, 然后相应地调整和调整其行为。更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

早期和持续交付有价值的软件“我们的首要任务是通过及早持续交付有价值的软件来满足客户的需求。”“Our highest priority is to satisfy the customer through early and> continuous delivery of valuable software.”第一个原则强调“及早和持续地交付有价值的软件”。在敏捷之前的许多传统计划驱动的项目中，最终用户客户直到项目的最终用户验收测试阶段才看到任何东西，到那时，进行任何可能需要的更改都是非常困难和昂贵的。强调软件的早期交付可以实现两个主要目标：1。它为客户提供了一个在开发周期早期看到软件的机会，并提供反馈和输入，以便能够快速、轻松地进行更正。2。工作软件是一个很好的进度度量。从实际完成、测试和交付到用户满意程度的增量软件功能方面衡量进展要准确和有效得多，而不是试图衡量未完成的大型开发项目的完成百分比。在不将大型软件开发项目分解为多个部分的情况下，准确地测量整个软件开发项目的进度是非常困难的。这可能是一个非常主观的判断和一些猜测。将工作分解为明确定义的“完成”标准的明确定义的部分，提供了一种更真实和客观的方法来衡量进展。更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

用户故事的目标不仅是记录需求，还要提供客户在生产中使用的工作软件。用户故事提供了一种机制，用于记录客户和开发人员之间关于软件功能的讨论。定义“用户故事代表卡中的客户要求，导致对话和确认。” 〜罗恩杰弗里斯模板以下是用于定义用户故事和验收标准的众所周知的模板。价值陈述：作为（用户角色），我想（活动），以便（业务价值）接受标准：给定（上下文），何时（执行行动），然后（可观察的后果）一般准则以下是编写用户故事时要考虑的一些通用准则：用户故事有三个方面：卡片，对话和确认（Ron Jeffries 2001）用户故事应表示对用户或系统所有者有价值的功能。用户故事应描述单个功能。用户故事应该有一个注释部分，其中记录了有关用户故事详细信息的对话。用户故事应该在故事点中具有估计（成本），其表示大小和复杂性。用户故事应根据其对客户的价值进行优先排序。良好用户故事的属性（INVEST）Mike Cohn在他的“用户故事应用”一书中指出了一个好的用户故事的六个基本属性。这些是：独立的（I）用户故事应该不依赖于其他用户故事。用户故事应该是自包含的。用户故事应按任何顺序完成和发布。当发生依赖关系时，应该以不同的方式组合或拆分用户故事。可面议（N）用户故事不应该是合同义务，因为它们是可以协商的。用户故事应该是客户，开发人员和测试人员之间的协作谈判。有价值的（V）用户故事应该对软件的用户或所有者有价值。用户故事不仅仅对开发人员有价值。用户故事应明确定义客户/用户的利益，以帮助确定优先级。用户故事应由客户编写，以确保其对客户/用户有价值。可估计（E）用户故事应根据故事点进行估算。在开发团队估计用户故事之前，应该清楚地理解用户故事。在开发团队估算之前，用户故事应包含足够的详细信息。当开发团队缺乏领域知识时，用户故事可能无法估计。当开发团队缺乏技术知识时，用户故事可能无法估计。当用户故事太大时，用户故事可能无法估计。小的（S）用户故事应该尽可能小，同时仍然提供用户价值。用户故事应该能够适合一次迭代。对于大的用户故事将难以理解和估计。可测试的（T）应通过测试验证用户故事，以证明它们已正确实施。用户故事应包含指导测试的故事接受标准。用户故事应该很容易进行单元测试。（技术实施）用户故事应该很容易接受测试。（行为的）用户故事应尽可能以自动方式进行测试。故事点规划改进的Fibonacci（0,1 / 2,1,2,3,5,8,13,20,40,100）T恤（xxs，xs，s，m，l，xl，xxl，）完成（DoD）的定义团队可以使用许多标准来定义他们的“完成定义”。这可确保团队提供在功能和质量方面完成的功能。Done的定义是可审核的核对表。以下是国防部的一系列可能标准和活动：单位测试通过接受标准达成代码已审核通过功能测试非功能性要求产品负责人接受用户故事用户故事示例以下是用户故事的示例。参考科恩，迈克。用户故事应用：敏捷软件开发。第1版，Addison-Wesley Professional，2004年。Wake，William C. Extreme Programming Explored。Addison Wesley，2002。

每个Sprint的输出的正式名字为“潜在可交付产品增量”。在开始第一个Sprint之前，产品负责人、团队和Scrum Master必须审视对于把一个产品待事项列表中的事项做到潜在可交付所需要的所有事情。所有为了交付产品所需的活动都应被包含在“潜在可交付”的定义中，并且要在这个Sprint中完成。遗憾的是，当团队开始使用Scrum时他们通常做不到在每个Sprint都能交付出“潜在可交付增量”这个目标。这通常是因为团队缺少自动化或者不够跨职能（例如，技术文档撰写者还没有被包含在跨职能团队中）。随着时间的过去，团队必须要提高从而能够在每个Sprint交付“潜在可交付产品增量”。但是为了开始，他们需要建立一个他们当前能力的基线。这会被记录在“完成的定义”中。在第一个Sprint开始前，产品负责人和团队要对于“完成的定义”达成共识，“完成的定义”是创建“潜在可交付产品增量”所需要的活动的子集（对于一个好的团队来讲两者是一样的）。团队会根据“完成的定义”来计划他们在Sprint中的工作。一个好的产品负责人总是会希望“完成的定义”与“潜在可交付”越接近越好，因为这样会增加开发中的透明度并降低延迟和风险。如果“完成的定义”不等同于“潜在可交付”，那么就会有工作被延迟到发布之前，这会导致风险和延迟。因此被延迟的工作有时被称为未完成的工作。Scrum团队应当持续地改进，这一点会表现在对“完成的定义”的扩展上。

概述：在团队成员间更新信息和进行协调。参与者：团队必须参加；产品负责人不是必须的；ScrumMaster通常会在场，但要保证团队自己主持会议。时长：最长15分钟。一旦Sprint开始，团队就要投身于另一个Scrum实践，那就是每日Scrum会议。在每个工作日指定时间都会举行这个很短的（15分钟，或者更短）会议。团队中的每个人都要参加。为了让它保持简洁，建议每个人都保持站立姿势。这是团队同步他们的工作并互相报告遇到的阻碍的机会。在每日Scrum会议中，每个团队成员一个接一个地向团队的其他成员报告三件事：（1）你昨天做了什么？（2）你今天要做什么？？（3）遇到了什么阻碍？注意每日Scrum会议并不是向管理者报告状态的会议。这是一个自组织团队互相分享目前工作情况的时刻，从而帮助他们进行工作协调。有人要把这些阻碍记录下来，Scrum Master负责帮助团队成员解决它们。在每日Scrum会议中只有很少或不会有深入的讨论，其形式只是做回答那三个问题的报告。如果的确需要讨论，那么在每日Scrum会议后马上就会有一个或多个并行的跟进会议，但在Scrum中没要求任何人必须参加这些会议。部分或者全部的团队成员需要针对于他们在每日例会中所收到的信息进行调整时开跟进会议很常见，换言之，这是又一个审视并调整的周期。对于新接触Scrum的团队，通常情况下建议管理者或者其他会被认为有权威的人不要参加每日例会。这样做的风险是会让团队感到“被监视”。它使得团队在压力之下每天都报告出重大进展（这是不切实际的期望），并使团队不愿报告问题。并且它会破坏团队的自管理，引入微观管理。对于一个利益相关人，更有益的做法是在会议后再找到团队，并帮助解决那些让团队进展慢下来的阻碍。

概述：为了将来的Sprint拆分大事项、分析事项、重新估计并重排优先级。参与者：团队；如果产品负责人是能够帮助梳理细节的专家，那么他会全程参与整个活动，否则他可以只参与其中一部分来设定方向或者重排优先级；其他理解需求并能给予团队帮助的人；ScrumMaster将在会议的开始部分来指导团队如何有效地开这个会，否则的话他不必参加。时长：通常来讲不多于团队一个Sprint工作容量的10％，但有时对于“有大量分析工作”的事项来讲要更长一些。例如，对于两周的Sprint，可能要有一天的时间花在梳理上。Scrum中一个很少有人知道，但很有价值的指导原则是，每个Sprint中整个团队要把一定百分比的时间专门用于梳理产品待办事项列表上，做为对将来Sprint的支持。这包含了详细的需求分析、把大的事项拆小、估计新的事项以及重新估计已有事项。Scrum中没有说这个工作该如何来完成，但是一个经常用到的方法是在接近Sprint中部或者结尾时开一个专注的研讨会，这样团队和产品负责人以及其他利益相关人就可以不受打断地专门做这些事情。这种梳理活动并不是为了当前Sprint已经选择的那些事项。它是为了将来的事项，最可能是为了下一两个Sprint。有了这个实践方法，Sprint计划会议变得相对简单些，因为产品负责人和Scrum团队将从一组清晰的，被很好分析过并认真估计过的事项入手。没有开过这种梳理工作研讨会（或者没做好）的特征是Sprint计划会议中出现重大的疑问或者发现，或者令人困惑并感觉不完整。这样一来计划工作通常要延续到Sprint中去，这显然不是大家想要的。

概述：对于功能性的产品增量进行审视并调整。参与者：团队、产品负责人、ScrumMaster。产品负责人可以邀请其他恰当的利益相关人参加。时长：时间箱为Sprint中的每一周对应一个小时。在Sprint结束后，就到了Sprint评审会议 (Sprint Review Meeting)，人们会评审这个Sprint。出席会议的人有产品负责人、团队成员以及ScrumMaster，再加上客户、利益相关人、专家、领导层和任何有兴趣的人。对于两周的Sprint来讲最长为两个小时。任何参与者都可以问问题和提意见。评审会议常常会被错误地打上“演示”的标签，但这并没有抓住这个会议真正的用意。Scrum中的一个关键思想是审视并调整。观察并了解发生的情况，然后根据反馈进行演进，不断进行。Sprint评审会议是对于产品的审视并调整活动。它让产品负责人了解产品和团队的当前状况（也就是对于这个Sprint的评审），也让团队了解产品负责人和市场的当前状况。因此，评审会议中的一个关键元素是团队与产品负责人之间进行深入的对话来了解情况和得到建议等等。评审会议当然要包含使用团队所创造的真的，运行起来的软件，但如果评审的关注点只是在看产品而没有进行交谈，这么做就失衡了。Sprint评审会议中“运行起来的软件”这部分并不是由团队来做“报告”，不会用到幻灯片。它是指亲手来检验正在运行的真正的软件，例如在一个用于开发的沙盒环境中。在评审会议议室里会有一台或多台电脑，人们可以在上面检验和使用运行起来的软件。最好有一个积极交互的过程，由真实用户和产品负责人动手与软件交互，而不是由团队做出一个被动的展示过程。尽量做到在不超过30分钟的时间之内做完Sprint评审会议的准备，否则就意味着有什么地方做得不对。

概述：针对流程和环境进行审视并调整。参与者：团队、ScrumMaster、产品负责人（非必须）。团队可能会邀请其他利益相关人，否则这些人不准参加。时长：时间箱为对应Sprint中的每一周为45分钟。Sprint评审会议包含了对于产品的审视并调整。而在评审会议之后的“Sprint回顾会议”则包含了针对流程和环境的审视并调整。这是团队讨论什么方式能工作，什么方式不工作的机会，并对要尝试的改变达成一致意见。有时Scrum Master可以扮演回顾会议的效率协调者，但可能还是找一个中立的外人来协调这个会议更好。一个好的做法是，Scrum Master们互相帮助协调彼此的回顾会议，这会起到在团队间“交叉受粉”的效果。组织Sprint回顾会议有很多技巧，《敏捷回顾》（《Agile Retrospectives》）一书中提供了很有帮助的一系列技巧。很多团队的回顾会议只关注于问题，这很不好。这使得人们以为回顾会议是某种让人情绪低落的或者负面的事件。正相反，要保证每次回顾会议也关注于正面的事物或者优势。有几本关于“欣赏式探询”的书在这方面给出了更多的点子。回顾会议如果总是用同样的分析技巧可能就会变得无聊起来，这样的话就要随着时间的推移引入不同的技巧。

Scrum不仅仅是一套具体的实践，确切地说更为重要的是这个框架提供了透明度并给出了“审视并调整”的机制。Scrum通过让影响产品负责人 (Product Owner) 和团队 (Development Team) 效率的机能失调和障碍变得显而易见，使它们得到及时处理。比如，产品负责人可能不清楚市场情况、特性或如何估算它们的相对商业价值。亦或者团队可能对于工作量估算或开发工作还不够熟练等。Scrum框架会迅速揭露这些弱点。Scrum并不能解决开发的问题，只是让问题都赤裸裸地显现出来，并为人们尝试用短周期和小改进试验来解决问题提供了框架。假设团队因为任务分析和估算技能不佳，而不能交付他们预期在首个Sprint完成的工作。对于团队而言，这是次失败。但是实际上，这是个必需经历的第一步，以使得团队对于以后的预期更加实际和周到。Scrum的这种模式使得机能失调显现出来，让团队能够及时处。正是这种基本的机制带给了使用Scrum的团队所能经历到的最大好处。一个常见的错误做法是当使用某个Scrum实践遇到挑战时改变Scrum。比如，团队交付有困难，他们可能决定延长Sprint，那么时间永远都是充裕的，并且在这过程中确保自己永远都不用学习如何更好地估算和管理时间。这样，没有经验丰富的Scrum Master的教练和支持，这个组织的Scrum就会蜕变成只是其自身弱点和功能不调的镜像，并且破坏了Scrum所能带来的真正利益：也就是使得好坏都显露无遗，给组织提供自我提升的机会。另一个常见的错误做法就是假定某个实践是不准许或禁止的，只是因为Scrum没有明确地提到。比如，Scrum没要求产品负责人为产品制定长期策略，也没要求工程师对于复杂的技术问题向经验丰富的前辈讨教。Scrum将这些都留给相关的个人来做正确的决定，在多数情况下，以上两个实践（和其他一些）都是特别推荐的。还有一个需要注意的是管理者强制团队使用Scrum。Scrum提供给团队空间和工具来自我管理，这种从管理层强压下来的命令并不是取得成功的方法。一个比较好的做法就是让团队先从同事或管理者处了解到Scrum，进行全面的专业培训，然后由团队决定在一定的时期内忠实遵循Scrum实践，在该时期结束时团队将评价其工作经历，再决定是否继续使用Scrum。虽然首个Sprint通常对于团队来说是极富挑战性的，但值得庆幸的是在Sprint结尾时Scrum带来的好处就会显现出来。所以很多新的Scrum团队都惊叫：“Scrum太难了，但是比起我们以前的做法它简直是太好了！”

Scrum Projects的主要利益相关者是产品负责人产品负责人的一个不可或缺的责任是向Scrum团队传达Scrum项目的重要性和重要性。这是通过使用Product Backlog成功实现任何敏捷项目的关键。现在让我们看一下产品负责人的一些主要职责 ：产品Backlog的创建和维护：Scrum Process主要用于软件环境和新产品开发领域。这是产品负责人正在进行的工作和全职工作。在任何sprint计划会议之前，他必须不断地进行梳理。根据业务ROI确定Backlog的优先级：产品负责人还需要根据业务和情况的需要对待办事项进行优先级排序。他还将用户故事中的史诗，主题和特征详细阐述，这些故事足以在单个冲刺中实现。产品负责人负责不断提醒Sprint＆Release团队，并确保团队在实现目标的过程中保持正轨。产品负责人负责与客户和利益相关方不断保持沟通，以确保团队正在构建正确的产品并提供预期的业务价值。同样在每个Sprint结束时，产品负责人都有机会引导团队朝着为利益相关者创造价值的方向发展。产品负责人还会在每个Sprint结束时不断检查Scrum团队所做的工作，并拥有接受或拒绝其工作或建议修改的绝对权限。产品负责人还充当团队对外界的代言人，并应确保所有沟通渠道保持开放，项目获得成功所需的正确的支持。如果产品负责人认为所需的方向发生了巨大变化并且不再需要花费，则有权终止Sprint。如果竞争对手发布新产品并且客户想要反击，则可能发生这种情况产品负责人的职责是繁重的，有很多必须由他穿着因此一个产品负责人的选择必须明智地做，因为它可能会导致成功或失败对整个项目可能最终意味着项目成功或失败。Scrum角色什么是Scrum团队？什么是Scrum的自组织团队？Scrum团队如何运作？ - 简要指南如何成为Scrum项目的优秀产品负责人？什么是产品负责人在Scrum中的角色？敏捷开发：如何成为合格的Scrum Master？什么是Scrum中的猪和鸡？项目经理与Scrum Master对项目所有者什么是三个Scrum角色？什么是Scrum Master？角色和责任什么是敏捷中的跨职能团队？作为Scrum Master，您如何帮助您的项目所有者？

Scrum方法需要改变传统方法的思维方式。中心焦点已经从瀑布方法的范围转变为在Scrum中实现最大的商业价值。在瀑布中，改变成本和进度以确保达到预期的范围，在Scrum中，可以改变质量和约束以实现获得最大商业价值的主要目标。瀑布模型适用于有序和可预测的项目，其中所有要求都明确定义并且可以准确估计，并且在大多数行业中，此类项目正在减少。客户需求的变化导致企业适应和改变其交付方式的压力增大。Scrum方法在当前市场中更为成功，其特点是不可预测性和波动性。Scrum方法基于inspect-adapt循环，而不是Waterfall方法的命令和控制结构。Scrum项目以迭代方式完成，其中首先完成具有最高业务价值的功能。各个跨职能团队在Sprint中并行工作，以便在每个Sprint结束时提供潜在的可交付解决方案。因为每次迭代都会产生可交付的解决方案（这是整个产品的一部分），所以团队必须实现可衡量的目标。这可确保团队正在进行，项目将按时完成。传统方法没有提供这种及时的检查，因此导致团队可能会下班并最终完成大量工作。当客户定期与团队互动时，定期审查完成的工作; 因此，可以确保进度符合客户的要求。然而，在瀑布中没有这样的交互，因为工作是在筒仓中进行的，并且在项目结束之前没有可用的功能。在复杂的项目中，客户不清楚他们在最终产品中需要什么，并且功能需求不断变化，迭代模型可以更灵活地确保在项目完成之前可以包含这些更改。但是，当完成具有明确定义的功能的简单项目，并且当团队具有完成此类项目的先前经验（因此，估计将是准确的）时，瀑布方法可以是成功的。敏捷 Vs. 瀑布下面是一个表格，可以更好地了解Scrum和瀑布的差异。下面是一个表格，可以更好地了解Scrum和瀑布的差异。敏捷还是瀑布？见图Standish Group的最新报告涵盖了他们在2013年至2017年期间研究的项目。在这段时间内，敏捷和瀑布的成功，挑战和失败的整体突破如下所示，敏捷项目成功的可能性大约是后者的2倍，失败的可能性降低1/3。（来源：vitalitychicago.com - 比较瀑布和敏捷项目成功率）敏捷与瀑布 - 项目成功率更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

任务计划和评估对于按照优先产品Backlog中指定的要求迭代开发产品至关重要。Scrum团队在任务评估会议中估算完成任务列表中每项任务所需的工作量。此过程的结果是Effort Estimated Task List。Scrum团队使用Task列表，这是一个包含团队为当前Sprint提交的所有任务的综合列表，用于开发Effort Estimated Task List。任务列表必须包括任何测试和集成工作，以便Sprint的产品增量可以成功地集成到之前Sprint的可交付成果中。尽管任务通常基于活动，但任务被分解的粒度级别由Scrum团队决定。在任务评估会议期间，Scrum团队使用任务列表来估计完成任务或任务集所需的工作量，并估计在给定Sprint中执行任务所需的人员工作和其他资源。该技术的一个主要优点是，它使团队能够对用户故事和需求拥有共同的视角，以便他们可以可靠地估计所需的工作量。任务估算会议中开发的信息包含在“工作量估计任务列表”中，用于确定Sprint的速度。在本次研讨会中，Scrum团队可以使用各种技术，如分解，专家判断，类比估计和参数估计。任务评估会议也可以与任务计划会议相结合。为了保持相对估计大小并最小化重新估计的需要，团队使用估计标准。估计标准可以用多种方式表达，两个常见的例子是故事点和理想时间。例如，理想时间通常描述Scrum团队成员专门开发项目可交付成果的小时数，而不包括花在项目之外的其他活动或工作上的任何时间。通过评估标准，Scrum团队可以更轻松地估算工作量，并使他们能够在必要时评估和解决效率低下问题。任务估计的输出是Effort Estimated Task List。它是与Sprint中承诺的用户故事相关联的任务列表。通常，估算的准确性因团队技能而异。估计的努力以团队商定的估算标准表示。Scrum团队在Sprint计划会议期间使用此Effort Estimated Task List创建Sprint Backlog和Sprint Burndown Chart。团队集体估算在Scrum开发期间，团队分担责任并共同致力于每个Sprint的工作，因此敏捷团队的估计工作量使用了集体估算方法。集体估算通常使用规划扑克作为工具，团队通过玩估计游戏进行集体估算。规划扑克被认为是在敏捷中进行工作负荷估算的最有效和最有趣的技术。它由一组类似于斐波纳契数的数字组成，包括：0,0.5,1,2,3,5,8,20,40，？，∞，扑克牌每组有4组这样的斐波那契数字用于服务供4人使用。群体与个体估计的准确性根据一些关于软件项目实验中个人和小组之间努力估计准确性的研究。来自同一公司的20名软件专业人员分别估算了实施相同软件开发项目所需的工作量。参与者有不同的背景和角色，软件项目以前已经实施过。之后，他们组成了五个小组。每个小组通过讨论和结合他们之间的知识来商定一项估计。结果 - 基于小组讨论的估算比个人估算更准确。进行计划扑克的步骤每个团队成员获得一组卡片，包括0,0.5,1,2,3,5,8,13,20,40，？，∞，共12张牌。该产品所有者要么读描述要素的团队。团队成员讨论该功能，并在需要时询问产品所有者问题。当成员完成讨论后，他们每个成员选择一张扑克牌来代表估计。然后同时显示卡片。如果团队评估不同的估计。我们同意吗？我们有差异吗？有什么我没考虑过的吗？那些选择最高或最低价值的人应该在每个成员选择另一张扑克牌之前与小组分享他们的推理。讨论结束后，您可以估算另一轮，团队需要达成协议。返回第二步并开始估计下一个条目。估计大小，而不是估计时间段，使用相对估计而不是绝对估计估计只不过是一个受过良好教育的猜测。我们利用手头的所有知识和经验来猜测它将花费的时间。因此，不是单独查看每个新工作项，为什么不将它与以前完成的工作项进行比较？人类更容易与类似物品相关而不是猜测事物的实际大小。例如，它是否更接近这个非常小的东西？或者它更像这个正常大小的项目？还是像我们上个月完成的那项工作一样真的很大？做相对估计不仅会减少估算工作所花费的时间，还会大大提高估算的准确性。我们的大脑无法进行绝对估计; 我们总是把我们需要估计的新事物与我们已经知道的事物相关联。故事点估计估计速度 - 记录和平均每个Sprint的团队速度该团队的速度是多少故事点数的Scrum团队在一个Sprint实际完成。团队速度告诉你团队的速度有多快。一个新估计的项目或团队（过去没有参考速度记录），我们可以做1-2个Sprint来测量速度作为初始速度。在Sprint实施过程中，我们需要记录每个Sprint的速度，以便将来的计划。估计用户故事速度我们估计产品Backlog的故事点总数，然后我们知道每个Sprint的平均速度，然后我们可以计算出我们需要完成多少Sprint，因此预计Sprint将是项目所需的。如下图所示。Scrum项目持续时间估算其他Scrum实用技术什么是Scrum中的Sprint目标？什么是Scrum中的Burndown图表？什么是角色 - 功能 - 原因模板？Sprint增量与潜在可运输产品对比MVP对MMP为用户故事撰写SMART目标和投资谁在Scrum中创建产品Backlog项目或用户故事？什么是敏捷估算？什么是敏捷中的故事点？如何估算用户故事？

在Scrum项目中，Scrum团队成员负责提供所需的产品或服务，而不是Scrum。因此，我们应该小心组建Scrum团队。Scrum团队有时被称为开发团队，因为他们负责开发产品，服务或其他结果。它由Sprint Backlog中的用户故事组成的一组人员为项目创建可交付成果。Scrum团队提供所需项目结果的基本特征如下所述：自组织 (self-organized)： Scrum团队成员是有动力的人，他们不等待上级分配任务。他们承担责任，分担风险，做出决定，共同努力实现共同目标。授权：(Empowered) Scrum团队或开发团队获得所需的资源，以提供所需的产品或服务以及作出决策的权限。如果团队只有责任但没有权力做出决策，那么连续/迭代开发就很困难。协作 (Collaboration)：项目管理是一个共享的价值创造过程，团队一起工作和互动，以提供最大的价值。Scrum团队应该分享知识，想法，风险和责任，并与团队成员协调工作，以提供理想的结果。共同目标 (Shared Goal)： 团队中的个人应共同努力实现共同目标。团队目标应该叠加他们的个人目标，如成长，评估和金钱。最佳规模 (Optimum Size)： 一个小型Scrum团队可能没有开发产品或服务所需的技能，而大型Scrum团队可能会破坏工作，因为团队内部的协作将很困难。根据SBOK的定义，Scrum团队的最佳规模应为6到10。这将确保Scrum团队足够大，能够拥有交付项目所需的技能，并且足够小，可以进行协作。多样化的技能 (Cross-functional)： Scrum团队应该集体拥有提供项目可交付成果所需的技能。在Scrum团队组建期间，应该选择团队成员，牢记交付项目可交付成果所需的技能。并置 (Collocated)： 建议组建一个Scrum团队，成员并置。这确保了团队成员之间的协作和协调可視化 (Visualized)：工作任務的可視化。讓團隊成員瞭解工作任務項以及當前進度。

对于大多数转向敏捷方法的公司而言，产品所有者 (Product Owner) 是新的东西。但是，每个月您都会看到产品所有者需求的显着增长。为什么？我们将在本文中讨论它，更多地关注产品所有者在软件开发项目中的角色。谁是产品所有者？一个伟大的产品负责人基本上是他的产品的企业家。PO是敏捷团队的成员，负责提供高质量的数字产品。简而言之，PO定义用户故事并优先处理积压 (Backlog)，同时保持团队功能的概念和技术完整性。敏捷产品负责人在质量控制方面的作用是巨大的。PO是一个关键成员，他接受完成后的故事。根据我们的经验，与不同行业的公司合作，如果公司没有采购订单，那么在大多数情况下，如果没有达到最后期限并且产品交付的功能不是真正需要的，那么开发过程会变得混乱。但是，我不得不说要完成敏捷软件开发项目中需要完成的所有工作，在我看来，产品负责人应该有一些技术知识才能更有效。为什么？因为产品所有者应该能够与技术团队交谈并理解对推进项目至关重要的概念。此外，PO应该能够向其他利益相关者解释技术概念。PO就像开发团队和利益相关者之间的中间人。但是，除了掌握技术知识外，PO应该从最终用户的角度对产品有所了解。这意味着PO也应该有业务背景。不幸的是，现在世界上很少有人真正符合这个“理想的候选人”标准，因此许多大学和学院开始开设课程来培养产品所有者。如果您想听取我们的意见，那么我们认为将技术人员，开发人员或CTO转换为PO比商务人员容易得多。让我们来看看PO的主要责任范围。软件开发项目中的产品负责人角色创建和维护产品Backlog 在软件领域，没有什么是不变的，产品负责人必须根据客户和市场需求调整产品Backlog。此外，好的PO知道何时以及如何说NO。这可能是最明显但也是最难掌握的人。对新想法或功能说“是”很容易，这只是产品积压的另一个项目。但是，良好的积压管理包括创建可管理的产品积压，其中的项目可能会实现。在积压的情况下添加项目，知道什么都不会发生，只会造成“浪费”和错误的期望。为了避免整个开发过程花费太长时间的情况，项目失去了重点，而开发的解决方案可能无法真正解决业务问题，PO应该对某些功能和变更说“不”。但在这些情况下，根据业务价值或ROI确定积压的优先级 每个用户故事必须按相对重要性排序。不应该有5个高优先级。重要的是要知道哪个用户故事是＃1，哪个是＃2等。这不仅仅是从业务角度来看，PO应该考虑到开发部分以及在做X之前根本无法开发的一些功能任务。因此，PO应该从双方分析需求，并提出最佳解决方案，最佳优先级，从一开始就为产品增加更多价值。用户故事 PO应该知道如何编写用户故事。简单的例子是：作为用户，我想<某个目标或目标>，以便<benefit，value>。这里有一篇文章解释用户故事。在每个Sprint开始时传达愿景和目标 这有助于保持团队的正常运转。产品负责人代表客户发表意见，并与利益相关方共同创造产品愿景。每个决定都考虑到产品愿景。这确保了可持续的产品开发，为开发团队提供了清晰度，并增加了产品成功的机会。吸引客户和利益相关者以确保团队正在构建正确的产品 开发团队不应该花时间向客户解释技术问题，这是PO的工作。换句话说，产品负责人是团队对外界的代言人，应该确保所有沟通渠道都是开放的，并且项目需要适当的支持才能取得成功。PO负责定义实现目标的边界和约束。它们可以包括截止日期完成日期，成本限制，内存限制和最低速度。参加每日Scrum会议，Sprint计划会议以及Sprint评审和回顾。 对于产品负责人而言，拥有能够适应不同团队和个性类型的良好沟通技巧尤为重要。产品负责人应根据当前状态，进展，可能的斗争和问题更新利益相关者。质量保证 通常情况下，PO是唯一可以接受故事的团队成员。这包括验证故事是否符合验收标准并具有适当的，持久的验收测试，并且它符合其“完成定义”投资回报率 产品所有者负责提供最佳投资回报。他们对sprint的发布和产品级别的所有经济决策负责。预算，时间和质量可根据需要进行调整，每个产品的成本和收益积压也可用于确定用户故事的优先级。解决冲突 任何无法处理冲突的人都不应该是产品所有者。在数字产品开发中，拥有强大的冲突解决技能对于阻止争议升级并专注于真正重要的事情非常重要。有时，PO必须经历一些冲突才能达成解决方案。准时交货 产品负责人负责确保团队满足截止日期和目标。PO负责根据里程碑提供最佳工作软件。如果您喜欢本文关于软件开发中的产品负责人角色，您可能会喜欢：Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (基础篇)Scrum的基本功 - 集合中英文版本 (角色和责任篇)

本文作者：张海龙，CODING 创始人兼 CEO本文字数约 3700 字，阅读时间约 8 分钟。2018 年对许多人来说是艰难与变革的一年，势如破竹的发展势头似乎被打破，小微创新型企业生存艰难。“产业互联网”“企业数字化转型”等寻求从内破局的呼声也越来越高。有趣的是，类似的情况不是第一次出现。1999 年金融海啸来袭，经济下行周期内，大家都寄希望于当时先进的信息技术，希望能以此提升自身的管理水平，增强企业竞争力。导致当年 ERP 进入中国后迅速走红，令无数缺乏管理经验的中国企业心驰神往。而到了数字化转型的浪潮之年，这个风口上的词变成了 DevOps（/de’vps/）。大家纷纷开始讨论要不要采用 DevOps 、DevOps 到底有没有那么神奇。Google Trends 中 DevOps 历年的热度数据DevOps 到底是什么2018 年，我们走访了近百个分布在各行各业中的 IT 团队，意外的发现，大多数的 IT 团队寻求改革并非来源于部门内部的自我革新，而是来源于业务部门的服务压力。正如同当年企业寻找 ERP，今天的企业将目光投向了 DevOps。但是 DevOps 并非像 ERP 那样可以直接部署的东西，而是一种由主流互联网巨头们所总结出来的的研发管理理念，是 Google、Netflix 等大型互联网公司实现快速迭代的秘诀。 作为一家专注于研发 DevOps 工具链的公司创始人，我在接触客户的时候，发现一个很有趣的现象：所有人都想“做” DevOps 并期待其能为他们带来商业上的成功，却对 DevOps 的核心理念知之甚少。这很大一部分原因是市面上对 DevOps 有着各种各样的说法，导致大家概念的混淆。想要弄清楚 DevOps 到底是什么，必须先从它的本质说起。软件开发最高效的组织形式是“One Man Work”，只有一个人干活，写个小项目，从需求到开发，从测试到部署全部独立完成，非常高效。但随着业务的增长，项目开始逐渐变得庞大，变成团队，出现了分工，出现了产品经理、项目经理、开发、数据、测试、运维等等角色。这些角色间存在天然的工作目标上的矛盾。举个例子，对于运维来说，稳定压倒一切，新 Feature 越少越好。而对于研发来说，却希望能开发更多的功能。这种矛盾会导致大量的资源和时间的浪费。就像两匹马拉一辆车，如果马头向着的方向不一致，肯定是没法全速前进的。DevOps 的理念就是希望能打破这种屏障，让研发（Development）和运维（Operations）一体化，让团队从业务需求出发，向着同一个目标前进。字面意思上说 DevOps 是指“开发运维一体化”，即通过工具辅助开发完成运维的部分工作，减少成本。但深入理解了 DevOps 之后，你会发现 DevOps 其实是一种软件研发管理的思想，方法论，他追求的是一种没有隔阂的理想的研发协作的状态，可能涉及到的角色有开发、测试、产品、项目管理、运维等等。所以我们认为，为了帮助研发团队在保持质量的前提下提高交付效率的方法和方法论都隶属于 DevOps 的范畴。比如 Google 提出的 5 个 DevOps 原则，这套原则中必须依赖于工具辅助的部分只有后两点，更多的则是对于开发组织形式的内省：精简组织架构；愿意承担一部分试错带来的损失；分阶段地一小步一小步地进行转型；最大化地利用工具和自动化流程；对所有的过程和结果进行记录和分析。所以 DevOps 不是简单的开发软件化，而是企业的学习能力不断提升的结果，将企业改造成敏捷应对的学习型组织，运用新的工具，优化组织架构和流程，不断地进行自我革命和创新的方式。工具是辅助，而非基础。困难重重的 DevOps 落地在弄清楚了 DevOps 的宏观定义之后，我们再来观察一下 DevOps 目前在国内的实践现状。根据南京大学 «DevOps 中国•2018 年度调研» 的调研报告，目前设有 DevOps 实践团队的公司中，科技和互联网行业占比接近 70%。其他行业的从业者对 DevOps 的认知还存在一定的不足。这与我们的调研走访体验一致：大多数企业都愿意尝试运用 DevOps ，但是在实践 DevOps 中，普遍碰到了比较大的困难。主要是以下三个原因：对 DevOps 有不切实际的预期部分团队为了做 DevOps 而做 DevOps，并没有真正的从业务的角度出发来考虑。如前文所说，DevOps 不是银弹，高水平的研发团队在 DevOps 实践中将快速找到研发质量与业务增长的平衡点。但对于许多仍然在使用中心化的研发组织形式的团队来说，DevOps 的尝试无法立即获得肉眼可见的增长数据，思索与尝试带来的对团队的训练可能会是第一份收获。步子迈得太大新生代互联网公司诞生于 DevOps 理念已经相对成熟的年代，且互联网公司天生地将迭代速度作为追求目标之一，使得这些公司能够在发展的初期，就将 DevOps 的理念融入到公司的架构设计中。上图是 Netflix 的整个系统架构。如此复杂的系统架构同时还能每天迭代几十个版本，无法通过传统的研发管理模式来维护，只有通过实践 DevOps 的理念，来优化组织的分工、资源和能效，才能得以实现。在这样的组织里，已经不需要有人了解所有模块是做什么，每个人只需要对自己的模块负责。而很多企业，为了巩固和提高自己的市场竞争力，非常急于达成上述高效的状态，并且希望能一步到位。国内其实大部分团队都没到大规模实践 DevOps 的时间点，有些团队甚至连分支开发、并行开发的方式都没有。我给这类的企业建议是：不要想着一口气吃成个胖子，一步一步来，先理解 DevOps 的理念和对业务的实际意义，然后搭建一只小的 DevOps 团队来承接一项新业务，旧的业务仍然使用旧系统，双轨并行，等待小团队适应了 DevOps 的管理节奏之后再向其他团队进行推广。之前出过一篇关于 DevOps 的专题报告《四周年 · 专题报告：双速 IT》，也可以作为参考。Toolchain Crisis实践 DevOps 的原则中很重要的一点就是对工具的运用及依赖工具搭建合适企业的自动化流程。但是目前市面上缺乏成熟的 DevOps 工具链，各个服务商的细分工具层出不穷，企业为了搭建整套 DevOps 流程，需要研究几十种工具，并选取其中的 7-8 种进行落地实践。非常依赖于管理者的项目经验，没有 DevOps 经验的团队起步将会比较困难。以 CODING 为例。2018 年之前 CODING 产品仅有任务及代码管理模块。我们是这样进行工作的：产品经理在 CODING 上撰写文档创建任务，研发 Leader 将任务分配给开发，开发完成后提交代码，并创建 MR，我们在本地部署了 Jenkins 进行持续集成进行构建和测试，再由其他工程师进行人工评审，通过后并到发布分支，进行预发布，再通过持续集成进行构建，自建 Docker registry 进行构建物管理。构建出的 Docker 镜像在测试环境和预发布环境上依次进行自动化测试及人工测试，测试通过后，使用我们运维自己搭建的工具进行部署管理。目前 CODING 每天都进行产品迭代，可以快速响应用户需求并保证服务质量，但搭建这一整套的流程高度依赖于团队能力，门槛非常高。为了降低工具的成本和使用门槛，包括 CODING 在内的很多云服务厂商都在做打通全流程的 DevOps 工具链的尝试，希望可以做到让企业开箱即用，低成本的践行 DevOps 理念，不过目前产品仍处于迭代期，无法满足所有企业的需求。DevOps 是未来的趋势既然 DevOps 这么难，坑这么多，为什么还要做呢？因为这是企业未来的长期诉求。从大趋势上分析，未来所有企业都将是软件企业，制造软件、服务软件、构建于软件。比如全世界最大的出行公司 Uber，其实是一个软件公司，而非出租车公司。从企业自身诉求出发，中国的中大型企业已经逐步进入了创新驱动的阶段。无论是供给侧改革还是智能制造 2025 都要求企业修炼内功，提高效率促进创新。过去几年中在塑造前沿行业的 DevOps 理念将在 2019 年左右成为主流，成为企业能否在行业内脱颖而出的关键性因素。在 Statsia 2018 年的报告中，有超过 72% 的企业或多或少地开始践行 DevOps 的理念，其中完整采用 DevOps 的比例高达 17% ，而在 2017 年这个数字仅有 10%。真正能够实践 DevOps 的团队也会为自身的业务带来巨大的提升。根据 Puppt 的2017 DevOps State Report，DevOps 型团队将部署频率提高46倍，交付速度提高 440 倍。可见，在国际上来说，DevOps 已经处于企业爆发性需求的前夜。而在国内公司中，新兴企业的成功实践也在为中国企业的 DevOps 输送方法论与有经验的专家。字节跳动可以说是 DevOps 最佳践行者之一。在其创始人张一鸣看来：公司的业务越复杂，人越多，组织就越大。这导致信息失效、（下属）向上管理和业务变大。他把类似组织的负规模效应称为“自嗨”，这是他所不能接受的。故而字节跳动在组织架构上，总共只有 3 个核心部门：技术、Growth 和商业化，分别负责研发、推广和收入。今日头条、抖音、西瓜视频……字节跳动的每款 App 都基于这三个部门来发展。在项目开始时，公司会为每个项目设置虚拟项目组，由三个核心部门抽调人员组成，试水成功后直接推广。所有产品共用一条技术线，快速试错。针对 App 类产品的快速迭代的业务特性，字节跳动依据 DevOps 理念对组织架构进行调整和优化，从结构上保证了技术支持业务创新的能力。Why Now？DevOps 的理念和优势被说了很多年，但一直都只在少量公司有能力实践。软件的工程化历史还比较短暂，业务需求与技术理念都日新月异，前两年大量的团队还在为了研发新的业务疲于奔命，没有精力关注研发效能升级的问题。许多团队的研发管理还停留在靠微信喊话和 Excel 管理的阶段。而如今，在市场遇冷和企业数字化转型的契机下，更多的公司开始将目光放在企业内部的效率提升和研发成本的控制上。在 Netflix、Google 这样发展比较久的的巨型公司可以耗费大量的内部资源从底层服务开始从零搭建 DevOps 流程。而像字节跳动这样的新型公司可以如此快速实现敏捷，也得益于云服务的逐步成熟。尤其是在当前环境下，运维业务逐步多样化和复杂化，很多传统的运维技术和解决方案已经不能满足当前运维所需，越来越多的团队选择使用 Docker kubernetes 等技术提升运维能力。同时，云厂商的 SaaS、IaaS 和 PaaS 服务相对于传统的运维业务帮助企业节省大量硬件维护的成本和时间，让企业能专注于业务的发展与创新。结语孙子兵法有云，凡兵法韬略，在道不在术。面对日新月异的的市场，企业必须逼迫自己不断的进行革新来应对市场变化。就像马化腾在互联网大会上提到的，现在互联网已经发展到了深水区，甚至是无人区。只有不断的迭代，迅速反应，才能应对未来的变化，而这也正是 DevOps 所强调的。点击立即体验一站式 DevOps 工具链。 ...

本教程适用于敏捷软件开发新手的Scrum团队成员，以了解他们的角色和职责。本教程还将帮助那些已经在敏捷模型中工作的人提高他们的技能，并帮助那些只想了解这些角色的人。它还将提供对责任及其所隐藏的每个角色的洞察力。Scrum团队的角色和责任Scrum团队主要由三个角色组成：Scrum Master，产品负责人和开发团队。核心团队以外的任何人都不会对团队产生任何直接影响。Scrum中的每个角色都有一套非常明确的职责，我们将在本教程后面详细讨论。在本节中，让我们关注Scrum团队的整体属性和理想的团队规模。Scrum团队属性以下是Scrum团队的2个属性：Scrum团队是自组织的Scrum团队是跨职能的自组织Scrum团队在完成工作方面是自力更生和自给自足的，无需外部帮助或指导。这些团队有足够的能力采用最佳实践来实现他们的Sprint目标。跨职能Scrum团队是团队中具备完成工作所需的所有技能和熟练程度的团队。这些团队不依赖团队外的任何人来完成工作项目。因此，Scrum团队是完成整个工作项所需的不同技能的非常有创意的融合。每个团队成员可能不一定具备构建产品所需的所有技能，但能够胜任他/她的专业领域。话虽如此，团队成员不需要交叉功能，但整个团队必须是。具有高自组织和跨职能的团队将带来高生产力和创造力。Scrum团队规模Scrum中推荐的开发团队规模为6 +/- 3，即3到9个成员，不包括Scrum Master和产品负责人。现在，让我们继续前进，详细讨论这些角色。Scrum MasterScrum Master负责促进/指导开发团队和产品负责人从事日常开发活动。他是确保团队理解Scrum价值观和原则并能够实践它们的人。与此同时，Scrum Master还确保团队对Agile充满热情，以便在框架内实现最佳效果。Scrum Master还帮助并支持团队自我组织。除了对团队成员进行有关敏捷重要性的培训和培训外，他还有责任确保团队始终保持积极性和强化。他还致力于加强团队成员之间的沟通和协作。Scrum Master是一名流程负责人，他帮助Scrum团队和Scrum团队以外的其他团队了解Scrum值，原则和实践角色和责任＃1）教练 - Scrum Master为开发团队和产品负责人充当敏捷教练。Scrum Master在某种程度上可以作为开发团队和产品负责人之间正确沟通的推动者。Scrum Master负责消除其他角色之间的障碍。如果注意到产品负责人没有参与或没有给开发团队提供适当的时间，那么Scrum Master的工作就是指导产品负责人了解他参与整个团队成功的重要性。＃2）辅导员 - Scrum Master也是Scrum团队的推动者。他促进和组织Scrum团队成员要求的所有Scrum活动。Scrum Master还帮助团队做出重要决策，从而提高Scrum团队的整体生产力。Scrum Master从不命令团队成员做某事，而是通过指导和指导帮助他们实现目标。＃3）消除障碍 - Scrum Master还负责消除影响团队交付业务生产力的障碍。团队成员无法自行解决的任何障碍都会导致Scrum Master解决。Scrum Master根据对团队生产力和业务的影响对这些障碍进行优先排序，并开始研究这些障碍。＃4）干扰关守 - Scrum Master还保护Scrum团队免受外界干扰和分心，以便团队可以在每次冲刺后继续专注于为业务提供最佳价值。如果团队在Scaled Scrum环境中工作，其中多个Scrum团队正在协同工作并且在他们之间具有依赖关系，那么干扰可能会引起更大的关注。Scrum Master确保团队不参与任何不相关的讨论，并专注于Sprint项目，而他自己则负责解决来自外部的查询和疑虑。Scrum Master负责保护团队免受外部干扰并消除障碍，以便让团队专注于提供业务价值。＃5）仆人领袖 - Scrum Master通常被称为Scrum团队的仆人领袖。他最重要的职责之一就是向Scrum团队询问他们的顾虑并确保他们得到解决。Scrum Master的职责是确认团队的基本要求是优先考虑并得到满足，以使他们有效地工作并产生高绩效的结果。＃6）流程改进者 - Scrum Master和团队还负责定期即兴创建所采用的流程和实践，以最大限度地提高交付价值。Scrum Master不负责完成工作，但是他有责任让团队设计一个让他们完成冲刺目标的流程。产品负责人我们将在本教程中讨论的另一个非常重要的角色是产品负责人。产品负责人是客户/利益相关者的代言人，因此负责缩小开发团队与利益相关者之间的差距。产品所有者以最大化正在构建的产品价值的方式管理差距。产品负责人将参与Sprint活动和开发工作，并在产品的成功中发挥至关重要的作用。角色和责任＃1）弥合差距 - 产品负责人与内部和外部利益相关方密切合作，收集输入并综合愿景，将产品功能放入产品Backlog中。产品负责人有责任了解利益相关方/客户群体的要求和偏好，因为他是代理人并肩负着构建正确解决方案的责任。同时，产品负责人确保开发团队了解需要构建的内容以及何时构建。他每天都与团队合作。产品负责人与团队的互动增加了反馈频率和响应时间，从而提高了正在构建的产品的价值。产品所有者的缺席/减少协作可能导致灾难性的结果并最终导致Scrum失败。产品负责人确保产品待办事项项目透明且清晰表达，团队中的每个人对项目都有相同的理解。管理产品待办事项 - 作为上述结果，产品负责人负责创建和管理产品Backlog，订购产品Backlog中的项目以最好地实现利益相关方的要求，即产品Backlog项目的优先级，最后他应该随时可以回答或澄清所有开发团队的问题。总的来说，他负责培训产品Backlog以提高交付价值。任何想要在产品Backlog中添加/删除项目或需要更改项目优先级的人都应该定向到产品所有者＃3）认证产品 - 他的另一个责任是认证正在构建的功能。在此过程中，他为每个产品待办事项项定义了接受标准。产品负责人还可以创建代表他定义的验收标准的验收测试，或者可以在创建它们时从中小企业或开发团队获得帮助。现在，他是通过执行验收测试来确保满足验收标准的人。他可以选择自己执行这些验收测试，也可以请专家这样做，以确保功能和质量方面得到满足并满足期望。此项活动通常在项目完成时在整个sprint中完成，以便可以发现错误并在实际Sprint审核会议之前修复。＃4）参与 -产品负责人是Sprint相关活动的主要参与者。他与开发团队密切合作，解释项目，范围和价值。他还充当开发团队的推动者，能够在Sprint结束时获取他们应该提供的Product Backlog项目。除Sprint活动外，产品负责人还负责产品发布活动。在产品发布活动期间，产品负责人与利益相关方进行讨论，以讨论下一版本的项目。团队蓬勃发展的关键成功因素之一是整个团队应尊重产品负责人及其决策。产品负责人以外的任何人都不应该告诉团队要处理哪些项目。建议单个产品拥有一名全职产品所有者。但是，可以存在产品所有者是兼职角色的安排。代理产品所有者代理产品所有者是产品所有者自己注册的人，他可以接管他的所有职责，缺席并支持他。代理产品负责人对他所委派的所有责任负有责任，但最终完成的工作的责任仍然在于实际的产品负责人。代理产品负责人还有权代表实际产品负责人做出必要的决策。开发团队Scrum团队的另一个非常重要的部分是开发团队。开发团队由熟练掌握自己专业领域的开发人员组成。与其他Scrum团队成员不同，开发团队负责实际实施潜在可交付软件/增量，并在每个Sprint结束时交付。开发团队可能包括具有专业技能的人员，如前端开发人员，后端开发人员，开发人员，QA专家，业务分析师，DBA等，但他们都被称为开发人员; 没有其他标题是允许的。开发团队甚至不能像测试团队，需求规范团队等那样拥有子团队。团队的成立考虑了在没有外界帮助的情况下成功开发，测试和交付每个Sprint产品增量所需的所有基本技能。因此，该团队应该是自给自足和跨职能的。开发团队不会从Scrum团队外部获得任何帮助并管理他们自己的工作。开发增量的责任始终在于整个开发团队，但Scrum团队中的每个人都负责整体交付。完全由开发团队决定添加/删除团队成员。如果需要新的技能组合，开发团队可以选择在团队中构建专业知识或向团队添加新成员。角色和责任＃1）开发和交付 - 开发团队负责根据每个sprint结束时的“完成定义”创建完成增量。完成增量可能不一定是下一个生产版本的一部分，但它绝对是最终用户可以使用的潜在可释放功能。产品负责人致电决定需要成为发布的一部分。开发团队负责开发和交付符合“完成定义”标准的每个Sprint的完成增量。任务和提供估算 -开发团队还负责从下一个Sprint中提取优先产品Backlog中的用户故事/项目。因此，这些项目构成了Sprint Backlog。Sprint Backlog是在Sprint计划会议期间创建的。开发团队的另一项非常重要的职责是通过分解Sprint项目并为这些Sprint项目提供估算来创建任务。没有人告诉开发团队做什么以及如何做。开发团队有责任从下一个Sprint中提供的Product Backlog中获取项目。Sprint启动后，无法更改/添加/删除项目。开发团队规模应明智地选择开发团队规模，因为它可能直接妨碍团队的生产力，从而影响产品交付。开发团队不应该非常庞大，因为它可能需要团队成员之间的大量协调。但是，对于一个非常小的团队来说，获得递增所需的所有技能将非常困难。因此，应为开发团队规模选择最佳数量。建议的开发团队规模为3到9个成员，不包括Scrum Master和产品负责人，除非他们还与其他开发人员一起开发软件增量。摘要Scrum团队角色产品拥有者开发团队Scrum Master尺寸Scrum团队规模 - 3到9自组织团队知道完成工作的最佳方式。没有人告诉自组织团队该做什么。跨职能团队拥有完成工作所需的所有技能，无需任何外部帮助。产品拥有者代表委员会或受其影响。与利益相关者和Scrum团队合作。管理产品积压解释产品待办事项。确定工作项的优先顺序。确保产品积压易于理解和透明。清楚地定义要处理的项目。确保开发团队了解产品待办事项中的项目在产品负责人中添加/删除/更改的任何内容都应通过产品所有者进行。接听电话以释放工作项。Scrum Master确保团队清楚地理解和采用Scrum。是Scrum团队的仆人领导者。删除障碍物保护团队免受无用的交互，最大限度地提高Scrum团队创造的业务价值。根据要求促进Scrum事件。确保会议时间安排。开发团队在每个Sprint结束时提供可能可释放的“完成”产品增量。它们是自组织和跨职能的。没有人告诉开发团队什么和如何做。没有标题是允许的。所有人都是团队中的开发人员。不能创建子团队。他们对Sprint项目负责。开发团队负责任务并提供估算。这就是我们在Scrum团队角色和责任方面的全部内容。我们讨论了每个团队成员所承担的责任以及他们作为一个整体团队的工作方式。Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

BPMN（业务流程建模符号） 是业务流程建模现代化的标准，由BPMI符号工作组五月制定2004年版的2.0 BPMN发布于2010年在英国最初的规范写由对象管理组。 BPMN的目标是：负责流程实施的技术专家;创建和改进流程的业务分析师;监控和控制流程的经理。通过这种方式，BPMN可以作为业务流程及其实现之间的链接。BPMN使用简单的图形表示法将业务流程可视化为图表。这些图形元素对用户来说很直观，并允许他们构建复杂的语义结构。业务用户发现使用表示为图表的流程非常方便，许多分析师使用BPMN来解决这个问题。使用BPMN设计的所有流程模型都是_可执行的_，不仅仅是在纸上描述，这意味着它们可以在任何BPM系统中运行。计算机程序将图表转换为实时运行的实际可执行进程。这 实际在BPMN建模和阅读业务流程的课程是一套用实际的例子，它会教你如何与流行的工作经验BPMN标准。为了提供课程的示例，我们使用了ELMA业务流程管理软件。这个独特的课程介绍了使用BPMN中描述的业务流程的核心概念。这是本课程的第一课，我们试图使其简单易懂，最重要的是，有用！第1课在BPMN中，通过具有一系列图形元素的图来描述过程。这种可视化使用户易于理解过程的逻辑。BPMN主要用于设计和读取业务流程的简单和复杂图表。为此，BPMN标准按类别对图形元素进行分类：因此，使用业务流程图的用户可以轻松识别元素。使用BPMN描述的任何过程都表示为根据某些业务规则因此或同时执行的多个步骤（活动）。看看“订单处理”流程，该流程可用于销售和租赁自行车的在线商店。图1“订单处理”流程您应该始终从“ 开始事件”中读取进程。图1.1开始事件从名称中可以看出，“ 开始事件”标识了流程的起点; 它只能有输出序列流。在BPMN中，起始事件由具有开放中心和圆形边界的圆圈表示。在我们的示例中，“ 开始事件”可以是电话呼叫，也可以是来自商店网站上留下的客户的消息。 从 Start Event开始，该过程遵循顺序流程，直到它到达 End Event ; 一个进程可以有几个结束事件。图1.2结束事件一个结束事件 指定了一个进程内的路径完成; 它只能有传入的序列流。一个结束事件 是通过用粗实线边界的圆表示。在我们的示例中，结束事件是将商品交付给客户。 请注意，在ELMA中，开始事件 和结束事件也按颜色区分，这就是为什么它们分别显示为绿色和红色圆圈的原因。工作流程由开始 事件和结束 事件之间的各种元素可视化。表示在该过程中执行的工作的核心元素称为活动。活动是BPMN的可执行元素，可以是原子的也可以是非原子的（复合）。Activity的原子类型称为任务。它以图形方式显示为圆角矩形。最常见的任务代表用户完成的工作，这就是为什么它通常被称为用户 任务。在我们的示例中，任务活动是：“处理客户请求”，“填写购买表单”和“填写租赁表单”。 图1.3用户任务BPMN的另一个广泛使用的元素是网关。在图形上，它显示为菱形，用于确定决策和评估条件。基本上，Gateway是一个分支点，通过拆分和合并来控制流程。图1.4。网关在我们的示例中，客户可能想要购买或租用自行车，并且根据该决定，订单被处理为购买或租赁。在流程图中，网关是决定点，指定每种情况下顺序流必须采用的方式。 在接下来的课程中，我们将了解其他BPMN 2.0图形元素及其在实践中的使用。熟悉BPMN的基本过程元素后，即使是最复杂的过程图，也可以阅读和理解。Business Process ModelingWhat is BPMN?BPMN Orchestration vs Choreography vs CollaborationBPMN Activity Types ExplainedBPMN Artifact Types ExplainedBusiness Process Modeling Software ToolBPMN Diagram and Tools - Visual ParadigmHow to Draw BPMN Diagram?Easy-to-Use BPMN Tools尝试BPMN在线例子（单击->即时编辑)

敏捷软件开发敏捷是世界上使用最广泛，最受认可的软件开发框架之一。大多数组织已经以某种形式采用了它，但是在采用计划的成熟度方面还有很长的路要走。本系列教程的唯一目的是将技术和非技术专业人员融入敏捷世界。我们将逐步引导您完成敏捷之旅，直到您了解使用敏捷背后的理念，优势以及如何实践它。本系列旨在使读者能够将敏捷和Scrum学习应用到他们的工作中。这个特别的教程专门向您解释为什么需要敏捷以及如何创建它。这里的基础是让您了解软件开发行业中敏捷采用的概念。敏捷的历史敏捷出生在一个晴朗的日子，当时有17个人具有不同的开发方法背景，在一起探索可能的替代软件开发解决方案，可以共同进行头脑风暴，寻求可能会缩短开发时间并减少文档的需求量。当时，软件开发过去发生的时间太长，以至于当项目准备交付时，业务已经向前发展，需求已经发生变化。因此，即使项目能够实现其既定目标，也无法满足业务需求。因此，这些不同软件工程技术的精英聚集在一起，他们会议的最终结果就是他们所谓的“敏捷宣言”，我们将在本系列的下一个教程中详细讨论。但是那天出生的敏捷并不是我们今天在组织中看到的。专家们同意的方法被称为“轻量级”且速度快。但是，本次会议的主要成果是认为更快的产品交付和持续的反馈是实现软件开发成功的关键。现有的瀑布技术过于繁琐，在最终产品准备交付之前没有提供反馈。这意味着没有进行要求修正的余地，并且在整个产品准备好之前，客户对进度没有任何看法。这就是这些专家想要避免的。他们想要一个能够持续反馈的解决方案，以避免后期返工的成本。敏捷挑战当时现有的瀑布技术过于繁琐，在最终产品准备交付之前没有提供反馈。它被称为开发的瀑布模型，因为团队首先完成了一步，然后才进入下一步。这意味着没有进行要求修正的余地，并且在整个产品准备好之前，客户对进度没有任何看法。这就是这些专家想要避免的。他们想要一个可以持续反馈的解决方案，以避免在以后阶段返工的成本。这就是为什么敏捷也是关于自适应和持续改进的原因，同时也是关于持续反馈和交付速度的原因。什么是敏捷承诺？敏捷承诺敏捷不仅仅是在开发软件时应用设定的实践。它还带来了团队思维方式的变化，这促使他们构建更好的软件，协同工作并最终让他们成为一个满意的客户。敏捷的价值观和原则使团队能够转移他们的注意力并改变他们构建更好软件的思维过程。敏捷到底是什么？敏捷不是一套规则。敏捷不是一套指导方针。敏捷甚至不是一种方法论。相反，敏捷是一套原则，鼓励灵活性，适应性，沟通和工作软件超越计划和流程。它在所谓的敏捷宣言中非常简洁地被捕获。敏捷软件开发使团队能够在开发复杂项目时更有效地协同工作。它由练习迭代和增量技术的实践组成，这些技术很容易被采用并显示出很好的结果。在将敏捷应用于行动中，我们有各种基于敏捷的方法去满足软件开发行业的所有需求，从软件设计和架构，开发和测试到项目管理和交付。不仅如此，敏捷方法和方法还为流程改进打开了一个范围，作为每个交付的一个组成部分。敏捷是一种软件开发的实践理念，建构一个自给自足且跨职能的团队致力于通过迭代进行持续交付，并通过收集最终用户的反馈在整个过程中发展。如何练习敏捷？各种多样化行业都有各种敏捷方法论。然而，所有这些方法中最流行的方法是：Scrum看板 (Kanban)极限编程 (XP)所有这些方法都侧重于精益 (Lean) 软件开发，并有助于有效和高效地构建更好的软件。这就是敏捷引言的全部内容。该部分的结构旨在帮助您了解团队在敏捷模式和思维模式下工作时应采用的核心价值观和原则。敏捷方法论和模型敏捷方法论简介：众所周知，敏捷是一种软件开发方法。我们还了解了敏捷创始人在敏捷宣言中提到的价值观和原则。在我们最初的讨论中，我们还避开了敏捷和传统瀑布模型之间的差异。在本教程中，我们将了解敏捷方法的优缺点。我们会看到什么是scrum？它与敏捷有何不同？然后我们将了解不同组织正在使用的各种敏捷方法，以及如何使用它们实现敏捷。您还将能够理解这些方法的不同之处以及优缺点。敏捷方法论的优点下面给出了敏捷方法的各种优点：客户在每次迭代 (iterative) /冲刺 (Sprint) 结束时不断获得项目进度的外观和感觉。每个sprint都为客户提供了一个工作软件，该软件根据他们提供的完成定义满足他们的期望。开发团队对不断变化的需求做出了很好的响应，即使在开发的高级阶段也能适应变化。持续的双向沟通 (feedback) 使客户参与其中，因此所有利益相关者 (Stakeholders) - 业务和技术 - 都能清楚地了解项目的进展情况。产品设计高效，满足业务需求。敏捷方法论的缺点虽然敏捷方法有几个优点，但它也有一些缺点。他们是：＃1）不希望使用全面的文档，这会导致敏捷团队错误地解释这一点，因为敏捷不需要文档。因此严谨性会因文档而丢失。应该通过不断询问自己这是否是足够的信息来避免这种情况。＃2）有时，在项目开始时，要求并不十分清晰。团队可能会继续发现客户的愿景已经重新调整，在这种情况下，团队需要整合许多变更，而且很难衡量最终结果。敏捷方法的类型世界各地都有几种敏捷方法。我们将详细了解最受欢迎的四个。＃1）ScrumScrum很容易被认为是最流行的敏捷框架。“scrum”一词被大多数从业者认为是“敏捷”的同义词。但这是一种误解。Scrum只是您可以实现敏捷的框架之一。Scrum这个词来自体育橄榄球 (Rugby)。球员们在一个互锁的位置挤在一起推着对手。每个球员在他们的位置上都有明确的角色，并且可以根据情况的需求发挥进攻和防守的作用。同样，IT中的Scrum相信赋予自我管理的开发团队有三个具体且明确定义的角色。这些角色包括 - 产品负责人（PO），Scrum Master（SM）以及由程序员和测试人员组成的开发团队。它们在迭代时间盒装持续时间中一起工作，称为冲刺。第一步是PO创建产品待办事项。这是scrum团队要做的事情的待办事项列表。然后scrum团队选择优先级最高的项目并尝试在称为sprint的时间框内完成它们。记住所有这一切的更简单方法是记住3-3-5框架。这意味着scrum项目有3个角色，3个工件，5价值 和5个事件。这些是 -3 角色： PO，Scrum master和开发团队。3 工件：产品Backlog，Sprint Backlog和产品增量。5 价值: 集中，勇气， 开放性，承诺，尊重。5 事件： Sprint，Sprint计划，Daily Scrum，Sprint评论和Sprint回顾。我们将在后续教程中更详细地了解每个内容。＃2）看板 (Kanban)看板是日语术语，意思是卡片。这些卡包含要在软件上完成的工作的详细信息。目的是可视化。每个团队成员都了解通过这些视觉辅助工作要完成的工作。团队使用这些看板卡进行持续交付。就像Scrum一样，看板也可以帮助团队有效地工作，并促进自我管理和协作的团队。但是这两者之间也存在差异 - 比如在scrum sprint期间，团队正在处理的项目是固定的，我们无法向sprint添加项目，而在看板中，如果有可用容量，我们可以添加项目。当需求经常变化时，这尤其有用。同样，另一个区别是，虽然scrum已经定义了PO，Scrum master和开发团队的角色，但是在Kanban中没有这样的预定义角色。另一个不同之处在于，尽管scrum建议对产品待办事项进行优先排序，但看板没有这样的要求，而且完全是可选的。因此，看板需要较少的组织并避免非增值活动，并且适用于需要对变化做出响应的过程。＃3）精益 (Lean)精益是一种专注于减少浪费的理念。它是如何做到的？在精简中，您将流程划分为增值活动，非增值活动和基本的非增值活动。任何可归类为非增值活动的活动都是浪费，我们应该尝试在过程中消除这种浪费，使其更加精简。更精简的流程意味着更快的交付和更少的工作浪费在任务上，这无助于实现团队目标。这有助于优化软件开发周期中的每个步骤。这就是精益原则从精益制造转变为软件开发的原因。通过应用以下所示的七项精益原则，可以在任何IT项目中使用精益软件开发：正如他们的名字所暗示的，这些都是不言自明的。消除浪费是第一个也是最重要的精益原则，我们看到了如何做到这一点，我们只是将活动分类为价值和非增值。非值添加活动可以是代码的任何部分，可能使其不那么健壮，增加所涉及的工作量并占用大量时间而不添加合理的业务价值。它也可能是模糊的用户故事或不良测试或添加大图中不需要的功能。第二个原则放大学习再次易于理解，因为团队需要各种技能，以在快速变化的环境中提供产品，新技术可以在短时间内出现。做出迟到的决定可以在减少返工的情况下获得回报，就像预期会有任何变更，然后更好地延迟，以便团队不必在业务需求变化时重做工作。但是这里总是存在一种权衡，因为团队需要平衡这一点与提供更快速的第四个原则。推迟决策不应影响整体交付，也不得减少工作节奏。一只眼睛应该始终在完整的画面上。赋予权力的团队现在也非常普遍，这甚至是敏捷的建议。赋权团队更负责任，可以更快地做出决策。拥有权力的团队的所有权意识可以带来更好的结果。为了赋予团队权力，应该允许他们自己组织并自己做出决定。因此，我们看到精益和敏捷有很多共同之处，只有一个明显的区别 - 精益团队可以帮助改进产品，敏捷团队就是实际构建产品的团队。＃4）极限编程（XP）极限编程是另一种最流行的敏捷技术。根据extremeprogramming.org，第一个XP项目于1996年3月6日开始。他们还提到XP以五种不同的方式影响软件项目开发 - 沟通，简单，反馈，尊重和勇气。这些被称为XP的值。其中，一切都始于沟通。XP团队定期与业务团队和其他程序员协作，并从第一天开始构建代码。这里的重点是在其他视觉辅助工具的帮助下尽可能地进行面对面的交流。极端程序员还会构建一个简单的代码，并从第一天开始获得反馈。重点是不要过分或预测尚未共享的要求。这使设计简单，只生产出满足要求的最小产品。反馈有助于团队改进并提高工作质量。这有助于他们在彼此学习的过程中建立对彼此的尊重，并学习如何分享他们的观点。这也给了他们勇气，因为他们知道他们已经收集了每个人的最佳想法，并根据其他人的反馈产生了一个好的产品。因此，他们也不害怕包含变更或收到有关其工作的进一步反馈。这在需求经常变化的项目中特别有用。持续的反馈将帮助团队以勇气包含这些变化。因此，我们已经看到了不同的敏捷方法，如Scrum，XP，看板和精益，以及它们各自的优缺点。现在，我们可以轻松区分它们，也欣赏它们之间的微妙差异。我们还了解了每种方法的基本原理，并了解了如何在需要时将它们应用于我们的项目中。在下一部分中，让我们了解Scrum的一切。Scrum框架 (Scrum Framework)SCRUM是敏捷方法中的一个过程，它是迭代模型和增量模型的组合。传统瀑布模型的主要障碍之一 是 - 在第一阶段完成之前，应用程序不会移动到另一阶段。而且，如果在周期的后期阶段发生一些变化，那么实施这些变化就变得非常具有挑战性，因为这将涉及重新审视早期阶段并重做变更。SCRUM的一些关键特性包括：自我组织和专注的团队。没有巨大的要求文件，而是有一个非常精确和重点的故事。跨职能团队作为一个单元一起工作。与用户代表密切沟通以了解功能。有一个最长一个月的明确时间表。Scrum不是一次完成整个“事物”，而是以给定的间隔做一些事情。在提交任何内容之前，会考虑资源功能和可用性。要很好地理解这种方法，理解SCRUM中的关键术语非常重要。重要的SCRUM术语1）Scrum团队Scrum团队由7人组成，其中包括+或 - 两名成员。这些成员是能力的混合体，由开发人员，测试人员，数据库人员，支持人员等组成，还包括产品所有者和Scrum主管。所有这些成员通过紧密协作一起工作，以递归和确定的间隔，开发和实现所述特征。SCRUM团队的坐姿安排在他们的互动中起着非常重要的作用，他们从不坐在小隔间或小木屋里，而是一张巨大的桌子。2）冲刺 (Sprint)Sprint是预定义的时间间隔或时间范围，其中必须完成工作并使其准备好进行审查或准备进行生产部署。这个时间框通常在2周到1个月之间。在我们的日常生活中，当我们说我们遵循1个月的Sprint周期时，它只是意味着我们在任务上工作了一个月，并准备好在该月底之前进行审核。3）产品负责人 (Product Owner)产品所有者是要开发的应用程序的主要利益相关者或主要用户。产品所有者是代表客户方的人。他/她拥有最终权力，应始终为团队提供。当任何人有任何需要澄清的疑问时，他/她应该可以到达。对于产品所有者而言，了解并且不在sprint中间或sprint已经开始时分配任何新要求非常重要。4）Scrum MasterScrum Master是Scrum团队的推动者。他/她确保Scrum团队富有成效和进步。如有任何障碍，scrum master会跟进并为团队解决问题。SCRUM Master是PO和团队之间的中介。他/她让PO了解Sprint的进展情况。如果团队存在任何障碍或问题，请与PO讨论并解决问题。就像团队的每日站立时一样，每天都会有一个关于PO的SCRUM Master的站立。5）业务分析师（BA）业务分析师在SCRUM中扮演着非常重要的角色。此人负责完成要求并在需求文档（基于其创建用户素材）中起草。如果用户故事/接受标准中存在任何含糊之处，他/她是技术（SCRUM）团队接洽的人，然后他将其接收到PO或者如果可能的话自行解决。在大型项目中，可能有超过1个BA，但在小规模项目中，SCRUM Master也可能作为BA。项目启动时获得学士学位总是一个好习惯。6）用户故事 (User Story)用户故事只不过是必须实现的要求或功能。在scrum中，我们没有那些巨大的需求文档，而是需求在一个段落中定义，通常具有以下格式：作为<用户/用户类型> 我想<一些可实现的目标/目标> 实现<做某事的某些结果或理由>例如：作为[管理员]，我想[要密码锁]，实现[以防用户连续3次输入错误的密码以限制未经授权的访问]。应该遵守用户故事的一些特征。用户故事应该简短，逼真，可以估计，完整，可协商和可测试。用户故事永远不会在Sprint中间被更改或更改。SCRUM Master和BA（如果适用）负责确保PO使用适当的“验收标准”正确起草用户故事“。如果要进行任何会影响sprint发布的更改，那么这些故事将从sprint中撤出，或者按照可用时间完成。每个用户故事都有一个验收标准 (Acceptance Criteria)，应由团队明确定义和理解。验收标准详细说明了提供支持文档的用户故事。它有助于进一步完善用户故事。团队中的任何人都可以写下验收标准。测试团队根据这些验收标准确定测试用例/条件。7）史诗 (Epic) 史诗是模棱两可的用户故事，或者我们可以说这些是未定义的用户故事，并保留用于未来的冲刺。试着把它与生活联系起来，假设你要去度假。当你下周去的时候，你已经准备好了所有的东西，比如你的酒店预订，观光，旅行支票等等。但是你明年的假期计划呢？你只有一个模糊的想法，你可能会去XYZ的地方，但你没有详细的计划。史诗就像你明年的假期计划一样，在那里你只知道你可能想去，但是在这个时间点你不知道所有这些细节的地点，时间，对象。以类似的方式，存在将来需要实现的特征，其细节尚不清楚。大部分功能都以Epic开头，然后分解为可以实现的故事。8）产品积压 (Product Backlog)产品待办事项是一种存储所有用户故事的存储桶或源。这由产品负责人维护。产品待办事项可以设想为产品所有者的愿望清单，产品所有者根据业务需求对其进行优先级排序。在计划会议期间（参见下一节），从产品待办事项中获取一个用户故事，然后团队进行头脑风暴，理解并完善它，并在产品所有者的干预下共同决定要采取哪些用户故事。9）Sprint Backlog根据优先级，用户故事一次一个地从Product Backlog中获取。Scrum团队的头脑风暴决定了它的可行性，并决定了在特定冲刺上工作的故事。Scrum团队在特定sprint上工作的所有用户故事的集合列表称为Sprint backlog。10）故事点 (Story Point)故事点是用户故事复杂性的定量指示。基于故事点，确定故事的估计和努力。故事点是相对的而不是绝对的。为了确保我们的估计和努力是正确的，检查用户故事并不重要是很重要的。用户故事越精确，越小，估计就越准确。每个用户故事都根据Fibonacci系列（1,2,3,5,8,13和21）分配到故事点。数字越高，复杂就是故事。确切地说如果你给出1/2/3的故事点，那就意味着故事很小而且复杂度很低。如果你给分数为5/8，它是一个中等复杂的13和21非常复杂。这里的复杂性包括开发和测试工作。为了确定一个故事点，头脑风暴发生在Scrum团队中，团队共同决定一个故事点。开发团队可能会为特定故事提供3个故事点，因为对于他们来说可能有3行代码更改，但测试团队给出了8个故事点，因为他们觉得这个代码更改会影响更大的模块所以测试工作量会更大。无论你给出什么样的故事，你都必须证明这一点。因此，在这种情况下，头脑风暴发生，团队集体同意一个故事点。无论何时决定故事点，请记住以下因素：故事与其他应用程序/模块的依赖关系。资源的技能组合。故事的复杂性。历史学习。用户故事的接受标准。如果您不了解特定故事，请不要调整大小。每当故事大于或等于8分时，它就被分解为2个或更多故事。11）烧掉图表刻录图表是一个图表，显示了scrum任务的估计v / s实际工作量。它是一种跟踪机制，通过该机制，对于特定的冲刺，跟踪日常任务以检查故事是否正在朝着完成提交的故事点的方向前进。示例：要了解这一点，请查看下图：我假设：2周冲刺（10天）2个实际在冲刺上工作的资源。“故事” - >此列显示为sprint拍摄的用户故事。“任务” - >此列显示与用户素材关联的任务列表。“努力” - >此栏显示了努力。现在，这项措施是完成任务的总工作量。它没有描述任何特定个人的努力。“第1天 - 第10天” - >此列显示完成故事的剩余时间。请注意，小时不是已经完成的小时，但仍然是剩下的小时数。“估计的努力” - >是努力的总和。对于“开始”，它只是整个单独任务的总和：SUM（C5：C15）必须在1天内完成的总工作量是70/10 = 7.因此在第1天结束时，努力应该减少到70 - 7 = 63.以类似的方式，计算所有的直至第10天，估计的努力量应为0（第16行）“实际努力” - >顾名思义，实际上是完成故事的努力。也可能发生实际努力增加或减少的估计值。您可以使用内置函数和Excel中的图表来创建此燃尽图表。刻录图表步骤将是：输入所有故事（A5列 - A15列）。输入所有任务（B5 - B15列）。输入天数（第1天 - 第10天）。输入起动工作（总结任务C5 - C15）。应用公式计算每天（第1天至第10天）的“估计工作量”。在D15（C16- $ C $ 16/10）输入公式并将其拖动一整天。对于每一天，输入实际的努力。在D17（SUM（D5：D15））输入公式，用于总结剩余的实际工作量，并将其拖动到所有其他日期。选择它并按如下方式创建图表：12）速度Scrum团队在sprint中归档的故事点总数称为Velocity。Scrum团队通过其速度来判断或引用。话虽如此，但应该记住，这里的目标不是达到最大的故事点，而是要获得高质量的交付，尊重Scrum团队的舒适程度。例如：对于特定冲刺：用户故事总数为8，故事点如下所示。所以这里的速度将是故事点的总和= 30完成的定义：当所有故事都完成后，Sprint被标记为完成，所有开发，研究，QA任务都标记为“已完成”，所有错误都是固定关闭的，否则可以在以后完成（如不完全相关或不太重要）在备份日志中提取并添加代码审查和单元测试，估计的小时数已经达到了任务中的实际小时数，最重要的是，已经向PO和利益相关者提供了成功的演示。在SCRUM方法论中完成的活动＃1）规划会议计划会议是Sprint的起点。这是整个Scrum团队聚集的会议，SCRUM Master根据产品积压和团队头脑风暴的优先级选择用户故事。根据讨论，Scrum团队根据Fibonacci系列决定故事的复杂程度并根据其进行调整。团队确定任务以及完成用户故事实施所需的工作（以小时为单位）。很多时候，计划会议之前都是“预先计划会议”。这就像scrum团队在参加正式计划会议之前所做的一项功课。团队试图在计划会议中写下他们想要讨论的依赖关系或其他因素。＃2）执行Sprint任务顾名思义，这些是scrum团队完成任务并将用户故事带入“完成”状态所做的实际工作。＃3）每日站立在冲刺周期中，scrum团队每天都会遇到，不超过15分钟（可能是一个直接的电话，建议在一天开始时）和状态3点：昨天团队成员做了什么？团队成员今天计划做什么？任何障碍（障碍）？促进这次会议的是Scrum大师。如果任何团队成员遇到任何困难，scrum master会跟进以解决问题。在Stand ups中，董事会也会进行审核，并自行显示团队的进展情况。＃4）审核会议在每个sprint周期结束时，SCRUM团队再次会面并向产品所有者演示实现的用户故事。产品所有者可以根据其验收标准交叉验证故事。Scrum大师再次负责主持这次会议。同样在SCRUM工具中，Sprint关闭，任务标记完成。＃5）回顾会议回顾会议在审议会议之后召开。SCRUM团队会见，讨论并记录以下几点：Sprint（最佳实践）期间进展顺利？什么在Sprint中表现不佳？得到教训行动项目。Scrum团队应该继续遵循最佳实践，忽略“不是最佳实践”，并在随后的冲刺中实施经验教训。回顾会议有助于实施SCRUM流程的持续改进。流程如何完成？一个例子！阅读了SCRUM的技术术语。让我试着用一个例子来演示整个过程。例：步骤1：让我们拥有一个由9人组成的SCRUM团队，其中包括1个产品所有者，1个Scrum master，2个测试人员，4个开发人员和1个DBA。步骤2：Sprint决定遵循4周的周期。所以我们从6月5日到 7 月4 日开始为期一个月的Sprint 。步骤3：产品所有者在产品待办事项中具有优先级的用户故事列表。步骤＃4： 团队决定于 6月4 日举行“预先规划”会议。产品所有者从产品积压中获取1个故事，描述它并留给团队进行头脑风暴。整个团队直接与产品所有者讨论并进行沟通，以便清楚地了解用户故事。以类似的方式，采用各种其他用户故事。如果可能的话，团队也可以继续调整故事的大小。在所有讨论之后，个人团队成员回到他们的工作站和确定每个故事的各自任务。计算他们将要工作的确切小时数。让我们来看看会员如何结束这些时间。总工作小时数= 9 减1小时休息，减1小时会议，减去1小时电子邮件，讨论，故障排除等 所以实际工作时间= 6.Sprint 期间的总工作天数= 21天。 总可用小时数= 21 * 6 = 126. 该成员休假2天= 12小时（每个成员有所不同，有些可能请假，有些可能不休。） 实际小时数= 126 - 12 = 114小时。这意味着该成员实际上可以在此sprint中使用114小时。所以他将打破他的个人冲刺任务，总共达到114小时。第五步： 6月5 日，整个Scrum团队召开“规划会议”。产品待办事项中的用户故事的最终判决已完成，故事将移至Sprint Backlog。对于每个故事，每个团队成员都会声明他们确定的任务，如果需要，他们可以讨论这些任务，可以调整大小或调整大小（请记住Fibonacci系列!!）。Scrum主人或团队在工具中输入他们各自的任务以及每个故事的小时数。完成所有故事后，Scrum主人注意到了最初的Velocity并正式启动了Sprint。步骤＃6：Sprint启动后，根据分配的任务，每个团队成员开始处理这些任务。第7步：团队每天开会15分钟并讨论3件事：他们昨天做了什么？他们今天打算做什么？任何障碍（障碍）？步骤＃8：Scrum master在“Burn down chart”的帮助下每天跟踪进度。步骤＃9：如果遇到任何障碍，Scrum主管会跟进解决这些问题。步骤＃10： 7 月4 日，团队再次召开审查会议。成员向产品所有者演示实现的用户故事。步骤＃11： 7 月5 日，团队再次召开会议，讨论回顾什么进展顺利？什么不顺利？行动项目。步骤＃12： 7 月6 日，团队再次召开下一次冲刺的预先计划会议，并继续进行循环。推荐阅读Scrum ArtifactsWhat are Scrum Artifacts?Definition of Done vs Acceptance CriteriaWhat is Definition of Ready in Scrum?How to Write a Sprint Goal?What is Product Backlog in Scrum? Who Responsible for It?How to Refine Product Backlog?Agile & Scrum BasisComprehensive Scrum GuideWhat are Scrum’s Three Pillars?What is Agile Software Development?Scrum in 3 MinutesWhat are the 5 Scrum Values?What is the Evolution of Scrum?Agile & Scrum PrinciplesThe Agile Manifesto and Twelve Principles10 Most Frequently Mentioned Basic Rules in ScrumScrum RolesWhat is Scrum Team?What is a Self-Organizing Team in Scrum?How Scrum Team Works? - A Brief GuideHow to be a Good Product Owner in Scrum Project?What is Product Owner’s Role in Scrum? ...

每日Scrum (Daily Scrum Meeting) 可能是开发团队当天最令人沮丧的活动之一。虽然这个简短的站立是为了让每个人都能快速了解每个团队成员的活动，但它往往会陷入我们都鄙视的冗长会议中。那么我们如何才能重新获得日常反会议的简单性呢？这些最常见问题的解决方案将帮助您解决问题。问题：我们将Daily Standup格式化为会议当一群人离开办公桌聚在一个房间谈论某事时，你怎么称呼它？是的，你的本能是正确的，它被称为会议，而不是立场（即使你的Scrum大师让每个人都站起来）。每日站立或争吵的目标是最大限度地提高效率，消除团队在大厅里蜿蜒前行，再喝一杯咖啡是一个很好的方法。解决方案：将Scrum Master发送给团队这提出了一个新问题：如果站立不应该在会议室举行，那么团队应该聚集在哪里？那么为什么不在他们已经在使用的空间！正如我们在之前的文章中所讨论的那样，一个理想的开发团队在一个房间里一起工作，以便让所有的创意成果汇集在一起。这个环境也是进行站立的最有效的地方，即使Scrum主人必须喘气来到他们身边。问题：每日站立感觉就像一次重大的中断想象一下，你正在更换汽车中的油，你楔入发动机下方，肘部深入车内，准备拔出机油滤清器（试着想象一下你以前从未真正做过这个） 。现在想象一下，你必须放弃一切，完全离开汽车，告诉大家你在换油方面取得的进展。现在你可以放松自己回到汽车下面，将你的手臂楔回油过滤器并重新开始。如果这是日常事情，那么我也会开始生气。解决方案：尽早完成理想情况下，应该在早上和任何人开始执行当天任务之前首先进行站立。实际上，这并不总是有效，因为开发人员可能会在不同的时间进入。在任何认真的工作开始之前，尽早做好准备。如果一个重要的利益相关者，产品负责人或团队成员以外的任何人不在那里，那么他们会错过它。问题：没有人关注我们都在这里，做每日站立，每个团队成员轮流告诉每个人他昨天所做的事情的细节。二十分钟后，几乎所有人都将手机拿出来，并没有灵魂注意到。我们现在基本上没有工作日的1/24丢失到基本无用的Scrum练习解决方案：快速有趣“我昨天修复了那个日期/时间转换错误，今天我要抓住那个排序速度任务。”“昨天遇到了搜索问题的一个问题，它只返回了最多400个结果，得到了解决了我今天将完成用户管理页面的搜索任务。“现在想象一下7人团队中的每个团队成员都会发生这种情况。站起来相当快不是吗？会议应该进行的唯一时间是，如果有人有一个非常有趣的问题，那么开发人员可能会花一些时间讨论它。站立应该是非常短或非常有趣但不乏味。如果它很无聊，那就是你没有教育团队如何利用这段时间是你的错（作为Scrum Master）。简而言之：每日站立是建立一个伟大的Scrum团队的一个主要部分，前提是你不要把它变成另一个公司活动。站立在Scrum团队周围，没有别的。Scrum团队需要花费很少的时间（强调小的）来集中他们的进步，目标和对他们来说很重要的问题。在站立期间你做的任何事都等于开销。从那里开始，团队可以围着房间四处聊聊进度和问题，每个人都会在10-15分钟内重新开始工作，除非出现非常有趣的事情。

我们汇总了您可能会在面试中获得的20个面试问题的清单，以及有效的答案，帮助您为梦想的敏捷Scrum工作做好准备！1.在30秒内解释敏捷。敏捷是一种方法和行为框架，鼓励“及时”生产，使客户能够更快地获得高质量的软件。2.敏捷和传统项目管理（瀑布）之间有什么区别？敏捷鼓励包括设计，开发和测试在内的一切都在同一时间完成。相反，传统的项目方法在下一个开始之前关闭并完成一个阶段。敏捷鼓励短暂，频繁的反馈循环并包含对需求的更改。在瀑布中，通常直到项目结束才收集反馈，并且不鼓励进行更改。3.您是认证Scrum Master吗？如果您没有认证并且他们问您这个问题，请不要感到惊讶！职位描述可能需要或不需要认证 - 面试官可能会或可能不会认为认证足以使专业知识成为您所申请职位的良好候选人。如果您还没有Agile Scrum Master认证，请告知他们您是否计划在不久的将来投资该认证。请务必提及您在该领域多年的经验。4. Scrum中有哪些角色？Scrum只规定了三个角色：产品负责人，Scrum Master和交付团队。理想情况下，这些角色应该是跨职能的，而不是在其他项目之间共享。许多Scrum大师没有机会与一个跨职能或专注的团队合作，因为该组织的抵制或无法允许一些人称之为“奢侈品”。这个问题可能会导致面试官问你怎么样会处理与团队中没有设计师或测试人员的团队合作，或者如何处理非专职团队。准备好了！5.什么是每日站立？关于敏捷的一个面试问题肯定是每日站立。答案？每天，最好是在早上，团队会面不超过15分钟回答三个问题：你昨天做了什么？ 你今天打算做什么？ 是否存在阻碍您工作的障碍或障碍？这次Scrum仪式并不意味着成为利益相关者的状态会议，而是一种激励团队并让他们为当天设定焦点的方式。6.描述Sprint计划会议中发生的事情。在Sprint计划中，产品负责人介绍了sprint的目标，并讨论了高优先级产品待办事项。交付团队然后选择下一个sprint的工作量。7. Scrum Master的作用是什么？以下是如何处理这样的Scrum Master面试问题：Scrum Master为团队服务并保护他们免受任何可能妨碍他们完成冲刺目标的干扰。他们还会删除障碍，教会团队自我组织，并担任教授敏捷和Scrum价值观和原则的教练。8.敏捷和Scrum之间有区别吗？是! 敏捷是Scrum所涵盖的更广泛的保护伞。敏捷有四个主要价值观和十二个原则。Scrum有自己的一套价值观和原则，并提供一个轻量级的“框架”来帮助团队变得敏捷。9.列举其他一些敏捷框架。除了Scrum之外，还有其他框架，例如看板，测试驱动开发和特征驱动开发。提及您遵循的框架并提供方案。10.什么时候应该使用瀑布而不是Scrum？如果需求简单，可预测，完全定义和理解，并且不会更改，请使用瀑布。11.您会为您的项目推荐自动化测试吗？Scrum鼓励使用自动化性能或回归测试，以便您可以尽快地连续交付软件。提供您的团队可能使用过的任何自动化测试工具的示例。12.你的短跑多久了？理想的冲刺长度在一到四周之间，两周的冲刺是最广泛使用的。13.什么是速度？速度是过去3-4次冲刺的平均点数。它用于帮助预测何时交付积压物品。14.如果有人想改变要求，可以吗？是。敏捷鼓励客户和利益相关者经常反馈，以便改进产品。我们需要能够接受改变。15.您使用了哪种类型的指标或报告？Sprint，发布刻录和刻录图表是标准报告。大多数公司还希望了解每个sprint完成的故事数量以及发布到生产后发现的缺陷数量。16.什么是烧毁图表？刻录图表显示团队已经烧毁的工作量 - 例如冲刺期间的小时数。讨论你过去如何使用它们。17.什么是回顾？回顾会是检查和调整过程的会议。这个敏捷方法访谈问题正在寻找进行回顾的许多方法 - 所以准备好解释一种或两种格式。18.您一次管理了多少个Scrum团队？这是一个很受欢迎的问题。不要提供Scrum指南，每个团队只有一个Scrum Master作为您的答案！在这个新角色中，您可能需要领导多个团队。注意使用“托管”和“领导”这个词.Scrum Masters不管理，他们领导团队 - 所以一定要在你的回复中使用这个词。你的面试官可能会非常仔细地听！19.您对团队使用了哪些类型的要求？Scrum中的要求是使用标准编写的用户故事，“作为___，我想要__以便我可以___。”作为Scrum Master，您不一定要编写用户故事，但是您可以帮助产品负责人确保用户故事的编写，优先级和准备好冲刺。20.描述交付团队成员似乎没有相处的时间。你是怎么处理的？注意一点冲突总是好的，但是你的面试官正在寻找你成为有效领导者的能力。反思你有几个团队成员，似乎从来没有能够解决问题。您是如何鼓励这些团队成员一起工作的？这是一项团队建设活动吗？你确定他们有一个共同的目标吗？说明你遇到的问题，你如何解决它以及结果。与任何面试准备一样，您需要自定义您的答案，以满足您面试的公司。想想大公司如何在他们的日常实践中使用敏捷Scrum方法。他们[希望充当这个角色的人能够擅长什么？]推薦的Scrum角色文章What is Scrum Team?What is a Self-Organizing Team in Scrum?How Scrum Team Works? - A Brief GuideHow to be a Good Product Owner in Scrum Project?What is Product Owner’s Role in Scrum?Agile Development: How to Become a Qualified Scrum Master?What is Pig and Chicken in Scrum?Project Manager vs Scrum Master vs Project OwnerWhat Are The Three Scrum Roles?What is a Scrum Master? The Role and ResponsibilitiesWhat is Cross-Functional Team in Agile? ...

自我評估作為Scrum大師, 你在扮演什麼角色（上面? 還是下？）哈哈！有些人仍然無法改變舊的思維方式一个伟大的Scrum Master确保整个团队支持所选的Scrum流程;管理超出团队自组织能力的障碍，阻止他们实现Sprint目标;认识到健康的团队冲突并促进建设性的分歧;准备好具有颠覆性，以便在组织内部实施变革;理解自组织的力量;理解稳定的冲刺节奏的价值，并尽一切努力创造和维护它;知道如何真正倾听并且沉默舒适;理解教练的力量，并且用心去学习一些有力的问题;教导产品负责人如何最大化ROI并实现目标;也适合XP，看板和精益。A great Scrum Master (英文原文)Ensures the entire team supports the chosen Scrum process;Manages the impediments that exceed the self-organizing capabilities of the team and it prevents them in achieving the Sprint Goal;Recognizes healthy team conflict and promotes constructive disagreement;Is prepared to be disruptive enough to enforce a change within the organization;Understands the power of a self-organization;Understands the value of a steady sprint rhythm and does everything to create and maintain it;Knows how to truly listen and is comfortable with silence;Understands the strength of coaching and has learned some powerful questions by heart;Teaches the Product Owner how to maximize ROI and meet objectives;Is also competent with XP, Kanban and Lean.推薦的Scrum文章What is Burndown Chart in Scrum?What is the Role-Feature-Reason Template?Sprint Increment vs Potential Shippable Product vs MVP vs MMPWrite SMART Goals & INVEST for User StoriesWhat is DEEP in Product Backlog?How to Write Product Vision for Scrum Project?How to Use Scrum Board for Agile Development?Who Create Product Backlog Items or User Stories in Scrum?What is Agile Estimation?What is Story Point in Agile? How to Estimate a User Story? ...

Scrum框架Scrum是一种管理项目的敏捷方式，通常是软件开发。使用Scrum进行敏捷软件开发通常被视为一种方法论; 但不是将Scrum视为方法论，而是将其视为管理流程的框架。要做Scrum，我们所需要的只是16个必需品，即3个角色，3个文物，5个价值观和5个事件。这些16个要素通过Scrum指南中描述的某些规则和指南绑定在一起。这些规则和指南可帮助Scrum团队尽可能充分利用Scrum框架来创建最大的业务影响。Scrum是3355的组合.scrum框架的核心概念可以简单地记为3.3.5.5，如下所示：3个角色产品拥有者开发团队Scrum Master3件文物产品积压Sprint Backlog - Sprint待办事项列表产品增量- 潜在的可发货产品增量5个事件短跑Sprint计划会议每日Scrum会议Sprint评审会议Sprint回顾会议5个值打开尊重勇气焦点承诺3355的目标落后于三个Scrum支柱透明检查适应“完成”（DoD）的定义是通过Scrum团队的5个事件来实现3个支柱来实现的。3355 Scrum框架Scrum依赖于一个自组织，跨职能的团队。Scrum团队是自我组织的，因为没有整体团队负责人决定哪个人将完成哪项任务或如何解决问题。这些是由整个团队决定的问题。在Scrum中，团队是跨职能的，这意味着每个人都需要从构思到实现。在敏捷开发中，Scrum团队由两个特定角色提供支持。第一个是ScrumMaster，可以被认为是团队的教练，帮助团队成员使用Scrum流程在最高级别执行。Scrum规则 (Scrum Rules)当我提到规则时，我的意思是那些无法修补以适应特定背景的方面。例如：没有3个角色，你不能做Scrum - 产品负责人，开发团队和Scrum Master。当我提到指南时，我指的是那些可能被改变以适应特定背景的方面; 然而，影响只能在实施后进行验证。然后我们相应地检查(insepction) 和调整(adaptation)。例如，Product Backlog Refinement消耗的不超过团队容量的10％ (<10% of the sprint duration)。是容量-小时数;故事点数; ＃天-好吧，没有规则。Scrum团队自我组织并选择最适合他们背景的东西;遵循我们消耗的指导方针，无论如何不超过团队容量的10％。在这篇文章中，我将探讨一些这样的指导方针，这些指南将11个要素绑定在一起，并赋予Scrum团队灵活性以适应这些方面的背景。＃1。开发团队规模：开发团队的规模建议为3-9名成员。根据具体情况，可能会有更多人或更少。它的影响因团队环境而异。来自Scrum指南：不到三个开发团队成员减少了交互，导致生产率降低。较小的开发团队可能会在Sprint期间遇到技能限制，导致开发团队无法提供可能可释放的增量。拥有超过九名成员需要太多协调。大型开发团队为实证过程提供了太多的复杂性。＃2。开发团队的标题/角色： Scrum不承认开发团队中的任何标题/角色。在开发团队中，每个人都是开发团队成员。虽然在组织内，团队成员可能拥有头衔/角色。根据我的经验，我与Scrum有关;我没有遇到任何只有一个职位/角色的团队。＃3。每日Scrum的三种问题格式：我使用过的大多数团队都使用Daily Scrum的3个问题的格式：昨天我做了什么帮助开发团队实现Sprint目标？今天我将做些什么来帮助开发团队实现Sprint目标？我是否看到任何阻碍我或开发团队达到Sprint目标的障碍？令人惊讶的是，这3个问题只是开始使用Scrum的团队的模板。只要他们专注于Sprint目标的进展，开发团队就可以以他们认为合适的任何方式构建Daily Scrum。＃4。事件的时间框：事件的时间框表示事件为1个月冲刺所允许的最长时间。准则是：对于较短的短跑持续时间，它通常较短。 这是否意味着，对于为期两周的Sprint，Sprint Planning的时间限制为4小时，Sprint Review为2小时，Sprint回顾为1小时和半小时？编号 为尽可能满足他们的目的所需要的事件可以短/长;但不能超过最大分配时间。例如：Sprint规划活动为期2周Sprint可能会在2小时内结束，如果达到目的，或者可能会持续到8小时（如果没有）。＃5。进展趋势： Scrum指南建议使用烧毁图表，累积流量等实践来监控进度趋势。但是，团队完全可以自由选择他们认为合适的任何练习来达到目的。根据我的经验，我见过团队创建视觉路线图，基于里程碑的进度，旅程线，发布燃烧图等。虽然，我们还需要记住在复杂的环境中;只有经验数据才能帮助我们做出正确的决定。＃6。估算：该的Scrum指南介绍了积压的产品项目需要估计。他们应该如何估计完全取决于Scrum团队。故事点，理想日，T恤尺码，狗尺码是一些方法。Scrum团队可以做“没有估计”吗？当然，只要Scrum团队能够起草一份支持经验主义的计划; 创建透明度并帮助团队在Sprint结束时创建可能可释放的“完成”增量; 没关系。Scrum团队自行组织选择适合其背景的内容。＃7。工作分解：在“选择的工作将如何完成？”部分。对于Sprint计划，Scrum指南提到-开发团队在Sprint的头几天计划的工作在本次会议结束时分解，通常分为一天或更短时间。这通常有助于发展团队这样做，但这并非强制要求。根据我的经验，我已经看到几个团队没有将工作项目细分到如此精细的水平。他们非常清楚如何将功能转换为“完成”增量。＃8。Sprint评审：这是一项重要的Inspect＆Adapt活动，Scrum团队与主要利益相关方就Sprint期间取得的成果进行合作，以及在下一个Sprint中可以做些什么来优化产品的价值。Scrum指南还描述了Sprint Review的一部分：与会者包括Scrum团队和产品负责人邀请的主要利益相关者产品负责人解释了产品待办事项项目已“完成”且未完成的内容开发团队讨论Sprint期间的情况，遇到的问题以及这些问题是如何解决的开发团队演示了它“完成”的工作并回答了有关增量的问题产品负责人会按原样讨论产品Backlog。他或她根据迄今为止的进展预测可能的目标和交付日期（如果需要）整个小组就下一步做什么进行合作，以便Sprint Review为后续的Sprint Planning提供有价值的信息回顾产品的市场或潜在用途如何改变下一步最有价值的事情审查下一个预期的产品功能或功能版本的时间表，预算，潜在功能和市场对于每年获得资助的Scrum团队来说，每两周进行一次Sprint评估的预算是否合理？也许不吧。 并非所有上述元素都适用于所有Scrum团队。它们作为指导提供，以便Scrum团队可以选择在Sprint评审期间讨论和触及产品交付的各个方面，因为他们认为适合他们的背景。＃9。发布到生产：每个Sprint的目的是创建可能可释放的“完成”增量。这意味着增量需要处于可用状态并符合Scrum团队的DoD。 但是，将增量发布到生产中的选择由产品负责人决定。基于团队的背景和他们创造的增量; Scrum团队可能决定每个sprint执行多个版本，每个sprint一个版本或多个sprint的累积发布;无论如何优化产品的价值。＃10。完成的定义：完成的定义有助于提高透明度并创建对完成工作意味着什么的共同理解。根据Scrum指南，Scrum团队有望扩展其国防部并使其更高质量的更严格。 同样，这不是一个规则。取决于团队的背景; Scrum团队可能会在每次回顾中重新审视它的国防部，或者可能继续使用相同的国防部，除非它学会了新的东西以提高产品的质量。结论：这些只是在Scrum指南中传播的一些指导原则。我想提出这个区别，因为我经常发现Scrum团队对Scrum规则和指南感到困惑。很少有人很常见- 将Sprint Planning的时间框修改为4小时进行为期2周的冲刺，或者开发团队花费太多时间和精力将Product Backlog Items (PBI) 分解为“任务” - 其他人则不那么常见。我相信这篇文章将帮助团队识别Scrum的一些方面，他们可以修改这些方面以适应他们的背景，以及他们能够区分那些无法改变的方面。Scrum ArtifactsWhat are Scrum Artifacts?Definition of Done vs Acceptance CriteriaWhat is Definition of Ready in Scrum?How to Write a Sprint Goal?What is Product Backlog in Scrum? Who Responsible for It?How to Refine Product Backlog?What is Sprint Backlog in Scrum? ...

今天（2017年11月7日），Ken Schwaber 和 Jeff Sutherland 发布了 Scrum 指南的更新。Scrum指南是Scrum的最终定义，由Scrum的创建者Ken和Jeff编写。《Scrum指南》描述了Scrum框架。而且，它只有19页长。通过保持简短的定义，它不仅强制实现一个明确的重点，而且提醒每个人它不是一种方法论。过程是根据团队所处的情况使用框架而产生的。因为Scrum关注复杂的问题，所以不可能定义完整的方法论。相反，Scrum提供了一个简单的框架，鼓励正确的经验过程出现。这使得现在超过1200万人可以练习Scrum，同时在非常不同的情况下解决非常不同的问题。添加了有关Scrum使用的部分： Scrum最初是为管理和开发产品而开发的。从20世纪90年代初开始，Scrum在全球广泛使用：研究和确定可行的市场，技术和产品能力;开发产品和改进;每天多次发布产品和增强功能;开发和维护云（在线，安全，按需）和其他操作环境以供产品使用; 和，维持和更新产品。Scrum已被用于开发软件，硬件，嵌入式软件，交互功能网络，自动驾驶汽车，学校，政府，市场营销，管理组织的运作以及我们日常生活中使用的几乎所有东西，如个人和社会。随着技术，市场和环境的复杂性及其相互作用的迅速增加，Scrum在处理复杂性方面的实用性每天都在证明。事实证明，Scrum在迭代和增量知识转移方面特别有效。Scrum现在广泛用于产品，服务和上级组织的管理。Scrum的本质是一个小团队。个人团队非常灵活和适应性强。这些优势继续在单个，多个，多个团队网络中运行，这些团队开发，发布，运营和维护数千人的工作和工作产品。他们通过复杂的开发架构和目标发布环境进行协作和互操作。当Scrum指南中使用“develop”和“development”这两个词时，它们指的是复杂的工作，例如上面提到的那些类型。更改了“Scrum Master”部分中的措辞，以更好地阐明角色。现在的案文如下： Scrum Master负责推广和支持Scrum指南中定义的Scrum。Scrum Masters通过帮助每个人理解Scrum理论，实践，规则和价值观来实现这一目标。Scrum Master是Scrum团队的仆人领导者。Scrum Master帮助Scrum团队以外的人了解他们与Scrum团队的哪些互动是有用的，哪些不是。Scrum Master帮助每个人改变这些交互，以最大化Scrum团队创造的价值。添加到产品负责人的Scrum Master Service部分 确保Scrum团队中的每个人都能够理解目标，范围和产品领域。将Daily Scrum部分的第一段更新为： Daily Scrum是一个15分钟的开发团队时间盒活动。每日Scrum每天都在Sprint举行。在此，开发团队计划在接下来的24小时内开展工作。通过检查自上次每日Scrum以来的工作并预测即将到来的Sprint工作，这可以优化团队协作和性能。Daily Scrum每天都在同一时间和地点举行，以降低复杂性。更新了每日Scrum部分，以明确Daily Scrum的目标，包括以下文本： 会议结构由开发团队制定，如果侧重于Sprint目标的进展，可以采用不同的方式进行。一些开发团队将使用问题，一些将更多基于讨论。以下是可能使用的示例：昨天我做了什么帮助开发团队实现Sprint目标？今天我将做些什么来帮助开发团队实现Sprint目标？我是否看到任何妨碍我或开发团队满足Sprint目标的障碍？在时间框周围增加了清晰度 使用“最多”一词来删除任何问题，即事件的时间框意味着最大长度，但可能更短。添加到Sprint Backlog部分： 为了确保持续改进，它包括至少一种团队工作的高优先级方式，在之前的回顾会议中确定。为增量部分添加了清晰度： 增量是一个可检查的，“完成”的工作，支持Sprint结束时的经验主义。增量是迈向愿景或目标的一步。2013年和2016年Scrum指南之间的变化关于Scrum值的部分。当Scrum团队体现并实践承诺，勇气，专注，开放和尊重的价值观时，透明度，检查和适应性的Scrum支柱将栩栩如生，为每个人建立信任。Scrum团队成员在使用Scrum事件，角色和工件时学习和探索这些值。成功使用Scrum取决于人们是否越来越熟练地掌握这五个价值观。人们个人致力于实现Scrum团队的目标。Scrum团队成员有勇气做正确的事情并处理棘手的问题。每个人都关注Sprint的工作和Scrum团队的目标。Scrum团队及其利益相关者同意对所有工作以及执行工作所面临的挑战持开放态度。Scrum团队成员互相尊重，是有能力的独立人士。2011年和2013年Scrum指南之间的变化添加了关于工件透明度的部分。Scrum依赖于透明度。根据工件的感知状态做出优化价值和控制风险的决策。在透明度完成的情况下，这些决定具有良好的基础。如果工件不完全透明，这些决策可能存在缺陷，价值可能会降低，风险可能会增加。Sprint Planning现在是一项活动。其中涉及两个主题：Sprint可以做什么，以及如何完成所选择的工作。在开发团队预测Sprint的产品Backlog项目之后，Scrum团队制定了Sprint目标。Sprint目标在开发团队的工作中创造了一致性，如果没有共同的目标，这些工作就不会出现在单独的计划中。请注意正式包含Sprint目标。产品Backlog经过精炼而非整理。精确的产品Backlog项目是透明的，足够的理解和粒度足以输入Sprint计划和Sprint的选择。具有此透明度的产品Backlog项称为“Ready”。Ready和Done是两个强化透明度的状态。Scrum规定其事件以创建规律性并最小化对未在Scrum中定义的会议的需求。所有事件都是时间盒事件，因此每个事件都有最长持续时间。作为容器事件的Sprint具有不能缩短或延长的固定持续时间。只要达到事件的目的，剩下的事件就可以结束; 确保花费适当的时间而不会在过程中浪费。Daily Scrum作为计划活动的重要性得到了加强。它经常被视为一种状态事件。每天，开发团队应该了解它打算如何作为一个自组织团队一起工作，以实现Sprint目标，并在Sprint结束时创建预期的增量。会议的输入应该是团队如何实现Sprint目标; 输出应该是一个新的或修订的计划，以优化团队在满足Sprint目标方面的努力。为此，重新制定了三个问题，以强调团队对个人的影响：昨天我做了什么帮助开发团队迎接Sprint今天我将做些什么来帮助开发团队实现Sprint目标？我是否看到任何妨碍我或开发团队满足Sprint目标的障碍？价值观的概念得到了加强，可以在Sprint评论中使用。在Sprint评审期间，Scrum团队和利益相关者就Sprint的工作进行了合作。基于此以及Sprint期间产品Backlog的任何更改，与会者将就可以采取的下一步措施进行协作以优化价值。2010年和2011年Scrum指南之间的变化开发团队不承诺完成Sprint计划会议期间计划的工作。开发团队创建了它认为将要完成的工作的预测，但是随着Sprint中的更多知识的出现，预测将会发生变化。Scrum没有要求使用刻录图来监控进度。Scrum仅需要：Sprint的剩余工作每天汇总并且已知。整个Sprint都保持着完成Sprint工作的趋势。在使用Scrum时，发布计划是一件很有价值的事情，但Scrum本身并不需要。Sprint Backlog是为Sprint选择的Product Backlog项目，以及交付它们的计划。不再需要“Sprint Backlog项目”的概念，尽管这种技术可以制定一个很好的计划。自组织开发团队总是有一个计划。产品待办事项是“有序的”，而不是“优先”，为产品负责人提供灵活性，以便在其独特情况下优化价值。添加了Product Backlog Grooming的做法。删除许多提示，可选的做法和技术。执行创建增量工作的人员团队是开发团队。无论各个团队成员的工作如何，他们都被称为开发人员。删除了对鸡和猪的参考。删除了对撤消工作的引用。Agile & Scrum BasisComprehensive Scrum GuideWhat are Scrum’s Three Pillars?What is Agile Software Development?Scrum in 3 MinutesWhat are the 5 Scrum Values?What is the Evolution of Scrum?Classical Project Management vs Agile Project ManagementWhy is Scrum Difficult to Master? ...

最新版Scrum指南已由来自Scrum, Inc的Scrum共同发明人Ken Schwaber和来自Scrum.org的Jeff Sutherland联手发布。上一版发布于2013年，此版最大的变化是包含了Scrum价值观。Scrum指南包含有关Scrum的权威指南，「整个游戏的规则」。Schwaber和Sutherland通过合作定期更新该Scrum指南，并通过Scrum指南网站的User Voice区域响应来自社区的反馈。新版发布后，InfoQ与Schwaber谈到了最新版中的改动和未来的计划。Scrum Guide 指南的目的Scrum 是一個框架，這框架適用於開發，交付，與持續支援具有錯綜複雜的產品。這份指南包含 Scrum 的定義，其中定義涵蓋了 Scrum 中的角色，活動，產出物，與它們之間如何進行的規則。Scrum 是由 Ken Schwaber 和 Jeff Sutherland 共同發展出來的；Scrum 指南也是由他們所撰寫及提供，他們是 Scrum 指南背後的共同推手。Scrum 的定義Scrum （名詞）：一個框架，人們可以運用這個框架來處理錯綜複雜的調適性問題，善用生產力與創意來交付盡可能最高價值的產品。Scrum 是：● 輕量的 ● 淺顯易懂的 ● 難以精通Scrum 是一個流程框架，從 1990 年代初期它就被用來管理生產錯綜複雜的產品。Scrum 不是一種流程，一個技巧，或明確既定的方法。倒不如説 Scrum 是一個框架，在其中你可以使用各種不同的流程與技巧。運用 Scrum 可以清楚的呈現不同產品管理方法和工作技巧的功效，因此你可以持續改善產品，團隊，還有工作環境。Scrum 框架中包含了 Scrum Teams 和他們相關的角色，活動，產出物，和規則。每個框架中的組成都有特定的目的，也都是讓 Scrum 成功和運行的必要條件。Scrum 規則把角色，活動和產出物整合在一起，也主宰了各個組成之間的關係和互動。這整份文件都是在描敘 Scrum 規則。各種使用 Scrum 框架的具體策略有很大的差異，這些策略不在這指南中描述。Scrum 的運用Scrum 一開始是為了管理和開發產品而發展出來的。從 1990 年代初期開始，Scrum 就在全世界被大量的運用在：研究和辨識出市場，技術，產品性能的可行性;開發產品和加強功能;發佈產品和加強功能，頻率高到一天可能發佈許多次;開發和支援雲端服務（線上，高安全性，隨時存取）和其他營運環境來幫助產品的運用，以及支援和更新產品。Scrum 已經被使用於開發軟體，硬體，韌體，互動的網路，自駕車，學校，政府，行銷，管理組織的營運，還有幾乎所有我們日常生活中的事物上，不論是個人或是社會。在科技，市場，環境都日趨錯綜複雜，而且各個因素之間的互動快速增加的情況下，每天都可以看到運用 Scrum 來處理錯綜複雜的問題的效用。Scrum 被證明在迭代和漸進式的知識轉移中特別有效。目前 Scrum 已經被廣泛的使用在組織內的產品，服務，和管理。Scrum 的精華在於小型的團隊。每個團隊都具有高度彈性和調適性。這些團隊從事開發，發佈，營運，和支援的工作，不論是一個團隊，一些團隊，許多團隊或是更多串連在一起的團隊所組成，都擁有這些優勢，他們藉由精細複雜的開發架構和鎖定發佈環境來協同合作和交互運作。當 Scrum Guide 中使用「開發 （develop）」這個字的時候，指的是從事複雜的工作，如上面所陳述到的那些類型。Scrum 的理論Scrum 是立基於經驗導向的流程控制理論，或是經驗主義。經驗主義立論於知識來自於經驗和依照已知的資訊來下判斷。Scrum 使用迭代和逐步 Increment 的方式，來最大化可預測性和控制風險。 有三根支柱支撐了所有經驗導向的流程控制的實行：透明性，檢視性，調適性。透明性負責產生成果的人員必須清晰地看見流程中重要的部分，這些部分被共同的標準來定義，所以觀看的人能得到一致的認知，這就是透明性。例如：● 所有的參與者對該流程都有共同的語言；以及● 真正執行的人員和檢視 Increment 成果的人員，需要對「完成」之定義，有一個共同的認知。檢視性Scrum 的成員必須經常檢視 Scrum 的產出物和 Sprint 目標的進度來檢測意料之外的變數。他們的檢視不應該頻繁到會阻礙工作的進行。最有效益的檢視方式，是由盡職且擁有技能的檢視者在工作的當下進行。調適性如果檢視者判斷流程中的某些部分超出了可以接受的範圍，且會造成產品不被接受，就必須調整當下的流程或使用材料。調整必需越快越好來減少未來更多的偏差。在 Scrum 中規定了四個幫助檢視性和調適性的正式活動，在 Scrum 活動的章節會介紹：● Sprint Planning● Daily Scrum● Sprint Review● Sprint RetrospectiveScrum 價值觀當 Scrum Team 體現和活化承擔，勇氣，專注，開放和尊重這五種價值觀時，Scrum 的三根支柱：透明性，檢視性，調適性就會出現並幫助大家建立信任。隨著 Scrum Team成員從事 Scrum 角色，活動和產出物的過程中，他們就會學習和探索這些價值。 要成功運用 Scrum 取決於成員是否精通並融入這五個價值。成員個人承諾會達到 Scrum Team 的目標，Scrum Team members 有勇氣做對的事情和處理艱難的問題，每個人專注在 Sprint 的工作和 Scrum Team 的目標上，Scrum Team 和利害關係人同意對工作和工作上的挑戰保持開放的心態，Scrum Team members 互相尊重對方是有能力和獨立的人。Scrum TeamScrum Team 由 Product Owner，Development Team 和一位 Scrum Master 組成。Scrum Teams 是一個自我組織和跨職能的團隊。自我組織的團隊會自行選擇最好的方式來完成工作，而不是被團隊外的人指示如何做。跨職能的團隊不需依靠非團隊成員而擁有所有完成工作所必備的能力。Scrum 中的團隊模式是設計用來將彈性，創意，和生產力最大化。Scrum Team必須證明自己在前述的情況和錯綜複雜的工作中越來越有效。Scrum Teams 用迭代和逐步 Increment 的方式交付產品，將回饋的機會最大化。用逐步Increment 的方式交付「完成」的產品，可以確保一直提供一個潛在可用的產品版本。The Product OwnerProduct Owner 負責將產品的價值最大化，而價值來自於 Development Team 的工作成果。如何做到這點可能在每個組織，Scrum Teams，或個人，都差異很大。Product Owner 這個角色只能由一個人來擔任，專門負責管理 Product backlog。Product backlog 管理包含：清楚的表達 Product Backlog items；針對 Product backlog 上的事項進行排序來達到最好的目標和使命；將 Development Team 工作所產生的價值最佳化確保 Product backlog 是每個人都可以看見的，是有透明度的，以及清晰瞭解的，而且可以顯示出 Scrum Team 接下來要做的事；和確保 Development Team 對 Product Backlog 的了解有到達所需要的程度Product Owner 可以自己做以上的工作，或由 Development Team 來做。但不管如何都是由 Product Owner 當責。Product Owner 是由一個人來擔任，而不是一個委員會。Product Owner 可能代表一個委員會對於 Product backlog 的期望要求，但任何人想要改變 Product Backlog 的優先順序，都需要經過 Product Owner 的同意。要讓 Product Owner 成功，整個組織必須尊重他/她的決定。Product Owner 對於Product Backlog 內容和順序之決定是透明的，沒有人可以強迫 Development Team 做 Product backlog 以外的需求。The Development TeamDevelopment Team 由一群專業人士組成，他們可以在每個 Sprint 結束時交付「完成」潛在可發佈的產品 Increment。「完成」的產品 Increment 必須在 Sprint Review 上呈現。只有 Development Team 的成員可以產生產品 Increment。組織建立並授權 Development Team，讓他們可以自行組織和管理他們自己的工作。所達成的綜效可讓 Development Team 整體的效率和效能達到最大化。Development Team 有以下的特性：他們是自組織的。沒有人（甚至是 Scrum Master）可以對 Development Team 下指導棋，告訴他們如何把 Product backlog 轉換成潛在可發佈的產品 Increment；Development Team 是跨職能的，擁有產出產品 Increment 所需要的所有技能；Scrum 認為 Development Team members 沒有職稱，不管個人所做的工作是什麼；Scrum 認為 Development Team 中沒有小團隊，不管需要解決的是什麼領域，如測試，架構，營運或商業分析；和Development Team members 雖然可能各自有專精的技能和領域，但仍是由Development Team 整體來當責。Development Team 的大小最理想的 Development Team 大小，是小到足夠靈活而且大到能夠完成 Sprint 內重大的工作。少於三個人的 Development Team member 之間的互動會減少，以至於只能提升小部分的生產力。小一點的 Development Team 可能會在 Sprint 中遇到技能的限制，使得Development Team 無法交付潛在可發佈的產品 Increment。如果成員多過九個人則會造成太多的協調。大的 Development Teams 產生太多的複雜性，而使得經驗導向的流程沒辦法那麼有效。Product Owner 和 Scrum Master 的角色並不包含在 Development Team人數中，除非他們也執行 Sprint Backlog 上的工作。Scrum MasterScrum Master 依照 Scrum 指南中的遊戲規則來負責推廣和支持 Scrum。Scrum Master 幫助每個人了解 Scrum 的理論，實務，規則和價值觀，來達成推動 Scrum。對於 Scrum Team 來說，Scrum Master 是一個僕人式的領導。Scrum Master 幫助Scrum Team 外的人了解哪些與Scrum Team 之間的互動是有幫助的，而哪些是沒有幫助的。Scrum Master 幫助每個人改變這些互動的方式，讓 Scrum Team 產生的價值能夠最大化。Scrum Master 對 Product Owner 提供的服務Scrum Master 對Product Owner 提供多方面的服務，包含：確保 Scrum Team 的每位成員都盡可能地理解目標，範圍與產品領域；找出有效管理 Product backlog 的技巧；幫助 Scrum Team 理解為什麼需要清楚簡潔的 Product Backlog items；在經驗導向的環境中理解產品規劃；確保 Product Owner 知道如何安排 Product backlog 來讓價值最大化；理解和實踐敏捷；與當需要或被要求時，引導 Scrum 活動的進行。Scrum Master 對 Development Team 提供的服務Scrum Master 對 Development Team 提供多方面的服務，包含：作為教練指導 Development Team如何自我組織和跨職能；幫助 Development Team 創造高價值的產品；移除 Development Team 在過程中的障礙；當需要或被要求時，引導 Scrum 活動的進行；與在組織環境還沒有完全採用與理解 Scrum 的情況下，作為教練指導 Development Team。Scrum Master 對組織提供的服務Scrum Master 對組織提供多方面的服務，包含：帶領和作為教練指導組織來採用 Scrum；規劃 Scrum 在組織內的實施；幫助員工和利害關係人理解及制定 Scrum 與經驗導向的產品開發；造成改變來增加 Scrum Team 的生產力；與其他 Scrum Master 一起合作來加強組織內 Scrum 應用的有效性。Scrum 的活動Scrum 規定了幾項活動來創造規律性，以此來減少其它 Scrum 未定義的會議。這些活動都是有時間盒限制的，也就是在某個時間長度內必須要完成。當 Sprint 開始，Sprint 的長度就固定下來了，不可以縮短或是延長。剩下的活動在達成其目的後就可以結束了，以確保在過程中只使用了適當的時間而不會造成流程中的浪費。Sprint 本身包含了其他的活動，除了 Sprint 本身之外，每次活動都是用來檢視與調適某些事情的正式機會，這些活動都是特別設計來促成嚴格的透明性與檢驗性。遺漏其中的任何一種活動可能導致透明性降低，檢視和調適的機會變少。SprintScrum 的核心是 Sprint，Sprint 是一個月或更短的時間盒。在 Sprint 內，會產出「完成」的，可用的，潛在可發佈的產品 Increment。Sprint 長度在整個開發過程中都是固定的，前一個 Sprint 結束後，下一個新的 Sprint 立刻接著開始。Sprint 包括了 Sprint Planning，Daily Scrums，開發工作，Sprint Review 與 Sprint Retrospective。在 Sprint 過程中：不可以發生會危及 Sprint 目標的改變；對於品質的目標不可以降低；與隨著獲得了更多關於產品的細節，Product Owner 與 Development Team 之間對於範圍內要做的事可以加以澄清與重新溝通。每個 Sprint 可視為一個不超過一個月的專案，如同其他專案一般，Sprint 是用來完成某些事情的。每個 Sprint 有著要打造些什麼的目標，而由一份設計和有彈性的計畫來引導其打造的過程，工作與最後的產品 Increment。Sprint 被限制在一個月內，當 Sprint 時間拉的太長時，現在正在打造的東西的定義可能會發生改變，而其複雜性也許會增加，導致風險上升，Sprint 藉由至少一個月一次的檢視與調適 Sprint 目標進度來達成可預期性，也因此，Sprint 便可將成本風險限制在一個月內。取消 SprintSprint 可在時間盒限制結束前取消，但只有 Product Owner 有取消 Sprint 的權力，雖然Product Owner 的這個決定可能是來自於利害關係人，Development Team 或是 Scrum Master 的影響。當 Sprint 目標已經變得過時，不重要的時候，就可以取消 Sprint，這可能是因為公司改變了方向或是因為市場或技術上的改變。一般而言，如果當下的情況已經變得不合理，那就應該取消 Sprint，但因為 Sprint 的時間很短，取消通常是不太合理的事情。當 Sprint 被取消時，會檢視已經「完成」的 Product Backlog items，如果有某部分的工作已經是潛在可發佈了，Product Owner 一般會接受這些成果。而尚未完成的 Product Backlog items 會被重新估計，並放回 Product backlog 內，花在這些尚未完成的 Product Backlog 上的工作價值會流失得很快，所以需要經常不斷的重新估計來反映。取消 Sprint 會消耗資源，因為要在新的 Sprint Planning 把每個人集合起來，重新開始新的 Sprint，Sprint 的取消會對 Scrum Team 造成重大傷害，所以並不常發生。Sprint PlanningSprint 內要做的事會在 Sprint Planning 中來訂定。工作計劃是由整個 Scrum Team 協同合作來制定的。Sprint Planning 是有時間盒限制的，以一個月的 Sprint 來説，Sprint Planning 最多為八小時。對於少於一個月的 Sprint，這個會議所需的時間更短。Scrum Master 確保這個會議活動的發生，以及出席人員了解這個會議的目的。並且教導 Scrum Team 在時間盒限制內完成此會議。Sprint Planning 回答以下問題：這次 Sprint 可以發佈什麼樣的 Increment？如何做才能夠達成 Increment？第一個討論題目：這次 Sprint 能做出什麼？Development Team 預測在這次Sprint內能開發出什麼功能。Product Owner 討論這次 Sprint 所應該達成的目標，以及完成哪些 Product Backlog items 可以達成這個目標。整個 Scrum Team 協同合作來了解 Sprint 要做的工作。這個會議的輸入包含： Product backlog ，最近的 Increment，在 Sprint 內 Development Team的產能預測，以及 Development Team 的過去表現。從 Product backlog 之中要選出那些項目完全取決於 Development Team。只有 Development Team 可以評估即將到來的 Sprint 所能達成的事情。在 Sprint Planning 中 Scrum Team 同時草擬本次的 Sprint 目標。Sprint 目標經由實作Product Backlog 來達成，同時指引 Development Team 知道為何要做這次的 Increment。第二個討論題目：如何完成所選的工作？在設定 Sprint 目標與選出 Product Backlog Items 之後，Development Team 決定如何在這次 Sprint 內，建造這個功能來做出一個「完成」的產品 Increment。Sprint Backlog 指的是：這次 Sprint 所選的 Product Backlog items 加上如何交付它們的計劃。Development Team 通常從系統的設計開始，到找出那些工作可以將 Product backlog 轉換成一個可運作的產品 Increment。工作通常有不同的大小，或不同的預估工作量。然而，在 Sprint Planning 中，Development Team 只預測他們在本次 Sprint 要完成的工作量即可。在 Sprint Planning 結束之際，Development Team 應該已經規劃出在 Sprint 的前幾天內所要做的工作，通常以一天或更少為一個單位。不管是在 Sprint 計劃會議中以及在Sprint 期間內，Development Team 自我組織的來承擔 Sprint Backlog 的工作。Product Owner 能夠幫助釐清所選定的 Product Backlog items 以及做出折衷。如果 Development Team 發現 Product Backlog 的工作內容太多或太少，他們可以與 Product Owner 重新商討所選的 Product Backlog items。Development Team 也可以邀請在技術領域或者其它領域的專家一起來參加會議提供建議。在 Sprint Planning 結束之際，Development Team 應該能夠解釋給 Product Owner 以及 Scrum Master，他們要如何自我組織來完成 Sprint 目標以及開發出預定的 Increment。Sprint 目標Sprint 目標是實作 Product backlog 過程中所必須達到的目的。它指引 Development Team 爲什麼要做這個 Increment。Sprint 目標是在 Sprint Planning 中產生的。對於在 Sprint 內要實作的功能，Sprint 目標提供了 Development Team 要實作哪些功能的彈性。這些被選定的 Product Backlog items 提供一個連貫的功能，而這個功能即可成為 Sprint 目標。Sprint 目標也可以是任何有連貫性的工作，這些工作讓 Development Team 一起合作，而不是讓他們各自做各自的。當 Development Team 工作時會牢記 Sprint 目標。Development Team 會實作出需要的功能和工藝來達到 Sprint 目標。如果要做的事情和 Development Team 預期的不同，他們會跟Product Owner 協同合作來溝通商量本次 Sprint Backlog 之範圍。Daily ScrumDaily Scrum 是一個針對 Development Team 的活動，其時間盒限制是 15 分鐘，此會議在 Sprint 期間內每日召開。在這個會議裡，Development Team 會規劃未來 24 小時的工作。透過檢視前次 Daily Scrum 後的工作及展望接下來的Sprint工作，將會逐步優化團隊協同合作和表現。Daily Scrum 在同一時間與地點舉行來降低其複雜性。 Development Team 藉由 Daily Scrum 來檢視達成 Sprint 目標的進度，以及檢視所完成的Sprint Backlog 進度的趨勢。Daily Scrum 優化了 Development Team 達到 Sprint 目標的可能性。每一天，Development Team 都應該理解如何以一個自我組織的團隊來一起完成Sprint 目標，並在 Sprint 結束時創造出符合預期的 Increment。 會議的架構由 Development Team決定，只要聚焦在達成 Sprint 目標的進度上，都可以用不同的方式進行。 一些 Development Team 會使用提出問題的方式，而有一些則會以討論的方式進行。以下是一個可以使用的範例：我昨天做了什麼事來幫助 Development Team 達到 Sprint 目標?我今天要做什麼事來幫助 Development Team 達到 Sprint 目標?我是否有察覺到任何障礙使得我或者 Development Team 無法達到 Sprint 目標?Development Team 或團隊成員經常在 Daily Scrum 後再立即會面，以便進行詳細的討論，調適或重新規劃 Sprint 的其餘工作。 Scrum Master 確保 Development Team 有進行 Daily Scrum，但 Development Team 要負責召開此會議。 而 Scrum Master 要教導 Development Team 將 Daily Scrum 保持在時間盒限制 15 分鐘內完成。 Daily Scrum 是 Development Team 的內部會議。 如果有其他人在場，Scrum Master 要確保他們不會打擾到會議的進行。 Daily Scrums 改善溝通品質，淘汰其他會議，發現並移除開發上的障礙，突顯及促進快速決策，還有提升 Development Team 的知識水平。 這是一個用來做為檢視和調適的重要關鍵會議。Sprint ReviewSprint Review 是在 Sprint 結束時舉行，目的是檢視 Increment以及在必要時調適 Product Backlog。在 Sprint Review 中，Scrum Team 和利害關係人一起協同合作檢視在 Sprint 中所完成的事項。依照這些事項和在 Sprint 過程中 Product Backlog 的變動，參與者一起協同合作討論接下來能做完哪些最有價值的事情。這是一個正式但輕鬆的會議，並不是一個進度回報的會議，關於 Increment 的展示是為了引發意見的反饋和提升協同合作。 對於為期一個月的 Sprint 來説，這是一個最多四個小時的會議。 在長度更短的 Sprint，通常所需的時間更短。Scrum Master 確保這個會議活動的發生，以及出席人員了解這個會議的目的。Scrum Master 教導參與的每個人如何在時間盒限制內完成會議。 Sprint Review 包含以下要件：參與者包含 Scrum Team 和 Product Owner 邀請的主要利害關係人；Product Owner 解釋哪些 Product Backlog items 已經「完成」，與哪些尚未「完成」；Development Team 討論在 Sprint 中進行順利的事項，遇到那些問題與及這些問題如何被解決；Development Team 展示已「完成」的工作並回答關於 Increment 的問題；Product Owner 討論目前的 Product backlog 的現況，他/她（視情況而定）根據到目前為止的進度來預測可能的的交付日期；整個團體協同合作來決定下一步要做什麼，所以 Sprint Review 提供了有價值的資訊給接下來的 Sprint Planning 當作輸入；檢視市場或潛在的產品使用情況是否改變了接下來最有價值的下一步；與檢視接下來期待會發布的產品功能的時間，預算，潛力，和市場。 Sprint Review 的結果，是一個修正過的 Product backlog ，在清單中定義了在下個 Sprint 可能會做的Product Backlog items。 Product backlog 亦可以調整來因應新的機會。Sprint RetrospectiveSprint Retrospective 提供 Scrum Team 一個自我檢視的機會，並建立一個改進計劃以便在下一個 Sprint 中落實。 Sprint Retrospective 召開在 Sprint Review 之後，下一個 Sprint Planning 之前。對於為期一個月的 Sprint 來説，這是一個最多三個小時的會議。 在長度更短的 Sprint，通常所需的時間更短。 Scrum Master 確保這個會議活動的發生，以及出席人員了解這個會議的目的 Scrum Master 確保這個會議是正向積極並有成效的。 Scrum Master 教導所有人在時間盒限制內完成會議。 Scrum Master 以團隊成員的身分來參與這個會議，因為他對 Scrum 的流程當責。Sprint Retrospective 的目的是：檢視上次 Sprint 內關於人員，關係，流程和工具的情況；找出並加以排序做的很好的重要事項，及具有改善潛力的事項；同時，制定一個計劃來落實如何改善 Scrum Team 的工作方法。Scrum Master 鼓勵 Scrum Team 在 Scrum 流程框架內改善其開發流程和實務，使其在下一個 Sprint 的工作中能更有效能及愉快。 在每個 Sprint Retrospective 中，Scrum Team 會規劃各種方法來提升產品的品質，在恰當且不與產品或組織標準相衝突為前提下，改善工作流程或調整「完成」之定義。在 Sprint Retrospective 結束之際，Scrum Team 應該已經確定了在下一個 Sprint 中要實施改善的地方。 在下一個 Sprint 中執行這些改善，即是 Scrum Team 在自我檢驗後的調適。雖然改善可能在任何時間點落實，但 Sprint Retrospective 提供了一個正式的機會來專注在檢視與調適上。Scrum 產出物Scrum 的產出物代表了工作或價值，用以提供透明化以及檢視和調適的機會。 Scrum 所定義的產出物是專門設計用於讓關鍵資訊有最大的透明性，以便每個人對該產出物有相同的理解。Product BacklogProduct Backlog 是產品所有已知需求的排序表。它是對產品進行任何更改的唯一需求來源。Product Owner 對 Product backlog 負責，包含其內容，可取得性和排序。Product backlog 永遠沒有完成的一天。早期的開發僅排定了最初已知和最被理解的需求。 Product backlog 隨著產品和使用環境的演變而演化。 Product backlog 是動態的；它不斷地變化來找出什麼對產品而言是恰當的，有競爭力以及有用的。只要產品存在的一天，它的 Product backlog 也會同時存在。Product backlog 列出了所有特性，功能，需求，改善功能和修補程式，這些事情構成了對未來要發布的產品的更新。Product Backlog items 的屬性包括了其描述，順序，估計和價值。Product Backlog items 通常包括測試描述，用來證明「完成」的完整性。隨著產品的使用和獲得價值，以及市場提供的反饋， Product backlog 將成為更大更詳盡的列表。 需求永遠不會停止改變，所以 Product backlog 就如同一個活的產出物。商業需求，市場狀況或技術的變化可能都會造成 Product backlog 的變動。數個 Scrum Teams 通常會一起參與對同一個產品的開發。 一個 Product backlog 便被用於描述該產品即將進行的工作，並採用 Product Backlog 的某一種屬性來把這些事項分類。 Product backlog refinement，是向 Product backlog 中的事項添加詳細資訊，估算大小和排序的動作。這是一個持續的過程，由 Product Owner 和 Development Team 就 Product Backlog items 的細節進行協同合作。在 Product backlog 精煉的過程中，事項會被進行審查和修訂。Scrum Team 決定如何以及何時來完成精煉。精煉所花的時間通常不超過Development Team 百分之十的產能。 然而，Product Backlog items 可以隨時由Product Owner 或在 Product Owner 的斟酌下來做更新。 較高排序的 Product Backlog items 比起較低的 Product Backlog items，通常比較清楚，同時包含更多細節。因為比較明確以及更多細節，可以讓預估更精準；而排序較後的 Product Backlog items，細節會越少。Development team 會在下一個 Sprint 開發的 Product Backlog items 會先被精煉，使得這些事項都可以合理的在 Sprint 時間盒期限內「完成」。「備妥」的 Product Backlog 可以在 Sprint Planning 中被挑選出來，而能夠 Development Team 在下一個 Sprint 內「完成」。 Product Backlog items 的透明性通常要經過上述的精煉化活動來獲得。 Development Team 負責所有的估計。Product Owner 也許可以經由幫助 Development Team 了解以及選擇取捨來影響他們，然而還是要由實際做事的人來決定最終的預估。監測達成目標的進度 在任何時候，用來達成目標的所有剩餘工作量都能夠被加總。Product Owner 至少在每次的 Sprint Reviews 中追蹤剩餘的工作量。Product Owner 將這次的剩餘工作量與之前做比較，進而評估預定的工作進度，是否能在期望時間內達成目標。這些資訊對所有的利害關係人都是透明公開的。 可以用各種不同關於趨勢走向的實務來預測進度，譬如：燃盡圖，燃起圖或累積流量圖。這些工具被證實是有用的，然而它們並不能用來取代經驗主義的重要性。在錯綜複雜的環境中，會發生什麼事是未知的。已經發生的事情，才能用來當做前瞻的決策的參考依據。Sprint BacklogSprint Backlog 是一組在這次 Sprint 要執行的 Product Backlog items 加上如何交付產品Increment 和達到 Sprint 目標的計劃。 Sprint Backlog 是 Development Team 對下一個Increment 中所需要的功能以及將該功能轉換到「完成」Increment 所需工作的預測。Sprint Backlog 讓 Development Team 識別出所有用來完成 Sprint 目標的必要工作。為了確保持續改善，它包含了至少一個在前次Sprint Retrospective 中優先級高的流程改進。 Sprint Backlog 是一個具有足夠細節的計劃，使得在 Daily Scrum 中可以了解正在發生的改變。 Development Team 在整個 Sprint 期間都會去修改 Sprint Backlog，使得 Sprint Backlog在 Sprint 期間裡慢慢變化而逐漸成形。 這樣的逐漸成形會隨著 Development Team 實作Sprint Backlog 的過程來發生，加上過程中學習而得到更多如何完成 Sprint 目標。 當需要有新的工作時，Development Team 便將其加到 Sprint Backlog 內。 隨著工作的進展或完成，團隊會去更新預估的剩餘工作量。當計劃內的某些部份被認定是不需要的，這些部分就會被移除。只有 Development Team 才能在 Sprint 期間內更改 Sprint Backlog。 Sprint Backlog 是 Development Team 在 Sprint 內計畫完成的工作，是一個可視性高且即時的工作畫面，且只屬於 Development Team 所擁有。監督 Sprint 的進度在 Sprint 的任何時間點都可以加總在 Sprint Backlog 內剩餘的總工作量。 Development Team 至少在 Daily Scrum 追蹤剩餘工作的總和，以預測達成本次 Sprint 目標的可能性。Development Team 可以藉由追蹤 Sprint 的剩餘工作來管理本身的進度。Increment Increment 是指在 Sprint 期間內完成的所有 Product Backlog items，以及所有先前 Sprint Increment 的價值總和。在 Sprint 的最後，新的 Increment 必須是「完成」的，這意味著它必須是可用的狀態，並符合 Scrum Team 對於「完成」之定義。在 Sprint 結束時，Increment 是一種可檢視，完成的工作實體，並可支持經驗主義。向願景或目標邁出更前進的一步。 無論 Product Owner 是否決定將其發佈，Increment 都必須是處於可用的狀態。產出物透明性Scrum 建立在透明性上，基於對產出物的理解做出把價值最佳化和控管風險的決策。在產出物完全透明的情況下，這些決定才會有可靠的基礎。 而當產出物沒有達到完全透明，可能會做出有瑕疵的決定，進而減低了價值，增加了風險。Scrum Master 必須與 Product Owner，Development Team，和其它相關人員一起努力來了解產出物是否完全透明。當不是完全透明時 Scrum Master 必須幫助所有人應用最合適的作法。Scrum Master 可以透過檢視產出物，對模式的感知，仔細傾聽周圍發生的對話，以及檢視預期和實際結果之間的差異，來發現不完整的透明性。 Scrum Master 的工作是與 Scrum Team 和組織合作來提高產出物的透明性。 這項工作通常涉及學習，使人信服和改變。 透明性不會在一夜之間發生，然而它是一條道路。「完成」之定義當一個 Product Backlog item 或者 Increment 被描述為「完成」時，每個人都必須了解什麼是「完成」之定義。 雖然這會隨著 Scrum Team 的不同而有很大的差異，但成員們必須對什麼叫做工作完成有共識，如此才能確保透明性。 這就是 Scrum Team 對「完成」之定義，並且用它來評估產品 Increment 上的工作是否完成。 同樣的定義用來指導 Development Team，讓團隊知道在 Sprint Planning 中可以選擇多少 Product Backlog items。 每一個 Sprint 的目的是交付潛在可發佈的功能 Increment，而這些功能符合 Scrum Team 目前對「完成」之定義。 Development Team 在每個 Sprint 交付產品功能的 Increment。 這個 Increment 是可用的，因此 Product Owner 可以選擇立即發佈它。 如果「完成」之定義對 Increment 來說是開發組織的慣例，標準或指導方針的一部分，那麼所有的 Scrum Teams 都必須要遵守。 如果 Increment的「完成」不是開發組織的慣例，那麼 Development Team 就必須對這個產品訂下一個合適的「完成」之定義。如果有多個 Scrum Teams 在同一個系統或產品發佈上工作，那麼所有的 Development Team 就必須一起訂下一致的「完成」之定義。 每個 Increment 都是遞加於先前的 Increment，並經過徹底地測試以確保所有 Increment 都能一起運作。 隨著 Scrum Teams 的成熟，可以被預期的是，他們對「完成」之定義將擴大到包含更多更嚴謹的標準以達到更高的品質。當使用了新的定義，可能會發現一些之前已「完成」的Increment需要更多的工作。 任何一個產品或系統都應該有一個「完成」之定義，作為工作的標準。結語經由此指南提供 Scrum 知識，Scrum 同時也是免費的。Scrum 的角色，活動，產出物和規則都是不能改變的，雖然實施部分的 Scrum 是可能的，但結果並不是 Scrum。Scrum 只有在完整的時候才會存在，也才能有效的成為其他技巧，方法論，和實務發揮的運作舞臺。 ...

Scrum是产品开发和团队组织的迭代和增量过程。借助Scrum框架，可以更快，更高质量地完成任务。这是可能的，因为团队的高自我激励，自己选择如何执行任务。客户需求将被迭代优先级并快速实现Scrum - 敏捷框架 (Agile Framework)Scrum是一个框架，支持迭代和增量产品开发，允许在正确的时间完成工作，最大化交付的价值。通过自组织团队，任务执行速度更快，质量更高。实现了高水平的自我激励，这也是Scrum允许团队更快地实现更高生产力的原因。根据业务价值不断优先考虑客户需求，并定期将其集成到产品中，使客户能够及时向团队提供反馈，从而按时提高产品质量。Scrum项目主要从对待开发的产品或系统的愿景开始。一开始，这个愿景可能含糊不清，并且肯定会在市场问题而不是技术术语上说明。随着项目的进展，它将变得更加清晰。出于这一愿景，产品负责人正在撰写产品Backlog。在迭代开始时（Sprint），产品负责人将优先级产品Backlog呈现给团队，团队选择它认为可以在Sprint结束时变为可发送功能的增量。这样做，就会创建Sprint Backlog。之后，团队将独自开发他们所选择的功能。该团队现在更深入地了解需求，考虑可用技术，并评估自己的技能和能力。然后它共同确定如何构建功能，每天修改其方法以找出新的复杂性或困难。团队确定需要做什么，并选择最佳方式。这一创作过程是Scrum生产力的核心。在Sprint结束时，团队向产品负责人展示了功能的增加，因此他可以一方检查功能，另一方面及时调整项目。Scrum角色 (Scrum Roles)Scrum - 3个角色：产品拥有者团队Scrum Master管理项目的所有职责分为这三个角色。产品拥有者 (Product Owner)产品负责人代表与项目有利害关系的每个人的利益（利益相关者），他负责最终产品。他从利益相关者那里获得产品需求，创建产品Backlog（需求细分为用户故事），负责投资回报（ROI），并且他正在制定发布计划。产品负责人使用业务价值点对产品Backlog进行优先级排序，以确保首先开发最有价值的功能。 企业想要的和团队可以做的事情之间的紧张关系是什么使Scrum成为高质量生产的有效工具。团队 (Team)该团队计算出如何将产品Backlog转换为Sprint内的功能增量。每个团队成员共同负责每次迭代和整个项目的成功。该小组负责/：软件质量用户故事的技术实施交付功能软件增量整理自己Scrum MasterScrum Master负责Scrum流程。他确保每个人都遵守规则。他还消除了球队的障碍。Scrum Master不属于团队。猪和鸡 - 承诺还是参与？所描述的三个角色已经致力于该项目。其他人可能只是对项目感兴趣（参与），但他们并没有陷入困境。Scrum明确分开了这两个群体。承诺：负责项目的角色有权为其成功做必要的事情。参与：对直接成功不负责任的其他利益相关者不能不必要地进行干预。应该总是清楚谁是负责投资回报率的人，谁与ROI有利害关系但不负责任。Scrum - 笑话一只鸡和一只猪走在路上。鸡对猪说：“你想和我一起开餐馆吗？” 猪仔细考虑了这个问题并回答说：“是的，我想那样。你想叫什么餐馆？” 鸡回答说：“火腿和鸡蛋！” 猪停下来，停下来回答：“我想，我不想和你一起开餐馆。我会承诺，但你只会参与其中。”Scrum工件Scrum - 3个主要的工件：产品积压 (Product Backlog)Burndown图表Sprint积压 (Sprint Backlog)产品积压产品的要求列在产品Backlog中。它是一个始终在变化，动态优先排序的业务价值排序要求列表。需求由PO分解为用户故事。Burndown图表Burndown图表显示了每个Sprint剩余的工作量。这是一种非常有用的方法，可视化任何时间点剩余工作与团队进度之间的相关性。它通过使用Burndown图表检查他们在规划方面的进展，并根据需要进行调整。Sprint积压 (backlog)Sprint Backlog包含团队分解为任务的当前Sprint的所有已提交用户故事。Sprint Backlog上的所有项目都应该进行开发，测试，记录和整合，以充分履行承诺。潜在的可交付产品功能 (Potential Shippable Product)Scrum要求团队在每个Sprint中构建产品功能的增量。此增量必须是可以发送的，因为产品负责人可能会选择立即实现该功能。这要求增量为：彻底测试过结构良好的写得很好的代码记录功能的用户操作新的管理职责三个主要角色 - 产品负责人，Scrum Master和团队 - 是管理角色。他们都是“猪”，因为他们在项目中承诺。组织中的所有其他管理者都是鸡，他们可能对项目感兴趣并且可能对其成功有浓厚的兴趣，但他们必须通过猪来解决问题。他们只是参与其中，因此他们对项目的执行或进展没有直接的权力。Scrum可以大大简化与项目相关的问责制和权限问题，但Scrum管理角色很难发挥作用。管理复杂的工作绝非易事，但定期使用Scrum实践可以使项目的进度，问题和社会学变得明显。Scrum - 易于使用？Scrum听起来很简单，在您阅读完这篇简短的文档之后，您可能会觉得可以毫无问题地开始使用。那是错的！与任何其他方法，流程或框架一样，scrum可能会对您的工作方式产生深刻的变化，因此请做好准备:-)Scrum活动什么是Scrum活动？什么是Scrum Ceremonies？什么是产品Backlog修饰？每日Scrum中的3个重要问题是什么？Scrum Sprint循环8个步骤什么是Scrum中的Sprint？Scrum的心跳 - 每日站立每日Scrum会议 - 快速指南为什么在Scrum中固定长度冲刺？什么是Scrum发布计划？什么是Sprint计划？什么是Sprint评论？什么是Scrum的Sprint回顾会议？什么是产品Backlog改进？什么是Scrum中的持续集成/交付/部署？什么是Scrum中的时间盒事件？什么是Scrum中的Spike？什么是敏捷计划扑克？

SCRUM使用经验方法（或有时称为经验主义）以适应客户不断变化的需求。经验主义是根据实际经历的内容做出决策的行为。经验方法意味着以事实为基础，以经验为基础，以证据为基础的方式开展工作，特别是，进展是基于对现实的观察，而不是基于大量前期要求的虚构计划。简而言之，我们可以学习和改进过去的错误和经验。Scrum支持经验过程控制的每一个实施的三大支柱是：透明度，检查和适应性，如下图所示：Scrum的三大支柱透明度Scrum中的透明度可以通过Scrum工具实现，例如产品Backlog，任务板和Burndown图表，每日站立，回顾，完成定义，Sprint评论等。这些工具用于通过跨职能团队转移工作流程。这是SCRUM的关键优势之一 - 允许关于工作和团队进度的可见性。这意味着当团队实现其目标时，负责该目标的人员可以得到认可和赞赏。检查必须经常检查Scrum工件并朝着目标前进，以检测不希望的差异。Scrum中的检查可以通过scrum活动来实现，例如：使用通用的Scrum板和其他信息来清除每个人的项目当前状态在开发史诗期间收集客户和其他利益相关者的反馈创建优先产品Backlog，并执行发布计划流程产品负责人检查和批准交付物演示和验证Sprint流程中的客户适应在敏捷世界中，我们始终拥抱和适应变化，以便我们不断改进。适应意味着我们改变不起作用的东西或者更好的作用。这意味着我们不断进行小型实验，保持正常工作，并在失败时进行改变。我们使用检查结果来决定接下来要运行的实验，例如：开发团队，每日站立仪式期间每天检查和调整。Sprint Review是另一个仪式，Scrum团队将要求所有股东提供反馈并相应调整。在Sprint Retrospective期间，Scrum团队在内部讨论问题和改进机会。将作为一个团队准备和调整新计划，以产生更多价值。摘要在Scrum中，决策是基于观察和实验而不是基于详细的前期规划。经验过程控制依赖于透明度，检查和适应性这三个主要思想。这意味着项目成果应该：向负责结果的人员了解流程的重要方面及时检查Sprint目标的进度，以检测不良差异尽快调整流程，以尽量减少任何进一步的偏差或问题总之，经验主义和三大支柱不仅对Scrum过程很重要，它们也是它的基础。这是您的团队在您创建的产品和您为团队使用的流程中实现持续改进的方式。角色，事件和工件只有在遵守基于价值的渐进式改进的情况下才能发挥作用，这些改进是通过接受频繁的反馈和接受变革而产生敏捷和Scrum基础综合Scrum指南什么是Scrum的三大支柱？什么是敏捷软件开发？Scrum在3分钟内完成什么是5个Scrum值？经典项目管理与敏捷项目管理为什么Scrum难以掌握？什么是Scrum中的速度？什么是敏捷？什么是Scrum？敏捷中的三个Amigos发展战略是什么？经验过程控制与定义过程控制如何保持Scrum的透明度？Scrum vs Waterfall vs Agile vs Lean vs Kanban什么是Scrum框架中的3355？为什么选择Scrum？Scrum如何克服我们总是面临的8个痛点？最好的免费和商业敏捷工具 - 每个Scrum团队都需要！什么是Scrum中的猪和鸡？什么是8种精益废物？

Scrum是一个项目管理框架，强调团队合作，问责制和迭代进展，以实现明确的目标。该框架从一个简单的前提开始：从可以看到或已知的东西开始。之后，跟踪进度并根据需要进行调整。Scrum的三大支柱Scrum的基础是经验主义，它指出知识来自经验，我们应该根据已知的事情做出决定。有三个支柱将Scrum结合在一起。为什么选择Scrum？Scrum一次提供功能，而瀑布只提供阶段。典型的瀑布式开发是基于阶段的顺序过程，在项目结束之前不会给出价值。Scrum将这种模式转变为每一周提供新功能，而不是专注于未来的大发布。Scrum将复杂的工作划分为简单的部分，将大型组织划分为小型团队，将影响深远的项目划分为一系列短时间的称为sprint的视野。通过迭代和渐进式构建，公司能够更快，更有效地为客户提供他们真正需要的产品和服务。使用Scrum，您可以在每个小开发周期结束时接收并整合客户反馈，这意味着您的结果将通过实际使用而非您的假设来塑造。这使得让客户和主要利益相关者密切参与和参与变得更加容易。敏捷与Scrum敏捷方法是一种有助于在SDLC过程中持续迭代开发和测试的实践。敏捷将产品分解为更小的构建。Scrum只是众多迭代和增量敏捷软件开发过程中的一个，它使我们能够专注于在最短的时间内提供业务价值。Scrum框架通常处理的是需求可能会发生变化，或者大部分时间在项目开始时都不知道。Scrum的特点是：轻量级简单易懂很难掌握Scrum的好处以下是scrum为组织，团队，产品和个人提供的好处。更好的质量：存在实现愿景或目标的项目。Scrum提供持续反馈和曝光的框架，以确保质量尽可能高。Scrum通过以下实践帮助确保质量缩短产品上市时间：Scrum已被证明能够为传统方法提供比最终客户快30％到40％的价值。提高投资回报率：缩短上市时间是Scrum项目实现更高投资回报率（ROI）的一个关键原因。由于收入和其他目标福利开始提前，早期积累意味着更高的总回报率。这是净现值（NPV）计算的基本原则。士气高级团队：与喜欢工作的快乐人士一起工作可以令人满意和有益。自我管理将通常由经理或组织做出的决策放入scrum团队成员的手中。加强团队协作：当Scrum团队负责项目和产品时，他们可以产生很好的结果。Scrum团队通过增强团队参与和沟通来协作并掌握质量和项目绩效。Scrum框架Scrum很简单。它与大量交织的强制组件相反。Scrum不是一种方法论。Scrum实现了经验主义的科学方法。Scrum用启发式方法取代了程序化的算法方法，尊重人和自组织，以处理不可预测性和解决复杂问题。下图显示了Ken Schwaber和Jeff Sutherland在他们的“30天软件”一书中描述的Scrum in Action，它将我们从规划到软件交付。Scrum流程的组成部分Scrum框架本身非常简单。它仅定义了一些通用指南，仅包含一些规则，角色，工件和事件。然而，这些组件中的每一个都很重要，用于特定目的，对于成功使用框架至关重要。Scrum Framework的主要组件是：Scrum角色：Scrum Master，Scrum产品负责人和Scrum团队工件：Sprint积压，产品积压，燃尽图，日志等……Scrum活动：Sprint计划，春季评论，每日站立，冲刺复古等……短跑下图显示了SCRUM框架的关键元素。该过程已由敏捷软件工具Scrum Process Canvas应用。Scrum角色当一个组织决定接受Scrum时，首先要了解的是Scrum角色与传统项目执行角色的不同之处。虽然Scrum中只有三个主要角色，但它们并不会自动与我们大多数人熟悉的标题保持一致。让我们从每个的简要定义开始：产品拥有者产品所有者是代表业务或用户社区的人员的scrum开发角色，负责与用户组合作以确定产品版本中的功能。产品负责人的主要职责是：制定产品和服务的方向和战略，包括短期和长期目标;提供或获取有关产品或服务的知识;了解并解释开发团队的客户需求;收集，优先排序和管理产品或服务要求;接管与产品或服务预算相关的任何责任，包括其盈利能力;确定产品或服务功能的发布日期;每天与开发团队一起回答问题并做出决定;接受或拒绝与Sprint相关的已完成功能;在每个Sprint的最后展示开发团队的主要实现;负责产品BacklogScrum大师Scrum master是敏捷开发团队的推动者。Scrum是一种方法，允许团队根据敏捷原则自我组织并快速进行更改。Scrum master管理信息交换的过程。Scrum Master的主要职责是：充当教练，帮助团队遵循Scrum价值观和实践;帮助消除障碍并保护团队免受外部干扰;促进团队与利益相关者之间的良好合作;促进团队内部的常识;保护团队免受组织干扰;Scrum团队Scrum团队（又名开发团队）由3到9人组成，他们必须满足提供产品或服务的所有技术需求。它们将由Scrum Master直接引导，但不会直接管理。他们必须是自我组织的，多才多艺的，并且负责任地完成所有必需的任务。开发团队负责从分析，设计，开发，测试到技术写作等每个sprint提供潜在的可交付产品增量。对于Scrum团队具有以下特征非常重要：团队必须是自组织的。所有团队组件必须管理自己的工作以完成已经给出的任务。在Agile Scrum中，没有团队负责人或直线经理的身影。每个人都必须做出足够的承诺来开展自己的活动，并为团队的成功做出贡献。如果一个失败，每个人都会失败。团队必须是跨职能的。所有团队成员必须拥有所有必需的知识和技能，以提供做得好并且随时可用的服务或产品。专家可用于必要的案例，但仅作为教练将知识传授给团队以实现特定差距。成为产品负责人需要企业愿景。产品负责人代表客户的声音，需要将他们的需求转化为Scrum Master和开发团队。这通常是一份全职工作。Scrum Master不是直线经理。他们帮助向开发团队提供所需的教练，并帮助消除团队面临的任何障碍。Scrum工件SCRUM工件用于帮助定义进入团队并且当前正在团队中工作的工作负载。还有更多的工件，例如，用户故事，发布积压，刻录图表等。但我们将专注于核心三：产品积压产品待办事项是用户故事的集合，其呈现产品团队所需/期望的功能。通常，产品所有者负责此列表。Sprint积压Sprint积压包含一系列可以包含在当前sprint中的故事。有关sprint积压与将项目包含在sprint中之间关系的两个要点需要注意。1）团队决定添加到sprint的内容。因此，团队负责交付这些物品的所有权和责任。2）在将项目从sprint backlog中删除并添加到sprint之前，团队必须确保他们拥有积压中所需的所有信息。通常，团队定义在添加项目之前必须存在的项目清单。产品Backlog与Sprint Backlog在冲刺积压是Scrum的冲刺过程中完成了由Scrum团队确定的任务列表。在sprint计划会议期间，团队通常以用户故事的形式选择一些产品待办事项，并确定完成每个用户故事所需的任务，如下图所示：刻录图表刻录图表是剩余工作与时间的图形表示。突出的工作（或积压工作）通常在垂直轴上，沿水平方向的时间。也就是说，这是一份杰出工作的运行图表。它可用于预测何时完成所有工作。它通常用于敏捷软件开发方法，如Scrum。但是，刻录图表可以应用于任何包含一段时间内可衡量进展的项目。杰出的工作可以用时间或故事点来表示。Scrum活动沟通是关键！SCRUM依赖于团队的所有方面并且透明地工作（Scrum支柱＃1）。考虑到这种核心理念，该方法围绕一系列关键事件构建，以确保其他两个支柱：检查和调整如下表所示：事件检查适应Sprint计划产品积压（承诺回顾）（Done的定义）冲刺目标预测Sprint积压每日Scrum冲刺目标的进展Sprint积压每日计划Sprint评论产品增量产品积压（发布）市场商业条件产品积压Sprint回顾团队合作技术与工程完成的定义切实可行的改进注意：在执行每个sprint期间，Scrum中有五个主要会议，如下图所示：Sprint计划所有冲刺都从计划开始。团队需要确定并承诺将作为sprint的一部分交付哪些项目。可能的项目总是从Sprint Backlog中获取，如下图所示：这是SCRUM主人可以发光的时间。产品所有者从业务/客户的角度确定他们需要的方面，SCRUM团队，确定他们认为可以提供哪些项目，以及SCRUM主人适应所有项目并确保满足两个方面的最佳要求。每日Scrum会议一旦团队确定了他们承诺作为sprint的一部分交付的项目。该团队将举行每日站立会议。此次会议的核心目标是确保团队中的每个人（以及可能的观察员）完全了解正在完成的任务的状态和进度：他们做了什么他们今天要做什么什么阻止他们此每日更新向团队提供实例反馈并提供。这些会议意味着简短，每人不超过3分钟。注意：观察员在那里观察，SCRUM主人必须尽可能减轻外部干扰和团队干扰。Sprint评审会议在Sprint结束时举行Sprint评审/演示会议以检查增量。团队根据完成定义演示增量，重点关注Sprint目标。产品负责人审核并接受交付的增量。Sprint回顾冲刺回顾通常是冲刺中最后完成的事情。许多团队将在冲刺审查后立即执行此操作。包括Scrum Master和产品所有者在内的整个团队都应该参与其中。您可以安排scrum回顾展达一个小时，这通常是足够的。回顾展让团队有机会确定3个关键方面：应该开始做什么？什么不顺利（并再次停止做）？什么进展顺利（并且应该继续做什么？）？这种方法的目的是不断提高团队效率。积压细化会议将积压视为项目的路线图。当团队协作创建需要为项目完成构建或完成的所有事项的列表时，可以修改此列表并将其添加到整个项目中，以确保满足项目的所有必要需求。短跑在Scrum框架中，Scrum产品Backlog中实现条目所需的所有活动都在Sprint中执行（也称为“Iterations”）。短跑总是很短：通常大约2-4周。每个Sprint都遵循一个定义的过程，如下所示：如前所述，产品待办事项中的项目按优先级排序并选择sprint backlog。一个sprint只包含几个大项目，即使单个项目低估工作的影响也会对sprint产生深远的影响。而且由于较大的项目往往难以估计和理解，因此短跑失败的可能性会进一步增加。经验丰富的Scrum团队花费时间和精力将复杂和较大的项目（即用户功能或史诗）分解为较小的用户故事（或随后分解为任务或子任务）。史诗史诗捕捉了大量的作品。它本质上是一个“大型用户故事”，可以分解为许多小故事。完成史诗可能需要几次冲刺。因此，当我们将epic用于开发时，它必须被分解为更小的用户故事。在项目周期的早期，我们提出了Epics。这些是非常高级的，几乎以营销为中心的功能性要点。我们将大型故事称为“史诗”，以传达有关它们的信息。我喜欢把这与电影有关。如果我告诉你一部特定的电影是一部“动作冒险电影”，它会告诉你有关电影的一些信息。可能有一些汽车追逐，可能是一些射击，等等。同样，将一个故事称为“史诗”有时可以传达其他意义。用户故事故事是产品要求或业务案例的简要陈述。通常，故事用简单的语言表达，以帮助读者理解软件应该完成的内容。产品所有者创建故事。然后，scrum用户将故事分成一个或多个scrum任务。用户故事通常是最终用户可见的功能。用户故事遵循“我作为世界卫生组织想要做什么”的格式，以便为什么。用户故事为客户/用户提供价值。这是客户/用户的产品要求。例如“作为客户，我希望能够创建一个帐户，以便我可以看到我去年购买的商品，以帮助我明年的预算。”任务另一方面，任务更具技术性，任务通常类似于代码，设计，为此类创建测试数据，自动执行等等。这些往往是由一个人完成的事情。任务不是以用户素材格式编写的。任务更具技术性。例如“评估用户界面的角度材料设计”或“将应用程序提交到应用商店”。為初學者提供更多敏捷和Scrum文章Scrum和自组织团队 (Scrum and Self-Organizing Team)敏捷和Scrum - 有什么区别？在Scrum Sprint中发布的频率是如何确定的？通过3个步骤建立自组织团队The Best Free Scrum Learning Resources, Guides and Articles为什么敏捷开发是您项目的更好选择？为什么Scrum是 - 快速失败技术?8经常被误解的Scrum Master角色Scrum Events - 初学者阅读文章Scrum在3分钟内完成

词汇表：精益，敏捷，Scrum，Sprint，看板将Lean和Agile看作几乎相同的事情，它们基本上是处理具有很多不确定性的项目的好方法，这就是为什么成功的初创公司采用这种方法。 （有关精益，敏捷和Scrum起源的事实历史，请参阅 此处 。）Scrum和Kanban是最受欢迎的两个敏捷项目管理框架。 它们有很大的不同 - Scrum似乎更常用，纯粹的看板更少。 但实际上每个人都使用他们自己的Scrum修改版本，这是鼓励的，通常采用看板的元素（我们也这样做）。Sprint是一个Scrum术语。 这是Scrum中的迭代周期。所以： 精益≈敏捷> Scrum>冲刺为什么精益和敏捷？因为在这个不断变化的社交和数字参与世界中，我们需要更好的方式来开展业务和管理组织。精益和敏捷是现代组织功能失调的两个主要原因的解毒剂：瀑布项目管理 ，和功能层级组织结构 。瀑布与敏捷项目管理当我们想到项目管理时，我们大多数人都会想象一个规范，循序渐进的工作方法，并有良好的规划和明确的目标设定。 这基本上是瀑布项目管理。瀑布项目管理思想在我们的文化中根深蒂固。 我们的教育强调良好的准备和一步一步的审慎。 进展正在达到检查点的标记。 了解我们正在走上正轨可以让我们感到舒适和自信，同时也有助于我们的教师和领导者更轻松地监控和管理。 这是一个很好的方法。 没有瀑布，世界上许多现代奇迹都不会存在。 全球各地的企业已成功扩展瀑布。 但瀑布有其局限性：它在重复性和相对较低的不确定性项目中运行良好。现实是，世界充满了不确定性。 人类的行为很难预测。 在您正在开发尚未找到市场的产品的项目中，瀑布式项目管理是寻找适合产品市场的非常昂贵的方式。 您可以负担得起废弃和重建产品的次数有限，并且在瀑布中进行另一次产品构建迭代所需的时间会使您在竞争中处于劣势。敏捷成为解决瀑布缺点的解决方案。 对于企业来说，它是一种更快，更具成本效益且风险更低的方法，可以应对其业务的诸多不确定因素。 在这个快速数字化转型的世界中，不再仅仅是创业公司必须应对扰乱市场。 跨行业的各种规模的企业都需要更好的方法来应对变化，敏捷是一种解决方案。传统与敏捷组织结构委派工作对领导者和管理者来说是一项日常挑战。 团队之间的移交文化为追求更高层次的企业目标创造了障碍。 敏捷通过重新定义的团队合作和领导模式从根本上解决了这些组织挑战。在传统组织中，领导和管理团队负责决策 - 战略和解决问题，预计答案将来自上方。 这给领导者“做出正确决策”带来了巨大风险。 再一次，在这个快速发展的数字和社交时代，对任何人而言，很难一气呵成。 认识到解决问题是一个发现过程，敏捷鼓励假设建立和实验作为一个整体组织练习。 简单地说，更多的眼睛和集体智慧增加了“把事情做对”的机会。精益与敏捷的精神精益和敏捷是方法，而不是方法。 即使是敏捷的实施框架Scrum，也拒绝称之为方法论。 这是因为没有一种严格的方法可以解决所有不确定性问题。 相反，你遵循某些共同的原则，或者可以概括为精益和敏捷的精神，并且大量适应：坚持不懈地追求产品市场契合度 （=为客户提供真正的价值）作为整体组织的努力。列表项目建立，衡量，学习 ：接受不确定性 - 这就是为什么我们假设，测试和验证我们是否越来越接近客户真正想要的东西。 在它被钉住之前，以小增量进行并继续迭代。了解客户，而不仅仅是销售和营销或领导团队，这是每个人的工作。 认为客户不是别人的工作 - 这也是你的工作。 因此，您被允许并被鼓励与客户一起进行构建测量 - 学习实验（即使您不是直接面向客户），领导团队将作为仆人领导者，促进系统化的协作工作框架。在Lean＆Agile中，没有人会受到指责。 如果出现故障，我们不会责怪某人，而是检查产生故障并修复故障的系统。实施Scrum视觉层次结构首先，您的企业愿景需要以“连接”的方式与组织中的每个人共享：您的员工所做的一切，一直到个人工作的任务级别，需要连接到愿景。这比人们想象的要难。 领导能够分辨和销售愿景，但这并不一定能让每个人都参与其中。 视觉分享练习实际上是与您的员工一起进行的视觉形成练习。输入Scrum：Epic，Story，Task是Scrum术语，可帮助人们思考产品或项目中需要构建或完成的所有关键事项，以实现共享愿景。 根据设计，Scrum通过沿着视觉层次结构进行“Backlog”创建练习，将每个人放在同一页面上。运行SprintScrum是一个由时间限制的项目管理框架，由Sprint组成，根据团队工作的特点，您可以设置一个固定的工作周期，通常在一到四周之间。 （据您所知，另一个流行的敏捷项目管理框架看板是一种“容量受限”的方法。）我们的想法是以小增量和快速迭代的方式完成工作，特别强调审查工作以帮助团队实现目标。 假设构建和重复实验是Scrum不可或缺的一部分，因为大多数项目都面临不确定性，而发现是关键（营销是一个很好的例子 - 产品市场适合自己是一个发现过程）。1.积压 (backlog)想想可能包含在产品中或需要在项目中完成的所有事情。 踏上用户旅程的道路：用户故事是将客户需求和需求置于背景中的一种很好的方式。用户故事：作为[用户]，我想[什么]，所以[值]。2. Sprint计划 (Sprint Planning)优先考虑和估计Backlog，决定在即将到来的Sprint中做什么。为了估计完成每项工作需要多长时间， 规划扑克 很有用。该 看板 （或Scrum的董事会）是Scrum的一个关键项目。 这是信息持久显示，可视化和与团队共享的地方。 鼓励定制以适应团队的工作流程。完成的定义 是Scrum中另一个必须遵守的规则。 Done的定义不仅仅是Sprint团队成员在发布前验证工作的质量保证概念。 它也是Sprint中发生的许多假设和实验的测量和学习标准。Scrum中有两个辅导员角色。 第一个是 产品所有者 ，“什么”的人，第二个是 Scrum Master ，“如何”的人。 关键在于促进 - Scrum团队的生产力以“ 速度 ” 来衡量 ，或者他们能够以多快的速度完成任务，并且最有效的是促使团队成员单独和共同决定做什么和做什么，而不是而不是像传统的等级组织那样指导他们。3.每日站立 (Daily Standup)一个典型的Scrum团队应该在3到9人之间 ，包括产品负责人和Scrum Master。 任何更大的，团队的速度下降，所以最好分成不同的Scrum团队。速度的关键在于团队成员之间在进步和障碍方面的丰富沟通。 固定格式每日站立被证明是用于这一目的非常有效： 每天都 在 同一时间 ，为 不到15分钟 ，球队在看板前聚集，并且每个团队成员通过回答以下分享他们的进步三个问题：✓昨天做了什么工作？✓今天计划做些什么？✓任何阻碍的方式？或者，团队也可以按照看板上的完成和待办事项的顺序进行。 如果多个团队成员参与每个看板委员会项目的工作，这可以是更好的格式。在 每日站立不是状态更新会 为经理，找出谁是落后于计划或给工作指令。 状态更新仅提供快照 - 重要的是签入流程。 站起来是团队了解已完成的工作和剩下的工作，以便人们加快团队合作。 如果有人被困，其他团队成员会帮忙。 如有必要，Scrum Master会重新调整工作流程，以便于移除障碍物。4. Sprint评论和回顾 (Sprint Review and Retrospective)在每个Sprint结束时，Scrum团队会召开两次会议。第一个是“什么”会议：Sprint Review将讨论由产品负责人推动的最后一个Sprint所做的工作。 这次会议通常伴随着新版本和其他成就的演示，欢迎来自组织其他成员的成员加入。第二个是“如何”会议：Sprint回顾展。 这是Scrum团队成员反映和讨论在上一个Sprint期间出现的障碍，即使事情进展顺利，还有改进的想法。 Scrum所有者通过确保重点仍然是修复流程而不是人们责备来促进此会议。在两次会议结束时，团队更新Backlog并计划下一个Sprint。Scrum的常见陷阱‣无灵魂的Scrum：冲刺为迷你瀑布通常，用户故事成为迷你规范文档。 然后，执行编码或任何活动，然后进行UAT（用户验收测试）或其他签核过程。 乍一看，这听起来并不错，许多团队陷入了这个陷阱。问题是，这只是以迷你瀑布风格运行的迷你项目。 分析，设计，编码和测试以顺序方式完成，可能跨越多个Sprint，最有可能作为功能之间的移交过程（例如BA（业务分析师）>开发人员> QA（质量保证））。精益与敏捷是关于不确定性的发现。 在Scrum中，构建 - 度量 - 学习周期被设计为在Sprint中发生，并且从事假设，MVP（最小可行产品）构建和测试的团队成员需要彼此尽可能地工作; 即跨职能团队合作。 工作不必是顺序的 - 如果某些东西不起作用或缺少标记，那么完全可以进行设计更改和修改，或者做出有意识的决定以采用不同的方法; 即调整和微型旋转。 迷你瀑布击败了迭代的目的，只实现了Scrum的小增量优势。‣领土Scrum敏捷现在在软件开发团队中很常见。 问题是，在许多组织中，只是运行Scrum的开发团队，有效地在组织内创建了一个岛。结果是开发团队与组织其他部门（即销售团队）之间的交流文化：“我们按照您的规范将产品整合在一起，现在就去销售它”。传播组织范围敏捷的关键是让人们将敏捷视为一种更广泛的沟通，合作和共同创造概念，而不仅仅是一个项目管理框架。 问一个问题，如果我们内部无法很好地连接，我们如何与客户建立联系？ 这应该会促使持续的客户价值创造和产品市场适应各个团队的思维。在组织范围的敏捷的实际实施方面，销售和营销的Scrum可以与开发团队的Scrum并行运行。 最终，最好的目标是转向跨职能的Scrum团队，其中开发，销售和营销职能都在每个Scrum团队中，并与产品或客户项目保持一致。‣Scrum Master in Command在每日站立期间，如果人们向Scrum Master提供状态更新，并且Scrum Master告诉人们该做什么，那么你就是在击败Scrum的目的。Scrum是一种系统性的努力，可以使组织脱离管理者 - 工作者模式。 在解决问题的企业中，指挥领导模式失败 - 它依靠领导者得到所有答案，使领导者自己成为障碍。在敏捷组织中，你试图从人们身上带出所有“合作” - 合作，协作，协调，共同创造，沟通，联系等等。 Scrum Master的作用是保持“co”流向侧面，而不是像指挥一样垂直。我们还必须了解“工人”在经理 - 工人模式中的被动安慰：接受工作指示是令人欣慰的，因为您不必考虑原因和方法，并且您不受决策责任的影响。 Scrum以多种方式解决了转变为自主工作模式的痛苦; 小型构建模块方法使工作更容易管理，每日站立是为了让团队成员在遇到困难时互相帮助，并且不责备人的文化鼓励个人承担实验风险。‣冲刺直到你掉落如果一个领导者设计“冲刺”作为一种系统的手段，使人们在永久的高度戒备中尽可能地努力工作，那只是危机的习惯性管理，或者更糟糕的是，剥削劳动力。一个不那么邪恶的领导者可能将“冲刺”定位为类似于赛道或游泳中的间歇训练。 他可能会说，通过持续不断的紧张工作，团队将能够突破其表现的界限。 但这会给团队成员带来精神疲惫的风险。 在如此高压力的环境中吸引和留住人才是很难的。在一次Sprint之后，下一个Sprint立即开始。 如果团队开始尝试从最后一个恢复新的Sprint，显然他们已经过度踱步。 Sprint必须以可持续的速度运行，不需要Sprint之间的休息或恢复时间。实际上，Scrum Sprints可能不应该被称为sprint。 它应该更像是慢跑或其他东西。 是的，你确实希望你的团队的“速度”增加（在Scrum中我们使用“ Burn Down Charts ”来衡量这一点），但这并不是你追求的终极速度。 你追求的是平均速度的提高，即在相同的时间内覆盖更多的距离。 正如任何长跑运动员都会证明的那样，找到合适的节奏和节奏是迈向远方的关键。采用精益和敏捷并非易事。 精益和敏捷背后的意识形态是理性的，对大多数人来说都是有意义的，但是将其付诸行动需要思维方式的转变和许多破碎的习惯。 虽然如果做得好，精益和敏捷将带来令人难以置信的生产力，积极性和突破组织。 在Lifecycle，我们非常了解组织行为和黑客攻击方法，以推动成功的精益和敏捷组织转型。Agile & Scrum BasisComprehensive Scrum GuideWhat are Scrum’s Three Pillars?What is Agile Software Development?Scrum in 3 MinutesWhat are the 5 Scrum Values?Classical Project Management vs Agile Project ManagementWhy is Scrum Difficult to Master?What is Velocity in Scrum?What is Agile? What is Scrum? ...

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~本文由薄玉桴发表于云+社区专栏今天你敏捷了没有？“敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流，往小了说是改进了开发方法，往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。我们使用 tapd 写 feature，流转、跟踪任务，言必谈敏捷，然而我们是否真的走对了敏捷？（注：tapd 是腾讯内部的敏捷项目管理系统） 。1.朋友，你听说过敏捷么？2.离开敏捷工具，我们怎么敏？3.设计也要介入敏捷流程？4.敏捷跟文档是对立的？5.我这有个几百亿的大项目，怎么敏？6.尽信书，不如无书。一、朋友，你听说过敏捷么？程序员说，要有敏捷从敏捷的滥觞看去，比起方法，这玩意貌似更像一个宗教（笑）。千禧之初，美国在计算机行业已经走了几十年，瀑布流、螺旋模型、快速迭代…各种各样的软件开发流程雨后春笋各领风骚一段时间。虽然不断变化和完善，但互联网的加速发展让传统方法显得笨重，难以快速适应变化。有十七个程序员（程序员改变世界）在美国犹他州的一个风景区开了个碰头会，找到了一个团队耦合度高，流程极其灵活的方法，他们把它称为agile program development。这十七个人如同开宗立派的长老，在会议之后给自己起了个名字“敏捷联盟”，他们不仅赋予了新方法名字，还有宣言，甚至纲领。盐湖城- snowbird（敏捷联盟成立地——雪鸟滑雪场）中文版的“敏捷宣言”。在建立于2002年3月的 《Manifesto for Agile Software Development》里你可以找到几十种语言的“敏捷宣言”。另外，长老们还制定了12原则，作为福音传播。显而易见，敏捷是绝对的结果导向，去文档化，去流程化，高效沟通和合作是究极奥义。看起来是个很不错的方法，文档不重要了，流程不重要了，大家聚在一起说一说就可以了不是吗？太棒了，感觉可以从繁重的文书工作中解脱出来了呢。失之东隅收之桑榆。一处的方便一定意味着另外什么地方以其他方式运行着简化掉的部分。去文档，敏捷管理者需要维护更为精细的需求池；去流程，口头沟通成为常态，对团队的耦合度要求更高。胖友，这里有一份教义，你要不要听一下。初识敏捷，有一些概念需要了解，如果你是老司机，跳过这部分，阿敏。agile：迅速，敏捷。这是敏捷的理念也是精髓：迅速响应需求，快速反馈结果。agile 的引入像一股活水冲击着老气横秋的瀑布流模型，速度上跑赢几条街。sprint：字面意思是短跑冲刺，一个开发阶段被认为是一次冲刺，一个个 sprint 首位相连，构成一个项目。Scrum:指的是英式橄榄球中一股脑争球这一战术或行为。scrum 即为这样一种方式，大家一拥而上，团队是球员，球是产品目标，人员环环相扣，围绕着产品目标进行工作。这里面多少有点“统筹法”的影子，人员深入协作以达到最优化效果。Product Backlog:backlog 即需求池。待办事项列表。Backlog 里面写什么：1.待开发任务。2.任务优先级。敏捷需要维护一份详尽的需求列表。这份列表常常要求 scrum 持有人（一般是产品经理）对所有待开发事项有深入了解，并且能够把待开发事项分解成更为细致的任务（或者跟敏捷教练一起，后面我们会再次提到敏捷教练）story board:很多领域都有故事板的概念，交互领域里，用故事板表述用户场景、电影领域里故事板用来更具体地描述分镜。在开发领域，故事版是任务流转的可视化窗口，一般有“待开发”“开发中”“待测试”“返工”“待发布”几个区块，所有任务由任务操作者负责流转至于下一个步骤，这样任何一个人项目成员都能看到任务的完成情况。一个app使用情景故事版在开发中，故事板展现所有需求的工作流burn down chart：燃尽图一个 sprint 内，人/时是一个比较固定的值。在这个时间框架充分安排开发任务，每天进行时间结算，绘制时间燃尽图。项目成员通过燃尽图获知时间进展，若项目燃尽所用时间与预期时间契合，则需求时间预估和安排合理，若不契合则需要在下一个 sprint 进行调整。名词听起来都玄乎乎的，很符合开宗立派的气质。这些概念定义了敏捷各个环节的工作，这些流程和节点是敏捷开展的基础和保障。二、离开敏捷工具，我们怎么敏？一个误区：我们用了敏捷管理工具，就敏捷了随着敏捷在行业内的不断融入，各种工具产品层出不穷。国外jira、redmine，Axosoft ，国内的leangoo 、禅道，三大家则都有自研的工具，百度的icafe，阿里的aone，我鹅自研tapd。（数据来源：“2016中国开发者白皮书”）我们在 tapd 上建迭代，建需求，研发、测试等着收到需求流转的邮件之后开始干活…任务在测试和研发之间流转，bug 提给研发，研发解决 bug …..我们宣称：我们敏捷化了！我们习惯于敏捷软件的便利，拉群解决一切，然而却丧失了敏捷的初衷，scrum 的本意。Jira的名字来自于哥斯拉假设我们没有任何项目协同软件，敏捷怎么实施？设定一个环境，现在没有任何协同工具可用，但是所有人都坐在一起。有人站起来说，既然这样，我们不如敏捷吧！敏捷工具消失了敏捷路径里必须有一个项目持有者，制定规划并把握项目走向。这位产品汪我看你骨骼惊奇，你就担负起这个责任吧。另外还有一个关键人物 SM（别想歪）。SM 全称 scrum master，中文称敏捷教练。一般说来，SM 需要由对技术开发以及当前项目明晰的技术经理担任。虽然缺少线上工具，但至少要准备一些简单材料：一卷双面胶+白纸或一沓便利贴；笔，一面平坦的墙或一块黑板。如果还有电脑可用，excel 或者 word，甚至写字板都可以，没有电脑那就白纸好了，总之你得找个地方写下你的需求池（backlog）需求池示例(任务名称、平台、详细描述、优先级按照P0-PX逐渐递减)确定一个 sprint 周期的自然天。可以用月/旬/周等时间概念作为周期，我们选择一周（五个工作日）作为一个 sprint 周期。按照优先级，从需求池中拉出你认为应该加入你们一穷二白的第一个 sprint 里面去的需求，别太贪心，大概觉得差不多一周左右的开发量就够了。拉上SM桑单独开一次小会。当然不是让你俩傻站着，你俩要开会你们一起通览需求，SM 桑根据经验对需求先行分解一遍，比如某需求在开发层面需要分解为 ABC 三部分，这三部分就形成三个开发任务。分解完成后，你得到了一个比较详细的待开发列表。正式开始一个 sprint 开始之前，产品、研发、测试需要一同开一次 scrum 会议，共同讨论本次 sprint 的功能点。会上讨论什么：1.需求讨论或技术讨论；2.成员预估需求所需开发时间；3.需求是否match人力时间，需求排入sprint；4.交流一下感情。每个任务的预估时间在最后由敏捷教练综合判定scrum 会后你的工作：1.整理这个 sprint 内的需求列表；2.整理每个需求的预期开发时间；3.撰写故事版上的小纸条；4.把小纸条贴到故事版上；5.制作一个燃尽图。一个改良版的小纸条，写明开发者、任务描述、预估时间和每日燃尽时间故事版布局如下：一个标准的故事版：最开始所有的小纸条都在“待开发”一栏到此为止，你可以开始 run 起一个 sprint 。以为这就完事了？天真。接下来你必须来参加每日举行的项目短会。这个环节在 agile 中非常关键，是 agile 的日常修炼。为了缩减会议时间，我们一般站着开——所以也叫“站会”，早上上班后或晚上下班前，抽出十到十五分钟时间，完成它。每日站会站会都有什么人参加：1.你（项目持有者）2.SM3.其他 scrum 成员站会干什么：1.昨天大家分别做了什么事，遇到了什么问题，如何解决或寻求解决方案；2.昨天任务的完成状态，剩余多少时间，是否需要进行时间修正（增加时间或减少时间），把已完成的任务流转到下一环节（把纸条从一个item内撕下，贴到下一个item里去）；任务进行中，小纸条的示例3.功能测试后是否有返工；4.交流一下感情。站会之后你的工作：绘制燃尽图。一个燃尽图的示例：正常的 sprint 的任务时间是随着 sprint 的进程逐渐减少的周而复始，完成了一个 sprint 后，你们开了第二次 scrum 会。这时议题多了一项:复盘上一个 sprint。任务未能燃尽；研发返工过多；测试需求淤积…..针对问题讨论解决方案，根据实际情况进行下一个 sprint 的任务安排。自此，我们在没有任何敏捷工具的帮助下，开始了敏捷的旅程。说起来agile developing 本来就是排斥文档的作业方式，为一个小轻快的方法制作一套严谨庞大的工具，基本也算违背了元老们的初衷了吧，科科。三、设计师在敏捷中如何介入？我们正在使用或者听过的一些流程方法——不单敏捷，瀑布流，迭代式，结对开发，精益开发….似乎都不关设计师什么事。既然开发团队抱团敏捷了，设计，这个在产品流程中必不可少而工作内容相对独立的角色，要怎么介入敏捷呢？一种思路是，设计拥有自己的敏捷流程。设计师作为一个 scrum 存在，以从上游获取的需求进行 sprint 。另一种思路，是把设计和测试完全纳入到团队中来，一起进行 scrum 的合作。这样的话，UI工作至少要比开发工作前移至少半个 sprint 。有请产品经理（项目持有者）出场。很好，我们有了一个设计师项目持有者将需求分为“ UI 支持”和“非 UI 支持”两类。我们将小纸条扩展一下。多出来 UI 前置部分的小纸条U I设计师参与到 scrum 会中。对于需要 UI 支持的需求，设计师给出一个 UI 制作的时间预估。项目持有者将这部分时间加到扩展小纸条上去。在一个 sprint 中，设计师的工作跟研发的工作分别进行。当设计师将某一需求完成时，将小纸条的 UI 部分撕下，汇入到“”待开发”中去。一个已经完成了 UI 设计的小纸条示例四、敏捷不需要文档吗？一切为快服务的敏捷特别适合初创团队使用。它能把团队人员紧密结合在一起，高效而有序地输出产能。而常规高效的版本输出往往是初创团队高速发展的第一要务。敏捷了一段时间之后，产品进入正轨，项目拿到拨款，公司拿到投资，你们要扩大团队规模，新入职的同事想了解下产品和技术细节，你告诉TA：你要不翻下 backlog 看看？这个实现你要不看一下代码？这个字段我也不记得有没有了….你抓包看下？新同事一脸懵逼，难道咱们没有文档吗？你自豪地指出：“我们是敏捷团队。”十几个人八九条枪的阶段之后，产品趋于稳定，团队逐步扩大。无论从内部协调还是外部沟通上对产品流程的正规化和文档化要求与日俱增。从短期收益上看，文档对于敏捷开发是非必须品，并且很有可能会拖慢进度。在一个 sprint 中，口头沟通显然效率更高，每个人都有精确到工时的任务，没人有等待文档更新的时间。强调文档就等于放弃灵活性。从长期和宏观上看，文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本，同时降低错误的发生概率。对于一个将要长期实施敏捷的 团队来讲，文档让后续的工作效率更高。一个以讹传讹的过程这样一个功在当代利在千秋的好事，当然要做。那么——谁来维护文档，怎么维护？我们挑选几个重要的文档：产品文档、概要设计、接口文档产品文档：不好意思内个产品经理你过来下。虽然你要维护 backlog 、跟 SM 分解需求、开 scrum 会、写小纸条、开站会、画燃尽图、还有什么外部沟通啊，写 PPT 啊，绞尽脑汁想规划啊……你还得认真把这个文档维护好。对又是你产品文档包括：1.需求；2.加入日期；3.开发版本；4.呈现和详细方案在非敏捷开发流程中，文档在评审会后完善并更新，形成一个给研发参考的实现目标。在敏捷中，需求本身在 sprint 周期内不断完善，你可以在一个 sprint 之后将文档补全。概要设计：敏捷的常规迭代中，概要设计不是一个必须的文档。但全新项目、重构以及重大新功能则必须输出概要设计文档。研发 leader 责无旁贷，这个落你身上了。接口文档：必要且重要。包括接口说明、字段定义、字段类型、值定义、数据上报、错误码等。一般来说约定之后由接口开发者更新文档，如果你们没有云端存储的能力，至少咱们人手一份，定期更新。长久来看，文档是提高效率的一大利器虽然《宣言》中明确地放低了文档的地位（“工作的软件大于详尽的文档”），敏捷强调互动和变化，以及对变化的及时响应。诚然文档恰恰做不到如此灵活。但敏捷真的完全排斥文档吗？文档的时效性和灵活性远低于口头沟通，但却有它实在的好处。1.空间上，文档传播范围更广。规范化和常规化的内容形成文档可以大大减少沟通成本。尤其在多个系统协作的情况下，跨 scrum 、跨团队甚至跨部门的沟通时有发生，文档的重要性和便捷性不言而喻。2.时间上，文档流传性更好。团队不是一成不变的，有人离开有人加入。更新换代中，新人快速了解系统，老兵传承研发理念；在更大的时间跨度上，团队可能成为忒修斯之船，文档的存在就是对产品历程的完整追溯，你将不用他人帮助就可以了解到产品的大部分面貌甚至全貌。五、大项目怎么引入敏捷？看起来敏捷方法特别适合产品常规迭代。有一种可能性是，你的产品需要插入一个巨无霸模块，与其说是模块倒不如说它几乎可以成为一个产品了。你想了想，这么大个项目怎么说产品、设计、研发、测试全情投入也得个一两个月。还能走敏捷吗？注意你的项目时间。有 deadline 的 scrum 是带着镣铐跳迪斯科，时间节点关乎 sprint 的大小。大项目敏捷之前，先得不敏捷几步。可能会发生一到多次需求讨论会。团队必须不厌其烦地理解需求或修正产品经理“天真的幻想”，产品经理使用不断完善的原型同团队进（tao）行( jia )沟( huan )通( jia )。在最后的产品评审之前，至少敲定产品框架和大部分细节。这次评审邀请项目成员和所有协同团队，除了敲定的产品功能，技术上需要得到一些初步结论（比如“能不能做”。事实上，产品经理应该在产品规划阶段就知会协同团队将要做什么）。接下来进行概要设计（新产品、重构、重大新功能必须进行概要设计）。技术评审邀请除设计以外的项目成员和协同团队参会。大项目敏捷中：1.将 deadline 之前的时间分解为多个 sprint 。（deadline 之前必须留出一定“出血时间”用以解决时间预估不足的任务、返工任务以及 bug )2.将所有需求分解成任务，开一次全局 scrum 会。预估时间之后，分散任务到各个 sprint 中。在时间较紧的情况下，sprint 的容量就要相应增加。一个需要加班的 sprint3.进入敏捷流程，常规 scrum 会、站会，燃尽图，故事版。未完成任务在 scrum 会上重新预估时间，滚入新 sprint 内，以此类推（按时完成 sprint 内的任务是目标。实在不行我们还有“出血时间”呢）4.别忘了文档。虽然被推崇备至，但敏捷并不是完美的开发方法。敏捷的最大的优势是灵活，而造成敏捷问题的根源也正是灵活。文末再总结本文重点：1.敏捷是一种流程、方法、理念，甚至信仰。2 用了敏捷管理软件不一定就是敏捷。敏捷的初衷是团队成员能够更加紧密地配合完成工作，线上的的流转如果削弱了这种配合性，反倒背离了敏捷的本意。实际上只要有白板纸张和笔，你的团队就能开始敏捷。4.我们敏捷了，不是不要文档了。在外部交流多、世代跨度长的情况下，文档的必要性显而易见。长期的面对面沟通最终会导致低效，这也是敏捷缺陷的根源。5.设计师可以完全介入到敏捷流程中，只需要做一些细心的安排。6.大项目开发中可以走敏捷，具体问题具体分析，需要根据项目特点制定敏捷计划。（文章所有插图为笔者手绘，版权所有）问答Scrum和敏捷开发有什么区别？相关阅读胡说八道谈敏捷敏捷开发–scrum破解敏捷的密码 【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识此文已由作者授权腾讯云+社区发布，更多原文请点击搜索关注公众号「云加社区」，第一时间获取技术干货，关注后回复1024 送你一份技术课程大礼包！海量技术实践经验，尽在云加社区！ ...