search.xml

<?xml version="1.0" encoding="utf-8"?>
<search>
  <entry>
    <title><![CDATA[敏捷教练第02课-储备-Scrum 精要]]></title>
    <url>%2F2018%2F06%2F03%2F%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%AC%AC02%E8%AF%BE-%E5%82%A8%E5%A4%87Scrum%20%E7%B2%BE%E8%A6%81%2F</url>
    <content type="text"><![CDATA[介绍 Scrum 的书虽然还没有达到汗牛充栋的程度，但已经是著作等身了——所有著作加起来能够等同于一个人的身高了。本文并不是对 Scrum 理论的简单重复，而是立意能做到两点： 涵盖 Scrum 中所有重要的概念。 所介绍的方法达到说明书的程度，拿过去就能用。 敏捷产生的历史背景首先简要谈一下敏捷产生的历史背景，以及由 Scrum 及其众多兄弟方法共同抽象出的敏捷宣言。 敏捷产生的历史背景，在于世界变化越来越快。人们不断产生更多更新的需求，技术因此不断进步，两者交相辉映，使得变化越来越快。 以通信行业为例，从 1G 到 5G 呈现出一种升级越来越快的状态。 1986年，作为 1G 标志的使用模拟信号的世界上第一套移动通信系统在美国芝加哥诞生。 1995年，诺基亚崛起，进入数字调制的 2G 时代。 2009年左右，CDMA 大行其道，进入数据传输速率更高的 3G 时代。 2013年左右，伴随移动互联网，移动通信进入网速更高的 4G 时代。 最近一两年，随着 AR、VR、车联网、物联网的诞生，5G 的商用化指日可待。 在这种变化越来越快的环境之下，传统的软件开发方法不再奏效。敏捷先驱们开始探索一些新的方法，对丰田生产方式、组织模式等进行了大量学习，发明了 Scrum、XP 等各种方法论。2001年，新方法论的创始人们聚首一堂，总结了各家方法论的共同点，提出了敏捷软件开发宣言。 敏捷宣言有4个价值观和12个原则，它们也是 Scrum 的基础。对4个价值观要能够背诵下来，对12个原则也要熟悉，以便达到遇到实践情况时能容易对照的目的。我们为您精制了手绘版的敏捷宣言价值观和原则，可以打印张贴备查。 敏捷软件开发宣言 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： 个体和互动 &gt; 流程和工具 工作的软件 &gt; 详尽的文档 客户合作 &gt; 合同谈判 响应变化 &gt; 遵循计划 也就是说，尽管右项有其价值，我们更重视左项的价值。 敏捷宣言遵循的原则 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 业务人员和开发人员必须相互合作，项目中的每一天都不例外。 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 可工作的软件是进度的首要度量标准。 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 以简洁为本，它是极力减少不必要工作量的艺术。 最好的架构、需求和设计出自自组织团队。 团队定期地反思如何能提高成效，并依此调整自身的举止表现。 Scrum 方法论 我们力求把方法论介绍到可操作的程度，从方便理解和记忆的角度，Scrum 方法论可以被概括为3355 3个角色 PO（产品负责人） SM（Scrum Master） 团队成员。 3个物件 Product Backlog（产品列表） Sprint Backlog（迭代列表） Product Increment（产品增量） 5个会议 Product Backlog Grooming （产品列表精化） Sprint Planning（迭代计划会） Daily Stand（每日站会） Spring Review （迭代评审会） Sprint Retrospective（迭代回顾会） 5个价值观勇气，承诺，专注，开放，尊重。 Scrum 由上述四种要素及背后的规则粘合起来。 3个角色各有担当又通力合作。 3个简单的物件统摄产品层面与迭代层面的交付物。 5个会议贯通产品层面与迭代层面的计划与执行活动。 5个价值观作为方法论的一部分，体现了 Scrum 以价值观为方法论的特色。 3个角色的职责 Scrum Master 的职责Scrum Master 的职责最难讲得清楚。有一个思路是参照卡诺模型。日本教授把产品需求分为三类： 必备型需求：这类需求没有满足，客户不会购买这个产品。 多多益善型需求：这类需求的实现程度与客户付钱的愿望呈线性关系。 喜出望外型需求：这类需求是区别于竞争产品的分水岭，客户愿意付出溢价。 按照这个思路，我们可以把 Scrum Master 的职责分为三类： 必备型职责：协助管理 Scrum 的3个物件和5个会议。 多多益善型职责：与各方沟通和协调问题解决。 喜出望外型职责：系统思考，发现流程和团队工作中的改善点，并推动改善。 产品负责人职责管好产品列表。理解了什么是好的产品列表，也就理解了产品负责人的职责。后面会讲产品列表。 团队职责与传统团队职责不太一样的主要有两点： 跨职能：个人不一定是全能的，但团队要是全能的，具备把产品列表变成产品增量的全部技能。团队成员之间，不受角色和头衔的制约，只要具备能力，每个人都可以认领所有任务。 自组织：团队自行决定自己的工作方式，只要团队有共识。原则上是全员参与估算和计划，全员进行项目进度的监控和调整。在现实的团队中，有专职人员，也可能有浮动人员，不管是专职人员还是浮动人员，几个共同的基础是：自动化与及时化，每个人都做好本职工作，彼此之间良好配合；每个人都理解团队的产品目标和迭代目标；每个人都了解团队的工作方式和节拍。 浮动人员的类别 一类浮动人员，例如架构师和设计师，有全局影响，但又不是全职参与。有两种变通的参与方式，一是跟专职人员一样，参加 Scrum 会议，二是在团队中指定他的影子，与他密切协作保证他能及时贡献到团队的目标。 二类浮动人员，如固定在两个团队之间共享的测试人员。 减少共享的人数，尽量把测试人员固定在其中一个团队；由有能力多任务的资深人员在两个团队之间浮动领任务，以缓解对其他人员的共享需要；在极端情况下，才让（1）中的人员也在两个团队之间浮动。 三类浮动人员，如在一段时间之内有部分时间花在该 Scrum 团队的人员。与一类浮动人员相比，这类人员的全局影响相对小，更多是因为技能或资源问题而导致的安排。其变通的参与方式与一类浮动人员类似。 四类浮动人员，如尚不能独立工作的新员工。变通的方法是由其导师协助领取任务。 团队之要 在 Scrum Master 的引导和辅导下理解 Scrum 框架，特别是从事情角度的严密的 PDCA 循环，和从人的角度的紧密合作。 以严密的纪律性使 Scrum 能良好运转，达成业务上的目标，并收获高效快乐的团队。 在纪律的支撑之下，技术上精益求精，更好地发挥创造性，包括在技术领域，并适当参与产品探索领域。 Team 在 Scrum 中的活动 梳理 计划 执行 每日检查和适应 迭代检查和适应（评审与回顾） Team 特征 自组织：自组织不能来自命令与控制，而是简单规则支持下的群游。 跨职能团队：多样性，跨职能，不同背景，不同的思考角度，造就更好的产出，更快更好的解决方案、更棒的创新。 一专多能 火枪手精神（互助） 宽带宽沟通（沟通带宽递减：面对面 &gt; 电话 &gt; 即时消息 &gt; 邮件） 透明 团队大小5~9人 专注与承诺 可持续步伐 长期稳定的团队 3个物件 产品列表（Product Backlog） 产品列表（Product Backlog）是产品列表项（Product Backlog Item，简称PBI）的列表。PBI 包括特性、故障、技术工作和知识学习。 好的产品列表要满足 DEEP 原则： Detailed Appropriately 细节得当。越是马上要做的 PBI，越是要有足够的细节。很久以后才做的，可以粗略一点。 Emergent 涌现式的。PBI 可以根据实际情况随时插入。 Estimated 有估算的。同样是近期要做的 PBI，估算要较精细，可以采用费波纳契序列的故事点估算，即1，2，3，5，8 …对于远期要做的 PBI，估算可以粗略，可以采用粗略的T恤尺寸估算，即 XS，S，M，L，XL 等。 Prioritized 排好优先级的。近期要发布版本中的 PBI 的优先级要明确排列，中期的可粗略排列，远期的可不必排列。 迭代列表迭代列表由从产品列表中选出当前迭代要完成的 PBI，及由 PBI 分解产生的任务构成。对于任务的估算，可以采用天或小时估算，也可以不估算。采用哪种方式，以团队能够做出靠谱的迭代承诺，以及在迭代工作的每一天方便监测趋势为标准。 产品增量产品增量是一个迭代结束时，输出的用户可用的新功能。产品增量要达到潜在可交付状态，即如果用户需要，可以快速部署给用户使用。 5个价值观 5个价值观的落实与否，是 Scrum 团队形成的重要标志。 对于5个价值观的运用，可以由团队一起讨论，每个价值观分别意味着什么，并进而把价值观转化为可执行的团队规范。利用迭代回顾会议，审视团队规范的执行情况。 5个会议 产品列表精化会目的：准备好。准备好的意思是，经过精化，PBI 达到可估算可计划和可执行的状态。开发人员可以对之进行开发工作了。 流程：主要是围绕 DEEP 标准 细节得当。产品负责人讲解每个 PBI，达到团队成员理解需求的程度。涌现式。在精化的过程中，根据产品负责人与团队的互动，可能会产生新的 PBI。估算。在产品负责人讲完每个 PBI 时，团队可以用估算纸牌进行估算。通过纸牌对话，也可以保证每位团队成员都理解了需求。优先级。优先级主要由产品负责人排列，但团队的估算和实现的难易程度，也会影响产品负责人重新考虑优先级的排列。 辅助物件：为了保证产品列表精化达到准备好的标准，可以制定一个叫做准备好的定义（Definition of Ready，简称DoR）的检查列表。DoR 列表示例如下： 业务价值清晰。 团队了解需求细节，能够做出是否能完成的决定。 依赖被清楚地识别和管理，没有妨碍完成 PBI 的依赖。 团队具备完成 PBI 的技能。 PBI 被估算，并且足够小，能够装到一个迭代里。 验收标准清晰和可测试。 性能指标清晰和可测试。 团队知道在完成后如何演示。 迭代计划会目的：在计划会结束时，给出靠谱的迭代承诺。流程： 产品负责人建议迭代目标和要完成的 PBI。 团队把 PBI 分解成任务。 团队决定是在计划会上就把所有任务分配到个人，还是在迭代过程中动态分配。分配的方式是团队成员认领。要不要分配的标准是，团队是否能对迭代计划进行承诺。 评估计划的工作量与团队容量是否平衡。 从迭代计划中提炼出迭代目标，把 PBI 粘合在一起，把团队团结在一起。 团队对迭代目标和计划进行承诺。 辅助物件：为了对完成有统一的标准，需要完成的定义（Definition of Done，简称DoD）检查列表。DoD 检查列表示例如下： 设计有评审。 代码完成，包括：代码有重构，代码符合标准，有注释，有签入，有评审。 用户文档更新。 测试完成，包括：单元测试，集成测试，回归测试，平台测试，语言测试等。 零已知故障。 验收测试完成。 部署到生产环境。 可以用 A1 纸和便利贴辅助计划会议： Scrum 的两个要点是：人的有效参与，做事的有效轨道。 这个计划会的设计，是以有效的轨道辅助人的主动参与。 贴出一张 A1 大白纸。 左边第一列是故事，由 PO 用同一种颜色的便利贴书写和表达。字要大，用白板笔写，保证不用站得很近也能看清楚。故障，新特性或任何要交付的事情统称故事。故事右边，用另一种颜色的便利贴列出任务。任务是为完成故事所要做的事，由团队书写。可以写上任务的执行人与估算。 整个会议，一次围绕一个焦点，即当前讨论的故事。以故事为单位流动起来。 PO 的注意事项：清晰讲述。随着会议的焦点流动，把故事讲得让团队明白。 SM 的注意事项：适度引导。控制焦点与流动，一个故事充分讨论完并分解成任务，再进行下一个。保持紧凑的节奏和整体时间盒。 团队注意事项：主动参与。一是对故事不清楚的主动提问，而是主动参与任务分解、估算、认领。 全部故事讨论完和分解成任务后，统计每人工作量，看工作量与容量是否平衡，个人之间工作是否能置换以达到每个人的工作相对均衡。最后是团队决定是否能对迭代计划和目标承诺。 每日站会目的：围绕目标同步进度，掌握对于完成目标的趋势。流程： 准时开始。每天固定时间和地点。 每人回答三个问题：为了帮助团队达到迭代目标，昨天完成了什么，今天打算完成什么，遇到了什么障碍。 总结趋势和风险。 15分钟之内结束。 站会中细颗粒度的协作： 利用站会，促进细颗粒度协作。 故事和任务拉动按优先级进行。 需要协作的任务，其所有者勇于发起协作请求。 被请求者以协作的任务先于本人可独立承担的任务进行。 在回顾会议中明确讨论该模式，并贯彻。 模式可以由任何一人发现。 关于站会中的发散讨论： 站会中发散讨论的度以全部团队成员觉得爽为标准。 15分钟时间盒不必严格遵守。 Scrum Master 需要对站会之后团队成员的日程有了解，以便判断站会延长一点是否产生影响。 Scrum Master 可以观察对于发散讨论是否全部或大部分团队成员沉浸其中，如果是，暂不打断。 如果出现较多分神现象，打断讨论，并提议会后安排讨论。 或者根据站会的剩余时间，询问团队，这种发散的讨论是否会影响团队成员的后续日程。 按以上原则，打断可以由任何一人提出。 在回顾会议明确探讨这种情景中的模式。 迭代评审会目的：了解过去一个迭代完成了什么，并对下一步做出预测。流程： 产品负责人邀请客户和干系人参与。 团队总结过去一个迭代的成就和克服的挑战。 团队演示完成的产品，获得反馈。 产品负责人分享来自用户和市场的信息，预测调整发布计划，预测下一迭代的内容。 迭代回顾会目的：团队建设，发掘和计划改善。流程： 基调：真诚和有效。排除顾虑，真诚表达。提出有效的问题，落实有效的方案。 白板上写两个栏目：感谢，改善。 每人（包括 PO 和 Scrum Master）用 Post It 写出要感谢的人，每张 Post It 写一个，数量不限。写完贴在白板。 每人（包括 PO 和 Scrum Master）用 Post It 写一个最痛的改善点，只写一个就好。写完贴出来。 Scrum Master 无需太多发言，只需起一个指针的作用。先从感谢的纸条开始，一张一张拿出来问是谁写的，写的人面向要感谢的人表达感谢，不能太空洞，要谈一下感谢的内容。 然后转向改善栏目，Scrum Master 同样不要多说话，一张一张拿起纸条，让写的人讲，其他人可以参与讨论，这个环节焦点放在问题澄清，而不是解决方案，Scrum Master 对这一点要有一定把控。 每张纸条讲完后，所有人当场举手或竖大拇指，表达的是认为这个问题是否要尽快即在下一迭代解决。 全部问题澄清后，全体针对要解决的问题，讨论方案。Scrum Master 关注一下讨论的流动情况，既不要太乱，也不要冷场。极端情况下，可以点名让大家逐一发言，但尽量不用这一招。 产生的方案，形成改善 Backlog。Scrum Master 要跟踪起来，可以在日常或站会中跟踪落实情况。 Scrum Master 要观察团队互动中的交互情况，如果有分歧点，就是改善点。比如说在 Demo 中，PO 对验收标准的理解与团队不一致。这就是需要改善的地方。改善的讨论和进行，可以在日常与相关人员讨论，也可以放到回顾会议。 除了团队的回顾会议，还可以有一对一的回顾会议： 一对一 Retrospective 是对团队 Retrospective 的鼓励和驯化。是为了帮助打磨团队 Retrospective。 一对一 Retrospective 是对团队 Retrospective 的补充。即使团队 Retrospective 已经搞得很好了，也还需要一对一 Retrospective。 一对一 Retrospective 可以由 Scrum Master 发起，也可以由任何人向任何人发起。 一对一 Retrospective 的目的，是加强人与人之间的连接，传递改善的信念，和计划和执行改善。 一对一 Retrospective 的边界，是围绕改善的基调，就与团队项目工作相关的事进行讨论。 一对一 Retrospective 的框架，可以包含探询交流对象对工作方式的反馈、探询痛点和关注的问题，和以 Scrum 实践和角色要求为基准、以观察到的行为为依据向交流对象提供的反馈。还可以包含不同团队之间的经验传递、桥梁和延展。 如果希望痛点和问题的探询更封闭一点，可以分解为几个角度：就团队项目工作的上下文而言，您的目标和期望的理想状态是什么？与现状的差距是什么？流程上有什么问题，或有什么妨碍理想状态的达到？团队合作方面呢？团队工作绩效和质量呢？任何其他方面？ 这个框架的运用要灵活。人的主动参与重于规则。如果人能主动参与改善事项的发掘、计划和行动，框架就可以放下。 Scrum Master 日常有力的观察是 Retrospective 的重要输入。 各个角色的普适标准：专业、尊重、坚持。 改变的第一原则：一切改变基于自愿。改善的用意是改善系统，不是改变个人。 最后用十论 Scrum 就是知行合一对 Scrum 作个小结： 人人知行合一：人人计划，人人行动。 时时知行合一：时时计划，时时行动。 团队知行合一：团队决定，团队行动。 敏捷知行合一：快速决定，快速行动。 需求知行合一：接近客户，掌握需求。 支柱知行合一：检验是知，适应是行。 完成知行合一：定义完成，共识目标。 透明知行合一：高度透明，流畅过程。 纪律知行合一：自我纪律，助长能力。 美德知行合一：积极主动，集思广益。]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷教练和 ScrumMaster</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷教练和 ScrumMaster</tag>
        <tag>Scrum 精要</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[敏捷教练第11课-实战-敏捷教练实战周期V形六步法]]></title>
    <url>%2F2018%2F05%2F23%2F%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%AC%AC11%E8%AF%BE-%E5%AE%9E%E6%88%98-%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E5%AE%9E%E6%88%98%E5%91%A8%E6%9C%9FV%E5%BD%A2%E5%85%AD%E6%AD%A5%E6%B3%95%2F</url>
    <content type="text"><![CDATA[本文按1-2-3-4-5-6的结构，对敏捷教练的基本功进行总结，并讲述敏捷教练的典型实战周期。 1-2-3-4-5-6指的是： 敏捷教练的1个目标。 Scrum 的双翼。 团队的3个阶段。 敏捷教练的4个发力的角度。 团队中的5种角色。 教练周期的6个阶段。 基本功1个目标敏捷教练的目标是帮助组织做得更好。正如敏捷宣言所说：我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。 Scrum 的双翼Scrum的双翼或两条轨道，一是关于人，即自组织团队，二是关于工作方式，即基于精益敏捷的Scrum框架的运用。掌握了这两个要点，即提纲挈领，纲举目张。 团队的三个阶段 第一阶段是无组织。团队绩效不稳定且相对较低，团队成员呈现出一种各自为政的状态，团队活动从目的到流程都缺乏聚焦。 第二阶段是自运转。团队绩效达到一个相对稳定的状态，各项团队活动目的明确，流程清晰，在 Scrum Master 不在的情况下也能自动运转起来。 第三阶段是自组织。团队绩效会阶段性地持续提升，团队成员的互动达到一种高效快乐的状态，团队能够持续地从根本上解决问题，和持续改善。流程中的浪费越来越少，越来越流畅。目标的完成越来越好。 敏捷运用就是把团队从无组织状态带到自运转状态，再带到自组织状态。 敏捷教练的4个发力的角度 流程导入：包括产品管理流程和团队迭代运作流程。 问题解决：持续解决问题，打造解决问题和改善的文化，形成学习型组织。 个人转变：让个人接收敏捷思维，探索更好的工作方式。 团队建设：基于 Scrum，打造高效快乐的自组织团队。 团队中的5种角色 产品负责人：产品负责人作为 Scrum 团队的掌舵人，对 Scrum 工作方式的成败至关重要。产品负责人可能有两种，一种是具备开放心态，一种并不理解但又排斥敏捷的价值。对于前者，可直接交流。对于后者，可以让他先观察，接受他先不行动。 Scrum Master：Scrum Master 作为流程的化身，从另一个角度对 Scrum 的成败有举足轻重的影响。Scrum Master 要了解敏捷和 Scrum 的基础框架，要相信和支持自组织团队，要有持续改善的系统思维，并通过大量琐碎辛苦的工作来使 Scrum 的运作尽善尽美。Scrum Master 同样可能有两种。一种是主动把这个角色当成一个职业，并且主动投入去精益求精。另一种只是偶然被安排了这个职位。 团队成员：通常来说 Scrum 不会直接影响团队成员的利益得失，大多数团队成员对于高效快乐的工作方式是不会反对的。有了产品负责人对 Backlog 的良好管理，和 Scrum Master 的有效引导，团队取得进步是自然而然的。 非专职人员：非专职人员需要理解 Scrum 工作方式，并与团队成员有效配合。非专职人员与团队的合作方式，需要打磨出显式化可执行的规则。 Team Leader：直接工作在 Scrum 团队内的 Team Leader 可能会受到 Scrum 工作方式的冲击。Team Leader 是否要受 Scrum 框架的制约，要根据组织的实际情况处理。 教练参与周期的6个阶段 调查与方案：了解团队的目标，所面临的问题，制定敏捷导入方案。 导入与反馈：导入敏捷，获得团队反馈。 痛点与问题解决：了解团队的问题和痛点，协助问题解决。 卓越驱动的系统改善，共识机制训练：制定改善架构，进行有系统的改善。 深入的问题解决：发现和解决那些影响敏捷工作方式发挥作用的障碍。 观察与拓展，发现好模式：观察团队中浮现出的好的模式，借鉴到其他团队。 本文的剩余部分将会详细介绍这个敏捷教练周期的6阶段。 阅读敏捷教练周期的6个阶段时，有几个注意事项： 谨记教练的目标是打造按敏捷方式完美运作，并内建了持续改善能力的自组织团队。 深入的敏捷实施涉及到工作方式与人两个维度。 6个阶段包括其顺序都不是绝对的，需要根据团队实际情况定制。 6个阶段，可能的话可以与迭代的节奏一致，即一个阶段对应一个迭代，但也不绝对。 阶段1：调查与方案，诊断与对策这个阶段的开始以收到教练需求邀请为标志，以制定出敏捷实施方案，并能够开始第一个迭代的敏捷导入为标志。这个阶段包括调查与方案两个环节。 在调查环节所要做的事情包括： 访谈关键干系人，包括部门经理、项目经理、产品负责人、Scrum Master、开发 Lead、测试 Lead、架构师和设计师等，了解团队的目标及面临的主要问题。 参与团队的会议，现场了解团队现有的工作方式。 方案包含两部分 在启动第一个迭代前所要做的事。 第一个迭代的启动计划。 在启动第一个迭代前所要做的事可能有 如果产品列表和用户故事的管理不能达到启动第一个迭代的条件，需要与产品负责人一起工作，打磨产品列表和用户故事，使之达到准备好的状态。 如果团队规模和技能配备妨碍了团队自组织和跨职能工作，需要先解决这部分问题。 如果 Scrum Master 对敏捷和 Scrum 的知识不够，需要先补足这部分知识。 在调查和方案阶段，所使用的标准是 Scrum、用户故事和精益敏捷的基础知识，以此来识别问题，补足知识，和解决问题。所使用的技巧主要是讲授和问题解决，也包括一定的指导。 在这个阶段最开始，还有一件最重要的事，就是教练启动会议。没有教练的关系，就没有教练的行为。 经过第1阶段，就具备了开始第一个迭代的敏捷导入的条件。第一个迭代的启动计划在下一节谈及。 阶段2：实施变化，导入与反馈这一阶段的目标是进行敏捷和 Scrum 工作方式的首次导入，并获得团队的反馈。对于已经使用 Scrum 的团队，是一种重新导入。已经使用 Scrum 的团队，有可能受制于团队已有模式的影响，只是在形式上采用了 Scrum，而丢掉了本质和核心的东西，重新导入需要以正确的敏捷修正受到侵蚀的敏捷。 这个阶段如果有条件的话，可以做一个全体团队成员参与的一到两天的启动仪式： 与 Scrum 建立连接：探讨已有工作方法中好的地方，不好的地方，建立改善的愿望，把 Scrum 当作好的工作方法的载体，建立良好使用 Scrum 的决心。 介绍精益敏捷、Scrum 和用户故事的核心和实践。 让团队成员深入了解彼此，制定团队的价值观和团队规范。 刷新产品愿景、路线图、发布计划和产品列表。 如果不能进行一到两天的启动仪式，则可以在每个 Scrum 仪式前分别用10分钟左右时间介绍该仪式及相关物件： 在产品列表精化会前介绍产品列表精化的目的和流程。 在迭代计划会前介绍计划的目的和流程，及每日站会。 在迭代评审前介绍评审会议及回顾会议的目的和流程。 在每个会议的介绍之后，协助该会议的进行。对于会议中偏离目的与流程的行为，进行指导。指导可以以在每个会议结束时发表评论的方式进行，可以在会后进行个别谈话，也可以拿到回顾会议讨论。 在第一迭代进行到中间的时候，即可以开始了解团队对工作方式变化的反馈，因为这时工作方式的效果已经能发生了。了解反馈的目的是对工作方式进行修正。在第一迭代中间了解反馈还有一个好处是，鼓励团队把反馈和问题带到回顾会议讨论。内建团队的问题发现和解决能力是敏捷实施的重要目标，为了达到这一目标，敏捷教练要有意压制自己对观察到的问题的表达，而是把团队推到前面，帮助团队成长。 在导入和反馈阶段，讲授、协助和指导的技巧都会用到。问题解决和持续改善也会触及。协作指挥和冲突领航则是择机采用。 经过第2阶段，团队初步体会了完整的正确的敏捷，并为工作方式的变化提供了反馈，以帮助后续工作方式的调节。 通常来说，经过一个迭代按正确 Scrum 的运转，团队对更加清晰透明的工作方式会有正面反馈，迭代的完成率等结果指标也会有明显提升。 第3阶段：痛点与问题解决在这一阶段和后续阶段持续要做的事是，持续观察团队的 Scrum 仪式，发现其中违背正确敏捷实践的行为，以及发现团队工作中涌现出的好的模式。对于观察到的结果，可以在当时即每个仪式结束时现场提出来，可以在个别谈话中进行，也可以留到回顾会议。依然是两个原则：只要不影响团队运作的行为，尽量延迟到回顾会议进行；培养团队的问题解决能力重于问题解决本身。 这种观察、思考、反馈和调整会延续到整个教练周期，并且以打造按正确敏捷运作、具有自我改善能力的自组织团队为目标。 在这个阶段，除了观察、思考、反馈和调整之外，可以设定另一主题，那就是痛点与问题解决。具体的方式采用一对一谈话。谈话的对象包含产品负责人、Scrum Master、团队 Lead 和其他对工作方式有热情的人。整个教练计划可以公开给团队，可以发起一对一交流，也鼓励团队成员来发起一对一交流。 这一轮交流的三个主题是： 进一步获得他们对工作方式变化的反馈。 探询他们的痛点和希望解决的问题。 同时提供对他们本身的反馈。 这种交流是一种一对一 Retrospective，其目的、边界和框架如下： 一对一 Retrospective 是对团队Retrospective 的鼓励和驯化。是为了帮助打磨团队Retrospective。 一对一 Retrospective 是对团队Retrospective 的补充。即使团队 Retrospective 已经搞得很好了，也还需要一对一 Retrospective。 一对一 Retrospective 可以由 Scrum Master 发起，也可以由任何人向任何人发起。 一对一 Retrospective 的目的，是加强人与人之间的连接，传递改善的信念，和计划和执行改善。 一对一 Retrospective 的边界，是围绕改善的基调，就与团队项目工作相关的事进行讨论。 一对一 Retrospective 的框架，可以包含探询交流对象对工作方式的反馈、探询痛点和关注的问题，和以 Scrum 实践和角色要求为基准、以观察到的行为为依据向交流对象提供的反馈。还可以包含不同团队之间的经验传递、桥梁和延展。 如果希望痛点和问题的探询更封闭一点，可以分解为几个角度：就团队项目工作的上下文而言，您的目标和期望的理想状态是什么？与现状的差距是什么？流程上有什么问题，或有什么妨碍理想状态的达到？团队合作方面呢？团队工作绩效和质量呢？任何其他方面？ 这个框架的运用要灵活。人的主动参与重于规则。如果人能主动参与改善事项的发掘、计划和行动，框架就可以放下。 Scrum Master 日常有力的观察是 Retrospective 的重要输入。 各个角色的普适标准：专业、尊重、坚持。 改变的第一原则：一切改变基于自愿。改善的用意是改善系统，不是改变个人。 这一阶段可能获得的问题有： 会议效率问题：在 Scrum 框架之下继续打磨提升，细致地进行会议每个环节的提升，包括会前准备、会中引导、会后跟踪。比如说在精化会前大家可以先熟悉一下故事，在评审会前需做好演示的准备。在会议中引导促进大家的互动。 三个角色的职责问题：产品负责人负责与客户和产品有关的问题，Scrum Master 负责与沟通协调有关的问题，团队负责与技术相关的问题。 提升团队的参与度和对完整故事的关注：通过提升透明性，在计划会和站会上更加清晰透明地呈现工作来提升团队的参与度，通过设置故事 owner 提升和训练对完整故事的关注。 ：需要团队共创解决方法，比如说，一个原则是，开发优先做需要测试的任务。还可以设置开发任务的检查点。开发与测试结对工作。 团队建设，心理安全与归属感问题：需要与管理者和团队讨论处理。建立产品团队的形态与心态。 这些问题大致分布在流程与效率、角色职责、团队感和业务学习方面。 对于收到的问题的解决思路有： 按敏捷框架中的原则和实践解决。 拿到回顾会议上，由团队讨论解决。 对于深层次的组织问题，第一步是清晰的呈现问题，第二步是与有影响力的人交谈。 鼓励学习其他团队的 Scrum 运作。 在这个阶段，对于团队的 Scrum 仪式，依然会讲授、协助和指导。更多的是以团队为中心的立体双向反馈，了解团队的痛点和问题，并协助解决。 经过这一阶段，团队的敏捷运作已经达到了有意识的状态，虽然还不能完全自运转，但已经会发生一些有意识的提升和改变。另一方面，对于团队的问题也有了更深入的了解，为下一阶段的系统化的改善打下基础。 第4阶段：卓越驱动的系统改善，训练共识机制如上一阶段所说，对团队的观察、思考、反馈、调整还在持续进行。 此外，可以引入卓越驱动的系统改善。卓越驱动的系统改善即是： 团队定义一组卓越指标，即团队认为对于提升团队工作方式最有价值的东西。 对于卓越指标，利用每一次回顾会议，进行评估和改善。 以这一套卓越指标驱动系统化的改善。 卓越指标示例： 卓越指标1. 跨职能团队定义：不要让技能不平衡成为障碍。 子条目： 定义人与技能矩阵，以及理想的技能配置。在理想情况下，每一所需的技能最好有至少两个人精通和一个人了解。找出现状矩阵与理想矩阵的差距。 在迭代工作中，在团队容量容许的情况下，有意识地安排结对工作，以传播技能。结对工作所造成的团队速率下降以不超过10%为宜。 跨职能与结对的安排需要考虑个人兴趣。 制定长期的跨职能团队建设计划。 卓越指标2. 价值流优化定义：移除障碍，让团队所有的努力都指向对客户价值的贡献。 子条目： 制定 DoR 准备好的定义，形成高质量的迭代入口。 制定 DoD 完成的定义，形成高质量的迭代出口。 -每迭代的故事分为承诺的故事和可选的故事，可选的故事可以在产品列表精化会或迭代计划会上产生。 识别和移除障碍，帮助工作更好地流动。 会议议程有清晰的结构，每一议程精确到十分钟的颗粒度。 卓越指标3. 团队工作定义：团队协作，以最大化团队产出。 子条目： 定期知识分享。 经常庆祝成功。 集体代码所有。 交叉演示工作，例如 Tom 可以演示 Jerry 的工作。 卓越指标的制定，要由团队一起完成。具体可采用团队会议与一对一交流相结合的形式。 经过阶段4，团队的协作和 Scrum 运作已经相对比较熟练了。但其中依然有大量可以改善的点。而这个卓越驱动的系统改善提供了一个结构，充当了一个面。日常点的观察，与卓越驱动的回顾会议的面的结合，让改善更深入地发生。 阶段5：深入的问题解决在这一阶段，观察与改善继续进行。 经过前面几个阶段，团队的 Scrum 运作得比较好了，也建立了改善系统和一定的改善能力，解决问题的意识也建立起来了。 下一步是发现和解决那些影响敏捷深化的问题。这一步所采用的方法主要有四个： 观察团队的 Scrum 运作。 在回顾会上讨论需要改善的问题。 一对一交流。 团队的敏捷成熟度评估。 在这一阶段所要解决的，可能是一些深层次的问题，例如：团队中存在层级结构，或者团队成员来自不同的部门，让团队无法真正自组织，产生高质量的互动。 在这一阶段，问题解决是采用的主要技巧。 阶段6：观察与扩展，发现好模式。这一阶段主要有三个任务： 持续观察和改善。 发现团队中涌现出的好的模式，并使之持久化，和扩展到其他团队。 培养 Scrum Master 的系统观察和思考能力。 改善是无止境的，改善之旅是没有终点的。唯晓成事之规律，方持不灭改善心。 最后用大野耐一对丰田生产方式两个支柱的解读帮助我们了解敏捷和 Scrum 最本质的东西：人，以及人的配合。 大野耐一在其所著的《丰田生产方式》一书中这样评价“准时化”和“自动化”之间的关系： “准时化”和“自动化”是丰田生产方式的两大支柱。如果用棒球比赛来打比方的话，那么准时化就相当于团队协作，也就是通过团队密切而巧妙地配合，将其实力发挥到极致。而自动化则是要求每一位选手的个人技术要越来越高超，并且进一步使得团队的整体实力在个人技术提高的基础上得到更充分的体现。准时化可以让问题明确化，自动化可以让解决问题的努力更有效。自动化——让每一个人提高自己的水平，整个团队也会因为每一位选手的高超技艺，相互之间的配合变得更加默契，战法也更加成熟和丰富起来。当然，由此带来的结果就是：比赛的成绩越来越好，也就是企业的经营业绩越来越优异。]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷教练和 ScrumMaster</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷教练和 ScrumMaster</tag>
        <tag>敏捷教练实战周期V形六步法</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[敏捷教练第10课-技巧-持续改善和系统思考方法]]></title>
    <url>%2F2018%2F05%2F23%2F%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%AC%AC10%E8%AF%BE-%E6%8A%80%E5%B7%A7-%E6%8C%81%E7%BB%AD%E6%94%B9%E5%96%84%E5%92%8C%E7%B3%BB%E7%BB%9F%E6%80%9D%E8%80%83%E6%96%B9%E6%B3%95%2F</url>
    <content type="text"><![CDATA[是什么让一个团队与另一个团队有所不同？是什么使得一个团队在敏捷教练离开后仍能保持提升？答案是一个团队内建的持续改善与系统思考能力，特别是 Scrum Master。一个具备持续改善和系统思考能力的 Scrum Master，就已经不是只顶着这个角色的 Scrum Master，而已经是个敏捷教练了。这与外在的角色和职位名称无关。 本文按以下这个大循环介绍持续改善与系统思考方法： 思想准备：组织的常青，教练的使命，敏捷的逻辑，工作生活的四层逻辑，追求高绩效 技能准备：敏捷宣言，Scrum 框架，精益思想 现场现物：GROW 模型-真实的问题，真实的目标，真实的方法 识别问题：观察，交流 解决问题：因果逻辑，PDCA，回顾会议 固化成果：提炼和运用模式 打磨逻辑，不断实践 本文介绍的思想会落实到下一章典型敏捷教练周期六步法当中，是六步法背后的思想和逻辑依据。作为敏捷教练，需要不断做两件事：一是不断打磨逻辑，二是不断在实践中实证。这两点，也是本课程的灵魂，和敏捷教练技能未来发展的基调。 思想准备 组织的常青在《基业常青》一书中，科林斯和波拉斯确定“高瞻远瞩”公司的标准是：处于所在行业中第一流的水准、广受企业人士崇敬、对世界有着不可磨灭的影响、已经历很多代的 CEO、已经历很多次产品生命周期且在1950年前创立。根据这六条标准，他们选出的公司有：美国运通公司、波音公司、花旗银行、沃尔玛、迪斯尼公司等共18家。 这些常青公司有以下一些特质： “造钟，而不是报时” 科林斯指出，“伟大的公司的创办人，通常都是制造时钟的人，而不是报时的人。他们主要致力于建立一个时钟，而不只是找对时机，用一种适销对路的产品打入市 场；他们并非致力于领袖人物充满魅力的人格特质，而是致力于构建高瞻远瞩的公司组织特质，他们最大的创造物是公司本身及其代表的一切。”“造钟”就是建立一种机制，使得公司能够依靠组织的力量在市场中生存与发展，而不必依靠某位个人、某种产品或某个机会等偶然的东西。随着市场的进一步完善与规范，企业必须 越来越依靠一个好的机制，包括好的组织结构、好的评价考核体系、好的战略管理等。 “利润之上的追求”与“教派般的文化” 所有伟大的公司都是“务实的理想主义者”。“利润是生存的必要条件，而且是达成更重要目的的手段，但对很多高瞻远瞩的公司而言，利润不是目的，利润就像人体需要的氧气、食物、水和血液一样，这些东西不是生命的目的。但是，没有它们，就没有生命。”利润之上的更高追求在伟大的公司里，更是被作为像“教派般的文化”那样所灌输。“利润之上的追求”如果不明确、不具体，就会是空洞的大口号。企业要意识到企业文化的重要作用，“教派般的文化”指的是卓越公司必须具有很强的共同价值观。 “自家长成的经理人” “18家伟大的公司在总共长达1700年的历史中，只有四位 CEO 来自于外部”。“自家长成”的经理人熟悉了解本公司文化，更易带领本公司进行变革。 其实，任何一个公司无论长盛不衰还是昙花一现，都有意无意地由一种理念所指引。 这三个特质，跟我们在前文数次提到的作为精益和敏捷鼻祖的丰田 4P 完全吻合。 教练的使命: 要成为一家高瞻远瞩的公司，需要有一个像丰田 4P 那样的体系。体系的落实，需要教练。在丰田，经理就是教练，教练是一种管理职责。在丰田之外，经理与教练分离。教练需要在一定范围内取得组织授权，以便履行教练的职责： 贯彻敏捷的工作方式。 打造被充分激励充分赋能的自组织团队。 以此创造价值实现目标。 敏捷的逻辑: 按照敏捷思想，采用一种方法，比如 Scrum。最起码在团队中取得形式上的共识和一致。 团队自组织。以敏捷思想为指导，通过共识机制，持续改善与解决问题。 以前两者为基础，取得好的业务成果。同时个人获得职业生涯和工作生活上长期全面的好处。 第1点相对直观，第2点的逻辑基础是：好公司。 在非理想状态下，重点可以放在第1点，对第2点做有限度的追求。不管环境如何，我们依然可以有所作为。好与坏不是非黑即白，而是同一频谱上的两个点。我们能做的，是施加一点好的影响。 好公司的标准 员工有相对体面的收入和足够的激励。 有相对公平平等透明的制度。努力与结果之间有清晰的影响关系。 经理与员工之间互相扶助的关系。 公司有前途，有奔头。 员工技能提升与发展。 有明确的努力方向。 晋升加薪的机会。 以员工为中心，员工有机会参与和影响公司管理。 工作环境和制度人性化。尊重人。 流程合理，不会有很多阻滞，办事不难。 工作的稳定性和保障性。 第1点和第2点的区别是，第1点是相对可以有形化和规定化，第2点需要大家的讨论和共识。没有共识，第1点也难以执行。而第2点也离不开敏捷思想的指导。自组织不是一个悬空的虚拟的概念的问题，而是一种持续改进的共识的共同的问题解决。自组织不是一种脱离内容的形式，而要以内容即工作组织和问题为出发点。 在非理想情况下，打造自组织，可以采用的方法是，受限的共识，和受限的自组织，受限的好团队。不管环境多么恶劣，共识的空间是有的。共识与流动即知行合一。 团队的发展阶段 无组织（各自为政，效率低下） 被动的自运转（Scrum Master 驱动） 自运转（自动按 Scrum 运作） 受限的自组织（大环境不理想） 自组织（基业长青） 找到一些问题（如跨职能团队，价值流优化，团队工作），推动团队达到哪怕是不完美的共识，和不完美的执行。 团队的三个角色之外，也要把经理纳入共识的范围。问题的解决不用那么急迫。因为没有共识，急迫也没有用。大环境之下，团队之间差异的原因，如团队的构成，团队的年资等，也是值得思考的点。以逻辑的甘露，在理念和团队事实上，有步骤地把一团意大利面拉直成拉面。 工作生活的四层逻辑 生产力，其逻辑是技能。工作方式是否能辅助大家的技能提升呢？ 生产关系，其逻辑是交易。如何影响分配的规则呢？ 五伦之外，其逻辑是合作。如何找出大家共同追求的东西呢？ 五伦之内，其逻辑是爱。如何激发人的善意呢？ 不管环境多么恶劣，合作还是可以存在的。合作既是敏捷的基础，也是敏捷的核心。 追求高绩效 在一个组织中，大家有共同的目标，共同的规则，就可以追求高绩效了。 建立 One Team 的理念和实践。在一个团队中，可以就所有问题公开讨论，包括绩效管理，个人发展，技术，管理，业务，工作满意度，员工参与度等。 一个组织的形态，往往都是不够理想的。在这种情况下，我们心目中要有最终的理想，并根据情况，制定阶段性的理想。 技能准备 技能准备的部分在本课程的前面部分已经涵盖，总结下来，包括： 敏捷宣言 Scrum 框架 精益思想 技术实践 教练方法 自我提升 对组织和团队发展阶段的认识 本章的系统思考和持续改善 有了思想和技能上的准备，就进入现场现物的了解问题。 现场现物 了解问题可采用 GROW 模型： Goal 目标：组织和团队的目标是什么？是速度提升吗？是质量提升吗？干系人对目标的共识程度如何？ Reality 现状：现状是什么？现在采用的工作方式是什么？实际运作是怎样的？实际运作中有些什么问题？ Opportunity 机会：是否存在提升的机会？各方干系人的支持程度如何？有什么不可克服的障碍？提升之后对团队意味着什么？ Way 方法：具体可采用哪种敏捷方法？是一步到位还是阶段性的？ 要注意三个真实真实的问题：亲自了解问题，而不是道听途说纸上谈兵。真实的目标：各方共识的目标。真实的方法：找到问题的根源再解决，而不只是一些形式上的措施，比如针对一个表象的问题搞一次形式上的培训。 识别问题识别问题的途径包括： 观察：亲自去看团队的运作，特别是各种项目会议，日常交流，工作物件。有条件的话，可以看下团队实际的日常工作。 交流：尽可能与所有团队成员和干系人一对一交流，了解他们观察到的现状，看法和建议。 解决问题：解决问题可以采用的方法包括： 因果逻辑：对问题要找到原因，从源头上解决。了解团队运作的系统动力。如果只是做一些表象上的规定，根本无法落实和执行。 PDCA：解决问题要有完整的循环，包括识别问题分析问题设定目标分析根源制定对策的计划阶段，贯彻对策的执行阶段，评估效果的检查阶段，和标准化的调整阶段。 回顾会议：利用群体智慧，解决问题。 固化成果从解决问题中学习，把解决问题的方法提炼成模式。 在模式一章已经介绍了一些模式。再补充一些如下： 在站会中，会观察到一些好模式，如细颗粒度的协作。当一位团队成员说他要启动一个任务，跟他的任务相关的其他团队成员会立即响应说他会同时启动那个相关的任务。把这种观察拿到回顾会议上讨论，让团队参与这种模式的提炼，并丰富细节，记录下来。因为模式是大家共同提炼的，可执行性更强。 团队共同参与的庆祝成功也是一种模式。团队有共同的目标，经过努力，取得了值得一提的成功，大家就要庆祝一下。这种成功是属于大家的，并且成功能促进更多的未来成功。 制度化客户反馈与产品想法的分享。产品负责人可以把向团队分享客户反馈和产品想法制度化，例如在产品列表精化会和迭代计划会分别固定一块时间拿来分享这类信息。目的是让团队更全面的了解客户，知道自己工作的意义。方式上可以打磨，产生一种花费时间最少又对所有人最有意义的形式。 打磨逻辑，不断实践 系统思考和持续改善并不是什么高深的东西，最后总结如下： 对于好的工作方式，心中要有标准，这个标准是我们追求的理想状态，也是问题的鉴别器。 心中带着标准，去观察现状，去和干系人交流，了解真实的问题。 制定改善目标和改善方案，并取得干系人的共识和支持。 实施方案，评估效果。 固化方法，固化成果。 以迭代的方法重复上述步骤，以敏捷的方式做敏捷。 逐步加深解决问题的深度。在解决问题的同时，深化共识和合作。 始终不忘事件之间的因果逻辑，并持续躬身实践。 唯晓成事之规律，方持不灭改善心。思考，就是想出事物当中的理所当然。改善，就是把理所当然的事做到极致。]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷教练和 ScrumMaster</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷教练和 ScrumMaster</tag>
        <tag>持续改善和系统思考方法</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[敏捷教练第09课-技巧-敏捷教练的提升三式]]></title>
    <url>%2F2018%2F05%2F23%2F%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%AC%AC09%E8%AF%BE-%E6%8A%80%E5%B7%A7-%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%9A%84%E6%8F%90%E5%8D%87%E4%B8%89%E5%BC%8F%2F</url>
    <content type="text"><![CDATA[在经历了四种心法和六脉神剑的修炼之后，敏捷教练的路还要往前走。本文介绍敏捷教练的提升三式： 成败模式 技能清单 教练之旅 提升第一式：成败模式本节介绍敏捷教练失败的种种陷阱，和成功的许多要素。注意在教练过程中的错误模式，并有意识地选择不掉进它的陷阱里。越少掉进失败模式的陷阱，你就越有时间注意到你在指导过程中出现的好的事情，即成功模式。 敏捷教练的失败模式 侦探。花不多不少的时间观察团队，然后便生成并带着下次回顾会议的话题，消失在黑暗中。 海鸥。猛然扎进站会中，用善意的观察和建议冲击整个团队，然后便飞走。 武断者。经常表达各种观点，固执己见，不惜放弃指导团队进行有意义的讨论所需要的客观性。 行政人员。通过充当不必要的会议后勤、访问权限申请和其他行政事务的中间人来削弱团队的自主权。 轴心。充当团队成员间所有交流的中心，并进行任务层面的协调。 蝴蝶。在一个个团队周围掠过，停留的时间仅够传授一滴慧珠或提出一个富于哲理的问题。 专家。深入地进入团队工作的细节中，以致因为树太多而不见森林。 唠叨者。好心地提醒团队开始站立会议、更新状态墙、按时完成承诺的任务等。 失败模式的来源 失败模式起源于教练的自负或持续的局部关注。 当以我为主的想法无节制地蔓延时，就会很容易地转化为以我为中心的状况。 以我为中心，就不能给团队留出足够的空间来领会可能发生的变化、提出新的观点，让他们意识到能够真正做到多好。 当敏捷教练指导多个团队或因为其他情况分散精力时，通常就会出现持续局部关注的现象。 从失败模式中恢复 方法很简单：用信任取代担心。 要对团队成员寄予信任，相信他们真正知道去做正确的事情。如果他们失败了，也会从中吸取教训并变得更强大。 敏捷方法的框架中有各种内置的机制来帮助你拥有信任感，因为他们鼓励和容许犯错误。固定时长的短迭代确保大家不会失利得太远或者造成影响深远的后果。 关注团队中真正发生的事情和试图发生的事情。 信任加关注就是好的教练方法的基础。 培养觉知。让头脑中的噪音沉寂，以便能够思考，和可以进行清楚的观察。为自己的头脑腾出一些空间，有意识地对自己进行调整，以了解团队所需的东西而不是自己内心发生的东西。 保持好奇。对团队正在进行的事产生好奇，并产生清晰理解。 拓展视角。在一个更大的时间轴和更宽的框架内看团队的当前状况，团队的缺陷就只是一片有趣多变的环境中闪现的一个略带瑕疵的小点。回到团队的共享愿景宣言：同饮同甘共苦之水。精神振奋，让不良片刻远离。 结对合作。当你感觉到失败模式在控制你时，与同侪结对。他们协助你重申目标，牢记于心，把以自我为中心的想法抛到一边，聚焦于你的关注，并准备用信任的心态进行指导。 练习成功。成功需要练习。自我提炼或借用他人的成功模式，不断练习，直到你对它们的感觉比失败模式还要自然。 敏捷教练的成功模式 魔术师：问这样的问题，看看什么东西在那里，但刚才看不见。 儿童型：诚恳又惊讶地问为什么，并对生活和其中的一切有永不满足的好奇心。 长耳朵：听所有的东西，但不响应所有听到的，以给别人发展的空间。 好质问者：以轻松有趣和稍微失衡的方式，把别人从自满中摇醒。 大智若愚者：提出粗浅的问题来启发大家。 蔓延的葡萄藤：通过团队基本感觉不到的小步移动，无情地将团队一点一点拉回敏捷的核心。 梦想家：勇敢地说出未来可能创造出来的东西。 扩音器：确保所有的声音都被听到，特别是被压抑的声音。 提升第二式：技能清单敏捷教练之路没有终点。敏捷教练只是在不断学习并把各种新的技能汇集到我们的指导过程中，为我们团队的辉煌而努力。本节提供了一些线路标志来帮助你在敏捷教练之旅中确定方位。这些标志符即敏捷指导的技能和行为，可表明你仍然处于通向好的敏捷教练的诸多途径之上。 技能之缓慢地灌输敏捷实践 帮助团队从敏捷实践中收到预期的收益。 在考虑产品构造方案，决定其如何相互协作时，团队能够坚持从敏捷宣言价值观和原则出发。 在改变敏捷实践时，确保敏捷宣言和检查调整环路完整无缺，并视之为团队至关重要的法宝。 技能之启动敏捷团队 懂得启动团队的目标，并尝试用各种方法和活动来达到这些目标。 目标包括计划和执行启动活动，并根据这些活动的结果调整后续活动的执行方法。 需要知道如何实施团队启动才既符合敏捷特征又对团队有价值。 技能之一对一指导团队成员 能够轻松自如地进行一对一指导，并且被指导的成员感受到自身的变化。 认识到每个成员处于敏捷转型的什么阶段。 激发每个人为了成为优秀的敏捷开发人员而愿意采取行动。 技能之指导整个团队 把自己想象成敏捷的清道夫、领头羊、管家、质量和绩效的看护者。 确保团队在一段时间内只专注于一个迭代目标。 密切关注团队的日常交流，确保他们是在真正协作并朝最简单的方向努力。 指出某个破坏性行为，使得这种行为下次出现时，其他人也有勇气指出来。 当团队忘记他们的共享愿景时，进行提醒。 帮助团队朝健康的敏捷团队方向前进，最终产生他们引以为荣的结果。 技能之指导产品负责人 指导产品负责人与团队交互。鼓励产品负责人以正面的方式与团队交互，约束那些损害团队自组织的行为。 指导产品负责人实践商业价值驱动的思维方法。确保团队只做那些用来创建优秀产品的事情。 指导产品负责人创建、整理和使用产品列表。 指导产品负责人帮助团队排出障碍。 指导产品负责人管理干系人。产品负责人不断与干系人一道工作来了解他们的需求，将它们转化为唯一的明确的声音。 技能之指导团队外部干系人 与项目发起人、经理以及团队之外的干系人进行指导性交谈。 为他们与团队可能发生的有用和有害的交互制定法规，帮助干系人了解他们如何能够最好地支持团队的动力和结果。 教会他们如何利用敏捷来仅构造最本质和最有价值的东西以实现竞争优势。 技能之在变化中指导团队 帮助团队走出来自变化或处境艰难的失望，提出新的计划来恢复团队的技能和活力。 当团队前进时，总会有事情把他们击退回来。 通过运用敏捷原则、实践和价值观，给团队指明重新站稳脚跟的方法。 技能之激发通向高绩效的途径 指导团队取得越来越高的绩效。 在团队中激发出来一条通道，让团队把通往高绩效的旅途掌握在自己手中。 为团队中的每个人，团队整体，他们构造的产品以及公司带来成果。 技能之接受团队比你更好的想法 愿意让你的决定和观点屈从于团队的观点和决定。 让团队掌握产生想法和决定的方法。 走向自我管理，和对想法和决定的彻底执行。 技能之自我掌控 自己的行动是为了给团队带来所需的东西。 不是为了自己的需要。 为了团队而存在。 技能之成为敏捷价值观和原则的楷模 被团队看作称职和成功的敏捷人员。 让团队从你在各种情况下的处事方法和与他们相处的方式中看到敏捷的价值。 让他们通过你的示范学会了如何很好地运用敏捷。 让他们学习更深入的技能使自己能更完全地协作，并产生令人惊异的结果。 技能之驾驭冲突 学会并运用至少一种冲突导航模式来帮助团队跨越冲突。 在冲突未解决时能让相关方友善相处。 有意识地选择时机和方式介入团队冲突，包括有意识地选择让冲突存在而不加干涉。 最终达到让团队能完全由他们自己驾驭冲突。 技能之不断学习和成长 给自己灌输一种永不知足的学习渴望，以及见证团队和公司蓬勃发展的愿望。 把新发现的知识融入到指导过程中，并在指导过程中注意自己技能的增长。 腾出时间来学习新的技能，体验新的观念。 不断反思自己的指导能力。 技能之分享回馈 分享自己在尝试和折磨过程中所获得的宝贵教训，及学到的新方法。 参加敏捷社区和敏捷会议，在各种讨论中贡献自己的观点。 在会议中提交和分享话题。 敏捷教练绩效度量标准 不要驱使团队取得结果，不要命令式指导他人的工作。 要含蓄地领导，创建一个自然的环境让团队交付好的结果，而不需要任何人来驱使他们。 不要控制团队的工作来保证预测的准确性。 要放开手脚让团队来完成他们选择的工作，并且支持他们对自己承诺的结果负责。 不要遵从公司的规则。 要发现当公司的规则限制了价值交付时，就挑战公司的规则。 不要立即把问题提升到管理层。 要与相关人员一起研究问题，直到问题完全解决，并继续向前进。 不要偏爱已经验证的并且安全的选择。 要给团队营造安全感来试验、失败并吸取教训。 不要按计划交付产品。 要允许团队根据他们的变化和逐步精确的计划来交付产品。把交付商业价值作为唯一的度量。 不要遵从经受了时间考验的策略和过程。 要培养创造性和提高团队能力，把每种情形当成全新的情形并提升产生全新结果的可能性，即使在熟悉的领域里。 不要照本宣科地实施敏捷。 要知道在什么时候照本宣科是最好的方法，什么时候需要舍弃最强有力的敏捷表述来换取再困境下至少一点点的改善。 敏捷教练每周价值清单（示例）： 帮助产品负责人和产品发起人保持一致，让他们给团队的指示与产品愿景一致。 制作团队交付的东西对软件操作的影响的视图。 帮助 PMO 采用敏捷团队的发布计划来创建他的总体进度表。 指导 PO 和 Scrum Master 创建产品列表。 启动一个新的团队。 说服项目级变更管理团队与敏捷团队一道工作，而不是下达最后期限。 让敏捷经理意识到自己以前太强势。 敏捷教练对一次指导的回顾（示例）： 团队发生了重大变化并被公司领导认可。经理们说，如果没有敏捷，他们很难按时交付。 培养了强有力的 Scrum Master。 两个团队成功地完成了产品负责人的更替。 团队不断认识到浪费。 影响新团队采用敏捷。 帮助运营团队采用敏捷更快完成操作性工作。 憎恨敏捷的团队愿意尝试敏捷。 正向影响了三四个 PO 和 Scrum Master。 选用了新工具协助回顾会议和团队协作。 收到了正面反馈和肯定。 有能力指导管理层。 需要改善：帮助高层领导知道如何发掘敏捷团队的能力来更好地交付和应对变化。 需要改善：协助新 PO 和 Scrum Master 与组织墙抗争。 需要改善：让高层领导接受指导。 敏捷教练绩效考评 影响力：当你与团队交互并提出一个有洞察力或强有力的问题时，团队会提出更好的想法或转向行动吗？ 一对一指导时，注意他几天或几周后的变化。 为你做得好的事情欢欣鼓舞，客观面对使你或他人失望的地方。 只有你自己知道什么时候你做到了合格的敏捷教练。 提升第三式：教练之旅每个敏捷教练都是沿着自己设计的旅途在前进。本节给出了八个敏捷教练的故事。他们的背景、经验和视角迥异，但他们热爱敏捷指导的原因都是，敏捷方法既体现了天然的工作方式，又能交付切实的商业结果。 作者 Rachel Davies 的旅途：发现与倡导 从开发人员：接到需求，再设计，再开发，再测试。当项目没有按时交付时，每个人的辛苦工作成果就被丢弃了。 到开发经理：指挥团队工作。开始寻找一种尊重人同时也能使他们交付产品的方法。 到 XP 开发者：结对编程，团队工作，测试驱动，每周都能交付软件。 到敏捷教练：让团队驱动流程，以平和的步调工作。对于无意于敏捷的团队，需要理解变革需要时间，敏捷教练需要耐心，从简单的东西开始。随着时间的推移，花时间去听团队的想法并帮助他们找出可能采取的行动，而不是指挥他们去做什么。在与团队的互动和回顾中播下变化的种子，在种子变成绿芽之前需要时间，在结果之前不断施肥。 技术培训师丹的旅途：守破离进阶的反思 守：参加认证 Scrum Master 培训，按照书本上的方式做事。 破：敏捷团队的行动就像创业公司一样，都是通过观察来学习，对工作采用经验主义的做法。 离：Scrum 是关于角色、权力和边界的定义。意识到有更多的东西要学。 的作者 Lyssa Adkins 的旅途：弥补过失 从项目经理：按计划做事情。项目一个接一个地按时、按量、按预算交付，但没有一个交付能够使客户满意。一长串的人们为这些项目伤害了他们的生活，因为他们的工作时间远远超出人的正常期望。 到 Scrum Master：教授、辅导、协助、沉思、提高。大家在工作中专业、快速、具有质量头脑。团队真的知道如何正确地做要做的事。团队中最羞怯的成员开始大声说笑，并因为他的才气被大家认可。 到工作/生活教练。学会了如何让团队对他们的日程负责。带给他们新的思考方法，给他们的生活带来欣喜的变化。 到敏捷教练：团队确实知道什么是最好的，我只是帮助他们了解他们自己知道的。 认证 Scrum 培训师马丁·科恩的旅途：个人回顾 从层级管理者：让下属执行我的方案。 到 Scrum Master：我知道什么是最好的，教给他们做。 到学习情商：在一个新的层次上理解人们的动机、表达和能动性。需要重视每个人自身，尊重他们的观点，更多地了解他们的个人目标和信仰。聆听和理解大家的感觉和想法，通过提问题来帮助所有人理解事情的缘由。尊重团队过去的经验，帮助他们开发他们的优势，建立起敏捷团队的观念和意识。 到敏捷教练：让敏捷的好处永远伴随。帮助建立一个环境让每个团队成员充分发挥自己的才干，并创建非凡的方案来真正满足业务的需要。 凯西的旅途：学会指导 从项目经理：你们开始编程吧，我去看看他们要的是什么。擅长动员团队，带领团队走向成功，与管理层沟通，使管理层满意。 到 Scrum Master：发现团队难以管理，对 Scrum 会议没有兴趣。 到生活教练：学习主动倾听，强有力地提问，增强意识，管理进度及责任感。采用指导风格而不是管理风格。 到敏捷教练：指导团队作为一个专一的实体来驶向成功。帮助团队实现自管理。多提问而不是多给建议，承认团队具有成功所需要的知识，维持积极的前景和方法。观察团队成员如何行动、说话与交互，让他们发现哪种方法可行。介绍工具和技术来帮助他们，每次会问他们是否愿意采用这种技术，并遵从他们的决定。 敏捷教练 Glen Wang 的旅途：寻求合理的管理 从工程师：一线工作人员看不到大局，每天的工作被微指挥微管理，等级制度造成各种弊病，开始思考合理的组织和应该的管理是什么样子。 到经理：开始在可控制的范围内自发地实践自组织自管理，设定团队愿景，让团队成员参与计划和管理，自由领取工作。 到 Scrum Master：Scrum 就是要找的方法，运用 Scrum 之后，看见了更好的团队。团队产出更多，也更快乐。 到敏捷教练：精通精益和敏捷体系，系统思考，注重内在品质和教练方法。致力于打造理想的组织。 敏捷教练虎头锤的旅途：保持探索之心 从工程师：从瀑布到 CMMI，从学习敏捷理论，并参与到“四不像”的敏捷实践，总觉得摸到了敏捷的门，但是进不了敏捷的“道”。 到 CSM：CSM 的培训被 Spotify 模式惊艳，开始尝试在公司内部进行敏捷培训，通过准备培训教材和多次培训，探索和总结过往的经验教训。 到进入采用 Spotify 模式的公司：真正理解了敏捷怎样融入日常工作，如何用透明度传递信任。发现了可视化的种种好处，所以从绘画小白踏上了视觉引导之旅。 您的旅途：未解之谜，意义之旅 ? 你曾经做过什么？学到什么？什么东西被你发现了并融入到你的敏捷指导方法中？ 指导敏捷团队对你来说，有什么重要意义？ 你以前在哪里，准备去哪里，有哪些让你走到今天的重要指导事件？ 你前面的路是什么，你下一个要到达的顶峰是什么？ 把你的旅途分享给他人，既能获得支持，也是给他人的启发和礼物。]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷教练和 ScrumMaster</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷教练和 ScrumMaster</tag>
        <tag>敏捷教练的提升三式</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[敏捷教练第08课-技巧-敏捷教练的六脉神剑（下）]]></title>
    <url>%2F2018%2F05%2F23%2F%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%AC%AC08%E8%AF%BE-%E6%8A%80%E5%B7%A7-%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%9A%84%E5%85%AD%E8%84%89%E7%A5%9E%E5%89%91%EF%BC%88%E4%B8%8B%EF%BC%89%2F</url>
    <content type="text"><![CDATA[敏捷教练的六脉神剑针对敏捷团队的工作方式提供了六个不同的教练角度，前三剑针对的是更基本的场景，后三剑针对的是更特定的场景。敏捷教练需要对六个角度谙熟于胸，并针对不同的场景混合运用。大多数情况下，场景是可预测的，可以以六脉神剑为基础，制定自己的脚本和台词。在每一次的教练行为中，目的是第一位的，首先是确定目的，然后才是确定方法。除了每一次教练行为的设计，还要对团队完整工作周期的教练计划进行设计。敏捷基础与六脉神剑是设计的基石。 对六脉神剑还可以做另一角度的分类理解，即主动型和应对型。主动型即主动主导的行为，应对型即当一个情况发生时的应对行为。从这个角度看，指导、协助、讲授和协作指挥更多是主动型的行为，问题解决和冲突导航更多是应对型的行为。但主动的行为也可能是由场景触发，而应对的行为也需要有预案和主动探询。主动的行为更多是前馈，应对的行为更多是反馈。主动的行为更多发生在正式的仪式中，应对的行为则更多在日常随机发生。主动和应对都需要计划和练习。 这一章的使用方法跟上一章的使用方法一样，提供的是凝聚了前人智慧的检查列表，可以作为我们大脑的扩展。使用时，首先是事先学习，设想在教练工作中可能遇到的场景，针对每一场景可以有什么样的预案。第二是，在每一活动前，根据这些检查列表，制定自己的剧本或脚本，以便在活动中使用。第三是事后回顾，在每一活动之后，再来阅读这些检查列表，什么事自己做得好，什么事还可以做得更好。经过反复演练这三步使用，把这些方法内化成自己的方法，并能进行扩展和创新。 第四剑：问题解决 敏捷问题解决规则 一个问题引起了你的注意，或者你觉察到了一个问题。这个问题可能来自观察，也可能来自团队的反馈。 暂停一下，思考该问题，把问题看清楚。问题的真相和本质是什么。 团队拥有对问题的最多理解，并且对问题的解决负有责任，教练的责任是协助团队，把团队纳入问题解决和变成问题解决者。 允许团队应对解决或者不应对。解决问题以及是否制定计划和采取行动是团队的决定和承诺。 传授解决问题的框架，让团队成为解决问题者，是教练的目的。 发现与寻找问题 要抵制立即解决问题的诱惑。除非人的基本尊严受到侵犯，对于其他情况，并不需要立即处理。 识别是否是真实的问题。不为虚拟的问题进行虚拟的讨论。 流程层面的问题：我们在敏捷方面做得如何？可以采用敏捷成熟度或健康度检查列表，推荐 Mike Cohn 的敏捷成熟度模型和 Spotify 的敏捷健康度检查。成熟度或健康检查中，对问题的评估只是个触发，团队的对话才是最有价值的部分。 质量和绩效问题：团队如何可以做得更好？通过制定完成的定义，并在每个计划会上完善，在每个评审会上检查，来持续提升质量。 团队的动态问题：团队如何可以变成一个更好的团队？ 扩展：团队动态问题之艾伦-布劳恩的团队动态调查 在团队每天的交互中有多少幽默的成分？ 在出现困难和高压时，团队最初的行为是什么？ 团队成员出现抵触情绪有多么频繁？ 当团队成员有抵触情绪时，他们之间多久会进行一次充分的讨论？ 基于团队规范，在平常的交互中团队成员做出妥协有多频繁？ 任何一位团队成员向任何其他一位团队成员能提供什么样的反馈意见？ 任何一位团队成员向任何其他一位团队成员真正提出了什么样的反馈意见？ 一位团队成员与另一位团队成员讨论你的绩效和行为，而不是直接向你或者在第三方在场的情况下提供反馈意见，可能性有多大。 就个人的职业目标而言，你从团队中得到了多大程度的支持？ 在处理一个工作问题时，需要承认有问题并需要请求团队成员帮助，这种情况有多少？ 当你向团队分享个人信息时，你感受到攻击的可能性有多大？ 当一个问题可能引发团队内部的冲突或争论时，团队有多大可能性把这个问题带到团队中讨论？ 当一个问题可能有很多个冲突点时，你有多大可能把这个问题带到团队中讨论？ 如果一个工作项可能引发很多不同的冲突，你把它带到了团队中，并且团队达成了可行的共识，这种可能性有多大？ 在过去两个工作日中，你能举一个例子说明你在团队中感受到温暖和包容吗？ 在过去两个工作日中，你能举一个例子说明你在团队中感受到被轻视或排斥吗？ 团队在多大程度上让你觉得你对自己的工作是负责的？ 扩展：团队动态问题之 BART（边界、权力、角色、任务）分析角色 在你的敏捷框架中，所有正式定义的角色都有人员各就其位吗？ 是否所有正式定义的角色都在角色边界之内运作良好？ 是否有人承担的正式角色多于一个？ 如果团队增加了额外的角色，这些角色的描述是否充分和清晰？ 任务 团队成员对于他们的团队目标是否清晰？ 是否有为了完成团队目标所需的所有不同任务？ 人们从先前相似的情况中引入了什么样的历史和过去的经验？ 权力 对于每一个角色，它的权力是否被清晰地制定，并被所有人理解和支持？ 团队成员是否在适当地行使权力？ 边界 人们是否在被赋予的敏捷角色的权力边界内工作？ 在迭代期间，团队成员如何赋予另一个团队成员获取任务的权力？ 在团队中各种各样势力的边界的什么？ 清楚地看待与思考问题 留到第二天解决：让脑子放轻松，看看第二天起床的时候是否已经有了答案，也许一些更深入的事情或者重现敏捷本质的事情会出现。 向自己提问：如果在这个世界上我可以做任何事情，这个事情是什么？这里的风险是什么？如果这个情况已经很好地解决了，解决后的情况会是什么样的？ 与另一位教练结队：从一位旁观者的角度得到建议，或者一些挑战性的问题。 直奔源头：复习敏捷宣言及其背后的十二条原则。 解决问题 直接解决它：说出你看到的症状，抛出你的假设，询问团队，对于这个问题，他们想要做什么。 重申敏捷的含义：例如，对于每个会议的目的和流程，重回 Scrum 指南。 揭示体系本身：把团队比作一个生态体系而不是机器，通过观察和探究揭示这个系统本身，并向团队分享。 善用回顾：让团队以不同的角度思考他们一起工作得如何。 增加一种启示方法：例如，增加一面痛苦墙，让团队把遇到的痛苦记录下来。 第五剑：冲突领航冲突中敏捷教练的角色 敏捷团队要长期在一起，冲突解决尤为重要。 教练需要帮助团队排除冲突，提供解决冲突的方法、指南和框架。 教练需认真决定是否要、何时及如何介入冲突管理。 冲突的五个级别： 第一级，解决问题。人们有不同的意见，也许误解已经出现，目标与价值的冲突也可能存在，并且团队对于这种冲突的氛围感到焦虑。在这一级里，团队关注问题解决，信息分享和协作流畅，语言是开放和基于事实的。 第二级，争执。自我保护变得跟解决问题一样重要。团队成员之间产生距离感，壁垒在强化。个人保护胜过协作，语言是戒备的但允许解释。 第三级，争辩。在第三级，目标就是赢得胜利。多个问题汇聚成更大的问题，在这个存在误解的环境中出现派系。问题和人成了同义词，人们已经不能只对事不对人。胜利重于解决，语言中包含个人攻击。 第四级，圣战。人们相信，唯一的选择就是让对手退出。保护自己的族群成了焦点，语言呈现出意识形态的特征，而不是针对具体的问题和实事。 第五级，世界大战。毁灭是这一级的战斗宣言，胜利已经不够了，对手必须输。很少或没有语言交流，唯一的目的是摧毁对方。 确定团队的冲突级别 聆听抱怨：带着同情心去聆听，接受抱怨者所说的事情，让抱怨者知道你在关心他，并正在花时间了解冲突的方方面面。 感受活力：大家是在充满活力地协作？还是彼此梳理漠视？团队的精气神是积极向上，还是消极冷漠？ 关注语言：通过大家说什么和如何说，判断团队的冲突级别。 扩展：冲突级别与语言 第一级，团队成员开放且建设性地参与冲突。语言例如：我听到你说了，但我认为你忘记了一个事实；我知道你的想法，但我不同意，因为。。。 第二级，对话变得偏于自我保护。语言例如：是的，我是弄坏了这个构建，但在我们团队中有比这更严重的问题。 第三级，扭曲的语言出现了。例如：他们总是走捷径，他经常控制每一次对话。 第四级，变得更加主观。例如：他们永远不会改变，我们是对的。 第五级，充满了斗争。例如：要么是我们，要么是你们，我们必须赢。 应对冲突 首先，什么也不做。在决定干预之前，花一些时间观察团队的行为，看他们在处理冲突上是否有进步。 分析和应对，考虑以下问题：冲突的级别是什么？问题是什么？作为 A 方，我该如何回应？作为 B 方，我该如何回应？有哪些分解冲突的选择？如果有什么我应该做的话，那会是什么？ 使用架构：使用敏捷的精髓如原则、价值观和角色定义来排除冲突。平衡任务导向和人际关系导向。 揭示模型：揭示冲突层次模型，邀请团队加入对话，探讨如何降低冲突级别。 扩展：冲突应对模式 第一级，解决问题。协作寻求双赢，了解每位团队成员的想法，达成共识。 第二级，争执。允许对方解决问题，任何事情以心理安全为基础。 第三级，争辩。关系比问题本身更重要，先接受对方的观点。对于可以分解的问题，进行交涉。收集数据，建立事实。 第四级，圣战。再次构建安全框架，居间传递想法，降低冲突级别。 第五级，世界大战。做任何必要的事情防止大家受到伤害。 化解团队成员之间的抱怨 第一，建议抱怨者跟被抱怨者直接提及顾虑和感受。 第二，跟抱怨者一起找被抱怨者交流。 第三，征得同意，居间转告抱怨。 如果这三招都不灵的话，最后一招是：不再把它作为一个问题。 面对无法解决的冲突 敏捷团队是亲密的。增加团队成员之间的良性互动，而不是关注于解开并解决问题。优秀团队中积极交互与消极交互的比例是三比一到五比一。 避免误解形成。团队学习聆听和互相关注。 确认允诺和共识。确认所有的声音都被听到，并显式确认允诺和共识。 利用共享愿景：尽管团队通常是由经理们创建并通告团队的，团队在一起也没什么共同梦想，但团队依然可以围绕产品和项目生成共同愿景。 关于冲突的最后招式 了解冲突框架，选择应对方式，处理抱怨和增加团队的积极性，这些技术自身并不能解决冲突。 只有这些技能和思维方式在团队的行动中得到体现时，神奇才会发生。 保持对话的基础存在，冲突才有被解决的可能。 第六剑：协作指挥 从合作到协作 合作的效果是各个部分之和。而协作是整体大于个体之和。 对于不需要创造性的活动，可以只合作不协作。 协作是以合作为基础，但增加了产生创造性、突破性和意想不到结果的重要元素。 在协作中，每个人都会在他人想法的基础上思考，敢于分享和评议，让那些更好的、个人无法独创的想法浮现。 在协作之前先形成合作，每个人集中精力演奏好自己的乐器。 教练作为协作指挥者，加入沉默的人员一方，消除高声音者的优势，鼓励每个人变得更自信。 让团队通过不断练习，达到不需要指挥者的境界。 培养协作个体 传授他们合作技巧：建立响应能力，沉默即暗示同意，运用否决权，寻找其它方案，反思有意识意图与无意识意图，带着同情心说出真相。 引导他们提前准备：在协作活动时提前做好准备，例如，在每日站会时身心都准时到达。 鼓励他们表现自我：培养自我价值，但排除虚荣心。 建立协作态度：对自己的生活环境负责，而不是把责任推给他人；不设防，而不是有保留地进行响应；坦然响应，而不是在需要响应时感到威胁；尝试双赢，而不是防御；寻找解决方法，而不是泾渭分明反应强烈；劝说而不是责备；坚定而不是对抗；既考虑长期也考虑短期；对他人观点感兴趣；欢迎反馈；把冲突看成人类环境的天然成分；平静而直接地谈论艰难的问题；为自己的行为后果负责；持续寻求更深层次的理解；传达关切的态度；寻求卓越；聆听。 培养团队的协作肌肉 说出不能说的话：敢于暴露弱点，遇到困难时可以求助。 建立而不是打压想法：对过失展示容忍，制止运用惩罚，讨论和接纳不同的观点产生合力。 听所有的声音：提升安静的成员并抑制占优势的成员。 培养协作中的亲密关系：团队成员能够感知其他人对新素材的理解程度，迅速介入澄清，使团队级别的理解更快地达成。 一起认真做游戏：例如计划纸牌。 不断提醒他们直到会用。 揭示协作的真谛 要创新，协作不是唯一的方法，但它是最直接的方法。 协作发生在当下，只有当你这样做时，它才存在。 要协作，必须了解你和你的协作同伴为汇聚带来了什么。 对你的工作充满热情是协作的前提。 如果你遇到一个问题，需要别人做出改变，那么你尚未真正了解你的问题。]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷教练和 ScrumMaster</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷教练和 ScrumMaster</tag>
        <tag>敏捷教练的六脉神剑</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[敏捷教练第07课-技巧-敏捷教练的六脉神剑（上）]]></title>
    <url>%2F2018%2F05%2F23%2F%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%AC%AC07%E8%AF%BE-%E6%8A%80%E5%B7%A7-%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%9A%84%E5%85%AD%E8%84%89%E7%A5%9E%E5%89%91%EF%BC%88%E4%B8%8A%EF%BC%89%2F</url>
    <content type="text"><![CDATA[敏捷教练的六脉神剑，指的是敏捷教练在教练团队和组织时可以使用的六种方法。本章介绍其中的三种方法：指导、协助和讲授。这几种方法，既有不同的角度，有时候也交织在一起使用。我们既要明辨概念上的细微区别，在使用时也无需纠结使用的到底是哪一种方法。三种方法分开讲是为了讲解的方便和概念的提炼，实际使用时可以把三种方法中同一场景下的具体方法糅合在一起使用。 在每一种方法之下，按一个一个场景，提供了一系列检查列表。每一个场景既相对独立，所有场景结合起来又构成了一个完整的全景。所以，在阅读时，要调动见木又见林，见全牛又见解牛的思维。既高屋建瓴，也在一事一物上磨，方能知行合一，唯精唯一，事竟功遂。为学之要，在博学之，审问之，慎思之，明辨之，笃行之。 对于检查列表，要辩证地看待。一方面，检查列表是前人和过去的经验总结，让我们在无所适从之际有个东西可以作为开始。另一方面，检查列表与实际情况之间一定有很深的代沟，使用者需根据情况，制定自己的检查列表。一个建议是，把本课程当成一个模板，直接在上面增删改查，形成自己的检查列表，并经常阅读、思考、聆听自己内心的声音，和不厌其烦不惧挫折地实践。完美来自实践和操练。按此方法坚持下去，三个月必见功效，小有所成。 第一剑：指导 Sprint 开始阶段的指导 可以在团队成立初期，在第一个 Sprint 的开始阶段，或后续 Sprint 的开始阶段有不同程度的使用。指导的内容要根据具体的场景（比如说计划会是一个场景，也可以细分为几个子场景，计划会之前的准备和之后的跟进也是场景）事先设计，也要根据指导过程中获得的反馈调整。 这个阶段教学型指导应占主导地位，比如帮助团队学习敏捷实践或教他们如何真正进入到各自的敏捷角色中。 时刻铭记指导的目标：帮助整个团队了解敏捷是如何完美工作的。 当一个可以教大家某个具体概念的绝佳机会出现时，要把握住并“大声地”指导他们。 当团队需要时，可以安排一个讲座来介绍或加深某块具体的敏捷知识。 一种做法是在每个会议之前，指导这个会议应该怎样运作。 指导与培训的区别是微妙的，指导更多指的是指导的内容马上用起来。 Sprint 中间阶段的指导 只要团队工作进行得比较顺利，要减少整个团队级别的指导。 只有当教练有意识地要发表对大家有非常大意义的见地时，才进行整个团队级别的指导，比如说当团队显著偏离了敏捷核心和实践时。 询问团队，如果进行中期检查是否会有效，比如说当燃尽图形状不太好时，检查并进行适当的调整。 如果中期检查引发 Sprint 中间的回顾，就要停下来。 进行一对一指导，逐个解决每个团队成员的问题。 不要影响团队的正常工作。 如果两个成员之间有些矛盾，鼓励提出问题的成员与另一成员一对一地把问题解决掉。 当有人做了特别有帮助或意义特别大的一件事时，要在整个团队面前讨论和鼓励这种行为。但也不要太过正式。 教练的工作以观察、思考、聆听、响应为主。站会是团队工作方式的缩影，也是很好的观察场所。 教练心中要有标准，标准是观察的取景框。 Sprint 收尾阶段的指导 在 Sprint 回顾时，要创造条件让大家积极讨论。回顾的形式多种多样，在网上可以找到海量资料。要点是让每个人都参与其中，有均等的发言机会，并且确保回顾产生的行动能够落实。 要指导团队成长到团队成员懂得相互学习是多么美好的那种境界。可以策划知识分享活动。可以在回顾会中设置互相感谢环节。 可以把 Sprint 收尾阶段和下个 Sprint 开始阶段的指导合二为一：向后的回顾和为将来的任务进行培训。 产品发布层面的指导 与 Sprint 层面的介入周期类似。 在发布开始阶段进行教育。 在发布收尾阶段进行回顾。 在发布中间阶段进行整个团队的检查和对团队成员的一对一指导。 在指导个人和指导团队之间找到一个平衡点，选择最有影响力而又干预最小的指导方式。 指导的基调 爱心：爱，认可和支持他们成为更优秀的团队和个人。 同情心：尊重他们的现在，帮助大家成为想要成为的那个人。 永不妥协。不能偏离敏捷核心和实践。 但不需要在工作场所表现的过于感情丰富。爱心和同情心必须是真实的，大家能从你的眼睛，听和说中感受到你的尊重。 充满爱心和同情心会让你坚定信心不妥协。 将这种对信念的坚持传递给他们，完全相信他们能成为自己想成为的人。强调每个人都具备不断提高自身敏捷能力的可能性和需求。 不要期望团队成员的表现能够立即达到你的高要求，但不要容忍他们用折中去改变敏捷标准的定义。始终强调真正高效的敏捷应当如何运行。 要了解，变得更好是一个历程。耐心和设身处地去了解每个人的实际处境，而不是去追求从概念世界推导出来的理想的完美。 不要自卑和自怜于自己的人微言轻。教练是一种职业。跟其他职业一样，不是以权威，而是以你的专业度令人信服。记住帮助团队做得更好这个使命和目标。 一对一指导的前提 在超前半步的层次上进行指导：用心倾听每个人的内心，了解他们面临的矛盾和麻烦，了解他们在敏捷之路上处在哪个阶段，注意观察你的指导给他们带来的改变。 置身于充满安全的环境：允许他们犯错，跌跌撞撞，抱怨。所有这些行为都不会受到绩效考核的影响。在团队内部发生的事就让它留在团队里。确保有足够的空间让彼此表现人性固有的一些弱点，并对团队内部发生的事情保密。但如果出现了极端情况，例如骚扰、歧视或暴力，就要打破保密的原则。 与管理者们合作：直属经理会在显性（绩效考核）和隐性（日常谈话）的层面上影响团队。需要与管理者同步工作思路。 创造一种积极的氛围：不要把人当作一个亟待解决的问题，而要看做一个有希望、有梦想、有需求的活生生的人。每个人都在通过自己的能力和拥有的资源尽全力来达到最好的结果。 三个支点：专业，尊重，坚持不懈。 一对一指导谈话 谈话首先要诚恳。 然后要真实切实。不真实的谈话，对个人和公司来说都代价昂贵。 一旦开始谈话，就要顺其自然。思考指导对象处在哪个阶段，应设定什么目标和路径。 可以主动发起谈话，开场白可以是观察式（观察到了什么）或邀请式（邀请团队成员评估当前状态）。 时刻记住你的目标：帮助每个队员在他们的敏捷之路上不断提高。 在谈话的开始阶段，需要认认真真做一名倾听者，才能听到真实的问题。被指导对象开口，就是成功的一半。 在谈话的中段，通过一些有影响力的问题来引起被指导对象的反思。要注意教练在谈话过程中要回避的事情：解决问题。只有被指导对象自由选择的结果才是最有意义的结果。 在谈话结尾时，讨论下一步应该采取什么具体行动，帮助被指导对象更加可靠地完成今后的工作。这种可靠应当是自愿的，确保他切实承担自己应该承担的责任。 不要显得教练的地位是高于被指导者的。在整个谈话的过程中，教练与被指导对象应该始终处在平等的地位。 你不必非要是某个领域的专家才能指导在这个领域工作的队员，因为你的角色是一名教练，而不是代替他们直接去解决问题的人。 教练要明白自己的界限，例如是否可以讨论工作之外的事，是否要对被指导对象的工作领域提供意见。 对话的线索可以是优化流程和解决问题，并以此调动团队成员的积极参与。 指导产品负责人 教练与产品负责人之间谈话的唯一目的是为了确保团队的健康成长，而与个人恩怨和办公室政治毫无关系，这种专业精神和对自己角色内容的澄清能够赋予你更多的正式权力。 指导产品负责人做好自己的本质工作。摆脱命令与控制的工作方式，专注于商业价值的达成，而不是去具体管理每个团队成员的下一步行动。 帮助产品负责人建立以商业价值为导向的思想体系，请产品负责人以商业价值为导向，重新审视整个产品开发流程，并以商业价值作为他们制定每一个决策的基础依据，对优先级按商业价值排序。 指导产品负责人成为为团队着想的优秀产品负责人。帮助团队和产品负责人从失败中学习，一起改正错误，然后变得更加强大。 回归根本，参照 Scrum 指南和前面章节，理清产品负责人在 Scrum 中应有的职责和行为。 指导产品负责人的时机，可以以 Scrum 流程为线索，在其中寻找产品负责人的发力点或乏力点。 指导敏捷教练和 Scrum Master 让他们观察和探索，你作为敏捷教练如何工作。让他们自己客观冷静地作出自己的决定。 如果他们决心成为一名敏捷教练，开始教学。让他们了解敏捷教练这一角色的全部含义：指导整个团队、指导特定个人、教授敏捷思想、协助敏捷会议，以及通过谨言慎行来把握自己。 然后逐步向这位新教练转移指导工作。第一个月让他看你怎么做，第二个月你看他怎么做，第三个月，你只指导这位新教练而不再干预团队。 回归根本，参照 Scrum 指南和前面章节，理清 Scrum Master 在 Scrum 中应有的职责和行为。 指导 Scrum Master 的时机，可以以 Scrum 流程为线索，在其中寻找 Scrum Master 的发力点或乏力点。 指导敏捷经理 在团队管理方面的指导：将团队的自组织能力和经理们的有效领导相结合。 在投资管理方面的指导：让团队从以计划为导向的思维方式转化到以价值为导向的思维方式。 在环境管理方面的指导：在由各种流程和外部资源组成的组织环境中，高效地审视组织内各流程的设计以消除各种对组织资源的浪费。 依然以 Scrum 流程为线索，寻找与敏捷经理的交互点，进行指导。有问题就是契机，没问题反而无处下手。 第二剑：协助本部分关于协助会议的检查列表，不是对会议基础知识的重复，而是假定您已经掌握了会议的基础知识之后，如何以运用基础知识为基础，把协助会议这件事做好。 您在协助每个会议之前，需要重温前面章节中会议的基础知识，加上本节的一些技巧，制定出自己的详尽完备的会议议程和脚本。这一点是关于功夫在会前。另一点是功夫在会外，会议日程的素材来自日常的观察和收集。运筹帷幄，才能把会开好。 协助每日站会 强调站会的规则：15分钟，三个问题，杜绝超长时间的讨论。 强调规则之后，停止干预，重点放在观察上。 在站会之后，征得团队同意，提供观察和见解。 把一些轻微的违规行为留到回顾时再进行解决。 训练让团队自己启动站会。比如说到了时间准时开始，不等人，让迟到的人感受到团队之车运转的压力而不再迟到。 一旦15分钟到了，宣布站会结束。 站会期望获得的效果：产生健康的同侪压力、细粒度的协作、同时聚焦少数任务、每位团队成员每天都需要对团队做出承诺、提出障碍。 对于什么时候修正站会中的问题，什么时候不做任何处理，做出审慎的决定。当前做法是否影响到团队的自组织能力，是判断的基线。 解决站会问题的方法之一是强调站会希望获得的效果。 另一个方法是要求眼神支持，即当一个人在站会中发言时，其他团队成员都要直视发言的成员，进行眼神交流。一次一个焦点（任务、对话）。 为团队创造空间并在回顾的时候把问题提出来，而不是马上寻找其他方法去解决问题。 还可以采用一对一指导。 找到低效的站会与付出的代价之间的因果关系，并让团队知道。 要有耐心，并且坚持从多角度尝试。 协助迭代计划会议 当我们可以回答这些问题时，迭代计划就完成了：迭代目标是什么？团队构成是什么？总人力投入是多少？具有最高商业价值的待处理事项是什么？对于这些待处理事项的顾虑（技术的、政治的、文化的）是什么？团队还有什么其他顾虑？团队对本迭代的最终承诺是什么？ 当我们达到这些目标时，迭代计划就完成了：了解工作—理解它、选择它、把它任务化、志愿完成它，获得一个全新的开始，为共同目标做出承诺，创建重点和充裕感。 为迭代计划做准备：确保 PO 已准备好待处理事项，Scrum Master 准备好会议结构。 在迭代计划期间的协助：介绍会议的结构，包括会议的时间盒。 在迭代计划会上可教授的时机和发力点：专注于交付的商业价值、强化 PO 作为产品愿景和决策的唯一声音、维护健康的角色边界、利用思维导图和静默任务分解改善会议的进程和共同的理解。 协助迭代评审 在即将进行迭代评审前，提醒团队把做过的所有任务整合在一起，并演示当前迭代开发的真正产品。 不需要完美展示，只需要真实展示。更多的时间花在真正的工作上，而不是让事情看起来更好看。 评审的目标：展示承诺中什么完成了和什么没有完成，获得干系人和客户的直接反馈，介绍团队是如何一起工作、处理挑战和解决问题的，针对一些大的障碍向干系人寻求帮助。 按价值第一的原则发言，一是先讲重要的事，二是要考虑为什么这个功能对用户有价值。 教练以观察为主：团队是如何进行互动和互助的？团队与 PO、干系人、客户的互动是怎样的？PO 是否以产品待办列表作为管理需求的方式？有没有人被欺压或者被强制沉默？会议是否在同一时间有一个焦点并保持流畅？对话中有哪些对敏捷的误解和误用？ 跟团队分享你的观察。 观察有两种：加强的观察即哪些行为加强了敏捷的理念和实践，深化的观察即揭示团队的内部工作方法的特质。 协助回顾会议 回顾的目的：检查并调整，回头看团队是如何一起把工作做完而不是产品怎么样，以及怎样才能下次做得更好。 教练在日常观察到的问题，重要的问题可以即时提出，其他问题可以留到回顾会议时提出。 教练在日常观察和思考的问题：团队是否使用敏捷框架来促进协同？团队正在忍耐什么？工作流是否顺畅？彼此的沟通协调关照关注和协作有什么不足的地方？出彩的瞬间是什么？哪里进展慢？整个迭代期间，团队的焦虑程度如何变化？大家是否全身心地参与进来？兴奋程度何时和如何变化？ 可以从对观察的提炼中找出回顾的主题，也可以事先通过与团队和 PO 沟通获得回顾的输入。 议程的基调是关注重要的事情。 回顾会议要遵守时间盒。 一旦达成付诸实践的协议，就写下来，并张贴在显眼的位置。 回顾会议之后，观察协议是否被执行，并为下一次回顾会议收集意见。 分享因回顾而带来的收益。 协助团队对话 教练的关注在对话的质量而不在对话的内容。 在高质量的对话中，每人都发言，认真听其他人发言，从对话中涌现出许多想法，这些想法又互相催化产生一些新的想法，把每一个想法当作一个礼物并一直向前推进。 教练在对话中强有力的观察：是不是每个想发言的人都得到了发言的机会？这些想法是高质量的吗？团队是不是尽可能采用简单的想法？团队是不是疲劳了？团队是不是很紧张？团队是否足够大胆而不墨守成规？他们是不是尽可能多地完成工作？是否以客户价值为中心？被卡住了吗？是否有新的视角？ 择机分享观察和思考。 教练提出强有力的问题：还有什么地方不清楚？可能性是什么？想要探索的是什么？还有哪些角度可以考虑？如果可以自由选择，你会做什么？这件事的实质是什么？这会让你得到什么？你预想的是什么？对于类似情况，你最好的经验是什么？主要的障碍是什么？最大的顾虑是什么？机会和挑战是什么？ 教练提出强有力的挑战：放大他们的想法，带到一个全新的方向，高标准，打破局限。 第三剑：讲授讲授、指导和协助三者的关系是：在团队启动或迭代启动时进行讲授，在会议和对话中进行协助，为了保证讲授的理论能够落实以及能够以贴合团队实际情况的方式落实，需要对团队和个人进行指导。通常来说，讲授会发生在迭代启动时，协助发生在每一次会议和对话，而指导会根据实际情况发生在任何时刻。 这一节还包括了对不同角色的教授，其内容是对不同角色基本职责的补充。教授的时机依然可以是以流程和解决问题驱动，在流程和解决问题的过程中寻找教授的时机。 在团队起步时的讲授 这种时机只会出现一次，并且一去不复返。 强有力的团队启动在一两天内就可以完成。 启动期间要解决的问题：学习将要使用的流程，了解团队，了解将要做的工作，前进！ 在启动期间，重点关注面向任务而不是面向人的事情，更容易成功。也就是，更多时间放在学习流程和了解将要做的工作，较少时间放在了解团队。 学习流程：对于从未接触过敏捷的团队，是真正意义上的新开始。对于已经用过敏捷的人，他们自认为了解敏捷，但可能受制于之前所在团队的模式和局限，实际上已远离敏捷，教练需要向他们刷新可信的敏捷，重回敏捷的核心。 了解团队：从了解团队中的每一个人开始，然后创建一个共有的团队特征。 作为个体相互了解：可以让每个人描绘自己的职业历程，画出来并分享；可以让每个人展示自己的技能，其他人提供我可以如何帮助你和你可以如何帮助我的反馈；可以以星座为载体让每个人陈述自己的偏好；可以让每个人从一组价值观中选取重要的，并进行交流。这些活动是为了在团队成员之间建立深刻的理解。 创建共有的团队特征：创建共同的团队愿景；创建团队规范。 了解将要做的工作：展望产品愿景，评审产品待办事项，创建第一个迭代的目标和计划。 团队启动的三个层次：一是按上述框架设计启动议程，二是了解并满足主要合作者的目标，三是深入了解每个人的情况并设计有针对性的启动。 教授团队的新成员 有可能的话，保持团队稳定。 当一位团队成员离开时，确保团队对他的贡献给予答谢。 当一位成员加入时，向他介绍团队，团队规范，团队如何使用任务板合作完成迭代目标，团队的愿景。 向新成员教授敏捷。 让已有成员向新成员介绍产品。 定期了解和跟进新成员在敏捷实践中的进展。 教授产品负责人 产品负责人是价值推动者。产品负责人的任何决定，都要考虑是否给公司带来最大价值。 产品负责人要经常与团队在一起，以便在需要时作出日常决策。 产品负责人是愿景管理者，要帮助团队了解愿景及确保每一个迭代都是朝愿景推进。 产品负责人要保护团队免受外界的噪音和压力。 产品负责人是最终责任人，为产品的业务成果负责。 产品负责人要对工作作出承诺，并充分参与。 产品负责人要得到项目发起人的授权。 产品负责人要与各方协作。 产品负责人要对所从事的领域有渊博的知识。 了解并沟通团队对产品负责人的期望。 定期与产品负责人交流，哪些方面做得好，哪些方面还可以提高。 教授敏捷经理 敏捷经理包括团队成员的职能经理、利益相关者和其他团队的经理。 敏捷经理身受双重的挤压，一方面是团队自组织管理的挤压，另一方面是高层想要看到进度表和状态报告的挤压。 当他们看到团队交付成果时，他们所受的挤压会被减轻。 敏捷经理可以是组织变革家，引导组织对敏捷的采用。 敏捷经理可以是边界管理家：强化健康的角色边界，包括团队内部和团队之间。 敏捷经理是价值最大化的倡导者：管理项目组合。 敏捷经理是精益管理者：使用精益思想来管理组织流程，加速流动，减少浪费。 敏捷经理是组织障碍消除者：以坚忍不拔的勇气来消除根深蒂固的障碍。 敏捷经理是团队拥护者：信任和支持团队，让他们发挥潜能。 敏捷经理可以通过产品负责人把工作项加到待办列表。 敏捷经理可以把观察到的问题交给敏捷教练。 敏捷经理可以参加站会，但要保持安静。 敏捷经理可以参加迭代评审并给出反馈。 敏捷经理在得到请求时帮助移除障碍。 教授敏捷教练 敏捷教练是清道夫，帮助移除障碍。 敏捷教练是领头羊，引导团队回归敏捷的实践和本质。 敏捷教练是服务型领导，帮助团队更好地工作。 敏捷教练是质量和成果的监护者，检查并调整团队生产什么和如何生产。]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷教练和 ScrumMaster</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷教练和 ScrumMaster</tag>
        <tag>敏捷教练的六脉神剑</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[敏捷教练第6课-技巧-敏捷教练的四种心法]]></title>
    <url>%2F2018%2F05%2F23%2F%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%AC%AC06%E8%AF%BE-%E6%8A%80%E5%B7%A7-%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%9A%84%E5%9B%9B%E7%A7%8D%E5%BF%83%E6%B3%95%2F</url>
    <content type="text"><![CDATA[敏捷教练的职责是帮助组织做得更好。为了履行这个职责，首先是做好前面几章介绍的知识储备。其次是运用这些知识影响组织，也就是下一章开始讲的教练的六种方法。在进行教练之前，敏捷教练需要做一些自身的在敏捷知识之上的内在准备，也就是四种心法： 内建能力 更高标准 自我掌控 灵活变通 心法一：内建能力在敏捷开发指导过程中，对团队影响最大的其实是教练本人的内在品质和行为方式，而并非任何外在的具体的技术或者意见。教练的一言一行无不体现出其内在品质和对敏捷主要观念的理解。通过内在品质的体现，可以给个人、团队和组织带来深远而持久的影响，比照本宣科式刻板地执行敏捷思想中的具体的技术有更加深刻的意义。 敏捷教练的定位 一个能够准确掌握敏捷开发实践和理论中深层次内容，并且能够帮助团队理解这些内容的人。 一个面对过巨大挑战、内部阻力，并且能够在需要时为经理们或者其他团队的人员提供指导的人。 一个能够帮助组织内各级管理层去深刻理解有效的敏捷开发能够为日常工作带来哪些好处的人。 一个能够从专业辅导、冲突管理、矛盾调解、剧场表演等相关学科中引入新的观点和理论，从而让自己团队的表现不断提升的人。 既关注在复杂而又变幻无穷的世界中创造出有意义的产品，也关注为参与创造的人们的职业生涯带来更多益处。 敏捷教练应该克服与改变的方面 对照下面“应该做到的”一起看 协调个人对团队的贡献。 做一个领域专家。 把精力花在追求特定产出上。 自己知道所有问题的答案。 自己全权管理整个项目。 推动。 注重截止日期和技术路线的选择。 注重行为的最优性。 亲自解决问题。 工作总能很好地计划，计划总能很好地被实施。 项目三要素可以相互调剂和妥协，以应对未知的突发情况。 随着需求、设计、开发、测试阶段的推进，可预测性越来越高。 准时和在预算内完成目标就是成功。 项目的范围可以事先锁定。 从头到尾控制整个项目的进程。 完成阶段性目标和任务是工作价值的度量。 敏捷教练应该做到的方面 指导整个团队进行协作。 充当团队的协助员。 把精力花在提升团队的整体表现上。 让团队自己寻找答案。 让团队自己寻找途径。 指导。 注重商业价值的达成。 注重于每时每刻都做有利于业务发展的事情。 将问题交予团队。 提前计划并不可少，但确定的计划并无用处。 时间和预算不变，范围可变。 随着时间推移，计划不断被修正，因而越来越准确。 客户获得的商业价值是成功的标准。 项目范围保持灵活，任何变化都可接受。 以团队贯彻敏捷思想来控制进程。 可工作的软件才是价值的度量。 敏捷教练的内在品质 能够读懂一个房间的空气中蕴含的情绪，并判断出是否一切正常。 关心人胜过关心产品，让团队成员感受到自己受到关心，自己的成长得到支持，进而团结一致，创造出卓越的产品。 不断培养自己的好奇心，清楚地意识到自己的疑惑在那里，不会主观揣测他人在想什么，及情况形成的原因，而是会如实发问。 相信人之初性本善，人的内心总有善良的一面，不过可能被客观情况耽误了，接受他们目前的状况，并尽可能帮助他们成长。 不是固执地执行事先制订的计划，而是时刻与团队一起解决新出现的问题。 有着学习的渴望，知道自己还需要不断成长和提高。 相信只要给予一个大胆的目标和一个成长的环境，任何一组人都能把事情做好。更高的目标值的追求。 不容忍人们为不求上进寻找的各种借口。例如：我们一直是这样做的。 相信预期之外的情况一定是会出现的，而混乱只是达到更好情况的必经阶段，做好应对混乱的准备。 愿意承担犯错的风险。承认错误，承担责任，但不会纠结于此。 形成个人特色 找到自己做敏捷教练的独特风格。 不断实践和总结。 把从本课程中学到的东西用自己的方式消化，然后指导团队。只有自己最熟悉自己周围的环境，也只有自己最了解自己。 对环境和自己要充满信心，不偏安一隅，勇于挑战自己，通过指导敏捷开发团队的工作来实现自己的成长和成功。 心法二：更高标准把高绩效作为自己的期望标准，并帮助团队去实现它，这些都能给你以重要而强大的动力。如果可以随时保持雄心勃勃，那么每个人都能获得最后的胜利。公司或组织不仅获得了更好的成果，还拥有了无所不能的团队。团队及每个成员则获得了更多自主权，掌握了高超的技能并实现了自己的目标。每个人都能从高绩效中受益。 设定高标准： 设定高绩效仅仅表明你相信高绩效是可以实现的，你相信团队能够实现这一目标。 需要用自己的信心激励团队朝着能共同达到的愿景而努力奋斗。 高绩效无关乎是否到达某一特定状态，而是一段通往更高目标的旅程。超越一切合理的期望，甚至对自己的进度感到惊讶，不断保持进步。 为帮助团队开启通往高绩效的旅途，需要为团队设定将要实现的目标期望。 接下来，指导他们迈出第一步，以及以后的每一步，并一步一步地朝着那鼓舞人心的高绩效的目标前进。 你首先需要先让自己产生一种对这段旅途期待向往和兴奋的感觉，然后再把这种感觉传导到整个团队中去。 高绩效是没有终点的旅途。 一旦开启高绩效之旅，就会有各种各样的障碍出现，团队要为他们能够彻底地快速地从挫折中恢复过来感到自豪。让高绩效成为他们对自己的期望和信心，支撑他们挺过一个又一个难关。 高绩效的隐喻之高绩效树 用高绩效树帮助团队描绘高绩效期望的愿景。 当出现问题或不足时，将它作为一种研究问题的方法。 高绩效树的树根：Scrum 的价值观 承诺：愿意对目标做出承诺，Scrum 会为人们提供兑现承诺所需的所有权限。 专注：做好本职工作，把所有精力和技能都专注在自己承诺的工作上，而不要因为任何无关事情分心。 公开：Scrum 中与项目有关的所有事情对大家都是公开透明的。 尊重：不同的背景和经历塑造出不同的个体，但是有一点很重要，那就是，我们需要对团队中不同的人保持尊重。 勇气：要有承诺的勇气、付诸行动的勇气、敞开心扉的勇气和期望得到别人尊重的勇气。 高绩效树的树根：还可以使用 XP 的价值观 沟通：只有通过很多实践才能保持正确的沟通，而这些实践又必须通过相互沟通才能完成。 简单：做简单并且只需要稍微改动就可以重用的事情。 反馈：对系统当前状态的真实地具体地反馈是非常宝贵的。 勇气：有勇气去开发高质量的软件，即使这意味着需要删除原有的代码，改变原有的设计方案甚至是延长开发周期。 高绩效树的枝叶：高协作和高绩效团队的特征 他们是自我组织起来的，而不是根据角色和头衔来组织的。 他们有权做出自己的决定。 他们坚信，作为一个团队他们可以解决任何问题。 他们致力于追求整个团队的成功，而不是为了个人利益不惜一切代价。 他们对他们自己的决定和承诺负责。 是信任而不是恐惧和愤怒在激励他们。 他们是多数人意见驱动的，并做到求同存异。 他们会不断提出富有建设性的反对意见。 高绩效树的果实 实现正确的商业价值。 更快地实现商业价值。 取得惊人的成果。 无所不能的团队。 团队和个人的成长空间。 高绩效树的用法 画在团队工作的地方，默默地提醒团队成员，高绩效是一件很自然的事。 当团队遇到麻烦或墨守陈规的时候，指着它说，我们的根系薄弱在哪里？ 当具备了高绩效团队的特征，产品却不尽人意时，可以说，你们现在想收获什么果实？ 当以这种方式来使用这棵树时，你的问题就变成了他们的挑战。一旦团队接受了挑战，就离该绩效目标又近了一步。慢慢地，他们就会走出一条属于自己的路。 如果一个团队对自己的工作质量感到不满，他们可能是没有做到多数人意见驱动，而过早地采用了第一个出现的可行方案。就在多数人意见驱动上画一个圈。 当迭代目标没有完成时，可能是因为分心的事是团队忘记了承诺，团队可以约定，从现在开始，互相帮助，排除干扰，真正全身心投入，完成承诺的工作。 最好是别为团队指出一条路，而是让他们去开创一条属于自己的路。 当团队把高绩效树当作自己选择的通往高绩效目标的道路时，这棵树就已经在团队中落地生根了。 高绩效的另一比喻：打好基础 经验论：从一系列短时间内发生的失败中汲取教训并最终取得成功。 自我组织：最了解问题本质的人最清楚该如何解决问题。 协作：培养一种“是的，然后呢？”的思维方式。 优先级：专注，做优先级最高的那件事。 节奏：深呼吸，然后顺其自然。 心法三：自我掌控个人的自我调节可以促使你成为团队所需的那种教练，但这往往不是一天两天能够做到的事情，而是一个漫长的反复的过程。这里面需要持续的剖析实践和不断地提高改进。 从自我剖析开始 明白自己在一些特殊情形的自然反应以及自己的底线，有助于认识自身的现状和将来可能会变成什么样子。 下一步是不断挑战自己的极限，不断找到和提升自己的短板。当你很紧张浑身不自在的时候，就是找到自己短板的时候了。 在这些情形之下，要有意识和自觉地面对自己的缺点，多花些时间做自我剖析和反思。 在这个过程中，还能认识到自己的本能行为，并有意识地在事情发生时选择自己本能或其他不一样的行为。 你本能的冲突应对模式是什么？ 竞争型：强硬且不配合。 合作型：强硬但配合。 妥协型：一般强硬和一般配合。 顺应型：配合且不强硬。 回避型：既不强硬也不配合。 你的沟通方式有多强硬？ 你是否每天会花些时间静下心来反思自己是如何和他人相处的？ 你是否记得所有人都有一样的需求？ 在你每次开口之前，你是否确认过把他人的需求和你的需求看得同等重要？ 当你让别人做事情时，你是否确认过自己是拜托的语气还是要求的语气？ 你是否倾向于告诉他人你希望他做的事情，而不是倾向于告诉他人你不希望他做的事情？ 你是否倾向于告诉他人你希望他采取什么样的行动来帮助他们完成目标，而不是仅仅告诉他人你希望他完成什么样的目标而已？ 你是否在提出同意或反对他人的意见前，尝试站在他人的立场换位思考一下他人的感受和需求？ 你是否在说不之前，想过是什么原因导致你不能说是？ 当你感到沮丧时，是否会问自己问题出在哪里，以及自己应该如何解决，而不是去怨天尤人？ 当别人做了件令你感到满意和高兴的事情时，你是否对别人表示感谢，且告之具体解决了你哪方面的需求，而不仅仅是一句简简单单的赞扬之辞？ 你能做团队的公仆吗？ 关于怎么培养自己的团队：定要确保优先满足团队成员的最高优先级的需求，你所提供的帮助和服务能够帮助团队成长和发展吗？ 关于倾听和给他人提意见的权利：自然地在回答任何问题之前先把别人的话听完。 关于认可其他人：尊重团队并认可他们取得的每一点进步。 服务型教练：帮助团队成员成长和进步，只有团队中的一个个个体变得强大了，整个团队才会强大起来，才会被激发出更多更好更有创意的想法。 你的应对方式聪明吗？ 你是如何应对矛盾冲突的 如何和团队沟通 是否做到了服务型教练 如何控制自己的情绪反应 摒弃命令加控制的方式 不要纠结于结果：给团队足够大的空间去提出最好的想法和开发出最好的产品。 把问题留给团队：无论是产品本身还是团队合作上出了问题，解决问题的最佳人选都是团队。 充当一面镜子：将自己所观察到的事情，以不夹杂个人意见的方式讲述给自己的团队。 留意自己的用词和表情：学习说话时不附加自己的判断，学习无暴力沟通。 习惯沉默：习惯那些不舒服的沉默和安静，让团队的其他人有说话的机会。 学着不讲情面：不把向来是这么做当作正常。 允许团队失败：一起经历失败，并一起从挫折中走出来的团队会比那些一直被保护着的团队更坚强和更高效。 做团队最大的粉丝但要谨慎：团队表现得好是因为他们是一个团队，但不要做出空谈式的赞赏。 自我掌控的日常实践 听一些可以舒缓心情的音乐。 读一些能带来灵感和启发的书、博客、名言警句。 慢跑，然后静静聆听大自然的声音。 写下三件你很感恩的事情。 做做瑜珈或者伸伸懒腰并深呼吸。 认可自己，享受当下生活的分分秒秒。 将你的电脑密码和你的当下工作联系起来。 只关注你所关心的 只关心那些你真正关心的事，放下不必要的焦虑。 如果你真正关心的是团队能否针对那些对他们自己有影响的事情发表看法，那么你要做的所有事情，就应该围绕着帮助团队去发表自己看法这个出发点。 一个有效的方法帮你弄清楚你真正关心的事情到底是什么，就是寻找这个问题的答案：我怎么才能为团队做出最大的贡献呢？ 保持关注一件你所关心的事，舍弃很多无关紧要的事。如同产品列表，你只能选择一件你最关心的事作为紧急事项。 时刻记住你真正关心的事情是什么，并保持对它的关注。 做好当下的事情 面对各种难题和不舒适的环境时，也要管理好自己的情绪，放开自己的心态，控制主观情感，选择最为恰当的应对方式。 有时，团队需要你表现得更加直率，这样他们才能看清你对刚刚发生的事情的真实反应。 你把团队看作日常工作中所不得不面对的障碍，还是和你一样有希望、梦想、恐惧和志向的人？ 只要一点点时间，我们就能分辨出我们是否受到敌视，被控制或者被愚弄。我们总能分辨出伪善。真实心意重于应用技巧。 把你遇到的人当作活生生的人来看待，这样才能真正扩大自己对团队的影响力。 多练习分辨自己对各种突发的自然反应，并熟练应对。通过学习特定的听、说和待人接物的方式，来锻炼自己这方面的技巧。 将周围的人都当成活生生的人看待，辅以从这些练习中得来的技巧，你就能很好地控制自己当下的心态了。 练习倾听 层次1：内心收听。非常认真地听着对方的话语，但是听到的每一句话其实都经过自己的重新解读。听到的每一句话其实都在回答自己心中的这个问题：这会如何影响到我自己。而这时回答问题时，往往会专注于展示自己的专业度，而错失了对真正问题的理解。 层次2：专心收听。听者和说者已经建立了切实的联系。听者设身处地地为说话人着想，专注于话语本身。摆脱了自身利益的束缚之后，就能听到问题本身，并据此作出客观无我的回应。或者保持沉默，让说话人能够自由地表达自己的想法。不会主观臆断或者带着自己的利益去片面理解说者的话。保持好奇心，探询问者的情绪。 层次3：全心收听。结合当时环境中的每个因素来真正收听每句话。在层次2中的切实联系仍然很强烈，再加上对每个细节的全面把握，就能对双方谈话的内容产生很多直觉层面的想法。双方都对所谈论的问题有了更深的理解。保持开放的态度，时刻提醒自己：你真的不知道他下一句是什么。 练习说话 当你有想说话的冲动时，审视一下自己，你的立场在哪里。为什么你要在此时有这种想法。不要只是为了显示自己是一个聪明人或者希望在团队面前表现自己的价值。你的价值不在此。 每次想说话时，确认自己的立场是基于为团队成员考虑。确保你每句话的目的,都是为了帮助他们成为一支更加优秀的团队。 不要马上开口。先从1数到10，在数数的时候，密切留意是不是有人说出了与你相同的想法。如果每有人说出你想的，那么再等一会儿，判断一下自己的想法是否仍然和谈话有关，并且是有帮助的。如果是，就简单明了阐述自己的想法。你要相信，谈话总是会沿着参与人的真实需求往下发展的。 缄口不言。当团队成员提问时，不要做第一个回答的人。用了这个技巧，你可能根本不用再回答了。当你是提问人时，如果无人回答，这个时候，你最恰当的方式是表现出你其实很安于这种令人不安的沉默。就大大方方坐在那里，不要求他们必须发言，但要维持眼神交流和邀请。总有人会说话。 练习融入团队 让自己融入当下，并调整自己的立场。 融入当下，意味着此时此刻，你全部的注意力和精力都集中在一处，对此时此刻完全专注，不畏过去，不畏将来。 对各种现象不满的杂念极易让人分散精力，使我们偏离于融入团队现在的关注点。 但真正融入当下时，就会发现团队当下真正的关注点在哪里，帮助他们用一种更加富有建设性和正面态度的方式成长。 通过全神贯注，磨练心智，你会更加关注当下，而且对自我的认识也会更加深入。 融入当下，你的立场会更加坚定鲜明。你的话语会清晰无误，你的每句话都会掷地有声。你的介入就能切实为团队作出贡献。 融入当下也是团队成员需要发展的一项技能。完完全全关注此时此地，关注其他人，关注目前手上的工作。 判断自己说的话是否对团队有益，适时调整立场，甚至撤回自己说的话。 不断自我提升，自我修炼，做团队的榜样。 心法四：灵活变通随着时间的推移，我们会面临不同的环境和不同的团队发展阶段。针对团队的不同阶段，要有不同的做法。灵活变通是敏捷教练的必备。 敏捷团队的发展阶段 守的阶段。原封不动地照搬老师所传授的那些招式，没有尝试去理解隐藏在里面的奥秘。一次又一次地反复对着规则模仿。 破的阶段。掌握了基本功之后，花时间琢磨所有事情的本质和真相，对功夫有很深层面的理解，而不止是停留在单纯的重复练习上。这时候可以借助检查和调整来打破规则。 离的阶段。招数已经融入学生的身体。可以抛开形式，但又不违背原则，甚至体现出更深层次的意义和作用。 为了不断超越，我们必须首先完完全全地掌握所有规则，然后才能安全地打破规则，最后创造出新规则。这些新规则不仅遵循隐藏在旧规则里面的原则，还能展现出更深层的意义和作用。 不同阶段的教练风格 守的阶段的教练风格：教学型。清楚了解团队的需要，保持坚定的立场和态度，为团队制定规则和纪律。 破的阶段的教练风格：指导型。随着团队不断从实践中总结，并将实践转化为自己思想的一部分，就不再是被动地遵从规则。教练可以指导团队对既定规则作出修订。 离的阶段的教练风格：顾问型。当团队能够将敏捷开发的实践、价值观和原则融会贯通时，就可以采用顾问型风格了。肯定团队的想法，鼓励他们善于听取别人的意见，善于交流彼此的想法，勇敢地面对各种困难，以及尽可能将事情简化。 在每个阶段，都需要深入了解团队，了解每个团队成员，以及整个团队的情况，帮助他们找到适合自己的对敏捷思想的解读。 对团队守破离状态的判断 团队对敏捷思想是否比较陌生？ 团队是否改变或干脆放弃了敏捷开发的实践行为模式，并忘记了这些模式背后所蕴含的思想？ 团队是否在刻板地照搬敏捷思想中的条目？他们是否能站在个人与集体、所开发产品、客户需求与不断应对变化的角度来思考问题？他们是否能顺畅地进行日常工作，并且从实践中不断获得自我提升？ 团队是否能够在保持敏捷思想核心价值观和原则的基础上，对自己的实践方式进行持续改进？他们是否能够冲破自己所在公司的某些既定障碍，来让自己的工作更加高效、更加快速地完成目标，获得更高的客户认可？他们是否具备了实现自我监控、自我修正所必需的技能和思想？]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷教练和 ScrumMaster</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷教练和 ScrumMaster</tag>
        <tag>敏捷教练的四种心法</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[敏捷回顾-团队从优秀到卓越之路“]]></title>
    <url>%2F2018%2F05%2F15%2F%E6%95%8F%E6%8D%B7%E5%9B%9E%E9%A1%BE-%E5%9B%A2%E9%98%9F%E4%BB%8E%E4%BC%98%E7%A7%80%E5%88%B0%E5%8D%93%E8%B6%8A%E4%B9%8B%E8%B7%AF%2F</url>
    <content type="text"><![CDATA[我们之前每个迭代也都有进行敏捷回顾，但是每次回顾很大程度上都变成了一次小的联欢活动，大家吃点东西，聊聊天，然后整理一份会议记录就算是回顾了。这样的回顾虽然起到了调节节奏放松身心的作用，但是对敏捷和迭代并没有发挥它应有的指导功能。之所以会这样，我分析了下，有下面几个原因： 1、敏捷回顾的目的和流程未明确； 2、未指定回顾会议的主持人、主持回顾检视会议的方法未掌握； 3、回顾检视的结果未得到正确的应用。 在读了两遍回顾女神的《敏捷回顾-团队从优秀到卓越之路》后，我们在回顾检视会中遇到的问题一下子都找到了答案。全书共10章，前面三章讲了回顾检视会的目标、回顾检视会策划及主持回顾检视会的几个关键环节。后面7章则是具体解释了回顾检视会中每个环节中具体活动开展的方式和工具。回顾检视会的目标这部分内容纠正了我们以往空而泛的“扬长避短”的目标，而把目标明确定义为：帮助团队检视和调整，更进一步说的是帮助大家定期的改善操作、处理问题和发现障碍。基于这个目的，回顾检视会重点关注的是如何使团队更好地协调的工作。 回顾检视会的结构化流程包含了预设会议基调、收集数据、激发灵感、决定做什么、总结收尾五个环节。 策划和组织一个回顾检视会了解历史和环境 这个迭代开发的输出是什么、迭代目标是什么、目标是否如预期的那样完成了 项目评审历史是什么，怎么进行的又是怎么跟进的 团队成员直接的关系如何、相互依赖关系如何、个人之间的关系和工作关系是什么样子 团队成员的感觉怎么样，他们忧虑和担心的事情是什么，他们对什么事情感觉兴奋 对团队来说，取得什么样的成果才值得话费这些时间 指定回顾检视会目标，有用的检视会的目标包括 寻找改进我们实践活动的方法 探索我们过去做得好的方面 发掘没有完成的任务的背后的原因 寻找改进我们响应客户需求的方法 修复被损害的关系 确定会议时间长度 迭代开发周期有多次时间 复杂性（技术的、与其他部门的关系、团队的组织） 团队的规模 冲突的严重程度或争论的激烈程度 拟定回顾检视会的框架预设会议基调（5%） 3?6收集数据（30%-50%） 20?40激发灵感 （20%-30%） 13?30决定做什么 （15%~20%） 10?20检视会总结收尾 （10%） 6?12活动直接的过渡时间（10%~15%）8?17 选择活动 鼓励大家平等的参与 突出讨论的焦点 鼓励新观点 （为每个活动准备一个备份活动，一长一短，时间紧的话就用短的那个） 主持回顾检视会管理活动作为一名回顾检视会引导者，你可以跟着内容走，但你的首要责任是跟着流程走，流程意味着管理活动、管理小组动态和管理时间。 介绍活动 从询问观察到的时间和感知到的东西开始 询问大家对这些时间和输入是怎么样回应的 询问灵感，并用这样的话提问：“这与我们项目有什么关系” 哪件事件是你能够用不同的方法去做的 掌握小组活动的动态 保证要说话的人有机会说话 让说的太多的人不要占用太多的时间 准备好处理情绪化的互动和情况（引导团队说出自己的感受而不是指责彼此） 要关注整个团队的互动而不仅仅是照顾个人 管理好自己 休息期间做三次深呼吸，问问自己几个问题 刚才发生了什么事 有多少是我意料之中的，有多少是意料之外的 怎么会走到这一步呢 下一步该怎么走 我有哪三个选择呢 我能为小组做些什么 预设会议基调为团队在回顾检视会活动中要做的事情做准备重温目标重温议事日程签到找到四五个情绪化的字眼如：高兴、生气、忧虑的、沮丧的和充满希望的，每名团队成员用这些字眼表达自己签到时的情绪状态当工作中存在冲突或挫折的时候，用这种签到的方式表达自己的情绪，也是寻求认可的一种方式ESVP 每名与会者匿名汇报他作为探索者（Explorer），采购者（Shopper)，度假者（Vacationer）或囚徒（Prisoner）–对回顾检视所持有的不同态度 把白板纸给大家展示看并且定义术语： 探索者渴望新的注意和灵感，他们想学好所有可以学到的有关迭代开发、版本发布和项目的东西 采购者会研究所有能得到的信息，然后高兴的把一个有用的新观点带回家 度假者对回顾检视会工作并不感兴趣，只是离开无聊的日常使他们很开心，他们不会一直把注意力都放在回顾检视会活动上。 囚徒们觉得他们是强迫来参加回顾检视会的，如果让他们选择，他们宁愿去做点别的事情。 重温工作协议目的简历一套支持团队进行有效讨论的行为规范，使团队成员有责任彼此监督他们的互动。 所需时间 一般需要10~30分钟 说明团队成员一起为工作中的有效行为出主意，然后选择5~7条协议指导团队行动和工作流程 收集数据的活动制定时间表目的刺激大家的记忆，让大家回忆在增量工作中发生了说明，从多个视角画出一副工作图画，逐项核对检查何人何时做了什么工作，以便从中发现模式或团队能量的变化。 所需时间基于人员及工作增量的多少，需要30-90分钟 说明针对迭代周期、版本或项目，每名成员把自己认为重要的事件写在卡片上，并按大概视角顺序把它们贴到白板上。回顾检视会主持协助大家讨论每个事件，使大家了解项目进行过程中的事实和情绪感受。变化形式 用颜色代码来收集事实和感受，用不同颜色代表不同的感情 蓝色：悲伤，愤怒，坏 红色：挑战，停滞 绿色：满意，成功，积极 紫色：快乐，惊奇，幽默 浅橙色：疲惫，紧张 事件颜色代码用不同颜色代表不同类型的事件 黄色：与技术有关的事件 粉色：与人员和团队相关的事件 绿色：与机构有关的事件 部门颜色代码用不同的颜色代表不同部分的事件 蓝色：开发 粉色：客户 绿色：QA和测试 黄色：技术文档 用主题颜色代码不同的主题 黄色：团队沟通 蓝色：设备使用 粉色：客户关系 绿色：工程实践 3个5活动目的挖掘项目过去的重要活动 所需时间30~60分钟 说明 把成员分为小组，每名成员有5分钟时间开动脑筋并写下了自己的想法。 5分钟结束，每个人把自己的纸条传给右边的人。 下一个五分钟内，每个人基于纸上已经有了的想法写下自己的想法。 重复这个过程直到纸条最终回到自己手中。 ###总结 在写下这些想法时，有什么新的发现 有什么令你感到惊讶的吗？哪些注意符合你的期望？为什么 哪些项被忽略了？ 哪些项和主题应该进一步分析 颜色代码圆点目的展示团队成员士气随时间而发生的变化 所需时间5~20分钟 说明 团队成员用彩色圆点贴在时间表上备注，从而描述自己士气的高或低 给每个人发两种颜色的圆点帖，先给每人7~10枚圆点帖，告诉大家哪种颜色代表士气高昂，哪种代表士气低迷 请每人用圆点来标注何时士气高昂，何时士气低迷 骄傲和懊悔模式（愤怒、悲伤、高兴）目的了解大家的感受 所需时间基于人员的多少，需要20~30分钟 说明 每人用不同颜色的卡片或沾笺来描述不同时间的情绪 提醒大家两个展板分别为 骄傲、懊悔（愤怒、悲伤、高兴） 说明如何进行，并给出时间限制 请用XX分钟考虑在本迭代项目中，什么时候在哪个事件让你感到骄傲、懊悔（愤怒、悲伤、高兴）；每张卡只写一件事。并注意字迹工整。时间结束时，请大家把卡片贴袋对应的展板上把所有卡片分类，问大家这两张卡片说的是不是同样的事。大家会告诉你哪些开票是类似的。直到把所有的卡片分类。 小结讨论当你读这些卡时，哪些最引入注目哪些事出人意料，这项任务的困难在哪里？哪部分让人感到积极和正面？在这些分类中可以看出什么规律？这些规律对我们有什么意义。基于以上这些情况，下一步我们应该做什么？ #激发灵感的活动 头脑风暴和筛选目的先让大家想出许多主意，然后按照实现定好的尺度进行筛选 所需时间 40~60分钟 步骤用下面三种方法之一进行头脑风暴活动 自由式，大家随机去想 循环式，转圈传递令牌，拿到令牌的出主意，如果这个没有想好可以放弃机会，将令牌传给下一个人。 给大家5~7分钟独自安静的思考，并讲想出来的注意写到纸上。 问大家应用什么样的标准进行筛选，选出4~8个建议进行讨论，然后对最好的4个顾虑标准拒收投票，并发结果写出来。请大家对筛选出来的意见进行评论，问问大家想推行哪些想法，问问是否有人强雷要求对其中任何一个想法负责实施。带着这些筛选出来的意见，进入下一个阶段，角色改做些什么 力场分析法目的分析研究哪些是支持所倡导的变革的因素，哪些是阻碍所倡导的变革的因素。 说明整个团队定义出希望达到的理想状态的情形。各小组找出促进和阻碍他们想要的变革的因素，把找出来的这些因素列在纸上，然后，集体分析各个支持和阻碍变革的因素直接的强弱关系。最后，全体讨论哪些因素是大家可以施加影响的–通过强化支持因素或者通过削弱阻碍因素 5个为什么目的发现潜在的导致问题的条件 说明团队成员两人一对或分成小组研究问题，用多次问“为什么”的方式超越习惯性思维方式 步骤 用“我们已经知道发生了什么，现在让我们来看看为什么会发生这些事情”这样的话来开始活动。 回顾整个团队找出来的所有因素和题目 分组后讨论 由一个人提问，为什么一件事或一个问题会发生 针对所得到的答复继续问为什么。 将问了四五次“为什么”之后所得到的答案记录下来 掌握好时间，到点叫停 各个小组报告结果 鱼骨图目的观察过去的问题症状进而发现问题的根本原因，寻找问题和故障背后的根本原因 时间30~60分钟 说明团队找出产生问题的因素进而发现最有可能的原因，然后找到改变或影响这些因素的方式 步骤 画出鱼骨图，在鱼头处写上问题或者现象，已经5个W–什么（What）,谁（Who）,何时（When）,在哪里（Where）,为什么（Why）,在每根鱼刺上标上相关的类别 在各个类别中开动脑筋想出相关的因素，用“这类问题（加入的问题的类别）会导致什么或者会影响到什么”？ 继续问“为什么会发生这个问题” 找出那些出现在多个类别中的条目，这些是最可能的原因 用圆点贴进行优先级排序目的引导小组怎样在一大堆变革、提议等方案中确定实施的优先级顺序 说明团队成员选择优先级最高的问题、想法或建议 ###步骤用下面的话开始活动：“我们有的清单有一大推建议，但是不可能一次做这么多的事情，只能挑出哪些大家认为优先级最高的事情来做。”给每名成员10个彩色小圆贴纸，圆点帖。每个人 给你认为优先级最高的事情贴上4个小圆点贴。 给你认为次优先级的事情贴上3个小圆点贴 给你认为优先级排第三的事情贴2个圆点帖 给你认为优先级排第四的事情贴上1个圆点帖 给几分钟时间让大家把手中的圆点帖放在要排序的是项旁边 数一数每一条目圆点帖数量，把数写在旁边。 在能够看出圆点帖数量多的优先事项时，问大家是不是还要继续下去。 用不同措辞描述同一个一题会得到完全不同的结果 什么是我们工作的重点 哪个事情产生的影响最大 哪个是我们最想解决的问题 学习矩阵###目的帮助团队成员在他们的数据中找出最重要的东西 时间20~25分钟 说明团队成员看一看他们的数据的四个展望（愿景），来一番头脑风暴，迅速列出一份问题清单。 步骤 准备一张白板纸，在四个部分分别以下列图标表示 笑脸 表示说明事情做得好我们就继续做下去不高兴 表示我们想改变说明灯泡 表示出现了新的想法花束 表示我们应到感谢谁 在回顾检视会中，采用四个象限去了解团队的体验 决定做什么的活动回顾规划游戏目的为试验或建议方案制定一个详细的计划 说明团队成员单独或组成双人小组，针对需要完成的试验、改进、建议等进行集体研讨，理清必须进行的所有任务，集体研讨后，去除重负的任务，填补遗漏的任务，并排好顺序，团队成员认领要完成的任务 步骤 单独或结成双人组进行工作，找出所有任务 进行任务对比，去除重复的，添补遗漏的 集中所有的任务，再次去除重复的，添补遗漏的 把得到的所有任务进行优先级排序 哪项任务是必须首先完成的，把需要首先完成的移到工作去最左侧 有没有能与这项任务同时做的任务，把可以同时做的任务放在第一项任务的下面 然后问哪项任务应该接下来做，把那项任务放在第一项任务的右边 SMART目标目的将设想按优先级别转换成行动计划，形成一系列具体，可衡量的行动 所需时间20~60分钟 说明让团队致力建立一些 具体的（Specific）, 可衡量的（Measurable） 有可能达到的（Attainable） 切题的（Relevant） 有时间约束的（Timely） 目标具有这样的SMART特种的目标更有可能取得成果 步骤 通过进行简短的关于SMART目标重要性的讨论引入此项活动 指向写在白板上或挂图上的SMART特征，提出一个具备SMART特征的目标实例 要求每个小组为新方案指定一个SMART目标，确定1~5个实现目标的行动步骤，并监控活动。 问题圆圈目的帮助团队针对下一轮迭代选择一项试验或选择行动步骤。特别是团队成员需要相互听取意见的时候 所需时间超过30分钟，根据小组的规模决定 说明团队成员在参加提问和回答问题的过程中，针对下一个步骤达成一致意见 步骤 要求团队成员围坐成一个圈，介绍活动方式：“有时候找到答案的最好方法就是问问题，我们要通过提些问题，找出我们想要做什么，作为我们在此次回顾检视会中的成果，我们采用转圈回答问题的方法，知道得到满意的答案或者时间到” 转向你左边的人，向他提一个问题，左边的团队成员尽其所知所能，按其观点回答问题，然后转为发问者，向他左边的人就上一个问题继续提问或提出一个新问题。 依次沿圆圈如此反复，知道每名小组成员都对他们的问题被听取和考虑而满意，并取得一致的行动意见为止。 再三品读这本书后，对回顾会议的展开和规划有了进一步了解，同时也明确了检视会的目的和掌握了一定的达成目的的方法和活动。很期待下一次的回顾会议，希望每次的回顾会议能让我们的团队效率更高。]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷回顾</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷回顾</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[敏捷教练第05课-储备-精益体系精要“]]></title>
    <url>%2F2018%2F05%2F14%2F%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%AC%AC05%E8%AF%BE-%E5%82%A8%E5%A4%87-%E7%B2%BE%E7%9B%8A%E4%BD%93%E7%B3%BB%E7%B2%BE%E8%A6%81%2F</url>
    <content type="text"><![CDATA[精益是敏捷的重要来源，敏捷对精益作了继承和发扬。 精益的体系浩繁，本文按4＊2的结构进行介绍，即从思想、方法、模式和工具四个层面对精益进行介绍，并在四个层面分别谈及在敏捷中的体现和运用。最后用三纲八目的结构，总结精益中最重要的三个思想及八种落实的方法。 精益学问体系有四个层面： 思想：是大脑，是思维。 方法论：是在宽泛领域看事情的眼睛。是复眼。 解决方案（模式）：是对特定场景问题的总是有效的解决方法。 工具：是在狭窄领域看事情的眼睛。是单眼。 思想就思想而言，涉及到的人包括： 丰田佐吉、丰田喜一郎、大野耐一作为创始祖师。 詹姆斯沃迈克作为研究第一人。 杰弗瑞莱克作为另树一帜的研究人。 思想的应用者： Scrum 的创始人 Jeff Sutherland &amp; Ken Schwaber。 Lean Software Development 的创始人 Mary Poppendieck。 Kanban 方法的创始人 David Anderson。 LeSS 的创始人 Craig Larman。 SAFe 的创始人 Dean Leffingwell。 在方法论领域的精益大师： 约翰舒克，特别是在 A3 报告和价值流图方面把相关知识显式化的功劳。 精益思想精益学问体系的思想，无法简单描述，就脉络来说，大致三个： 丰田屋或精益屋，经由以大野耐一为代表的创始祖师，和后续发展。 詹姆斯沃迈克的精益思想。 杰弗瑞莱克的丰田 4P。 丰田佐吉、丰田喜一郎和大野耐一等人关于丰田生产方式的思想，反映在丰田屋模型中。屋顶代表的是通过最佳质量、最低成本、最短生产周期和消除浪费来为客户创造价值。底座代表的是管理层对创造价值和消除浪费的长期承诺和支持。两个支柱是自动化和及时化。自动化是关于个人自动自发。及时化是关于团队合作。 渡边昭捷丰田之道2001版的丰田屋模型中，两个支柱演变为持续改善和尊重人。新支柱从概念上来讲，适用的范围更广泛，但也存在丢失旧支柱包含的精神的风险。 Craig Larman 写了一本 &lt; Lean Primer &gt;，将精益介绍到软件界，并使之成为其 LeSS 的重要思想基础。Craig 在书中也总结了一个精益屋，跟丰田本身的屋子模型基本相似，只是在术语上采用了软件开发人员更容易明白的术语。 LeSS 的对手 SAFe 也以精益作为基础。SAFe 的创始人在 SAFe 体系中也使用了屋子模型。这个屋子的屋顶是价值，底座是领导力，跟前几个屋子模型一致。不同的是，支柱变成了四个，在尊重人和持续改善之外，增加了流动和创新。流动和创新也是丰田模式中本有的概念。 精益软件开发的创始人 Mary Poppendieck 从精益中提炼了7个原则，应用于软件开发中：消除浪费，增加反馈，延迟承诺，尽快交付，内建质量，赋能团队和全局优化。 精益软件开发中的一部分思想来自于詹姆斯沃迈克总结的精益思想，这也是精益思想的另一个山头。沃迈克作为精益思想第一人，是把精益介绍给全球的主要桥梁。沃迈克经过对丰田的研究，提出了精益思想五原则：价值，价值流，流动，拉动和尽善尽美。 精益中重要思想“流动”的历史，则可以追溯到1574年亨利三世在威尼斯造船时采用的连续流，经由1799年埃里惠特尼的可互换件，1902年丰田佐吉的自动化，1910年亨利福特的流水线，1950年戴明的统计过程控制，发展到后来的丰田生产方式。 精益思想的第三个高耸的山头是杰弗瑞莱克的丰田模式和 4P 模型。杰弗瑞莱克对丰田的研究，不次于詹姆斯沃迈克，被称为最懂丰田的人。 杰弗瑞莱克丰田 4P 模型及14条原则Philosophy 理念 原则1. 管理决策以长期理念为基础，即使因此牺牲短期财务目标也在所不惜。 Process 流程 原则2. 建立连续的作业流程以使问题浮现。 原则3. 使用拉动式生产方式以避免生产过剩。 原则4. 使工作负荷平均（生产均衡化）。 原则5. 建立立即暂停以解决问题、从一开始就重视质量控制的文化。 原则6. 工作的标准化是持续改善与授权员工的基础。 原则7.通过可视化管理使问题无所隐藏 。 People and Partners 员工与合作伙伴 原则8.使用可靠且已经充分测试的技术以协助员工及生产流程。 原则9.培养深谙公司理念的领袖，使他们能教导其他员工。 原则10. 培养与发展信奉公司理念的杰出人才与团队。 原则11. 重视合作伙伴与供应商，激励并助其改善 。 Problem Solving 问题解决 原则12.亲临现场，彻底了解情况（现地现物）。 原则13.制定决策时要稳健，穷尽所有的选择，并征得一致意见；实施决策时要迅速 。 原则14.通过不断省思与持续改善以成为一个学习型组织。 莱克的书中，不提精益，重回本名：丰田模式。沃迈克在后来的一本书，《十年观察》中采用了目的、流程、人的框架，也暗合了莱克的表述。 丰田模式的4P模型和14条原则，揭示了一种真北标准。 具备真北标准的企业具备三个特征： 特征一、具备正义的目的。正义的目的有两层含义，一是以客户价值为中心，二是以正义和不作恶的方式达成目的。 海底捞的使命：服务至上、顾客至上，以创新为核心，提倡个性化的特色服务，致力于为顾客提供愉悦的用餐服务。 丰田父子传承的使命： 丰田佐吉临终前，将丰田喜一郎叫到眼前，给他留下了作为父亲的最后一句话：“我搞织布机，你搞汽车，你要和我一样，通过发明创造为国效力。” 谷歌不作恶使命： 组织全球信息，使人人皆可访问和使用。不作恶口号的提出来自员工。由阿米特帕特尔于1999年提出，或者是由保罗·布克海特在2000年或是2001年初有关企业价值观的会议上提出。这个口号被创始人采纳和推广。Google 2004年的首次公开募股的招股书（又名“S-1”），（Google创始人的一封信，后来被称为“不作恶的宣言”）：“不要作恶。我们坚信，作为一个为世界做好事的公司，从长远来看，我们会得到更好的回馈-即使我们放弃一些短期收益。” 口号最重要不是拿来说和挂在墙上，而是相信自己的口号和拿来使用。在做产品时，如果会伤害用户的利益，虽然有短期收益，也可以根据这一价值观来否决，而且这个否决可以来自任何一个人。 特征二、全员主动参与海底捞在管理上，倡导双手改变命运的价值观，为员工创建公平公正的工作环境，实施人性化和亲情化管理理模式，提升员工价值。 每一个工会会员都必须明白一个基本道理，我们不是在执行公司命令去关心员工，而是真正意识到我们都是人，每个人都需要关心与被关心，而这个关心基于一种信念，那就是人生而平等。 海底捞的内刊上，有两行让人印象深刻的字：倡双手改变命运之理，树公司公平公正之风。在海底捞，员工可以享受一个特权：基层服务员可以享有打折、换菜甚至免单的权利，只要事后口头说明即可。 关于海底捞被人广为称道的细节服务，发圈、眼镜布等，最初只是一个个自发的想法。包丹袋就是这个想法的代表，这是一个防止顾客手机被溅湿的塑封袋子。由于是一名叫包丹的员工提出这个创意的，即用员工的名字命名。“这种命名的方式既能实现他的价值，也是对他的尊重，很多员工都有很多不错的创意，要给他们提供机会。”当包丹袋在其他店也开始使用时，这些店会给这位员工交纳一定的费用。 海底捞这种开放的平台还体现在培养员工的兴趣爱好上。一名员工在和外国顾客交流时，说起了流利的英语，随后公司为此举行了一次英语竞赛，并为优胜者请来了外语老师。“让员工能够发挥自己的特长，从而在工作中获得乐趣，使工作变得更有价值”。 大野耐一：“没有人喜欢自己只是螺丝钉，工作一成不变，只是听命行事，不知道为何而忙，丰田做的事很简单，就是真正给员工思考的空间，引导出他们的智慧。员工奉献宝贵的时间给公司，如果不妥善运用他们的智慧，才是浪费。” 丰田汽车提出“创意工夫提案制度”，对每个员工建议设置500日元到20万日元不等的奖金，优秀建言者的头像会被永久贴上丰田公司的“光荣走廊”。结果，丰田公司在40年间收到了超过2000万个提案，其中99%被采纳。 丰田的创意提案制度强调领导者的参与性和问题的精细化：首先，领导者要对员工进行培训，告诉他们什么是真正的问题；其次，提出的问题具有较强的可行性，员工不需要面对“怎样增支减收”之类的宏观问题，而是具体到“机器之间隔几米能使操作者少走路”“左手应该拿工具还是拿加工半成品”的实操问题；最后，员工不参与工资、考评等领域的建言，以免引起争论与攻击。 谷歌认为，员工应该都成为创意精英（Smart Creatives），才能够使得这个组织产生赋能的效应。 有一个周五下班前，拉里发现了某产品中一个严重的问题。他没有告诉任何人，而是写下了问题，及其影响。拉里把它贴在茶水间，就回家了。 周一早上五点钟，拉里和相关人员就收到一封邮件。邮件不是简单的附和创始人的想法，或是对要解决这个问题的不痛不痒虚张声势的呼吁。相反，邮件中包含了对这一问题根源的详细分析，及对多种方案中最优方案的选择，还有对这一方案的具体执行。而且，还提出了进一步想法，这一想法成了后来一个重大业务的基础。 邮件的发出人只是在周五下班前偶然看到了拉里的纸条，并且从组织架构上来说，他不属于出问题的这个产品。 这个故事的重点不在于是否提倡加班，工作是否需要计划。而在于： 每个人都明白公司的当务之急和价值取向。 一种不急赏不惩罚不嫉妒的文化：这件事做成了，也不会有马上的奖赏。失败了，也不会被惩罚。成功了，也不会被嫉妒。 这个例子，将谷歌文化的力量彰显的淋漓尽致。如果一个企业支持员工有发言权，那么持相同观点的人就会被吸引来，子曰：近者悦，远者来。在企业成立之初就认真考虑和确定你希望的企业文化，是明智之举。创始人是企业文化的源头，创始人为实现大计而物色并信赖的团队，是企业文化的最佳载体。问一下你的团队：我们重视什么？我们的信念是什么？我们想成为怎样的企业？ 特征三、形成一个具有持久生命力的系统。勉强给企业真北标准下一个定义，大致是：企业有一套理念，这个理念把客户，员工，企业发展，甚至造福社会等各种要素组合在一起，充分考虑各方面的福祉，持续优化形成卓越运作，达到企业的基业长青和个人的幸福。 这样一种管理理念的主要思想是：管理决策的制定以最终的目的为前提，眼光放长远，有一套处理问题的步骤，通过培养员工来为企业增值，并且认同持续不断解决根本问题会促进整体学习的观念。 如果把上述各个流派的精益思想做个总结，可以概括为以下几点： 强调目的和价值 强调领导者的作用 强调对人的尊重 强调流程 强调问题解决和持续改善 所有这些是精益的要点，也是敏捷的要点，而且所有这些点要有机结合，而不是孤立存在。企业要想通过敏捷转型获得竞争优势，需要对精益体系有完整的理解。这些都是精益和敏捷的元认知，敏捷教练可协助管理者理解。 精益方法基础的重要基本概念什么是价值？ 客户愿意为之付钱。 是一种产品或服务的形态发生改变的过程。 这种改变必须无浪费地做对。 什么是问题？ 标准没有达到。 旧的标准达到了，又提出了新的标准。 标准没有稳定地达到，有时能达到，有时不能达到。 什么是浪费？TIM WOODS 八大浪费： Transportation 运输的浪费。 Inventory 库存的浪费。 Motion 移动的浪费。 Waiting 等待的浪费。 Over production 过度生产。 Over processing 过度加工。 Defect 缺陷也是一种浪费。 Skill unused 未使用的技能。 从更高的视野看什么是浪费 3M： Muda 无驮，就是一般所说的浪费。 Muri 无理，比如说人或设备过载。 Mura 无稳，比如说有时忙有时闲。 浪费管理的基本思路，跟把大象请出冰箱一样简单。分两步： 识别浪费。 消除浪费。 这些关于价值、浪费与问题的思想，都是非常深刻的认识，在敏捷当中也是同样适用的。敏捷教练可以把这些思想，运用到问题解决和持续改善中。 ###把思想、方法论、解决方案（模式）、工具组合在一起： 定义价值。可以使用： 增值工作 八大浪费 3M 观察整个价值流。可以使用：价值流图 让增值步骤流动。可以使用： 目视管理 5S 防呆法 节拍时间 标准工作 连续流 单元式布局 产线均衡 快速换模 全员生产维护 分层流程审计 让客户拉动。可以使用：看板 持续重复前面的步骤。可以使用： 反思 经验分享这个价值流分析，可以直接运用到软件开发的管理中，所使用的具体工具可以变通。David Anderson （《看板方法》）的重要基础就是价值流。 精益方法论方法论是解决问题的方法，重点介绍 TBP 或 A3 报告。 TBPTBP：Toyota Business Practice，中文可以叫丰田问题解决法，是A3报告的一种逻辑框架。A3 报告参看在丰田工作过的精益大师 John Shook 的 &lt; Manage to Learn &gt;。 TBP 体现了质量大师戴明的 PDCA。美国人一般把这个方法叫做 Practical Problem Solving，即实践的问题解决法。 TPB 中的基本意识 客户至上 经常自问自答“为什么” 当事者意识 可视化 根据现场和事实判断 彻底地思考和执行 把握速度和时机 诚实正直 全员参与 PDCA/TBP/A3/Practical Problem Sovling 为什么这么好？依然可以用 4P 解释： Purpose：从目标出发。 Process：是一步一步紧密相扣的闭环和螺旋式上升的问题解决方法。 People：平等积极参与。 Problem Solving：彻底的问题解决。 A3 在丰田就是一种尚方宝剑，可以穿越等级和部门墙。TBP 八步详解PDCA 扩展为丰田八步问题解决法： Plan 计划 第一步：澄清问题。 第二步：分解问题。 第三步：设定目标。 第四步：分析根源。 第五步：制定措施。 Do 执行 第六步：贯彻措施。Check 检查 第七步：评估结果。Act 行动 第八步：标准化。 下面我们来逐一解释一下。 第一步：澄清问题。 通过问 5W2H，形成清晰简洁脚踏实地的问题描述。注意这里的 5W2H 是从现象级来问，不是问原因。原因在后面，不要着急，慢就是快。 问题是什么？ 它是在哪里发生的？ 何时发生的？ 谁会受到影响？ 为什么这是一个问题? 影响有多大？ 发生的频率如何？ 第二步：分解问题。 可以画一个流程图，按流程分。 可以按影响因素的重要程度分，参考二八原理和柏拉图。 第三步：设定目标。 重新回顾什么是问题：理想状态是什么，现状是什么，理想状态与现状的差距就是目标。目标的设定可以是更高目标，或稳定化的目标。 第四步：分析根源。 可以采用鱼骨图，五个为什，主效应图等。 第五步：制定对策。 对症下药。 第六步：执行对策。 坚持，不妥协。 第七步：评估效果。 可以采用控制图，箱体图（控制图的变种）等。 第八步：形成标准。 在敏捷当中，可以把 A3 方法作为一个问题解决工具来使用，以打造彻底解决问题，持续改善的学习型文化。 其他问题解决方法的简要描述如下： DMAIC 方法：用于复杂问题 Define 定义 Measure 度量 Analyze 分析 Improve 改善 Control 控制 DMADV 方法：用于创新问题 Define 定义 Measure 度量 Analyze 分析 Design 设计 Verify 验证 8D 方法：用于质量问题 D1：定义问题 D2：建立团队 D3：抑制问题 D4：调查与根源识别 D5：纠正问题的措施 D6：预防问题的措施 D7：实施与评估 D8：可持续性评估 精益工具工具是对事物的相对简单的抽象。工具可以被方法论调用。 精益工具主要有： 流图 Flow Chart 柏拉图 鱼骨图 五个为什么 控制图 箱体图 主效应图 特别说一下五个为什么。问为什么的三个角度： 为什么故障会发生？ 为什么故障没有被检测到？ 系统中有什么漏洞？ 精益工具可以在敏捷软件开发中有选择的使用。 精益解决方案（模式） 模式是方法论的产物，是针对特定场景的解决方案。 5S Sort 分类 Set in order 排序 Shine 清扫 Standardize 标准化 Sustain 持续 目视化管理的三个层次 Visual order 可视化顺序。 Visual display 可视化展示。 Visual control 可视化控制。 创建一件流的步骤 化身为物。 让它流动。 持续流动。 标准化的原因： 不稳定制造了浪费，并且阻碍了改善。 标准化在改善循环中的地位 标准化-〉暴露问题-〉解决问题-〉实施新方法 节拍时间 有效工作时间/需求数量。 标准工作三要素 周期时间 工作顺序 在制品数量 防呆法 例如，能够使用下拉菜单的，就不要让用户填写。 快速换模 持续构建是快速换模思想的体现。 精益当中的解决方案或模式，并不能直接运用到软件开发中，但仍然可以给我们很多启示。 重温一下精益知识体系的四层：思想，方法，工具，模式。这种思维体系本身也与我们的敏捷教练基本功相一致：我们要掌握敏捷的核心思想，通过教练方法，调动教练工具，来生成和普及 Scrum 模式。 精益三纲八目 最后，按照精益三纲八目的结构做一下总结。 精益当中最重要的三条思想，成为精益三纲： 从内在的生存动机来说：适者生存，持续改善，更高标准 从客户价值来说：专注价值，消除浪费 从方法来说：身临现场，科学方法，快速反馈 敏捷转型，需要企业上下对这三点有一致的认知。 而实现这三条思想的具体方法，可归类为八种，成为八目： 因业果关系：偏因的鱼骨图，五个为什么，柏拉图；偏果的关系图，箱体图，主效应图，控制图；偏解决方案的流图。 结构化上升：PDCA，A3，DMAIC，DMADV 可视化：价值流图 简化：5S，防呆法，单元式布局，快速换模，全面生产维护，逐层过程审核，纸芝居 流：价值流图，3M，八大浪费，一件流，看板，反思，分享 均衡化：3M，产线均衡 标准化：标准化，标准作业 稳定化：节拍时间 这八类方法的每一类，都体现着一种智慧。大部分都可以运用到敏捷中。 本文提供了两种理解精益的思路，思想-方法-工具-模式和三纲八目。这是对精益知识体系的完整概括。其中很多可以通过常识思考和理解运用。更深入的了解，参看第一章推荐的书目。]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷教练和 ScrumMaster</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷教练和 ScrumMaster</tag>
        <tag>用户故事精要</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[敏捷教练第04课：储备-scrum的20个子模式]]></title>
    <url>%2F2018%2F05%2F14%2F%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%AC%AC04%E8%AF%BE-%E5%82%A8%E5%A4%87-Scrum%20%E7%9A%8420%E4%B8%AA%E5%AD%90%E6%A8%A1%E5%BC%8F%2F</url>
    <content type="text"><![CDATA[自克里斯托弗亚历山大发明建筑模式，经由设计模式，发展到组织模式。模式是一种经过验证的、经过分类的、可以被反复重用的、场景化、定式化的经验总结。模式思维是理性和感性思维的中和，是人固有的一种能力。模式的好处是省力。敏捷管理，也存在一些这样的模式。本文介绍的模式可分为三大类。第一类是 Scrum 本身存在的模式，第二类是在 Scrum 活动中探索出来的模式，第三类是 Scrum 反模式。 Scrum 中存在的模式 这部分模式可以帮助我们更好地理解和实施 Scrum，以及评估和改进 Scrum 的实施，也能帮助我们理解 Scrum 的发明。 模式名称：Backlog解决的问题： 在本质上偏于不确定性的项目中需要知道下一步做什么。需要一种组织方法使得在项目的任何阶段都易于知道下一步要做什么。甘特图方法事先定义任务和锁定时间，无法满足不确定性环境下的项目管理要求。完全不管也不是一种好方法。 解决方案： 用 Backlog 组织工作。 Backlog 是一个排好优先级的列表。高优先级的工作先做。 Backlog 的总合是产品，Backlog 中工作的完成意味着产品愿景的实现。Backlog 是动态管理的，以便完成的产品是合适的、有竞争力和有用的。 Backlog 的内容来源很多。可以来自市场、销售、技术、开发部门和客户。 只有一个人对 Backlog 排序。这个人对产品愿景的实现负责。 根据市场需要和组织预算，一个或多个 Scrum 团队工作于一个 Backlog。团队从 Backlog 中选择一个迭代可以完成的工作项。 团队在一个迭代中选择的工作要有一定的内聚度，构成迭代目标。团队在一个迭代内的工作，是为了完成迭代目标。 团队把工作分解为任务，以便完成迭代目标。 Backlog 这个简单的物件，上溯产品愿景，下达具体的工作项管理。 达到的效果： 项目中的所有工作根据客户需要和团队能力动态排序。 模式名称：Sprint解决的问题： 工作中涉及探索、创造与测试，而不是简单重复的机械式工作。 需要优化沟通和信息共享。 需要在一个时间盒里承诺完成来自 Backlog 的一定的工作量。 团队需要无打扰地工作，管理层和客户需要看到进展。 预先计划和命令与控制的方式行不通。 解决方案： 给开发人员空间进行创造性的工作，学习探索，做实际的工作，免受外部干扰，运用机会和洞见来优化工作方式。 同时显示真正的进展让管理者和干系人有信心。 以短周期，小团队，来承载 Backlog 中的一段工作，并产生可交付的产品。 聚焦，而不是微管理。焦点有不同层级的颗粒度，迭代层级，是团队和干系人共同关注的焦点。迭代之下的焦点和颗粒度，如每天的工作，更多由团队关注就可以了。 在一个 Sprint 中，外部干扰被排除。团队内外及干系人对这一点有共识。 团队在过程中可调整工作方式。团队以最好的方式，使用他们的技能经验和创造力，专注于手上的工作，产生可见、可用和可展示的交付。 创建安全的时间盒，并向客户和干系人做出可信的承诺。 是团队主动进行的承诺，和对创造性的工作和工作方式的优化。 达到的效果： 所有参与者高度有效而又各有侧重的所有权，包括团队、干系人和客户。 最大可能完成计划的工作。在每一个周期结束的时候，干系人可以影响和调整后续迭代的计划。因而使得长期计划具有极大的灵活性。 每日站会的高度可见性，可以帮助发现浪费并很快回归真正的工作。 为了能够选出迭代的工作，强制产品负责人更好地对 Backlog 排优先级。 不适用于需要高度指导的人。 模式名称：每日站会解决的问题： 需要一个方法来控制经验主义和不可预测的流程，例如软件开发，科研，艺术项目和创新设计等。 对于需要探索、创造性和测试的工作，精确估算是困难的。 过渡计划不会增加可预测性，只会浪费时间。太过详细和锁定细节日程的计划也难以执行。 太过频繁的日常跟踪浪费时间，还会打扰开发人员。 太多跟踪也无助于计划的完成。 解决方案： 团队每天碰面15分钟，回答三个问题：昨天完成了什么，今天打算完成什么，遇到了什么困难。 每天发生在同一时间同一地点，强化团队状态、问题和计划的社会化。 是大家主动参与的一种目标、趋势和风险追踪。 达到的效果： 增加紧迫感。 提升知识分享，社会化，外化，内化和组合知识（参见野中郁次郎的知识管理、场理论和 SECI 模型）。技术专家成为社群资产。 鼓励沟通和诚实。 提升归属感。 转变文化。通过透明，提升大家对目标的关注和主动参与，进而打磨流程，促进从根本上解决问题，建立学习型组织。 高度可见的项目状态。 高度可见的个人生产力。通过同事压力促进卓越。 更少因阻碍造成的浪费。阻碍被及时发现和解决。 更少因等待造成的浪费。通过细颗粒度的协作减少等待。 提升团队内的社交。建立快乐高效的团队。 Scrum 活动中探索出来的模式 这部分的模式是作者在 Scrum 的使用中探索出来的模式，可以根据团队情况试用并调整。 模式名称：团队生物钟解决的问题： 使团队成员更能感受团队工作的节律。 使团队成员之间的合作更有节拍。 使团队从良好惯性中受益。 解决方案： 团队生物钟由团队共同讨论制定和调整。 团队生物钟有两种，每天级别的和迭代级别的。 在每天级别的团队生物钟里，大概包括以下四种时间。 每日站会时间，15分钟。 站会后讨论时间，大概1小时。不是全员参与，话题和人按需设置。 团队核心时间，大家都能找到彼此且欢迎骚扰的时间，可以选取每天的两个时间段。 私密时间，即不欢迎打扰的时间，个人可以集中精力做一下需要专注的事。 迭代级别的团队生物钟也大概包括四种时间。 日常工作时间。 Scrum 的五个会议时间。 Scrum 之外的会议时间，比如知识分享，代码评审等。 发布的准备时间和发布时间。 迭代级别及每日级别的各种生物钟要形成节律。 产生的效果： 各项活动更能准时高效开展。 团队成员有专注的时间做专注的事情。 工作的节律感带来更高的员工满意度。 好习惯帮助减少团队活动和任务间的切换成本，产生效益。 模式名称：会议议程精确到十分钟。解决的问题： 会议目的不明确，流程不清晰，执行不聚焦，效率低。 解决方案： Scrum Master 提前收集议题，设计议程，尽量切割到以十分钟为颗粒度。 确实不能切割的，可以以20分钟或30分钟为颗粒度。对于不能切割的，也可以寻找一些切割的角度，帮助会议的焦点有效流动，即所有人能同时有效地关注一个点，当一个点关注完，流动到下一个点。 在执行每一议程前声明时间盒。 执行时可以根据情况调整，并为下一次议程设计提供经验。 达到的效果： 会议整体效率更高。 在某个小议程，目标更明确，团队更专注。 通过提升会议的效率与效能，提升团队满意度，更好地完成团队目标。 模式名称：产品列表业务精化会与技术精化会解决的问题： 如果只讨论业务，不讨论技术方案，无法进行估算。因此到了计划会上也无法做出靠谱的计划和承诺。 在同一个精化会上既讨论业务也讨论技术，时间不够，而且团队的准备度也不足。 把技术方案的制定留到会后，可能受其他任务的挤压，无法确保能制定出。 解决方案： 把精化会分解为两个，业务精化会和技术精化会。 在业务精化会上，集中精力梳理业务需求。 识别出需要提前制定技术方案的故事和可以直接带到计划会上的故事。 对于需要制定技术方案的故事，指定专人调查，并在稍后的时间举行技术精化会，产生技术方案。 两个精化会的时间都固化。 产生的效果： 业务精化会聚焦于业务，主题清晰，效率高。 技术精化会专注于技术方案的制定。 因此到计划会时可以制定靠谱的计划和承诺。 整体工作过程更加有条不紊，团队对完成迭代目标更有信心。 模式名称：一人天任务解决的问题： 培养当日事当日毕。 帮助发现障碍。 形成流动。 解决方案： 尽量把任务的平均大小向一人天靠拢。 理解这个模式的目的，而不是照搬形式。 任务可以在计划会产生，也可以在每日站会动态产生。 达到的效果： 更好的流动。 更好的风险识别和管理。 模式名称：故事 X 人矩阵解决的问题： 清晰呈现不同人员在同一个故事上的合作。 清晰呈现每人当前手上的任务数。 解决方案： 在白板 To Do 列中，按故事带任务两级呈现，故事从上到下反映优先级，任务从左到右反映大致的先后顺序。 在 Doing 列中，自左到右按人排列。故事与人形成矩阵。 每日站会进行的顺序是按故事泳道，故事驱动。 每个故事涉及到的人讲解和拉动任务。 达到的效果： 更清晰的合作呈现。 更清晰的多任务呈现。 更好的故事和任务流动。 模式名称：随机一分钟项目经理解决的问题： 确保在每日站会中，每人都关心团队目标。 确保在每日站会中，每人都认真听他人说什么。 并以此确保隐性知识传递，团队成员互相学习。 解决方案： 在每日站会最后，以随机方法产生一分钟项目经理。 一分钟项目经理做五点说明。 我们的迭代目标是什么。 趋势是什么，是否可控。 主要风险和障碍是什么，如何管理。 团队士气如何。 邀请全体团队成员对完成迭代目标的信心点赞，以创造一个再次思考风险的契机。并宣布散会。 达到的效果： 站会中团队成员更好的投入。 更好的风险和趋势管理，更好的目标完成。 更好的团队凝聚力。 模式名称：Scrum 风险管理分类解决的问题： 风险分类不清晰，难以确定合适的负责人。 风险分类与角色职责没有匹配。 解决方案： 风险分为三类：与产品和客户相关的，与技术相关的，与社会化相关的。 产品和技术相关的，由产品负责人解决。 技术相关的，由团队解决。 社会化相关的，由 Scrum Master 解决。 风险管理可视化。 达到的效果： 更好的风险分配。 风险管理与角色职责匹配。 有意识的风险管理。 模式名称：知识分享基金解决的问题： 给分享者一点激励，更多代表的是团队的认可。 让所有人，不管是分享者还是参与者，都成为分享的主动拥有者。 解决方案： 由团队或个人众筹知识分享基金，不用太多。 每迭代固定设一个知识分享时间，分享内容不限，只要对团队或项目有帮助。 分享者主动提出分享话题。 如多人都想分享，由多位分享者协调分享时间。 每次分享结束时，给分享者一个小礼物。 选取每次分享的重要照片，形成团队分享相册。 达成的效果： 更好的知识传播。 更好的团队成员之间的连接。 模式名称：同事赞扬解决的问题： 提供一个团队成员互相感谢的机会，把内心的感谢表达出来。 以此加深彼此了解。 并形成一个更有凝聚力的团队。 解决方案： 在回顾会议开始时，增加一个同事赞扬环节。 每人以 Post-It 写下要感谢的人，并把所有 Post-It 放在一起。 Scrum Master 随机抽取一张，让写的人面向要感谢的人表达感谢，包括感谢的原因。 依次过完所有 Post-It。 达到的效果： 更高的士气，更好的团队凝聚力。 更高的产出。 模式名称：卓越驱动的迭代回顾会议解决的问题： 迭代回顾会议缺乏结构与效率。 迭代回顾会议缺乏有利于长期提升的制度化。 解决方案： 团队制定一组卓越指标，例如跨职能团队、价值流、团队工作。卓越指标代表团队为了完成产品目标和迭代目标所最看重的东西。 针对每一指标，制定一系列子项或检查项。 定期更新指标定义。 在迭代回顾会上，把卓越指标打印张贴。 针对每一指标，集体评估团队做得好的地方和需要改善的地方。产生改善措施。 产生的效果： 更系统化结构化制度化的回顾。 更持续的改进。 模式名称：同事评估解决的问题： 在传统的由经理进行的评估中，多数员工是不满意的。 解决方案： 在每个迭代结束的时候，分配给每个团队成员等量的代币。 规则只有一条，就是要把代币送给其他团队成员，自己不能留。至于全部送给一个人，还是平均送给每个人，是当事人自己的决定。 根据组织的形态，可以有两种方式：只有结果公开，和结果和过程（即谁送给谁多少）都透明。 根据组织的形态，决定代币的用途，如只是兑换小礼品，还是兑换奖金。 是否要使用，如何使用，使用的程度，需获得组织和团队的共识。 达到的效果： 同事评估更能反映一个人的真实表现。 Scrum 反模式 这部分是在 Scrum 的使用中应该避免的模式。 产品负责人的反模式 产品负责人在迭代中大部分时间缺席，不能回答团队的问题。 在迭代计划之后，改变故事的范围或验收标准。 对于无法实现或不再有效的验收标准，缺乏改变的灵活度。 产品负责人不能及时对完成的故事提供反馈。 误用取消迭代的权力。 在迭代目标不再有效时，也不取消迭代。 开发团队的反模式 没有 WIP（进行中的工作项）限制。 在遇到阻塞时，开始其他任务，使自己保持忙碌。 任务板不能保持更新。 工作于没有显示在任务板的工作。 镀金，增加不必要的工作。 Scrum Master 的反模式 允许管理者或干系人在迭代中打扰团队，让团队从事与迭代目标无关的事情或会议。 不能支持需要帮助的团队成员。 允许微管理，允许产品负责人向团队分配任务。 没有回顾会议。 Scrum 团队的反模式 有人没有询问团队就把任务加到迭代列表。 不产生交付的迭代。 做不是产品负责人认为当前应该做的工作。 没有紧迫感。 新人加入时，没有接轨计划。 可变的迭代长度。 管理者的反模式 在紧急情况下放弃 Scrum。 经常在团队之间重新分配团队成员。 不经产品负责人，直接向团队分配特定任务。 干系人反模式 偷偷向团队加入任务。 把每件事都当成紧急的。 打扰团队。 模式是一种语言，语言承载思想。Scrum 中的模式承载了“更好”在不同场景中的实现。下一章探讨精益体系，看作为敏捷起源的精益如何在敏捷中发挥作用。]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷教练和 ScrumMaster</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷教练和 ScrumMaster</tag>
        <tag>用户故事精要</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[敏捷教练第03课储备-用户故事精要]]></title>
    <url>%2F2018%2F05%2F14%2F%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%AC%AC03%E8%AF%BE-%E5%82%A8%E5%A4%87-%E7%94%A8%E6%88%B7%E6%95%85%E4%BA%8B%E7%B2%BE%E8%A6%81%2F</url>
    <content type="text"><![CDATA[本节课程我们主要解决三个问题：为什么要有用户故事？用户故事是什么，它们具有哪些属性、内涵和特征？在产品开发的全流程中怎么使用用户故事？ 理解用户故事理解用户故事，从两个问题开始。 用户想要达到的目标是什么？ 达到这个目标的成本是多少？ 为了回答这两个问题，我们需要把大目标分解为小目标，排优先级和估算。 用户故事是这个过程中使用的基本单元载体。比用户故事大或者模糊的可以叫做史诗，主题或者只是一个产品点子。 关于上面两个根本问题，“@左耳朵”有很好的描述： 亚马逊里挑战产品和运营的方法论是 T-shirt Size Estimation。就是用 T 恤的尺寸来做评估。你要做这个东西可以，但是产品和运营必须得拿出证据说明你要做的这个东西是什么样尺寸的。 比如说 XXL 可以带来一百万人民币或一百万用户受益，XL 就是 50 万，L 是 25 万，这样砍下去，然后这些需求给到技术团队，这边技术团队也会做个评估。XXL 是要六个月做完，XL 是三个月，L 是一个月，M 是两周，S 是一周。这样两边一对。如果说业务影响力比较高，而且技术实施比较轻，这就是小而美，那就是最高优先级；如果是反过来，技术这边要花好大的力气，业务影响力又不是特别高，那就坚定不移地把它砍掉；如果两个都是中等，那就是自由行事；如果两个都是 XXL 的话，那能不能需求这边降低一个维度。比如将 XXL 降到 XL，我这边可以降好几个档次，两三个星期就可以实现出来，这样可能会是一个比较好的方式。 产品愿景是用户故事的统摄产品愿景要回答三个问题： Who：它的用户是谁？ What：它是什么？一是要有清晰的画面感，二是与已有产品不同。 Why：它意味着什么？有什么价值和目的？ 两个产品愿景的例子： 我们要在10年的时间里，把一个人送到月亮上，还要让他回来。 把1000首歌装在口袋里。 产品愿景可以从最初的一个点子开始，慢慢打磨成熟。而在产品愿景打磨的过程中，把大而模糊的点子敲碎成清晰而可执行的小块，就是用户故事。产品愿景与用户故事同生同长，用户故事全部做完了，产品愿景就实现了。 用户建模，是用户故事的起点用户建模可以考虑用户的两点： Pain 痛点：用户在产品目标领域目前有什么痛点？ Gain 收益点：我们的产品能给用户带来什么收益？ 用户角色建模，要以用户为中心。建模的 BSCR 步骤： Brainstorm：产品探索团队头脑风暴出用户角色。 Sort：对头脑风暴出的用户角色快速分组和识别层级。 Consolidate：对每一角色逐一讨论，整合角色。 Refine：提炼角色。识别用户角色的： 用户角色分组可以考虑用户的： 使用频次 领域知识 IT 知识 使用目标 用户建模的其他技术： 典型用户画像。针对一种角色，虚构出一个人物，描述他的行为特征，使用场景，核心诉求。还可以给出画像。打印出来放在团队可见的地方，让团队在开发产品时对用户的需求能感同身受。 极端用户。想象一个极端用户会有什么诉求，以产生新的灵感。这方面不用太用力。 用户故事 用户故事是从用户的角度描述功能。用户故事的 WWW 及格式 Who：谁要使用这个功能？ What：需要完成什么样的功能？ Why：这个功能带来的价值是什么？ 用户故事的格式 英文：As &lt; a user &gt; ，I want &lt; to do something &gt;， so that &lt; I can achieve some purpose &gt;. 中文：作为 &lt; 一个用户 &gt;，我想要 &lt; 做什么 &gt;，以便 &lt; 达成什么目的 &gt;。 例子： 作为一个求职者，我想要发布简历，以便用人单位找到我。 现存世界上第一张用户故事卡，from @张克强。 用户故事的 AC（Acceptance Criteria）验收标准 验收标准也是迭代结束时 Demo 的标准 更多代表外部质量 简洁与完备之间平衡 包含成功路径和失败路径 对前述故事的验收标准例子： 我想要发布 Word 简历 我想要发布 PDF 简历 发前能预览 发后能检查 可以设置公开或私密状态 失败有原因提示 搜集故事的方式 用户访谈：不设定立场，问开放式问题和背景无关问题。 问卷调查：问卷可简单直接，比如了解用户使用软件功能的频率。 直接观察用户如何使用产品。 产品探索团队使用故事编写工作坊，头脑风暴，输出简单原型和用户故事。 用户故事的一些重要特征 一目了然格式一致的表达。 用户故事有两个部分：描述部分和验收标准。描述部分的常用格式是：As &lt;用户&gt;，I want &lt;功能&gt;，so that &lt;目的&gt;。验收标准可以有多条，常用的格式是：Given &lt;前提条件&gt;，When &lt;动作&gt;，Then &lt;结果&gt;。 鼓励推迟细节，只需有足够的信息以使项目前行。我们不需要一次性把项目的所有需求搞清楚，我们只需要在迭代之前把一个迭代要做的事搞清楚即可，而以用户故事作为基本单元，可以支持这种开发模式。 用户故事以合适的颗粒度，方便理解，方便排优先级，保证重要的事先做。随着时间的推移，不重要的事也许就不需要了。 用户故事鼓励通过交谈了解细节。强调对话而不是书面沟通。 用户故事的验收标准保证成果可以被审核验证。 以用户故事为载体，促进结构化沟通，使谈话有落地点。 从业务角度描述，可以同时被业务人员和开发人员理解。 用户故事的大小适合估算和做计划。颗粒度适合迭代开发。 支持随机应变的开发，检视和适应。 鼓励各方参与交流，传播隐性知识。 用户故事的 3C，鼓励通过交谈了解细节 Card 卡片：用户故事通常写在卡片上，描述用户想要达到的目标，突出对用户有价值。 Conversation 对话：书面文档是一种低带宽沟通，表达信息的能力受限，接受信息的体验受限，信息传递能力受限。面对面交流是高宽带沟通，利用检验，适应和反馈促进沟通的有效性。用户故事模式鼓励对话。无形的对话为有形的卡片补充细节。 Confirmation 验收标准：无形的对话再次落实到有形的验收标准，并成为故事的一部分。 排优先级要考虑的要素 大部分用户对该功能的渴望程度。 少部分重要用户对该功能的渴望程度。 故事之间的关系，是否有开发的先后顺序。 技术实现的难度。 成本高低。 关于优先级的两个模型 MoSCoW 莫斯科定律：Must have 必须有；Should have 要有；Could have 可以有；Woudn’t have 不会有。 Kano 模型：没有不行的功能，线性功能，尖叫功能。 用户故事的 INVEST 准则 Independent：用户故事之间是独立的。如果不独立，可能是划分的方法有问题，可重新划分。 Negotiable：用户故事是可讨论的。使用卡片是为了提醒对话。讨论的细节会变成测试。 Valuable：用户故事对用户有价值。有条件的话，让用户写或确认用户故事。 Estimatable：用户故事是可估算的。不可估算的原因可能是：缺乏领域知识（多与客户讨论，学习对方的语言，了解对方的想法，事实往往比想象的简单），缺乏技术知识（可以把故事分为两部分：探针实验 spike，和实际开发），故事太大(分拆)。 Size appropriately：大小适中。故事的合适大小取决于团队，容量和使用的技术。 需要分割的故事，可能是复合故事（按 CRUD 分拆），或复杂故事（可以分探针实验 spike 和实际开发两个故事，与其他故事一起排排优先级，然后在不同的迭代完成探针实验 spike 和实际开发）。需要合并的故事，包括若干小 bug，或小改动。 Testable：用户故事是可测试的。故事的描述需使用具体的量化的描述，而不是绝对的含糊的描述。 其中有价值和可估算是第一级标准，对应着本文开始时提到的产品开发所要回答的两个根本问题。另外四个标准更多是为了方便迭代开发。 用户故事的一些其他原则 从目标开始，大目标分解成小目标。 切蛋糕式划分故事，竖切而不是横切。 故事的描述要封闭，有完成感。故事针对一个场景，一个画面，一次完整的动作。 约束也可以作为一个故事。 故事的冰山法则：近期要开发的要划分的细而清晰，远期开发的可粗而模糊。 文档也可以作为故事。 故事中要包含用户角色，一个故事只包含一种用户。 为了表述简单，故事使用主动语态。 有可能的话，让用户编写故事。 故事不用编号。可提炼出作为标识的关键词以方便讨论时引用。 一定不要忘记故事的意图。 避免镀金，开发不需要的功能。团队公开透明的工作方式可以帮助这一点。 非功能需求可以作为故事。 缺陷可以作为故事。 故事分级 Epic 史诗：一个很大的故事。 Theme 主题：安放一组类似故事的篮子。 Story 故事：业务角度。 Task 任务：技术角度，一个故事可分解为多个任务。 用户故事分解大故事拆成小故事，9种不同切分方法。 按工作流程步骤切分是否可以先完成工作流程的头尾部分，再添加中间步骤去完善该故事呢？ 按操作切分是否可以把不同操作切分成独立的故事呢？（比如是有关“管理”或“配置”某物） 按不同业务规则切分是否可以先完成业务规则的一个子集，后续再添加其他规则呢？（比如故事中有没有范围型词语像是“灵活的日期”来暗示着多种变化呢？） 按不同类型数据切分是否可以先处理一种类型的数据，后续再处理其他类型的数据呢？ 按实现先后依赖切分该故事的实现背后是否依赖另一个流程的数据输入？ 按照体验质量切分是否可以先完成一个低体验质量的故事，然后再提高体验水平？ 按不同界面切分是否能先简化复杂界面，先完成一个简单版本？如果多个界面获取相同类型数据，是否可以先从一个界面处理数据，后续再增添其他界面呢？ 按简单/复杂切分如果简单的核心就能提供大部分价值，是否可以先完成简单核心，再通过后续的故事来扩充它呢？ 延迟性能优化是否可以先使其工作，后续再满足非功能性需求呢？（当复杂主要来自非功能性需求时） 绝对估算与相对估算绝对估算：按天或小时。 相对估算： 按倍增数列：1，2，4，8，16，32，64 按斐波那契数列：1，2，3，5，8，13，20，40，100 按T恤衫尺寸：XS，S，M，L，XL 估算纸牌 产品负责人讲一个故事 团队提问澄清 团队成员独立出牌估算，互不干扰，喊统一翻牌时才翻牌 出到最小点数和最大点数的人讲讲话 其他人可参与对话 第二轮出牌 对同一个故事不超过三轮出牌 客户参与、产品探索和产品交付的全流程 第一，产品负责人收集需求。利用前文讲到的客户团队和需求收集方法。需求来自客户和干系人，也来自产品负责人的思考。需求以业务角度为主，也考虑技术角度。需产品负责人与技术领域的架构师等密切协作完成需求的梳理。第二，产品探索团队利用故事写作研讨会对用户建模，编写用户故事，放入待办列表，排序，估算，制定发布计划。好的故事估算方法 允许团队随着对产品了解的加深随时改变想法。 要能适用于史诗和小故事。 估算精度随故事变大而变小。 估算快速。 能帮助提供进度和剩余工作的有用信息。 要能做到不精确也没事。 可以用来制定发布计划。 团队集体估算。 故事估算的单位可采用故事点或者理想天。 具体的估算方法 产品负责人拿起一个故事，进行讲解，团队成员提问澄清。 团队成员用斐波那契序列的纸牌出牌估算，出到点数最大和最小的人说明，其他人可参与讨论。独立出牌估算，翻牌前不要把估算讲出来，也不要受他人估算的影响。 大多数故事的估算会在一到两轮出牌后收敛。最多也不要超过三轮出牌。 还可用冒泡分桶法进行快速估算。把故事按从小到大从左到友排成一排，从冒泡法排到大家都认可为止。然后分组分到不同的桶里。桶的大小排列也是斐波那契序列。 每个迭代能完成的故事点数是速率。速率是一个靠谱的指标的依据是：故事的估算值与实际大小的偏差呈正态分布。每个迭代选取的故事的正负偏移可以彼此抵消。因此故事估算的精度不会影响速率指标的可靠性。速率指标可靠的前提是：在项目过程中始终采用一致化的估算方法，迭代之间的故事没有交叉重叠，项目过程中没有发生影响速率的大的异常。 速率和估算的几个注意事项 不要拿速率来比团队。 分解后小故事估算的总合不一定等于大故事的估算。 任务工时的总和不需要跟故事点成正比。 结对编程不影响对故事的估算方法。 做到一半的故事不能计入速率。没有完全完成的事情是不靠谱的。鼓励一件流。迭代完成后不要修订速率。 发布计划的制定 选定迭代长度。 预测速率。 产品的总故事点除以速率，即得出需要多少个迭代完成。 速率预测可采用 历史值 执行一轮看看速率是多少 猜测 可视化发布计划的方法 墙 电子表格 甘特图 第三，与客户确认发布计划。第四，与交付团队梳理故事，达到准备好的状态（DoR - Definition of Ready）。故事要有清晰的验收标准，优先级和估算。团队成员有充分的理解。第五，迭代计划，分解任务，生成迭代待办列表。 在迭代计划会上 选取本迭代要完成的故事。 把业务故事分解为技术任务。分解也是做设计。不能技能的人员可以在同一个故事中合作。 团队做出承诺。 第六，每日工作，按故事和任务的优先级执行。 测量和监控速率的方法 迭代故事点燃尽图。 迭代工时燃机图。 每迭代计划速率和实际速率趋势图。 每迭代计划和实际速率累计图。 这些图表只是团队监测趋势的工具。团队要在每天的工作中检视和适应以保证能达到完成迭代目标的趋势。 第七，迭代验收和演示。最好能有客户参与，以获得反馈。在 Scrum 中，用户故事运转在两条轨道上。一条是产品级别的产品列表精化，既帮助产品的长远规划，也为迭代的开始做好准备。另一条是迭代级别，故事经过精化准备好之后，经由迭代计划会进入迭代，经由每一天的检查与适应，在迭代评审会议上展现为产品增量和可工作的软件，在经过迭代回顾会议探讨下一个迭代如何做得更好。]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷教练和 ScrumMaster</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷教练和 ScrumMaster</tag>
        <tag>用户故事精要</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[敏捷教练第01课-敏捷教练和 ScrumMaster 基本功四部曲]]></title>
    <url>%2F2018%2F05%2F14%2F%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E7%AC%AC01%E8%AF%BE-%E6%95%8F%E6%8D%B7%E6%95%99%E7%BB%83%E5%92%8C%20ScrumMaster%20%E5%9F%BA%E6%9C%AC%E5%8A%9F%E5%9B%9B%E9%83%A8%E6%9B%B2%2F</url>
    <content type="text"><![CDATA[课程概述敏捷教练是一个职业。Scrum Master 和敏捷教练是同一职业的不同阶段。当一个人能带好一个 Scrum 团队时，他是一个 Scrum Master。当他能带各种不同类型的团队，并持续追求更好，他就是一个敏捷教练。 Scrum Master 职责的范围和边界相对确定，敏捷教练职责的范围和边界相对不确定。但从学习的角度，他们所需要的基本功是一致的。本课程中对这两个角色，在大多数时候不太区分。鉴于这两个角色既有相似处又有区别，大家在使用时对这两个名称的理解上又有变异，所以课程的名称中就把这两个名称并称，以求相对准确地表达这个课程所要服务的角色。就算是您所采用的敏捷方法不是 Scrum，依然可以从本课程中受益。 如同任何其他职业，敏捷教练有它的技能，也需要并且能够通过练习达到精通。我们可以通过四部曲的结构理解敏捷教练这个职业及其技能： 目的：任何一个职业，都有它存在的目的。这个目的包括职业产生的背景，工作的环境，以及所承担的职责。 储备：即敏捷教练所必备的基础知识。 技巧：即如何运用基础知识履行职责。 实战：即在一个典型完整的工作周期中，如何利用储备和技巧取得成功。 本章会介绍： 敏捷教练这个职业产生的背景 敏捷教练的工作环境 敏捷教练的职责 体系化的参考书目 敏捷教练职业产生背景 “追求更好”旅途的守护者 敏捷方式可以追溯到1620年弗朗西斯·培根（Francis Bacon）科学方法的发源时期。更合理一点的起点可能是在20世纪30年代，那时候贝尔实验室的物理学家和统计学家沃特·阿曼德·休哈特（Walter A. Shewhart）开始使用计划-执行-学习-调整（PDSA）循环对产品和过程进行改善。 休哈特把这种反复渐进的开发过程教给了他的学员戴明（W.Edwards Deming），后者在二次大战后的日本大量使用了该方法。戴明将 PDSA 改造为 PDCA。丰田公司雇用了戴明来培训公司中数百名经理，并在他的经验之上创立了著名的丰田生产体系——这也是如今精益思想的最初由来。这种反复渐进的方式对于20世纪50年代的 X-15 超音速飞机的制造也是贡献巨大。 丰田模式的关键，以及使丰田有杰出表现的原因并不是任何个别要素，而是一个由各要素组成的 4P 体系： 长期理念（philosophy）：重视着眼于长期的思维，公司高层注重为顾客及社会创造与提升价值，这个目的主导了该公司的长期方法——建立学习型组织，投资于人员、产品与工厂，以及绝不松懈地坚持质量，以适应环境的变迁，成为高效的组织。 正确的流程（process）：正确的流程方能产生优异成果，流程是以低成本，高安全性与高昂的士气达成最佳质量的关键。 借助员工与合作伙伴（people and partner）的发展，为组织创造价值：丰田公司管理层的看法是，他们打造的是“人”，不是汽车。尊重员工的智慧和能力，并不断激励他们做得更好。 持续解决根本问题（problems）是组织型学习的驱动力：丰田模式的最高境界是组织型学习，丰田的持续学习制度重心在于辨识问题的根源，并预防问题的发生，持续改善。 此体系必须每天以贯彻一致的态度实行，而非只是一阵旋风。这个体系成功的秘诀是，经理即教练。培养深谙公司理念的领袖，使他们能教导其他员工。这是我们今天思考敏捷教练职责的最重要参照物。丰田的 4P 模式，也能帮助我们从根本上去思考什么是敏捷。 大野耐一是将丰田生产方式体系化的重要人物。大野耐一退休后，与其弟子创建了 NPS（New Production System），为其他企业服务。精益教练诞生，教练与经理分离。这也预示着在今天敏捷教练和管理者通常是分离的职位。 Scrum 的另一根植于日本的基础，是1986年野中郁次郎和竹内弘高在哈佛商业评论上发表的名为《新的新产品开发游戏》的文章。通过研究那些比竞争者更快发布新产品的制造商们，比如富士-施乐的复印机，本田的摩托车引擎，佳能的照相机，定义了以团队为基础的新的产品设计和研发过程。这种过程不是通常在产品开发中的“接力赛”——一组专家完成产品部分功能并将项目传递到下一组专家手中。这种方式被野中郁次郎和竹内弘高称作为“橄榄球”方式，“团队试图作为一个整体完成所有任务，将球传来传去。” 在1993年，Jeff Sutherland 面临一项似乎是不可能完成的挑战：Easel 是一家软件公司，需要在半年之内开发一款新产品来替代它的传统产品。Jeff Sutherland 通晓很多方法，比如快速应用程序研发，面向对象设计，PDSA 循环，专案工作等等。他希望在公司总部建立一个类似于专案工作的文化氛围，将组织分割和合并的好处结合起来。他开始学习任何和提高组织效率相关的知识。通过阅读上百篇研究报告和顶尖的产品管理专家面谈，他脑海中逐渐有了一些有煽动力的想法。 这中间有一个想法来自于贝尔实验室的关于 Borland Quattro Pro 团队的文章。该文章主张，每天短的团队会议能显著增加团队效率。而 Jeff Sutherland 的核心概念则来自于竹内弘高和野中郁次郎的“橄榄球”方式，虽然该方法更关注制造过程而不是软件开发过程。通过借鉴哈佛商业评论文章中的关键想法和进行一些特别的试验，Jeff Sutherland 创建了一种新的软件开发方法，归功于橄榄球带来的灵感，Sutherland 将这种方法称为“争球”（Scrum）。Scrum 方式最后确保了他准时完成了似乎不可能的任务，也没有超出预算，程序漏洞比之前版本还要少很多。Sutherland 随后就长时间和 Ken Schwaber 对该方法进行长期研究，并在1995年两人首次在公众面前发布 Scrum 的方法。 在2001年，17位自称“有组织的无政府主义者”在美国犹他州的雪鸟滑雪场会面，分享他们的想法。Jeff Sutherland 和其它 Scrum 的先驱也在其中。参与者们分享了互相竞争的几种方式：极限编程（XP）、水晶方法、自适应软件开发（ASD）、特性驱动开发（FDD）、动态系统开发方法（DSDM）。所有这些方式都是“轻量版”的框架，因为这些方法使用更少、更简单的规则来适应快速变化的环境。不少与会者都觉得“轻量”这个术语挺适用的。 虽然与会者不能在方法上达成一致，但是他们还是为这个运动取了个名字：敏捷。这个词是一位参与者提出的，他当时正在读《敏捷竞争者和虚拟组织：给客户更多的策略》一书。书中列举了100家公司的例子——包括 ABB， 联邦快递，波音，博士和哈雷戴维森，这些公司正在创建适应动荡市场的新方法。有了这个名字，参与者达成一致，发布了“敏捷软件开发宣言”，该宣言中突出了每个人都同意的4个关键价值。稍后在会议中，以及之后的几个月中，他们发展了12个原则，被称为“敏捷宣言背后的原则”。 从2001年开始，所有的开发框架，以及与之匹配的价值观和原则就被称作为敏捷技术。 同时，敏捷方法继续演化。在20世纪80年代后期和90年代前期，MIT 的研究学者们开始研究日本的制造体系，特别是丰田生产体系。他们借用了名词“精益”来描述改善效率的这套体系，包括消除浪费（muda)， 减少波动（mura）和降低负荷（muri）。虽然精益方法并没有在雪鸟会议上被表述成敏捷方法，但是精益和看板软件开发系统在后来被并入敏捷系统。在开始时候，一些纯粹的敏捷主义者拒绝承认精益方法。 但是精益宣传该方法能关注客户协作，最终更多的敏捷践行者开始接受精益，看板，还有混合方法（比如 Scrumban 和 Lean scrum），作为敏捷价值和原则合法的应用。 这些新方法论的创始人们是精通技术的管理者，和管理者中的思想者。敏捷宣言的17位创始人，是敏捷思想的传道者，可以被认为是最早的敏捷教练。他们所创造的这些方法的本质，不是一些死板的规定，而是在追求“更好”的旅途中，作为承载“更好”的载体。这些方法论的落地，以及作为这些方法论内在精神的追求“更好”，不会自动发生。 一种可能的逻辑是，由管理者来承担落实新方法论的责任。管理者可以转型为教练，重拾作为精益鼻祖的丰田的精神。对于管理者无法承担教练职责但又想追随敏捷潮流的组织，则需要专职的敏捷教练。 敏捷教练工作的环境守破离的概念来自日本，大致可以理解为遵守、突破和脱离。这个概念在敏捷界被广泛运用，含义也会有所变迁。下面这个关于组织所处阶段的守破离，来自于 Scrum 之父 Jeff Sutherland。 组织的守的状态 CEO 没有敏捷思维。以命令和控制的文化为主。 依据传统的管理层级结构产生项目组。 即使采用敏捷，也是跟风，流于形式，无法深入。 在这种状态之下的效率提升通常只能做到20%~30% 组织的破的状态 CEO 改变管理者的角色。教练和支持的文化浮现。 管理者教导团队自组织和自管理。管理者成为领导者。 领导者为团队提供有挑战的排好优先级的目标。 消除组织债，创建可行的商业和组织计划，提供团队所需的资源。 识别和移除障碍，消除浪费和技术债，确保团队速率最大化。 确保产品负责人对交付的价值负责。 确保 Scrum Master 对流程改善和团队快乐负责。 确保团队对质量提升和技术债修复负责。 团队依据排好优先级的产品列表自我形成。 领导者在组织内驱动不同技能的虚拟实践社区，为组织提供能力建设。 领导者按需重构组织。 在生产力方面会取得200%~400%的提升。 示例公司：Spotify，SAP，Salesforce，Microsoft。 组织的离的状态 层级仍然存在，但主要是为技能培养服务。 团队自组织负责产品方向和组织重构。 领导者支持团队所需的技能。 群游使组织在压力之下更强壮。 产生500%~1000%的生产力提升。 示例公司：Valve，Zappos，Morning Star，Gore，Grindr。 这三种状态，跟建国方略中的军政、训政和宪政暗合，可参照理解。 瓶颈通常在瓶子的上部，一个公司最大的瓶颈是 CEO。作为一个敏捷教练，针对所处的组织形态，可以采取运用敏捷基本功加上变通的方法来开展工作。 至于团队，也会有三种形态。 无组织团队 从团队绩效方面看，是相对不高和不稳定的，时好时坏。迭代计划预测的靠谱度较差，速度也不高。 从团队动态和互动看，呈现出一种各自为政的状态，沟通不畅，合作困难。从会议看，目的不明确，流程不清晰，效率低，参与者沮丧。 自运转团队 从团队绩效看，呈现出相对稳定的状态，迭代目标承诺靠谱度较好，迭代目标基本能完成。 从团队动态和互动看，团队成员目标一致，有良好的沟通合作，在各项活动中，团队成员都能主动参与。会议的目的和流程清晰，没有 Scrum Master 的情况下，会议也能按照打磨好的流程自动运转起来。 自组织团队 从团队绩效看，在稳定的基础上，呈现出阶段性的持续提升，生产率和质量不断提高。 从团队动态和互动看，团队有更多高质量的互动，团队除了关心共同的目标，还关心持续改善和从根本上解决问题。呈现出上文中所说的丰田 4P 的一些特征。 敏捷教练所要做的，就是把团队从无组织状态带到自运转状态，再进一步带到自组织状态。这个使命的履行，本课程中敏捷教练和 ScrumMaster 的基本功可以帮到您。 敏捷教练的职责：流程与人两手抓在设计本课程之前，针对一部分敏捷从业人员和经历者做了一个小调查，想了解他们对 Scrum Master 职责的理解。这个调查虽然样本较小，不具备统计意义，但依然可以帮助我们了解跟我们处在同样角色的人对这个问题怎么看。调查结果如下： 精通管理规则，精通业务梳理，极强的沟通协作能力，技术熟练，懂业务管理。 敏捷教练确保 Scrum 被正确的运用和贯彻，同时保护团队和引导新的想法落地。 Scrum Master 是牧羊犬的作用，让团队在一个迭代中不受打扰，同时他应该对敏捷的流程、理念有深入的了解，具有较强的管理能力。 引导团队进行效率的提升，通过各种工具的导入，来实现项目目标。但是，究竟是否要像传统团队一样，也要引导团队进行项目交付，并解决依赖问题，这个要商榷。 保证团队资源，保证各个角色及职责协作，解决团队开发中的障碍，协调解决沟通问题，保证开发过程按计划进行。 指导 Scrum 小组成员理解为什么、知道如何参与 Scrum 实践的每一个环节，把控好 Scrum 实践的产出，为整个小组的 Scrum 迭代/计划结果负责。 基于对 Scrum 角色的了解，以及对项目和资源的认识，帮助 stakeholder 决定最佳的按照 Agile 路线来实施项目的教练。 培训和指导团队践行敏捷实践；关注项目的度量数据，及时带领团队调整，加速或稳步前进；关注成员的状态，激励督促团队前进；带领和辅导团队按照敏捷和精益的方式做事，打造优秀自组织团队。 牧羊犬守护团队，流程；教练，培训，引导团队，PO，相关人知识，技能；推动过程改进，促进变革；提升团队，组织效能。 在敏捷团队中推进敏捷开发模式和流程，是团队的组织者，保证团队资源，协调内外部关系，解决出现的问题。 帮助团队进行敏捷实践落地，梳理流程，减少外部干扰，鼓舞士气，提高团队作战能力。提高工作效率。 传播敏捷思想，指导团队，指导 PO，组织敏捷会议，排除团队干扰。 指导团队按 Scrum 方式运转，传播 Scrum 思想，指导敏捷实践，提高效率。 保证团队资源完全可被利用并且全部是高产出的。保证各个角色及职责的良好协作。解决团队开发中的障碍。做为团队和外部的接口，屏蔽外界对团队成员的干扰。保证开发过程按计划进行，组织 Daily Scrum，Sprint Review and Sprint Planning meetings。 Scrum Master 是 Sprint 的负责人，Sprint 做得好不好的终责者。负责计划，执行 Sprint，并使团队团结及有自主创造能力。 搭建 team 架构，分配各个角色成员，开展 scrum 常规的事项，并让敏捷的理念深入人心。帮助团队更好的按照 Scrum 框架有效的运行，对团队遇到的问题和障碍提供帮助，协助扫清研发过程中的障碍，打造高效能的团队。 组织项目团队，承诺项目开发，回顾项目过程，总结项目经验教训，组织每日站会，制定 Sprint 计划。 Facilitate everything and eventually retire，留下一个自组织团队，悄然离去，深藏功与名。激励团队，coach，team lead，life tutor。 Scrum Master 应该是作为团队初步接触敏捷时作为流程与套路教授和规范。在团队逐步成熟后，Scrum Master 的职责可以旁落，而专职 Scrum Master 可以取消。 那么敏捷教练的职责到底是什么呢？ 《敏捷教练》一书的作者之一，瑞秋·戴维斯（Rachel Davies）对敏捷教练的观点： 概括地说，敏捷教练帮助团队在工作中应用敏捷实践，从而帮助团队发展的更健壮。接受这些变化需要时间，所以没法通过“点到即止”的方法立即让它们生效。你需要与团队长时间呆在一起，并帮他们，让他们更加关注工作流程、关注如何更有效地协作。你对团队的目标是在你离开后，让他们能“自我指导”并且擅长应用敏捷。这样不会限制敏捷教练向组织引进敏捷，以及建立新敏捷团队。 &lt; Coaching Agile Teams &gt; 的作者 Lyssa Adkins 对敏捷教练的观点： 敏捷教练确实非常重要，因为现在有许多人在运用一堆蹩脚的敏捷工作方式。即使运用了，它们只是更快地产出了平庸的结果，我知道，那并不是他们运用所谓“敏捷”工作方式的主要意图。我认为教练是帮助团队取得惊人成果所不可或缺的组成部分，因为所有的成果都是人互相交互所产生的。敏捷框架中没有说明如何处理人与人交互的部分。为了使敏捷框架良好运作，它当然会提供可让其正常运行的结构和容器。但是在敏捷框架之外，还有很多事情要做，还有很多东西需要带给团队，针对不同的规则，需要给团队很多建议——如冲突管理、敏捷促进、教导及指引人、专业指导等等。 本文给出的敏捷教练的职责定义是： 贯彻一种工作方式，包括精益、敏捷和系统思考。 打造自组织团队，特别是要面对人（包括自我与他人）这个最复杂的实体。 以此来消除浪费，增加价值，达到组织的目标。 要履行这些职责，需要理解敏捷，这是本课程基本功的储备部分；要能够在组织中用敏捷影响他人，这是基本功中技能的部分；要体会真实环境中的敏捷运用，这是本课程基本功中的实战部分。 体系化的参考书目 敏捷是敏捷教练的代码 敏捷的历史是一场不断追求更好的历史，在这个过程中，先行者们为我们留下了众多可供参考和让我们无须重新发明轮子的书籍。 本节以类库、框架、架构，和编辑、编译、链接、运行的视角解析敏捷和敏捷教练，以及如何运用先行者们留下的书籍。 敏捷是一种代码，2001年2月，17人在美国犹他州的雪鸟滑雪场，解码和发明了这门语言，并贡献了敏捷基础类库。 敏捷基础类库 Kent Beck 等的 （《敏捷宣言》）。 敏捷框架类库 Jeff Sutherland &amp; Ken Schwaber Kent Beck （《拥抱变化：解析极限编程》） Mike Cohn （《用户故事与敏捷方法》）（《敏捷估算与规划》） David Anderson （《看板方法》） Mary Poppendieck （《精益软件开发》） Craig Larman 的 Large Scale Scrum Dean Leffingwell 的 SAFe 敏捷扩展类库 野中郁次郎和竹内宏高《新的新产品开发游戏》《场理论》 Henrik Kniberg （《硝烟中的 Scrum 和 XP 》） Kenny Rubin （《Scrum 精髓》） Jeff Patton （《用户故事地图》） Mitch Lacey （《Scrum 实战指南》） Ken Schwaber （《Scrum 敏捷项目管理》） Mike Cohn （《Scrum 敏捷软件开发》） Eric Ries （《精益创业》） Ellen Gottesdiener Jezz Humble （《持续交付》） 《戴明14条》 艾永亮《腾讯之道》 何勉《精益产品开发原则、方法与实施》 精益类库 大野耐一 《丰田生产方式》《现场管理》 新乡重夫《从 IE 的角度看丰田生产方式》 James Womack （《改变世界的机器》）（《精益思想》） Jeffery Liker （《丰田模式》）系列 John Shook （A3 报告）（价值流图） 引导与心理学类库 NLP 神经语言程式 世界咖啡 六顶思考帽 管理与变革类库 Chip &amp; Dan Heath （《瞬变》） Jurgen Appelo （《管理3.0》） Jurgen Appelo （《变革管理3.0》） Daniel Pink （《驱动力》） （《重新定义公司》） 敏捷模式类库 Scrum 本身就是个模式 《用户故事地图》也是模式 Linda Rising 本课程中的 Scrum 子模式，例如故事泳道、一人天任务、随机一分钟项目经理。 敏捷教练方法类库 Lyssa Adkins 修身类库 《大学》《中庸》《论语》《孟子》 《王阳明全集》 《心经》《金刚经》 《圣经》 阿德勒《超越自卑》 《人生五大问题》 斯蒂芬柯维《七个习惯》 《红与黑》 《基督山伯爵》 《悲惨世界》 《百年孤独》 《活着》 《常识》 而在设计敏捷工作方法的架构时，可以基于上面提到的敏捷框架中的一个或多个。可以使用的思维线索有： 软件开发的阶段：概念，机会，策略，需求，方案，计划，实施，验证，部署，维护，退役。 PDCA 5W2H 在做敏捷工作方法的实施时, 第一步是需求： 与关键人员交流，了解问题与目标 这一步要放下敏捷的代码，倾听了解问题与目标本身。 第二步是制定解决方案： 根据现状，参考敏捷方法，制定关键举措。 使用类库和框架，制定架构。 敏捷工作方法的编码就是用上面的各种类库和框架，生成适合组织和团队的可执行的敏捷方法，包括架构和详细实现。执行的环境是团队中每个人的大脑。 编辑，是把方案细化的过程： 把敏捷方法动作化，做好剧本。无剧本，不操作。 为每一次谈话做好充分准备。 编译，是与团队中所有人交流的过程，使所有人理解敏捷方法： 可以是讨论，针对某个具体变化的方案与执行。 可以是培训，介绍整体或某个环节的工作方法。 可以是一对一交流，让方法切实而不只是形式上发生。 链接，是处理与现状和与已有工作方法的冲突： 分析问题，解决问题。 调整“代码” 运行，是新方法的执行： 落实每一个动作，并检查调整。 编辑、编译、链接、运行会反复多次进行，跟程序员写代码没有区别。]]></content>
      <categories>
        <category>敏捷Scrum</category>
        <category>敏捷教练和 ScrumMaster</category>
      </categories>
      <tags>
        <tag>敏捷</tag>
        <tag>Scrum</tag>
        <tag>敏捷教练和 ScrumMaster</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[设计模式-微服务-网关模式]]></title>
    <url>%2F2017%2F10%2F12%2F%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F-%E5%BE%AE%E6%9C%8D%E5%8A%A1-%E7%BD%91%E5%85%B3%E6%A8%A1%E5%BC%8F%2F</url>
    <content type="text"><![CDATA[定义API网关是一个服务器，它是系统中的单个入口点，用户对API网关进行单一呼叫，然后API网关调用每个相关的微服务器。它类似于面向对象设计的Facade模式。API网关封装内部系统架构，并提供针对每个客户端定制的API。它可能还有其他的责任，如身份验证，监控，负载平衡，缓存，请求整形和管理，以及静态响应处理。 优缺点使用API​​网关的主要优点是它封装了应用程序的内部结构。客户只需与网关进行通话，而不必调用特定的服务。API网关为每种类型的客户端提供了特定的API。这减少了客户端和应用程序之间的往返次数。它还简化了客户端代码。 API网关也有一些缺点。它是另一个高度可用的组件，必须开发，部署和管理。还有一个风险是API网关成为开发瓶颈。开发人员必须更新API网关以暴露每个微服务端点。重要的是更新API网关的过程尽可能轻。否则，开发人员将被迫排队等待更新网关。尽管存在这些缺点，但是对于大多数现实世界的应用来说，使用API​​网关是合理的。 类图]]></content>
      <categories>
        <category>设计模式</category>
        <category>微服务</category>
        <category>网关</category>
      </categories>
      <tags>
        <tag>微服务</tag>
        <tag>设计模式</tag>
        <tag>网关</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[Java8 日期/时间（Date Time）API指南]]></title>
    <url>%2F2017%2F09%2F19%2FJava8-%E6%97%A5%E6%9C%9F-%E6%97%B6%E9%97%B4%EF%BC%88Date-Time%EF%BC%89API%E6%8C%87%E5%8D%97%2F</url>
    <content type="text"><![CDATA[为什么我们需要新的Java日期/时间API？在开始研究Java 8日期/时间API之前，让我们先来看一下为什么我们需要这样一个新的API。在Java中，现有的与日期和时间相关的类存在诸多问题，其中有：1、Java的日期/时间类的定义并不一致，在java.util和java.sql的包中都有日期类，此外用于格式化和解析的类在java.text包中定义。2、java.util.Date同时包含日期和时间，而java.sql.Date仅包含日期，将其纳入java.sql包并不合理。另外这两个类都有相同的名字，这本身就是一个非常糟糕的设计。3、对于时间、时间戳、格式化以及解析，并没有一些明确定义的类。对于格式化和解析的需求，我们有java.text.DateFormat抽象类，但通常情况下，SimpleDateFormat类被用于此类需求。4、所有的日期类都是可变的，因此他们都不是线程安全的，这是Java日期类最大的问题之一。5、日期类并不提供国际化，没有时区支持，因此Java引入了java.util.Calendar和java.util.TimeZone类，但他们同样存在上述所有的问题。在现有的日期和日历类中定义的方法还存在一些其他的问题，但以上问题已经很清晰地表明：Java需要一个健壮的日期/时间类。这也是为什么Joda Time在Java日期/时间需求中扮演了高质量替换的重要角色。 Java 8日期/时间API设计原则1、不变性：新的日期/时间API中，所有的类都是不可变的，这对多线程环境有好处。2、关注点分离：新的API将人可读的日期时间和机器时间（unix timestamp）明确分离，它为日期（Date）、时间（Time）、日期时间（DateTime）、时间戳（unix timestamp）以及时区定义了不同的类。3、清晰：在所有的类中，方法都被明确定义用以完成相同的行为。举个例子，要拿到当前实例我们可以使用now()方法，在所有的类中都定义了format()和parse()方法，而不是像以前那样专门有一个独立的类。为了更好的处理问题，所有的类都使用了工厂模式和策略模式，一旦你使用了其中某个类的方法，与其他类协同工作并不困难。4、实用操作：所有新的日期/时间API类都实现了一系列方法用以完成通用的任务，如：加、减、格式化、解析、从日期/时间中提取单独部分，等等。5、可扩展性：新的日期/时间API是工作在ISO-8601日历系统上的，但我们也可以将其应用在非IOS的日历上。 Java日期/时间API包Java日期/时间API包含以下相应的包。1、java.time包：这是新的Java日期/时间API的基础包，所有的主要基础类都是这个包的一部分，如：LocalDate, LocalTime, LocalDateTime, Instant, Period, Duration等等。所有这些类都是不可变的和线程安全的，在绝大多数情况下，这些类能够有效地处理一些公共的需求。2、java.time.chrono包：这个包为非ISO的日历系统定义了一些泛化的API，我们可以扩展AbstractChronology类来创建自己的日历系统。3、java.time.format包：这个包包含能够格式化和解析日期时间对象的类，在绝大多数情况下，我们不应该直接使用它们，因为java.time包中相应的类已经提供了格式化和解析的方法。4、java.time.temporal包：这个包包含一些时态对象，我们可以用其找出关于日期/时间对象的某个特定日期或时间，比如说，可以找到某月的第一天或最后一天。你可以非常容易地认出这些方法，因为它们都具有“withXXX”的格式。5、java.time.zone包：这个包包含支持不同时区以及相关规则的类。 Java日期/时间API示例如何在java8中获取当天的日期java8中有个叫LocalDate的类，能用来表示今天的日期。这个类与java.util.Date略有不同，因为它只包含日期，没有时间。 LocalDate today = LocalDate.now(); -- 2017-09-19 如何在java8中获取当前的年月日LocalDate类中提供了一些很方便的方法可以用来提取年月日以及其他的日期属性,特别方便，只需要使用对应的getter方法就可以了，非常直观。 LocalDate today = LocalDate.now(); int year = today.getYear(); int month = today.getMonthValue(); int day = today.getDayOfMonth(); System.out.println(year); System.out.println(month); System.out.println(day); 在java8中如何获取某个特定的日期通过另一个方法，可以创建出任意一个日期，它接受年月日的参数，然后返回一个等价的LocalDate实例。在这个方法里，需要的日期你填写什么就是什么，不想之前的API中月份必须从0开始。 LocalDate birthDay = LocalDate.of(2001, 1, 1); System.out.println(birthDay); 在java8中检查两个日期是否相等LocalDate重写了equals方法来进行日期的比较。 LocalDate todayEq = LocalDate.of(2017,9,19); System.out.println(todayEq.equals(today)); 在java8中如何检查重复事件，比如生日在java中还有一个与时间日期相关的任务就是检查重复事件，比如每月的账单日如何在java中判断是否是某个节日或者重复事件，使用MonthDay类。这个类由月日组合，不包含年信息，可以用来代表每年重复出现的一些日期或其他组合。他和新的日期库中的其他类一样也都是不可变且线程安全的，并且它还是一个值类（value class）。 MonthDay birth_Day = MonthDay.of(9,19); MonthDay to_Day = MonthDay.from(today); if(birth_Day.equals(to_Day)) { System.out.println(&quot;今天是你的生日&quot;); }else { System.out.println(&quot;今天不是你的生日&quot;); } 如何在java8中获取当前时间这个与第一个例子获取当前日期非常相似，这里用的是LocalTime类，默认的格式是hh:mm:ss:nnn LocalTime now = LocalTime.now(); System.out.println(now); --- 17:42:53.966 如何增加时间里面的小时数很多时候需要对时间进行操作，比如加一个小时来计算之后的时间，java8提供了更方便的方法 如plusHours，这些方法返回的是一个新的LocalTime实例的引用，因为LocalTime是不可变的。 LocalTime now = LocalTime.now(); System.out.println(&quot;当前时间：&quot; + now); LocalTime two = now.plusHours(2); System.out.println(&quot;2小时后的时间：&quot; + two); --- 当前时间：17:45:12.091 2小时后的时间：19:45:12.091 在java8中使用时钟java8自带了Clock类，可以用来获取某个时区下（所以对时区是敏感的）当前的瞬时时间、日期。用来代替System.currentTimelnMillis()与TimeZone.getDefault()方法。 Clock clock = Clock.systemUTC(); System.out.println(clock); -- SystemClock[Z] 在java中如何判断某个日期在另一个日期的前面还是后面如何判断某个日期在另一个日期的前面还是后面或者相等，在java8中，LocalDate类中使用isBefore()、isAfter()、equals()方法来比较两个日期。如果调用方法的那个日期比给定的日期要早的话，isBefore()方法会返回true。equals()方法在前面的例子中已经说明了。 LocalTime now = LocalTime.now(); System.out.println(&quot;当前时间：&quot; + now); LocalTime two = now.plusHours(2); System.out.println(&quot;2小时后的时间：&quot; + two); System.out.println(now.isBefore(two)); --- 当前时间：17:49:21.295 2小时后的时间：19:49:21.295 true 在java8中处理不同的时区java8中不仅将日期和时间进行了分离，同时还有时区。比如ZonId代表的是某个特定时区，ZonedDateTime代表带时区的时间，等同于以前的GregorianCalendar类。使用该类，可以将本地时间转换成另一个时区中的对应时间。 LocalDateTime localDateTime = LocalDateTime.now(); ZoneId zone = ZoneId.of(ZoneId.SHORT_IDS.get(&quot;ACT&quot;)); ZonedDateTime zdt = ZonedDateTime.of(localDateTime, zone); System.out.println(&quot;特定时区时间为：&quot; + zdt); --- 特定时区时间为：2017-09-19T17:59:10.288+09:30[Australia/Darwin] 如何表示固定的日期，比如信用卡过期时间正如MonthDay表示的是某个重复出现的日子，YearMonth是另外一个组合，代表的是像信用卡还款日，定期存款到期日，options到期日这类的日期。你可以用这个类找出这个月有多少天，LengthOfMonth()这个方法返回的是这个YearMonth实例有多少天，这对于检查2月是否润2月很有用。 YearMonth currentYearMonth = YearMonth.now(); System.out.printf(&quot;这个月的是%s有%d天&quot;,currentYearMonth,currentYearMonth.lengthOfMonth()); System.out.println( &quot;currentYearMonth.atEndOfMonth()：&quot; + currentYearMonth.atEndOfMonth()); YearMonth creditCartExpiry = YearMonth.of(2018, Month.OCTOBER); System.out.printf(&quot;你选择的年月日期是%s %n &quot;,creditCartExpiry); --- 这个月的是2017-09有30天 currentYearMonth.atEndOfMonth()：2017-09-30 你选择的年月日期是2018-10 如何在java8中检查闰年LocalDate类由一个isLeapYear()方法来返回当前LocalDate对应的那年是否是闰年。 LocalDate today = LocalDate.now(); System.out.println(today.isLeapYear()); --- false 计算两个日期之间包含多少天，多少月计算两个日期之间包含多少天、周、月、年。可以用java.time.Period类完成该功能。下面例子中将计算日期与将来的日期之间一共有几个月。 LocalDate today = LocalDate.now(); LocalDate date1 = LocalDate.of(2017, Month.JULY, 12); Period period= Period.between(today, date1); System.out.println(period.getDays()); System.out.println(period.getMonths()); --- -7 -2 在java8中获取当前时间戳java8获取时间戳特别简单。Instant类由一个静态的工厂方法now()可以返回当前时间戳 Instant it = Instant.now(); System.out.println(it); 可以看到，当前时间戳是包含日期和时间的，与java.util.Date很类似，事实上Instant就是java8以前的Date，可以使用这个两个类中的方法在这两个类型之间进行转换，比如Date.from(Instant)就是用来把Instant转换成java.util.date的，而Date。toInstant()就是将Date转换成Instant的 如何在java8中使用预定义的格式器来对日期进行解析/格式化在java8之前，时间日期的格式化非常麻烦，经常使用SimpleDateFormat来进行格式化，但是SimpleDateFormat并不是线程安全的。在java8中，引入了一个全新的线程安全的日期与时间格式器。并且预定义好了格式。比如，本例中使用的BASICISODATE格式会将20160414格式化成2016-04-14 String day = &quot;20130923&quot;; LocalDate formatterd = LocalDate.parse(day, DateTimeFormatter.BASIC_ISO_DATE); System.out.println(formatterd); --- 2013-09-23 如何在java中使用自定义的格式器来解析日期 在上例中，我们使用了预置的时间日期格式器来解析日期字符串了，但是有时预置的不能满足的时候就需要我们自定义日期格式器了，下面的例子中的日期格式是”MM dd yyyy”.你可以给DateTimeFormatter的ofPattern静态方法()传入任何的模式，它会返回一个实例，这个模式的字面量与前例中是相同的。比如M代表月，m仍代表分，无效的模式会抛异常DateTimeParseException。 String day1 = &quot;2013 09 23&quot;; try { DateTimeFormatter df = DateTimeFormatter.ofPattern(&quot;yyyy MM dd&quot;); LocalDate holiday = LocalDate.parse(day1,df); System.out.println(holiday); } catch (DateTimeParseException e) { // TODO: handle exception } --- 2013-09-23 如何在java8中对日期进行格式化，转换成字符串 前面的两个例子中，我们主要是对日期字符串来进行解析转换成日期，在这个例子我们相反，是把日期转换成字符。这里我们有个LocalDateTime类的实例，我们要把他转换成一个格式化好的日期串，与前例相同的是，我们仍需要制定模式串去创建一个DateTimeFormatter类的实例，但调用的是LocalDate.format()。这个方法会返回一个代表当前日期的字符串，对应的模式就是传入的DateTimeFormatter实例中定义好的。 LocalDateTime aDate = LocalDateTime.now(); try { DateTimeFormatter df = DateTimeFormatter.ofPattern(&quot;yyyy MM dd&quot;); System.out.println(aDate.format(df)); } catch (Exception e) { // TODO: handle exception } --- 2017 09 19]]></content>
      <categories>
        <category>java</category>
        <category>java8</category>
      </categories>
      <tags>
        <tag>Java8 日期/时间工具类</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[Java 8 中的 Streams API 详解]]></title>
    <url>%2F2017%2F09%2F19%2FJava8-%E4%B8%AD%E7%9A%84Streams%20API%E6%8C%87%E5%8D%97%2F</url>
    <content type="text"><![CDATA[为什么需要 StreamStream 作为 Java 8 的一大亮点，它与 java.io 包里的 InputStream 和 OutputStream 是完全不同的概念。它也不同于 StAX 对 XML 解析的 Stream，也不是 Amazon Kinesis 对大数据实时处理的 Stream。Java 8 中的 Stream 是对集合（Collection）对象功能的增强，它专注于对集合对象进行各种非常便利、高效的聚合操作（aggregate operation），或者大批量数据操作 (bulk data operation)。Stream API 借助于同样新出现的 Lambda 表达式，极大的提高编程效率和程序可读性。同时它提供串行和并行两种模式进行汇聚操作，并发模式能够充分利用多核处理器的优势，使用 fork/join 并行方式来拆分任务和加速处理过程。通常编写并行代码很难而且容易出错, 但使用 Stream API 无需编写一行多线程的代码，就可以很方便地写出高性能的并发程序。所以说，Java 8 中首次出现的 java.util.stream 是一个函数式语言+多核时代综合影响的产物。 什么是聚合操作在传统的 J2EE 应用中，Java 代码经常不得不依赖于关系型数据库的聚合操作来完成诸如： 客户每月平均消费金额最昂贵的在售商品本周完成的有效订单（排除了无效的）取十个数据样本作为首页推荐 这类的操作。但在当今这个数据大爆炸的时代，在数据来源多样化、数据海量化的今天，很多时候不得不脱离 RDBMS，或者以底层返回的数据为基础进行更上层的数据统计。而 Java 的集合 API 中，仅仅有极少量的辅助型方法，更多的时候是程序员需要用 Iterator 来遍历集合，完成相关的聚合应用逻辑。这是一种远不够高效、笨拙的方法。在 Java 7 中，如果要发现 type 为 grocery 的所有交易，然后返回以交易值降序排序好的交易 ID 集合，我们需要这样写：清单 1. Java 7 的排序、取值实现 List&lt;Transaction&gt; groceryTransactions = new Arraylist&lt;&gt;(); for(Transaction t: transactions){ if(t.getType() == Transaction.GROCERY){ groceryTransactions.add(t); } } Collections.sort(groceryTransactions, new Comparator(){ public int compare(Transaction t1, Transaction t2){ return t2.getValue().compareTo(t1.getValue()); } }); List&lt;Integer&gt; transactionIds = new ArrayList&lt;&gt;(); for(Transaction t: groceryTransactions){ transactionsIds.add(t.getId()); } 而在 Java 8 使用 Stream，代码更加简洁易读；而且使用并发模式，程序执行速度更快。清单 2. Java 8 的排序、取值实现 List&lt;Integer&gt; transactionsIds = transactions.parallelStream(). filter(t -&gt; t.getType() == Transaction.GROCERY). sorted(comparing(Transaction::getValue).reversed()). map(Transaction::getId). collect(toList()); Stream 总览什么是流Stream 不是集合元素，它不是数据结构并不保存数据，它是有关算法和计算的，它更像一个高级版本的 Iterator。原始版本的 Iterator，用户只能显式地一个一个遍历元素并对其执行某些操作；高级版本的 Stream，用户只要给出需要对其包含的元素执行什么操作，比如 “过滤掉长度大于 10 的字符串”、“获取每个字符串的首字母”等，Stream 会隐式地在内部进行遍历，做出相应的数据转换。Stream 就如同一个迭代器（Iterator），单向，不可往复，数据只能遍历一次，遍历过一次后即用尽了，就好比流水从面前流过，一去不复返。而和迭代器又不同的是，Stream 可以并行化操作，迭代器只能命令式地、串行化操作。顾名思义，当使用串行方式去遍历时，每个 item 读完后再读下一个 item。而使用并行去遍历时，数据会被分成多个段，其中每一个都在不同的线程中处理，然后将结果一起输出。Stream 的并行操作依赖于 Java7 中引入的 Fork/Join 框架（JSR166y）来拆分任务和加速处理过程。Java 的并行 API 演变历程基本如下： 1.0-1.4 中的 java.lang.Thread5.0 中的 java.util.concurrent6.0 中的 Phasers 等7.0 中的 Fork/Join 框架8.0 中的 Lambda Stream 的另外一大特点是，数据源本身可以是无限的。 流的构成当我们使用一个流的时候，通常包括三个基本步骤：获取一个数据源（source）→ 数据转换→执行操作获取想要的结果，每次转换原有 Stream 对象不改变，返回一个新的 Stream 对象（可以有多次转换），这就允许对其操作可以像链条一样排列，变成一个管道，如下图所示。图 1. 流管道 (Stream Pipeline) 的构成 有多种方式生成 Stream Source：从 Collection 和数组 Collection.stream() Collection.parallelStream() Arrays.stream(T array) or Stream.of() 从 BufferedReader java.io.BufferedReader.lines() 静态工厂 java.util.stream.IntStream.range() java.nio.file.Files.walk() 自己构建 java.util.Spliterator 其它 Random.ints() BitSet.stream() Pattern.splitAsStream(java.lang.CharSequence) JarFile.stream() 流的操作类型分为两种：Intermediate 一个流可以后面跟随零个或多个 intermediate 操作。其目的主要是打开流，做出某种程度的数据映射/过滤，然后返回一个新的流，交给下一个操作使用。这类操作都是惰性化的（lazy），就是说，仅仅调用到这类方法，并没有真正开始流的遍历。 Terminal 一个流只能有一个 terminal 操作，当这个操作执行后，流就被使用“光”了，无法再被操作。所以这必定是流的最后一个操作。Terminal 操作的执行，才会真正开始流的遍历，并且会生成一个结果，或者一个 side effect。 在对于一个 Stream 进行多次转换操作 (Intermediate 操作)，每次都对 Stream 的每个元素进行转换，而且是执行多次，这样时间复杂度就是 N（转换次数）个 for 循环里把所有操作都做掉的总和吗？其实不是这样的，转换操作都是 lazy 的，多个转换操作只会在 Terminal 操作的时候融合起来，一次循环完成。我们可以这样简单的理解，Stream 里有个操作函数的集合，每次转换操作就是把转换函数放入这个集合中，在 Terminal 操作的时候循环 Stream 对应的集合，然后对每个元素执行所有的函数。还有一种操作被称为short-circuiting用以指 对于一个 intermediate 操作，如果它接受的是一个无限大（infinite/unbounded）的 Stream，但返回一个有限的新 Stream。对于一个 terminal 操作，如果它接受的是一个无限大的 Stream，但能在有限的时间计算出结果。当操作一个无限大的 Stream，而又希望在有限时间内完成操作，则在管道内拥有一个 short-circuiting 操作是必要非充分条件。 清单 3. 一个流操作的示例 int sum = widgets.stream() .filter(w -&gt; w.getColor() == RED) .mapToInt(w -&gt; w.getWeight()) .sum(); stream() 获取当前小物件的 source，filter 和 mapToInt 为 intermediate 操作，进行数据筛选和转换，最后一个 sum() 为 terminal 操作，对符合条件的全部小物件作重量求和。 流的使用详解简单说，对 Stream 的使用就是实现一个 filter-map-reduce 过程，产生一个最终结果，或者导致一个副作用（side effect）。 流的构造与转换下面提供最常见的几种构造 Stream 的样例。 构造流的几种常见方法// 1. Individual values Stream stream = Stream.of(&quot;a&quot;, &quot;b&quot;, &quot;c&quot;); // 2. Arrays String [] strArray = new String[] {&quot;a&quot;, &quot;b&quot;, &quot;c&quot;}; stream = Stream.of(strArray); stream = Arrays.stream(strArray); // 3. Collections List&lt;String&gt; list = Arrays.asList(strArray); stream = list.stream(); 需要注意的是，对于基本数值型，目前有三种对应的包装类型 Stream：IntStream、LongStream、DoubleStream。当然我们也可以用 Stream、Stream &gt;、Stream，但是 boxing 和 unboxing 会很耗时，所以特别为这三种基本数值型提供了对应的 Stream。Java 8 中还没有提供其它数值型 Stream，因为这将导致扩增的内容较多。而常规的数值型聚合运算可以通过上面三种 Stream 进行。 数值流的构造IntStream.of(new int[]{1, 2, 3}).forEach(System.out::println); IntStream.range(1, 3).forEach(System.out::println); IntStream.rangeClosed(1, 3).forEach(System.out::println); 流转换为其它数据结构// 1. Array String[] strArray1 = stream.toArray(String[]::new); // 2. Collection List&lt;String&gt; list1 = stream.collect(Collectors.toList()); List&lt;String&gt; list2 = stream.collect(Collectors.toCollection(ArrayList::new)); Set set1 = stream.collect(Collectors.toSet()); Stack stack1 = stream.collect(Collectors.toCollection(Stack::new)); // 3. String String str = stream.collect(Collectors.joining()).toString(); 一个 Stream 只可以使用一次，上面的代码为了简洁而重复使用了数次。 流的操作接下来，当把一个数据结构包装成 Stream 后，就要开始对里面的元素进行各类操作了。常见的操作可以归类如下。 Intermediate map (mapToInt, flatMap 等)、 filter、 distinct、 sorted、 peek、 limit、 skip、 parallel、 sequential、 unordered Terminal forEach、 forEachOrdered、 toArray、 reduce、 collect、 min、 max、 count、 anyMatch、 allMatch、 noneMatch、 findFirst、 findAny、 iterator Short-circuiting anyMatch、 allMatch、 noneMatch、 findFirst、 findAny、 limit 我们下面看一下 Stream 的比较典型用法。 map/flatMap我们先来看 map。如果你熟悉 scala 这类函数式语言，对这个方法应该很了解，它的作用就是把 input Stream 的每一个元素，映射成 output Stream 的另外一个元素。转换大写 List&lt;String&gt; output = wordList.stream(). map(String::toUpperCase). collect(Collectors.toList()); 这段代码把所有的单词转换为大写。 平方数 List&lt;Integer&gt; nums = Arrays.asList(1, 2, 3, 4); List&lt;Integer&gt; squareNums = nums.stream(). map(n -&gt; n * n). collect(Collectors.toList()); 这段代码生成一个整数 list 的平方数 {1, 4, 9, 16}。从上面例子可以看出，map 生成的是个 1:1 映射，每个输入元素，都按照规则转换成为另外一个元素。还有一些场景，是一对多映射关系的，这时需要 flatMap。一对多 Stream&lt;List&lt;Integer&gt;&gt; inputStream = Stream.of( Arrays.asList(1), Arrays.asList(2, 3), Arrays.asList(4, 5, 6) ); Stream&lt;Integer&gt; outputStream = inputStream. flatMap((childList) -&gt; childList.stream()); flatMap 把 input Stream 中的层级结构扁平化，就是将最底层元素抽出来放到一起，最终 output 的新 Stream 里面已经没有 List 了，都是直接的数字。 filterfilter 对原始 Stream 进行某项测试，通过测试的元素被留下来生成一个新 Stream。留下偶数 Integer[] sixNums = {1, 2, 3, 4, 5, 6}; Integer[] evens = Stream.of(sixNums).filter(n -&gt; n%2 == 0).toArray(Integer[]::new); 经过条件“被 2 整除”的 filter，剩下的数字为 {2, 4, 6}。把单词挑出来 List&lt;String&gt; output = reader.lines(). flatMap(line -&gt; Stream.of(line.split(REGEXP))). filter(word -&gt; word.length() &gt; 0). collect(Collectors.toList()); 这段代码首先把每行的单词用 flatMap 整理到新的 Stream，然后保留长度不为 0 的，就是整篇文章中的全部单词了。 forEachforEach 方法接收一个 Lambda 表达式，然后在 Stream 的每一个元素上执行该表达式。打印姓名（forEach 和 pre-java8 的对比） // Java 8 roster.stream() .filter(p -&gt; p.getGender() == Person.Sex.MALE) .forEach(p -&gt; System.out.println(p.getName())); // Pre-Java 8 for (Person p : roster) { if (p.getGender() == Person.Sex.MALE) { System.out.println(p.getName()); } } 对一个人员集合遍历，找出男性并打印姓名。可以看出来，forEach 是为 Lambda 而设计的，保持了最紧凑的风格。而且 Lambda 表达式本身是可以重用的，非常方便。当需要为多核系统优化时，可以 parallelStream().forEach()，只是此时原有元素的次序没法保证，并行的情况下将改变串行时操作的行为，此时 forEach 本身的实现不需要调整，而 Java8 以前的 for 循环 code 可能需要加入额外的多线程逻辑。但一般认为，forEach 和常规 for 循环的差异不涉及到性能，它们仅仅是函数式风格与传统 Java 风格的差别。另外一点需要注意，forEach 是 terminal 操作，因此它执行后，Stream 的元素就被“消费”掉了，你无法对一个 Stream 进行两次 terminal 运算。下面的代码是错误的： stream.forEach(element -&gt; doOneThing(element)); stream.forEach(element -&gt; doAnotherThing(element)); 相反，具有相似功能的 intermediate 操作 peek 可以达到上述目的。如下是出现在该 api javadoc 上的一个示例。 peek 对每个元素执行操作并返回一个新的 Stream Stream.of(&quot;one&quot;, &quot;two&quot;, &quot;three&quot;, &quot;four&quot;) .filter(e -&gt; e.length() &gt; 3) .peek(e -&gt; System.out.println(&quot;Filtered value: &quot; + e)) .map(String::toUpperCase) .peek(e -&gt; System.out.println(&quot;Mapped value: &quot; + e)) .collect(Collectors.toList()); forEach 不能修改自己包含的本地变量值，也不能用 break/return 之类的关键字提前结束循环。 findFirst这是一个 termimal 兼 short-circuiting 操作，它总是返回 Stream 的第一个元素，或者空。这里比较重点的是它的返回值类型：Optional。这也是一个模仿 Scala 语言中的概念，作为一个容器，它可能含有某值，或者不包含。使用它的目的是尽可能避免 NullPointerException。 Optional 的两个用例 String strA = &quot; abcd &quot;, strB = null; print(strA); print(&quot;&quot;); print(strB); getLength(strA); getLength(&quot;&quot;); getLength(strB); public static void print(String text) { // Java 8 Optional.ofNullable(text).ifPresent(System.out::println); // Pre-Java 8 if (text != null) { System.out.println(text); } } public static int getLength(String text) { // Java 8 return Optional.ofNullable(text).map(String::length).orElse(-1); // Pre-Java 8 // return if (text != null) ? text.length() : -1; }; 在更复杂的 if (xx != null) 的情况中，使用 Optional 代码的可读性更好，而且它提供的是编译时检查，能极大的降低 NPE 这种 Runtime Exception 对程序的影响，或者迫使程序员更早的在编码阶段处理空值问题，而不是留到运行时再发现和调试。Stream 中的 findAny、max/min、reduce 等方法等返回 Optional 值。还有例如 IntStream.average() 返回 OptionalDouble 等等。 reduce这个方法的主要作用是把 Stream 元素组合起来。它提供一个起始值（种子），然后依照运算规则（BinaryOperator），和前面 Stream 的第一个、第二个、第 n 个元素组合。从这个意义上说，字符串拼接、数值的 sum、min、max、average 都是特殊的 reduce。例如 Stream 的 sum 就相当于 Integer sum = integers.reduce(0, (a, b) -&gt; a+b); 或 Integer sum = integers.reduce(0, Integer::sum); 也有没有起始值的情况，这时会把 Stream 的前面两个元素组合起来，返回的是 Optional。 reduce 的用例 // 字符串连接，concat = &quot;ABCD&quot; String concat = Stream.of(&quot;A&quot;, &quot;B&quot;, &quot;C&quot;, &quot;D&quot;).reduce(&quot;&quot;, String::concat); // 求最小值，minValue = -3.0 double minValue = Stream.of(-1.5, 1.0, -3.0, -2.0).reduce(Double.MAX_VALUE, Double::min); // 求和，sumValue = 10, 有起始值 int sumValue = Stream.of(1, 2, 3, 4).reduce(0, Integer::sum); // 求和，sumValue = 10, 无起始值 sumValue = Stream.of(1, 2, 3, 4).reduce(Integer::sum).get(); // 过滤，字符串连接，concat = &quot;ace&quot; concat = Stream.of(&quot;a&quot;, &quot;B&quot;, &quot;c&quot;, &quot;D&quot;, &quot;e&quot;, &quot;F&quot;). filter(x -&gt; x.compareTo(&quot;Z&quot;) &gt; 0). reduce(&quot;&quot;, String::concat); 上面代码例如第一个示例的 reduce()，第一个参数（空白字符）即为起始值，第二个参数（String::concat）为 BinaryOperator。这类有起始值的 reduce() 都返回具体的对象。而对于第四个示例没有起始值的 reduce()，由于可能没有足够的元素，返回的是 Optional，请留意这个区别。 limit/skiplimit 返回 Stream 的前面 n 个元素；skip 则是扔掉前 n 个元素（它是由一个叫 subStream 的方法改名而来）。limit 和 skip 对运行次数的影响 public void testLimitAndSkip() { List&lt;Person&gt; persons = new ArrayList(); for (int i = 1; i &lt;= 10000; i++) { Person person = new Person(i, &quot;name&quot; + i); persons.add(person); } List&lt;String&gt; personList2 = persons.stream(). map(Person::getName).limit(10).skip(3).collect(Collectors.toList()); System.out.println(personList2); } private class Person { public int no; private String name; public Person (int no, String name) { this.no = no; this.name = name; } public String getName() { System.out.println(name); return name; } } 输出结果为： name1name2name3name4name5name6name7name8name9name10[name4, name5, name6, name7, name8, name9, name10] 这是一个有 10，000 个元素的 Stream，但在 short-circuiting 操作 limit 和 skip 的作用下，管道中 map 操作指定的 getName() 方法的执行次数为 limit 所限定的 10 次，而最终返回结果在跳过前 3 个元素后只有后面 7 个返回。有一种情况是 limit/skip 无法达到 short-circuiting 目的的，就是把它们放在 Stream 的排序操作后，原因跟 sorted 这个 intermediate 操作有关：此时系统并不知道 Stream 排序后的次序如何，所以 sorted 中的操作看上去就像完全没有被 limit 或者 skip 一样。 limit 和 skip 对 sorted 后的运行次数无影响 List&lt;Person&gt; persons = new ArrayList(); for (int i = 1; i &lt;= 5; i++) { Person person = new Person(i, &quot;name&quot; + i); persons.add(person); } List&lt;Person&gt; personList2 = persons.stream().sorted((p1, p2) -&gt; p1.getName().compareTo(p2.getName())).limit(2).collect(Collectors.toList()); System.out.println(personList2); 上面的示例对清单 13 做了微调，首先对 5 个元素的 Stream 排序，然后进行 limit 操作。输出结果为： name2name1name3name2name4name3name5name4[stream.StreamDW$Person@816f27d, stream.StreamDW$Person@87aac27] 即虽然最后的返回元素数量是 2，但整个管道中的 sorted 表达式执行次数没有像前面例子相应减少。最后有一点需要注意的是，对一个 parallel 的 Steam 管道来说，如果其元素是有序的，那么 limit 操作的成本会比较大，因为它的返回对象必须是前 n 个也有一样次序的元素。取而代之的策略是取消元素间的次序，或者不要用 parallel Stream。 sorted对 Stream 的排序通过 sorted 进行，它比数组的排序更强之处在于你可以首先对 Stream 进行各类 map、filter、limit、skip 甚至 distinct 来减少元素数量后，再排序，这能帮助程序明显缩短执行时间。我们对清单 14 进行优化：清单 18. 优化：排序前进行 limit 和 skip List&lt;Person&gt; persons = new ArrayList(); for (int i = 1; i &lt;= 5; i++) { Person person = new Person(i, &quot;name&quot; + i); persons.add(person); } List&lt;Person&gt; personList2 = persons.stream().limit(2).sorted((p1, p2) -&gt; p1.getName().compareTo(p2.getName())).collect(Collectors.toList()); System.out.println(personList2); 结果会简单很多： name2name1[stream.StreamDW$Person@6ce253f1, stream.StreamDW$Person@53d8d10a] 当然，这种优化是有 business logic 上的局限性的：即不要求排序后再取值。 min/max/distinctmin 和 max 的功能也可以通过对 Stream 元素先排序，再 findFirst 来实现，但前者的性能会更好，为 O(n)，而 sorted 的成本是 O(n log n)。同时它们作为特殊的 reduce 方法被独立出来也是因为求最大最小值是很常见的操作。找出最长一行的长度 BufferedReader br = new BufferedReader(new FileReader(&quot;c:\\SUService.log&quot;)); int longest = br.lines(). mapToInt(String::length). max(). getAsInt(); br.close(); System.out.println(longest); 下面的例子则使用 distinct 来找出不重复的单词。找出全文的单词，转小写，并排序 List&lt;String&gt; words = br.lines(). flatMap(line -&gt; Stream.of(line.split(&quot; &quot;))). filter(word -&gt; word.length() &gt; 0). map(String::toLowerCase). distinct(). sorted(). collect(Collectors.toList()); br.close(); System.out.println(words); MatchStream 有三个 match 方法，从语义上说：allMatch：Stream 中全部元素符合传入的 predicate，返回 trueanyMatch：Stream 中只要有一个元素符合传入的 predicate，返回 truenoneMatch：Stream 中没有一个元素符合传入的 predicate，返回 true它们都不是要遍历全部元素才能返回结果。例如 allMatch 只要一个元素不满足条件，就 skip 剩下的所有元素，返回 false。对清单 13 中的 Person 类稍做修改，加入一个 age 属性和 getAge 方法。使用 Match List&lt;Person&gt; persons = new ArrayList(); persons.add(new Person(1, &quot;name&quot; + 1, 10)); persons.add(new Person(2, &quot;name&quot; + 2, 21)); persons.add(new Person(3, &quot;name&quot; + 3, 34)); persons.add(new Person(4, &quot;name&quot; + 4, 6)); persons.add(new Person(5, &quot;name&quot; + 5, 55)); boolean isAllAdult = persons.stream(). allMatch(p -&gt; p.getAge() &gt; 18); System.out.println(&quot;All are adult? &quot; + isAllAdult); boolean isThereAnyChild = persons.stream(). anyMatch(p -&gt; p.getAge() &lt; 12); System.out.println(&quot;Any child? &quot; + isThereAnyChild); 输出结果： All are adult? falseAny child? true 进阶：自己生成流Stream.generate通过实现 Supplier 接口，你可以自己来控制流的生成。这种情形通常用于随机数、常量的 Stream，或者需要前后元素间维持着某种状态信息的 Stream。把 Supplier 实例传递给 Stream.generate() 生成的 Stream，默认是串行（相对 parallel 而言）但无序的（相对 ordered 而言）。由于它是无限的，在管道中，必须利用 limit 之类的操作限制 Stream 大小。生成 10 个随机整数 Random seed = new Random(); Supplier&lt;Integer&gt; random = seed::nextInt; Stream.generate(random).limit(10).forEach(System.out::println); //Another way IntStream.generate(() -&gt; (int) (System.nanoTime() % 100)). limit(10).forEach(System.out::println); Stream.generate() 还接受自己实现的 Supplier。例如在构造海量测试数据的时候，用某种自动的规则给每一个变量赋值；或者依据公式计算 Stream 的每个元素值。这些都是维持状态信息的情形。 自实现 Supplier Stream.generate(new PersonSupplier()). limit(10). forEach(p -&gt; System.out.println(p.getName() + &quot;, &quot; + p.getAge())); private class PersonSupplier implements Supplier&lt;Person&gt; { private int index = 0; private Random random = new Random(); @Override public Person get() { return new Person(index++, &quot;StormTestUser&quot; + index, random.nextInt(100)); } } 输出结果： StormTestUser1, 9StormTestUser2, 12StormTestUser3, 88StormTestUser4, 51StormTestUser5, 22StormTestUser6, 28StormTestUser7, 81StormTestUser8, 51StormTestUser9, 4StormTestUser10, 76 ##Stream.iterateiterate 跟 reduce 操作很像，接受一个种子值，和一个 UnaryOperator（例如 f）。然后种子值成为 Stream 的第一个元素，f(seed) 为第二个，f(f(seed)) 第三个，以此类推。24. 生成一个等差数列 Stream.iterate(0, n -&gt; n + 3).limit(10). forEach(x -&gt; System.out.print(x + &quot; &quot;));. 输出结果： 10 3 6 9 12 15 18 21 24 27 与 Stream.generate 相仿，在 iterate 时候管道必须有 limit 这样的操作来限制 Stream 大小。 进阶：用 Collectors 来进行 reduction 操作java.util.stream.Collectors 类的主要作用就是辅助进行各类有用的 reduction 操作，例如转变输出为 Collection，把 Stream 元素进行归组。groupingBy/partitioningBy按照年龄归组 Map&lt;Integer, List&lt;Person&gt;&gt; personGroups = Stream.generate(new PersonSupplier()). limit(100). collect(Collectors.groupingBy(Person::getAge)); Iterator it = personGroups.entrySet().iterator(); while (it.hasNext()) { Map.Entry&lt;Integer, List&lt;Person&gt;&gt; persons = (Map.Entry) it.next(); System.out.println(&quot;Age &quot; + persons.getKey() + &quot; = &quot; + persons.getValue().size()); } 上面的 code，首先生成 100 人的信息，然后按照年龄归组，相同年龄的人放到同一个 list 中，可以看到如下的输出： Age 0 = 2Age 1 = 2Age 5 = 2Age 8 = 1Age 9 = 1Age 11 = 2…… 按照未成年人和成年人归组 Map&lt;Boolean, List&lt;Person&gt;&gt; children = Stream.generate(new PersonSupplier()). limit(100). collect(Collectors.partitioningBy(p -&gt; p.getAge() &lt; 18)); System.out.println(&quot;Children number: &quot; + children.get(true).size()); System.out.println(&quot;Adult number: &quot; + children.get(false).size()); 输出结果： Children number: 23Adult number: 77 在使用条件“年龄小于 18”进行分组后可以看到，不到 18 岁的未成年人是一组，成年人是另外一组。partitioningBy 其实是一种特殊的 groupingBy，它依照条件测试的是否两种结果来构造返回的数据结构，get(true) 和 get(false) 能即为全部的元素对象。 #结束语总之，Stream 的特性可以归纳为： 不是数据结构 它没有内部存储，它只是用操作管道从 source（数据结构、数组、generator function、IO channel）抓取数据。 它也绝不修改自己所封装的底层数据结构的数据。例如 Stream 的 filter 操作会产生一个不包含被过滤元素的新 Stream，而不是从 source 删除那些元素。 所有 Stream 的操作必须以 lambda 表达式为参数 不支持索引访问你可以请求第一个元素，但无法请求第二个，第三个，或最后一个。不过请参阅下一项。很容易生成数组或者 List 惰性化很多 Stream 操作是向后延迟的，一直到它弄清楚了最后需要多少数据才会开始。Intermediate 操作永远是惰性化的。 并行能力当一个 Stream 是并行化的，就不需要再写多线程代码，所有对它的操作会自动并行进行的。 可以是无限的集合有固定大小，Stream 则不必。limit(n) 和 findFirst() 这类的 short-circuiting 操作可以对无限的 Stream 进行运算并很快完成。]]></content>
      <categories>
        <category>java</category>
        <category>java8</category>
      </categories>
      <tags>
        <tag>Java8 Streams java集合</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[轻松学习新代码库的六个步骤]]></title>
    <url>%2F2017%2F09%2F09%2F%E8%BD%BB%E6%9D%BE%E5%AD%A6%E4%B9%A0%E6%96%B0%E4%BB%A3%E7%A0%81%E5%BA%93%E7%9A%84%E5%85%AD%E4%B8%AA%E6%AD%A5%E9%AA%A4%2F</url>
    <content type="text"><![CDATA[学习新的代码库是一项艰巨的任务。如果你不能和创建该库的研发人员进行交流，自己研究该库是一个很复杂的过程。本文给出六个步骤指引开发者学习。 步骤一：创建业务词汇表单如果你是一位开发者，你或许会出席过一些软件设计会议，会议可能会涉及到创建新术语，以便于更好的软件设计交流。在创建该术语的同时可能会发生与该术语同义的情况，会议成员不可避免地讨论这些具有相同概念的术语，这会让人感到混乱。 这时，业务词汇表单就变得尤为重要，它能记录这些新的术语。在软件设计的每个阶段，你会不断碰到新的术语和概念。把这些术语保存起来非常重要，并且边学边存储，绝对有益无害。 业务词汇表单应该包含几个不同的列，分别是：“术语名称”、“语境”、“定义”。当你看到一个有趣的术语和短语时，可以更新该表单。该表单有可能包含大量的同义词，也有可能有对同一术语的不同定义解释。出现上述的情况，你需要结合上下文的语境进行分析使用。 步骤二：了解应用程序运行应用程序并且获知该程序提供的功能。如果你不知道该程序是做什么的，就无法在源代码中寻找有关信息。 步骤三：浏览有效的类库文档迄今为止，是不是任何的体系结构或设计类库文档的内容都是合理呢？这有待考量。类库文档是一个极好的资源。如果旧的体系架构已经历了数次修订，它就不再值得你花时间去阅读整个文档，不过，你可以大概浏览一下。如果你足够幸运，你可以在文档中遇到你所需的术语。 步骤四：做假设几乎所有的应用程序中，开发者都会碰到如下情况：环境的配置、I18N（语言的国际化）、应用程序的文件格式、用户界面、应用程序的启动和关闭。针对这些情况，可以进行假设。开发者可以假设应用程序中的任何一段代码块，哪个代码块是应用程序的核心，这个才是学习的重点。 步骤 五：定位第三方库文件代码库很有可能存在一些的依赖。如果检查到项目中包含第三方库文件，可以查看该库文件是如何与应用程序的功能联系起来的，某处的模块或组件是如何使用第三方库的。 步骤六：分析代码本部分列举几个选项来分析新的代码库： 1、目录以及文件架构可以把目录名中的一些术语添加到业务词汇表单中。文件架构可以提供一些基本的线索，如：前台代码及后台代码。它们可以分别放在独立的文件中。开发者会发现，凡具有特定功能的模块代码都被放在独立的文件夹中。按照这个线索，就知道如何进行查找了。 2、功能文件的映射在用户界面上写一些可执行的功能代码块。把重要的代码块放到一个单独的文件夹中，并对文件夹进行命名。这个文件夹有可能对团队中的其他人有用，他们可以把该功能应用到项目编程中。 3、单元测试如果采用单元测试，开发者可能会用到第三方框架。你可以用第三方框架来辅助测试。即使没有找到合适的框架，仍然可以来做单元测试。当然，你也可以不采用单元测试，但我依然推荐你用，因为有助于你对源代码中组件的理解。 4、注释源代码中可能包含一些注释，有的注释对开发人员很有帮助，有的会让人有所误导或有的注释可能过期了。如果你觉得注释有问题，你可以通过调试器追踪有关代码，了解相关代码的意思。如果你发现错误的注释，修改或删除它们。 5、可视化工具在新的代码库中使用语言代码分析工具。如：ObjectAid是一个极好的Java代码分析工具。这是 Eclipse IDE中的一个插件。你可以创建对象来协助类图，把java文件拉到类图中，就自动画出类图。 6、设置断点使用调试器，设置一些断点并运行查看。这是第一次学习新的代码基础。 结论上述的分析过程采用自上而下的方法，能够更好的帮助开发者学习新的代码库。]]></content>
      <tags>
        <tag>源码学习 架构师之路</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[分布式定时任务调度系统技术选型]]></title>
    <url>%2F2017%2F08%2F15%2F%E5%88%86%E5%B8%83%E5%BC%8F%E5%AE%9A%E6%97%B6%E4%BB%BB%E5%8A%A1%E6%96%B9%E6%A1%88%E6%8A%80%E6%9C%AF%E9%80%89%E5%9E%8B%2F</url>
    <content type="text"><![CDATA[我们先思考下面几个业务场景的解决方案: 支付系统每天凌晨1点跑批，进行一天清算，每月1号进行上个月清算 电商整点抢购，商品价格8点整开始优惠 12306购票系统，超过30分钟没有成功支付订单的，进行回收处理 商品成功发货后，需要向客户发送短信提醒 类似的业务场景非常多，我们怎么解决？ 为什么我们需要定时任务很多业务场景需要我们某一特定的时刻去做某件任务，定时任务解决的就是这种业务场景。一般来说，系统可以使用消息传递代替部分定时任务，两者有很多相似之处，可以相互替换场景。如，上面发货成功发短信通知客户的业务场景，我们可以在发货成功后发送MQ消息到队列，然后去消费mq消息，发送短信。但在某些场景下不能互换： a)时间驱动/事件驱动：内部系统一般可以通过时间来驱动，但涉及到外部系统，则只能使用时间驱动。如怕取外部网站价格，每小时爬一次b)批量处理/逐条处理：批量处理堆积的数据更加高效，在不需要实时性的情况下比消息中间件更有优势。而且有的业务逻辑只能批量处理。如移动每个月结算我们的话费c)实时性/非实时性：消息中间件能够做到实时处理数据，但是有些情况下并不需要实时，比如：vip升级d)系统内部/系统解耦：定时任务调度一般是在系统内部，而消息中间件可用于两个系统间 java有哪些定时任务的框架单机 timer：是一个定时器类，通过该类可以为指定的定时任务进行配置。TimerTask类是一个定时任务类，该类实现了Runnable接口，缺点异常未检查会中止线程 ScheduledExecutorService：相对延迟或者周期作为定时任务调度，缺点没有绝对的日期或者时间 spring定时框架：配置简单功能较多，如果系统使用单机的话可以优先考虑spring定时器 分布 Quartz：Java事实上的定时任务标准。但Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能 TBSchedule：阿里早期开源的分布式任务调度系统。代码略陈旧，使用timer而非线程池执行任务调度。众所周知，timer在处理异常状况时是有缺陷的。而且TBSchedule作业类型较为单一，只能是获取/处理数据一种模式。还有就是文档缺失比较严重 elastic-job：当当开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片，目前是版本2.15，并且可以支持云开发 Saturn：是唯品会自主研发的分布式的定时任务的调度平台，基于当当的elastic-job 版本1开发，并且可以很好的部署到docker容器上。 xxl-job: 是大众点评员工徐雪里于2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。 分布式任务调度系统对比 参与对比的可选系统方案： elastic——job （以下简称E-Job）与 xxx-job(以下简称X-Job) 项目背景及社区力量X-Job ： 大众点评公司下员工许雪里、贡献者 3人; github有2470star、1015fork | QQ讨论群6个 | 有登记在使用的超过40家公司 | 文档齐全E-Job ： 当当网开源，贡献者17人; github有2524star、1015fork | QQ讨论群１个、源码讨论群１个 | 有登记在使用的超过50家公司 | 文档齐全 ｜ 有明确的发展计划 支持集群部署X-Job ： 集群部署唯一要求为：保证每个集群节点配置（db和登陆账号等）保持一致。调度中心通过db配置区分不同集群。 执行器支持集群部署，提升调度系统可用性，同时提升任务处理能力。集群部署唯一要求为：保证集群中每个执行器的配置项 “xxl.job.admin.addresses/调度中心地址” 保持一致，执行器根据该配置进行执行器自动注册等操作。 E-Job ： 重写Quartz基于数据库的分布式功能，改用Zookeeper实现注册中心 作业注册中心： 基于Zookeeper和其客户端Curator实现的全局作业注册控制中心。用于注册，控制和协调分布式作业执行。 多节点部署时任务不能重复执行X-Job ： 使用Quartz基于数据库的分布式功能E-Job ： 将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片。 日志可追溯X-Job ： 支持，有日志查询界面E-Job ： 可通过事件订阅的方式处理调度过程的重要事件，用于查询、统计和监控。Elastic-Job目前提供了基于关系型数据库两种事件订阅方式记录事件。 监控告警X-Job ： 调度失败时，将会触发失败报警，如发送报警邮件。 任务调度失败时邮件通知的邮箱地址，支持配置多邮箱地址，配置多个邮箱地址时用逗号分隔 E-Job ： 通过事件订阅方式可自行实现 作业运行状态监控、监听作业服务器存活、监听近期数据处理成功、数据流类型作业（可通过监听近期数据处理成功数判断作业流量是否正常,如果小于作业正常处理的阀值，可选择报警。）、监听近期数据处理失败（可通过监听近期数据处理失败数判断作业处理结果，如果大于0，可选择报警。） 弹性扩容缩容X-Job ： 使用Quartz基于数据库的分布式功能，服务器超出一定数量会给数据库造成一定的压力E-Job ： 通过zk实现各服务的注册、控制及协调 支持并行调度X-Job ： 调度系统多线程（默认10个线程）触发调度运行，确保调度精确执行，不被堵塞。E-Job ： 采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项。 高可用策略X-Job ： “调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；E-Job ： 调度器的高可用是通过运行几个指向同一个ZooKeeper集群的Elastic-Job-Cloud-Scheduler实例来实现的。ZooKeeper用于在当前主Elastic-Job-Cloud-Scheduler实例失败的情况下执行领导者选举。通过至少两个调度器实例来构成集群，集群中只有一个调度器实例提供服务，其他实例处于”待命”状态。当该实例失败时，集群会选举剩余实例中的一个来继续提供服务。 失败处理策略X-Job ： 调度失败时的处理策略，策略包括：失败告警（默认）、失败重试；E-Job ： 弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样失效转移功能也会牺牲部分性能。 动态分片策略X-Job ： 分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。 执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务，同时传递分片参数；可根据分片参数开发分片任务； E-Job ： 支持多种分片策略，可自定义分片策略 默认包含三种分片策略： 基于平均分配算法的分片策略、 作业名的哈希值奇偶数决定IP升降序算法的分片策略、根据作业名的哈希值对Job实例列表进行轮转的分片策略，支持自定义分片策略 elastic-job的分片是通过zookeeper来实现的。分片的分片由主节点分配，如下三种情况都会触发主节点上的分片算法执行：a、新的Job实例加入集群b、现有的Job实例下线（如果下线的是leader节点，那么先选举然后触发分片算法的执行）c、主节点选举” 和quartz框架对比 调用API的的方式操作任务，不人性化； 需要持久化业务QuartzJobBean到底层数据表中，系统侵入性相当严重。 调度逻辑和QuartzJobBean耦合在同一个项目中，这将导致一个问题，在调度任务数量逐渐增多，同时调度任务逻辑逐渐加重的情况加，此时调度系统的性能将大大受限于业务； Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能。 综合对比 总结和结论 共同点： E-Job和X-job都有广泛的用户基础和完整的技术文档，都能满足定时任务的基本功能需求。 不同点 X-Job 侧重的业务实现的简单和管理的方便，学习成本简单，失败策略和路由策略丰富。推荐使用在“用户基数相对少，服务器数量在一定范围内”的情景下使用 E-Job 关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。但是学习成本相对高些，推荐在“数据量庞大，且部署服务器数量较多”时使用 附 定时任务的其他方案发货后超过10天未收货时系统自动确认收货的多种实现方式 每天定时半夜筛选第二天 可以自动确认收货的订单,然后第二天 每10分钟 执行一次确认收货 开销不会太大吧 时间也相对精确 自动确认收货这个状态如果仅仅是让客户端看的话，等用户下一次上线的时间，做一次运算就可以了。 延迟和定时消息投递ActiveMQ提供了一种broker端消息定时调度机制。适用于：1、不希望消息马上被broker投递出去，而是想要消息60秒以后发给消费者，2、想让消息没隔一定时间投递一次，一共投递指定的次数RabbitMQ可以针对Queue和Message设置 x-message-tt，来控制消息的生存时间，如果超时，则消息变为dead letter。利用DLX，当消息在一个队列中变成死信后，它能被重新publish到另一个Exchange。这时候消息就可以重新被消费。]]></content>
      <categories>
        <category>微服务</category>
        <category>定时任务</category>
      </categories>
      <tags>
        <tag>分布式架构</tag>
        <tag>微服务</tag>
        <tag>定时任务</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[Java设计6大原则]]></title>
    <url>%2F2017%2F08%2F11%2FJava%E8%AE%BE%E8%AE%A16%E5%A4%A7%E5%8E%9F%E5%88%99%2F</url>
    <content type="text"><![CDATA[所谓无招胜有招，练一门功夫分为内功和外功。外功好比招式，就是所谓的23种设计模式。而内功呢，就是心法，那就是这6种法则。光会外功那是花拳绣腿，内功修为才是境界。如此众多的设计模式，学完2遍，3遍可能也会忘的只记得单例和工厂模式。但是只要原则记住，在以后的设计中，有意无意就会用的设计模式的精髓。一 ： 类单一职责原则： 一个类只有一个引起这个类变化的原因。即一个类只完成一个功能，如果做不到一个类只完成一个功能，最少要保证一个方法只完成一个功能。 二：依赖倒置原则： 高层组件应该依赖抽象而不依赖具体，即面向接口编程，一般依赖的成员变量或者参数都应该是抽象的不应该是具体的。 三：里氏代换原则： 凡是父类出现的地方都可以用子类代替并且原功能没有发生变化，子类不应该覆盖父类的非抽象方法。 四：迪米特法则： 一个类要尽量的封装自己，一个类只与自己的朋友类打交道一般朋友类是成员变量或者参数，非朋友类一般都是局部变量 五：接口隔离原则： 一个接口完成的功能尽可能的单一，不要让一个接口承担过多的责任。 六：开闭原则： 对扩展开放，对修改闭合]]></content>
      <tags>
        <tag>Java设计</tag>
      </tags>
  </entry>
  <entry>
    <title><![CDATA[领域驱动设计原理]]></title>
    <url>%2F2017%2F08%2F06%2F%E9%A2%86%E5%9F%9F%E9%A9%B1%E5%8A%A8%E8%AE%BE%E8%AE%A1%E5%8E%9F%E7%90%86%2F</url>
    <content type="text"><![CDATA[使用领域驱动设计的业务价值1、你获得了一个非常有用的领域模型2、你的业务得到了更准确的定义和理解3、领域专家可以为软件设计做出贡献4、更好的用户体验5、清晰的模型边界6、更好的企业架构7、敏捷、迭代式和持续建模8、使用战略和战术新工具 领域驱动设计参考项目推荐1.IDDD_Samples实现领域驱动设计作者VaughnVernon 所做的四种不同实现https://github.com/VaughnVernon/IDDD_Samples 2.dddsample-core领域驱动设计(Domain Driven Design)的官方参考架构，该架构分成了Interfaces、Applications和Domain三层以及包含各类基础设施的Infrastructure。https://github.com/citerus/dddsample-core 3.Axon-trader基于命令查询职责分离(CQRS)模式的一种领域驱动实现https://github.com/AxonFramework/Axon-trader，依赖框架 https://github.com/AxonFramework/AxonFramework其中有整合disruptor的实现的命令总线和自身的命令总线。Disruptor是一个高性能的异步处理框架，或者可以认为是最快的消息框架(轻量的JMS)，也可以认为是一个观察者模式实现，或者事件-监听模式的实现，直接称disruptor模式。disruptor最大特点是高性能，其LMAX架构可以获得每秒6百万订单，用1微秒的延迟获得吞吐量为100K+。 《领域驱动设计模式、原理与实践》 整理思维导图]]></content>
      <categories>
        <category>领域驱动设计</category>
        <category>模式、原理与实践</category>
      </categories>
      <tags>
        <tag>领域驱动设计</tag>
        <tag>领域驱动设计模式</tag>
        <tag>领域驱动设计原理与实践</tag>
      </tags>
  </entry>
</search>