敏捷实践指南读后感100字

《敏捷实践指南》是一本由[美] Project Management Institute著作，电子工业出版社出版的平装图书，本书定价：68.00元，页数：170，特精心收集的读后感，希望对大家能有帮助。

《敏捷实践指南》读后感(一)：敏捷的方法在于没有方法

这本书是美国项目管理协会（PMI）与敏捷联盟合作开发的敏捷实践标准，它是理解、评估和使用敏捷和混合的敏捷方法的资源。书中不仅介绍了敏捷的概念、价值观和原则，还介绍了敏捷的生命周期、实践和工具，以及如何在不同的项目环境中选择和适应敏捷方法。书中还提供了一些案例和实例，展示了敏捷方法在实际项目中的应用和效果。

读完这本书，我感觉收获很多。我学习到了敏捷的思维模式，如何以客户价值为导向，如何以迭代和增量的方式交付产品，如何以团队协作和自组织为核心，如何以反馈和改进为驱动。我也了解了敏捷的各种框架和方法，如Scrum、XP、Kanban、Lean等，以及它们的优缺点和适用场景。我还看到了敏捷与传统项目管理方法的异同和融合，以及如何根据项目的复杂性、不确定性和变化性来选择合适的方法。

我最喜欢的一部分是第三部分的案例，作者用了很多具体的数据和图表，让我看到了敏捷方法在不同行业和领域的应用和成果。我觉得这些案例都很有说服力，能够为我提供一些参考和借鉴。我也注意到了作者在选择和实施敏捷方法时给出的一些建议和注意事项，我觉得这些都很有帮助。

总之，这本书是一本很好的敏捷入门书籍，不仅能够让我们掌握敏捷的基础知识和技能，也能够让我们看到敏捷在实际问题中的应用和解决方案。我觉得这本书对于任何想要学习和使用敏捷的人都是很有帮助的。

《敏捷实践指南》读后感(二)：生于敏捷，死于管理

多亏当年毕业后第一份工作的团队就是敏捷实践团队，在多年大小公司团队的产品经理加项目管理经历过来之后回头看敏捷方法，一边慨叹敏捷方法对人的价值之高，一边苦笑多数团队的桎梏之重。

以 Scrum 为代表的敏捷方法本是一套项目协作的方法论，这套方法论的核心在于激发团队每个成员的自主意识，以形成自激励协作模式为目标，这很像是开源界的做法。而在 Scrum 诞生之前，早就有了 PMI 来对项目管理过程进行一系列方法论上的统筹总结，其代表作《PMBOK》更是迄今为止都作为项目经理的必读书目一版再版。如果我们把软件行业因为使用传统瀑布流式开发受到种种限制而当做敏捷方法的诞生起点的话，那么可以很容易看到——瀑布式方法和敏捷方法，都是项目管理中可以应用的方法论。

而这本《敏捷实践指南》，就是 PMI 配合《PMBOK》出品的、把敏捷方法从项目管理体系中单独进行介绍的、适合有一定互联网项目管理经验或者对目前种种问题感到不满的互联网公司CEO或项目经理进行学习了解的书籍。

要说这本书好在哪儿，就是它用极其精要的内容把敏捷方法在项目管理中的作用、实践方法和工具都进行了完整介绍，如果你是一个有相关经验的人，你会看到几乎每一页、每一段、每一行的文字都在命中你团队过去的某个问题。而要说这本书哪儿有问题，那就是它绝对不是一本理论型、方法论型、教材型的书籍，它没有多少案例，也没有多少注解，更不会对每一个专业名词都进行详细释义。如果你在日常工作中不会留意和思考团队协作中的问题，那这本书对你来说可能就是认知之外的书——每个字你都认识，但完全不知道在讲什么。

当然，如果是为了快速解决问题，我还是更加推荐直接去读《硝烟中的 Scrum 和 XP》或者《Scrum 精髓》。

不过敏捷方法虽好，目前对于绝大部分公司或者团队来说，如何用合适的方法让老板理解并支持你施行，才是最大的障碍。因为作为老板从潜意识和本能就是要去掌控公司一切事务的，集中式管理的思维根深蒂固；而敏捷方法却是在让员工自行决策、团队信息透明，这是分布式管理的思维方式。这两种思维的矛盾根源就是一个认知悖论——认可它的人某种意义上就已经掌握并且在使用了，而需要它的人并不会认可它。

《敏捷实践指南》读后感(三)：敏捷实践指南

敏捷概述

有些项目在项目需求，以及如何使用现有知识和技术满足这些需求方面，具有很大的不确定性。这些不确定因素可能导致大量变更和项目复杂性的提高。

随着项目不确定性的增加，返工的风险和使用不同方法的需求也会增加。为了减轻这些风险的影响，团队选择的生命周期要能够通过较少的工作增量解决项目的大量不确定性问题。

团队可以利用较少的工作增量验证自身的工作，并且可以对接下来的工作做出相应变更。与静态书面规范相比，当团队交付小的增量时，他们能够更快更准确地理解真正的客户需求。

受斯泰西复杂性模型启发的不确定性和复杂性模型

团队可以用明确稳定的管理要求规划并管理项目，轻松解决各种技术挑战。但是，随着项目不确定性的增加，变更、做无用功和返工的可能性也会随之增加，而这不仅代价高昂，而且耗费时间。

有些团队让项目生命周期发生演变，以便使用迭代和增量方法。许多团队发现，在探讨迭代需求、更频繁地交付增量时，团队会更容易适应变更。由于团队获得反馈，这些迭代和增量方法减少了浪费和返工。这些方法应用了：

-非常短的反馈循环；

-频繁调整过程；

-重新进行优先级排序；

-定期更新计划；

-频繁交付。

通过构建一个小的增量，然后对其进行测试和评估，团队可以在短时间内以低成本探索不确定性，降低风险，最大程度地实现商业价值的交付。这种不确定性可能集中于适用性和需求（正在构建的产品是否正确？）、技术可行性和性能（产品是否可以采用这种方法构建？）或过程和人员（这是否为团队工作的一种有效方式？）。以上三个特点（产品规格、生产能力和过程适用性）通常都具有高度不确定性因素。

不过，迭代和增量管理方法也有其应用局限性。当技术和需求的不确定性都很高时，项目就会极端复杂，陷入无序状态。为了使项目尽可能可靠，需要遏制其中一个不确定性变量。

项目有多种形式，也有多种实施方式。项目团队需要认识到相关特征和方案，以选择最可能使项目成功的方法。

本实践指南涉及四种生命周期，分别定义如下：

-预测型生命周期。这是一种更为传统的方法，提前进行大量的计划工作，然后一次性执行；执行是一个连续的过程。

-迭代型生命周期。这种方法允许对未完成的工作进行反馈，从而改进和修改该工作。

-增量型生命周期。这种方法向客户提供各个已完成的，可能立即使用的可交付成果。

-敏捷生命周期。这种方法既有迭代，也有增量，便于完善工作，频繁交付。

并没有一个通用的术语用于描述非敏捷方法，我们选定使用术语“预测型”。

项目生命周期的特征

四种生命周期的特征

项目的固有特征决定了其适合采用哪种生命周期。

生命周期的连续区间

没有哪个生命周期能够完美地适用于所有的项目。相反，每个项目都能在连续区间中找到一个点，根据其背景特征，实现最佳平衡。

-预测型生命周期。充分利用已知和已经证明的事物。不确定性和复杂性的减少，允许项目团队将工作分解为一系列可预测的小组。

-迭代型生命周期。允许对部分完成或未完成的工作进行反馈，从而对该工作进行改进和修改。

-增量型生命周期。可向客户提供完成的可交付成果，让客户能够立即使用。

-敏捷生命周期。它同时利用迭代属性和增量特征。团队使用敏捷方法时，他们会对产品进行迭代，创建完成的可交付成果。团队将获得早期的反馈，并能提供客户可见性、信心和对产品的控制。由于团队可以提前发布产品，而团队将率先交付价值最高的工作，所以项目可以更早产生投资回报。

预测型生命周期预计会从高确定性的明确的需求、稳定的团队和低风险中获益。因此，项目活动通常以顺序方式执行。

为了实现这种方法，团队需要详细的计划，了解要交付什么以及怎样交付。当其他潜在变更受到限制时，这些项目就会成功（例如，需求变更；项目团队成员修改团队交付的成果）。团队领导的目标是尽可能减少预测型项目的变更。

团队在项目开始时创建详细的需求和计划时，他们可以阐明各种制约因素。然后，团队可以利用这些制约因素管理风险和成本。进而，团队在实施详细计划时，他们会监督并控制可能影响范围、进度计划或预算的变更。预测型项目强调根据部门划分的、有效的、顺序的工作，并且通常不会在项目结束前交付商业价值。如果遇到变更或需求分歧，或者技术解决方案变得不再简单明了，预测型项目就将产生意想不到的成本。

每种生命周期都有计划要素。生命周期的不同之处并非在于计划是否完成，而在于完成了多少计划以及何时完成。

在连续区间的预测一端，是计划驱动着工作。有多少计划，就有多少提前执行的可能性。尽可能详细地定义需求。团队估算何时能够交付可交付成果，并全面开展采购工作。

在迭代方法中，也计划了原型和验证，但是输出的目的是修改一开始所创建的计划。对未完成的工作的早期评审将有助于未来的项目工作。与此同时，增量方法计划交付整个项目后续部分。团队可以提前计划可交付成果的若干次连续交付，或者一次只计划交付一个。可交付成果为未来的项目工作提供了相关信息。

敏捷项目也有计划。主要区别在于，通过对频繁交付的可交付成果的评审，团队将能获得更多的信息，从而在此基础上进行计划和重新计划。无论采用哪种项目生命周期，项目都需要计划。

迭代型生命周期通过连续的原型或概念验证来改进产品或成果。每一个新的原型都能带来新的相关方新的反馈和团队见解。然后，团队在下一周期重复一个或多个项目活动，在其中纳入新的信息。团队可能会在长达数周时间的一个特定迭代中使用时间盒，集中各种见解，然后根据这些见解对活动进行返工。这样，迭代有利于识别和减少项目的不确定性。

当项目复杂性高、变更频繁或当项目范围受到相关方对所需最终产品的不同观点的支配时，采用迭代型生命周期会有优势。迭代型生命周期可能需要更长的时间，因为它是为学习而优化，而不是为交付速度而优化。

迭代型生命周期

有些项目优化是为了加快交付速度。许多企业和项目无法等待所有的事情全部完成；这种情况下，客户愿意接受整个解决方案的一个部分。这种少量可交付成果的频繁交付称为增量型生命周期。

您是否曾经参与过这样的项目，在项目过程中，需求似乎每天都在变化，您认为，“我们在交付企业批准的原型时就会了解需求。”如果情况如此，那么，采用敏捷方法将有助于这个项目。原型法鼓励反馈，并有助于更好地理解可纳入每个可交付成果的需求。

如果您怀疑需求将根据客户的反馈发生变更，请使用迭代方法。与一次交付一个最终产品相比，增量型生命周期将经常优化为项目发起人或客户交付价值的工作。在开始工作之前，团队就计划了最初的可交付成果，他们还会尽快开始第一次交付的工作。某些敏捷项目在项目启动后几天内就开始交付价值。有的项目可能需要更长的时间，从1周到几周时间不等。随着项目的继续，团队可能会偏离最初的设想。由于可以更快地交付价值，因而团队可以管理偏差。与客户在项目结束时获得价值相比，确保客户能尽早获得价值，其变更和差异程度的重要性变得不那么重要。

采用增量方法的一个例子是：为客户提供一个单一功能或是交付一项完成的工作。例如，在继续修建大楼的其余部分之前，施工人员可能希望先展示一间已完工的房间或一层楼。这种情况下，在继续修建大楼的下一层前，他们可能会为已完工的楼层布置家具、刷漆等。客户可以查看和批准有关样式、颜色和其他细节，以便在进一步投入时间和金钱之前做出相应的调整。这样做将减少潜在的返工和/或客户的不满。完整性和交付是主观的。团队可能需要获得关于原型的反馈，然后可能选择将最小可行性产品 （MVP） 交付给部分客户。客户的反馈将帮助团队了解他们需要为随后交付的最终功能的完善提供些什么。敏捷团队的一个重要差异化优势在于，他们会经常交付商业价值。由于产品的功能得到增加，就能吸引更多的消费者，因而我们就可以说，它是增量交付的。

在敏捷环境中，团队预料需求会发生变更。迭代和增量方法能够提供反馈，以便改善项目下一部分的计划。不过，在敏捷项目中，增量交付会发现隐藏或误解的需求。

在敏捷环境中，团队预料需求会发生变更。迭代和增量方法能够提供反馈，以便改善项目下一部分的计划。不过，在敏捷项目中，增量交付会发现隐藏或误解的需求。

基于迭代和基于流程的敏捷生命周期

在基于迭代的敏捷中，团队以迭代（相等持续时间的时间盒）形式交付完整的功能。团队集中于最重要的功能，作为一个团队合作完成其工作。然后，团队再集中于下一项最重要的功能，并合作完成其工作。团队可决定一次进行若干功能的开发工作，但团队不会同时完成所有的迭代工作（即团队不会在完成全部分析等工作后再解决所有需求）。对于建立在流程基础上的敏捷方法，团队将根据自身能力，从待办事项列表中提取若干功能开始工作，而不是按照基于迭代的进度计划开始工作。团队定义任务板各列的工作流，并管理各列的进行中的工作。完成不同功能所花费的时间可能有所不同。团队让进行中的工作的规模尽量小，以便尽早发现问题，并在需要变更时减少返工。无需利用迭代定义计划和审核点，而由团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划。

敏捷生命周期是符合《敏捷宣言》原则的周期。特别是，客户满意度将随着有价值产品的早期交付和持续交付不断提升。此外，功能性的、提供价值的增量可交付成果，是衡量进展的主要尺度。为了适应更频繁的变更和更频繁地交付项目价值，敏捷生命周期结合了迭代和增量方法。

对于整个项目，没有必要使用单一的方法。为达到特定的目标，项目经常要结合不同的生命周期要素。预测、迭代、增量和/或敏捷方法的组合就是一种混合方法。

混合敏捷方法

敏捷团队很少将其实践局限于一种敏捷方法。

敏捷框架并不是针对团队定制的。为了定期交付价值，团队可能需要对实践进行裁剪。通常，团队都会实践各自特殊的敏捷组合，即便他们使用一个特定的框架作为起点也不例外。

裁剪敏捷框架的一个例子是，一个广泛使用的常见协调方法涉及到协调使用Scrum 框架、看板方法和极限编程 （XP）方法的要素。Scrum为产品待办事项列表、产品负责人、Scrum主管以及跨职能开发团队的使用提供指导，包括冲刺计划、每日例会、冲刺评审和冲刺回顾会议。看板面板帮助团队进一步提高效率，方法是将工作流可视化、使障碍更容易被察觉，以及通过调整在制品限制来实现流程管理。此外，受极限编程启发的工程实践，如使用故事卡、持续集成、重构、自动化测试和测试驱动开发，将进一步提高敏捷团队的效力。总之，与孤立采用各种实践相比，协调这些不同来源的实践将产生更好的协同成果。

对于高不确定性项目，项目的复杂性是一个人所无法管理的。而跨职能团队既能协调自身的工作，还能与业务代表（产品负责人）开展合作。从事敏捷项目工作时，项目经理的角色就会从团队的中心转变成为团队和管理人员提供服务。在敏捷环境中，项目经理充当仆人式领导，其工作重点转变为引导需要帮助的人，促进团队的合作，保持与相关方的需要一致。作为仆人式领导，项目经理要鼓励将责任分配给团队成员，分配给那些掌握完成任务所需知识的人。

无论整体的敏捷方法是什么，团队越是限制其在制品，团队成员就越有可能通过合作来加快整个团队的工作。在成功的敏捷团队中，团队成员在工作中以各种方式开展合作（如结对、群集、群体开发），因而，他们会协同工作，而不会落入迷你瀑布的陷阱中。团队在给定时间解决所有的需求，然后试图完成所有的设计，继而又去完成所有的构建，就会发生迷你瀑布的情况。使用这个场景，在构建中或构建后测试中的某一时刻，团队可能会意识到，原先的假设已经不再有效。这种情况下，团队解决所有的需求根本是在浪费时间。相反，当团队成员合作打造全部功能中的少量功能时，随着工作的推进和交付少量已完成的功能，他们也在不断学习。

如果团队不重视质量，很快就会无法快速发布任何东西。

下面的技术实践中，很多都来自于极限编程，它们可以帮助团队以最快的速度交付：

-持续集成。无论产品如何，都要频繁地将工作集成到整体中，然后再进行重新测试，以确定整个产品仍然按照预期工作。

-在不同层面测试。对端到端信息使用系统级测试，对构建块使用单元测试。在两者之间，了解是否需要进行集成测试，以及在何处进行测试。团队发现冒烟测试有助于测试工作产品是否良好。团队发现，决定何时以及对哪些产品运行回归测试，可以帮助他们在维护产品质量的同时，良好地构建性能。敏捷团队非常偏爱自动化测试，因此他们可以借此构建和保持交付的势头。

-验收测试驱动开发（ATDD）。在ATDD中，整个团队聚集一堂讨论工作产品的验收标准。然后，团队创建测试，这让团队能够编写足够的代码，进行自动化测试，满足标准要求。对于非软件项目，要考虑怎样在团队完成大量价值时对工作进行测试。

-测试驱动开发 （TDD） 和行为驱动开发 （BDD）。在编写/创建产品之前编写自动化测试，实际上可以帮助人员设计产品，防范产品错误。对于非软件项目，要考虑如何通过“测试驱动”团队的设计。硬件和机械类项目经常使用模拟进行设计的中间测试。

-刺探（时间盒研究或实验）。刺探对学习很有用，可以在诸如评估、验收标准定义以及通过产品了解用户行为的流程中使用。在团队需要学习一些关键技术或功能要素时，刺探会很有帮助。

项目发起人通常想知道项目什么时候能够完成。一旦团队建立了稳定的速度（每个迭代的故事或故事点的平均数量）或平均周期时间，团队就能够预测项目将花费多长时间。

附录A1—《PMBOK®指南》映射

项目管理过程组与知识领域

敏捷在《PMBOK®指南》知识领域中的应用

附录A2—《敏捷宣言》映射

《敏捷宣言》背后原则的实践指南映射

附录A3—敏捷和精益框架概述

根据广度和详情制订的敏捷方法

Scrum是用于管理产品开发的单个团队过程框架。

极限编程 （XP） 是一种基于频繁交付周期的软件开发方法。该名称基于这样一个理念：将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践。XP 最受关注的地方在于推广旨在改进软件项目成果的整套实践。该方法最初包含十二种主要实践，随后逐渐演变，采用了一些其他推论实践。

极限编程实践

看板在精益制造中是一种用于规划库存控制和补给的系统。这种“准时制”库存补给过程最初可在杂货店中看到，商店会根据货架不足情况而不是供应商库存来补给货架商品。受这种准时制库存系统的启发，大野耐一开发了看板，并在1953年将其应用于丰田的主要制造厂。“看板”一词按字面翻译为“视觉符号”或“卡”。带有卡片的物理看板面板能够推动和实现整个系统中工作流的可视化，让每个人都可以看到。该信息发射源（大型显示屏）包含许多列，表示需要完成的工作流的状态。最简单的面板可能包含三列（即要完成的工作、进行中的工作和已完成的工作），但可以调整为使用团队所需要的任何状态。

看板方法应用并适用于多种场合，可以确保工作流和价值交付的持续性。看板方法不如某些敏捷方法规范，因此开始实施时的破坏性也较小，原因在于它是原始的“原地出发”方法。在必要或适当的情况下，组织可以相对轻松地应用看板方法并通过完全实施该方法而向前发展。与大多数敏捷方法不同，看板方法未规定使用时间盒迭代。在看板方法中可以使用迭代，但应始终遵循在整个过程中持续拉取单个条目并限制在制品以优化流程的原则。如果团队或组织有以下需要时，则看板方法最为适用：

-灵活性。团队通常不受时间盒的限制，将执行待办事项列表中优先级最高的工作。

-专注于持续交付。团队专注于完成整个系统工作流，直至在制品完成才会开始新工作。

-提高工作效率和质量。通过限制在制品将可以提高工作效率和质量。

-提高效率。检查每个任务，了解增值或非增值活动，然后清除非增值活动。

-团队成员专注力。限制在制品，使团队能够专注于当前工作。

-工作负载的可变性。如果即将开展的工作存在不可预测性，团队将无法做出可预测承诺，即使对于短期工作也不例外。

-减少浪费。透明将会使浪费可视化，因而能够消除浪费。

看板方法是从精益思维原则衍生而来。

看板方法是一种整体性组织增量演变过程和系统变更框架。该方法采用“拉式系统”来完成在制品。团队完成一个条目后，即可拉取另一个条目到该过程。

看板方法的定义原则和属性

看板面板是一种技术含量低但接触广泛的技术，使用者在一开始时可能会认为其过于简单，但很快便会发现其强大的功能。看板面板利用列进入和退出策略以及限制在制品等制约因素，可提供一目了然的工作流、瓶颈、阻碍和整体状态信息。此外，面板可作为面向所有观众的信息发射源，提供团队工作状态的最新信息。

看板面板通过展示在制品限制和拉取系统来优化工作流

在看板方法中，完成工作比开始新工作更为重要。从未完成的工作中无法获得任何价值，因此团队将协作实施和遵从在制品（WIP）限制，让整个系统中的每份工作得以“完成”。

水晶是一种方法论家族。水晶方法论旨在根据项目规模（项目中涉及的人员数量）以及项目的关键性来量化并提供方法严格程度选择。

水晶方法家族

水晶方法认识到每个项目可能需要一系列轻量剪裁的策略、实践和过程，以匹配项目的独特特征。该方法论家族根据“重要性”使用不同的颜色来确定要使用的方法。“水晶”一词的使用源自宝石，它的不同面代表了根本的核心原则和价值观。不同面代表了技术、工具、标准和角色

水晶原则的核心价值观和常见属性

项目中包含的这些属性越多，成功可能性越高。