Norman Kerth 在《Project Retrospectives》一书中曾提到回顾会议的primary directive principles: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. 无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。 如何理解回顾会议最高指导原则 这句话至少有三层深意： 信任 对事不对人 发展的眼光 信任 人与人之间很重要的一层关系是信任。唯有信任，团队才是真正的团队；唯有信任，人与人之间的协作才能顺畅。在回顾会议中，第一个要传递的信息就是信任。管理者对于团队是信任的，相信团队每个成员都已全力以赴。团队成员之间也是互相信任的。我们在现有已知情况、个人的技术水平和能力、可用的资源下已经做到最好。 对事不对人 回顾会议的目的是帮助团队提高与改进工作的流程。在这个过程中，团队必然会碰到发生过的问题。那么针对每个问题，必须明确的一个原则是对事不对人。我们现在讨论这个问题，目的是能从这个问题洞察到更深层的原因以避免之后发生同样的问题。而不是为了羞辱一个人。作为引导师，需要密切关注会议中的氛围。一旦发生针对个人的行为，引导师需要立刻采取行动。根据行为的严重程度采取的应对方式不同，细节可以参考引导方面的书籍。 发展的眼光 指导原则中提到“无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况……”，这段话说明即使现在发现了问题，部分是由于个人技术水平和能力有限，那么给我们一个很好的启示是，团队现在某个方面技术水平和能力需要提高，即团队（或个人）总是有提高发展的空间。 如何使用回顾会议最高指导原则 我最常使用这个原则的方法是：每次回顾会议开始的时候，团队全体成员集体朗读一遍。确信大家都理解之后才进行下一个环节。 ————————————————————— 最后广告时间 – Scrum联盟的CSM敏捷认证课程 2017年4月16日-17日 上海 2017年4月24日-25日 深圳 2017年5月25日-26日 北京

阅读《技术人创业攻略》一书中，作者对Dave Thomas的访谈有如下一段话： 真相是，“敏捷并不存在”。它不是一种东西，不是一个名词。人们是把它当做一个名词开始用起来的，但是他们并不理解背后的含义。 “敏捷”不是一种东西，敏捷是一个形容词——它描述了一种东西。你可能有一个敏捷的团队或者一种敏捷的过程，但你却从来不是“敏捷”。 对于Dave的这个定义我并不认同。 首先敏捷是一个名词。作为名词的敏捷，它不是一个状态，而是一个完美目标。 敏捷不是一个状态，不是一个状态，不是一个状态！有不少公司在敏捷转型的时候认为，只要我们做到xyz，我们就是敏捷了！对不起，你们并没有敏捷，你们只是达到了一个新的状态。 而敏捷是一个完美目标。何为完美目标？完美目标，是一个永远无法达到的目标。是的，敏捷就是一个永远无法达到的目标。 敏捷是一个持续学习的过程。持续学习也是没有终点的，是一路上不断地持续地学习。因此前几天微信群有朋友问，有没有敏捷成熟度模型？我内心想说的是，不要用模型限制束缚了持续学习。 其次敏捷是一个动词。作为动词，敏捷的含义让我们感觉是快。这里往往有误解，认为敏捷就是效率高、速度快！ 敏捷不是速度快！！！请参考我之前的博文《敏捷不是快》 另外我对敏捷的定义是“一个持续学习的过程”。在这个定义中，也没有任何一个字眼说敏捷就是速度快、效率高！ 最后广告时间 – CSM敏捷认证课程 2017年4月16日-17日 上海 2017年4月24日-25日 深圳 2017年5月25日-26日 北京

Keywords: “double loop learning”, “retrospective”, “Scrum” What inspires me to think about double loop learning Scrum is double loop learning (1977 HBR) 1. Before going to Boston, I read a wonderful article from HBR (https://hbr.org/1977/09/double-loop-learning-in-organizations), which illustrates learning in organizations, aka named double loop learning. To explain it in a short sentence, e.g during our discussion (Boston SA F2F sprint2), we came up an item from product backlog, which is about ensuring core Scrum accurate in SA web content.

在上一篇文章中，我提到以下几点： 绩效管理（度量）的主要目的 度量指标的分类 在这篇文章中，将会展开描述度量指标，详述在软件开发中都有哪些度量指标。 注意：这只是一个度量指标清单，不要照本宣科全部采用（会累死的）。一般建议对于一个组织（或者团队）选用7个以内的指标就足够了。 为了评估公司对产品交付的支持 客户净推荐值（NPV）——推荐产品的客户数/客户样本数 系统稳定性——比如通讯系统的99.99999% 预测进度 燃尽图（故事点或工作小时数） 团队速率（每个迭代交付的故事点数） 提高质量，减少技术债务 生产系统的缺陷数量——发生在客户一侧、生产系统上的缺陷数量（很重要的统计数据） 内部测试发现的缺陷数量（或者说迭代内缺陷） 单元测试的代码覆盖率 违规代码数量（Sonar等静态代码检查） 评估过程的有效性和改进 迭代是否完成目标 是否有回顾会议（反思改进） 需求的周期时间（cycle time） 价值流图 商业效率 产品的整体周期时间 达到收支平衡的时间点（tipping point） 获利的时间 投资回报率（ROI） 现金流（组织内的任何需求都可以折现成$$） 收入增长 评估用户（c端） 每日新用户数 每日留存用户数 每日付费用户转化率 每日净推荐值 企业文化指标 容忍失败，并从中学习 创新意愿 特性团队的比例 下一篇，我将列举一个现实中的团队绩效评估例子，并进行解读。 以下为广告。近期BoB的CSM敏捷认证课程安排如下： 2017年3月16日17日 成都 https://yihuode.io/activities/404 2017年3月23日24日 北京 https://yihuode.io/activities/419 2017年4月16日17日 上海https://yihuode.io/activities/444 2017年4月24日25日 深圳 https://yihuode.io/activities/436

最近的课程： 2017年3月23日24日 北京 https://yihuode.io/activities/419 2017年4月16日17日 上海https://yihuode.io/activities/444 2017年4月24日25日 深圳 https://yihuode.io/activities/436 价格：早鸟价：6300元（早鸟已满）；三人同行每人可享6000元；普通7000元 说明：京东员工、敏捷社区志愿者有特别折扣，详情联系讲师（邮件或微信） 课程简介 从2001年提出敏捷宣言至今已有十余年，敏捷不仅仅在国外发展势头很强劲，在中国也有越来越多的企业开始敏捷转型。一开始是外企把敏捷带入中国，目前国有企业、民营企业、私营企业以及初创企业都在或多或少的应用敏捷实践。越来越多的企业和公司认识到敏捷转型的重要性。敏捷不仅仅是一些方法或实践，更是一种心态的变化，也是一个新的旅程。 在本次课程中，学员不仅从实际操作的层面上掌握Scrum的运用技巧，学员还将学会如何避免Scrum实施过程中的一些常见问题。Scrum很简单，但要掌握其精髓却并非容易，讲师结合自己在企业内实施敏捷转型的实践经验和Scrum框架，通过案例与游戏介绍解释什么是Scrum以及为什么Scrum可以如此高效。课程中通过多个游戏，和穿插的实例、练习、讨论等让学员亲历Scrum的工作过程、领悟Scrum的内涵、掌握Scrum的精髓。你的工作方式的改变从这里开始。 课程特色 来自于大型外资企业和互联网行业的一线敏捷实践 内容全面深入，重在实践操作与应用，囊括了大量项目经验 通过游戏化的方式，让学员在课后可以立即启动自己的Scrum 学习目标 帮助学员学习理解Scrum的原则、方法、与实践经验 提升学员对Scrum，以及敏捷最新实践的理解 通过游戏化的方式，学会如何在组织内进行Scrum转型 主要收益 Certified ScrumMaster证书 Scrum联盟两年会员资格 Scrum实战培训手册1本 对Scrum转型有帮助的、有启发性的1G+视频 团队敏捷备忘录1份 PMI上可以申请的16PDU 适合人群 作为一名Scrum初学者，我可以系统地学习Scrum，了解Scrum背后的原理以及相关知识，以便为组织的Scrum转型打下基础。 作为一名管理者，我可以了解Scrum框架的工作方式，还可以从Bob那里学习组织转型的经验，以便引导我的组织开展Scrum转型，收获更大的价值。 作为一名传统项目经理，我可以看到Scrum是如何工作并生效的，以便更好得把Scrum应用到项目中。 课程大纲 模块1：敏捷与Scrum概述 模块2：Scrum角色 模块3：Scrum工件之产品列表及条目 模块4：敏捷估算与规划 模块5：Scrum会议 模块1：敏捷与Scrum概述 敏捷软件开发逐步地深入人心，但在敏捷转型的企业中，只有很少一部分可以做到持续不断地交付商业价值，使客户满意。相当数量的企业敏捷转型后，效果并不理想，然而问题在哪儿呢？本次工作坊将会从“道、法、术”的层面来解读敏捷，学员将不仅仅知道什么是敏捷，还会了解为什么需要敏捷，敏捷的核心是什么，敏捷会给企业带来什么好处。 Scrum作为敏捷软件开发的一种框架，很简单，但实现起来并不容易。本模块将会分析Scrum价值观，Scrum的基础以及Scrum的概述。 模块2：Scrum角色 Scrum中包含3个角色：ScrumMaster，产品负责人和开发团队。为什么是这3个角色，为什么没有项目经理，一线经理负责什么。这些问题将会在本模块进行解读。 2.1 开发团队 Scrum中的开发团队是自组织的、跨职能的团队，是小的团队，是蜂拥式的工作方式。如何组建这样的开发团队，如何能够激发开发团队的自主性，这个子模块会重点探讨开发团队相关的问题。 2.2 ScrumMaster ScrumMaster是一个全新的角色，他不是项目经理。在Scrum团队中ScrumMaster常常看起来很“闲”，没什么事情做。这是一种错觉，也是一种误解。ScrumMaster可以作为教练，辅导团队Scrum转型；ScrumMaster也可以作为牧羊犬，保护团队不受外界干扰，可以在Sprint内专注于完成Sprint目标；ScrumMaster还可以作为引导师，使团队的会议变得更聚焦、更简单；ScrumMaster还是变革大师，不仅帮助自己团队Scrum转型，还要帮助组织进行转型。 2.3 产品负责人 产品负责人负责最大化产品以及开发团队工作的价值。在Scrum中，通过什么工具，以什么方式，产品负责人可以完成上述的工作，以及产品负责人的职责是什么，将会在这个子模块进行探讨。 模块3：Scrum工件之产品列表和条目 产品列表是团队工作的输入，是至关重要的一环。好的产品列表是ODDE的。如何创建一个好的产品列表，如何拆分产品列表中的条目，都有哪些内容可以放在产品列表中，产品列表的一些常见臭味。以上这些话题将在这个模块中进行深入的探讨。 模块4：敏捷估算与规划 敏捷中的估算怎么做，需要细化到什么程度。敏捷宣言中提到“响应变化 高于 遵循计划”，那么在敏捷中是否还需要计划。敏捷中的规划都有哪些，分别是什么用处，在什么阶段使用。本模块主要讨论这样的一些主题。

作者：安宝平 微信ID: abp0616 Scrum 点滴 一直想把自己使用和学习Scrum的一点心得体会写出来，因为各种原因一直没有动手，（主要原因是懒）。这次参加完“敏捷之旅2016-北京”之后正好碰见个4天的圣诞假期，再不动手就说不过去了。 在现在项目中折腾了将近4年，经历了很多很多，也和其他公司一些人讨论过Scrum，在此期间自己产生过很多疑问，也了解到别人的一些疑问，发现曾经搞清楚的问题有了答案没有记录下来，过了阵子完全忘记了，或者说那些问题的答案逐渐在自己的意识中边缘化甚至消失。自己的“组织过程资产”正在缩水，这是件恐怖的事 。趁着还没大幅缩水的时候做个文字版的记录吧。（如下内容是“现在”这个时刻的记录，半年之后会变化很多，至少现在对于Scrum的理解相比半年之前已经变化很多了。现在先记着，等研究半年后再做个记录。） 先定几个基调，嘿嘿：） 工程师如果知道这么写代码会出bug他肯定不会这么写，基本没哪个工程师故意写出有bug的代码。 工作性质决定了工程师写的代码哪怕一个单词拼写错误都可能出现bug，不是说开发工程师比其他行业的工作人员更容易犯错，而是由工作本身决定。（一个职员写一封英文邮件，有点拼写错误一般不会出现问题）。 个人或者团队的表现好与不好更多的原因在于事业环境因素。如果只抓着个人或者团队的错误不放，很有可能是在舍本逐末\缘木求鱼。 关于工程师文化：大家所谈的工程师文化都是积极的、正面的、向上的。。。我觉得吧，这有点不客观。脱离客观一般会出问题。 Scrum反对教条主义，同时反对生搬硬套Scrum的要求。不要“只是因为Scrum没有明确地提到就假定某个实践是不准许或禁止的。” 想不出来以什么形式记录这些内容，就用了模拟问答的形式，自己感觉良好。哈哈。 Q（1）: 我对于 “敏捷”粗浅的理解？ A: a) 对于比较庞大的需求，相对于瀑布模式，在敏捷中每个迭代都交付庞大功能的小部分功能，而不是等到所有功能都开发完成之后再交付，这种更早、更快的持续交付就是敏捷，是交付层面的敏捷。 b) 为了保证每个迭代所交付的产出具有该有的质量，要对本迭代和之前迭代的所有交付做充分的测试，这些测试要在短时间内完成，人工测试难以完成，所以施行自动化测试（含单元测试、集成测试和页面交互的自动化测试）辅以人工测试。自动化测试速度比人工测试快，这是QC层面的敏捷。 引用某大咖的话“敏捷是一种心态：一种拥抱变化，拥抱学习的心态，敢于尝试，强调实战，快速反馈，适应环境和市场的变化。需要每个成员的紧密合作，需要积极融洽的团队氛围。” Q（2）：Scrum是什么？ A: 在我看来Scrum讲的是工作流程，职责分工，如何与他人合作。是爱德华•戴明博士的管理理论在软件开发这个行业中的具体体现。是适合于软件开发这种工作的项目管理工具。 Scrum的流程是框架，文化理念才是核心。 Q（3）: 为什么要实行敏捷（Scrum）和实行时要注意什么？ A: 每个公司（团队）情况不一样，这个要看出发点或者目的是什么。就怕没有太清晰的目标，同时对于敏捷（Scrum）不甚了解的情况下引入。这种情况下引入Scrum比较容易制造出一个变形的Scrum团队：稍微问一下就会发现，其实是挂着Scrum的“羊头”卖着自己的“狗肉”，各层面问题仍然存在同时还给Scrum安了一个“徒有其名”的罪名。 想实行Scrum之前自己不妨多花些时间想想为什么要改变原来的开发模式，再找个Scrum专家（比如我，哈哈~）交流下，自己对Scrum做个深入了解，看看自己能否接受Scrum及Scrum是否适合自己。 Q（4）: Scrum Master工作的意义（产出），如何衡量？看起来Scrum Master没有做看得见的工作，凭什么要给你开薪水？ A: 这个么。。要是开发团队没有什么问题， Scrum Master确实没太大的意义，我也这么认为。但…是……，如果开发团队有很多问题，比如产出bug量很多，每个开发工程师一周之内用于修bug的时间大于等于1天。这样的情况下Scrum Master如果能把工程师每周用于修bug的时间降到1小时之内，整个团队的效率至少是20%的提升吧。一个团队年度预算如果是500W。嗯，这个产出就比较容易计算了。同时引用某大咖的话“敏捷不仅是对工作的改变，更是精神面貌的改变。” Q（5）: 实行Scrum不需要对远期的需求做讨论（规划），只把当前几个迭代的需求讨论清楚就可以了？ A: 这个是对Scrum的误解！Scrum说的是不对远期需求做过细的讨论，但不是不讨论。比如: l 开发的是一个全新的大项目：在开始第一个迭代之前还是要做高层次的开发规划，比如项目有12个功能模块，要在1年之内完成开发，此时要做一个年度的planning meeting。先把12个模块的流程图做出来，有了逻辑关系就有了开发顺序，再评估每个模块需要的人力。对比现有人员，就会知道是否需要补充新的人员或者评估出年度内会不会需要加班。 l 在已有项目上做新功能开发：在年度之初做planning meeting也是有必要的。只是此时可能不需要画流程图而是根据业务、市场的需求排列需求的开发优先级。 个人认为应该加入到Scrum Master培训中的内容：对于大型项目、多个Scrum团队并行开发的情形要做高层次的年度、季度planning meeting和retrospective meeting。 Scrum强调对于远期的需求不做详细的分析，只对近期要开发的内容做具体的定义，需求的细化是渐进明细的。这里要注意，低层次的、细枝末节的需求可以渐进明细，但是中高层次的需求就不能渐进明细了。反而要像瀑布开发模式那样，在最初就把中高层次的需求定义清楚。即,除了迭代的planning meeting要做，还要做季度和年度的planning meeting，要注意的是，这个年度的planning meeting比迭代中的planning meeting粒度要大的多，绝不是瀑布模型中细致入微的开发计划。对于怎么做如果加个限定词，那就是“必须”、“不遗余力”，否则容易形成需求层面的技术债务。如果在设计系统阶段没有对扩展性，耦合性，系统性能等等这些方面做充分的考虑，等问题出现时再补救会很头疼。张小龙很得意的一件事就是微信从一个小程序到现在的庞然大物没有经历过重构。 Q（6）: 实行Scrum之后不需要写文档了？ A: 这也是对Scrum的一个误解。Scrum强调面对面的沟通，避免撰写详细规格说明书，但不等于完全不写任何文档。有些文档仍然要写，并且要求还不低。我们项目组对于核心功能、重要功能和复杂功能，要求开发工程师一定要写detail design。写完的detail design通过了tech lead的审阅才能开始写代码。在此之前有时还需要工程师写出functional design（功能设计文档），所写的functional design由product owner审阅，审阅通过说明工程师对于功能需求理解到位，detail design审阅通过说明工程师在技术实现上基本没有偏差，再之后进行的开发才不会出现大的偏差。这样的QA工作做的到位再交付给QC时才不会出现过多的问题。我们这里在没有单元测试、集成测试等自动化测试的加持下做到平均每个工程师每个月产生2个bug，很大的原因在于上述QA工作。（不是说自动化测试不需要，不是我们不想做自动化测试，这些由项目组之外的管理层决定。这么大的项目目前由于缺失自动化测试导致的一些问题已经暴漏出来了。）

敏捷度量以及绩效管理，敏捷团队的考核和敏捷团队度量一直是个难题。本文会从度量的目标开始，然后进一步阐述度量的指标有哪些。

2017年第一篇BoB Jiang敏捷新闻稿。 马上要春节啦，再次BoB提前预祝各位敏捷小伙伴，阖家欢乐，身体健康！ 2017年开始，BoB Jiang敏捷新闻开始对外开放，征集敏捷相关新闻、观点、案例分析等稿子（包含但不限于以上类别）。如果您想成为BoB Jiang敏捷新闻编辑的一员，欢迎加我微信私聊。（有心人肯定可以找到我的微信哦） 内容大纲 新闻 社区 荐书 课程 新闻 -————————————— 2017年6月3日在越南岘港举办敏捷之旅全球大会，本次大会将会聚集全球各地2016敏捷之旅最佳话题。详情参考：https://conference.agile-world.com/ 社区 -————————————— 2017年Agile1001（敏捷一千零一夜）有更多的玩法。想要加入我们，可以点击链接查看2017的课程内容。www.hdb.com/party/fcopb.html 2月份Agile1001的活动如下： 2017年2月12日 北京 人脉构建 by 王泽一 2017年2月18日 上海 敏捷团队右脑训练工作坊 by 王伟 2017年2月18日 深圳 精益看板工作坊 by 李国柱 2017年2月25日 北京 精益创业（或待定） by 龚正 2017年2月25日 成都 一起来读书 by 张莹 荐书 -————————————— 《精要主义》这是我读过的最有共鸣的一本书。先说一下整本书的结构： Explore 探索 - 区分出最重要的少数和不重要的多数 Eliminate 排除 - 敢于说“不”，排除不重要的事情 Execute 执行 - 让做重要的事情变成习惯，很容易的执行。 把书中一些共鸣点列举一下： 1. 抽离 - 为思考和探索留出时间。在现在移动互联网时间，每个人每天都非常忙，一点点闲暇时间也被碎片信息所充斥。在这个现状下，尤其需要注意留出时间进行独立思考。作者举出了几个例子（请参考书），我也说一下我个人的感受。冥想（坐享） - 每天有15分钟什么都不想什么都不做，静静的放空自己，注意感受自己的思绪变化。在李笑来老师的得到专栏也有很好的讨论。在最近一个月的练习后，明显我可以更好的认识到自己的情绪变化。 2. 勇气 - 优雅的说不的艺术。一直以来我认为自己是个烂好人，别人求助的事情90%都会答应。读到这一段之后给我巨大的冲击。原来说不有这么多方式，而且即使说不，也不会破坏关系。建议老好人仔细阅读这一章节。（优雅说不的六大原则）