导图社区 敏捷教练：如何打造优秀的敏捷团队
- 84
- 3
- 举报
敏捷教练：如何打造优秀的敏捷团队
这是一篇关于敏捷教练：如何打造优秀的敏捷团队的思维导图。本书通过真实的例子,介绍如何辅导团队平稳度过整个敏捷转型生命期,如何打造一个自立、自觉的敏捷团队。针对敏捷实践的工作机理和如何激发团队的成长有深入的思考，可帮助读者了解如何高效召开各种敏捷会议，及如何指导团队建立良好的工作流程和工作习惯。总结了在敏捷转型过程中教练和团队可能面对的障碍及应对方案，很多都是我们实际敏捷推广过程中遇到过的问题，对于刚开始推行敏捷转型的敏捷教练、团队还是很有指导意义的。
编辑于2021-05-22 01:05:28- 敏捷教练
- 敏捷团队
- 相似推荐
- 大纲
敏捷教练
1.起步
敏捷教练的职责
作用
帮助团队驾驭敏捷
开发出色的软件
目标
培养高产出的敏捷团队
成员有自我判断能力，不依赖教练为他们制定的敏捷法则
活动概览
留意
留意团队工作方式
仔细思考原因
探索诱因
反馈
给与团队反馈
分享观察到的情况
帮助他们利用反馈改进工作方式
做到可以自己发现问题
教育
设法鼓励他们学习
演示敏捷方法
讲故事、开设培训课程
引导
清理障碍
促进有建设性的沟通和协作
支持
团队受阻时在场
鼓励他们继续前行，帮助他们保持动力
养成教导的态度
敏捷教练的重要习惯
以身作则
定义
遵守敏捷原则从自己做起，让团队看到活生生的例子
作用
非常有效的领导团队的方式
平衡心态
定义
不把批评当做针对自己的，更可能是针对团队所遭受的变化
循序渐进
定义
耐心地（缓慢而持久地）推动团队的变革
谨慎言辞
定义
留意自己与团队交谈的方式
以信息的方式讲给大家听
边走边学
定义
花时间反思事情进展与预期不符的原因
预备，辅导！
敏捷工作的步骤
寻求引荐
正式介绍
相互介绍
选择一个点切入进去
PrOpER循环
试着每天进步一小步
逐渐习惯自己的教练角色
让团队决策而不是制定方向
继续前进
保持新鲜视角
如何开始教导
PrOPER循环
问题
选项
暴露问题
让团队看见问题
公开讨论
和团队讨论这个问题
静观其变
搁置问题，看团队是否会自己发现问题
暗度陈仓
说服团队内或外的其他人认识到问题
根由分析
寻求问题的根本原因
教育团队
提供更多信息帮助团队找到解决办法
予人权责
将此职责转交给团队或某团队成员
试验
检验
保持速度
难关
形式
没有时间辅导
分析
承担特殊/很重的项目任务
应对
抽身而出
慢下来
调换团队
渴望承担更多工作
应对
分析情况，慢下来
没有经验
分析
超出敏捷经验范围
应对
坦诚告诉团队
帮助团队解决问题
应对
引导讨论
研究组织内其他敏捷团队尝试的经验
敏捷的拦路石
分析
碰到严重障碍无法走向敏捷
应对
先移除障碍
再考虑辅导团队敏捷
组织结构调整
应对
不建议此时开始辅导
检查表
练习向其他人解释敏捷
先打好基础，再找个最好的 方法把自己介绍给团队
想办法亲自示范自己对敏捷原则的运用
实施辅导时运用PrOPER循环
暂停片刻进行反思，并从错误中学习
找机会向公司内外的其他敏捷教练请教
在一个组织太久，可能变成腌菜团队如可以有效运用敏捷流程，就可离开了
2.与人合作
作用
借助团队成员的专业能力，揭示使他们停滞不前的原因
辅导团队探寻意见分歧，找到大家都能接受的解决方案
倾听
技巧
营造空间
不要插话，不要谈自己
保持开放
保持放松和坦率的表达方式
表示关注
看着对方，一直保持眼神交流
肯定
点头向对方示意我明白了
先倾听再建议
澄清问题
言外之意
检查整体状况
关注说话的人，留意表达，考虑发起谈话的动机
寻求支持、提供帮助或感谢帮助
寻求认同感、建议或更多信息
想要帮助解决描述的问题
注意任何非言语提示，如肢体语言和说话的语调
烦恼、愤怒或兴奋地
谈话时不安还是放松
表现是否和平时不同
同理心
维系信任关系
分析谈话中暴露的问题并跟进
不泄露秘密
背景倾听
关注每一位发言者，等他们说完后再要求澄清问题
把谈论到的确切的字眼单词记在笔记本上
给予反馈
步骤
区别基本信息和对具体情况的评估及感受
聆听他们所体验的事情经过
如果认为还有提升空间，就给出一些建议
给出自己耳闻目睹的具体实例
化解矛盾
步骤
发现团队内潜藏的矛盾，多花时间听听团队内部有哪些看法揭示矛盾之前，了解它的来龙去脉
调解员角色：没有帮助，矛盾是否能自我解决
仲裁者角色：不偏袒任何一方，聆听各方对问题的描述，复述问题表明理解
剥离个体原因，从团队角度重新描述问题
观察
描述观察
感觉
揣测情绪
需要
揣测需求
请求
提出建议的具体动作
达成共识
方式
使用同意梯级
作用
暴露缺乏共识的现象
专注与大多数团队成员都支持的方案
帮助团队达成共识
难关
会议中的情绪爆发
和开始人谈话，搞清楚情绪爆发的原因
缺乏社交能力
了解每个人偏好的沟通方式
文化差异
学习团队文化维度
检查表
练习深度聆听
给反馈时，要区分事实与感受
爆发冲突，确保各方都能平等陈述各自观点
使用同意阶梯揭示对变革的支持力度
3.领导变革
方式
不止让人们了解工作内容
了解变革动机
引入变革
步骤
让团队知道，对他们的变革能力充满信心
团队讨论
思考精妙
认识调整
授人以渔
示范给大家看，为什么它重要，该怎么开始行动
告诉他们怎么起步
形式
教育团队
演示
公示
兜售问题
描述不转变带来的后果，清晰描绘景象
找到支持观点的证据
关注点是流程改进，不是个体绩效
培养变革的主人翁意识
讨论变革的优缺点，培养一致的主人翁意识
首先选定一个问题和团队着手解决
集中精力解决它
变革实验
遇到阻力时，提议尝试其他方法作为试验
作用
对于改变每采纳一次，下次的抗拒就更少一些
提问
作用
表明尊重他们的意见
对他们的回答感兴趣
挑战假设
作用
帮助团队意识到自己是在未经证实的情况下做出的假设
问开放式问题
方式
问类似于“怎样”、“会发生什么”等开放式问题
作用
打开话匣子，带动人们反思并分享他们的观点
内容
求助性问题
坦率寻求团队的帮助
一对一咖啡时间询问
寻求他们的帮助
思考型问题
让团队“思考”问题
这个问题你考虑多久了
你多久思考一次这件事
针对这件事所做的考虑，你满意吗
你的想法还有哪些遗漏
你有哪些见解
反思型问题
鼓励团队多关注工作方式
选择事后提问的方式
五问法
作用
用于团队进行根本原因分析
暴露出超出团队控制范围的（必须上报组织内更高层的其他人员处理的）问题
何时不要问问题
定义
问了问题就要接受别人给的答案，即使不认同也要接受
一直提问，会显得有所保留而不愿分享
信任度太低，提问题帮不上忙
直率、坦诚、分享看法，努力培养融洽关系
鼓励学习
定义
在采取敏捷前，有时间学习敏捷
不要让团队把教练作为唯一的敏捷知识来源
鼓励积极主动学习相关知识
创造学习机会
紧跟行业发展趋势
访问学习资料
亲自示范希望他人表现的行为举止
引入新思想
到组织外学习
参加会议
作用
会议让团队接触新思想
结识有同样困扰的人
参加本地用户组活动
引导会议
步骤
首次尝试新敏捷会议时，主动引导会议
实时发表评论，展示思考过程
会议
提示
选对时间
选择正确的时间，确保整个团队都能参与，充分提醒大家做好所必需的准备
布置场地
考虑会议场地，避免团队被隔得太分散
记录备注，选择白板或白板纸等工具
明确目的
声明会议目的
简要说明会议议程
提醒团队注意遵守会议相关的所有工作协议或基本准则
保持会议顺畅
确保大家说话不偏离主题，且富有成效
鼓励全体参与
确保所有人都发表自己的观点
总结要点
总结要点，写在白板上，复述理解，检查并确认理解了这些要点
结束会议
确保所有产出都已被妥善记录
要求大家对自己的会议引导技能给予反馈
难关
有些人就是不愿意变
先易后难
卷入公司政治
花时间了解关键相关方，理解他所持有的观点
帮他了解计划，争取让他认同思维方式，赢得支持
议程冲突
公共场合努力保持中立
达成共识，引入改变过程
检查表
分享对敏捷的激情
向团队兜售问题
遇到阻力，查明源头
通过提问的方式让团队参与改进自身的敏捷流程
鼓励多渠道学习
新形式的会议要好好引导团队
4.建设敏捷团队
帮助团队形成凝聚力
社交粘合剂
每日站会、回顾会议
促进彼此了解
分享个人的经历
共进午餐
安排团队外出
建立信任
合理的自我揭露
让团队成员在宽松情况下承认自己需要帮助
分享个人经历
缩小差距
在不同角色之间建立信任缩小不同学科间的差距
让团队成员相互理解
营造团队空间
作用
有共享工作空间保持顺利沟通
集中办公
虚拟环境支持协作
虚拟环境支持协作
电子化信息存放位置明确
开发环境与测试环境设置保持一致
角色平衡
客户
定义
掌管业务案例，排列软件功能优先级的人
形式
客户团队
业务分析师
用户代表
交互设计师
开发团队
定义
负责决定如何构建功能，告诉客户过程所需时间
交付日期范围需协商共同确认
近客户负责与团队明确需求细节
远客户负责业务优先级相关决策
角色之间未能形成平衡，必有一方过度劳累
客户太劳累，开发人员无法客户充分交流，只能靠猜测去理解真正需求
开发人员人手不够，产出让业务人员失望
教练将不平衡状态副作用显现出来，让管理层认真思考和解决问题
激励团队
不太容易、但也不太难
找一个能吸引人的目标
开发有价值的产品
安排团队与最终用户见面
描绘项目内机会与个人目标之间的联系
澄清团队享有的空间与自主权
留出创新时间
迭代计划中，留出时间，探索新想法
黄金卡
庆祝成功
增进团队关系
展示团队成就
不要打击士气
工作内容决定人们是否开心和积极向上
工作环境决定人们是否不开心和不思进取
压力
公司文化
协助改善工作环境
谨防奖励
旨在鼓吹个体生产力的奖励计划会侵害团队内的协作
利用出色工作和创造伟大产品所获得的满足感来激励团队，会工作的更好
难关
不是跨职能团队
所有会议邀请所有人员参与，邮件里都捎带上
组织一次交际晚餐或酒会，营造团队氛围
没有现场客户
鼓励客户访问，与团队见面
鼓励定期交谈
团队太庞大
把项目拆成子团队，特性团队更理想
团队是资源池
不符合敏捷原则，不进行敏捷
团队排斥个人
沟通，听取原因解释，与被排斥人沟通
团队变得自满
提高团队工作对资深干系人的可见度，给团队提供更多反馈
检查表
创造机会让团队成员相互认识
创造共享的工作空间帮助团队共同工作
明确角色职责，帮助客户获得团队协作所需的支持
确保团队有可达成却有挑战性的目标
准备食物和饮料庆祝发布
教导基础
5.每日站会
每日三问题
内容
昨天我做了什么
今天我要做什么
我遇到了什么障碍
作用
团队辅助轮
站立
原因
所有人都站着的时候，耗时更少
围在团队工作区白板前召开每日站会
始于团队，服务于团队
作用
同步工作内容
谈话聚焦计划中的工作
建立团队焦点
环顾整个团队
面向整个团队
避免给出表扬
团队掌控流动
发言令牌
讨论任务的进度
不试图解决遇到的所有问题
真正在做团队板上贴着的任务的人来回答问题
参会人员
开发人员
测试人员
设计师
客户
作用
传递未来工作的进展
信息更新在会后再做
敏捷教练
项目经理
作用
跟进遇到的任何问题
每日站会两部曲
开发团队进度汇总
团队用户故事讨论
处理问题
步骤
留待会后解决问题
问题停车场，记录所有需跟进事项
散会前看一遍问题，排列事项优先级，决定是否需要谁来跟进这些问题
每日站会不是专题会的替代品，更长时间讨论，建议团队专门安排会议为此
检查依赖于团队之外其他人的交付物
设定时间
团队决定想在什么时候召开每日站会
作用
促成团队做出承诺
推动形成独立解决问题的团队文化
择机辅导
扮演团队的良知
在团队偏离方向时，温和地提醒他们按计划行事
提醒检查团队板反应的用户现状
谦虚的心态，寻找改进机会
理解团队
是否每个人都全情投入，积极及兴致很高
一直在前进并在做高优先级的任务吗
是否一起工作而相互帮助
能够集中精力干活，免受打扰吗
会后跟进观察结果，或推迟到下一次回顾会再讨论
难关
会上有人迟到
与其讨论，理解遇到的问题协助改正，保障会议有效展开
帮助他意识到行为，触发改变的根源
会议时间太长
使用例行问题，团队成员轮流回答
讨论会后进行
和队友相关的事，协助纵观全局
针对大型团队，拆分子团队，独立开展工作，召开稍小规模站会通过Scrum of Scrum 协调工作
站会遭劫持
会后和劫持者沟通，不在站会上挑战他们
建议他们与客户先谈，以便下次规划会议纳入考量
团队没有做计划中的任务
用户故事任务发生变化
鼓励团队为新任务增加放在团队板上
为另一个项目干活
鼓励团队向客户提出问题
计划外工作出现
与客户一起为支持工作安排预算
跟踪支持工作实际所花掉的时间
不想开每日站会
个人
检查任务进展，以防被卡住还试图隐瞒
团队
学习如何成为一个团队
会议开得太糟糕
回顾会议上与他们沟通担忧
检查表
寻找一片空间开每日站会
让团队来决定每日站会时间
鼓励团队做到答复简短而亲切
保持每日展会顺畅进行
请客户参加每日站会分享进展和信息更新
手机问题并贴到白板上，每个人都看到，排列优先级后跟进
回顾会议时评审每日展会的效率和站会形式的尝试效果
6.理解构建目标
用户故事
作用
支撑敏捷团队所有工作的基础，计划、开发和测试的依据
用户故事的生命周期
用户故事从想法开始
交谈中成长
交谈汇聚形成具体测试用例
可工作软件演化成形
软件产生用户反馈和新想法
3C
Card（卡片）
把故事写在索引卡上，引导小组进行交谈
Conversation（交谈）
问问题，找出拆分故事的方法
Confirmation（确认）
确定用于评估故事是否已完成的测试
鼓励交谈
团队
围绕用户故事进行交谈，使团队理解需要构建哪些功能
开发、测试团队
发动开发与测试团队与客户主动交谈，确认所要实现的故事的理解
敏捷教练
留意团队苦于不知道构建什么功能，提醒他们找客户问清楚
客户
鼓励与团队交流，一起探究未来用户故事
与卡片共舞
索引卡记录用户故事相关言论
按迭代分组，在桌面上挪动卡片
亲自展示用卡片记录用户故事，带领团队开始实践
经过交谈有所改变，撕掉换新的
检查卡片上记录的内容，有出入，让客户更正或重写卡片
示范如何写卡片，然后停下来
故事卡布局要一致
顶部写个简短的标题
估算点写在卡片上相同的地方
故事模板
作为一名...用户，我想要..能力，这样是为了...好处
创建干系人图
没有用户交互，改模板不能很好帮助团队理解需求不必非得使用
作用
帮助团队学会问问题，增进理解
为后续迭代增加更多相关故事，这样尤其有效
确认细节
以测试集形式明确故事的范围
作用
澄清需要构建什么及需要的工作量
团队采用走查真实样例的方式拟定故事测试
作用
帮助团队检查理解软件用意
满足客户需求
引导团队探索
进行错误处理
鼓励团队向客户从简单交互开始问问题
用户输入了什么数据
用户期望看见什么
有没有业务规则是我们需要知道的
鼓励团队思考可能出错的地方
协助团队接触前敏捷时期的坏习惯
难关
没有面向用户的功能
用户故事适用于描述真人用户的需求
需求必须有记录
快速创建故事的电子记录
在用户故事交谈完成后记录完整的文档
团队无法见面
以用户故事为基础，讨论用户需求
确认已实现的故事测试
检查表
教团队学会“卡片、交谈、确认”
亲自示范如何写故事卡，然后停下来让团队自己写
确保团队的工作空间和会场有充足的卡片或便利贴用于讨论故事
用户故事模板不要变成填空练习，要能促进团队提出问题
辅助客户在规划会议之前准备好故事细节
7.提前计划
鼓励团队创建不同粒度的计划
做规划的步骤
准备
会前和团队（尤其是客户）一起，准备好用户故事
在知道故事相关利益的前提下，把故事尽可能切割更细
每次讨论一件事
同一时间只讨论一件事
不停聚焦
保持会议流畅，重新聚焦交谈方向，以免卡壳
控制热度
协助团队澄清细节，结合过去考虑的交付率，给出团队能完成的工作估算
规划会议
讨论故事
构建软件交付故事
选择切实可交付的故事，相应安排迭代时间表
为规划做准备
鼓励团队与客户一起准备好用户故事
几个团队成员一起进行预规划会议
创建计划
理解优先级
理解工作规模
一致认同计划
和团队一起提前确定规划会议的议程
理解优先级排序
客户做开场白，介绍下一个迭代或软件发布
鼓励团队其他人问问题
注意观察拆分用户故事的机会
作用
故事测试更易明确，易估算，更有可能实现交付
审查下个迭代故事测试，每个团队成员朗读其测试内容
明确工作规模
讨论软件设计的牵连范围
建议客户暂时离开
作用
确保团队花时间探讨故事的技术细节
召开规划会议
作用
搞清楚需要多久
弄明白做什么
鼓励团队使用白板
作用
以视觉方式呈现设计思路
不明确不影响估算的所有细枝末节
随时展开设计讨论
鼓励团队如果需要，立刻开会讨论软件设计
将故事分解为任务
作用
有助于交付用户故事的小块头工作
挖掘更多故事测试及进一步拆分故事的方法
小任务更有利于团队为同一个故事而共同努力
便与协调多人同时参与
陷入僵局是，推动摆脱困难
我们需要改数据库吗
这个东西我们怎么测
有没有什么编辑文案或GUI设计资产之类的东西可以向其他团队要
我们还需要做些什么才能满足“完成”的定义
估算，而非猜测
以协作方式进行，只考虑需完成的工作，不因为事情可能出错而留有余量
调查时间长，建议团队安排探针（Spike）
探针
定义
一次时间盒形式的调查
作用
得出用户故事的估算
得出估值
使用计划扑克，让所有人都参与讨论
计划扑克
步骤
团队成员选牌代表估值，面朝下放在桌上
作用
避免估值受到他人影响
所有人出牌后摊开牌面比较
数字均一样，在用户股市上标出该估值
给出不同点数，团队就讨论对工作难易程度看法不同的原因，再重新投票
拿不定注意，可以给出（？）牌
作用
保证所有人的参与
避免有人喊出首个估值后的锚定效应
对故事和故事构建工作的各种假设和想法在讨论中显现
作用域
几个月后发布的前瞻性计划
故事卡上标出估值平摊桌上，矩阵式排列故事卡按估值从低到高顺序横向排开，让团队一目了然看到所有
审查并承诺
选择切实可交付的故事，相应安排迭代时间表
根据可完成用户故事数量，制定计划
运行几个迭代之后，会有平均速率数据
避免队内专家负担过重，学习瓶颈一直存在的话，安排学习型任务，丰富团队技能
按迭代摆放
摆在最前面的优先级最高
除非一些卡片牵扯到了风险、依赖性或最终期限
按照可持续速率进行计划
向前看
可预留一个迭代出来
作用
预留给新的用户故事
已计划故事开发延迟时的缓冲
用户故事计划不要超过三个月
超过的话，基于故事主题制定路线图
看板
作用
使团队专注于改善工作流
实现工作可视化，呈现价值流中的不同转化阶段
限制每一点的在制品数量
发现系统中的存在的瓶颈和约束，持续改善系统，提高生产力，改善绩效
团队一次出力最多不超过三个特性的限制
追踪注意
提议团队提名出追踪者
追踪焦点为交付物
对软件发布计划进行版本管理
通过电子表格或维基页面分享用户故事、估算值和交付时间，不同版本计划保持同步
鼓励团队给计划的故事连同估值拍快照，迭代结束时，得出命中率
难关
客户不知道自己要什么
开会前几个团队成员一起协助客户梳理用户故事
团队被迫过度承诺
警示无法交付所有故事的潜在风险
确保故事拆分足够细，保障各个功能领域有所交付
计划在迭代进行中发生变化
鼓励团队规划时多花时间检查任务
鼓励在计划中加入探针
会议中冲突不断，气氛很紧张
鼓励团队向客户讲出心中的想法和担忧
明确告诉客户需要认真听
最终选入计划的故事应该是共同的决定
构建软件交付故事，从难易程度判断相近方案
编码实现两种方案，有效学习，得出更好方案
团队速率下降
帮助团队留意放缓迹象，尝试找出问题根源
根据新速率制定计划
规划毫无意义
在团队板上给团队任务建立优先级排序列表
团队自选工作方式
转而选择看板开发方式
情况
团队成员无法有效参与
较多缺陷需修复或缺陷修复很难估算
检查表
和团队一起拟定规划会议议程，分为多个环节进行
提醒团队在会前与客户一起准备用户故事
确保会上所有人都有机会可以问有关用户故事的问题
鼓励大家先讨论设计然后再估算工作
建议团队把大个头故事分解为任务
创建故事卡矩阵，把估算相同的故事放在一起，以此帮助团队保持估算的一致性
照顾团队维持一个可持续的工作速度
确保有人拿走卡片铁道团队板上之后，再结束会议
8.公式进展情况
学会公示需要关注的东西
帮助团队建一张团队板
团队板
组成
故事
所有故事都放在这里，按优先级自上而下排序
任务
任务放在这里，紧挨着放在相关故事旁的泳道里
进行中
工作开始后，把任务移到这一栏
等待测试
相关任务全部完成后，把故事卡移到这一栏
作用
提示客户或测试检验工作确认它通过了故事测试
丢弃已完成的任务
如有问题需修复，把故事卡移回故事兰，为修复创建新任务卡
完成
目标在于把所有已完成故事放在这里
得带中这一栏会被逐渐填满
鼓励团队同一时间内只关注少数几个故事，从头到尾彻底做完
团队板要直观易懂
坚持使用同一个卡片模板
记号笔清楚写下故事标题
已完成卡片与圆点贴纸
未开始
红色贴纸
进行中
叠加黄色贴纸
评审中
蓝色贴纸
已完成
绿色贴纸
缺陷叠加黄色贴纸
谁在干什么
让团队自己挑活干
正在做的任务卡上标识名字或照片
鼓励团队任务受阻时将它暴露出来把卡片从进行中移到受阻区域
挑选物料
团队参与挑选工作区所需物料
电子板
电子化追踪
写下故事标题
迭代规划时商定的故事的估算值
大型可视化图表
作用
提高所追踪问题的可见度，更容易看到自己是否在改进
问题消，图表退
引入可视化图表需谨慎，事先征得团队许可
结对阶梯
燃尽图和燃耗图
燃尽图
燃耗图
作用
描绘了下次发布前各迭代所完成故事点数的情况
如果差距明显，削减下次发布的用户故事数
无法按原计划交付，确保团队将消息告知客户和其他关键干系人
维护团队板
和团队协商，看团队如何解决信息维护的问题
保持整洁，让团队看的一清二楚
每次迭代结束清理干净画布，从空白画布开始下次迭代
难关
团队板没地方放
团队不更新团队板
担心卡片会丢失
备份
检查表
拉团队一起设计和搭建团队板
团队的板子可张贴个人事务和图表，以便专注于改进工作方式
精心设计和制作适合团队的板子，挑选物料，以便一目了然
鼓励团队个卡片打标签
给所有团队成员信息同步，给远程成员创建一份电子版概要
迭代燃尽图只用于粗略衡量团队对顺利完工有多少信心
迭代结束时把板子清理干净，迭代中不断地审查可视化图表内容，撤掉团队觉得失效的图表
集体规划
9.做到“完成”
先理解构建哪些功能，每个故事需要哪些测试
团队往往受挫于低估了测试软件和修复相关问题所需的时间
帮助团队搞清楚两点
到底怎么样才算“完成”
为此应该如何协作
谁来做测试
测试不是一个人的事，是整个团队的责任
开发人员
确保代码，通过故事测试之后才发布进行后续测试
帮助测试实现测试自动化
客户
清楚软件的预期使用环境
敦促团队让客户随时可轻松获取最新可工作版本进行尝试
测试人员
擅长破坏性测试
思考考验系统的边界情况
帮助团队充实故事测试，验证是否通过
外部团队
在正式发布前执行一些特定测试
使不同角色彼此协作，他们需对完成的定义达成共识
定义“完成”的意义
完成
基本定义
客户对开发出来的东西感到满意
所有的故事测试都通过了
鼓励参照自身经验，涵盖所有认为重要的检查
与团队沟通完成之前的检查
代码已通过了团队中其他开发人员的评审
代码已有单元测试
已实现了故事测试的自动化测试
团队中的测试人员已完成了探索式测试
用户文档已更新完成，记入了最新的功能
已完成某个操作系统特定配置集的性能测试
完成定义步骤
项目开始时，讨论完团队的工作约定后，讨论完成的定义
公示“完成”的定义
检查发布前需完成的事项
回顾会上修订对完成的定义
留意是否假定了迭代结束之后还会进行其他检查，并询问对应的执行人
团队完工吃力，找出瓶颈，想办法改进工作流采纳看板方式，限制工作队列，将其提现到团队板上
测试的规划
邀请测试人员分享担忧
确保测试人员被邀请参与规划会议，鼓励他们积极参与其中
作用
理解测试实际工作方式，更好规划测试活动
开发、测试人员挨着坐
作用
增强沟通
建立尊重
开发、测试并肩作战摸清故事测试细节、找出测试失败根本原因
缺陷管理
思考处理迭代中发现的缺陷
软件已实现了用户故事的主要价值，可推迟修复缺陷
妨碍发布，马上修复与客户沟通当前状况
标出失败的测试
使用团队板来标记出失败的测试，整个团队都能看到
把延迟的缺陷当做新的故事，放入用户故事backlog 留给后续迭代
缺陷追踪系统
作用
一个隐藏的blocklog
找到问题的根源
鼓励团队找到导致缺陷的原因，思考如何避免它的发生
尽早得到反馈
开发人员完成了故事的切片，就可以提供给客户或测试人员以获得反馈
留意测试人员和客户向开发人员的反馈方式
鼓励他们分享自己的观察，而不是观点
如果客户并未和开发团队坐在一起，让他们每天预留一个小时来帮助团队
从未完成中复苏
未完成时，理解发生出现这种情况的原因
询问有何建议可组织这种情况再次发生
规划下次迭代之前，决定如何避免完不成对其速率的影响
清理干净团队板，未完成故事，与新故事一起，带入规划会议
如果团队一意孤行
说服团队，让其了解说不也是一个选择
帮助团队收集数据，放慢速度、承诺更少
让客户了解这样做会有无法交付的风险
如果客户无法放弃任何故事
拆分更细用户故事，让团队有更高几率交付一些故事
难关
与我无关
引导做些测试工作，确保学习时有人陪伴和支持
建立起为整个团队服务的责任感
与远程测试人员共事
迭代前安排一个电话会议，谈谈测试任务的估算，结合开发任务一并考虑
以电子形式追踪缺陷，确保团队通过简单的方式和远程测试人员交流
组织强制使用缺陷追踪器
测试人员的工作是要预防缺陷，而不只是收集它们
鼓励团队只用缺陷追踪软件应对迭代结束之后才发现的缺陷
检查表
和团队确定“完成”的定义
确保在得带规划会议时把测试考虑进去
鼓励开发人员跟测试还有客户密切合作
推荐在迭代过程中把软件做到可供客户使用
使用团队板展示在迭代结束前修复的缺陷
如果团队并未完成所有故事，选择演示或回顾会议，和团队一起找原因
10.测试驱动开发
定义
使用自动化测试来检查代码是否可以工作
作用
开发人员可以更自信地开发
测试人员专注于边界案例
帮助团队转向持续集成
引入测试驱动开发
步骤
找到切入点，一次选择一个问题
测试驱动开发
步骤
写代码之前先写一个测试
用最少的代码通过测试
找机会巩固代码并消除重复
作用
帮助开发人员转换视角，由外而内地看问题
先考虑代码接口，然后才是内部逻辑
共同合作确立测试策略，把测试组织起来做成团队任何人都可以运营的一个共享测试集
团队每天写一些自动化测试
作用
提升技能并搭建测试基础设施
了解每个人改变自己工作方式的兴致
采用PrOpER循环消除TDD面临的一切障碍
团队的认同
商定可以做出的承诺
找到阻止他们开始尝试TDD的障碍，并移除
使用同意梯级帮助团队决定行动
代码道场
定义
把开发人员聚起来，解决摸个预先准备的编程挑战
作用
提高开发人员设计技能和促进团队学习
演示如何一小步一小步解决编码问题
步骤
两名开发人员用一台连接投影仪的电脑开始编程
一边应对，一边大声讲话，介绍工作内容，实时解说问题解决
每5分钟更换搭档中一人，由其余人员顶替，持续一个小时左右
该学学怎么写测试
找有自动化测试和TDD经验的人去帮助团队
做计划时留时间学习如何编写自动化测试
提前告知客户，经历学习期团队速率很有可能会下降
决定从何处入手写测试
以迭代方式完成遗留代码测试的改造
为新代码和遗留代码的修改部分编写测试
与团队商定测试策略，决定如何测试不同区域的代码
在白板上画出软件架构草图，和团队一起走查架构，找出最能收益自动化测试的部分
单元测试
形式
非单元测试
和数据库对话
跨网络进行通信
动的是文件系统
无法正常运行，而其他单元测试可以
需要先对环境调整（编辑配置文件）才能运行
与真正的单元测试隔开，以随时有一个可快速运营的测试集
关注代码中可能有问题的路径
团队商议好如何组织测试，测试的命名方式等，保持一致性
团队所有人顺利运行自动化套件
持续集成
定义
尽早且频繁地集成代码变更
团队的共同约定
所有测试在任何时候都能运行通过
2-4小时提交一次代码
从培养CI纪律开始
遵守一个同步式CI流程
代码提交并构建成功后，再继续开发代码测试没有通过的话，去修复问题
构建令牌
作用
帮助开发人员学习承担失败构建的责任
密切注视团队承担责任修复失败的构建
改善构建状态的反馈机制，让团队第一时间知道
一旦构建失败就向所有人发出警报
反馈需要又快又明显
保持使用TDD
留意运行缓慢的测试
把接收测试也当做完成用户故事IDE一部分，当做其“完成”的定义的一部分
把运行时间长的测试隔离成单独的测试套件在后台运行
保持警惕，杜绝低劣测试拼凑覆盖率的情况
修订测试策略，扩大覆盖面
难关
无可用测试工具
维护测试先行之纪律
结对讨论设计帮助开发人员着手使用TDD
每个人都有自己的分支
和团队谈一谈，鼓励尝试几周的CI，团队回顾时再做检查
检查表
转为TDD需要有充足的时间
全新项目可以从测试先行起步
整个团队都要能认同此方式才行
团队计划要记入学写自动化测试的时间因素
把团队聚起来商定一个测试策略
持续集成是一种态度不是一组工具
团队使用了CI服务器，就要让他们轻松履行职责修复失败的测试构建做到可视化，让整个团队都能看见
留意运行缓慢的测试，用测试覆盖率帮助团队更清楚自己做得有多好
11.代码整洁
增量式设计
定义
拿时间出来，一小步一小步地边做边改
设计改进变成日常工作，每个用户故事结束时干完
软件设计还是编写代码实现更多用户故事，需要找准平衡点
摆脱分析过度
尝试找出阻碍团队前进脚步的障碍
通过实现需求来验证想法
对前进方向达成共识
团队陷入僵局，组织一次团队研讨会，评估各种设计方案的利弊
外部专家提供独立视角，团队匿名投票方式来决定
预留设计的时间
帮助团队时刻将设计铭记在心
估算中为设计讨论和设计重构预留时间
把设计评审加入到团队的“完成的定义”中
通过结对编程实现代码
帮助团队在设计讨论中使用白板，亲自示范
重构
定义
不改变行为的前提下，提升软件设计的活动
作用
保持代码调理、不紊乱
方式
通过重新组织及重命名代码提升可读性
通过整合、删除未用代码减少冗余代码
重构工具
如果大家刚接触重构，则在计划中预留团队学习时间，鼓励举行一次代码道场
可读的代码
作用
方便未来几年的代码维护者
意识到自己写清晰代码的必要性
介入并教团队其他成员更好地表达自己
集体代码所有权
定义
任何团队成员可以编辑任意代码
留意团队开发人员之间的交谈深度
让团队联手，像一个真正团队那样工作
带领整个团队共同商定编码风格
使用同意梯度确定是否已有足够共识
保持结果的可视化能提醒大家不忘约定，还能展示他们的遵守情况
回顾会议可以讨论形式变化不如预期的原因
与专家共事
结对编程预防团队相互不沟通
修复破窗
协助团队制定行动计划
认识到问题并把它分解成一小块一小块
结对编程
定义
两个人一起干活，用同一台电脑解决同一个问题
角色
驾驶员
负责打字
导航员
负责考虑后续步骤和观察潜在的缺陷
结对者轮流担任这两个角色
作用
代码质量更高
优良实践在团队中广泛分享
开发人员更少被打断
每一部分代码都有超过一个开发人员了解它
实现了统一的编码风格
团队融合提高，因为团队互相学习，很享受一起工作
辅导单个开发人员的绝佳方式
鼓励开发人员交换结对
难关
开发人员不喜欢结对编程
乒乓编程
与团队讨论必须做多少结对编程，什么时候结对编程比较合适
开发人员不遵循团队代码实践
和违反实践的开发人员聊一聊，了解个中缘由
故意违反约定，更适合换个团队工作
编程语言的差距造成结对编程的障碍
结对编程对熟悉那门语言的开发人员有意义
检查表
帮助团队找到平衡点，决定如何分配用于软件设计与实现代码的时间
在规划过程中，提醒团队为增量式设计预留时间
鼓励团队每次签入代码前都进行重构
带动整个团队商定一个公共的编码风格
帮助团队制定计划
采用结对编程，让两个脑袋一起来解决难题
引入乒乓编程，鼓励在结对时轮流担当驾驶员和导航员这两个角色
关心质量
12.演示成果
作用
进行演示能够激励他们按时完成所有东西
准备演示会议
作用
成功会议的秘诀在于准备工作
计划做几个可演示的故事
至少演示一两个用户故事
谁来参加演示会议
维护团队演示工作成果的权利
演示会议大概一周前把邀请发给所有人，以便大家预留时间
团队可以安排一次单独的演示环节，如果高管未到场
向干系人简要介绍迭代流程
最终确定运行顺序
迭代最后一天的时间表
一次演习为演示会议做好准备
澄清哪些故事已完成可以做演示
决定呈现故事时的顺序
商定那个人呈现哪个故事
组织一次排练为演示做预演
演示那天所发生的的典型交谈
技术准备
只在已验证过的干净的集成环境下演示软件
会议开始前的准备
调试演示要用的所有器具
检查网络连接
会议即将开始时提醒团队
每个人都要上场
客户做会议开头，对本迭代目标和要开发的用户故事进行概述
团队可以等到演示完软件后再讨论这些不足发生的原因
团队呈现他们的工作成果，自行决定会上谁来做呈现
收集演示过程中的所有反馈，正面反馈和负面反馈在内，默默记在索引卡内
会议结束前，复审反馈要点，检查有没有遗漏
宣告会议结束之前，针对如何记录团队速率达成共识
会后，确保团队新建用户故事记录下演示中的改进提议
鼓励团队为自己去的的成果举行庆祝活动
回顾会议中讨论还存在哪些问题
发布软件
团队需要和用户一起检查下列项目的情况
软件是否已充分测试过
是否存在致命问题
对终端用户来说，现在是否是获取新发布的好时机
相关文档是否已完成（例如发布说明）
团队是否需要委派一名团队成员支持这个发布
碰到问题时这个发布是否支持回滚
难关
演示时软件不能正常运行
检查会议室电脑是否已安装必要的软、硬件以正常运行
故事无一完成
坦然面对该情形，按照当前状况进行展示，通知重要干系人，拿到有意义的反馈
下次把用户故事细化
帮助客户认识到团队要先结尾之前工作，不能承担更多故事
演示依赖于其他软件的软件
构建大型产品的一部分，共同召开联合演示会议
如果不可行，基于软件桩运行软件来进行演示
我们的软件没有用户界面
鼓励团队微数据处理创建可视化呈现
检查表
和团队一起规划，确保所选故事都能演示
确保整个团队包括客户都来演示会议
迭代最后一天，提醒团队评审，明确演示内容
帮助团队避免演示会议受到技术故障影响
会议中要记下干系人的反应和反馈
团队需和客户确定哪些故事吻合了完成的定义，以便计算最终速率
鼓励团队实现部署和部署测试的自动化
演示会议结束后，庆祝团队所取得的成绩
13.以回顾驱动变革
拿出时间来理解所发生的的事情并改变他们的行事方式
让团队学会回顾，识别出当前流程中的痛点，学会独立解决问题
引导回顾会议
帮助团队探索问题
对于上个迭代有何见解
希望重点改善哪些领域
下个迭代可以实行哪些想法
回顾会一半时间回头看过去的迭代，得出相应见解
前进档得出让情况好转的想法，实施想法的行动计划
回顾过去
步骤
想坚持变革，必须获取团队的认同
要寻求改进，须先构建支撑体系
团队中每个人把自己在上个迭代中学到的东西（故事）汇聚起来
花时间倾听每一个人的讲话
便利贴创建一条时间线
作用
拼接出一幅完整的事件图
观察其他事情对自身行为产生影响
激发团队查漏补缺
方式
彩色时间线
绿色
愉快的时间
粉色
紧张有压力
黄色
中性
情绪仪
分辨团队干劲十足和意志消沉的时刻
美术馆
团队把感受到的项目画成图，贴到墙上后逐一展示
挖掘宝藏
步骤
调查时间线开始，努力定位挖掘点
邀请团队就费解的纸进行澄清
泛泛的理由用具体例子来诠释问题
走完时间线，采用记名投票方式，削减清单到只剩前二或前三话题为止
关注团队下个流程可完成的改进工作
向前看
团队想清楚如何改变自己的流程
没做完的行动，弄清楚原因，考虑增加措施
定义不清
没有明确责任人
没有时间
留出足够时间，制定团队所有人都一清二楚的切实的行动计划
行动鞋
橘色长筒靴
快速行动解决紧急事件
棕色工作鞋
务实的行动
灰色运动鞋
收集某问题的更多数据
深蓝色海军鞋
遵循标准流程的行动
紫色马靴
权威的行动
粉红色拖鞋
需要关心他人感受的行动
一步一个脚印
步骤
询问团队如何一步一步向前进,步子迈得越小，团队就有更大可能达成
针对所有行动步骤，逐一检查，将先导事项化为行动
探索问题，搜集数据，采取行动，解决问题
团队就如何实现这些改变的问题上达成共识
步骤
团队成员独自写出他们希望团队采取的行动清单
接下来团队结对，将他们的清单合并做成候选单
结对加入另一结对，继续裁剪他们的清单
最后团队得到经过集体精简后的行动候选单
规划下次迭代综合考虑这些行动
策划回顾会议
基本准备工作（引导会议）
向团队建议安排不同的活动
洞察解析
商定流程改进的关注点
激活创造性解决方案
最高指导原则
定义
每个人对自己的工作都已全力以赴
安全探究出错原因
回顾会议不是讨论个人绩效的最佳场合
抵消基本归因错误的影响
更大范围回顾
发布回顾会议
召开一个关注范围更广的回顾会议邀请和团队合作的人参加这个会议
人员
与团队合作的人
销售
市场
客户支持
运营支持
系统管理员
作用
纵观全局
解决团队外部问题
安全感检查
方式
通过匿名投票摸清状况
作用
看大家是否轻松自如地谈论过去工作中出现的问题
步骤
匿名投票
分组讨论
集体汇总呈现
回顾会上要做一些准备工作
关键的项目工件
发布燃图
维基页面
难关
相同的行动反复出现
拆分成迭代即可达成的任务
沉默的队员
安插一些书写活动鼓励他们参与其中
团队成员怨声载道
做一些额外的检查
追踪记录因而损失的时间，上报管理层
保持中立
检查表
召开回顾会议时先往回看
后半部分向前看
留意回顾会议的“异味”
找出团队最想解决的问题
切勿过度承诺
上次回顾会议的行为未能完成，找出原因，考虑增加新的行动
14.自我成长
增长见识的方式
保证每个月读一本技术书
参加开源项目
每天都在社区邮件组一次发言
上班途中听一段播客
每个月腾出一个晚上参加兴趣小组的活动
分享所学
与其他人分享学习心得
接受训练
教导、引导、领导力和人际交往技能方面有一些优秀的培训课
制定计划
制定计划
个人发展计划
喜欢这份工作的哪些地方
兴趣在哪里
制定个人目标
构建自己的人脉
会议
呈现工作坊
经验报告
用户组
参加本地敏捷兴趣小组
个人反思
反思以往经验
日记
反思及改进自身表现的极佳方式
把思绪写下来能帮助你表述自己的感受
成功日记
作用
围绕有效运转的部分构建组织
找一名教练
为下个月设定有弹性的目标
一个月内可达成的SMART目标
休息片刻
方式
不会被打扰，可以放松下来让大脑开个小差
放松，要淡定
不能因为别人不听建议就发火
善待自己和他人
未来之路
成长超越了当前所担任的角色
加入某个新团队，新项目或新部门
辅导比以前更多的人
辅导那些有别于自身经验的工作角色
做其他人的导师
确保自己的工作充满挑战，最好是略显艰难，督促自己一直保持专注
检查表
花时间学习
设定计划，确定当月想学什么，怎样学
花时间反思
最强效的教训是从自己或大或小的错误中学习得来的
留出时间放松自己
每天都要给自己留出时间，保持事情走在正轨上
结识其他与我志同道合的人
本地兴趣小组和会议都是认识别人的好地方
善待自己
汲取教训、赔礼道歉，继续向前
善待他人
别归咎于人们动机不良
别让工作一成不变，要不断推进自己
倾听反馈