想象一下，您在涉及多个系统的大型项目中担任承包商，并且您正在创建其中一个系统。整个项目使用传统的流程，但有些气味告诉你敏捷流程会好得多。
现在的问题。仅在您自己的组中引入敏捷软件开发过程是否有意义？没有机会改变整个项目，但您可能会改变自己组中的过程。
这种本地流程变更的主要好处和缺陷是什么？在这种情况下是否有特定的敏捷过程可以正常工作？
答案 0 :(得分：5)
这是一个很棒的日记，讲述一个人如何在几年内将整个公司改为敏捷 - 是的，从他自己的子项目开始，即“自下而上”。但他确实考虑了“自上而下”改变的利弊。
http://jamesshore.com/Change-Diary/
非常有趣和无聊的东西。
答案 1 :(得分：2)
阅读Effective Ways to Introduce Agile into the Workplace和Joel的seminal Getting Things Done When You're Only a Grunt。
除此之外，它可能主要是与您的上级和客户进行营销/期望管理。两者都可能不喜欢投资于各种敏捷的客户包容“游戏”。这两者也可能反感“新奇”的做事方式。
答案 2 :(得分：2)
我认为答案取决于你与其他人的过程有多孤立。如果他们只是告诉你去完成你的部分并返回一个完整的小部件，那么在本地实现敏捷应该相对容易。另一方面，如果您需要遵循大量随机日期和程序，那将会更加困难。
你必须要灵活，并确保你所拥有的任何冲刺节奏与系统的其他部分相似。你必须提前计划你的冲刺，因为中央计划人员可能会提前想要一个全能功能列表，而不会代表更为悠闲的敏捷方法。只要保守你会提供什么，你应该没事。
优势应该与敏捷在其他地方的优势相同。
答案 3 :(得分：1)
这是一个有趣的场景。几年前我也有过类似的情况，我认为这样做基本上会使项目经理（你的？）工作量翻倍。您将需要扮演双面角色，一组牌面向客户，另一套面向开发者。
如果您的开发人员很好，我会选择它。如果他们不是，并且需要踢和手持，请小心。如果它们很好但可能会被带到他们自己的议程中，那就要坚定地负责。
有时候，传统项目模型的组织强调与开发人员的思想无关的次要功能，并完全忽略真正的热点，这有时会很有趣。我仍然没有得到它 - 也许这是简单的愚蠢和非专业。期待。
并且记住基于测试的方法是敏捷开发的核心。先做测试。这对于客户来说是特殊的，但是他们将会看到子项目的实际进展情况。你可能会在早期获得更少的“进步”，但在最后一码时更多。
答案 4 :(得分：0)
取决于您的动机，以及您的目标。
陷阱：主要的一点是敏捷开发通过提高可见性来发挥作用。因此，在一个子项目中采用敏捷实践，如果努力取得成功，可能会导致暴露影响整个项目的问题，从而导致出现反弹的风险。请记住two envelopes的比喻。
您首先采取的做法取决于您希望如何处理此风险。如果您从采用与规划相关的实践（任务板，发布计划，用户故事，速度）开始，事情可能会相对较快地发生。
同样，或多或少，如果你从需求领域的实践开始（用户故事，自动验收测试）。
如果从内部质量（测试驱动开发，重构，持续集成）开始，您可以提高开发人员对项目的积极性，冒着在更大的方案中不一定重要的事情。< / p>