作者 Sigi Kaltenecker and Peter Hundermark ，译者 曹知渊 发布于 2014年9月19日 | 1 讨论 “最优秀的架构、需求和设计都出自自组织团队（self-organising）之手”，敏捷宣言（Agile Manifesto）如是说。这提出了一系列问题：什么是自组织团队？为什么我们需要他们？自组织团队有什么不一样？有什么办法可以使这种团队模式脱颖而出？ 令人惊讶的是，关于自组织团队的定义以及如何高效地支撑他们的资料很少。组织发展咨询师Sigi Kaltenecker和敏捷教练Peter Hundermark正在编写一本小册子，名字叫《领导自组织团队》，这本书将由InfoQ于2014年年底出版。 书中的一系列文章中将向读者阐述这个主题，本文是其中的第二篇。第一篇的题目是《什么是自组织团队？》，本文的关注点是“为什么我们需要自组织团队？”，而第三篇和最后一篇文章的主题则是《如何领导自组织团队》。 为什么我们需要自组织团队？ 从1980年代以来，我们经历了巨大的变迁： 政治变迁，比如苏联和东欧国家的解体； 社会变迁，比如很多国家愈演愈烈的人口迁移，以及不断提高的教育水平； 人口变迁，西半球不断提到的预期寿命和不断降低的出生率见证了这一点； 环境变迁，主要指的是全球变暖和气候变化； 技术变迁，比如医学、生物和通讯技术，催生了新一代的“数字原住民”（译者注：意为自幼就熟悉信息技术的人）； 经济变迁，从股东利益至上，到所谓金砖四国的出现，再到2008年的全球金融危机。 所有这些改变都给我们带来了新的 挑战。一个组织已经无法自主选择是否要应对这些挑战。必须要做出改变。保持现状的想法就好像试图留住秋天的落叶。一个组织要想成功，它必须充分利用这些变化带来的机遇，同时对危机有足够的准备。换句话说，一个组织必须得跟上当前市场的要求，甚至要领先一步。这很困难，因为市场变幻无常。今天的宠儿，明天可能一败涂地。昨天赖以成功的因素，一夜之间可能成为负担。 “业务敏捷性（business agility）”被证明是一个组织在二十一世纪获得成功的诀窍。改进和革新很久以来就是组织单位的必修课。手上的机会要充分利用，新的可能性要充分挖掘，竞争优势要逐步建立。 对于以上很多问题来说，自组织的敏捷团队看起来都是一剂良药。这种团队听说能： 获得更好的结果 传递更多的商业价值 比微观管理（micro-managed）的团队更加高效地协同工作 学得更快 工作中有更大的动力和乐趣 带来更高的回报 管理者们都忙着在想象自组织团队的样子，但是他们忽略了一个重要的盲点：自组织不仅是一种团队形式，更是一种管理手段。传统的“命令并掌控”的管理手段已经水土不服了，取而代之的是更多对敏捷性的要求。沉闷的官僚机构、令人窒息的控制系统、毫无意义的规划和绩效管理是这种水土不服的几个症状。 根据当代的一些研究，比如德勤领先创新中心的变化指数（The Shift Index），五个雇员中只有一个会全身心投入工作，75%的雇员缺乏动力和激情，只有15%的团队才能完全展现他们的潜力。此外，越来越多的人患上“变革疲劳症”（译者注：对组织的不断调整表现出冷漠和消极），因为很多变革动议最终都无法达到预想的目的。通常这种动议得到的回应是，“千万别再搞了”，而不是成员的积极投入。虽然没有广泛的数据支持这一点，但是各种采样调研显示，60%到80%比例的项目都终结于此。 这种令人沮丧的失败率有很多原因：缺乏透明性、同时实施太多的变革、变革推动者太弱势、缺乏反馈机制，最后但同样重要的是，太过沉湎于项目计划细节、预设的里程碑和明确的结果。不幸的是，我们身边的这些动荡，在无情地嘲弄着我们的那些计划和预测。正如Meg Wheatley试图唤醒我们的话：“我们不能再用旧世界的地图去征服新世界了。” 我们来看看上个世纪典型组织的特点和现代观点的对比，借此我们可以更好地理解哪些变革是势在必行的。 二十世纪 二十一世纪 组织是中央集权下的各种功能的集合体 组织是一整个系统 组织中的各种因素因果关系是可以预料的 复杂的关系网络 中央集权式的协调和控制是必须的 分散式的各种自我组织和自我调节的流程 等级制度和官僚机构 精简的层级网络 股东利益至上 平衡各利益相关方 追求短期利润 通过不断改进和变革，追求长期的成功 变革被动地受项目驱动 变革被视作长期的，顺势而为的行为 表一：组织的典型特征 这个表概括了Russell Ackoff早在二十五年前指出的机械性思考和系统性思考的一些关键区别。尽管这个表格有点极端化，它还是指出了过去和面向将来的两类领导技能所需要的系统性环境。这两种占主导地位的组织特征分别认同两种完全不一样的管理和领导模式带来的价值观和原则：功能化还是全盘布局，一成不变的因果关系还是复杂的思考，行政干预还是不断变革，股东利益至上还是平衡各方利益，把变革看作迫不得已的事还是所有业务的驱动力。 这样，在前一种已经固化的业务流程中，它的管理者必须自己一手设计出一个高绩效的团队。他必须有能力设定明确的目标，建立决策模式，调配资源。糟糕的是这种机械化模式所倡导的原则和价值观至今仍然大行其道。他们还是用旧学院式的实践原则领导着很多企业——甚至更糟，在大学中依然教授着这些理念。尽管我们身边不断出现新的挑战，传统的MBA仍被认为是担任经理人的关键资本。

作者 Ben Linders ，译者 姜信宝 发布于 2014年9月30日 | 讨论 分享到：微博微信FacebookTwitter有道云笔记邮件分享 稍后阅读 我的阅读清单 在敏捷项目中，产品负责人往往被看做是业务和IT联系首要保障的人。但对于有效的IT业务整合，仅有产品负责人是不够的。来自业务、需求和组织的供应方的人们，做些什么可以提高IT和业务整合的效果呢？ 在敏捷和软件架构研讨会2014上，来自Ordina的Klasien Postma介绍了“敏捷项目不能产生有效的IT业务整合”。在她的演讲中，Klasien说明人们如何采用精益思想去决定哪个架构文档是必须的，以及当文档是必须的时候，讨论为什么在许多项目中往往是IT团队采用敏捷实践，并且在关于如何提高敏捷项目中业务、需求和供应方的参与方面给出了一些建议。 Klasien介绍了她的工作经验，她在司法委员会和荷兰税务机关这两个政府部门当中担任过不同的架构师角色。她观察到这些组织中的一些趋势，包括向更少的部门集中化，通过共享服务中心实现专业化，以及更加注重IT管理。 司法委员会采用两种团队：产品开发团队——面向供应链，专注于业务价值和项目范围；服务开发团队——面向组件，专注于质量和跨项目范围的重用性。团队使用多个backlogs以管理他们的工作并与其他团队协作。 Klasien给出一套基于精益思想的问题，可以用来决定哪些架构文档是必须的，以及何时需要它们： 谁需要这个文档？ 为什么他/她需要这个文档？ 对他/她来说这个文档的价值是什么？ 文档丢了会怎么样？ 不同类型的架构文档有不同的用处。领域架构用来做长期规划，项目开始的时候架构文档支撑项目初始化。在迭代期间使用解决方案架构以及控制架构和变更管理。 根据Klasien所说，这些就是为什么需求、供应和业务作为合作伙伴不配合的原因： 用户被称作客户，而不是同事 没有把供应方当做业务伙伴 有许多偏见，且没有足够的自信 Klasien在她的的演讲中提供了一些建议，不同的利益相关人可以参考相应建议提高业务IT整合的效果。她建议业务要意识到他们应该关注自动化，并且业务人员应该钻研自动化流程以及尽量不要反对IT。对来自需求方的利益相关人，她建议当现实和理论不符时应该去拜访执行单位，亲眼查看现状，因为现状与理论总是有偏差的，需求方还应该在制作产品规格时让真正的用户参与，不要认为IT是很困难的事情。对于供应方的利益相关人，她建议邀请产品负责人之外的用户参加演示会以及产品规格会议，并专注于简单的说明。 Klasien说，对于业务IT整合，建立在平等上的合作是最重要的。要把业务现实有效地融入到IT解决方案中，需要让思路脱离固有的模型和预定义的模式。 查看英文原文：How Agile Can Yield Effective IT Business Alignment 感谢杨赛对本文的审校。 给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

本文是Rally公司2013年从9629个使用Rally软件的团队中总结抽取的报告，（所有的报告是基于数据的，所以）非常有参考价值。 我简单翻译总结了一下：（英文版的报告） 全文分为四个维度: 1. 生产力翻倍 关键发现：稳定团队带来如下结果 – 提高60%的生产力 提高40%预测性 提高60%的响应能力 建议： 每个人全心投入到一个团队中 保持团队完整稳定 我的反思： 针对上面的发现和建议，结合软件开发的现状。应该加强产品化思维，减少项目方式（做项目的时候是一个团队，做完了团队就散了）。 2. 质量提升250% 关键发现： 做全Scrum的团队比不做估算的团队质量提高250% 轻型Scrum团队（只估算故事点而不估算任务小时数）整体表现更好。（文中提到针对成熟的敏捷团队） 建议： 有经验的团队可以从轻型Scrum获得最好的结果。 如果是敏捷新手，或非常注重质量，选用全Scrum 我的反思： 虽然最近一年，看板（Kanban）方法越来越火，但个人感觉看板虽然简单，实施起来实属不易（比Scrum用起来更难–貌似越简单的东西，用起来越难）。所以如果我个人推荐的话，还是考虑先从Scrum入手。 3. 上市时间（Time to Market）缩短一半 关键发现：有效控制在制品（WIP）的团队— 流程中的时间（比如用户故事在研发流程中）缩短一半 只有1/4的缺陷 但是生产力低34% 建议： 如果在制品太高了，那就降低它 如果在制品已经很低了，考虑经济驱动因素： 如果生产力到达底线（注：生产力已经不能再低了），那么不要降低在制品数量 如果上市时间（TTM）到达底线，继续降低在制品数量 我的反思： 在制品数量不能无限度的降低，当每个人的在制品是0-1时，生产力会大幅下降。经济合理的在制品数量是每个团队成员1-2 总结上面两条，当降低在制品数量没有显著影响到生产力时，继续降低在制品（WIP） 针对软件行业的大多数团队，在制品数量都是较高的。因此，降低WIP往往能带来意想不到的效果。 推荐一本好书，Don Reinertsen的《The Principles of Product Development Flow》。详细介绍了产品开发中的经典理论，有很多都是反思维了，看了很受启发。 4.

Agile Tour（以下称为敏捷之旅）是一个国际非盈利性组织，于2008年成立，总部位于法国。其目的是提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。它通过一系列的活动，在全球的范围内 极大推广敏捷 分享敏捷的愿景 联合 支持 非盈利活动的背后离不开一大群‘最可爱的人“，即我们每年活动的组织者们。正是有了他们牺牲自己宝贵的休息时间和与家人团聚的时间，才能使敏捷在北京传播开来。 这篇博客主要是想感谢从2010年以来，敏捷之旅北京的历届组织者们： 2014年12月20日 （联想） =================================== Bob Jiang(姜信宝)，廉雨，喻泽高，张明，张峰，高玉峰，周园，刘芸，熊志男，金世亮，王一男，Isly，Melody 2013年12月21日 （创新工场） =================================== Bob Jiang(姜信宝)，谢钊，程嘉利，黄喆，喻泽高，李东，张布航，王立杰，王明兰 2012年12月1日（清华大学出版社） =================================== Bob Jiang，李东，Shining，李小波，蒋麒麟，黎金刚，马斌，Andy Wang，徐毅，周筱敏 2011年11月12日（京仪酒店） =================================== 李东，Bob Jiang，张雷，景兴碧，王兴华，洪志奎，周金根，王立杰 2010年10月30日（京仪酒店） =================================== 李东，Shining

在亚马逊上偶然发现的一本小书，《偷师学艺》。书里面开篇的一段很好，“没有什么是原创的”。引用《圣经》，“太阳底下没有新鲜事。日光之下，并无新事。”那也就是说所有的创意都是“偷”来的。 想起来苹果不是第一个做PC的，而是抄袭IBM的个人电脑，从而取得巨大成功的。微软也没有发明图形化操作系统，而是从苹果偷来了这个很棒的创意。 这本书中介绍的10个创意秘籍，我非常认可的几点摘录一下： 写一本你自己想读的书 努力工作并且与人分享 与人为善 正好昨天也和一位好友梳理了一下自己的人生规划，该找准自己的方向，开始起航了！

敏捷之旅（Agile Tour）是每年一度的非营利性系列会议，旨在把敏捷社区联系起来，系列会议分别在全球众多城市召开，从10月份开始到12月份结束前后历时数月。 敏捷之旅的主要目标是： 针对敏捷的大规模交流：我们在10月份的主要任务是，开展以开发实践为主题的“大众传播”。我们希望把这些内容传递到每一个有听众的地方，从而引起人们对我们新式专业方法的大量关注。 分享我们的敏捷愿景：既然敏捷是与时俱进的，那么我们在为敏捷社区贡献我们的认识、阐释及理念的同时，要对各种新视野保持开放。 本地化增长：促进敏捷领域在世界各地的领导力。 支持：协助我们的同行及当地企业采用敏捷。 你将获得的： 活动之前和期间免费培训的机会（敏捷相关或演讲技巧） 和志同道合的朋友们一起以敏捷的方式做事，从而深刻体会敏捷理念的机会 扩展自己的人脉 扩大自己在敏捷社区中的影响力 活动当天与讲师共进晚餐，一起讨论的机会 如果你对此感兴趣，很简单，发封邮件告诉我吧，我的邮箱是jiangxb@gmail.com，邮件主题为“<你的姓名> + <应募组织者或志愿者>”，正文中请包括以下内容： 姓名 公司 电话 想告诉我的话（为什么想参与到活动中啊，对敏捷之旅有什么期望啊，有什么好的建议和意见啊等等） 敏捷之旅北京的组织者，非你莫属！

最近设计思维（Design Thinking）越来越多的出现在我的视线中，因此在网络中搜索了一些有关设计思维的材料。总体上我的理解为：设计思维是一个设计的过程，分为洞察-构思-原型三部分；另外这三部分不是按顺序执行的，且是迭代进行的。 本文译自https://dthsg.com/what-is-design-thinking/ 设计思维是以人为本的 关注人、客户以及他们的需求，而不是具体的技术或其他情况。 因此采用的方法有观察、访谈、头脑风暴、原型…… 在商业、科技和人文交汇点创新就是根本性的新体验创新。 用户来决定一个产品或服务是否应该存在或开始。 设计思维是重复的学习过程 在项目中，设计思维团队用迭代的方式工作：重新定义问题，发现需求，构思，打造原型，与用户进行验证。 迭代的方式实现了人文领域较高的专业知识，且支撑着多种结果。 设计思维项目包含发散和收敛阶段 设计思维让团队成员发散的思考。 发散思考的结果打造了收敛结束的基础。 设计思维是结构化的方法，沿着项目时间线定义了清晰的里程碑。 一开始项目建立于定义好的明确目标。换句话说，设计思维项目有很不确定性，因为在最后阶段之前结果都是开放的。 设计思维是原型设计 结果的有形性，体验性和验证性是设计思维的本质的要素。 原型允许最终用户在创新的早期过程参与其中。 直观感觉给予复杂挑战的最初期理解。  通常，设计思维远不止这些……

海尔为什么能成为白电老大，暨海尔参观之行的总结： 关键词：创新，人单合一，按单聚散，6S，经典语录 最近微信上流传着很多有关海尔的评论，本人也随波逐流，上周末去了一趟海尔实地考察。下面我将细细道来我的一些观察和体验。 在海尔，听到最多的词汇是创新，并且是从海尔成立之初（1984年），创新就被植入了海尔的基因中。并且海尔非常会使用精神激励来鼓励创新，如在海尔文化展过程中，可以看到典型的启明焊枪（以个人名字命名的创新产品）。 这点让我非常震惊，没有想到一个传统的生产制造商会如此看中且鼓励创新。在海尔，每个员工都可以把创新想法发布出来，每周会有评审会审核想法。一旦创新想法通过，就可能会被载入海尔的史册。当然更重要的是他可以成为自主经营体的负责人，领导并负责这个新想法的实现。 人单合一，全称是人单合一双赢模式。人指的是员工；单指的是市场目标，用户需求，而不是狭义的订单。人单合一即员工与用户融合为一体。双赢指的是员工在为用户创造价值的同时，也体现出自身价值。即由原来的员工听公司的（执行者），转变为员工听用户的，公司听员工的（接口人）。由用户来决定自己的需求（体验）。人单合一使每个人都是自己的CEO。 按单聚散 - 员工由原来的执行者（服务指令）转变为接口人。经典的人事管理为选育用留。互联网概念下的人事管理为在线员工而非在册员工。让员工成为自己的CEO，真正地行动起来。 6S（整理 整顿 清扫 清洁 素养 安全） - 进入海尔大门后，第一眼就看到了非常熟悉的6S（原来为5S，增加一个安全Safe）宣传牌。后来听海尔的朋友介绍，在海尔，6S已经融入到了每天的工作当中，每天班组都要站在大脚印上进行自省。 参观海尔文化展过程中，记录了几句张首席非常经典的话： 企业是人，文化是魂。 13条不准 有缺陷的产品就是废品。 斜坡球体论（上升力是创新，止动力是基础管理） “走出去”有风险，但不“走出去”风险更大。 能阻挡我们的只有我们自己。 参观完海尔后，我问了几个同行的同事什么感受。几位同事都感慨道，今天参观的是互联网公司吧，海尔彻底颠覆了传统制造商的做法，真没想到，等等。 写在最后： 在去青岛的路上，和马老师建议参观完海尔斤进行一次全体的回顾会议（复盘）。马老师欣然同意让我来引导，非常感谢马老师的信任。在整个回顾过程中，我采用了ScrumGathering中国期间学到的4F方法，即Fact（事实），Feeling（感觉），Finding（发现）和Future（未来）。我设计的4个问题为：1. 在今天的参观过程中（包括海尔文化展和下午的海尔大学交流环节），你都看到了什么，听到了什么？ 2. 每个人用1-3个词总结今天参观后的感受。 3. 如果把海尔大学和京东大学做一个比较和联系，你会有什么发现？ 4. 回去之后你会做点什么？ 各位京东大学的同事们，在今后的培训当中，你们也可以尝试4F方法，和ORID（焦点汇谈法）很相似，但很好记，也很容易使用。

最近有几个朋友找我推荐敏捷的书单，借此机会也整理一下自己看过的敏捷书籍。希望能对敏捷刚入门的朋友有些作用。这次推荐书单共有3本书，分别是《Scrum精髓》（极力推荐），《Scrum敏捷软件开发》，《敏捷项目管理》。 《Scrum精髓》 这本书可以说是针对敏捷，特别是Scrum而言是一本宝典（Bible）。书中不仅包含敏捷原则（不同于敏捷宣言对应的12条原则），这些原则是作者结合精益软件开发、经济学原理和敏捷12条原则综合得出的敏捷核心原则（如管理库存，关注闲置工作而不是闲置人员等，具体内容详见第3章）。并且本书中还包含管理者在敏捷环境中应该怎么做，作者结合自己多年的管理经验（从项目经理到职能经理到CXO等）得出作为管理层，在Scrum中应该扮演什么角色。（详情参见第13章）总之，这是一本不可多得的敏捷好书，在亚马逊上长期占据第一的位置。推荐指数，五颗星！下面是编辑推荐内容。 短短几年时间,Scrum 跃升为敏捷首选方法,在全球各地得以普遍应用。针对如何用好、用巧这个看似简单的框架,本书以通俗易懂的语言、条理清晰的脉 络阐述和提炼出 Scrum 的精髓。 全书共 4 部分 23 章,阐述了七大核心概念:Scrum 框架,敏捷原则,冲刺,需求和用户故事,产品订单,估算与速率,技术债;五 大角色:产品负责人,ScrumMaster,开发团队,Scrum 团队结构,经理:Scrum 规划原则及四大规划活动:多层次规划、产品组合规划、产品规划和长期规划; 冲刺四大活动:规划、执行、评审和回顾。 本书取自作者十多年的实践经验,对员工个体和管理层都具有重要的指导和 参考意义,可以帮助企业导入 Scrum 方法实现敏捷转型,从而在动态的商业环 境中以积极的心态拥抱变化,做出优秀、卓越的产品,成就创业、守业、常青基业。 《Scrum敏捷软件开发》 这本书是我读的第一本敏捷书籍，第一次读的时候感触不是很深。不过每一次翻阅都有更深一层的感悟。本书尤其适合组织进行敏捷转型时作为参考。比如书中提到的ADAPT模型，企业转型中成立ETC社区，针对人力资源或PMO等部门在敏捷转型时该做些什么。Mike Cohn的书值得一读。 编辑推荐：本书是Mike Cohn的三大经典著作中影响最为深厚的作品，也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。作者把自己近15年的敏捷实践经验，从更高的思想层次对敏捷和Scrum多年来的经验和教训进行深入而全面的梳理和总结。本书适合经理、开发人员、教练、ScrumMaster、产品负责人、分析师、团队领导或项目领导。 《敏捷项目管理》 这是一本不可多得的在项目管理领域如何应用敏捷的书籍。传统的项目管理是经典的项目管理铁三角（时间、成本和范围），而敏捷项目管理有了新的三角形（价值、质量和约束）。在敏捷项目中，是以价值为核心，质量为本，在约束（时间、成本和范围）条件内完成项目。本书还介绍了传统项目管理更多的是固定范围，而时间和成本不固定，但最终结果是时间和成本都大大超过了预期。在敏捷项目管理中，时间和成本固定（固定的时间盒，人员固定即成本固定–软件开发中人力成本占据大部分），而范围不固定。这样敏捷团队可以专注于高优先级的需求（在产品列表中靠上的需求），从而即使我们没有完成所有需求（在既定的时间和成本内），我们也是完成了最有价值的部分。

昨天发了一篇博文，介绍“每日站会中常见的错误与误区”。有小伙伴问，那些都是错误的做法，那么正确的每日站会应该怎么开？下面就说一下在Scrum中，每日站会是怎么开的。 在冲刺期间的每一天，理想的做法是在每天同一时间，开发团队举行一定时间范围内（不超过15分钟）的每日例会（Daily Scrum，参见下图）。这个检视与调整活动有时也称为“每日站会”（Daily Stand-up），因为大家站着开会可以使会议简明扼要。 举行每日例会的一个常见做法是ScrumMaster负责确保会议更顺畅，每个团队成员都要轮流回答3个问题，让其他团队成员了解情况： 在上次每日例会之后我完成了什么？ 在下次每日例会之前我计划做什么工作？ 有什么障碍让我无法取得进展？ 通过回答这些问题，每个人都能了解全局，知道发生了什么事情，实现冲刺目标的进展如何，对当天的工作，是否需要修改计划，有什么需要处理的问题。每日例会是必不可少的，能够帮助团队管理一个冲刺内快速、灵活的工作流。 每日例会这个活动不是用来解决问题的。相反，很多团队选择的做法把问题的讨论放到每日例会之后，和一小部分感兴趣的人讨论。每日例会也不是传统意义上的状态会议，尤其不是以前那种由项目经理召集、为了解项目最新状态而举行的会议。不过每日例会对于开发团队成员交流冲刺Backlog条目的状态也是可能有帮助的。每日例会主要是一个检视、同步、适应性地制定每日计划的活动，以帮助自组织团队更好地完成工作。 Scrum曾经使用过术语“猪”和“鸡”来区分在每日例会中哪些人应当参与，哪些人只要站在旁边看就行了，不过这两个术语现在已经不用了。这两个农场动物术语来自一个老笑话（这个笑话有几个不同的版本）：“在早餐吃的火腿鸡蛋中，鸡是参与者，猪是全部投入了。”显然，Scrum使用这些术语是为了区分参与者（鸡）和为了实现冲刺目标而全力投入的人（猪）。在每日例会中，只有猪应当发言，如果有鸡参加例会的话，应当作为旁观者。 我发现一种很有用的做法，即把Scrum团队中的每个人都看成猪，不是猪的，就是鸡。当然，不是每个人都赞成我这个观点。例如，产品负责人不需要参加每日例会，所以有些人认为他是鸡（其中的逻辑是，如果不需要参与，又怎么可能“全力投入”呢？）。我认为这好像不对，因为很难想象作为Scrum团队的一员，对于冲刺的最后结果，产品负责人的投入怎么可能比开发团队更少呢？如果在Scrum团队中使用猪和鸡的隐喻，是行不通的。 下面是关于Daily Scrum的另一种描述。（摘自ScrumAlliance官方网站说明） Activity: Daily Scrum The Development Team is self-organizing. The Development Team uses the Daily Scrum meeting to ensure that they are on track for attaining the Sprint Goal. The meeting takes place at the same time and place every day. Each Development Team member gives three bits of information: What I have accomplished since our last Daily Scrum.