Scrum的可行性及其对哲学的某些修改

Question

我更希望那些回答这个问题的人能说明他们是否有在敏捷环境中开发的经验，或者他们是否从理论的角度出发。

背景：

假设有一家机会主义公司开发技术创新产品(多触控接口、语音识别设备等)，所有这些都是根本不相关的。然而，正如人们可能看到的那样，开发类似产品的关键优势在于，可以从产品中创建/提取库，并将其出售给其他公司、开发人员等。因此，增量式工作是有利的，因为它允许将里程碑与最终产品分离开来。

Question1 :从业务的角度来看，这是否有利？你们中有谁曾在公司内遇到过将库分离成单个产品的情况吗？

Question2 :如果产品确实是以这样一种增量的方式创建的，那么Scrum是否看起来是一种适用的有效方法？

让我们假设，创建组件的增量过程已经就位，以便将组件组装成最终的应用程序。开发团队最初规模很小，有6到7人。为了好玩，让我们称这支队伍为行会。公司刚刚起步，他们需要赚钱。为了论证起见，让我们假设公会开发了FaceAPI库。所有这些都是在Scrum方法中完成的，比方说在一个sprint中。现在，该公司有足够的资金雇用更多的7人。这些新的7人被放入他们自己的行会，他们的技能反映了原来行会的技能。

所以现在，这家公司有两个工会，和一个图书馆，以发展。假设一个工会负责使用原始库创建Product1，而另一个工会负责扩展具有更多功能的库。这两个“sprint”将同时执行，最后更新的库将合并到应用程序中。如您所见，处理Product1的团队可能需要对库进行一些修改，在这种情况下，合并将是非常重要的。

在任何情况下，这都是一般的想法。公司将有个人行会或人员团队(问题3:您认为这个想法如何？由于团队规模较小，他们希望雇用具有良好协同作用的成员。这有可能提高整体士气和生产力吗？)，它将同时执行sprint。由于公司提供的服务的性质，团队将或多或少地使用相同的组件和应用程序的部分，但是可以创建它们的sprint，这样团队就可以不受阻碍地执行工作。每个行会都是一个自封的单元，有测试人员、设计师和QA。

最后问题：

• 作为开发人员或测试人员，您对以这种方式运作的公司有什么看法？它能培养开发人员的领导能力吗？听起来有吸引力吗？听起来注定要失败吗？
• 任何有Scrum知识或经验的人，它似乎在这种环境中自然适用吗？
• 是否有人为类似于上述描述的公司工作过？如果你不介意回答的话，它叫什么？成功了吗？

Answer 1

首先，到目前为止，我已经完成了3个或多或少的Scrum项目。

你的故事里有一些不清楚的东西。公司的目标是开发图书馆或最终产品？对我来说，这两者似乎很矛盾，尤其是对于一家小公司来说。

另一件事是，在没有任何真正用户的情况下，从库本身开始开发对我来说不太灵活。一个敏捷的设置将以相反的方式开始:首先开发一个具体的产品，根据具体情况重构设计，可能到达某种层次的体系结构，其中较低层可以提取到一个可重用的库中。然后开始开发更多的具体产品，寻找在项目之间重用代码的可能性，并按照客户(产品开发团队)的具体使用和需求的要求，改进公共库的设计。

在某种程度上，库开发可能需要自己的团队--在一开始，在不同的团队之间协调它的设计和积压可能就足够了。

Answer 2

关于团队相互执行代码的问题--这就是源代码管理的目的。分叉的新东西，然后在下一个冲刺重新整合和稳定。

关于q2，scrum是一种增量式的方法，所以如果设计适合于增量式的工作段，那么这当然是合适的。

关于q3，雇用“能在他们内部工作并愿意与之共事的人”怎么会是一件坏事呢？

Answer 3

团队组织和系统结构高度依赖。见康威定律

这意味着，要让两个单独的团队在两个单独的代码模块(库团队和产品团队)上工作，您需要在团队之间有一个明确定义的通信通道，因此，开发的代码将在设计中反映这些通道。传统上，这意味着您最终为库定义了一个API或接口，它的作用就像每个团队都可以开发的契约。敏捷实践通常采用一种更紧急的设计理念，因此很难创建一个有意义的API。

大多数敏捷团队解决这一问题的方法是通过时间限制开发到可管理的增量。因此，虽然设计整个API可能是不现实的，但产品团队和库团队可能会就API的设计达成一致，这足以满足两周的工作需要。为下一次迭代编写代码、部署、设计和重复。这样，团队和代码模块之间的通信路径就可以建立起来，这样两个团队就可以独立工作，而无需踩到彼此的脚尖。

我最近使用过的另一个选项是使用看板/有限WIP流程管理更大的团队。由看板管理的同一个团队中的每个人都可以进行更有机和灵活的自组织，这意味着您的系统将能够更容易地进化。通过保持工作进度的高度可见性，它增加了交流，并且通过限制正在进行的工作，通过阻止系统朝着任何一个方向发展得太远，限制了开发人员之间的相互攻击。与一个坚实的VCS相结合，你应该做得很好。

最后，另一种选择是，在深入开发之前，您需要花一些时间来真正考虑您的体系结构。在有限的“尖峰0”角色中使用软件架构设计流程(如建筑中心设计方法论 )可以帮助您解决在允许紧急设计时通常遇到的许多问题。在设计结束时，您将能够为您需要做的事情制定一个更有意义的计划。请记住，仅仅因为这是一个设计阶段，并不意味着您不编写代码--恰恰相反。ACDM强烈主张进行实验。