本文將介紹敏捷原則和一些行業示例，并了解非軟件團隊如何采用敏捷方法以提高團隊生產力。  

在線項目管理工具 Proof Hub 開發工程師 Nandini Sharma 表示，調整某些事情的方法有時候可以徹底改變這么做的原因。方法論本身就試圖重新想象意義。  

在很多時候，由熱情驅動的工作通常陷入困境，而方法驅動的工作在努力實現目標的同時不斷尋找前進的道路。在本世紀初引入敏捷方法就是幫助軟件團隊提高生產力的一個例子。

Sharma 表示，作為軟件行業的一員，當她第一次聽到非軟件團隊對敏捷方法表示歡迎時，她認為，“非常可行！”

而在畢馬威公司一項調查中，77%的受訪者表示在IT職能之外使用了敏捷項目管理。此外，59%的受訪者在其營銷和銷售流程中采用了敏捷用例。

敏捷確實具備團隊明智的管理資源所需的要素。圣何塞市政部門工作人員采用敏捷來提高生產力和效率，因此對于這一點不要感到驚訝，很多行業也可以這樣做。對于開發軟件，Sharma 和其團隊使用了幾種項目方法和團隊管理軟件來保持工作正常進行。

雖然非技術團隊可以自由使用，但這里有一些非技術的方法，可以讓世界各地的非技術(軟件)團隊適應敏捷方法的技術特性。

敏捷對于非軟件團隊來說是什么？

敏捷最初是為軟件團隊開發的，它是一種方法論，致力于優先考慮團隊協作而不是孤島運營，將動態變化置于嚴格規劃之上，并讓利益相關者積極參與項目。

對于非技術團隊，采用敏捷方法的核心原則如下：  

?團隊所有成員全面討論手頭的任務，互相分享想法。并不是每個人都只做他們自己的事情。  

?更多的關注點是付諸行動，執行實際工作，而不是在精心策劃上花費時間。  

?讓關鍵的利益相關者（主要是客戶）積極參與該過程，以對正在取得的進展進行不斷的反饋。  

?為更改、修改和重新考慮留出空間，以便將其整合到開發中。  

?工作在可管理的時間內完成，并具有明確的任務優先級。非技術團隊不會同時承擔所有任務。  

人們可以自由地將這些想法應用到認為合適的工作流程中。由于不專注于編寫代碼，因此這些想法在實現上會有所不同，同時保持其本質。  

需要記住，敏捷是一種意識形態，而不是指令。最好的做法是吸納這些想法，而不是創建用戶手冊。

敏捷對非軟件團隊有什么好處？  

敏捷工作方式旨在克服軟件團隊面臨的某些項目管理挑戰。但是，如果了解這些概念，對幾乎所有計劃采用它們的團隊都有深遠的好處。  

以下是敏捷為非軟件團隊提供的一些好處。  

（1）反饋管理  

幾乎所有類型的團隊都需要來自內部組織（員工）或外部消費者（客戶）的持續反饋，以使工作與期望的標準保持一致。如果反饋沒有被正確吸收或沒有一致地分發，其輸出可能會變得不規則。Sharma 將其稱為“質量不合格”。  

在敏捷過程中，工作通常被劃分為持續 1～3 周的階段。在每個階段結束時，主要利益相關者將對工作進行審查，以便及時指出問題。

因此，非軟件團隊可以通過遵循敏捷方法，建立以反饋為中心的文化，以保持結果符合預期。  

（2）更快的推進  

敏捷團隊通常可以更快地交付項目，因為團隊成員積極學習如何確定工作的優先級，并節省時間。敏捷方法要求團隊成員每天進行溝通，并不斷了解正在取得的進展。這樣，任何需要進行的重大更改都會被及早發現，并作為流程的一部分進行處理。  

由于可以及時解決問題，因此避免了長時間的來回修訂。項目不會延遲，交付速度也會得到積極影響。  

（3）管理不確定性  

在任何項目中，真正的交付并非簡單的執行計劃，而是管理不可預見的事情。任何有經驗的項目經理都會認同“無論做什么都會出現不確定情況”的說法。而墨菲定律告訴我們，“項目問題不可避免”，無論計劃有多好都會出錯，因為它必定會出錯。  

敏捷方法旨在有效地應對不確定性，因為它不是建立在嚴格的時間表之上的。團隊成員可以靈活地調整項目流程，并在需要時適應變化。  

（4）明確的工作流程  

大多數敏捷框架都帶有旨在保持項目進度高度組織的工作流。需要注意的是，這些工作流程并非旨在進行微觀管理，而是為整個團隊創建參考點。  

最常見的例子是看板框架，它包括“計劃實施”、“正在進行”和“完成”等階段。許多Saas 應用程序提供基于看板的工作流程。

這樣做是為了在每個任務從一個階段轉到另一個階段時，為項目提供系統的任務生命周期。工作流程的存在確保了項目的靈活性可以通過安全欄得到補償。  

（5）客戶端集成  

敏捷方法強調在項目的每個階段都要讓客戶參與進來，而不是在 6 個月后才讓他們參與。客戶集成在主要問題出現之前解決。服務行業工作的團隊很清楚，當客戶在投入大量時間之后表示反對意味著什么。  

當客戶積極參與每周會議、項目更新并清楚地了解項目的發展方向時，就會有更大的成功機會。  

敏捷適用于企業嗎？  

事實上，敏捷適用于企業。以下了解一下敏捷可能不起作用的項目。  

（1）當要求明確時  

如果客戶或項目有明確定義的期望，并且不確定性最小，那么項目可以采用常規的方法。

由于企業不需要大量的客戶反饋，并且團隊成員必須遵循線性路徑，因此敏捷方法的核心原則不會有很多好處。  

大多數軟件項目在本質上都是探索性的。隨著項目逐漸成型，每個人（包括客戶）都會弄清楚他們想要什么。如果已經知道項目的結果和方向，敏捷就不會有太大的幫助。

（2）當團隊不愿協作時  

協作是運行敏捷項目的關鍵。如果團隊不愿協作，那么敏捷可能會適得其反。

顯然有一些方法可以改善團隊內部的溝通，例如團隊溝通工具和小組活動，但說起來容易做起來難。如果覺得團隊溝通并不是很大的挑戰，那么沒有敏捷也可以做得很好。  

（3）當可以避免創新時

并非所有項目都需要創新。敏捷開發的目的是讓創新輕松融入工作方式。如果項目是一個簡單的任務列表，可以標記完成并向前推進，那么可能不需要敏捷方法。

非軟件團隊的敏捷方法  

既然知道了使用敏捷的方法好處和注意事項，那么了解非軟件團隊如何將敏捷方法融入他們的工作中。在這里需要關注 Scrum：敏捷框架為充分利用敏捷制定了一套規則。  

同樣，這里只討論使用 Scrum 的概念性方法，而不會深入探討機制。  

（1）什么是 Scrum？  

Scrum 是敏捷方法的可實現版本，在其中討論科學術語、工作協議和定義的團隊角色。從非技術角度上來說，它可以概括為以下幾點：

?客戶或企業擁有的分析師提出業務需求，這可能是需要完成的材料產品或過程。  

?團隊了解需求，并開始在設定的時間間隔內自行編排工作，通常需要 1～3 周的時間，在此期間他們將完成一小部分需求。  

?在這個時間間隔結束時（比如第三個周末），團隊與客戶或分析師坐下來，向他們展示他們取得的成果，并確定是否令人滿意。  

?如果工作達標，則計劃實施下一個任務。如果工作需要調整，團隊將努力整合更改并相應地計劃未來 1~3 周的任務。  

關鍵要點：  

?將工作分成幾個小部分。  

?在固定的時間內處理每個部分。  

?審查每個部分取得的進展。  

?讓關鍵利益相關者（客戶或分析師參與審查）參與進來。  

?關注“什么最有效？”，“這就是我們所設想的嗎？”等問題  

（2）Scrum 團隊結構  

Scrum 有一個明確的團隊結構，以便順利地協調工作。它可以幫助分配角色和職責，而無需使用確切的標簽。  

①產品擁有者  

?角色：要實現的目標的客戶或分析師。  

?責任：找出需要解決的問題，仔細了解需要什么樣的解決方案；產品負責人制定期望，并驗證進度是否朝著正確的方向發展。  

②Scrum 主管  

?角色：監督 Scrum 流程的關鍵人物。  

?職責：Scrum 主管充當產品負責人和團隊之間的紐帶。他們管理溝通、確保協作，并確保有效地遵循 Scrum。  

③團隊  

?角色：執行任務的實施者。  

?責任：團隊負責吸收需求并自行管理可執行文件。他們在彼此之間分配任務，并協作以保持生產力。  

非軟件團隊敏捷的行業示例  

（1）Lonely Planet 公司

澳大利亞 Lonely Planet 公司是一家擁有 49 年歷史旅行書籍出版商，該公司推出了一個下載量超過 10 萬次的移動應用程序。  

①面臨的挑戰  

?Lonely Planet 公司的法律團隊在管理日常需求方面面臨問題。  

?法律文件修改較多，工作重點未確定。  

?團隊成員感到壓力過大和不滿。  

②他們如何變得敏捷

?團隊采用看板來為基于“待辦事項”或“待處理”的任務提供結構。  

?團隊使用類似 Scrum 的框架來管理修訂反饋，并輕松管理成員的工作。  

?如果沒有 Scrum 主管，團隊成員會自行管理，確定任務的優先級，并確保工作量不會變得不堪重負。  

③結果  

Lonely Planet 公司的法律團隊能夠將生產力提高 25%，并減少工作環境中存在的整體混亂。  

（2）荷蘭國家藝術博物館  

荷蘭國家藝術博物館是荷蘭最古老的博物館之一，建于 1885 年，收藏著荷蘭藝術和歷史的精美作品。

①面臨的挑戰  

?該博物館需要根據它們所屬的歷史時間來管理和展示其文物。  

?由于管理所需的大量工件和專業知識，任務變得繁重。  

②他們是如何轉向敏捷的  

?在博物館工作的團隊將自己組織成自我運作的小組，并對歷史上出現的文物進行分類。  

?他們在完成任務的幾個小組之間建立了強有力的溝通，并積極合作以實現目標。  

?該方法是非線性的，因為團隊在進行中改變了他們的團隊結構、方法和速度。  

③結果  

該團隊能夠高質量地完成任務，并采用這種敏捷流程來隨著博物館流量的增長，不斷改變博物館的陳列和展示方式。  

（3）美國國家公共廣播電臺  

美國國家公共廣播電臺是一家擁有 50 年歷史的廣播電臺，在美國擁有 1,000 多個聯合廣播電臺。  

①面臨的挑戰  

?美國國家公共廣播電臺向制作廣播節目推銷創意，但他們很難想出一個看似成功的節目模式。

?美國國家公共廣播電臺節目的構思過程具有風險、成本高昂，并且通常需要進行多次更改。  

②他們是如何轉向敏捷的  

?美國國家公共廣播電臺通過創建小型迭代“試播節目”，采用敏捷的方式推銷創意，并與當地團隊、地區項目主管和社交媒體上的聽眾一起進行測試。

?與帶有不確定性的成熟節目相比，這些試播節目雖然成本不高但也不容易傳播。

?他們利用各種來源的反饋，積極了解觀眾最喜歡什么，作為他們完整制作節目的基礎。  

③結果  

該團隊使用敏捷的方式來管理節目的編排，以減少不確定性，并整合來自多個渠道的反饋，從而實現經濟高效、快速、高質量的制作。

結論  

如果項目的不確定性、不完整的需求和模糊的愿景是項目的一些特征，那么應該嘗試一下敏捷原則。

它在使軟件團隊獲得更大成就方面有著良好的記錄，并且對其他團隊也具有巨大的潛力。本文是理解敏捷方法的一種嘗試，雖然可能無法完全理解這一點，但可以將本文作為入門介紹。  

畢竟，這一切都歸結為如何提高生產，這需要花費更多的時間來掌握。