软件Scrum或精益与工业工程概念(如约束理论)有什么关系？

Question

在Scrum中，工作通过一系列sprint交付给客户，其中项目工作的时间被限制在固定的天数或星期，通常是30天。在精益软件开发中，目标是尽快交付，允许为下一次迭代提供早期反馈。

这两种技术都强调了工作流的重要性，在工作流中，软件工作产品不会在开发中积累，等待在未来某个日期发布。两者都允许新的或完善的需求和来自QA和客户的反馈被采取行动，尽可能少的延迟，基于优先级。

几年前，我听了一次演讲，演讲者简短地谈到了工业工程中一个叫做约束理论的概念家族。在工厂中，他们使用基于三个组件的操作模型:鼓、缓冲器和绳子。滚筒在通过系统时同步工作产品。缓冲区，通过在等待下一阶段消耗时保持来自一个阶段的输出来保护系统。绳子把产品从一个工作站拉到另一个工作站。

从历史上看，这些想法是Scrum和精益传统的一部分，还是在一个单独的轨道上？

我们想从滚筒缓冲绳的角度来考虑Scrum和精益，它的部件是什么？

• 每天的scrum会议，每月发布)？
• 缓冲区={刻录列表，源代码控制系统)？
• Rope ={每日会议，持续集成服务器，每月发布}？

工业工程师根据不同类型的工厂来定义工作流程。

• 工厂:直管。一个输入，一个输出。
• A-工厂:许多投入和一个产出。
• 工厂:一个投入，多个输出产品.
• 工厂:多投入，多输出.

如果它适用，什么样的工厂最像Scrum或精益，为什么？

Answer 1

敏捷实际上只是一组原则(参见这里)。Scrum只是一个尝试遵循这些原则的工具。

另一个敏捷/精益工具，它在看板中非常依赖约束理论。其中一个关键点是限制正在进行的工作(WIP)，以提高输出(参见这里)。

但是值得注意的是，看板只有在您选择以这种方式使用它时才是敏捷的，因为它对过程的指令性比scrum少得多，理论上可以在瀑布SDLC中实现。

Answer 2

精益、看板和约束理论起源于工业工程领域，但已经适应了软件工程。例如，看板的起源可以直接追溯到丰田。所以我简单地把这段关系叫做“先驱者”

软件中的大多数敏捷方法都植根于精益，但也有一些基于TOC和看板的方法。

我们中的一些软件工程师早在90年代就读到了“目标”，那时敏捷还没成熟，他们就开始寻找应用这些原则的方法。就我个人而言，我很难“看到”它，并将我的开发过程改进为相当敏捷(在结果方面，甚至在2001年编写敏捷宣言之前)；但是我很难描述我的瓶颈是什么。后来我读了“关键链”，但仍然坚持把TOC翻译成软件。

几年后，我读到了“敏捷管理”(Agile)，它在解释Scrum、XP和FDD方面做得很好(后者是将TOC清晰地翻译成软件)。从那时起，我可以看到一个连接，一旦您有了一个明确的交付度量，并可以将TOC原则应用于Scrum实践。

但是目前的TOC软件专家是Clarke，检查他的书“滚石下坡”和“瓶颈规则”。