項目管理，為什麼敏捷專家可能會威脅到您的軟體開發項目的成功

在軟體開發項目中，瀑布式方法指示了項目活動的順序和收費流程，這種方法已經使用了很長時間，直到研究和案例研究表明，一種替代的疊代且因此更靈活的方法（被廣泛稱為敏捷）更合適，有前途。 項目成功的機會更高。

實際上，統計和調查表明，敏捷的交付方式（具有Scrum，Kanban，XP等多種口味）可以提高利益相關者的滿意度，尤其是因為它考慮了當今商業環境的動態以及由此產生的事實。 在項目的整個生命周期中，項目範圍通常不會保持不變，因此可以適應過程中的更改。

有了一些明顯的好處，敏捷方法就變得非常流行，我經常聽到IT人士自豪地說："我們現在很敏捷！" 哪種聲音從傳統的瀑布模型發展到現代的敏捷方法，現在通過項目交付可以更加成功。

但是，這是一種危險的思維方式，實際上可能導致相反的結果，即項目失敗。

敏捷不是一種"萬能的"方法，而只是可以為給定項目選擇的另一種方法。 這裡的重點是"可以"，因為項目經理應該具有分析項目環境中各種因素的技能和能力，以確定可以保證項目成功的最合適方法。

下表顯示了那些特性和要考慮的因素，以便項目經理確定哪種方法最適合該項目：

因此，應該對所謂的敏捷專家保持謹慎，他們聲稱敏捷是任何項目的唯一出路。 在某些情況下，您還會聽到一些公司或IT部門負責人要求其團隊將敏捷應用於未來的任何項目-無疑是一種非常錯誤的方法，這表明此類敏捷專家對項目交付概念的看法非常有限且高度偏頗。

什麼是免疫專家？

敏捷專家通常是對敏捷方法有強烈熱情和知識的人，通常還會得到各種專業認證的支持，例如 Scrum Master，SAFe敏捷專家等。但是，在許多情況下，敏捷專家對敏捷方法學發展出非常強烈的偏見。

我個人對3種類型的敏捷專家及其相關態度進行了區分：

· 專制的敏捷主義者-"敏捷應該毫無例外地應用於所有軟體開發項目。 這可能是由於迄今為止在使用Agile的軟體開發項目中所取得的成就，因此該人被強烈地推向敏捷方法論。 他/她成為管理/領導敏捷項目的專家。

· 未知的敏捷主義者-"除了敏捷之外，我從未聽說過其他任何東西。" 這種類型的敏捷專家通常可以在年輕一代中找到，其中一些甚至在撰寫敏捷宣言（2001年）時可能還沒有出生。 這個人從來沒有參與過任何非敏捷驅動的項目，也沒有任何關於傳統瀑布概念的知識。

· 民主敏捷主義者-"我是敏捷交付方法的專家，但我也是傳統方法的專家。"在敏捷方法方面擁有豐富的專業知識並不意味著僅需要限制一種方法即可。 相反，這種類型的敏捷專家試圖成為敏捷和傳統交付方法方面的專家，不斷學習各種交付模型，並且能夠同時使用這兩種方法。

除非項目經理是3型敏捷專家（"民主敏捷專家"），否則他/她應被標記為項目的重大風險，因為敏捷方法可能是錯誤的選擇，並可能導致項目失敗。

示例：假設您要從A到B旅行，並且需要儘快到達那裡。 您可以通過兩種方式實現它：通過開車或騎自行車。 一個總是使用汽車而不理會其他任何方式的人可能會完美地實現目標。 但這可能取決於A與B的距離。如果從A到B花費100英里，那麼這輛車可能是最好的選擇，但是如果B距A僅2分鐘，那麼您可能應該選擇 騎自行車儘快到達那裡。

因此，應該提防負責項目交付的"專橫"和"不知情"的敏捷專家，他們過快地得出一個結論，即應該以敏捷的方式交付項目。

不要誤會我的意思，我也不反對敏捷-實際上，這是交付軟體開發項目時我個人的喜好。 但是我永遠不會忽略Waterfall是一個合理的選擇。

在選擇交付方法時，這裡根本沒有好與壞。 而是一個"取決於"。

最成功的項目經理是既可以兼職又可以兼任的項目經理：傳統主義者。

(本文翻譯自Marcus Glowasz的文章《When Agile is Evil》，參考：https://medium.com/the-project-office/when-agile-is-evil-534197f158e0)