作者：Ron Jeffries
译者：年志君 （微信公众号：敏捷家）
背景 这个小故事根据资源、质量、范围和时间的关键度量变量，来描述了一个有效的团队运作方式。故事由罗恩·杰弗里斯翻译自原始的巴比伦楔形文字。
开始啦 从前 … 有一个伟大的国王，他想为几千位最亲密的朋友举行国宴。他把首席工匠叫来，告诉他晚餐的安排。国王描述了他想要最好的餐桌摆设，全部镶入黄金，并镶嵌有错综复杂的珠宝。首席工匠画了一些草图，并与国王就摆设达成了一致。他们同意在几周后再见面，看看餐桌摆设制作的进度计划。
几个星期过去了，首席工匠来报告。他向国王展示了一个时间计划，该计划包括创建摆设的原型，国王的审查，以及最终餐桌摆设的展示。计划表显示，晚宴布置将在11月完成，但国王愿意在10月举行宴会，此时天气仍然晴朗。首席工匠同意在下次会议之前调整工作，以便在10月前完工。
按计划，首席工匠带着原型和修订的10月完工的生产计划展示给国王。而且，工匠还建议与国王要定期见面，以检查进展情况。国王审阅了由于工期缩短而简化设计的原型。国王要求在盘子上要有更多的小天使，在镶嵌的珠宝上有更漂亮的雕刻，在刀叉上增加更复杂的卷轴。首席工匠抗议说，这些新的功能将延迟完工计划，但国王提醒他谁是国王，谁不是。首席工匠退了出去。
落后了 在下一次的项目审查中，事情已经明显落后了。准备好的珠宝太少了，盘子也不够完整，刀叉也做得太少。国王要求工匠们更加努力地工作。首席工匠抗议，但国王再次提醒他们的相对地位。国王要求增加审查的次数，甚至比已经同意的还要频繁。
在下一次审查中，任务并没有完成太多。国王坚持要去现场看看正在做什么。第二天他到了，工匠们有点紧张，但他们知道他们自己的技艺，并且他们大多数都像往常一样努力工作。
“那个人在干什么?”国王指着一个明显的懒鬼问。 “国王啊，他正在休息。”工匠首领回答说。 “这是对我们时间的极大的侮辱。” 国王斥责道: “他们应该在晚上休息，而不是在工作的时候。” “国王啊，就照您说的办。”工匠首领回答说。 国王问:“那边那个人在干什么?” “国王啊，他在磨刀。” “又是在浪费我们的时间。难怪你一事无成。从今以后，工具要在夜间磨，不能在工作中磨。” “国王啊，如你所愿，”首席工匠叹息道。至此告别，直到国王下次审查。 在下一次审查的中途，首席工匠找国王的首席管家，要求增加一些新的学徒帮助完成任务，特别是磨刀的任务。这位管家考虑到国王的财政预算，以管家古老的方式解决了这个问题，没有回应首席工匠的请求。。
在下一次审查时，实际上完成了更多的工作。国王视察了一堆已完成的盘子和器皿。起初，他满意地笑了笑，但当他更仔细地查验时，他的微笑变成了皱眉。
他咆哮道：“这些盘子，这些小天使很粗糙，不像早期的盘子那样精致。如果你就这么做了，客人们是不会有什么好印象的。” “国王啊，工作粗糙，是因您的命令使用了钝的工具。” “我没有命令你做差劲的工作，我命令你不要浪费时间！ “噢，国王，”工匠解释说，“就像陛下没有好的食物和环境就不能举办一个好的宴会一样，我的工匠们也不能用粗糙的工具创造出好的艺术。” “我必须把一切都告诉你吗?”国王尖叫道。“可以让别人磨工具吧!” “国王啊，我已经为此请了新的学徒，但您的管家没有答应我的请求。” 国王咆哮道:“工匠，不要拿这些内部事务来烦我。我可是国王。让工匠们在需要的时候磨砺他们的工具:但他们必须通过加班来弥补时间。” “哦，国王，就照你说的办吧。”首席工匠闷闷不乐地回答。 国王回到视察的地方。很快，他又被激怒了。
“这些盘子，很多还没有雕花的珠宝。这里出什么问题了?” “哦，国王，珠宝损坏的情况越来越严重了。”首席工匠答道。 “是什么导致了这一切，”国王大叫道，”你的人如此无能吗？ “恕我直言，国王陛下，珠宝雕刻是一项微妙的工作。由于没有频繁的休息时间，雕刻者眼睛疲劳，双手颤抖，导致工作失败。 “你这个傻瓜。”国王大声说。“你必须惩罚那些破坏我珍贵珠宝的工人。显然，他们不够小心。” “应该是这样的，”首席工匠鞠躬答道。 在第二次视察时，国王带着怀疑和明显的挑战神气走了进来。当他看到雕刻的质量有所提高时，他平静了一点，当他看到大部分的盘子都镶嵌着宝石时，他几乎高兴起来。然而，随后，他数了数已完成的工作，发现尽管质量提高了，但完成的工作并不多。
“你现在做错了什么，工匠?”你自己要受什么惩罚呢?” “啊，国王，”首席工匠答道，“我的几个主要的工匠因为您的惩罚而生病了，不能工作了。还有一些人离开自己的王国去了邻国，说他们的工作在那里会更受赏识。结果，我们的工人更少，生产的工作也更少了。” “我命令你的工匠们加班，”国王咆哮道，“难道这还没有改善吗?” “国王啊，事实恰恰相反。同样，也有一些人离开了王国，去寻找一个他们会更受赞赏的地方。留下来的大多来自基层，虽然他们精力充沛，但缺乏做你所要求的工作经验。当他们因为加班而疲惫不堪时，又出现了损坏和无效的工作。” “这是不可接受的!我对你们非常失望，工匠。回到你们的住处，等待我决定你们的命运。” 首席工匠退出了，他确信他的时代结束了。
国王非常担心。那个首席工匠辜负了他的期望，他一定会死的。不过国宴很重要，晚宴布置也必须完成。尽管国王不愿意承认这一点，但工匠还是尽力按照命令去做了。国王决定咨询他的巫师，巫师从小就是他的导师和心腹。
巫师 他还没来得及召唤使者，一声巨响和一团烟雾宣告了巫师的到来。据说，当人们想到他的时候，这位巫师总是知道的。 国王跳了一下后，并没有浪费时间。他向巫师描述了围绕晚宴发生的事情，然后表达了他的担忧。“巫师，我觉得首席工匠违抗了我的命令，必须得死。然而，由于我们无法给他适当的建议，我们是否对这个问题也要承担一些责任呢? 不管怎样，没有了首席工匠，我的工匠们怎么准备晚宴呢?”
巫师伸手从稀薄的空气中抓取了一只鸽子。他拔出匕首，打算仔细观察鸽子的内脏，只是刚好想起自己是在王宫里。他把鸽子塞进一个宽大的口袋里，却打了个响指，发出了短暂的火光，接着是一缕烟雾。他观察着烟雾消散的过程，辨别出只有他才能看到的模式。最后，他转向国王。
“陛下，我研究这些问题已经很久了，可以提供一些见解。我们必须考虑工作的四个方面，而且只有四个方面。这些我称之为资源、范围、质量和时间。不可改变的自然法则与这些方面有关。让我们仔细思考，看看他们之间有什么关系。”
巫师继续说:“我把陛下所要求的工作称为所有任务的总和，即范围。” “一个奇怪的名字，巫师，但我熟悉你的神秘方式。说下去。”国王说。 “现在考虑一下资源：陛下有多少工匠。如果一个工匠失踪了，他的工作或工作范围是增加还是减少呢?” “这要看丢失的工匠是好是坏，以及他被赋予了什么责任。”国王回答说。 国王,您是明智的。然而你的工匠们很有能力,正如你所要求的那样,他们肯定会明智地分担责任。那么,减少资源的结果是什么呢?
本文引用了《软件开发的本质》一书的部分观点。它很好地启发了有关价值的思考，同时也是一个大胆的广告。如果你还没有这本书的话，你可以请直接从线上购买。
一、价值的特性
我们可能做的每个特性都是为了给产品增加一些价值。每个特性都需要花时间去实现。我们不知道这些特性有什么价值，也不知道实现这些特性需要多长时间。但我们仍然有可能能很好地感知应该做什么。
假设上面这些特性的高度是它们的价值，宽度是它们的代价（成本或花销）。哪一个应该先做，哪一个应该稍后做呢?这样假设很清楚，不是吗?
二、价值的增长取决于我们选择做什么
如果我们优先选择高价值、低成本的特性，而后再实现低价值、高成本的特性，这样看价值增长的差异，就是3倍与1倍的差异。而在大多数产品中，最好的创意比最差的要好几十倍，甚至更多。但是这个结果很难在页面上展示出来!
一些被推迟实现的特性看起来相当枯燥。假设我们做一些不同的，更有价值的特性，甚至是其他产品，会发生什么?
三、我们甚至可以把投资转向新的产品
最高价值的特性最先被频繁地发布，那些不值得花时间和金钱去做的特性很快就会出现，这是一件好事。我们常常可以通过投资新的产品而做得更好。
我们想做的下一个产品是什么呢?谁会对产品的变化感到消极呢?我们怎样才能使这种转变对每个人都有好处呢?我们能否专注于一个投资组合，而不是一个回报率递减的单独产品?我们能展示更多更有价值的软件吗?
最好的价值来源于小的、以价值为中心的特性，并且频繁的交付。
是的，我们可以看到小的特性可以更快地交付价值。接下来让我们考虑管理我们的项目。较小的可见结果会对管理有帮助吗？还是会给我们带来阻碍?
我们的团队呢?他们是按照这样的方式工作的吗?他们需要的人，需要的技能，需要的帮助被满足了吗?继续读下去——我们会讨论所有这些事情。
首先要记住的是，我们通过交付软件的每个特性来获得最好的结果。
你喜欢这些来自《软件开发的本质》的引用吗? 已经有一本了吗?或许你有很多的朋友和同事也需要一本呢!
作者：Ron Jeffries
译者：年志君
审校：Bob Jiang
原文链接
我什么时候不使用TDD？ Alex Bunardzic一直是有关TDD及其反对者的 Twitter 话题中的一员。他的担忧之一是TDD的支持者同意TDD并不总是合适的，但没有说什么时候不用TDD。让我们探索一下。
亚历克斯的担忧似乎在于他正试图让组织中的人员使用TDD，其中许多人提出了异议。这些异议之一是，甚至专家都说他们并不总是使用TDD，所以我们为什么要在这里使用TDD。
现在，如果您接受销售培训0^，那么您将要教的一件事是如何处理异议。第一项也是最强大的技术是忽略它们。在销售中，您可能会继续提出反对意见，这就是为什么我们很多人讨厌被出售的原因之一。
我没有卖任何东西，但似乎Alex负责在他的公司中销售TDD，所以我们可能有不同的担忧。我在写和讲授思想上的关注是可以理解的。我很乐意将决定权交给听众。如果我每月都有这么多TDD销售的配额，我可能会有所不同。
尽管如此，我确实知道有些情况下我通常不使用TDD，并且我或多或少乐于谈论它们。或多或少是因为TDD主题似乎不断地深入我的灵魂。无论如何，这里是：
我什么时候不用TDD？ 让我数一数：我*有时*不用TDD的…
当手头没有合适的TDD工具时； 当我不知道如何测试某事时； 当输出本质上是可见时（可视化）； 当程序是一个简单的，会扔掉的。 让我们通过示例进一步探讨其中的每一个情况。
当没有像样的测试工具可以立即使用时，我通常不用TDD。
一个例子是我iPad上的Codea Lua。它没有附带TDD工具，而且很长一段时间没有可用的工具。我很喜欢写一个玩玩，因为在Lua中反思很有趣，但从未真正得出我喜欢的东西。
然后出现了CodeaUnit，它工作得非常好，我最近在示例TDD会话中使用了它。但是请参阅以下部分。
另一个示例是Second Life的脚本语言LSL。该语言非常初级，不包含反射功能，这在您尝试生成一个体面的TDD框架时非常重要。如果没有可用的工具，则我用TDD的频率将比理想情况低。
但是请注意：缺少一个不错的工具并不是不使用TDD的很好理由。通常，我在Lua或LSL上的开发所花的时间要比遵循TDD学科所需的时间长。我怎么知道？我对使用TDD和不使用TDD时会发生的事情非常有经验，因此我很容易认识到缺少测试会伤害我的情况。
最好的迹象是调试会话需要更多的时间。这总是表明更多测试时我‘会做得更好。
如果工具不易使用，您是否应该考虑不使用TDD？
我认为这不是很好的理由。几乎可以肯定的是，无论您使用哪种语言，都可以使用一个很好的TDD工具。对我来说，如果是只写一些小小的一次性程序的人，寻找和学习该工具的投资*可能*不值得。您正在专业地工作。对于您来说，投资可能是值得的。
很可能，这对我来说是值得的。在没有TDD的情况下工作会使我更经常地进入调试模式。即使对于我的小型项目，TDD的价值也可能存在。我将自己不这样做的原因归咎于懒惰，说实话而不是出于智慧。
当输出本质上是可见（可视化）时，我通常不进行测试。
在Codea / Lua中，人们经常编写一些代码在屏幕上绘制运动对象。在《第二人生》中，我经常编写脚本来在虚拟世界中移动事物。尽管这些脚本中的某些部分可能会从TDD中受益，但总会有一些-其主要功能使我不知道如何有效地使用TDD。
让我们举两个例子。
想象一下，我想在iPad屏幕上绘制一个蒸汽引擎。该图片的一部分将是引擎驱动轮，该驱动轮会随着火车的移动而旋转。推杆安装在该轮的半径中间附近。该推杆的轮端绕转0^左右。该杆的另一端在连接到蒸汽活塞的另一根水平杆的推动下水平地前后移动，该水平杆只是来回运动。
我们的任务是在轮子旋转时针对每个角度计算推杆的位置。为了弄清楚该如何做，我绘制了一些草图并做了一些几何处理（通常使用直角三角形），直到我弄清楚了在每个方向盘上的远端在哪个位置。
显然，当车轮为零时，推杆完全远离车轮，其端点为l + r，其中r为推杆圆的半径，l为杆的长度，假设车轮位于零位置。
当车轮处于180度时，终点将在l-r处。当车轮位于90或270时，终点将为…sqrt（l ^ 2-r ^ 2）。同时，如果角度为θ，则起点为 rotBy（θ）。
大概。多一点的几何使我相信终点是sqrt(l*l - y*y) - x，其中x和y是起点的相对坐标。
也许，有一种更好的方法来计算终点。它一定是某种 sin或cos (正弦或余弦)功能或类似的东西。但是这种方法很好用，因为我们有能力在两点之间画一条线。
所以我只是编写了代码，看起来像这样，没有进行大量清理：
-- Loco function setup() theta = 0 -- degrees deltaTheta = 1 origin = vec2(600,600) radius = 200 rodRadius = radius/2 rodLength = 500 end function draw() background(40, 40, 50) strokeWidth(5) drawWheel() drawRod() theta = theta + deltaTheta end function radians(angleInDegrees) return angleInDegrees*math.
我常说我可能发明了故事点，如果真是这样，现在我会感到很抱歉。让我们一起来探索我现在对故事点的思考。至少有一个人对我所想的很感兴趣。 – Ron Jeffries
当然，故事是极限编程的思想，不是Scrum的。不知何故，Scrum践行者接受了这个理念。尽管在Scrum官方指南中有关待办事项的内容，将待办事项作为用户故事是一种普遍的Scrum实践。
至少在某种程度上来说，他们是对的。我已经在其他地方写了关于故事的常规用法，正如它应该被写下来一样。在这里，我们将讨论的是”故事点”。
在极限编程中，故事最初是用来估算时间的：实现故事需要花费的时间。紧接着我们来谈谈”理想天数”，它是用来非正式地描述如果别人让你尽自己最大努力单独完成故事需花费的时长。我们用理想的天数乘于一个”负载因子”转换得到实际需要的时间。负载因子通常是3（3天才能完成一个理想天数的工作量）。
我们刚谈到用天数来估算，经常是把”理想”抛开。这将导致的结果是我们的老板很疑惑，怎么是要花费3天来完成本来1天就可以完成的任务，又或者说，为什么我们不能用3周来完成50”天”的工作。
我记得，我们开始称”理想天数”只是”点”。所以一个故事应该用3个点来估算，这就意味着这个故事需要花费大概9天来我完成。总之，我们确实也是只用点来决定多少工作进入一个迭代，所以如果我们说大概20个点，没人会反对。
我可能已提出改名字的建议。如果我真这样做了，现在会感到抱歉。从给我的同事西蒙的电子邮件中，有一些关于目前我对这个话题的想法，他问到：
你真的后悔发明了故事点，或者你只是简单谴责当他们做相关度量时，没有正确理解而导致滥用吗？
我答道：
我当然谴责他们滥用；
我认为使用故事点来预测”我们将什么时候完成”充其量是个无力的想法；
我觉得跟踪实际与估算的比较充其量是浪费；
我觉得比较团队的估算质量或速率是危险的。
让我们更深入一点。
实际上，一些用来做”敏捷”的方法，以更容易计划的名义，推荐给各团队规范化用户故事点。这表面上看起来非常合乎情理，却太容易掉进团队比较的陷阱，组织也是经常这样做的。
比较 首先，即使他们看起来很像，每个团队都有自己的技能和特定工作环境。所以如果他们看两个貌似一样的故事，一个团队说这是个2，另一个团队说这是个6，那就不是很有趣了，当然这样比较两个团队也不是个有效的方法。
现在我们怀着好奇心来了解这种状况，首先判断条件是否足够相似来比较，其次试问估算更高的团队，是否需要咱们能提供的帮助。这样就很好。隐式或显式地结束”更慢”团队的劣势或以某种方式搞砸——这将是非常糟糕的事，但不幸的却是很常见的。
我认为对很多管理者来说，比较两个产品团队是件极其诱人的事。在可能的情况下，抛开故事点的概念，甚至抛开评估点的概念，我认为也是足够不可抗拒的。我们回到如何用更少的估算来开展工作问题上，这里还有其他的文章也讲到这方面内容的。
跟踪 对于很多管理者，估算的存在意味着”实际”的存在，意味着你应该拿估算与实际比较，确保估算与实际相匹配。当估算与实际不匹配时，就意味着人们应该要学习如何更好的估算。
对我来说，真正的敏捷里最重要的是选择接下来要做的事，并且立即开展去做。最关键的问题是找出最有价值的事做，并且快速实施。快速开展去做，归结为去做小部分价值高的和快速迭代。如果不这样做，故事成本估算帮助不到什么。
因此，如果估算的存在让管理者把注意力从价值中移开，取而代之的是改善估算，把精力从快速交付真正有价值的东西转移。
这让我觉得估算，不管是点还是时间，都是浪费！
压力 有关估算/实际涉及的是老板们需要”更多”的自然压力。尽管很多团队已经完成了，这是不够的。更多，更多，更多。
交付有价值的东西，最好的方式不是更多、更多、更多，而是频繁的做有价值的东西。如果我们把故事分解到”足够小”替代估算故事，从而达到一直持续平稳地交付有价值的东西。
聚焦在更多的增值。让团队在越来越大的压力下做更多的需求，不可避免地会产生一个坏结果：团队试图更快速地去做，而忽略代码质量和测试。他们瞬间开始承载越来越多的缺陷，因为持续返工去修复缺陷，甚至由于代码质量迅速下滑而放慢速度。事情变得越来越糟糕，压力持续增长，这将演变成一场灾难的节奏。
由于估算至少被卷入过度压力的投入中，我宁愿避免。
我更深入点：我宁愿完全避免迭代或冲刺计划。在接下来几周，我们不会为去填补预算而工作，而会因为接下来有几项最重要的事情清单而做。
预测完成 一种常见的做法是做个基本特性列表，先想一会，然后决定定义我们产品的下一次发布。当然，接下来的问题是”这些什么时候能全部完成？”
没有人知道这个问题的答案。我们可以做很多工作来改善我们不知道的事，在某些领域和某些时候，这当中的一些事也是值得做的，譬如当一个大的合同等待投标的时候。但是当我们正忙于开发内部或外部客户的解决方案时，尽可能地频繁提供少量有价值的东西，而不是等到通常会无限期拖延的全功能一起发布。
选择临近下一次发布给客户的日期，尽可能地挑选好东西到发布中，这样更好。估算故事点或时间阻碍了交付。在我看来，如果可能的话，这最好要避免。
分解（拆分） 那么问题来了，如果你不喜欢故事估算，那你喜欢什么呢？好吧，我喜欢故事分解，它是将大的故事点分解成更小的故事点集合，每个小故事点尽可能高的价值，然而只需要很少的时间就可以完成，理想情况下，少于一天，也许只是几个小时。
现在，我不在乎与你争论分解（拆分）时是否必须进行某种估算。如果你或者你团队的估算只是在脑海里，没有告诉任何人，那么，不论是故事点或时间的估算问题，就不太可能提出来。当然，了解故事点”可能足够小”和”可能不够小”之间的差异并不等同于知道”三天”和”一天”的差别。
另外，这有个技巧。我在 Getting Small Stories 和Slicing, Estimating, Trimming有提到。我也是从Neil Killick学的：分解故事直到它只需要一个验收测试。一个好的故事点只需要很少的实践。
当然，还有关于估算主题的其他文章，点击链接会有超乎你想了解的。
预测将来 但是…难道我们不应该合理的知道一个产品发布需要多长时间和估算是否必要吗？然而也许这不是故事估算。你应该不会把你的需求归结到故事层面，若这么干，貌似是很大程度的浪费。
当然，如果你必须要这么做，那就这么做。无论我做什么或者我的关于你该做什么的理论，只是理念。最终你需要做的是在自己所处的环境下尽一切可能的成功。只是我觉得可以有些更好的东西。
第一，想想下一次发布的一个或多个重要功能。讲讲这些功能可以解决什么问题和什么样的软件可以帮助解决这些问题。谈谈可以解决一些问题的最简单功能。我们不必要解决所有的问题：通常我们提供一些解决方案足以推动事情的发展。
第二，想一个到那时你觉得可以构建出一些好的功能点的时间节点。设置最后的期限并开始着手工作。
第三，再分解重要的功能故事点并实现它。你应该能够在一天或更容易地实现。只做下一步最重要的：别试图老是先实现边边角角的功能。你应该尝试这样的思维框架”如果做了这个小东西，客户Jack就会在实际中使用它”。然后，就做这个小东西并且让客户Jack试用它。我们想尽可能快的持续传递价值。
我们想把正在做的东西的价值明显化，让产品经理或者其他老板等不及想看到产品。这样…我们就在有或没有故事估算的情况下做了正确的事。
译者：Nikijv
审校：Bob Jiang
英文原文
一个Twitter的帖子问”敏捷”是否反管理，以及”敏捷”为什么经常看起来很像反管理。简单写一下，本文中我个人的观点是敏捷软件开发如敏捷宣言所设想的那样，并不是反管理。这比反管理更激进：这是一种完全不同的管理方法。
敏捷软件开发仍然比当今的认知更激进，相当的不幸，包括大部分品牌和方法，在我这个有点老的男人对云观点大喊大叫的时候，也被大多数较小的”敏捷”供应商所采用。
敏捷软件开发正如我们所定义的那样，对于业务与开发间的日常协作较为频繁，以维持增量的可工作软件。这样团队称为自组织团队，尤其要说明的是：最好的架构、需求、设计来自这些自组织团队。
原则上很清楚，软件、架构、设计等一切工作都源自于团队，从团队中涌现。
例如，需求不来自于一些业务单元，而是通过中央委员会进行传递，然后传递到一些传统部门或项目部门直到它落在一些程序员的办公桌上。
这不是”反”管理。这根本不涉及解决类似于预算工作、人员补偿、评估性能或者其他”管理”关心的主题。
当然，敏捷软件开发提出了一个新的、不同于软件产品制作的管理。尤其通过基于工作软件的可持续生产使用的自组织、增量、速度技术，是解决软件开发应该被管理的新方式。
敏捷是反管理的么？我不这么认为，敏捷明确反泰勒式的管理，而支持推动管理。
同样，像所有好人一样，我们更乐于好的富有成效的管理，强烈反对贫瘠、无效、有害的管理。
但是我想建议这个底线是：
如果一个组织试图通过任何传统的方式控制团队的选择，该做什么以及如何做的选择来管理敏捷软件开发，这样很可能他们做错了。
如果你是敏捷的支持者，你试图与传统管理达成某种中间状态或和解，有可能你也是没有真正理解敏捷软件开发的根本意图。
一、scrum在发光
考虑到Scrum的构想，最流行的敏捷方法如果不是最有效的，那什么是？
Scrum称为自组织的团队，包括产品负责人，被授权于全部权利和责任，负责大型组织团队的投资回报率。Scrum团队中Scrum开发者的开发团队，必须包含交付产品增量的”全部必要技能”，一个被集成、测试过的、可工作软件包括团队迄今为止产生的所有价值元素。
Scrum承认Scrum团队是嵌入式的，以某种方式，在一个组织中，组织提供了资金（投资），干系人关心Scrum团队做了什么。敏捷团队通过每个冲刺向干系人展示他们已完成的工作，邀请并听取干系人的意见。Scrum团队与全权负责的产品负责人决定下一个冲刺做什么以及怎么做。
冲刺审查是Scrum团队及其嵌入组织之间的完整接口。
关于Scrum仍然有些问题没有解答，同样这些问题在上面Twitter的帖子中也涉及到了。Scrum不会告诉你如何预算，如何决定补偿，如何评估性能等等。
在Scrum课程中，人们经常询问各种管理职能。有个经典实践可以回应，课程上小组在便利贴上写下他们能想到的所有管理职能。他们可以把这些便利贴放到下面4个位置：开发团队，产品负责人，Scrum教练以及其他。
将会有两件事发生。首先，许多传统管理职能转移到一个或多个Scrum团队元素。由团队分配任务，由产品负责人决定要构建什么，由Scrum教练支撑和引导等等。有趣的一点是，总有些管理职能被贴到其他堆中。Scrum甚至不会建议如何做这些：这已经超出了Scrum的范围。
然而，很明显，Scrum打算不管这些超出范围的管理职能是什么，它们与团队的首要接口，可能只通过冲刺审查。尤其是除了产品负责人，没有人可以要求团队做任何事情，Scrum对”经理”在Scrum团队运行时可以做什么做了非常具体的限制。
二、敏捷软件开发是反管理么
敏捷软件开发需要一种新的管理方式，在团队规模上，团队内部拥有对产品的所有权利和责任，而且最主要的接口是检查实际演变的产品。
不一定是”反管理”，但一定与某些类型的管理背道而驰，尤其是源自于泰勒主义更具有侵入性的形式——福特主义，将工作视为机器，工人几乎没有权利或仲裁。尽管敏捷软件开发肯定要求从团队内部而不是外部应用这些概念，但与戴明和统计过程控制等概念的对立程度要小得多。
但我觉得主要的概念已经相当清楚：敏捷软件开发是一种完全不同的管理方法，尽可能的把权利和责任下放给团队。这种管理方法对于如何走得更远没有设置上限，但它设定了一个相当严格的下线，这个下线是嵌入在团队内部的产品做什么以及如何做。
三、这些想法的限制是什么
这很难说。我们通过敏捷团队的成长能力去决定谁在团队谁不在团队，这对薪酬和评估有很大影响。我们开始听到团队中的谁直接与客户合作，客户有时基于固定价格安排，或者更常见的基于运行速率为产品提供资金。
今天，更多的限制是被组织强加的——试图做”敏捷”，这些限制中有很多是明显错误的。有时组织没有从战略上很好地理解最好的管理是如何的。我通常认为,个人管理结构应在敏捷之前就位：不同的团队成员”属于”一个或另一个经理,而该经理则继续尝试对团队成员的行为进行控制。
坦白讲，自组织团队被授权，而这导致冲突、混乱以及很多时候应该做敏捷组织主要来源走向黑暗敏捷。这个观点是正确的。
底线，敏捷软件开发提倡不同的管理方式，很可能与一些过时的管理观念不相容，不幸的是，这些观念在今天仍然相当普遍。
反对的？不。完全不同？是的。
原文链接
黑暗敏捷 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的原则和价值之前，它被滥用几乎是不可避免的。
似乎开发团队除了接受压迫之外别无他法。幸运的是，事实并非如此。好消息是，我们可以做一些强有力的事情。坏消息是，这并不容易。另一个好消息是，它主要是关于编程，我们通常都很擅长这方面。 来自产品负责人和/或其他掌权人的大部分压力来自于他们无法清楚地看到我们正在做什么，我们实际上已经完成了什么。如果我们能清晰的展现出事情的进展，我们可以改变我们的境遇。
如果产品有很多已知的缺陷，我们的领导会认为还有更多，他们会害怕，会把他们的恐惧转化为压力施加给我们，因为恐惧经常表现为愤怒，他们会对我们生气，通常会非常生气。 如果我们在实现功能之前先处理设计或基础设施工作，开发新功能的进展似乎很慢。这使得我们的领导者担心我们会延迟发布或无法提供重要功能。我们将再次遭受他们的恐惧和愤怒的洗礼。 当领导层看不到可工作的软件时，他们会对未来感到害怕 - 这是对的。他们总是以对事情没有助益的方式展现恐惧，这通常是痛苦的。开发人员可以阻止这种情况发生。我知道的唯一方法是提供软件。真实存在，具有可见功能的已经上线的软件！
