在传统项目开始后介绍敏捷开发

大约一年半以前，我进入一个声称从事敏捷开发的工作场所。我了解到，这个地方采用了几种敏捷实践（例如日常站立，冲刺计划和冲刺审查），但没有一个原则（及时/足够的心态，尽早暴露失败，丰富的沟通）。

现在，我承担了使团队更加敏捷的任务，并向我保证，开发人员和业务团队已完全同意我的要求。作为一个试点计划，他们给了我一个项目，该项目刚刚完成了15个月的需求收集，有110页的“分析与设计”文档（被认为是“一成不变的”），而且我无法找到最终结果。用户（仅限于实际上不会使用该产品的用户经理组成的委员会）。

我从小处着手，为他们提供了前5个冲刺的预期可交付成果的列表（未定义未来的冲刺），第一个冲刺的目标列表，并且剖析了A＆D文档以获取足够的用户案例来满足第一个冲刺的目标。

从那时起，他们就问为什么我们对所有sprint都没有所有要求，为什么我没有开始为第三个sprint（他们认为更重要，但基于第一个sprint的成果） 2个sprint），并要求获得整个IT团队认为繁忙的工作或与我们无关的更多文档（例如，预先编写用户手册，预先记录所有sprint中的所有数据字段等） “前期”工作）。

作为一个新的项目经理，这对我来说是很艰难的，但是我已经有效地实现了一些改进，例如故事管理的scrumban，结对编程，以及让业务预先为我们提供了客户验收测试（作为需求文档的一部分） 。

所以我的问题是：

1. 我该怎么做才能更有效地将变革引入抵制企业？
2. 我可以在IT方面引入其他实践来帮助向企业展示敏捷的好处吗？
3. 文档的负担使我们感到窒息-企业仍然将其视为风险管理策略，而不是风险。我们可以采取什么措施来减轻他们对文档的关注和要求（特别是文档的数量及其对所有这些文档的需求）？
4. 我们与公司位于不同的建筑物中，位于大约3个街区之外，他们拒绝让该项目的人员同居b / c，因为该人员“在他们在我们公司时将无法从事其他项目建造。” 他们希望我们总是走到那里，把我们的问题捆绑在一起，这样我们就可以立即问他们，而不会因为“不断的打扰”而浪费那个人的时间。我们如何做才能与他们进行更丰富的沟通？

任何其他建议也将不胜感激。

谢谢！

我确信我已经获得开发人员和业务团队的完全支持，但我无法与最终用户联系。

要清楚地说明的一件事是，一方面是口头上确保您“接受”，另一方面，是赞助您的作品的人的实际承诺之间的区别。

对您最好的建议是完全取消标签“ Agile”。尽可能禁止在谈话中使用该词。相反，请注意以下几点：

• 要求您提供什么结果（具体来说，不是您的团队）
• 您的任务的成功标准是什么（还是您而不是团队的标准）
• 什么意味着您可以支配（包括人员，人员，时间，信息，培训预算等）

“使团队更加敏捷”不是一个可行的目标。它不够具体，无法测量，没有结束条件。您需要的是特定的东西：用Z表示的目标，表示的缺陷减少X％或实际兑现的要素交付日期的Y％。

为了实现这些目标，您可能需要进行一些更改。现在适用一些经验法则。每一个改进都是改变，但并非每一个改变都是改进。人们常说人们抵制变革，但实际上人们抵制变革，却不知道变革是否会有所改善。

专注于您认为容易获胜，难以实现的实践。关注于建立框架的实践，这些框架不仅用于实施变更，而且还用于评估变更的效果，并向人们保证，它们是在改善而不是退化。“信息辐射器”以及回顾展都是不错的选择。

这些更改中的某些更改既可能是必需的，也可能被视为威胁，例如，更多地访问拥有关键信息的人员。不要在这些问题上妥协：“购买”是一个谈判过程，您实际上有机会交付自己所要的东西，而不会被羔羊当作政治屠杀。

尝试进行设置，以便如果事情不对劲（很多事情可能会出错），很难将责任转移给您。请注意，这可能会发生，并做好准备：知道您的退出策略。

为了顺利地引入新事物，您需要确保人们不会将其视为威胁和永久的。

我们许多人自然而然地避免了任何新事物。这是生物的。通常寻求新颖性的人永远不会给您带来任何问题。您需要确保更多焦虑的人不会将您的建议视为对其当前舒适度的威胁。

团队采用某种实践或想法的理想方法是确保该想法来自他们，而不是来自外部的任何人，例如管理层，或更糟糕的是，有一些随机顾问。为此，请与整个团队就一个主题进行集思广益会议。主题应该是问题。在会议中，您将必须仔细提出想法，并提出论据和事实。

我们不喜欢对永久性物品做出决定。我们已经对潜在变化的影响感到焦虑。宠物店已经知道这种行为。买狗是一个很大的决定，可能会从根本上改变您的生活。当您在商店中时，推销员通常会建议您将其带回家，如果您改变主意，则将其退还。如您所料，回报很少。该提案只有一个目标：减少使人们无法做出决定的焦虑。建议您的团队实践在评估效果后尝试固定的时间。

关于第二个问题，我强烈建议您一次带一件东西。

您的文档问题应该放在P.SE上，如果您俩都愿意定期开会，那么您在两座不同的大楼中就不会有任何问题。在某些情况下，一方根本不想见；）

敏捷并非适合所有人，听起来您的企业就像在说敏捷一样，因为它是最热门的流行语。首先，推动一个全新的项目或规模较小的维护项目开始使其过程更像真正的敏捷方法论，可能是一个好主意。尝试使用已经在进行中的项目来重新设计方法，就像在8车道高速公路的中间更换轮胎一样。您需要一种方法来表明您的业务敏捷性可以工作，但是您需要一个可以使其运作的环境，但是根据您所说的，敏捷不太可能与他们已建立的文化相适应。

根据他们想要的文档，您可能可以向他们表明，这是由您正在使用的工具自动生成的，或者是多余的，并且文档B要求提供信息A。您还需要调整文档计划，让他们知道为什么您的估计会发生变化，并要求他们减少请求的文档数量或像业务分析师那样专用于创建文档的资源。

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

那是你的问题。他们不明白。有人不能要求您变得更敏捷，也不愿意继续兜风。他们有错误的期望。在您甚至开始之前，事情就已经坏了。纠正期望，否则您将失败。就像我要您以每小时150英里的速度行驶，然后我给您一辆雪佛兰来做。

建立他们想要的文档的时间/资源/成本，并让他们查看将进度表推迟多长时间。

这可能有助于向他们显示正在推动项目团队进行多少工作，以及如果他们不这样做会如何减少工作。