Here's a great diary of how a guy changed his whole company towards Agile over a period of a couple of years - yes, starting with his own subproject, i.e. "bottom-up". But he does go into the pros and cons of trying a "top-down" change.
Beyond that it's probably mostly marketing/expectation management with your superiors and customers. Both of which might resent investing in the various agile customer-inclusion "games". Both of which also might resent the "new-fangled" way of doing things.
I think the answer depends how isolated you can be from everyone else's process. If they just tell you to go get your portion done and come back with a completed widget, implementing Agile locally should be relatively easy. If, on the other hand, you are expected to follow lots of random dates and procedures, it will be more difficult.
You'll have to be flexible and make sure that whatever sprint cadence you have lands on similar dates to the rest of the system. You'll have to plan out your sprints ahead because the central planners will probably want an all-up feature list early and won't stand for the more laid back Agile approach. Just be conservative about what you'll deliver and you should be fine.
The advantages should be the same as the advantages Agile has elsewhere.
This is an interesting scenario. I had a similar situation years back, and I'd say doing this essentially doubles the project manager's (your?) workload. You will need to play double face, with one set of cards towards the customer and one set towards the developers.
If your developers are GOOD, I would go for it. If they are not, and would require kicks and handholding, be careful. If they are good but may get carried away to their own agendas, be firmly in charge.
It is sometimes funny how organizations with traditional project model emphasize minor features, irrelevant to the developer's mind, and completely ignore the real hot spots. I still don't get it - maybe it's plain stupidity and nonprofessionalism. Expect that.
And do remember test based approach is the heart of Agile development. Do tests first. This will be peculiar to the customer, but they will benefit in seeing how the subproject actually proceeds. You might get less "progress" early on but more at the final yards.
Depends on your motivations, and what you aim to achieve.
Pitfalls: the major one is that agile development works by increasing visibility. Thus, adopting agile practices in one sub-project, if the effort is at all successful, can lead to exposing issues that affect the whole project, resulting in a risk of backlash. Keep in mind the parable of the two envelopes.
Which practices you take on first depends on how you want to handle this risk. If you start by adopting the planning-related practices (task board, release plan, user stories, velocity) matters may come to a head relatively fast.
Ditto, more or less, if you start with practices in the area of requirements (user stories, automated acceptance tests).
If you start with internal quality (test-driven development, refactoring, continuous integration) you may improve the motivation of the developers on the project, at the risk of not necessarily mattering a whole lot in the larger scheme of things.
发布评论
评论（5）
这是一篇精彩的日记，讲述了一个人如何在几年的时间内将整个公司转向敏捷——是的，从他自己的子项目开始，即“自下而上”。 但他确实探讨了尝试“自上而下”变革的利弊。
http://jamesshore.com/Change-Diary/
非常有趣和有趣的东西。
Here's a great diary of how a guy changed his whole company towards Agile over a period of a couple of years - yes, starting with his own subproject, i.e. "bottom-up". But he does go into the pros and cons of trying a "top-down" change.
http://jamesshore.com/Change-Diary/
Very entertaining and intruiging stuff.
阅读将敏捷引入工作场所的有效方法和 Joel 的 < a href="http://en.wiktionary.org/wiki/seminal_work" rel="nofollow noreferrer">开创性 当你只是一个普通人时也能把事情做好。
除此之外，可能主要是与上级和客户进行营销/期望管理。 两者都可能不愿意投资于各种敏捷的客户包容“游戏”。 两者都可能对“新奇”的做事方式感到不满。
Read Effective Ways to Introduce Agile into the Workplace and Joel's seminal Getting Things Done When You're Only a Grunt.
Beyond that it's probably mostly marketing/expectation management with your superiors and customers. Both of which might resent investing in the various agile customer-inclusion "games". Both of which also might resent the "new-fangled" way of doing things.
我认为答案取决于您与其他人的流程的隔离程度。 如果他们只是告诉你去完成你的部分并带着完成的小部件回来，那么在本地实施敏捷应该相对容易。 另一方面，如果您需要遵循大量随机的日期和程序，那就会更加困难。
您必须保持灵活性，并确保您的冲刺节奏与系统其他部分的着陆日期相似。 您必须提前计划好您的冲刺，因为中央规划人员可能希望尽早获得完整的功能列表，并且不会支持更悠闲的敏捷方法。 只要对你要交付的东西保持保守，你应该没问题。
这些优势应该与敏捷在其他地方所具有的优势相同。
I think the answer depends how isolated you can be from everyone else's process. If they just tell you to go get your portion done and come back with a completed widget, implementing Agile locally should be relatively easy. If, on the other hand, you are expected to follow lots of random dates and procedures, it will be more difficult.
You'll have to be flexible and make sure that whatever sprint cadence you have lands on similar dates to the rest of the system. You'll have to plan out your sprints ahead because the central planners will probably want an all-up feature list early and won't stand for the more laid back Agile approach. Just be conservative about what you'll deliver and you should be fine.
The advantages should be the same as the advantages Agile has elsewhere.
这是一个有趣的场景。 几年前我也遇到过类似的情况，我想说这样做本质上使项目经理（你的？）的工作量增加了一倍。 您需要玩双面牌，一组牌面向客户，一组牌面向开发商。
如果你的开发人员很好，我会选择的。 如果不是，并且需要踢和握住，请小心。 如果他们很优秀，但可能会沉浸在自己的议程中，那么就要牢牢掌控一切。
有时很有趣的是，采用传统项目模式的组织会强调与开发人员的想法无关的次要功能，而完全忽视真正的热点。 我还是不明白——也许这纯粹是愚蠢和不专业。 期待这一点。
请记住，基于测试的方法是敏捷开发的核心。 先做测试。 这对于客户来说是特有的，但他们将从了解子项目的实际进展情况中受益。 你可能在早期获得的“进步”较少，但在最后几码获得的“进步”更多。
This is an interesting scenario. I had a similar situation years back, and I'd say doing this essentially doubles the project manager's (your?) workload. You will need to play double face, with one set of cards towards the customer and one set towards the developers.
If your developers are GOOD, I would go for it. If they are not, and would require kicks and handholding, be careful. If they are good but may get carried away to their own agendas, be firmly in charge.
It is sometimes funny how organizations with traditional project model emphasize minor features, irrelevant to the developer's mind, and completely ignore the real hot spots. I still don't get it - maybe it's plain stupidity and nonprofessionalism. Expect that.
And do remember test based approach is the heart of Agile development. Do tests first. This will be peculiar to the customer, but they will benefit in seeing how the subproject actually proceeds. You might get less "progress" early on but more at the final yards.
取决于您的动机以及您想要实现的目标。
陷阱：主要的一个是敏捷开发通过提高可见性来发挥作用。 因此，在一个子项目中采用敏捷实践，如果这一努力完全成功，可能会导致暴露影响整个项目的问题，从而导致强烈反对的风险。 请记住两个信封的寓言。
您首先采取哪种做法取决于您希望如何处理这种风险。 如果您首先采用与规划相关的实践（任务板、发布计划、用户故事、速度），事情可能会相对较快地达到高潮。
如果您从需求领域的实践（用户故事、自动验收测试）开始，或多或少也是如此。
如果您从内部质量（测试驱动开发、重构、持续集成）开始，您可能会提高项目开发人员的积极性，但冒着在更大的计划中不一定很重要的风险。
Depends on your motivations, and what you aim to achieve.
Pitfalls: the major one is that agile development works by increasing visibility. Thus, adopting agile practices in one sub-project, if the effort is at all successful, can lead to exposing issues that affect the whole project, resulting in a risk of backlash. Keep in mind the parable of the two envelopes.
Which practices you take on first depends on how you want to handle this risk. If you start by adopting the planning-related practices (task board, release plan, user stories, velocity) matters may come to a head relatively fast.
Ditto, more or less, if you start with practices in the area of requirements (user stories, automated acceptance tests).
If you start with internal quality (test-driven development, refactoring, continuous integration) you may improve the motivation of the developers on the project, at the risk of not necessarily mattering a whole lot in the larger scheme of things.