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

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

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

Sharma 表示，作為軟件行業(yè)的一員，當她第一次聽到非軟件團隊對敏捷方法表示歡迎時，她認為，“非?？尚校　?/p>

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

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

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

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

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

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

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

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

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

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

?工作在可管理的時間內(nèi)完成，并具有明確的任務(wù)優(yōu)先級。非技術(shù)團隊不會同時承擔所有任務(wù)。  

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

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

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

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

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

（1）反饋管理  

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

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

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

（2）更快的推進  

敏捷團隊通?？梢愿斓亟桓俄椖?，因為團隊成員積極學習如何確定工作的優(yōu)先級，并節(jié)省時間。敏捷方法要求團隊成員每天進行溝通，并不斷了解正在取得的進展。這樣，任何需要進行的重大更改都會被及早發(fā)現(xiàn)，并作為流程的一部分進行處理。  

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

（3）管理不確定性  

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

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

（4）明確的工作流程  

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

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

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

（5）客戶端集成  

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

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

敏捷適用于企業(yè)嗎？  

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

（1）當要求明確時  

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

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

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

（2）當團隊不愿協(xié)作時  

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

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

（3）當可以避免創(chuàng)新時

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

非軟件團隊的敏捷方法  

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

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

（1）什么是 Scrum？  

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

?客戶或企業(yè)擁有的分析師提出業(yè)務(wù)需求，這可能是需要完成的材料產(chǎn)品或過程。  

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

?在這個時間間隔結(jié)束時（比如第三個周末），團隊與客戶或分析師坐下來，向他們展示他們?nèi)〉玫某晒?，并確定是否令人滿意。  

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

關(guān)鍵要點：  

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

?在固定的時間內(nèi)處理每個部分。  

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

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

?關(guān)注“什么最有效？”，“這就是我們所設(shè)想的嗎？”等問題  

（2）Scrum 團隊結(jié)構(gòu)  

Scrum 有一個明確的團隊結(jié)構(gòu)，以便順利地協(xié)調(diào)工作。它可以幫助分配角色和職責，而無需使用確切的標簽。  

①產(chǎn)品擁有者  

?角色：要實現(xiàn)的目標的客戶或分析師。  

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

②Scrum 主管  

?角色：監(jiān)督 Scrum 流程的關(guān)鍵人物。  

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

③團隊  

?角色：執(zhí)行任務(wù)的實施者。  

?責任：團隊負責吸收需求并自行管理可執(zhí)行文件。他們在彼此之間分配任務(wù)，并協(xié)作以保持生產(chǎn)力。  

非軟件團隊敏捷的行業(yè)示例  

（1）Lonely Planet 公司

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

①面臨的挑戰(zhàn)  

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

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

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

②他們?nèi)绾巫兊妹艚?/p>

?團隊采用看板來為基于“待辦事項”或“待處理”的任務(wù)提供結(jié)構(gòu)。  

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

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

③結(jié)果  

Lonely Planet 公司的法律團隊能夠?qū)⑸a(chǎn)力提高 25%，并減少工作環(huán)境中存在的整體混亂。  

（2）荷蘭國家藝術(shù)博物館  

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

①面臨的挑戰(zhàn)  

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

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

②他們是如何轉(zhuǎn)向敏捷的  

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

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

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

③結(jié)果  

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

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

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

①面臨的挑戰(zhàn)  

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

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

②他們是如何轉(zhuǎn)向敏捷的  

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

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

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

③結(jié)果  

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

結(jié)論  

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

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

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