当前位置： >
> 敏捷教练-如何打造优秀的敏捷团队 PDF扫描版[71MB]
敏捷教练-如何打造优秀的敏捷团队 PDF扫描版[71MB]
敏捷教练-如何打造优秀的敏捷团队
书籍大小：71MB
软件语言：简体中文
书籍类型：
书籍授权：免费软件
更新时间：
书籍类别：其它相关
购买链接：&&
应用平台：
网友评分：
内容介绍热点排行下载地址相关内容
内容包括326个种和品种，以“怎么办”的形式，深入浅出、简明扼要地直接进行了回答，力求做到全面性、科学性、新疑性和实用性相结合，对花卉生产者也有参考指导作《浪潮之巅》 近一百多年来，总有一些公司很幸运地、有意识或无意识地站在技术革命的浪尖之上。在长达十年甚至几十年的时间里，它们代表着科技的浪潮，直到下一波浪潮的来主板维修从入门到精通（全彩典藏）》由资深主板维修培训师精心编写，以最新主板为基础，全面、系统、深入地讲解了主板元器件的识别和检测、主板各种单元电路的结构原理、单网络存储是一个涉及计算机硬件以及网络协议技术、操作系统以及专业软件等各方面综合知识的领域。目前国内阐述网络存储的书籍少之又少，大部分是国外作品，对存储系统底层细新版增加了大数据和机器学习等最新内容，以满足人们对当下技术的学习需求；同时，根据专家和读者的反馈更正了错漏，并更新了部分内容算法(第四版)作为算法领域经典的参考书，全面介绍了关于算法和数据结构的必备知识，并特别针对排序、搜索、图处理和字符串处理进行了论述。本书主要介绍计算机单机系统的组成原理及内部工作机制，包括计算机各大部件的工作原理、逻辑实现、设计方法及其互连构成计算机整机的技术《计算机组成与体系结构:性能设计(原书第8版)》以intel x86和arm两个处理器系列为例，结合当代计算机系统性能设计问题，介绍了计算机体系结构的主流技术和最新技术计算机组成原理(第2版)概念清楚，通俗易懂，书中举例力求与当代计算机技术相结合，可作为高等学校计算机专业教材，也可作为其他科技人员的参考书。本草纲目是一部具有世界性影响的博物学著作，作者李时珍，这是它的电子版本，以《本草纲目金陵版》为基础，按药物的“正名”、“释名”、“气味”、“主治”、“附方”分为
敏捷教练-如何打造优秀的敏捷团队 PDF扫描版[71MB]
CopyRight &
JB51.Net , All Rights Reserved《敏捷教练——如何打造优秀的敏捷团队（Agile&Coaching）》阅读随笔
<img src="/blog7style/images/common/sg_trans.gif" real_src =".cn/YGK7e0_n.jpg" STYLE="max-width:690" WIDTH="200" HEIGHT="250" NAME="image_operate_10604"
ALT="《敏捷教练&&如何打造优秀的敏捷团队（Agile&Coaching）》阅读随笔"
TITLE="《敏捷教练&&如何打造优秀的敏捷团队（Agile&Coaching）》阅读随笔" />
&&市面上讲怎么做敏捷教练的书有2本，1本是这本，还有1本叫Coaching
Agile Teams（早前Ethan总在KM中给过一本供借阅）。这本书名为敏捷教练，但其实"敏捷教练"和Scrum
Master并不是截然区分的2个帽子，"Agile
Coaching"是每一个Scrum
Master都应该掌握的方法，因此这本书中的几乎所有内容，都适用于Scrum
Master。书里干货还是挺多的，不过和预期略有点不太一样，原本有点以为会讲些怎么coaching人（如具体的，怎么培养SM），不过这本书主要篇幅是在讲怎么coaching具体的敏捷过程和实践。
& 我学到的东西：
核心的Coaching模型就是PrOpER了。觉得起这个名字的水平……还要大小写跳过字母的。。。不如加个什么W的，变成POWER得了。PrOpER就是Problem -& Option -& Experiment -&
Review，这个思维倒是挺好的，有点lean
startup的意思，首先要界定问题，然后考虑备选方案（可列出多个选项），然后just do it，再总结经验教训、回顾改进。
作为教练，是不能自己卷起袖子深陷于项目任务的。就像足球教练，需要站在场外而不是站在场上，这样有更理想的角度，更能全神贯注于全局状态、改进过程、提升团队合作。
"房间里的大象"理论：教练不能浸泡在一个团队中太久，否则像黄瓜在盐水罐里浸泡的下场一样，不管是否情愿，都会变成腌黄瓜。房间里的大象就是说，有些问题触目惊心的存在、却被明目张胆的忽略掉了，原因就是"不识庐山真面目，只缘身在此山中"啊。缓解的办法就是多点和外面交流，把团队的状态告诉团队外的人、或者邀请团对外的人参与团队活动，就会得到不一样的反馈。
教练要化解团队矛盾，基本原则是要询问他们的感受和需求（来自《非暴力沟通》一书），有4个步骤的基本套路：观察（"当你……的时候"——描述观察）、感觉（"你是否感觉到……"——揣测情绪）、需求（"因为你需要……"——揣测需求）、请求（"你想让我/他/他们做……吗"——建议行动）
理想情况下，教练总是会发现大把的问题和改进机会。不要着急，心急吃不了热豆腐，像Kent
Beck说的一样，"从小的变化开始，每次只做一件事，其他的稍后慢慢来"，专注于一个问题和团队一起解决。
在变革遇到阻力时，可以提议：尝试一下，权当做试验。团队会评估试验成功与否，这回引导团队关注其好处，考虑如何度量改进效果。这里面有一个天大的秘密：一旦团队决定冒险，把改变当作试验来尝试，团队成员就会习惯于新的工作方式，再退回来的实际概率很小！
对于激发团队自己思考问题（而不是教练思考问题），可以问的问题，带有"思考"（包括同义词，如想、考虑、见解…）这个词的问题就是好问题。例如：这个问题你考虑多久了？你有哪些见解？针对这件事情目前的考虑，你觉得有遗漏吗？等
对于客户（或Scrum里的PO）的角色，在大型的项目中，只有一个人担当客户肯定是不够的，需要有一个客户团队。一种合理的解决方法，就是近客户（near-customer）和远客户（far-customer）组合，近客户负责跟团队一起明确需求的细节，远客户负责业务优先级的决策。近客户和开发团队坐在一起，而远客户和运营、市场团队坐在一起。近客户就是BA/SA，远客户就是真正的产品经理。
每日站会：严格的站会规则（几点开、谁能说话、三段论）适合于初始引入的Scrum团队，但要注意不要变成应付式的"照章办事"、扼杀团队内部的自组织。不要本末倒置，我们更乐意听到热烈的讨论、每个人的都很投入、发挥出创造力，这是我们希望达到的状态。
用户故事：有些人把用户故事当作新的需求文档来使用，这就完全错过了用户故事的要义，用户故事的要义就在于问问题——3C
客户测试：不要也不应该期待客户写出边界测试/异常处理测试，这是IT人员份内的事情，用户只会也应该专注于软件交付的业务价值是否符合他的预期
这本书对看板的解释，我觉得是我看过的定义得最好的，如下这段话："软件开发中的看板系统专注于实现工作的可视化，呈现价值流中的不同转化阶段，并限制每一点的在制品数量。团队因而可以发现系统中存在的瓶颈和约束，并借此持续改善系统，提高生产力，改善绩效。"
慎用电子化的敏捷管理软件。如果项目或敏捷流程本身有问题，引入电子工具未必能解决问题，而且这类软件更易于掩盖问题，并促成糟糕的沟通实践。对于同时使用物理工具和电子工具的团队，建议只需在迭代的一头一尾使用电子工具，前面记录下故事的标题（及必要的信息）及估算值，后面记录故事的实现状态、团队的速率。中间任务级的信息，没有记录的必要。
重构：重构就像在家里整理东西，如果我每次去超市购物回来，都把东西随手一丢、也不收拾，我的房子很快就会变成一个烂摊子，房间里堆得满满当当，家里变得寸步难行。我啥也找不到，最终我可能要重新买这些东西。我可能会打碎一些东西，因为它被其他东西遮住了。所以，重构就是让代码一直有条理、不紊乱，对于居家，它就是最基本的持家之道。
回顾会：就是50%的时间回顾过去，50%的时间展望未来。回顾过去有3招：彩色时间线、情绪曲线、美术馆。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。《敏捷教练-如何打造优秀的敏捷团队》读书笔记
本书通过真实的例子，介绍如何辅导团队平稳度过整个敏捷转型生命期，如何打造一个自立、自觉的敏捷团队。针对敏捷实践的工作机理和如何激发团队的成长有深入的思考，可帮助读者了解如何高效召开各种敏捷会议，及如何指导团队建立良好的工作流程和工作习惯。总结了在敏捷转型过程中教练和团队可能面对的障碍及应对方案，很多都是我们实际敏捷过程中遇到过的问题，对于刚开始推行敏捷转型的敏捷教练、团队还是很有指导意义的。
后面几章是讲具体的敏捷实践，在很多书籍都有介绍过，就没有仔细去看了。
第一章教练的职责
1.1敏捷教练的职责
1.2教练角色
?给出建议，让团队自己决策而不是由你指定方向
?以团队外援的身份履行教练角色，优势在于能够和团队亲历问题，而不是旁观。团队知道你是从亲身体验的角度看问题时，会把你视为自己人。
?敏捷教练并不需要知道所有的答案，有时候没有答案反而更好，非专家定位有助于你和问题保持必要的距离，还能从局外人的角度看待问题，帮助团队整体优化。
?可以引导讨论，也可以引入组织内外其他敏捷团队尝试的经验。
?团队境况越来越好的时候，教练应该功成身退，让团队自我教导，自己想办法找答案。
1.3几个重要的习惯
?以身作则：从自己做起，让团队看到真实的例子
?平衡心态：别让团队的反应乱了阵脚
?循序渐进：耐心，逐步改进
?谨言慎行：注意言辞，说话要基于团队的立场
?边走边学：尝试，反思，从错误中学习
1.4教导前应澄清的问题
1.5PrOpER教导循环
?问题：选择一个问题着手解决，观察团队的工作方式，哪些方面需要改进?
?选项：考虑可选方案，哪些能推动项目向好的方向发展，列出至少三个选项。
?试验：选择其中一个进行阐释
?检验：检查结果，是否有所改善?是否有经验教训?
1.6考虑可选方案的方式
?暴露问题：让团队看到问题
?公开讨论问题：和团队讨论这个问题
?静观其变：搁置问题，如果情况变得更糟糕，团队也许自己会发现问题
?暗度陈仓：说服团队内或团队之外的其他人认识到问题
?根因分析：寻找问题的根本原因
?教育团队：提供更多信息帮助团队找到解决办法
?予人权责：将此职责转交给团队或某个团队成员
?在受阻时，可以想象其他教练面临同样的情形时所采取的措施。
1.7腌黄瓜现象
? 黄瓜在盐水灌里泡久了，会变成腌黄瓜。
? 如果我们跟同一个团队，甚至同一家公司长达几个月之久，会失去我们的新鲜视角。我们会看不出以前一眼就能察觉出来的问题，思想逐渐大众化，&我们这里就这样做事&。
? 如果发现自己正在变成腌菜，试着向外人解释你所面对的团队流程及挑战。解释过程中，也许能再度发现流程中的问题、隐藏的假设以及&房间里的大象&。
? 房间里的大象：指那些触目惊心地存在却被明目张胆地忽略甚至否定的事实或者感受。
1.8敏捷拦路石
?当团队碰上严重障碍无法走向敏捷时，建议先移除障碍，再启动敏捷。不然人们会将失败归咎于敏捷。
?比如正在进行组织结构调整，人们会更关注如何保住自己的工作，而无暇顾及敏捷。
第二章 与人合作
?先倾听再提建议：
&倾听最难的在于克制自己的冲动，例如过早给出建议，或者把话题转到自己的相似经历。
&你也许对所发生的事情有不同的看法，但在查清事实真相之前，先花时间听完对方的说法。
&谈话顺利，可以要求澄清问题，以便不带偏见地理清事情的来龙去脉，并体现出你的意图在于澄清事实，而非对他们的行为进行盘问或批评。
&参与集体会议时，如果你发现他们误解了一些东西，比如：&我们已经敏捷了，所以不需要写版本发布文档&，此时可以暂停会议检查团队对这一点的理解。
&大家说什么词，你就用什么词，不要把你的理解强加于人，大胆问他们并确认是否已准确理解他们的要点。
?言外之意：
&寻求支持，还是找认同感，还是希望你帮助解决他所描述的问题
&设身处地为他人着想，想象他们对现状的感受
?维系信任关系：
&结束谈话时，总结听到的关键点，并和对方确认，你是否理解他们的需要?
&讲话者和你分享信息总是有原因的，但如果谈话后不继续跟进，他们可能会再也不会这样做了。问题暴露出来后，需要深入调查后再承诺，不要勉强自己立即做出承诺。
&不要泄密，确认谈话内容是需要保密，还是可以和团队分享他们的担忧。
&引导会议的时候，关注每一位发言者，等他们说完后再要求澄清。可以复述他们所讲的内容，这有助于你检验自己的理解。
&谈谈从你的视角看到的数据，给出你曾经耳闻目睹的具体实例，而不是你的诠释。
2.2化解矛盾
?有时团队会遇到一些冲突，教练可能会被卷入其中，如果发现团队内潜藏的矛盾，就多花点时间听听团队内有哪些看法，了解它的来龙去脉。
?在扮演仲裁者角色时，不能偏袒任何一方，聆听各自对问题的描述，并用自己的话复述问题，表明你理解他们说的内容。接下来剥离个体原因，从团队的角度重新描述问题，告诉大家你发现一些环境因子对局势是有影响的。比如团队承受着交付压力，导致大家都工作到很晚。或者画画因果图，查明有哪些影响力。
?团队内部化解纷争，有助于停止各自为政的行为。通过聆听，了解团队面临的问题，建立互信。
?给反馈时，要区分所见所闻跟感受。讲观察结果时，要用实际的例子，而不是泛泛的建议。先讲述耳闻目睹的例子，再问问他们的见解，接着大家一起讨论下次如何应对类似的情况。
?如爆发冲突，确保冲突各方都有机会陈述各自的观点。
2.3达成共识
?引入新实践的时候有助于搞清楚是否所有团队成员都买你的帐。
?梯度级别投票，将赞同的级别分成从力挺到力阻。
?共识很重要，因为在有人不认同某措施的时候，他们不大可能全身心的投入。有时候你得做出决定，即使没有达成共识，也值得去做。通过一段时间的变更，团队在回顾会议上重新评估其成效。但如果梯度级别显示有很多反对声音，就得努力寻找所有人都能接受的方案。
?相反的有同意阶梯，即在大家同意做某一件事的前提下，针对具体细节做投票。
第三章 领导变革
3.1引入变革
?身为敏捷教练，你的工作有时是引入新的敏捷实践，有时则是帮助团队优化工作流程。不管是哪种，都需要领导团队实现变革。这并不是告诉大家该做什么这么简单。人们需要先知道为什么要这么做，才能全身心投入其中。
?不能太快推动团队实现变革，开始变革前，团队需要时间讨论一下，认识到自己现在需要做哪些调整。
&仅仅说服团队必须变革还不够，还需要告诉他们怎么起步。假设你给某团队的建议是写单元测试，说这可以帮助减少缺陷泄露，你会发现所有人都点头赞同，但就是不真正动手写测试。千万不要惊讶，他们需要再支持以实现变革。
&有以下办法可以试试
?教育团队：安排内训课，帮助大家学习如何写单元测试
?演示：和开发人员结对，亲自示范如何写单元测试
?公示：帮助团队达成共识，每天都写一定数量的单元测试;在团队白板上追踪目标的进展。
&不要急着发表自己的观点，先准备好可以驱动变革的问题兜售出去。团队如果不改变，最可能的结果是什么，要把这幅景象清晰的描绘出来。让大家都明白，&不变&是有问题的。
&变革的确需要花更多的时间、金钱，可能还会有很多困难。跟大家解释，为什么你还认为变革是个好主意，带来的收益大于付出。
&例如：先走查，而后才迁入代码，这意味着实现用户故事需要更长时间，但这同样意味着，从长远看代码更容易维护。
&如果能找到支撑观点的证据，兜售问题就更有说服力。上述例子，如果能分享一些代码在发布前被频繁退回返工的数据给大家看，再提出预测就会很有效。但不要批评团队当前的工作方式，教练的关注点是流程改进，不是个体绩效。
&在理想情况下，你会发现大把的问题和改进机会，但是如果一个不漏的数落所有问题，就会给人留下负面印象，人们很快就不会再听你的。
&如果要人们接受你的领导，可以&从小的变化开始，每次只做一件事，和团队集中精力解决它，其他的稍后慢慢来&。
?向别人提问的行为表明你尊重他们的意见，而且对他们的回答感兴趣。尽量采用有启发性的问题，比如：
&要让这个缺陷不再出现，我们能做什么?
&我们怎样才能做到按时发货?
?使用&为什么&这类问题要格外小心，这听起来像是批评，虽然你并无此意。比如：&你为什么要那样做?&听起来就像指责，而&你有试过&做吗?&听起来友好一些。也尽量不要使用&你们&这种字眼，让人感觉居高临下。
&求助型问题：不要在团队会议上问，那是一般的做法，要选择一对一的时间问他们。
&思考型问题：通过思考型问题引导团队思考。比如：
?这个问题你考虑多久了?
?针对这件事情所做的考虑，你自己满意吗?
?你有哪些见解?
3.3鼓励学习
?鼓励团队在计划里留出一些时间，例如，如果团队想要试试测试驱动开发这样的新实践，他们需要有时间事先学一学怎么做，而后才开始实施。
?不要让团队对你产生依赖，把你作为他们唯一的敏捷知识来源，要鼓励他们自己主动学习相关知识。
?安排时间让组织里的其他人分析他们的敏捷经验，这能为你的同事创造机会，展示他所学的东西。
3.4引导会议
?为团队引进新实践时，需要展示具体做法。例如回顾会，主动请缨引导会议，向团队展示具体做法。在会议进行时，把遵循的流程解释给团队听，让他们学习如何自主引导这些会议。
?下次会议前，协助会议的引导者规划会议议程，而后在会议中退居次席。但也要实时发表评论，向团队展示你的思考过程。
?总结要点：结束会议时，把所有要点记录在白板上之前，复述你的理解，检查并确认自己真的理解了这些要点。
后面几章都是讲具体的敏捷实践，在很多书籍都有介绍过，就没有仔细去看了。推荐这篇日记的豆列
&&&&&&&&&&&&