你应该使用敏捷来建造你的下一个家吗?
在我们开始讨论敏捷和治理之前structure-governance-metrics框架我们正在扩建，我想花点时间看看能不能告诉你们我妻子和我今年夏天打算建的房子。这是一个重要的对话，因为我们需要建立一个关于敏捷项目计划的共同理解。
场景一:敏捷家庭建设者团队
我妻子和我决定要建一个新家。我们在一个不错的社区找到了一处我们喜欢的房产。首先，我们要找一个我们喜欢并且信任的建筑商。我和我的妻子对适合我们和我们家庭的房子类型有一个非常好的想法，我们决定花大约50万美元来完成房子。但是，它需要在我们的孩子暑假离开学校之前完成。
下一步是联系建造者，看看他能做些什么。
第二天，我们来到建筑工人的办公室，告诉他我们对新家的计划。建造者非常兴奋，看起来很有能力，并且非常有信心在我们设定的时间和成本限制内建造房子。我们问他下一步计划如何建造我们的新家。令我们惊讶的是，他告诉我们，他是一个敏捷的构建者，不做任何计划。
构建者继续向我们解释，作为一个敏捷的构建者，他不做任何计划。他将每两周与我们会面一次，以确定我们的优先事项，并确定下一个最重要的项目。每隔两周我们就可以检查他做了什么随时改变我们的想法。他告诉我这对我最有利，因为我不知道我到底想要什么，直到我看到它。
当我问他，当我没有时间和钱的时候，我是否能得到我想要的房子时，他不知道，但他向我保证，我会尽早得到房子里最有价值的部分。此外，我可以在建造过程中的任何时候搬进房子，如果我决定我已经在任何时候建造了足够的房子，我可以提前取消合同，只支付他工作几周的工资加上剩余合同的20%。
所以我的问题是，你会这样花钱吗?
悖论
大多数人在花自己的钱时，都想知道时间和金钱用完后他们会得到什么。他们想要一些保证，保证他们有足够的卧室和浴室。他们想知道地块的面积，他们想要的是一层还是两层的房子，他们想知道车库能容纳多少辆车。
人们明白，在构建过程的后期，他们可能不得不做出一些权衡。他们可能会选择地毯，不得不在照明方面做出一些权衡，或者他们可能会决定他们想要昂贵的橱柜，而选择便宜的硬木地板。此外，他们可能想推迟决定颜色，或完成，或他们想在前院灌木。他们不愿意把卧室留给别人。
我们不会这样花我们自己的钱，但这是我们要求客户在与我们一起构建软件时花钱的方式。
场景二:规模化的敏捷住宅建造者
幸运的是，这不是我们的建筑工人要求我们建造房子的方式。我和妻子确实见过他，并描述了我们梦想中的家。我们讨论了我们想要建造的房产，卧室、浴室的数量，以及我们能放进车库的汽车的数量。此外，我们还讨论了饰面、地板的质量，以及我们希望如何美化庭院。这花了大约一个小时。
在那之后，我们花了一两个星期的时间与架构师开会。她和我对房间的布局，楼层数，地下室的布局，以及房子在地块上的位置都有详细的了解。我们对地板和橱柜做了高层决策，但没有选择任何细节，没有选择任何颜色，也没有选择特定的电器、灯具或门把手。还有很多事没决定。
我们决定的是哪些东西会推动房子的成本。这些东西以后改起来会很昂贵。在这个过程中，我们知道有很多东西会改变，但也有一些东西真的很难改变，这些决定必须尽早做出。我们讨论了一旦动工的潜在风险，并为防止出现任何问题进行了缓冲。
结果是房子的蓝图和立面。我们有一个项目预算，包括建筑成本、材料成本和各种工具和用品。每一行都考虑了建造者的利润。每一行都代表了房子的一些特征或属性，当房子完成时我可能会关心这些。我们在几周内就完成了所有这些工作，并没有对房子做任何详细的决定。
根据预算做计划
有趣的是，计划的第一个削减比我们想要的多出20万美元，我们意识到有一些风险，可能应该再缓冲5万美元，以防万一。尽管我信任建造商，我还是让我的注册会计师和顾问一行一行地审查了计划，以确保所有的成本都是合理的，在我们决定继续前进之前，我们做出了一个合理的财务决定。
在我们审查计划的时候，建筑商对我说了一些对我们如何管理这个项目至关重要的话。他说我有2万的硬木地板预算。以这个价格，他向我保证，我将能够得到一个高质量的地板，特别长和特别宽的木板，一个非常高质量的木材和非常高质量的饰面。也就是说，我的硬木地板预算是2万。
当有时间来铺设硬木地板时，就由我来选择我想要铺设什么样的地板。如果我决定要一个便宜点的楼层，我可以省下钱，把它用在别的地方。如果我想要一种像巴西樱桃这样的异国情调的木材，那就得花更多的钱，我还要额外付钱。这最终取决于我，但他会与我合作，了解我的权衡和任何相关成本。
在企业规模下，评估变成预算
我立刻意识到这正是我指导团队定义、评估和计划软件项目的方式。你必须有一个高层次的计划，尽早做出关键的决定，并且有时间和成本估算来呈现给客户。
你不需要做的是在你开始之前定义任何东西。你必须建立预算来约束你的不确定性。
在建造者做出估计的时候，他必须按照这个估计来管理项目……估计变成了预算。建设者必须和我一起工作，作为主要的利益相关者，帮助我在预算之内做出权衡。当我们分解软件需求时，专注于最低限度的市场特性和最大的价值，我们正在有效地做同样的事情。
好吧，让我把这一点讲清楚。就像你不会建立一个开放的范围的房子一样，你的涉众也不想承诺一个开放的软件项目。我们必须预先做足够的工作来制定一个可信的计划，降低风险，并了解成本。我们必须评估工作，设定预算，并做出权衡，以确保产品按时并按预算完成。
能够告诉人们项目将花费多少以及何时完成是很重要的。同样重要的是，告诉人们他们的时间和金钱将得到什么。而且，重要的是他们知道风险并能缓冲一些意外事件。他们还需要知道什么是锁着的，什么是开着的，以及为了确保成功他们可能要做出的权衡。
为什么这是一个如此难解决的问题?
问题是，许多软件团队试图在不理想的条件下构建产品，他们不断地意识到他们没有预料到的问题和风险。他们同时在太多的项目上工作，并且有无法管理或控制的外部依赖关系。人们对团队没有奉献精神。结果是，人们得出的结论是，软件是无法估计的。
回到房子的类比，这就好像我们在岩石土壤上建造房子，不断地发现需要破碎和拖走的巨石。就好像我们的承包商说会出现却永远不会出现一样。这就好像我们不断地在一层房子和两层房子之间改变主意，或者在地基已经浇好之后决定要一个地下室。
总结一切
答案不能是举手投降，拒绝做出承诺。我们可能要花几千美元来确定这个构建是否可行。我们可能还得再花几千美元进行土壤测试，以确保这块土地能容纳我们的新家。你可以花钱来降低风险。有时你需要做一些工作来学习你不知道的东西。
对大多数组织来说，不估计、不计划、不承诺都不是答案。这不是一个任何人都能接受的起点。
你必须问问自己，怎样才能稳定交付过程。组建团结的团队是有帮助的，这是我之前关于结构的文章。有一个治理模型来控制工作流程也有帮助，这是我的下一个帖子。拥有一种降低风险的方法，投资于发现，建立基线指标，以及度量随着时间推移的改进的能力，这些都发挥了作用。更多的帖子即将发布!
#不估计是#不可能的
分开的想法
最后一点，基米和我并没有建造这栋房子。这个社区很漂亮。平面图和立面都很美。我们非常喜欢我们的建造者，并相信他能够在我们同意的时间和成本限制内交付我们梦想中的房子。问题是，在我们计划建造的那个县，房价很低，而估价是房屋建造成本的60%。
无论如何，我们都可以继续前进，但很快就会发现房子的价值低于我们支付的价格，而且在可预见的未来也没有迹象表明它会复苏。所以，当然，我们花了大量的时间和精力，甚至一些现金来发现我们不应该建造这座房子。如果我们使用主流的敏捷思维来建造房子，我们就会发现它并不值得我们付出的代价，但为时已晚。
我们花了几个星期的时间和几千美元，但避免了一个非常非常昂贵的错误。在我看来，这不是浪费，这是良好的风险管理。
看看之前的文章，舒级敏捷并不等同于照本宣科的Scrum．
评论(10)
卢卡斯
一个棘手的问题——这在企业软件和房屋建筑市场都是有效的:
谁来付钱给那些从事高水平项目的人?
更多:如果需要澄清的“请求”频繁出现，使团队很忙，但涉众不购买计划中的项目，该怎么办?
彼得Saddington (@agilescout)
不错的故事。
我喜欢它。
关于这个我也有个故事。不同之处在于，我们教我们的构建者和架构师在某些事情上更加敏捷....我们仍然在建造我们的家:)
格伦b Alleman
迈克,好讨论。在我们“设计、开发、部署”企业ERP和大型政府软件集约化系统的世界里，总有惊喜。它只是定义域的一部分。当然，许多人不恰当地使用的误区是，前期的大设计、承诺的预算和“遵循计划”的方法是我们工作的方式。这既不是事实，也不是概念上正确的。
真正发生的是一个发现和遏制的递增的、迭代的过程。这是系统工程过程的基础。v字形的方法。系统工程范例很少出现在基本的软件开发中，而且在企业IT中使用得也不够。它是通过合同流程下降而强制执行的。这种SE方法通过可交付成果的“日益成熟”的综合总体规划集成了项目中的所有跨学科角色http://goo.gl/QglVk是在一个序列中定义的，该序列为涉众提供了最佳价值，并允许在需要新功能时进行下游变更，同时保持到目前为止的交付价值。
但其中一个核心误区是围绕预算编制过程的。“全部预算”是作为项目架构评估的一部分进行估计的。这不是技术架构，而是程序架构。“我们将如何在预算、时间和交付所需的能力的基础上建造这个东西。”这类似于你家的程序化建筑。“在为你提供你想要的东西、遵守建筑规范、结构完整性的同时，如何应对不可预见的事件的情况下，房子是如何建造的?”
当我们在科罗拉多建房子的时候，我们在地块(倾斜的地下室)上发现了未曾预料到的花岗岩结构。爆破完成后，我们消耗了一些管理储备，并回到了计划。
在讨论#NE的过程中，我意识到开发者对世界的看法没有考虑到几个关键因素
预算和资金是以客户为中心的观点。这是他们的钱。在我们的房子例子中，是我们的钱，而不是建筑商。拥有一个部分建造的房屋或部分建造的ERP系统，或部分交付隐形战斗机的航空电子设备能力，都是不好的。哦，F-35的部分航空电子设备能力就是这样。老鼠。
-在任何领域都不可能预先知道所有的需求。因此，认为传统过程可以做到这一点的观点往好里说是错误的，往坏里说则是天真的。这是系统工程Vee和综合总体规划的目的。连续揭示满足客户所需能力的可能性。
-项目中的每个数字都是一个概率数字，由潜在的统计过程驱动。相应的行为。在#NE讨论中传达的错误信息的数量是惊人的。我不认为这是参与者的功劳。我责怪公立学校没有很好地教授概率和统计。坦白地说，我们的女儿是一名教师，并且同意。没有项目的概率模型，任何估计都不可能是正确的。这种缺乏理解导致管理不善。这并不局限于“呆伯特老板”，也适用于大型复杂问题。
关于糟糕的估计是如何被糟糕地使用的，已经写了很多。但建议我们不进行估计似乎是最好的。归根结底，这是所有商业活动的基础亚博vip9通道
为你的房子，为我的房子，为SAP安装，为联合攻击战斗机，为下一代GPS(我目前的工作是项目架构师)。价值只能通过知道成本来决定。只有这样，我们才能给这个值指定度量单位。
厨房改造的价值是以成本为依据的。在新厨房里，一个真正漂亮的6燃炉和双自洁烤箱是“非常珍贵的”。你可以花2万美元，也可以花6千美元。
可能(也可能不会)这些表明我们没有估计能从中学到一点看关键任务项目,比如建造你的房子或更新一个保险公司的网络,和生产一种新产品准备市场计划发射时间计划允许呆在业务成本的投资回报率(ROI)。亚博vip9通道但我感觉他们工作的环境不是这样的。
谢谢你的评论，格伦。我知道我说过很多次了，但是我想我更能理解新人们所处的情况，以及为什么敏捷社区的那部分人已经放弃了评估。我开发了一些语言……我在这里写的不多……来帮助人们了解他们在哪里，他们想要去哪里，以及如何到达那里。随着LeadingAgile作为一家公司的成长，我发现我们更多地是以管理咨询的方式行事，而不是以培训、指导或项目交付的方式。有太多的东西我们甚至不能与客户讨论关于交付、平衡能力与需求、价值流、指标或评估，直到一些潜在的组织功能被修复。几乎任何规模的每一项参与都以如何组织、如何治理和衡量什么的建议开始。一旦我们对产品交付机制达成一致，我们就可以开始实施一些关于评估和交付的规程。我们帮助那些无法估算的公司，以及那些认为他们的积压是不可估量的公司，在相对较短的时间内做得更好。评估并不困难，但是让一个组织围绕可以交付的内容设定理性的预期，通常几乎是不可能的。如果开发人员没有正确的评估输入，没有管理风险和不确定性的策略，没有能够处理现实的领导团队，他们就会放弃。 I think that is what we are seeing.
再次感谢你的评论。我很欣赏并尊重你的观点。
Henrik Ebbeskog
好的文章!
我想到的一件事是，建造软件和建造房子不是一回事。构建软件是更加不确定的，并且包含更多的“未知数”。因此，在估算成本/时间时，很难使用以前的“知识”。
同样的类比也可以是:“养一个孩子要花多少钱?”什么时候完成呢?”
这就是为什么我认为许多开发者觉得很难估算。
你对此有何评论?
詹姆斯·o . Coplien
许多敏捷规程都来自模式规程，并受到Christopher Alexander的启发。亚历山大在他的建筑设计中遵循的原则与敏捷建筑完全相同。有迭代:基本过程的循环。有增量交付:本地适应和零敲碎打的增长。有一种估计，他在他的著作中详细地讨论过。最重要的是，这里有那些住在房子里的人的参与:他把自己作为设计师大师的支柱放在一边，取而代之的是谦逊的建筑大师。
许多人用敏捷来攻击它。敏捷并不意味着抛弃架构:Scrum的发明者Jeff Sutherland说，他从来没有也永远不会在没有预先架构的情况下进行软件开发。许多人混淆了敏捷和方法论，从某种意义上说，这是公平的，但我不会为他们辩护，并建议批评者更关注他们的反馈，如果他们心里有一个特定的方法。
简而言之，这篇文章是一个有趣的故事，但它离题了，因此，不相关。任何事情都源于谎言。我们被这篇题为“你应该使用敏捷来构建你的下一个家吗?”，然后发现一些令人难以置信的陈述，比如:“不估计、不计划、不承诺不是大多数组织的答案。”这不是一个任何人都能接受的起点。”从修辞上讲，我们假设敏捷意味着没有评估、没有计划和没有承诺。在Scrum中，我们充满激情地进行评估。我们充满激情地计划，无论是在愿景层面还是在战术层面。团队在每一次Sprint中都致力于Sprint目标。我希望作者要么提出挑战，说Scrum不是敏捷的(这只会证明作者不理解敏捷)，要么他自己也不理解敏捷。
亚历山大非常成功，在世界各地建造了很多伟大的作品。他在这个过程中获得了许多奖项。我不知道Mike得到了多少，但我认为一个对敏捷及其前提都很了解的人一辈子也不可能做到。敏捷似乎也运行得很好。只是它和一些人认为的很不一样。令人遗憾的是，有人在发表这样的文章之前，不会花至少十分钟的时间做研究。我们从他的语气中知道这不是偶然的:哦，不，这篇专栏及其影响是经过精心策划的。当你权衡事实并再次阅读这篇文章时，想想这一点。
嘿,吉姆,
谢谢你的评论。我听过你和Jeff关于建筑的演讲，我知道你对此的观点。让我告诉你一些我为什么写作以及我为谁写作。我写这篇文章是为了探讨我在敏捷实现中经常看到的问题。我写这篇文章是为了探究我认为它的常见解释是错误的。我不是在攻击你的工作或杰夫的工作或其他人的工作。我才不会把一个稻草人弄死。我并不是在攻击Scrum的准则。我只是在和那些误解我的人说话。不幸的是，预想中的Scrum并不是实践中的Scrum。 It’s not the Scrum that is often taught in CSM classes. It’s not the Scrum that is often applied. It’s not the definition of Scrum that has made itself into common practice. That is what I am speaking against and trying to explain.
实践中的Scrum通常只需要很少的backlog，很少的架构，很少的预先计划，很少意识到如何权衡以优化确定结果发生的机会。不幸的是，您和Jeff所教授的Scrum正在使我的许多日常实践者变得不受欢迎。简而言之，我不是在给你和杰夫写信，也不是在寻求你们对我的解释的认可。我写信给那些误解Scrum和敏捷的人，他们可能会从他们在CSM课程中遇到的不同视角或不同的看待事物的方式中受益。我用的是一些简单的比喻，我认为这有助于人们理解。
如果你从根本上不同意我的观点，我也很乐意与你讨论或辩论……也就是说，你的回复似乎是对Scrum的攻击，而不是我观点的优点。考虑到我的目标受众，我应该增加或减少什么有什么想法吗?我知道你是怎么想的，我不认为我们真的有那么大的分歧。
大卫Asbury
这是一个奇怪的攻击性的评论，与什么是平衡和写得很好的文章。
接下来的评论很有意思，而且没有回复。
安德鲁·芮米
我曾多次担任大型政府网站的产品负责人，我热爱敏捷。我也是一名建筑设计师，我想用敏捷来帮助我的客户管理他们的扩展和雷诺。这是一篇很棒的文章。
我不喜欢建筑商的报价和最终价格在意外变化后的脱节!
你关于建造者估算和预算的观点很好。我认为一些敏捷规模原则可能是有用的;(小的、中号的等)。使用构建器进行这种评估可以帮助排除各种猜测和其他未知因素。如果他们不能给出一个合理的规模估计，那么这将表明需要进行更多的调查，需要将较大的模糊任务分解成小单元(就像软件团队评估软件sprint)。绝不要在冲刺阶段完成超大规模的任务——它们总是会偏离轨道!
马克
敏捷是为软件构建而创建的，因为看起来，所有容易定义的、毫无意外的、以及客户从一开始就正确的软件项目都已经结束了。
因此，敏捷是针对有不确定性的地方的，所以你可以每两周(大概)演示一次，然后每两周获得反馈并增加周期。你会厌恶房屋建设中的技术性债务。
当你建造一座房子,你开始与一个师(假设你有土地权利)谁知道当地法令,建筑规范,等等,你坐下来了解你想要什么:#床,#浴,平方英尺,和理想情况下你想要列出你设计偏好预先如果你喜欢现代的,当代的,维多利亚时代,工匠,等等。你知道厨房电器的时间越早，计划就会越早正确显示是否需要专门的插座。或者你想要多少个USB接口，在哪里。建筑师应该帮助你绘制一些图像，这样你就可以知道卧室在后面、前面等的优缺点，办公室的位置(如果想要一个)或者你是否需要一个食品储藏室，等等。
然后，构建过程不必是敏捷的，因为所有细节都是已知的。然而，你应该在每一个早上见面，然后每两周做一次房屋建造审查。这将有助于确定何时订购电器、地板、油漆等，以及何时可以接受检查和其他基于时间的事件。
再次强调，你的大部分工作是定义你对房子的愿景，并确保你对建筑师的作品感到满意。
顺便说一下，我用敏捷方法建造了我的房子，提前挑选好了所有的东西:地板、绝缘材料、墙壁开关/插座、电器、热水器、窗户和暖通空调。基本上没有给承包商留下任何订单或利润。