多学科环境中的敏捷
我在一家工程咨询公司工作，他从事工业设计、机械、电子和软件的综合工作。从本质上看-或者仅仅是历史-整体发展理念一直是瀑布。但是当我加入的时候，我感到惊讶的是敏捷，我现在要说它是一个行业标准，几乎没有人听说过敏捷。对我来说，虽然我仍然对敏捷持怀疑态度，但我认识到它对开发人员和客户都有好处，并且一直热衷于推广它的使用。
在我看来，很明显，您不能以敏捷的方式构建硬件。这是太费时和昂贵的“重构”一个物理的东西。这意味着我们正在走向软件-敏捷和硬件-瀑布，而项目经理正在努力使两者一起工作。更糟糕的是，当我们面临向客户提供项目的最终成本时，就变得困难了。敏捷不执行uber计划，速度预测要求项目启动、运行，并通过几个sprint才能有意义。这意味着我们倾向于过度估计突发事件，推高价格，降低竞争力。
在我看来
我们将敏捷明确地卖给客户端，并让他们接受每个sprint的新软件迭代，从而能够增加待办事项并确定下一批工作的优先次序。我们说服他们，这是一种非胡说八道的工作方式，瀑布是不现实的，导致超支。产品负责人来自此模型中的客户端。那么，我们如何处理合同，说我们对软件的收费是多少？我们如何避免这样一种印象，即这是一种开放的收入流，只要我们愿意，就用多久都符合我们的利益。
我们只在内部采用敏捷。产品负责人是我们的一个男/女。客户端只得到一个alpha/beta/发布版本的软件，就像瀑布一样。如果我们已经过了一段时间，那么我们是否会在最后的阶段伪造这个滑动呢？这是敏捷吗？
简而言之，在我们和客户之间签一个合同似乎是一种非常不敏捷的做事方式。然而，瀑布注定要失败，在这样一个环境中，我们每天都会看到，我们不仅在项目的第一天就不了解问题域，客户也是如此。我们如何实现软件的敏捷和硬件的瀑布--是否有软件可以在一个伞下处理这两个问题？我们如何与这些世界结婚？
回答 4
Software Engineering用户
发布于 2013-08-05 13:57:23
“如果你只有一把锤子，那么每个问题都像钉子一样”.
敏捷是一种非常好的方法，在开发人员社区中得到了广泛的接受(这是有充分理由的)。
然而，这并不是城里唯一的游戏，也不总是正确的答案。(深空探测器和航空电子设备的代码出现在脑海中)。
敏捷是您所在行业的行业标准吗？(一般情况下不是发展，而是你所从事的具体业务)。听起来可能不是这样。你的客户没有要求它，硬件的人也不想要或者不需要它。(敏捷需要来自客户端的额外努力，这可能是可用的，也可能不是可用的)。
如果你要采用它，确保你这样做是出于正确的理由&而不仅仅是因为所有的孩子在这样做或P.SE。
如果您决定继续前进，慢慢来，只在内部使用它，并建立一个跟踪记录。采用一种方法是一种企业文化的改变，而这种改变永远不会很快发生。
耐心点。
Software Engineering用户
发布于 2013-08-05 13:45:06
您使用的敏捷模型应该始终根据环境量身定做，这样流程才能为客户提供有形的价值。敏捷的一个关键好处是，价值是提前交付的，客户也喜欢这样。在看到它的行动后，他们开始接受这种方法。
在您的例子中，硬件人员只会在第十天交付工作工具包。在第X天之前会发生什么？如果您正在研究瀑布方法，您什么时候开始代码设计和构建？在构建h/w之前，如何测试代码？你用仿真器吗？
慢慢地，在内部使用敏捷。并不是每个客户都希望成为敏捷“实验”的一部分(正如他们所看到的)。建立一个短跑和速度的记录。通过已知的速度，可以比以前更准确地估计新项目。然后，公司可以向感兴趣的客户出售敏捷方法。敏捷需要来自客户的额外承诺，而不是所有的客户都希望参与其中，直到他们看到了成本的差别。
Software Engineering用户
发布于 2013-08-05 15:25:56
我认为您需要研究您需要采用的敏捷的“类型”。Scrum是敏捷的一种形式，当有新的特性需要开发时，它很好地适应软件开发。看板是敏捷的另一种形式，它有时会更好地应用于那些不能用固定的间隔来解决问题的组，比如用大部分错误来维护已经开发的代码。这只是两种类型的“敏捷”，还有更多可以研究的地方。从其他人之前的回答来看，敏捷的设计是为了帮助您使一个灵活的过程适应您的公司需求。
我们公司已经把软件和硬件团队放在scrum上。我不能对硬件团队的情况发表评论，但它可以帮助scrum上的软件人员安排他们的日程。
https://softwareengineering.stackexchange.com/questions/207234
复制相似问题
腾讯云开发者
