仅在子项目中引入敏捷实践？

Question

想象一下，您在涉及多个系统的大型项目中担任承包商，并且您正在创建其中的一个。整个项目使用传统流程，但有些气味告诉你敏捷流程会更好。

现在的问题。仅在您的团队中引入敏捷软件开发流程是否有意义？没有机会改变整个项目，但是你也许可以改变你自己小组的过程。

这样一个本地过程变化的主要好处和缺陷是什么？在这种情况下是否有特定的敏捷流程可以发挥作用？

Answer 1

阅读Effective Ways to Introduce Agile into the Workplace和乔尔的seminalGetting Things Done When You're Only a Grunt。

除此之外，它可能主要是与上级和客户进行营销/期望管理。这两者都可能会怨恨投资各种敏捷的客户包容性“游戏”。这两种情况也可能会让人感到厌恶“新式”的做事方式。

Answer 2

我认为答案取决于你是如何与其他人分离的过程。如果他们只是告诉你完成你的部分，并回来一个完整的部件，在本地实施敏捷应该是相对容易的。另一方面，如果你期望遵循大量的随机日期和程序，那将更加困难。

您必须保持灵活性，并确保您在与系统其他部分的日期类似的日期上拥有的冲刺节奏。您必须提前规划您的冲刺，因为中央计划人员可能很快就会想要一个全面的功能列表，并且不会支持更加悠闲的敏捷方法。只要保守一些你会提供什么，你应该没问题。

优点应该与敏捷在其他地方的优势相同。

Answer 3

这是一个有趣的场景。几年前我有过类似的情况，而且我认为这样做基本上使项目经理（您的？）的工作量翻倍。您需要双重面对面，一套卡面向客户，一套面向开发者。

如果你的开发人员很好，我会为它付出。如果他们不是，并且需要踢腿和手持，请小心。如果他们很好，但可能会被带到自己的议程，坚决负责。

有时候，传统项目模式的组织强调次要特征，与开发人员的想法无关，并且完全忽略真正的热点，这有时很有趣。我仍然没有得到它 - 也许这是愚蠢的愚蠢和非专业主义。期待这一点。

还记得基于测试的方法是敏捷开发的核心。先做测试。这对于客户来说是特有的，但是他们会从中看到子项目实际进行的效果。你可能会在开始的时候获得更少的“进步”，但在最后的场地可能更多。

Answer 4

这里有一个很好的日记，记录了一个人在几年内如何将他的整个公司改变为敏捷 - 是的，从他自己的子项目开始，即“自下而上”。但他确实试图尝试“自上而下”的改变。

http://jamesshore.com/Change-Diary/

非常有趣和intruiging东西。

Answer 5

取决于你的动机，你的目标是实现。

陷阱：最主要的是敏捷开发通过提高知名度而发挥作用。因此，在一个子项目中采用敏捷实践，如果努力取得成功，可能会导致影响整个项目的问题暴露出来，从而导致反弹的风险。请记住two envelopes的寓言。

你首先采取的做法取决于你想如何处理这种风险。如果从采用计划相关实践（任务板，发布计划，用户故事，速度）开始，事情可能会相对较快。

如果您从需求（用户故事，自动验收测试）领域的实践入手，或多或少也是如此。

如果您从内部质量开始（测试驱动的开发，重构，持续集成），您可能会提高开发人员对项目的动力，但并不一定涉及大型项目。