敏捷

What（什么）：

• 敏捷是一种灵活的项目管理和软件开发方法论，强调通过迭代和增量的方式交付高质量的价值。
• 敏捷方法注重快速反馈、持续改进和适应性，以更好地满足客户需求和不断变化的市场环境。

Why（为什么）：

• 敏捷的出现是为了解决传统瀑布模型开发方法的局限性，如需求变化难以应对、项目延期和产品质量问题。
• 敏捷的目标是提供更高的客户价值、提升团队协作和自组织能力，以及提高项目透明度和交付效率。

Who（谁）：

• 敏捷方法适用于各种规模和类型的项目，无论是小型团队还是跨部门合作的大型组织。
• 敏捷涉及多个角色，包括敏捷团队成员（开发人员、产品负责人、Scrum Master等）和利益相关者（客户、用户等）。

When（何时）：

• 敏捷方法强调持续交付和迭代开发，项目按照固定长度的时间框架（例如冲刺）进行计划、执行和评估。
• 敏捷强调快速反馈和频繁的迭代，以便及时调整计划和响应需求变化。

Where（在哪里）：

• 敏捷可以在各种行业和组织中应用，包括软件开发、产品开发、项目管理和服务交付等领域。
• 敏捷可以在实体团队、分布式团队和跨部门团队中实施。

How（如何）：

• 敏捷方法包括多种框架和实践，如Scrum、Kanban、极限编程（XP）等，每种方法都有自己的原则和实施方式。
• 敏捷强调迭代规划、自组织团队、持续集成、自动化测试、用户故事、可视化管理等实践方法。

精益

What（什么）：

• 精益是一种管理方法论，强调通过持续改进、减少浪费和提高价值交付来优化业务流程。它关注于实现高效、高质量和高价值的工作流，以满足客户需求并实现可持续发展。

Why（为什么）：

• 精益的目标是通过消除浪费和提高流程效率来提供价值。它致力于降低成本、提高客户满意度、加强竞争力和增强组织绩效。精益方法论通过优化资源利用、改进流程和提升员工参与度来实现这些目标。

Who（谁）：

• 精益方法论适用于各种类型的组织，无论规模大小或行业背景。它不仅关乎领导层的支持和承诺，还需要全体员工的参与和合作。精益的理念和原则可适用于制造业、服务业、医疗保健、项目管理等各个领域。

When（何时）：

• 精益可以在任何时候应用。它可以在组织启动阶段引入，也可以在现有组织中进行持续改进和优化。无论是面临具体问题还是寻求整体改进，精益都提供了框架和方法来解决当前的挑战，并促进持续的业务优化。

Where（在哪里）：

• 精益可以在各种工作环境中应用。它的原则和工具可以适用于生产车间、办公室、供应链管理、项目管理等各个领域和业务部门。无论是物质流程还是信息流程，精益的原则都可以应用于各种工作环境和组织类型。

How（如何）：

• 精益方法论涵盖了一系列工具和技术，例如价值流映射（Value Stream Mapping）、5S整理、Kanban看板、持续改进（Kaizen）和精益生产（Lean Production）。这些工具和技术帮助组织识别和消除浪费、优化流程、提高效率和质量，并激发员工参与和持续改进。精益方法论的实施包括以下步骤：

  • 价值流映射（Value Stream Mapping）：通过绘制价值流程图，全面了解业务流程中的价值创造和浪费环节。这有助于识别和优化价值流程，并确定改进的重点领域。

  • 5S整理：通过整理、整顿、清扫、标准化和保持（Sort, Set in Order, Shine, Standardize, Sustain）来创造整洁、有序和高效的工作环境。这有助于提高工作效率、减少浪费和改善员工工作条件。

  • Kanban看板：使用看板系统来可视化工作流程和任务状态。这有助于优化任务分配、提高团队协作和监控工作进展，以实现快速反应和高效交付。

  • 持续改进（Kaizen）：通过持续地识别问题、找到根本原因并实施改进措施，不断优化业务流程和工作方式。这需要建立一个持续改进的文化，并鼓励员工积极参与改进活动。

  • 精益生产（Lean Production）：应用精益原则来优化生产流程，包括减少库存、改善产品质量、实现短交付周期和灵活生产等。这有助于提高生产效率、降低成本和满足客户需求。

• 在实施精益的过程中，关键的成功因素包括领导层的承诺和支持、员工的培训和参与、建立有效的沟通和反馈机制，以及持续监测和评估改进的效果。

那敏捷和精益的区别是什么呢?

敏捷（Agile）和精益（Lean）都是管理方法论，旨在改善组织的业务流程和绩效，但它们有一些区别。

• 定位和起源：

  • 敏捷：敏捷方法论最初是为软件开发领域设计的，旨在应对传统瀑布模型的限制和挑战。它强调快速响应变化、迭代开发、自组织团队和持续交付。
  • 精益：精益方法论起源于丰田生产系统（Toyota Production System），强调通过减少浪费、提高价值流动和持续改进来优化业务流程和价值交付。

• 范围和应用领域：

  • 敏捷：敏捷方法论广泛应用于软件开发和项目管理等领域。它强调快速迭代、跨功能团队协作和持续反馈，适用于需求变化频繁、创新性强的项目。
  • 精益：精益方法论可应用于各个行业和领域，包括制造业、服务业、供应链管理等。它关注于消除浪费、优化价值流程和提供高效、高质量的价值交付。

• 理念和原则：

  • 敏捷：敏捷方法论的核心价值观包括个体和互动高于流程和工具、工作软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划。它强调灵活性、快速学习和持续改进。
  • 精益：精益方法论的核心原则包括价值流、流程优化、浪费消除、持续改进和尊重人的价值。它强调通过提供价值、优化流程和减少浪费来实现组织的成功。

• 工具和实践：

  • 敏捷：敏捷方法论使用一系列实践和工具，如迭代开发、Scrum框架、看板方法、用户故事和持续集成。它强调自组织团队、频繁交付和持续反馈。
  • 精益：精益方法论使用一系列工具和技术，如价值流映射、5S整理、Kanban看板、持续改进和精益生产。它强调流程优化、消除浪费和持续学习。 尽管敏捷和精益有一些区别，但它们也存在着一些相互关联和重叠的方面：

• 迭代和增量：敏捷和精益方法论都强调迭代和增量的工作方式。它们鼓励在较短的时间框架内完成工作，通过持续的反馈和学习来不断改进和优化。

• 客户价值导向：敏捷和精益都关注提供客户价值。它们强调以客户需求为导向，通过优化流程和提供高质量的产品或服务来满足客户期望。

• 团队合作和自组织：敏捷和精益都倡导团队合作和自组织。它们鼓励跨功能团队的合作和决策，以实现更高效的工作流程和更好的成果。

• 持续改进：敏捷和精益都注重持续改进。它们强调不断反思和寻求改进的文化，以逐步提高业务流程和组织绩效。

总体而言，敏捷和精益都是为了帮助组织更好地应对不确定性和变化，实现高效、高质量的价值交付。它们可以相互补充和结合使用，根据组织的需求和背景选择适合的方法和实践。

Scrum

What（什么）：

• Scrum是一种敏捷软件开发方法，用于管理和组织团队的工作流程。
• 它强调迭代开发、自组织团队和持续交付，旨在提高团队的灵活性和适应能力。

Why（为什么）：

• Scrum的目标是满足客户需求，提供高质量的软件产品。
• 它强调通过频繁的反馈和调整，及时适应变化的需求和市场条件。
• Scrum还旨在提高团队成员的参与度和工作满意度，促进团队合作和协作。

Who（谁）：

• Scrum团队由产品负责人（Product Owner）、Scrum团队（Scrum Team）和Scrum主管（Scrum Master）组成。
• 产品负责人负责管理产品需求和优先级，确保团队开发出有价值的产品。
• Scrum团队是自组织的跨功能团队，负责开发、测试和交付可用的软件增量。
• Scrum主管负责协助团队遵守Scrum流程和原则，解决团队遇到的问题。

When（何时）：

• Scrum使用迭代开发的方式，每个迭代称为一个Sprint。
• 每个Sprint通常持续2至4周，包含计划、执行、审查和回顾等阶段。
• Scrum团队在每个Sprint期间持续开发和交付软件增量，通过Sprint计划和回顾不断优化工作流程。

Where（何地）：

• Scrum可以在各种组织和行业中应用，包括软件开发、项目管理、产品开发等。
• Scrum团队通常在一个共享的工作空间中进行工作，以促进交流和协作。

How（如何）：

• Scrum采用一系列仪式、角色和工件来组织工作流程。
• 仪式包括Sprint计划会议、每日站会、Sprint评审和Sprint回顾。
• 角色包括产品负责人、Scrum团队成员和Scrum主管。
• 工件包括产品待办清单（Product Backlog）、Sprint待办清单（Sprint Backlog）和增量软件产品。

Kanban

What（什么）：

• Kanban是一种敏捷项目管理方法，用于可视化工作流程和任务管理。
• 它通过看板、限制工作在进行中的任务数量和持续改进来提高工作效率和交付价值。

Why（为什么）：

• Kanban的目标是优化工作流程，减少浪费并提高交付速度。
• 它帮助团队识别并解决瓶颈，提高工作质量和客户满意度。
• Kanban还促进团队协作和可视化工作进度，使团队更好地管理任务和资源。

Who（谁）：

• Kanban团队由团队成员、Kanban经理和产品负责人组成。
• 团队成员是执行任务和工作的人员，他们负责完成工作并提供交付价值。
• Kanban经理负责协调和管理团队的工作流程，确保任务的顺利进行。
• 产品负责人负责确定任务的优先级和工作的价值，确保团队交付符合客户需求的产品。

When（何时）：

• Kanban是一个持续改进的过程，团队可以随时应用它。
• Kanban通过持续的任务管理和工作流程改进来提高团队的效率。
• 工作任务在团队的限制下持续进行，根据需求和资源进行调整。

Where（何地）：

• Kanban可以在各种行业和组织中应用，包括软件开发、项目管理、生产制造等。
• 团队通常在一个可视化的看板上管理任务，以便更好地跟踪工作进度和状态。

How（如何）：

• Kanban使用一个可视化的看板来管理任务，通常分为待办、进行中和已完成的列。
• 每个任务都在看板上表示为一个卡片，团队成员根据任务状态进行移动。
• Kanban团队通过限制在进行中的任务数量，避免过度负荷和优化工作流程。
• 团队通过持续的反馈和改进来不断优化任务管理和工作效率。

Scrum和Kanban的区别

Scrum和Kanban都是敏捷方法，而不是精益方法。尽管它们都与敏捷和精益思想有关，但它们在理念和实践上有所区别。

区分Scrum和Kanban的主要依据如下：

Scrum：

• Scrum是一种迭代的、增量式的敏捷方法。
• Scrum注重团队的自组织和合作，通过明确的角色（如产品负责人、Scrum Master、开发团队）和仪式（如Sprint计划会议、每日站会、Sprint评审、Sprint回顾）来规范团队的工作流程。
• Scrum采用时间固定的迭代周期（称为Sprint）来进行规划、执行和交付软件增量。

Kanban：

• Kanban是一种基于流程的敏捷方法。
• Kanban通过可视化工作流程、限制在进行中的任务数量和持续改进来优化工作效率和交付价值。
• Kanban强调根据需求和资源的实际情况来进行任务管理和流程优化，没有时间固定的迭代周期。

在实践中，Scrum和Kanban可以结合使用，或者根据组织的需求和特定项目的情况选择适合的方法。Scrum更适用于需要明确角色和时间固定迭代周期的项目，而Kanban更适用于需要灵活性和持续流动的工作流程。重要的是根据团队和项目的要求选择最适合的方法，并根据实践中的反馈进行调整和改进。

VSM

What（什么）：

• 价值流映射是一种方法和工具，用于分析和改善价值流程中的活动和流程。
• 它通过可视化整个价值流程、识别价值和非价值增加的活动以及浪费，以实现流程的优化和改进。

Why（为什么）：

• 价值流映射的目的是消除浪费、提高效率和质量，以实现更高的价值交付和客户满意度。
• 它帮助组织理解整个价值流程，并在此基础上进行改进，以减少非价值增加的活动、降低成本和提高交付速度。

Who（谁）：

• 参与价值流映射的人员包括流程所有者、生产团队成员、质量团队、管理者等。
• 价值流映射需要跨部门的合作和协调，因此需要涉及到相关的利益相关者和团队。

When（何时）：

• 价值流映射可以在不同阶段应用，包括新项目启动前、现有流程改进、问题解决等。
• 最好在开始设计或改进流程时进行价值流映射，以便及早识别和解决潜在的问题和浪费。

Where（何地）：

• 价值流映射可以在各个工作区域和流程中应用，包括制造业、服务业、项目管理等。
• 它可以在实际工作环境中进行，通过物理布局、可视化工具或数字平台来展示和分析价值流程。

How（如何）：

• 价值流映射的过程包括收集数据、绘制当前状态和未来状态的价值流图、分析和识别浪费、制定改进计划等步骤。
• 使用符号、指标和图表来表示价值流程中的各个环节、等待时间、库存量、瓶颈等。
• 团队通过讨论、协作和实验来确定改进方向和实施计划，并持续追踪改进的结果和效果。

根因分析

What（什么）：

• 根因分析是一种系统化的方法和工具，用于确定问题或事件的根本原因。
• 它旨在识别导致问题发生的根本原因，而不仅仅是处理表面的症状。

Why（为什么）：

• 根因分析的目的是预防问题的再次发生，从而提高工作质量和效率。
• 通过确定和解决问题的根本原因，可以减少重复性问题、改善流程、降低成本并提高客户满意度。

Who（谁）：

• 参与根因分析的人员包括受影响的团队成员、质量控制团队、工程师、管理人员等。
• 还可能需要跨部门合作，根据问题的性质可能需要专业知识和技能。

When（何时）：

• 根因分析可以在问题发生后立即进行，以便尽快确定并解决根本原因。
• 它也可以作为持续改进的一部分，在定期的审查和评估过程中进行。

Where（何地）：

• 根因分析可以应用于各个工作领域和行业，包括制造业、服务业、软件开发等。
• 它可以应用于实际工作环境中的问题，也可以应用于模拟或实验环境中。

How（如何）：

• 根因分析的过程包括数据收集、问题描述、问题分析、根因识别、解决方案制定和实施等步骤。
• 使用工具和技术，如鱼骨图（因果图）、5Why分析、流程图等来辅助分析和识别根本原因。
• 团队通过讨论、合作和实验来确定最佳的解决方案，并跟踪改进的结果和效果。

A3报告

What（什么）：

• A3报告是一种问题解决和决策支持工具，通常使用A3纸张的形式进行编制。
• 它是一种简洁而有条理的文档，用于概括问题、分析根本原因、制定改进计划和跟踪结果。

Why（为什么）：

• A3报告的目的是促进团队的沟通、合作和持续改进。
• 它通过结构化的问题解决方法，帮助团队深入分析问题、制定可行的解决方案，并推动实施和评估改进的效果。

Who（谁）：

• A3报告通常由团队成员、项目经理、质量控制人员、领导者等编制和使用。
• 它是一个团队工具，需要团队成员的参与和合作。

When（何时）：

• A3报告可以在问题发生后或改进机会出现时使用。
• 它可以作为持续改进过程中的一部分，也可以用于特定的项目或倡议。

Where（何地）：

• A3报告可以在各个工作领域和行业中应用，包括制造业、服务业、项目管理等。
• 它通常用于内部使用，作为团队和组织内部的工作文档。

How（如何）：

• A3报告的结构一般包括问题陈述、目标设定、当前状态分析、根本原因分析、改进方案、实施计划和结果评估等部分。
• 使用工具和方法，如5Why分析、PDCA循环、鱼骨图等来辅助问题解决和改进过程。
• 团队通过协作、讨论和实验来编制A3报告，并根据实际情况进行修订和更新。

精益需求管理

What（什么）：

• 精益需求管理是一种基于精益思维和方法的需求管理方法和工具集。
• 它旨在通过最小化浪费、提高价值交付和增强需求的适应性，有效管理和满足项目或产品的需求。

Why（为什么）：

• 精益需求管理的目的是优化需求的获取、分析、确认和跟踪过程，以提高项目或产品的成功率和客户满意度。
• 它能够帮助团队减少不必要的功能、提高需求的优先级和顺序，并快速响应变化的需求。

Who（谁）：

• 精益需求管理涉及项目经理、产品负责人、业务分析师、开发团队和利益相关者之间的协作和合作。
• 它需要团队的跨部门和跨职能合作，以及与客户和用户的紧密沟通和协调。

When（何时）：

• 精益需求管理是一个持续的过程，贯穿项目或产品的整个生命周期，从需求的提出到交付和维护阶段。
• 它包括需求的收集、分析、确认和跟踪，以及在变化和不断学习中进行的持续改进。

Where（何地）：

• 精益需求管理可以应用于各个行业和项目领域，包括软件开发、产品设计、工程建设等。
• 它可以在组织内部进行，也可以涉及外部客户和用户的参与和合作。

How（如何）：

• 精益需求管理采用一系列方法和工具，包括价值流映射、用户故事、敏捷计划、原型开发和持续集成等。
• 它强调与客户的紧密合作、迭代开发和快速反馈，以实现需求的持续优化和交付价值的最大化。
• 在实践中，团队使用可视化工具、持续改进和跨功能协作来促进需求管理的效率和效果。

干系人管理

What（什么）：

• 干系人管理是一种系统性的方法，用于识别、分析和主动管理与项目或组织相关的各方利益相关者。
• 通过了解和满足干系人的需求、期望和利益，干系人管理旨在建立共赢的关系，以实现项目或组织的成功。

Why（为什么）：

• 干系人管理的目的是确保项目或组织能够在利益相关者的支持下取得成功。
• 它有助于最大限度地发挥利益相关者的积极作用，减少冲突和阻力，并促进项目或组织的可持续发展。

Who（谁）：

• 干系人包括直接或间接与项目或组织相关的个人、团体或组织。
• 这些利益相关者可能是项目或组织的所有者、管理层、客户、用户、员工、供应商、合作伙伴等。

When（何时）：

• 干系人管理是一个持续的过程，从项目或组织的规划阶段开始，贯穿整个生命周期。
• 在每个阶段，都需要识别、分析和管理新的干系人，并与现有干系人保持有效的沟通和合作。

Where（何地）：

• 干系人管理可以在项目或组织的内部和外部环境中进行。
• 在内部，干系人管理需要与项目团队成员、决策者和执行者进行有效的沟通和协作。
• 在外部，干系人管理涉及与客户、合作伙伴、供应商和其他利益相关者进行互动和合作。

How（如何）：

• 干系人管理包括识别、分析和评估干系人的需求、权力、利益和影响力。

• 基于这些分析结果，制定沟通计划、利益管理策略和冲突解决方案。

• 干系人管理还需要建立良好的合作关系，通过有效的沟通、协商和利益平衡来实现共同目标。

• 干系人管理涉及使用各种工具和技术来识别、分析和有效管理项目或组织的干系人。以下是一些常用的干系人管理工具：

  • 干系人注册表（Stakeholder Register）：记录项目或组织的各方利益相关者的详细信息，包括姓名、职务、联系方式、利益、需求、关系等。这个注册表有助于全面了解和跟踪各方的参与和影响。

  • 影响力/利益方格（Influence/Impact Grid）：将干系人按照其对项目或组织的影响力和利益程度进行分类和排序。这个工具有助于确定哪些干系人需要特别关注和管理。

  • 沟通计划（Communication Plan）：制定明确的沟通策略和计划，确保及时、准确地向干系人传达项目或组织的信息。该计划包括沟通频率、渠道、内容和参与者等方面的规划。

  • 利益管理策略（Stakeholder Engagement Strategy）：制定与不同干系人群体互动和合作的策略。该策略包括建立合作关系、解决冲突、满足利益和期望等方面的方法和措施。

  • 冲突解决工具（Conflict Resolution Tools）：包括各种技术和方法，用于处理干系人之间的冲突和分歧。例如，协商、调解、合作问题解决等。

  • 会议和工作坊（Meetings and Workshops）：组织针对干系人进行的定期会议和工作坊，以促进沟通、合作和共识达成。例如，干系人介绍会、干系人需求收集会议等。

  • 干系人参与评估工具（Stakeholder Engagement Assessment Tools）：用于评估和监测干系人的参与度和满意度的工具。例如，干系人调查问卷、干系人参与度评估表等。

  • 社交媒体和数字平台（Social Media and Digital Platforms）：利用各种在线平台和社交媒体，与干系人进行实时互动和信息分享。这些平台可以加强干系人参与和沟通效果。

教练技术

What（什么）：

• 教练技术是指教练在指导和培养他人时使用的特定技巧和方法。
• 它涵盖了教练在帮助个人或团队实现目标和发展能力方面的各种技术和策略。

Why（为什么）：

• 教练技术的目的是促进学习和发展，激发个人或团队的潜力。
• 它可以帮助他人建立自信、提高绩效、解决问题、增强自我意识等，从而实现个人和组织的成功。

Who（谁）：

• 教练技术可以被广泛应用于各个领域，包括商业、运动、教育、领导力等。
• 教练技术可以由专业教练、领导者、教育者、指导者、顾问等人员使用。

When（何时）：

• 教练技术可以在许多不同的情境和场合中使用。
• 它可以在工作环境中的日常工作中应用，也可以在特定的培训、指导或咨询过程中使用。

Where（何地）：

• 教练技术可以在各种环境中进行，包括工作场所、体育场馆、学校、会议室等。
• 它可以适用于面对面的会议、团队活动、远程会议、在线学习平台等不同的场所和方式。

How（如何）：

• 教练技术可以通过各种技术和方法来实施，例如提问、倾听、反馈、目标设定、行动计划等。
• 教练技术还可以利用不同的工具和资源，例如评估工具、教练手册、练习册、模型框架等。

组织变革

What（什么）：

• 组织变革指的是组织为了适应外部环境变化、提高绩效或实现战略目标而进行的系统性和持续性的改变。
• 这可能涉及组织结构调整、流程优化、文化转变、技术引入等多个方面的变化。

Why（为什么）：

• 组织变革的目的是使组织适应变化的环境、提高竞争力和效率，并实现长期的可持续发展。
• 它可以帮助组织应对市场需求的变化、解决内部问题、提高创新能力、优化资源利用等。

Who（谁）：

• 组织变革涉及组织内的各个层级和各个部门，以及与组织相关的利益相关者。
• 这包括高层管理人员、团队领导者、员工、客户、合作伙伴等。

When（何时）：

• 组织变革可能发生在不同的时间点和阶段。
• 它可以是作为一次性的重大变革项目，也可以是一个持续不断的改进过程。

Where（何地）：

• 组织变革可以在整个组织范围内发生，涉及到不同的部门、办公地点和团队。
• 这可能包括总部、分支机构、生产厂区等。

How（如何）：

• 组织变革可以通过多种方式和方法来实施，包括战略规划、项目管理、培训和发展、沟通和参与等。
• 这可能涉及到制定变革计划、培训员工、建立跨部门合作机制、建立变革指导小组等。

思考

在学习CAC之前, 我一直有个误区, 我一直以为团队采用的要么是敏捷实践, 要么是精益实践. 所以我会时常困惑, 为什么我们明明是敏捷团队, 但居然还采用了精益的实践. 那我们究竟是敏捷团队还是精益团队呢? 我相信这不止是我一个人的困惑, 所以我认为有必要搞清楚每一个概念, 并且了解清楚他们的区别.

在我看来, 本质其实是解决问题, 我们面临着什么样的问题? 有什么样的实践可以帮助我们应对? 无论是敏捷还是精益, 本质上就是人类总结的方法论, 不管你是单独使用敏捷, 还是敏捷, 精益混合使用. 只要能解决你的问题, 那就够了.

不管是敏捷还是精益, 他们都是完整的方法论, 如果你采用, 那么随之而来的问题就是, “如何验证我采用了该方法论后, 是有效果的呢?”. 敏捷成熟度模型（AMM）即是答案.

对我来说, 在一个已经采用了敏捷实践的团队来继续引入更先进的实践是比较容易的, 但如果要引导一个团队从零转向敏捷, 是极其困难的. 我需要这样的经历, 也许是跟随着某个咨询项目来学习, 否则一切都是纸上谈兵.

作为Senior Consultant来公司半年多了，上个月初已经过了试用期，但却没有想象中的那么高兴。

近段时间因为手头工作的不善处理让自己陷于十分被动的境地，可以说是一次深刻地教训了，如果没有深入的思考反省，难免以后会再犯。因此我不得不与自己妥协，承认自己的种种不足，并采取各种手段来补齐。

前段时间读完Bob大叔的《程序员的职业素养》后，我觉得自己并不是一位合格的专业的程序员，我的Title已经到了Senior，但实际情况着实还需要跳一跳，稳一稳，才能对得起这个Title。

花了点时间整理了一下这本书的要点脑图，稍微来分析下自己的教训时刻吧。

专业主义

• 建卡的目的是追踪进度，并非简单的to-do -> in progree -> done列的拖拽，需每天更新进度，若当天没有进度可更新，那是不是说明今天产出极其有限？即使没有什么产出，也应该有被block的原因。
• 任务分解并非简单将任务分为各步骤执行，若单个任务较重，考虑创建Epic。花一定时间讨论未来任务潜在的问题，block，若在一开始就发现难以逾越的鸿沟，也许就不会到最后被动的束手无策。
• TDD是当前公司，团队所推崇的实践，若不采取TDD，实在无足够自信通过CICD直接部署，已经深刻体会到了。
• 结对编程是分享context，从泥潭中获救的最有效的方式，也是相互学习的好方式。由于时差和任务分解不清晰导致结对编程的效率比较有限。
• 做卡并非简单的完成任务，需深入思考背后所带来的价值，可以给客户提供的业务价值，若看不到价值，果断地及时止损是很有必要的。TL的视野大多数情况下比你长远，认真听，认真思考。

说"是"和"不"

• 说了太多试试看，有一种盲目自信和英雄主义，这是一种来自菜鸡的虚荣。
• 如果不以解决问题为目标，很容易陷入消极对抗中，“你说的都对，但我就是有我的主意”。也许并不是有意为之，但表现出来的就是。这很容易造成无限期的延期。
• 认真地说是，如果你的承诺做不到，不如直接坦诚的说不会。真正的承诺是，你可以掌控的事情。

恶性循环

近两三个月处于恶性循环中，白天无精打采低效地做事，晚上回家疲惫不堪，身体的疲惫和心理的疲惫让人快乐不起来。分析过后，原因如图所示。

• 拿到了与自己岗位不足够匹配的role，HR明确地说需要跳一跳才能够到，我听进去了，但做了行动上的矮子。入职之后将其抛之脑后，理所当然的接受。很怀念为了来这里付出的努力，但得到之后并没有珍惜。
• 周围人的期望，领导的看好，再加上我的求胜心切，让我盲目的以50的战斗力挑战100的要求。难免不会显得力不从心，有点像高中时期，还带着初中的光环，以为自己无所不能。对自己没有太清晰的认识，处事也不足够圆滑。
• 越是感受不到成就，越是想做更难的任务，心中的英雄主义无时无刻再告诉我自己去做点出彩的任务，却忽视了自身的战斗力。
• 越是在日常工作中的愚钝表现，越让我斗志消沉。

我在期间陷入长期的自我怀疑和颓废，一直在想到底适合我的是什么，我反馈给TL的愿景到底是真实要想要的还是不甘心？长期以来我也没有想出自己到底想做什么，也许真的陷入了能力陷阱？我也不知道，不过也许可以尝试一下新的认知。

也许是想太多，根本原因已经找到，就是职业要求和个人能力不匹配。现在必须采取一下方式进行破局。

• 不再纠结自己到底适合什么，做好手上的每一件小事，积累满足感，成就感，为自己提供正向激励。
• 专研所在领域，每天学习一点，积跬步，积累满足感，为自己提供正向激励。
• 努力做好手上的小事，学习好计划的内容，越努力越幸运。
• 别忘了自己当初是因为什么契机才涉足云计算领域的？又是为什么在跳槽的时候可以升职加薪？再说的远一点，当初是因为什么才能得到的全国数学竞赛二等奖，或者演讲比赛二等奖？

没啥说的了，干吧。