有什麼好的做法，如果有的話，敏捷運動失去了？

Question

我是一個很長時間敏捷的倡導者，但讓我感到困擾的事情之一是很多敏捷實踐者，尤其是年輕人，已經拋出或缺少了很多好東西（非Scrum，非XP）實踐。 Alistair Cockburn的寫作風格讓人想起;正交陣列（成對測試）是另一個。

我大部分閱讀的都是敏捷相關的書籍和文章，主要是敏捷的民間工作......有什麼我失蹤了嗎？

Answer 1

在5 - 10年的時間裏，看看這些系統在沒有人寫下爲什麼做出特定決定以及所有相關人員都離開時如何維護這些系統，這可能很有趣。

Answer 2

（...）已拋出或缺少一大堆好的（非Scrum，非XP）實踐。

Scrum不是規定性的，它取決於你選擇如何做事情。換句話說，沒有什麼能夠強迫你使用用戶故事（例如，即使用戶故事適用於很多團隊，沒有共識），所以如果你認爲它們在你的上下文中更合適，可以隨意使用（輕量級）用例。爲了說明這一點，Jeff Sutherland報告說，他絕不會再使用用戶故事來進行PDA設備項目（他們在當前公司使用某種「光規格」）。這同樣適用於測試，使用任何適合你的作品。總而言之，如果您發現XP不夠靈活，請使用其他內容...並檢查並調整。

Answer 3

迭代開發。在實踐中，敏捷團隊可能會做迭代（或者其他任何事情，敏捷是一種「真正的蘇格蘭人」），但是敏捷過程並不需要或不足以定義迭代開發。

以RUP爲例 - 笨拙和臃腫，它確實爲長期發展編譯了一些敏捷錯過的好方法。

---

在一般筆記，敏捷是避開問題的方法：如何避免長期的規劃，如何保持團隊小，短期的任務，涉及的用戶，等它的工作往往不是，但有時候你必須面對並解決問題：如何達到嚴格的最後期限，完成大型團隊工作，實現遙遠而複雜的目標，滿足客戶需求。那時人們需要超越敏捷。

Answer 4

有什麼我失蹤？

是的，我想了很多，但前提是您對Softawre開發流程感興趣。

我喜歡這個意譯：

每個項目都應儘可能敏捷而不是更靈活。

不是每個項目都可以敏捷...但我認爲80％+可以。

我將敏捷視爲「car of the year」。它非常適合大多數人，但是如果你需要/想要一些特別的東西，例如能夠加速300KM/H的汽車或能夠攜帶20噸貨物的汽車，則需要其他東西。

還有很多情況下，當一個人可能想要別的東西比「一年的汽車」，需要一本書寫下來:-)我建議你Agility and Discipline Made Easy: Practices from OpenUP and RUP。在本書中，你會發現許多「缺失的部分」。理解的關鍵在於，敏捷性只是軟件開發過程（所要求的），有時無法實現。本書描述了幾個關鍵開發原則（這是RUP的基礎），並解釋了在不同級別的採用中使用它們的「儀式」和「迭代」級別。

一個例子

實踐：自動化的變更管理和更改傳播

在你的項目，你可能需要非常先進和嚴格的變更管理，並決定通過實現自定義的「自動變更管理和變更傳播」或重新配置現有工具，並使用變更和控制板。

效果：這很可能會增加您的項目中的「典禮」級別。