敏捷开发篇--Agile Development-自用

** 如有错误，感谢指正**

如有错误，感谢指正，请私信博主，有辛苦红包，拜“一字之师”。

请根据目录寻找自己需要的段落

导语：本博客为个人整理Java学习记录帖，如有错误，感谢指正。系统学习，欢迎持续关注，后续陆陆续续更新~
Java 交流qq群 383245788。群内有一些资源和大佬，欢迎进来交流。

本文旨在学习交流，个人敏捷开发学习心得-自用

内容来源：

1. 黑皮书-软件开发
2. 拉钩教育
3. 相关博客和学习视频

正文

敏捷理论

敏捷既可以说成是一种思维，也可以说是一-种方法，它旨在项目推进的过程中，帮助团队提高效率但除了敏捷，精益思想和看板方法也能够提高效率。

• 精益方法多用于企业管理，是面向全局性的战略级方法
• 敏捷和看板方法多用于产研团队，是面向组织级的

敏捷的三把利剑：价值观、原则和实践

• 敏捷思维是由是价值观和原则构成，并在敏捷实践中体现出来的。其中，价值观来定义敏捷思维模式，原则作为行动指导，实践也就是具体应用的过程。实践的部分是非常重要的，学习敏捷，最终都要落实到实际工作场景中，在这个过程中，要注意根据自身需求去选择最适合的实践方案。

敏捷宣言

• 个体和互动高于流程和工具；
• 工作的软件高于详细的文档；
• 客户合作高于合同谈判；
• 响应变化高于遵循计划。

敏捷宣言定义了敏捷是一种方法，但依据多年的敏捷实战经验，我们可以这样来理解敏捷，它就是用来应对 VUCA 时代不确定性商业环境的方法和实践。敏捷宣言是敏捷的价值观，它告诉我们两点：

1. 敏捷方法并不是凭空而谈，它源自实践积累，我们需要把握敏捷的核心，在实践中不断去探索更好的方法。
2. 敏捷方法来源于实践，它也应归于实践，帮助我们解决实际问题，而不是一个框住我们思维的框架，沦为思想牢笼。

敏捷的十二大原则

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须互相合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何提高成效，并依此调整自身的举止表现。

解释：十二原则是用来指导我们如何进行敏捷实践的，它明确地列出了我们在推进项目中会遇到的一些情况，并且说明了应该怎样去做，或者怎样做更好。比如第二条，它告诉我们要欣然地面对需求变化，这是因为在工作中，需求很容易频繁地变更，如果团队没有做好随时面对变更的心理准备，就很容易陷入沮丧之中影响了项目推进。比如第六条，它告诉我们面对面交谈是最好的沟通方式，这是因为有很多团队在工作中习惯用文字沟通，但是这样容易表述不清产生歧义，需要反复确认，增加了沟通的成本。

敏捷实践：

敏捷方法

Scrum 方法：Scrum 是现在最流行的敏捷方法 ，它主要是面向开发和维护复杂产品的。这个结构框架很好理
解，可以用“3355”来全盘概括，意思是 3 种角色、3 种工件、 5 种仪式和 5 种价值观。

DSDM 方法：DSDM 就是动态系统开发方法。它具体的实施思路是这样的：在时间进度和可用资源预先固定的情况下，力争最大化地满足业务需求（传统方法一般是需求固定，时间和资源可变），然后交付所需要的系统。对于交付的系统，必须达到足够的稳定程度，确保可以在实际环境中运行；对于业务方面的某些紧急需求，必须做到在能够在短时间内满足，并在后续迭代阶段中对这些功能进行完善。
水晶方法：一种提倡机动性的方法，包含具有共性的核心元素，每个原色都含有独特的角色、过程模式、工作产品和实践。发明人将水晶方法细化为透明水晶方法论（Crystal Clear）、黄色水晶方法论（Crystal Yellow）、橙色水晶方法论（Crystal Orange）以及红色水晶方法论（CrystalRed）。这几种水晶方法论按照项目重要程度以及参加人员规模来进行划分。
水晶方法更强调组织，它会教你如何进行组织转型，同时也是一套可以根据不同的组织进行“因地制宜”裁剪的方法。
特性驱动方法：特性驱动方法简称 FDD，它是一个模型驱动（model-driven）、短期迭代（short-iteration）的过程，也就是说 FDD 是一个开发过程，过程就有起点和终点，FDD 的起点是创建一个全局的模型轮廓，通过两周一次的"特性设计-特性实现"的迭代，逐渐丰富模型功能内容。
特性驱动方法在平常地工作中使用较多。它最大的特点是需要一个全面的架构，这意味着设计和建模已经非常清晰了，所以它比较适合不需要试错的产品，也就是说需求范围很确定的项目。
自适应软件开发方法 ：

1. 基于复杂自适应系统理论，改善软件推测、协作和学习过程，建立新的价值观：自适应比优化重要；
2. 关注人（技能）和交流，将开发过程放在第二位，关注工作的软件而不是文档，它强调和客户协作及对变更的适应；
3. 定义以人为本的、领导-协作管理模型。领导的重点不是指令，而是创造一个文化氛围，使自适应和协作能够有效运行，除此之外，还要创造一个协作结构，使多个团队能够进行有效沟通。

它是更加适合需求多变、开发期短的软件项目。可以说它就是敏捷的雏形，但是更适用于开发内部，这是因为它不强调交付的价值，也没有过多关注到市场和用户的变化。

持续集成方法：持续集成方法是一种工程实践方法，具体来说就是每当开发人员提交一行代码，就能通过机器自动编译、自动测试，然后自动发布。开发团队通常每天集成一次，就能产生一个新版本供团队和用户体验，其目标是通过快速产生的版本可以尽快把问题暴露出来，进一步提高开发生产的效率。

最佳实践

我们是通过这些具体的内容来评判是否是最佳实践的：

1. 稳定的团队：我们需要稳定、有默契的团队，即在很长一段时间内团队成员是固定不变的。
2. 可预见的速率：我们需要在一个迭代当中形成团队的速率，方便知道下一个迭代我们可以做完哪些工作。
3. 单件流：我们需要集中精力一次做好一件事情，所以不欢迎并行任务。
4. 质量内建：我们需要在每一个环节保证好自己的质量，不让质量问题留到下游。
5. 日事日毕：我们需要把任务粒度拆分成至多1天，以方便每天知道我们的工作进展。
6. 设有紧急停车带：我们需要给紧急任务加上紧急停车带，以便分析紧急任务的插入情况。
7. 滚动迭代：我们需要通过迭代交付来完善我们的产品。
8. 持续改进：我们需要通过回顾和总结，不断强化我们的团队能力。
9. 尽早交付：我们希望尽早交付版本，更快得到用户反馈，以便于更快满足用户所需。

需要注意的是，我们要认清自己与最佳实践的差距，不可一蹴而就。要针对自己的实际情况，按照需求进行裁剪，避免形式主义，不要为了敏捷而做敏捷。

敏捷转型-项目的生命周期

项目的生命周期是来描述项目从概念到完成的整个过程。整个项目生命周期包括五个过程组。

1. 启动过程组：是一个包含了获得授权，并定义一个新项目或现有项目的一个新阶段，然后正式开始该项目或阶段的过程。 比如，我们在开始做斗地主第一个手游版本之前，会先论证市场、竞品和用户商业模式，然后形成结论之后输出项目章程。在这个过程中，我们投入的资源会比较少，只有制作人、产品负责人和项目经理，以及几位研发领导；
2. 规划过程组：是通过明确项目范围和优化目标，为实现目标而制定行动方案的一组过程，使团队工作能够有序发展。比如通常我们的项目会分成四个阶段计划：Demo 阶段、基本功能实现、灰度发布和正式发布，每个阶段都有其范围、资源投入情况等；
3. 执行过程组：是通过完成项目管理计划中确定的工作以实现项目目标的一组过程。在这个过程里，我们主要需要关注的是信息沟通和项目进展；
4. 监控过程组：是指通过跟踪、审查和调整项目进展与绩效，以识别必要的计划变更并启动相应变更的一组过程，使得项目朝目标方向进展。这个过程我们主要控制四个方面：范围变更、质量控制、状态报告及风险应对；
5. 收尾过程组：是指为完结所有过程组的所有活动以正式结束项目或阶段而实施的一组过程。这个过程组的主要价值是可以总结项目过程中得到的教训，并对此持续改进，帮助我们在今后的项目中完成得更好。

在实际的工作中，我们遇到的项目多样，需求情况是不同的，所以人们根据不同项目的特点对它们进行了归纳，总结出了四种项目生命周期：预测型、迭代型、增量型、敏捷型。我们可以根据自身项目的特点来选择合适的类型，帮助我们更好地推进，也就是说我们可以以此来判断项目是否适合敏捷方法。

预测型生命周期

首先是预测型生命周期，通常我们所说的项目生命周期其实就是指预测型生命周期。预测型生命周期是以分析、设计、构建、测试和交付为顺序的方式执行的，这要求我们制定详细的计划，什么时候启动项目，什么时候结束项目。在此过程中，我们尽量限制变更，以至于我们需要成立变更委员会这样复杂的机构来处理每一次变更的审批。因为这样项目尽可能地减少了处理变更带来的成本，有利于最小成本地交付产品。
在项目刚开始制定计划时，团队必须考虑到各种项目制约因素，并将这些制约因素加入风险和成本计划当中。这样当我们在执行计划时，可以严格控制对这些计划的影响，尽量少让项目产生变更。
因为预测型项目强调顺序执行，所以通常不会在项目过程中交付产品或服务，这样会产生一个较大的风险，就是一旦对客户需求理解不够，或对需求产生了分歧，那么前面做的很多工作将付之一炬。

迭代型的生命周期

早期的互联网项目大多属于迭代型生命周期。它在项目过程当中就会产生交付，我们可以在过程中获得反馈，然后收集这些反馈进行归纳、提炼，随后形成新的需求，再把这些需求放在下一个迭代版本中完成。这样我们就可以通过原型验证或概念验证的方式来帮助我们改进工作成果。这样做的好处是可以减少项目的不确定性。
迭代型的生命周期整个过程包括需求分析、分析设计、构建测试和价值交付，它的特点集中在中间的分析设计和构建测试的过程中，此时我们需要不断快速打磨以完善我们的产品。这样就能通过快速迭代来尽早修复问题，而且修复成本就会变得更小。如果项目中需求频繁发生变化，或者我们认为客户的需求不是很确定时，就适合采用迭代型生命周期，因为迭代型生命周期更关注构建原型和优化改善，而不是为了提高交付速度。

增量型生命周期

增量型生命周期，它可以向客户提供完成的交付成果，让客户能够立即使用。许多企业或客户更愿意团队在项目过程中交付，而不必等到所有需求全部完成。当我们交付一部分解决方案时，客户就已经能够使用了，我们把这种少量交付成果的生命周期称之为增量型生命周期。
项目团队在开始之前就会计划好每一次我们要交付的成果，在开始之后他们会尽快完成第一次交付任务，在实际的工作中，有可能第一次交付时间为一周，第二次交付时间为两周或三周不等。随着项目的继续，团队可能会发现，最终交付的成果可能与刚开始计划的有较大偏差。但是团队不必在意这个结果，因为我们更重视更快交付价值来收集的用户反馈，相比如期完成计划内的需求，我们更看重客户对于交付成果的看法和交付价值。所以，只要结果是为客户创造了价值，我们就不必太在意最初计划的需求是否被全部完成。

敏捷型生命周期

敏捷型生命周期，它同时有着迭代和增量的属性，但是注入了敏捷的基因，所以是符合敏捷宣⾔的一种生命周期，它能够更好地应对更频繁的变更和交付项⽬价值。具体来说，它在迭代型的基础上增加了增量型对用户价值的分析，也就是说客户满意度将随着有价值产品的早期交付和持续交付不断提升。
所以在这种类型的生命周期中，我们会对产品进行增量交付，有节奏地迭代交付成果，这样客户能够在固定的周期看到我们的交付成果，并进行反馈，这会让我们团队对是否能满足客户所需变得更有信心，项目也能尽快得到回报。

生命周期特性对比
在你开始一项项目的时候，我们首先要明确项目的需求、执行方式、交付方式和最终目标这些内容

• 如果需求非常的明确，也就是说客户的需求在项目之初已经确定，并且不会随着项目的进行而改变，那么此时我们就可以确定，项目采用预测型生命周期来推进。
• 但是如果我们的项目需求是动态的，而且这个需求比较复杂并且充满了不确定性，需要内部在不断完善中来达成最终的交付，那么此时我们就要选择迭代型生命周期。
• 如果我们的客户想要根据部分成果来调整最初的需求，也就是说在整个推进过程中要注重客户的反馈，那么此时我们就要选择增量型生命周期。
• 但在现实生活中，情况往往不是这么简单，我们可能需要在频繁迭代的时候，考虑到客户的反馈，那么此时我们就要选择敏捷型生命周期，这里请你注意，因为敏捷型生命周期注重频繁的交付，所以对团队的要求很高，但是如果遇到大型项目，这样就会很吃力而且不太实际，而增量型生命周期是在固定的周期完成部分交付，就会更加适合。

敏捷方法看重的就是交付成果，所以结合上述分析，我们可以知道，当你的工作场景是预测型和迭代型时，那么你完全没有必要采用敏捷方法；当你的工作场景是增量型和敏捷型时，你就可以部分或全部转型敏捷。

敏捷实践方式：基于迭代和基于流程

基于流程的敏捷实践

基于流程的敏捷，就是建立在流程基础上的敏捷实践，项目开始时，团队会以客户价值为优先级，从待办事项列表中提取优先级高的若干个功能开始开发。它最大的特点是：每次迭代必须要把所有的功能做完。在这种实践中，团队需要评估本次迭代的总工作量，因为每次选取的功能不尽相同，而总工作量也不同，那么每次的迭代时间也不同。如果这样的项目需要频繁交付的话，我们就只能在每次迭代前，尽可能地选择较少的功能进行开发。不仅如此，如果在迭代过程当中一旦出现变更，变更的工作量也会加到总工作量里，迭代的时间也会相应延长。所以团队要做出适当的进度计划，不能因加入功能过多而拉长了迭代的时间，让项目失去了灵活性

基于迭代的敏捷实践

在项目开始时，与基于流程的敏捷一样，团队会以客户价值为优先级，从待办事项列表中提取优先级高的若干个功能开始开发。它的最大特点是：每次迭代的结束是严格被时间框死的，也就是说，针对团队的迭代，我们要根据团队的能力，给定一个固定的可用时间。敏捷中把这种严格的时间节点称之为时间盒。我们要在时间周期内交付完整的功能，这就要求我们把需求相对独立地分开，并且严格按照价值排序，因为这样我们便可以灵活应对变更，一旦变更发生并插入当前的排序中，我们就可以把优先级低的需求从迭代中剔除，以保证固定的迭代周期。这样做的好处是，无论何时，团队当前迭代做的一定是最有价值的功能。

这两种方式最大的区别在于，基于迭代的敏捷就是我们平时所说的典型的敏捷开发，它规定了明确的交付时间，也就是交付时间是固定不变的。就像坐高铁一样，错过了时间就只能改签到下一列，这个发版日期交付不了就只能等到下一个发版日期。而基于流程的敏捷，它的范围是固定的，也就是说每次必须完成预定的功能才能交付。

混合敏捷实践

实际工作场景是非常复杂的，每个项目都有其独特的背景。我们就不太可能用单一的敏捷方法“一招鲜，吃遍天”。我们可以结合之前所说的两种敏捷实践方式，组合出适合团队的方案，这种行为就是“裁剪”，这种实践方式为混合敏捷实践。敏捷是帮助我们解决问题的，所以千万不要为了敏捷而敏捷，只有能够解决团队的问题时，我们才要导入敏捷。
裁剪，它不仅仅针对敏捷实践方式，其实对于敏捷方法来说也是一样，我们要针对团队问题灵活运用敏捷方法，也就是具体问题具体分析，对症下药，比如：

• Scrum 为 PO（Product Owner）、SM（Scrum Master）以及 Team（跨职能团队）的使⽤提供指导，包括 Sprint 计划、每⽇晨会、Sprint Review 和回顾会议。
• 看板帮助团队进⼀步提⾼效率，⽅法是将⼯作流可视化，使项目瓶颈更容易被察觉，以及通过调整 WIP（在制品限制）来实现流程管理。
• 极限编程 XP，运用⼯程实践如使⽤用户故事卡片、持续集成、重构、⾃动化测试和 TDD（测试驱动开发），针对开发过程可以提高开发效率。

针对适用场景裁剪
根据适用的场景来进行裁剪，主要就是这两种场景：预测为主敏捷为辅和敏捷为主预测为辅。
首先看预测为主敏捷为辅的。比如京东拼购，和所有电商平台一样，它内部具有首页、分类页、详情页、下单页、支付页和结算页等标准页面，我们在做基础功能的时候就可以先把这些页面做出来，这部分页面已经很成熟了，不需要用户再去验证了，所以京东拼购只需要在它的特色功能“拼购”和“分享”上下功夫，用这些页面去试错就行了。这就是典型的预测为主敏捷为辅。
而以敏捷为主预测为辅的案例，这种模型主要用在一些需要集成组件的工作环境中。比如腾讯广告的推荐算法，它是一套成熟的推荐体系，通常会嵌入到各种浏览器、新闻、小视频、游戏等平台中，对算法本身来说，它的功能需求和框架是可预测性的，但是集成之后，需要根据具体业务场景用敏捷的方式不断优化。

敏捷是一套自上而下的方法，落地时必须得到领导的支持，但有的领导可能只是简单地了解了敏捷的好处，没有接受专业的指导就让团队自己摸索并实施，反而会让大家感觉敏捷一些实践环节的增加（如每日晨会），成了团队多出来的负担，这时需要引入专业敏捷教练，帮助大家理解实施敏捷的真正目的。
为了避免团队成员对敏捷转型有所抵制，我们可以先解决团队面临的问题，在总结回顾会议上，告诉团队问题解决完之后产生的效果。当团队认可效果之后，我们再告诉团队是采用了哪些敏捷实践，让大家逐渐接受并认可敏捷方法。

转型敏捷的起点-敏捷思维

敏捷思维特点可以用三个词来概括：

1. 快速，雷厉风行，只有跑得比别人快才能保持优势；
2. 高效，只有组织高效协同，才能持续交付价值；
3. 试错，通过不断低成本试错，满足客户真正需要，才是必胜之道。

这就是敏捷思维的三个特点。我们在前面也曾讲过，敏捷实践的最终目的是在导入敏捷的过程
中，帮助团队建立起敏捷思维。

改变思维，拥抱敏捷

首先，我们要考虑如何才能让团队敏捷起来？这就需要改变思维，让自己与时俱进，时刻都准备好接受新的事务。无论你是否是团队的领导，只要你想敏捷，那么自己必须先要形成敏捷的思维习惯，用体系化学习掌握理解它，这样才可以更好地引导团队，所以这里我就有以下建议。

1. 保持一颗好奇心，对事物充满好奇。
2. 体系化地学习敏捷知识。

有了这种改变思维的自觉性，加上理论知识的支撑，你就可以在团队中引导或者说帮助大家敏捷起来。你可以从这三个方面来做：

1. 换位思考，在团队里我们需要多站在他人的角度去思考问题，而不只是着眼于我们自己的想法，站在对方角度思考问题可以使沟通更加高效;
2. 共同经历，指我们需要和团队成员一起经历工作之外的事情。比如：定期举行团建活动，比如登山或徒步，让大家在忙碌的工作之余不仅锻炼了身体还增加了彼此的认识，培养了团队默契;
3. 建立共同的目标，我们都希望在工作中团队和自我都能够得到提升，有了这个共同目标后，在日常的工作中协作便能够更加高效，正所谓人心齐泰山移。

用敏捷思维为团队分工

树立敏捷意识，从团队分工开始。践行敏捷，就一定需要按照敏捷思维进行分工，敏捷中最流行的 SCRUM 方法，包括三个角色

• PO（Product Owner）即产品负责人，一般由产品经理来担任。作为项目的第一负责人，他主要负责指导产品的方向，并对最终交付的产品负责。他需要将待办事项里的需求按客户价值进行排序，还要从客户那里获得产品反馈并告诉团队应该如何改善。产品负责人与团队开展日常合作，参加迭代计划会、每日晨会、评审会与回顾会等，并且为将要开发或交付的下一个版本设定方向。
  值得注意的是在敏捷开发中，产品负责人职能最大，他可以决定版本是否达到了发版要求。
• SM（Scrum Master）即敏捷教练，也被称为 Scrum 主管、团队教练或者团队促进者，一般情况下，由项目经理、研发经理或者质量经理来担任，在所有的敏捷团队中我们都需要有这个角色。
  敏捷教练应该具备这些能力：
  1 敏捷专家，具备丰富的知识和实践经验，能够带领团队顺利完成敏捷转型。
  2.障碍清除者，在敏捷实践过程中，能够帮助团队清除一些障碍，让项目如期交付。
  3.仆人式领导，能够将领导力从命令式转向服务式，帮助团队快速成长。
  4.变革的引领者，具有感染力，能够身先士卒，带领团队不断拥抱变化。
  敏捷教练更像是一只部队的政委，不仅个人经验丰富还能够带领团队披荆斩棘，持续交付价值。
• Team 即团队。敏捷中的团队通常指跨职能团队，这是敏捷实践中重要的一环。跨职能团队指打破职能界限，将团队中持续交付产品所需的所有角色，按照项目在空间上聚集在一起，大家共同负责该项目的 KPI，比如设计人员、开发人员、测试人员以及其他所需角色。跨职能团队往往能够在更短的时间，独立地交付高质量的产品，所以我们要注重建立跨职能团队。

如果把敏捷实践比作划龙舟，那么产品负责人相当于舵手，敏捷教练相当于鼓手，而团队相当于划船人。每个角色各司其职，大家认识到自己的职责所在，敏捷才能更加深入人心。

敏捷导入的过程中，正是敏捷思维在团队中生根发芽的关键时期，此时我们不仅要帮助大家更好地实践敏捷，而且要在行动中注重培养敏捷的自觉性，让大家既知其然又知其所以然，建议关注接下来所提到的这几个方面。

• 建立干净透明的环境
  在敏捷实践的过程中，团队需要一个干净透明的环境，是指信息和规则要透明，因为在敏捷实践中，因为复杂的层级会造成执行效率低下，所以敏捷鼓励我们让团队自己做决定，而团队需要清楚目前的信息和规则来做判断。作为领导，就要有意地创建这种环境。
  可以将团队尽量分成小团队来运作。这是因为小团队沟通更简单，管理成本更低。
  我们最好采用集中办公，就是指跨职能团队尽量按照项目进行组合，在物理位置上尽量坐在一起。
• 负责人发挥灯塔作用
  专注能够提升效率，这是显而易见的，而敏捷最注重的就是效率，所以如果你是敏捷转型的负责人，你就要肩负起灯塔的责任，为大家在黑暗中指明前进的方向。
  首先进行培训和开展交流活动，一方面敏捷方向的培训可以让团队建立一致的语言，具备体系化的知识，帮助团队了解为什么要敏捷以及如何实施敏捷；另一方面针对团队专业技能，可以帮助成员提升专业知识，让整个团队更加专业。
  其次是鼓励团队，庆祝团队的成功。团队在短时间内没有取得成绩的时候，我们要鼓励他们，说明这是转型正常会遇到的阵痛；取得了一些成绩之后，我们则要鼓励团队使其获得信心，让团队成员有信心承担更多的责任，并在组织中做出巨大的贡献。重要的是我们需要充分肯定团队并给予奖励。这样能创造出一种积极的氛围，我们的士气也会高昂，从而使团队效率更高。
  最重要的是让团队适当“擦伤”，就是遇到一些小问题我们不要马上就给出解决方案，而让他们自己试着解决，锻炼团队独立解决问题的能力。

从快速交付中尽早获得反馈
敏捷注重频繁的交付价值，通过频繁的交付我们可以得到及时的反馈，及时地修正方向，使产品朝最符合要求的方向发展，这套思维方式在敏捷中非常重要。可以建立一套快速反馈机制，让大家熟悉并最终熟练这个模式：

1. 整个团队根据所有的任务建立产品待办事项列表（Product Backlog）；
2. 产品经理从产品待办事项列表中选取价值高的需求列入迭代待办事项（Sprint Backlog）；
3. 研发人员用 1—2 周的时间快速迭代；
4. 测试完成后发布；
5. 产品经理收集用户反馈后整理成需求，并重复第 1 步。

自组织团队

自组织团队也叫作自管理团队或者被授权的团队。管理层授权团队自己管理自己的工作过程和进度，并且团队通过自己的方式完成工作。也就是说，自组织团队并不是完全自组织的，自组织也是在一定的限制条件下的自组织，离开了这一限制，自组织也就无从谈起。
对于自组织团队来说，他们需要做的是：

1. 自己分配任务，而不是等着管理层来给自己分配任务；
2. 团队自行考虑用怎么样的产品方案和技术手段来实现目标；
3. 团队自行制定需要遵循的行为准则。比如我们团队只有 3 条准则：开会自动交手机，迟到发红包，尽量不给别人“添麻烦”（即文档或代码自检）；
4. 团队需要向管理层随时报告进展和问题；
5. 团队成员自己管理自己工作内容，流转工作状态。

管理层如何组建自组织团队

自组织团队不代表彻底的自由，而是在管理层的战略下，有约束的自由。在组建自组织团队时，管理层主要需要做以下这些事情。

1. 确定团队目标和愿景，让团队充分理解我们要做这件事情的目的和意义，
2. 确定团队上下文，即组织结构、团队结构、团队组成，组织结构是服务于业务的，只有好的组织架构和绩效方式，才能让自组织团队保持高效。
3. 提供环境和支持，主要是安全感、良好的团队空间、氛围和技能辅导等。
4. 适当放权，给予团队自治权，让团队自我管理，比如每个人确定个人的工作任务、团队商议迭代周期等。管理层一般不插手团队的执行过程，只有当团队成员需要帮助时，才需要反馈给管理层，让其提供帮助。
5. 训练协作，管理层需要通过实操让团队“练兵”。给团队制造一些“意外”，让团队自行处理和总结经验，借此来锻炼团队应对“意外”的能力。

自组织团队实践

基于自组织的前提下，我们接着需要做什么呢？那就是待办事项，也就是汇总未开始安排的任务，由自组织团队共同创建并维护。
创建待办事项列表：
待办事项列表可以让我们把控项目推进的过程。在创建时，我们应该从团队的角度出发，以团队为衡量。列表要详细得将任务展示出来，所以应该包括任务详情，它的价值以及所需要的预估工作量。除此之外，列表是用来帮助我们推进项目的，所以列表中要将具体的执行步骤写清楚。综合这些考量，一个待办事项列表应该包含 ID 、类型、名称、价值、优先级、工作量和执行计划这些内容。
其中类型是根据其来源来划分的，通常是这三种类型：

1. 用户故事，即站在用户角度写的需求，通常由产品经理撰写；
2. 外网 BUG，即外网曝出的 BUG，通常来自数据或用户反馈，需要测试人员确认；
3. 开发任务，即开发人员撰写的任务，如数据库设计、系统重构任务等。

分类型可以帮助我们根据当前的主要任务，更快地选择相应的待办事项来完成迭代的目标。如我们这次迭代目标是解决大量外网用户的投诉问题，那么我们就在外网 BUG 类型里面选择待办事项。
团队进行讨论，明确需求的背景、价值，以及是否有现成的解决方案，进而确定是否需要纳入待办事项列表。然后纳入待办事项
根据优先级对待办事项排序，待办事项的提出者要给待办事项加入一个优先级.
对需求通过增加、删除、分解或合并进行整合。如果需求较复杂，我们需要关注它的完整性，尽量用一个需求来覆盖多个用户场景。如果可以拆分，就把需求拆成更小的单元，以便于更灵活地进行排期处理。
自组织团队共同对需求所需要的工作量进行估算，也就是每个人都要进行估算并给出意见。敏捷一般按照估算扑克来估算，当给出的估算值之间差距大于可接受范围时，估算数值大的人和估算数值小的人要各自陈述自己的意见，说明是什么原因促使自己做了相应的估算。通过这种方法，可 以让所有人都有机会发言，分享自己的想法，然后汇总得出大家都认可的结果
最后我们要发布这个列表，保证团队内外信息同步。

---

在做表的过程中我们需要注意以下几点：
Detailed Appropriate ，即适当的详细程度。待办事项的每一项描述清晰简洁，明确该事项是为解决哪类用户的问题、我们需要做什么以及做的价值即可。
Estimated ，即估算。待办事项要有一个大概的工作量估算值。值得注意的是，他与迭代计划的估算不同的是，这里的估算是只是负责人对工作的初步估算；
Emergent ，即涌现，指的是允许随时插入新需求，自组织团队可以积极应对变化；
Prioritized ，即考量优先级，指需要对每一个待办事项都排优先级，这样有新需求时，可以根据优先级进行比对，来确定放到表中哪个位置。
这个也叫做作 DEEP 模型，在完成列表后，我们还可以据此来衡量列出来的待办事项是不是合理。

---

维护待办事项列表
我们要插入一个新的待办事项

1. 分析：产品经理分析新的需求，确定是否放入待办事项列表中。如果确认可以则在表中新增一行
2. 排序：放入之后，产品经理需要评估需求的价值，并进行优先级排序
3. 理解：团队共同理解需求的描述。
4. 估算：团队估算该需求的工作量
5. 更新发布计划

迭代计划

敏捷和所有项目管理都一样，我们需要行动方案来指导我们达成未来的目标，计划可以帮助我们有序地推进，但是敏捷的计划频度相较于传统开发更加高频，敏捷的计划更加灵活，我们称之为迭代计划。
在敏捷中，我们要将上一个迭代中用户的反馈加入本次迭代当中，也就是说敏捷落地是一个闭环，从最初的演进阶段，根据待办事项列表选择优先级最高的任务，接着实施阶段去完成该任务，然后反馈阶段收集用户体验得到他们最真实的想法，最后优化阶段根据之前的反馈进行优化，这四个阶段周而复始帮助我们的产品趋向最佳，不断提高用户的满意度。在整个过程中，迭代计划用来帮助我们更加高效地推进。
时间盒是一种管理方法，即在预算时间内对完不成的功能进行删减或者延迟，而不是拖延预算的时间。一个好的迭代计划应该是在时间盒内尽可能排进价值最高的代办事项。

制定迭代计划

1. 确定迭代周期，这通常由团队自行决定，一般在 1~4 周之间。迭代周期主要取决于两个因素：敏捷成熟度（指团队敏捷实践的能力）和自动化程度，这两种因素程度越高，迭代周期越短，反之越长。
2. 确定一个迭代内的关键工作项，
3. 固定关键工作项的发生时间，比如我们用两周迭代，然后在第二周的周一进行需求评审，周二开始测试。我们通常用表格将固定关键工作项的发生时间列出来，放在团队都能看到的位置，大家需要共同遵守。
4. 培养团队的工作节奏感，大家根据上述表格来安排每周固定的会议，如需求评审会、迭代回顾会、迭代计划会，等等。
5. 如果待办事项的紧急程度不一致，可以在一个时间盒中设置多个发布节点，但是一般不超过2 个。如果有紧急需求，需要在迭代内进行发布，我们也可以灵活调整，让其发布，原则上不超过2个，因为迭代内太多次发布，整个节奏就会乱掉，那迭代节奏也就没有意义了。

迭代计划会议

先是确定会议目的，即通过会议我们要明确即将要开展的工作内容，讨论明晰待办事项的相关信息；其次是确定会议参与人，一般 Scrum Master 是组织者，PO和 跨组织职能团队均要参与；
接着是会议议程，这个过程比较相对复杂一些，我们稍后会详细说明；再次是通过会议确定迭代目标，我们可以把此目标放在团队显眼处同步；
最后是输出，即将结果做成迭代代办事项列表，这其实是待办事项列表的子集，因为它是从待办事项中选出的优先级最高的事项。

会议议程
我们先来看第一部分，明确要做什么。在这个部分我们需要换位思考，站在用户的角度，作为用户去使用产品，设身处地地从场景中提炼用户的痛点，这个过程也叫作讲故事。
在待办事项列表中，PO 会使用 MoSCoW 法则对任务来进行基于客户价值的优先级排序。此时我们就要从待办事项列表中，选出既能满足用户痛点，同时优先级较高的用户故事，然后支持用户场景落地，也就是实现这个功能。

MoSCoW 法则：
Must：必须要做的—功能集或Feature（特性）是系统的基础，没有了它们，系统将无法work或没有价值。
Should：应该做的—我们应该有的功能，这样子系统才可以正常使用，如果没有他们，系统将非常非常难用。
Could：可以做的—产品的附加值，加分亮点项。
Would not：不要做的–这个产品不需要的功能。
待办事项中标为 Must、Should 的事情我们要保证完成，Could 优先级的我们争取未完成 ，在发生重要变更的时候，我们牺牲优先级为 Could 乃至 Should 的事情保证变更。

其次就是明确我们怎么做，在这个部分我们需要先对选出来的用户故事进行工作量估算，我们可以采用故事点数和理想人天数来估算工作量；然后分解任务，遍历所有的用户故事，将其分解成团队成员可执行的任务，如分成前端任务、后端任务、联调任务、测试任务等，用户故事分解遵循谁认领谁分解的原则；最后团队承诺，任务分配到成员后，每次成员要承诺保质保量，尽可能做到不延期完成任务。

两种估算方式

• 理想人天数估算 这是一种个体估算。
  具体是指假设没有任何突发事件的理想情况下，一个开发人员完成该故事所需的工作量。这种方式实施起来比较简单，完成一轮估算所需时间较短，因为每个人都很熟悉自己的工作效率，所以这种估算方式比较主流。
• 敏捷更推荐使用故事点数估算，这是一种集体估算。

1. 建立团队共同认可的估算基准值，即团队对同一个需求要有一致的理解。这个基准值可以是完成一个需求的页面数，也可以是对数据库的增删改查次数，也可以是完成操作的步骤，一般完成单位功能基准值为 1；
2. 对同一个需求，每位成员都要给出自己的评估值，然后通过估算扑克方法同时呈现，因为是相对估算，我们基于斐波那契数列，把故事点数设置为 0，1，2，3，5，8，13，20，40，60。
3. 估算最低和最高的成员说明自己估算的理由。比如 A 认为这个需求点数是 60，因为 需求里涉及很多算法，而团队之前没有做过任何算法的工作。 而 B 认为需求点数是 5，因为他知道有第三方的算法工具可以直接引用。综合这些因素，团队考虑到 B 想法的可行性，最终决定对该需求评估是 5 个故事点；
4. 对同一个需求进行 2 到 3 轮估算，通常用 5 分钟左右就可以最终确定该需求的估算；
5. 重复第 2、 3 步，直到估算完本次迭代所有需求的工作量。

敏捷的执行和监控

清晰团队及团队外成员的职责

想要做到敏捷团队进展透明化，我们首先要做到使团队内外成员都清晰自己的职责。
敏捷团队主要成员 Product Owner、Scrum Master 和 Team。
要分清团队内部人员和外部人员的职责。团队外部人员指的是，对团队没有直接产出的人员，比如管理层、投资人和客户。对于外部人员来说，我们只需要参考他们的意见，交付他们想要的价值即可，并不需要让他参与到整个事情当中。

每日站会

在项目执行过程中，这是非常重要的一个工具。因为在每日站会上我们团队的信息得以流转，所以它可以帮助我们同步进展，同时及时暴露问题，并且能够及时纠正问题。

• 每日站会流程
  每日站会一般是这样的流程，团队一起围着白板这样的信息发射源站成一圈，然后每个人轮流发言。这里有两种发言格式，主要取决于我们的团队使用哪种敏捷方式。
  如果是基于迭代的敏捷，那么我们主要做的是同步进展和抛出问题，关注自组织团队的承诺。这时的发言格式是：昨天我做了什么？今天将要做什么？遇到了什么问题，谁来帮助我？
  如果是基于流程的敏捷，那么我们关注团队的完成程度，主要做的是上下流的协同。这时的发言格式是：我们还需要做些什么来推进这⼀⼯作？有⼈在做看板上所没有的事情吗？作为⼀个团队，我们需要完成什么？⼯作流程是否存在瓶颈或阻碍？
• 每日站会的具体规则

1. 团队人数不超过 10 名。因为沟通的路径是 N*(N-1)/2，这就意味着人数越多，沟通效率越低，所以我们应当尽量保持 10 人以内的小团队。
2. 需每天进行。敏捷的核心是小步快跑，因此我们把任务粒度拆分到1天内，每个人每天至少可以完成1个任务，这样团队每天都有新的进展，但是也会遇到新的问题，所以需要每日开展站会同步信息
3. 固定的时间且每次不超过15分钟。我建议在每天上午上班15分钟后开始，团队成员可以用 15
   分钟梳理昨天完成的工作。Scrum Master 要控制会议时间以保证效率。
4. 固定的地点。团队在固定的时间就可以到指定地点集合，更加快速、直接。
5. 需站立，这样容易集中注意力，大家在潜意识里容易想赶紧结束会议，所以就会提高效率。
6. 不解决问题。如果站会过程中解决问题，会让这个会议主题发散，我们把问题抛出来，在站会之后 Scrum Master 可以安排专项会议解决问题。
7. 相关人员都需出席，所有与项目相关的人员都需要出席会议。
8. 团队以外的人不能发言，以免不熟悉团队的外人干扰团队正常工作流程。
9. 可以使用“发言令牌”，如网球，毛绒玩具等，随机抛向团队成员，拿到“发言令牌”的成员才可发言。这样使得团队成员要随时准备下一个发言，大家会更专注。

擅用信息同步工具

敏捷注重高效，在团队中，信息快速同步对于提高效率非常重要，那么擅用信息同步工具就非常的重要

• 迭代版本日历
• 白板

交流方式的变化会对人们理解彼此的过程产生影响，我们在远程沟通时就需要有新的会议流程和行为模式

1. 议题的清晰度与会议的连贯性是视频会议成功的关键，我们需要事先协定好会议规程以避免混乱。规程包括发言的时间、用哪个统一的通讯平台。
2. 规定写得越清楚越好， 除非团队事先就已经定义好，否则少用一些英文缩写或专有名词。
3. 不要给团队发过多的信息，在发送之前，自己要仔细斟酌要表达的内容，避免产生歧义。
4. 注意团队中性格内向的人，这些人比较擅长书面沟通，远程沟通实际上是为那些不喜欢在集体中发言的人提供更公平的竞争环境
5. 最后，找一些远程庆祝和社交的方法，比如发微信红包、举办远程生日会等，增强团队的凝聚力和合作能力。

做好收尾

展示会

展示会（Sprint Review），又叫迭代评审。在展示会上，Product Owner 会验收本轮迭代成果，并做出决策即接受还是拒绝，这样就知道了本轮迭代最终是成功还是失败。
为什么要开展示会呢？这是因为借助展示会我们得以在成果发布之前提前验收，这帮助我们尽早知道成果是否能被接受，而且能及时发现有什么问题，就能更快地做出优化行动，防止团队产生方向性错误，又可以让客户更加满意；同时这种短期的成果产出，可以确保产品开发目标更加清晰，并且保持一致。

• 展示会流程
  首先，Scrum Master 要邀请相关人员参与会议，我们的团队包括开发人员、测试人员和 ProductOwner 肯定都要参加，如果有条件，最好邀请管理层和客户参与其中，这样有利于增强管理层和客户对产品的信心。值得注意的是，如果邀请了重要角色，我们需要提前做好内部验收和测试，避免“翻车”。
  会议开始前，Scrum Master 要搭建好评审环境，比如产品的运行环境、用于展示的会议室和投影、白板这些工具等。整个会议中，Scrum Master 不仅负责宣读展示会议流程，还要维持会议流程的正常进行。
  会议开始后，开发人员负责演示产出的结果即本次迭代内容，从用户场景的角度开始演示，在这个过程中其他参会人员可以就演示问题发表自己的看法，开发人员有义务回答提出者的问题，直到大家不再有疑问为止。在这期间，测试人员需要评估本次展示的质量。
  在完成答疑后，Product Owner 需要做出接受或拒绝验收此轮迭代的决定，如果拒绝就要给出理由，并且要求团队进行相应的整改。之后，Product Owner 会带着团队探讨下一轮迭代的内容，使大家对下一轮迭代有初步预期，必要时可以讲讲下一迭代版本的用户场景，比如，我们在本次迭代完成了支付功能的对接，下一迭代我们需要将重点放在用户活跃上，新增任务功能，预计日活将提升 10%

注意事项

1. 展示会议要控制时间，一般不超过 2 小时；
2. 为了让演讲环节顺利进行，需要相关人员提前准备好演讲内容；
3. Scrum Master 对会议需要有 Plan B，以应对现场演示环境设备出现问题等其他突发情况。

回顾会

在《敏捷宣言》的原则中这样描述回顾会：“团队要定期反省如何能够做到更加有效，并相应地调整团队的⾏为”。所以回顾会并不是为了责备，而是从之前的工作过程中学习经验，帮助团队学会持续改进。
一般是以下这几种情况开回顾会

1. 当团队完成⼀个发布或者加⼊⼀些功能时。此时，无论迭代周期的长短，或者要完成的功能多与少，我们都需要做回顾。
2. 当团队意识到出现问题，以及团队协作不顺畅时。此时，我们就可以开回顾会，帮助我们调整现有的工作模式。通过回顾会，我们可以收集出现问题的过程数据，然后分析数据找出根本原因，再讨论得到新的方法去解决问题。
3. 当团队达到任何其他里程碑时。我们可以通过回顾会更好地继续后续工作。
4. 当出现外网故障时，我们需要通过回顾会重现故障场景，分析当时的问题，团队讨论出解决方案，然后 Scrum Master 跟进解决掉。

• 回顾会流程
  回顾会议分为定量回顾和定性回顾两部分。我们需要先开展定量分析，这时需要展示两种数据。
  一种是结果数据，团队通过结果数据可以看到自己已达到的成果，这能够增强团队的信心和凝聚力，具体来说需要关注到以下这些数据。

1. 技术数据
2. 过程数据，包括 BUG 情况和团队速率
   另一种是过程数据，这让团队更清楚推进过程，具体来说需要关注到：
3. 收入数据
4. 活跃数据
5. 留存数据

定量回顾结束之后，我们就要进行定性分析。定性分析是为了找出团队过程中的改进点，具体的的步骤是：

1. Scrum Master 给团队成员发若干便签条；
2. Team 的每位成员在 10 分钟内至少要写两张，分别要写“做得好的”和“有待改进的”，而且在每张纸上只写一条意见以便组合分析；
3. Scrum Master 收集纸条，然后把做得好的贴左边墙上，把有待改进的贴在右边墙上；
4. Scrum Master 先点评做得好的部分，这种肯定可以增强团队信心；
5. 针对有待改进的纸条，Scrum Master 可以让填写人进行说明，然后将其按照问题类型归类，可分为需求问题、测试问题、开发问题、团队问题或其他问题；
6. Scrum Master 针对已分类的问题让团队投票选出 Top3 的问题，因为团队不可能一次解决完所有的问题，所以我们应该解决主要问题，然后每次迭代都做出改进；
7. Scrum Master 引导团队针对 Top3 问题共同讨论解决方案，并确定方案负责人和解决时间；
8. Scrum Master 把方案、负责人和解决时间作为会议纪要记录下来，并同步给相关人员，在后面的迭代过程中进行跟进，直到问题闭环为止。

绩效

如何科学有效地度量敏捷团队绩效呢？这主要从速度、质量和价值三个纬度着手

速度

首先来看速度，它包括需求响应能力和发布能力。敏捷注重效率，从字面意思来看就是速度，这里主要衡量团队是否具备快速执行的能力。
其中，需求响应能力是指敏捷团队对用户需求的处理和交付的能力，主要体现在业务需求前置周期和用户故事交付周期上，前者是由 Product Owner 负责，指的是用户需求从被提出到进行排期的时间；后者是由 Scrum Master 负责，指的是用户故事从排期到发布的时间。这两个周期越短，那么说明团队的需求响应能力越强
发布能力主要体现在集成测试周期、发布频率和解决发布问题的平均时间长上：

1. 集成测试周期是指从开发转测试到集成测试完成的时间，这个周期越短，团队的测试能力越强；
2. 发布频率指的是团队两次发布的间隔，间隔时间越短说明团队工程能力越强。
3. 解决发布问题的平均时长指的是，产品发布之后，从出现外网问题开始到每个被解决问题的平均时长，这考验了在发布并出现外网问题时团队响应和解决问题的能力。

• 这些数据通常可以在项目管理工具中找到，计算公式如下：
• • 集成测试时间=测试完成时间-转测时间；
• • 发布频率=本轮迭代发布时间-上轮迭代发布时间；
• • 解决发布问题的时长=问题解决时间-问题发现时间。

质量

质量是产品的核心，这个维度评分越高说明团队打造优质产品的可能性越高。
质量分为内部质量和外网质量。内部质量指的是产品在测试过程（包括单元测试、集成测试、上线前测试和线上测试）中产生的质量，体现在单位周期的遗留缺陷数和单个用户故事的缺陷数上，缺陷即 Bug。
这里单位周期的遗留缺陷数是指，在一个迭代周期内产生的缺陷在迭代完成时剩余的数量；单个用户故事的缺陷数是指，开发人员在实现一个用户故事过程中产生的缺陷数量。
我们通过加权计算缺陷数量。比如把缺陷按照严重程度分为致命缺陷、严重缺陷、一般缺陷、轻微缺陷和建议缺陷，通常它们的权重分别为 5、4、3、2、1，而这里的严重程度的衡量标准由测试人员给出，因为篇幅有限所以此处不做展开。我们依此标准统计相同程度的缺陷数量，缺陷数量越低，那么团队的内部质量也就越好。
外网质量指的是产品发布后，它在外网呈现的质量情况，这里涉及外网问题反馈和系统的年平均故障率。外网问题反馈指的是用户对产品质量的吐槽，这些很难做量化，通常我们会在产品论坛、贴吧、苹果 App Store 或者其他应用市场，以及客服电话和 App 本身的反馈渠道去收集用户的吐槽。一旦应用本身出了问题，一个用户就有可能会用多个账号在不同的渠道反馈此问题，所以我们就很难以用户反馈量来说明评估质量的下降情况，并且很难从吐槽当中评估问题严重程度，所以我们一般度量系统的年平均故障率。
系统的年平均故障率指的是，系统一年发生的故障时间之和除以一年系统服务的总时间，这个数值越低，说明团队开发的这套系统越稳定，质量越高。

价值

敏捷的核心就是价值驱动，价值纬度可以帮助我们衡量团队是否掌握了敏捷的核心，以及掌握的怎么样。
而价值用需求吞吐率和交付有效性来度量，具体来说，吞吐率是指单位时间内交付的业务需求数，比如一个迭代内，我们团队交付了多少个业务需求。交付有效性就是业务的需求价值。需求都会有价值，有的需求会有直接价值，比如提升了多少收入或者会增加多少用户数，或者用户活跃率得到了提升等，也有一些需求没有直接价值，比如提升了用户体验等。直接价值可以量化，但间接价值就没有办法量化了。所以团队在和自己做纵向的效度量时，更适合用到价值。
说完衡量指标接下来我们就看一下具体的做法，也就是绩效管理。绩效管理是指各级管理者和员工为了达成组织目标，共同参与绩效计划制定、绩效辅导沟通、绩效考核评价、绩效结果应用、绩效目标提升的持续循环过程。

绩效管理的误区

第一个，把绩效度量等同于绩效管理，其实绩效管理是各层管理者都必须关注的管理过程，它包括绩效计划、绩效实施、绩效度量和绩效改进。而绩效度量只是绩效管理中的一个环节，是一个有效的管理工具。
第二个我们需要注意的是，有些团队只把绩效度量的结果最主要用在发奖金和调工资上。虽然通过绩效管理，我们可以使薪酬分配从经验管理过渡到科学管理，但绩效管理对组织来说还有更重要的意义，我们可以通过绩效管理使员工的努力朝向组织的战略目标。具体来说，绩效管理可以让每个员工知道自己的成长方向。对企业来说，成功地绩效管理可以提高企业的绩效，让所有成员分享成功的果实。
如果仅仅为了发奖金和调工资，员工就可以按照你的标准展示出你想看到的。比如你想要降低千行代码的 Bug 率，那么员工可以从两方面着手：一是把原来可以用十几行代码完成的任务写成几十行代码，或者让测试人员私下提出 Bug，不把 Bug 记录在项目管理系统中。
第三个需要注意的是，不要过分追求全面的度量指标。除了我们前面所列的指标之外，还有很多可以衡量绩效的指标，比如每页需求的缺陷数，测试 Bug 的响应周期等。但是，衡量指标并不是越多越好，这是因为：

1. 过多的指标增加了数据收集的难度，使得数据收集的工作量大大提升；
2. 面对如此之多的指标，团队成员很可能无法照顾到每一项指标，即无法在各项指标上都取得较好的业绩。在无法全面完成的情况下，团队成员很可能会舍弃一两个实现难度比较大的指标，而这些指标就有可能是关键绩效指标。

最后一个需要注意的是，千万不要忽视绩效管理的真正目标，即帮助管理者持续的改进、提高绩效。有些管理者喜欢直接给不同团队进行绩效度量，以此来比较团队绩效水平的高低。但是，团队是个复杂的系统，大家做的业务、团队成员的能力，以及团队磨合的时间都不一样，所以我们无法用统一的标准衡量，因此我们应该聚焦到绩效管理的目标上。

如何从 0到 1 导入敏捷

转型管理驱动因素

通常公司都是因为某种动机而选择导入敏捷，我们管这种动机叫 转型管理驱动因素 。根据我多年的项目管理经验，转型的动机主要有两种。
第一种是 与加速交付相关 的转型。企业往往都是从百人以下的小团队开始发展，随着成长人数会越来越多，曾经的工作方式愈发不合适，组织效率就会越来越低，尤其是人数过千以后，管理者意识到要提高交付效率，加速交付过程，而敏捷可以帮助企业达成此目标，所以他们就想导入敏捷。这种状况多发生在互联网行业或传统软件行业，他们一般会以业绩成果来度量敏捷导入的产出。
第二种是 与敏捷方法相关 的转型。敏捷在中国已经推广了十几年，已经有很多公司导入了敏捷并取得不错的效果，比如腾讯公司。这就引起了其他大型企业的关注，如果敏捷能够使公司发展得更好，那为什么我不试试呢？所以他们也想导入敏捷，而且通常以改变协作方式为切入口，因为他们希望敏捷能帮助自己的团队与其他部门、供应商之间更频繁地交流与协作。他们比较重视敏捷过程的度量，比如某些环节的效率是否提升，跟同行业佼佼者比较还有多大差距。这种状况多见于银行业中。
针对不同企业的动机，我们也应该有不同的转型方式。如果是与加速交付相关的转型，我们更需要重视敏捷导入产生的结果，比如敏捷导入之后，是否优化了价值的交付，收入是否比原来有所增加，用户数量是否有所增加，用户满 意 度是否增强。如果是与敏捷方法相关的转型，我们需要对企业的成熟度进行度量，给自己树立一个行业标杆，辅导团队做过程改进，努力达到或接近行业标杆的水平

敏捷转型的影响因素

首先来了解不利于转型敏捷的消极因素，主要涉及这些情况：

1. 工作被分解为部门孤岛，从⽽创造出阻碍加速交付的依赖关系，而不是构建在能⼒中⼼指导下的跨职能团队，也就是说，部门墙越厚就越不利于敏捷转型；
2. 短期交付型的项目不适合用敏捷。比如我们承接甲方的需求开发，甲方要求交付的产品特别明确，其间产生变更也会以补充合同进行说明，交付时间也会清楚地写进合同中， 因为这个项目不存在频繁的变化，所以并不需要敏捷；
3. 团队优化的依据是部分效率而不是端到端的项目交付流或整体优化情况， 因为如果只想着提升研发效率，那么敏捷转型带来的效果是有限的，而敏捷可以带来的是全方位的优化，所以在导入的过程中，我们要着眼于全局；
4. 员工属于特定领域人才，实现技能多元化的工具或激励有限，不重视培养T型专家⼈才。因为敏捷是跨职能团队，每个人除了自己的领域之外，最好还有其他领域的专业知识，比如开发工程师具备产品思维。 敏捷鼓励 T 型专家人才，即 在某一领域具有专长，同时又能在其他多个领域有一定的经验和见解的人 。 如果团队只是强调培养特定领域人才，这就只是在培养螺丝钉， 并不能为跨职能团队带来很多收益；
5. 分散化项目组合即使员工同时分配到过多的项目，而无法专注于单个项目。敏捷宣言提到“可工作的软件胜于面面俱到的文档”，说明敏捷团队提倡简化文档。正是因为这点，所以我们要使团队保持稳定，主要就是团队成员相对固定，如果员工分配到过多的项目，就会打破这种稳定的团队结构，敏捷转型也就很难获得成功。

其次，我们来看能够推动敏捷转型的积极因素，主要涉及这些方面：

1. 管理层具有强烈的转型意愿。任何转型都是自上而下的，敏捷转型也不例外，管理层的转型意愿越强，企业的敏捷转型也越容易获得成功；
2. 员工的认知和改变意愿。如果员工在认知上认可敏捷，认为 敏捷转型能解决自己目前的问题，且愿意在工作方式上作出改变。比如开始组建跨职能团队、开展晨会和回顾会，认知和改变的意愿越强，也就越容易获得成功；
3. 组建跨职能团队。如果领导愿意把原来的组织结构调整为跨职能团队，为敏捷提供天然的适合生长的土壤，那么团队更容易转型成功。比如腾讯，就是按照跨职能组织的典型，产品、开发、测试和运营以项目为单位组织，大家共同背负业绩 KPI，树立共同的目标。除此之外，员工的涨薪并不直接由自己的职能领导给出评价，而是由通道委员会决定员工的职级 ，HR 再根据职级进行调薪。这样的团队只为达成产品目标服务，非常敏捷；
4. 专注于短期目标而不是⻓期目标。敏捷团队需要不断试错以获得短期利益，所以敏捷团队更关注短期目标的达成，如果团队属于这种特性，那么更适合敏捷转型；
5. ⼈才管理成熟度和能力。敏捷对于团队的要求是比较高的，一是由于敏捷鼓励自组织型团队，所以团队得有自我管理的能力，这就对团队成员要求较高；二是敏捷需要团队有很强的自动化能力，例如自动化测试、自动化构建和自动化部署。团队自我管理能力越强，团队的自动化能力越强，敏捷转型也越容易获得成功。

如果团队的积极因素大于消极因素，那么敏捷转型的成功率越高，反之则成功率越低，所以我们在 转型前应该尽可能地先识别这些因素，为了推动敏捷导入，我们可以按照上述的关注点，避免消极因素，发展积极因素。

试点项目的选择

敏捷不是一蹴而就的，我们会选择试点项目切入。

• 首先是 项目的重要性 。
  选择次重要的项目进行转型，这样带来的影响是比较好的，而且比较可控。
• 其次是 项目的周期。
  最好选择持续 时间为企业内项目通常 的 持续时间一半左右的项目 ，这个周期大概为三四个月。这可以给团队足够的时间在 Sprint 中很好地工作，体会到 Scrum 带来的好处。而且这个项目周期能够充分证明 Scrum 可以在更长周期的项目中获得类似的成功
• 还要考虑 项目的规模 。
  只有一个团队的项目作为开始，并且要让团队成员都坐在一起，即便未来该试点项目会扩大到多个团队，我们也要从一个团队开始，这是因为：

1. 可以节省多个团队间的沟通的成本；
2. 第一个试点团队需要敏捷教练集中精力去处 理 的问题非常多；
3. 一个团队的结果比较容易量化，便于最后转型效果的展示。

• 还要考虑 业务方或客户的支持和参与

在转型的过程中，我们需要培养人员输出文档，为后续全公司敏捷转型做准备，所以我们需要培养至少一位 Scrum Master，这个角色需要具备专业的敏捷教练能力，并可以结合公司实际情况落地适合的敏捷实践。另外，还需要输出“某某公司 Scrum Master指导手册”，以便于指导公司的 Scrum Master 进行敏捷转型。
最后，我们还需要有人定期对敏捷实践和产出的效果进行宣传，如果公司有 PMO （ ProjectManagement Office ）团队，这个职责会落到他们身上；如果有 HRBP（ HR Business Partner），那么他就有义务去做这件事情。如果我们都没有以上两种角色，那么就要从试点团队中选出至少一人来负责这件事情，只有不断让他人知道敏捷给团队带来的切实好处，才会激发公司其他团队的转型意愿。

---

以下是个人思考

没有进过公司参与敏捷实践，待补充…

---

文末

给大家出一道脑筋急转弯。大家知道为什么后羿射九日为什么只用了三箭？
因为他一箭三连[手动doge]​！
都看到这里了，对您有帮助的话，还请帮忙点赞评论，点个关注啊~
最后：送大家一句话。起点低，当下净，回头脏，平常道！