《敏捷教练 如何打造优秀的敏捷团队》一书，作者通过分享自己的工作经历和故事，指出了敏捷开发中各个角落可能存在的问题，介绍了如何引导团队和组织着手改进，以系统方式讲解敏捷教导的幕后机理，学到更多实用性很强的辅导技巧。
我们在辅导团队过程中，会遇到各种各样的困惑， 合格的教练应具备哪些基本素质，在遇到团队问题时，如何应对才会不让我们纠结，到底该做什么，怎么做才能被团队接受，《教练技术》给我们展示了相同境遇下的经验分享，让我们更深入地了解敏捷实践，以及如何以敏捷教练的身份辅导其他实践者和团队学习敏捷。
敏捷教练的目标是培养出高产出的敏捷团队，让团队走上自己的敏捷之路。教导工作就是要与人共事。教练工作的本质是与人共事，转变人们的思想和观念，并辅导他们学会使用某些具体的实践、工具和方法。
敏捷教练在工作中应充满激情和热情，敏捷教练职责：
[if !supportLists]1、 [endif]留意观察团队的工作方式， 思考他们为什么会这么做，有哪些诱因。
[if !supportLists]2、 [endif]反馈给团队你的观察，善于发现问题，帮助团队改进工作方式；
[if !supportLists]3、 [endif]教育团队了解更多的敏捷方法，提高团队认知范围，鼓励团队不断学习；
[if !supportLists]4、 [endif]引导团队清除障碍， 促进内外沟通协作；
[if !supportLists]5、 [endif]支持鼓励团队在困难面前，保持动力，鼓励前行；
任何事情都不是一下子能够达成的， 需要一步一个脚印的走下去，做到以上方面，敏捷教练应在工作中所遵循的指导原则：
1、倾听原则：敏捷教练需要和团队个体打交道，一对一和他们交谈，获取他们的顾虑和想法，有助于帮抓团队发现那些地方可以提升，通过倾听建立于团队的信任。
深度倾听团队的声音，不带偏见的理清事情的来龙去脉，努力澄清事实，确保自己理解他们所说的意思。同时反馈自己耳闻目睹的具体实例，而不是加杂个人的的评价和建议，而是询问团队见解，一起讨论应对方案。。
2、领导变革原则：有时需要敏捷教练引入新的敏捷实践，领导团队实现变革。人们需要知道变革动机后，才能全身心的投入其中。
引入变革不是一阵旋风，命令团队执行，那样可能会带来更大的阻力。领会新的想法是需要时间的。敏捷教练发现改进机会，分享有效的支撑论据，尊重团队的意见，向团队提问，如何解决，让团队意识到不变是有问题的，引导团队考虑改变方案。
在强有力的提问中有些技巧，让我真正get到敏捷教练在提问环节，核心掌握的技能。不使用封闭式的问题，多问开放性问题，带动团队反思并分享他们的观点。询问为什么趋向关注问题，不是解决方案。纠结过去的错误不放，不如专注努力改进来的更有实效。
[if !supportLists]n [endif]求助型问题：适合一对一的询问，寻求他们的帮助。
[if !supportLists]n [endif]思考型问题：从不同视角看问题，帮助团队走出问题的羁绊。如果对方有压力或情绪则不适宜，因为无法集中精神让自己远离问题进行思考。
[if !supportLists]n [endif]反思型问题：寻找根因的五问法
[if !supportLists]n [endif]注意何时不要提问题：要是你和对方之间的信任度太低，提问题估计帮不上忙，可能得不到诚实的回答。让我体会到在团队初建期，在没有建立足够的信任时，提问只会让对方觉得你是在挑刺，再找麻烦，这个阶段坦诚，直率努力建立信任也许是最重要的。
3、建立敏捷团队的指导原则：任何一个高凝聚力的团队都不是平白产生的，首先要有团队协作的环境。信任需要时间，充分利用站会和回顾会逐渐建立信任，坦诚相待，合理的自我揭露，分享经验，建立内部信任。同时通过营造团队空间，让团队坐在一起更好的工作，通过物理空间拉近大家距离，这让我想到了每次组织变化，我们的座位就要调整。建立明确的角色职责，要让整个团队都清楚各个角色的职责。明确团队实现具有挑战性目标，让团队知道我们是开发一个有价值的产品，会更容易融入其中，成功时也要给出庆祝，向组织展示团队的成功，同时也是增进团队关系的机会。
4、教练团队有效的技能
在敏捷实践中，应用有效的工具和方法，深入地了解敏捷实践，辅导团队学习敏捷。按照每日站会、共同计划、过程透明可见、做到真正“完成”，测试驱动开发、简洁代码、回顾会议驱动变革，顺着时间变化，遇到的困难
团队实施过程，面对违反团队规则的行为，敏捷教练也不必当成“碎碎念”时刻提醒团队，可以在偏离的时候，通过实际行动于计划的偏差，提醒团队如何解决。
每日站会：注意站会时长，分离讨论，先介绍进度，再讨论如何解决，记录所有需要跟进的事项，并排列优先级,确定有人跟踪；
用户故事：鼓励团队，包括产品、开发、测试面对面讨论用户故事，提出质疑，以此来加深他们对功能的理解。和团队一起，以测试集的形式明确故事的范围，这些测试都通过了，故事才能算作“完成”。
规划会议：本次迭代优先完成什么， 及需要多长时间完成，鼓励大家先讨论设计然后再估算工作；
进展跟踪：关注故事交付，而不是某一个任务
关注质量：测试驱动开发、尽早测试，持续集成，结对编程、整洁代码、增量设计，不断提升代码质量
回顾会议：召开回顾会议时要先向后看，回想都发生过什么，以及它们为什么发生。留出足够的时间让团队可以讲完整个故事。在回顾会议的后半部分，要向前看，决定采取行动并制定计划。
由于每个人、每个项目、每个团队和每个组织都各不相同，所处不同的环境，我们没有永远有效的神奇公式，每一个团队都需要找到行之有效的更好方式，一切都靠时间和尝试去找到正确的方法。工作中边学习边实践，不断反思回顾，形成自己的实践理论，持续改进。
网友评论