1.什么是敏捷之旅（Agile Tour）？ Agile Tour（以下称为敏捷之旅）是一个国际非盈利性组织，于2008年成立，总部位于法国。其目的是提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。它通过一系列的活动，在全球的范围内 极大推广敏捷 希望通过一系列活动，在每一个参与城市都对敏捷思想引发足够的关注，并形成一个敏捷开发的社区。 分享敏捷的愿景 敏捷在持续演进，希望在打开新的视点的同时也把我们对敏捷的理解和观点分享给整个敏捷社团 联合 在保持敏捷文化和自治的同时，在世界各个地区提倡和提升敏捷的领导力 支持 帮助同行，朋友和本地商业机构转向敏捷方法 2. 敏捷之旅—足迹 自2008成立以来，每年的10月至12月，敏捷之旅都会在全球范围内举行活动，让更多的人了解敏捷。而每年参加的城市和人数也迅速的增长，已成为全球规模最大的敏捷大会。而截止目前已有84个城市申办敏捷之旅活动。 下面是申办城市的列表： 3. 敏捷之旅—在中国 敏捷之旅在中国行始于2009年成都，最早把敏捷之旅引入中国的是成都的敏捷先驱们，敏捷之旅成都-2009的讲师有Stéphane Lécuyer、Vernon Stinebaker、顾全、Julien Mazloum、Brenda Bao、徐毅。而从2010年开始，国内敏捷社区的一批先行者，包括知名的敏捷培训师和教练，开始在全国范围内组织敏捷之旅系列活动，以让更多的城市和更多的朋友借此平台，了解敏捷，结交朋友，交流互动，从而形成一个全国范围内的社区平台。 从2009年至今，敏捷之旅在中国申办过的城市已经扩展到了成都、北京、上海、杭州、深圳、广州、西安、青岛、大连、福州、天津、厦门、广州、太原、南京、苏州、大连、香港、长沙、郑州二十个城市。 参加过敏捷之旅中国的众多国外知名专家包括（不限于）： · Jean Tabaka 拥有30年软件开发行业经验，著有敏捷软件开发系列丛书《CollaborationExplained: Facilitation Skills for Software Project Leaders 》。 · James Grenning 敏捷宣言创始人之一, Renaissance Software Consulting 公司创始人，全球知名讲师，过程教练及咨询师。 · Patrice Petit 全球知名敏捷教练，咨询师，敏捷之旅（Agile Tour）的创始人 · David Hussman 2009年Gordon Pask大奖的获得者，参与了很多书的编写工作，具体有：《AgileSoftware Development in the Large, Managing Agile Project》和《Agile Software Development with Distributed Teams》。在全球各地培训和培养敏捷教练，有超过十年的敏捷培训经验. · Gojko Adzic 全球知名敏捷专家和教练，敏捷畅销书《Bridging the Communication Gap》 和《Specificationby Example》的作者。

2014年12月20日，在联想北京总部，来一场“与敏捷的思奔之旅”？ 那么我们来看看这趟旅程都有什么奇妙之处： 我梦想创业，可是不知道如何找到好的商业模式？ 意启部落小伙伴们带我们一起体验一个商业模式如何诞生。 O2O很火，你知道吗？ Agile1001的F4团队将以精益创业的思想带我们进行O2O项目实战。 想与敏捷大牛面对面交流吗？ 姜信宝、申健、张伦、周金根、寇晓东、王立杰、王栋、施勤文、刘新… 知道互联网企业中的敏捷先锋是如何实践的吗？ 来自于京东商城的王栋和汽车之家的冯林与大家分享敏捷布道之路。 总有些意料之外的小惊喜 图书奖品、早鸟优惠价、便携记事本… 谁是幕后英雄，敏捷之旅2014-北京的组织者： 报名请戳： https://www.headin.cn/Themes/Activity/Details/?activityId=5466c604c3378ff3a4de7665 关于敏捷之旅： https://agiletour.cn/

分享人：申立君 分享书籍：《安德的游戏》

Scrum中定义有三个角色 产品负责人 ScrumMaster 开发团队 另外还会提到两个常见角色（经理和项目经理）在Scrum当中的职责。 产品负责人 职责 产品负责人最大的职责是为产品的投入产出比（ROI）负责，即最大化团队的投入产出比。在Scrum当中，由于Sprint是时间盒（即时间是固定的），且成本（软件开发中人力成本是最大的成本，其他忽略不计）也是固定的，那么最大化投入产出比就是如何做出最有价值的产品增量。 创建产品愿景 创建与维护产品Backlog（插播一句，Jeff Patton同学很不喜欢Backlog这个词，听起来产品还没有开始开发就落后了，如果谁有更好的词我们可以一起交流） 主持产品Backlog优化会（增加、删除、修改或细化用户故事，并根据需要进行排序） 协调干系人与开发团队之间的沟通 参加团队的Scrum会议 在Sprint计划会上和团队一起决定当前Sprint的开发内容 接受或拒绝团队的产品增量 决定何时发布 所需技能 根据上述的职责，作为产品负责人需要以下技能： 业务能力 - 产品负责人首先要对产品以及所在行业有较深的认识和理解。这样才能根据业务价值来对不同的需求进行排序，或者对产品的整体方向有感觉。 技术能力 - 虽然产品负责人不必是技术专家（SME），但懂一些技术对于需求排序、拆分、优化是有很大帮助的，特别是在参加Sprint计划会的时候，可以很容易的理解开发团队。 决策力 - 产品负责人接受或拒绝产品增量，那么对于产品负责人他就要有授权，可以决策哪些是可以接受，哪些要拒绝。以及决定什么时候发布，什么特性优先级高等等重要事项。 沟通协调能力 - 产品负责人需要有很强的沟通协调能力，因为他是干系人与团队之间的润滑剂。 谁来担任 简单的回答，可以完成上述职责并拥有上述技能的人都可以来担任产品负责人。较常见的是产品经理担任。我见过的还有项目经理、架构师等不同岗位转型为产品负责人的。 ScrumMaster 职责 Scrum权威 - ScrumMaster是团队中最熟悉和了解Scrum框架的，并可以根据实际情况对团队进行指导。 辅导团队和产品负责人 - 如果产品负责人或团队不知道该怎么办，ScrumMaster需要提供相应的辅导、培训或支持。 保护团队 - 在一个Sprint中，ScrumMaster要保护团队不受打扰，可以专注于Sprint目标和承诺。 移除障碍 - ScrumMaster要善于发现障碍，并可以帮助团队移除障碍，包含但不限于个人障碍，团队障碍以及组织级的障碍。 变革大师 - ScrumMaster不仅要在团队内实行Scrum，还要能够影响并促进组织或整个公司内的变革。 所需技能 热情 - 首先ScrumMaster需要是一个有热情（Passion）的人。热爱并喜欢自己的工作，充满激情，并且可以感染周围的人。 主动学习 - 学习是永无止境的，作为ScrumMaster，需要主动的学习，补充自己的短板，刻意的练习，成为真正的master（大师）。 善于提问 - ScrumMaster不一定是所有问题（尤其是技术上的）的大师，但他一定要能善于启发团队思考并行动。这往往是通过提问来实现的。好的问题可以让团队清晰的认识到自己。 耐心 - 对于变革要有耐心，可以容忍团队犯错误。让团队在错误中学习并成长。 协作沟通 - ScrumMaster需要和团队沟通，了解个人障碍和团队障碍。也需要和团队外的干系人沟通，来排除障碍或了解他们的期望。总体说，ScrumMaster需要较强的沟通能力（和产品负责人类似）。 公开透明 - Scrum的三大支柱之一就是透明。因此作为ScrumMaster也需要公开透明，不仅仅是团队的进展要透明，所有的沟通交流也需要是透明的。只有信息透明，才能产生信任与尊重。详情可以参考《克服团队协作的五种障碍》 谁来担任 常常问道的一个问题是，ScrumMaster是全职工作吗，可以兼职吗？对于一个新组建的团队，我强烈建议全职的ScrumMaster。因为有很多的事情需要ScrumMaster来做，参考上面的职责。如果是成熟的团队，ScrumMaster可以兼职，但不建议既做ScrumMaster又做开发工作；但可以同时是两个团队的ScrumMaster，因为工作类型是相似的。

京（精）读会，京东人自己的读书会，精品阅读俱乐部。 感受读书乐趣，体会阅读收获，分享朋友感受。 在这里你可以找到一起读书的小伙伴，也可以听到很多有趣的书评。欢迎爱读书的小伙伴来参加我们的活动。 Bob Jiang 几种书不读– 当下热卖的书不读，人物传记不读（尤其非本人写的），心灵鸡汤类不读 笔记方法– 读书的时候，有重点要点内容，记录在书前面并标注页数 读书时，重点关注重点段落（如标题，黑体等），以及段落的首尾句子。 读英文书时，尽可能不查字典，靠上下文猜。 推荐的三本书 《做不可替代的人》 《The Principles of product development flow》 《creative confidence》 程文宇 不读 - 厚的，读不懂的 喜欢读 - 历史、快餐类、科普类，工作有用的 先看目录，先读有兴趣的章节 推荐的三本书 《金字塔原理》 《曾国藩》 《专业主义》 申立君 1、选书：喜欢同学、老师、同事等亲近的人推荐，会更贴近自己的实际情况，也可以方便讨论分享； 2、有目的的看书，抱着问题去看，更容易看得进去，收获也更多； 3、速度更快：首次看书过程比较粗略，留下记号，标注难点、精彩的地方，再根据书本值得看的程度，决定看不看第二次，第二次阅读的重点是什么； 4、便利贴标记：随手贴留记号，方便回顾，也不伤害书本；利用不同的颜色代表不同的含义；摘录要点，随手贴在家里任何地方； 5、读书笔记：用思维导图记录书的框架和要点；写书评；特别好的书，做成PPT、信息图，与大家共享； 6、向别人推荐书目：很好的交流过程，也可以督促自己多读书； 7、记录读完的每本书写在卡片上，记下日期，定期回顾数量和心得，非常有成就感，激励自己； 8、文学作品的阅读： 阅读有争议的文学作品，可以先去网上搜搜大家的观点和争议，自己再去品读会更有效率； 读小说，快速看整段的内容，抓动词、转折等这些关键点，可以更快的理解小说内容； 读小说，先查查作者的生平背景，可以更好的理解小说意义； 读之前，可以看一下同名小说改编的电影； 推荐的三本书 《百年孤独》 《组织行为学》 王颖 我的读书方法： 1.制定年度读书目标； 例如，一年读30本。年底总结一下，对下一年的目标进行调整。（可参考各国家人均读书量，无限动力） 2.书非借不能读也； 除了百年畅销和工具用书，建议不要买书。跟朋友、同事借，或者直接去书店站着看，这样看书最有效率。 3.不要纠结 一本书，其中某个段落不是很理解，反复两天都卡在这几页。那么不要纠结，直接跳过。整体看完了自然就理解了，或者不影响整本书的指导意义。 4.带着问题读书 每本书都是作者的经验精华，但未必每个人在读的过程中都能全面吸收。带着问题读书，生活/工作中的问题解决了，就是活的读书笔记。 推荐的三本书 《明朝那些事儿》 慕容雪村 - 梦境 刘玮玮 读哪些书： 以互联网、电商、科技、信息类为主。 读书方法： 一般是按需读书。先看目录，重点章节细看，了解的、信息量低的章节粗看。 以经典书为主，但时下的行业联系紧密的新书也会买来看。 会在书上写写画画，也会用专门的本子记录要点，并在本子上写下思考的灵感。好书会写书评。也曾期望一书一评。几本相关的书读下来，会写文章投稿。

Scrum入门基础系列之Scrum框架 读过几本Scrum书的人，想必对于Scrum框架都可以如数家珍，如Scrum的3个角色，5个会议，3个工件。在展开这些内容之前，我想先介绍一下Scrum的价值观以及敏捷宣言。 敏捷宣言[1] 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： 个体与互动 胜于 流程与工具 可工作的软件 胜于 详尽的文档 客户协作 胜于 合同谈判 响应变化 胜于 遵循计划 也就是说，尽管右项有其价值，我们更看重左项。 Scrum价值观[2] 专注：一段时间内只专注于少数几件事情。Stop Starting, Start Finishing。团队的能力（精力）是有限的，在有限能力和有限时间范围内，专注于最有价值的事情，以取得更好的成果。 勇气：我们需要勇气去迎接各种挑战。 公开：在团队中公开进展（Progress），即可视化、透明，这样可以很容易的暴露出风险问题和障碍。并且透明也是尊重、信任的基础。 承诺：自组织团队开始的时候做出承诺，并在迭代期间尽全力完成履行承诺。 尊重：团队是坐在一起的，长期稳定的，这有助于加深彼此的尊重和了解。 Scrum框架 Scrum框架是不是银弹，也不是灵丹妙药。实行Scrum不需要团队成员都是精英。因为Scrum只是快速的把问题暴露出来，以至于我们无法忽视和忍受它。Scrum框架是一个团队的流程框架，由自组织的团队进行改进完善。该框架主要包含角色，会议和工件三大部分。 角色 产品负责人（Product Owner） - Scrum中对产品负有全部责任的唯一人。产品负责人需要创建和维护产品Backlog，并需要参加必须的Scrum会议，如Sprint计划会、Sprint评审会等。详情可以期待下一篇博文（Scrum角色）。 ScrumMaster - 这个角色是Scrum框架提出的新角色。他需要对整个Scrum框架非常熟悉，还需要是一个变革大师。在Scrum中，ScrumMaster没有授权，而还需要完成很多的工作，如移除风险等。 开发团队 - 开发团队指的是跨职能的自组织团队。开发团队中可能包含开发人员、测试人员、用户体验工程师、数据库专家等。开发团队负责完成端到端的工作，从而在Sprint结束的时候可以完成产品增量。 会议 Sprint计划会 - Sprint计划会主要分为2部分：做什么和如何做。Scrum团队一起决定他们要做什么，以及如何构建、测试承诺的工作。在计划会议过程中，产品负责人的重要职责之一是解释澄清模糊的需求。最后的产出为Sprint目标和Sprint Backlog。详情敬请期待后续博文。 每日例会（Daily Scrum） - 每天的15分钟站立会议。Scrum团队一起回答三个问题：从上一次例会到现在我完成了什么（重点在于是否完成承诺，以及暴露风险）？从现在到下一次例会我计划完成什么（重点在于承诺）？有什么风险或障碍（尽早暴露问题风险）？ Sprint评审会（Review） - 在Sprint评审会上，产品负责人接受或拒绝团队完成的用户故事。（注：产品负责人应该在平时的工作中进行评审，而不是只在评审会上进行这些工作）这是一个非正式的会议，准备时间不要超过1小时。（注：但必备的准备工作还是需要的） Sprint回顾会（Retrospective） - Scrum团队一起检视和调整他们的工作方法，以达到成熟高效的自组织团队。 产品Backlog梳理会（Product Backlog Refinement） - 由产品负责人组织协调干系人或团队一起进行产品Backlog梳理，包含但不限于新增需求，删除需求，修改需求，拆分需求，改变需求顺序等等。 工件 产品Backlog - Scrum中需求存放的清单，常见的格式为用户故事，也可以包含其他类型的内容，如缺陷、用例、史诗故事等。 Sprint Backlog - 由Sprint中承诺的故事和相应的任务组成。在Sprint过程中，团队每天都会更新Sprint Backlog，在每日例会上讨论并同步有关Sprint Backlog的信息。

作为ScrumMaster或会议主持人，你有没有碰到过如下问题： 会议开着开着跑偏了 会议超时了 会议没有结果 不知道该干什么了  敏捷会议的神器来了 - 敏捷会议魔方。使用这个魔方，可以为你提供会议何时开，开多久，会议的目标，会议的检查清单，成果以及会议中用到的工具等等，详情可以参考上述的示例。 其中的会议包括： Sprint计划会 每日例会 Sprint评审会 Sprint回顾会 计划发布会 产品Backlog梳理会 怎么用这个魔方呢？ 从下面的链接下载文件 打印出来 用剪刀沿着虚线进行裁剪 用胶水把6个面粘起来。 agile-meetings-cube-CN_PDF 原文链接： https://blog.crisp.se/2014/10/16/peterantman/the-agile-meetings-cube 感谢Crispe公司的Peter Antman

Scrum入门基础系列之Scrum起源 说起Scrum就不得不提Scrum之父 - Jeff Sutherland和Ken Schwaber，Jeff在1993年结合他的工作实践创建了Scrum框架，1995年Ken在OOPSLA会议上第一次发表Scrum的论文。此后Scrum之父的两位分别撰写过多篇文章，并联合发布了《Scrum Guide》（Scrum指南）。有关具体的Scrum起源可以参考我之前的一篇博文 - Scrum起源。 说到Scrum的起源，让我们再来看看Scrum的3大支柱：Inspect Adapt Transparent。 其中transparent（即透明性）为基础。离开了透明性（公开）的话，团队成员之间就没有信任和尊重的基础，也很容易发生更多的问题。 另外两个支柱经常一起提到，Inspect and Adapt，即检视与调整。检视与调整组成一个循环。检视，就是查看当前的可交付产品、流程等一切可见的内容；然后根据检视的结果进行反思，下一步如何调整工作计划、流程等等。说到这里，有没有觉得很耳熟呢？检视与调整，PDCA（Plan Do Check Act）环。计划、执行、检查、处理。是的，这就是著名的戴明环，是美国的质量大师在1950年提出的质量改进循环。 然而，PDCA环是戴明原创的吗？让我们往前推20年，看看1930年另一位美国的质量大师沃特 休哈特提出一个PDS（Plan Do See）的概念，和PDCA是不是很相似呢？是的，没错。戴明就是从休哈特的PDS中进一步发扬光大而提出的PDCA环的。 再一次发散一下，这让我想起我读过的一本书《偷师学艺》，书中开篇第一句就是“没有什么是原创的”。大师就是读很多很多书，然后能够吸收消化这些内容，把它们变成自己的再写出来。 怎么样，你有什么感想呢？ Scrum入门基础系列： Scrum入门基础系列之Scrum起源 Scrum入门基础系列之Scrum框架 Scrum入门基础系列之Scrum角色 Scrum入门基础系列之Scrum会议 Scrum入门基础系列之Scrum工件 Scrum入门基础系列之Scrum需求梳理 Scrum入门基础系列之Scrum估算

原文链接：https://www.infoq.com/cn/news/2014/10/scrum-interview-ken-rubin Bob: 多数Scrum书籍是写给开发团队看的。为什么经理或高层也应该看《Scrum精髓》呢？这可是500页的一本书啊！ Ken: 这个问题分为两部分。为什么经理或高管应该熟悉Scrum？为什么尤其是管理层应该读这本书？ 第一部分，为了敏捷的长期成功，组织必须要遵循敏捷原则。经理和高管是遵循敏捷原则的基础。如果高管们不了解敏捷的核心原则，那就很可能他们制定决策和采取行动都是违背了成功采用敏捷交付商业价值的。换句话说，组织内整条价值链遵循敏捷原则对于实现敏捷真正的价值，是非常重要的。 仅仅在开发团队层面相信敏捷和Scrum是目光短浅的。我的经验是Scrum成功的公司，经理和高管都开始拥抱敏捷原则。因此我强烈认为经理和高管必须熟悉敏捷原则和Scrum实践。 第二部分，为什么经理和高管应该读这本书呢？好吧，有个小秘密，这本书原本是专门为经理和高管写的。原来的书名打算叫做“Scrum：管理者指南。”该书旨在告诉经理和高管，通过经济的方法采用Scrum和敏捷，本书和许多其他以开发者或技术为中心的敏捷书籍是有所区别的。 开始写作时，我想写一本易读易懂、图文并茂并以经济为基础的Scrum书籍，不仅经理和高管可以受益，Scrum团队的所有成员也可以受益，这个目标愈发清晰。在写作和从读者收到反馈时，我会大概查看与调整本书的中心思想。 我很愿意做出这种改变，因为我从不相信技术人员只受到技术内容影响，并只想阅读技术书籍。以我的经验，最好的技术人员作出经济有效的决策来指导他们做出技术权衡，并且因此体会到相同风格的讨论可以得到经理和高管的认同。另外，对于技术和业务人员通用的方法使它们共享相同的Scrum知识，因此大家在讨论Scrum及其影响时使用相同的词汇和框架。 本书有500页，从前到后摘录关键内容时，实际只有不到400页。而且，书中还有208副图片——这是我用来呼吁经理和高管的图文并茂方式的延续。本书中至少每隔一页就有一张非常棒的图片，结果就可以快速阅读且很有吸引力。 Bob: 如果从本书中总结一件事情，那会是什么？ Ken: 成功的Scrum来源于价值链横向和纵向都以经济合理的方式采用核心敏捷原则。因此，不论是开发团队成员还是高管采用核心Scrum实践，我们应该采取相似的方式。 Bob: 为什么又写一本Scrum书籍？ Ken: 很好的问题。有以下几个原因。 首先，多数流行的Scrum书籍慢慢过时了。在有些重要的方面，他们实在不能代表当下的实践状态。 其次，不能只是有一本书不仅描述核心的Scrum框架，还有采用Scrum的大多数通用方法。当要回答下面问题时我发现不得不推荐好几本书籍，“开始Scrum你会建议我们读哪本书。” 再次，我发现大多数人的学习是通过结合卓越的视觉表现与宏大叙事以改善的。实际上真没有一本Scrum书籍能提供一套出色的视觉表现，以帮助人们掌握敏捷核心概念。 关于作者 Kenny Rubin 是Innolution公司的管理负责人，该公司是一个敏捷培训公司，主要是帮助组织以一种有效和经济合理的方式来开发产品。作为一名认证的敏捷教练，Rubin已经在敏捷和Scrum、Smalltalk开发、管理面向对象的项目和转型管理方面训练了超过18,000人。他曾在200家公司进行过培训，涵盖的范围从创业公司到财富榜前十的公司。 Rubin是全球Scrum联盟的首席常务董事，该联盟是一个非营利性的组织，主要从事于进行成功运用Scrum的研究。除了创作《Essential Scrum：最流行敏捷过程的实用指南》这本书，他还是1995年出版的《Succeeding with Objects：项目管理的决策框架》的合著者。想了解更多他的背景请登录：https://www.innolution.com，你也可以在该网站上关注他的博客。Twitter的粉丝关注他请@krubinagile。 感谢侯伯薇对本文的审校和杨赛对本文的策划。 购买《Scrum精髓》

在一次和滕振宇、Michael James的cotrain过程中，讲到开发团队的职责时，碰到一个很有趣的讨论结果。当时讨论的问题是： 日常工作中，什么时候你的心情会很好？ 最后有3组同学都提到了“认可（recognition）”这个词。但更有趣的是，虽然都说认可，不过认可的程度是不一样的。下面我就认可在敏捷软件开发中的作用展开谈一下。 自我认可 团队的认可 管理层的认可 客户的认可 1. 自我认可。 你有没有做完一件事情后发现，哇，时间过的这么快！好有成就感啊，又搞定了一个问题！一般这样的情景发生在什么样的事情上呢，或者什么时间呢？这个现象叫做Flow（心流）。 还记得在Dan Pink的《驱动力》（参见我的读书笔记）一书中，提到驱动力3.0的概念（1.0和2.0大家去买一本书自行脑补哈）。在驱动力3.0中（即内在驱动），Dan提到3个关键因素：自主（autonomy），专精（mastery）和目的（purpose）。要达到Flow，上述的3个因素是很关键的。首先是自主，人们可以决定自己做什么，怎么做，什么时候做，在哪儿做。其次是专精，每个人都有一颗专精的心，什么事情都想精益求精，做的更好。刻意的练习，是一条通往专精的康庄大道。最后是目的，不论做什么事情要有明确的目的，可以参考SMART原则。 2. 团队的认可 在Scrum中提倡的是团队绩效，团队的结果。但不代表Scrum就不鼓励个人，最常用的方法是激励卡或感谢卡（为什么采用这种方式呢？给大家留个问题）。Scrum中团队被认可是很关键的，怎么实现呢？进展（progress）很关键，也就是说通过Sprint review来评审潜在可交付的产品增量。每个Sprint都会产出一些结果，因此管理层或客户能感受到实际的内容，也会基于这些内容提供一些反馈。 3. 管理层的认可 管理层的认可，这个问题稍微复杂一点。作为管理层，常常关注在KPI，度量结果。度量本身是一个非常复杂且庞大的问题。根据度量的目的和意义，可以把度量划分为两类：A.如果度量对于团队和个人具有正向激励作用，这就是一个好的度量。 B.如果度量对于团队或个人具有负面的作用，这就不是一个好的度量。所以为了得到管理层的认可，ScrumMaster和团队要一起思考我们需要度量什么指标，怎么度量以满足管理层的需要。 4. 客户的认可 软件开发的最终目的是什么？我认为是让客户高兴，即得到客户的认可。想要得到客户的认可，就需要共情（Empathy），可以换位思考，想其所想，真正解决客户的问题。这里可以参考设计思维（Design Thinking），就不展开论述了。 总结 Scrum中，认可是一个奇妙的事情。人的内心总是渴望认可，不论个体或团队。认可同时也是内在驱动的动力之一。内在驱动还有很多其他类型的动力，详情可以参见《管理3.0》（如好奇心，自主，目标，荣誉，专精，秩序，影响力，人脉，职位等等）