誤解

人人都在談敏捷開發(fā)。但真正成功的案例其實(shí)不多，百度上搜“敏捷開發(fā)”，除掉推廣，第一條是“為什么我不推薦敏捷開發(fā)”。令人無語。

對(duì)敏捷開發(fā)存在誤解太多，就以那篇頭條來說，作者其實(shí)只試了皮毛，或者說只看到了粗淺嘗試帶來的惡果，而沒有領(lǐng)會(huì)Agile Development的本質(zhì)。

最大的誤解，就是把敏捷當(dāng)做了便捷，以為有一條捷徑。

首先來自老板，聽說有“敏捷開發(fā)”這樣的好東西，就可以肆無忌憚地壓團(tuán)隊(duì)時(shí)間。

“啊，這個(gè)要這么久才能完成？！為什么你們不采用敏捷開發(fā)呢？”

在這種思維主導(dǎo)下，開發(fā)團(tuán)隊(duì)不管應(yīng)該不應(yīng)該，只能把文檔、性能、安全、交互體驗(yàn)等一時(shí)半會(huì)不爆發(fā)的問題擱置一邊再說。

對(duì)老板來說，敏捷開發(fā)最好的操作手段是daily meeting。因?yàn)槔习逑矚g開會(huì)嘛，每天固定一個(gè)時(shí)間，讓所有團(tuán)隊(duì)成員匯報(bào)進(jìn)度。Daily meeting變成了daily report。

其次來自程序員。

現(xiàn)在的程序員應(yīng)該70%以上不是計(jì)算機(jī)專業(yè)出身吧?；蛟S對(duì)開發(fā)語言很熟，但是缺少系統(tǒng)邏輯思維訓(xùn)練。更重要的是，嚴(yán)重缺乏項(xiàng)目管理/文檔管理的歷練。他們既不知道流程的重要性，也不知道死于流程的局限。對(duì)于敏捷開發(fā)，他們只是抱著一種學(xué)語言的態(tài)度去學(xué)習(xí)敏捷開發(fā)的具體方法，以及避開文檔、流程的小確幸。

所以對(duì)程序員來說，敏捷開發(fā)的“最大好處”是不用寫文檔。（因?yàn)槌绦騿T最討厭寫文檔了，僅次于看別人的代碼而沒有文檔。）

第三種誤解（或者誤導(dǎo)）來自推銷敏捷開發(fā)的培訓(xùn)機(jī)構(gòu)。

在我有限的接觸中發(fā)現(xiàn)，所謂敏捷開發(fā)培訓(xùn)師往往是一些專業(yè)的培訓(xùn)師，而不是產(chǎn)品經(jīng)理或項(xiàng)目經(jīng)理。他們培訓(xùn)敏捷開發(fā)，就像培訓(xùn)OFFICE辦公軟件一樣。對(duì)他們而言，敏捷開發(fā)當(dāng)然是包治百病的靈丹妙藥。他們就是“捷徑”的推銷員，而不是經(jīng)歷過爬坑的真正開發(fā)者。

本質(zhì)

05年我第一次接觸SCRUM。培訓(xùn)老師第一堂課便說，SCRUM is not a silver bullet!敏捷開發(fā)并非萬能。

同期培訓(xùn)的同學(xué)，有很多來自微軟和雅虎，個(gè)個(gè)都是IT精英。和他們聊天時(shí)聽得出來，這些大公司不缺人才，但依然嚴(yán)重困擾于決策流程長，項(xiàng)目周期嚴(yán)重超標(biāo)等問題。

那么敏捷究竟能解決什么問題？

或者反過來看，如果不用敏捷，那么可以采用什么方法呢？那就是傳統(tǒng)的軟件工程啊。其實(shí)這個(gè)問題也經(jīng)常被提到，敏捷開發(fā)VSCMMI。

敏捷和軟件工程都是好東西，適用不同場景。問題的實(shí)質(zhì)是，時(shí)代變了。

在PC時(shí)代，所謂軟件開發(fā)基本是2B。那個(gè)時(shí)候也沒有產(chǎn)品經(jīng)理，而是需求分析師和項(xiàng)目經(jīng)理。軟件收入是靠做項(xiàng)目，或者賣拷貝。這就決定了軟件項(xiàng)目的成功取決于兩點(diǎn)：

• 正確理解客戶需求（或者說服客戶接受現(xiàn)有方案）；~需求分析師
• 用最小的人力成本完成客戶需求；~項(xiàng)目經(jīng)理

CMMI在做的努力，就是想對(duì)某個(gè)領(lǐng)域的知識(shí)進(jìn)行模式化，然后對(duì)這個(gè)領(lǐng)域的不同客戶復(fù)制項(xiàng)目?？蓮?fù)制性和可配置性越好，邊際利潤就越高。在這個(gè)方向上，軟件開發(fā)的高峰是SAP，IBM，Oracle的超級(jí)ERP軟件。在他們所服務(wù)的領(lǐng)域內(nèi)，企業(yè)模式是固定的，至少是相對(duì)固定的。

而這種軟件服務(wù)領(lǐng)域的試錯(cuò)成本非常高，一個(gè)企業(yè)不可能因?yàn)檐浖蛩囟M運(yùn)行或者停運(yùn)。

但是在敏捷開發(fā)時(shí)代，環(huán)境變了。其實(shí)是由于環(huán)境先變了，才使得敏捷開發(fā)有了需要?；ヂ?lián)網(wǎng)帶來了兩個(gè)變化：

首先世界是平的了。軟件的復(fù)制和擴(kuò)散大大加強(qiáng)，信息以前所未有的速度傳播到個(gè)人。以前必須通過企業(yè)再傳遞到個(gè)人的服務(wù)，可以直接為個(gè)人服務(wù)。以前是為出租公司寫調(diào)度系統(tǒng)，現(xiàn)在是為UBER、滴滴寫算法。

其次，世界是個(gè)人的。每個(gè)人都有自己獨(dú)特的需求要求被滿足，每個(gè)人的聲音也可以通過互聯(lián)網(wǎng)傳播。過去只要版本號(hào)一定，你打開WORLD、EXCEL后的界面肯定是一樣的。但今天每個(gè)人每個(gè)時(shí)刻看到的FACEBOOK、微信都是不一樣的。

這兩個(gè)變化導(dǎo)致軟件的高度多樣性和高速演化。過去我們?cè)诒I版市場可以用一張光盤收羅一年的新軟件和新游戲，而現(xiàn)在APPSTORE一天發(fā)布的新應(yīng)用我們都看不過來。張小龍過去也許一年只需要更新Foxmail一次，但微信一個(gè)月就得升級(jí)。

因此，發(fā)現(xiàn)用戶想要什么，比工程師能做什么成為更重要的話題。這也是為什么沃茨尼克雖然在極客心目中仍然地位尊崇，但在商業(yè)社會(huì)上重要性遠(yuǎn)遠(yuǎn)不如喬布斯。

喬布斯因?yàn)閷?duì)產(chǎn)品定位的準(zhǔn)確，成為神一般的存在。也使得產(chǎn)品經(jīng)理這個(gè)崗位得以神話。

而對(duì)一般人來說，如果沒有喬布斯的靈感，那么發(fā)現(xiàn)需求或解決方案的最好辦法就是試錯(cuò)。當(dāng)然，也有很多自詡喬布斯直接下注的。那是在敏捷之外的另外一種誤會(huì)了。

敏捷開發(fā)，就是面向試錯(cuò)而來的。

為什么不要文檔而要看可用的軟件？因?yàn)榭赡苡姓`讀，可能現(xiàn)有文檔規(guī)范限制了表達(dá)，甚至可能在寫文檔的過程中，環(huán)境已經(jīng)變化了；

為什么互動(dòng)重于流程和工具？因?yàn)樗鞋F(xiàn)存的流程和工具都是為解決過去已經(jīng)存在的問題而設(shè)計(jì)的，而不是為正在發(fā)生的問題設(shè)計(jì)的；

為什么和客戶協(xié)商重于合約？因?yàn)榭蛻粢膊恢浪?她要什么，甚至我們都還沒找到嚴(yán)格意義上的“客戶”呢？一個(gè)新產(chǎn)品，即便是“好”的，往往也需要一批潛在客戶去嘗試去體驗(yàn)，發(fā)現(xiàn)最適合的一個(gè)子類人群；

拔高地說，做敏捷開發(fā)要有向死而生的勇氣。如果沒打算重構(gòu)，那么就得好好計(jì)劃。如果要做敏捷開發(fā)，就得做好下一輪重新來過的準(zhǔn)備。

因此對(duì)老板來說，敏捷開發(fā)不見得就會(huì)節(jié)省時(shí)間；但是能更準(zhǔn)確地知道項(xiàng)目成本，或者更早知道產(chǎn)品的問題。

對(duì)程序員來說，敏捷開發(fā)是通過小改來避免大改。用前期的的失敗（試錯(cuò)）來保證最終結(jié)果；而不是順風(fēng)順?biāo)貨_到一個(gè)大坑里。（當(dāng)然，有的程序員不這么想。因?yàn)樾「氖莻€(gè)人麻煩。而大改是整個(gè)項(xiàng)目組甚至公司的事情）

最后說下培訓(xùn)機(jī)構(gòu)?；叵肫饋?，我當(dāng)年的授課老師也是收費(fèi)上課，但他們的商業(yè)模式卻大不相同。授課只是普及概念，他們真正的收入來自親自入駐企業(yè)帶隊(duì)做項(xiàng)目，或者駐場培訓(xùn)SCRUMMSTER。因此無論是是從實(shí)際出發(fā)，還是要給自己留條后路，他們都會(huì)強(qiáng)調(diào)敏捷開發(fā)并非萬能，必須結(jié)合產(chǎn)品/項(xiàng)目/企業(yè)實(shí)際情況而定。

實(shí)踐

前面說的都是虛的，現(xiàn)在來談實(shí)踐。在國內(nèi)國外嘗試過敏捷開發(fā)十多年，每一次嘗試都帶來新的體會(huì)。

作為SCRUM MASTER，面臨三種考驗(yàn)。

第一，當(dāng)然是老板了。

非技術(shù)出身的老板基本上沒有真正了解敏捷開發(fā)的。這沒關(guān)系。接上文，老板關(guān)心的是否能更快交付。我的策略是拿敏捷開發(fā)作為籌碼，和老板談價(jià)還價(jià)。敏捷需要保持開發(fā)團(tuán)隊(duì)的完整，需要跨部門抽調(diào)人員，或者擴(kuò)大產(chǎn)品經(jīng)理/項(xiàng)目經(jīng)理的職權(quán)；敏捷需要保證開發(fā)團(tuán)隊(duì)的專注，至少一個(gè)sprint周期內(nèi)的無干擾；需要讓豬走開，需要和客戶（用戶）直接接觸。這都需要管理層的支持。所以我會(huì)拿更精準(zhǔn)（同時(shí)也必須是更短）的交付計(jì)劃與老板做交換。

然而坦白地說，如果能夠得到完整的團(tuán)隊(duì)和專注的時(shí)間，不采用敏捷也能有更高效的產(chǎn)出。^_^

第二重考驗(yàn)來自團(tuán)隊(duì)。

作為SCRUMMASTER，認(rèn)清自己的團(tuán)隊(duì)成員也許比做需求分析更重要。

團(tuán)隊(duì)成員中有的可能并不能完全勝任自己工作，按照標(biāo)準(zhǔn)SCURM模型這是不能接受的！但現(xiàn)實(shí)往往如此，不管大公司小公司都會(huì)遇到人員短缺的問題。

團(tuán)隊(duì)成員有的來自其他部門，他只是想做豬而不是雞。

團(tuán)隊(duì)成員有的曾經(jīng)聽說過敏捷開發(fā)，因此非常急切地想嘗鮮，甚至主動(dòng)推薦某種協(xié)同工具。

團(tuán)隊(duì)成員有的曾經(jīng)經(jīng)歷過“敏捷開發(fā)”并且有著糟糕的體驗(yàn)，比如上文提到的作者。他對(duì)這一套有著非常強(qiáng)烈的抵觸情緒。

但最危險(xiǎn)的不是他們，而是團(tuán)隊(duì)中的技術(shù)大牛。

對(duì)的，就是技術(shù)強(qiáng)責(zé)任心重勤勤懇懇還特別愿意幫助新同事的大牛同學(xué)。

在項(xiàng)目KICKOFF會(huì)議上，大牛同學(xué)想好了項(xiàng)目實(shí)施方案，準(zhǔn)備嘗試新的技術(shù)框架；大牛同學(xué)愿意教小白兔怎么使用；小豬同學(xué)來不及做的部分，大牛同學(xué)也準(zhǔn)備接過去；其他同學(xué)也因?yàn)榇笈５拇嬖?，而?duì)項(xiàng)目增添了信心。

然后在第一個(gè)SPRINT周期的末尾，大牛同學(xué)通宵加班，并建議將這輪迭代延長兩周，這會(huì)保證新框架可以穩(wěn)定上線并且提供十倍的靈活性和二十倍的穩(wěn)定性。

如果你同意了，苦逼之旅就開始了。大牛同學(xué)最終花了三周時(shí)間完成了新框架，但是除了底層模塊，前端功能什么也沒有。老板在等了一個(gè)月之后急著要看DEMO，如果這個(gè)項(xiàng)目有問題，那么小豬同學(xué)就回他自己部門了。而大牛和小白兔已經(jīng)幾天沒合眼了…

敏捷就是面向試錯(cuò)，所以敏捷開發(fā)要竭力避免開發(fā)過程中的完美主義，而要保證穩(wěn)定持續(xù)的結(jié)果輸出，從結(jié)果反饋尋求答案。團(tuán)隊(duì)中的技術(shù)大牛是最容易走入技術(shù)導(dǎo)向誤區(qū)的人，同時(shí)他也最容易影響他人。

那么要不要嘗試新技術(shù)新框架呢？當(dāng)然可以。但是程序員必須具備有限優(yōu)化的能力，在一個(gè)迭代周期內(nèi)進(jìn)行小范圍的嘗試。項(xiàng)目本身不應(yīng)該是新技術(shù)的試驗(yàn)田。

對(duì)于其他同學(xué)的問題，很多時(shí)候我并沒有告知他們這是一個(gè)敏捷開發(fā)過程。只是通知他們按階段交付結(jié)果，結(jié)果最重要，文檔、會(huì)議、協(xié)同工具都是手段而已。如果他們喜歡DailyMeeting，那么就開；如果他們喜歡用Worktile，那么就用。SCRUMMASTER可以推薦工具，但不強(qiáng)制實(shí)行。只有當(dāng)團(tuán)隊(duì)自身發(fā)現(xiàn)這個(gè)工具有利于他們更好地交付結(jié)果，他們才會(huì)真正地去使用這些工具。

另外一些最基本的經(jīng)驗(yàn)：

• 盡可能保持人員穩(wěn)定；
• 盡快排除情緒不穩(wěn)定的成員；
• 在一起辦公；
• 不超過十個(gè)人；

最大的考驗(yàn)，嗯，來自于…SCRUMMASTER自己。

換句話說，在這個(gè)項(xiàng)目團(tuán)隊(duì)中，SCRUMMASTER究竟是怎么樣的一種存在呢？

對(duì)一個(gè)沒接觸過敏捷開發(fā)的團(tuán)隊(duì)成員來說，經(jīng)典的SCRUMMASTER是一個(gè)完全不參與實(shí)際項(xiàng)目開發(fā)，只是做做思想工作的精神鼓勵(lì)師啊。

但其實(shí)對(duì)老板，對(duì)團(tuán)隊(duì)來說，你才是那個(gè)OWNER。

如果每個(gè)項(xiàng)目成員都很牛逼地勝任本職工作，并且充分理解敏捷開發(fā)的精神，SCRUM MASTER的確可以抽象化了，或者就由某個(gè)軟件替代了。但其實(shí)這個(gè)角色才是最無法抽象或者被替代的。

在我的實(shí)踐經(jīng)驗(yàn)中，我的角色就是產(chǎn)品經(jīng)理+項(xiàng)目經(jīng)理，也就是這個(gè)項(xiàng)目的OWNER。只有這樣，才能有話語權(quán)向老板爭取資源，才能有權(quán)威克制大牛的技術(shù)沖動(dòng)，對(duì)抗外部干擾。

但這樣又很容易走向一言堂，破壞敏捷開發(fā)所提倡的主動(dòng)性和平等性。用來平衡的手段，是讓團(tuán)隊(duì)更多接觸用戶，通過用戶反饋?zhàn)寛F(tuán)隊(duì)意識(shí)到“我的工作對(duì)用戶的影響”，而不是為了取悅項(xiàng)目OWNER。

對(duì)于像我這樣研發(fā)出身的SCRUM MASTER，還有一重風(fēng)險(xiǎn)：技術(shù)的詛咒。

雖然技術(shù)背景對(duì)于項(xiàng)目開發(fā)周期和BUG風(fēng)險(xiǎn)有更好的理解和判斷，但是技術(shù)背景會(huì)使得SCRUM MASTER忍不住參與到技術(shù)實(shí)現(xiàn)中去。

個(gè)人最失敗的一個(gè)案例：當(dāng)時(shí)有三個(gè)并行的項(xiàng)目需要管理，偏偏是我參與最多的項(xiàng)目進(jìn)展最不順利。項(xiàng)目瓶頸在于后臺(tái)數(shù)據(jù)庫設(shè)計(jì)進(jìn)度太慢，導(dǎo)致前端無法開始聯(lián)調(diào)。由于我熟悉數(shù)據(jù)庫設(shè)計(jì)，因此有時(shí)直接上陣開發(fā)。

直到某天我在敲代碼的時(shí)候，忽然看到本該做此工作的DBA眼神呆滯，茫然地坐在一邊；才突然醒悟自己的越俎代庖。其實(shí)數(shù)據(jù)庫設(shè)計(jì)慢的原因，是作為前開發(fā)人員的我，認(rèn)為設(shè)計(jì)不夠“美”，而作為OWNER的我，應(yīng)該把開發(fā)的權(quán)力還給DBA，而只從實(shí)際輸出結(jié)果評(píng)估是否可以交付。

SCRUM MASTER必須時(shí)刻考慮大局，放下自己的技術(shù)偏好。SCRUM MASTER需要根據(jù)實(shí)際任務(wù)情況和成員情況，盡可能地組織出一只團(tuán)隊(duì)不斷交付。前面說到每個(gè)項(xiàng)目都有新體驗(yàn)，就是說項(xiàng)目本身可能相似，但總會(huì)遇到不同背景不同性格的程序員們，看他們是怎么理解怎么執(zhí)行敏捷開發(fā)的。

SCRUM MASTER不寫代碼，但通過調(diào)動(dòng)程序員完成一個(gè)產(chǎn)品，從某種意義上說，這是另一種形態(tài)的編程呢。

本文由 @ 狄也傲 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。