ACP.敏捷概念梳理1

908486905

已于 2023-04-06 22:38:30 修改

阅读量1.7k 敏捷开发ACP 文章标签：敏捷

于 2022-12-20 20:22:20 首次发布

本文链接：https://blog.csdn.net/u010025781/article/details/128389475

敏捷开发ACP 专栏收录该内容

22 篇文章 9 订阅

第一部分

敏捷铁三角的参数：价值，质量，约束。传统的铁三角包括的参数是范围，进度和成本

敏捷计划的三个主要层级为：发布计划，迭代计划，每日计划

敏捷开发模型的特征包括开发由多个迭代组成。

敏捷拥抱不确定性，而瀑布式开发试图消除不确定性并管理它。

Probe探测是用一个快速试验来解决问题，而不是永无休止地讨论。这是使用此方法的一个理想场景。

scrum 的三大支柱：可视性、检验和适应性。

敏捷的方法是在复杂决策的环境下用的最好

零迭代期，团队通常做计划，没有可用的软件交付客户，在敏捷中，计划不能产生内在价值，只有可能的软件才能转化价值。

迭代H ：也被称为加强迭代，此时没有新的功能被开发，而是已有的功能要测试

授权团队负责管理迭代（冲刺）未完项，而产品负责人负责管理产品未完项。

信息发射源的对立面是信息冷冻机。信息冷冻机是一种图表或组件，你必须开发或探索才能理解里边的内容。它意味着不透明。

产品未完项的属性应该是 deep : 详略适宜的（detailed appropriately）、可估计的（estimated）、涌现式的（emergent）、排好优先级的 (prioritized)。

“完成”的定义是整个团队确定的。

一个功能点从开始到完成所花费的时间被称为循环时间

产品负责人是敏捷项目中的重要角色。产品负责人这个名词专属于scrum,但他相当于别的方法论中客户的角色。由于产品负责人的参与度很高，很多会议都会邀请他参加，所以这个问题有点难度。迭代回顾会议是核心团队的会议，他们在会上会查看在前一次迭代已经完成的工作并讨论下一次迭代怎样做好，团队查看自己的工作时，产品负责人在这个会上发挥的作用不会很大。客户和产品负责人负责编写用户故事。产品负责人角色存在于scrum中，其他架构中都是以客户角色出现的。

根据亚伦•桑德斯所说，敏捷失败（失败模式）的前 12 条是：

       1.承诺没有自动产生组织变化或获得支持。

       2.文化不支持变化。

       3.文化没有反思，或者执行反思不足。

       4.在项目收尾过程中丢失标准和质量。

       5.计划中缺乏协作。

       6.缺乏或者过多产品负责人。

       7.项目领导力不足，或者 scrum 主管不信任团队并不允许团队自主管理和自我约束。

       8.没有现场的敏捷支持者或者教练。

       9.缺乏一支完善，高绩效的团队。

       10.不维持严格的测试标准的情况下，技术债务会增加。

       11.文化维持传统的绩效评估，即推崇个人时丢失团队方面。

       12.因为变化难以进行，所以传统或“旧式”的经营方式出现。

漏网缺陷是一个软件缺陷，没有被开发或测试团队发现，但是后来被终端用户发现

1. 估算

计划扑克应该在开发用户故事之后和创建故事点之前使用。因为计划扑克就是采用用户故事来创建故事点的。计划扑克是基于宽带德尔菲估算技能、也是以共识为基础的工作量估算技能。有时候也称为 scrum 扑克，往往在故事点和开发用户故事中用来估算相对工作量。

在计划扑克会议中，每一位估算师各派有一副相同的价值范围宽广的计划扑克卡片。

斐波那契数列常用来衡量计划扑克的价值（即 0,1,2,3,5,8，等）；

另一种常见数列是（问号，0,1/2,1,2,3,5,8,13,20,40，和 100）。

计划扑克会议按如下运行：

1）一名调停人，主持会议，不参与估算。

2）产品负责人/管理人员对用户故事作概述，并回答开发者提出的澄清问题，往往产品负责人不参与投票。

3）每一位估算师抽取一张卡片来估算工作量。

4）每人抽取一张卡片后，同时将他们的卡片翻转，

5）持高和低估算的估算师各有一个机会作立场辩护。

6）达成共识前，不断重复以上流程。持有用户故事的开发者往往拥有较高可信度。

团队正在开会讨论估算。每次估算都将范围绘制到图上进行讨论。团队用的是哪一种方法？使用了宽带德尔菲。在这个技术中，范围被标记在一个图表上并用于讨论。

在其他条件都相同的情况下，亲和估计估算方法速度最快。

亲和估算是预测工作量的一个方法，通常在故事点，开发用户故事中，而尤其在大型产品待办事项中作用巨大。虽然还有其他估算方法，但是基本的亲和估算模式涉及从小到大范围里测量用户故事。这个范围可以是斐波那契数列或者 t-shirt 尺码，常常贴在大型会议室墙上。然后参与者在估算时可将他们的用户故事贴到这面墙上。这种估算常在无声中进行，且直到评估用户故事，常伴有若干迭代。

估算开发一个用户故事的相对工作量时，分配给每一个用户故事的时间通常称为时间箱，那么往往每一个用户故事的时间箱值是2-3分钟

进行计划扑克时，每一个用户故事应分配2-3分钟。往往设定的时间值是 2 到 3 分钟来讨论用户故事。

故事点表示开发一个用户故事的相对工作量。每一个故事点表示一个固定的开发工作量值。当估算敏捷团队时，必须考虑复杂度，工作量，风险和依存关系。

故事点是开发工作的固定单元，用在相对测量用户故事中，以达到估算参与开发的工作量的目的。故事点并不以时间为基础，而以意义为基础。

用户故事或者特性首先在发布计划期间被分配到迭代中。如果用户故事是特性，那么在迭代计划期间会被分解成若干任务，这样任务可再分配给特定的开发者。为便于管理计划和监控，估算任务持续时长的一条经验是每一项任务的应大约占开发时长的四小时到两天。

如果一个团队快速估算用户故事工作量并用 xs、s、m、l 或 xl 标注，有可能使用了下列哪个方法？近似估计

敏捷开发中的主题是指一组有关的用户故事。

开发一个用户故事的理想持续时长是2-5天；史诗故事是一个大型故事，可能横跨几个迭代周期。它也被称为一种能力。

速度是指对每一迭代团队完成的用户故事点或故事数量的衡量。一个敏捷团队可根据稍前的速度记录来估算下一个迭代可完成的用户故事点数量。

周期（完成一个用户故事的时间）应该随着迭代期的推进一直缩短直到其达到最佳水平。周期是一个用户故事中从规格说明到可运作软件整个过程所需的时间量。

正常情况下，开发速度随着项目的进展而提高，然而会受到很多因素的影响。

除了使用故事点来估算用户故事的相对尺码外，敏捷团队还可使用理想时间。理想时间代表时间量，即不受会议，个人生活，非工作日或其他拖延，障碍和分心的干扰的情况下，相对于待办事项中其他用户故事，单独个人建立，测试和发布用户故事所花的时间。

一个用户故事为0，说明开发团队只需要很小的努力

可以通过解聚把大的用户故事分解为小的更易于处理的故事。Disaggregation解聚将史诗故事或大型故事分解成小型用户故事,解聚类似与传统项目的分解。

用户故事要点（Ron Jeffries，3C---Card（卡片）、Conversation（会话）、Confirmation（确认））：

简述：用卡片（Card）来简要描述故事。

细节：与Product Owner（或客户）交谈（Conversation）来明确细节。

确认：验收评审，确认（Confirmation）被正确完成。

敏捷主题是一系列故事、迭代或版本。例如，一个迭代主题可能是报告，因此大部分或全部的用户故事都可能和生成报告相关。

时间盒是管理某个时间被限定的项目的一种方法。只有在规定时间内通过验收的功能包含在时间盒内。

时间盒法约束了团队，尽管不是以一种特别消极的方式。它只是规定时间上不能灵活变化，但是范围可以变化。这种情况下迭代和版本在进度上都不会灵活。

发布计划有助于客户和敏捷团队决定每一个项目时间范围或者阶段内应该开发的内容和一个产品理想上准备发布的时间。

在发布计划会议，敏捷项目管理者和开发团队相信讨论产品前景。这确保适当要求，验收标准，优先排序建立。

力场分析是寻找推动和阻碍变化的因素并给因素分配编号以了解两边力量的总和。

德尔菲法是一种结构化的方法，严格按照流程执行。参与的专家采用匿名方式发表意见，相互之间不得讨论，不能发生横向联系，只能与调查人员进行沟通。通过多轮次调查专家对问卷所提问题的看法，经过反复征询、归纳、修改，最后汇总成专家基本一致的看法。

宽带德尔菲方法是德尔菲方法的进一步发展，采用收敛原则来判定专家们的意见是否已经趋于一致。这个收敛原则——带宽——是专家们基于估计对象的特征和集体经验讨论达成的共识，并在估计过程中用这个收敛原则来判断专家的意见是否已经趋于一致

线框图是一种无须实际功能或代码就能演示界面的快速方法，也是向用户展示他们能够理解的概念的快速方法。

影响项目的5 个核心风险区包括：

生产率变化（计划和实际操作之间的差距）；
范围渐变（初始协议以外的大量附加的需求）；
规格故障（干系人对需求的共识的缺失）；
内部日程的缺陷（对任务工期的错误评估）；
人才流失（人力资源的流失）。

因为每一项迭代通常产生的工作产品是完美整合的，迭代往往持续 2-4周，期间不断地进行验证和确认以确保产品的质量。验证是为了确保产品的执行符合客户的描述需求（例如用户需求指出的），确认是为了证明产品的执行符合预期（即符合客户需求）。有时候一个产品可能是依照规范完美整合，即它可通过验证，但是它并不符合客户的目标，即它不能通过确认。

产品负责人所拥有的产品路线图，是产品需求的高层次概述，常用作特性优先处理，特性归类和粗略时间框架确定的工具，有利于促进组织特征。

创建产品路线图需遵循 4 个步骤：

       1）确认需求（这些会成为产品待办事项的一部分），

       2）将需求分类或分定主题，

       3）评估相对工作量（例如，计划扑克或者亲和估算）和优先化（价值），

       4）评估粗略时间框架（评估高速和冲刺持续时间，以及粗略发布时间）。

信息发射源的定义是对项目有关的数据的可视化展示。

项目的燃尽图是一个常用的来展示迭代进度的信息发射源。它记录两项序列：剩余的实际工作和剩余的理想/预估的工作。竖轴是工作单元（常是故事点或时间），横轴是迭代持续时长（常是日期数字）。理想/预估的工作序列是条向下倾斜的直线，由需完成工作价值（例如 20 故事点）的竖轴出发，延长至横轴上迭代的最后一天（即 0 故事点）。实际工作序列每日更新，取决于敏捷团队的生产率和任务的复杂性。实际工作序列常常是易变的，并非直线，它随着项目团队干涉开发流程而消长（往往是非线性的，反映开发的起伏）。

最小可售功能（mmf）是一个最小和可市场化的软件特征或者产品特佂。“最小”的意思是简单和小，并且不复杂。“可市场化的”的意思是拥有部分价值，无论是产生收益或者节约成本，都可进行市场化或者销售。

敏捷统一流程(aup)是统一流程或称 up（up 本身是更详尽的迭代和增量软件开发的框架）的简化版。aup 为敏捷框架简化 up。aup 项目包含 4 个阶段：

       1）创始

       2）细化

       3）建立

       4）转变。

在每一个短迭代结束时，团队交付一个工作产品。

验收测试驱动开发（atdd）与测试驱动开发（tdd）类似，在于它同样需要编程人员在产品代码前编写出测试。验收测试驱动开发的测试旨在验证预期软件中的特性/行为。

验收测试驱动开发的迭代迭代的 4 个步骤可简记为 4 个 ds：

1）discuss 讨论：敏捷团队和客户或者商业干系人详细讨论用户故事，包含用户故事应有和不应有的预期行为。

2）distill 提取：开发团队研习讨论中的条目并提取成可验证和确认这些行为的测试。提取流程中，整个团队应充分认识“完成”对用户故事的意义，这正是验收标准所在。

3）develop 开发：提取后，团队开发测试代码和产品代码以产生产品特性。

4）demo 示范：产品特性开发后，团队向客户或商业干系人展示以获得反馈。

一个健全的站立会议的重点特征包括：

       同辈压力——因为团队靠大家，所以同辈的期望可带动进步；

       密切的配合——团队应当理解对专注的必要性并独立工作；

       细在专注——团队应当理解每日站立会议中简洁的必要性，由此团队才有效益；

       每日承诺——团队应当理解对每人每日承诺的价值所在，并兑现这些承诺；

       辨别障碍——团队应当集体意识到每个人的困难，由此团队可集体尝试解决。

一个复杂的适应型系统（或称为 cas），是指由互动，适应型主体或成分组成的系统。这一名词是用于在敏捷中提醒敏捷专业人员，一个产品的开发在之前能影响未来行为的互动，事件和决策中是适应型的。混序这个词有时候用来描述 cas。资料中显示混序项目的三个重点特征是：

结盟和合作

浮现和自我管理

学习和适应

在敏捷设计流程中，原型有助于客户了解当前设计状态。3 种常见的原型是 html，书面（即概述）和线框。线框是用户界面的概述，确认它的内容，设计和设计功能，常是黑白色，剔除细节性的图片和图像。线框可在纸上，白板或者软件上创作。

在早期的需求收集中，一个重要干系人一再提出现行需求讨论话题之外的需求。团队怎样处理：团队应该把干系人的关注点增加到停车场图中。这是停车场图的根本目的。它用来抓住可能重要的但应该以后再关注的偏离主题的信息。

敏捷开发的基石是“增量交付”。增量交付是指为及时反馈和接纳，频繁向客户交付连续改善的工作产品。为演示和反馈，往往在每一个冲刺或迭代的末期交付产品。这项反馈技能，可使客户评价产品并提出新的需求。在敏捷流程中，接受变动/更新/改善的需求，以确保客户得到有价值和质量的产品。一个冲刺或迭代往往持续 2-4 周，最后，渐进地交付一个新的并改善的产品。

精益基于 7 条原则，即消除浪费、强化学习、尽可能晚决策、尽可能快交付、授权团队、构建完整性和全盘检视。

价值流程图是敏捷采用的精益生产分析技能。一张价值流程图可能用于分析信息或者材料的流动，从它们的源地到重点，以此来识别浪费区域。识别出的区域成为流程可完善的地方。浪费的形式非常多，可用 widetom 来记忆。

       w---waiting 等待

       i---inventory 库存

       d---defects 缺陷

       e---extra processing 额外流程

       t---transportation 运输

       o---over-production 过度生产

       m---motion 动态。

价值流程图是敏捷采用的精益生产分析技能，用于对形成客户产品或服务的原料和信息（即价值）的流动进行分析。执行价值流程图大致包括 5 个步骤：

1）确认产品，客户和范围（即流程的始末）。

2）地图作为团队或者个人现时价值流，确认流程步骤，延时和信息需求。估算流程步骤的持续时长和前置期持续时长（lead time durations）。前置期是指在发生前一项流程或者事件需等待的时长。

3）分析价值流程图来确认浪费存在的地方（比如前置期）和流程可完善的地方（流程时间通常认为是价值增加时间，但是应尽量减少整个流程的时间，由此来缩短向客户交付价值流的时间）。

4）通过分析，总结出一份展示价值流应努力达到的前景或者目标的未来价值流程图。

5）通过流程完善活动（即完善）或者其他方法来达到目标的一些工作。

你作为一名新的团队成员刚刚开始在一个敏捷项目中工作，墙上有张图显示了积压的、开始的、设计了的、编码的和完成的工作项。这是什么图？这是累积流量图的经典例子。它表明了在系统中进行的、还没开始的和已经完成的工作。看板面板也符合问题描述，但是他不在4个选项中。

敏捷团队必须时常处理产品待办事项里的产品特性优先级问题。从发布计划到迭代计划，敏捷团队必须优先处理产品的用户故事/特性来确保高质量和高价值的特性优先得以开发，以此帮助带来乐观和较早的投资收益。

敏捷团队往往在相对价值和风险方面优先处理需求或用户故事/特性；价值由客户决定（即客户-价值优先级）。

两个处理产品优先级的常用方法是：moscow 和 kano。

moscow 方法将产品特性分为“必需含有”，“应该含有”，“可以含有”和“会含有”四类。

而 kano 方法将特性分为“必须含有（开端）”，“不满足因素”，“满足因素”和“愉悦因素”。

       “必需含有”是指必需含有的特性。

       “不满足因素”是指反过来影响感知价值而应该移除的特性。

       “满足因素”是指此类因素越多客户越满意，能够正相关地增加感知价值的特性，但并不是必需的。

       “愉悦因素”是指能指数型地增加感知价值来满足客户的特性。

依据风险来优先处理特性，可运用风险-价值指标。

风险-价值指标含4个象限，横轴表示价值，竖轴表示风险。用户故事被分配到其中一个分类/象限：低价值，低风险；低价值，高风险；高价值，低风险；高价值，高风险。成本-价值指标同样可用这种方式形成。

敏捷中所有的优先化都是“相对的”，也就是说一个用户故事只是相对优先于其他用户故事，而非在固定规模上得到优先处理。"

缩写 smart（specific 详细的，measurable 可测量的，achievable 可完成的，relevant相关的和 timeboxed 时间定量）有助于敏捷工作者记忆一项明确任务的特征。

       s-specific 任务是指明显有助于用户故事开发的任务，应该是清晰明确的。

       m-measurable 任务是指团队和客户能够验证的任务。

       achievable 任务是指开发者可切合实际地执行和理解的任务。

       r-relevant 任务是指明确地为用户故事增加价值的任务。

       t-timeboxed 任务是指能够对开发所需的工作量和时间进行估算的任务。

滚动计划（或计划前滚动 rolling look ahead planning）包括部分波动性和阶段性的计划，尤其是在大型复杂的项目中作用明显。只有未来几个迭代会作细节计划，而时间较遥远的迭代则只作高层次计划。逐步完善则假定细节和需求会逐步得到改良，并且会适时融入到计划流程中。

在滚动的前进计划中，一次计划多少个迭代？接下来的几次迭代

在使用负责项目的滚动波或滚动预测未来计划时，敏捷团队计划在下几个迭代中的工作。一个滚动波或滚动预测未来计划聚焦于计划准备完成的工作，并非超出这个门槛的工作，因为未来太遥远。

闪电战计划包含故事的依存关系和涉及使用卡片来计划项目，其中时效性、任务和故事的依存关系被确定和考虑。

吉姆•海史密斯敏捷项目管理模型包括以下 5 个阶段：构想，推测，探索，适应和结束阶段。

海史密斯敏捷企业架构的 4 个层次包括：

       投资管理分层

       项目管理分层

       迭代管理分层

       技术实践分层。

水晶是软件开发灵活轻便方法的方法家族。方法家族是区分成员的颜色代码，例如透明，黄色，红色。颜色的选择取决于成果水平的要求。在光谱一端是完全透明的。不考虑颜色，水晶架构是迭代的并且有三个基本过程：

章程

交付迭代

项目总结。

水晶纲领包括：

建设团队，

做探索性的 360，

为团队定义实践标准/微调方法论，

建立初始项目计划。

在交付周期中，水晶团队开发，集成。像其他敏捷架构，水晶包括协定事件，像站立会议和反思提高工作室。在包装中团队总结项目，进行完成仪式。

时间，预算和成本估算是敏捷中重要的知识和技能板块。根据海史密斯的观点，由于其接受变动的范围，敏捷方法的本质意味着它为固定的预算和进度提供良好的支持，但变动的范围使总成本的估算更艰难。

总体来说，预算和进度的约束是已知的，但是这发生在项目初始阶段，开始需要定义一组商定的基础产品功效前；固定的范围降低了敏捷团队提供提高的价值的创新确实。

对于熟悉固定价格合同的公司来说，合同签订前里面的需求已是商定好的，而采取敏捷会是一个折磨人的冒险。

相反，其他的合同类型会推荐给敏捷工作，包括：初始阶段的一般服务协议和为迭代或用户故事分开设置的固定价合同；工料合同；不超过固定费用合同；最后奖励性合同（例如，固定价加激励；成本加酬金及奖励合同）。

一项敏捷项目中，典型的信息发射器包括：项目燃尽图，任务板，燃起图、缺陷图表。

风险燃尽图是用于跟踪项目伴随时间风险的风险管理技能。通过风险燃尽图，干系人可迅速查看随着时间项目风险管理的绩效（比如提高，降低以及对应的量值）。严重度（影响和收益的产品）是沿着竖轴绘制，而横轴是时间。影响力的量值往往是 0-5，按风险升序排列。

收益率/可能性的量值往往是 0-5，按收益率升序排列。

例如，一项风险的最高风险度是 25（5*5=25），最低风险度是 0。

敏捷团队和客户/产品负责人识别到风险同时分配严重度值到风险登记册，并跟踪这些值。理想情况下，风险严重度会随着时间降低。

因为风险调整未完项是按照风险而不是按照价值进行排序，所以会和产品未完项有不同的顺序。风险调整未完项取决于风险估算的方法，才能决定是定性还是定量。

通过在风险调整未完项中对故事排序

适应风险的待办事项是指按风险整理的产品待办事项。风险可被估算为严重性/结果和可能性。用户故事也可放置在风险-价值矩阵中，得以在待办事项中优先处理。

风险-价值矩阵是有 4 个象限的图表：

       沿着横轴是升序价值。沿着竖轴是升序风险。

       高价值和高风险用户故事位于右上角。

       高价值和低风险用户故事位于右下方。

       高价值和低风险用户故事位于右下方。

       低价值和低风险用户故事位于左下方。

通常团队会优先处理高价值，低风险用户故事，接着是高价值，高风险的，然后是低价值，低风险的，最后是低价值，高风险的。

高敏捷情商的意思是自我意识，控制自己的情绪并能注意到其他团队成员的情绪。高敏捷情商使团队成员之间有效协作。

温馨而舒适的环境是在设计团队氛围时重点考虑的方面，它可以促进有效沟通，提升创造力和激励团队成员。构建良好的敏捷团队氛围的指导包括：

团队成员的协作；

减少非必要的干扰/分心；

为信息发射源提供专用白板和墙面空间；

为每日站立会议和其他会议提供空间；

结对工作站；

其他人性的措施如植物和舒适的家具。

建立一支高绩效的团队对于任何项目的成功至关重要。一支高绩效的团队表现为：

       授权正确的成员

       建立信任

       以可持续的步调工作

       保持稳定的速度/生产率开发

       有固定时间回顾和反思工作

       有团队领导负责移除任何障碍并提供指导和教练

       自主管理和自我约束

       协作的

       可运用以下几种管理技能建立或促进高绩效的团队氛围：

       移除任何降低团队绩效的障碍

       对团队绩效持高期望

       教练和指导团队达到自身的最佳绩效。

彼特是利用渗透沟通的原则来了解保尔的困境的。渗透沟通包括抓取视觉暗示，比如肢体语言。

一支高绩效敏捷团队是渗透沟通和面谈式互动的理想组合。

对于分布式团队，在没有组合的情况下，一些经验可以提供有效沟通的最佳形式：

       团队内部网站

       虚拟团队空间

       电邮视频会议

       地理分离，特别是世界范围的，团队要考虑语言，文化，时区不同。

积极倾听包括听、理解、保持和积极响应，但不包括记录。

不仅在敏捷中，富有动力的团队对其他任何项目都至关重要。富有动力的团队运作更流畅，生产效率高，表现超越期望值。可提高团队动力的简单步骤包括：

       1）共度黄金时间，团队成员可在个人层面上了解他人以此营造社区氛围，

       2）提供反馈，指导和训练，赞扬和感谢团队成员的出色工作，同时为技能和能力提升提供指导和训练，

       3）授权，授权团队成员作关键决策，在此期间，建立信任并显示领导对团队能力的信任

敏捷中，有效的“知识分享”是成功的关键因素，它需要所有团队成员和干系人对关键信息的近乎实时的交流。为了促进知识分享，敏捷在流程中运用标准实践，例如使用全面专家/多功能团队，

       自主管理和自我约束团队，

       协作，

       每日站立会议，

       迭代/冲刺计划，

       发布计划，

       结对编程和结对轮换

       项目回顾/反思

       现场客户支持。

当然敏捷的第六项原则是“开发团队内部和之间最有效和最有力的传达信息的方式是面对面对话。”从这层意思上说，敏捷倾向于和鼓励所有干系人和团队成员的协作，因为沟通的最好方式是面对面对话，并且反过来，促进知识分享。

基本上成千的决策都是在项目的过程中决定的，其中的许多决策是为了应对团队无可避免面临的问题的。因此适当地熟悉问题解决的策略，工具和技能对敏捷团队来说是至关重要的。部分常见的问题解决技能包括：

大声提问；

再次讨论问题；

5why；

沉没成本谬误；

故意持不同意见的人；

保持善良，回放；

提问探究性问题；

反映式/主动式聆听。

敏捷中一个常见的误解是敏捷团队并不需要一个领导者。事实上，所有的敏捷团队都需要领导者，但是领导团队的方式从根本上是不同于典型传统的项目管理人员/项目领导者的。一些学者从理论上阐释了这种误解是基于敏捷团队期望的“自主管理”品质。虽然“自主管理”的敏捷团队授权拥有产品的所有权并承担责任，同时可自行决策，尽管如此它仍需要一个领导者，来帮助提供指导，提供咨询，训练，解决问题和进行决策。

敏捷领导者所需的重要方面包括：

       授权团队成员决定敏捷实践和方法的标准；

       允许团队进行自主管理和自我约束；

       授权团队成员和客户合作决策；

       激励团队创造力和探索新思想和技术才能；

       成为提倡者，向团队成员阐释产品前景，以此激励完成整体目标；

       移除并解决团队工作中可能遇到的障碍和问题；

       向可能不熟悉敏捷的干系人沟通和宣传敏捷项目管理的价值和原则；

       确保包括商业管理人员和开发者在内的所有干系人有效协作；

       最后，能够依据工作环境改变领导风格，以此确保有力支持敏捷价值和原则。