人們對敏捷性的關注由來已久，關于敏捷性的報道十年前就已經(jīng)出現(xiàn)在新聞當中?！睹艚菪浴芬惨呀?jīng)發(fā)布了近二十年時間，我們中的許多人早在宣言正式發(fā)布之前就開始學習和嘗試敏捷技術了。

由于敏捷的成功率和業(yè)務滿意度都很高，這引起了一些抵制者的恐慌。為此，他們?nèi)ψ柚蛊髽I(yè)向敏捷性轉(zhuǎn)型。如果你是他們中的一員，同時也面臨著"向敏捷性轉(zhuǎn)型"的壓力，那么你現(xiàn)在應該采取行動，不能像因小行星撞擊地球而滅亡的恐龍那樣坐以待斃。以下這七種方法不僅行之有效，而且還可以幫助你在IT部門中"阻止"敏捷性的實現(xiàn)，同時又不會讓你在公司、中名聲掃地。

[[414421]]

1. 曲解敏捷性的含義

當啟動下一個項目時，你應堅持讓項目經(jīng)理以"敏捷的方式"運行它們，同時讓團隊中的所有人每天早上都要弄清楚他們當天能做些什么，以便讓項目朝著他們認為的方向發(fā)展。

當團隊準備測試一個功能時，你可以今天就讓產(chǎn)品負責人知道：你明天就需要業(yè)務人員來測試這個功能。如果明天沒空，沒關系。這只意味著該功能將不得不調(diào)整至下一個迭代周期。

如果產(chǎn)品負責人抱怨項目沒有按時完成，那么，這剛好正中下懷，你可以借機解釋一下"敏捷項目"沒有時間表。敏捷性就是意味著"沒有計劃"，難道不是嗎?

2. 忽視架構(gòu)

不要在定義應用程序架構(gòu)的項目上過早地浪費時間。如果敏捷性意味著需求不斷演化，那么應用程序架構(gòu)不也應該不斷演化嗎?

因此，不要通過堅持遵從一大堆的抽象原則來限制開發(fā)人員的創(chuàng)造力。相反，你要授權開發(fā)人員，讓他們按照自己想要的方式開發(fā)，按照他們自己喜歡的方式構(gòu)建模塊和接口。如果來自不同開發(fā)人員的不同模塊不能在一起即插即用，或者不同開發(fā)人員編寫的代碼依賴于不同的庫，那么你也不用擔心。這正是重構(gòu)的意義所在。

如果不同的開發(fā)人員想用不同的語言開發(fā)，那么剛好，容器不就是用來解決這個問題的嗎?

3. 選擇Scrum

敏捷性不是一種方法論，而是一系列方法論，每一種都適用于不同類型的項目。Scrum之所以非常受歡迎，并不是因為它們是"最佳實踐"，而是因為它們是結(jié)構(gòu)嚴謹?shù)拿艚葑凅w，比其他任何產(chǎn)品更接近舒適區(qū)。(注：Scrum是橄欖球運動的專業(yè)術語，表示"爭球"的動作;把一個開發(fā)流程取名為Scrum，就是讓開發(fā)團隊在開發(fā)項目時像打橄欖球一樣迅速、富有戰(zhàn)斗激情、人人你爭我搶地去完成它們。Scrum就是這樣的一個開發(fā)流程。)

Scrum不太適合COTS(現(xiàn)成的商業(yè)軟件)和SaaS(軟件即服務)的部署，而IT部門所承擔的大多數(shù)項目都含有COTS和SaaS。不同的敏捷變體、會議室試點(CRP)或與其密切相關的ATTD(驗收測試驅(qū)動開發(fā))是更好的選擇。

但是誰聽說過它們?很可能沒人在乎。即使你的最強大的政治對手也不會批評你選擇了最流行的敏捷變體，即使他們知道還有其他敏捷變體可供選擇，也不會批評你。

因此，當由Scrum驅(qū)動的COTS部署出現(xiàn)了問題，即使你清楚這一結(jié)果，也不會有人質(zhì)疑。如果有人質(zhì)疑，你可以說項目失敗了，因為敏捷從一開始就不是一個好主意，而且你可以安全地暗示，任何提出不同意見的人都是在推卸責任。

4. 玩蛙跳游戲

敏捷性的魅力和最大的優(yōu)點在于它的簡單性，最大的缺點是缺乏良好的擴展性。

明智的業(yè)務部門會讓敏捷性保持敏捷，為此他們會拓展敏捷的原則，將軟件部署和所有業(yè)務變化都包含進去。從這個角度看，大規(guī)模戰(zhàn)略計劃本質(zhì)上是瀑布式的，其失敗的原因與瀑布式項目失敗的原因相同：它們是線性的，有很多相互依賴性和潛在的單點故障。另外，它們建立在對未來的假設之上，當未來到來時，這些假設至少會改變兩次。

但是你不要在意這些。CIO的工作不是讓業(yè)務更加靈活，而是為了支持商業(yè)戰(zhàn)略，不管戰(zhàn)略是否有任何實際運作的機會。由于敏捷性不能擴展到戰(zhàn)略級計劃，因此IT部門需要采用一種聽起來像敏捷性但是擴展起來像瀑布一樣的方法。

這時你可以用到SAFe，即所謂的Scaled Agile Framework(可擴展的敏捷框架)。盡管敏捷性的成功是因為其本身方法簡單，但是SAFe卻異常復雜，有著大量移動部件、潛在的故障點以及對未來的假設。另外還有一個額外的好處就是沒有人熟悉SAFe。

SAFe 本身沒有問題，但是需要有經(jīng)驗的從業(yè)者和相當多的程序基礎設施。如果業(yè)務部門需要SAFe ，那么IT部門就要部署SAFe。從瀑布式轉(zhuǎn)向SAFe本身就存在鴻溝和風險。

盡管程序必然會失敗，但是你卻可以全身而退，不用承擔責任，因為你已經(jīng)警告過敏捷性不能擴展。

5. 堅持讓開發(fā)伙伴使用敏捷性，同時堅持讓他們同意固定價格的投標

當然，他們必須使用敏捷。非常好，不是嗎?此外，你還需要教會業(yè)務部門中的每名經(jīng)理如何以敏捷方式與IT部門協(xié)同工作。

供應商的出價必須要有一個固定的價格。這是保持供應商誠實的唯一方法。否則他們就會用一種"不當激勵"來拖延項目預算和進度。

如果有供應商提出，從一個固定的范圍開始，并通過嚴格的變更控制來調(diào)整價格，那么管理可以限制敏捷性。這不失為一件好事情，因為在簽署工作說明之前，你就可以知道與該供應商合作的難度。

6. 離岸敏捷

從理論上講，業(yè)務規(guī)劃師會為收入、成本、風險和業(yè)務成績設定目標。但是實際上，在大多數(shù)業(yè)務部門中，批準實際執(zhí)行的項目都是降低成本的項目。

從為開發(fā)者工作支付的費用開始設置障礙，與此相比，還有什么會更合適呢?因此，當與開發(fā)合作伙伴合作時，你要確保其大多數(shù)團隊成員在11個時區(qū)之外生活和工作。

敏捷原則的第6條強調(diào)了開發(fā)人員之間以及開發(fā)人員和業(yè)務用戶之間面對面交談的重要性。有了時差，海外開發(fā)者自然不會參與。沒關系。你也不用理會這條。這只是理論。在節(jié)約資金和抽象原則之間做出選擇，那些想節(jié)約資金的人自然會站在你這邊。

當敏捷"團隊"交付模塊時，也沒關系，即便他們擊中靶子，也是擊中了位于錯誤目標中心的靶子。這些模塊的成本確實是大大降低了，同時IT部門也可以甩鍋給業(yè)務部門，指責業(yè)務部門不清楚他們自己的需求。因為面對面交流太少，所以要求不明確。

7. 讓一切都圍繞流程

是的，我們都知道敏捷宣言鼓勵"個人和交互勝過流程和工具"。但如果說管理層在過去幾十年里學到了一件事的話，那就是業(yè)務的成功取決于建立定義良好的可重復流程。成功不是來自人際關系，也不是通過員工合作找出更好的解決方案。成功來自于員工遵循流程，按照規(guī)定按部就班的一步一步來。

每個流程設計師都知道，一個好的流程不應該有漏洞。由你來決定你的敏捷流程，就像所有其他優(yōu)秀流程一樣，描述了流程是如何從一個環(huán)節(jié)到另一個環(huán)節(jié)，每個決策點都被描述為一個過程分支，而每個參與者都將他們的輸入轉(zhuǎn)化為輸出，成為下一個員工的輸入。

為敏捷流程添加足夠的復雜性，最終IT部門可以擴展EPMO的項目管理流程執(zhí)行的范圍，以便他們能夠密切關注敏捷教練，就像他們一直讓你的瀑布式項目經(jīng)理保持一致一樣。

如果你覺得這里列出的七個策略沒有吸引力，那么你還有一個選擇。

你可以向不可避免的事情屈服。你可以承認敏捷確實比瀑布式開發(fā)更有效，并且真心嘗試一下。這可能會很痛，但是你可以這樣想：膝關節(jié)置換手術也會痛。但從長遠來看，回避比讓它發(fā)生的傷害性更大。