在过程中获取管理采购

Question

我为之工作的公司历史上很少有软件开发的过程。目前我们并没有真正遵循任何具体的方法。问题当然是，它使规划变得困难，成功地发布了一个不错的版本，甚至吸引了优秀的软件开发人员。

我想我可以说服他们去做一些Scrum过程。然而，关键在于获得管理层/所有者的购进。我认为，在任何一段时间内锁定特定特性的想法都会吓到他们。

有谁对我如何证明自己有什么建议吗？

到目前为止，我计划：

1. 介绍Scrum是如何工作的。我如何看待它与我们现有的人一起工作，以及它将如何使企业受益。
2. 要求对特定的人进行培训，这样我们就不会“随心所欲”了。
3. 设定一个实施日期，有一些计划和不确定的结果，我可能不得不捆绑开始一个新的过程。

Answer 1

如果您的项目类似于标准/典型的IT项目，那么您的项目很有可能已经失败，或者出错，或者成本过高，或者没有做客户(内部或外部)所需要的事情，或者开发时间过长。

如果您要倡导一个过程，就需要向您展示，您不会因为拥有结构而失去灵活性。

向决策者提出的要点：

• 拥有一个类似Scrum的过程将提高管理层掌握的信息数量，并使他们能够更快地做出决定。假设您有一个为期6个月的项目。那么，在没有进程的情况下，您如何知道在发布之前完成了多少工作？使用刻录图表，您可以以可见的方式跟踪所剩的时间。如果将其与定义为100个测试用例的TDD相结合，他们可以看到50%的测试用例都可以工作，但从烧毁率来看，只需要25%的时间(记住经理们喜欢简单，所以这不是项目的完美状态，，但是一个很容易理解的状态，比以前更好)。.e.g.因为这些项目具有更好的可见性，所以他们会感觉到更多的控制。
• 拥有过程可以让您提高质量，长期而言，这将减少bug，减少用于bug的时间，增加知识转移(如果您的明星开发人员受到总线的攻击，会发生什么情况)，所有这一切意味着公司将使开发人员专注于一个更好的产品，而不是持续修复bug。，例如，这样可以节省他们的钱，
• 将首先实现一小部分更改。这将是一个概念的证明，安全和容易退出，如果需要。例如，这表明您正在减轻感知到的风险，。你需要减轻人们感知到的风险，因为这正是他们所关注的。说，在你提出建议之前，你会想要收集一些数据。为什么？好问题:你需要一个基线，有两个原因：

1. You'll want to know how much the changes have helped.  So you can propose more changes.
2. You'll likely have a manager complain about a problem while the proof of concept is going on.  You'll want _evidence_ that shows that problems in a chaotic process free environment are the norm, and this is not a **worsening** of the state, and perhaps a slight improvement.  _You can bet on something going wrong in a process-free environment.  And you can bet that the proof of concept process changes will be blamed.  So be ready for it._

​

Answer 2

在我的经验中，在设计方法或实践中，在尝试一次之后，更容易推销管理。如果可能的话，我会选择一个小项目，通常是面向内部的，并要求“试点”你的新scrum流程。一般来说，要让人们购买一个试点产品要容易得多，因为他们只需要在有限的基础上做出承诺。

随着您的新的经过改进的试点项目的推进，一定要记录下scrum是如何使您的项目比以前的(缺乏)方法更成功的(post-its、记事本、Word文档等等)。在这里要残忍地诚实，只要有可能，就试着用真实的方式来量化。

在项目完成后，用已完成的项目作为证据，编写您的说明，并将您的发现提交给管理层。使用以下结果：

• 产品待办事项为用户提供了功能重置X上的真正进展感
• 猪/鸡会议方式通过控制会议，每周节省X人/小时
• sprints使开发人员能够更紧密地合作，从而减少了X%的错误代码

一般来说，如果你能把领导者带到一个他们可以得出结论的地方，他们就会寻求一种新的产品或方法。此外，这也是很重要的，如果你发现你的原始流程想法在试验过程中没有体现出来，那么就准备离开它们吧。

祝您好运，工作愉快！

Answer 3

你可以把Scrum卖给“不输”的主张。看看当您使用Scrum时会发生什么：

1. 所有的发展工作总是集中在最优先的任务上。
2. 进度100%开放，每日检查。
3. 用户/客户可以在每次迭代结束时检查进度。
4. 自动处理移动需求。

我对Scrum的唯一合理的反对意见是，不可能预测一个项目将花费多少钱，或者它将花费多长时间。这是因为Scrum承认，当项目开始时，每个人都会学习，需求也会改变。瀑布假装能做到这一点，但我们都知道它有多好。