Scrum五个事件之五：回顾会议（Retrospective Meeting）

名词n. 扭打，混乱；并列争球不及物动词vi. 参加并列争球及物动词vt. 抛（球）开始并列争球

Scrum是一种敏捷软件开发框架，旨在提高团队的生产力和质量。它强调团队的自我组织和自我管理，通过短周期的迭代和增量式的开发来快速响应客户需求。Scrum框架包括三个角色：产品负责人、Scrum Master和开发团队。其中，产品负责人负责定义产品需求和优先级，Scrum Master负责教练团队和确保Scrum框架的正确实施，开发团队则负责实现产品需求。Scrum框架中的核心是Sprint，它是一个短周期的迭代，通常为1到4周。在Sprint期间，开发团队通过Daily Scrum会议进行日常沟通和协调，确保团队成员了解彼此的工作进展和遇到的问题。Sprint期间，开发团队将产品需求转化为可交付的增量，该增量应该是可用、可测试和可部署的。

Scrum 是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。 Scrum流程如下图： Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。 Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下： 透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。 开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。 如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。 Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。 文章内容来源于： Scrum中文网

Scrum是一个开发框架，是敏捷开发的一种最佳实践。SCRUM价值观：1. 个体和互动高于流程和工具；2. 工作的软件高于详尽的文档；3. 客户合作高于合同谈判；4. 响应变化高于遵循计划。SCRUM中定义了三个主要角色：产品负责人，敏捷教练，开发团队。SCRUM还定义了四个会议：冲刺计划会，每日站会，冲刺评审会，回顾会。SCRUM的三个角色，适当运用四个会议，以短周期冲刺的形式，渐进式的、递增的，将用户需求实现成特定产品，并快速得到客户的反馈并改进产品，以满足客户的需求。

自上世纪 90 年代初期以来,Scrum 就已经应用于管理复杂产品的开发。Scrum 不是开发产品的一种流程或一项技术,而是一个框架,在这个框架里可以应用各种流程和技术。 Scrum能使产品管理和开发实践的相对功效(relative efficacy)显现出来,以便进行改进。 上面是摘自《Scrum指南》中文版的介绍，即Scrum的官方定义。这里面几个点需要格外强调： Scrum是一个框架，而不是一个流程，也不是一个方法，更不是一项技术。这里面有什么不同呢？框架指的是这些内容组成一个整体，不可裁剪或修改。一旦裁剪或修改，框架就不稳固，容易出问题。 我们可以看看采用Scrum的组织中，出问题的大多数情况是在我们这里需要裁剪一下Scrum而造成的。比如每日站会太浪费时间，能否一周开两次。团队看起来没什么需要改进的，回顾会是否可以取消？等等 如果把Scrum裁剪了，请不要说在采用Scrum。 Scrum最适合解决复杂问题，比如软件开发这类复杂问题。另外还有适应性问题，即强调灵活性，需要团队可以快速响应变化。这是敏捷的本质，可以参考之前的博文“ 为什么敏捷是Agile，而不是Cgile或其他词 ”。 更多的解读，大家可以参加 CSM敏捷认证培训 了解详情。 参考材料： Scrum指南

Scrum是一个英国橄榄球的运动中的一个术语“挣球”，想象“挣球”的场景，所有人紧盯同一个目标，每个人都富有激情，共同为了拿下这个目标奋斗。 说白了，就是一个小步快跑，将一个大目标拆解为一个个可以快速交付的小目标，这个大目标可能前期还有很多不确定的假设，在一个个小目标的实现过程中，在实际市场反应的情况下，来验证假设的正确性，从而优化调整这个大目标。 在看下图之前，我先解释下，Scrum的几个重要元素的概念，概括起来讲就是3355， 3个角色 3个工件 5个活动 5个价值观 u200b 以上就是对Scrum过程的一个简单描述。 Scrum是以经验主义和精益思维相为基础的理论。经验主义表示Scrum理论认为所有的知识都是来源于实际经验和对已有事物的观察而获得判断。他的三大理论基础分别是透明、检视和适应。 从我们实际敏捷转型的过程中来看，采用敏捷之后，业务方更加满意，团队更加具有热情（长期没有成果，会让团队士气低落）。

Scrum中的角色主要分为产品负责人（Product Owner）,Scrum主管（Scrum Master）和开发团队。 产品负责人是项目中代表客户意愿的人，主要负责编写用户需求（User Story）,为User Story排列优先级并放入产品订单（Product Backlog）。这一角色与传统软件项目中的产品经理角色职责类似，在Scrum的实践中也可以有客户担任。产品负责人是确保项目不偏离客户需求的人，也是使项目价值最大化的人。Scrum主管（Scrum Master）的主要职责是帮助开发团队消除哪些影响团队交付目标的障碍，也是团队与外界交互的接口，屏蔽外界对开发团队的干扰。Scrum主管确保所有项目参与者都遵守Scrum规则，保证团队开发计划的正确执行。Scrum主管在实际实践过程中通常由精通Scrum流程且开发、管理经验丰富的人担任，不同于传统软件开发项目的项目经理，Scrum主管不发号司令、不分配共走，而是尽力在自己的责任范围内帮助开发团队解决问题。 开发团队是由软件开发人员、软件测试人员、设计人员、数据库管理员等不同职能的人组成的团队，开发团队通过实行自管理、自组织和跨职能的开发协作，实现每个迭代的开发计划和产品交付。不同于传统的软件项目，Scrum团队的开发人员和测试人员不仅同属一个团队，而且实践上也要求开发人员和测试人员做在一起。 因为Scrum要去每个完成的User Story都是可测试、可交付的，所以所有的测试工作（包括单元测试、功能性测试、 集成测试及用户验收测试）都是在同一个迭代内完成。而且测试人员和开发人员都要参与到自动化测试脚本的开发工作中。以此来保证软件系统的持续集成和持续交付。

一、敏捷管理理论1、敏捷管理的定义敏捷即灵活性，是动态的、适应于具体情况、迎合变化和自我完善的。敏捷项目管理是应对经常变化的、具有不确定性的软件项目的管理方法。敏捷是一种态度而不是一个流程，是一种氛围而不是方法。敏捷项目管理中最重要的一个术语就是创新。实施敏捷项目管理过程中项目管理者要注意：调整团队自身来适应变化，致力于产品，和客户进行协调，注重沟通。2、敏捷管理的开发方法常见的敏捷软件方法包括：Crystal、ASD（AdaptiveSoftwareDevelopment）、Scrum、FDD（FeatureDrivenDevelopment）、XP（ExtremeProgramming）、RUP（RationalunifiedProcess）等，它们都具有强调灵活、阶段迭代、反馈和逐步逼近目标的特性，本文中将重点介绍Scrum方法。二、Scrum开发方法Scrum（英式橄榄球争球队），软件开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。正如Schwaber所言，Scrumisanagile，lightweightprocessthatcanbeusedtomanageandcontrolsoftwareandproductdevelopmentusingiterative，incrementalpractices。Scrum将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝目标有明确的推进。1、Scrum方法的原理（1）Scrumteam。指整个项目小组，不仅仅包括全职开发人员，也包括了发行软件会影响到的外部人员，比如市场营销人员和顾客。（2）Backlog。Backlog是一种任务列表，包括ProductBacklog和SprintBacklog两种，是指导Scrum开发方向的指针。SprintBacklog是一个Scrum团队计划将要在当前Sprint中完成的所有功能列表。SprintBacklog实际上是ProductBacklog的一个子集，在ProductBacklog的纲要性指导下，SprintBacklog不断发展并且充实整个项目的ProductBacklog，使之趋于完善。比如：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。（3）Sprint（冲刺）。Scrum开发过程由一系列迭代的Sprint过程组成，一个Sprint过程就是一个冲刺过程，多个Sprint过程顺序进行，直至风险评估认为产品可交付为止。一个sprint是在限定时间段内的一系列开发活动，包括分析、设计、编码、测试等。通常为30天的迭代时间，把Backlog中的每一项安排在Sprint中，由团队估算出所需要的时间（按小时记）。每一次Sprint之后，一定要有可以交付使用的功能。每一次Sprint之后要回顾，团队按照既定的SprintBacklog目标来演示完成的内容。（4）Scrummeeting。Scrummeeting是Scrum中项目管理的有效手段，分为两种：Sprintmeeting和Dailymeeting。Sprintmeeting是在下一个Sprint开始之前，即在当前sprint即将结束之时举行的，Sprintmeeting讨论并决定下一个sprint的sprintBacklog，会议举行的时间周期随Sprint的周期而定。

Scrum是一种敏捷开发框架，它将软件开发过程分为多个迭代周期，每个周期称为一个Sprint。Scrum框架包括8个骤，分别是：1. 产品待办列表：定义产品需求和功能，将其记录在产品待办列表中。2. Sprint计划会议：在Sprint计划会议中，团队会根据产品待办列表选择需要完成的任务，并制定Sprint目标和计划。3. 每日站会：每日站会是团队成员每天进行的短暂会议，用于分享进展、讨论问题和协调工作。4. Sprint开发：在Sprint开发过程中，团队会根据Sprint计划完成任务，并在每日站会上进行进度汇和问题讨论。5. Sprint评审会议：在Sprint评审会议中，团队会展示已完成的工作成果，并接受益相关者的反馈和建议。6. Sprint回顾会议：在Sprint回顾会议中，团队会回顾Sprint开发过程，总结经验教训，并制定下一个Sprint的改进计划。7. 产品增量：在每个Sprint结束后，团队会交付一个可用的产品增量，该增量包含已完成的任务和功能。8. 迭代循环：Scrum框架是一个迭代循环的过程，团队会不断重复上述步骤，逐步完善软件功能，同时也不断改进和优化开发过程。

Scrum的3种工件包括：Product Blacklog、Sprint Backlog、完成标准。产品Blacklog是Scrum中的核心工件，它是对整个产品的功能描述，所有功能描述都是有顺序的排列，团队依照优先排列顺序进行工作。 它是产品需求的唯一来源，开发团队所有工作都来自产品Backlog。 产品Blacklog由产品负责人创建和维护。 产品Blacklog贯穿于整个项目的生命周期。 产品Blacklog是一个有顺序的列表。 好的产品Blacklog做到DEEP： 粗细适宜的（Detailed appropriately）：待办事项列表顶端的百分之十可能包含非常小且分析得很详细的事项，而其他的百分之九十则不是那么具体。 估算过的（Estimated）：团队提供给产品负责人产品待办事项列表中每个事项的工作量估算和技术风险估算。 涌现式的（Emergent）：为了响应学习和变化，要定期梳理产品待办事项列表。产品负责人会 不断地更新产品待办事项列表 ，以反映客户需求的变化、新想法或见解、竞争而导致的变化、出现的技术障碍等。 排好优先级的（Prioritized）：在产品待办事项列表顶端的事项具有最高优先级，或者是从1开始顺序排列。 Sprint Backlog是当前Sprint完成的且梳理过的产品待办事项，包括了一个开发团队完成这些工作的计划。有了Sprint待办事项列表后，Sprint就开始了，开发团队成员按照Sprint待办事项列表来开发新的产品增量。 在Sprint计划会议上，自组织团队在会议中生成Sprint Backlog。团队接受从产品Backlog挑选出要在本轮迭代实现的需求， 将故事转化为具体的任务，每项任务落实到具体的责任人 。 Sprint Backlog中的每个项都是一个 用户故事 。 每个Sprint的输出成果为“潜在可交付产品增量”，基于“随时可向用户发布”的目标制定衡量团队工作是否已完成的标准，由团队和PO形成共识。 完成标准的好处： 共同协商的完成标准是团队的自我承诺，团队会更认真。 用于准确评估团队工作进展。 清晰和明确的完成标准保证了每次迭代是高质量的。 完成标准的关键要点： 团队自协商：团队根据项目实际情况来定义完成标准，并严格遵守。 有层次：一般分为三个层次：Story级别，迭代级和发布级，每个级别都有各自的完成标准。

第一阶段：首先产品经理(产品团队)把需要上线的产品特性做成 产品需求列表（Prodcut Backlog） ,由产品经理(产品团队)基于产品整体战略、目标、业务价值、实现难度等因素甄选出优先级最高的项目，交个整个团队进行讨论。 第二阶段：召开迭代规划会议，研发团队、产品经理和开发团队负责人（Scrum Master）讨论用户故事的优先项，且决定本次次迭代要研发的需求项。 并由开发团队负责人开展可行性评估和工时评估，确定迭代的需求排期，形成迭代需求列表（Sprint Backlog） 。 第三阶段：会议结束后，团队中的每个成员需要对每个用户故事有深刻的理解。 团队负责人根据需求拆分相应的子任务，分配相应的开发成员执行，并评估相应的工时 。 第四阶段：研发团队要在一到三周的时间里开发完成迭代需求列表中的需求， 在迭代中，每日站会用于团队来交流他们做完了什么，正在做什么，以及遇到的问题，及早发现风险 。 第五阶段：每次迭代的产出都是一个可以发布的产品版本，在迭代结束前，会进行迭代评审会（Sprint Review Meeeting）， 由研发团队向产品经理做案例演示并接受评价。产研团队根据整个迭代需求的完成情况和缺陷处理情况，最终决定整个产品是否上线，也可以在发布前增加新功能。 确认上线后，由运维进行上线环境部署，正式上线。 第六阶段：在迭代结束时，产品和开发会举行迭代回顾会（Sprint Retrospective Meeeting），团队一起思考工作中可以改进的地方，制定改进措施。 每次迭代都需要进行这样的会议，来不断改进产品的质量 。 最后， 产品团队在产品功能上线后，持续收集用户的反馈，分析数据形成新的用户故事，进入下一次迭代 。

叔叔服务u

Scrum的5个活动 产品Backlog梳理会议（ Product Backlog Refinement） Sprint计划会议（Sprint Planning Meeting） 每日站会（Daily Scrum Meeting） Sprint评审会议（Sprint Review Meeting） Sprint回顾会议（Sprint Retrospective Meeting）

第1章　背景：Scrum的科学原理经验性过程控制复杂软件开发Scrum的骨架与核心Scrum的角色分配Scrum的流程Scrum的人工因素产品BacklogSprint Backlog潜在可交付产品功能的增量总结第2章　新的管理责任MetaEco公司的ScrumMasterMetaEco公司案例背景ScrumMaster采取行动ScrumMaster的价值美格能源公司的产品负责人美格能源公司案例背景产品负责人采取行动产品负责人的价值Servicelst公司的团队Servicelst公司案例背景团队采取行动团队的价值结语第3章　ScrumMasterTrey Research公司未经培训的ScrumMaster问题所在经验教训Litware公司未经培训的~ScrumMaster问题所在经验教训Contoso.com的过度热心观点正确并不意味着一切经验教训MegaFund的恶狼恶狼袭击经验教训结语第4章 在混乱中建立秩序Servicelst公司的案例背景运用Scrum经验教训Tree商业出版社的案例背景运用Scrum经验教训Lapsec的案例背景运用Scrum经验教训结语第5章　产品负责人客户与团队的合作Servicelst管理层重拾活力Sprint评审会议经验教训解决MegaFund公司的XFlow问题解决问题经验教训TechCore的公司目标Scrum如何协助TedaCore经验教训MegaBank的公司目标：资金转账系统Scrum如何为FTS提供帮助经验教训结语第6章　规划Scrum项目MegaBank管理现金为期两天的Sprint计划会议经验教训认证ScrumMaster处理投资回报问题MLBTix团队对题目的回答经验教训结语第7章　项目报告——保持可视性MegaEnergy所有权项目的新项目报告解决问题经验教训在MegaBank获取更多信息解决问题经验教训在Setvicelst，并非所有事项都具可视性现实状况经验教训结语第8章　团队Servicelst团队构成了解谁是老板：转变学会更好地设计：转变学会自组织：转变预估工作量：转变学会在工作中享受乐趣：转变在WebNewSite给团队一次机会案例背景经验教训结语第9章　使用Scrum扩展项目在MegaFund扩展项目处理方法经验教训Scrum扩展在Medcinsoft扩展项目处理方法漏洞修复经验教训结语附录A　规则附录B　定义附录C　资源附录D 固定价格和日期的合同附录E 能力成熟度模型（CMM）术语表

敏捷开发是一种基于迭代和增量的软件开发方法，它是一种轻量级的、灵活的开发方法，强调团队合作、快速反应、用户需求和变化的响应能力。其目标是快速、高效地交付高质量的软件，同时能够在开发过程中及时响应用户需求和变化。为了实现这一目标，敏捷开发采用了一系列的实践和原则，包括Scrum、XP、迭代开发、持续集成、测试驱动开发等。其中，Scrum是敏捷开发中最为流行的方法之一。Scrum强调团队合作、迭代开发和持续改进，将软件开发过程划分为一系列的迭代周期，每个周期称为一个“Sprint”。在每个Sprint中，团队会选择一些用户需求并将其转化为“用户故事”，然后根据这些用户故事进行开发和测试，最终交付可用的软件。与传统的瀑布模型相比，敏捷开发具有以下优势：1. 更快的交付周期。敏捷开发采用迭代和增量的方式开发软件，可以在短时间内交付可用的软件。2. 更高的用户满意度。敏捷开发强调与用户的紧密合作，可以更好地理解用户需求并及时响应用户反馈，从而提高用户满意度。3. 更灵活的开发过程。敏捷开发强调团队合作和快速反应，可以更灵活地应对变化和调整开发计划。4. 更高的开发效率。敏捷开发强调自组织和自我管理，可以激发团队成员的创造力和积极性，从而提高开发效率。5. 更好的质量保证。敏捷开发强调持续集成和测试驱动开发，可以在开发过程中及时发现和修复问题，从而提高软件质量。总之，敏捷开发是一种高效、灵活、用户导向的软件开发方法，它能够帮助团队快速、高质量地交付可用的软件，并及时响应用户需求和变化。

推荐文章地址： https://www.cnblogs.com/byvar/p/7235650.html 这篇文章是我目前所看到的最通俗易通的文章的了~推荐给大家！ 我个人理解的敏捷开发，就是把一个大目标细分为短期内可以完成的可运行可交付的小目标； 1.由于拆分成小目标，这样在短时间内就可以看到成果！在看到成果的同时也可以及时修改，因为好多产品经理也不能明确自己要做什么；这样可以弥补经过长期做出来的产品还不是想要的产品的尴尬！及早发现，及早治疗~ 2.开发人员有新鲜感！工作效率高！为什么这么说呢？因为短时间就可以看到自己的劳动成果，使人有满足感，避免在长时间的工作中消耗自己的激情！还有一点就是 人性 ，一个人长时间做一个事情看不到成果难免会懈怠！如果一个功能开发一个月或者更久，久而久之，自己的开发效率啊！主动性啊都没有刚开始的时候那么积极！（老外太TM屌了，把人性都考虑在内了，不得不佩服！！！） 举个例子1： 如果你是开发人员，你会能感同深受，你在刚开始开发一个项目时你的激情和热度；你在一个项目中开发一年的激情和热度！！！ 举个例子2： 为什么一个人在一个公司呆久了会想要离职？为啥？除了工资待遇，公司复杂文化，我觉得还有一点就是呆的太久了没有变化了！就和热恋中的男女朋友一样，热恋时恨不得天天腻在一起，时间长了。。。。。。 3.还有一点我觉得也很重要，快！快！快！抢占市场！！！早死早超生！ 为什么这么说呢？我觉得这点特别适合当今的互联网公司，因为现在纯正的互联网公司要的就是快！！！快就代表着机遇和金钱啊~ 你想想如果同样一个好的idea要做成产品，有两个公司都在做，公司A使用敏捷开发模式，公司B使用传统的瀑布式，人家公司A一周就上线了，B还在搞需求，设计文档呢。。。。你想想，结果可知！可以先不那么全，先出来个原型然后慢慢完善功能！！！为什么现在阿里巴巴已经很牛逼了，但是就是找不到流量的入口，也就是粘性用户，为什么？？？如果阿里在腾讯开发出微信之前，他先开发出一款类似的App，你想想结果会怎样？O(∩_∩)O哈哈~结果怎样我也不知道。。。。。。 还有一点就是做个原型上线，看看市场用户的反馈，如果用户对你做的这个感兴趣，你可以继续丰富功能，继续挖掘；如果不case，那就果断放弃，继续下一个idea，也没多大的损失！！！因为好多的产品都是试出来的，没有哪儿个产品经理敢说我设计的产品一定是受用户喜爱的~ 以上是我理解的敏捷开发模式的好处，也就是小学语文的中心思想！O(∩_∩)O哈哈~至于其他的像什么Sprint Backlog啊，Daily Scrum Meeting啊（每日站立会议），Sprint burn down啊（Sprint燃尽图），Srpint Review Meeting（演示会议）啊都是打辅助的！以上都是理论性的知识，其实我认为最最最重要的就是团队之间的配合度！！！默契度！！！有效沟通！！！团队之间要真正的从心里互相尊重，理解，与欣赏！！！做到一个团结，紧张，活泼的团队！！！

通常在球有意外或侵权时，裁判会判scrum。但那也要看裁判，不是每个裁判都常常判scrum（因为很浪费时间，很多裁判选择让比赛流畅的进行）。scrum规则其实和橄榄球的逻辑是一样的，球不能从对方后面被抢走，只能从前面。所以当不再这个 scrum 里面的 scrum half 把球扔进去时，你必须尝试把对方往后推，或尝试用脚把球弄到后面去。但有时候像快到底线时，球员会选择推到底。scrum 时有三排人，前排中间的是hooker，前排两边是prop, 第二排中间是lock，第二排左右侧的是flanker和最后面的是8号。通常scrum的步骤是这样，裁判会先喊crouch也就是蹲的意思，前排会蹲下。然后会说touch也就是触碰，双方prop要触碰对方prop的肩膀。然后裁判会说engage，这时候就会撞在一起。这时没有犯规那组的scrum half会把球从侧面扔进去。然后两组就开始竞争这颗球。如果裁判喊 crouch, touch 和 engage 而你没有照做，或做的太慢，裁判往往会把球直接判给对方。但这也要看裁判，有些会给你机会再scrum一次。我以前打的是winger，不用负责scrum。

敏捷团队一般被描述为“跨职能的小团队”，跨职能是团队内部有不同角色担负不同职责，小团队指的是团队的规模不大（一般10人以内）。虽然是小团队，在启动和协作的过程，依然要形成一些基本的行为规范。试举几个栗子。 站会规则： 在敏捷团队的构建初期，一般站会是最容易被导入的敏捷实践了-源于其简单易行，大家呼朋引伴呼啦啦一下就可以聚集这个会议。而恰恰是这个简单，很多时候最容易做不好。比如有人迟到，有人看手机，或者听到自己不感兴趣的内容直接神游八极了。这样的结果就是最终站会效果不好-在站会这样的小事情上都没有“共同承诺”，更不用说任务和冲刺这样更费心费力的实践了。 那么，站会的规范应该怎么做呢？ 在站会之前，团队通过共同决策（具体形式比如站会开始前的“站会”），大家一起决定：每天固定时间9点30分在大屏幕前开始站会，迟到者做5个俯卧撑或者发一个20元的红包，开会期间全部手机禁用，有特殊情况需要接打电话请退出站会，在旁边接打电话；每个人针对自己任务做进展陈述，对于需要深入讨论的问题先记录下来，等待会后再同步等。 DoR（产品列表就绪的定义）规则： 对于进入产品待办事项列表，团队的公约可以归纳为6个原则INVEST和4大特征（DEEP)。我在另外一篇文章中有详细对DEEP的思考，可以参考。 Scrum敏捷产品列表管理的再思考 对于INVEST的说法解释的很多，后续我再另外用文章介绍。 6个原则INVEST Independent相对独立 Negotiable可协商 Valuable有价值 Estimatable经过估算 Small大小适宜 Testable可测试 四大特征（DEEP) Detailed appropriately 详略得当 Emergent 涌现的 Estimated估算过的 Prioritized排序过的 DoD（完成的定义）规则： 对于敏捷团队来说，判断一个事情是否完成与原有的协作模式有所不同。以往的项目团队，一般会划分很多个完成阶段：如产品设计完成，研发完成，测试完成等好几个阶段。为了方便追踪，划分阶段也是无可厚非，而这只是从内部团队的视角出发-很显然，我们如果还是从小团队的视角出发，容易造成局部优化，反而造成全部流程的阻滞（如研发单纯的完成很多的功能开发，没有做必要的自测，随意的把任务推到测试库里，给测试团队造成堆积）。 如果从用户的视角来看，Scrum的团队理论就可以说得通。在Scrum Guide中，有这么一段话： Scrum 不认可开发团队中所谓的“子团队”，无论是否有特别的专业领域，例如无论是测试还是业务分析的成员都不能划分为“子团队”。此规则无一例外； 同时,开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。 从客户的角度来看，我提出的需求和功能，在你的团队内部如何流转我并不care-只有两种状态，完成或者没完成。就算是你内部完成了编码和测试，只差最后一步的上线-没有上线就是未完成，没有例外。 在团队中建立完成的定义这样的“公约”，就是统一团队认知的过程：没有那么多的阶段，99%都不是完成，功能交付给到客户可用，才是真正完成。 敏捷团队执行过程中还有很多的团队公约。所谓团队公约，我认为就是跨职能团队在自组织的形势下自然生长出来的基础规范，其最重要的功能是平衡团队认知，规范团队行为。毕竟，自组织团队自己制定游戏规则，才是敏捷的精髓不是吗。

scrum是英语中橄榄球运动的一个专业术语，表示“争球”。现在特指一种敏捷开发的模型。scrum，它不是一种方法，也不是一项构建产品的技术，而是一个框架，在这个框架里可以应用各种过程和技术。scrum团队，由开发人员组成的scrum团队负责在每个迭代周期将一定量的开发任务完成。团队同时是跨职能的；团队成员必须具备完成开发任务所需要的技能，5到9个人被公认为是“最佳的”团队构成人数。

每日站会是Scrum生命周期中不可或缺的重要事件。从名字就可以看出，它是每天进行一次，可以说是Scrum中循环周期最小的事件。正因如此，它才可以产生最频繁的“计划-检查-调整”过程，帮助我们尽早的发现并解决可能出现的问题。 每日站会要求Scrum团队全体成员参加。主要内容是更新每个人的状态，让每个成员都了解其他人在做什么，进而对整个项目和当前进度有一个全局的把握和了解，这也是Scrum的项目透明化理念的具体展现。同时如果有必要，每个人还需要指出阻碍当前进度的问题，以获得团队其他成员帮助或者寻求外部资源，尽早解决。 具体而言，每个人都需要说明一下三点： 需要注意的是，这个会不能开的时间过长，否则每天会浪费大量的时间，得不偿失。而应该速战速决，每个人只是简明扼要的更新状态和进行必要的对话，千万要避免陷入细节并产生太多额外的讨论。 有一种实践可以达成站会的时间控制，就是选择一个东西作为Token，可以是比较醒目的任何东西，拿着顺手就行。开站会时，Token依次在每个成员间传递，原则上说只有拿着Token的人才能讲话，其他人只在必要的时候进行简单的问答式对话，其他更深入的讨论留待会后交流。这样一圈下来，时间就差不多可以控制在15分钟之内。

Scrum是软件开发中最流行的敏捷框架。Scrum是一种迭代的方法，他的核心是冲刺（Scrum的迭代术语）。为了支持这一过程，Scrum团队使用特定的角色、工件和事件。Scrum团队在整个项目中通过检验确保他们达成过程中每一部分的目标。 在每一个冲刺中，开发团队开发和测试产品的一个功能部件，直到产品负责人接受它并且使其成为一个潜在的可交付产品。当一个冲刺完成，另一个冲刺便开始。Scrum团队在每个冲刺结束时以增量形式交付产品特性。产品发布通常发生在一个冲刺结束或者多个冲刺结束之后。 冲刺的一个核心原则是他的周期性：冲刺及其过程是周而复始的，如下图所示。 在一个敏捷项目中，使用检查与调整原理会成为日常基础工作中的一部分。 1.在冲刺中，你对照冲刺目标以及发布目标不断进行检查以评估进展情况。 2.你在组织中召开每日例会，评审项目团队昨天已完成的工作和接下来一天要完成的工作。基本上，Scrum团队根据冲刺目标检查它的进程。 3.在冲刺结束时，你通过召开回顾会议来评估绩效和对必要的改进作出计划。 检查与调整听起来也许是繁冗复杂且有点正式，但其实不然。使用检查与调整解决问题，并不需要你想太多，你在今天试图去解决的问题在未来往往会发生改变。 Scrum框架为项目定义了特定的角色、工件和事件。 1.产品负责人。代表项目的业务需求方，并负责解释需求。 2.开发团队。执行日常工作。开发团队专注于项目并且是跨职能的，也就是说尽管团队成员你可能有自己的专长，但是每个成员在项目中都能承担多种项目工作。 3.Scrum主管。负责保护团队远离组织的干扰，移除障碍，并保证过程的一致性。 1.干系人。干系人是指任何一个受到项目影响或对项目有投入的人。尽管干系人不是正式的Scrum角色，但在整个项目中，Scrum团队与干系人一起紧密工作是必不可少的。 2.敏捷导师。导师是在敏捷技术和敏捷框架上经验丰富的权威。通常这个人来自项目所在部门或组织之外，所以他能以一个局外人的角度客观地支持团队。 1.产品待办列表。完成的需求列表，通常用来记录定义产品的用户故事。产品待办列表会贯穿于整个项目。所有代办事项，无论详细程度如何，都在此列表中。 2.冲刺待办列表。一个给定的冲刺中的要求和任务列表。产品负责人和开发团队在冲刺计划阶段为冲刺选择需求，同时开发团队把这些需求分解到任务中。不同于产品待办列表的是，只有开发团队可以变更冲刺待办列表。 3.产品增量。可用的产品。无论产品是一个网站还是一所新房子，必须足够完整，以便展示其可用的功能。在项目中，当一个产品包含了足够可交付的功能，从而满足客户对这个项目业务目标后，你可以宣布这个Scrum项目完成。 1.冲刺计划会议。在每个冲刺开始之前召开。在这类会议上，Scrum团队决定哪些目标、范围和任务纳入确定的冲刺待办列表中。 2.每日例会。每天召开，时长不超过15分钟。 Scrum每日例会中，Scrum团队成员做3项目汇报： 团队成员昨天完成了什么； 团队成员今天将要做什么； 团队成员当前的障碍是什么。 3.冲刺评审会议。在每个冲刺结束时召开。在这个会议中，开发团队向干系人和组织整体展示他们在冲刺中完成的已被验收的产品模块。 4.冲刺回顾。在每个冲刺结束时召开。这是一个内部会议，Scrum团队的成员（产品负责人、Scrum主管、开发团队）讨论冲刺中的成功作法、失败现象以及他们将如何在下一个冲刺中进行改进。这个会议是以行动为导向，换句话说，项目中的酸甜苦辣、五味杂陈还是在别处释放吧。会议最后将为下一个冲刺形成切实可行的改进计划。 口号：自由、平等、奋进、拓新 自由开放，不受约束，撸起袖子就是干，大家平等，畅所欲言，振奋向前，奋勇前进，开拓创新。

“冲刺”是scrum框架的基础，通俗地讲就是每个迭代周期，我们在实践过程中需要抓住冲刺的几个特性：时长限定，持续周期短，一致的持续期，锁定冲刺目标，完成的定义。 时长限定： 冲刺中有个时间盒（timebox）的概念，用来帮助安排工作执行情况和管理工作范围。时间盒具有设定wip数量限制，强制排优先级顺序，展示进度，避免不必要的完美主义，促进结束，增强可预测性等优点。就目前我们团队的敏捷实践来看，敏捷开展前期，团队处于传统瀑布式开发向scrum模式的过渡时期，团队成员还没有那么强的迭代时间盒的概念，可以多提醒团队成员时间盒，或者将当前迭代的起始时间张贴到大家每天都能看到的地方，让大家在完成迭代计划的时候有时间概念，达到冲刺的目的。 持续期短： 持续周期短的冲刺跟瀑布式开发模式相比更容易规划，得到反馈的速度更快，如果我们做完一件事很快就可以被检验，就算有错误也能及时纠正，错误成本大大降低。从团队成员来看，持续周期短，反馈迅速能够有效地减少人出现疲颓的现象，提高团队成员的工作效率。 一致的持续期： 一般来说，团队的冲刺时间最好固定，因为这样有助于团队形成一个有节奏感的冲刺活动，几个迭代周期之后，也更方便估算团队的迭代工作量，制定更为合理的迭代计划。说到团队的节奏，我觉得一味地满负荷的迭代冲刺也是不可取的，会造成团队成员疲累，长此以外，便失去了冲刺的“冲”。团队可以根据成员的需要，进行一些帮助团队缓解压力，放松身心的活动，大家可以在迭代回顾会上就这些事进行讨论，比如我们团队之前就有成员提出每周六下午大家一起出去运动，诸如此类。总之，迭代冲刺不是空喊着提高效率一味地干活，而是劳逸结合，形成张弛有度的团队节奏。 锁定冲刺目标： 冲刺目标是团队和产品负责人作出的共同承诺，团队承诺在当前冲刺结束之前完成目标，产品负责人承诺在冲刺执行过程中不改变目标。这涉及到相互之间的承诺，所以冲刺目标在迭代周期内是不允许的变更的，就像是大家都应该遵循的游戏规则，随便更改冲刺目标是十分影响士气的事。但是不可变更并不意味着不可以澄清，变更和澄清的区别在于，变更会涉及需求变更，导致大量的工作返工，而澄清更多的是对需求的补充说明，提供更多的细节来帮助团队实现冲刺目标。 当然游戏规则也是团队和产品负责人一起定的，并不是要求我们墨守目标，盲目地把它当作铁律，团队还是要注重实效，不应该因为团队中某一个群体或个人的原因随意更改目标，但如果是团队共同的效益，我们也可以适时地做一些调整。比如我们团队，会有一些现场的vip任务，如果当一个紧急的vip任务来了，而团队成员又没有闲置的工作来完成的时候，可以在对团队目标没有大的影响的情况下，做一些等工作量的替换，将优先级稍低的工作延后。 另外冲刺目标的达成是跟团队士气息息相关的一件事，所以刚实践敏捷的团队，建议刚开始的迭代周期不要将工作量排得太满，一是因为刚开始团队成员对敏捷的流程把握还不够准确，所以对工作量的评估可能不够准确。举个例子，我们团队的一部分测试工作是由开发人员结对相互测试，第一个迭代周期的时候，我们的开发就只评估了自己开发的时间，而没有考虑到结对测试的时间，导致后面计划完成得很吃力。二是因为一开始的几个迭代周期如果能顺利进行有助于建立团队成员的信心，我们应该尽可能地保证团队能顺利并愉快地进入到敏捷模式中。 完成的定义： 完成的定义是在宣布工作潜在可发布版本之前，要求团队成功完成的各项工作检查。包括开发的DOD，测试的DOD等，团队可以根据自己的特点自定义DOD，并且可以随着团队的敏捷成熟度进行不断的优化调整，形成有自身团队特色的DOD。团队的DOD就像是一些大家都需要遵循的规格，是大家互相之间的承诺，所以我们团队在定义DOD时是大家一起讨论得出的，后续的变更优化也会充分尊重大家的意见。既然是要团队成员一起遵守的事情，那么让团队成员一起讨论制定更有说服力，也更能促进它的落地。 总结： 在我看来，冲刺是敏捷中十分关键的要素，区别于瀑布式开发，它以快速反馈，持续改进的方式，先定一个小目标，小步快跑，从而准确高效地达成项目的长期目标。当然这只是从冲刺的角度看问题，我们不应该被冲刺的一个个小目标遮蔽了双眼，只专注于一个个小的功能特性，而忽视了一些不紧急而重要的工作，团队或者是产品负责人一定还是要有全局的观念，把握住产品的大方向，合理地制定每个迭代周期的计划。

很多软件公司，在遇到产品交付延期、开发周期长、产品质量低下、运维成本高、响应需求慢等等问题时，会尝试引入敏捷来改善。然而，大多数公司的老板和管理者，从一开始就是错的，就注定要失败——因为他们本末倒置，忽略了 人的能力 和 责任心 ，只期望从过程和控制上来改善。 一个人做不好工作，主要有两个原因： 自我认知不清指一个人不知道自己想干什么、能干什么、能把什么干好，简单说就是没有自知之明，不知道自己的位置。 缺乏责任心是指一个人认为手上的事儿不是他的，是别人的（比如老板的、公司的、经理的），干好干坏和他没什么关系，所以这个事儿唤不起他的责任心，做起来就没动力，结果自然就是做不好。 一个公司或团队，要想有好绩效，就应该在这两方面努力： 找到有自我认知的成员 给成员选择和做决定的权利，让其产生责任感 搞明白了这个关键，接下来我们就结合Scrum最重要的一个阶段——冲刺启动会议——来看看为什么大多数Scrum实践会失败。 Scrum中的Sprint启动会议（计划会议）必须开，而且PO（Product Owner），SM（Scrum Master），ST（Scrum Team）都要参加。 一般来讲，Sprint启动会议要做下列事情： 很多团队会把启动会议分解，1、2两件事放一起做，3、4、5三件事放一起做。 当我们把需求讲解和PBI单独来做时，就很容易走回老路上去：只有所谓的核心人员参与讨论。 很多团队在做Scrum实践时，会嫌启动会议中的需求讲解和PBI挑选耽误事儿，或者觉得没必要大家都参加，只要产品经理、项目经理、技术大拿参加就好了，需求讨论好了再让其他团队成员参加。 这就在最开始犯了严重的错误。这样做，那些没参加需求讨论的成员，肯定没什么积极性！因为，这种形式，和之前的瀑布或迭代，没有任何差别啊，都是一小撮人决定需求，然后告知或安排给其他成员做。 告知、命令、安排，这些传统的控制手段，非但不产生积极性，还大大挫伤和打击团队成员的积极性 。 参与感非常重要，哪个成员没有参与决策而过程，哪个成员就没有积极性，就没有责任感，潜力和效率就出不来。所以，不要怕一开始花费的时间长，只要拿时间盒限制一下，不要离谱就好了。 这是SPRINT的起点，也是 第一个关键点：Scrum TEAM都要参与需求确认 。这一步做错了，对后面的影响很大。 第二个关键点就是从PBI到SBI，和第一个关键点一样，要由PO、SM、ST共同完成。 这个冲刺是ST在做，所以ST一定要对SBI认同，他们需要“我决定了我们这个冲刺做什么”的感觉，这种感觉带来把控感，带来积极性。否则，就回到老路上：你让我干啥我就干啥呗，还能怎么样……注意到了吗，这是非常消极的做法。 当一个人不能决定他要做什么时，就会失去责任心，就会消极对待（或者无法主动积极） 。 这一点下面的环节还会谈到。 第三个关键点就是讨论工时。合理的工时，才能让人心甘情愿的接受。 假如一个SBI需要32个工时，SM非要压到10个，那谁拿了这个SBI都会不情不愿，结果一定是花费比32个工时更多的时间。 讨论工时需要注意一点： 不要让技术能力最强的人来决定工时 。显而易见，技术水平高的开发人员估出来的工时，要比其他人少很多，因为他会以自己的能力和效率为基准。如果某个SBI比较复杂，只有技术和业务能力强的人才能把控，那就把他们估出来的工时乘一个系数（建议乘2或者1.5）。 最后，对讨论出的所有工时，再乘1.2或1.5的系数。这样最终的工时才是比较靠谱的。 最后一个关键点就是挑选任务。 注意，“挑选任务”中的挑选二字，正是它们带来了参与感、自主性、积极性。 假如SBI分解完毕，工时估算就绪，然后SM说，张三你做这个李四你做那个，那前面的功夫基本上就白费了。而这一点恰恰是很多SM常犯的错误。 当我们被安排时，非但很难有动力去把一件事情完成得很好，甚至还会消极对待 ，任务差不多就不愿再花心思了。 一个人愿意选择需要他学习新技能的任务去做，这是非常棒的事情，说明他愿意挑战自己，渴望成长。如果你给他当头一盆冷水，就伤着宝宝了…… 很多SM陷入安排SBI的局面，往往也是因为一些现实的困难，比如： SM对进度压力和关键任务的担心，其实也可以归结到 能力与任务不匹配 这一点上。技能与任务不匹配，短期有压力，长期是向好的。这点需要SM去平衡，比如一个人领了有挑战的任务，可以再给它几个匹配度高的任务（匹配度高的SBI的工时可以调整得少一些，或者不乘前面提到的系数），这样结合起来，对进度的影响就会小一些，而这位团队成员，仍然可以做他愿意做的事，还会有积极性。 只有SM允许ST自己选择任务，ST才有积极性 ，否则，我Qt做得好，十年都让我做GUI，我也没意思；他Android GUI熟悉，就一辈子做，人家想搞搞iOS都没机会，也会带来消极情绪。 不要把人限制在某个围墙内，要允许他成长，鼓励他成长，帮助他成长 。这是SM要考虑的事情，也是他需要承担的压力和风险。 不管SM面临多大压力和多少风险，一定要谨记： 有选择才有责任感，有选择才有积极性 。否则，你就回到了告知、命令、安排、压制的老路上，Scrum就注定会失败。 Scrum不仅仅是一套模型，它的内在是“ 以人为本 ”，只有团队成员充分的参与和选择，才能带来积极性和责任心，Scrum实践才可能成功。 相关阅读：

敏捷中常见名词解释 1）产品待办列表（Product Backlog） 整个产品的 Backlog 列表。包含客户提出的功能性需求和非功能性需求，以及技术团队内部产生的一些需求。动态的对需求进行管理。 2）冲刺待办列表（Sprint Backlog） 当前迭代的 Backlog 列表。是从 Product backlog 中根据优先级挑选出来的。是静态的管理需求。 3）用户故事（User Story） 用户故事：描述对用户有价值的功能。用户故事也可以定义为分配给软件开发组的特定业务需求。 4）完成定义DoD（Definition of Done） 当产品待办列表项或者增量被描述为“完成”的时候，每个人都必须理解“完成”意味着什么。虽然这在不同的Scrum团队之间会有巨大的差别，但是团队成员必须对完成工作意味着什么有相同的理解，这样才能保证透明性。 5）产品负责人Product Owner（PO） 产品负责人。负责维护产品订单的人，代表利益相关者的利益。保证Scrum Team在做从业务角度来说正确的事情。Scrum Team 由自我管理的、负责开发产品的人组成。通常由5－9个跨功能的人员组成。 6）Scrum Master（Management） 负责一个team按照scrum方式运行的角色，确保scrum按照初衷正确实施，消除那些影响团队交付的障碍，并负责屏蔽外界对开发团队的干扰，为团队服务的。通常是项目PM担任，也可以是通过Scrum Master认证的人员担任。 Scrum与Kanban 看板：在制品(work-in-progress, WIP)必须被限制 WIP上限和拉动式生产 3种角色 PO PM Scrum Team 3个工件 Product Backlog、Sprint Backlog、潜在可交付的产品增量 潜在可交付的产品增量：要求每一个Sprint结束都产生用户可用的软件，也被称着“潜在可交付的产品增量”（Potential shippable product increment, PSPI）。能否每个Sprint生成满足质量定义的PSPI 是Scrum 执行效果的试金石。因此这里关键的是团队内有一致同意的DOD（完成的定义），基于其中的内容来判断是否迭代内所有东西都做完了。同样，随着时间推移，团队DOD内容会不断修改完善 。“潜在可交付”并不意味着构建出的东西必须实际交付，交付是产品负责人的业务决策，基于发布计划来确定。 5个事件 Sprint Planning（IPM）：Sprint计划会议在Sprint一开始召开。PO和团队共同决定计划在这个Sprint完成哪些用户故事。 Daily Scrum Meeting（Standup）：每日站会，一般在15分钟以内。团队成员相互交流任务的进展，计划以及遇到的困难。 Sprint Review（Showcase）：Sprint评审会议发生在Sprint将要结束的时候。团队和客户一起评审本次Sprint的产出是否达到预期。 Retrospective：回顾会议发生在Sprint的最后，由Scrum Master负责召集团队召开。会中大家回顾和小结这个Sprint做的好的地方以及有哪些不足。保证团队能够持续改进，不断提高。 Backlog Refinement：Product Backlog的梳理，可以发生在整个Scrum周期的任何时间。 5个价值观 勇气：有勇气去面对各种挑战。 专注：每个迭代只专注于该迭代要完成的事情。团队和个人的能力、精力是有限的，在有限的时间内专注于最有价值的事情，以取得好的结果。 承诺：作为一个自组织团队，在迭代开始的时候做出承诺，并在迭代中全力完成。 尊重：团队是能随时沟通，并且相互理解的。 公开：团队所有的进展、问题、阻碍都是对所有人可视化、透明的。这样的团队才能彼此尊重，同时也能随时暴露问题。

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

Scrum是一种迭代增量的软件开发过程，覆盖产品的生产、交付和管理，通常用于敏捷开发。Scrum 的整体流程：第一步：产品负责人负责梳理来自利益相关方的反馈与需求，并按照优先级排序，形成产品待办事项；第二步：经过迭代规划、会议分析，和对产品待办事项进行估算，形成迭代待办事项；第三步：由团队在固定的开发周期内交付潜在可发布的产品增量；第四步：经过迭代评审和迭代回顾，结束当前迭代，并开始下一次迭代。

文化工作者团队中主要成员角色可以分为如下部门： (1)理论编辑部、 (2)新媒体运营部、　　(3)新闻采编部、　　(4)技术研发部、　　(5)网络论坛部、　　(6)文化活动部、　　(7)网络舆情部 以及　　(8)创意支持部等等。

一、敏捷管理理论 1、敏捷管理的定义 敏捷即灵活性，是动态的、适应于具体情况、迎合变化和自我完善的。敏捷项目管理是应对经常变化的、具有不确定性的软件项目的管理方法。敏捷是一种态度而不是一个流程，是一种氛围而不是方法。敏捷项目管理中最重要的一个术语就是创新。实施敏捷项目管理过程中项目管理者要注意：调整团队自身来适应变化，致力于产品，和客户进行协调，注重沟通。 2、敏捷管理的开发方法 常见的敏捷软件方法包括：Crystal、ASD（AdaptiveSoftwareDevelopment）、Scrum、FDD（FeatureDrivenDevelopment）、XP（ExtremeProgramming）、RUP（RationalunifiedProcess）等，它们都具有强调灵活、阶段迭代、反馈和逐步逼近目标的特性，本文中将重点介绍Scrum方法。 二、Scrum开发方法 Scrum（英式橄榄球争球队），软件开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。正如Schwaber所言，Scrumisanagile，lightweightprocessthatcanbeusedtomanageandcontrolsoftwareandproductdevelopmentusingiterative，incrementalpractices。Scrum将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝目标有明确的推进。 1、Scrum方法的原理 （1）Scrumteam。指整个项目小组，不仅仅包括全职开发人员，也包括了发行软件会影响到的外部人员，比如市场营销人员和顾客。 （2）Backlog。Backlog是一种任务列表，包括ProductBacklog和SprintBacklog两种，是指导Scrum开发方向的指针。SprintBacklog是一个Scrum团队计划将要在当前Sprint中完成的所有功能列表。SprintBacklog实际上是ProductBacklog的一个子集，在ProductBacklog的纲要性指导下，SprintBacklog不断发展并且充实整个项目的ProductBacklog，使之趋于完善。比如：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。 （3）Sprint（冲刺）。Scrum开发过程由一系列迭代的Sprint过程组成，一个Sprint过程就是一个冲刺过程，多个Sprint过程顺序进行，直至风险评估认为产品可交付为止。一个sprint是在限定时间段内的一系列开发活动，包括分析、设计、编码、测试等。通常为30天的迭代时间，把Backlog中的每一项安排在Sprint中，由团队估算出所需要的时间（按小时记）。每一次Sprint之后，一定要有可以交付使用的功能。每一次Sprint之后要回顾，团队按照既定的SprintBacklog目标来演示完成的内容。 （4）Scrummeeting。Scrummeeting是Scrum中项目管理的有效手段，分为两种：Sprintmeeting和Dailymeeting。Sprintmeeting是在下一个Sprint开始之前，即在当前sprint即将结束之时举行的，Sprintmeeting讨论并决定下一个sprint的sprintBacklog，会议举行的时间周期随Sprint的周期而定。

一、敏捷管理理论1、敏捷管理的定义敏捷即灵活性，是动态的、适应于具体情况、迎合变化和自我完善的。敏捷项目管理是应对经常变化的、具有不确定性的项目的管理方法。敏捷是一种态度而不是一个流程，是一种氛围而不是方法。敏捷项目管理中最重要的一个术语就是创新。实施敏捷项目管理过程中项目管理者要注意：调整团队自身来适应变化，致力于产品，和客户进行协调，注重沟通。2、敏捷管理的开发方法常见的敏捷方法包括：Crystal、ASD（AdaptiveSoftwareDevelopment）、Scrum、FDD（FeatureDrivenDevelopment）、XP（ExtremeProgramming）、RUP（RationalunifiedProcess）等，它们都具有强调灵活、阶段迭代、反馈和逐步逼近目标的特性，本文中将重点介绍Scrum方法。二、Scrum开发方法Scrum（英式橄榄球争球队），开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。正如Schwaber所言，Scrumisanagile，lightweightprocessthatcanbeusedtomanageandcontrolsoftwareandproductdevelopmentusingiterative，incrementalpractices。Scrum将开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝目标有明确的推进。1、Scrum方法的原理（1）Scrumteam。指整个项目小组，不仅仅包括全职开发人员，也包括了发行会影响到的外部人员，比如市场营销人员和顾客。（2）Backlog。Backlog是一种任务列表，包括ProductBacklog和SprintBacklog两种，是指导Scrum开发方向的指针。SprintBacklog是一个Scrum团队计划将要在当前Sprint中完成的所有功能列表。SprintBacklog实际上是ProductBacklog的一个子集，在ProductBacklog的纲要性指导下，SprintBacklog不断发展并且充实整个项目的ProductBacklog，使之趋于完善。比如：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。（3）Sprint（冲刺）。Scrum开发过程由一系列迭代的Sprint过程组成，一个Sprint过程就是一个冲刺过程，多个Sprint过程顺序进行，直至风险评估认为产品可交付为止。一个sprint是在限定时间段内的一系列开发活动，包括分析、设计、编码、测试等。通常为30天的迭代时间，把Backlog中的每一项安排在Sprint中，由团队估算出所需要的时间（按小时记）。每一次Sprint之后，一定要有可以交付使用的功能。每一次Sprint之后要回顾，团队按照既定的SprintBacklog目标来演示完成的内容。（4）Scrummeeting。Scrummeeting是Scrum中项目管理的有效手段，分为两种：Sprintmeeting和Dailymeeting。Sprintmeeting是在下一个Sprint开始之前，即在当前sprint即将结束之时举行的，Sprintmeeting讨论并决定下一个sprint的sprintBacklog，会议举行的时间周期随Sprint的周期而定。

【答案】：BA选项ProductBacklog产品待办事项清单；B选项Refactoring重构，不属于Scrum的步骤；C选项SprintBacklog，Sprint待办事项清单；D选项Sprint，冲刺迭代。

区别之一： 迭代长度的不同XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.区别之二: 在迭代中, 是否允许修改需求XP 在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队收到干扰区别之三: 在迭代中，User Story是否严格按照优先级别来实现XP 是务必要遵守优先级别的。 但Scrum在这点做得很灵活， 可以不按照优先级别来做，Scrum这样处理的理由是： 如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。 另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量Scrum 没有对软件的整个实施过程开出一个工程实践的处方。要求开发者自觉保证，但XP对整个流程方法定义非常严格，规定需要采用TDD, 自动测试， 结对编程，简单设计，重构等约束团队的行为。因此，原作者认为， 这点上，XP的做法值得认同的，但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念，结合敏捷模式，表达给团队的信息是“你是一个完全自我管理的组织， 但你必须要实现TDD, 结对编程, ...等等”

乘风破浪这个词火了，在Scrum中也有一个乘风破浪的活动即Scrum回顾会。检视&调整是Scrum重要精髓之一，迭代回顾会议是Scrum中最有价值的会议之一，团队不断的复盘不断的检视达到团队自我持续改进、高效、自组织。 敏捷迭代固定时间盒，结束的标志之一是团队开完迭代回顾会，回顾会是Scrum从计划，执行到复盘的PDCA闭环，所以开好一场回顾会对Scrum master来说也是至关重要的一个流程。 回顾会前准备 迭代回顾会参加的人员有Scrum Master、团队所有成员、产品负责人等。对会议的参与人员发出会议通知，比如开会的时间，地点，会议议程等。同时提示大家提前思考本次迭代总结包括做的好的地方，需要改进的地方以及建议的改进措施。 Scrum master在回顾会开始前需要输出本次迭代的总结，包括不限于： 1.迭代用户故事完成情况，以及环比上个迭代情况 2.迭代bug数以及bug等级 3.冲刺预估工作量和实际完成情况对比 4.燃尽图燃尽情况，本次迭代进度 5.迭代的总结（好的流程或者待改进地方）Scrum master输出 回顾会中 回顾会议的基本原则： 1.对事不对人 2.聚焦于下次能否做得更好 3.从产品或者系统角度思考改进 回顾会议流程： 1.回顾上个迭代回顾会提出的改进措施是否落实以及完成 2.Scrum master对本次迭代概括性总结（会议前已输出） 3.引导团队成员轮流发言 4.Scrum master做好团队发言的记录，按照做的好的地方，需要改进的地方，改进措施三个维度记录 5.团队选择下个迭代最紧急且最重要2-3个改进项 6.讨论改进项的改进措施并做好记录 Scrum master在迭代回顾会中应该扮演复盘的引导人、设问人和叙述人。可以采用“三阶九步法”即精心准备，有效引导，推进到位（详见《复盘+》）。引导团队发言，比如打分法，迭代满分10分，引导团队成员给迭代打分，思考与发言。设问一些问题，比如迭代中某个接口开发遇到了某个问题对整个用户故事的提测影响等。 回顾会后 迭代回顾会结束之后，Scrum master把会议纪要和下个迭代改进的措施发到项目沟通群，提示团队改进同时跟进改进效果。 本人参与公司某个产品，从去年5月产品团队敏捷转型开始走Scrum流程到现在产品逐渐发展壮大拆分多个子产品团队，进行了大概30个Sprint（2周时间盒），收集并总结了团队成员反馈的共性问题，并在回顾会上引导成员讨论出优化改进措施，目前这些问题都已有解决方案，有的问题已经彻底解决了，有的问题还在不断改进完善中，这正是Scrum的精髓所在“检视&调整”。

敏捷教练管理信息交换的过程。 scrum模拟最初由Hirotaka Takeuchi和Ikujiro Nonaka在论文中应用于制造业，这个方法常用于敏捷软件开发（agile software development）和其它类型的项目管理。 在拉格比中，重新开始比赛并列争球的时候，对立的两对挤在一起。在产品开发中，每个早上团队成员都挤在一起开一个站立会议，会议中他们回顾进展，实质上也是重新开始这个项目。 在这个日常的会议中，有时候也叫做scrum，敏捷教练会向团队成员提出以下三个问题：你昨天做了什么？这个过程中有哪些阻碍？你今天要做什么？ 尽管敏捷教练（scrum master）的头衔听起来很有权威，权威教练不是项目领导，也不用为后果负责，整个团队一起承担后果。但这并不意味着这个工作很简单。 敏捷教练（scrum master）负以下责任：帮助团队在特定时期要达到什么目的这一问题上达成一致意见。帮助团队在日常scrum中达成一致意见。帮助团队集中注意并遵循日常scrum中一致同意的规则。清除团队进步的阻碍。保护团队不受外部干扰来源不详；敬请注意使用！

Sprint Planning Meeting——Scrum计划会议是每个Sprint(冲刺)开始之前的一次计划会议。计划会议的目标是从Product Backlog(产品待办列表)中挑选任务至Sprint Backlog(冲刺待办列表)，决定下一个Sprint要交付的内容。 本文是Scrum敏捷开发那些会议的第二篇，将会介绍Sprint计划会议的方方面面。 Timebox 上文已经提到，Sprint计划会议会在每个Sprint开始之前召开。除了这个固定的时间，还有一个很重要的时间概念——Timebox(限制的时间段)。Scrum的每个流程及会议都拥有一个相对固定的限制时间，一般来说，计划会议持续时间尽量控制在1-3小时。 地点 与站会不同，计划会议需要长时间的讨论，选择在会议室召开较为合适。 与会人员 Scrum Master, Product Owner, Scrum Team都需要参加计划会议。Scrum Master负责会议的顺利进行，Product Owner负责澄清Product Backlog中的待办项目的细节，Scrum Team则根据需求做出下个Sprint的承诺。 确定了时间、地点和人物，接下来要解决的就是计划会议的具体内容了。 到底如何将Product Backlog中任务移动至Sprint Backlog。 最后来谈一谈持续改进。每一个Team，都是由陌生到熟悉，由生疏到成熟，相对来说越成熟的Team就越高效。 对于计划会议来说，Estimation的精准度很重要，因为它意味着Scrum Team能否做出对自己以及对任务的准确评估，或者说能否做出一个有效的承诺。持续改进的过程，也是一个不断记录和对比过去的过程，通过数据对比，Scrum Team可以更清楚地了解自己的能力。

首先，讲解下Sprint开发过程的一些原则： 当仔细思考这些原则的时候，将会看到Agile宣言渗透其中。接下来详细讲解每一原则。 请注意，这些技术中有许多是从精益方法中借来的，特别是WIP的看板。这是因为一旦故事计划好了，团队就应该像一台运转良好的机器一样运转。因此，持续改进和减少浪费的目标在此也绝对适用。 然而，Scrum与众不同且保持敏捷的一个关键方面是，产品负责人在团队中，他们可以增量地接受工作。另外，Sprint Backlog对所有人完全透明地显示了团队在Sprint结束前必须完成的工作，开发团队可以根据Sprint的需求来管理他们的时间。这些故事结合在一起形成了一个有意义的、可交付的产品增量。 正是基于这些原因，敏捷为开发团队提供了可持续性、目的性、掌控性和自主性，而不是纯粹的精益方法。这些要素已被证明是最能激励知识型员工团队的。

通常在球有意外或侵权时，裁判会scrum。球不能从对方后面被抢走，只能从前面。所以当不再这个 scrum 里面的 scrum half 把球扔进去时，你必须尝试把对方往后推，或尝试用脚把球弄到后面去。但有时候像快到底线时，球员会选择推到底。

迭代计划（ Sprint Planning ）是 The Scrum Guide 中5个迭代事件（ Sprint Events ）中的一个，这个事件是一个Sprint周期的第一个会议，迭代计划会的好坏，直接关系着后续迭代的顺利进行。 The Scrum Guide 的建议是1个月的迭代，计划会最好不超过8小时，我们公司的迭代一般都在2周，所以理论上不应该超过4小时。 但是连续开4小时的会议，几乎所有的同事都是无法保持全神贯注的注意力的，会议开到后面，很多同事就开始昏昏欲睡，或者玩起手机了。 我们公司的做法是，将迭代计划会拆成了2个会议： 迭代梳理会 、 迭代计划会 ，这两个会议分别用来讨论 The Scrum Guide 提到的两个问题： 下面分别介绍这两个会议的细节。 这个会议主要是回答 这次Sprint能做什么？ 的问题。 会议的召开时间，我们公司一般是定在这个迭代结束前的倒数第二天（结束前的最后一天是用来召开迭代评审和迭代回顾的）。 在开这个会议前，PO需要准备好以下资料： 下面分别就这几个资料做个说明： 下一迭代的梳理会前，PO需要根据之前迭代Team完成故事数的情况，从Product Backlog中预先准备好足够的Sprint Backlog，比如：之前的几个迭代，Team完成故事数基本保持在10-13个，那么PO在这次的梳理会前，他最好能准备15个以上的用户故事，这么做是因为敏捷团队是在不断成长的，它的 速率（Velocity） / 容量（Capacity） 是在不断扩容的。 优先级的确认其实应该分2步： 很多团队一直重点关注Sprint Backlog的优先级确认，却忽略或低估了Product Backlog优先级确认的重要性：我们在规划一个产品的时候，基本都是先定一个大方向（Epic），然后向下分解成大的功能模块（Feature），最后再分解成一个个的小功能（User Story）。 Product Backlog在确认优先级的时候，是站在整个产品的视角考虑的，所以这个优先级确认的有与无、好与坏，往往会给公司带来致命的伤害。 规模化敏捷框架SAFe（Scaled Agile Framework）提出了一种定量计算法来评估需求优先级的方法：WSJF（Weighted Shortest Job First：加权最短作业优先），下一个章节我会介绍。 在确认好Product Backlog以后，Sprint Backlog的优先级可以默认与Product Backlog一致，如果梳理会上有其他同事提出修改的意见（比如研发的同事会觉得有一些依赖的先后顺序、或者有一些相似的功能想要放到一块等等），可以在会上直接调整。 在梳理会上，按照DoR（Definition of Ready）的要求，最好能有高保真设计图，如果实在给不出来（这个会议是在下一迭代开始前的2天召开的，有时设计的同学确实赶不出来），低保真原型图一定是要有的，否则大家开了半天会，但是都不知道产品要做成什么样，那这个会基本等于白开了。 每一条排入迭代的用户故事，都要有详尽的验收标准，之后的开发以及测试，都是按照这份标准来进行的。 迭代梳理会由 SM引导 ， PO主持 ，时间一般控制在2小时左右（2周的迭代），会议的目的主要有： 这个会议主要是回答 如何完成所选的工作？ 的问题。 我们公司一般是安排在迭代的第一天上午进行，时间一般控制在2小时左右（2周的迭代）。 会议的主要流程如下： 迭代计划会前或者当天，高保真的设计图就必须要准备好了. 另外，迭代计划会开完以后，测试的同学就要着手开始写新迭代的测试用例了，在计划会的当天，应该就能有一份测试用例的初稿了，在迭代的第二天再开个测试用例评审会，就可以开始开发了。当然，有些经验比较丰富的测试人员，或者比较成熟的团队，测试用例写的比较好的话，也可以不用为了用例评审单独开一个会，团队成员自行看下觉得没问题就好。 上述就是我们公司迭代计划会的一些方法，每个公司的做法可能不一样，不管形式是怎样的，只要大家能回答 The Scrum Guide 中关于迭代计划会的两个问题即可。 如果大家有更好的组织形式，欢迎留言讨论。

按照 The Scrum Guide 的定义（这里是中文版： Scrum指南中文版（The Scrum Guide） ），迭代评审会是在Sprint快结束时举行，用以检视所交付的产品增量并按需调整产品待办列表的一个会议。在Sprint评审会议中，Scrum团队和利益攸关者协同讨论在这次Sprint中所完成的工作。根据完成情况和Sprint期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。这是一个 非正式会议 ， 并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。 对于长度为一个月的Sprint来说，评审会议时间最长不超过4小时。对于较短的Sprint来说，会议时间通常会缩短。ScrumMaster要确保会议举行，并且每个参会者都明白会议的目的。ScrumMaster教导每位参会者遵守时间盒的规则。 Sprint评审会议包含以下内容： Sprint评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个Sprint的产品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。 以上是官方的定义，我们公司的做法与上述内容基本一致，但是有些细节会有些调整： 我们公司的评审会主要就是以上流程，关于 The Scrum Guide 中提到的： 这个问题我们是在回顾会分析的。 这个问题我们一直都没有涉及，没有涉及的原因有两点： 因为我们公司的回顾会流程比 The Scrum Guide 定义的流程少了3步，所以我们的耗时也比官方的建议时间少一些，我们2周的迭代，一般1~1.5小时就能开完了，比官方的建议时间少了半小时。 以上就是我们公司Scrum评审会的做法，如果大家有更好的组织形式，欢迎留言讨论。

Scrum作为一种项目管理方法，已经帮助数百家公司成功走出困境，高质量、快速地成功交付软件产品。Scrum是管理复杂项目的简单方法，它的魅力在于规则和实践方法数量较少，简单好用，容易上手。但与此同时，Scrum的简明性往往又使新手在不知不觉中重拾传统项目管理方法和工具。使产出成果缩减。在实际项目管理中。怎样充分利用Scrum更好、更快地帮助团队开发出优秀的软件产品，成为很多项目经理密切关注的主题。在本书中，Scrum创始人兼倡导者之-肯·施瓦伯分析了一系列具有启发性的案例，从其多年指导公司进行敏捷项目管理的经历中精选了各类成败案例，描述经验教训。通过本书案例，读者将理解如何使用Scrum解决复杂问题，驱动更优成果，更快交付更具有价值的软件产品。领悟Scrum理论与实践精髓之后，您能：·驾驭最复杂、最难处理的项目·有效管理未知因素和不断变化的产品需求·建立自管理开发团队，简化指挥系统·从客户处接受更清晰的规格说明及反馈·大幅度缩减项目规划时间及所需工具·在30天周期内构建并发布产品，使客户尽早获得可交付产品·定期评审、报告及调整项目，避免失误·支持位于不同地区的多个团队同时开发某一大型项目·将投资回报最大化

　scrum 的产品管理工具有8Manage PPM敏捷产品开发管理工具。支持增量式产品开发的短迭代管理和满足竞争格局和产品需求动态变化的管理需求。如有需要，敏捷管理也可灵活扩展以满足传统项目监控的管理需求（如时间管理，成本管理）。　　敏捷管理中的产品需求像展示在故事板上的场景或故事，来龙去脉清晰明了，一目了然。在同一页面可把产品需求和需求负责人分配到对应的用户故事，有根有据，可随时追踪

前些年去法国自驾，发现法国道路上的红绿灯特别少，大部分的路口都被设计成环岛（见下左图）。而在国内，这样的设计非常少，大部分是十字路口（见下右图）。两种路口的目标都是为了更好的让车辆通行，那么哪种是更好的设计呢？答案是各有利弊！ 环岛的优势是不需要红绿灯（环保），车辆进入路口时基本无需等待。而十字路口在大流量时通行效率更高（车辆无需在岛内绕行），而在乡村车辆很少时，可能会造成车辆空等。如果路口有大于4条路交汇（比方上海的五角场），十字路口的信号灯设计将会非常复杂，远不如环岛效率高。但环岛对于司机的要求很高，需要理解的规则比信号灯复杂。 之所以提到这个例子，是想提醒大家，我们在讨论一种模式或者工具时，很多时候我们会强调它的优势，而选择性的忽视其的局限。只有从各个角度去了解事物时，才能获得更多的洞察和更深的理解。 上一期我们从一个实际的案例展示了如何用 SoS 的方式运作一个大型的项目。这期我们将继续深入讨论 SoS 可能的不足之处。问大家两个问题： 1.上期案例中这样运作 SoS 哪些地方可能出现问题？ 2.我们该如何应对？ 在我们展开进一步讨论前，大家可以先思考一下，看看有没有自己的答案？ 现在让我们从以下2个主要方面对 SoS 展开更多讨论，看看可能出现的问题。 1.需求管理 2.团队协作 上一期中，我们提到张这幅需求分层的图，这是一个洋葱式逻辑包含关系的图。 如果我们从时间维度或者说生命周期来看的话，那么需求分解的图应该是怎么样的呢？（这里假设需求只需要拆分成3层） 上图展示了非常理想的状况，需求可以“快速分析和拆分，快速启动开发，迭代交付”。然后事实通常是如下图所示，可能会遇到反复调整方案，没有资源启动等等问题。 问题1： 在“真实情况”中，solution 通常从提出到开发会经历很久，有些时候是因为需求的反复变更，有些时候是 solution 的反复修改，而有些时候时要等待合适的开发资源。在 SoS 的框架中，我们会发现 APO-OPO 的沟通模式会有很多的交接，这增加了快速启动前等待的时间，最糟糕是，完整的 solution 已经在文件夹中躺了1年以上。而且，通常在开发资源准备好时，solution 很可能要重新刷新。 解决： ● 简化 solution 的制订，从最初的一个几十页的文档简化到 one page solution（PPT），只列出这个 solution 最关键的一些要点，并做一些简单的拆分。这里遵循的原则是避免提前，过度的设计。这里通常由 APO 负责，有时也会指定由某个 OPO(Operational PO)负责。 ● 在预测到开发资源可能准备好时，通常1名或多名 OPO 将会对 solution 以及拆分的 feature 做进一步详细设计，并将需求细化。 这样我们就可以在需求出现时不必做过度的设计，而且也避免了过时的重新设计。 在大团队进行协作时，一个无法避免的问题就是高昂的沟通协调成本。在 SoS 的框架下，由于引入了 APO-OPO，SoS-Team 双层结构，不可避免会加剧这样的问题。 问题2： 某些 solution，甚至 feature 是跨 area 的，需要不同 area 的 PO 与 team 进行协同。 解决： 由于 area 是相对静态设置，因此不可避免的会有一些需求穿越 area。解决方案： ● 尽量由同一 area 的 APO，OPO，team 负责主导。实际开发过程中，由一名 OPO 负责澄清需求，并且设置需求优先级。同时 team 的 scrum master 之间会建立一个团队层面的沟通机制，来协调进度和开发依赖。 ● 之前提到 team 一般会有1-2个 primary domain, 2-3 secondary domain 的开发能力。因此一个 team 原则上是可以跨 area 工作的。这个在一定程度上缓解了这个问题。 ● 尽量在架构与技术上解藕（这个依赖良好的软件架构），使两个团队可以独立开发和发布。 工具支持：我们在 PO 群建立一个需求看板，在各个 SoS 建立 SoS 共享看板，每个 Scrum 团队也有各自的白板。同时各个团队（包括 PO，SWAT）建立各自的 wiki，将团队信息发布出去。可以借助的工具包括 Jira，Teambition 等等。（P.S. Teambition 的知识库是很好的共享团队知识的工具。） 总结：以上列举了两个在 SoS 框架下可能发生的问题。我们可以看到，在 SoS 框架中，普遍来说信息沟通与决策链条会拉长，因此克服这些短板就成了很大的挑战。一方面在拆分需求时能消除复杂性，尽量避免需要大量的沟通；另一面，要给予团队更多的赋权和赋能，让他们能灵活处理各种问题。文章的开头我们提到了十字路口适合大流量的通行，但必须高度依赖信号灯。同样地，在团队协作时，我们需要有一些协作工具，例如 Jira, Teambition 等等。正是这些工具的出现，才使得团队有能力完成复杂协作，包括信息共享，知识共享，创新等等。 另外，敏捷开发依然是高度依赖人的开发模式，如果产品开发过程中，团队没有成长，总会遇到某种模式所无法克服的问题。相反，团队如果能持续成长，那么就能灵活运用各种模式，实现真正的敏捷！ 点击这里，了解更多关于 Teambition 的故事

昆仑手表。CORUM是瑞士高级制表品牌，由ReneBannwart及其叔父GastonRies于1955年成立，中文音译为昆仑手表，是一个国际知名品牌。

Scrum作为目前互联网公司实施敏捷（Agile）最流行的一种方式，也在不断地被越来越多的实施者们以他们的方式进行“改进、优化”。很多时候，流程方面的裁剪确实是必要的，或许是软件的形式不同、公司的氛围不同，可一些最基本的游戏规则都被更改至面目全非，那还能称之为Scrum吗？ 敏捷宣言的创始人之一Ron Jeffries把“伪”敏捷的实践戏称为“Dark Agile”，“黑暗”敏捷，也就是软件开发界的黑暗料理啊。让我们来看看这些实践是如何把敏捷带入深渊的。 Scrum中有三个角色组成了Scrum Team， 实际上真正输出用户价值、商业价值的Development Team，是他们（通常为开发、测试、实施人员）将需求真正转化为产品输出。那么其他两个角色的价值在哪里？ 首先是Product Owner（PO），这个角色的名称其实会让人产生一些误解，中文通常翻译为“产品负责人”，其实最终负责产品交付、质量的，还是Development Team。那这个负责人负责什么呢？ Scrum Alliance的Scrum Guide里写道： Product Owner其实是Product Backlog Owner，他负责管理“产品待办列表”。通常来讲，PO作为所有需求方的代表，管理产品要提供的功能，换言之，任何人想要更改需求，都要先通知PO，由PO决定是否更改产品待办列表。 PO还要负责能够清晰地向Development Team解释需求，并且让产品待办列表开放可见。同时负责排列事项的优先级以保证产品价值的交付。 所以如果你身边的PO，或者你自己就是一个PO，检查以下几点，看看是不是已经“黑化”了： 合格的PO，是一个充分了解产品的“产品代言人”，开发团队能够从PO这里直接或间接得到所有关于产品的问题明确的答案。这样才能让开发团队在“需求无障碍”的环境中火力全开。 Scrum Master首先得是个Master，也就是中文里的“大师”或者“师傅”，需要精通Scrum，能够帮助Team良好的运行于Scrum的各个过程中。 再来看一下Scrum Guide: 这里有两点需要注意，第一，Scrum Master是一个servant-leader，并不是一个领导者，而更偏向于服务者。第二，Scrum Master服务的对象是Scrum Team，也就是说包括了PO和Development Team。 看看以下几个“黑化”了的Scrum Master: Scrum Master应该提供Scrum流程方面的建议，组织各种会议以及帮助团队形成适合团队的工作模式，保证团队成员对产品的认识都在同一水平上，同时在团队之间消除沟通的隔阂，实现“交流无障碍”。 合格的Scrum Master，是可以“消失”的Scrum Master，当Team完全熟悉Scrum之后，应该可以省略这个角色。 只有Development Team的成员真正创造了产品的增量。 之前也说过，产品的输出来自于Development Team，所以真正的产品负责人，应该就是Development Team本身，每一个成员都应该对自己的输出的质量和数量负责。只要是没有意识到这一点的开发人员，都已经“黑化”了。 Development Team对每个Sprint做出交付增量的承诺，都应该基于自己能力和意愿，而不是基于压力或是诱导。而PO和Scrum Master的存在，可以让团队更加专注于自己的工作，减少流程、需求上的噪音。 Scrum Team的三种角色是完全扁平化的，至少在组织架构方面，Scrum没有上下级的概念。如果你的组织在上面加上了上下级的概念，那就要谨防其带来的额外障碍了。 “黑暗敏捷”让本来很轻的Scrum变得很重，或许是妥协，或许是曲解，都应该尽量避免。

通过可视化的拖拉配置 快速开发B/S架构的Web和APP项目 分为.Net版本和JAVA版本-支持多种常用数据库-手机/平板/电脑一次搞定-源码交付,自由扩展。

作者：（美国）科恩（Mike Cohn） 译者：廖靖斌吕梁岳 陈争云 等Mike Cohn Mountain Goat Software创办人，以帮助客户公司成长为卓越软件开发组织为己任，专门提供Scrum与敏捷软件开发培训。Mike Cohn是敏捷运动两大公认名著(《用户故事与敏捷方法》和《敏捷估算与规划》)的作者。他曾经历任多个软件开发公司(从新创公司到《财富》40强)的技术总监，曾服务子BBC(英国国际广播公司)、Capital One(美国第—投资集团)，Electronic Arts(艺电)、Experian(益百利)、Gooqle(谷歌)、Intuit(直觉软件公司)、Lexis Nexis(律商联讯)。

敏捷开发方法尤其适合于开发团队比较庞大的项目。关于scrum方法描述错误的是敏捷开发方法尤其适合于开发团队比较庞大的项目，scrum是敏捷中三个流行的方法精益，极限编程(XP)之一，scrum是一个框架，是一种迭代方法，核心是冲刺。

【答案】：C本题考查敏捷方法基础知识。极限编程XP是激发开发人员创造性、使得管理负担最小一组技术。水晶法Crystal认为每—个不同项目都需要一套不同策略、约定和方法论。并列争球法(Scrum)使用迭代方法，其中把每30天一次迭代称为个冲刺， 并按需求优先级来实现产品多个自组织和自治小组并行地递增实现产品，协调是通过简短日常情况会议进行。自适应软件开发（ASD)有六个基本原则：①在自适应软件开发中，有一个使命作为指导，它设立了项目目标，但不描述如何达到这个目标；②特征被视为客户键值关键，因此，项目是围绕着构造构件来组织并实现特征；③过程中迭代是很重要，因此重做与做同样重要，变化也包含其中；④变化不视为是一种更正，而是对软件开发实际情况调整；⑤确定交付时间迫使开发人员认真考虑每一个生产版本关键需求；⑥风险也包含其中，它使开发人员首先跟踪最艰难问题。

【答案】：BScrum为并列争球法，是敏捷开发方法的一种。该方法使用迭代的方法，其中把每30天一次的迭代称为冲刺，并按需求的优先级来实现产品。多个自组织和自治小组并行地递增实现产品，协调是通过简短的日常情况会议进行。具体步骤包括：首先需要确定一个ProductBacklog，即按优先顺序排列的一个产品需求列表；Scrum Team根据ProductBacklog列表，进行工作量的预估和安排；有了ProductBacklog列表，通过Sprint Planning Meeting（Sprint计划会议）从中挑选一个Story作为本次迭代完成的目标，这个目标的时间周期是1～4个星期，然后细化这个Story，形成一个SprintBacklog；SprintBacklog是由Scrum Team完成的，每个成员根据Sprint Backlog再细化成更小的任务（在2天内能完成）；在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行Daily Scrum Meeting，每次会议控制在15分钟左右，每个人都必须发言，向所有成员当面汇报前一天的工作，承诺当天要完成的任务，可以提出遇到不能解决的问题，并更新自己的Sprint burn down；做到每日集成，也就是每天都要有一个可以成功编译并且可以演示的版本；当一个Story完成，即Sprint Backlog完成，也就表示一次Sprint完成，此时需要进行Sprint Review Meeting（演示会议），即评审会议，产品负责人和客户都要参加，每一个Scrum Team的成员都要向他们演示自己完成的软件产品；Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。重构（Refactoring）就是通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。不是Scrum的步骤。

敏捷开发包括一系列的方法，主流的有如下七种：XPXP（极限编程）的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。SCRUMSCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。该方法由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。Crystal MethodsCrystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。FDDFDD （Feature-Driven Development，特性驱动开发）由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。ASDASD（Adaptive Software Development，自适应软件开发）由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样 有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。DSDMDSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。轻量型RUPRUP其实是个过程的框架，它可以包容许多不同类型的过程， Craig Larman 极力主张以敏捷型方式来使用RUP。他的观点是:目前如此众多的努力以推进敏捷型方法，只不过是在接受能被视为RUP 的主流OO开发方法而已。

会。scrum会有多个release，每个Scrum项目可以有多个ReleaseCycles，每个版本可以有多个sprint。ReleaseBurndownChart与ProductBurndownChart比较相像，不同点在于前者展示单个release的内容，而后者会跨多个release。