一、干系人分析
干系人分析是系统地收集和分析各种信息，以便确定在整个项目中应该考虑那些人的利益。通过干系人分析识别出干系人的利益、期望和影响，并把它们与项目的目的联系起来。干系人分析也有助于了解干系人之间的关系，以便利用这些关系建立联盟和合作伙伴，从而提高项目成功的可能性。在项目或阶段的不同时期，应该对干系人之间的关系施加不同影响，所以，要基于干系人的价值进行分析。
1、故事地图
故事地图是客户价值优先级排序的工具，提供了一个关于功能合适交付的产品路线图。故事地图解释哪些会纳入第一个版本、第二版本或者子版本。故事地图还可以用作和跟干系人沟通的工具，把地图放在墙上作为一个项目计划的信息发射源。故事地图鼓励大家用不同的凡是参与，通过可视化的展示引发干系人的关注。
2、干系人价值排序
把干系人和用户的优先级纳入到项目的优先级中并且执行，结合干系人的优先级来进行项目优先级的排序，让干系人价值具体化，确保不要做一些干系人不支持或者没有价值的功能。
分析干系人价值的一种方法就是让业务代表参与到待办事项的优先级排序中。在功能实现的时候，按照业务代表指定的顺序进行，就可以尽早地把最高优先级的功能交付到市场，从而给客户带来竞争优势。
二、管理干系人参与
管理干系人的参与是指在整个项目中，与干系人进行沟通和协作，解决过程中出现问题，促进干系人合理参与到项目的相关活动。管理干系人的参与可以帮助项目经理提升来自干系人的支持，并把干系人的抵制降到最低，从而显著提升项目成功的概率。管理干系人的参与有多种方法，但是不管采用哪种方法，都要确保管理干系人的参与是可视的并且是可监控的。另外，要鼓励干系人参与计划会和回顾会，从而提高干系人的参与。
在知识型项目中，工作经常是不可视的，与干系人频繁的沟通尤其重要。大部分的决策都是在项目过程中决定的，在很多项目中，经常会因为没有合适的沟通而出现一些问题。为了避免这些潜在的问题，敏捷方法提供了很多沟通方法和软技能去解决问题。
三、沟通方法
有效沟通是敏捷的奠基石，沟通是在不同部分传递信息。沟通管理是敏捷的一个知识领域，PMI除此之外有几个关于沟通的定义。
- 沟通计划：确定项目干系人信息和沟通的需要
- 信息分布：适时地提供给项目干系人需要的信息
- 绩效报告：收集、分派绩效信息，包括状态报告、进展衡量、预告
- 管理项目干系人：管理沟通去满足要求，以及项目干系人一起解决问题
从敏捷的角度而言，团队间的沟通建立在过程中，通过写作、信息发射源、日常站会、回顾会、等得以促进。敏捷中的沟通倡导可视化，希望产品负责人、顾客、用户能高度参与项目并使用沟通技巧。
1、面对面沟通(高带宽沟通)
在敏捷中，最好的沟通方式就是面对面沟通。面对面沟通是沟通中最高带宽的沟通，所以面对面沟通也可以称为"高带宽沟通"。面对面沟通在同一个时间内可以传递的信息最多，并且能够获得一些及时的信息。而静态的沟通方法，例如文档，就不能做到这些。
在面对面沟通中，参与者可以很快速地理解信息，并且通过提问的方式及时获取反馈。这些对话还可以借助一些非语言沟通方式进行，比如手势、面部表情、语言语调、情绪和态度，这些非语言信号传达了大量的情感。
2、信息发射源
项目通常需要很长时间才能完成，但是客户经常在描述他们期望的东西后希望可以尽快获得。因此，频繁地给干系人展示项目已经实现的东西就显得很重要。这些模型或者展示并不是单单让我们检查我们正在构建的东西，还可以给客户或者发起人进行一些过程展示。因此，需要及时跟干系人沟通，确保他们被及时告知当前项目的状态。
信息发射源是一些列高可视化展示信息的方式，包括大图表、图形以及项目数据概要信息。这些工具，有时候代表"可视化控制"，可以快速向干系人展示项目的状态，并且这些信息经常在高流量的并且最大曝光度的地方展示。信息发射源是阿利斯泰尔 科伯恩(Alistair Cockburn)发明的，与"信息冷冻机"中被锁定的实践形成对比。在信息冷冻机中，没有人知道进展如何。相反，信息发射源高可视化的图形的方式向干系人传达项目信息，这些信息包括：已完成的、进行中的及其它重要信息。这些类型的数据可能会被展示在信息发射源中：
- 需按期交付的功能与剩余的功能
- 谁在从事什么工作
- 当前迭代选择的功能
- 速度和缺陷度量
- 回顾会发现的问题
3、燃尽图/燃起图
与客户密切联系并且给他们展示已经构建的项目的一些组件，保证项目过程的实际速度是可视的。过程的实际速度并非发起人或者客户所听到的，有时候会存在偏差，甚至对干系人来说是坏笑话。如果这些信息能够被尽早交付，即使坏消息也是有价值的。通过监控和讨论这些信息，可以做出更好的权衡。
燃尽图和燃起图是用来显示过程并且帮助判定项目(或者一个项目中的版本)应该什么时候被完成的。燃尽图显示了一个项目中剩余的估算，而燃起图则显示了已经交付的东西。这意味着，完成的工作越多，燃起图将会显示向下移动的一个过程指示器，从而显示剩余的需要完成的工作。相比之下，燃起图中的这个过程指示器将会向上移动，显示已经完成工作的增长。燃尽图和燃起图如下：
4、速度
速度是每个迭代中对团队能力的一个度量。这个度量帮助我们基于上一个迭代完成的故事点数评估团队后续的工作能力。当我们想跟联系人沟通已经完成什么功能，将要完成什么以及我们期待什么时候完成项目，速度就是一个很好的度量方式。团队可以在任何工作单元去测量其的速度，所以，这些单元可以是小时数、天数、点数。
速度经常会在开始的几个迭代中不一致，然后慢慢稳定。这是因为团队有一个不断熟悉工作和逐渐协作的过程。
5、敏捷建模
敏捷建模涉及敏捷项目中常用的建模技术。模型在敏捷方法中非常重要。敏捷经常聚焦在模型的讨论和创建，而不是最终的产出物上。敏捷模型经常需要在白板上画出来，然后通过拍照记录下来。
敏捷模型是轻量级地区捕捉设计，而不是追求细节上的完美。可以在敏捷建模中用到敏捷模型包括：
- 用例图形
- 数据模型
- 屏幕设计
不管你创建的是什么模型，目标都是为了交付价值而不是无关的文档。所以，要保持轻量级，快速移动以适应变更。
6、频繁讨论"完成"
知识型项目的产出经常是无形的，为了减少彼此理解的偏差，把项目中出现的每一个新的想法或观点尽早地且频繁地展示出来，对于干系人之间的连接非常重要。如果团队想减少一些沟通中的隔阂，减少受到低质量的产品，那么其就要去频繁地讨论什么是"完成"。创建一个共同认可的"完成"的定义在管理干系人期望时非常重要。对软件项目来说，在声明什么事是"完成"时候之前，可以参考诸如以下常规的说法。
- 已测试：所有的单元测试、集采测试和用户测试都已完成
- 已编码：所有代码都编码完成
- 已设计：代码已根据团队的需求完成了重构
四、软技巧
1、授权
授权团队进行自主管理，了解如何通过最少的管理参与解决问题，是敏捷方法论的基石。这与传统项目管理者的观点不同，传统项目管理者控制所有决策同时委托任务给团队，几乎无反馈。敏捷团队决策必须包含所有成员和干系人且决策方便。因为客户参与到开发中非常重要，所以需要鼓励客户通过集中/现场支持与敏捷团队密切融合。当敏捷团队承担产品传递的责任时(即拥有所有权)，团队自身感受到授权。
2、谈判
谈判在敏捷项目中会出现，尤其是在讨论需求或者功能的优先级以及完成的定义的时候。团队和客户可以在功能和成本之间进行权衡，从而找到一个合适的方案。在敏捷项目中，谈判并非一定要做，而不是一个零和游戏，正如敏捷宣言"客户合作胜过合同谈判"。"健康的"判断可以给双方一个机会去充分描述每个观点，权衡利弊。
3、冲突解决
冲突是项目工作中不可避免的一部分。当大家集中去解决一些问题时，就会存在观念的差异性以及竞争利益。有些程度的冲突是"健康的"，可以确保一些观点在应用之间被充分地阐述和验证。但是，我们需要确保冲突不要升级。
创建一个让大家可以提出建设性的冲突的环境，对成功管理干系人参与项目来说非常重要。当冲突超越了正常界限时会变得具有破坏性。Seep B.Leas提出了一个描述冲突的框架，帮助我们判断冲突的级别并且更好地理解冲突从1级(解决问题)上升到5级(世界大战)，如下：
-第1级(解决问题)：语言一般来说都是敞开心扉的并且有建设性的，大家用一些事实去证明他们的观点，客观陈述事情本身。对于第1级冲突而言，尝试帮助大家建立一个每个人都能支持的达成共识的决定。
- 第2级(争论)：言语之中开始包括一些自我保护的东西。对于第2级冲突而言，授权给团队去解决，这可以帮助团队成员达成对某个决策的支持，并恢复一种组织的安全感。
- 第3级(竞赛)：争执中出现了以偏概全、推论和放大。冲突变得有职责性。对于第3种冲突而言，需要容纳大家不同的观点，这也许在工作本身上会有一些妥协，但是团队的价值观必须始终坚持
- 第4级(战斗)：冲突变得越来越意识化和极端。对于第4级冲突而言，需要利用交际手段，因为对立双方之间的沟通已经充满了破坏性，团队可能需要一个第三方的中立的引导员去传达信息。在这个冲突层级中，我们需要努力让冲突降级
- 第5级(世界大战)：言语都是好斗性的 ，很少直接跟对方说话，搞团队内战。如果冲突达到了第5级，则基本是不可能解决的，所以，我们不需要尝试去解决它，而需要找出一种方法，让团队冲突共存，需要把对立双方单独分开，防止进一步伤害。
如果这个冲突在第1~3级，不要立刻采取行动去解决冲突，而是让团队自己去解决。因为自组织团队是需要尝试自行解决问题的。如果团队能够自己克服冲突，它将会提升一项重要技能，在将来可以自我管理类似的冲突。如果对于这个冲突，团队不能解决，而且这个冲突还有可能升级，那么敏捷项目经理就需要介入。
总之，当人们在一起工作时，冲突是常见的且不可避免的。我们应该多给团队一些机会让它去解决冲突。如果教练必须介入，应该想办法管理团队成员的情绪，让冲突降级，寻找一些继续前进的方法。
4、积极聆听
减少误解和错误信息传递的一项沟通技能是积极聆听。积极聆听是指听到说者想表达什么，站在说者的角度去考虑，而不是仅仅听到说话的内容。根据关注点的不同，可以把聆听分为以下三个层级。
- 层级1：
内容聆听，即仅仅听到说的内容，听者根据自己的信念模式去解读，忽略了说者的真正意图。- 层级2：
专注聆听，即不仅听到了说话的内容，还关注了说者的语言、语调等表达方式，把自己放在了说着的角度，用移情的方式感受说者的想法以及情感。- 层级3：
全局聆听，即除了听说到的内容，关注说者的语音语调，要更多地注意到说者的动作或者手势等这些肢体语言。例如，我们注意到说者一直在看手表，可能说明他在在赶时间。积极聆听属于层级3，是一种全局聆听，通常包括如下动作：
- 关注当下，集中精力与演讲者，不仅仅包括演讲者说话的内容，也包括说者的语调和情绪。
- 做笔记、不打断
- 确认或复述所听到的内容
- 善用开放式问题、适当的肢体语言和沉默来提高聆听技巧
5、参与式决策
参与式决策鼓励团队成员参与过程决策。决策的速度和团队对这些决策的认可程度都会直接影响项目绩效与团队凝聚力。沟通和参与决策对保持每个人参与非常重要。如果在做决策的时候不咨询团队成员的想法，团队成员就有可能感觉自己被孤立或者隔离，这对于自组织团队的打造是一个风险隐患。
敏捷鼓励领导进行更多的授权和更少的命令控制。团队授权不仅可以提升干系人的满意度和生产力，还可以提升决策过程的有效性。以下为常见的几个参与式决策的模型。
- 1、简单投票
即直接用手表达赞同还是反对，简单的"支持"或者"反对"的投票。这个决策比较快速，帮助团队避开一些两难的讨论，但是会省略一些细节。- 2、拇指法则
即采用拇指向上、向下或者一侧的方法进行决策。它对一个简单的投票来说也比较有效。拇指指向一侧的人不能发表观点，有时候这些成员在某些观点上是中立的。这个方法比让小组中的每个人都投票更快速，因为大部分的人没有一些明确的观点。- 3、决策光谱
即团队成员通过对光谱放一个标记"有利于"到"迷惑"到"绝对反对或者支持"去表达他们对这个决策的感觉。这个模型让大家在表达他们对这个决策的支持时，还可以表达他们的保留意见- 4、First-of-Five投票
这种方法比较快速，通过显示手指的数量表明他们的支持程度。需要在前期定义清楚五个指头的意思是"完全赞同"还是"还是完全不同意"
我们需要找出一些方法让干系人参与到重要的项目决策中，包括迭代计划和版本计划，估算讨论和回顾会。如果这些人不参与，他们就不会对这个决策做出承诺。最终，他们也不会对这个项目做出承诺。
6、有效领导
领导需要确保"做了正确的事情"，关注方向。管理需要确保"正确的做事"，关注方法。相对于领导来说，管理聚焦更多的流程机制、任务控制上。领导更关注人与目标。但是，并非说领导比管理者要好，有些场合依然需要管理，把领导和管理结合起来去打造团队的高效生产力。
(1) 服务型领导
敏捷提倡服务型领导，聚焦在给团队成员提供需要，移除障碍，并且执行一些支持型性的工作进而最大化团队生产力上。一个领导在团队中的主要角色为以下四类：保护、保障、保持、保姆。
- 保护：
保护团队不被中断。服务型领导需要隔离并且阻止团队成员注意力的转移、中断以及去做一些不属于这个项目的工作。任务中断需要来回切换，这本身也是一种浪费，保护团队不被干扰会提升生产力。集中办公是一种保护团队不被中断的方式。- 保障：
移除障碍。服务型领导需要清除团队中可能会引起延期或者不增加价值的障碍。这些障碍可能包括工作的浪费或者投入精力去做一些合规的活动。在精益中，合规工作是不直接交付价值的活动。在每日站会中，第三个问题就是“你遇到了什么障碍”。领导者需要注意这些障碍并最好在当天安排去解决。- 保持：
保持持续引导项目愿景。支持的项目愿景对成功领导一个项目至关重要。只有当干系人对要完成的工作有一个清晰的目标时，才能更好地参与项目。沟通项目愿景帮助干系人识别这些分歧并且让他们按照项目的目标进行。服务型领导需要持续地寻找一些机会以持续沟通项目愿景，进而达到对团队的有效激励。- 保姆：
为团队提供支持。为保持一个高效生产力的团队提供必要的资源，包括工具、食物和其他福利。在一个迭代结束时，可以帮助团队成员充电，比如团队成员参与一些培训以获得新的知识和技能，体现团队对个人成长的培养。
(2) 挑战现状
我们要不断的创新以寻找一些改进的方法，通过实践去学习和成长；鼓励干系人为改进提出一些新的想法，并给他们机会去尝试；鼓励团队去挑战现状，既可以践行过程改进，还可以激励团队成员。
7、分布式团队
分布式团队在面对面的沟通中会存在一些挑战，用信息发射源这样的协作工具会比较好。但是，这是一个大部分项目需要解决的挑战。数据显示，超过50%的敏捷项目团队至少在一个不同的物理办公区域。为了解决这个问题，分布式团队可以用一些沟通的技术，比如语音会议、实时聊天或者用它们自己的方式提供一个共享的团队环境让分布式的这些干系人进行实时交互和聊天