Scrum改变了团队成员之间的工作文化，就像Henrik Kniberg (在 Spotify) 说过, “Scrum 团队看起来更像mini创业团队。”但是这和传统的直线组织兼容吗？ 我知道所有采用Scrum的公司仍然有直线组织。直线组织的理念是为了链接组织单元，帮忙管理组织系统中的上下级关系。换句话说，所有的ScrumMasters是ScrumMaster直线组织的一部分，开发人员是其直线组织的一部分，等等。但是现在有许多已知的组织类型，混合也是有可能的。开篇的图不要太认真，但他们展示出“现代”的直线组织。 但是上下级的思想和自组织、跨职能的Scrum不兼容吗？我们真的需要一个管理角色，具有对策略和薪水等的一言否决权吗？ 或许我们可以找到一个值得思考的方法，就像Henrik提到的mini创业一样。我们如何组织mini创业，就好像员工是公司的主人一样？我个人喜欢作为团队的一份子，所有人都是平等的伙伴，和Scrum团队类似。当然角色必须是共同的；有些人必须担当PO角色，还有些人担当ScrumMaster，等等。取决于个人兴趣，这些角色可以是固定的或者轮换的。团队进行关键决策（众所周知在Scrum中团队做出承诺）。团队内还要做出决策依据，从而我们一起完成用户故事。计划会议帮助mini创业团队构造任务，而我们为下一个时间盒的迭代设定团队目标，以及审查结果——我们也通过回顾持续改进自己。 如果mini创业团队变大了，我们会把团队拆分成两个来减少开销。以我的观点，在扩张的时候有3个事情是很重要的： PO要和两个团队一起工作。 新团队成员也是平等的伙伴。 团队基于主题构建“公会”（译者注：参见Henrik写的关于Spotify Scaling Agile的文章） 现在可以说PO正在变成这个mini创业团队的经理，但这不是真的。PO仍然是平等的伙伴；他不过有其他的关注点。仍然是团队或者团队的代表根据主题做决策。组织越大，公会变得越重要；它就像粘合剂一样，把独立的团队带到一起，交换最好的实践并在主题内做出决策。例如，制定决策是PO的职责，然而分解策略应该是团队的责任。 公司组织对于Scrum团队不兼容吗？或者你如何设计理想的敏捷组织呢？

翻硬币游戏在Scrum培训中很常用，因为它是一个很简单，但能揭示很多道理的游戏。下面我会介绍一下这个游戏的规则和所揭示的一些道理。 道具 1元硬币5枚 5角硬币10枚 1角硬币5枚 共计20枚硬币 游戏规则 只能用左手 一次只能翻一枚硬币 一个人翻完N个硬币后，才能把硬币传递给下一个人 数量N由游戏引导师指定 全场评选一名最快的人，提供礼品（可选） 游戏概述 翻硬币游戏，在网上查到最早是由Joe Little提出来的，后来Jeff Sutherland还有Crisp公司的咨询师都大力推广。我在学习这个游戏后，深入发掘发现它不仅可以用于Scrum培训，还可以用于Lean、Kanban等。 现在大多数公司都重视效率，重视时间线，而忽视了队列和批量的大小。在这个游戏中，正是通过改变批量的大小，从而改善了排队情况，进而大大提高了效率，也加快了进入市场的时间。 具体描述 游戏每组需要8-12人，每组的布局如上图。游戏里一共有5个角色： 游戏引导师 工程师（实际干活，翻硬币的人） 经理（不干活，负责计时他面前的工程师从开始翻第一枚硬币到翻完最后一枚硬币的时间） 客户（负责根据批量分发硬币，以及计时收到的第一批硬币的时间） 客户的老板（负责计时收到所有硬币的时间） 一共4轮游戏： 第一轮，批量大小是20 第二轮，批量大小是10 第三轮，批量大小是5 第四轮，批量大小是1 第一轮 客户把20枚硬币分给工程师1，工程师1翻完20枚硬币后，一起传给工程师2，2翻完后传给3,3传给4,4传给客户。第一轮结束。 经理1,在工程师1开始翻第一枚硬币时计时，翻完最后一枚时结束，记录时间。其他经理同理。 客户记录收到的第一批硬币时间。 客户的老板记录收到所有硬币时间。（第一轮应该和上面的时间一样） 第二轮 第二轮，客户把10枚硬币分给工程师1，工程师1翻完10枚硬币传给工程师2，在1翻完10枚硬币时，客户再次给10枚硬币。2翻完10枚后传给3，一直传到客户。 经理1,在工程师1开始翻第一枚硬币时计时，翻完最后一枚时结束，记录时间。其他经理同理。 客户记录收到的第一批10枚硬币时间。 客户的老板记录收到所有硬币时间。 第三轮 第三轮的批量大小是5，其他同上。 第四轮 第四轮的批量大小是1，其他同上。 反思点 批量减小，上市时间（Time To Market）缩短了 批量减小，交付时间（Lead Time）缩短了 为什么批量减小，上面的两个时间缩短了？ 当批量减小后，客户有什么变化？ 个人绩效和团队绩效的联系？

许多公司标榜自己在做“敏捷”。敏捷是执行软件开发的最新的框架。这个框架下有不同的方法，如Scrum，极限编程（XP），RUP等。Scrum目前是最热门的。一般来说，组织会使用一个混合的版本来适合他们的需求，也受到组织的环境限制（EEF、OPA；指的是企业环境因素，组织流程资产）(EEF/OPA, or enterprise environmental factors/organizational process assets). 因此，公司为什么要转型到敏捷呢？ 我们用敏捷宣言来概括回答这个问题： Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 敏捷赋予客户更改的灵活性，因为整个流程是迭代的并且客户知道每个迭代的进展。还有，团队计划且承诺每个迭代的工作，并一起完成承诺。 对于双方这是一种双赢的场景： 客户实时得到项目、产品的更新状态，并且客户可以自由地改变需求。 团队就像军队里的阿尔法单元（5-9个人），一起在短迭代内荣做。 不争的事实： 这些都是理论。然而生活不是非黑即白：哪里都有灰色地带。 “do Agile做敏捷”比“be Agile成为敏捷”更容易一些。敏捷需要一定的纪律来得到正确的结果。 会议在时间盒内吗？ 会议中你是很好的倾听者吗？ PO或者ScrumMaster就是唯一说话的人吗？ PO或ScrumMaster把工作“强加”给你吗？ 在Sprint计划会议时，PO不等团队的输入就要求承诺吗？ 被迫给故事ABC分配XYZ点数的估算吗？ 在回顾会议你不“公开”，因为害怕所说的适得其反吗？ 在sprint过程中你被迫承担新故事，而影响了你已经承诺的交付吗？ 在每日站会上你从来不谈论尽管已经存在的障碍？ 你希望PO或SM微管理而你只需要工作即可吗？ 你相信胡萝卜加大棒的管理方法很重要吗？ 这些场景只是其中很少的例子；可能的清单是无穷无尽的。这些表明你在“做敏捷”（只是为了完成而已），但你不是“成为敏捷”，因为你不知道敏捷实践和交付的真正重要性。 你可能是遵循瀑布式开发人的敏捷傀儡。这种Scrum是臭名昭著的“Water-Scrum-Fall”。（译者注：也有叫做Scrum-But） 我给这个方法起了个新名字：“潮湿的”Scrum 遵循瀑布式开发的实践Scrum就变“潮湿”了。人们根据场景和难度有选择的使用Scrum。然而这么做很难（几乎不可能）理解敏捷的精髓。 潮湿的Scrum如何工作 客户需要以下内容： 更多的人为干预 可控的工作组织在短迭代内，而不是把整个项目、产品作为一个整体进行管理。 事实更新完成的工作 改变需求的权利 高质量结果 这些都是Scrum理论上的交付物。然而，如果团队没有纪律性，也不关注使项目成功的话，就没有工作方法可以确保项目成功。

English original：How my sister n my girlfriend learned to code，翻译：Ekaterina@yeeyan 就像我在上一篇博文中提到的，Eva和Fong（译者注：根据博主的上一篇博文，Eva是博主的姐姐，Fong是博主的妹子）来到旧金山跟我学编程。在这篇博文中，我将记录下我教她们的方式，我构建这种学习过程的理由，以及这种学习方式奏效的原因。虽然以时间顺序列出她们在这段时间做的或学习的每一件事再容易不过，但是这毫无用处，而且读者们也会遗漏重点。了解学习过程中的细节并且明白它起作用的原因至关重要。所以我会从基本原则开始讲。本文较长，请做好准备。 我姐和我女友是如何学编程的 请在编程过程中始终牢记这些基本原则。 1）交流沟通 在Eva和Fong开始学习之前，我为她们申请了博客，并请她们记录下她们的编程之旅和学到的东西。万事开头难，你可以问问她们。我大概花了一周的时间跟她们唠叨才让她们写了第一篇博客。但是现在，她们不在博客上写点儿自己投入了大量时间的项目就觉得不对劲。 如果你在项目中使用了API（译者注：Application Programming Interface，应用程序编程接口），发推文或者是邮件给这家公司告诉他们你关于他们的API的想法。当你在黑客马拉松中赢得奖项时，发个不错的推文@他们表示谢意，或写篇相关的博文。每写一篇博文都使它成为一直以来最好的，并怀着它会被放上黑客新闻版首页的期望将它提交（尽管大部分时候这种期望都不能实现）。 健康交流的最大好处就是，它使你对你的项目负责， 由此也引出我的下个要点。 2）完成 Fong和Eva都知道，完成一个项目困难，却重要。我声明：除非她们写了一篇关于手头项目的博文，在推特上@了API公司，并且将它发布在黑客新闻网版上，我们是不会开始一个新项目的。尽管她们的第一个项目只是井字棋游戏，但这是她们做过的最好的井字棋游戏。从来就没有人想写一个蹩脚的项目，所以不管这个项目有多简单或者不相关，如果你要着手做个项目，那它必须是你能拿到的最好的那个。我已经见过太多开发者为毫无前景的次要项目工作。如果你在学习编程，你必须从一开始就认识到要珍惜你的时间和精力，完成你的项目证明它的价值。 完成整个项目的最后20%需要花费全部努力的80%。开发者可以在1、2天之内实现一个项目的概念。而测试每种情况并且解决每一种边际情况从而成就一个“完美”的产品则需要两倍的时间。在项目最后的20%花费那80%的精力，将会在许多许多访问中传为佳话。 3） 思考 如果你卡住了，不要紧盯住你的代码。出去散个步，呼吸点新鲜空气，再考虑一下。你卡住了是因为你的逻辑中有错误，而修正它最好的方法就是在脑海中或是在纸上一步一步地彻底想通它。程序员靠思考赚钱，问题在你的思考中被解决，编程是个蛋疼的工作。伟大的项目经理通常都有广博的编程背景，并且在思考和问题解决方面接受过出色的训练。 有一种说法：当你被卡住20多分钟时，并且你仍然茫然无绪，请教别人吧。如果在20分钟内没有任何头绪，那么在接下来的一个小时，你也不会有任何进展的。相信Eva。她有一天就浪费了5个小时，因为一个愚蠢的错误——血的教训啊。散个步，做个其他事。然后再回到项目上来。能将自己与问题切断并转移注意力，是个技术活。 4）再思考 也许你现在已经明白了，思考，在一个程序员的生活中是至关重要的。不要去复制-粘贴代码，尤其当你在学习如何去编程的时候。如果你想学习怎么编程，复制，粘贴——“看，有用诶！”不会使你有任何成就。相反，无论何时你看到代码，你必须在企图去试运行它之前想清楚它在干什么。当你能轻易看懂别人的代码了，将其简化到你刚好需要的程度，然后写出来。如果从一开始就定期这么做，你会在几个月内成长为一个非凡的开发者。 5）谷歌 学会独立解决问题。除非至少被卡住20分钟，不要问编程问题。程序员们必须是独立的。他们是伟大的思想者和伟大的交流者。为了成为他们中的一员，你必须逻辑地思考，想出问题出现的原因。许多年轻开发者面对的问题是，写出他们真正需要的代码对他们来说很困难。我们中的许多人也是这样，明知道问题是什么，但就是不知道要去找什么去解决它。这是个你必须从一开始就培养的技能，它漂亮地联系了第一点，“成为一个交流者” （译者注：疑为博主手误，communication 应为communicator）。 现在，有了这五点牢记于心，以下是Eva和Fong学到的东西，以时间顺序排列。 第1-3天：通过Ruby语言学习编程基础 我选择Ruby语言，因为它用来上手是最的。在Ruby语言中，有很少语法限制（space键与tab键，类型声明，等等），所以Eva和Fong能够关注编程的思考过程而不是解决语法问题。她们学习了if型语句、循环体、数据结构，解决了一些编程题目，比如说FizzBuzz（编程初级问题，即满足a条件时输出Fizz，满足b条件时输出Buzz，同时满足a、b条件时输出FizzBuzz）,替换字符串中的字符，转换一个数组，找出最大值。关于类别和对象的学习也是重要的。 *注*我没有教她们特定的ruby语法，而是让她们对参数都使用括号，并且以返回空结束每个函数。 这样的话，她们下次学一种新的语言时就能更快上手。 第4天：HTML HTML或CSS严格上来说不能算是编程语言，所以没必要在这里花上太多时间。Eva和Fong在HTML上花了一天时间，编了几个标签玩儿，快速完成了表单、信息页等内容。这样，对CSS的兴奋感就建立起来了。在这里重点要学的是区分块HTML与内联HTML、标识与分类。 第5天：CSS 在摆弄过HTML后，“如何在那里表达这个，怎样使这个丑陋的HTML页面看起来更漂亮”的问题浮出了水面。CSS就是那个完美的答案。花上一天的时间尽情设计网页（所有HTML页面都已经在前一天建好）。这一块的重点是，相对/绝对/固定定位，HTML浮动元素，以及如何用绝对、固定定位来控制正常的浮动。 第6-7天：通过jQuery来学习javascript jQuery需要花点时间来适应，而且因为涉及到编程，学习jQuery框架需要占用点时间。她们花了几天时间将HTML页面做成交互式页面。 第8-15天：第一个项目- 井字棋 这时，Eva和Fong已经了解了HTML/CSS/Javascript，但不是特别习惯。这正是让她们开始第一个项目（井字棋）的绝佳时机。虽然她们花了两天的时间来完成这个项目，又用了几天时间来对其进行润色修饰。项目的最后20%要花费精力的80%是个金科玉律。作为一个初学者，学着去完成你的项目是很重要的。 第16-20天：Sinatra框架 在那个看起来永远都不能结束的井字棋项目之后，Fong和Eva迫不及待地想学点新东西。学点服务终端代码对她们已经在做的事来说是个激动人心的全新体验。我选择Sinatra，是因为它是我使用过最整洁、最简单的网络框架，而且这种简洁性让解释网络的工作原理变成小菜一碟。 第20-22天：Photoshop Photoshop对非凡的设计非常重要。对那些从没用过它的人来说，它有点儿吓人（至少对我来说是这样），但是用Photoshop做出来的网站比典型的bootstrap（译者注：由Twitter推出的一款开源前端框架）站点要高端一个档次。而你真正要知道的只是混合、协调功能就够了。任何一个相当成功的开发者都会需要Photoshop，所以学会它并且在你所有的项目中使用它非常重要。 第20-27天：项目2-Dragpic（译者注：通过拖动图片实现从网页上方便地保存图片的软件） 项目2涉及到Javascript的大量使用。这个项目涉及到使用ajax（译者注：一种用于创建更好更快以及交互性更强的 Web 应用程序的技术）的需要，facebook的API，以及cookies。这是个将所有网络编程基础联系起来的绝佳项目。这个项目所需要的技术范围比第一个要更广，我觉得这也向更多更复杂的项目迈进了一步。在这段时间里，她们凭借GIT（译者注：分布式文件管理工具）通力合作。这可是一个开源项目啊！ 第28-30天：RSpec 这时，Fong和Eva已经能相当自如地构造网络应用了。也正是这时，她们意识到，代码是多么地脆弱，一个细微的改动，就能导致满盘皆输。现在，测试驱动开发就显得有重要意义。我们花了几天时间重温了rspec，Eva和Fong则写出测试案例作为每天早晨的编程练习。我之前提过她们每天早晨都要解决一个技术问题吗？从第28天开始，她们就必须为这些技术问题写出rspec，在她们开始编程之前也不例外。 第30-35天:BackboneJS（译者注：一个开发网络应用的框架，提供了强大的对模型、视图和交互的抽象） 通过负责一个设计技术范围广泛的项目（比如Dragpic），你能学到很多，遇到很多你希望能有更优解的问题。只有这样，你才能这正意识到那些帮助你的框架的价值。我还没有找到任何一个优秀的backboneJS教程，所有教程都一下子提供了太多信息。以下是我教授它的方法： 第一步：学习模型。仅为一个数据库数据库条目创建一个模型。学会如何去修改和保存。 第二步：学习视图。为你已经在做的模型创建一个视图。添加事件接听程式，体会视图如何能够隐蔽地与模型连接，以及这一切组装为一体是如此地合适。 第三步：集合的意义现在就明确了。 你不可能手动打印输出每一个模型，尤其是当你不知道模型具体数量的时候。 我们没有学过常规课程，到现在为止，我也不认为这有什么要紧。 第35-40天:Android 假如你现在还没怎么注意，我们已经在短时间内涵盖了大量的材料了。伟大的程序员适应变化，因此我们最后一个计划就是学习Android系统。在编程中你不能忽视移动设备，这块实在是太重要了。我教她们Android编程，这不是特别难，Android编程与web编程非常类似。在视图上你有XML（译者注：extensive makeup language,用于标记电子文件使其具有结构性的标记语言）,同时也有足以和web控制器相媲美的Java代码。模型-视图-控制！通过用Ruby语言和Java语言工作，Fong和Eva开始寻找编程语言之前的共同点，成为了编程语言不可知论者。对她们来说，编程语言仅仅在语法上有所不同，但工作起来却是一个道理（其实不是这样，稍后我会对其进行辨析，厘清混淆）。 结论： 1）女孩们在编程上天赋异禀。 2）没有获得计算机科学的学位不是个不学编程的借口。 3）在快乐中编程，人人都能学。 继续探索，然后征服编程吧！

由Agile42公司开发的看板披萨游戏遵循以下许可：Creative Commons Attribution-Share Alike 3.0 License. 仅仅通过教科书的方式传授精益敏捷的原则，是很困难的。人们必须亲身经历这些原则以体会它们是如何工作的。通过游戏，不必打乱日程工作或沉迷在技术细节，你就可以获得经验。这也是我们在培训中使用游戏和模拟的原因。如果没有合适的游戏，我们就创造一个，比如看板披萨游戏！ 通过agile42公司的这个游戏，你可以发现看板是什么。然而其他看板游戏通常关注白板概念和已有看板系统中的工作流，我们的看板披萨游戏教会大家如何从现有流程产生看板系统。 用纸做披萨 如agile42 Scrum Lego City Game，我们希望看板游戏用每个人都熟悉的东西并且每个人都能做。我们尝试远离IT环境，因此参与者不用考虑太多和他们现有工作环境的相似处。我们认为用纸做披萨这个想法太棒了——每个人都喜欢披萨，并且每人都知道披萨是怎么做的。（至少知道一般术语） 什么时候以及如何使用看板披萨游戏 如果你想要理解看板是什么，以及在日常工作之外的安全环境里实践一些精益概念，那么看板披萨游戏是最合适的！ 学习目标 从培训的角度这个游戏的目的是什么？我们希望参与者： 体验看板系统如何从已有的流程中浮现出来（如工作当中那样） 体验一个完整的看板系统（而不是只关注白板和相关概念） 理解白板是依赖于场景的：对于任何流程，都有许多不同设计的看板，这些都是适当和实用的，而不必只有一个最优的看板。 理解限制在制品（Work In Progress）的影响。 体验自组织和适应性。 充满乐趣! 每个团队都有不同颜色的纸、剪刀和其他材料（参见本页底部的完整物料清单）。团队根据配方裁剪、涂抹和粘贴这些材料以形成披萨。准备 这个游戏从开始到结束有一套PPT可以使用。（译者注：后续提供不需翻墙的链接） 确保充足的物料！ 每组至少4个人 可以一个组玩，但多组的话会增加有益的竞争，也会更有趣 (可选) 如果人数为奇数，可以考虑邀请他做观察员，担当质量监控并衡量交货时间。 游戏流程 1. 第一轮，创建一个隐含的流程 看板总是从你当前现有的流程开始的。在游戏的开始，让团队拿一些纸片并制作尽可能多的披萨（夏威夷）。如下图 展示一块做好的夏威夷披萨并解释怎么做的：一块披萨饼底（三角形纸），番茄酱（红色马克笔），3块火腿（粉色便利贴）和3块菠萝（黄色便利贴）。番茄酱要涂满饼底（译者注：记得披萨饼有卷边哦），馅料大小合适并均匀分布在披萨上。 演示烤箱盘并演示怎么用。烤箱一次最多烤3块披萨。烤的时间最少30秒。在烤的过程中不能动烤箱（增加或拿走披萨）！ 下面要求团队制作尽可能多的披萨，但要避免浪费，如准备好而不用的原材料。当你决定结束的时候（大概5-7分钟后，不事先确定时间），告诉大家停下来。 2. 介绍看板 在第一轮结束后，介绍看板和核心看板实践。 核心看板实践： 使工作流可视化 限制你的在制品数量（WIP） 管理流动（Flow） 实现反馈环 明确流程原则 一起改进 接下来，介绍计分系统并让团队自己算分。设计计分系统是为了提倡限制WIP，并且可以间接地流动（在这个游戏中，流动和交货时间是有关联的，只要人们不知道一轮的准确时长，他们就会重复相同的行为）。收集分数并记录到白板或者挂图上。 让团队把工作流可视化并且通过引入生产材料库存（披萨饼底，火腿块等）来使流程更明确。现在不要尝试优化工作流，仅仅把第一轮出现的内容记录下来。 让团队限制他们的在制品（WIP）。第一轮结束后团队有一堆的材料浪费了吗？每个步骤合理的WIP大小是多少？ 披萨的质量如何？有没有偷工减料？披萨饼底应该是一样大并且涂满番茄酱，馅料剪得很精美且分布均匀。 下轮开始之前，扔掉已经交付的披萨，但保留没有用过的材料，包括桌子上没烤过的披萨。 3. 第二轮，使用刚才建立的看板系统 现在用刚刚建好的看板系统开始下一轮。再次强调，快要结束的时候不要给出任何提示，当你觉得差不多的时候（5-7分钟后）就结束这一轮。结束后做一个小结并算分。 接着让团队花1分钟反思一下，他们的看板系统哪里挺好的，哪里需要改进，并再花1分钟重新设计工作流和尝试不同的WIP限制数目。 4. 第三轮，扩展 给游戏增加点复杂度，引入客户订单和一种新的披萨（蔬菜配方）。订单可以包含1种或2种披萨，只有整个订单完成了才能得分（订单里披萨的总分）。蔬菜披萨没有火腿和菠萝，只有7条蔬菜（绿色的便利贴）。可惜蔬菜一烤就很容易焦了，所以只能在披萨烤好后粘上。

帕累托法则是根据它的发起人命名的（Vilfredo Pareto意大利经济学家）。这个概念非常简单：80%的结果来自20%的原因。 帕累托法则（也叫二八原则）可以应用到许多业务领域。比如： 在销售领域，80%的业务来自20%的客户。 在效率方面，80%的成果来自20%的任务列表。 在服务行业，80%的工作来自20%的服务产品。 在市场营销方面，80%的回应来自20%的营销工作。 在客户服务领域，80%的抱怨来自20%的客户。 在Backlog里，80%交付的价值来自20%的Backlog (如果你想了解这些数字是怎么产生的，可以参考维基百科关于帕累托分布的定义：https://en.wikipedia.org/wiki/Pareto_distribution.) 为了遵循以交付高价值和客户喜欢的功能的方式高效地管理Backlog的精神，我建议要毫不留情地清理现有Backlog中的待办事项列表。这意味着需要识别80%不能使客户高兴的特性并清除掉它们。找到20%让客户高兴的特性，交付并重复这个过程。 帕累托法则承认努力和结果之间的不平衡，并且允许我们用这种不平衡来发挥自己的优势。但这不是说我们可以不做非关键的、80%不太重要的工作。比如，我们不能忽略监管需求；但是，我们可以改变行动，因此我们关注在最需要的方面。比如，因为我们要做其他队客户很重要的特性，所以不会浪费时间在营销监管需求上。 在多个级别上都存在帕累托法则：你可以指出组合中20%的产品，它们交付了80%的价值吗？你知道这些产品来自20%的史诗(epic)故事吗？当把史诗故事拆分成更小故事时，团队知道20%的关键任务交付了80%的价值吗？ 应用帕累托法则 在Backlog中应用帕累托法则的关键是，需要关注其中关键的20%，这些实现了80%的客户满意。当然这是一般原则，而不是确凿的统计数字；对于某些条目，分界点可能更接近90/10或者70/30。但要点是一样的，当你开始查看交付了哪些让客户不高兴的特性时（或者是客户根本不用的特性），帕累托法则是出奇地准确。 应用帕累托法则的难题在于识别关键的20%。在某些领域有可衡量的指标（比如客户数、收入以及每个服务的时间），这些很简单。当在Backlog中有一个冗长的待办事项列表，里面有许多条目需要完成时，做同样的分析会很困难。我的建议是不停止交付，而是跟进已经交付的工作，看一下产品是否真正满足客户了。如果你花了大量时间完成80%底部的特性时，或许下一次你不会这么做。为什么我们喜欢衡量成功，事后分析是20-20，当确定要做的20%时，通常你也准备完成20%的改变。（Why we like to measure success here is because hindsight is 20-20 when determining the 20 percent to concentrate on, and many times that 20 percent changes by the time you’re ready to address it.）如果跟进正在交付的内容，真正衡量客户的满意度，你会看到交付Backlog中更高价值的持续改进。 How High? 就用这个思想做个实验： 团队一年的成本——假设100万元。 用这个成本团队交付的价值——团队交付了一年300万元。 我们再做一个假设：我们一起工作的PO，有另一个Backlog，价值比现在的高10% 另一个假设：或许PO通过愿景激励团队，移除障碍，并且团队开发速度提升了。 最终，Backlog中应用帕累托法则（20%的backlog交付了80%的价值，并且PO依此组织backlog）并回答下面这个问题： “PO一年可能交付多少价值？” 帕累托法则这个概念是非常高明的. 原文链接：https://www.scrumalliance.org/community/articles/2013/december/pareto-your-backlog

回顾会议是Scrum的一部分，用来反思完成的工作，从而帮助团队提高（自组织和定期调整）。然而，我目睹了许多团队的回顾会议，他们会议变得单调地重复或者变成“形同虚设的会议cribbing sessions。”回顾会议往往就得到扩展（不是在限定时间内完成），并且通常不产生任何实际的改变（业务价值），也不识别和解决问题。 如果回顾会议进入这种状态，那么是时候改变了，你应该引导团队并且关注于给出会议的方向 ，确保回顾会议在时间盒内并且最后有可量化的行动项。 为无方向的回顾会议给出方向 如果团队想要走出这种困境，通过建议讨论的主题而给出一个会议结构（日程），很可能是个不错的注意。下面是一些有用的建议： Sprint planning: 我们的计划够好吗？在迭代中碰到问题了吗？ 每日站会: 我们如何有效的开每日站会？ 持续集成: 为了提高效率，还有哪些可以放到持续集成内的？ 时间盒交付: 我们能交付承诺的内容吗？ PO的反馈: PO在澄清需求方面是如何回应的？ 协作: 我们（团队）之间是如何协作的？ 回顾会议: 通过回顾会议我们有所经验和教训吗？ 你可以根据自己的环境和需要调整上面的列表。 关注问题的数量而不是质量 为了避免主观或定型的发言，建议团队使用一个打分系统（从1-最低到10-最高）。调查结束后，团队就会得到一个当前迭代的平衡计分卡，因此很容易找出表现最好和最差的地方。 下面我们看一下 如上图，团队能够发现强项和弱项的地方，然后可以选择最好的（1或者2项）和最差的（1或者2项）进行讨论。（译者注：最好的1项和最差的1项，在上图中是协作和时间盒集成）这就是我们的回顾会议要做的事情，如何改善弱项，以及如何进一步提高强项。 持续地监控回顾会议 这些分数给了团队开会和讨论的结构化的方法。然而，做为ScrumMaster，定期监控会议的价值也是非常重要的。因此我建议你维护一个所有迭代对比的趋势报告。如下图： 通过分析过去几个迭代的进展，你应该可以识别出以下点（译者注：参考上图的Trend列）： 低谷期: 持续得分很低的问题或者有下降趋势的问题。 平台期: 相对稳定但还没有达到“绿色区”的问题。这可能表明团队中酝酿着停滞或漠不关心的情绪。 顶峰期: 团队持续改进的方面，或者在相当长时间内维持在“绿色区”的方面。 在某些点，可以考虑从计分卡中移除“顶峰期”并引入新的主题，从而可以保持关注于低谷期和平台期。这会帮助你从不同的方面评估立足点以及帮助突破团队内单调的风险。 正确使用回顾会议时，它可以洞察团队的健康度并突出改进的范围。如果不满意你的回顾会议，那么改变它！ 原文链接：https://www.scrumalliance.org/community/articles/2013/december/introspect-the-retrospectives

沟通当中最重要的是倾听，而不是说。 还记得有这样一个故事： 有一天，一个说话连篇、滔滔不绝的人来找苏格拉底。他问到，我如何学会沟通。我认为我很会说，但是为什么没有人愿意听我讲。苏格拉底回应道，我应该收你两份钱，因为我要先教会你闭嘴，然后才是如何说。 通过这个故事，我们得知沟通的时候，首先需要倾听。只有真正地做到用心倾听，才能打动对方，建立彼此的信任与联系。 如何做到倾听呢？ 这里有几个方法，非常实用（节选自《参与式决策引导宝典》： 1. 简要复述：顾名思义，用自己的话重复对方刚才所讲的内容。这样做有几个好处，第一说明我在认真的听对方讲；第二得到对方的核实，如果复述有误，可以第一时间重新站在同一跑道上。 例句：“听起来你的意思是……”，“不知道我这么说，是不是你的意思……”，“……我有没有理解你的意思？” 2. 引导对方充分表达：应用场景，a.帮对方厘清思路。b.对方自以为说清楚了，可听众迷迷糊糊。 例句：“你可以说的再具体一点吗？”，“你现在想到的是什么？”，“你可以举个例子吗？” 可以先使用简要复述，然后使用连词加上引导的句子。 3. 求同存异：沟通当中难免有冲突，但再大冲突的观点，也有相同之处。沟通当中我们需要寻求这样的共同点，来找到两全其美的解决方案。 例句：“让我归纳一下每个人的说法。我听到很多不同的观点，然而也有相似之处。”“听起来有些人希望在新年假期可以早点下班，有些人则宁可正常上班，但要放几天假。” “虽然如此，你们似乎都同意在过年前想要某种形式的休假。” “我这样说对吗？” 4. 同理心：了解他人的感受，和感同身受。最基本的技巧是，说出你觉得对方正在经历的感受。但一定要做确认，鼓励对方纠正你的猜测。

基本概念: 这是一个在复杂的、自适应系统中选择恰当管理行为的方法，该系统是基于所涉及问题的确定性程度和认同级别的。 潜在使用场景: • 为特定的问题或决策选择管理或领导方法。 • 制定一组决策（或大家的日程）的意识。 • 与人沟通，为什么特定的方法是合适的。 • 当需要创新和创造性选择时，这个矩阵可以用来有意地增加不确定性和不认同，从而把系统轻推到混乱的边缘。 描述: 管理和领导的艺术是拥有一组方法，并且知道什么时候用哪个方法。Ralph Stacey 提议了一个对管理艺术有帮助的矩阵，这个矩阵在两个维度上识别管理决策：确定性程度和认同级别。 我们来仔细看一下这两个维度。 接近确定性: 当因果关系确定时，问题或决策也接近确定性。当过去一个相似问题或决策发生时，通常是这样的。人们可以非常确定地从过去推断和预测行动的结果。 远离确定性: 确定性连续的另一端是远离确定性的决策。对决策制定者而言，这些情况常常是独特和新颖的。因果关系不是很明朗。从过去的经验推断，在远离确定性的范围预测不是一个良好的方法。 认同: 竖轴代表团队或组织内关于问题、决策的认同级别。和预想中的一样，依赖于问题的认同级别，管理或领导职能发生变化。 接下来描述该矩阵中不同的区域： 1. 接近认同，接近确定性 （Close to Agreement, Close to Certainty） 2. 远离认同，接近确定性 （Far from Agreement, Close to Certainty） 3. 接近认同，远离确定性 （Close to Agreement, Far from Certainty） 4. 混乱：远离认同，远离确定性 （Anarchy: Far from Agreement, Far from Certainty） 5. 混乱的边缘 （The Edge of Chaos） 1) 接近认同，接近确定性 （Close To Agreement, Close To Certainty）

本文讲述了改变Scrum每日站会的一个小故事。我们从典型的以人为中心转变到以Sprint Backlog里的故事为中心。这个想法来自于Jeff Sutherland的一篇论文。 本文的目的是简要描述我们为什么和怎样进行每日站会的变化，它的优缺点，以及我们得到的反馈。在开始之前，先介绍一下背景。 背景 团队已经采用Scrum和每日站会，也有Product Owner（PO）角色。 何时何地出现了改变每日站会的需求？ 改变的需求来自于团队的回顾会议。 在改变之前，每日站会按照标准的方式进行。每个团队成员将回答3个经典问题：_1）昨天我完成了什么？2）有什么障碍？3）今天我将要完成什么？_当一个人完成后，下一个人继续。这种方式关注正在说话的每个团队成员。 几个月（许多迭代）之后，许多人抱怨每日站会效率低。基于大家对于这种效率低的原因的反思，团队达成结论，每日站会本身的这种方式可能导致了效率低。 提出什么行动计划？ 我们读过Jeff Sutherland的论文https://jeffsutherland.com/ScrumMetricsHICSS2013BWSubmissionFinal.pdf 并且非常喜欢关于改变每日站会的提议。Jeff提议在每日站会上检查Sprint Backlog中每个故事的功能，而不是每个团队成员的。作为教练，我留意到这篇论文，或许团队有兴趣学习一下。事实上，团队很高兴有这个提议，于是团队落实了行动计划，以在下一个迭代来验证这个变化。 这个改变是如何执行的？ 在接下来的迭代中，团队在相同的地方开始每日站会，但是这次是基于Sprint Backlog中的每个故事回答3个经典问题。也就是说一个以上的团队成员（取决于几个人参与这个故事）都会说围绕着具体的故事他们完成了什么，将要完成什么，是否存在障碍，以及完成这个故事还需要什么。直到手上这个故事所有相关的问题都解决了，团队才会继续进行下一个。这个流程持续到Sprint Backlog中最后一个故事讨论完。需要注意的是，建议从最重要的故事开始，按照重要性的降序继续讨论。 这个改变带来什么好处？ 假设PO参与每一次的每日站会，这个方法可以让PO听到团队关于产品开发的进展——比如，这个方法面向的是产品，而不是谁完成了什么。重要的是正在开发的产品，以及在Scrum中，团队整体执行开发工作。从概念上，我们说团队工作是一组有共同目标（愿景）的人在高度协作的环境中工作。 改变的结果是，团队的效率几乎马上得到提升。假设这是由于这样的事实导致的，当讨论故事的时候参与的每个人都发言，从而提高了专注力。相比之下，传统的每日站会经常有干扰。比如，如果两个开发人员做同一个故事，团队不得不等到两个人在不同的回合中都说完了，才能充分地理解这个故事过去和将来的行动。 更重要的是，对故事专注力的改变，需要整个团队强化正在构建产品的知识，因此现在团队专心在产品上，而不是开发人员的任务。 每个开发人员说话不做限制的事实，允许其他团队成员（他们可能在自己的故事中受阻，或只是完成了一个故事）尝试一起合作关掉正在讨论的故事，而不是去认领一个新的故事。 这个改变的缺点是什么？ 大家都知道，在接下来的回顾会议中我们分析了这样的流程改变，为了识别出优缺点。在这个案例中，观察到的主要缺点是，它很难检测到团队成员是否在工作。现在的每个站会中，讨论围绕着故事，而不是每个人在做什么。因此，团队成员必须更积极主动处理这种“闲置”的状态。 同样的，当团队成员非常忙碌的时候，可能也不是那么明显。 作为教练，假设这迫使团队需要更多更好地自组织的话，我的观点是这个缺点可以转化为机会。每个人负责有效地利用自己的时间。每个人负责查看开发流程是否停滞。而且每个人负责决定为了前行而如何一起工作。事实上，参加改变的团队发现一个方法来减轻这个缺点。比如，团队修改仪表盘，因此，查看流程中的每个团队成员的情况更容易。 关于这个改变有数据吗？ 通过调查我们收集到一些数字和指标： 团队A1有3个成员，团队A2有4个团队成员，两个团队共用一个ScrumMaster 团队B1有7个成员和1个ScrumMaster 团队C1有4个成员和1个ScrumMaster 根据上述数据，我们可以分析有多少人直接参与。总有有26个人：4个PO，18个团队成员和3个ScrumMasters。每个人的问题是：假定每日站会的这个改变，最符合下面哪条Scrum价值：_专注，勇气，或者承诺_？调查结果如下图： 我的反思 基于上面给出的数字，我想突出观察到的第一手资料，这种方式工作的团队使Scrum里面关于“团队”的概念更具体。也就是说，每个人都被真正地激励并以可持续的方式工作。每个人都认识到“集体的力量大于个人”。Scrum的目标就是尽可能早的交付高质量的产品增量。 尝试改变，观察结果，从结果中获得认知，再次改变！如果有些事搞砸了，尽早的失败比以后的失败要更重要！ 原文链接：https://www.scrumalliance.org/community/articles/2013/november/change-your-daily-scrum-meeting