最近在着手准备ACP考试,仔细看了下相关的书籍,对每章知识点进行相应的整理,想着记录下来,后续如有更好的理解,再回头更新。
之后会按照以下目录进行梳理:
- 敏捷的理念
- 价值驱动交付
- 干系人管理
- 打造高绩效团队
- 适应性计划
- 发现与解决问题
- 持续改进
- 敏捷的实践
干系人管理
-
干系人管理概述
为什么需要关注干系人:- 项目是人来执行的,标准是由人来定义的,人对管理在项目管理中非常重要;
- 积极的与干系人沟通,有助于项目朝着正确的方向,降低后期的变更的可能性和成本;
- 信息传递的偏差可能会导致项目的失败。
哪些是项目的干系人:
- 高管及项目发起人:虽然敏捷很好,但是在意新技术的带来的实践风险
- 管理者:使用敏捷带给他们控制权力的缺失和角色的冲击;
- 项目团队:可能会抵制一些新工具和新方法,觉得不必要改变;
- 用户:担心是否能做出来对他们有价值的产品;
- 供应商:是否能与项目节奏想吻合。
干系人管理的原则
主要有10点:- 干系人利益点需要随着时间趋于一致;
- 联合干系人并维护好关系;
- 找到一种让各个客户都满意的均衡的方法;
- 为服务客户,不以一个人的利益换取其他人利益;
- 制定目标,完成对干系人的承诺;充满报复,实现我们和他人的梦想;
- 和所有干系人进行彻底的沟通;
- 干系人包括样貌各异的承认和小孩,错综复杂;
- 需要概括时长营销方法;
- 与首要和次要的干系人接洽;
- 不断监督并且重新设计过程使其变得更好去服务干系人。
可以看出,干系人对项目成功很重要,干系人复杂,如何管理和调整与关系人的关系值得敏捷团队关注。
-
识别干系人
人物:用细节详细阐述用户信息;识别用户类别和在项目中能够发挥的作用;
线框图: 为干系人提供一种视觉化的方式帮助他们达成一致;
用户故事三要素:角色、目标和可达到的价值:
作为<角色>,我想<功能>,这样就可以<商业价值/益处>3C
card:物理卡片,作为需求的载体,充当需求的占位符。不建议使用电子卡片替代,目的是为了保证面对面的沟通和交流;
conversation : 故事包含的诸多细节需要和用户协商确定,延迟决策,后续确认细节的相关事宜,这样可以减少浪费。体现在INVEST中的“可协商”;
confirmation:包含验收标准和环节,以确保被正确实现。不变的准则是:验收标准必须在开发前确认。-
INVEST属性:
independent: 可以用任何一种方法进行用户故事排序和实现,相互依赖会影响客户对优先级的区分,避免让故事的工作量和难度与实现的次序相关。
negotiable: 团队可以与商业代表一起讨论用户故事并且基于某些属性做一些权衡,可以挖掘客户的真实需求;
valuable: 如果不能定义一个需求的价值,就没必要实现。清晰的价值,有利于代办事项的排序;
estimable: 虽然敏捷也不提倡准确的估算,但是可以显示需要在这个用户故事上付出的努力。如果无法进行估算,就很难依据成本效益分析进行排序,估算是为了更好的计划;- 粒度太大,史诗故事: 需要拆分;
- 缺乏领域知识: 需要与客户讨论;
- 缺乏技术能力: 进行穿刺;
- 缺乏封闭性: 拆分故事;
small: 小的用户故事更容易被估算,大的故事估算可靠性较低;
testable: 需要有较为明确的验收标准,对于测试能够从界面&接口进行的,可以做自动化测试;
用户故事代办事项:
代办事项可以指导我们在团队内部进行优先级排序,也可以作为版本管理和迭代管理的一个计划工具;
用户故事的粒度
用户故事被作为需求的拆分和评估的单元,拆分到可估算的程度,一般为1-3天。 -
干系人分析
分析识别初干系人的利益、期望和影响,并把他们与项目的目的联系起来;了解干系人之间的关系,以便利用这些关系建立联盟和伙伴合作,提高项目成功的可能性。- 故事地图:客户价值优先级排序的工具,提供一个关于功能何时交付的产品路线图。可以用作跟干系人沟通的工具,把地图放在墙上作为一个项目计划的信息发布源。
- 干系人价值排序:把发起人和用户的优先级纳入到项目优先级中来,结合他们的优先级进行事项的排序,不要做他们不支持或者没有价值的功能;
-
管理干系人的参与
沟通方法- 面对面沟通:高胆管沟通,是最有效的沟通方式,信息传递最多;
- 信息发射源: 使用高可视化的展示信息的方式;可以展示以下功能:
- 需按需交付的功能和剩余的功能;
- 谁在从事什么工作?
- 当前迭代选择的功能;
- 速度和缺陷度量;
- 回顾会上发现的问题;
主要展示代办事项、处理人、缺陷、当前迭代的情况和其他客户关心的信息;
- 燃尽图/燃起图:可以帮助更好的判定和了解项目处于的阶段和未来工作的风险,即使是坏消息,也是有价值的。
- 速度:是每个迭代中对团队能力的一个度量,能够帮助我们基于以往经验评估团队后续的工作能力。是一个慢慢稳定的过程。
- 敏捷建模:聚焦在模型的讨论和创建,包括:用例图形、数据模型和设计等;
- 频繁的讨论“完成”:为来减少彼此理解的偏差,把项目中出现的每一个新想法和新观点尽早且频繁的展示出来,对于干系人之间的连接是非常重要的。
软技能:
- 授权:授权团队进行自主管理,了解如何通过最少的管理参与解决问题,是敏捷方法论的基石。
- 谈判:健康的判断可以给双方一个机会去充分描述每个观点,权衡利弊;
- 冲突解决:
- 解决问题:信息共享,协作,陈述事实;健康的工作环境;
- 争论:自我保护意识加入;授权团队解决
- 竞赛:以偏概全、推论和放大;坚持团队价值观,容纳大家观点,工作本身可以有一定的妥协;
- 战斗:越来越意识化和极端;需要一个第三方的中立引导员传达信息,让冲突降级;
- 世界大战:团队内战。不可能解决,不要尝试解决,需要找到一种方法,让团队与冲突共存,需要把对立双方单独分开,防止进一步伤害。
- 积极聆听:
有以下几个表现,通常的动作:- 关注当下,集中精力于演讲者,不仅包括演讲者说话的内容,也包括说这的语音语调和情绪;
- 做笔记,不打断;
- 确认或复述所听到的嗯日哦功能;
- 擅用开放式问题、适当的肢体语言和沉默来提高聆听技巧;
- 参与式决策:
敏捷团队需要的是更多的授权和更少的命令控制;- 简单投票:支持&反对,但是会省略一些细节(不那么同意等)
- 拇指法则:加入中立;
- 决策光谱:表达他们的支持时,还可以表达他们的保留意见;
- Fist-of-FIve投票:显示手指的数量表示他们的支持程度;
- 有效领导:
- 服务型领导:
保护:保护团队不被中断,保持团队不被干扰,提升生产力;
保障:移除障碍。领导需要关注每日站会障碍并最好当天安排解决;
保持:保持徐迟引导项目愿景。需要持续地寻找一些机会以持续沟通项目愿景,进而达到对团队对有效激励;
保姆: 为团队提供支持。在保证为团队提供必要的资源后,帮忙团队成员提升,关注个人培养和成长。 - 挑战现状:鼓励改进提出新的想法和机会的尝试,挑战现状,践行过程改进,激励团队成员。
- 服务型领导:
- 分布式团队:
信息发射源进行信息同步,语音会议&实时聊天等工具进行沟通