現在，大多數組織都使用敏捷軟件交付模型，其首要目標是盡快交付新功能。
我們不妨思考一下這些統計數字：由Digital.ai于2020年5月發布的《第14屆年度敏捷方法現狀報告》發現，有95%的受訪者表示自己的組織有實踐敏捷方法，而這樣做的首要原因是為了加快軟件交付，增強處理不斷變化的工作重點的能力并提高生產率。
盡管這些受訪者抱有如此宏偉的目標，但是敏捷專家和敏捷實踐者紛紛表示，許多組織并沒有達到它們所追求的速度，因為它們對實踐中的持續性問題視而不見。
Scrum.org的首席執行官Dave West說：“人人都說自己在實踐敏捷方法，但很多人其實并沒有做到，或者做的不盡如人意。”
那么，組織到底在哪些地方做得不盡人意而自身又沒有意識到呢?下面來看看十個常見的自欺行為，這些行為仍然會降低軟件的交付速度。
1. 我們之所以敏捷，是因為我們使用各種術語
West發現IT團隊采用了敏捷方法的那套話語體系，例如將項目經理稱為Scrum主管，將工作組稱為部落。誠然，使用合適的術語也許很重要，但這往往只是表面的變革。這些步驟必須得到組織重組的大量工作的支持，從而使已經完成的工作與已經安排的新職位相匹配。
West說：“人們常常做相同的事情，只是稱謂不同罷了。他們也許更改了名稱，但并沒有更改工作要素。而且大多數人為實現這一目標只是做了口頭承諾。”
第一資本(Capital One)的技術副總裁Christine Hales對此表示贊同。
Hales說：“這確實是一種文化變革。如果你將其視為一堆流程和工具來使用，那么你就會錯過真正可行的解決方案。人們需要以團隊的方式進行不同的工作;這就是文化的轉變。”
2. 技術人員不需要接受工具和過程變革方面的培訓
多年來，德國的金融機構德國中央合作銀行(DZ Bank)引入了一系列技術來支持長期的開發運維(DevOps)實踐，但總部位于德國法蘭克福的開發運維負責人Henning Ehm發現，采用此類工具是漫無目的的。
Ehm說：“我當時在想，‘我在做一些有益他人的事情，我創建技術，然后他們以適當的方式使用技術。’但是卻有很多人抵觸技術。”
IT領導者往往會認為自己的技術人員會自覺地利用最新的工具并加大使用力度，這種看法并不罕見。但是，正如Ehm所了解的那樣，技術人員也需要培訓，而且也要從變革管理的策略中受益。
Ehm說：“工程人員喜歡反復鉆研，但是要想真正發揮工具的潛力并將其引進流程中，這是艱苦的工作，你必須在變革流程上孜孜以求。如今，我更加關注員工本身，更加關注如何使他們處在一個將技術發揮到極致的場合。”
3.拖沓的會議
敏捷實踐放棄了冗長的正式會議，轉而傾向于短暫的集體會議和類似的活動，但是積習難改。例如，Ehm說，他發現，一些本該持續15分鐘的Scrum會議卻持續了45分鐘之久，與會者利用這段時間來解決所有它們所關注的問題和話題。
Ehm說：“會議必須有一個非常具體的目的，但很多人對此并不習慣”。他說，管理者需要讓團隊知道這樣一件事，即在采用敏捷方法并需要管理者強行對時間和話題施加限制時，那就要讓他們知道會議真正的運作方式。
Ehm說：“現在，我們在會議上僅討論一件事。”
4. 只要能自由選擇工具和流程就永遠能提高速度
盡管現代實踐鼓勵各個團隊選擇適合自己的方法，但美國運通全球商務旅行(American Express Global Business Travel)的工程總監Amit R Bhandarkar卻認為這種方法存在弊端。
Ehm說，他的團隊最終使用了不同的持續集成/持續交付(CI/CD)工具，其中一些工具使用開源的解決方案，而另一些工具則使用由不同供應商提供的產品。“他們以不同的方式實現了相同的結果并且影響了敏捷性;Bhandarkar說：“有些團隊表現十分出色，而另一些團隊則在苦苦掙扎。”
作為回應，開發團隊進行了標準化，轉移到一個高度一致的環境中，這個環境能維持高度一致的成功率并減輕了開發人員的維護負擔。
Bhandarkar認為這是一個經驗教訓。“只要有選擇，你就必須對自己的方法進行規范;無論這是你想要的特定方法或是沖刺的時間，你都希望保持規范性和一致性，以便每個人都彼此同步”，他這樣說道。
5. 我的團隊足夠靈活
貝恩公司(Bain & Co.)的合伙人兼《正確實施敏捷方法(Doing Agile Right)》的合著者Steve Berez曾經與一家航空公司合作，該航空公司需要工程師為飛行操作創造各種新的功能，同時需要減少客戶系統的工作。但是能夠進行飛行操作運營的工程師數量有限，這使IT部門對不斷變化的業務需求的響應能力大大降低。
Berez說，這是一個十分普遍的問題，他還補充說“工程師不是說取代就取代的。”
Berez說，首席信息官可以通過在業務的不同部分增加對通用技術的使用以及對員工的交叉培訓來解決此問題，以便員工可以使用多種技術。
Berez解釋說：“這往往意味著使用微服務進行新的開發任務并對那些微服務使用相同的開發語言，即使在不同的功能領域也是如此。”
6. 該規則不適用于我們
與所有方法一樣，敏捷框架主張使用一系列最佳實踐。
但West發現許多組織并不遵循某些規定的流程，它們認為自己不受這些流程的限制——之后卻想知道自己為什么沒有獲得期望獲得的好處。
例如，West已經發現組織從敏捷團隊中排除了一個特定的業務組(例如市場營銷)，理由是這在他們的公司中是行不通的，因為他們的流程太獨特了，而實際上這只是一場沒有人愿意為之奮斗的地盤之爭。
Berez說：“‘我很特別’是‘我無法解決這個問題的絕妙借口’。”
West還說：“每個人都是獨一無二的，但現實并非如此。誠然，每種情況都是獨一無二的，而且一個模型并不能適用于所有的情況，但基本原則卻都適用。因此，如果你要打破敏捷原則，那么你必須明確說明你為什么要這樣做并了解這樣做的后果。”
7. 光是流程變革就足夠了
技術研究和咨詢公司信息服務集團(ISG)的合伙人Prashant Kelker說：“目前，人們過于關注敏捷方法和儀式，以至于忽略了結構。”
Kelker說，企業里的敏捷倡導者還需要考慮如何重組部門和產品，例如確定這些要素是否以客戶或流程為中心。
Kelker承認，這是一個很難應對的方面。他說：“一旦你開始談論結構，你就會專注于自我，職務，員工的職業和職業發展歷程”，但他強調結構問題仍需解決。
8. 我們的預算流程不會拖后腿
盡管大多數組織都采用了敏捷方法，但是管理專家說，許多組織沒有意識到更新長期預算慣例的必要性。
Berez說：“我們在許多組織中發現了這樣的情況，即它們追求新商機的過程花了太長時間。當他們期望的價值不存在時，停下正在開展的工作又花了太長時間。這往往是因為許多組織每年依然為項目提供資金。”
Berez說，最成功的敏捷組織已經發生了轉變，即從決定每年資助哪些計劃變為實施一個預算流程，該流程隨著工作的進展并證明了自身的價值而更為頻繁地分配多筆小額資金，這一過程類似于風險投資。而另一些人則使用這樣一個流程，在這個流程中，獲得授權的產品負責人會使用持續一段時間的資金來交付特定業務成果。
Berez說，這種預算方法“創造了更大的靈活性和敏捷性。”
9. 我的合作伙伴和供應商也不需要敏捷方法
IT領導者通常認為，對自己的團隊和內部流程進行變革將使他們能夠快速，靈活地按照業務部門和市場的要求交付新功能。
但是，這還不夠，Kelker說。他們還必須讓合作伙伴參與進來。
Kelker補充說：“如果你與供應商簽訂的合同只允許瀑布式方法怎么辦?如果你的采購方式是計劃生成運行(plan-build-run)怎么辦?如果你的采購任務不允許使用開發運維怎么辦?”
Kelker說，如果企業的IT團隊不能讓供應商和合作伙伴效仿，那么他們就無法將敏捷方法的收益最大化，直到能讓供應商和合作伙伴效仿，他們才能將敏捷方法的收益最大化。他們Kelker指出，與第三方供應商簽訂的IT合同必須這樣起草——確保各方都在使用敏捷方法以快速交付各種新功能并不斷做出改進，而且付款方式能夠為這一舉措提供支持。
10. 我們實施了敏捷方法，所以我們很棒
West曾向一位高管詢問該公司的Scrum實踐的效用，那時他正在與一家軟件公司合作，其目的是擴展其敏捷實踐。這位高管不屑一顧，稱自己的公司已經采取了這些措施，他認為Scrum的做法(就像公司隨著時間的推移采用的其他敏捷原則一樣)已經落實到位。盡管他的公司在幾次單獨的沖刺之后未能交付產品，但他認為這種思路并沒有什么不妥。
West說：“他們認為敏捷是可以做到并完成的：這個問題顯而易見，但是因為太棘手而沒人理會。他們完全忘記了持續改進這一要點。如果你對此視而不見，如果你沒有制定繼續改進敏捷實踐的計劃，那么你最終一定會遇到問題。”
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號