僅在子項目中引入敏捷實踐？

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的寓言。

你首先採取的做法取決於你想如何處理這種風險。如果從採用計劃相關實踐（任務板，發佈計劃，用戶故事，速度）開始，事情可能會相對較快。

如果您從需求（用戶故事，自動驗收測試）領域的實踐入手，或多或少也是如此。

如果您從內部質量開始（測試驅動的開發，重構，持續集成），您可能會提高開發人員對項目的動力，但並不一定涉及大型項目。