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

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

[[414421]]

1. 曲解敏捷性的含義

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

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

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

2. 忽視架構(gòu)

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

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

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

3. 選擇Scrum

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

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

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

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

4. 玩蛙跳游戲

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

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

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

這時你可以用到SAFe，即所謂的Scaled Agile Framework(可擴(kuò)展的敏捷框架)。盡管敏捷性的成功是因?yàn)槠浔旧矸椒ê唵危荢AFe卻異常復(fù)雜，有著大量移動部件、潛在的故障點(diǎn)以及對未來的假設(shè)。另外還有一個額外的好處就是沒有人熟悉SAFe。

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

盡管程序必然會失敗，但是你卻可以全身而退，不用承擔(dān)責(zé)任，因?yàn)槟阋呀?jīng)警告過敏捷性不能擴(kuò)展。

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

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

供應(yīng)商的出價必須要有一個固定的價格。這是保持供應(yīng)商誠實(shí)的唯一方法。否則他們就會用一種"不當(dāng)激勵"來拖延項(xiàng)目預(yù)算和進(jìn)度。

如果有供應(yīng)商提出，從一個固定的范圍開始，并通過嚴(yán)格的變更控制來調(diào)整價格，那么管理可以限制敏捷性。這不失為一件好事情，因?yàn)樵诤炇鸸ぷ髡f明之前，你就可以知道與該供應(yīng)商合作的難度。

6. 離岸敏捷

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

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

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

當(dāng)敏捷"團(tuán)隊(duì)"交付模塊時，也沒關(guān)系，即便他們擊中靶子，也是擊中了位于錯誤目標(biāo)中心的靶子。這些模塊的成本確實(shí)是大大降低了，同時IT部門也可以甩鍋給業(yè)務(wù)部門，指責(zé)業(yè)務(wù)部門不清楚他們自己的需求。因?yàn)槊鎸γ娼涣魈?，所以要求不明確。

7. 讓一切都圍繞流程

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

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

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

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

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