仅在子项目中引入敏捷实践?[闭门]

这是一本关于一个人如何在几年内将整个公司转变为敏捷的伟大日记——是的,从他自己的子项目开始,即“自下而上”。但他确实探讨了尝试“自上而下”变革的利弊。

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

非常有趣和有趣的东西。

阅读 Effective Ways to Introduce Agile into the Workplace 乔尔的呢 seminal Getting Things Done When You're Only a Grunt .

我认为答案取决于你与其他人的过程的隔离程度。如果他们只是告诉你去完成你的部分,然后带着一个完整的小部件回来,那么在本地实现敏捷应该相对容易。另一方面,如果你被要求遵循很多随机的日期和程序,那就更难了。

你必须灵活,确保你的冲刺节奏与系统的其他部分在相似的日期。您必须提前计划好您的冲刺,因为中央计划员可能希望尽早获得一份全面的功能列表,而不会支持更轻松的敏捷方法。对你将要交付的内容保持保守,你应该会很好。

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

这是一个有趣的场景。几年前我也遇到过类似的情况,我认为这样做会使项目经理(你的?)的工作量增加一倍。你需要打双面牌,一副牌是给客户的,一副牌是给开发商的。

如果你的开发者很好,我会去的。如果它们不是,并且需要踢和握,那么要小心。如果他们很好,但可能会被他们自己的议程冲昏头脑,那么就要牢牢掌控。

请记住,基于测试的方法是敏捷开发的核心。先做测试。这对于客户来说是很特殊的,但是他们可以看到子项目的实际进展情况。你可能会在早期得到较少的“进步”,但在最后一码会得到更多。

取决于你的动机,以及你的目标是什么。

陷阱:主要的一个是敏捷开发通过增加可见性来工作。因此,在一个子项目中采用敏捷实践,如果成功的话,可能会暴露出影响整个项目的问题,从而产生反弹的风险。记住这个故事的寓言 two envelopes

您首先采取的做法取决于您希望如何处理此风险。如果您开始采用与计划相关的实践(任务板、发布计划、用户故事、速度),那么问题可能会相对较快地出现。

如果您从需求领域的实践(用户故事、自动验收测试)开始,或多或少也会如此。

如果您从内部质量(测试驱动开发、重构、持续集成)开始,您可能会提高开发人员对项目的积极性,但这样做的风险不一定会在更大的项目计划中影响很大。