Agile

背景当初所在公司用上了滴滴出品的 agileTC ，整体上十分好用。但有个性能大家都在召唤：反对测试工作中批改用例集内容，并同步批改到残缺用例集中。所以有了这篇文章。 先阐明下具体应用的场景，让大家更了解为什么要做这个性能，目标是什么： 首先，测试集、测试工作这块是自身 agileTC 的已有设计，测试集用于存储测试用例，测试工作用于执行用例。测试工作能够在用例集中筛选/全选用例，进行每个用例的测试后果注销。但测试用例不能批改用例，要批改用例必须到用例集编辑界面（此界面无筛选性能） 在我司的理论我的项目应用中，常见用法是： 1、项目前期次要是多数 1-2 人参加，他们依据需要及技术计划，实现初版的残缺用例，并在外面标记开发自测用例。用例评审用的也是这一版。2、提测前开发自测时，测试会创立对应的开发自测用例并给开发参照执行、注销后果。3、提测后，用例会分给多人执行（人数可能不止后期的 1-2 人），会通过自定义标签模式记录这批用例是谁负责。此时会通过测试工作的筛选条件来筛选到只剩下此人负责的用例，独自进行执行和注销。 理论执行中，可能会因为需要变更、局部需要细节须要补充等起因，在 2、3 步常常须要更新用例集。尽管也能够到测试集进行更新，但测试汇合计会有过千个用例，而测试工作则只有数百个，因而在测试工作中就进行更新，相对而言会更为不便。 因为总用例集须要用于进行一些数据统计和二轮测试用，所以此时也须要更新。基于此，所以做这个增量保留的性能。 这块性能之前本人其实也有大抵想过，但始终没有想得特地透彻，这次做的过程中也是一开始想着间接用现成的 json-patch 间接就能够满足，但本人随机测试一下就呈现用例被笼罩且没有任何抵触提醒的问题，所以前期罗唆彻底梳理了一遍整体设计思路，再从新写代码、加单测。 这块可能其余有做基于百度脑图的 xmind 用例治理平台相干的同学也有遇到，所以在此分享一下，也冀望大家有更好的思路，能够上面评论交换下。 全文较长，倡议能够先看目录理解大略，再具体看内容设计方案思考现有技术计划是这样的： 1、当初用例集和测试工作，波及 2 个表，test_case 和 exec_record。 2、test_case 表存储每个残缺的用例集 json 内容，包含节点、标签、优先级。这个残缺的 json 能够间接被脑图组件残缺加载和展现。 3、exec_record 表存储每个测试工作的信息，包含筛选条件、各节点的执行后果。其中各节点执行后果存储形式是节点 id+ 测试后果，示例： {"bv8nxhi3c800":"9","c8tws927cpc0":"9","c8tws7dgbm80":"9"}4、在前端界面展现的测试工作内容，理论是通过 用例集表 json 依据筛选条件筛选节点->筛选后节点 json 和测试工作的测试后果进行合并 两个步骤得出。这个合并和筛选是实时的，每次刷新加载测试工作的脑图编辑界面，都会做一遍。 5、对于用例集的多人合作，滴滴自身也自带多人同时编辑用例的性能（集成在前端编辑器中，通过 websocket 实时存储 diff 和更新），但因为之前应用时发现会呈现用例失落、用例反复之类的问题，起因猜想和一些网络不稳固导致同步可能不够实时无关。因为前端编辑器没有开源，无奈真正寻找到本源及修复，加上一些对脑图编辑器二次调整的须要，所以改用了另一个基于 kityminder + vue 改的脑图组件，也因而无奈应用这个自带的多人同时编辑用例性能（这个性能要求编辑器实时上报用户的每一次操作改变，这个性能只有 agileTC 的脑图编辑器组件才具备）。 以前用过的另一个用例治理平台，模型会简略很多： 1、不辨别用例和工作，用例自身就带有注销测试后果性能，数据库只须要存用例内容。 2、保留时，会主动依据服务端内容计算出本次保留和关上界面时版本的 diff ，而后把这个 diff 和最新用例内容进行主动合并存储。若合并发现抵触，则反馈抵触内容，让用户在前端界面手动解决抵触后存储。 在理论实际中，会呈现合并抵触的状况极少，绝大部分状况都是能够间接主动合并存储的。所以大家的理论用法，也根本都是主测先创立一个简略的 xmind 并分好每个人负责的一级节点，而后各负责人员再去往这个一级上面扩大具体的用例内容。 基于下面的这些历史教训和计划，整体设计方案有两个大方向： 方向一：最小改变准则。用例集每次保留都是增量保留（包含工作中编辑、用例集中编辑），由服务端主动通过 base 版本和保留版本得出 diff ，再利用到最新的用例集中。 ...

前言软件开发行业中常用的两种方法，一种是目前非常热门的敏捷开发(Agile)，如 Scrum，Kanban 和 Lean 等，另一种是大家耳熟能详的传统瀑布模型(Waterfall)。在2017年做自动化运维平台的项目中，我非常荣幸成为初始成员之一完整经历了项目的生命周期，感受到 Scrum 和 Kanban 的强大魅力。虽然项目已经过去很久了，但是敏捷开发Agile的思想在平时的工作中都能带给我非常多的帮助，我想把自己的心得和体会做下分享，本文主要通过分享几个简短有趣的视频让大家更快的熟悉Agile，并强烈推荐各位可以在实际项目中实践和灵活应用。 敏捷开发Agile中Scrum与Kanban的实践更新历史2019年06月07日 - 初稿 阅读原文 - https://wsgzao.github.io/post... 扩展阅读 视频分享以下视频建议优先观看，有助于理解Agile和ScrumAgile Product Ownership in a Nutshell https://www.bilibili.com/vide... 7 分钟视频：什么是敏捷开发 Scrumhttps://www.bilibili.com/vide... Agile基础知识扫盲什么是敏捷开发？敏捷开发 (Agile Development) 是一种以人为核心、迭代、循序渐进的开发方法。 怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发； 为什么说是以人为核心？我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。 什么是迭代？迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。 什么是 Scrum？Scrum 的英文意思是橄榄球运动的一个专业术语，表示 “争球” 的动作；把一个开发流程的名字取名为 Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。 而 Scrum 就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。 Scrum 框架Scrum 创造性地发明了很多概念，请大家结合实践来理解3 Roles：三种角色产品经理 (Product Owner)，简称PO，负责产品的需求、进度、目标。项目经理 (Scrum Master)，简称SM，俗称敏捷教练，负责阻挡外界对开发团队干扰，保证团队顺利工作。团队成员 (Scrum Team) ，一般 5~10 人，包括开发、测试和运维等，不仅需要技术能力，还需要很强的沟通能力和自我管理能力。 4 Meetings：四种会议类型，项目开发周期，一般2-4周冲刺规划会议（Sprint Plan Meeting），在启动每个 Sprint 前召开，PO和团队成员将 backlog 分解小模块制定任务优先级，团队成员确认理解需求并计算小模块的工作量。每日站立会议（Scrum Standup Meeting），开发团队成员召开，一般为 5-15 分钟站立式，每个开发成员汇报昨天做了什么，今天计划做什么，是否遇到障碍？冲刺评审会议 (Sprint Review Meeting），在每个 Sprint 结束后，将这个 Sprint 的工作成果演示给 PO、客户、老板和其他相关的人员。冲刺回顾会议（Sprint Retrospective Meeting），对刚结束的 Sprint 进行总结。会议的参与人员为团队开发的内部人员。一般该会议为 1 小时。 ...

今天聊聊敏捷软件过程。 先说结论：据我观察，至少有60%的团队误用了敏捷软件过程，或者说至少60%的团队在进行伪敏捷开发。 与大家通常的认知是相反的，敏捷过程并不是一个非常容易实践或者实施的过程规范。 通常来讲，没有天上掉馅饼的事儿，所以使用敏捷软件过程带来灵活性收益的同时，一定是要付出相应的代价的。 例如： 如果需要实行结对编程，那么在选择团队成员的时候就需要考虑人员的性格特质，或者增加相应的培训和团建活动；如果需要实行测试驱动开发，则要求团队成员对于自动化测试的技术掌握更加熟练和深入；如果需要进行快速设计，则会对开发人员的设计经验有一定的要求，并同时未来一定要有进行重构的时间安排才可以；等等其它最终，你会发现：如果一个团队没有能力实施传统的软件开发过程的话，则他们多半也无法很好的实施敏捷软件过程…… 敏捷过程实施起来其实还是有一些难度的。有一些团队准备实施循序渐进的策略：针对敏捷过程所要求的一些最佳实践，先上一些比较容易实施的，然后在陆续加入其他。 令人失望的是，这样的做法也会引发一些问题。就拿非常流行的极限编程来讲，极限编程所要求的最佳实践实际上是相互循环依赖的！所以仅仅选择某几项最佳实践来进行实施的话，最终会导致整个系统的崩溃！比如： 极限编程讲究的是快速设计，但是其最终的设计合理性和最优性是由CRC讨论会和后续的重构动作来保证的；极限编程省略了冗长的需求分析文档，代之以即用即抛的“用户故事”；但是为了保证功能的正确性，他会有一个更加严峻的要求：现场客户；极限编程没有专门的测试阶段，那么如何保证产品的质量呢？辅助以三个最佳实践：结对、测试先行和持续集成；重构动作保证了架构的最优化，但是谁来保证重构不会对系统带来负面影响呢？测试先行和持续集成；类似的等等于是，有不少团队在实行了敏捷软件过程之后，仍然停留在（或者说倒退回了）游击队式的野生软件开发过程。 那么如何才能够正确的实施敏捷开发过程呢？我理解，至少需要具备如下的前提，才能够比较顺利的实施敏捷过程： 团队成员对面向对象的开发和设计有相当程度的理解和经验（最起码有想要提高或者学习的需求）；团队成员能够熟练的使用自动化测试的框架，并编写自动化测试脚本；团队成员能够熟练的使用持续集成的框架或者产品；团队成员平均沟通能力中上，没有表达能力低下者；至少有一个渠道能和客户（或者有足够话语权的客户代表）进行频繁并流畅的沟通；管理者（包括甲方客户）和开发团队之间有相对比较平等的话语权；管理者（包括甲方客户）能够理解（或者信任）开发团队所提出的一些隐性的工作量（例如重构、编写文档、测试脚本等）所带来的时间成本；上述看似并不太高的门槛，却挡住了60%的软件开发工程师……

PS2018年Agile是什么情况？巴黎圣母院注定要着火？“米"字为什么是012345678? Go成为企业级编程语言新宠？Read on…The Listhttps://martinfowler.com/arti…Martin Fowler做的The State of Agile in 2018。是根据 https://www.infoq.com/present… 这个视频整理的。划重点： Raise the importance of technical excellence, and never forget that when writing software, the technology side is really vital, and organize around products. 通篇没有一次提scrum。现在的scrum，已经被项目经理绑架，偏离了Agile的初心https://drewdevault.com/2019/…Rust is not a good C replacement金句：_Go is the result of C programmers designing a new programming language, and Rust is the result of C++ programmers designing a new programming language_我尝试过学Rust，真是不好学啊。是不是除了Haskel之外最难学的语言？Webassembly on the server is the future of computing.最近Mozilla发布了WASI。Docker创始人Solomon Hykes发帖说了上面的话。我有点懵bi。这是肿么肥私？只能表示密切关注一下????https://github.com/LingDong-/…用RRPL来描述中文字符你不知道RRPL是啥？俺也不知道。全拼是Recursive Radical Packing Language。清楚了吗？没有？只能帮你到这里了。剩下的自己看项目。。。反正我知道“米”这个字是 {0, 1, 2, 3, 4, 5, 6, 7, 8} 1 2 3 |/ 8 -+- 4 /|\ 7 6 5https://drewdevault.com/2018/…Anatomy of a Shell用C语言实现一个Shell。解释了parsing，AST, execution等等。对底层有兴趣的值得一读。大神Guido star了996.icu。发文的时候，所有人都知道了吧。但还是贴一下https://github.com/kubernetes…Kubernetes Perl client! 这是进一步证明Kubernetes一统江湖还是一部分人闲得蛋疼呢？我选后者????。但是开源人就是这么任性。还好只有8颗星。这是说明还有8个人在等Perl 6吗????？https://www.infoq.com/article…Simplicity, Please - A Manifesto for Software Development金句：_A large code base (Google’s is some 2 billion lines) need not be complex, and a small code base may not exhibit simplicity._文章写的有些不好懂，读一下前面的几个bullet也就行了。https://medium.com/netflix-te…Full Cycle Developers at Netflix — Operate What You Build跟着Netflix不仅能追神剧，还能学习软件工程????。记住这个词：Full Cycle Development，也许以后会火。https://github.com/vugu/vuguVugu: A modern UI library for Go+WebAssembly (experimental)对Go程序猿来说，这是Go进一步统治世界的证明。但是。。。还早吧。https://www.infoq.com/present…▶️ Go - A Key Language in Enterprise Application Development?Go会成为企业应用的关键语言吗？我认为会。除非web被什么东西替代了。https://www.nytimes.com/inter…Why Notre-Dame Was a TinderboxNYT认为圣母院注定要着火。论防火墙的重要性。这样的文章真好啊，图文并茂。PPS这篇拖了一段时间。一来忙，二来懒，三来写这个时间成本变高了。又是一个在咖啡馆里面充实的早上☕️。且写且珍惜 ...

什么是游泳车道图？泳道（Swimlane）图是一种流程图 (Flowchart)。与流程图一样，它描绘了从开始到结束的过程，但它也将这些步骤分为几类，以帮助区分哪些部门或员工对每组操作负责。这些通道是使行动与其他通道在视觉上分离的列。泳道图使责任比常规流程图更清晰。在寻求改进流程时，了解哪个部门负责什么可以帮助加快纠正低效率和消除延迟的过程。为什么Swimlane图是有用的在任何流程改进计划中，泳道不仅可以帮助识别流程中的瓶颈，还可以识别哪个部门负责这些瓶颈。游泳通道图也有助于澄清责任并帮助部门在部门通常不了解其他部门所做的事情的情况下协同工作。您可能会发现代价高昂的冗余，重复或差距以及通信问题。如何创建游泳通道流程图确定车道。确定泳道所代表的分区，并标记它们。开始你的图表。定义流程的起点。将圆角矩形添加到相应泳道的顶部以指示其起点并标记它。添加步骤。接下来为图表添加更多步骤。每一步都应该用一条线连接到它前面的那一步。要在同一个泳道中绘制台阶，请从上到下绘制。要在另一个部门中添加一个步骤，请从左到右。在每个步骤中，描述它代表的内容，直到您到达流程结束。步骤之间的箭头表示信息或流量的传递。你自己试试，通过例子学习泳道图免费的Swimlane Diagram示例和模板可在在线Swimlane Diagram软件中编辑：Visual Paradigm Online。使用模板作为起点来创建自己的Swimlane Diagram。Swimlane Diagram Template - 4 Swimlanes课程开发儿童的成长监测仓库Swimlane流程图模板Swimlane图模板垂直跨功能流程图模板跨职能流程图模板垂直的Swimlane图模板学生注册

您想創造難忘的第一印象並為您的客戶提供差異化的購買體驗嗎？您想了解您的客戶如何在當今的數字世界中購物？客戶旅程中最有影響力的渠道和接觸點是什麼？您如何影響這些？這對於您想要輸入的新產品類別有何用處？客戶旅程地圖是一種強大的技術，可以幫助您了解客戶的動機 - 他們的需求，猶豫和顧慮。雖然大多數組織在收集有關其客戶的數據方面相當擅長，但僅憑數據無法傳達客戶所經歷的挫折和體驗。一個故事可以做到這一點，商業中最好的故事講述工具之一是客戶旅程地圖。客戶旅程地圖使用講故事和視覺效果來說明客戶在一段時間內與業務的關係。從客戶的角度講述故事，從而深入了解客戶的整體體驗。它可以幫助您的團隊在體驗您的產品或服務時更好地了解和解決客戶需求和痛點。換句話說，制定客戶旅程可以讓您的企業有機會了解您的品牌如何首先吸引潛在客戶，然後通過整個銷售流程的接觸點。為何選擇客戶旅程地圖？客戶旅程映射的目的是了解客戶經歷的內容並提高客戶體驗的質量，確保所有接觸點和所有渠道的一致性和無縫體驗。沒有任何替代方法可以傾聽客戶關於旅程中的步驟如何為他們解決問題的方法。通過了解客戶旅行與您的業務，您現在可以改善客戶體驗，從而實現：提供整個客戶旅程的鳥瞰圖將團隊聚集在一起，以解決特定的客戶障礙，以了解核心客戶的旅程路徑，其中額外的開發將產生最大的影響。通過識別關鍵步驟和決策點，最大限度地減少負面客戶體驗，從而構建更快，更高的客戶轉化率。通過了解如何通過採購週期的每個階段來提高客戶保留率，以確保所有利益相關方都能獲得併獲取正確的信息。允許企業在特定渠道中放大單個客戶旅程。了解所需的指標，以識別客戶的進度和不足之處，提供機會讓客戶重新加入。允許企業根據客戶體驗策略確定優先級揭示各渠道和部門之間的差距CJM的基本概念客戶旅程是潛在客戶通過所有可用渠道與公司的產品，品牌或（接觸點）的不同聯繫點的旅程，直到他執行期望的目標操作。客戶旅程可延長數小時或數天。主要目標行動是購買，訂單或查詢。接觸點是客戶與您的企業之間的任何联系點，從經典廣告（廣告，電視或廣播點等）到在線營銷活動，再到朋友的意見或評論網站上的信息。可用渠道，如電話，網絡，分支機構，營銷傳播和服務互動。創建客戶旅程地圖旅程地圖可以採用多種形式。然而，最終目標始終如一：找到並解決客戶的痛點。步驟1.定義您的角色人物角色和旅程地圖都是重要的戰略工具，有助於深入了解客戶是誰，他們需要什麼，以及他們如何在所有接觸點與您的業務互動。但更重要的是，要在整個組織內分享客戶見解。用於創建旅程地圖的大部分信息來自您的角色（例如，他們的目標，動機，他們想要完成的關鍵任務以及當前的痛點），這就是為什麼最好先創建角色。您需要決定的第一件事是您將要映射的旅程，例如特定客戶類型（角色），潛在（目標）客戶或一部分客戶，具體取決於您的旅程映射計劃的目的。一旦您創建了不同的角色，您就可以使用它們創建客戶旅程地圖，描述每個角色在與您公司的生命週期中的各個接觸點的體驗。第2步。定義客戶階段旅程地圖通常按客戶階段（有時稱為階段）進行組織。每個階段代表了客戶在整體旅程中努力實現的主要目標。您應該構建一個客戶旅程地圖，其中包含代表客戶目標導向之旅的階段，而不是內部流程步驟。因此，一旦定義了自己的角色，就必須確定客戶旅程的各個階段。從購買您的產品或服務開始，一直考慮從哪個過程開始？根據角色定義客戶隨著時間的推移經歷的階段。定義他們的方式，時間和地點：發現您的公司，研究您的產品或服務，選擇競爭對手，向您購買以及與您建立關係。步驟3.描述您的客戶用於與您的組織交互的接觸點從始至終，客戶接觸點是您品牌的客戶聯繫點。例如，客戶可以在線或在廣告中找到您的商家，查看評分和評論，訪問您的網站，在您的零售商店購物或聯繫您的客戶服務。這似乎是一個很長的列表，但這些只是你的一些接觸點！確定您的接觸點是創建客戶旅程地圖並確保客戶在每一步都滿意的重要一步。第4步。進行研究雖然您可能需要提供一些參與獎勵，但如果他們認為您真正對他們的經歷感興趣並且會使用他們的反饋來改善他人的事情，那麼大多數人都很樂意提供幫助。對於旅程的每個階段，嘗試確定：他們的目標是什麼，他們想要實現什麼目標他們期望這個過程是什麼樣的他們用來完成舞台的步驟和接觸點在每次接觸點體驗期間，他們是如何感受到情感的？他們在舞台上的其他想法完成需要多長時間步驟5.確定摩擦點一旦你理解了你的角色的目標並寫下他們的接觸點，就該看看大局 - 他們與你公司的整體經驗。每個企業都會以不同的方式透視客戶角色。與您的團隊一起走過每個旅程地圖階段，將幫助您識別客戶體驗中的任何摩擦點。當然，每個企業都是不同的，您將最了解您的客戶。下面有一些示例問題可幫助您入門：摩擦力出現在這個特定的接觸點上？人們因此放棄購買嗎？客戶是否了解您已提供的此解決方案？如果是這樣，為什麼不呢？第6步。解決旅程地圖並不僅僅是說明性的。典型的練習應該確定一些快速修復，包括提高享受和改善旅程的機會。當然，大多數公司發現，隨著客戶需求得到更好的理解和滿足，該流程有助於推動更廣泛的客戶體驗改善。簡而言之，繪製旅程應該有助於實現改善體驗和提高投資回報率的具體行動。將您的地圖視為一個活文件，定期重新訪問並根據需要進行更新，並記住與任何相關的利益相關者分享其他應用CJM的技巧使用客戶旅程圖改進和創新通過投資改善客戶體驗來確定推動增長的機會是許多旅程製圖計劃的關鍵目標。您應該構建一個客戶旅程地圖，作為在您的行動計劃中使用的工具。這將顯示您識別機會的位置，評估其影響，成本等，並最終為您的組織設置投資優先級。一些地圖明確列出了地圖本身的關鍵機會。這可以作為溝通工具，特別是如果在優先考慮機會之後添加關鍵機會。通過這種方式，旅程地圖成為一個持續的溝通和治理文件。在旅程地圖中可視化前台和後台到目前為止，我一直專注於前台或外景。後台是指參與交付旅程的內部系統，流程和人員。這是旅程的由內而外的視角。當在單個旅程地圖中組合時，這兩個視圖通常被稱為前台/後台地圖或生態系統地圖。在一個地圖上映射前台和後台，可以查看負責提供客戶體驗的內部資源和流程，這可以幫助您的組織了解交付過程中涉及的內容並最終改善客戶體驗。開發客戶旅程地圖的清單以下是您在創建客戶旅程地圖時會問自己的問題：在使用您的解決方案之前，您的客戶如何找到您以及他們如何解決（或應對）問題？您試圖解決的客戶問題是什麼？或者換句話說，客戶體驗到的產品可以幫助緩解的常見問題和難點是什麼？客戶獲得客戶服務獲取支持的難易程度如何？您是如何通過渠道改善客戶互動的？客戶是否容易為您的產品或服務付款？在线旅行社网上商店网上银行密码恢复现场烤箱维修服务图书馆医院一般销售生命周期模板2一般销售生命周期模板详细的客户旅程地图模板汽车购买在线购买电视基本的客户旅程地图模板销售支持标准客户旅程地图模板接触点模板相關鏈接專業的客戶旅程映射工具YouTube視頻 - 什麼是客戶旅程映射？免費試用Visual Paradigm

第七章 什么是敏捷设计软件项目的设计是一个抽象的概念。它和程序的概括形状、结构以及每一个模块、类和方法的详细形状和结构有关。可以使用许多不同的媒介去描绘它，但是它最终体现为源代码。最后，源代码就是设计。软件设计的臭味僵化性-设计难以改变脆弱性-设计易遭到破坏牢固性-设计难以重用粘滞性-难以做正确的事情不必要的复杂性-过分的设计不必要的重复-频繁的粘贴，赋值晦涩性-混乱的表达，代码难以理解软件腐化的原因由于需求并没有按照初始设计的方式进行变化，从而导致了软件的退化，改动都很急迫，并且进行改动的开发人员对原始的设计思路并不熟悉，因此，虽然对设计的改动可以工作，但是他却以某种方式违反了原始设计，随着改动的不断进行，这些违反渐渐积累，设计开始出现臭味。敏捷团队敏捷团队依靠变化获取活力，不尽兴预先设计，保持系统设计尽可能的干净，简单，并使用许多单元测试和验收测试作为志愿，保持了设计的灵活性，易于理解性，利用这种灵活性，持续地改进设计，以便于每次迭代结束所生成的系统都具有最适合于那次迭代中需求的设计。敏捷设计敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、 干净以及富有表现力。第八章 单一责任原则（SRP）在SRP中，我们把职责定义为变化的原因。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。我们需要分离耦合的职责，并对其持久化。结论SRP是所有原则中最简单的之一，也是最难运用的之一。我们会自然地把职责结合在一起。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。事实上，我们要将论述的其余原则都会以这样或者那样的方式回到这个问题上。第九章 开放—封闭原则（OCP）软件实体(类、模块、函数)应该是可以扩展的，但是不可修改的。开放封闭原则有两大特征对于扩展是开放的有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。对于修改是封闭的类一旦设计完成，就可以独立其工作，而不要对类尽任何修改。结论在许多方面，OCP都是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处（也就是，灵活性、可重用性以及可维护性）。然而，并不是说只要使用一种面向对象语言就是遵循了这个原则。 对于应用程序中的每个部分都肆意地进行抽象同样不是一个好主意。正确的做法是，开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。 拒绝不成熟的抽象和抽象本身一样重要。

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

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敏捷

什么是鱼骨图？鱼骨图（也称为因果图或Ishikawa图）可视地显示问题的多种原因。它有助于识别利益相关者关于问题原因的想法，并允许用户立即将想法分类为主题以供分析或进一步收集数据。它可以与“五个为什么”的技术结合使用。你什么时候使用它？确定问题的可能原因时当难以理解导致系统故障的因素或原因时作为团队流程最有帮助准备鱼骨图的5个步骤？同意问题陈述（也称为影响）。- 写在鱼的嘴里。同意问题的主要原因类别。从主箭头写成分支。- 主要类别包括：设备或供应因素，环境因素，规则/政策/程序因素以及人员/工作人员因素集思广益，解决问题的所有可能原因。问“为什么会发生这种情况？” - 将其写成适当类别的分支。再次询问“为什么会发生这种情况？”关于每个原因。- 写子引起分支原因分支。问“为什么？”并产生更深层次的原因并继续在相关原因或类别下组织它们。有哪些潜在的陷阱？容易关注症状而不是问题的原因如果没有主要参与者的意见，很容易对您认为问题的内容进行假设，而不是实际存在的问题寻找用于创建鱼骨图的最佳简易软件？用Visual Paradigm创建鱼骨图[](https://www.visual-paradigm.c…单击工具栏上的图表>新建。2.在New Diagram窗口中，选择Cause and Effect Diagram（鱼骨图也称为因果图），然后单击窗口底部的Next。3.为图表命名（例如：查找图形时遇到困难），然后单击“确定”以完成创建新图表。4.然后你会看到这样的东西：5.双击图表右侧的“ 问题 ”，然后重命名。在这种情况下，我们将其重命名为_“查找绘图时的难度”。6.双击_Category1_将其重命名为_Man，然后右键单击_Man_并从工具栏中选择Add Primary Cause以创建新的主要原因。7.双击_原因_并将其重命名为_库工作人员未充分了解，然后通过右键单击_库工作人员未充分通知_创建次要原因并选择添加辅助原因。通过双击重命名次要_原因。9.重复上面的步骤5到8以创建更多主要和次要原因。10.要创建新类别，请右键单击鱼中的任何空白区域，然后从工具栏中选择“添加类别”。11.完成图表后，您将看到类似的内容：其他鱼骨图资源如何创建鱼骨图？ - Visual Paradigm因果图工具

如果您曾尝试使用MSVisio®创建流程图，您知道这并不容易。Visual Paradigm Online（VP Online）更加用户友好且直观，更不用说它的成本更低且平台中立。让我们来看看为什么Visual Paradigm Online是最好的Visio®替代软件。VP Online更具成本效益为 您的整个组织提供低于MSVisio®等效座位数的维护成本 - 节省高达50％。在此请求网站许可证报价。VP Online是跨平台的 作为基于云的图表软件，VP Online支持各种在线图表工具，如UML，BPMN，ArchiMate，ERD，组织结构图，PERT，SWOT，思维导图等。因为VP Online工作原理在网络上，用户可以通过任何Web浏览器在线创建图表，无论他们的操作系统如何。VP Online不需要任何安装 VP Online允许您和您的团队在线编辑图表。没有人需要下载和安装任何软件才能绘制图表。VP Online可以导入Visio®绘图和Visio®模板 VP Online允许您在VP Online中打开Visio®绘图和模板并进行编辑。即使您没有安装Visio®，这也可以使用。只需点击几下，您就可以放弃桌面软件，享受更时尚，更直观的图表解决方案。许多用户正在使用VP Online VP Online的资源目录，无论其复杂程度如何，都可以轻松创建任何类型的图表。许多用户使用VP Online创建技术和业务绘图，并将结果包含在他们的文档和演示文稿中VP Online不需要支援服务 VP Online在构建时非常简单。即使没有技术背景的用户也可以使用VP Online而无需事先培训。VP Online不仅仅是图表软件 除了图表，VP Online还支持许多强大的功能。例如仪表板，流程图，客户旅程映射，信息图表制作工具等。常问问题Visual Paradigm Online多少钱？免费用于非商业用途。Visual Paradigm Online的Express Edition是一款免费的图表软件，可用于个人，教育和其他非营利目的。对于商业用途，每个用户每月仅花费4美元，比市场上的其他流程图软件便宜。模板是免费的吗？是的，包括免费的图表模板。您可以根据需要多次使用它们。自己动手吧了解VP Online的最佳方法是亲自尝试。:-)您无需注册或下载。时间很宝贵。只需单击下面的链接即可打开VP Online的图表编辑器并立即尝试。Visual Paradigm Online - 图编辑器如果您想了解有关Visual Paradigm Online的更多信息，请阅读：Visual Paradigm 特征列表相信我。你会喜欢的。请享用！

雖然這篇文章討論了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-形人不是通才，他们在一个领域拥有深厚的技能，但也有其他技能可以帮助他们与其他开发团队成员合作。例如，伽利略和哥白尼是众所周知的天文学家。哇，你可能认为开发人员拥有的技能太多，这些开发人员是否存在？是的，他们存在，但不幸的是，他们中的大多数人已经很高兴与一家好公司合作。而且由于软件正在吞噬世界，软件的作用越来越重要，我们需要提高游戏的门槛。

(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的基本功 - 集合中英文版本 (角色和责任篇)

本教程适用于敏捷软件开发新手的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分钟内重新开始工作，除非出现非常有趣的事情。

什么是用户故事？用户故事是简短而简单的功能描述。它们是从系统的用户或客户的角度编写的。它们通常遵循简单的格式：作为[用户类型]，我希望 [某个目标] 以便[某种原因]。最初，用户故事是在索引卡或便签上写的。它们被安排在墙上以便于规划和讨论。您现在可以在任何主要的敏捷工具中突出显示它们。实体卡片或笔记将焦点从通过讨论的写作转移到关于能力和共享理解。事实上，这些讨论比故事中所写的更重要。谁写了用户故事？用户故事由业务代表以客户特定语言编写。我们之所以这样做，是因为我们希望业务部门和开发团队能够清楚地了解客户需求和原因。开发团队的工作是满足用户故事的验收标准。在Scrum中，产品负责人代表业务。产品负责人团队将完成该活动。何时撰写用户故事在整个产品或项目生命周期中编写用户故事。任何时候，任何人都可以编写新故事并将其添加到产品待办事项中。如果您的交付团队正在尝试预测发布计划，请在产品待办事项中维护大约准备好3个冲刺的用户故事的数量。而且付将用户故事写为功能的子集上付更大的努力。在这些情况下，产品所有者团队与交付团队协作，将故事分解到足够的水平。[作为]网站成员，[我希望]以半结构化的方式在我自己的页面上描述自己，[以便] 其他人可以学习 关于我。 也就是说，我可以填写预定义的字段，但也有一两个自由文本字段的空间。 （这会很好 让这个自由文本是HTML或类似的。）[As a] site member, [I want] to describe myself on my own page> in a semi-structured way [so that] others can learn about me. That is, I can fill in predefined fields, but also have room for a free-text field or two. (It would be nice to let this free text be > HTML or similar.)[作为]网站会员，[我希望] 可以填写申请成为认证Scrum从业者，[以便] 我可以获得 指定。 [注意：认证的Scrum Practitioner是被称为Certified Scrum的最初名称专业的。[As a] site member, [I want] to fill out an application to become a Certified Scrum Practitioner [so that] I can earn that designation. [Note: Certified Scrum Practitioner was the initial name of what became known as Certified Scrum Professional.[作为]一名从业者，[我希望]我的个人资料页面包含有关我的其他详细信息（例如，我的一些答案） 从业者申请）[以便]我就可以展示我的经验[As a] Practitioner, [I want] my profile page to include additional details about me (i.e., some of the answers to my Practitioner application) [so that] I can showcase my experience.[作为]培训师，[我希望]我的个人资料页面包含有关我的其他详细信息（即我的一些答案） 培训师申请），[以便]其他人可以了解我，并决定我是否适合他们。[As a] Trainer, [I want] my profile page to include additional details about me (i.e., some of the answers to my Trainer application) [so that] others can learn about me and decide if I’m the right trainer for them.[作为]培训师，[我希望]我的个人资料能够列出我即将开设的课程，并包含指向每个课程详细页面的链接 [以便]未来的参加者可以找到我的课程[As a] trainer, [I want] to list my upcoming classes and include a link to a detailed page about each [so that] prospective attendees can find my courses.[作为] 网站成员，[我希望]我可以查看其他成员的个人资料，[以便]找到可能需要联系的其他成员。[As a] site member, [I want]I can view the profiles of other members so that I can find others I might want to connect with.[作为]一个网站成员，[我想**]根据几个字段（类、位置、名称）搜索配置文件，这样我就可以找到其他我想联系的人。[As a] site member, [I want] to search for profiles based on a few fields (class attended, location, name) [so that] I can find others I might want to connect with.更多关于用户故事的文章用户故事工具What is User Story?What is Story Point in Agile? What is User Story Mapping? ...

我们汇总了您可能会在面试中获得的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？什么是敏捷计划扑克？

敏捷是一个术语，用于描述软件开发的方法，强调增量交付，团队协作，持续计划和持续学习，而不是试图在接近结束时立即交付。敏捷专注于保持流程的精益，并创建最小的可行产品（MVP），在最终结果出现之前经历多次迭代。不断收集和实施反馈，总而言之，这是一个更加动态的过程，每个人都在朝着一个目标努力。Scrum和其他领先的敏捷方法敏捷是一种思维方式，它是一套价值观和原则。敏捷是一种思考和行动的方式。敏捷就是短周期，迭代和增量交付，快速失败，获得反馈，及早向客户提供商业价值，关于人员，协作和互动。敏捷是一种关于透明度，检查和适应的心态。但是，敏捷不包含任何角色，事件或工件。这是一种心态。例如，Scrum是敏捷伞下广泛使用的框架之一，它可以帮助你变得更敏捷，但敏捷运动中有更多的框架，如看板，XP，Crystal等等，如图所示下面：ScrumScrum是一个框架，人们可以在其中解决复杂的自适应问题，同时高效且创造性地提供具有最高价值的产品。它用于管理软件项目和产品或应用程序开发。它的重点是适应性产品开发战略，其中跨职能团队作为一个单元在2-4周内达成共同目标（Sprint）。它由一系列价值，文物，角色，仪式，规则和最佳实践组成。Lean (精益)精益起源于丰田生产系统（TPS），它在20世纪50年代，60年代及以后彻底改变了实物商品的生产。精益保持其在制造业中的地位，但也在知识工作中找到了新的应用，帮助所有行业的企业消除浪费，改进流程并促进创新。软件开发是精益方法的自然应用，因为与制造业一样，它通常遵循一个确定的过程，具有一定的接受条件，并导致有形价值的传递。指导精益方法所有实践的关键概念，我们称之为精益支柱。他们是：连续的提高尊重人轻量级领导看板 (Kanban)看板是一种高度可视化的工作流管理方法，在精益团队中很受欢迎。事实上，83％的精益生产团队使用看板来可视化并积极管理产品的创建，重点是持续交付，同时不会使开发团队负担过重。与Scrum一样，看板是一个旨在帮助团队更有效地协同工作的流程。看板基于3个基本原则：可视化您今天要做的事情（工作流程）：查看彼此上下文中的所有项目可以提供非常丰富的信息限制正在进行的工作量（WIP）：这有助于平衡基于流的方法，因此团队无法启动并立即承诺过多的工作增强流程：当某些内容完成后，积压中的下一个最高优先级项目将被激活看板通过定义最佳的团队工作流程，促进持续协作并鼓励积极，持续的学习和改进。动态系统开发方法（DSDM）DSDM是一个由八个原则组成的框架，包括生命周期和产品，角色和职责以及几种最佳实践技术。这些支撑和支持的理念是尽早提供具有战略意义的商业利益，从而为组织提供最佳的投资回报率（ROI）。DSDM是一种优先考虑计划和质量而非功能的方法，它在一开始就修复了成本，质量和时间，并使用MoSCoW优先级排序方法，将项目分解为四种不同类型的要求：必须有（Must have）应该有（Should have）可以有（Could have）不会有（Won’t have）支持DSDM Atern的原则有八个[13]。这些原则指导团队必须采取的态度和他们必须采取的思维方式，以始终如一地提供。专注于业务需求按时交货合作绝不妥协质量从坚实的基础逐步建立起来迭代开发持续清晰地沟通表现出控制力极限编程最初由Kent Beck描述的极限编程（XP）已经成为最受欢迎和最有争议的敏捷方法之一。XP是一种快速，持续地提供高质量软件的规范方法。它旨在提高面对不断变化的客户需求的软件质量和响应能力。它促进了高客户参与度，快速反馈循环，持续测试，持续规划以及密切的团队合作，以非常频繁的间隔（通常每1-3周）提供工作软件。该方法的名称来源于传统软件工程实践的有益元素被带到“极端”水平的想法。例如，代码审查被认为是一种有益的做法。极端情况下，可以通过结对编程的实践不断检查代码。最初的XP方法基于四个简单的价值观 - 简单，沟通，反馈和勇气。它还有12个支持实践：规划游戏 (Planning Game)小版本 (Small Releases)客户验收测试 (Customer Acceptance Tests)简单的设计 (Simple Design)配对编程 (Pair Programming)测试驱动开发 (Test-Driven Development重构 (Refactoring)持续集成 (Continuous Integration)集体代码所有权 (Collective Code Ownership)编码标准 (Coding Standard)隐喻 (Metaphor)可持续发展 (Sustainable Pace)特征驱动开发（FDD）功能驱动开发（FDD）由Jeff De Luca于1997年在一家大型新加坡银行的软件开发项目中开展。它是一个迭代和增量的软件开发过程，是一种开发软件的敏捷方法。FDD将许多业界公认的最佳实践融合为一个有凝聚力的整体。这些实践是从客户端值的功能（特性）角度推动的。其主要目的是及时反复提供有形的，有效的软件。使用FDD的优势在于，由于“初期设计足够”（JEDI）的概念，它甚至可以扩展到大型团队。由于其以功能为中心的流程，它是一个很好的解决方案，可以保持对敏捷，增量和固有复杂项目的控制。它由五个基本活动组成：开发整体模型构建功能列表按功能规划按功能设计按功能构建。每个项目都有自己独特的模型，这将产生一个功能列表。最后三个活动是短迭代过程，其构建时间不超过两周。如果它需要两周以上，那么它将被分解为更小的功能。水晶 (Crystal)水晶方法是由Alistair Cockburn在20世纪90年代中期开发的一系列方法（Crystal系列）。这些方法来自Cockburn多年的学习和团队采访。Cockburn的研究表明，他采访过的团队并没有遵循正式的方法，但他们仍然提供了成功的项目。Crystal家族是Cockburn对他们所做的事情进行编目的方式，这些项目使项目成功。水晶方法主要关注：人 (people)相互作用 (Interaction)社区 (Community)技能 (Skills)人才 (Talents)通讯 (Communications)敏捷宣言“敏捷”一词是在2001年的敏捷宣言中创造的。该宣言旨在建立指导更好的软件开发方法的原则。敏捷宣言由4个重要的价值观组成。阅读敏捷宣言的方式并不是右侧的物品不再具有价值，而是敏捷运动更重视左侧的物品。那么让我们来看看敏捷宣言的第一行。这条线表明，我们重视人，他们的互动，沟通和协作，而不是拥有各种广泛的流程和工具。当然，流程和工具很有价值，但是，如果它们真正支持人们一起工作并提供优质产品，那么它们就更有价值。我们现在在很多组织中看到的是，流程和工具本身就是目标。从敏捷的角度来看，我们对此有不同的看法。流程和工具应该支持人们共同合作并为客户创造价值。敏捷宣言原则作为敏捷宣言的补充，敏捷联盟还定义了一套12项基本原则，除了敏捷宣言之外，还提供了指导和更详细的解释：我们的首要任务是通过早期和持续交付有价值的软件来满足客户。欢迎不断变化的要求，甚至是开发后期。敏捷流程利用变化来实现客户的竞争优势。经常提供工作软件，从几周到几个月，优先考虑更短的时间尺度。业务人员和开发人员必须在整个项目中每天一起工作。围绕有动力的个人建立项目。为他们提供所需的环境和支持，并相信他们能够完成工作。向开发团队内部和内部传达信息的最有效和最有效的方法是面对面交谈。工作软件是进步的主要衡量标准。敏捷过程促进可持续发展。赞助商，开发者和用户应该能够无限期地保持稳定的步伐。持续关注技术卓越和良好的设计可提高灵活性。简单性 - 最大化未完成工作量的艺术 - 至关重要。最好的架构，要求和设计来自自组织团队。团队定期反思如何变得更有效，然后相应地调整和调整其行为。摘要敏捷开发是软件开发行业的一个流行词，它是管理软件开发项目的另一种方式。它不是特定的软件开发方法，而是基于敏捷宣言中表达的价值观和原则的一套方法和实践的总称。解决方案通过自组织，跨职能团队之间的协作发展，利用适合其背景的实践。基本的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工件什么是Scrum工件？完成与接受标准的定义Scrum中Ready的定义是什么？如何写短距离目标？如何使用MoSCoW方法确定产品积压的优先级如何使用100点方法确定产品待办事项的优先级？ ...

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? ...

为实际的Sprint Planning做准备充分的Sprint计划实际上是由所有团队成员完成的。团队代表在团队之间提交工作是不合理的。Sprint Planning 的要点每个团队队员应该准备Sprint Planning。如果多个scrum团队正在处理相同的产品待办事项列表，那么它们必须一起聚集并参与sprint计划。使用优先级排序的待办事项列表，PO按顺序向团队呈现最高价值的故事。目的是让团队中的每个人都完全理解故事的意图以及故事的具体接受标准 (definition of done)。解释所有用户故事的done定义也是很有帮助的。每个Sprint 都以Sprint Planning 会议开始，包括两个会议——WHAT会议和HOW会议。在WHAT会议中，团队从Scrum Product backlog 待办事项列表中选择用户故事 (user stores) ，他们将在其上工作。并且，在HOW会议中，所选择的用户故事被进一步分解成具有设置优先级和故事点的小任务到 Sprint Backlog。规划的前半部分——决定实现什么回顾Sprint目标 (Reviewing Sprint Goal) - Scrum会议代表将展示项目的高级愿景。产品负责人确定Sprint的目标，并证明它将如何向产品交付价值。检查产品待办事项清单 (Reviewing the Product Backlog)- 在sprint计划会议之前，产品所有者将重新排列用户故事，并优先考虑这些故事。计划第二部分-如何完成工作在计划的后半部分，团队决定如何完成工作。创建待办事项列表 (Creating Product Backlog) - PO与团队一起回顾最高优先级的故事，并决定他们在每次冲刺中能做多少。每个人都应该在这个计划中投入工作。如果有人无法提交，PO和团队需要共同努力来改变sprint的形状，直到每个人都能够提交。Sprint计划是scrum中的关键协作工作。更新发布计划 (Updating the Release Plan) - 一旦团队致力于用户故事，产品所有者将重新访问用户故事到Sprints的版本计划映射。使用当前信息，团队在前一次Sprint中完成的故事，从当前Sprint的产品待办事项列表中删除的故事，产品所有者更新发布计划。Scrum非常认真地对待承诺步骤。每个人的承诺对于实现你的冲刺目标是非常重要的。从回顾sprint目标到更新发布计划，每个步骤都必须仔细遵循。Scrum工件什么是Scrum工件？完成与接受标准的定义Scrum中Ready的定义是什么？如何写短距离目标？如何使用MoSCoW方法确定产品积压的优先级如何使用100点方法确定产品待办事项的优先级？什么是Scrum中的Sprint目标？什么是Scrum中的Burndown图表？什么是角色功能原因模板？冲刺增量与潜在可运输产品对比MVP与MMP为用户故事撰写SMART目标和投资什么是产品Backlog中的DEEP？如何为Scrum项目撰写产品愿景？如何使用Scrum Board进行敏捷开发？谁在Scrum中创建产品Backlog项目或用户故事？

故事点 (Sotry Points) - 简介Scrum指南告诉我们，估算应该由将要完成工作的人提供，但它并没有告诉我们应该如何提供估算。它把这个决定留给了我们。Scrum团队使用的一种常见策略是使用称为故事点的度量单位进行估算。但为什么要使用Story Points而不是几小时或几天或任何其他众所周知的时间单位？我们是故意试图混淆吗？在本文中，我将介绍使用Story Points的优缺点，并得出一个令人惊讶的结论。什么是故事点？“故事点是一个相对的度量单位，由各个Scrum团队决定和使用，以提供完成要求的努力的相对估计 “为什么要使用Story Points？故事点旨在使团队评估更容易。与其他产品积压项目 (product backlog items) 相比，团队只考虑产品积压项目需要多少工作量 (effort)，而不是查看产品积压项目并在几小时内估算出来 。好的，所以它使评估更容易，但它有用吗？我们无法对成本和可交付时间进行任何预测，至少直到我们从可能需要几个月的几个冲刺(sprints)中获得了速度(velocity)的平均值使用时间作为度量单位有什么问题？几百年来，我们有了标准的时间单位。为什么我们不能使用几小时或几天？好吧，简而言之，因为你的小时与我的小时不一样。如果您要求两位开发人员估算相同的任务，您将得到两个不同的答案。虽然一些差异可能是由规范或理解上的差距来解释的，但事实是开发人员拥有不同的知识和经验，因此需要花费更多或更少的时间来完成相同的工作。要求这两个开发人员评估完成一个产品积压项目(Product backlog item) 相对于另一个产品积压项目所需的工作量，并且您更有可能最终达成共识。使用Story Points的真正原因因此，到目前为止，您可能不相信使用Story Points的必要性。好吧，他们展示了完成不同产品积压项目工作的相对工作量，但这对任何事情有何帮助？在我们了解团队的速度之前，我们仍然无法预测产品积压项目何时可能完成。更糟糕的是，如果团队成员发生变化，速度会发生变化，我们将不知道新的速度是什么，直到一段时间。所有这些问题导致许多人试图在故事点和时间之间建立关联，但正如 Mike Cohn 在他关于将故事点与小时相关的文章中 指出的那样，这并不是微不足道的。但是，尝试将故事点数与小时相匹配是不容忽视的。重要的是团队可以在冲刺 (sprint)中完成多少个故事点 (story points)，称为速度 (velocity)。当你知道这一点时，你可以做出一些预测而且你知道什么，它们可能是好的。很好。使用Story Points的真正原因是它们是准确的。谁这么说？Jeff Sutherland，Scrum指南的合着者。在他关于为什么故事点比几小时更好的文章中 他这样说：使用故事点因此比小时更快，更好，更便宜，而表现最好的团队完全放弃任何每小时估计，因为他们认为它是浪费，只会减慢他们的速度。冲刺增量与潜在可运输产品对比MVP与MMP为用户故事撰写SMART目标和投资什么是产品Backlog中的DEEP？如何为Scrum项目撰写产品愿景？如何使用Scrum Board进行敏捷开发？谁在Scrum中创建产品Backlog项目或用户故事？

Scrum要求产品在每个Sprint中保持可能可交付（例如，经过适当测试/集成）的状态，产品所有者(Product Owner)声明哪个工作是最优先考虑的，并且工作可以分成薄的垂直切片，通常是以客户为中心的用户故事(User Stories) 每个都要大于几天。如果我们正在做其他敏捷 (Agile)的东西，我们不能错过发布日期 (Time Schedule)，因为产品每周或每两周都可以发货。估计错误的唯一缺点是我们会按时发货，同时省略不太重要的功能 - 比瀑布 (waterfall) 或伪敏捷团队 ( pseudo-Agile) 今天所遇到的压力更小的工作方式。在瀑布式方法中 (waterfall approach)，管理人员根据时间确定团队成员的工作负载能力。经理要求选定的开发人员估计他们预期某些任务需要多长时间，然后根据该团队成员的总可用时间分配工作。在瀑布中，测试是在按照特定的职位名称之后完成的，而不是与代码一起编写的。瀑布的缺点是众所周知的：工作总是迟到，总是有质量问题，有些人总是在等别人，而且总是在最后一刻才赶上最后期限。Scrum团队采用完全不同的方法。首先，整个Scrum团队而不是个人负责这项工作。整个团队负责每个产品Backlog项目。整个团队负责测试产品。没有“我的工作”与“你的工作”。所以我们专注于每个产品积压项目的集体努力，而不是每个任务的个人努力。其次，Scrum团队更喜欢将项目相互比较，或者以相对单位而不是绝对时间单位来估算它们。（最终，这会产生更好的预测。）第三，Scrum团队将客户可见的需求分解为尽可能小的故事，从而大大降低风险。如果有7个人的工作量太大，我们会组建功能团队 (feature team) 消除依赖 (dependency)。估算过程是什么样的？Scrum并未规定团队估算其工作的单一方式。根据Sprint计划会议的决定，Scrum定义的唯一估计是团队是否会在此Sprint中尝试PBI 。常见的估算方法包括T恤尺码（S，M，L和 XL），2（1,2,4,8）的力量，斐波那契序列 (Fibonacci sequence):1,2,3,5,8等，或者只是小而不是需要拆分（参见下面的#NoEstimates）。在Product Backlog改进会议(refinement Meeting) 中，团队与产品负责人坐下来讨论产品Backlog顶部的故事。产品负责人通常需要工作量估算来帮助评估ROI，有效地确定产品Backlog中项目的优先级，并预测在给定的发布日期之前哪些项目将准备就绪。因此，产品负责人希望对工作难度进行诚实的评估。尽管团队中的个性不同，为了收集观点的横截面，所有团队成员通常同时披露他们的估计值是有用的。个人一次出示他们的牌，激发“计划扑克 (Planning Poker)”这个词。个人通常会选择不同的牌。这应该引发对实施方法的讨论，向产品负责人 (Product Owner)澄清要求，并将需求分成较小的故事（其中一些将是较低的优先级）。通常需要几轮来达到单一的工作量估计，这反映了整个团队对故事难度的感觉。改进和澄清比估计本身更重要。根据敏捷宣言，业务人员和开发人员必须在整个项目中每天一起工作。冲刺增量与潜在可运输产品对比MVP与MMP为用户故事撰写SMART目标和投资什么是产品Backlog中的DEEP？如何为Scrum项目撰写产品愿景？如何使用Scrum Board进行敏捷开发？谁在Scrum中创建产品Backlog项目或用户故事？

“快速提供质量”是当前竞争激烈的数字商业世界的成功口号。传统的软件开发方法将开发和测试分为两个不同的步骤 - 开发人员构建一个功能，然后QA团队对其进行缺陷测试。随着产品的增长，测试时间和工作量也呈指数级增长。这给项目经理带来了一个不受欢迎的选择 - 要么延迟发布，要么停止测试。“敏捷”的出现是因为需要一种更好的软件开发方法，使开发人员和测试人员能够减少代码中的错误数量，并分别在代码的早期检测错误。敏捷方法可帮助组织管理不可预测性，同时推动团队之间的协作和透明度，并采用不同的思维模式来取得成功。在敏捷环境中，开发周期将任务分解为小增量。它使团队能够以更高的协作性和更好的质量交付工作软件。敏捷软件开发方法为业务带来了显着的好处 - 加快了产品上市时间，提高了竞争优势，提供了高质量的软件，丰富了客户的满意度。第10届年度敏捷状态调查表明，敏捷软件开发在过去十年中越来越受欢迎。包括初创公司和大型企业在内的组织数量每年都在不断增加。这篇博文简要概述了第10届Agile™状态调查中提出的关于采用敏捷软件交付的十大理由：加速产品交付 - 敏捷开发方法使企业能够在更快的发布周期内提供高质量的软件，更符合用户需求。涉及较短冲刺的敏捷开发方法正在获得动力，以保持与业务目标一致的开发过程的速度。增强管理不断变化的 优先级的能力 - 敏捷的软件开发方法不仅需要团队更快地开发和测试，还需要更快地为客户提供产品和服务的增强功能。确保客户以可靠和可用的方式进行更改/增强需要在项目的每个步骤中采用敏捷方法。提高生产力 - 组织需要不断寻找以获得更好的业务成果。他们需要更好的方法来改进IT人员用于交付软件的技能和方法。敏捷方法可以通过更有效的通信提高生产力，同时高度响应不断变化的客户需求。提高软件质量 - 在敏捷环境中，开发和QA团队相互合作非常好，还旨在与客户密切合作，快速开发软件。敏捷技术可评估和提高软件质量，同时提供更高的客户价值。提高交付可预测性 - 客户通常关心可预测性。他们要求团队善于制定并保持承诺，在每个sprint结束时可靠地提供工作，测试和补救的代码。没有可靠和可预测的团队，稳定的可预测程序，特别是当团队之间存在多个依赖关系时，是不可能的。通过灵活的软件交付方法，强调设置指标和度量，团队可以计划，协调和交付足够的可预测性以及发布级别的承诺。改善业务 / IT一致性 - 组织需要改进业务和IT一致性，以实现高业务价值。组织需要高效和有效才能具有竞争力。快速变化的商业环境需要创新和灵活性。组织必须专注于IT，以正确的方式实施正确的系统以满足业务需求。组织必须通过关注在考虑基础架构和技术的同时改进的流程来实现业务/ IT协调。敏捷方法可以使所有IT运营流程 - 变更问题 - 事故 - IT运营 - 保持一致。此外，它还专注于减少设计，记录，部署和测试的时间和精力，以及成本和投资。提高项目可视性 - 可见性是快速适应所需变更的关键。在缺乏项目可见性的情况下，很难跟踪和衡量生产率的提高。参与软件开发和交付的团队需要知道他们前进的方向，就像组织领导者需要知道的那样。各种开发，测试和运营团队必须了解项目和组织的当前状态，性能和目标。通过敏捷方法提高[团队和领导能力，可以及早提供客户价值。降低项目风险 - 敏捷作为一种有效的软件开发方法，可以降低软件开发的风险。短跑中的软件开发包括敏捷技术，例如冲刺回顾，冲刺回顾等。这些技术提供持续的反馈，有助于防止期望与完成的软件之间的偏差。通过敏捷，Scrum团队首先优先考虑最高价值和最高风险的要求。他们使用现有的敏捷工件和会议来管理风险。提高团队士气 - 敏捷的软件开发方法强调各团队之间更好的沟通和协作。敏捷方法的本质是让团队对未来的挑战感到兴奋。Scrum会议，优先级，回顾和反馈机制使团队环境保持活跃和发生。自我组织，无缝沟通，尊重每个成员，高度协作，所有利益相关者的项目可见性等，这些都是敏捷方法的内在特征，带来积极的变化并保持团队的积极性。特别是，通过各种论坛和讨论板进行沟通是敏捷方法的核心。敏捷方法 要求组织倾听员工的意见，传达其计划以处理员工的各种问题，并认可员工的努力和成就。改进工程学科 - 正确采用和实施的敏捷原则和实践，使团队成员能够管理和提高软件质量，而不仅仅是完成工作。高质量产品的重要组成部分始终是良好且可扩展的设计和架构。当一个组织采用敏捷原则以提供高质量产品为目标时，他们也应该接受合理的工程学科。良好的设计，完善的配置管理和有效的[测试策略对于充分利用敏捷性至关重要。您现在想采用敏捷Scrum吗？您还想了解更多关于Scrum的知识，以及如何建立自己的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中的猪和鸡？敏捷和Scrum原则敏捷宣言和十二项原则Scrum中最经常提到的10个基本规则Scrum工件什么是Scrum工件？完成与接受标准的定义Scrum中Ready的定义是什么？如何写短距离目标？如何使用MoSCoW方法确定产品积压的优先级如何使用100点方法确定产品待办事项的优先级？什么是Scrum中的Sprint目标？什么是Scrum中的Burndown图表？什么是角色功能原因模板？冲刺增量与潜在可运输产品对比MVP与MMP为用户故事撰写SMART目标和投资什么是产品Backlog中的DEEP？如何为Scrum项目撰写产品愿景？如何使用Scrum Board进行敏捷开发？谁在Scrum中创建产品Backlog项目或用户故事？Scrum活动什么是Scrum活动？什么是Scrum Ceremonies？什么是产品Backlog修饰？每日Scrum中的3个重要问题是什么？Scrum的心跳 - 每日站立每日Scrum会议 - 快速指南为什么在Scrum中固定长度冲刺？什么是Scrum发布计划？什么是Sprint计划？什么是Sprint评论？什么是Scrum的Sprint回顾会议？什么是产品Backlog改进？什么是Scrum中的持续集成/交付/部署？什么是Scrum中的时间盒事件？什么是Scrum中的Spike？什么是敏捷计划扑克？Scrum Sprint循环8个步骤

The Chicken and the Pig 的商业寓言解释了Scrum流程中的早餐猪和鸡。这是区分Scrum / Agile世界中角色的一种方法。角色是敏捷的关键。它们是不变的，是每个决策的基础，并定义了Scrum中最基本的人际关系。猪和鸡寓言鸡和猪的寓言用于说明参与项目的项目利益相关者的不同级别。基本的寓言运行：猪和鸡正走在路上。鸡说：“嘿猪，我以为我们应该开一家餐馆！”猪回答说：“嗯，也许，我们会怎么称呼它？”鸡回应：“火腿鸡蛋怎么样？”猪想了一会儿说：“不，谢谢。我会坚持，但你只会参与其中。“有时候，故事是一个谜语;问题：在培根和鸡蛋早餐中，鸡肉和猪之间有什么区别？答：鸡是参与的，但猪是承诺！Scrum语境中的猪与鸡The Chicken and the Pig的商业寓言是关于项目或事业的承诺。当生产由火腿和鸡蛋制成的盘子时，猪提供需要他牺牲的火腿，并且鸡提供不难生产的鸡蛋。因此，只有鸡只参与，所以猪确实在那道菜中生长，但两者都需要生产这道菜。在Scrum的背景下，鸡会对将要开发的产品有所贡献，但是猪决定了它将如何完成以及它可以完成的速度。因此，猪包括开发团队成员，代表鸡的产品所有者和Scrum Master，负责组织一些Scrum事件 (Scrum Events)，特别是在Scrum站立 (Daily Standup)期间，而客户，供应商，管理人员和其他有远见的重要人物事实上，是Scrum中的鸡。Scrum学习资源什么是产品负责人在Scrum中的角色？为什么选择Scrum？Scrum如何克服我们总是面临的8个痛点？Scrum在3分钟内完成Scrum Sprint循环8个步骤最好的免费和商业敏捷工具 - 每个Scrum团队都需要！什么是Scrum中的猪和鸡？谁在Scrum中创建产品Backlog项目或用户故事？

当我以敏捷教练的身份进入组织时，Scrum的一个常见问题就是Sprint Planning。“这些会议需要很长时间！" 我的客户抱怨。一个使Sprint Planning会议既短又高效的简单方法是通过定期使用Backlog Grooming Meeting。有时称为Story Time Section，这些会议的目的是对Product Backlog 进行改进 (Product Backlog Grooming Sessions)。这个定义故意含糊不清，因为会议非常通用。Backlog Grooming会话可用于：编写用户故事（可以在一系列一个或多个Backlog Grooming Section“从头”构建Product Backlog）列表项目分解太大的用户故事（史诗 epics）改进写得不好的用户故事估计积压项目添加接受标准深入研究待办事项以便进行长期技术规划最后点句很重要。有些人错误地认为，做Scrum意味着除了下一个冲刺阶段 (Sprint) 将要发生的事情之外永远不要关注任何事情。这不是真的。相反，积压梳理会议 (backlog Gromming Meetings) 是: 例如， Product Owner说 “3月份的发行版非常棒，所以今天我想花时间看看，我希望获得在7月份的发行版中的用户故事。” 这样做给团队一个机会来进一步研究产品的未来，并且能够提醒他们技术挑战和“必须解决的问题”。如何举行有效的Product Backlog Grooming？以下是一些指导方针：记住一个目标: 在每次会议中，产品负责人都应该说：“这是我今天想要完成的。”这可以是团队达成的协议目标，但关键是要在会议开始前设定目标。漫步到一个待办事项列表梳理会话中，说：“嗯，嗯……我们今天想谈什么？”“是浪费时间的保证。”安排会议来支持和改进下一届Sprint Planning会议: 一个好的Product Backlog Grooming Meeting让所有参与其中的人都感到熟悉Product Backlog，让他们清楚地了解下一轮Sprint的目标，并且意味着他们可以在Sprint Planning会议中实现目标。因此，安排Product Backlog Grooming Section，在下一个Sprint Planning之前至少几天。限制“鸡”的参与: 在Scrum中称为“鸡”，利益相关者 (stakeholders) 可以是积压梳理会话 (Backlog Grooming Meeting) 的有效参与者。但是限制他们的数量。例如，如果您有10个利益相关者，您想要从他们那里收集反馈，那么通过一系列2-3个会议，而不是一个大型会议，从他们那里获得反馈。记住，涉众通常并不像团队、产品负责人和Scrum Master那样理解Scrum的规则。他们通常不具备“良好的Scrum礼仪 (Scrum Manner)”，你可能会发现一大群人会很快接管你的会议，使得会议变得混乱和有效。定期使用Backlog Grooming Sections 是确保Sprint Planning会议更顺利运行的最佳方法之一。它们改进了产品待办事项列表的质量，使每个参与其中的人都更加熟悉所要求的内容，并且使自信地达成Sprint承诺变得更加容易。基本Scrum阅读列表什么是Scrum工件？什么是5个Scrum值？敏捷宣言和十二项原则Scrum中最经常提到的10个基本规则什么是Scrum的三大支柱？什么是产品Backlog修饰？每日Scrum会议 - 快速指南完成与接受标准的定义Scrum中Ready的定义是什么？为什么在Scrum中固定长度冲刺？如何写短距离目标？

Scrum是一个轻量级框架，具有最少的规则。这些规则有助于人们在创建软件产品的每一天都能凭经验充分利用。产品积压，sprint积压和潜在的可交付产品增量是Scrum工件的示例。产品积压 (Product Backlog)Sprint积压 (Sprint Backlog)增量（可能可发货）(Potentially Shippable)产品积压 (Product Backlog)产品Backlog只是项目中需要完成的所有事情的列表。它取代了传统的需求规范工件。这些项目可以具有技术性质，也可以是以用户为中心的，通常采用用户故事的形式。Sprint积压 (Sprint Backlog)sprint backlog是当前sprint中为开发选择的精炼产品积压项目列表，以及团队完成工作的计划。它反映了团队对可以完成的工作的预测。一旦sprint backlog建立，开发团队就开始研究新的产品增量。产品增量 (Product Increment)每个sprint都会产生一个产品增量，这是最重要的Scrum工件。产品增量是每个冲刺的“目标线”，并且在冲刺结束时，它必须：质量足够高，可以给用户满足Scrum团队目前对已完成的定义产品所有者可以接受产品Backlog修饰 (Product Backlog Grooming)Scrum产品积压只是项目要做的事情列表。产品负责人创建，维护并定期重新订购要为产品实施的功能列表，以适应新出现的需求，客户反馈和市场变化。Sprint规划产品Backlog的基础 (Groundwork of Product Backlog for Sprint Planning)产品Backlog顶部的产品Backlog项目应该进行细化，并可能很快包含在下一个sprint计划中。积压下来的项目需要更少的具体，并且可以反映更大的矿石更复杂的想法。这些较大的块需要在接近Product Backlog的顶部时分解成更小的块，如下图所示，如Gunther Verheyen的文章 - 产品Backlog的价值所示：在上面的产品待办事项中，产品待办事项（PBI）很容易被分类为三个不同类别的sprint计划：Sprint计划：Sprintable整理：可操作/用户故事 (Groomed)未来：史诗/宇宙故事 (Epic / Cosmic Stories)通过维护分类良好的产品积压（如上述结构），您的团队应该更容易进行sprint计划流程。更多Scrum阅读What is Definition of Ready in Scrum?Why Fixed Length Sprints in Scrum?How to Write a Sprint Goal?What is Sprint Planning?What is Sprint Review?What is Sprint Retrospective Meeting in Scrum?What is Product Backlog Refinement?

什么是Scrum团队？Scrum团队是一组个人（通常在五到九名成员之间）一起工作，以提供所需的产品增量。Scrum框架鼓励团队成员之间进行高水平的沟通，以便团队可以：遵循共同的目标遵守相同的规范和规则相互尊重Scrum团队的结构Scrum团队。Scrum团队包括：产品拥有者Scrum Master，和开发团队Scrum团队分享与产品交付相关的不同任务和职责。每个角色都密切相关。建议Scrum团队成员尽可能在同一位置一起工作。让我们从责任，权限和特征的角度来看看这些角色。项目负责人产品负责人是团队成员，他知道客户想要什么以及他们想要的相对业务价值。然后，他或她可以将客户的需求和价值转换回Scrum团队。产品负责人必须了解产品的业务案例以及客户需要的功能。他必须与团队协商，以确保他们正确实施产品愿景。最重要的是，他必须有权做出完成项目所需的所有决定，换句话说，产品负责人负责管理产品Backlog，其中包括：清楚地表达产品Backlog项目。订购产品Backlog项目以最好地实现目标和任务。优化团队执行的工作价值。确保产品待办事项清晰可见，透明且清晰，并显示团队将进一步开展的工作。确保团队将产品Backlog中的项目理解为所需的级别。Scrum MasterScrum master帮助团队保持对业务承诺的责任，并消除可能妨碍团队工作效率的任何障碍。他们定期与团队会面，审查工作和可交付成果，最常见的是每周一次的节奏。Scrum master的作用是指导和激励团队成员，而不是对他们执行规则。Scrum master的作用包括：确保流程顺利进行消除影响生产力的障碍组织关键活动和会议开发团队开发团队由组织组织和授权，以组织和管理自己的工作。由此产生的协同作用优化了开发团队的整体效率和有效性。开发团队具有以下特征：他们是自我组织的。没有人（甚至不是Scrum Master）告诉开发团队如何将Product Backlog转换为潜在可释放功能的增量;开发团队是跨职能的，具有创建产品增量所需的所有技能;Scrum不承认开发团队成员的任何头衔，无论该人员正在执行哪些工作;无论需要解决哪些领域，如测试，架构，运营或业务分析，Scrum都不会认可开发团队中的子团队; 和，个人发展团队成员可能具有专业技能和重点领域，但问责制属于整个开发团队。