作者：赛斯高丁（Seth Goddin） 评论： > 原则与坚持原则，看似很简单的事情。但在某些极限情况下，是否能坚持原则才最重要，最难能可贵。 问题：你的原则是什么，什么时候你会打破原则？可以的话，请举例说明~ 我们在困难时期暂停的原则并非真正的原则。当它们难以维护时，原则确实很重要。 然而，这不是同一件事，因为拒绝考虑边缘情况。 “言论自由”是一个很好的原则，一个可以生活的原则。但有充分理由不允许在拥挤的电影院里大喊“着火啦”。 边缘案件总是受到无休止的争论。没有简单的亮线。因此，从不考虑边缘情况是很诱人的。 规则就是规则。 但是没有判断力的原则并不是他们看似简单的道路。 因为没有我们对边缘案件的判断，我们已经放弃了责任。 如果我们不作出决定，我们的决定就不再是我们的决定。 努力工作包含自愿陷入困难的召唤。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！

作者：赛斯高丁（Seth Goddin） 评论： > 投身于竞争中，还是寻找一块蓝海（无人竞争的业务）？ 问题：真的存在无竞争的业务吗，你可以列举一下，谢谢。 在渔人码头（Fisherman’s Wharf），有一家又一家餐馆。就在所有其他业务旁边开展业务，这是明智之选吗？ 在书店里有成千上万的书，每本书都在争相找一个读者。 问题是，当周围没有很多书时，书籍是不可能售出的。他们不会在梅西百货（综合百货）卖出很多书。 大多数市场营销人员面临的最大竞争对手是“无”。没有竞争总是占据最大的市场份额。 令人惊讶的解决方案是被竞争所包围。因为这将问题从“if？”变为“which？” 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！

作者：赛斯高丁（Seth Goddin） 评论： > 有人划的线条长，有人划的短，有人划的粗，有人划的细。每个人划出来的都不一样。这代表了这个世界的多样性。 问题：你身边的同事（或同学）为什么会做那些（愚蠢的）事情呢？ 人们当然会这样做。 有趣的见解是要意识到我们划的线似乎每次都在正确的位置。 习惯于我们的线条是独一无二的， 这是了解如何与看待不同事物的人交往的第一步。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！

作者：赛斯高丁（Seth Goddin） 评论： > 有始有终，一件事情、一个潮流、开始了就会有结束。要学会观察结束的标志。从下面可以看出，如果大众可以很容易获取的，就代表括号要关闭。 问题：敏捷将要关闭了吗？ 打开括号 技术出现并改变了文化。 然后，文化使新的产业和运动成为可能，进一步改变了文化。 然后技术出现并结束了我们习以为常的系统。 括号打开，然后，它们可能会关闭。 流行摇滚的括号用晶体管收音机打开（孩子们可以在没有他们父母的情况下听音乐）并关闭流媒体（没有稀缺意味着长尾意味着没有大众市场）。 出版的括号以古腾堡开头，随着书店的去世而告终。数字图书意味着没有稀缺的货架空间，没有稀缺的纸张，没有发行商的权力，没有大众市场。 一扇门打开，然后，有一天，它关闭。 很容易哀悼这些时代的结束，但在我的一生中，这么多的括号已经打开…… 计算机将我们与资源，真理和彼此联系起来（这可能意味着民间真理而不是真实的事实） 医学确实是一门科学，而不是一系列半懂的迷信 音乐家和作家可以在没有看门人的情况下找到观众 我们改变了关于公平的叙述（即使我们刚刚开始取得进步） 传播创意或创办企业从未如此简单 几乎所有信息的访问都是便宜而快速的 如果你足够关心学习什么，你可以 这可能是一天交易悲剧和厄运，如果这是让事情变得更好的最佳方式，我会赞成它。 但是，随着所有已经打开的大门，有什么机会让事情变得更好。做一些事情，让事情变得更好。 HT Kevin Kelly，Chris Anderson，Bernadette Jiwa， Jeff Jarvis，Rohan Rajiv，Paul McGowan，Dan Pink，Roz Zander，David Deutsch等等。更多关于本周播客的系统思考。 开始一个项目。 原文链接 行动 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.

你用的是正确的文化模式吗 作者 | Michael K Sahota 译者 | 陈旭，BoB 授权出品 | 敏捷变革中心 阅读原文 以下为译文： 敏捷的首要挑战是文化-多年来行业研究一直表明，适应新的工作方式通常不会与“日常工作”融为一体。若想敏捷取得成功，我们需要了解其文化以及如何正确的贯彻。关键问题是：你是否使用了正确的文化模式？或者换个不那么挑衅的问法：你使用的文化模式有多有效？让我们分析一些常用的模式，看看它们相较如何。 施耐德文化模式？不。 早在2011/2012年，我就开始尝试施耐德文化模式，以了解和改变组织文化。我的工作和我的博客文章（如何让你的文化有效[注1]）对敏捷社区产生了巨大的影响。（只需看看有多少人使用了这张图，或者引用了我的图表中的单词和符号）。 这个模式我比较喜欢的是： - 容易理解 - 它不评判文化系统，因此可以更加安全地谈论正在发生的事情 - 它可以在一个研讨会中被介绍并激发关于文化实际上是什么的广泛讨论 我停止使用它的原因是： - 它在任何一个给定的文化体系中都是适用的，即使其实际上在不同文化体系上的表现存在着非常明显的差异 - 要明确改变文化是很有挑战性的 竞争价值观框架？不。 在一个非常高的层次上，人们可以理解这或多或少与施耐德模式相同，并且具有相似的特性。我的同事皮特·贝伦斯很好地解释了竞争价值框架相比与施耐德模式的优势[注2]。其优点之一是，它将领导行为与文化象限联系起来。 作者Cameron&Quinn在“诊断和改变组织文化：基于竞争价值框架”中分享了一个非常有力的见解： “表现最好的领导者在四个象限中的每一个象限中都培养了能力和技能。” 高绩效来自于对这些文化象限的超越和整合。这意味着高绩效文化没有一个单一的定义，它是一个超越性性的属性，融合了所有文化。当然，有一个模型提供了一条更清晰的道路。 拉卢文化模式？对！ 这种模式来自于对组织的重塑，这是组织发展中的一本里程碑式的书，它能释放人们的才能，取得惊人的成果。它是螺旋动力学（Spiral Dynamics）的简化和修订版本。这本书是以世界各地组织的案例研究为基础的，这些组织以一种新的工作方式取得了成功。我简化了这个模式，将其变体展示在上面的图表中，并且对teal有一个更相关的定义。（请阅读此处了解拉卢文化模式的解释[注3]。） 当我们分析研究结果和数据时，可以非常清楚地观察到所有文化系统实际上并不相同。但事实上，他们都有一种明确的关联：随着信任和认知（或观念）的逐步加深，组织成果和大家的参与度也会随之增加。 拉卢模型非常强大 - 它非常清楚地向领导者展示他们所负责的组织系统并不是很高效。它要求领导者在听取意见时必须有足够的同理心和理解能力来获取真实的心声。但是当他们确实在倾听时，这就会是一种极大的激励。 它为什么这么好用？一个是它基于真实的公司研究。另一个更重要的点是，每个人在看完模型后都想要“Go Teal”。它激发了人们对保持增长而持续投资的渴望。它帮助领导者意识到他们的红/橙文化实际上是低绩效的。相比之下，人们可以在离开施耐德或竞争价值模型的情形下依旧感觉他们做得很好。 注意：我并不是在鼓吹所有人都要“Go Teal” - 这是一个陷阱。有关此问题的进一步见解和指导，请参阅：如何改变您的组织文化[注4]。 Sahota文化模式？是 事实证明，仅使用拉卢文化模型并不足以应对组织文化的复杂性。提供动力和渴望也是很必要的，然而，有效的改变需要更深入地理解文化本身的概念。 Sahota文化模型[注5]通过识别塑造文化的内联元素提供对文化的清晰理解。它还强调了不仅要关注结构，还需要关注系统意识（或心态）。我们经常陷入只关注结构（特别是过程），而不是人们本身以及他们如何在一起工作的陷阱。这个模型提醒我们，它实际上是关于意识（或心态）和人，而不是关于结构或过程。 延伸阅读 我写了很多关于组织文化变革的文章。下面两篇博文可以作为您探索我博客的起点： - 如何改变您的组织文化[注4] - 如何在各种文化背景下成功敏捷[注6] 原文链接 如何让你的文化有效[注1] 竞争价值框架相比与施耐德模式的优势[注2] 拉卢文化模式的解释[注3] 如何改变您的组织文化[注4] Sahota文化模型[注5] 如何在各种文化背景下成功敏捷[注6] 行动 每日问题 你的组织文化是如何识别的，用了什么模型？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表

作者: Roman Pichler 原文: https://www.romanpichler.com/blog/10-scaling-tips-for-product-people/?doing_wp_cron=1561070340.3916580677032470703125 给产品负责人的十条扩展建议 管理不断增长的产品是一件荣耀与挑战并存的事情：让更多人和团队参与并扩大规模并非易事。本文分享了10个实用技巧，以帮助您（产品负责人）进行有效地扩展。 1. 让合适的人参与进来 少数拥有合适的技能和主观能动性的个人要比那些不专业的当一天和尚撞一天钟的人更具生产力。根据我的经验，产品人员和开发团队成员都是如此。因此，努力让合适的人参与进来。这样可以让您的团队更长时间的保持灵活与高效，并且更具适应性。 虽然这可能听起来像常识，但我看到不止一个组织试图通过随意的增加人手到产品中来完成更多工作。例如，我与之合作的一家公司指派了使用古老编程语言开发企业信息系统的开发人员去开发采用最新技术的全新嵌入式产品。毫无疑问这些人在新岗位上非常挣扎，产品也蒙受了损失。 您的Scrum Master应该能够帮助您找到合适的人并清除相关障碍 - 例如，在没有考虑他们的技能和动机的情况下进行人员调动。 2. 不要过早扩张 我曾经参与过一项新产品开发工作，从项目开始就在三个地点分配了100多名开发人员。虽然最初没有足够的工作让这么多人忙碌，但是开发团队不想浪费时间，开始编写软件。这导致了一个膨胀的、过于复杂的代码库和一个难以适应且维护成本昂贵的产品的诞生。 与其过早地扩大规模，不如尽可能地保持小规模，直到接近产品产生市场价值的规模。这允许您快速响应市场反馈，试验新想法，并进行任何可能需要的架构和技术变动，以便进入增长阶段。 3. 建立最小可行性 另一种减少规模扩张需求的好方法是推出一款最小可行性的产品。与功能更丰富、更有抱负的产品相比，开发这样的产品通常需要更少的时间和更少的人员。更重要的是，它可以更容易地适应市场的变化，以实现产品与市场的契合。 你的产品能有多小取决于它的市场。例如，在最初的iPhone上，苹果创造了一个新的市场，因此可以提供一个相对简约的产品。与之形成对比的是，Apple Watch进入了一个现有市场，直接与三星(Samsung)、Garmin和Fitbit等公司的成熟产品竞争。 4. 帮助开发团队实现自给自足 随着产品的增长，工作负载通常也会增加: 处理越来越多的需要花费更多的精力来理解的不同的用户需求，并决定如何最佳地处理这些需求。如果您的开发团队在这个阶段仍然需要填鸭式地提供详细的需求，那么您的工作量可能会变得非常巨大。 为了减少这种风险，帮助开发团队尽早了解用户并了解他们的需求，例如，让团队成员参与用户调研(作为产品发现工作的一部分)，并让他们直接获得用户对早期产品增量的反馈。这将允许团队成员对解决方案拥有自主权，并做出正确的技术决策，提高参与积极性，为添加更多的团队打下基础，并使您不必创建细节丰富的用户故事并在sprint期间回答许多问题。 5. 有机增长 早在1968年，Melvin Conway就观察到“一个系统的结构和设计它的组织结构之间有着非常密切的关系。”这意味着，如果您从三个开发团队开始，那么您产品的软件体系结构可能由三个主要的子系统组成——不管这个体系结构是否支持所需的用户体验和特性。 为了避免这种风险，从一个产品负责人、一个开发团队和一个Scrum Master开始。一旦您验证了关键的用户体验和技术风险，就可以通过要求团队拆分来进行扩展。然后在新组建的团队中加入更多的人。这种方法也被称为有机生长，因为它模仿了生物的细胞分裂。 除了避免上面提到的Conway法则,有机增长还提供了两个额外的好处:它使增加人手的效果落到实处而不是让一个低效的团队处理所有的新特性,它允许您测量增加人手在生产力和基础设施上的影响。 后者可能看起来相当枯燥，但我曾经与一个组织合作过，为了加快开发速度，该组织一口气从3个开发团队提升到了8个。不幸的是，没有人预料到基础设施无法处理新团队造成的网络流量增加。因此，签入和签出代码突然需要花费几分钟而不是几秒钟，这意味着开发速度显著降低，直到升级工作完成后情况才有所好转。 6. 雇佣功能所有者和功能团队 随着您在开发工作中添加更多人员，请考虑使用功能团队 - 实现端到端功能的团队- 而不是像前端或持久层一样按架构分块构建组件的团队。与组件团队相比，功能团队具有更少的团队间依赖性，并降低了局部优化的风险，提高了整体产品性能。但是，它们确实需要统一标准以避免定义不良变量和代码重复：您通常不希望每个功能团队都重新开发自己的UI而放弃已有的可用代码。 当您将功能团队引入到开发工作中时 - 希望是通过有机增长的方式- 您还必须考虑对工作负载的影响。我的经验表明，单个产品人员通常无法与三个以上的敏捷开发团队合作。因此，您必须考虑让其他产品人员参负责该功能并指导功能团队，我称这些人为功能所有者。下图显示了如何应用该角色。有关更多信息，请参阅我的文章“扩展产品负责人角色”。 7. 从一个站点开始，以循序渐进的方式分发工作（如有必要） 虽然很难将合适的人员聚集在一起，但软件开发中有一些事情比分散团队 - 团队成员在不同地方工作 - 例如伦敦，波士顿和班加罗尔开展新产品开发工作更具反作用。 一般来说，存在越多的不确定性，变化和创新就会越多，参与开发工作的每个人都在同一地点办公（包括产品负责人）就越重要。这使您可以培养融洽的团队氛围，建立有效的协作并就共享标准达成一致，例如，如何协作优化产品待办事项以及进行有效的冲刺评审。 因此，在一个站点的一个团队开始新产品的开发工作。一旦解决了关键的用户体验问题和技术风险，如果需要，可以考虑以循序渐进的方式将工作分散到其他站点。这使您可以了解如何通过布局分布式团队来改进您的实践以取得成功，包括通过视频会议进行产品策略审核和产品待办事项优化的协作。 8. 考虑分拆功能和创建产品变体 成长是一件有趣的事情。虽然这是一个值得庆祝的理由 - 产品终于进入了成长阶段并取得了成功 -我们现在必须应对日益庞大且复杂的目标群体，更多样化的需求，更多的功能以及更多的开发团队。但它不一定非得这样。 还记得Facebook在2014年拆分Messenger并将其作为独立应用推出吗？分拆是一项很好的技术，可以避免成功的产品变得越来越大，越来越异构，并且需要越来越多的人来管理和开发它。取而代之的是，您可以使用自己的专业产品人员和开发团队创建新的专业产品。 产品变体执行类似的工作：但是，您可以创建针对一组特定的目标规划版本，而不是分离一个或多个功能。以微软的图表工具Visio为例，该公司提供VisioStandard和Visio Professional等变体。每个变体都可以由一个单独的团队开发，并拥有自己的产品人员来负责。 9. 利用平台优势 平台会捆绑一些共享资产，例如，共享的前端或后端组件或常见服务（如持久层，日志记录和安全防护），并标准化它们的使用方式。使用平台在扩展环境时有两个好处：首先，它鼓励重用并避免每个团队重复造轮子，比如日志服务。其次，它创建并实施跨不同功能和团队的标准，例如通用用户界面设计。 在创建平台时，您有两种选择：集体所有，要求不同的功能团队共同管理和改进平台。或者，您可以通过专门的平台所有者和团队管理平台。（请注意，平台所有者通常需要深厚的技术功底，因为他们通常需要功能团队讨论新接口和现有接口的更改。）

假敏捷 Fake Agile 作者：Steve Denning (from Forbes) 译者：乔梁 （微信公众号：持续交付2.0） 我现在的微信签名是“别提概念，只解决问题”。而在2013年之前，我用的签名是“别提敏捷，只解决问题”。 为什么呢？因为在2012年的腾讯，敏捷开发方法似乎早已成为“过去时”。但是，还有一大堆问题要解决呀。 （上图与腾讯无关，来自我朋友圈的@王宇） 今天的文章是Martin Folwer在“推它”上一个引用，原文发表于福布斯网站，作者是Steve Denning。点击文末的”原文链接“，看英文版。 正文如下： 有个公司请我去讲讲“假敏捷（fake agile）”。他们想讲我解释一下，如何识别假敏捷，以及如何处理这种情况。这个要求是可以理解的。 就像穿着弗拉门戈服装和谈论弗拉门戈的人一样，没有掌握弗拉门戈舞步或展示弗拉门戈音乐的感觉或天赋，一些所谓敏捷管理的例子的确与真正的敏捷是相关的，但又似是而非。 随着人们越来越认识到“敏捷正在吞噬世界”。德勤和麦肯锡的调查显示，超过90％的高级管理人员高度重视敏捷，而不到10％的人认为他们的公司目前非常敏捷。 愿望与现实之间的差距导致大量的经理，顾问和教练声称自己敏捷并提供帮助公司变得敏捷。 不少公司也有首席执行官问：“我们为什么不敏捷？” 因此，“敏捷”一词经常被抛出，而并未对其含义达成任何共识。 它通常适用于对任何敏捷性没有实质性要求的公司或公司的一部分。 在某种程度上，事实上，实际上非常敏捷的公司往往回避标签，“敏捷”，并使用他们自己的本土词汇，感觉更真实。 1、定义“敏捷” 为了解决困惑，我们需要对真实事物进行定义。 正如这里所解释的，我对过去十年的研究表明，敏捷的主要成果是体现了具有三个主要组成部分的思维模式的公司。 为了强调所有这三个组成部分的重要性，我只是半开玩笑地称它们为“法律”。也就是说，除非你遵守所有这些“法律”，否则你无法真正称你的组织是“敏捷的” 。 我在这里谈论的是整个公司的敏捷性或业务敏捷性。因为，经验表明，只有整个公司使用相同的步调运行时，才会产生敏捷的主要成果。 2、敏捷三定律 客户法则 - 专注于为客户提供价值，作为组织的全部和最终目标。 小团队法则 - 假设所有工作都由小型自组织团队进行，工作周期短，专注于为客户提供价值 网络法则 - 持续努力消除官僚主义和自上而下的等级制度，使公司作为一个互动的团队网络来运作，所有这些都集中在共同努力，为客户提供越来越多的价值。 该定义包括运营敏捷性（operational agility，使现有业务更好）和战略敏捷性（strategic agility ，生成新产品和服务，从而引入新客户）。 该定义独立于那些术语、标签，或者是特定的专有流程或特定品牌。 3、没有标签的敏捷 该定义认识到，一些最成功的敏捷最终都在企业内部实现了本土术语。 换句话说，这些公司甚至没有称自己敏捷并且回避标准的敏捷词汇，其中一些（如Scrum）被故意设计为对管理层没有吸引力。 亚马逊，苹果，Facebook，谷歌，Netflix和微软等大多数规模最大，发展最快的公司在其所做的大部分工作中都具有敏捷性，即使他们通常不使用标准的敏捷词汇。 他们的业务敏捷性是他们成为世界上最有价值公司的重要原因。 3、敏捷的初级阶段 敏捷是一段旅程。 没有哪个公司能够在第一天实施敏捷的所有元素。 掌握敏捷的各个方面需要时间。 当一家公司处于敏捷旅程的初期阶段时，人们可能会称之为“早期敏捷”。这不是假的敏捷，而是“它是不完整的”。 如果旅程顺利进行，那么公司将逐步掌握所有三项敏捷法则以及战略敏捷性。 旅程永无止境：公司继续寻找变得更加敏捷的新方法。 公司敏捷旅程的路径顺序可能不同。 例如，微软大约十年前开始使用小型敏捷团队，如下图所示。 它继续在2008 - 2014年期间以稳步增长的规模进行试验。 只有在Satya Nadella成为微软首席执行官的这段时间之后，这种方法才开始传播到整个组织，人们可能会认为微软是一家开始体现业务敏捷性的公司。 人们可能会称，2014年之前的微软是一个”敏捷初级阶段“公司。 相比之下，亚马逊从1997年股票市场首次亮相开始就接受了对客户的痴迷，明确承诺致力于为客户创造价值并实现市场主导地位。 仅仅五年之后 （大约2002年），亚马逊就拥抱了“双披萨团队”，并开始将网络连接在一起，而不是自上而下的层级。 在此之前，将亚马逊称为早期敏捷实例是合适的，尽管其旅程中早期步骤的顺序与微软不同。

黑暗敏捷 Dark Scrum 作者：Ron Jeffries 译者：陈旭 （微信公众号：敏捷变革中心） 我们来谈谈“黑暗Scrum”。至少在软件方面，Scrum似乎常常压迫人们。通常，Scrum不能像它本该的那样快速、可靠、稳定地交付。结果，每个人都在受苦。大多数情况下，开发人员比任何人都要承受更多的痛苦。 我最近很多想法背后的主题是： 我最初的“敏捷”导师Kent Beck曾经说过，他发明极限编程是为了让程序员的世界更加安全。事实证明，这个世界对程序员来说还并不安全。Scrum可能对程序员来说是非常不安全的。用Scrum的联合创始人之一Ken Schwaber的话来说:“这让我很难过”。 我很认真的说Scrum其实做得相当好，也是一个很好的框架。与决定需要做什么和需要推迟做什么的业务人员有紧密的联系是件好事。团队拥有构建产品所需的所有技能是件好事。每隔几周就构建一个经过测试的有形产品是件好事，向涉众（stakholders）展示它也是件好事，回顾工作的进展以及如何改进它们也是件好事。多年来，我一直在研究、实践和思考Scrum，关于它的一切都非常好。不是很完美，但真的很好。 不幸的是，这只是Scrum的理念，一个理想的按照预期的方式进行的Scrum。就像每一个好的理念一样，现实有时也不尽人意，有时它远远不及设想。我称之为“黑暗Scrum”。 黑暗Scrum: Scrum的一些典型滥用 让我们看看在黑暗Scrum中，事情是如何出错的，只需几个步骤。在本节中，我们将观察一个经历黑暗Scrum的团队，黑暗Scrum领导者的本意是好的，他们只是做错了。 自组织是缓慢发生的 显然，要精通Scrum需要一些时间。它有新的角色和活动。更困难的是，它要求我们接受新的价值观。我们应该让我们的开发人员自行组织工作。我们很容易组织Scrum会议，并通过Scrum角色来称呼自己。但真正做起来却并不容易。 Scrum开始时，接受过培训的人很少，理解它的人更少。很多人认为他们知道自己应该做什么，不过如果他们做错了也不奇怪，事实上他们经常做错。 当今的掌权者常常认为他们的工作是决定人们应该做什么，告诉他们去做，并监督他们做。Scrum则不然，Srum解释需要做什么，然后退后一步，让员工自行组织去完成它。 以Scrum模式运营并不容易。忘记旧的习惯需要时间，学习新习惯需要时间，学习信任团队也需要时间，团队也需要时间来学习如何被信任，在某种程度上，这就是本文想要传递的潜在信息。Scrum的培训为接受培训的人开启了这个学习过程。 黑暗Scrum始于那些熟悉自己的旧工作，但不熟悉新工作的人进行Scrum活动的时候。它是这样的: 太棒了，我们每天都可以帮助团队 每天，团队会聚在一起组织一天的工作。这种做法，即“每日Scrum”，典型的Scrum团队都会做。房间里可能有一个人，ScrumMaster，他被告知应该怎么做。程序员没有被告知，很多时候，甚至产品负责人也没有被告知。几乎可以肯定，其他掌权者也还没有被告知。 但掌权者已经知道他的工作。他的工作是高高在上的监督每个人都在做的事情，确保他们正在做正确的事情，否则就让他们改正。每天都有强制性的会议让他可以这么做，这是多么方便！ 结果是：团队无法围绕他们的任务群策群力，整理出一份适宜的当天的工作方案。取而代之的是掌权者将信息从他们身上抽离出来，在自己的头脑中处理，然后再告诉每个人该做什么。由于事情没有像昨天早上预期的那样被完成，这种不正当的活动往往气氛紧张并充满了互相责备。 黑暗Scrum每天都会压迫团队，自组织不可能产生。 我们也有快捷频繁的规划！ 每个Sprint，Scrum产品负责人都应该与团队会面，并描述需要什么。然后团队确定他们可以做些什么来满足需求，并开始构建它。嗯，理论上就该这样。可实际上，甚至可能没有业务方面的产品负责人。即使有，他们可能也没有接受如何成为产品负责人的培训。 好吧，掌权者有者可能是Scrum的新手，但他们对如何处理这个问题知之甚多。因此，每两周他们就会出现并告诉这些程序员他们必须构建什么。哦，那些程序员会反击。他们懒惰，顽固。但掌权者会继续施压，因为这就是他管理人的方式。所以他们告诉团队该做什么，他们最好这样做。 当然，掌权者很少或根本不知道如何编程，程序员通常至少有一些线索。他们不知道代码的状态是什么，程序员通常都知道。程序员应该决定某项任务在Scrum中的工作量，但在黑暗Scrum中，掌权者更懂这个。他们把任务堆积起来分配，他们认为这是他们的工作：驱使团队前进。 结果永远不会改变。团队认真地尝试做被要求做的事情。他们知道无法说不可能，尽管它就是不可能的。他们只是会因为懒惰，愚蠢和制造麻烦而受到谴责，所以他们尽力而为，但就是不够好。 在Sprint结束时，结果不符合要求。魔法再一次没有发生，开发人员再次失败了。幸运的是，我们有机会直接处理这些事：Sprint评审！ 我们需要批判性的评审已完成和未完成的事项 每个Sprint，利益相关者都会了解团队已达成的成果，并提供接下来相关工作的指导。伟大的理论，但在组织没有精通Scrum的情况下很少能在实践中完成。 黑暗Sprint回顾的第一步是提醒每个人团队“承诺”做什么。（也就是说，在团队说“我们会尝试”之前就提出要求。这是一个承诺，不是吗？）然后看看团队带来的可怜的失败。 你猜怎么着。组织要的比能完成的多，并且没得到满足。团队尝试了，并且在尝试时他们采取了他们能想到的所有捷径来完成所有那些不合理的请求。他们压缩测试工时，他们压缩设计工时，他们甚至在太累而无法思考时工作。 他们没有足量完成工作，已完成的工作做的也并不是很好。团队再一次失败了。 幸运的是，黑暗Scrum拥有掌权者，产品所有者和利益相关者，他们确保程序员可以完全了解他们做得多么糟糕。这肯定会激励每个人下次做得更好，在这一点上，我们有Sprint回顾！ 我们要告诉他们该如何改进 在Sprint回顾中，团队回顾上一次Sprint，以及之前的历史。他们观察哪些进展顺利，哪些进展不顺利，并弄清楚如何在下一次进行改善。 在实践中，黑暗Scrum掌权者会帮助他们，提醒团队尽管他们被紧紧的管理着，但仍存在不足之处。掌权者向这些开发人员明确说明他们的失败- 这种失败 - 肯定是由于他们的懒惰和无能导致的。 为了激励团队做得更好，掌权者会不停的摇头叹息并指出不改进的后果，这总是会引起团队的注意。 有时团队会提出建议。以下是他们可能会说的一些事情，以及掌权者如何回答这些事情： 开发者：我们需要更多的测试来减少bug的数量。 掌权者：不，开发进度已经落后了。你编程的时候动点脑子。你不写bug就不需要解决它们。我们需要新功能，不是测试！ 开发者：这个设计正变得混乱，我们需要重构并提升。 掌权者：不，你一开始想什么了做出这么蹩脚的设计？没人告诉你要设计的这么烂。马上收手把问题解决掉。快到周末了，就用这个周末把它解决掉。 开发者：需求不清晰，他们没有澄清需求，所以我们的工作在最后阶段被否决了。 掌权者：我们花钱雇你就是让你解决问题的。你需要自己想办法解决这些问题。别在这傻坐着了赶紧把我们想要的东西做出来。 现在你应该明白。把团队成员的鼻子放在磨刀石上磨，把脚放在火上烧，软件开发一直是这么干的。Scrum并没有改变这一点。 哎，这真是令人沮丧 嗯，当然，Scrum实际上正试图改变这一切。但是，除非组织的信念和思想真正的发生了变化，旧的管理方式依旧会频繁发生，它每隔几周，甚至每天都在发生。 作为开发人员我们能做什么？ 黑暗Scrum正在滥用Scrum，他们与Scrum试图教给我们的东西明确对立。没有真正的Scrum专家会推荐任何这些做法。正在做这些事的人并没有“做的正确”。每个人都同意这一点。尽管如此，黑暗Scrum真实存在，它还经常发生。在我看来，在人们真正学习Scrum的原则和价值之前，它被滥用几乎是不可避免的。 似乎开发团队除了接受压迫之外别无他法。幸运的是，事实并非如此。好消息是，我们可以做一些强有力的事情。坏消息是，这并不容易。另一个好消息是，它主要是关于编程，我们通常都很擅长这方面。 来自产品负责人和/或其他掌权人的大部分压力来自于他们无法清楚地看到我们正在做什么，我们实际上已经完成了什么。如果我们能清晰的展现出事情的进展，我们可以改变我们的境遇。 如果产品有很多已知的缺陷，我们的领导会认为还有更多，他们会害怕，会把他们的恐惧转化为压力施加给我们，因为恐惧经常表现为愤怒，他们会对我们生气，通常会非常生气。 如果我们在实现功能之前先处理设计或基础设施工作，开发新功能的进展似乎很慢。这使得我们的领导者担心我们会延迟发布或无法提供重要功能。我们将再次遭受他们的恐惧和愤怒的洗礼。 当领导层看不到可工作的软件时，他们会对未来感到害怕 - 这是对的。他们总是以对事情没有助益的方式展现恐惧，这通常是痛苦的。开发人员可以阻止这种情况发生。我知道的唯一方法是提供软件。真实存在，具有可见功能的已经上线的软件！