「孤狼」開發人員可能已經不合時宜

「孤狼」開發者的時代已經過去，證據表明，更多樣化的團隊通過協作能夠產出更好的成果，協作已然成為成功關鍵的因素。

關鍵啟示：

敏捷需要自適應架構。如果沒有正式的設計過程，代碼會堆疊在舊的代碼之上，最終得到一個不靈活的設計結果。

工具被創造時，軟體和業務敏捷度並非完全相同，這兩種敏捷需要單個工具來滿足所有用戶的需要。

「孤狼」開發者的時代已經過去，證據表明，更多樣化的團隊通過協作能夠產出更好的成果，協作已然成為成功關鍵的因素。

將大規模敏捷項目擴大涉及團隊間的和更多的跨職能間的協作和可見性。

因為當今的項目可能一開始時並沒有明確固定的需求，所以項目經理必須計劃設立一條持續的規劃和反饋循環。

數字轉型要求IT組織成為提供差異化客戶體驗的業務推動者，從而獲得投資回報。為了跟上創新步伐、立即取得成果，許多IT團隊採用敏捷開發方法，其發布間隔以天為單位，而不是季度，從而使質量得以保證。

這樣的目標可能是軟體開發界的聖杯，但它並非總是可行。從理論上講，敏捷開發具有所有正確的要素，但它並不適合所有項目。讓我們考慮一下它在最佳情況下是什麼樣子。

敏捷開發能加速初始業務價值的交付，並採用持續的規劃和反饋流程。由於採用了這種迭代規劃和反饋循環，團隊不僅能將交付的軟體與所需的業務需求保持一致，而且能輕鬆適應整個流程中不斷變化的需求。

狀態的測量和評估基於利益相關者對於項目所有階段實際進展情況的準確了解。由於遵循了敏捷流程，在項目結束時，軟體系統更好地滿足了業務和客戶需求。

一切聽起來都很合乎邏輯且合理，但敏捷項目的現實往往會有所不同。敏捷方法並不總是能獲得預期的結果。

以下是敏捷項目失敗的六種常見情況。

1

不可持續的系統架構

《敏捷宣言》指出，「良好的設計和卓越的技術能提高敏捷」，並且人們一直在推動「適應性架構」。保持敏捷的訣竅在於提前做好足夠的設計。但問題在於如何知道什麼樣的設計能被稱為足夠的設計。如果設計過程變更太少，且沒有正式的設計過程，代碼堆疊在舊代碼之上，最終得到的會是一個不夠靈活的設計。

敏捷架構與傳統的瀑布架構不同，瀑布架構中的系統架構在前期即被準確定義，開發是一次性活動，具有明確開始和結束日期。敏捷的軟體架構則是一個持續的過程，它使開發人員能夠持續地在必要時對架構進行更改。設計在sprint計劃會議期間可能是連貫的，但它可能缺乏可以賦予其長期可持續性的正式架構模型。

2

現有工具的局限性

敏捷方法常受到現有工具的限制。當今的企業應用程序生命周期管理（ALM）市場由整體式和企業內置的解決方案主導，由於這些方案是根據「瀑布」交付方式設計的，它們缺乏敏捷交付的關鍵要素。

雖然軟體開發行業已經在採用最佳的敏捷工具（如Jenkins、VersionOne和RallyDev），但這些工具並非針對企業IT組織的需求而設計。相反，它們設計的目的是被專業軟體工程師使用，而不是業務用戶。

這些用戶不願意、不能、亦不應該被要求參加培訓課程，以學習如何進行功能測試並提供反饋。另外，由於這些系統包含太多功能，而且這些功能擁有過高且不必要的硬體和計算要求，所以購買和維護它們也可能很昂貴。

3

文化鴻溝

一些習慣了獨立工作的開發人員可能會發現敏捷開發所需的所有協作均會減慢自己的速度。

對許多人來說，如果習慣了大量的自由，他們就會反對改變工作方式以適應高度協作的方法。那些創造力強又聰明的人通常只希望你給他們想要的工具，然後讓他們干自己最擅長的事。儘管最終，敏捷項目團隊的每個人都需要變得更加靈活。

據Gartner的《2016年度應用測試服務魔力象限》估計，到2020年，60％的測試人員將需要測試、應用開發、業務流程或行業技能的組合而不是某個單一的技能。考慮到當今項目發生變化的程度，「孤狼」開發人員單獨坐在某處，不與別人交流的做法已經毫無意義，因為協作已然成為成功的一個關鍵因素。

很多證據表明，更多樣化的團隊可以取得更好的成果，所以個人開發者是否應該「順應潮流」並學習一些社交技能呢？

4

難以擴大規模

敏捷是一種傳統意義上受到中小型企業歡迎的方法，但最近在大型企業中它也已變得更加主流。

小項目對於敏捷開發較為理想，因為大項目需要更多的協調。將敏捷應用於大項目遇到的一個特殊問題就是如何處理團隊間的協調。

大規模敏捷涉及與其它組織單位（如人力資源、營銷、銷售以及產品管理）間的溝通。因為敏捷方法很大程度上依賴於緊密的工作關係和大量的用戶反饋，隨著項目的增長，通信流也會呈指數倍增。

另外，隨著企業拓展到新的地域，或與其他組織合併，項目也會因此分散在不同地點的多個團隊中。如果在不同的地點和協作工具之間沒有一致的方法，人員不能看到分布在多個開發和測試團隊中的測試周期的實時狀態，那麼可能會導致瓶頸，進而導致項目延遲和成本超支。

5

項目類型不對

傳統方法（如瀑布）對於範圍兩端的項目最有效，即：1）已經建立了明確和固定要求的項目，或者2）之前沒有可以提供有效反饋的用戶群的新技術或方法。

儘管事實上，長期的項目越來越不普遍。當今的業務環境具有VUCA性（不穩定性、不確定性、複雜性和模糊性），這意味著一個為期12個月的項目中60%以上的需求將會發生變化，所以幾乎不存在一個「固定」的項目終點。

當今的業務系統中已經沒有「明確和固定的需求」這一說了。技術變化非常迅速，客戶需求非常緊急，法律變化非常頻繁。「只有看到了，我才知道要什麼」（即IKIWISI - 摘自1986年《快速應用開發》）才是用戶需求的真正寫照。

項目經理必須評估項目，來判斷少量開發人員獨立工作的做法是否是介於1和2之間的項目是更合適和更具性價比的解決方案。

與矩陣管理結構中的多個不同用戶組進行對接的項目或許不適用敏捷方法。例如，使用金字塔結構時，通常一起工作的團隊數量大於項目實際需要的數量。當這些團隊成員被部分分配給項目時，問題變得更糟，因為投入度較低。

6

因為協作問題陷入僵局

為了從敏捷方法中獲得最大收益，軟體開發團隊成員需要每天看到、感覺到和聽到用戶身上發生的情況。但現在大多數項目的現實是，不同的團隊成員距離較遠，或者無法面對面溝通。依靠手動的電子郵件通信可能會減慢通信速度，並且容易出錯。

根據我自己在企業組織方面的經驗，超過50％的組織正在使用Microsoft Office產品，如Word或Excel，有的組織甚至是通過紙和筆來管理應用交付的某一方面，比如測試。

當來自不同地點、不同地域的團隊開始使用通信工具來獲取所有不同類型的信息並加快信息流動時，他們常常會得到過程的優化和最終結果的改進，從而使團隊更強大、更高效。

當一個測試組落後，或涉及用戶驗收測試的業務用戶因休假而忘了運行程序時，工具可有效防止流程卡住。項目內部人員和與客戶之間的溝通和協調常常由於物流、位置和時間安排變得很困難，所以建立方便敏捷團隊協作的端到端通信框架對於幫助人們更有效地合作至關重要。

當敏捷開發有效的時候，組織能夠發布高質量、迅速變更的軟體，推動企業向前發展。但它並非任何時候都有效。要想成功，需要協作、透明度和實時了解項目風險和質量。

嘗試用戶故事映射、思維導圖和用戶故事切分技術能夠更好地將大型複雜的解決方案拆分為更小、更獨立的部分，從而快速進行實施並更快地獲得用戶反饋。你肯定希望看到更遠的未來，想知道當下你需要做什麼來創造價值，並在將來交付這些價值。

所以請保持交流的通暢，並將所有反饋的消息自動化，包括測試結果、變更單和重新測試，以便使一切流暢進行。

同時請承認該方法論的局限性，如果你的專家堅持獨立工作，而且矩陣管理過於臃腫使得所有的反饋線路難以管理，請不要羞於承認敏捷的局限性，回到瀑布方法吧，雖然它有些過時，但它畢竟是經過驗證的方法論。

最終，我們正在構建的是客戶可以使用而且喜歡的產品。根據客戶的反饋頻繁添加新功能能使他們更滿意。

對於軟體客戶來說，有什麼比投資一個毫無用處的產品，它不能滿足我的需求，而且我看不到一條能讓它變得更好的出路更糟糕的事情？ 如果我知道某個首次迭代的產品會隨著時間的推移變得更好，我肯定會購買它。

事實上，當採用敏捷方法時，隨著開發團隊不斷改進產品，客戶看著產品不斷改進是很快樂的事情。敏捷幫助我們與客戶建立這種夥伴關係，使我們能夠與他們一起努力解決問題。

儘管敏捷開發方法有其複雜性，但如果具備正確的條件和工具，IT團隊絕對可以實施敏捷開發方法、推動業務發展、並鞏固持久和忠實的客戶關係。

如您有何疑問，請聯繫小編：

15201480058

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 優才學院 的精彩文章: