人們對敏捷性的關(guān)注由來已久，關(guān)于敏捷性的報(bào)道十年前就已經(jīng)出現(xiàn)在新聞當(dāng)中。《敏捷宣言》也已經(jīng)發(fā)布了近二十年時(shí)間，我們中的許多人早在宣言正式發(fā)布之前就開始學(xué)習(xí)和嘗試敏捷技術(shù)了。
由于敏捷的成功率和業(yè)務(wù)滿意度都很高，這引起了一些抵制者的恐慌。為此，他們?nèi)ψ柚蛊髽I(yè)向敏捷性轉(zhuǎn)型。如果你是他們中的一員，同時(shí)也面臨著"向敏捷性轉(zhuǎn)型"的壓力，那么你現(xiàn)在應(yīng)該采取行動(dòng)，不能像因小行星撞擊地球而滅亡的恐龍那樣坐以待斃。以下這七種方法不僅行之有效，而且還可以幫助你在IT部門中"阻止"敏捷性的實(shí)現(xiàn)，同時(shí)又不會(huì)讓你在公司、中名聲掃地。
01
曲解敏捷性的含義
當(dāng)啟動(dòng)下一個(gè)項(xiàng)目時(shí)，你應(yīng)堅(jiān)持讓項(xiàng)目經(jīng)理以"敏捷的方式"運(yùn)行它們，同時(shí)讓團(tuán)隊(duì)中的所有人每天早上都要弄清楚他們當(dāng)天能做些什么，以便讓項(xiàng)目朝著他們認(rèn)為的方向發(fā)展。
當(dāng)團(tuán)隊(duì)準(zhǔn)備測試一個(gè)功能時(shí)，你可以今天就讓產(chǎn)品負(fù)責(zé)人知道：你明天就需要業(yè)務(wù)人員來測試這個(gè)功能。如果明天沒空，沒關(guān)系。這只意味著該功能將不得不調(diào)整至下一個(gè)迭代周期。
如果產(chǎn)品負(fù)責(zé)人抱怨項(xiàng)目沒有按時(shí)完成，那么，這剛好正中下懷，你可以借機(jī)解釋一下"敏捷項(xiàng)目"沒有時(shí)間表。敏捷性就是意味著"沒有計(jì)劃"，難道不是嗎？
02
忽視架構(gòu)
不要在定義應(yīng)用程序架構(gòu)的項(xiàng)目上過早地浪費(fèi)時(shí)間。如果敏捷性意味著需求不斷演化，那么應(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ā)，那么剛好，容器不就是用來解決這個(gè)問題的嗎？
03
選擇Scrum
敏捷性不是一種方法論，而是一系列方法論，每一種都適用于不同類型的項(xiàng)目。Scrum之所以非常受歡迎，并不是因?yàn)樗鼈兪?最佳實(shí)踐"，而是因?yàn)樗鼈兪墙Y(jié)構(gòu)嚴(yán)謹(jǐn)?shù)拿艚葑凅w，比其他任何產(chǎn)品更接近舒適區(qū)。（注：Scrum是橄欖球運(yùn)動(dòng)的專業(yè)術(shù)語，表示"爭球"的動(dòng)作；把一個(gè)開發(fā)流程取名為Scrum，就是讓開發(fā)團(tuán)隊(duì)在開發(fā)項(xiàng)目時(shí)像打橄欖球一樣迅速、富有戰(zhàn)斗激情、人人你爭我搶地去完成它們。Scrum就是這樣的一個(gè)開發(fā)流程。）
Scrum不太適合COTS（現(xiàn)成的商業(yè)軟件）和SaaS（軟件即服務(wù)）的部署，而IT部門所承擔(dān)的大多數(shù)項(xiàng)目都含有COTS和SaaS。不同的敏捷變體、會(huì)議室試點(diǎn)（CRP）或與其密切相關(guān)的ATTD（驗(yàn)收測試驅(qū)動(dòng)開發(fā)）是更好的選擇。
但是誰聽說過它們？很可能沒人在乎。即使你的最強(qiáng)大的政治對手也不會(huì)批評你選擇了最流行的敏捷變體，即使他們知道還有其他敏捷變體可供選擇，也不會(huì)批評你。
因此，當(dāng)由Scrum驅(qū)動(dòng)的COTS部署出現(xiàn)了問題，即使你清楚這一結(jié)果，也不會(huì)有人質(zhì)疑。如果有人質(zhì)疑，你可以說項(xiàng)目失敗了，因?yàn)槊艚輳囊婚_始就不是一個(gè)好主意，而且你可以安全地暗示，任何提出不同意見的人都是在推卸責(zé)任。
04
玩蛙跳游戲
敏捷性的魅力和最大的優(yōu)點(diǎn)在于它的簡單性，最大的缺點(diǎn)是缺乏良好的擴(kuò)展性。
明智的業(yè)務(wù)部門會(huì)讓敏捷性保持敏捷，為此他們會(huì)拓展敏捷的原則，將軟件部署和所有業(yè)務(wù)變化都包含進(jìn)去。從這個(gè)角度看，大規(guī)模戰(zhàn)略計(jì)劃本質(zhì)上是瀑布式的，其失敗的原因與瀑布式項(xiàng)目失敗的原因相同：它們是線性的，有很多相互依賴性和潛在的單點(diǎn)故障。另外，它們建立在對未來的假設(shè)之上，當(dāng)未來到來時(shí)，這些假設(shè)至少會(huì)改變兩次。
但是你不要在意這些。CIO的工作不是讓業(yè)務(wù)更加靈活，而是為了支持商業(yè)戰(zhàn)略，不管戰(zhàn)略是否有任何實(shí)際運(yùn)作的機(jī)會(huì)。由于敏捷性不能擴(kuò)展到戰(zhàn)略級(jí)計(jì)劃，因此IT部門需要采用一種聽起來像敏捷性但是擴(kuò)展起來像瀑布一樣的方法。
這時(shí)你可以用到SAFe，即所謂的Scaled Agile Framework（可擴(kuò)展的敏捷框架）。盡管敏捷性的成功是因?yàn)槠浔旧矸椒ê唵?，但是SAFe卻異常復(fù)雜，有著大量移動(dòng)部件、潛在的故障點(diǎn)以及對未來的假設(shè)。另外還有一個(gè)額外的好處就是沒有人熟悉SAFe。
SAFe本身沒有問題，但是需要有經(jīng)驗(yàn)的從業(yè)者和相當(dāng)多的程序基礎(chǔ)設(shè)施。如果業(yè)務(wù)部門需要SAFe，那么IT部門就要部署SAFe。從瀑布式轉(zhuǎn)向SAFe本身就存在鴻溝和風(fēng)險(xiǎn)。
盡管程序必然會(huì)失敗，但是你卻可以全身而退，不用承擔(dān)責(zé)任，因?yàn)槟阋呀?jīng)警告過敏捷性不能擴(kuò)展。
05
堅(jiān)持讓開發(fā)伙伴使用敏捷性，同時(shí)堅(jiān)持讓他們同意固定價(jià)格的投標(biāo)
當(dāng)然，他們必須使用敏捷。非常好，不是嗎？此外，你還需要教會(huì)業(yè)務(wù)部門中的每名經(jīng)理如何以敏捷方式與IT部門協(xié)同工作。
供應(yīng)商的出價(jià)必須要有一個(gè)固定的價(jià)格。這是保持供應(yīng)商誠實(shí)的唯一方法。否則他們就會(huì)用一種"不當(dāng)激勵(lì)"來拖延項(xiàng)目預(yù)算和進(jìn)度。
如果有供應(yīng)商提出，從一個(gè)固定的范圍開始，并通過嚴(yán)格的變更控制來調(diào)整價(jià)格，那么管理可以限制敏捷性。這不失為一件好事情，因?yàn)樵诤炇鸸ぷ髡f明之前，你就可以知道與該供應(yīng)商合作的難度。
06
離岸敏捷
從理論上講，業(yè)務(wù)規(guī)劃師會(huì)為收入、成本、風(fēng)險(xiǎn)和業(yè)務(wù)成績設(shè)定目標(biāo)。但是實(shí)際上，在大多數(shù)業(yè)務(wù)部門中，批準(zhǔn)實(shí)際執(zhí)行的項(xiàng)目都是降低成本的項(xiàng)目。
從為開發(fā)者工作支付的費(fèi)用開始設(shè)置障礙，與此相比，還有什么會(huì)更合適呢？因此，當(dāng)與開發(fā)合作伙伴合作時(shí)，你要確保其大多數(shù)團(tuán)隊(duì)成員在11個(gè)時(shí)區(qū)之外生活和工作。
敏捷原則的第6條強(qiáng)調(diào)了開發(fā)人員之間以及開發(fā)人員和業(yè)務(wù)用戶之間面對面交談的重要性。有了時(shí)差，海外開發(fā)者自然不會(huì)參與。沒關(guān)系。你也不用理會(huì)這條。這只是理論。在節(jié)約資金和抽象原則之間做出選擇，那些想節(jié)約資金的人自然會(huì)站在你這邊。
當(dāng)敏捷"團(tuán)隊(duì)"交付模塊時(shí)，也沒關(guān)系，即便他們擊中靶子，也是擊中了位于錯(cuò)誤目標(biāo)中心的靶子。這些模塊的成本確實(shí)是大大降低了，同時(shí)IT部門也可以甩鍋給業(yè)務(wù)部門，指責(zé)業(yè)務(wù)部門不清楚他們自己的需求。因?yàn)槊鎸γ娼涣魈?，所以要求不明確。
07
讓一切都圍繞流程
是的，我們都知道敏捷宣言鼓勵(lì)"個(gè)人和交互勝過流程和工具"。但如果說管理層在過去幾十年里學(xué)到了一件事的話，那就是業(yè)務(wù)的成功取決于建立定義良好的可重復(fù)流程。成功不是來自人際關(guān)系，也不是通過員工合作找出更好的解決方案。成功來自于員工遵循流程，按照規(guī)定按部就班的一步一步來。
每個(gè)流程設(shè)計(jì)師都知道，一個(gè)好的流程不應(yīng)該有漏洞。由你來決定你的敏捷流程，就像所有其他優(yōu)秀流程一樣，描述了流程是如何從一個(gè)環(huán)節(jié)到另一個(gè)環(huán)節(jié)，每個(gè)決策點(diǎn)都被描述為一個(gè)過程分支，而每個(gè)參與者都將他們的輸入轉(zhuǎn)化為輸出，成為下一個(gè)員工的輸入。
為敏捷流程添加足夠的復(fù)雜性，最終IT部門可以擴(kuò)展EPMO的項(xiàng)目管理流程執(zhí)行的范圍，以便他們能夠密切關(guān)注敏捷教練，就像他們一直讓你的瀑布式項(xiàng)目經(jīng)理保持一致一樣。
如果你覺得這里列出的七個(gè)策略沒有吸引力，那么你還有一個(gè)選擇。
你可以向不可避免的事情屈服。你可以承認(rèn)敏捷確實(shí)比瀑布式開發(fā)更有效，并且真心嘗試一下。這可能會(huì)很痛，但是你可以這樣想：膝關(guān)節(jié)置換手術(shù)也會(huì)痛。但從長遠(yuǎn)來看，回避比讓它發(fā)生的傷害性更大。
作者：本文作者Bob Lewis為一家大型全球IT服務(wù)公司的高級(jí)管理人員兼IT顧問。
原文網(wǎng)址：https://www.cio.com/article/3604372/7-ways-to-sabotage-your-shift-to-agile.html
編譯：陳琳華
