首先平衡系统
让我们说你是一个建立企业级软件产品的公司，一般是漂亮的标准，但似乎似乎需要一定程度的定制...或者也许是一个新的特征（或两种）来缩短大笔的特征。您的产品比竞争更好，始终是极高的质量，销售飙升。
多年来，销售额继续增长，随着这些销售，产品的大小和复杂性以及它的增长也随之而来。随着时间的推移，您可以将新功能添加到产品中的速度已经下降，即使您的开发组织的大小翻了一番时，即使在同一段时间内翻倍。更糟糕的是，产品质量恶化，而且您正在靠近一些漫长的客户。
交付新特性的压力越来越大，而产品的质量和新版本发布的速度都在持续下降。我们很容易认为这是一个工程问题，但让我们更全面地看待这个系统，并探索从销售到支持的整个系统是如何促成这个问题的，以及我们是否要修复它，并促成解决方案。
销售对产品管理的影响
围绕销售的整个过程在很多方面给产品管理带来了压力。首先，产品经理被拉进销售过程，以帮助完成交易。随着时间的推移，它们对团队的可用性越来越小。其次，需要编写更多的新需求，并将其提供给开发组织，以保持所有这些新特性的运行。最终结果是，我们有了更多的需求，编写需求的时间更少了，与开发人员一起澄清需求的时间也更少了。
产品管理对发展的影响
我们现在拥有不像曾经的产品经理，并且他们生成的要求比以前更高的水平，并且更多的是它们比以往任何时候都更多的水平。因为要求没有充分分解，而不是充分理解，产品经理不可用。我们与一系列未知数留下了一系列未知，留给开发商在他们走出时锻炼。
此外，需求的数量远远超过了Sales所销售的时间范围。随着开发速度放缓，需要分析越来越多的需求，实际交付的功能就会越来越少，而且通常情况下，功能会不断被重新确定优先级，以适应愤怒的客户，并减轻拖延的日程安排，这将导致大量的浪费和重复工作。与此同时，销售继续增长，积压也继续增长。
发展对QA的影响
给定固定日期，资源有限，显然是不灵活的要求...开发人亚傅体育app员将尽可能展示尽可能多的进步，往往牺牲质量在积压中制作凹痕。谁需要测试代码无论如何，这就是我们拥有的QA，对吗？构建的软件的纯粹量创造了QA后面有一个不断增长的积压，并且QA永远不会赶上。
更糟糕的是，由于QA在代码中发现了大量的问题，低质量的软件不得不回到开发/QA周期。因为(正如我们所知)质量不仅仅与缺陷有关，它还与代码的可维护性有关……随着技术债务的增长，代码变得越来越难处理，越来越难测试。发现的缺陷是很难修复的，修复它们常常会导致在系统中引入更多的缺陷。
质量保证对支持和持续工程的影响
由于QA被要求快速测试软件，缺陷经常被忽略并被转移到生产中。这些问题导致了更多的问题单、需要支持的调用、需要记录、跟踪和管理的缺陷……在某些时候，所有的缺陷代码都必须被修复。由于问题的数量，以及代码中充满了技术债务的事实，持续工程很快就发挥了作用。
持续工程的溢出反馈给核心开发，或者随着问题的升级反馈给销售，最终反馈给产品管理，产品管理再反馈给开发，再反馈给QA，循环往复，无休无止。最终，整个组织创建新特性和交付可工作软件的能力都会停止。
你是做什么的?
好的......我认为很明显，我们永远不应该让自己进入这个混乱......但现在我们在这里，我们该怎么办？
- 我应该通过雇佣来解决这个问题吗?如果有，我应该雇佣哪些角色?
- 我应该用训练解决问题吗？如果是这样，我训练谁？
- 我应该使用更好的工程实践吗?如果有，是哪些?
- 我应该使用更多的自动化吗?如果是，我从哪里开始?
- 我应该用流程来解决问题吗?如果是，是什么过程?
- 我应该用压力来解决问题吗?对这个系统施加更大压力会有什么影响?
- 我应该用更好的管理来解决这个问题吗?效率的提高是否会让这个系统表现得更有预见性?
- 我应该停止销售新产品吗?我应该只卖现成的东西吗?
非琐碎问题
这显然属于非琐碎问题的范畴，而且像大多数非琐碎问题一样，它们没有简单的答案。然而，最重要的是要意识到，人们在回答这个问题的时候都有自己的职业生涯。承认你有麻烦是困难的，采取措施解决问题更困难……虽然目标很明确，但从A到B的道路将会很困难。
问题的核心是，对新软件的需求远远大于我们生产新软件的能力。即使我们的开发人员已经翻了一番,现在我们创建新功能的能力减少我们花的时间定义产品,我们花的时间致力于遗留缺陷,我们花费的时间和努力来管理软件,我们花时间测试软件,实际上,我们花的时间偿还技术债务。
变得真实
我们的工作是认清这一点……我们必须使我们的能力与组织的需求保持一致。有时这意味着我们必须减少需求，有时这意味着我们必须提高生产高质量工作、经过测试的软件的能力。将新人引入一个支离破碎的系统只会让这个系统变得更糟。我建议在系统稳定和平衡之前开始抑制需求。
这意味着我们可能需要停止我们所知道无法交付的承诺，这可能意味着产品经理应该与团队更密切地工作，或者可能意味着我们需要聘请一些商业分析师。亚博vip9通道这可能意味着我们需要通过生产更少的糟糕软件并使开发人员专注于更好的单位和集成测试来帮助QA。在许多情况下，开发人员甚至可以帮助手动测试。我们可以通过首先提供更好的软件来减少支持的负载，并在建立更多的内容之前修复我们在生产中的产品。
也许
也许我们公司的人需要搬家。也许有些人需要找一个不同的地方工作。也许我们需要一个更有纪律的过程，或者更有效地执行我们已经到位的过程。我们可能需要所有这些东西的一点点……关键是要意识到，我们没有一个点问题需要一个点解决方案，我们有一个系统问题，我们需要一个系统解决方案。修复系统的一部分通常不会让事情变得更好，有时反而会让事情变得更糟。
一旦我们平衡系统，现在我们就可以开始思考雇用或如何花钱......以改善整个系统的方式。将系统纳入平衡必须是我们开始的地方，如果我们想要一个实际解决问题的长期解决方案是一种可持续的方式。
评论（11）
Sachin Kundu.
啊，纪念限制理论的经典案例。当你把它放下“令我们稳定和平衡”
如果销售的数据超过了处理能力，就会产生在制品和随之而来的浪费。第一个解决方案是减少销售(听起来有点不太直观)，然后看看瓶颈在哪里。
敏捷侦察员
不能说它更好。凭借大型企业，这正是这种情况。你会说什么是开始平衡方程式的第一种方法？
迈克J. Berry.
随着应用程序逐渐成熟，这些类型的动态开始接管一个可管理的环境，组织开始感受到市场需求的压力。我喜欢关于必须在早期偿还因不负责任的开发而积累的技术债务的评论。由经验丰富的架构师进行架构审查可以消除许多技术债务。良好的OOP实践，如S.O.L.I.D等，也可以为有效扩展提供一个安全的平台，同时最大限度地减少技术债务。您应该在您的环境中坚持这一点。即使是最小的项目。
未提及的一个角度是需要一个组织能够适当地优先考虑所需的功能。我们在敏捷中谈论“释放客户价值”才能越早，我与我工作的大量程序员无法真正告诉你客户价值是什么。为了好玩，请在你的工作场所询问，看看你得到了什么答案。有些人认为这是更快的表现。有人认为这是更新的技术。客户价值是客户愿意支付下一美元的费用。
有这样的授权,很多即将到来的“功能”每个人都试图快速添加到系统可以轻松地优先,在许多情况下,一个组织会发现大部分的列表是来自哪里,根本没有一个客户在一个开放的支票簿。这是一个简单的经验法则，它将有助于消除许多似乎被添加到开发backlog中的模糊的“需求”。在这些类型的情况下，消除非客户价值项是一个巨大的好处，因为它允许程序员关注那些真正重要的项，并更快地交付真正的业务价值。亚博vip9通道
萨钦，我想你很难说服董事会或股东减少销售。那会让你被解雇的。还有其他建议吗?
；-)
彼得......我认为第一步将高度依赖于您的环境。目前，我可能会在我正在考虑的客户上开始与客户的东西。下一步可能是短期QA帮助，而我们专注于减少开发人员的技术债务和自动化。您可能会接近销售并要求他们退回到新功能，直到系统稳定。
Mike ......原则上同意您的同意，但这些销售额往往具有合同承诺。我认为解决方案必须超越简单的优先级。我使用故事映射和MMF的想法。我们必须积极分解工作，以便我们解决开发可以构建的最小功能集，以实现业务价值。亚博vip9通道然后以优先顺序提供交付。到目前为止，我不希望DEV组织驱动该决策（在大多数情况下至少）。
苏德师
如何在董事会中应用WIP限制（销售，产品。MGMT，Dev和QA）如果您很难招聘或培训开始
然后将力量转移到每个区域，如果有什么东西在WIP限制之外被阻塞，平行解决问题
试图思考精益:)
哑光块
好的文章迈克!这描述了我几乎完全面对的情况，你说这是一个“不平凡”的问题，这绝对是正确的。有很多方法可以解决这个问题，它们都有各自的优缺点。我认为最重要的是，你只需要认识到它，并开始解决这个问题。我写了一篇关于敏捷采用过程的论文，虽然没有直接提到这个问题，但确实向读者介绍了我们解决这些问题的步骤。虽然我不认为我们已经完全脱离险境，但我们的处境肯定比以前好得多。文章(向敏捷发展)可以从我的网站的参考资料部分下载(亚傅体育apphttp://www.developmentblock.com/亚傅体育appresources/)或者任何参加Agile2011的人都可以参加我将要展示它的会议!