在传统项目开始后介绍敏捷开发
大约一年半以前，我进入一个声称从事敏捷开发的工作场所。我了解到，这个地方采用了几种敏捷实践（例如日常站立，冲刺计划和冲刺审查），但没有一个原则（及时/足够的心态，尽早暴露失败，丰富的沟通）。 现在，我承担了使团队更加敏捷的任务，并向我保证，开发人员和业务团队已完全同意我的要求。作为一个试点计划，他们给了我一个项目，该项目刚刚完成了15个月的需求收集，有110页的“分析与设计”文档（被认为是“一成不变的”），而且我无法找到最终结果。用户（仅限于实际上不会使用该产品的用户经理组成的委员会）。 我从小处着手，为他们提供了前5个冲刺的预期可交付成果的列表（未定义未来的冲刺），第一个冲刺的目标列表，并且剖析了A＆D文档以获取足够的用户案例来满足第一个冲刺的目标。 从那时起，他们就问为什么我们对所有sprint都没有所有要求，为什么我没有开始为第三个sprint（他们认为更重要，但基于第一个sprint的成果） 2个sprint），并要求获得整个IT团队认为繁忙的工作或与我们无关的更多文档（例如，预先编写用户手册，预先记录所有sprint中的所有数据字段等） “前期”工作）。 作为一个新的项目经理，这对我来说是很艰难的，但是我已经有效地实现了一些改进，例如故事管理的scrumban，结对编程，以及让业务预先为我们提供了客户验收测试（作为需求文档的一部分） 。 所以我的问题是： 我该怎么做才能更有效地将变革引入抵制企业？ 我可以在IT方面引入其他实践来帮助向企业展示敏捷的好处吗？ 文档的负担使我们感到窒息-企业仍然将其视为风险管理策略，而不是风险。我们可以采取什么措施来减轻他们对文档的关注和要求（特别是文档的数量及其对所有这些文档的需求）？ 我们与公司位于不同的建筑物中，位于大约3个街区之外，他们拒绝让该项目的人员同居b / c，因为该人员“在他们在我们公司时将无法从事其他项目建造。” 他们希望我们总是走到那里，把我们的问题捆绑在一起，这样我们就可以立即问他们，而不会因为“不断的打扰”而浪费那个人的时间。我们如何做才能与他们进行更丰富的沟通？ 任何其他建议也将不胜感激。 谢谢！