Scrum

需要泛滥不晓得如何下手？总想先做简略的需要，简单需要却一拖再拖？那么，咱们是时候开始思考如何设置需要优先级了。 本期终极指南将展现如何为需要设置无效优先级，如何无效治理工作量，让效率指数倍增长，搭配《Scrum流程：如何迷信地进行需要优先级排序？》应用更佳！ 一、如何设置优先级？在Scrum中，PO确定一个产品需要列表后，开发团队会抉择一个用户故事作为一个迭代的指标，而一个用户故事是由多个需要组成，所以需要优先级的设置十分重要。咱们能够通过以下几个方面来思考设置需要优先级： 1、需要的重要性与紧急性在Scrum中，产品需要的重要性和紧迫性由PO确定，PO通常会思考市场竞争和商业指标等因素来确定产品的重要性和紧迫性。在确定需要的重要性和紧迫性时，能够思考需要对产品质量和用户体验的影响程、需要的紧急水平和截止日期、需要的复杂度和危险水平、需要的价值和优先级、需要的依赖关系和关联性等因素。通过综合思考这些因素，能够更好地确定需要的重要性和紧迫性，以便团队成员更好地安顿和优化工作。 2、需要所须要的工夫评估每个需要所需的工夫，有助于防止错过最初期限或团队成员适度操劳的状况。但在估算需要时，肯定要留神给每个迭代都留有盘旋的余地，以防呈现紧急需要。一旦做出预计，PO应依据预计的时间表定期审查停顿状况，并依据新信息对需要进行调整。 3、需要的依赖关系咱们个别将有关联的需要搁置在同一个用户故事中，但如果造成用户故事太大，就能够拆分成多个用户故事。当然这样就会造成用户故事之间有依赖关系。依据INVEST准则，为了造成用户故事之间的相互依赖关系，咱们要尽量减少这种状况。在迭代开始时要调整好先后顺序，例如B用户故事中的字段依赖于A用户故事，则要先做A用户故事，再做B用户故事。 从以上几个角度思考设置需要优先级，能够帮忙团队更好地布局治理我的项目进度，确保我的项目按时实现。另外，需要优先级的设置应该是动静的，须要依据我的项目停顿状况进行调整。 二、设置优先级的益处通过设置需要优先级，团队成员能够更高效地实现需要，进步工作效率和品质，从而实现团队的指标。让咱们来看看设置优先级的一些最无益的后果： 1、提高效率团队通过确定需要优先级可能分明地看出工作重点，明确哪些需要是最重要的，哪些需要须要尽快实现。这不仅可能更好地布局和治理工夫，还能够更好地掌控我的项目进度，防止需要延误和进度滞后，从而进步工作效率，就像软件开发人员会将修复重要平安BUG设为高优先级，而更改款式则是低优先级。 2、优化资源利用在古代商业环境中，工夫和资源是贵重的资源。在解决需要时，咱们能够依据需要优先级来分配资源，确保重要需要失去优先解决，防止资源节约和反复利用，进步资源利用效率，从而降低成本和提高效益。 3、进步生产力一旦需要优先级失去明确定义，咱们就能更轻松地掂量每项需要的进度。这激励每个团队成员放弃生产力并专一手头的指标，从而进步整个组织的整体生产力。此外，设置需要优先级还能够让咱们放弃专一和积极性。当咱们分明理解需要优先级后，能够帮忙防止被不太重要的需要或分心所困扰，而是专一于需要并实现更多作。 三、写在最初那禅道项目管理工具是如何帮忙团队进行需要优先级设置呢？ 创立需要列表，为每个人物调配优先级状态；设置截止日期和揭示，免得遗记重要需要；多种可视化项目管理工具，轻松掂量需要进度。借助项目管理工具的帮忙，让需要治理变得更加简略。需要优先级的设置是项目管理中十分重要的一部分，通过对进行排序和分级，团队能够更好地掌控我的项目进度和资源分配，从而实现我的项目的胜利。 借助本终极指南中提供的技巧，快开始将你手中的需要进行优先级划分吧！

胜利的项目管理取决于整个团队对角色和职责的了解，应用责任调配矩阵调配和定义角色是使我的项目放弃在正规并为胜利做好筹备的好办法。 如果设计切当，责任调配矩阵可能促成我的项目的胜利交付。  一、什么是责任调配矩阵责任调配（RACI）矩阵是项目管理工具，用于定义和跟踪团队成员在我的项目中的角色和职责。 RACI代表着四种角色：Responsible（执行者）、Accountable（负责者）、Consulted（咨询者）和Informed（知情者）。 通过应用RACI矩阵，团队成员能够分明地理解本人在我的项目中的角色和职责，从而更好地合作和实现工作。 【1】执行者 执行者是指在Scrum团队中负责执行工作并确保工作最终实现的人员。他们是工作的次要执行者，须要确保工作按时实现并达到预期的质量标准。执行者通常是团队成员中最理解工作的人，因而他们须要与其余成员严密单干以确保工作的胜利实现。 【2】负责者 负责者次要负责分配任务，确保工作按计划按时交付。因而，负责者须要理解工作的具体细节，明确任务的指标和需要，确定实现工作所需的资源、工夫和估算。同时，还须要负责监控工作的停顿，并定期向负责人汇报工作的状态。 实践上负责者只有一位，如果超过一位就可能引起凌乱，但理论状况并非总是如此。在必须有多个负责方的状况下，必须明确每个人所负责的特定我的项目。 【3】咨询者咨询者是指在我的项目过程中须要提供专业知识、技术领导或反馈意见的人员，他们通常是具备相干教训或专业技能的专家。征询人员不负责间接执行工作，但须要依据本人的专业知识为团队提供业余意见和倡议。因而，咨询者需与其余成员紧密联系，确保团队在工作执行过程中可能最大化地利用他们的技能和常识。 【4】知情者 知情者是指与工作相干，但不直接参与工作执行的人员。知情者须要理解工作停顿状况，以确保它们的工作不会受到工作的影响。 以上四个角色在Scrum团队中都扮演着十分重要的角色，他们须要相互合作，确保工作可能按时实现并达到预期的质量标准。在Scrum团队中，每个角色都有本人的职责和工作，须要相互配合，能力获得最佳的工作成果。 二、如何创立RACI矩阵RACI矩阵开始是一个简略的图表，确定要实现的工作、团队成员以及他们在每个工作阶段或流动中负责的RACI角色。通过以下四步创立可能在肯定水平上防止含糊不清，确保最佳的清晰度。 1、确定要害流动和交付物的清单创立责任调配矩阵时，首先要明确我的项目指标，确定实现这些指标所需的要害流动和相应的交付物。 要害流动是必须实现以使整个我的项目可能按时、按质地交付。它们可能会波及在预约的工夫内实现重要里程碑、制订要害决策、保障估算打算和履行质量保证等方面。而交付物是我的项目中创立的、需交付的文件、代码、产品或服务等。 2、确定谁须要参加到我的项目中首先，思考每个参与者的能力和教训，确保他们可能胜任本人的角色并为我的项目的胜利做出奉献。同时，咱们也须要思考部门和团队之间的单干，确保各个部门或团队之间的合作顺畅。 其次，思考资源的可用性和估算限度。必须确保所需的资源和估算能够满足我的项目的需要，并及时调整和协调资源之间的竞争和抵触。 最初，咱们还须要更加重视交换和单干。要确保所有参与者都理解本人的角色和工作并有机会与其余参与者协商和制订我的项目打算。须要建设一个良好的沟通机制，定期举办会议并公布更新。 3、确定我的项目角色和负责每个流动和可交付成绩的职称和人员。一旦确定工作和负责人，任务分配便成为一个一直重复的过程。项目经理可依据业务负责人的意见以及相干文件进行第一次调配。 这里须要留神一点：咱们须要将人员姓名与其所负责的我的项目角色一并列出。因为人员可能会变动，因而列出姓名有助于防止歧义，而列出头衔则有助于在角色变更时进行更新。 在指定负责角色时，尽量将其限度在一个人身上，或者在列出多个人员时进行廓清阐明，以防止含糊不清。此外，应有一位独自的人员负责签收和批准，与负责创立的人员离开，以确保明确性。 4、与团队的次要成员举办审查会议，以获得统一。初步的RACI矩阵实现后，与团队举办审查会议，审查要害流动和可交付成绩以及负责每项流动的人力资源。通过电子邮件分享该草案，而后，安顿工夫进行审查。 记录审查会议的后果，并散发会议记录。在会议前让团队晓得，会议后会有笔记。这也将有助于确保要害成员充沛留神，并在审查期间三思而行，集中精力。 三、说在最初其实，每一个我的项目都能够创立一个RACI矩阵。如果我的项目曾经开始了，还须要创立RACI矩阵吗？ 即使我的项目曾经开始，项目经理仍能够利用现有的我的项目时间表，创立一个RACI草案，以确保正确的小组参加和调配，并举办审查会议（或会议），并获得团队的认可。

每日Scrum站立会议 每日Scrum站立会议并不存在。在Scrum中，咱们不进行站立会议。 Scrum的确有每日Scrum，然而没有人须要在其中站立。 “站立会议” 这个术语被认为是排外的，因为它假设所有缺席者都能站立。这是一种身材健全主义，组织应该停止使用它。然而，每日Scrum和站立会议之间还有其余值得注意的区别，超出了术语的敏感性。 每日Scrum和站立会议的差别 每日Scrum和站立会议之间有许多不同之处。以下是它们之间的10个要害区别： 1. 每日Scrum的目标 每日站立会议的指标是向团队领导或经理报告集体的状态，而每日Scrum的指标是容许开发人员疾速解决阻碍并制订“下一个工作日的可执行打算”。 2. 参加站立会议的人员 每日站立会议通常包含开发人员、测试人员、经理、团队领导甚至利益相关者，而每日Scrum仅供开发人员应用。 开发人员能够邀请任何人加入每日Scrum，但只有开发人员能够是沉闷参与者。 3. 每日Scrum的工夫调配 Scrum在每日Scrum上设置了严格的15分钟工夫框，而站立会议容许继续进行，直到小组中的某个人太累而无奈站立。 4. 站立会议的会议主持人 每日站立会议通常由经理、团队领导或处于势力位置的集体主持。 在Scrum中，没有子团队或层级。每日Scrum中没有领导者，而是由一个“业余人员凝聚的团结统一体”推动会议，以制订可执行的当天打算。 5. 每日Scrum和站立会议的过程 站立会议通常要求所有参与者答复一组规范问题。 Scrum没有任何形式化的须要答复的问题汇合，并且每日Scrum没有固定的格局。 6. 站立会议的频率 每日Scrum每个工作日都会进行，以便团队能够打消阻碍并启动他们的开发工作。相比之下，站立会议可能依据组织的需要每日、每周甚至间歇性地安顿。 7. 每日Scrum的地点 Scrum指南保持要求每日Scrum在每天雷同的工夫和地点进行，而站立会议不受此类限度。 8. 术语“站立会议” “每日站立会议”这个术语是有阻碍意识的，因为它假如每个人都能站立。因而，“每日Scrum会议”是一个不那么具备攻击性的术语。 9. 相干框架 “每日Scrum会议”这个术语与Scrum框架密切相关，它在Scrum之外没有理论利用。 相比之下，站立会议是由极限编程办法在软件开发畛域中流行起来的，尽管在软件开发之外的其余行业和方法论中也广泛应用站立会议。 10. 总体目标 每日Scrum会议的指标是打消其余会议的需要，免得扩散开发人员的注意力，让他们专一于通过Sprint生产价值增量的次要指标。 与每日Scrum会议不同，站立会议的指标是让管理者和领导评估我的项目的停顿状况。 每日Scrum会议和站立会议的益处 沟通和合作是所有软件开发我的项目的重要组成部分。在Scrum中，每日Scrum会议是一个定期的会议，帮忙开发人员启动一天的工作，而站立会议则是管理者和利益相关者从团队所有成员那里获取状态报告的机会。 【注】本文译自：Daily Scrum vs standup meetings: What's the difference? (theserverside.com)

有点长，冀望你能通过本文彻底理解 Scrum。 在本文中，我首先回顾了下个性团队，指出个性团队的一些问题，接着进入正题介绍 Scrum 的定义、特色、劣势，而后讲述了Scrum 的3个角色，接着是框架、流程、5个会议和3个工件，最初列了一些我在应用 Scrum 时遇到的一些问题，心愿能触发你的思考。 回顾个性团队 个性团队是一个长期稳固、跨职能、跨组件，继续端到端交付用户价值的团队，负责把一个个「以用户为核心的性能」变成一个个可交付的产品增量。从这张图中，我发现这个过程有点糙。有点怎么把大象装冰箱里的感觉。一些问题没有答复，比方： 这三个人都是啥角色都负责什么？怎么配合日常工作是什么？上面我来介绍下Scrum 的框架，平时我就是用它帮我解决这些问题的。 Scrum的定义和特色Scrum 的定义Scrum是一个用于开发和保护简单产品的框架，是一个增量的、迭代的开发过程，目标是让开发人员像打橄榄球一样迅猛并充斥激情，通过团队单干，进步工作效率。通过团队间的无效交互，为企业发明价值。 Scrum 的特色迭代开发：有固定周期的迭代，每个迭代都交付一些增量的可工作的性能。增量交付：每个迭代完结前，实现新的增量的交付。自组织团队：自组织治理工程过程和进度，决定本人如何发展工作，决定谁来做什么高优先级的需要驱动：研发团队要从待办列表最上层的高优先级的需要开始开发Scrum 的劣势疾速反馈：个别1-2周一个迭代周期，也是一个反馈周期尽早交付：高优先级需要及时满足危险升高：短周期继续反馈，问题及时修改适应变动：小步快跑，一直修改继续改良：一直反思、回顾、优化客户称心：始终与用户进行沟通，一直反馈修改需要Scrum的人员和角色3.1 产品负责人PO(Product Owner)PO 角色定义确定产品的方向和愿景，定义产品公布的内容、优先级及交付工夫，为产品盈利负责。保护产品需要清单，代表利益相关者的利益，代表业务方。 个别产品经理负责，或者由相熟畛域业务想转产品经理的研发人员负责。因为产品经理自身曾经是所有业务的接口人，相熟畛域常识、熟悉业务是其本职工作，所以产品经理负责PO更正当。不倡议仍然写代码的研发人员负责。写代码和负责整个业务都是须要全身心注入的工作。不倡议 SM 专任总体准则，「谁了解用户」「谁相熟畛域业务」，「谁能代表业务方」、谁来负责PO。 PO 主要职责帮公司失去最高投资回报，指引团队做最有价值的工作，为产品的ROI负责确定产品的性能，定义实现的规范，验证交付的工作成绩决定公布的日期和公布内容依据市场价值、用户价值调整产品性能和优先级承受或回绝开发团队的工作成绩；参加五个会议：产品待办布局会，迭代打算会议, 每日站立会，迭代评审会，迭代反思会PO 日常工作PO参加产品布局，对接内、内部利益干系人对产品待办梳理、优化、优先级排序PO负责制订迭代打算，确认团队每个迭代实现的性能、优先级和预期交付日期PO加入每日站立会，听取状况，理解停顿，廓清需要。PO必须每天可能解答问题，并进行验收测试。Sprint内，PO还要确定下个迭代的打算，交付性能、优先级程序以及交付日期。Sprint完结时，PO要参加迭代展示会(show case)和 Sprint 反思会。3.2 麻利教练SM (Scrum Master)Scrum Master角色定义是团队的Scrum 教练和组织者，与 PO 严密单干，保障的是麻利开发的流程和秩序。整个团队保障停顿和后果。是规定的执行者，是团队中的服务型领导。促使团队依照 Scrum形式运行，为Scrum过程负责的人个别可由更相熟麻利开发模式及施行流程的 PMO 来负责Scrum Master 主要职责帮忙员工及干系人了解并施行 Scrum领导团队采纳 Scrum，治理 Scrum 流程，确保流程的贯彻执行组织召开每一个会议，解决团队在开发过程中遇到的问题找到妨碍团队高绩效的阻碍，并解决确保团队外部沟通顺畅、高效团队和内部的接口人，保障团队专一和工作节奏，爱护开发团队不受烦扰保障各个角色及职责良好合作保障开发过程按计划进行Scrum Master 日常工作Scrum Master 领导团队成员听从Scrum 流程和应用麻利工具Scrum Master 组织召开五个会议Scrum Master 加入每日站立会。例会上听取状况，甄别危险和问题、提供帮助。Scrum Master 解决团队在开发过程中遇到的问题Scrum Master 帮团队扫清高效能的阻碍3.3 研发团队Team(Scrum Team)研发团队角色定义负责在每个迭代的结尾交付潜在可公布的“实现”产品增量 由组织构建并受权,来组织和治理他们的工作。所产生的协同工作能最大化 开发团队的整体效率和效劳。 他们是自组织的,没有人(即便是 Scrum Master 都不能够)通知开发团队如何把产品 待办事项列表变成潜在可公布的性能。开发团队是跨职能的,团队作为一个整体领有发明产品增量所须要的全副技能。Scrum 不认可开发团队成员的头衔,无论承当哪种工作他们都是开发者。此规定无一例外。开发团队中的每个成员能够有专长和专一畛域,然而责任归属于整个开发团队开发团队不蕴含如测试或业务剖析等负责特定畛域的子团队。研发团队的主要职责负责自组织地交付用户故事做交付过程中的所有工作摆布估算流程决策「如何实现」研发团队日常工作了解迭代待办，拆分工作项评估工作量、开发产品、实现代码编写且自测通过团队做技术决策：技术调研、架构设计自领迭代工作、团队决定任务分配评审测试用例产品上线交付用户价值Scrum 框架和流程 【PO】和所有利益相干人密切合作，从用户角度以及公司业务思考问题和决策【PO】创立产品愿景、产品路线图；梳理最有价值的产品性能，【PO】把最有价值的产品性能保护到一个依照优先级排列的产品待办列表(Product Backlog)【PO】负责细化产品待办列表中的所有用户故事【SM】召开产品待办布局会，PO依照优先级形容要做的产品待办，团队进行了解、发问，PO针对问题进行细化；团队会后进行工作了的预估和安顿。【SM】召开迭代布局会，PO依照优先级逐条具体解说本次迭代要实现的产品待办，研发团队依照优先级筛选要实现的产品待办，直到下个迭代工作量达到饱和，同时创立关联的工作待办列表，并和产品待办关联。【研发团队】自组织召开每日站立会，SM和 PO 必须加入；每个人讲完本人的进度后，更新工作看板内容。PO帮忙接到迭代中的问题；SM 解决影响团队高效能的问题。【SM】召开迭代评审会，研发团队进行show case，承受评估；PO以用户故事是否能胜利交付来评估工作实现状况。【SM】召开迭代反思会，总结哪些做的好，要保留；哪些做得不好，要改良Scrum 5个会议5.1 产品待办布局会（Backlog Grooming Meeting）开会时间：通常是迭代打算会开始前3天参加人员：PO，SM，研发团队散会指标：咱们下个迭代要做的内容，开发团队确认工作故事点PO把下次迭代将要实现的用户故事、依照优先级形容给在场的人员团队明确指出需要不明确或者有问题的中央，PO记录，会后补全、廓清开发团队评估工作故事点开发团队创立子工作并关联5.2 迭代打算会（Sprint Planning）开会时间：迭代开始的第一天参加人员：PO，SM，研发团队会议指标：决定咱们下个迭代要做哪些内容。PO确认待办事项整顿会议上的问题都曾经解决，性能曾经欠缺或者有余。产品性能列表曾经依照客户价值优先级排序。PO 逐条具体解说要实现的产品待办，尤其是之前存在问题的待办。开发团队依据待办事项整顿会议会后评估的工作量，从高到低筛选待办，直到本次迭代工作量达到饱和。PO 参加探讨并答复和需要相干的问题，但不烦扰估算后果。最终产生迭代待办事项列表（Sprint Backlog）队员认领工作5.3 每日站会（Daily Scrum）参加人员：PO，SM，研发团队会议指标：理解团队现状每日Scrum通常不超过15分钟。每日Scrum中可能有简要的问题廓清和答复，但不探讨。每日Scrum既不是向管理层汇报，也不是向产品负责人或者ScrumMaster汇报。它是一个开发团队外部的沟通会议，来保障他们对现状有统一的理解。开发团队是自组织的，通过每日站会来确认他们依然能够实现迭代的指标。每一个开发团队成员须要提供以下三点信息： ...

在Scrum框架中，咱们对Scrum的五个会议肯定都不生疏，但如何组织这五个会议，能力让Scrum团队真正踊跃、被动地参加进项目管理中呢？接下来咱们会以一个Sprint为周期，具体介绍一下Sprint中的五大会议。 一、产品待办事项列表梳理会产品待办事项列表梳理会其实是贯通在所有Sprint两头的流动，这个会议不仅为当下的Sprint打下基础，还为之后的Sprint提供优先要做的待办事项。 个别在Sprint开始前，须要开发成员、产品负责人以及Scrum Master一起参加，来探讨需要，拆分、廓清用户故事；欠缺验收规范；对故事的优先级进行排序；估算故事点。产品待办事项列表梳理会的时长个别不会超过一个Sprint时长的10%。 在会后，参会成员须要一起产出一个梳理好的产品待办事项列表。 二、打算会议严格来讲，打算会议是Sprint开始的第一个事件，目标是为接下来的Sprint对齐指标，承诺须要实现的故事，并做出打算。 在打算会议上，须要开发成员、产品负责人以及Scrum Master一起参会，参会成员会独特明确Sprint指标；划分工作优先级；拆分细化工作；确认工作实现的定义；预估工时以及确认Sprint 待办事项列表。打算会议的开会时间个别是Sprint开始的第一个上午，在一个为期1星期的Sprint中，打算会议时长个别不会超过2小时。 完结打算会议后，团队会明确此次Sprint的指标，并产出一个梳理好的Sprint待办事项列表。 三、每日站会到了执行阶段，为了明确团队成员的工作进度，及时发现并解决大家在执行过程中遇到的问题，团队须要通过每日站会来更新Sprint指标达成状态，并依据以后停顿从新打算残余的工作。在会上，咱们须要同步工作进展，裸露工作问题，而后在会后寻求问题解决方案。 每日站会的具体工夫依据团队本身理论状况而定，只有可能造成一个习惯即可。会议继续时长个别不能超过15分钟。参会成员次要是开发团队与Scrum Master，产品负责人也可旁听。 在每日站会的时候，团队各成员顺次进行陈说，包含且不限于： 我昨天实现了什么；明天的打算；遇到的艰难或阻碍。在这种及时、无效的信息互通后，团队成员可能对彼此的工作及工作项状态造成共识，如果呈现一些技术问题，则能够在会后大家一起解决；如果呈现资源有余的问题，Scrum Master能够进行资源的协调，为Scrum团队排除障碍；如果呈现工作停顿与打算不统一的状况，能够及时地找出问题，并对前面的打算进行调整。 四、评审会议当Sprint行将完结时，咱们要交付的产品增量就须要承受测验啦。评审会议是Sprint中完结前的倒数第二个事件，在评审会议中，须要产品负责人、Scrum Master以及客户等其余利益相关者一起参会。个别在为期一周的Sprint中，评审会议的会议时长最好不超过1小时。 在评审会议中，会有如下议程：团队介绍Sprint成绩，并演示新性能，承受其余参会者的评审；根据Sprint指标对我的项目进行评估；并依据参会者的反馈后果来调整产品Sprint待办事项列表。 评审会议后，团队和产品负责人则会收集客户或其余利益相关者对产品的反馈，以便前期进行调整。 五、回顾会议回顾会议是Sprint中的最初一个事件，也是团队须要回顾这一Sprint中的工作，找出需改良的事项，并制订改良打算的会议。回顾会议的参会者个别是Scrum团队成员。 在回顾会议中，参会者须要回顾上次会议改良后果；概括性总结此次Sprint的过程，包含哪些地方是做得很好须要激励的，哪些地方是须要改良并继续跟踪的；总结量化后果；做会议纪要并给整个团队同步；做出下一Sprint须要改良的待办事项列表。 在产出的改良待办事项列表中，须要做好优先级排序，并将优先级高的改良事项放入下一个Sprint待办事项列表中。 六、如何激发团队成员的积极性？当团队成员专一于本人的工作时，会不可避免地感觉会议在占用本人的工作工夫，或者总是会打断本人的工作思路，从而对散会呈现了抵触情绪。实际上，Scrum次要依附这五大会议来进行信息同步与交互，对齐指标，这五大会议能够说是必不可少的。那么咱们如何能力激发起团队成员的参会积极性，保障会议高效有序地发展呢？ 1.提前准备一些散会所需的信息、材料或者是团队考察能够在会议之前进行和同步。比如说回顾会议，咱们能够在会议之前先发动一个回顾考察，这样在会议过程中就能够间接进行收集与分享了。 2.将会议提前纳入工作咱们在排工作的时候，能够将会议作为工作中的一项，同样须要估算工时，这样会议的发展是在大家打算内的，就不会呈现突发散会或者加班散会的状况。 3.散会控场如果大家的发言过于踊跃，会呈现逐步远离会议主题的状况，这个时候会议发起者能够进行控场，如果某位参会者的发言偏离了会议主题，能够将这个想法或者话题记录一下，而后暂停这个话题，持续回到会议主题中。那会议中记录的这些“跑偏”的话题咱们能够在会后进行发散、探讨。 总之，在Scrum团队中，最重要的就是小步快跑、疾速对齐，一直地发现过程中的问题并进行改良，进步团队的工作效率和能力程度。 历史文章举荐：PDCA循环——疾速晋升软件品质的必备工具 要想组建麻利团队，这些办法不可少 需要变更，麻利我的项目应如何做？

共创嘉宾| 潮海我的项目教练 撰文编辑| LigaAI 全文约 4,300 字，浏览约需 12 分钟 迭代评审会（Sprint Review）基于实在的用户应用场景，展现以后整个产品增量，通过获取贴合用户应用习惯的反馈和倡议，最终输入产品待办列表的优化调整。迭代评审会应重点关注用户需要的解决状况，而不是查找缺点（当然，影响外围流程的重大缺点肯定要记录在册）。 展现后果：开发团队检视以后迭代的最后打算，展现每个需要/故事的工作后果及变动；评审反馈：产品负责人进行确认，收集反馈，并记录进一步的改良构想为新需要/故事；调整计划：产品负责人及要害干系人介绍无关后续迭代的新信息/构想，为接下来的迭代打算会议提供有价值的输出信息。基于清晰的会议目标和探讨重点，如何更好地实现迭代评审会？高效的迭代评审会又有哪些鲜为人知的事倍功半小技巧？ 本期麻利实际，LigaAI联结潮海我的项目教练团队的资深麻利教练，一一为你解答。 一、 每个迭代完结都要进行评审吗？作为Scrum五大事件之一，迭代评审会通常在产品增量实现后、正式公布前举办，但在实践经验中，并非每个迭代实现都必须要进行评审。根据工夫频率的不同，迭代评审会分为高频评审和低频评审。 高频评审实用于产品增量简单的状况。通过将产品增量拆分成若干个要害需要，并在每个要害需要实现后，邀请重要干系人参加测验，以扩散一次性评审的会议压力。低频评审适宜产品增量对干系人的感知价值不大（比方长流程的端到端需要）或干系人工夫缓和等状况。通过多个增量的合并评审，缩小频繁会议对工作的占用和烦扰。此外，以迭代周期/固定周期作为举办迭代评审会的标记并非最优解。迭代周期是团队外部的开发治理单位，在可感知价值增量层面或有不稳定性。 更好的做法是基于里程碑/史诗的实现状况，以增量后果为指标，按需发展迭代评审会。 研发里程碑个别分为「外部里程碑」和「内部里程碑」两种。 外部里程碑常指我的项目要害决策点，如需要阶段实现、设计阶段实现，次要用于评估我的项目外部危险，个别不波及用户反馈，无需迭代评审；内部里程碑是波及对外公布的重大性能/模块的实现，须要在产品公布前邀请要害干系人加入迭代评审会，并奉献实在的应用反馈。二、 干系人肯定要参加会议吗？在《每日站会能不能取消？》一文中，咱们曾提到「非必要状况下，Scrum Master能够不加入每日站会」。那么，迭代评审会是否也能够不须要要害干系人的参加呢？ 答案是——不能够。 迭代评审会的外围指标是收集用户反馈，所以要害干系人的参加极其重要。 但在理论中，不可避免地，干系人可能因各种起因无奈加入会议，能够采纳以下几种形式解决： 第一，由干系人受权的决策代表代替干系人加入会议。决策代表须要具备对产品增量奉献反馈的能力，并且要可能提出「通过与否」的关键性意见。 第二，如果干系人无奈分出大块工夫参加评审，那Scrum团队能够采纳高频小模块的形式实现反馈，遵循「价值准则」——先展现最急需反馈的性能。 第三，将干系人的会议预约列入待办。防止临期预约的抵触和缺席隐患，产品负责人能够在迭代布局期，就提前锁定要害干系人的会议工夫，或将迭代评审会以定期模式常态化（比方安顿在每双周的固定时段），确保干系人可胜利缺席。 奉献反馈的干系人必须加入，而执行反馈的技术人员也同样不能缺席。 开发团队应在现场直面用户，凝听最实在的用户声音，能力更好地了解业务、了解需要。 现实状况下，开发团队应全员参加迭代评审会，同干系人一起合作探讨，在认同中建设工作价值感； 如果团队规模较大，也能够轮流派代表或者安顿技术骨干参加会议，负责本次产品增量的开发人员必须出席会议，以缩小一手反馈的传递偏差。 三、迭代评审会的多种打开方式01 合而为一践行Scrum的过程中，麻利四会（即打算会、每日站会、评审会和回顾会）不用是齐全独立的。 例如，对于每周一迭代的短周期麻利团队，能够思考将评审会和打算会合为一次会议，以加重会议累赘。会议中，应先评审、后打算：要害干系人在评审完结后后行离场，Scrum团队持续进行新一期迭代的打算会议。 迭代回顾会则不倡议与其它会议合并，因为这是麻利团队复盘和经验总结的宝贵机会；但能够思考将多个迭代的回顾会合并一次举办。 02 一分为二对于产品增量价值低、客户感知影响不大、或有高质量要求，需先进行外部评审的迭代而言，能够采纳「一分为二」的低频评审模式，将迭代评审会分为「Scrum团队的外部会议」和「与干系人合作的内部会议」两次进行。 Scrum团队的外部评审侧重于残缺的性能展现，重点审查要害性能是否跑通、是否存有Bug尚未修复/发现等；有要害干系人参加的内部评审以收集用户实在反馈为主，重点验证产品增量是否满足客户需要、是否达成真正的产品价值。03 直面客户是最好的模式近程办公和异地合作流行的明天，共享式的文档/表格/问卷合作免去许多会议，然而迭代评审会以获取用户实在反馈为外围，面对面沟通却是不可省去的重要典礼——直面客户、察看用户的应用和体验是获取无效反馈的次要路径。 对于重要且急需用户反馈的性能，Scrum团队应被动安顿产品负责人和性能相干的技术骨干返回干系人公司，进行一对一展现和沟通； 面对无奈克服的时差或时空问题，也能够采纳线上视频会议的模式，然而倡议要开启摄像头和麦克风，并应用共享屏幕，让Scrum团队「看到」干系人的应用反馈。 四、迭代评审会的四个黄金搭档高效的迭代评审会个别蕴含性能演示、体验试用、探讨反馈和待办优化四个环节。 01 性能展现述清会议内容与目标后，开发成员联合迭代打算与产品增量，向产品负责人和要害干系人展现曾经实现的产品价值。 看似简略的性能展现，也存在一些共性的改良空间——《深刻外围的麻利开发》提出「展示会七宗罪」以形容性能展现过程中的七大问题，并针对性地提出了高效展示会的七个技巧。 七宗罪之一：筹备工作没做好，空耗会议工夫 正确做法：主讲人在正式展现前，应该做好充沛的筹备工作——预演演示步骤，筹备测试数据，提前部署演示环境等等，防止慌手慌脚和空转节约，进步会议效率。 七宗罪之二：没有阐明铺垫，云里雾里不知所以 正确做法：在开始演示之前，主讲人该当简要地介绍会议指标和所要展现的性能，并阐明性能给用户带来的价值。清晰的上下文能让产品负责人和干系人更快地进入状态。 七宗罪之三：逐条过验收规范，缺失业务完整性 正确做法：不要一一演示用户故事/验收规范。主讲人应以性能为单位，将残缺的产品/性能/模块串起来展现；最好定义出独自的业务场景，应用业务语言让业务成员更有代入感。 七宗罪之四：雷同/相似的性能，演示所有门路 正确做法：只演示最要害的门路。遇到多个门路实现雷同或类似性能时，抉择其中一条最简单/重要的门路具体演示，其余门路指出不同的中央，点到为止，无需笼罩全副门路。 七宗罪之五：过多提及跟演示性能无关的内容 正确做法：专一于最有价值/重要的性能演示，不要让小反馈/未实现的模块耽搁会议工夫；尽量不提及技术难题或技术计划等业务人员不感兴趣的内容。 七宗罪之六：认为展现仅仅是BA或QA的事件 正确做法：不让某个角色独占性能展现，人人都应该参加进来；能够采纳人员轮换的形式进行展现，这样能够晋升成员的业务意识，更相熟整个零碎性能。 七宗罪之末：不相熟的新人负责展现，重点含糊 正确做法：新人展现前应充沛理解业务和零碎，确保可能应答和解答业务的挑战和疑难；也能够让新人在结对编程、Story Kickoff等多做主导，具备肯定的零碎和业务意识后再向干系人展现。 02 体验试用开发成员实现性能演示后，更重要的是要让要害干系人亲自体验和试用零碎性能/Demo。用户亲自下场试用和测验，是获取反馈中必不可少的一环。 产品负责人也能够邀请实在的用户加入评审会，让其在开发的领导下体验演示的性能和零碎。须要留神，此时开发团队应该为干系人和用户留出足够的自主摸索空间，疏导他们重现最实在的应用习惯和场景，防止成为「产品推销员」。 03 探讨反馈产品负责人要收集要害干系人（和用户）的反馈，及时记录最新的改良与构想为新的需要。在体验试用环节，Scrum团队能够通过以下几种形式，察看用户体验，洞悉实在反馈。 ...

在从新梳理了回顾的大抵流程之后，咱们接下来须要做的就是改良回顾会议，让团队在回顾会议中更高效地思考。 零碎思维在回顾中是十分重要的，因为作为集体来讲，在没有信息和数据的状况下，团队成员会偏向于根据本人的了解和过来的教训来做出假如和论断，但这些假如和论断是全面或者说是不符合实际的。举个例子： 原定于10点的会议曾经提早了十分钟还没开始，这时，鲍勃冲了进来开始赔罪：“对不起，我来晚了！就在我刚要来到家的时候，一只流浪狗跑了过去。” 这时房间的其余参会者示意：“酷！”利亚姆说，“你会收容它吗？”“太吓人了，你没事吧？”琼妮问。伊恩点了拍板，督促道：“好吧，让咱们先完结这次会议吧。” 这三个人同时听到了鲍勃的这句话，然而因为关注点的不同，反馈也大不相同。利亚姆因为最近始终想养一个宠物，所以他猜想鲍勃可能会思考养这只流浪狗；琼妮小时候已经被流浪狗咬到过，所以她察看到鲍勃的衣服又皱又乱，所以放心鲍勃是不是被流浪狗咬到了；而伊恩最近和女朋友吵架，下班的时候始终郁郁不乐，这次他对鲍勃的早退有些不平，但发现其他人并没有过多地关注鲍勃早退这件事。 在这种状况下，咱们能够通过“推理阶梯”来推断会产生什么。 推理阶梯的目标在于咱们能够依照这个阶梯的关键步骤来走，不会跳过或略过某些关键步骤，确保咱们做出的论断更加精准。 团队在开回顾会议的时候，会议发起人能够通过一直地发问帮忙成员更好地思考，比方：咱们思考到了所有相关性了吗？还有什么维度可能与之相干？咱们的察看后果是在泛滥数据的根底上实现的吗？还是说只察看了几个数据？咱们做了什么假如？应如何验证咱们现有的假如？咱们为什么要做这些假如？这是惟一合乎咱们的论断和指标的打算吗？咱们是否让其他人来论述一下他们是如何想的？不过，在思考之前，咱们须要将足够多的数据收集到咱们的信息池中。在下面的例子中，他们三人承受到的信息就是鲍勃所说的话以及他们察看到的又皱又乱的衣服还有鲍勃脸上的表情。利亚姆三人接管到的信息池很小，在无限的信息池中，他们的思考和推断是基于本人的既往教训。所以引申到日常的项目管理 中，咱们在和团队成员做回顾的时候，首先须要改善的就是信息/数据的广度和深度。如果咱们可察看的数据非常少，那就有可能失落要害信息。假如在下面的例子中，鲍勃阐明跑过来的是一只小泰迪，那么就会打消琼妮的顾虑，也给其余的人多了一些反馈的空间。 其次咱们须要改善的是咱们的指标，在咱们设置团队Sprint的指标之前，首先须要明确咱们设置指标的目标是什么，这会帮忙咱们确定接下来要重点改良哪些方面。 如果咱们将指标设为“咱们是否向用户提供了他们想要的有价值的性能”，这将决定了咱们做出的性能须要客户验证并反馈、改良，满足他们的需要后交付。 接着在确定好改良的指标之后，咱们就要将略显含糊的指标转为具体的口头。首先咱们会请团队成员阐明这个改良指标的价值所在，而后具体是哪些角色须要做出这些扭转，最初咱们为了达成这个改良指标，将指标转化为一步一步具体可行的操作。这里要阐明的是，如果这个改良的工作量大，能够通过将其合成为更小的工作，而后在接下来的几个Sprint中逐步改良。 举个例子：咱们在会议中提出的改良是“限度工作在制品”。那咱们的第一个口头就是缩短开发的均匀周期。那进一步诠释这个口头则是须要在“doing”一栏中设置4个工作的在制品数量限度。如果咱们在这个过程中遇到问题了，呈现了在制品梗塞的状况，咱们就能够寻求别人的帮忙，通力解决这一问题。这样，咱们就由一个含糊的“限度在制品”的指标转变为了比拟清晰的“设置4个在制品数量，遇到问题后寻求别人帮忙”的行为。 为了更高效地实现回顾，咱们之前也有说要如何调动起大家的积极性，那这篇文章心愿可能帮忙大家在回顾会议中可能更高效地思考。 往期文章：如何无效进行回顾会议（中）？ 如何无效进行回顾会议（上）？

简介：笔者在带团队的六年中发现，程序员们退职场都有一个独特的困扰：“如同写代码都没什么问题了，日常工作基本上都是应酬业务需要的开发，如同找不到其余的更大的附加价值了，我应该找一些什么样的发力点能力让我的价值更突出呢？” 。本文将和大家聊聊程序员的软技能。 作者 | 英布起源 | 阿里开发者公众号 前言笔者在带团队的六年中发现，程序员们退职场都有一个独特的困扰：“如同写代码都没什么问题了，日常工作基本上都是应酬业务需要的开发，如同找不到其余的更大的附加价值了，我应该找一些什么样的发力点能力让我的价值更突出呢？” 。笔者认为，这就是典型的硬技能当下「看似」没有什么问题了，瓶颈卡在了软技能上。所以开篇做个小分享，聊聊程序员的软技能。 留神：明天讲的软技能 ≠ 心灵鸡汤，都是实实在在要学的技能。也不代表笔者精通了这些软技能，也是本人的集体心得与学习梳理，与大家做个分享，一起学习。 什么是软技能所谓软技能，就是绝对于「硬技能」而言的技能，对于程序员来说，「硬技能」就是计算机专业技术能力，软技能则是业余之外的所有技能，包含职业规划能力、解决人际关系能力、业余态度、做事的形式和办法等。 软技能的重要性《哈佛商业评论》的一项钻研指出：对 2000 家公司考察后发现，比起硬技能，公司更看重员工的通用能力（这里的通用能力 = 硬技能 + 软技能）。所以说，软技能的重要性一点也不用硬技能低。 笔者认为，很多初入职场的同学有一个十分谬误的观点就是：「软技能如同也没那么重要，貌似是可有可无的，程序员就应该更重视硬实力，硬实力才是咱们吃饭的手艺」。很多时候，咱们的硬实力（技术水平）曾经齐全可能胜任每一个编码需要，咱们向上倒退的瓶颈，可能恰好就是那一些看起来扑朔迷离却无比重要的「软技能」。 硬技能通常比软技能更容易定义和评估，但软技能更多波及行为或思维，也就是个性特征和认知能力，它更难评估。然而它们不论在任何行业、工种都实用，不论什么行业，什么工种，都能随身携带，学好能够受害一生。 工作中须要哪些软技能？比方工夫治理、沟通、学习办法、工作办法、价值观、大局观、人际交往、逻辑思考、领导力等等，这些加起来可能几天都说不完。这外面很多软技能是因人而异的，比方学习办法、领导力等，所以明天的分享次要举例一些笔者认为十分重要、每一个人都要晓得且使用到工作中的八种软技能。 程序员最重要的八种软技能人际交往能力有一本书叫做《软技能—代码之外的生存指南》不晓得大家都看过没？这本书最先提到的软技能就是人际交往，这是程序员们软技能上最缺失的。 不要只是埋头写代码 程序员遇到的所有的需要都来自于人、应用软件的是人、上下游沟通的是人，而埋头写下可能让计算机执行的代码只是咱们工作目标中的一个环节而已。写一手好的代码是咱们的基本技能，然而过于埋头写好代码却疏忽了人与人之间的连贯，这往往会带来更大的问题，比方信任感、亲切感的失落对工作协同的影响。与人打交道是咱们的根本职场技能，这跟咱们上学时的语数外是一样的，一旦偏科重大，想考一个好问题就很难了。当然了，除非你是「北大韦神」这种神级人物，自带光辉。 被动与人打交道 《能力陷阱》一书中，有一段话记忆粗浅：「许多人认为，人际网络实质是虚假的，认为是在“利用他人”，认为带有目的性的人际交往让本人变得“虚假”、“不洁净”、“像舔狗”，从而回绝在舒服区域以外建设人际关系。」，大家感觉这段话对吗？其实是不对的，当你抱着双赢的思维去沟通，就不会有这种累赘了。 《能力陷阱》中还有一个十分外围的观点：粗心就是「当一个人善于解决某一场景的问题的时候，工夫越久兴许越离不开这个场景，兴许这毕生就定格在这个场景外面出不来了，可能一辈子都是个程序员。」特地是对于管理者来说，管理者要做一个连接器，本人部门跟内部部门之间的连接器，走进来是走出「能力陷阱」的第一步。 LinkedIn 的创始人德·霍夫曼发现，当你在职业上要寻求帮忙时，最远不会超过三度，即咱们通常只须要通过两个人就能与其他人取得联系。然而咱们并未能很好地利用这些关系，因为咱们大多数人都没有意识到咱们的人际关系网络力量到底有多弱小。 阿里侠客行管理者培训里有一句很经典的话：「脸皮薄容易耽搁事」。 别单独用餐 有一本十分滞销的书叫做《别单独用餐》，外围观点也是论证社交的重要性，如何建设本人的人脉圈子，如果你不晓得如何建设本人的人脉圈子，不防重工作日的午餐开始，试着被动约人吃饭。一段时间当前，你会发现自己的圈子以及获取的信息跟以往有很大的不同。 记得之前听到过一个公司的段子：“公司的大佬，如果人不在工位或会议中，那肯定在园区的咖啡厅”。层级越高，资源、信息的共享就变得尤其重要。把用餐工夫利用起来，是一个很好的点子。 换位思考 学会聆听、关注别人感触，具备同理心。在跟人打交道或沟通之前，换位思考一下，如果你是对方想听到什么或看到什么，时常锤炼换位思考的思维，工夫长了会发现十分有用。如果不晓得对方是如何思考的，那就不要谈话，聆听即可。 举个例子：咱们经常会为了视觉还原问题而懊恼，设计同学找到咱们解决像素级别问题的时候，咱们往往是不是会焦躁，性能都开发不完，哪有精力去还原视觉，经常就会不耐烦的沟通，这个时候换位思考一下，他的设计作品最初做进去不是他想要的，他本人会不会有落差，这是他的工作职责，咱们只须要站在他的角度思考，给他一个适合的解决工夫即可。 在咱们工作中，我认为换位思考就是要有「服务思维」，处处将心比心、为他人着想。 结构化思维能力结构化思维是一种从无序到有序、从凌乱到清晰的思维能力，能够帮忙咱们疾速加工解决繁冗的信息，提炼要点，从而更加清晰的表白。这个话题很大，咱们只说要害的两个点： 概念不能多 有钻研证实：人类短期记忆的容量大略在 7 个左右，范畴是 5 到 9 个，所以尽量不要超过 7 个概念或我的项目。这在演讲或沟通中也十分重要。 有逻辑关系 大脑容易记住有逻辑关系的事物，逻辑关系分为纵向逻辑关系和横向逻辑关系 纵向逻辑关系 演绎逻辑：线性的，最终会为了得出一个由逻辑词“因而”引发的论断，比方因果关系演绎逻辑：将一组具备共同点的事实、思维或观点归类分组，并概括其共同性/论点，比方不同的群体横向逻辑关系 工夫程序：比方依照事务倒退的工夫线划分空间程序：比方依照地点空间来划分水平程序：比方重要的，不重要的来划分金字塔原理: 麦肯锡 40 年经典培训教材《金字塔原理》，每个职场人都必须看，强烈推荐，就不多介绍了。黄金圈法令（What、How、Why） 很多时候咱们都晓得 What 和 How，然而不晓得 Why（或者说没有认真思考 Why），就容易陷入到成长瓶颈。黄金圈法令也是一个经典的学习的三部曲。① What，是什么、② How，如何实现、③ Why，为什么是这样（而不是另外的样子呢？）。 举几个例子： ...

简介：高效落地麻利开发，先从这3个要害流动着手。带你用数据做好迭代复盘改良 ，数据谈话，借助云效我的项目合作·Projex 高效发展迭代复盘高效落地麻利开发。 摘要：高效落地麻利开发，先从这3个要害流动着手，带你用数据做好迭代复盘改良。数据谈话，借助云效我的项目合作·Projex 高效发展迭代复盘，高效落地麻利开发。 在前 2 篇文章《麻利开发落地指南之迭代排期》和《麻利开发落地指南之迭代跟进》中，咱们曾经理解： ● 什么是麻利开发 Scrum 办法； ● 什么是双周迭代； ● 如何高效地发展迭代排期会； ● 如何在云效我的项目合作·Projex 中落地排期； ● 如何无效地推动迭代打算； ● 如何在云效我的项目合作·Projex 中落地迭代跟进； 接下来，咱们持续以双周迭代为例，介绍在 Scrum 办法中的另一个重要的流动：迭代复盘会。 如何发展一场高效的迭代复盘会同样，咱们也梳理了迭代复盘会中须要相干同学做筹备的事项（如下表），供大家参考： 在落地迭代复盘会时，有几个点须要特地留神： ● 廓清复盘会的指标是为了继续改良：迭代复盘会的指标是要驱动研发团队的继续改良，而不是问责。通过迭代数据和团队的效力数据，能够让团队能更直观地理解现状，看到效力问题，找出导致问题的根因并采取行动，继续改良团队的研发效力。 ● 参加成员以一线员工为主：复盘会须要邀请到参加迭代的各个角色成员，包含团队负责人、产品经理、开发、测试等。倡议不邀请部门领导加入，防止大家因为管理者在场而不能畅所欲言的状况。 ● 稳固的流动频率：如果大家以双周迭代运作，初期倡议每次迭代完结举办一次。后续团队合作绝对稳固后，可一个月举办一次，须要稳固且继续地进行复盘会流动，这样有利于团队一直的改良。 ● 轻松的流动气氛：复盘会不是问责的流动，是一起发现和改良团队效力、合作问题的会议，复盘会主持人能够适当筹备一些零食或水果，让现场气氛轻松活跃一些，让每位参会成员都积极参与到流动中。 数据谈话，借助云效我的项目合作·Projex 高效发展迭代复盘要理解团队的效力现状，往往须要效力数据做撑持。上面咱们以云效我的项目合作·Projex 为例，介绍如何借助数据，高效地实现迭代复盘流动。 一 、迭代复盘会输出1. 团队以后研发效力数据 如果要继续晋升研发效力，团队须要明确效力指标，并在每次迭代复盘会上确认以后研发效力状态和指标的差距。在咱们辅导过的麻利开发团队中，大家通常以晋升需要响应能力、交付品质为指标： ● 晋升需要响应能力：通常体现在可能继续缩短需要交付周期。在云效我的项目合作·Projex 我的项目内的度量模块（能够在设置-导航服务中开启）或者在云效效力洞察·Insight中，通过「需要交付分布图」咱们能够直观地看到需要交付周期变化趋势、需要交付的频率和交付量等。 需要交付分布图 ● 晋升交付品质：通常会先从晋升过程品质动手，在云效我的项目合作·Projex 我的项目内度量模块或者在云效效力洞察·Insight中，倡议采纳「缺点趋势图」来观测缺点的产生、修复、存量趋势，通过「缺点修复分布图」来继续观测缺点修复效率。咱们冀望缺点尽早发现、尽快修复和存量放弃低水位，同时也冀望缩短缺点的修复时长。 缺点趋势图 缺点修复散布 更具体的研发效力剖析解读，能够查看这篇「看懂这5幅图，研发效力剖析和改良就容易了」 2. 本次迭代的燃尽图和工作项实现状况 在筹备好研发团队整体效力数据后，作为复盘会负责人还须要筹备好，本迭代交付相干的统计数据。咱们在云效我的项目合作· Projex 中迭代概览中能够获取到这些数据： ● 迭代工作项概览：概览数据能够直观地反映迭代打算的需要、缺点和工作的总体实现状况； ● 迭代燃尽图：「工作项燃尽图」和「工时燃尽图」反映出迭代排期工作项的交付趋势，以及过程变化趋势； 3. 上一次复盘会的改良项列表 ...

简介：高效落地麻利开发，先从这3个要害流动着手。在麻利迭代中，尽管迭代周期比拟短，但仍然须要对迭代过程进行无效跟进。如果在输出、过程、输入环节，没有要求，每日站会（迭代跟进）将会十分低效。好的每日站会，应该这么开！ 摘要：高效落地麻利开发，先从这3个要害流动着手。在麻利迭代中，尽管迭代周期比拟短，但仍然须要对迭代过程进行无效跟进。如果在输出、过程、输入环节，没有要求，每日站会（迭代跟进）将会十分低效。好的每日站会，应该这么开！ 在上一篇文章《麻利开发落地指南之迭代排期》中，咱们曾经理解到： ● 什么是麻利开发； ● 什么是双周迭代； ● 如何高效地发展排期会； ● 如何在云效我的项目合作·Projex 中落地排期会。 接下来，咱们来具体介绍在整个迭代跟进过程：从迭代排期确定到迭代交付的过程，同样咱们还是以双周迭代为例进行讲述。 借助每日站会无效推动迭代打算迭代进行的过程中，咱们个别会采纳每日站会（一种最先被落地的实际）进行迭代的推动和跟进。为了不便大家落地，咱们将每日站会的指标、事项等细则整顿成了表格以供参考，如下表： 咱们会看到，下面表格中的输出、过程、输入环节有比拟多的要求，这是因为，如果在输出、过程、输入环节，没有要求，每日站会（迭代跟进）将会十分低效。 上面的几点，是咱们在辅导麻利开发团队时，常常遇到的一些问题，须要特地留神： ● 重点关注需要停顿：很多研发团队会重点跟进研发工作的实现状况，这容易导致需要无奈及时测试和按时公布。一个需要拆解为研发工作后，通常各方对齐接口联调后能力进行整体需要的测试和验证，此外产品经理和用户重点关注也是需要的验收和公布，这便须要研发团队在迭代跟进时从需要登程，重点关注需要的整体停顿。 ● 每日站会前更新好需要的状态：如果研发团队基于在线工具进行合作，需要内容和停顿曾经在线化，团队成员在每日站会前更新好状态，大家同步停顿时清晰明了，每日站会的发展就会比拟高效。 ● 聚焦迭代过程中问题：这个是和站会前更新需要状态要互相配合的，需要状态及时更新了，迭代停顿在需要看板上能够高深莫测，大家在每日站会时，便能够聚焦关注需要交付的阻塞、危险和问题即可。 ● 口头项要及时同步相干方：每日站会通常会有以后的问题、跟进人和跟进形式等记录，如果没有及时同步给团队，很容易脱漏，也会造成信息的不同步。所以通常将这些内容记录成口头项（蕴含事项、负责人和冀望实现工夫），并在会后及时同步给团队成员或其余相干方。 上面，咱们以云效我的项目合作·Projex为例，讲述如何借助工具高效地落地每日站会。 如何借助云效我的项目合作·Projex 高效发展每日站会一、站会前输出团队成员更新停顿：依照理论状况更新需要和工作的状态、要害工夫节点，如提测工夫、工作起止工夫等。通常在实际过程中，状态更新很容易被忘记，如果站会个别在早上进行，倡议团队成员在前一天上班前更新需要和工作的状态；站会负责人：需跟进上一次站会的问题列表。二、发展每日站会1.迭代跟进，关注每日站会“6+1” 通常咱们在每日站会时，通过看板来同步需要停顿，且会前已更新好需要状态。所以在站会时需要的停顿高深莫测，只有重点关注问题即可，如站会的 “6+1” ： ● 6 指的是：瓶颈队列、要害的缺点、重点关注的需要、妨碍和问题、到期或行将到期的需要、中断； ● 1 指的是：查看是否存在“未反映在看板上的问题”，比方产品经理长期插了一个需要却没有录入零碎。 每日站会“6+1” 确认需要曾经拆解实现个别倡议在需要排期时把需要拆解到研发工作（前端、后端和联调），但时常会呈现，需要拆解工作不到位的状况，所以站会的时候须要查看，需要是否已拆分到研发工作，以及是否已指派到具体的开发人员，如下图所示： 需要拆解到研发工作 明确需要的要害工夫点需要的要害工夫个别是指打算提测日期、打算实现工夫等，曾经和相干负责人明确定下来，并更新在需要卡片上。 明确要害工夫点 跟进团队缺点解决停顿每日站会时，在同步完需要的停顿和问题后，须要抽 1-2 分钟工夫查看一下缺点解决状况，在云效我的项目合作·Projex 的缺点治理中，能够查看到遗留缺点状况，并可依据诉求配置不同的查看视图。如下图，能够依照负责人分组进行查看缺点状况。 此外，云效我的项目合作·Projex 还提供了查看迭代缺点统计报表，在迭代概览中，能够查看以后迭代查看“缺点趋势图”和“存量缺点按成员排名”指标卡。 跟进迭代进度和偏差云效我的项目合作·Projex 的迭代概览中能够看到迭代燃尽图，以不便咱们跟进迭代的进度和偏差： ● 工作项燃尽图：依照迭代排期时的工作项数量进行燃尽（反对过滤需要、工作、缺点），如下图左侧所示，存量曲线高高飘起，阐明进度曾经重大滞后； ● 工时燃尽图：依照迭代排期时预估的工时进行燃尽，如下图右侧所示，残余工时数量往上飘，阐明排期是工作量评估有余或插入了新的需要。 站会问题口头项跟进在每日站会时，通常会有问题记录和口头项，每次站会时可由专人负责进行记录和跟进，同时也须要回顾一下上一次每日站会遗留口头项的实现状况。 三、每日站会输入● 需要更新到最新的状态 尽管每日站会前团队成员会更新好需要状态，但站会过程中，也有可能可能要更新需要和工作的状态，研发团队要保障每日站会完结时，看板上需要和工作状态肯定是最新的状态。 ● 站会口头项及时同步 把站会上发现的问题清单，包含问题、责任人和实现工夫等，会后通过邮件、沟通群等及时同步给团队成员或其余相干方。 总结回顾当初咱们理解了每日站会是迭代跟进时的无效流动，咱们须要： ● 每日站会前，更新迭代中需要的停顿状况和上一次站会口头项状况； ● 每日站会时，关注站会的“6+1”，及时跟进偏差和问题； ...

简介：最近部门在推品质标准化，通过品质标准化，推动品质内建，从而进步研发部门的交付品质，作者深度参加其中，并在推动过程中总结了一些教训以及思考，在此通过以下定义、共识、实际三个大方向和大家分享一下。 作者 | 静艺起源 | 阿里技术公众号 最近部门在推品质标准化，通过品质标准化，推动品质内建，从而进步研发部门的交付品质，我也深度参加其中，并在推动过程中总结了一些教训以及思考，在此通过以下定义、共识、实际三个大方向和大家分享一下。 一 定义1 品质标准化何为品质标准化？用个不太失当的比喻，大家都晓得工厂的流水线作业，每个地位上的人或者机器要做什么都是提前标准好、定义好的，流水线上的商品从原材料到成品通过的都是同一套流程，因而成品间的品质不会相差太远。研发流程和流水线作业有肯定的相似性。咱们心愿通过标准化各条业务线的研发流程，以做的比拟好的业务线作为规范样板间，标准出一套标准化的流程，并实用到其它业务线，从而使各条业务线都能进行高质量的交付。 2 品质内建不少研发团队的同学都认为品质都是靠测试同学去守护的，会认为产品呈现了品质问题，是测试的锅，这是对测试工作和品质保障的一种狭窄的意识。测试同学是品质的守护神，可是品质不能只靠测试同学在最初一环去兜底。想要给用户交付高质量的产品和体验，必须是在研发流程各个环节都恪守品质标准，在需要评审、方案设计、开发、自测环节上的产品、开发、测试同学都要有品质意识并严格执行品质标准，这就是品质内建。 3 交付品质交付品质蕴含零碎品质和产品体验两局部。零碎品质指的是零碎的性能齐备性、零碎的稳定性和健壮性，产品体验是指客户应用此产品时是否有丝滑的体验。 二 共识要让研发流程中的各个角色都违心去践行一套对立的规范和标准，必不可少的条件是各个角色意识形态上的对立。只有团队的思维统一了，规范和标准能力被推动并落实。在推动 ICBU 跨境资金-国内结算团队标准化建设的过程中，咱们团队从上到下首先在以下观点下达成了高度对立。 1 品质不只是测进去的在知乎上看到针对“品质是被设计进去的，还是被测进去的”问题有一个探讨，感觉写的挺好的，从不同角度剖析了这个命题，我把它摘抄进去，针对“品质之道”的根源之争，大家的发言很踊跃，我摘抄了几个具备代表性的： A同学：我认为品质是设计进去的，在设计上思考的各种非性能品质数据，都会落地到代码中。设计的优化会一直的驱动零碎品质的优化。B同学：我认为品质是测试进去的，设计的货色能够防止已知的问题，但在理论测试的过程中，还是会发现其余未思考到的问题，例如兼容性问题，你能提前通过设计预防吗？所以测试发现问题，问题驱动品质晋升。C同学：听完B同学的发言，我更深信了品质是设计进去的。在一直的BUG驱动下，咱们打补丁式做进去的零碎，品质会更好吗？打补丁解一时之急，而后续系统性的设计、重构、降级，才是晋升品质的关键点。所以...D同学：如果站到产品层面，咱们会怎么去定义产品好不好？在咱们定义产品好坏的品质模型里，很可能会蕴含软件研发相干的非性能品质属性(ISO9126)，可能会包含产品舆情、竞品比照中挖掘出的货色。例如，咱们去定义一款内容举荐产品的好坏，除了“内容不反复”、“多样性”等维度外，“是否反对分享”、“是否反对点赞”也会成为品质好坏的评判规范，新性能上线、满足需要，用户就会认为产品好。咱们的认知会一直降级，“好”的规范也会有更高的要求。用户无时无刻不在应用、测试、反馈，让品质一直变好。2 既要、又要、还要、且要上述的四位同学的观点，代表了不同的品质理念和谋求： 谋而后动的观点：无论是对需要的二义性剖析、对设计中UML图的流程剖析、时序剖析、状态剖析，都是心愿可能磨刀不误砍柴工、降低成本。A同学说得对。摸索式测试的观点：无论是保障在设计变成代码的过程中是否100%的实现翻译，还是在测试的过程中受到启发认为应该写下更多的逻辑代码，都是心愿所见即所得，想人之未想。B同学说得也对。技术债的观点：无论是对前段时间的补丁代码进行重构，还是对系统进行架构的降级，还是对基建能力进行优化，都是心愿可能打好底盘，走的更远，走得更稳。C同学靠谱。继续改良的观点：无论是做竞品剖析、舆情剖析、线上被动检测、监控、产品质量模型等事件，都心愿可能在已有认知和未有认知里发现问题、发现有余。D同学思维广。既然大家都说得对，都代表了一种优良的品质理念，那么就不须要取舍了，既要、又要、还要、且要。 所以咱们最初的论断就成了： “品质既是设计进去的，也是测试进去的，还是被逼出来的”，但品质肯定不只是测进去的，品质保障不只是测试一种角色的责任，是贯通研发流程各个角色独特的责任。 3 缺点发现的工夫越早，老本越低毫无疑问，缺点被越早的发现，修复的老本就越低。在需要评审阶段就发现需要上的不合理，在技术设计阶段就发现技术计划的问题所在，在测试验证阶段发现零碎的bug和产品bug，修复这些环节发现的问题的老本逐步升高，但如果问题对客后才被发现，修复的老本将是微小的，可能会影响客户体验和满意度，或造成资损，甚至导致公司声誉受损。 4 测试策略实质上是在品质老本和品质危险之间获得均衡的一种办法咱们晓得，程序的执行场景和场景中波及的数据输出都是无奈穷举的，因而测试是不能被穷举的。所以咱们须要进行测试计划的设计，通过使用黑盒测试用例设计的等价类、边界值法等，白盒测试用例设计的条件笼罩法、门路笼罩法等从有限的测试数据中选出无效的测试数据，在无限的测试工夫内进行无效的测试。 5 开发自测是根本要求和根本素养咱们始终在强调开发自测，无论需要是否有测试接手，开发都必须要盲目地实现自测。作为一名合格的开发，自身就要对本人交付的代码有充沛的质量保证，这应该是自上而下地在团队里须要贯彻的思维和共识。 三 实际ICBU 跨境资金-国内结算团队是 ICBU 品质标准化实际的样板间，咱们团队在研发流程各个环节都有严格的品质标准。国内结算团队承接的业务多且简单，特地是波及到资金的需要交付，咱们都是十分审慎的。在国内结算团队，一个需要从提出到上线，对于测试接手类的重要需要须要经验如下环节： 需要评审->资源投入评估->技术方案设计评审->开发&联调&自测->测试计划评审 -> 性能预演->测试->公布打算评审-> 灰度-> 全量 对于自测类需要，须要经验如下环节： 需要评审->资源投入评估->技术方案设计评审->开发&联调>自测-> 灰度-> 全量 上面将论述这些环节的标准以及掂量每个环节做得好不好的指标。 1 需要阶段在需要阶段咱们常遇到的问题是，在我的项目开发过程中，才发现存在未评估到的需要点，如果要实现这些未评估到的需要点，可能会导致我的项目延期，也无疑会减轻我的项目组成员的压力。为了解决这个问题，咱们提出了以下应答机制和标准： 1、我的项目开发过程中，发现存在未评估到的需要点，如果不影响到主流程，通过走变更的形式解决。 责任人： 辨认变更：模块 owner or 模块开发操作变更：PM & PD 2、大型项目进入开发前，须要再评审一遍细的PRD，如果有UED 变更，须要先筹备好设计稿再组织PRD评审； 责任人：PD（组织）、PM（监督&协调） 2 资源投入评估需要评审完结后，开发和测试同学须要评估投入的开发资源和测试资源，需要PM会拉通各方定下排期，次要包含联调工夫、提测工夫和公布上线工夫，各个节点的工夫一旦确定，PM和 TPM将会严格依照这个工夫点来推动，个别是不容许延期交付的，除非有非凡起因，比方其它紧急需要长期插入等。 在资源投入评估中，除了定下排期，测试还会评估该需要是开发自测还是测试染指，会有一套评估机制。在国内结算团队，开发测试比是9:1，这意味着测试不可能接手每一个需要，对于一些评估进去没有资金危险、不对客的页面需要，会要求开发自测。 总的来说这一环节，最重要的标准是： 1、拉通各方资源，协调排期责任人：PM 2、确定联调工夫、提测工夫、公布上线工夫，接下来PM和TPM 会严格依照这三个节点推动我的项目责任人：PM 和 TPM ...

简介：作为我的项目负责人，咱们如何及时获悉以后我的项目的最新进展和问题，理解我的项目的整体情况？作为项目管理人员，咱们如何跟进和推动我的项目的失常进行？如何借助云效效力洞察平台 Insight，帮忙我的项目管理者及时发现问题和偏差，推动我的项目停顿、保障我的项目的迭代和高质量交付。 作为我的项目负责人，咱们如何及时获悉以后我的项目的最新进展和问题，理解我的项目的整体情况？ 作为项目管理人员，咱们如何跟进和推动我的项目的失常进行？ 带着这两个问题,咱们进入到麻利我的项目度量的场景，聊一聊如何借助云效效力洞察平台 Insight，帮忙我的项目管理者及时发现问题和偏差，推动我的项目停顿、保障我的项目的迭代和高质量交付。 在云效效力洞察 Insight 中，咱们能够从 3 个维度跟进我的项目的运作情况： 看我的项目整体情况：理解我的项目（或交付团队）的整体运作状况；看我的项目交付趋势：理解我的项目迭代交付的速率、品质和停顿；看资源投入情况：理解团队成员工作散布，保障我的项目中的重点事项的投入与交付。看我的项目整体情况在云效Insight的麻利我的项目度量的报表中，通过「我的项目停顿」和「需要/缺点现状概览」指标卡，咱们能够： 疾速洞察我的项目的整体运作情况，如停顿、偏差、危险、问题、需要/缺点停顿等；疾速获知所选时间段内需要、缺点的吞吐量和逾期情况。 图片起源：云效效力洞察Insight 咱们能够依据这些数据，及时跟进解决危险和问题，如果发现异常，可疾速采取行动。例如，当咱们看到我的项目中有缺点过多、存量危险和已超期事项，须要疾速推动我的项目的负责人去催办，疾速将缺点、危险和已超期事项解决，免得成为我的项目最终交付的卡点。 看我的项目交付趋势在云效Insight的麻利我的项目度量的报表中，通过「需要趋势」和「缺点趋势」指标卡，咱们能够： 理解我的项目的需要、缺点的新增与实现状况，把握团队的交付模式，提前辨认问题和危险；理解我的项目的需要、缺点的存量的发展趋势。图片起源：云效效力洞察Insight 在观测需要、缺点的趋势时，咱们须要重点关注： 1. 看存量趋势通过我的项目的需要、缺点的存量趋势，当存量曲线走高时，能够疾速推动重点需要和要害缺点的及时实现；当存量需要曲线走低时，须要查看需要布局状况，是否会呈现需要断档的状况产生。当存量缺点缺点逐渐或忽然走低时，须要查看需要提测的品质，是否真的是品质比拟好，还是测试不充沛导致的； 2. 看团队的交付模式如果长时间没发现缺点，而到某一段时间集中新增大量缺点，可能反映出是瀑布交付模式，须要及时进行干涉，防止集中和批量集成，缩短问题裸露的工夫，建设疾速反馈机制。 其次，咱们能够观测「需要交付速率」和「缺点修复速率」指标卡，通过这两张指标卡，咱们能够： 看到在每一个单位工夫内的需要交付、缺点修复的数量，及所选时间段内均匀单位工夫需要和缺点交付量；看到需要交付速率趋势，依据近期交付量来合理安排团队未来的交付节奏和对外的承诺。图片起源：云效效力洞察Insight 其中： 需要交付效率：横坐标为工夫，以周为单位，纵坐标是需要的数量（个），柱子高下代表一周交付需要数量的多少，柱子的色彩散布别离对应交付周期的长短散布； 注：按需要个数统计的形式，因需要大小不统一会呈现一些统计偏差，因而冀望做需要交付统计时可能将需要粒度拆分的绝对较小且平均。 缺点修复效率：横坐标为工夫，以周为单位，纵坐标是缺点的数量（个），柱子高下代表一周修复缺点数量的多少，柱子的色彩散布别离对应修复周期的长短散布。 在察看需要交付速率和缺点修复速率时，咱们须要重点关注： 1.需要交付速率的趋势查看本周内已交付的需要数量，并与历史速率的做比照，可发现差距，并及时推动打算交付但还未交付的需要； 2.需要和缺点联合理解交付关系需要的交付速率和缺点的修复速率联合起来一起看，能够帮忙咱们判断缺点修复速率与需要交付速率的关系。个别状况下，缺点数量多且修复速度越低，需要的交付速率也会比拟低。反之，缺点数量少且修复速度快，需要的交付速率就会比拟快。 最初，咱们须要察看「需要燃起图」和「缺点燃起图」指标卡，通过燃起图咱们能够： 看到我的项目（团队）一段时间内的工作成绩，理解交付的速率和残余需要/缺点量；通过两条曲线的差距和将来交叉点，可预测我的项目（需要、缺点）的实现工夫，不便对外做承诺。 图片起源：云效效力洞察Insight 其中： 需要燃起图：横坐标为工夫，纵坐标是需要的数量（个），“实现曲线”该我的项目（团队）已实现的需要数量变动，“全副曲线”该我的项目（团队）总共须要实现的需要数量变动； 缺点燃起图：横坐标为工夫，纵坐标是缺点的数量（个），“实现曲线”该我的项目（团队）已修复的缺点数量变动，“全副曲线”该我的项目（团队）总共须要修复的缺点数量变动； 曲线交叉点：依照所选时间段内的交付速率，我的项目中存量需要或缺点预计实现的工夫。 在察看需要和缺点燃起图时，咱们须要重点关注： 实现曲线的斜率：实现曲线的斜率代表团队的需要交付速率和缺点修复速率，当曲线的斜率陡升或陡降的时，须要及时关注和跟进，理解是否呈现了集中交付需要或修复缺点的状况；两曲线间的间隔：两曲线的间隔代表待实现需要和缺点的数量，也是该我的项目残余的工作量，当间隔根本变动不大时阐明需要实现或缺点修复与其新增量保持平衡，在继续交付的模式下，间隔应该尽可能的短且两条线平缓增长。两曲线的交叉点：两曲线的交叉点代表该我的项目（团队）如果依照以后的交付速率，我的项目中所有需要或缺点预计实现的工夫，当咱们晓得这个工夫时，咱们能够更不便对外做承诺。看资源投入情况在云效Insight的麻利我的项目度量的报表中，通过「成员工作量排名」和「存量缺点按成员排名」指标卡，咱们能够： 看需要、缺点和工作按人员的散布状况；看我的项目组成员所负责的缺点状况，以及不同类型的缺点的散布状况；图片起源：云效效力洞察Insight 在察看我的项目人员散布时，咱们须要重点关注： 工作量排名前三位：成员工作量排名在后面的几位，咱们须要理解成员是否工作负荷过高、并行需要是否过多等，如果有此类情况，须要及时调整成员的工作安顿；工作量排名后三位：成员工作量排名在前面的几位，咱们须要理解成员是否工作量安顿过少，或不负责以后我的项目中的工作，如果有此类情况，须要调整成员的工作安顿；缺点的排名前三位：缺点数量排名的前几位人员，须要推动其及时修复缺点，同时须要对缺点的引入起因进行剖析，防止相似的问题再次引入。整体回顾咱们能够从整体情况、交付趋势和人力投入 3 个方面来观测我的项目的情况，重点观测 5 幅图： 我的项目停顿：反馈我的项目的整体停顿，可查看我的项目的停顿和危险等；需要交付速率：反馈我的项目历史的需要交付吞吐量，可对将来的交付产能进行预测；缺点趋势图：反馈团队历史的过程品质状况，可剖析团队的交付模式和品质情况；需要燃起图：反馈我的项目交付速率，可对我的项目打算实现工夫点进行预测；成员工作量排名：反映我的项目工作量的散布状况。同时咱们还能够有更多的数据分析，比方：需要趋势、缺点修复速率、缺点燃起图、缺点按成员排名、迭代停顿概览等，这篇文章中咱们没做分享，然而也能够在云效Insight中看到。 原文链接本文为阿里云原创内容，未经容许不得转载。

Scrum根底Scrum一词来源于英式橄榄球，是争球的一种形式，Scrum框架借用这个词比喻产品开发团队是一个整体合作的团队，独特进行冲刺，达成团队指标。 Scrum 最后是为了治理和开发产品而开发的。从上世纪 90 年代初开始，Scrum 在寰球范畴内已失去了广泛应用，这是两位次要的创始人 Jeff Sutherland与Ken Schwaber。 Scrum 已被用于开发软件、硬件、嵌入式软件、交互性能网络、主动驾驶、学校、政府、 市场、治理组织经营，以及简直咱们(作为个体和群体)日常生活中所应用的所有。 Scrum 基于经验过程管制实践，或称之为经验主义。经验主义主张常识源自理论教训以及 以后已知状况下做出的决定所取得。Scrum 驳回一种迭代、增量式的办法来优化对将来的 预测和管制危险。 通明、检视和适应是经验过程管制的三大支柱，撑持起每一个经验过程的施行。 Scrum 5个价值观承诺、勇气、专一、凋谢、尊重，是Scrum的5个价值观。 Scrum 3个角色Product Owner产品负责人外围职责是为产品的胜利负责： 为产品的愿景布局负责治理并排序PBL为产品需要的ROI负责承受或回绝迭代交付成绩Scrum MasterScrum Master为Scrum的胜利施行负责： 执行Scrum框架帮团队打消阻碍爱护团队不受外界烦扰率领团队继续改良Team团队为产品性能交付负责： 小团队 5-9人跨职能、无角色自组织、自治理为迭代交付给出承诺为达成承诺能够要求任何事件 Scrum 3个工件Product Backlog产品待办列表是一份涵盖产品中已知所需每项内容的有序列表，它是产品需要变动的惟一 起源。产品负责人负责管理产品待办列表的内容、可用性和排序。 产品待办列表永远是不残缺的。最早开发的产品待办列表列举最后所知的以及了解最透彻 的需要。产品待办列表会随着产品及其应用环境的扭转而演进。产品待办列表是动静的， 须要继续更新以反映出产品须要什么来放弃其适用性、竞争力和有用。如果产品存在，产品待办列表也就同样存在。 产品待办列表列出所有的个性、性能、需要、加强和修复等对将来要公布的产品进行的改 变。产品待办列表项具备这些属性:形容、秩序、估算和价值。产品待办列表项通常包含 测试形容，将在“实现”时证实其完整性。 随着产品的应用、价值的获取和取得市场的反馈，产品待办列表会成长为更大和更详尽的 列表。因为需要永不进行扭转，所以产品待办列表就如一份活的工件。业务需要、市场形 势或者技术的变动都会引起产品待办列表的扭转。 排序越高的产品待办列表项通常比排序低的更清晰同时蕴含更多细节。依据更清晰的内容 和更详尽的细节信息就能做出更为精确的估算;同样，排序越低，则细节信息越少。产品 待办列表项中那些行将会占用开发团队下一个 Sprint 大部分工夫的项会被加以精化，因 此，任一产品待办列表项都可能在 Sprint 的工夫盒期限内适当地“实现”。这些可能被 开发团队在一个 Sprint 中“实现”的产品待办列表项称为“准备就绪”，它们将作为 Sprint 打算会议中的待选产品列表项。产品待办列表项的足够通明水平通常要通过上述的 精化流动来取得。 开发团队负责所有估算工作。产品负责人能够通过帮忙开发团队更好地了解需要，并依据 状况衡量取舍来影响他们，然而最终估算是由开发团队决定的。 Sprint BacklogSprint 待办列表是一组为以后 Sprint 选出的产品待办列表项，同时加上交付产品增量和 实现 Sprint 指标的打算。Sprint 待办列表是开发团队对于下一个产品增量所需的那些功 能以及交付那些性能到“实现”的增量中所需工作的预测。 ...

“咱们明天有个改良讨论会，但我工作还没做完。” “把回顾会议跳过，间接做需要不好吗~” “会议太多，没工夫写代码！” …… 咱们常常从开发人员那里听到这样的拥护意见，他们认为 Scrum （也包含其余的麻利框架）障碍了事件的实现。然而：Scrum （包含其余的麻利框架）是真正的问题吗？ 对 Scrum 的谬误利用，的确会解放开发人员，使他们的工作变得很苦楚。然而，如果你违心克服一些阻碍，你能够找到解脱这种悲惨情况的办法。 在这篇文章中，咱们将分享「 为什么许多开发人员感到被 Scrum （蕴含其余麻利框架）解放，本人能够做什么来扭转这样一个可怕的场面？」心愿你能从中受害。 问题从何而来？1948年，Tom Kilburn 才写出了有史以来的第一行代码。 从那时起，咱们始终在寻找从软件开发中获益的办法，现在咱们曾经获得了相当大的停顿—简直所有的事件都是以数字形式进行。 开发软件并不像建造一座桥，你不可能当时计算好所有，确定资料和所需的劳动力，创立一个我的项目，而后施行它。 土木工程是简单但可预测的，软件开发是简单且不可预测的。不少公司仍专一于用从土木工程中借用的思维形式来创立软件。开发人员是有创造力的人，他们喜爱承受问题来解决，而不是接受任务来施行。 然而，高层管理人员往往把他们看作是在墙上砌砖的建筑工人而非克服特定的挑战的有意义的修建。 当管理层对开发人员有谬误的冀望时，无论你应用什么框架，其后果都会令人丧气。但如果你有足够的勇气，你能够扭转游戏的场面。 是什么让开发者感到被解放了？很多开发者都对 Scrum （或其余麻利框架）示意恶感。 他们感觉 Scrum 障碍了他们的工作，而不是帮忙他们实现工作。这种谬误的认识往往是因为对 Scrum 的不良体验而产生的。 “我晓得的大多数问题都是因为产品治理单薄而产生的。”一位开发者说。 常常有人在没有筹备好的状况下就成了产品负责人。在没有任何产品治理技能的状况下演变成了一个产品负责人，让人误以为 Scrum 是一个专一于交付的过程而误用了这个框架。 以下这些迹象表明你正在被 Scrum （蕴含其余麻利框架）解放而非开释本人的后劲： 1.在细化会议中，有人早早定义了解决方案，开发人员被要求提供解决方案，而不是解决问题。 粗体2.机械的开始一个冲刺打算，但因为所选的工作并不互相关联，导致这个指标的设立变得毫无意义。 3.我的项目负责人过于关注我的项目进度而疏忽了团队成员的成长。每个人都在议论本人的 "Sprint "，指标各不相同。 4.经常为了实现工作而疏忽细节导致技术债权减少。产品负责人也默认承受了这一点，没有解决。 要么成为内部世界的受害者，要么成为故事的英雄，挑战现状。 开释开发者的后劲一旦你成为产品负责人，就要做好与反模式作战的筹备。想要回绝“每周工作40个小时，却看不到任何有意义的工作成绩”，上面这些态度能够帮忙到你： ▶ 专一于少而精的事件 确保开发人员能够作为一个团队工作，而不是在 Scrum 团队外部创立微型团队。如果无奈设定一个 Sprint 指标，你就会失去意义。 ▶ 充沛调研和了解指标 专一于达成指标。 即便你收到高度规范化的路线图，也要了解每个我的项目背地的指标，而不是匹配一系列的需要。不要试图用与利益相关者的其余计划来解决，用后果而不是论据来证实。 ▶ 与开发人员一起解决问题 当你意识到开发人员因为你给他们施加压力而产生技术债权时，要公开探讨并找到解决的办法。如果欠缺会议耗尽了你的精力，因为开发人员想晓得每一个小细节，这就是不足信赖的体现。可能他们胆怯失败，胆怯被追究责任。除非你能解决与开发人员的抵触，否则团队将是不失常的。 ▶ 设定指标 作为产品负责人，你必须采取推动的立场，不要被动。理解当下最要害的问题，设定一个产品指标，并确保利益相关者理解其重要性。但凡无助于实现产品指标的事件，都与当下无关。 ▶ 受权给开发人员 不要试图通过呈现在所有的每日 Scrum 上向他们施压，要求停顿，来对开发人员进行宏观治理。赋予他们做决定的权力，给他们发明的空间。 ...

心理学家诺埃尔·伯奇（Noel Burch）创立了一个学习模型，以形容人类在学习新技能时如何经验四个学习阶段。 当波及到学习新技能时，咱们会在整个学习过程中经验不同的情绪。开始的时候，咱们不能意识到学习的重要性和曾经晓得了多少。咱们往往会感到丧气，甚至当咱们意识到咱们没有足够的常识来学习这门学科时，咱们甚至会放弃。当咱们在学习过程中，如果每一步都能意识到本人的感触时，咱们就会坚持下去，同时治理和管制咱们内心深处的情绪稳定。 在这篇白皮书中，我将分享本人作为Scrum Master从信息分发者到佣人式领导者的经验。在我的职业生涯中，我采访了许多Scrum Master，并培训了1000多名业余人员。基于我的教训，联合我职业生涯中的理论案例，我想许多Scrum master可能会跳过本文所探讨的阶段。 我不心愿你们把这些阶段看成是“阶段之门”，相同，把它看作是你走向佣人式领导的阶梯。Martin M. Broadwell’s的《能力的四个阶段》在维基百科中记录如下: 有意识无能力：个体没有足够的常识来了解某些事件并意识到本人的有余。他们可能会否定这项技能的实用性。在进入下一个阶段之前，一个人必须意识到本人能力的有余和新技能的价值。一个人在这个学习阶段所花的工夫取决于学习的刺激因素。无意识无能力：只管集体不晓得如何了解某件事，但他们能够很好地意识到倒退一项新技能的重要性以及哪些方面尚不满足。在这个非凡的阶段，犯错是学习过程中不可分割的一部分。咱们的大脑当初意识到咱们正处于一个漫长的学习曲线的终点。无意识有能力：尽管集体意识到做事件，但展现技能须要集中注意力。它被分解成几个步骤，从而无意识地参加执行新技能。有意识有能力：通过一直的实际和致力，个体曾经适应了新的技能。它已成为“第二”本能，它能够天然地执行。依据学习的形式和工夫，个体有能力将技能传授给别人。这种主动响应容许集体进入一种全神贯注的、不加思索的状态，通常称为“在状态中”或“在状态流中”。 图1所示。“学习的四个阶段”(起源: 诺埃尔·伯奇 Noel Burch) 我理解到精通Scrum的阶段与学习的四个阶段之间有很好的相关性。在本文中，我试图展现Scrum Master的一些行为是如何阻止他们向佣人式领导者转变的。在这个过程中，我形容了意识咱们所处的阶段的必要性。我深信，Scrum Master们将通过洞察来扫视和调整他们的格调而从中受害。 当我回过头，看到我在2013年刚刚成为Scrum Master时的晚期经验，我很喜爱这个机会，只管对于如何成为一个无效的Scrum Master的信息很少。尽管我称本人为Scrum Master，但“称作”和“成为”之间是有显著区别的。 我是从意识和能力的四象限的角度来写这份白皮书的。它蕴含了我作为Scrum Master的个人经历以及一些我的钻研工作。在我看来，没有人会始终呆在这些象限里，也不会按程序挪动。这一策略使Scrum Master晓得有多少团队成员，掂量他们工作场合的所有变量，并抉择适宜他们指标和状况的适合的情景式领导力办法。然而，值得反思的是，你大部分工夫是在哪个象限度过的。 我用学习的四个阶段的类比来帮忙Scrum master从信息分发者转变为佣人式领导者。 范式转变咱们的世界是一个简单的世界。能够必定地说，正如Ted Bililies所说：“过来十年，常识和技术的半衰期直线降落。世界经济转向成为互相分割的纸牌屋，以及动荡的因素-经济因素卫生方面的不平等，恐怖主义的流行病–撼动了社会各阶层。” 4 Gunther Verheyen在解释Scrum方面做得很杰出。依据Gunther所说，“ Scrum是越来越多地被发现为解决简单问题的简略框架，除了软件和产品开发之外的其余状况。更多不同的人，团队和组织在Scrum旅程中寻求领导和反对，无论问题的性质。” 5 其外围是，Scrum旨在开释自组织团队的力量和智慧，这些团队负责向客户交付价值。这些团队不会神奇地呈现，而是由作为Scrum团队佣人式领导者的Scrum Masters来反对和造就的。以我的教训，成为佣人式领导的过程须要激情、贡献和承诺。这首先须要转变观念。你应该做好筹备在旅途中学习和重新学习所有内容。 如果您问我是否可能从有意识无能力过渡到有意识有能力，我的答案取决于您从谬误中吸取教训的凋谢水平，无意识地致力扩大您的技能，取得新技能并乐于承受反馈。 我并不是说每个Scrum Master都会经验这些阶段。然而，以我的教训，大多数Scrum Master都这样做。 图2. Scrum精通阶段 精通Scrum的各个阶段精通Scrum有四个阶段，而所处的不同阶段将决定您作为佣人式领导者的效力和效率。每一个阶段都可能会引领你进入到下一个阶段，每次进入新的阶段都将帮忙你变得更长于让自组织团队在一个简单的世界中更好地成长。 信息分发者 这是精通Scrum最早的阶段，被称之为“信息散发”。精通Scrum的这一阶段十分不稳固。在这个阶段，人们不晓得所需的必要技能，也不能纯熟的表演这个角色。 尤其是我的一些个人经历，帮忙我在有意识无能力的状况下指出了这一“阶段”。如您所见，我想把信息分发者放在“有意识无能力”象限下。实际上，人们可能没有意识到对团队的影响。 2012年，当我有机会在一家金融机构负责ScrumMaster时，第三方产品是从供应商那里购买的，甚至在我退出之前就曾经实现了新的团队组建。 团队成员常常在回顾中提出“咱们应该查看是否须要持续应用该产品”。另一方面，我从管理层那里失去了很多指令。 我从管理层那里取得信息，比如说: 冲刺的节奏应该是怎么的?谁来估算这个故事?每个Sprint的指标是什么?我从单方收集了很多信息，并来回传递。就像一个散发信息的ScrumMaster，我的重点是收集所有的信息，并把它们放在一个独特的中央。当我这样做时，我认为我的工作曾经实现，而不是确定工作模式，使得数据更有意义，并应用这些数据来提供检查和适应的机会，从而发明继续改善的环境。 当有人问我的时候，我只是简略地指出信息起源。换句话说，我不晓得我无能力的水平。我并没有意识到要去理解其余ScrumMaster在这个行业中所做的事件，否则我怎么可能成为一个更好的ScrumMaster呢? 侥幸的是，许多ScrumMaster仿佛都是靠本人的力量倒退到这个阶段的。然而，相当大比例的ScrumMaster都是基于这种思维模式。如果你发现成为一个无效的ScrumMaster的惟一办法是明确地向你的团队散发对于该做什么的信息，而后疏导他们去做，始终到他们真的开始做，否则你很有可能会卡在信息分发者的阶段。 当你不太可能对你的团队产生有意义的影响时，预计的我的项目时间表会面临更大的压力，这只会加剧问题。 特色： 你总是把信息传递给团队；你没有意识到要成为一个无效的Scrum Master还须要其余技能(疏导、传授、领导)；你素来没有想过把人们聚在一起来进步合作；你不晓得本人短少什么。倡议的解决方案： 加入一些正式的培训(如高级Scrum Master工作坊，譬如Scrum.org上的Professional Scrum Master (PSM))；通过自主学习和社区团聚来进步你的意识程度。预言者 俗话说:“在本人的城市里，你不可能成为预言者。”换句话说，你须要尽快后退一步，这样其他人能力后退。 依据我的教训，这是大多数ScrumMaster可能找到本人的阶段。我已经单干过的大多数ScrumMaster都是以这种思维形式运作的，可能没有意识到他们有多少工夫是不受本人管制的，这取决于外界对他们过来和以后的冀望（尤其是老板），以及Scrum Master在它们四周建设的流程关系。预言者是他人写的。我想将预言者阶段置于“无意识无能力”象限之下。 我想起一个我的伙伴做ScrumMaster的故事。他过来经常为团队解决问题，预测将来的冲刺。他这样做失去了很大的回报。事实上，他不仅因为解决了过后的问题，而且因为预感并预测了将来的趋势而受到处分，只管这些趋势并没有成为事实。 咱们称他为“预言者”。他持续预测将来，建设了很多假如来领导团队。惋惜其中一个假如是，这些团队没有足够的资源。所以他得持续致力。 几个冲刺后，团队曾经靠近交付期限，收到了新的变更申请，但客户的交付预期并没有做相应的更改。他去找老板帮忙，老板说：“搞定它。” 他不断加强与客户的沟通，并预测如果团队能在周末工作，就能实现。两天过来了，团队成员找到他说这是不可能实现的，须要大量的浸透测试，咱们这边没有浸透测试设施。当他再次向老板寻求帮忙时，老板说：“搞定它。” ...

作者： 徐子岩 Shaun Xu 研发自动化产品 PingCode Flow 曾经上线将近半年的工夫。在这期间，咱们很快乐的看到越来越多的研发团队试用、承受并喜爱上这款产品。从目前的后盾监控数据看，咱们的客户在 PingCode Flow 中共创立了将近 2500 条规定，均匀每天执行规定近 3500 次。如果咱们做一个简略的计算，假如主动执行的一条规定相当于原先 30 秒的手工操作，那么这就意味着，每天 PingCode Flow 帮客户节俭了将近 30 个小时的工作量。 随着对 PingCode Flow 的认可度逐步提高，咱们在和客户沟通的时候也发现，大家对于如何在本人的团队中创立适合的规定存在着一些艰难。尽管 PingCode Flow 内置了将近 30 个模板，涵盖了从软件开发、项目管理，到 DevOps、团队治理等诸多畛域，然而一个实在的研发团队如何应用 PingCode Flow，哪些规定适宜，以及如何调整规定的具体步骤，对于客户来说还是有一些难度。 因而，咱们心愿通过这篇文章，分享一下咱们 PingCode 研发团队本人在应用哪些规定，为什么应用，以及带来的成果和收益。心愿可能给读者提供一些思路和借鉴。 接下来，我将会分为研发治理、高效沟通、DevOps 和人员治理四个方面，介绍咱们正在应用的局部规定。 研发治理研发治理蕴含了研发团队在日常开发过程中的一些流程和要求。之前为了标准团队，咱们须要制订具体的开发手册，为新退出的员工进行培训；在日常工作中，研发组长还要随时查看并揭示团队成员恪守。除此之外，在标准和流程有更新的时候，还须要同步到手册中，培训并时刻揭示成员新的要求。所有的这些工作都极大地占用了一线管理者和团队成员的工夫和精力。接下来，我将介绍几个与研发治理相干的规定。 无人负责的工作项变为「进行中」后主动设置负责人咱们心愿在研发过程中，每一项工作都有一个明确的负责人。这样不仅可能明确责任，同时也能主观的展现出目前工作的停顿情况，成员的工作负荷以及团队的人员配置是否正当。然而，无论是因为成员的大意，还是因为我的项目紧工作重，常常会呈现工作项被设置为「进行中」了，然而并没有同时支付负责人。为此，咱们创立了这个规定。 首先，规定在工作项状态被设置为「进行中」后触发。 随后，判断当前工作项的负责人是不是处在未设置状态。 最初，将工作项的负责人设置为规定的触发者，也就是最开始变更了工作项状态的那个成员。 通过如此简略的三个步骤，咱们就完满的解决了「团队成员遗记设置负责人」这个问题。无需员工手册，也无需培训。 主动设置工作项所属迭代与上一个场景相似，在麻利开发的过程中，咱们不可避免的在进行中的迭代内长期退出一些新的用户故事或缺点。这些工作项可能是长期创立的，或者从需要池调整来的。那么在团队成员开始工作的时候，须要确保它的迭代属性被设置到以后迭代中，否则就会导致 Scrum Master 无奈精确理解以后迭代的工作内容，在 Sprint Review 会议中很有可能漏掉这个工作。 因而咱们创立了这个规定，在工作项状态被设置为「进行中」后，查看其迭代属性是否为空。 如果为空的话，就将这个工作项退出到所属我的项目的以后迭代中。 高效沟通在考查研发团队工作效率的时候，咱们往往将关注点都放在了研发流程和标准上。诚然，流程和标准是进步研发效力的次要路径，然而团队内以及团队间的沟通合作是否高效，也大大影响了研发人员的工作效率。而且，沟通的老本不仅仅体现在沟通所需的工夫自身，它还蕴含了因为沟通不及时不正确导致的期待、谬误和返工问题。而这些工夫上的耗损往往没有失去足够的器重。 PingCode 研发团队目前 8 个开发小组，组内的沟通自不必说，各个小组之间的沟通，研发团队与运维团队的沟通，以及产研与营销的线的沟通都十分的频繁。如何可能及时、疾速且正确的同步工作进度、后果，这不仅影响产研的效率，也影响着客户满意度和公司营收。 上面的几个规定就是联合咱们本身的需要，重点解决团队内以及跨团队的沟通问题。 告诉被阻塞的工作项这个规定应该是自上线以来，团队成员反馈最为有用的规定之一了。它要解决的场景非常简单。研发过程中，不可避免的有工作间的从来关系，也就是说，某些工作必须期待其它工作的实现后能力开始。具体的，能够通过 PingCode Agile 中对于工作项的「阻塞」和「被阻塞」关联关系来展。 当一个工作项状态发生变化，特地是曾经实现后，须要告诉到被阻塞的工作项负责人，让他们尽快开始后续的工作。之前咱们团队的要求是，当团队成员实现一个工作项后，要检查一下有没有被阻塞的其它工作项。如果有的话，须要告诉（口头或者发评论）到对应的负责人。然而在大家缓和工作的时候，总会无意间遗记告诉，或者漏掉了某个负责人，导致开发工夫无端被节约。开发组长和 Scrum Master 还须要定期检查跟进状态，十分费时费力。 针对这个问题，咱们创立了如下的一条规定。当工作项状态变动后，PingCode Flow 会主动查看所有被其阻塞的工作项。 ...

乏味的是，麻利教练须要可能实现许多不是教练的工作。麻利教练的基本技能之一就是懂得教练的机会，什么时候该教练，什么时候该做其它的事件。 举个例子，你可能留意到某个团队并不了解他们为什么必须把工作分解成独立的小块工作。如果你只被容许教练，你就得依照程序提出正确的问题，充斥急躁地疏导他们后退，一步一步直到他们想通，了解这样做的用意，最终找出正确的办法。这种形式须要团队的逻辑和演绎程度达到几近非人的飞跃，也须要你本人几近非人的教练技巧。更有效率的形式是跳出教练的角色，当一小会儿讲师。 教练和讲授是两种不同的“操作模式”，咱们称为教练的姿势。在本文中，咱们将探讨五种姿势，如图1所示。你须要总是分明觉知本人当下采取的教练姿势。随着状况变动的要求，你须要常常扭转姿势，不同的姿势采纳不同的伎俩。 图1：教练的姿势 教练大部分状况，你的操作模式是教练，这也是你的根本姿势。这个姿势下，你要凝听和察看团队的工作体现，挑战和询问他们的假设和现状，疏导和率领团队口头。 教练姿势很靠近咱们探讨的系统性教练。这是最为“中立”的姿势，教练自己尽量不带偏见，也不会把本人的想法去强加给团队。为了不让你教练的团队被集体想法的偏倚所影响，你应该在状况容许的条件下尽可能地放弃在教练姿势。 讲授咱们探讨过讲授姿势，这是你常常应用的姿势。与系统性教练相同，某种程度上与静止教练也不同的是，麻利教练须要可能教育和讲授。 在这个语境里，“讲授”意味着当你教练的团队不足某个畛域的常识的时候，你可能捕捉到，并且清晰地为其解释概念，答复与概念相干的问题，并且确认团队的确曾经把握了这个新常识。这并不意味着你必须筹备和举办几天兼具趣味性和知识性的课程。只管很多麻利教练也会从事麻利讲师的工作，反过来的状况也很多。然而要讲授一门几天的课程，你须要齐全不同的技能。 如前所述，你要尽快从讲授姿势退回到教练姿势。问这样的问题，“你认为这个新的常识会如何影响你将来的口头？”， 或者“有了我刚刚提供你的信息，你认为什么才是当初最佳的口头？” 能够帮忙你回到教练姿势。对你的教练对象来说，这也是一个信号，你把责任交还给她，而她须要利用脑海中的新常识，做出理智的决策。 导师这是把学识从导师传递到辅导对象的过程。应用导师姿势的情境是，辅导对象具备肯定水平的常识，然而不足该畛域的教训。传递教训能够通过探讨、讲故事，分享趣闻轶事、提忠告的形式。还能够通过亲手演示、合作或者结对工作办法，这种状况也称为学徒制。 导师姿势很容易与教练混同，可能是因为好的导师必须也是好的聆听者和好的教练。很多导师打算都蕴含职业和生存教练的层面。相似地，教练有时须要承当导师的角色。麻利教练通常须要担当高级麻利教练或者ScrumMaster的导师。 你的辅导对象可能会发现有个导师很不便，她会激励你放弃这个姿势。再次揭示，你须要尽快地回到教练姿势去。对于这种状况，你能够说“这是我想要通知你的故事。它激发了你什么样的想法？” 或者 “咱们曾经一起实现这个工作了，那么上面你本人独立实现，我来看一下。” 参谋在必要的时候向客户提出倡议，也是一名麻利教练应具备的能力。这项能力包含了给出多项可选的倡议、原创的见解和评估客户的教训。如果你对论题有本人的想法，你还须要证实你的想法并且解释你的理由。 你应该十分审慎地给出倡议，因为教练和倡议是互相抵触的流动。作为一名教练，你应该保持中立和公正，然而作为征询参谋，客户是冀望你提供意见和倡议的。你不可能同时兼顾两个角色。这就是为什么，比起倡议你最好采取另外一种姿势的起因之一。 另外一个起因是寻求倡议的人们并不总是为了寻找实在的答案。有时候人们仅仅想要发泄他们的丧气情绪，或者，他们想晓得在推动他们的议程时，是否能够利用你来反对他们。 第三个起因是，当你提出忠告或者给出倡议的时候，你必须要对你的语言负责。有时候，你在该事件上并没有发言权，或者你可能有利益冲突。有时候，简略的问题须要简单的答案来答复（或者多个简单的答案）；有时候，客户承受了你的倡议并且在没有了解其中含意的状况下便去施行了。 咱们通常会回答客户“视状况而定”，而后可能会向客户解释相干的实践（培训），并且帮忙他们找到本人的答案（教练）或者向他们提供有启发性的案例（导师）。咱们只是偶然会提供一个含糊其辞的回答（倡议），简直不会为他们做施行（征询）。 即便在向客户给出倡议的时候，你也应该让教练对象承当起责任。实现这一点的技巧之一是通过假如来造成你的倡议：“你有没有可能......”，或者提供若干选项：“另一种值得摸索的办法是......”，这向教练对象收回了一个信号，即她须要想出解决办法，因为她是最理解状况的人。这也表明了你当初退回到了教练姿势。当你把你的解决方案力推给别人时，是有危险的，即其他人并不会齐全尽心尽力的去实现计划预期想要达到的后果。 塑造楷模作为麻利教练，咱们须要始终体现出耿直。在一位麻利教练的职业生涯中，一些要害的职业支柱是通明、诚恳，致力于帮忙人们成长并且为你的客户带来最大化的利益。塑造楷模次要是对于事必躬亲麻利和精益的价值观。 麻利教练的确不能言行不一。比方，你规定会议每次都要准时开始，而后本人却早退，或者要求ScrumMaster做好工作筹备，却对本人的工作体现出毫无脉络。 塑造楷模不同于来自内部的承包服务或咨询服务。承包人或参谋是被雇佣来为客户实现一项工作。塑造楷模的不同之处在于，它是一种为组织外部的ScrumMasters提供退职培训的流动。塑造楷模也只是在无限的程度和无限的工夫内承当相应的责任，例如确保回顾会可能顺利进行或者确保团队关注由此产生的行为。 作为楷模，你能够疏导若干次的冲刺，并逐渐的将流动移交给组织外部的ScrumMaster，这简直涵盖了所有教练合同约定的范畴。这与在较量中个别不会在球场上得分的球队教练，以及不会为了委托人扭转本人的体系教练造成了显明的比照。 如果你的教练合同明确蕴含了承包服务或咨询服务，咱们能够讨论一下嵌入式领导。嵌入式麻利教练会作为团队成员或ScrumMaster，以月或年为单位周期，参加团队的全职工作，同时向团队和四周组织推动麻利实际或晋升麻利思维。只管这个主见看上去不错，能够说是出一份钱失去两份服务，它对教练自己和客户却都会有隐患，所以咱们尽量避免这种合同。 因为教练当初在团队外部了，在数月内她将失去局部可信力和影响力，同时，团队经理将开始对她进行发号施令。教练大部分的领导工作都投入到了施行所抉择的麻利办法上，教练进度比通常状况要慢。团队也容易依赖教练，因而，当教练最终来到团队时，麻利办法的推动将停滞不前。嵌入式教练对教练本身来说也是容易产生问题的。同时解决两个不同的指标很少可能带来令人满意的后果，尤其是当指标之间还存在抵触的时候。仅有这么点工夫...我应该做个回顾会还是编写更多软件？况且，集体的业余能力倒退会陷入停滞。 相比专一的麻利教练，嵌入式教练有双倍的业余内容要去学习，然而却只有更少的工夫可能利用。嵌入式教练所获取的教训会局限于特定的客户，她会吃亏在无奈与不同的客户单干所取得宽泛、广泛的知识面上。作为一名嵌入式教练，从一个角色转换到另一个角色时，明确本人的身份是很重要的。不要不停的在角色间进行切换或者在两者之间勾留，因为这只会让你四周的人感到困惑。你还须要找到适合的人来培训他，在你来到起初代替你。 作为麻利教练，当你提供倡议或者塑造楷模时，你应该始终小心不要将本人卷入内容和产品的决策中。提出新潮的产品个性或改良UI这些事是很吸引人的。请牢记，你始终致力于改良的是组织，而不是产品。 当你把本人定位在组织体系中时，你就很难放弃主观和公正。除非你碰巧是一位公认的领域专家，否则你所教练的组织很可能比你更懂他们的客户。 参考资料：The Hitchhiker’s Guide to Agile Coaching 起源：ShineScrum捷行译者：Suzzi&毛蛋申明：文章取得作者受权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。 玩乐高，学麻利，规模化麻利联合作战沙盘之「乌托邦打算」，12月25-26日登陆深圳，将“多团队麻利协同”基因内化在研发流程中，为规模化晋升研发效力保驾护航！!⛴公众号回复“乌托邦”可加入

在麻利开发的过程中，研发团队须要“小步快跑，疾速迭代，继续改良”，迭代回顾会议（Retrospective Meeting）是Scrum中最具备价值的会议之一，也是 PDCA 循环中的要害动作，帮忙团队回顾和改善开发流程，实现继续过程改良。然而在理论的麻利开发中，「迭代回顾会议」经常因为以下起因被摈弃： 主题不聚焦，难以贯彻执行回顾不讲真话，倡议不被器重氛围相似「甩锅大会」，团队成员相互指摘推诿会议干燥无聊，没有真正帮忙团队实现提效迭代之间工夫紧迫，认为回顾没有价值那么，如何做一场乏味又高效的迭代回顾会议呢？会议能够遵循这样的路线图：进步会议透明度、收集数据并剖析改良、适应并拥抱变动。 回顾会议从「通明」开始当回顾会议变成「甩锅大会」，往往是因为团队之间不够「通明」。人们有时会因为放心来自内部的指摘而暗藏本人真正的工作形式，这样的暗藏使得团队在回顾会议中难以产生无效的反思。为解决这一问题，回顾会议首先要从进步会议透明度开始。 营造有安全感的会议环境回顾会议不仅仅是让成员参加进来，更重要的是敞开心扉，没有顾虑地把问题裸露进去，以此寻找改良方法。因而在会议过程中，要防止探讨任何对于集体责任的问题。有条件的能够抉择宽敞的会议室，或筹备一些零食，营造轻松的探讨气氛，加重参会者的防范心理。 理解参会人的心态有效的「回顾会议」给人的印象往往是互相推诿责任，浪费时间，加入这样的会议不免心情沉重消极。通过「ESVP」游戏能够帮忙 Scrum Master 理解参会者的心态，同时也反映出迭代中可能存在的问题，进而渐进式地疏导团队以侧面踊跃的心态面对回顾会议。 E：Explorer（探险家）S：Shopper（购物者）V：Vacationer（度假者）P：Prisoner（囚犯） ESVP的罕用办法 不同的角色代表了不同的参会心态。探险家渴望看到每一个细节，并寻求从回顾会议中取得最大收益；购物者喜爱思考一些不同的事件，并且对一些新的见解感到称心；度假者享受回顾会议；而“囚犯”则是被困在回顾会议中，更违心去做一些其余的事件。 「ESVP」通常使用在回顾会议的开幕式。当呈现很多“囚犯”时，常见的策略是询问他们为什么感觉被困在回顾会议中，以及他们想要做什么，兴许他们想做的事件是咱们过后能做的最好的事件；而如果有很多度假者，回顾会议可能不会产生很多见解，迭代将会面临压力。 绘制迭代过程中的情绪曲线在正式地进入「剖析数据」环节之前，Scrum Master 还须要让参会者回顾迭代过程产生的事件，并以此绘制情绪曲线。 对照以后迭代的「麻利看板」和「燃尽图」等可视化视图，团队可能直观天文清迭代的要害工夫节点以及信息，并联合迭代中积淀的日志、团队文档等，追溯迭代状况。 ONES Project 燃尽图 ONES Project 麻利看板 迭代情绪曲线的横轴是时间轴，示意「迭代」的时间跨度；纵轴是情绪轴，下面的象限属于积极情绪，上面的象限属于消极情绪。 情绪曲线示意图 团队成员依据「迭代」的工夫将本人的情绪变动画成一条曲线，最初用一个词语来评估本人在整个迭代中的情绪。情绪曲线的出现后果可能是「正向」的，也可能是「负向」的，当「负向」曲线的成员居多时，咱们要进一步理解是什么起因导致，并在后续的迭代中躲避。 收集数据并改良剖析收集迭代过程中产生的各种研发数据，并通过对立的平台进行可视化的展示，是剖析改良的重要前提。 通过 ONES Performance （效力治理）主动收集研发过程中的数据，极大地节俭了项目经理的工作量，并确保了数据的客观性和可靠性。基于业余的效力度量指标体系，ONES Performance还预置了多维度的可视化报表模板，满足团队不同的剖析场景，疾速理解研发效力数据，为剖析和定位问题提供重要依据。 ONES Performance 提供业余的效力度量指标 剖析改良能够通过「帆船回顾模型」或「鱼骨图」进行： 帆船回顾模型通过「帆船回顾」来剖析迭代中的劣势、劣势和危险等，其中： 船：代表我的项目团队岛屿：代表要实现的指标太阳：代表过来做得好的中央，将来能够持续保持风和云：代表团队的劣势锚点：代表过来做的不好的中央，将来须要改良珊瑚：代表已辨认的危险，对将来会产生妨碍帆船回顾模型 当帆船回顾完结，咱们就能收集到大量反映真实情况的数据，这些数据别离位于各个代表不同意思的图形中，对于做的好的局部，团队的管理者须要给予激励，争取能做到更好，这是在理论回顾会议中容易被疏忽的局部，对于待改良的局部，通过划分优先级确定外围问题。 鱼骨图鱼骨图将因果关系可视化，帮忙团队剖析造成不利影响的多个潜在起因，实用于继续改良。在鱼骨图中，问题出在鱼的头部，而造成问题的起因就是鱼的肋骨，大骨示意的是次要起因，中骨示意子起因，通过重复问「为什么」一直向下钻取，寻找起因，解决问题。 鱼骨图 适应迭代回顾拥抱变动适应是真正麻利的外围，回顾会议的真正意义在于不断改进过程，使下一步变得更好。 回顾会议是 Scrum 团队中每个人都能够从中吸取教训的会议，它应该以一种乏味的形式进行，让每一个人都能够理解上一个 Sprint 中出了什么问题，并观赏上一个 Sprint 中的胜利。 每次回顾会议中产生的重要文档能够积淀在 ONES Wiki 中，造成团队知识库，为其余团队及后续的迭代提供教训参考，激励团队继续改良。 ONES Wiki 组织我的项目文档、治理我的项目常识 基于对企业麻利实际的深刻理解和需要剖析，ONES 提供了欠缺的麻利研发治理解决方案，打造高效的团队合作环境，帮忙企业疾速继续改良研发过程。 ONES 麻利解决方案

Scrum是麻利开发模式的一种。在Scrum模式下，团队通过一直迭代来对产品进行增量交付。一个典型的Scrum团队有5-9个成员，分3种角色，ScrumMaster协调团队的工作，为团队抉择最佳的工作模式，爱护团队缩小外界的打搅，帮忙团队解决阻塞工作进行的问题。本文次要是从Scrum4个方面来向大家展现 云效让Scrum自动化起来。 内容简介 Scrum根底框架构建基于云效的在线研发合作Scrum我的项目云效Projex Automation基本原理云效让Scrum自动化起来，疾速配置Scrum自动化场景 阐明疾速应用：Projex（新）内测申请Projex地址Product Owner Product Owner负责产品的方向，制订产品路线图和公布打算，定义产品性能优先级，为团队廓清需要。Product Owner和ScrumMaster不能是同一个人。 团队成员 团队成员不分开发和测试，是全功能型的开发实现团队，在任何产生瓶颈的中央，所有成员全力以赴解决。 一个迭代也叫一个冲刺（Sprint），个别周期长度为1-4周。在一个迭代里，成员全力交付承诺的需要。如果任何需要没有实现，则移到下一个迭代持续实现。 在一个迭代的周期内，有4个会议： 迭代布局会 迭代布局会的目标是为本迭代安顿需要，定义需要的优先级，廓清需要。迭代布局会在迭代的第一天举办，须要整个Scrum团队参加，业务方和用户代表也可能参会。在迭代布局会上，Product Owner对需要Backlog按优先级从高到低进行解说，每个需要解说结束后，现场解答团队的问题，廓清需要，而后团队一起对需要进行疾速评估。一直反复这个过程直到需要工作量达到团队在本迭代内可交付的最大值。团队随后对布局到本迭代内的需要进行调配和工作拆解。 每日站会 每日站会的目标是为了团队理解彼此的停顿和是否有阻塞工作进行的问题。每日站会从迭代的第二天开始召开，须要整个团队加入。每日站会要求尽可能简短（所以要站着开），个别不超过15分钟。如果有须要解决的问题，会后跟进，而不要在站会中解决。 迭代评审会 迭代评审会的目标是为了验收产品。迭代评审会不须要固定的工夫和地点正式召开，而是团队任何成员如果有可验收的性能，就叫上Product Owner和业务方或用户代表进行验收。 迭代回顾会 迭代回顾会的目标是对本迭代进行回顾，发现改良机会，让团队继续改良。迭代回顾会个别在迭代的最初一天召开，整个Scrum团队参加。迭代回顾会倡议应用踊跃的语言，每个成员对三个问题进行反馈，以找出改良机会： 在本迭代中，有哪些方面做得好的，团队须要持续放弃？在本迭代中，有哪些方面能够做得更好的，团队须要改良？在本迭代中，有哪些事件团队不应该再反复了？云效数字化研发：Easy Scrum - Projex Automation 因为平台受限，请大家移步，点击下方链接会以视频模式给大家解说： [[Scrum根底框架，云效让Scrum自动化起来]](https://cloud.video.taobao.co...) 云效让Scrum自动化起来，在Scrum模式下，团队通过一直迭代来对产品进行增量交付，通过以上视频的理解，置信大家对基于云效Scrum根底框架，云效Projex如何反对Scrum高效落解放我的项目成员的双手让价值主动流转起来，曾经有了一个清晰的理解，还有什么疑难，大家能够在评论区探讨交换。

摘要：在Scrum中，Sprint打算会议（简称打算会议）作为一个Sprint的开始，产品负责人（简称PO）要和开发团队一起确立本次Sprint的指标，否则开发团队可能就不晓得做什么，进而无奈发展Sprint中的流动。本文分享自华为云社区《Sprint打算会议开始了，产品负责人却没来》，作者：麻利的小智。 背景在Scrum中，Sprint打算会议（简称打算会议）作为一个Sprint的开始，产品负责人（简称PO）要和开发团队一起确立本次Sprint的指标，否则开发团队可能就不晓得做什么，进而无奈发展Sprint中的流动。 那么如果产品负责人没有加入打算议会应该怎么办呢？ 为防止造成歧义，在剖析之前须要廓清一下的是，文中所说的产品负责人，次要是指自主研发我的项目中PO或者非自主研发下的代理PO（非客户人员）。在Scrum指南中尽管没有明确指出产品负责人到应该是谁（客户or供应商），但业界比拟认同的是产品负责人是“客户的代表”这种说法，即你公司本人的人作为产品负责人，因为篇幅无限不再赘述。 问题剖析随着国内越来越多的企业开始应用Scrum做为麻利转型的办法，对于这样的企业来说，可能会对Scrum中产品负责人的职责存在肯定水平上的意识偏差。无论是从Scrum指南上来看，还是从其余参考资料（如《Scrum 精华》）中，原则上是要求产品负责人加入打算会议且准时的。可随着我的项目的发展壮大，需要剖析、干系人数量以及复杂度等都会随之增长，这也就导致了产品负责人的工作量呈几何式的增长。产品负责人没有加入打算会议可能不仅仅是主观认知上的起因也会被一些客观因素所影响。 所以一般来说，导致产品负责人没有加入打算会议的次要起因有： 1. 产品负责人没有明确其职责：次要体现在产品负责人没能分明或没有器重其在打算会议中的职责而没有加入。 2. 打算会议的召开没有固定性：次要体现在打算会议的召开的工夫不固定，存在肯定可能上和产品负责人工作打算相冲突而没有加入。 3. 打算会议的效率低、工夫长：次要体现在产品负责人的工作量多而简单的状况下，打算会议开的工夫长、效率低，导致产品负责人主观抗拒不愿加入。 4. 没有做好应答突发状况的工作：次要体现在产品负责人因市场变动、客户的要求等外界不确定性所影响等不能加入打算会议。 综上，接下来将会别离对上述剖析的4个方面给出解决措施。 解决措施产品负责人没有明确其职责Scrum Master，在日常的工作中要做好“政委”工作，将Scrum的思维浸透给Scrum团队中的每一个人。其中，就产品负责人而言，要让他分明的理解，作为产品负责人在Scrum框架中的作用和职责以及事件参加的重要水平等。对于打算会议来说，原则上是要求产品负责人加入打算会议且准时的，因为产品负责人须要和团队一起确立Sprint指标和范畴，否则可能会导致Sprint的无指标或偏离指标而没有达到预期的成果。 打算会议的召开没有固定性“没有规矩不成方圆”，首先要立规矩（打算）。如，在一个正筹备麻利转型的团队，在其启动会上（或其余践行麻利之前的流动），就要先立规矩。其中就应蕴含Sprint的周期，以及什么工夫哪些人须要加入哪些Scrum事件等。当然曾经运行了一段时间的麻利团队，也能够从新立规矩，如果没有（须要）的话。对于打算会议而言，须要固定好每一个迭代什么工夫开，开多长时间，以及加入的人员。 在日常的工作中，Scrum Master要做好“保姆”的工作，能够在行将要散会前“吼”一嗓子。但咱们倡议是以会议揭示邮件的形式，目前支流的邮件管理系统（outlook、foxmail），都能够做到“反复周期”的设置，简略又不便的揭示到Scrum团队中的成员。 上述两点，其实说白了，就是要在思维和流程上先僵化，要让每个人（Scrum 团队）都晓得在什么工夫就做什么事件，放弃团队节奏，避免出现团队中的任何人，在散会的工夫还不晓得要散会的状况。 没有做好应答突发状况的工作如果产品负责人，遇到突发状况无奈参会时，比方须要在客户现场解决相干问题。这就须要产品负责人能确保，产品代办列表中的用户故事的数量，能应答开发团队将来1到2个Sprint的工作（含优先级）。除了数量以外，还要对用户故事的品质有所要求，所谓的品质，不仅要有清晰的形容，还须要有验收规范（AC）。这样就能够很大水平上为产品负责人缺席提供了可能，因为哪怕产品负责人不在，开发团队也晓得该做什么，如何去做。当然，这里所提到的是产品负责人分身乏术的问题，如果产品负责人只是在异地，工夫上是OK的，那么就须要团队要能具备视频散会的能力和工具，那就必须要求团队提前准备了。 此外，还应该晋升开发团队的能力，就如Scrum指南所指出的，开发团队也能够实现产品负责人治理产品代办列表的工作。这就须要开发团队具备自组织的能力（对于自组织能力的建设，请注意之后咱们专家团队的FAQ），在咱们华为云DevCloud外部，其实也始终贯彻着，人人都是产品经理的理念，做到团队中的每一个人都能够成为产品负责人的backup。 还有一点须要特地留神的，也是比拟容易疏忽的——产品负责人也是人。产品负责人也会有接孩子、开家长会、度假等工作以外的事件。这也就是传说中的“周末事件”，所以在对Scrum事件的工夫安顿上，应防止在一周的完结和开始进行（星期一、星期五），以升高要害事件被日常生活中断的概率。所以很多团队会抉择星期二、三作为Sprint的开始。如果存在“周末事件”的影响（产生频率较多），那么这也就对应了一开始提到的，如果有须要就从新“立规矩”。 最初还须要思考到极其状况，就是打算会议产品经理必须加入，这往往是由将来工作调整上的突发性引起的，或其余重要价值的事项。对于这种状况，就可能不得不把会议推延到产品负责人工夫OK的时候了。如果只是提早了几个小时，那么其实影响并不大，在当天晚些工夫散会即可，而且其余会议也不受影响。可如果会议推延较多，那么很可能就是工作布局上产生微小变动，这就要视状况而定做调整，甚至勾销该Sprint。 打算会议的效率低、工夫长一般来说，打算会议可能会继续开4到8个小时。这对于产品经理来说，无疑是减轻了其工作累赘，所在肯定水平上是不违心承受这么长时间的会议的，那么就须要在会议上能晋升效率。 咱们在理论开打算会议的时候，通常将打算会议分为上下半场。大抵（不同团队可能有所不同）如下： 这里能够清晰的看到，一个打算会议被分为产品负责人和团队一起加入的，以及开发团队本人加入的两个“会议”。所以实际上产品负责人不必参加残缺的打算会议，这就给产品负责人在会议上节俭了工夫。在这一过程中Scrum Master要能掌控好，防止产品负责人参加到了细节和技术实现上的探讨中。 这里还须要提到的是，打算会议的一个重要输出项，一个有优先级并且适合颗粒度大小用户故事的待办工作列表，而且其中需要细节曾经在梳理会上就被开发团队所通晓了。这也要求了产品负责任人要器重用户故事的品质，这实际上也是在帮忙本人加重沟通上的累赘，晋升效率。更多对于用户故事的编写请参考《“ 用户故事等于需要阐明 ”—— 你肯定没有写好用户故事》 。 对于只加入半场会议的产品负责人，如果整个流程上管制的好，那么其后果，就是能够晋升产品负责人加入会议的可能性和志愿性的。当然，这个上下半场也不是齐全相对没问题的，如在下半场开发团队发现Sprint指标可能会有些变动，那么能够再和产品负责人做轻量级的对其和调整，个别问题不大。 总结以上对于产品负责人没有加入打算会议的剖析，是依据常见的状况所阐述的，但必定不仅于此，因为真正的理论状况永远是变幻莫测的，咱们须要始终围绕着麻利的核心思想发展流动和解决解决问题，在践行的过程中，采取是“先僵化、后优化、再固化”的方针，不断完善和改良咱们的流程和思维，进而晋升效力和竞争力。 参考资料《Scrum 指南》 《Scrum 精华》 点击关注，第一工夫理解华为云陈腐技术~

写在后面本文翻译自《The 8 Stances of a Scrum Master v2\_0》，英文原文地址：https://scrumorg-website-prod...；对于原文中的一些专有词汇，我在译文中都是以“中文（English）”的款式把英文词汇也显示进去了，不便大家对照了解；译文中波及到麻利开发的价值观、准则的局部，我间接应用了官网的中文版翻译（价值观：http://agilemanifesto.org/iso...，准则：http://agilemanifesto.org/iso...）；译文中波及Scrum指南的局部，我间接应用了Scrum指南官网的中文版翻译（https://www.scrumguides.org/d...）；译文中的一些词汇，为了放弃浏览体验的一致性，我都尽量保留了麻利价值观、准则和Scrum指南中的翻译，比方“Servant Leader”，因为Scrum指南中的翻译是“服务型领导”，所以我也沿用了这个称说，然而我认为译为“佣人式领导”也是能够的。以下是译文： 一、Scrum Master的8种立场Scrum指南中对Scrum Master的定义为： Scrum Master 负责依据 Scrum 指南中的定义来促成和反对 Scrum。Scrum Master 通过帮忙每个人了解 Scrum 实践、实际、规定和价值来做到这一点。 Scrum Master 是团队的服务型领导。Scrum Master 帮忙 Scrum 团队之外的人理解他们如何与 Scrum 团队交互是无益的，通过扭转他们与 Scrum 团队的互动形式来最大化 Scrum 团队所发明的价值。 Scrum Master这个角色领有许多立场和极大的多样性。一名优良的Scrum Master会意识到这些，并能依据环境和背景，晓得在何时以及如何应用它们。所有这些立场都是为了帮忙人们了解Scrum的精力。 （Scrum Master的8种立场） Scrum Master的作用是： 服务型领导（Servant Leader），他的关注点是团队成员的需要和他们提供价值的人（客户）的需要，指标是达成合乎组织的价值观、准则和商业指标的成绩。引导者（Facilitator），搭建舞台，提供明确的界线，使团队可能单干。教练（Coach），领导集体的思维和行为，领导团队的继续改良，领导组织与Scrum团队的真正单干。管理者（Manager），负责管理阻碍、打消节约、治理过程、治理团队的衰弱、治理自组织的边界、治理文化。导师（Mentor），将麻利常识和教训传授给团队。老师（Teacher），确保Scrum和其余相干办法被了解并实际。阻碍移除者（Impediment Remover），思考到开发团队的自组织能力，解决妨碍团队提高的问题。改革推动者（Change Agent），使Scrum团队的文化可能蓬勃发展。这篇白皮书蕴含了我作为Scrum Master的集体教训。除了这些教训，我也退出了我在学习书籍、文章和视频时的发现。我还退出了对Scrum Master角色最常见的误会，以及为什么我把我的头衔从麻利教练（Agile Coach）改为了100% Scrum Master。这个变动背地的起因形容了我写这篇白皮书的动机。心愿你能喜爱这个后果！ （Scrum Master的8种立场） 二、对Scrum Master的8个误会尽管下面提到的Scrum Master的8种立场看似是常识，但它们必定不是常见的做法。很多时候，Scrum Master的角色被误会，被认为是充当： 书记员（Scribe）。在Scrum事件中做笔记。把整个Sprint打算、每日打算、需要梳理探讨和回顾会承诺都记录下来。我在一个客户那里实在地经验过这件事，他们心愿Scrum Master每周能够做四个小时的书记员。秘书（Secretary）。布局大家日程中所有的Scrum事件。负责放弃团队的日程安排与节假日和休息日的更新。Scrum警察（Scrum Police）。严格遵守Scrum的规定，而不关怀团队的现状和背景。如果你没有依照Scrum指南行事，那么你就做错了。没什么可多说的。团队老板（Team Boss）。所谓“服务型领导”，其实只是团队的老板。是决定雇佣和辞退某人的老板。是决定某人是否应该加薪的老板。管理员（Admin）。如果你须要在JIRA、TFS或任何其余工具中进行更改：Scrum Master就是你的敌人。他/她对每个工作流程都一目了然。会长（Chairman）。每天早上，团队都会向每日Scrum（Daily Scrum）的会长提供状态更新。这为Scrum Master提供了必要的信息，以便向他/她的下级写出每日状态报告（daily status report）。超级英雄（Super Hero）。这是一只鸟。是一架飞机。它是超级Scrum Master！！！在你的阻碍还没有真正成为阻碍之前，就解决了你所有的阻碍。英雄沉迷于解决“问题”的刺激中。他/她这样做不是为了团队，而是为了进步他的英雄位置。咖啡店员（Coffee Clerk）。为你的团队成员买咖啡是没有错的。这会让你很合群。但如果你每天的次要目标是为了给团队提供咖啡的话... 那你就失去了作为Scrum Master的意义。 ...

每日站会曾经成为许多团队的常见典礼，特地是在麻利软件开发中。然而，有许多奥妙的细节能够帮忙咱们辨别是在无效的散会还是在浪费时间。 具体内容站起来是为了放弃会议的简短“好”可能是什么样的？当人们试图一起工作时呈现的一系列非凡问题每日站会的模式谁来加入？咱们谈些什么？咱们按什么程序发言？何时何地？咱们如何放弃精力充沛？咱们如何造就自主性？咱们如何晓得站会停顿不佳？这真的只是每天一起站起来而已。一、站起来是为了放弃会议的简短每日站会（也称为“每日Scrum”、“每日小会”、“晚上点名”等等）形容起来很简略： 整个团队每天都会散会疾速更新状态。站起来是为了放弃会议的简短。就是这样。 但这个简短的定义并没有真正通知你通过哪些细节来辨别团队是在无效的散会还是在浪费时间。 那你怎么能晓得呢？ 对于有教训的从业者来说，当站会呈现问题时，他们会本能地晓得该如何调整来解决这个问题。 然而对于老手来说，当停顿不顺时，他们不太可能晓得该怎么做……而且更有可能的是，在没有外在帮忙的状况下，他们会罗唆齐全放弃这一实际。 如果呈现这种状况那将是很可怜的，因为运行良好的站会会给团队带来微小的价值。 为了解决这个问题，重要的是要明确每日站会罕用模式的收益和问题。这些每日站会的模式能够帮忙经验不足的从业者，也能够揭示经验丰富的从业者关注他们直觉背地的起因。 二、“好”可能是什么样的？随着音乐的想起，就像巴甫洛夫的铃声一样，团队会在没有任何额定提醒的状况下起身走到贴满卡片的看板前站好。这首特定的歌曲会在每天早上同一时间循环播放。一些人将卡片挪动到工作流的正确地位，或者在不同色彩的便当贴上贴上附加阐明。一些对我的项目感兴趣的项目组之外的人也在这里彷徨，查看工作的停顿状况。 留神到大家都在看板墙边准备就绪，团队负责人启动了团队之前购买的一个大屏计时器：他们对每日站会理论破费的工夫很感兴趣。 一个团队成员站进去议论看板最右侧最靠近部署点的卡片。他的部署脚本依然存在一些问题。另一个小组成员说她能够帮忙解决这个问题。人们依照从右到左，从上到下的程序论述每个工作项的状况，如果其他人能帮忙解决阻碍他们就会自行发言。另一边，团队负责人正在改良板上记录提出的阻碍。 有一次，大家在探讨如何解决一个特定问题时探讨的工夫略长。留神到有一个进展，团队负责人正筹备举起手指打断他们……就在这之前，其中一个团队成员倡议他们应该线下再探讨。 不久之后，所有的卡片都被笼罩到了，团队负责人问还有没有人要补充。有人提出她有一个对于新性能的乏味想法，该想法可能会使一些打算中的需要变得更好。这激发了总是试图加入站会的产品经理的趣味，他们都批准在会后持续探讨这个问题。 当团队开始进行传统的完结典礼时，大家齐喊口号：“1…2…3…精益求精！”团队负责人翻了个白眼，这不是他的主见，但他不得不抵赖，这让站会在欢快中完结。 人们扩散开并开始探讨提出的各种事件，包含阻碍、新想法以及对于某些工作项的问题。 三、当人们试图一起工作时呈现的一系列非凡问题当一群人试图作为一个团队一起工作时，每日站会是一种针对一系列特定问题的重复性解决方案。 每日站会是一种定期同步的机制，以便团队… 分享对指标的了解。即便一开始咱们就认为彼此对指标达成了统一了解（也可能了解并不统一），咱们的了解也会发生变化，同时咱们所处的环境也会发生变化。如果一个“团队”的每个成员都在为不同的指标而致力，那么这个团队往往就会很低效。协调工作。如果工作不须要协调，你就不须要一个团队。反之，如果你有一个团队，我认为工作就须要协调。团队成员之间的协调不力往往会导致蹩脚的后果。分享问题和改良。团队绝对于单独工作的次要益处之一是，当有人遇到问题或发现更好的办法时，团队成员能够互相帮助。如果一个“团队”的成员不违心分享问题和/或不违心互相帮助，那么这个团队往往也会很低效。认同为一个团队。如果你不常常与团队接触，就很难在心理上认同这个团队。即便你置信他们能力很强并有着雷同的指标，你也不会产生强烈的归属感。四、每日站会的模式每日站会的模式通过答复以下问题来给出： 谁来加入？咱们谈些什么？咱们按什么程序发言？何时何地散会？咱们如何放弃精力充沛？咱们如何造就自主性？五、谁来加入？5.1 全体人员以下人员和代表都可缺席：其余畛域（如市场、生产反对、高管、培训师等）的人、心愿理解我的项目状态和停顿的人、在必要时能够奉献出本人一份力量的人。在多个会议和报告中传播我的项目状态须要大量的反复工作。 因而 用每日站会来取代局部或全副会议和报告。任何直接参与或想理解我的项目日常运作的人都应该加入这惟一报告我的项目状态的会议。 然而 如果有人之前没有加入过每日站会，他们可能不晓得会议的流程，他们可能会做出一些扰乱站会秩序的行为。这能够通过提前告知新参与者和观察员预期的行为规范来解决。 并非所有模式的报告内容都会（也不应该）被站会所涵盖。例如，我的项目的整体停顿能够通过一个大型可视化图表[1]进行沟通，这个图表能够是燃尽图[1]、燃起图、累积流图等等。 5.2 工作项也要缺席也被称为：以故事为核心的站会 如果故事对我的项目至关重要，它们就应该在站会上发言。 ——Brian Marick, Latour 3: Anthrax and standups[2] 人们有时会适度专一于跑者，而疏忽了指挥棒。也就是说，每个人都很忙，但工作项却没有获得应有的停顿。 因而 与其把每日站会视为是人的典礼，不如把它视为是工作项（例如，麻利开发中罕用的用户故事）的典礼，人们参会只是为了替工作项发言……因为很显然工作项是不会谈话的。 昨天-明天-阻碍的问题依然能够应用，但会从工作项而不是人的视角来应用。这也意味着可能并不是每个人都会发言，咱们没有任务说任何与工作进展无关的事。 因为有了更清晰的焦点，人们才更有可能在没有提醒的状况下提出阻碍，并注销和解决阻碍。 然而 不要求所有人都发言可能会覆盖那些害羞或不违心谈话的人的问题[3]。这在以工作项为重心的状况下更难发现。 六、咱们谈些什么？6.1 昨天-明天-阻碍也被称为：三个问题 有些人很健谈，并且偏向于在讲故事的时候发散很多货色。还有些人在听到一个问题后就想立刻解决这些问题。工夫过长的会议往往会导致大家注意力不集中，与长时间探讨没有间接关系的参与者往往就会分心。 因而 能够用以下的格局来组织每日站会： 我昨天实现了什么？我明天要做什么？哪些阻碍妨碍了我的停顿？这些是满足每日站会指标的最小子集的问题。其余的探讨话题（如探讨设计、闲聊等）应该推延到会议完结后进行。 Olve Maudal倡议，这些问题的程序应该倒过去，以突出问题的重要性： 哪些阻碍妨碍了你的停顿？你明天在做什么？从昨天开始你实现了什么？——Olve Maudal，每日站会-兴许第三个问题应该先说？[4] Lasse Koskela以另一种模式提出了这些问题，他强调团队成员不应该向领导汇报： 每个团队成员顺次向他的队友提供3条信息： 自昨天会议以来我所做的事件我明天要实现的事件我须要他人帮忙解决的阻碍——Lasse Koskela，对于Scrum和三个问题的咒骂[5] Jonathan Rasmussen提供了不同的措辞，以扭转站会的态势： 你昨天为扭转世界做了些什么？你明天打算如何将其实现？你打算如何革除那些挡在后退路线上的阻碍？答复这类问题会齐全扭转站会的态势。以前你只是站在那里并介绍一些近况，而当初是向全世界发表你的用意。 ——Jonathan Rasmussen，《麻利武士》[6] 也有一些团队减少了额定的问题： Buffer增加了一个环节，人们能够分享他们正在努力提高的畛域。[7]Thomas Cagley倡议寻找危险。[8]Mark Levison发现增加更多有针对性的改良问题很有用。为了适应具体的环境，最初两个问题可能须要被批改。你昨天实现了什么？你明天承诺做什么？你的妨碍/阻碍是什么？你昨天发现了什么代码坏滋味/缺失单元测试/…？你昨天对代码做了什么改良？——Mark Levison，每日站会的变量[9] ...

《四种常见研发模式及其优缺点比照 | IDCF》 一文介绍了常见的四种研发模式，实用场景及优缺点。 笔者有幸参加由瀑布模型到麻利治理改革尝试的全过程。传统项目管理采纳PMP模式，有严格的评审和产出物流程。但麻利项目管理突破了传统模式，咱们须要同时在治理和开发思维上做出改革。本文将对麻利与Scrum的关系，Scrum的外围概念价值、落地三三五五及度量规范进行论述总结。心愿可能帮忙到学习或打算将麻利带入团队的敌人。 一、瀑布与麻利模型1.1 瀑布模型 1.2 模型 二、麻利宣言与十二准则 三、核心思想、行动指南与治理角色核心思想：关注价值、拥抱变动、疾速交付、继续改良。行动指南：产品Backlog梳理、版本布局及公布、迭代布局及执行、每日站会、迭代总结会。治理角色：麻利教练-提出问题的总结者，解决问题的合作者；帮忙团队转变思维形式和观点，让团队深刻了解麻利、实际麻利，通过现身说法，让团队学会如何利用麻利办法、实际和工具。使命：帮忙团队驾驭麻利，生产优良产品。指标：造就高效能、高产出麻利团队，让团队领有自我管理能力、自我成长能力，自行独立实际麻利。流动：察看、反馈、造就、疏导和反对。四、麻利都有哪些实际与工具采纳麻利开发的办法也有很多，次要包含极限编程（XP）、Scrum、水晶办法（Crystal Methods）、自适应软件开发（ASD）、个性驱动开发（FDD）、动静零碎开发（DSDM）、轻量级RUP、测试驱动开发（TDD）等等。而在泛滥的麻利开发方法中，尤以施行Scrum比拟风行。 五、Scrum概述与场景概述：Scrum是一套轻量级的工程实际框架，是Agile的一种，通过各种流程和技术来无效解决简单的适应性问题，并发明MVP（Minimum Viable Product）的产品历史：来自英式橄榄球静止，实质含意就是一群人你推我搡地去抢球和控球。用球赛来类比的确是一个形象又适合的比喻，在赛场上只管队员们致力依照既定打算推动，然而场上瞬息万变，不可能实时依照教练或者队长的指令亦步亦趋的去行事，只能靠平时训练中造成的素养见风使舵，达成指标。实用场景：依赖固定节奏的交付周期，称为Sprint或迭代，围绕迭代、增量的过程骨架开展的流动。 六、Scrum核心思想与精华外围思路：首先抵赖咱们的客户并不分明本人的需要，并且需要会一直变动，所以咱们默认需要是变动的，并且制订出一套策略能让整个组织依照小性能疾速开发，并且后续一直迭代。 精华： 解决客户问题，指标是让客户称心；关系：团队成员之间的关系，团队与客户之间的关系要解决好；反思：作为Scrum Master应该反诘本人和团队，当初是否帮忙客户解决了问题，咱们和客户的关系怎么样？通过一直反思问题来促成团队成长。反模式：以流程为核心：团队一起反思如何更快的进行产品交付，而不是如何制订一个完满的流程；以绩效为核心：绩效是把双刃剑，不同团队采纳不同的绩效。没有正确的绩效也没有不变的绩效。要回到Scrum精华实质，把团队聚焦在解决客户问题上来；“推动”麻利转型：Scrum的转型，须要团队、管理层、老板统一认为，咱们Scrum改革的WHY。七、Scrum落地与三三五五Scrum是一套轻量级的工程实际框架，是Agile的一种，通过各种流程和技术来无效解决简单的适应性问题，并发明MVP的产品。实用场景：依赖固定节奏的交付周期，称为Sprint或迭代，围绕迭代、增量的过程骨架开展的流动。 Scrum胜利落地的要害： 深刻学习Scrum的运行规定。全面把握Scrum的根本机制。投入足够的工夫来学习和实际Scrum。引入Scrum肯定要在新我的项目或新迭代开始的时候，而不是中途。一直继续改良Scrum过程。继续加强master 麻利治理能力及麻利文化。治理软技能。Scrum三三五五： 八、Scrum角色与职责8.1 产品负责人(PO)职责：次要负责确定产品的性能和达到要求的规范，指定软件的公布日期和交付的内容，最大化产品及开发团队工作的价值。 产品负责人是治理产品待办事项列表的惟一负责人。 产品待办列表的治理包含： 清晰表白产品待办列表条目。看待办列表排序，最好的实现目标和使命。确保研发团队对所执行工作的价值。确保产品待办列表所有人可见、通明、清晰，并且显示Scrum团队的下一步工作。确保研发团队对产品待办列表中的条目达到肯定水平的了解。扭转需要优先级，必须压服产品负责人。为保障产品负责人的工作取得成功，组织中所有人员必须尊重最终的决定，高优先级待办是惟一待开发的产品门路。 角色需具备的能力: 熟悉业务，可能让各方干系人对产品需要的意识达到共识。精确甄别用户要求，洞察其背地的用意并转化成为产品需要。具备项目管理和产品设计、布局等方面的专业技能和教训。8.2 研发团队(DT)职责：次要负责软件产品在Scrum规定流程下进行开发工作，人数管制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具备肯定的表达能力；成员能够采纳任何工作形式，只有能达到Sprint的指标。 研发团队为每个Sprint的结尾交付潜在可公布的产品增量负责。 角色需具备的能力: 期待通过晋升本人和帮忙别人，让团队成员变的更好。尊重本人和别人，认可并实际麻利价值观和麻利准则。具备凋谢共赢的心态、求真务实的风格和良好合作精力。8.3 Scrum Master(SM)职责：次要负责整个Scrum流程在我的项目中的顺利施行和进行，以及革除挡在客户和开发工作之间的沟通阻碍，使得客户能够间接驱动开发。 Scrum Master服务于Scrum团队，帮忙团队外的成员理解如何与Scrum团队交互是无益的，通过扭转交互来最大化Scrum团队发明的价值。 1）服务于产品负责人 找到无效治理产品待办事项列表的技巧。清晰地与产品负责人沟通愿景、指标和产品待办事项列表条目。疏导产品负责人创立清晰扼要的产品待办列表条目。在经验主义环境中了解长期的产品布局。了解并实际麻利。按需推动Scrum流动。2）服务于研发团队 领导研发团队自组织和跨职能。疏导研发团队发明高价值的产品。移除研发团队停顿过程的阻碍。在Scrum还未平安被驳回和了解的环境下领导研发团队。按需推动Scrum流动。3）服务于组织 领导并组织采纳Scrum。在组织范畴内打算Scrum的施行。帮忙员工及干系人了解并施行Scrum和经验性产品开发。发动晋升Scrum团队生产力的改革。与其余Scrum Master一起，帮忙组织更无效利用Scrum。角色需具备的能力: 踊跃影响别人、帮忙别人取得成功来施展个领导力。可能疾速与别人建设信赖，无效帮忙别人发现和解决问题。乐于助人，善于与别人单干，沟通能力和抗压能力都很强。九、三个工件9.1 产品待办列表(Product Backlog)产品待办事项列表是一个排序的列表,蕴含所有产品须要的货色,也是产品需要变动的惟一起源。列出了个性、性能、需要、改良等将来公布产品的扭转，蕴含形容、秩序和估算的特色。优先级越高，需要应该越清晰。 9.2 迭代列表(Sprint Backlog)一组为以后 Sprint 选出的产品代办事项列表条目,外加交付产品增量和实现 Sprint 指标的具体打算。能够在每日站会上失去出现。只有研发团队能够对Spring Backlog能够进行批改，此时能够移除局部失去开发意义的需要，减少其余优先级更高的需要。 9.3 产品增量(Product Increment)增量是一个Sprint实现的所有产品待办列表总和以前Sprint所产生的增量的价值总和。 十、五个流动 十一、Scrum治理与度量11.1 定性治理增量是一个Sprint实现的所有产品待办列表总和以前Sprint所产生的增量的价值总和。 冲刺打算 - 对冲刺期间工作范畴及工作量的具体评估；每日站会 - 团队成员共享工作进度和面临的问题。提供相干Sprint工作剩余时间的报告。放弃指标方向；Sprint总结会议 - 分享停顿顺利，体现优良的中央。停顿不佳及改良思路，能够帮忙Scrum团队和流程的继续改良；团队满意度 - 定期理解Scrum团队满意度，能够晋升麻利文化，缩小团队抵触和流程问题。11.2 定量治理燃尽图(Brundown Chart) - 比拟直观显示冲刺过程中实现了多少故事点以及还剩下多少故事点，有助于预测冲刺范畴是否会按时实现；麻利速度(Velocity Chart) - 掂量团队在过来几个Sprint中均匀实现的故事点数即产能，用于预测团队在新的Sprint中的体现。也能够用于晋升团队产能的掂量指标。但Scrum团队之间比拟不具备参考意义；累积流量图(Cumulative Flow Diagram) - 用于显示工作状态-在sprint，发行版或跨软件团队。它能够可视化流程中的瓶颈–在任何工作流程阶段中，成比例的大量工作表明存在问题。例如，在验证或测试阶段图表中的大“气泡”示意该阶段资源有余；管制图（Control Chart）、缺点数等；度量的目标是为了使Scrum团队更加聚焦交付增量指标，通过过程指标一直修改和继续改良，而非以考核和监督为目标。 ...

如果用一句话概述本篇的主题，那就是：关注8人团队的自组织性，构建百人团队的研发工作流。 Worktile是在15年的时候引入的Scrum。在那之前咱们并没有采纳规范的麻利实际框架，一是研发团队并不大，二是咱们本人的合作工具有足够的可视化能力。 但当咱们对外推出了第二款产品Lesschat（起初Worktile企业版/合作版，绿色Logo）当前，Worktile（这里指Worktile根底版，红色Logo）须要继续更新，Lesschat也须要继续更新，咱们该如何解决工作的优先级呢？ 基于理论的问题，公司决定把参加Lesschat开发的工程师独立进去，装备上独立的产品负责人，组建了一个8人的Scrum团队。咱们落地Scrum的过程大略是这样的： 第一步：Scrum团队启动会 首先，确定Terry大神为咱们的PO，确定Shaun Xu大神为咱们的Scrum Master。而后咱们独特制订了Scrum团队的工作协定： 由PO保护产品待办列表 Sprint周期为2周 Scrum各个会议的工夫、地点、内容代码提交形式故事点的规范 …… 第二步：先跑一个Sprint 咱们在第一周周一的早上10点，开打算会议。由PO进行产品解说，阐明用户故事的优先级，由开发团队预估故事规模、拆分开发工作，以及最初承诺Sprint指标。 每天早上10点，咱们在工位左近的走廊里开站立会议。每人花两分钟的工夫同步工作进展。 咱们在第二周周五下午4点，开验收会议。由开发工作的负责人演示其实现的工作，而后由PO决定未实现的工作或新增的Bug要不要放在这个版本中。 在第二周周五下午5点，开回顾会议。每个人都说一说团队做的好的和不好的中央，咱们一起确定改良计划。 第三周周二的早晨，咱们部署了第一个Sprint实现的产品增量。避开周末上线是放心除了问题没人解决，多预留两天是为改Bug。 第三步：两周一次，一直的改良 这个习惯咱们保持到当初。 和很多团队一样，咱们在晚期也遇到了很多问题，比方： 前后端共同完成的用户故事预估起来往往偏差较大挪动端小伙伴想要的API常常排不上号突发的紧急任务（来自老板）打乱Sprint的打算每天的站立会议阶段性的流于形式 ……不可胜数咱们一直的发现自己的问题，一直的改良。随着一个又一个的Sprint，们发现能够利用一些优良的工程实际晋升研发效率，比方简略设计、测试驱动开发、继续集成、继续部署等等。我总结咱们的实际如下图： 咱们在变，市场也在变，市场变了，咱们也要跟着变。大略在16年的时候，公司决定在Lesschat的根底上开发Worktile 5.0，也就是企业版，面向的是企业场景，方向转变很大，对咱们研发来说又是一次考验。 忘了用了多久实现基础架构的调整，然而肯定很快，快到我曾经忘了遇到了什么艰难。 咱们在16年年底根本实现Worktile 5.0，17年年初对外公布。 5.0上线后，Worktile提供了一种新的企业服务形式，简略概述为：Worktile平台+Worktile的各个子产品（音讯、工作、日历、网盘、审批等等）。 对于咱们研发来说，这里的挑战有两个：一是把各个子产品拆分进去，改为微服务的架构形式；二是研发团队的规模化麻利。第一个问题解决起来很简略，第二个问题的确考验了咱们。 开始的时候，咱们应答各个子产品的需要，采取的形式是打一枪换一个中央。艰深的解释就是，一个Sprint咱们投入到“日历”这个产品中，一个Sprint咱们投入到“网盘”这个产品中。 很显著，这样的形式不足以应答疾速变动的市场，因为来自“网盘”这个产品的需要往往要等好几个Sprint能力实现，对于客户来说这样的速度太慢了。 尽管从研发的角度，咱们是严格依照产品待办列表的优先级安顿Sprint工作的，然而这绝非是一个现实的安顿。另一方面，开发人数在增长，然而大家都在一个Scrum团队中，这样的团队散会效率越来越差，重大影响了开发工夫。 如何把团队级别的麻利回升到业务级别，这个问题越发重要，随着Worktile 6.0、7.0的开发，咱们缓缓的找到了感觉，下图是我总结的教训： 团队级别的麻利关注的是构建一个高效的自组织团队。这样的团队可能很好的实现开发工作，也可能利用优良的工程实际晋升自我的效率。 而业务级别的麻利更加关注的是通过规模化治理研发团队，晋升研发效力，从而继续稳固的实现业务价值。 组织级别的麻利更加关注的是通过短缺的市场调研确定方向，而后通过产品的实在数据验证方向，为下一步决策提供根据。 具体实施起来的过程是这样的： 1、市场调研和需要评估 a.调研包含但不限于：行业动态、竞品剖析、客户反馈等 b.需要评估由市场、产品、技术等相干方的负责人参加 2、业务线的麻利 按季度或月确定研发指标由技术负责人、架构师评估，由产品总负责人拆分为产品个性由产品总负责人和各个产品负责人拆分个性由技术、架构师、产品确定各个个性的规模和实现周期将拆分后的用户故事放入各个Scrum团队的PBI中，设置优先级各个Scrum团队打算各自的Sprint工作各个Scrum团队代表每周同步各自的工作进展按期进行各个模块、子产品的集成，部署到UAT环境按期实现指标 3、验证需要和后续口头 进行必要的数据收集，例如重要页面的QPS，转化率等等进行数据分析确定后续的产品改变方向随着麻利实际深刻，咱们发现研发的效力问题是个全行业的问题。同时，通过数据分析，咱们发现自家客户50%以上是研发场景，那为什么不打造一个业余的研发管理工具赋能给咱们的客户呢？ 于是18年，公司正式决定打造Worktile 8.0（Worktile研发版，现已独立品牌为PingCode），19年8.0上线。 在这个过程中，为了保障咱们的交付效率，咱们自研了一套继续交付平台，它能够为各个Scrum团队赋能，通过大量的配置化即可接入平台，轻松实现CICD。 到目前为止，咱们的麻利曾经波及100人以上，有管理层、市场人员、产品、技术、运维，甚至还有HR。 为什么我说HR也麻利呢？因为咱们的考核和升级制度，也从硬指标变为以驱动自主性为主，这不就是文化麻利的标记吗？ 2020年，为了给Worktile客户提供更好的服务，Worktile 8.0正式更名为PingCode，专一于服务研发场景的企业客户，而Worktile则持续服务于合作畛域的企业客户。 这对于咱们研发来说又是一个新的考验，然而这样的考验曾经不算什么难题了。 将来的市场还会变，然而咱们有足够的信念应答。咱们也十分欢送有研发治理需要的客户退出咱们，麻利没有起点，咱们一起成长。 Worktile—一个工具满足工作所需

本文作者：CODING - 敏杰小王子11 月 18 日晚，Scrum 框架的创始人 Jeff Sutherland 和 Ken Schwaber 联手公布了最新版 Scrum 指南。作为 Scrum 的权威定义，《Scrum Guide》曾经走过 25 个年头，在这二十多年间，Scrum 在国内也从概念布道走向了宽泛落地，接下来咱们联合 CODING 帮忙中国团队在 Scrum 转型静止中的感悟带你一起解读这份最新版的 Scrum 指南。 （文末附新版 Scrum 指南原文链接） 不变的 Scrum 经典内核在理解最新版的变动之前，咱们得先晓得不变的是什么。Scrum 的经典框架没有扭转，基于经验主义和精益思维，通过短周期的疾速试验来裸露团队面对的潜在问题，并通过一直的检视与调整来继续改良产品、团队和工作环境，从而高效并创造性地交付最高价值的产品。 三大支柱通明、检视、适应 五个价值承诺、专一、凋谢、尊重和勇气 三个角色开发人员、PO、Scrum Master 三个工件产品 Backlog、Sprint Backlog、增量 五个事件Sprint Sprint 打算会议 每日 Scrum 会议 Sprint 评审会议 Sprint 回顾会议 值得关注的变动点变动一：简化语言，扩充受众范畴“2020 版 Scrum 指南着重于打消冗余和简单的陈说，以及删除所有与 IT 工作相干的推断（例如，测试、零碎、设计、需要，等等）。” 新版 Scrum 指南面向的受众更加宽泛，不再局限于 IT 人员。依据 Digital.ai 公布的《2020 麻利状态报告》，显示在软件和 IT 以外的畛域利用麻利：经营、市场、人力资源、销售和销售经营这几个畛域加起来曾经达到 30%，基于“查看与调整，并循环”的简略办法，越来越宽泛的团队开始失去绩效晋升。 ...

摘要：近日，Scrum麻利办法框架的创始人发表了Scrum指南的2020年版本，依据官网介绍，相比2017年版本，本次扭转次要波及七个方面。接下来让咱们一一解读这些变动，谈谈我的集体想法。Scrum麻利办法框架的两位创始人Ken Schwaber和Jeff Sutherland通过直播，向大家宣告公布了Scrum指南的2020年版本。作为Scrum的创始人，Scrum指南被宽泛认可为是Scrum框架的权威定义和解释，有着极高的位置，也因而备受争议。而两位创始人可能继续聆听社区实践者们的反馈，审慎但继续地刷新Scrum指南，以响应Scrum在实际利用中所面临的问题以及实践者的困惑，这自身也是一种麻利精力的体现。 那么，咱们一起来看看这个2020年版本都有些什么变动。在scrumguides.org网站上有专门页面介绍各个版本之间的扭转，英文过硬的敌人，也能够间接关上链接浏览：https://scrumguides.org/revis...。留神，下文中，我应用了“产品列表”、“Sprint列表”等词汇，然而在2020年版本的指南中并未翻译这两个及其他一些词汇，而保留了英文原文，如Product Backlog、Sprint Backlog。为了行文不便，我仍应用中文表白。 2020年版本相比2017年版本的变动，依据官网介绍，次要波及七个方面的扭转。接下来让咱们一一解读这些变动。变动题目那个段落是官网文档中的表述，下方缩进局部的文字是我的个人见解。 变动1 ——缩小预描述性：这些年来，Scrum指南逐步变得有些过于详述。这份2020年版本旨在通过删除或软化预描述性语言的形式让Scrum回归为一个仅够（最小化但足以失效）的框架。比方，移除了每日Scrum的三个问题、软化了PBI（产品列表条目）属性的形容、软化了Sprint列表中对于回顾改良条目标形容、软化了Sprint勾销章节的内容，等等； 的确有点回归初衷的感觉，从一开始，在泛滥麻利方法论当中，Scrum就属于是最为简洁的那个，而且两位创始人在各种场合的解说也都强调具体如何操作是灵便的。而移除的这些个内容，其实都是过来这些年来大家在实践中比拟纠结的焦点。比如说每日Scrum到底要不要严格遵守三个问题的格局？公说公有理婆说婆有理，其实是针对不同成熟度的团队，保持和不保持各有利弊，但写在指南外面，不免被认为是普适性都要恪守的。 至于回顾改良条目，是因为在2017年版本外面有这么一段话：Sprint 产品待办列表将开发团队用来达成 Sprint 指标的所有工作变得清晰可见。为了确保继续改良，它至多包含一项在前次回顾会议中确定下来的高优先级的过程改良。删除这段话，对我来讲，没有什么影响，该改良的就应该落实，怎么落实最好，就是在以后Sprint列表外面以工作或故事模式来进行治理是最棘手的。但对于不那么相熟Scrum的实践者来讲，预计又要争执Sprint回顾会议上制订的改良措施如何落实了。 至于Sprint勾销，则是从原来大略20句话简化到了现在就一句话。删除的多是车轱辘话，这个改良应该没啥问题。但简化到就这么一句话这个做法，相当于进一步强化了PO对Sprint的生杀大权，或者说独裁权。三种角色的职责与势力划分是否还可能保持良好的均衡，有点难说，外国人喜爱强调分工和职责，但不太去讲如何基于不同分工角色单干的能源，要害是能动性往往却是单干可能产生成果的根底。 变动2 ——一个团队聚焦一个产品：指标是要破除在团队内还有一个独自团队的概念，这种做法会导致在PO和开发团队之间呈现“代理”或“咱们和他们”等行为。当初，就只有一个Scrum团队聚焦于同一个指标，别离承当三组不同职责：PO、SM和开发者。 不相熟的敌人可能未必能很好了解这个扭转。在以前，Scrum指南在三种角色的名称定义上有那么点不够谨严，说是有PO、SM和开发团队三种角色，而后三种角色独特形成了一个Scrum团队，相当于是说Scrum团队 = PO + SM + 开发团队，大家就会很纠结那到底是几个团队呢。 对于PO、SM可能都还好，但对于开发团队的成员来讲，他们就会很困惑，我到底属于哪个团队？说一名成员属于开发团队又属于Scrum团队，对于成员本身的身份认同和团队认同方面，是会造成十分大的困扰的。所以这次间接去掉开发团队外面的团队一词，就是对这种争议的间接回应。2017年简中版本把很多术语都翻译成了中文，尽管我集体意见是偏向于不翻译、保留原文的，而这次2020年简中版本中则少数都保留了英文原文，比方开发团队在2017年版本外面的原文是The Development Team，而在2020年版本外面改成Developers且保留了英文原文。但我还是比拟关注这个Developers的翻译的，因为通常来讲Developers都会被等同于开发人员，大家潜意识外面去了解的技能模型就是会写代码的，这就对非编码人员或非编码技能不够敌对，会影响到团队的团结气氛以及非编码人员或非编码技能的能力构建和职业倒退的。2020年版本外面并没有对Developers的具体技能模型和更具体的分工或角色进行形容，从好的角度看，是因为强调自治理，所以把决策权留给了这个Scrum团队本人去决定。但从坏的角度看，就是不负责任了，因为这就意味着要可能利用好Scrum框架，做好团队角色的分工和单干，会依赖于主导者或SM或麻利教练的教训程度，这也就难以保障Scrum落地的成果。 变动3 ——引入产品指标：2020年版本Scrum指南引入了产品指标的概念，以帮忙Scrum团队聚焦于一个更有价值的指标。每个Sprint都应该带动产品更靠近最终产品指标。 Scrum以前其实并没有太显著或者着重去强调本人是面向产品型研发这个场景的，尽管PO这个名字就曾经表明了态度，毕竟它叫产品负责人嘛，当然是围绕产品转的。在引入了产品指标这个概念之后，进一步强化了框架自身对产品型研发场景或工作场景的聚焦。Scrum是否用于我的项目研发场景，在过来那么多年，是始终有争议的。将Scrum框架跟整个我的项目研发场景对应，会感觉不适宜，因为Scrum框架定义中用产品列表去承载整体需要治理，而产品列表是凋谢、继续刷新的，而我的项目范畴则通常都是锁定的。如果用Scrum外面的Sprint去对应我的项目型研发场景下的我的项目，从资源、时限、范畴等角度看，都是一种提前锁定的模式，十分靠近，但Sprint的时长周期，又跟个别所了解的我的项目周期相去甚远，就如同大家都是猫科，但你这个小猫咪的养育办法，用去养育大老虎总感觉有些不对劲。 所以，这个变动，就要看两位创始人给Scrum设定的愿景到底是啥了。一方面是否真的想要强化面向产品型研发的场景，另一方面，第7个变动说删除IT工作化表述，但其实Product这个词也有很强的IT工作化的暗示。但我想如果要齐全去IT化，预计就是伤筋动骨，相似全身整容，比方Product这个词汇，贯通了Scrum框架的整个脉络。要剔除它，谈何容易。 变动4 ——Sprint指标、实现定义和产品指标的归宿：以前版本的Scrum指南提到了Sprint指标和实现定义，但并没有真正给它们身份。它们并非工件，但却或多或少都跟工件有关系。2020年版本不仅是减少了产品指标，还进行了更清晰的论述。三大工件现在都纳入了与之对应的“承诺”。产品列表的承诺就是产品指标；Sprint列表的承诺就是Sprint指标；增量的承诺就是实现定义（当初曾经去掉了双引号）。它们的存在就是为了让各大工件的停顿变得更清晰和更聚焦。 搞笑点说，就是以前它们都是公开恋情，名不正言不顺的。当初正式給它们证了个婚，Sprint列表跟Sprint指标结婚拉钩、增量跟实现定义结婚拉钩，而后给产品列表配了个对象叫产品指标，也结婚拉钩。其实是坏事，但另一方面来讲，也阐明Scrum框架在变得更加流程化、规范化，因为从流程定义的角度来讲，不可能只是定义过程中的动作，而不定义过程的后果或者说准出规范的。这几个承诺某种程度上就有点质量标准或者准出规范的滋味。 当然，扭转嘛，没有相对好和相对坏的。比方产品指标，2020年中文版本中搜寻能够找到22个中央，只有一个中央说了谁来制订，那就是PO负责“开发并明确地沟通Product Goal”。这必然带来问题，相当于Product Goal的定义和决策权是独裁的、不受约束的，那么如果PO以产品指标的变动为由，提出可能不那么吻合Scrum精力的要求，比方在Sprint过程中插入突发工作等要求，该如何解决、该如何解决争议呢？置信肯定会成为后续Scrum实践者们的热议焦点。 变动5 ——自治理替换自组织：以前版本Scrum指南介绍开发团队是自组织地去抉择工作对象以及工作形式。2020年版本更聚焦于Scrum团队，强调一个自治理的Scrum团队，抉择工作对象、工作形式以及工作指标。 这个其实有点懒政，从扭转的角度并未讲明确自治理和自组织之间的差异是什么，而从指南独自文档角度也没有解释分明到底自治理意味着啥，也没有讲清楚其争议解决机制是什么，毕竟这三个角色三权大力，SM作为事中人是很难以中立角色来协调化解纠纷的。而且更为蹩脚的是，在文档中，介绍变动的中央，说的是“a self-managing Scrum Team, choosing who, how, and what to work on”，而在指南注释外面则是“They are also self-managing, meaning they internally decide who does what, when, and how”，两者并不完全一致。这是会带来问题的。Scrum指南或者框架近些年的变动以及创始人们的舆论（当然我没有贴身关注他们的动向，所以或者有讲过，但我不晓得），给人的感觉是更偏向于缩小领导性质的具象化形容，而更强调文化、准则导向与问题解决思路，但在自治理团队的定义方面，如此含糊甚至呈现肯定水平的自圆其说，有点匪夷所思。 变动6 ——三个Sprint打算会议议题：2020年版本Scrum指南在“做什么”和“怎么做”根底上，减少强调了Sprint打算会议的第三个议题，也即“为什么”，直指Sprint指标。 ...

你听过柏林新建机场的故事吗？机场原定2006年开工，2007年启用，但由于机场建设过程中到处出现施工和安全问题，补东墙漏西墙，导致工期一拖再拖，预算一涨再涨，以至于2019年了还没开张，预计开业时间已经被拖到了2020年10月。 无论是建机场还是开发软件，人们往往会低估未完成的工作量。即便没有低估，也会尽可能以能安抚老板客户的方式回复，例如“我已经完成95%了”毕竟，这种粉饰太平的回答总好过“这个复杂的任务，我大概只完成了一半”、“是的，我低估了完成这项任务所需的工作量”、“老实说，我也不知道还会不会有其他不可预见的问题出现”这些回复。 虽然这种“即将完工状态”听起来很好，但它会影响整个项目状态的透明度。这也是为什么在敏捷开发—如scrum过程中，我们只会关注彻底完成的功能。完成与否只能二选一。在scrum演示会中，我们会查看每个用户故事，根据所有的验收标准和团队制定的DoD（完成的定义）进行审查。只有在所有工作完成、所有的非功能性需求（NFR）和其他部分的DoD满足的情况下，用户故事才能被认定为完成并结束开发。 在敏捷软件开发中，功能的状态是非此即彼的，即要么完成，要么未完成——不存在任何中间状态。以工作流节点、业务规则或数据变化等作为依据来拆解用户故事，并将拆解后的用户故事放到每个sprint中完成，但被定义的范围和质量必须要彻底完工。因此不要因为用户故事A已经快要完工，就让团队转而开始其他任务，与此同时在backlog中添加一个新的“完成用户故事A的收尾工作”的故事。 这就意味着我们需要知道如何处理未完成的功能。我参与过的很多团队都对此进行过很激烈的讨论。如果你只强调故事点，开发团队可能觉得遭遇了不公平待遇，因为他们已经完成了“95%的工作”（详见上文），但并没有得到应有的认可和肯定。尤其是在管理层对scrum和故事点的概念理解有偏差，仅仅通过scrum团队的开发速度来评价团队表现的情况下，针对这一问题的讨论则会愈演愈烈。 所以，到底应该怎么处理scrum中未完成的用户故事呢？ 首先，我认为：不要太在意这个问题。因为团队没能完成用户故事的情况只是个例，不会经常发生。因此，无论采取什么样的解决方案，都不应该对团队的任何指标产生重大影响。但如果团队经常出现此类问题，那么你实际上应该解决的是为何团队经常不能完工这一问题，而不是试图通过接受团队产出的半成品来妥协。 总之，不要过分在意这种特殊的情况！其次，我认为：未完成的用户故事不应该在演示会议上展示。它们应该被移到Product Backlog的顶部重新评估规划，而不是自动进入下个sprint的backlog。因此，没有故事点会为未完成的用户故事标记“完成”。在下一次规划会议前，PO（在与开发人员沟通后）决定是否需要花更多的时间在这个未完成的用户故事上。如果答案是“需要”，那么在下一次的规划会议上，这个用户故事就会被移到Sprint Backlog中，且保持原始估算值。即便开发人员自称功能已经完成了90%，我们也能根据所有的故事点预估当前sprint的开发速度。正如前面所说，未完成的用户故事应该是个例，因此从长远来看，团队的速率应该维持在平稳水平。 作者：Felix Braun 翻译/校对：Worktile 文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

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

前言软件开发行业中常用的两种方法，一种是目前非常热门的敏捷开发(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 小时。 ...

作为敏捷开发基本构成部分，每日站会往往是最容易被误解的。事实是：每日站会本身并不会让团队变得敏捷。每日站会的目的不是自吹自擂，也不是为了验证工作成果；更不是计划时间，Sprint规划会议的目的才是这个。每日站会也不是只用来讨论开发阻碍而设置的会议，因为在遇到阻碍的时候，应该第一时间寻求帮助。 本文，我们将讨论如何有效应对阻碍并提供一些来自我们自己团队的重要提示和技巧。希望能让你们团队的每日站会（以及整体敏捷项目）变得更高效。 Scrum中的每日站会是什么？在诸如美式足球和橄榄球等众多运动中，球队在每场比赛上场前都会聚在一起开个短会。这种临场短会是战略性的：它能让整个球队的成员在比赛过程中互通信息、相互协作、配合。对于研发团队来说，每日站会就像是球队的赛前短会。每日站会甚至经常被称为“每日scrum”，并通过强调“我们”这个重点，让每个成员都了解到团队的现状和进度。 换句话说，每日站会是一个由核心团队参加的日常会议，即：Product Owner、开发人员和scrum master。 每日站会的风格取决于各个团队自身的情况，因此都是独一无二的。但通常情况下每日站会要回答三个问题： 昨天做了什么工作？今天要做什么？工作中遇到了什么问题？这些问题反应了当前的进度并凸显团队遇到的阻碍。此外，让每个人分享他们为团队整体进度所做的贡献，能够强化团队成员之间的联系。每日站会强调让每个成员分享自己的成果和计划，这样做可以让每个人都因为组织的发展做出了贡献而感到兴奋。 就个人而言，在每日站会前，每个人都要知道自己要说什么。这能够确保会议的活跃氛围，让每个与会者都全神贯注。在Worktile，团队成员用看板来展示当前迭代所有的工作项，用视图筛选来过滤其他工作项，让大家能掌握项目的最新进展。 可以帮助个人充分准备每日站会的过滤功能有两个：一是“仅展示我的任务”；另外一个是“按更新时间排序”。同时使用这两个过滤功能，界面上就能够得到分配给个人的任务和最近更新的事项。 （视图设计器） （按负责人及更新时间排序的看板视图） Worktile的每日站会每日站会的形式不是一刀切的。在Worktile，每个团队都有其独特而个性化的每日站会，以确保团队每个成员参与并投入其中。形式各有不同。 下面，让我们深入了解怎么样才能成功开展高效的每日站会，分享一些我们自己的经验： 1.选择合适的时间 ——在Worktile，多数团队的每日站会在上午9点30到10点之间进行。这个时间安排让每个人都有机会在参会前了解当天的信息和更新，同时也不会要求每个参会人都起得太早。 2.确保每日站会的简短高效 ——在Worktile，团队都是以比较随意的方式完成每日的站会，以确保每个人都能够集中注意力并保证会议效率。可以让参会成员轮流计时，以确保每个人都全身心参与和聆听。将每日站会的时间限制在15分钟以内（我们一般在10分钟左右完成）。如果团队规模较小，则可以尝试在更短时间内完成每日站会。 （截图来自Worktile） 3. 使每日站会成为Sprint回顾会议的一部分 ——尽管每日站会已经成为了众多敏捷文化的一部分，但这并不意味着团队不能在回顾会议中讨论每日站会的有效性。在 Worktile ，有些团队每天开会，而有的可能选择每周开三次会。除此之外，有的团队还会定期讨论如何让每日站会更好地为团队的回顾会议做准备。如果团队没能发现每日站会的价值和益处，则需要通过讨论找出原因。然后做出改变，因为每日站会也是敏捷不可或缺的一部分！ 文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

Sprint Review不是回顾，其目标是演示这个Sprint中自己的工作成果，参会人员包括设计师、开发人员和Product Owner。在Worktile，我们尽量保持Sprint评审会的轻松随意氛围。团队成员们会聚集在桌子周围进行非正式的演示，讲述自己在本次迭代中完成的工作。在这期间团队成员可以相互提问、尝试新的功能并提供反馈。成功的分享是构建敏捷团队的重要工作。 首先，我们回顾一下为什么团队对“完成”的定义对Sprint review如此重要： 第一步：定义“完成”如果你在使用敏捷开发工具，那么你就应该清楚将任务卡从“测试中”拖到“已验收”这个操作会令你非常有成就感。这个任务卡的流转代表着一项工作终于完成了！ 在截止时间前完成工作需要合理的规划、定义清晰的“完成”和专注的执行力。虽然大多情况下，这些工作是在Sprint规划阶段要做的事，但为了确保Sprint和review能顺利进行，团队要做的远不止规划，还要形成一种清晰的交付文化以及明确“完成”的定义。 交付文化高效团队能够将清晰的流程和开发文化带到每个工作项中。你可以用下面这些问题来评估一下你的流程，确保该流程能让团队保持最佳状态： 实施前，Product Owner、设计师和研发团队对用户故事的定义是否明确？每个人是否都理解并践行团队的工程价值观和文化？关于代码审查、自动化测试和持续集成是否有明确的定义和需求来鼓励可持续的敏捷开发？团队每完成一个用户故事，是否会有很多bug？ 换句话说，“完成”是否真的意味着“完成”呢？团队的质量和完成文化应该在每个用户故事、工程工作项和bug之上。这种文化反映了团队交付软件的方式。 为每个工作项定义“完成”明确 “完成”的定义可以帮团队聚焦每个工作项的最终目标。当Product Owner在团队的backlog中添加工作时，定义验收标准是他工作流程中非常关键的一部分。用户故事的完成意味着什么？在Worktile，团队也会跟踪其他用户故事的验收标准和测试说明。这样，整个团队就能够明确掌握每个工作项的完工情况。那么什么是验收标准和测试说明呢？ 验收标准：Product Owner用于确认故事已满足其需求的指标。测试说明：来自质量支持团队的简短、有针对性的指导，可帮助开发工程师编写更好的功能代码进行自动化测试。定义明确的事项在实施过程中更容易成功。通过使用Worktile，团队可以轻松添加字段及描述，让每个任务都有清晰的定义。 第二步：庆祝团队成果Sprint review是庆祝团队和个人在迭代过程中所取得成就的好时机。所以在Worktile，我们通常在周五下午进行Sprint review。Sprint review并不是回顾的同义词，所以要确保在迭代完成之后，回顾之前举行Sprint review会议。虽然我们欢迎外部人员加入会议，但通常情况下是Product Owner、整个开发团队和Scrum master参与会议。为了取得最佳效果，建议每个迭代花费30分钟到1小时的时间。我们喜欢Sprint review，因为它可以保证团队的健康和士气。Sprint review的核心目标就是团队建设。review并不是对抗，也不是考试——而是整个团队的协作活动，让成员可以展示自己的工作，现场交流并获得反馈。如果Sprint review没能在团队中产生积极影响，原因可能是： 团队任务太多以至于迭代期间无法完成；团队深陷现存的技术债；功能开发未能确保持续性，以避免在代码库中引入新的bug；团队的开发习惯没有适时调整；Product Owner在迭代过程中更改了优先级，而开发团队则因范围的变更陷入困境；注意：团队在迭代中遇到困难是常有的事。迭代回顾会议时，团队可以花费点时间探讨一下为什么迭代过程中会发生变更，并制定计划在下一个Sprint中解决问题。 最后建议对于那些不熟悉sprint review的团队来说，它们很容易就将其并入sprint回顾会议。Sprint review是独立于sprint回顾会议之外的独立仪式。通过sprint review，我们可以花点时间享受工作成果、自由地庆祝成就。有效的sprint review可以增强团队的士气和动力。 文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

健康的Product Backlog就像一个健康的人那样：整洁有序、组织合理、公开透明。一个按照优先级顺序排好的敏捷Backlog不仅能够简化发版和迭代计划，还能够对团队计划去做的所有工作进行细致规划——包括客户根本不会关注的内部工作。尤其是当利益相关者和其他团队对团队提出额外的工作需求时，Backlog能够帮助他们设定期望指标，同时还能够使工程时间具备价值，产出实际可交付的成果。 什么是Product Backlog？Product Backlog是开发团队根据路线图及需求制定的按优先级排列的列表。其中，最重要的项目显示在Product Backlog的顶部，确保团队知道这就是要先交付的成果。因此，开发团队不是按照Product Owner规定的节奏开展工作，Product Owner也不会是开发团队完成工作的驱动者。相反，开发团队根据Product Backlog中的顺序推进工作，通过看板的持续改善或scrum的迭代来完成这些项目。 专家提示：将所有工作内容存储在同一个任务跟踪器中——不要使用多个系统来管理bug、需求和研发工作项。如果是要求开发团队完成的工作，就请将其保存在单个列表中。以两个“R”为出发点团队的路线图和需求为Product Backlog奠定了基础。路线图计划可以拆分为几个史诗（epic），每个史诗（epic）都包含几个需求和用户故事。 让我们来看看一个名为Teams in Space的虚构产品的路线图。 由于Teams in Space网站是路线图中的第一个任务，我们希望将这一任务分解为下面三个不同的开发史诗（epic）（这里以绿色、蓝色和蓝绿色显示）和每个史诗（epic）中各自不同的用户故事。 然后，Product Owner将每个用户故事的需求，整合到开发团队的单个列表中。Product Owner可以先提供单个完整的史诗（epic）（左图）。或者，如果预订折扣航班的测试对这个系统来说更为重要时，就需要来自几个史诗的用户故事（右图）。 下面是两个例子： 哪些因素可能会影响Product Owner的优先级排序？ 客户优先权紧急反馈相对实施难度工作项之间的关联关系（如：如果先做完A，B会更容易）虽然确定Product Backlog的优先级顺序是Product Owner的任务，但绝对不应该在封闭的情况下完成。实际上Product Owner会通过收集来自客户、设计人员和开发团队的意见和反馈，来优化每个人的工作量和所需交付的产品。 确保 Backlog处于健康状态Product Backlog一旦创建，非常重要的一点就是要通过定期维护来确保它能够与开发项目的整体节奏保持一致。Product Owner在每次迭代规划会议前，都应该评审backlog，以确保优先级顺序正确无误，且上一次迭代的反馈已经被整合到本次迭代中。敏捷圈通常将Product Backlog的定期审查称为“Backlog修饰”。如果Product Backlog的规模变大，Product Owner就需要按照短期和长期项目，将backlog进行分组。贴标签前，短期项目需要完善细节。这需要与设计和研发一起协作制定完整的用户故事、估算开发时间。较长期的项目不需要特别清晰具体，但最好能让开发团队做一个粗略的估计来判断项目的优先级。这里的关键词是“粗略”——也就是说团队完全理解并开始着手做长期项目后，所有的估算都有可能发生改变。Backlog作为连接Product Owner和开发团队之间的桥梁。如果是由于客户反馈、精炼估算和新需求出现等原因，Product Owner可以随时重新变更backlog的优先级。但是，一旦进入开发阶段，尽量将更改的机率降到最低，因为这样会打乱开发团队的节奏并影响工作的聚焦点、流程和士气。 专家提示：一旦backlog超出了团队的长期能力，可以尝试关闭团队几乎无法达成的任务。在团队的任务跟踪器中，用特别的表述来给这些任务做标记，如“超出范围”等，以便用于稍后研究。需要注意的非常规现象: Product Owner在项目一开始就对backlog进行了优先级排序，并且在开发人员和利益相关者提供反馈意见时也没有对其进行调整。开发团队将backlog中的事项限制为面向客户的项目。Backlog存储在本地，不经常共享，导致感兴趣的各方无法获取更新后的内容。Product Backlog如何让团队保持敏捷？经验丰富的Product Owner会严格修改其项目的Product Backlog，使其成为可靠且可共享的工作大纲。Backlog鼓励能够让项目变得更健康的讨论和决策——因为并不是每项任务都可以排在第一位。利益相关者可以质疑既定优先级，这是一个很好的做法。围绕优先事项进行讨论能够确保每个人的优先事项保持一致。这些讨论可以促进团队优先级一致性的文化，确保项目中的每个成员都有优先级一致的思维。Product Backlog同时也是迭代规划的基础。所有工作项都应包含在backlog中：用户故事、bug、设计变更、技术债、用户提出的需求、回顾中的操作项等。这样做可以确保每个迭代的每个人的工作项都包含在整个讨论中。然后，在完全知晓需要完成的所有事项的情况下，团队成员可以在迭代开始前与Product Owner一起权衡此次迭代的工作项。 专家提示：Product Owner决定了backlog中工作项的优先级，而开发团队则通过backlog来决定团队开发速度。而对于希望将工作“推”给团队的新Product Owner而言，这可能是一种难以平衡的关系。文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

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

王明兰 --原华为、微软创新与转型教练、华为云SaaS产品总监，著名精益&敏捷转型专家 VUCA最早来源于冷战时期，在现代世界意指商业世界越来越不确定性，越来越易变，越来越不可预测，我们已经进入到了VUCA时代。 我们再也不能用原来的那种传统的、计划驱动的方式来工作，因为时代的不确定性，所以大家要拥抱变化。敏捷本身也是在那样一个时代背景下，越来越发展壮大。如果倒回来很多年之前，敏捷不会发展壮大，因为我们还没有进入这样的时代。 以前，企业的生存周期比较长，但是现在企业的生存周期越来越短，从前的几十年、上百年，现在是十年，十五年。不确定性越发严重，所以企业不断的探索怎么能够让自己更加适应市场的变化，适应这个时代，这是很多企业都在尝试敏捷转型背后的驱动力。 这本书大家知道是什么吗？ TEAM OF TEAMS ，这本书是很火的畅销书，叫 赋能 。 在我们看来这本书的内容和名字，实际上讲的就是大规模组织里面怎么能够提升组织的适应能力。赋能讲的大家都知道，在伊拉克战争期间，美国军队怎么改变自己来应对恐怖组织的袭击。我总结了整个书里面介绍了美国军队做了哪几项改变： 1-从集中化军事集团变为小规模特种部队作战单元；2-高度可视化的一些战形迅速做出科学决策；3-持续的反馈和调整 这三点实际上 不仅适用于战争 ，这本书 成为畅销书并不是因为描写战争 ，而是 他在商业领域非常通用 。 我在很多公司做过敏捷咨询，发现不同的企业里对敏捷转型的迫切性是不一样的，有的企业非常迫切，有的企业还是属于无所谓，有的企业觉得想，但是又不敢。 什么样的企业会更加迫切呢？ 有这样一个调查，如果企业的经济环境越来越不确定，这种企业它对转型就更加迫切。比如通讯业：像诺基亚、诺基亚西门子这种通信行业的企业做敏捷非常早，华为虽然不怎么讲，但是在中国的民企里华为做敏捷是最早的一个，华为从08年就在做，默默无闻，因为华为不鼓励员工出来说。 此外，银行业里基本所有的国有大行都在尝试敏捷转型。为什么要转型呢？也是一样地面临业务的压力。 那到底什么样的组织才能称为一个敏捷型组织呢？ 我总结了敏捷型组织需要三力： 第一个快速的响应力；第二个强大的执行力；第三个是需要持续的创新力。 光说三力挺容易的事情，同时具备三力，具备极致的情况下的企业非常非常少。 快速的响应力 快速的响应力需要一家企业它的组织结构需要能够快速响应。 什么样的组织机构需要快速响应？如果做一件事情都要层层去审批汇报，然后到最顶层就是审批下来才能往下下达，这种企业，它的响应力一定不会快。 敏捷型的组织是什么样的？敏捷型组织倡导的是端到端的价值链的打通。 比如我我在一些银行企业里做咨询，银行里的研发团队想在手机银行里面上线一个小功能，这本身一个很简单的事情，一般来说一个团队就搞定的事情，但是他们不一样，上线一个功能需要拉通七、八个团队，七、八个团队里又跨越了三、四个部门，上线这个功能，需要两个月的时间。 如果对于一个创业公司来说，非常快就上线了，但是在银行这种组织里就做不到。做不到并不是因为人的能力差，也不是因为技术差，就是因为 组织结构太复杂。做任何一件事情，都需要跨越其他的团队，甚至是其他的部门去协同才能完成。敏捷组织需要的是把这些组织结构打通，构建为全功能的团队，让这些团队能够向一个创业型团队一样具备高速的响应力。 因此， 建设敏捷型组织的结构，就是要把组织结构扁平化，打破壁垒，让每个团队都像创业团队一样 Scrum团队本质上就是最小的敏捷型组织单元 ，Scrum团队每个成员他们构成一个团队之后，就不再依赖于其他团队，就能够交付一个端到端的，这是Scrum的本质之一。 Scrum的发明人 Jeff Sutherland 在这两年新出了一本书叫  《敏捷革命》  ，这本书出的意义就是它描述了Scrum在IT以外的行业里的应用，这点是蛮有突破性的。敏捷虽然发展这么多年，大家以为只是在软件开发领域，没有想过在软件开发以外还可以应用。但是Jeff Sutherland在这本书里介绍了他将Scrum应用在各种各样的行业，包括联合国、政府、电视台等等没有任何软件开发的工作里。 Scrum的本质并不是和软件开发相关的，它的本质前面列的《赋能》里的三点一样: 1-跨职能的团队 2-本质是小循环3-早失败 强大的执行力 执行力这个话题已经谈了很多年了，历史上敏捷跟执行力没什么关系，敏捷不要什么命令控制，好像对执行力感觉是自上而下的。 我之前也是这样想的，也是这样理解的，但是这几年我一些企业的研发以外的部门做咨询，发现这些部门的领导是非常希望有方法帮助他们来去构建执行力的，但是他们没有这样一个有效的方法。我发现敏捷其实是一个非常好的方法帮助他们打造执行力。 这个畅销书叫 《执行》 ，虽然没有提到任何敏捷的理念，但是里面讲的执行的方法，都很有敏捷的思想，这点是蛮让我吃惊的。比如讲的领导需要具备的七条基本行为: 第一、条了解企业和员工第二、坚持以事实为基础第三、确立明确目标和实现目标的先后顺序第四、跟进第五、对执行进行奖励第六、提高员工能力和素质第七、了解你自己 持续的创新力 从组织来说，最核心的就是最大的动力就是危机感，因为一个组织如果没有危机感就没有动力去创新，华为为什么有持续的创新的动力？因为它太有危机感了。 ...

什么是Sprint规划？Sprint规划是scrum中用来启动Sprint的事件。迭代规划的目标是定义Sprint可以交付的内容，以及如何完成各项工作。迭代规划需要整个scrum团队合作完成。 与体育概念中的最后冲刺不同，scrum中的‘冲刺’（sprint）要求团队一直保持极速状态以提供可工作的软件，与此同时还需要不断学习和提高。 在scrum中，Sprint是所有工作都得以完成的一段时间。只是在开始行动前，需要设置Sprint的相关条件：例如要决定时间周期的长度、Sprint目标以及从何处开始行动。Sprint规划会围绕Sprint中的应办事项和工作重点展开。如果组织得当，Sprint规划会还能够为团队营造一个充满激情和挑战并指引团队走向成功的环境。糟糕的Sprint规划可能会因为设定不切实际的目标，而导致团队的失败。 做什么——Product Owner阐述Sprint目标以及对实现目标有益的PBI。Scrum团队据此决定在即将开始的Sprint中需要做什么，以及要做哪些才能实现Sprint目标。怎样做——开发团队根据需要交付的Sprint目标来规划具体工作。经开发团队和Product Owner协商一致后，最终得到一个基于价值和工作量的Sprint计划。谁来做——Sprint规划必须要有Product Owner和开发团队的参与。Product Owner根据产品的价值取向来制定Sprint目标。而开发团队则需要弄清楚能否实现该目标。二者都必须参与，缺一不可，任何一方的缺席都将导致Sprint计划无法进行。输入——Product Backlog是Sprint计划中非常重要的一个出发点，因为它提供了可能会成为当前Sprint一部分的“基本特征”表。除此之外，团队还需要查看增量中已完成的工作，以了解进度和剩余工作量。输出——Sprint规划会议最重要的目的是让团队阐述Sprint目标，以及如何实现这个目标。这些内容将体现在Sprint的Backlog中。Sprint规划会的前期准备要举办一场精彩的Sprint规划会需要满足一些基本要求。Product Owner要做好充足的准备，结合前一次的Sprint Review会议中总结的经验教训、利益相关者的反馈以及他们对产品的愿景，奠定Sprint的基础背景。透明度方面，Product Backlog应是更新后的版本，确保清晰精准。Backlog Refinement是scrum中一个可选事件，因为有些backlog不需要进行梳理优化的。但对大多数团队而言，最好在sprint规划会前将团队聚在一起对backlog进行review并做出优化。 专家提示：周期为2周的Sprint，要在中期举行一次backlog梳理会议。跳出当前的Sprint来思考下一个对团队来说大有裨益。这样不仅能够为Sprint规划做准备，还可以为评估当前的工作提供不同的视角。限制Sprint规划的时间Sprint规划的时长应限制在每周两小时以内。所以，一个为期两周的Sprint，其规划会议将不会超过两个小时。这叫做“timeboxing”，即设定团队完成一项任务所需的最长时间，在这个前提下，进行Sprint规划。Scrum Master负责确保会议在规定时间内完成。如果团队在限定时间内达到了满意的效果，就可以认为会议顺利完成。时间限制仅强调最长时间，对最短时间没有限制。 专家提示：将Sprint目标作为Sprint规划的重点，不要将过多的精力放在Backlog的细节上。 聚焦目标而非具体的工作，才能让团队有更多的精力找到实现目标的最佳方案。聚焦结果而非具体工作在做Sprint规划时，团队很容易陷入“细节困境”，纠结于哪个任务应该先做，由谁做，以及完成这项任务需要多少时间等。对于比较复杂的工作，初期掌握的信息有限，且大部分判断都是基于假设。Scrum是一个完全根据经验的过程，这就意味着很多工作没办法提前规划，而是要通过实践来学习，然后将学习到的信息反馈到整个开发流程中。Sprint目标以一个比较高的水平对Sprint的目标进行阐述，而backlog列表也可以用结果导向的思维来编写。用户故事是一种从用户角度描述工作的非常好的方式。如下图所示，用户故事应该将焦点放在客户最终想要实现的效果的缺陷、问题和改进上，而非观察到的问题。通过在用户故事中添加清晰、可测量的结果，团队可以清楚地衡量输出结果，知道什么时候才算完成。尽可能提前了解团队聚焦的工作，这样团队中每个人在启动工作时就不至于一无所知。例如，团队可以将无法确定的事情定为需要在Sprint期间回答的问题，也好过让其保持不清不楚的状态。 专家提示：无法确定某事和让其保持不清不楚的状态是两回事。不要忽视未知事件，因为它们就是团队必须脚踏实地完成的艰苦工作。但也不要使用含糊不清的描述来掩盖或隐藏它们。相反，当你不了解某些事情时，要认清自己的无知，并将其列为需要进一步了解的工作。预估是必要的，但不代表要假装了解未知事项Sprint规划需要一定程度的预估。团队需要明确Sprint中能或者不能完成的任务，即：预估工作量和实际工作量。工作量的预估经常与承诺相混淆。预估本质上是团队根据当前掌握的知识做出的预测。衡量工作量大小的方法如故事点（story points）和T恤尺码分类法（t-shirt sizing）分别为团队提供了不同的视角来分析和看待问题。而它们并非神器，不能帮助团队在尚未掌握足够信息的前提下发现真相。因此，未知因素越多，预估的正确性就越低。良好的预估要基于相互信任的环境，在这种环境下，团队可以自由交换信息，在不断的学习和改进中对假设进行论证。如果工作完成后证明前期的预估是错误的，那么以后的预估要么变得大很多，以确保不再出错；要么花更长的时间来进行预估，以避免再次出错。 专家提示团队可以尝试用不同的预估方法，如T恤尺码分类法（t-shirt sizing）或故事点（story points）。因为不同的方法分析问题的角度不同。Sprint规划最佳实践Sprint规划期间，团队很容易陷入“细节困境”，导致他们忘了Sprint规划的重点是为接下来的Sprint制定一个“恰到好处”的计划。规划不应成为团队的负担，而应该帮团队专注于有价值的结果，并确保团队保持正常的运行轨迹。好的Sprint规划通过定义输出的结果和清晰的计划来获得成功。但也要小心过犹不及，Sprint规划中，要聚焦目标和恰到好处的Sprint Backlog，而不是面面俱到的规定Sprint中每一分钟的工作计划。接下来，就是确定Product Backlog的顺序，以便团队提前完成Sprint目标时能接着进入后续的工作中。Scrum是一个旨在解决复杂问题的流程框架，而复杂问题的解决需要一个经验积累的过程（即边做边学）。经验积累的过程很难预先计划，所以不要自欺欺人——要承认我们不可能制定完美的计划。相反，可以专注于结果并投入到实际的工作中去，哪怕我们正在尝试解决非常困难的问题，启动工作仍可以是一件易事。 文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

Sprint指Scrum团队完成一定数量工作所需的短暂、固定的周期。Sprint是Scrum和敏捷的核心，找到正确的Sprint周期将帮助您的敏捷团队交付更高质量的产品。 “在Scrum框架中，庞大且复杂的产品将被拆分成一个个小的片段，通过一系列被称为“Sprint”的迭代来完成。” Sprint使项目更易于管理，让团队更快、更频繁地交付高质量的工作，并使团队能够更灵活地适应变化。 许多人将Scrum的Sprint与敏捷软件开发联系起来，以至于不明就里的人将Scrum和敏捷当成是同一件事。但实际上，两者根本不是一回事儿。敏捷是一套开发的原则，而Scrum则是一个能够帮助你把活儿搞定的框架。 如何规划和执行Scrum Sprints？Scrum践行者们考虑十分周到。通过召开Sprint planning会议，用于规划即将开始的Sprint。Sprint Planning是一个团队协作活动，这个过程中，团队需要回答两个基本问题：本次Sprint要完成哪些工作？如何完成？ Product Owner，Scrum Master和开发团队需要协作选定每个Sprint中要做的工作项。Product Owner则需要商讨Sprint要达成的目标，以及在Sprint结束时可以确保目标实现的PBI。 然后团队需要在此基础上制定一个计划，说明他们将如何构建Backlog列表并在Sprint结束之前将其“完成”。选择工作事项以及如何完成这些工作事项的计划被称为Sprint Backlog。Sprint Planning结束时，团队已经准备好开始Sprint Backlog的工作，将Backlog列表中的工作推进到“进行中”和“已完成”。 Sprint期间，团队通过每日站会汇报工作进展。站会的目标是展示可能影响到团队顺利交付Sprint目标的阻碍或挑战。 Sprint完成之后，团队将在Sprint Review上展示他们在Sprint期间完成的工作。这也是在产品正式上线前，团队向利益相关者和团队其他成员展示工作成果的机会。 最后，以Sprint Retrospective来为整个周期画上一个圆满的句号。这也是确定团队在下一个Sprint中需要在哪些地方做出改进的机会。在此基础上，就可以着手开始下一个Sprint周期了。 要和不要即便在掌握了前述基本准则的情况下，大多数团队在刚刚开始尝试sprint实践时也会遭遇诸多困难。以下是一些建议的做法和注意事项。 推荐要做的事项： 一定要确保团队设定并真正理解了Sprint目标以及Sprint成功与否的标准。这是确保每个成员协同一致并朝着共同目标前进的关键。确保Backlog中所有的工作项按照优先级和关联关系顺序进行排列。如果管理不当，这可能会是一个极大的挑战，并且还会破坏整个过程。确保团队对速度有很好的理解，并且要体现休假和团队会议等事项。用Sprint Planning会议来充实需要完成工作的具体细节。鼓励团队成员为Sprint中的所有需求、bug和任务草拟工作任务。如团队无法判断相关性，例如来自另一个团队、设计和法律签署的工作则应该暂时搁置。*最后，一旦做出决策或计划，请确保有人在项目管理或协作工具中能获取该信息。这能够确保每个人都可以轻松地查阅相关决定及其理由。 当我们致力于成为完成前述所有“推荐要做的事项”的Scrum团队时，也要避免下面这些危险事项： 需要避免的事项： 不要一次性设计太多用户故事、高估团队速度，或在Sprint中加入无法完成的任务。尽量避免设定那些注定会导致团队失败的目标。不要忘记质量或技术债。要为像bug和工程师健康等这样的QA和非功能性工作预留缓冲时间。不要让团队对sprint中工作内容存在不清楚的地方。确保每个人都清楚地了解，不要太专注于快速推进而忘记确保每个人都朝着同一个方向前进。此外，不要承担大量未知或高风险的工作。将庞大或具有高度不确定性的用户故事进行拆解。可以大胆地将部分工作留到下一个Sprint去完成。如果听到团队成员表达的担忧，无论是关于团队速度、低确定性工作，还是他们认为超出预估的工作量，都不要忽视这些声音。解决他们提出的问题，并在必要时重新校准。文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

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

关志光--国内大型高科技企业教练负责人,敏捷研发提效和教练专家 我们现在接触的很多所谓的敏捷理念，让很多人认为这只是一个理念而已，但实际上你可以看到国内所有的敏捷流派都有来源，西方国家所有的研究都是基于科学理念的，所以如果我们对敏捷有深入认识，会知道敏捷是一种经过验证、真实有效果的一种实践。 这里有句话叫 “A mind is like a parachute.It doesn’t work if it’s not open.” 这是美国教育家讲的一句话：每个人的心里就像降落伞，如果不打开是不能工作的。 我接触敏捷很多年，最后我总结的经验是： 所有敏捷一般都跟日常经验相反 。 全球敏捷研发历史的回顾与反思很多人都知道2001年发生了一件关于敏捷的事情，美国有几位敏捷大牛在那里探讨了三天三夜，谁都说服不了谁。他们建立了一个网站把敏捷思维发上去了，之所以敏捷今天这么受欢迎，背后就是因为大家非常认可它的价值观和它的原则。 我们从这个时间轴来看，敏捷这件事情在1968年康威定律发表的那一天这个事情就发芽了。 1968年Melvin E.Conway发表了《How Do Committees Invent》 ，怎样写组织架构？怎样写代码？最核心的思想就是康威定律。 1986年哈佛商学院发表了一篇文章《新新产品开发游戏》 ，日本当时有很多领先企业，他们虽然做的是制造业，但他们的流程已经改变了，出现了迭代，这是一篇相当重要的文件。 1995年发表了Scrum框架。 1999年Kent Beck写了一本书叫《Extreme Programming Explained: Embrace Change》 ，他在项目里把经验进行了回顾总结。 2007年David J·Anderson & Rick Garber 在芝加哥发表《Lean New Product Dev Conference》 ，他提供了一些新的视角，将日本企业的精益思想进行了保留，这是Scrum方法的来源。 2008年Scrum Gathering Lyssa Adkins在芝加哥发表了Agile Coach ，要打造一个新的工具，仅仅靠流程是不够的，领导力要进行重塑，要用新的方法来引导，这是非常核心的。Agile Coach第一次发表出来，马上引起了很多新的讨论。 2011年有了产品级别敏捷/规模化敏捷/大规模Scrum/SAFe 。 2017年很多公司都在讲企业级敏捷/精益企业，重塑组织，还有小规模人在谈青色进化领导力 。 敏捷讲的是要有构建基础理论，与它对应的就是X理论，Y理论则是来自麦克格里格。 X理论对人的态度是不信任的，Y理论对人的态度是信任并促进人的改善； X理论对人的假设认为根本上是懒惰的，Y理论对人的假设是需要有所成就愿意承担责任并勤奋工作； X理论对工作的兴趣是不感兴趣的，Y理论对工作的兴趣是合适的环境下工作与游戏休闲一样有趣； X理论对努力工作的条件是要靠惩罚的压力或者靠金钱的动力，Y理论努力工作的条件是可与内心的召唤而工作。 20世纪之前对人类历史影响很大的一本书是泰勒的《科学管理》，他认为科学管理如同节省劳动的机器一样，其目的在于提高每一单位劳动的产量 。 ...

李国柱-京东精益敏捷教练 导语： 一般我们想到产品创新，会觉得这个是产品经理的事，是产品经理应该关心的，我们研发团队好像一般关注比较少。根据我自己的经验我发现在创新上面非常强的团队，通常研发团队有非常深的参与度，而且对整个创新过程的支撑是非常强。 敏捷思维在创新过程其实也能够扮演很关键的角色，接下来我结合自己的工作经历跟大家分享一下，在产品创新过程当中如何做到敏捷思想和敏捷实践起到助推产品创新的效果。 一、产品创新面临的挑战首先我们在企业里工作中会做各种各样的创新尝试，大到产品的全新业务模式的建立或者旧有业务模式的重构，小到用户体验的提升，非常非常的多。产品经理可能有一些不错的想法抛出来，我们研发团队来帮助实现，这个过程会投入到很多的人力或者很多的金钱，最后结果如何呢？相当多的结果是非常不确定，很有可能达不到我们需要的这种效果。也就是说其实是非常不确定性，有非常多的不确定性，或者是成功的机会其实并不是非常的高。 根据我自己的经验做过一些统计，互联网行业新产品成功率，我自己的经验不会超过5%。之前一家公司我参与产品的创新和孵化工作，当时有39个项目进入孵化阶段，两年以后还活着的只有3个， 这个成功率是非常低。即使是小的创新，比如说用户体验提升的工作，至少有一半以上是不成功，也就是说我们上线以后，发现用户并没有期望那样喜欢我们的产品，或者更多的用户流入。这个取决于做用户体验的目的，你是拉新还是促活，还是保证留存等等诸如此类。所以创新成功的领域非常低。 另外，我们在这个过程当中不得不依靠一些老司机，比较资深的，对用户，对行业有比较深洞察的产品经理，可能他们提出来的想法是靠谱一些。我们需要这样的人，这样也是在我们的行业当中是不可或缺。但是问题是这是可遇而不可求，你也许有机会跟一个靠谱的资深产品经理一起工作，但是也许不是这样的。而且即使有这样的人在团队当中，这么长时间下来我发现他不可能一直对下去，这次可能是OK，但是过一段时间在另外一个功能点，他的洞察力不一定靠谱了。这个其实是我们的现状决定的。 现在互联网行业基本红利期结束了，好摘的果子基本摘掉了，剩下都是难啃的工作，剩下都是比较难的工作，有很多不确定性，到底有哪些路可以走通，其实谁都说不清楚，这个也是我们面临的很大挑战。 我们经常听到VUCA时代，说的就是这个，我们这个时代瞬息万变，不确定性非常强，不管是在各个业务领域，基本上都是这样： V（Volatility）、U（Uncertainty）、C（Complexity）、A（Ambiguity） 创新面临最大的挑战就是不确定性，我们面临很多路，但是没有办法搞清楚哪一路真的可以走通，这个创新面临的最大不确定性，但是好消息是敏捷最大的长处就是应对不确定性。 二、产品需要敏捷思维敏捷应对不确定性的方式 我们工作中两种不同的思维方式或者工作方式，一种是预测式的过程，另外一种是经验式的过程。 预测式过程就是传统的这种做事模式。我们觉得要把这件事情做成，就意味着一开始什么都要做对，什么都要想对，这种工作模式一开始花大量的时间和精力希望在一开始什么都做对，什么都要靠谱，常常事与愿违，就是这种不确定性。这个会导致团队以为快接近目标的时候，才发现这个不是我们去的方向，赶紧换方向，可能是另外一个目标。这个时候你调整方向会花大量的代价。可能接近调整目标了以后，其实发现目标还在另外的地方，又要再做调整。很多团队死在调整路上，你根本没有为不确定性做准备。 敏捷方式就经验式的过程，它的方式是什么？假定没有办法在一开始就得到所有需要的信息，从而没有办法什么都做对，这种前提下就不指望我们一开始做的是最正确的决定，我们先基于现有的信息先做靠谱的决定，然后往前走两步，走两步以后，这个时候有新的信息进来，我再基于新的信息做更加靠谱的决定，再往前走两一步。这样不断往前走，新的信息不断进来，不断修正方向，反而更好，更快达到我们的目标，这个是敏捷应对不确定性的方式。 打破确定性思维 平时我们怎么把洗澡水调到合适的温度？ 水头没有刻度，我没有办法去调，怎么办？难道就没有办法洗澡，我们就试，我们先拧开再说，要不断的调整，不了多久就调到合适的温度这就是所谓经验式的过程，敏捷应对不确定性的方式。 我们必须打破不确定性思维，我们希望从确定性思维向右边转变。这个过程当中，很多团队不敢轻易尝试，因为失败了就要背锅，这种环境是不可能有什么创新动力在，我们必须转变以最小成本快速试错。 关键在于，不确定性环境下要试错，但是要想成功有两个关键词儿，第一是最小成本，第二是快速，这两个缺一不可。 ①-所以我们需要从不愿意轻易尝试，极力避免失败，转变为以最小成本快速试错。 ②-追求大而详尽的计划转变为迭代式小规模计划。 大而详尽计划没有意义，没有过不了多久情况变得不一样，你原来想跑的东西没有办法试用。 ③-追求完整、详细的需求文档转变为需求渐进明晰，切分小粒度。 在这个过程中，你花大量时间到写需求文档，很多时间都浪费掉了。我们期望方式是需求渐进明细，远的需求按照优先级来排好，很快马上要做的需求，最近一两周做的需求把它仔细细化可以开始开发，更加远的需求允许一定程度的模糊性或者是粗粒度，这样更加容易应对变化。 ④-对范围、时间、质量毫无差别的坚守转变为坚守时间、质量、范围可协商。 举个例子： 老板把你叫到办公室跟你说，这些需求某一天全都要，保质保量。这个意味着范围、时间、质量全部限死了，你在这个过程没有什么调整余地，这些需求在那个时间点要保质保量全部上，实际当中我们发现在不确定环境下，这个其实相当难做到，大家都会硬头皮做。这个时候问开发能不能实现，开发说压力太大了，但是不行，老板要，你必须做到，996、247你随便选。 开发同学面临这种状况会怎么选，可见都弄上去，你要的功能，要的界面这些都弄上，但是不好见的地方不好意思要做很多的妥协，各种临时的解决方案都在里面了，代码看上去一团糟，接手的时候很难在这个基础做开发。因为你已经把时间卡在那儿了，我们真的要这样吗？ 我们回过来看一下：时间、质量、范围。 时间能不能妥协？通常不能妥协。因为毕竟很多东西是要时效性，比如说双十一活动和6.18活动，时间不妥协。 质量能不能妥协？质量当然不能妥协了。这个是我们的责任，我们有责任有义务保证质量把我们的产品功能奉献给客户，服务奉献给客户。 我们的范围能不能妥协？实际上是可以的。我们再把老板交过来一大包需求拿过来，仔细切小看看，你会发现他们优先级度是不一样，有些东西可以往后放一放，这个时候会发现很多协调、讨价还价的余地。 也就是说范围应该可以接受，这个是天然决定，你要切开小粒度，必须切下，切开，然后再说这个重要，还是那个重要，这个先做，那个先做，这个时候才有讨论余地。 ⑤—精确的进度把控及对任何便利的追究，到接受意外变化并以最小的代价快响应。 “构建-衡量-学习”循环 在精益创业里面，所有构建、衡量、学习就是来自于精益创业，一开始有想法，然后快速形成开发，形成上线，然后可以收集到用户的反馈，基于用户的反馈，用户的数据分析出来得到和验证我们的路子，这个路子是不是走的通，是不是用户需要，然后形成新的想法再进一步实现，这个过程就是“构建—衡量—学习”我们以快速试错成本的一个方法。 探索创新方式的学习循环 产品方向搞清楚了，我们在后面需要持续推动产品的增长，我们在局部不断做这种优化，所以后面优化的思路完全是一样，它来自于增长黑客的思路。 可以在团队成立专门增长团队，有了新的想法开始排优先级，觉得靠谱就赶快做出来，上线验证。我们只做验证我们想法需求最小集，只要验证我们的想法，甚至不开发都可以，很多时候不开发，做一个假的界面，背后是人工在弄，就没有开发现成的系统，只要验证我们的想法就足够了。快速评估、学习里面的验证思路，然后形成新的想法。 三、建立低成本快速试错的工程能力如果要支撑之前的以最小成本快速试错，我们必须建立低成本快速试错的工程能力，这个实现不了，我们很难实现最小成本快速试错。 例如 “团队一” 可以做到一周快速有五六次上线， “团队二” 可能一个月就试一两次 “团队二”一个月做的尝试试错数量都比不上“团队一”一周做的，如果我们竞争对手能做的这么快，我们的危机就来了。他一个月尝试试错次数是我们一年的量，这个意味着他可以比你更早找到正确的方向，我们的生存危机就很大了，所以我们必须建立低成本快速试错的能力。 让创新置换快速运转 我们有想法、快速实现上线，基于数据分析，然后形成新的想法，不断来进行循环。这个过程要做很多的事情，我们要让创新的环快速运作，大家看各种各样的事情要做。这个需要很多人紧密配合，才能让环转起来。 在你的团队里面，转一圈要多久？通常之前参与比较好的团队，如果一个想法比如说一天开发，一天测试的想法，转一圈非常快，基本一天半就转完了，你有一个想法，产品同学有一个想法马上要验一下，这个非常重要，一天开发一天测试，两天半就够了，这个是非常快的。 如果把这个创新环比做成齿轮，我们想让齿轮快速转起来，就需要加入润滑油，这个润滑油就是精益的实践。 跨职能自管理团队 我们要把我们的这种创新团队组织起来，这个创新团队跟之前不一样，它必须是跨职能自管理团队，首先我们要坚持的是围绕价值流组织跨职能团队，下图是电商业务价值流，所谓价值流就是通过一系列的过程能够提供用户有价值的产品。这个过程是企业的命脉，如果这个过程出问题，那么企业就有了问题。围绕这个过程顺利进行，我们必须下面有很多的系统支持，就是有系统群。每一个系统群有相应的研发价值，研发团队确保这个系统正常运作，如果有新的需求快速迭代，快速上线做尝试，这是首先要做到的。 在团队划分的时候不要对抗康威定律。康威定律说的是软件系统组织和架构有一一对应的关系，如果没有对应就意味着有更高的沟通协作成本。 ...

很多时候，我们感觉什么都没干一天就过去了，但对领导者来说，事情最好已经提前做完了，而且是越快越好。聪明的管理者知道，“时间”是需要花大功夫去把控的限制因素，只有掌握了更多关于时间和工作的数据，我们才能更好地执行计划，在预算范围内按时完成项目。 燃尽图就是用来反映此类项目数据的工具，常用于敏捷软件开发中，如Scrum。它可以呈现剩余工作量和可用剩余时间，并通过可视化的图示表述繁复文字无法表述的意思。 一、燃尽图是什么？燃尽图可以呈现团队处理用户故事进度，是一种对工作完成情况可视化展示的工具，燃尽图可显示每次迭代工作总量中仍需完成的工作余量。 燃尽图的横轴显示工作天数，纵轴显示剩余工作，反映了项目启动以来的进度情况，它让每个团队成员都能够看到当前的进度。团队需定期更新燃尽图以保持其准确性。 目前存在两种形式的燃尽图，Sprint燃尽图用于显示迭代中的剩余工作量，而产品燃尽图则用于说明整个项目的剩余工作量。 二、如何解读燃尽图燃尽图有下面几个要点，它有一个X轴，代表项目或迭代的时间；有一个Y轴，代表需要在项目中完成的工作，用户故事剩余的工作量也由该轴表示。 项目起点位于图表左侧最高点，发生在项目或迭代的第0天。项目完结点位于最右侧，标志着项目或迭代的最后一天。 计划曲线燃尽图中的计划曲线是一条连接起点和终点的直线。因为代表了需要完成的所有预估任务的总和，计划曲线的终点应穿过X轴，表示已经不存在任何剩余的工作。但鉴于它以估算值为基础，因此并不总是准确的。 实际曲线燃尽图中还存在一条实际曲线，显示项目或迭代中实际剩余的工作量。在起点，计划剩余工作量和实际剩余工作量是相同的，但随着项目或迭代的进行，实际剩余工作曲线将在计划工作线的上下方波动。实际的剩余工作线每天都会添加一个新的点，直至项目或迭代完成，以确保尽可能准确。 如果实际工作线高于计划曲线，则意味着剩下的工作量比预期多，换句话说，意味着项目进度落后于计划。但如果实际曲线低于计划曲线，则意味着剩余工作量少于预计，项目进度快于既定计划。 三、燃尽图有什么好处？燃尽图最显著的好处是，能提供关于项目进度和更新状态的最新报告，并对这些重要数据进行直观展示，可以确保每个人都统一进度。 此外，将燃尽图展示到所有人面前，能够让团队所有成员都积极参与项目，并激励成员提前处理可能出现的问题。因此图表越大越显眼就越好。燃尽图应该成为办公室的视觉焦点，进而引发对项目和进度的相关讨论。 简洁明了的燃尽图十分有用，因为它是查看项目历史速度（Velocity）的最佳工具。速度（Velocity）是一个敏捷术语，表示迭代期间完成的用户故事相关的预估工作量总和。 四、燃尽图有何局限？燃尽表无法呈现所有信息例如，它仅显示已经完成的用户故事工作量，无法预知任何变化，例如在工作范围内估算待办列表（backlog）的所有points。因此，我们很难判断燃尽图中的变化是由于已经完成的backlog，还是由于故事点的增加或减少引起的。在燃尽图中增加一个专门显示backlog总量的图表可以解决这个问题。 但是，燃尽图（向下或向上线条显示）都无法显示哪些产品backlog已经完成。燃尽图能显示项目的进度，但无法显示团队是否在做正确的事，也无法判断团队是否在交付正确产品backlog。 燃尽图需依赖精准的预估燃尽图的另外一个问题是理想剩余工作线。实际工作线是高于还是低于理想工作线需要取决于对任务原始时间估计的准确性。因此，如果团队过高估计时间要求，则项目实际进度可能会看似正常或略超前。但如果低估了时间要求，则看起来会落后于计划。 将效率因素纳入燃尽图可以解决这个问题。因此，在项目的第一次迭代之后，重新计算效率因素能够获得更高的准确性。 五、燃尽图的历史回顾燃尽图是从Scrum社区开发出来的，并且在2000年左右首次用于管理软件项目和其他相关工作。Ken Schwaber首次对燃尽图进行了描述，因此也被认为是燃尽图的发明者。当时正在Fidelity Investments工作的Ken Schwaber创建了燃尽图，来为Scrum团队提供一个可以帮助他们绘制项目进度图的简单工具。 到2002年，燃尽图在Scrum社区中越来越受欢迎。从那以后，燃尽图开始运用于scrum之外的其他领域，成为了管理者控制项目进度的有用工具。 Worktile提供专业的敏捷项目管理模板工具，包括需求管理、迭代规划、缺陷追踪、报表统计、团队协作等功能，能实时查看和监控项目进度，提高团队成员工作效率。10人以下团队可免费使用，免费注册Worktile。 文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

蔡建斌 -国际物流公司亚洲 IT 交付团队经理 导语 敏捷是一个很流行的一个词语，但是在敏捷里面，包括很多团队也是刚开始用Scrum，怎么让质量成为敏捷的一个助力而不是拖累，这个是我主要想谈的。 关于质量的定义，我前不久接触到一个文章，里面有一个图讲到质量的五个维度，但是我做了一些微调，改成了四个。接下来就从我定义的4个维度的质量分别探讨一下。 1. 基于价值的质量，交付影响而不是交付产品 在IT业有一个很著名的人叫做 温伯格 的咨询师， 他提到质量的定义叫做质量是对某些人的价值，价值是什么意思？ 福特问客户想要什么，他说要一匹更快的马，但是福特提供给了客户汽车。马和汽车是提供给客户的产品，价值是什么？客户可能有天天从各个城市飞来飞去需求，他希望有更快的马来助力，这个就是价值的意思。客户的需求往往是方案，它很少告诉你这个东西背后是什么目的。所以User Story的背后，就是价值。 在工作上，我认为我们不是在交付产品，而是是交付影响力，就是交付对用户的影响。你让我开发一匹更加的马，我要问这个马用来干什么，对你有什么影响，因为我交付的是影响而不是产品。 Impact Mapping通过 Why Who How What得到一些想法：我们做产品是为了什么？影响哪些人？ -如果说一个咖啡馆老板，他想赚一个亿，谁能帮助他达成这个目标？ -如果说顾客可以帮助他达成这个目标，那怎么帮助他达成？ 比如顾客（who）买了咖啡之后，觉得不错然后会推荐给其他朋友（how），所以顾客通过把咖啡店推荐给好友的行为可以帮助他赚到一个亿（why）的小目标，但是需要注意的是，这个"who"可以很多。 有了前面的铺垫后就能得到"what" 为了鼓励顾客去推荐好友这个行为，我可能会开发一个“推荐赚积分积分换咖啡”（what）的功能系统。我们开发Story不是Story本身，产品本身不是我们直接的目标，我们的目标其实是为了影响“顾客去推荐好友”这样一个行为，这个影响，最终达到业务目标，就是这个why。 我们跟产品合作，他们给我们做了一次what，他会说你给我做一个积分换咖啡的功能，其实背后这些功能会带来什么样的价值，才是更需要探讨的。但是这样的思想框架并不是真的去问why 、who等等，而是告诉我们真正需要交付的东西，而不是真正的产品。所以说提出一个可能符合背后目标的更好的what出来，这才是框架的一个根本目的。 2. 基于产品的质量，利用反馈 例如，我们要研发更快的马，或者研发一辆汽车，这个就是产品本身，定下来仍然有质量因素在里面，就是怎么把东西做对。 Cynefin模型： simple ：你要解决问题很简单，你有一些最佳实践套用就可以了，如果你的公司，你的研发在这个象限上，其实是恭喜你，其实是非常舒服的 complicated ：比较繁杂的场景，这个场景下你的解决方案可能有多个，可能不存在最佳实践，又或者可能有多个实践，可能找几个专家来帮你搞定，这个是一个场景 complex ：没有办法简单找几个专家来研究得出结论，这个应付的东西是各个维度，有可能是质量出问题，加上预算有限，加上产品方向不清，需求不清，产品跟架构师之间合作不来，各种交织在一起，但是有一个目标需要推进。 chaotic ：就是混乱，如果碰到这种，这个挑战确实是非常大，可能不是一般的管理者能够应付得了，需要CXO坐在一起给出方向。 disorder ：管理者把解决问题分解成多个子领域，分解成多各个情境来逐个击破。 产品研发大部分属于第二和第三象限，这两个维度的实现就是先做，然后再反馈。反馈有一个原理：越早的反馈越便宜。 举个例子 在产品研发中，有一个很大的问题，就是你的技术团队和产品经理的鸿沟。这个鸿沟很常见，但是在我自己的工作场景里面这个鸿沟不常见，我一直是技术领域的人，但是我在产品上或者需求上跟产品经理一直是通力协作的，用实时的反馈来跨越反馈，而不要等产品经理已经设计了两个月，然后给我们开发完上线后，再提出需求不对，这样就比较被动。 如果反馈能做到实时，下面就是实践。在新的产品研发开始的时候，我与技术人员产品经理会一起先把概念模型画下来，因为一个团队有很多的角色，包括架构师、开发、US、甚至外包人员，不同的角色怎么确保理解的一致，最后明白如何做自己的工作。你怎么确保这份活动基于统一的理解，没有共识就比较容易出现鸿沟。把概念模型画下来就是为了现实上的例子，可以很简单，我们有什么业务对象，他们之间关系是什么样，把这些东西画下来，大家基于一份共识去做各自的活，这个鸿沟会少一点。 3. 基于产出的质量，定义完成，以终为始 我自己是研发出身,研发质量产出是什么？就是需要建立条目化，短周期之内可以交付的东西，这个是产出，第一个产出是代码，尤其在软件行业，代码占了80%的产出，怎么把代码写对，就是第三个维度。 代码质量有一个心法叫做定义完成； 举个例子，很多程序员你问他这个Story做了没有，他给你的答案是什么？度量BUG是为零，程序员做完之后交给QA，QA告诉开发有没有BUG。你的QA下一道工序是我的客户，我应该告诉你有没有BUG或者有多少个BUG，而不是反过来。 需求质量也是很重要的产出； 你要保证你的产品经理做的需求是不是符合，是不是条目化，是不是按照优先级，你是不是做最重要的事情。你有三个团队，每个团队都在按照优先级来做事，但是三个团队是不是有统一的优先级，很多团队是没有做到的。 有些需求你不做用户会不高兴，但是你做了也不会很高兴，就像我们的实践一样，项目大的时候不做实践会很惨，但是做了项目也不一定会成功。 工作中当你问程序员说这个做完没有，很多程序员告诉你90%完成，或者完成了但是没有测，或者有几个BUG，或者需要重构一下，这种心态是不好的，但是没有反馈。 我们叫做以终为始，用户故事只有两种状态，只有完成和没有完成，没有但是，没有完成你要把它完成掉。程序员会说这个做了90%，然后去做下一个故事，结果是没有一个可以工作。而我们倡导的是把一件事情全部做完，才做下一个。 4. 过程质量，拆 有这样一句话，如果你用同样的方式去烤面包只会得到相同的面包。 过程质量就是写代码的质量，这个心法就是拆，拆成小的东西，拆成一个可交付的东西，其实写代码也是需要拆的。 举一个例子，很多程序员写代码，一天下班的时候代码还没有编译，我们写代码方式应该是这样,很多程序员写代码是东写一点，西写一点，这个意味着什么？没有透明度，他不知道写哪一个，这样的过程想代码质量好是不可能的。 ...

对从事项目管理的人员来说，敏捷已经成为一场席卷全国的风潮。但敏捷并不是什么新事物，它已经有20多年的历史。正如社交媒体圈子所说的那样，敏捷的声势与流行程度正在逐年见长。但敏捷是不是真的如坊间传闻的那样，是一个可以解决所有项目困境的万能药？当然不是！但敏捷的确是一种比较好的项目管理方法。敏捷为项目负责人及其团队提供了一些独特的优势。我们之前将敏捷方法与传统的瀑布流方法进行了比较。敏捷这种软件开发领域的项目管理办法，在过去数年有着强劲的发展势头。它解决了产品需求与开发等方面的不确定性。与之相较的瀑布流方法则试图将项目生命周期的各阶段，即启动、计划、执行和收尾等，按照严格的结构顺序进行组织。 什么是敏捷?要确切定义何为敏捷非常困难。不同的人可能会给出不同的答案。敏捷这个大范畴内包含下面几个体系，如Scrum、XP Extreme、 Lean 和 Kanban Software Development 以及Crystal Clear。敏捷将项目规划变成了一个贯穿整个项目生命周期的迭代过程。“fail-fast”这个术语体现了对迭代的渴望，即通过先将开发出的不完美的产品提供给客户使用，以收集客户的反馈。客户的反馈至关重要。传统的项目管理方法要求项目需求在项目开始之前就要收集并确定好。但敏捷方法则不同，敏捷更加实用和高效，要求产品负责人和关键利益相关者在产品开发过程中，参与构建和测试。这样做能够大大节省时间。为什么我们需要花上三个月的时间收集需求，再花上四个月的时间开发产品，到最后才发现开发的产品并不是客户真正想要的？为什么我们不能够开发一部分之后，展示给客户，将反馈整合到产品的开发中，然后不断重复这个过程并在更短的时间内构建客户想要的产品？简而言之，这就是敏捷的目标。 使用敏捷的最佳条件是什么？当我们无法确定产品的需求是什么时，最好使用敏捷方法。从收集用户故事开始就让产品负责人和Scrum团队参与进来能够让我们更高效地利用时间。用户故事是产品负责人希望开发的功能和特征的简要描述。然后，根据这些软件功能，产品负责人和Scrum团队创建一个名为Product Backlog的待办事项列表。建立Product Backlog后，Scrum团队就会创建Sprint Backlog。客户所需的产品功能将会被安排在不同的Sprint中完成。因此，Sprint中是下一个版本中的功能，这么做的目的是为了每次都开发和部署产品的一小部分功能。 产品负责人和Scrum团队将召开每日站会来review开发进度。这种方法有助于解决产品或需求中的不确定问题。所以整个产品开发流程就是：开发部分功能—测试—收集反馈并继续开发—直至产品负责人对最终产品满意为止。 什么情况下敏捷不是最佳选择？敏捷并不总是最好的方法，例如需求基本是确定的。当项目具备可靠的历史记录作为开发基准时，我们最好采用瀑布式开发方法。数据中心的构建就是一个很好的例子。需求和任务开发顺序都很明确，无需做太多的规划。因此，如果按照前文所述的“部分开发-反馈-继续开发”这一流程进行显然是不切实际的。 那么，何时步入敏捷？现在，我们已经清楚了解了敏捷的定义，适用条件及在什么情况下最好使用传统的开发方法。下面，让我们了解一下在什么情况下最好使用敏捷。具体情况可能比较多，仅在下文中列举几类主要情况： 产品需求不确定时这种情况下，敏捷可以使项目更快启动，并让产品负责人参与到开发过程中。用敏捷的方式，我们就不必在不确定客户是否会满意的情况下花六个月的时间记录产品需求。产品负责人可以在开发新产品功能时，根据他或她的反馈作为开发过程的一部分，以最快的速度将功能呈现出来，从而确保产品可以更快交付。 敏捷是软件开发项目的最佳选择因为软件开发过程本身就允许整个系统中的部分功能先进行开发、测试和交付。这就意味着某些特定功能的交付时间会早于其他功能。Sprint则允许开发团队单独测试和部署这些功能，从而确保开发效率。 协作的团队可从敏捷方法中受益（每日站会）敏捷方法的关键是每天的站立会议。会议上，团队可以讨论当前的开发进度、遇到的问题和来自产品负责人的反馈。如果有人能够负责召开这些会议并将会议结果更新到敏捷看板上就好了。因为协作的团队成员可以随时访问和更新故事板，这将有助于团队协作的顺利开展。 这一点可以通过Worktile的迭代故事板可以做到，在每日站会的时候迭代负责人可以拖动需求看板来改变需求状态及时更新需求进度。 积极参与的产品负责人产品负责人的实时反馈是敏捷成功的关键。这样不仅可以取代繁琐的需求文档，还能确保清晰的传达产品负责人的需求。产品负责人参与并为开发团队提供持续的反馈，能使团队更快地开发出正确的产品。产品负责人应该参加每天站会，并表达自己的期望、喜好和不满。这样能确保开发团队开发出产品负责人想要的产品。 团队工作与协作——积极主动的团队成员社会责任是敏捷方法的关键驱动因素。敏捷希望创建一个能在一定程度上实现自我管理的团队环境。敏捷教练希望创建一个积极并表现出主动性的团队。如果团队成员没能赶上进度或积极参与，那么敏捷教练希望其他团队成员能够互相帮助、鼓励和激励。敏捷教练将以身作则，奠定团队中相互鼓励和问责的协作基调。 从失败中学习的意愿快速试错更快速地从失败中学习。原型设计和反馈是敏捷的重要工具。传统的开发方式试图在项目启动前描述所有的需求，这么做会浪费大量时间，尤其是在开发新产品时。所以一旦有了想法就应该立刻进行开发，即使当前的产品并非产品负责人想要的。这样做的目的是要通过不断的反馈来调整产品方向并继续开发。 管理层支持敏捷框架并具备团队赋权的企业文化敏捷可以为企业带来文化和期望层面的转变，因为它鼓励团队赋权，让团队负责做出决策并承担相应的风险。与之相反的是，在传统的开发团队中，项目经理需要提供明确的方向，而在敏捷开发中，敏捷教练则会鼓励开发团队提出最适合产品开发和产品负责人的方案。管理层必须赋予团队必要的自由，仅提供能让团队快速成长的指导和方向，而不是控制团队的每一步行动。 拥抱敏捷使人兴奋。因为它让项目负责人多了一种项目管理方法，来解决项目进度中的各类问题。但与其他方法一样，敏捷的应用也存在限制，也有其不适合的任务。总而言之，敏捷为项目经理提供了更多的选择，让他们有可能更好地管理项目。 项目管理工具让项目经理可以更好地完成本职工作，正确的项目管理工具让我们能够在预算范围内，按时保质地完成工作。Worktile在这方面可以发挥巨大作用。作为一个项目管理工具，它为您提供了实时规划、监控和报告的方法。 文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

敏捷是理想型指标和原则，看板和Scrum是帮助团队坚持敏捷原则并完成工作的基本框架。本文详细介绍了在Scrum和看板之间做出选择时要考虑的关键因素，以及如果我们无法做出决定时该怎么办。 Scrum和看板实践之间的区别很容易总结出，但这只是表面上的。虽然这两种框架实践起来不同，但原则基本相同，他们都将帮助团队以更高的效率构建更好的产品和服务。 敏捷敏捷是一种结构化的迭代方法，多用于项目管理和产品开发。它根据产品开发的波动性特征，为组织团队提供了一种能够在不偏离项目常规轨道的情况下随时作出响应、更改的方法。今天，敏捷很难成为某个组织的独有竞争优势，因为还没有被彻底掌握并做到最佳。这意味着把它做好比以往任何时候都更重要。 （敏捷开发流程） 看板看板可以让你手头的工作变得可视化，并限制正在进行的大量工作，最大化提升效率(或优化流程)。团队通过使用看板并不断改进他们的工作流程，能够有效减少从项目(或需求)开始到结束所花费的时间。 ScrumScrum团队通常以Sprints的固定时间间隔为准来交付最终产品，他们的做法是创建循环任务，以便快速收集和集成客户反馈。Scrum团队采用特定的角色，创建特殊的工具，并定期举行会议来保持项目的进展。 Scrum：结构化的敏捷方法使用Scrum的团队，需要承诺在每个Sprint结束时交付一些有价值的工作增量。Scrum专注于小的增量工作，帮助团队不断进行学习，以预测和了解到接下来要做什么。 Scrum工作节奏Scrum发展很快，每2-4个星期就有一个明确的开始和结束日期。短时间框架迫使复杂的任务被分解成更小的需求，并帮助团队快速学习。但关键的问题是：您的团队能够如此快速地交付可用代码吗?Sprint 的进行中还包括 Sprint 计划、Sprint 评审和回顾会议，并穿插着每日Scrum 站立会议。这些Scrum仪式都是轻量级的，在循环任务的基础上运行。 交付方式每次Sprint结束时发布版本一直是Scrum的最佳实践，团队为每个Sprint设置一个目标，在Sprint评审会议上决定是否要发布。 Scrum角色Scrum有三个明确定义的角色：产品负责人为客户提供支持，管理产品 Backlog，并帮助开发团队确定所做工作的优先级；Scrum Master 帮助团队坚持 Scrum 原则；开发团队完成项目工作，交付增量。 那谁来管理 Scrum 团队？答案是：没有设定这个角色。Scrum 团队属于自治型，尽管职责不同，但每个人都是平等的，所有人都坚定于一个共同的目标：为客户提供有价值的产品。 关键指标Scrum团队的核心指标是速度，即在一个Sprint周期中完成的需求数量，它为下一阶段Sprint及团队要承担的工作作出了预测性指导。 多变性Scrum团队有时会得到客户反馈，并了解到他们所做的可能不符合客户的预期价值。在这种情况下，Sprint的范围应该以“客户期望的价值”为中心来改变。 看板：持续改进，流程灵活看板有助于可视化我们手头的工作，限制正在进行的工作(WIP)，制定完整工作流程。看板对于项目任务复杂、优先级划分明晰的团队非常有用，Scrum需要对整体工作内容进行高度控制，而看板则灵活度更高。 看板工作节奏看板基于一个连续的工作流结构，它能够让团队保持敏捷，随时准备适应不断变化的任务优先级。工作项(通常由卡片表示)排布在看板上，它们从工作流程的一个阶段流向下一个阶段，基本工作流阶段包括：To Do（未开始）- In Progress（进行中）- In Review（审查中）-Done（已完成）。想了解更多“工作流”内容也可以查看：制定工作流来获得团队更高效率。 看板最大的优势是为团队定制出工作的标准流程。例如我们文章创作项目，流程包括“初稿-稿件审核中-稿件审核通过（待排期）-稿件已发布”，审核人可以很全面的把控内容的创作质量。 交付方式理论上，看板并没有规定交付任务的固定时间。如果任务完成得更早(或更晚)，团队就可以根据需要发布产品，而不必等待Sprint Review这样的发布里程碑。 看板的角色整个团队都可以共享看板，也为所有需要交付的任务负责。虽然有些团队聘请了敏捷教练，但与Scrum不同的是，没有一个“看板大师”能让所有事情都顺利运行。 关键指标交付时间和周期时间是看板团队的重要指标，即处理任务从开始到完成所需的平均时间。循环任务的完成时间的长短，体现了一个看板团队的效率高低。 看板中，处理工作瓶颈的方法是WIP限制，它可以控住工作流任何一个阶段中的卡片数量（即任务量）。当您达到WIP限制时，类似于Worktile的看板工具就会为该列（流程阶段）设置任务上限，团队就会更多的专注于这一阶段的工作。 多变性看板十分灵活，工作项可以随时更改。新的工作项被添加到待办事项列表中，现有的卡片可以根据优先级的规划情况被暂定或删除。此外，如果团队工作量发生变化，可以重新校准WIP限制，并相应地调整工作项。 看板vs scrum：哪个更适合团队？俗话说：“尽信书，则不如无书”，Scrum和看板正是“书上的敏捷”。因此为团队做出的决定不需要如此黑白分明，我们还需要联系现实情况去决定；还有一种情况是，目前有很多团队正在使用scrum和看板的混合模型。 不管你为团队最终选择了什么，务必坚持使用一段时间。可以在日常会议中从待办事项列表中找出一些要做的工作，然后问问你的团队认为哪些做得好，哪些做得不好；通过尝试scrum和看板，并不断提出问题和复盘工作，那你的团队已经走在通往敏捷的路上了。 文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

您是否在开发对组织来说有价值的产品？如何判断产品是否有价值？ 如果没有经常提出这两个问题，那么您可能忽略了产品价值方面的问题。 产品是目前工作所要达成的目的，是组建团队的原因。产品也是你选择Scrum的原因，所以，你必须要集中精力理解并提高产品价值。 优化产品价值的4个步骤 第1步：培养产品思维而非项目思维产品思维聚焦于创造有价值的输出。 如果开发的产品没有人想要或使用，那么产出就毫无价值。 作为一名以传统项目管理作为职业起点的PMP，我对项目思维模式非常熟悉。衡量项目是否成功的标准通常基于一个铁三角：在规定的时间和预算内交付所有预期功能。 Scrum不是以更快、更便宜的方式交付更多产品。 Scrum旨在频繁交付更高的价值。 通过交付更高的价值，可以为组织降低风险，并挖掘更多的可能。虽然仍然需要做项目预算和时间表，但更需要重视的是要确保开发的产品是适合的。以下几步将详细介绍如何做到这点。但是，培养产品思维是一个持续的过程，因为人们很容易重拾旧思维，尤其是在压力下。 当出现“项目状态”的对话时，请注意倾听发起对话的人的思维模式。如果对话只涉及项目完成百分比、项目预警、问题跟踪等问题时，你需要问一些强有力的问题把大家的焦点带入产品思维模式中。这里有几个例子可供参考： 我们如何验证有关用户需求/市场需求的假设？我们对价值了解多少？如何通过价值指导产品决策？从我们开始这个项目以来，用户/竞争环境发生了哪些变化？Scrum团队里的PO（Product Owner）在培养产品思维模式方面扮演很重要的角色。 第2步：描绘宏伟蓝图由于你是以迭代递增的方式开发产品，因此必须清楚地了解工作的方向和原因。这样可以帮你确定是否与公司目标保持一致并在需要的时候做出相应调整。 有许多方法可以帮助企业明确产品目标（产品愿景）及其背后的商业模式。产品愿景描述的是对产品的期望，向目标用户传达的是其主要价值定位。 宏伟蓝图还包括价值定位。期望中的产品会有许多的特点和功能。所以为了衡量价值大小，必须要定义产品中最重要的价值点以及如何判定你达到了预期目标。 虽然对价值的定义高度依赖于背景，但以下几种价值类型也可以考虑： 商业目标（如，客户转化率）利润/收入（如，每位客户带来的收益、回头客）节约成本（如，获客成本）客户/用户增长率（如，新客户、市场份额、使用最新版本的客户）功使用率（如，使用某项功能的客户、使用某项功能的时间）现在，具体要做的就是明确价值定义及如何衡量价值。 第3步：价值实现复杂问题的解决办法总会在你认真工作（不仅仅是分析和谈论）的时候出现，你可能会判定那些假设是错误的，也可以看出市场甚至是商业模式已经发生改变。 因此，必须在开发产品的时候让价值涌现。产品Backlog代表计划开发的产品及开发顺序。而通过产品Backlog的细化过程来使价值涌现时，需要注意3点： 将任务分解到足够小理解价值一致性拉远/推进将任务分解到足够小——以便更灵活快速地交付价值。一旦确定了愿景，就会有一些实用的方法来构建更高层次的细节。首先，可以确定实现愿景的关键业务结果或目标。然后，再确定交付预期结果所需的关键特征、功能或性能。 任务分解越细，灵活性越强，交付价值和验证假设的速度就越快。还有很多补充的方法和理念会对细节上的工作有所帮助（如需求地图和假设地图）。达到“中等水平”后，可以考虑尝试进一步分解PBIs（Product Backlog Items）的模式。 记住不需要提前分解每件事。随着时间推移，产品Backlog会出现，这个时候你可以根据你在迭代递增式开发中所学的知识对其进行调整。 理解价值一致性——以交付更大的价值。在产品Backlog中聚焦价值的另一种方法是确定预期结果。很多时候PBIs（Product Backlog Items）会说明产品预期特征和功能。那么，我们是不是可以转而更多地关注产品特征或功能的预期结果？有许多方法可以让PBIs聚焦在价值上，包括求用户故事（如果运用得当的话），假设驱动开发和A / B测试等。还可以在产品Backlog中为每一个PBI捕获价值作为元数据。这个元数据也许是以美元为单位的投资回报率（ROI），也许是步骤2中定义的价值定位的映射。 不断拉远推近……以确保可交付价值没有偏离。在检验和调整时，需要“拉远”以查看不同之处，然后再“推近”查看现在有什么不同以及需要如何调整。这就是如何验证学习的有效性，然后学以致用的方法。拉远推近的频率取决于产品开发的情况、市场中验证假设的频率以及业务变化大小。注意：PO（Product Owner）不会单独确定什么是有价值的，不会知道价值细分的最佳方式，也不会以书面形式完美地描述分解过程让大家理解。这就是为什么PO必须想方设法让他人共同参与合作，一起改进产品Backlog。 第4步：验证实际价值现在一切准备就绪，可以开始评估实际价值。没有得到市场验证之前，价值只是一个假设。 产品发布之后才能精准获知产品的实际交付价值。通过获取经验数据，来确保知情决策所需的透明度。 实际价值与预期价值的比率是多少？如何有效地收集这些经验数据？开发团队通常可以提供一些将数据收集功能构建到产品中的方法。随着产品规模和复杂性的增加，还需要增加流程和工具来收集这些经验数据。 一旦有了数据，就可以分析走势。记住，某一时间点的数据并不能说明多少，整体走势更为重要。而且需要收集多种类型的数据，单一类型的数据并不能说明全局的情况，因为影响产品使用的因素通常会有很多（有些因素超出控制范围）。 在分析价值走势的时候，请思考这些问题：已经发布了哪些产品更改，这些更改何时以及如何影响价值，哪些因素超出了可控范围（例如，即使已经实现了预期会增加销售额的新功能，但股市下跌也会影响用户决策） 将实际价值的测量方式透明化。听取利益相关者的看法以及他们如何看待走势对产品改进方面的影响，而Sprint评审会议是听取意见的良好时机。 总结经验主义引导你积极处理这些棘手的产品价值问题。对价值而言，它必须具有透明性，并且必须经常检验它的实际值，以便根据需要进行调整。就像开发出一款可运行的产品一样，想清楚要做什么同样复杂且具有不可预测性。所以要学会边做边学，根据所学知识做出决策。 总之，Scrum的核心不是我们开发了多少东西，而是通过频繁交付可运行产品为组织创造了多少价值。因此，Scrum也强调不断学习和适应，以便从产品中获取更多价值。 文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

团队如何最大限度地发挥Scrum和敏捷的优势？ 回想一下，Scrum团队在Scrum的框架内定义了自己的流程。这其中包括方法、工具和互动以及如何履行Scrum角色的职责、如何使用工件和事件等。如何确定团队做什么以及怎么做？ 从产品管理方法到研发及质量管理方法。从团队的沟通协作方式到团队成员如何有效利用团队知识提升自己的技能及能力等等。在充满不确定性且不断变化的环境中交付复杂的产品会涉及到很多方面。因此，我们尝试简化过程并聚焦具体的行动。 下面是改进团队流程的5个步骤，希望能对你的团队有所帮助： 第1步：增加透明度的深度和广度要改进团队流程，就一定要有透明度。如果只是要“遵守规则”，Scrum只会提供最低程度的经验论。而只有当团队真正接受经验论时，才更有可能改进流程。最重要的是，团队必须要了解其流程如何影响结果。以下是团队需要探讨的一些问题： 我们如何决定产品做什么？这些决定如何实现透明化并且需要对谁透明？在任何特定时刻，我们如何理解团队在实现增量目标方面的进展？（这可能是每日目标，Sprint目标或更长期的目标。）就我们所做的每一项工作而言，什么才是有价值的输出？怎样才能让它更有价值？怎样打造高品质的产品？目前的产品质量如何？发展趋势如何？哪些因素会让结果更完美？哪些因素会导致不那么完美的结果？我们提出了哪些假设？这些假设如何验证？第2步：使用精简原则精益软件开发有七个原则。虽然这七个原则都很有用，但在这里我做了简化。我的同事Simon Reindl向我介绍了他所谓的精简原则。 价值最大化浪费最小化流动最大化这三个原则是相互关联的。流动最大化意味着我们尽可能快的推动项目（即价值）在整个过程中的流动，同时还要保证质量和客户满意度。摒弃浪费可以帮我们做到这点。因为浪费从来不会给客户增加价值。现在，从精简原则的视角来评估整个流程。寻找资源浪费的迹象和能将价值流最大化的机会。常见的资源浪费来源如下： 开发出客户不想要或者不会使用的产品心有旁骛、不断切换任务半成品质量差的产品不必要或无效的流程和文档第3步：期待变化，寻求更好（即检验和调整）团队使用的方法和工具将受到产品类型、产品技术平台、产品使用环境、产品使用者及使用方式、监管与法律环境、市场走向、不断变化的业务需求等因素的影响。所以说，涉及的因素很多。而且大部分因素会随着时间推移而发生改变。因此，团队在检验和调整他们的工作内容、工作原因、工作方法以及工作收益时必须保持警惕。世界各地的产品开发社区在不断创造和共享新的方法和工具，因此保持联系并不断学习非常重要。实际上，团队通常需要不断改进和发明新的方法和工具，来满足他们的独特需求。在复杂的工作中，并没有所谓的最佳方法。最佳方法是团队当前情况下的最优方法，而一个月后随着团队情况的变化，最优方法也会有所不同。参与推动领域或行业发展。 第4步：专注于交付“完成”增量将1-3步应用到交付“完成”增量中。Scrum的全部意义在于“完成”。可发布产品的增量有利于降低风险，优化可预测性，同时体现敏捷业务的优势。“完成”是检验进度的唯一真正标准。如果你没有在每个Sprint结束之前交付至少一个“完成”增量，那你就要注意了，这就是你需要集中精力做到的一点。那么如何改进流程以达到“完成”状态呢？当然，改进流程的方法有很多。但是，说到实现“完成”状态，这里有很多共性的因素需要我们考虑。因此，我和Simon Reindl套用1-3步中的方法将需要探索的共性因素的范围缩小，简化成了7个特定领域。这7个领域刚好可以帮助团队踏上探索和改进流程之旅： 明确定义什么情况下才算“完成”有效使用Sprint目标尽量在Sprint周期结束前“完成”PBI（Product Backlog Item）保证质量解决技术债务问题识别并消除阻碍不断提升团队技能、知识和能力第5步：不要满足于触手可及的目标快速获得小范围的成功是件好事。可以通过改进一些简单的流程获得相对稳定的收益，甚至可以通过局部优化获得一些益处。只是团队需要在一段时间内超越这些触手可及的目标，这个时候，团队需要的就是系统性的优化而不是局部优化（这也可能意味着要颠覆目前团队或产品架构）。分享一个实例吧。我曾与一个Scrum团队合作过，这个团队没有针对庞大且复杂产品的自动化测试。因为实施自动化测试需要大量工作且成本很高。有很长一段时间，自动化测试作为改进的理念被多次提及，然而，最终这个团队还是选择通过其他途径去提高质量减少浪费。当然，他们确实提高了质量和效率。但是，随着流程的推进每项改进最终获得的收益却越来越少。终于，他们意识到是时候超越触手可及的目标，寻求更大的利益。他们需要面对来自自动化测试的挑战。由于他们之前在短时间内获得了一些小的成功，所以已经在团队中树立了更强大的团队认同感，准备扩大业务范围（即实施自动化测试）。 总结Scrum团队要有自己的流程，这一点确实非常重要。当人们觉得自己在某件事上拥有所有权时，他们就会想投入更大精力，获得更好的效果。改进团队流程是一项持续的工作，永无止境。你的团队是否能保证在每个Sprint结束时都能构建一个“完成”增量？团队以何种方式表明他们对自己的流程拥有所有权？团队流程的哪些方面不那么透明，而且可能被忽略了？您希望采取哪些步骤，改进团队流程？ 文章来源：Worktile敏捷博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

组织以什么样的方式能最大限度的发挥Scrum的优势？ 组织在哪些方面阻碍了个人的发展？ Scrum是一种能使业务变得敏捷的框架。而组织恰恰需要变得敏捷。只是，组织本身有时候并没有足够的能力来帮助Scrum团队的成长，甚至还会阻碍Scrum团队的成长。组织本身所具备的公司架构和企业文化，将影响内部的团队和产品。所以组织的作用不能忽略，且与组织背道而驰没有任何益处。必须有效利用组织来获得最大效益。 有效利用组织的5个步骤第1步：明确组织需求，融汇贯通深入思考什么才是组织真正想要的。或许先要有一个明确的使命宣言。再深入一点，探索业务目标。然后，思考实现这些目标的最大挑战是什么。然后学会融汇贯通，有效利用敏捷的优势。我发现组织的目标通常与 提高投资回报率（ROI） 、 降低投资风险 以及 更灵活地应对变化 有关。提出强有力的问题进行探索、明确方向并让组织的重要人员之间达成一致。然后就会发现大多数人在想要达成的目标方面有共识。而通常会在决定如何达成目标时出现分歧。共识可以是正式的（例如，在组织中确立敏捷的愿景或创建一个专注于敏捷的团队）。也可以是非正式的，通过谈话达成共识。关键是要使用可以引起对方共鸣的语言不断强化共识。 第2步：寻找分歧分歧是由两个不可调和的因素所造成的紧张局面。组织内部的价值观、信仰或行为与敏捷思维会在哪些方面产生分歧？这些分歧对Scrum团队的有效性有什么影响？这两个问题会帮助你找到延缓Scrum团队改进的组织级障碍。记住Scrum Mastery 的其他三个维度。要知道培养强烈的团队认同感、改善团队流程以及优化产品价值所需要的条件。分歧以何种方式影响这些维度？ 下面结合我以往的经验向大家举一些例子： 招聘模式、职位描述、工作汇报架构、激励措施和绩效管理流程会对团队认同感维度产生重大影响。跨部门或跨团队的合作可以提供相当丰富的信息。如果各团队没有想通过合作更好的实现组织目标的意愿（不仅仅是实现部门或团队的目标），这将会对团队认同感和团队流程维度产生很大影响。组织在不同领域衡量成功的标准往往会影响到产品价值维度。具体来说就是：是否应该更重视产品思维模式而不是项目思维模式。组织流程和政策中体现的控制机制可能对团队流程维度产生重大影响。第3步：为组织障碍创建有意义的透明度当发现组织存在的阻碍时，以有意义的方式使其透明化。只是说出某个阻碍以及它对Scrum团队的影响还不够。还需阐明这些阻碍会对组织产生多大的影响，可以利用步骤1中的方法来判断。这个阻碍在哪些方面使组织与其目标背驰？这个阻碍会耗费组织多少资金？从长远来看，牺牲掉的是什么？ 第4步：让组织参与有目的、经验性的变革你无法改变某个人，也没办法让组织发生变革，但你可以影响变革。影响变革的最佳方式是让受到影响的人参与其中。让他们去邀请、鼓励和支持组织参与。培养同舟共济的心理（运用你在步骤1中已经完成的工作）。欣赏那些有美好愿望并且希望获得成功的人。您已在步骤3中让阻碍透明化。那么现在需要你脑洞大开，提出各种解决方案。接收不同的意见（而不是认为只有你才知道解决阻碍的最佳方案）、乐于协商、多视角看待问题。排出优先级、小步走、有目的的进行实验、检验和调整。取长补短，从失败中快速成长。基于实证变革的敏捷指南是一个很好的免费资源，为您提供改进组织的经验过程。 第5步：做一个服务型领导，耐心地推动变革从组织规模和已有的架构和文化来看，有影响力的变革可能需要时间。坚定自己服务式领导的角色。如果大家知道你把他们放在第一位，而且在他们的成长和成功上投入时间和精力，他们就会选择跟随你。耐心且谨慎地推动变革，同时尊重他人，看到他人的亮点。一方面意味着挑战假设和约束，打破限制性信念，同时提高标准；另一方面意味着要勇于开拓，披荆斩棘，以身作则，指明努力的方向。这需要对参与其中的每个人都给予关注，表示同情。还需要诚信、守诺。 总结把Scrum的优势最大化通常意味着需要不断推动组织文化、工作流程甚至是架构的发展。将组织作为一个可以创造成功的资源，有效利用。 文章来源：Worktile技术博客 欢迎访问交流更多关于技术及协作的问题。 文章转载请注明出处。

什么是游泳车道图？泳道（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

采用Scrum敏捷方法本文的内容主要来自即能的一个小课程，包括我的一些笔记、整理和想法。传统项目管理 vs 敏捷管理不同于传统的一次交付产品的一部分，敏捷管理每一次交付的都是一个可用的产品。Minimum Viable Product：交付到用户手上的最小、可用的产品。 传统项目管理敏捷管理项目规模大小计划时长长短团队规模大小用Scrum进行敏捷项目管理铺垫知识…特殊角色产品负责人：需求列表的唯一负责人，代表各方需求；产品的最终负责人，指导团队前进方向项目负责人：服务于团队&项目经理，把控计划的落地执行；指导团队进行工作，移除团队工作进程障碍什么是燃尽图？抄自维基百科：燃尽图（英语：burn down chart）是用于表示剩余工作量的工作图表，由横轴（X）和纵轴（Y）组成，横轴表示时间，纵轴表示工作量。这种图表可以直观的预测何时工作将全部完成，常用于软件开发中的敏捷软件开发方式，也可以用于其他类型的工作流程监控。第一步：计划创建需求列表制定2-4周计划1. 创建需求列表估算每个任务的工作量按照优先级排序产品负责人需要根据业务目标、用户或客户需求以及其他利益相关者的需求创建一个需求列表，作为团队的待办任务清单。2. 确定要执行的任务产品负责人需要通过在需求列表中挑出高优先级的任务，确定接下来两周左右的目标。3. 开迭代计划会团队明确接下来2-4周要做什么讨论任务工作量有多大，怎么执行首先，产品负责人需要说明接下来的任务…然后，项目负责人把控会议进程，给计划提供建议…最后，整个团队一起评估任务，估算工作量，每个成员自己主动领取任务，确定可以完成什么，产出迭代计划第二步：执行每日站会跟进看板检查燃尽图1. 从“每日站会”开始项目负责人把控站会时间，控制在15分组以内，这是为接下来24小时的工作做计划，及时发现工作问题，促进团队执行。站会中，每个成员都要回答以下三个问题：昨天做了什么？遇到了什么问题？今天要做什么？2. 执行过程跟进看板执行任务期间，项目负责人带着团队跟进看板，及时发现工作流中的问题，及时解决。3. 检查燃尽图不断跟踪剩余的工作量，帮助项目领导和团队把控工作进度。第三步：调整评审会议回顾会议1. 开迭代评审会：做出工作调整在迭代快结束时，所有团队成员需要参与进迭代评审会，其中：产品负责人需要重新调整需求列表项目负责人需要把控时间，确保会议有效在评审会中，团队需要完成以下三个任务：检查在迭代中完成和没有完成的工作讨论执行过程中遇到的问题下一步工作如何调整2. 开迭代反思会：改进团队问题在迭代结束后，所有团队成员需要参与进迭代反思会，项目负责人把控时间，同时确保会议积极有效。在反思会中，团队需要思考以下三个问题：前一个迭代中，团队做得怎么样？有哪些地方存在问题？接下来如何调整？3. 开始新一轮的任务从用户获得反馈，基于反馈做出下一个迭代的计划，然后就能开始新一轮任务啦。

OKR与敏捷开发的原理有着相似之处，但已经使用敏捷的团队再用OKR感觉会显得多余。这种误解的根源就在于对这两种模式不够了解，运用得当的情况下，OKR和敏捷可以形成强强联合的效果，他们可以创造出以价值为驱动的团队，改变团队的工作方式。本文最后一部分分析了OKR的正确使用方法，以及如何赋予团队更多自主权。回顾第一部分请点这里：系列文章｜OKR与敏捷（一）：瀑布式目标与敏捷的冲突回顾第二部分请点这里：系列文章｜OKR与敏捷（二）：实现全栈敏捷使用OKR的正确方式与其他工具一样，OKR也可能会被滥用并沦为待办事项列表。但如果你想要专注于价值实现，那么你的目标就必须要体现这一点。因此你需要设定价值导向的关键结果：价值就像讲笑话：你没法告诉对方它到底好不好。价值导向的OKR不仅仅衡量结果。你还需要明白对你的客户和公司来说，什么样的结果才是有价值的。下面的例子展示了两种关键结果的差别：在敏捷中使用行为导向的关键结果会产生摩擦。既然敏捷团队已经有了明确的路线图，为什么他们还需要OKR呢？我遇到的所有尝试将OKR与敏捷相结合的团队，都在专注于开发活动本身。使用价值导向的OKR能够带来变革，它可以成为连接敏捷和精益的桥梁，弥补产品和开发之间的空白。改变侧重点尽管敏捷使用的命名法专注于交付。我们也需要抛开一些概念，比如“完工、燃尽图、速度”。与之相反的，我们应该专注于价值。我们不需要验收标准，需要利用OKR来定义成功的标准。从意见转变为数据敏捷并不是独立的数据驱动，而是HiPPO（HighestPaid Person’s Opinion）模式，即听从薪酬最高者的意见。《谷歌的经营之道》一书生动形象地描述了这个模式：这种敏捷模式下隐藏着一个巨大缺陷。即公司的利益相关者告诉团队应该去做什么工作，并对工作进行审查。罗恩·杰弗里斯（Ron Jeffries）描述了一场与利益相关者的虚拟对话：“每周你可以告诉我们你最看重什么，然后我们会告诉你哪些要求是我们可以实现的。一周之后，你就可以拿到我们的成果。如果你乐意，你就可以交付出去。”按照泰勒管理模式，由利益相关者来决定团队应该做什么，以及交付的成果是否可以出售。这种做法默认利益相关者知道什么具有价值，且他们的意见可以作为实际价值的衡量指标。但数据表明实际上正相反。例如，罗恩·卡哈维发表了一篇论文，对微软的一系列创意和结果进行了分析。结果，仅有 1/3的创意对期望指标在统计层面产生了积极效应。如果敏捷开发摒弃了数据统计和成果衡量，转而选择HiPPO（听从薪酬最高者的意见）来决定应该开发什么功能，那么其误差将超过66%。很多公司还在使用“客户意见至上”的管理模式。这种模式中，个别人的意见代表了终端客户。在过去这个做法尚且行得通，因为在数据采集上很困难。但到了数字化的现代社会，这已经成为了瀑布模型的又一个遗留问题。用实验取代HiPPO模式事实上，开发团队不需要个别人来代表客户的意见。因为团队可以自己采访客户以判断开发行为是否得当。OKR可以取代HiPPO，通过实验让团队学习和复盘。OKR可以帮助团队采用假设驱动开发模式，巴里•欧莱礼将其描述为：我们认为……可得到……当……我们有信心继续进行……在这个模型中，复盘不再是为了展示可交付成果。团队在复盘中通过讨论主题和主要假设来不断完善交付成果。赋予团队自主权命令与控制依然存在。命令与控制心理依然贯穿敏捷交付的全过程。利益相关者有权决定开发什么功能。因此，团队的工作模式依然是“因为这是山姆说要做的”，直到“山姆觉得不错”之后才算完工。公司发展需要团队全身心的奉献，所以他们需要理解公司的业务问题并能够就构建内容发表意见。马蒂·卡根曾写道：“如果你只让你的工程师写代码，那你只得到他们一半的价值。”为了赋予团队自主权，你要给予他们自主决定如何实现预期成果的自由。因此团队的目标也需要改变：玛丽·帕彭迪克（Mary Poppendieck）曾写道：“或许敏捷开发实践最大的缺陷是哪个来团队决定做什么的方式。在很长时间以来，人们认为团队本身并没有责任来回答应该做什么这个问题。”团队不需要执行由利益相关者提出的瀑布式计划，他们可以利用双轨敏捷和设计冲刺等方法来发现有价值的产品。原文作者｜Felipe Castro内容编译｜Worktile文章来源 | Worktile官方博客文章转载在请注明出处。

OKR与敏捷开发的原理有着相似之处，但已经使用敏捷的团队再用OKR感觉会显得多余。这种误解的根源就在于对这两种模式不够了解，运用得当的情况下，OKR和敏捷可以形成强强联合的效果，他们可以创造出以价值为驱动的团队，改变团队的工作方式。本文第二部分介绍了如何实现全栈敏捷。回顾第一部分请点这里：系列文章｜OKR与敏捷（一）：瀑布式目标与敏捷的冲突全栈敏捷想要实现业务的敏捷性，公司需要确保各层级的敏捷性。以此来替换公司传统组织架构的各个层级：在全栈敏捷中，组织各个层级的架构转变为：文化以激发团队的自我驱动力为基础。不再控制各团队详细的计划，而是以公司使命为总纲统领全局。领导们只需“明确最终结果和目的，尽可能减少对团队的约束。”战略以数据为驱动，动态迭代并侧重验证假设。目标将遵循敏捷模式，使用OKR。策略运行‘故障检测’实验，形成较短反馈周期。运营则使用敏捷开发模式。图为Worktile敏捷开发示意图重构组织债务技术债是大多数软件工程师都熟知的问题。 技术债的来源主要是团队想走捷径，而技术债将导致代码难以更改且无法扩展。技术债是要偿还的，并且还有利息。为了解决技术债问题，团队需要重构代码，在不添加新功能的情况下完善内部架构。渗透了敏捷交付思维的瀑布模型将导致组织债务，就像技术债那样，组织债务会导致公司变革艰难且需要付出代价。为了实现全栈敏捷，公司需要填补组织债务，因此需要重构各层级的组织架构。但是说起来容易做起来难，许多公司的尝试均以失败告终。那么，最好的办法是什么？从强调“思维模式”到注重“体系架构”许多敏捷开发圈子的人都认为，解决问题的唯一方法是思维模式的转变。好像只要我们改变了组织的思维模式，所有的问题就可以迎刃而解。仅关注思维模式的转变是很危险的，因为它不具备行动性。“‘思维模式’好像已经取代了‘价值’和‘使命’，成为避免老生常谈的最新行动” ，戴夫·斯诺登（Dave Snowden）曾写道。另一种解决方法是专注于能够改变公司运作方式的实际行动。斯坦福大学詹姆斯·马奇（James March）教授提醒我们说：“领导力不仅涉及诗和远方（愿景）还要注重体系架构。” 当然“诗和远方（愿景）”确实很重要，但很多公司却忘了体系架构：也就是公司的体系和流程的建设。改变公司的体系架构流程复杂还有花费很多时间，但成功之后，收益远大于付出。有一个工具可以帮助改变‘组织的体系架构’并实现业务敏捷性。 这个工具就是OKR（目标与关键结果法） ，这一目标架构已被谷歌和Spotify（流媒体音乐平台）等公司采用。图为Worktile OKR示意图OKR与传统计划方法的最大区别是什么呢？ OKR需要定期设定及评估——通常每季度一次。此外，与自上而下的单向目标设定流程不同的是，OKR是双向的。这就意味着团队可以根据公司的总体目标来设定自己的OKR，并在与上级沟通和探讨后使用。这种管理模式营造了一个鼓励团队参与目标设定的大环境。他们对自己参与设定的目标具有更强的责任感，并且还会每周一次进行跟踪和复盘。如运用得当，OKR能够帮助公司实现全栈敏捷。创建价值驱动团队实现全栈敏捷的关键就在于要专注于价值。问题在于，整个公司的架构以完成上级规定的任务为重点。而敏捷则以交付为重点，二者结合将导致公司沦为以交付产品功能为重点的功能工厂。这种对交付的痴迷由来已久。从软件开发行业将可运行的软件作为衡量进度的标准开始一直持续到现在。正如杰夫·萨瑟兰（Jeff Sutherland）的书名所说，Scrum是“一门能够让软件开发事半功倍的艺术”。因此，看板上实际少了一栏，即“可行性”，如下面来自约翰·卡特（John Cutler）的图所示：只有在增加价值的情况下，“完成”才具有意义。事实上，未改进指标的功能可能会产生负面效果：新提交的代码可能存在缺陷，需要维护，并且会导致产品变得更加复杂。尽管《敏捷宣言》存在误导性，但其中一位作者马丁·福勒也对成果进行了论述：“解决瀑布模型问题的关键是要认识到，敏捷主义者更重视成果而非功能。功能列表是非常有价值的工具，但并不意味着最终目标。真正重要的是总体的成果，因为我认为这对客户来说才是有价值的。”你为什么要做这个？关于团队激励，亨里克·克里伯格（Henrik Kniberg）展示过一张很棒的PPT：第一个团队代表了功能工厂。 这种模式下团队无法自主确定应该做什么，团队之所以从事某种工作是因为有人要求他们这么做。这种模式遵循泰勒管理模式中的计划和执行相分离的原则，这既会让团队丧失动力，也无法激励创新。而第二个团队则走了另外一个极端，即仅凭“直觉”行事。而第三个则是价值驱动团队。 这样的团队会专注于价值的交付，并且知道如何才能发挥最大作用。他们有清晰的目标，并且能够让自己的工作与公司战略保持一致。TBC……原文作者｜Felipe Castro翻译｜彭相珍文章来源 | Worktile官方博客文章转载在请注明出处。

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

OKR与敏捷开发的原理有着相似之处，但已经使用敏捷的团队再用OKR感觉会显得多余。这种误解的根源就在于对这两种模式不够了解，运用得当的情况下，OKR和敏捷可以形成强强联合的效果，他们可以创造出以价值为驱动的团队，改变团队的工作方式。本文第一部分介绍了瀑布式目标与敏捷之间的冲突。功能工厂敏捷的诞生是为了确保软件的交付，可以替代瀑布式开发来管理软件项目。敏捷模式注重的是可交付成果（开发需求或软件功能）而非项目价值（业务成果）的管理。事实上，敏捷中并没有单独跟踪结果的规范。《敏捷宣言》本身具有一定的误导性，因为它告诉人们要衡量可交付成果，它的第七条原则规定：“可工作的软件是进度的首要度量标准”。该原则默认所有可使用的软件都有价值，这显然是错误的。因为有些项目能够产生价值，有些不能；用户可能会采用软件的某些功能但却会摒弃其他的功能。大多数公司陷入了“功能工厂”模式，其团队压根不关注交付产品的价值。正如约翰·卡特勒（John Cutler）所描述的那样，开发人员就像流水线的工人那样“坐在工厂里，批量制造各种功能，然后传送出去”。马蒂·卡根（Marty Cagan）强调过这种模式可能导致的可怕后果：“开发团队忙着具化细节、写代码和测试。他们对更大背景知之甚少，甚至不太相信自己的产品真的能成为解决方案。他们不在乎这些功能是否真正解决了潜在的业务问题。因为他们衡量进度的标准是输出而非成果。”距《敏捷宣言》发表已经过去15年了，大多数公司使用敏捷只是为了交付，而在缩放框架上几乎没有什么帮助。因为他们选择这条阻力最小的路并且专注于改善软件开发过程。也正因此，几乎很少有公司能够真正实现公司业务的敏捷性。敏捷交付我喜欢把公司看成是一个包含了五个层级的架构，即文化、战略、策略、运营和目标。公司目标反映公司的工作和运营方式，因此它也会渗透到其他四个层级。传统公司的组织架构图示如下：在传统的公司架构中，各个层级的特点分别是：文化是自上而下的，是指挥和控制。战略是静态的年度计划。目标遵循了瀑布模型。策略通过豪赌模式和长反馈周期产生作用。运营则使用瀑布式开发和项目管理模式。通常，公司采用的敏捷，是指敏捷交付功能。仅仅只是用来替换公司最底层的架构：敏捷交付仅在运营层面实践精益和敏捷性。当团队进行分散的实验时，敏捷取代了瀑布式开发，这也就导致团队无法形成实验文化。尽管各处都开展了一些A/B测试，但许多高风险假设未能得到验证。鉴于敏捷交付不涉及其他层级的架构，因此其优势变得越来越小， 瀑布模型的缺陷与公司敏捷性的实现之间存在直接冲突。瀑布式目标在设定目标时，瀑布模型的思维模式仍然十分常见。公司通常会以年度为单位，自上而下地规定一系列静态的目标，而这与公司保持敏捷性之间存在直接冲突。瀑布式目标遵循了静态的规划模式。通常由一群高层管理人员集体制定公司的年度目标，然后逐级向下传达，并最终形成公司该年度的固定计划。没什么能比瀑布更形象地描述这种自上而下逐级传递目标的设定模式了！这种静态的模式包括下列几种假设：可以提前明确整个计划的全部步骤；绝大多数计划都是正确的；市场状况基本保持不变；变动会很小。公司会在年中审核的时候处理这些细微变化，并在之后制定一个更新后的详细静态计划。以项目为基础的瀑布式目标更糟糕的是，瀑布式目标不关注价值，因为它们反复围绕着管理层批准的一系列项目而设定。弗雷德里克•泰勒（FrederickTaylor）曾写道： “每个员工的工作都应该至少提前一天由管理层详细规定出来。” 如果他得知当今的公司依然遵循着他的教导，想必会异常欣慰。在泰勒的敏捷管理理论中，团队存在的意义就是为了完成项目的交付。管理人员将严格按照流水线工厂的模式来规划工作。这种管理模式将导致公司反应迟缓、难以适应变化，同时还会增加风险和浪费。在敏捷交付中，大多数的缩放框架都是能够取得一定成效的，因为他们着重通过敏捷的思维方法来推动瀑布式计划的实现。由静变动的计划信奉静态计划模型的人就像是苏联时期的中央领导人，他们制定5年计划方案，认定自己可以预测未来。相较之下，动态计划则拥抱变化。他们在一个较小的计划周期内运转。动态计划假设市场条件和计划本身都会发生变化。更重要的是，我们对问题的理解将伴随着了解的深入而变化，而计划也会做出相应调整。正如肯特·贝克（KentBeck）所写的： “一成不变地按照既定计划行事的唯一方法就是拒绝学习、固步自封。”你希望团队可以在更短的周期内更新迭代并检验假设，那你怎么能效仿苏联通过瀑布式流程来设定一系列的静态目标呢？这样肯定行不通，尽管我们在交付层面实现了敏捷，但在其他方面依然使用瀑布模型。我们需要改变。TBC……原文作者｜Felipe Castro翻译｜彭相珍文章来源：Worktile官方博客文章转载请注明出处。

我们收到很多问题询问如何把OKR和其他框架结合起来使用，以便管理组织的人员、流程和活动。软件开发公司最喜欢用的框架之一就是Scrum，Scrum是一个诞生于20世纪90年代的软件开发框架，我们公司内部一直在使用这一框架。Scrum的优点以及为什么它能优于瀑布流开发相较于瀑布流开发的其他传统框架，Scrum最大的优点是关注持续快速迭代以及对变化的适应性。 如果使用瀑布流开发，在项目一开始就要确定项目结果，并且要对此达成一致，通常还要有详细的范围和项目规范。项目计划是从这些规范中产生的，方法是通过以项目在未来的完成情况为出发点，向后推进，以线形的方式规划出时间、预算和依赖性。靠这种方法做出的成品是一份路线图，概述出到软件推出之日为止，需要完成的软件开发工作。那么不足之处是什么呢？如果在软件开发过程中出现了变动，时间线，依赖性，以及在大多数情况下连预算都需要完全重做，实际上就破坏了计划。与此不同，Scrum关注的是为了达到一个理想终点的持续快速迭代。取代详细计划的是精益规范或者是需求和回顾会议，这些会衡量每一次迭代成果。这些回顾应该围绕一个问题： “ 我们所做的工作有没有让我们离目标需求更近？ ”Scrum 的力量来自于它能够管理工作，实现一个未知的、独特的、或者前所未有的结果。 这一框架系统地、渐进式地问题解决过程。瀑布流开发与此不同，只有在其所涉及的过程和工作都是可预测的，并且此前已经有人尝试过的情况下，瀑布流开发开发才能发挥最大功效。这其中的差别犹如建一座桥和建一艘火箭搭载船的差别。火箭技术相对较新，建造一艘火箭搭载船要有很多增量步骤，重复多次才能获得成功。美国太空探索技术公司（SpaceX）为了能让火箭在船上着陆所做的工作就是一个很好的例子。反之，人们对建桥这一工程难题的理解十分透彻，也已经无数次解决过这一难题。建桥不需要重复很多次，对时间和成本规划的要求高，而这是瀑布流开发经常应用的领域。OKR和Scrum的异同OKR和Scrum的相似之处在于 两个框架都需要有一人专门管理框架的实施情况 ， 称为“Scrum负责人”或“OKR负责人”。两个职位职责明确，他们的责任是保证团队依照框架行事。Scrum是一个高度规范的框架，有明确的职责和仪式。Scrum的益处包括透明性、项目可见性以及频繁沟通。团队集体决定他们在为期2周的一个短期“sprint”内能够完成什么样的工作，这也使得Scrum是一个很民主的过程。OKR也有一套规则，虽然这套规则不如Scrum的规则条理清楚。这些规则决定什么是目标O，什么是关键结果KR，以及如何把二者结合起来衡量目标的实现。和Scrum一样，OKR有时间表，但是比为期两周的sprint要长得多（季度和年度）。设定OKR首先需要做的是，公司领导决定需要实现何种目标，接着，团队设定自己的OKR，需要确保团队的OKR与公司的目标保持一致。如何把Scrum和OKR结合起来只要每个人都清楚两个框架的范围和参数，OKR和Scrum可以成功地结合在一起使用，效果也确实不错。我们在确立公司OKR后，会进一步落实实现OKR的行动方案。Sprints和行动方案能在行动周期内有机结合，促进团队OKRs的达成。为了能让这两个框架合拍，重要的一点是在每个季度开始的时候，一位OKR负责人和一位Scrum负责人与他们的研发团队坐在一起，决定需要在这个季度完成的最重要的事情（通常为3项）。由于OKR周期更长，目标更宏观，而Sprint涉及的更具体的执行层面工作， 因此需要首先考虑OKR。 要让OKR在这一阶段就能有效开展， 相对于强调对结果实现的追求，更应关注对结果的衡量 。 比如，如果你想要解决的问题是有缺陷的软件，那么，统计消灭了多少个软件缺陷就不是一个有效的关键结果。修复了一个缺陷，缺陷的数量就少了一个，但是如果有更多的软件缺陷被报出来，你就没有让软件变得更完善，你仅仅是在数自己修复了多少个缺陷。一个更好的关键结果应该是统计出现了多少缺陷，或者统计一个季度内出现了多少客户需求。如果这个评估指标的趋势有所下降，那么你就可以自信地认为你正在解决你最初想要解决的问题。设定了OKR的目标和关键结果后，就可以开始规划Sprint。在这一个阶段，重要的是要决定Sprint的周期。如果一个Sprint为期一个月，一个单一的Sprint目标很可能会直接对应开发团队3个OKR目标的其中一个。至于更常见的为期2周的较短Sprint，Sprint目标则变成OKR目标的行动方案。我们更推荐第二种方法，因为这种方法在连接两个框架的同时还保持了二者最初的目标，即 Sprint管理生产和代码传输， 而OKR设定目标，衡量评估工作结果 。但是，这也意味着每一个OKR都需要有自己的Sprint时间线。如果你有一个大型的开发团队在一个产品的不同领域开展工作，比如前期工作、后期工作和系统管理，这一方法就能发挥很好的效果。使用这种方法的话，每一个领域引导1个OKR和1条Sprint时间线，而整个小组内部有3个OKRs。对于规模较小，没有能力运转3条Sprint时间线的开发团队，我们也推荐这种方法，但是只需要专注一个单一的OKR即可。原文作者｜Rob Davies翻译｜周雁洁文章来源：Worktile技术博客欢迎访问交流更多关于技术及协作的问题。文章转载请注明出处。

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

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

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

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

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

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

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

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

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

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

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

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

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

Scrum vs Waterfall waterfall 开发流程：Plan -> Build -> Test -> Review -> Deploy缺点：Plan 需要在开发之前完成。 可能的风险：Plan 与预期不符，程序员Build,Test时对 Plan 的计划理解错误或为按照 Plan的计划执行。任何一个环节发生问题，都需要一层层往上追溯直到重新修改Plan。一旦有问题或者需求修改，可能会延长几月甚至几年的上线周期。Scrum 开发流程将一个项目划分为无数个可交付的小项目，每个项目按照 Plan -> Build -> Test -> Review 的流程进行。每一个可交付的项目称之为一个 Sprint, 一个 Sprint 通常为1-3周。 Scrum 开放角色划分产品经理： 负责整个产品的设计管理Scrum Master: 负责整个项目开发的流程与预期相符，保证开发流程的顺利进行开发 TEAM: 负责产品的开发Scrum 流程控制Product Backlog: 产品经理根据优先权顺序创建的需实现的功能，需求列表User Stories: 按照以下图示模板创建文档，帮助产品经理准确理解需求，设计产品，以及预估开发时长。 最高优先级别的user story 进入 Sprint Backlog 进行项目大小评估，划入下一个 Sprint 计划中。Burndown Chart: 展示 sprint backlog 的任务完成进度，Burndown Chart 为 0 时，表示任务的完成Scrum CeremoniesSprint Planning: 产品经理，Scrum Master, 和开发团队一起讨论 User Stories, 预估项目大小Daily Scrum: 每天汇报昨日任务的进度，今天的工作计划，以及项目中遇到的问题需要获得的帮助Sprint Review: Sprint 结束时的审查阶段， 开发 Team 向产品经理展示 Sprint 的完成结果，讨论以后可提高进度的方案Scrum 开发流程总结：项目经理根据 User Stories, 设计产品，将需要实现的功能列表按照优先级加入 Product Backlog -》 Scrum Master，产品经理，开发 Team 根据 Product Backlog 一起讨论哪些功能点进入下一个 Sprint -》 将讨论的需要实现的功能点加入 Sprint Backlog， Sprint Backlog 是一系列 User Stories 的集合 -》 执行一个 Sprint (1-3周)，并每日一个 Daily Scrum, 确保项目的运行 -》 一个 Sprint 的输出为预计可交付的产品 -》 执行 Sprint Review，开发 Team 展示完成的 Sprint 产品，讨论以后可提高进度的方案。 Introduction to Scrum - 7 Minutes ...

構建服務時可以使用許多敏捷方法，每種方法都有自己的一套工具和技術。本指南介紹了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分钟内重新开始工作，除非出现非常有趣的事情。