00.人们觉得我可以解决任何类型的问题，所以认为我是一个优秀的项目经理，并且在这种计划驱动的环境中，一个好的项目经理同时也应该是一个问题解决者，这已被事实证明是必要的。
01.敏捷问题解决规则：
*问题引起你的主义，或者你觉察到问题
*暂停，思考该问题并把他看清楚
*把问题交给团队
*允许团队应对解决或者不应对
02.遇到问题本身并不代表是个问题，所以欢迎问题，因为问题可以带给团队一起克服问题、一起成长和一起加强合作的机会。人们会把问题逮到你面前，而你将把问题放到那里等闲视之。如果这样不够的话，你就去找出这些问题的症状。
*流程层面：我们在敏捷方面做得如何？
*质量的绩效角度：团队如何可以做的更好？
*团队的动态维度：团队如何可以变成一个更好的团队
03.了解一些问题比知道所有答案更好。
04.敏捷教练丹.麦为敏捷团队定制的BART分析方法
*角色。
-在你的敏捷框架中，所有正式定义的角色是否都有相应的人员各就其位？
-是不是所有的正式角色都在角色边界之内，而非跨越角色而工作，并且工作能很好地完成？
-是否有人在敏捷框架中承担的正式角色多于一个？如果是，对于权力和边界的使用，对团队的影响是什么？
*任务。
-团队成员对他们的团队目标是否很明确，而该目标来自他们每个人都可以明确表达的共有精神榜样？
-是否有人可以区分为了完成团队目标所需所有不同任务（如产品负责人有一个优先级排序的列表）？
-人们从先前相似的情况中“引入”了什么样的历史和过去的经验？而这些如何影星他们对当前任务的本质的理解
*权力。
-团队成员是否在适当地“行驶”正式权力？例如，团队是否在每天的站立例会上适当地“行驶”他们的权利
-对于每一个角色，他的权力是否被清楚地制定、被所有人理解，并且被坚持？
*边界。
-人们是否在赋予他们对敏捷角色的去哪里边界内工作？如果不是，这些权利边界问题的影响是什么？
-在Sprint期间，团队成员如何赋予另一个团队成员获取Sprint任务的权利？在Sprint期间，随着时间的推移这一权利有什么变化？在多个Sprint之间，这又有什么变化？
05.敏捷宣言
*个体与交互优于过程和工具
*可用的软件优于过程和工具
*客户协助优于合同谈判
*响应变化优于遵循计划
06.遵循的准则：
*我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户
*欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势
*要不断交付可用的软件，周期从几周到几个月不等，且越短越好
*项目过程中，业务人员与开发人员必须在一起工作
*要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务
*无论是团队内还是团队间，最有效的沟通方法是面对面的交谈
*可用的软件是衡量进度的主要指标
*敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度
*对技术的精益求精以及对设计的不断完善将提升敏捷性
*要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术
*最佳的架构、需求和设计出自组织的团队
*团队要定期反省如何做到更有效，并响应地调整团队的行为。
07.简单而直接地解决问题意味着你说出你看到的症状，抛出你的假设，并询问团队，对于这个问题，他们想要做什么。
08.以价值为先的讨论支持了这一目标，因为他会让每一个人去关注为什么大家最初聚到一起合作的原因，那就是创造商业价值。
09.教练的工作不是去修理或者“修复”体系，而是把体系的本质揭示给相关的成员。有了对体系新的认识，体系中的成员其“响应”能力就会增强，从而更好地执行系统的任务。
10.一旦你检测到问题，最好安排一次回顾会议，提出这些问题。选择做一些活动，让团队在活动上以不同的方式思考他们一起工作的如何。这些并不熟悉的活动往往给他们带了了新的视角，并最终让他们看到你先前已经注意到的问题。当然，这也意味着你需要花时间去设计这次回顾。
11.如果团队只是浮于问题的表面而没有真正地深入问题的本质，你的主要工作就变成了帮助团队成员建立相互之间直接的关系，这样他们就可以直接用一些有成效的交谈，来让问题浮现出来。
12.总结：
*这是团队成员的承诺，不是你的
*他人向你反馈问题，或者自己发现了问题，然后停下来好好思考问题的本质
*拥有提问“我们那些环节比较薄弱”的勇气是一位敏捷教练的长久实践和神圣职责
*一旦你清楚地看到一个问题，或者你已经认真考虑过了但仍然没有相处任何办法，那么把他交给团队。看看他们能引入什么新的角度，从而帮助每一个人理解该问题，然后询问他们想要怎么处理这个问题（如果存在的话）。
扫一扫
559
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
