寫在前面
- 這是一個在2016年舉行的2015敏捷之旅。
- 我第一次去，活動地點(diǎn)不好找。出地鐵站碰到一位急匆匆的妹子在問路，不好意思把她當(dāng)成了人工GPS，她在前面小跑問路，我在后面跟著。我本來想邀請她一起找路的，奈何妹子跑得太快，又素不相識，沒好意思攔截。
- 時間不夠。幾乎每場都是超時的，尤其第一場，大概講了一半就草草結(jié)束。
- 主講的都是專家，本身挺有料的，但每個人演講水平不一樣，或者對聽眾需求把握不夠準(zhǔn)確，在演講過程中，大廳的留言直播小屏里竟然出現(xiàn)了吐槽，什么“要干貨不要忽悠、不知道在講什么”之類。不知道專家有沒有看到這些負(fù)面反饋。我想如果我是演講者，在臺上面對屏幕看到現(xiàn)場這樣的批評，估計舌頭都要打結(jié)了。還有吐槽主持人水平不行的。主持人是小姑娘，好像是志愿者來的，只是串場介紹嘉賓，不知道那些高要求的吐槽帝是怎么想的。
下圖是主會場流程，下午另外開有兩個分會場。我一直呆在主會場，一天下來，暈乎乎的，腦容量不夠用的感覺（可能是聽的太專注，腦子缺氧）。
進(jìn)入正題
有一段很有哲理的話大概是這樣：一本書、一場電影很精彩，看完以后，過了很長時間，我們無法記得全部，但如果仍有一句話一段臺詞深深打動了你，改變了你的想法，那就是那本書或電影帶給你最大的收獲。
對于講座來說也是一樣，我無法記得所有內(nèi)容，但每一場我至少收獲了一個關(guān)鍵詞，而且每一個關(guān)鍵詞的后面都有大段我對它的消化。
第一場，關(guān)鍵詞：5 Why分析法
蘇于登講了一個他如何用敏捷方法使一個銀行項(xiàng)目起死回生、最后大家升職加薪皆大歡喜的案例。我印象很深的是使用5 Why分析法診斷當(dāng)前項(xiàng)目流程中存在的問題。
首先，把當(dāng)前項(xiàng)目從需求到上線所經(jīng)歷的所有流程步驟可視化，并劃分出問題的界限，即我們有權(quán)限改造的范圍在哪里。如下圖，如果軟件中心是我們改造的范圍，那我們只針對軟件中心的流程做診斷。
其次，把每個流程步驟所在進(jìn)行的工作內(nèi)容可視化。如下圖，可以借助工具以看板的形式列出工作內(nèi)容。
審查每個流程步驟、每項(xiàng)工作內(nèi)容，找出異常及問題所在。如下圖，看上去是“項(xiàng)目經(jīng)理確認(rèn)”的環(huán)節(jié)出了問題，項(xiàng)目經(jīng)理前面的開發(fā)環(huán)節(jié)，一大堆任務(wù)在處理中，而項(xiàng)目經(jīng)理好像無事可干。
最后，用5 Why分析法探詢問題本質(zhì)，從最表層的問題問起，抽絲剝繭，最多5次發(fā)問，找出問題產(chǎn)生的根本原因。
一個產(chǎn)品或一個項(xiàng)目的開發(fā)運(yùn)營，需要需求、設(shè)計、開發(fā)、測試、運(yùn)維各環(huán)節(jié)的團(tuán)隊(duì)成員配合，當(dāng)問題出現(xiàn)時，到底是自己的原因、他人的原因、工具的原因還是協(xié)作的原因，每個人從自己的角度好像都可以找到合理的解釋，爭論下去甚至?xí)l(fā)展到推卸責(zé)任、互相指責(zé)的地步，這個時候糾結(jié)于個人立場的表述無異于霧里看花。作為團(tuán)隊(duì)leader應(yīng)當(dāng)保持清醒的頭腦、理智的分析，而5 Why分析法就是一個引導(dǎo)團(tuán)隊(duì)找出問題產(chǎn)生的根本原因的好方法。
這里還有一段小插曲?；顒咏Y(jié)束后第二天，大會微信群里有一個朋友現(xiàn)學(xué)現(xiàn)用，按上述方法，對他正在進(jìn)行的一個項(xiàng)目的流程及內(nèi)容作做了可視化，果然發(fā)現(xiàn)很多坑。 在大家的鼓勵下，他發(fā)問了N個Why，層層分析，最后絕望的發(fā)現(xiàn)是組織結(jié)構(gòu)、公司體制的問題。
這個時候怎么辦？
我想為什么是5 Why，而不是6 Why、7 Why、N Why，是有一定道理的。除了5個Why足夠找出原因外，另外，5次發(fā)問它在一定程度上限定了提問者的天花板，即有限次數(shù)的提問可以把問題的解決限定在提問者力所能及的范圍內(nèi)。問太多，發(fā)現(xiàn)是公司的問題、老板的問題，不是沒有意義，但可能不是在提問者有能力和權(quán)限去解決的層面上。如果我是那位朋友，我會把我的發(fā)現(xiàn)報告給我的直屬領(lǐng)導(dǎo)，但不要期望或消極等待上級、老板去解決問題，我會在我的5 Why范圍內(nèi)投入我能推動的資源去解決我所在層面的問題。
第二場，關(guān)鍵詞：Feature team
潘瑞英來自騰訊，她介紹了騰訊開發(fā)團(tuán)隊(duì)采用的一種敏捷組織模式：特性團(tuán)隊(duì)（feature team）。
特性團(tuán)隊(duì)要求團(tuán)隊(duì)圍繞軟件或產(chǎn)品的某項(xiàng)可交付的端對端的特性來組織開發(fā)，團(tuán)隊(duì)成員的構(gòu)成是跨職能的，而且是長期的穩(wěn)定的組織結(jié)構(gòu)。舉例，一個做網(wǎng)站開發(fā)的特性團(tuán)隊(duì)，開發(fā)、測試、運(yùn)維、數(shù)據(jù)庫管理員都在同一個團(tuán)隊(duì)里。相對于職能團(tuán)隊(duì)或組件團(tuán)隊(duì)來說，特性團(tuán)隊(duì)的成員協(xié)作更緊密，溝通更順暢，它直接面對“客戶”（特性的使用者，有可能是使用產(chǎn)品的客戶或者其他接口團(tuán)隊(duì)），它快速高效地響應(yīng)客戶、市場、行情的需要。
騰訊的產(chǎn)品如QQ瀏覽器、微信安卓版等就是按這種模式組織開發(fā)的，他們把同一個產(chǎn)品內(nèi)上百人的開發(fā)團(tuán)隊(duì)按產(chǎn)品特性拆分成多個每個約15人左右的特性團(tuán)隊(duì)，每個小團(tuán)隊(duì)針對特性進(jìn)行快速迭代，每次的迭代周期完成后，再合并回主版本。
潘老師是從騰訊大產(chǎn)品的角度來介紹特性團(tuán)隊(duì)，對于創(chuàng)業(yè)公司小團(tuán)隊(duì)而言，如果引入敏捷開發(fā)，其實(shí)開發(fā)團(tuán)隊(duì)的構(gòu)成天然是特性團(tuán)隊(duì)的模式，而團(tuán)隊(duì)針對的所謂“特性”其實(shí)就是整個產(chǎn)品。
第三場，關(guān)鍵詞：扁平化組織
莫敏介紹了敏捷在騰訊游戲開發(fā)中的應(yīng)用。其中一項(xiàng)講到了他們團(tuán)隊(duì)中的扁平化組織結(jié)構(gòu)，我印象比較深刻。
一個騰訊游戲開發(fā)團(tuán)隊(duì)的扁平化組織結(jié)構(gòu)大概如下圖。
可以看到大家都是靠技能吃飯。我在公司跟團(tuán)隊(duì)開會做分享的時候，提到了全棧工程師，多技能學(xué)習(xí)的問題，其中一個同事隨口說了一句：到最后都轉(zhuǎn)管理了，哪還學(xué)那么多技能啊。我用這張圖反駁他說，互聯(lián)網(wǎng)公司，無論大到像騰訊，還是小到剛成立五個指頭可以數(shù)完人的創(chuàng)業(yè)公司，在扁平化的組織結(jié)構(gòu)（開發(fā)團(tuán)隊(duì)）里沒有職業(yè)經(jīng)理人的角色，尤其是在敏捷團(tuán)隊(duì)中，為了應(yīng)對快速變化的需求、縮短開發(fā)周期、提高推出頻率，大的團(tuán)隊(duì)要拆分成小團(tuán)隊(duì)（當(dāng)然不是絕對，但如果要選擇比較好的實(shí)踐的話，這是推薦的做法），在這種小團(tuán)隊(duì)中，沒有職能經(jīng)理發(fā)號施令的空間，相反的，全?；虬肴珬碛卸囗?xiàng)技能的開發(fā)工程師更為吃香。
現(xiàn)在常常提到互聯(lián)網(wǎng)思維對傳統(tǒng)企業(yè)的沖擊，這是很實(shí)際的一個問題，互聯(lián)網(wǎng)公司、敏捷團(tuán)隊(duì)的扁平化組織結(jié)構(gòu)對于傳統(tǒng)企業(yè)來說是一項(xiàng)必須直面的挑戰(zhàn)。
第四場，關(guān)鍵詞：敏捷是一種文化
李小波是深圳灣的聯(lián)合創(chuàng)始人，他說敏捷是一種文化。在深圳灣，他們提倡自組織、自管理型的團(tuán)隊(duì)，在這樣的團(tuán)隊(duì)中，要給成員充分的信任，營造開放、充滿激情與創(chuàng)意的工作氛圍，聽起來很facebook、google的感覺，當(dāng)然，對人才選拔、員工的素養(yǎng)要求也會比較高。
既然是文化，就會引起沖突。他舉了個例子，說深圳灣后來新加入一位聯(lián)合創(chuàng)始人，來自于國企。他們之間就不同的公司管理理念產(chǎn)生了一些諸如命令與信任、服從與激情、層級與開放的沖突（其實(shí)就是傳統(tǒng)企業(yè)文化與敏捷文化的沖突）。
但這并不是一巴掌拍死的壞事，來自于國企的這位聯(lián)合創(chuàng)始人與他之間的這種沖突，對于公司文化是一種平衡，這些沖突最后都展現(xiàn)為一種融合，讓他在公司推行敏捷文化時，仍然維持著恰當(dāng)?shù)募s束，避免團(tuán)隊(duì)組織走向散漫無序的極端。
第五場，關(guān)鍵詞：敏捷轉(zhuǎn)型的關(guān)鍵在于搞定人
蔣毅舉了一個IBM團(tuán)隊(duì)轉(zhuǎn)型敏捷的例子。他早期作為一個測試工程師，成功參與了一個IBM內(nèi)一個小團(tuán)隊(duì)的敏捷轉(zhuǎn)型試驗(yàn)。上頭一拍板，big bang！決定參照成功模式，對一個500人的團(tuán)隊(duì)進(jìn)行敏捷轉(zhuǎn)型。結(jié)果經(jīng)歷了大半年混亂無序、充滿抵制、怨言的痛苦轉(zhuǎn)型過程。雖然最終還是完成了轉(zhuǎn)型，但是過程劇痛， 走了彎路，浪費(fèi)了很多資源。
一個大組織中，每個人都有自己的訴求，每個人面對問題的層面不一樣。對于敏捷的轉(zhuǎn)型，大家有沒有統(tǒng)一的目標(biāo)，大家怎么看待敏捷對個人對組織的影響，有沒有共識？這是轉(zhuǎn)與不轉(zhuǎn)，需要認(rèn)真思考的問題。
有一個參會者訴說了他的苦惱，他想在公司推行敏捷開發(fā)方法，但每次開會討論，大家都不積極，好像有沒有敏捷都無所謂，去開會純粹是為了應(yīng)付leader的要求。
蔣毅給他開的藥方是，先問問自己一個問題：你為什么要采用敏捷，如果不用敏捷，你目前的開發(fā)團(tuán)隊(duì)有什么問題？搞清楚了敏捷的目的、確定敏捷可以解決團(tuán)隊(duì)所遇到的問題后，然后要詢問每個團(tuán)隊(duì)成員的訴求：你個人目前碰到的問題是什么，你想解決什么、獲得什么？作為leader，需要把敏捷可以帶來的好處，短期的或長遠(yuǎn)的，落實(shí)到個人，打開團(tuán)隊(duì)成員的心結(jié)。
第六場，關(guān)鍵詞：DevOps不是工具，是方法
我是第一次了解DevOps，絕大部分參會者也是第一次知道這個概念。剛看到這個單詞時，我以為DevOps是一種工具或一套軟件。其實(shí)它是關(guān)于開發(fā)與運(yùn)維（Development+Operations）如何更高效地協(xié)作的方法。它是一個概念、方法論，就像“敏捷”這個概念一樣，它指的是團(tuán)隊(duì)組織某項(xiàng)活動采用的過程、方法，甚至文化與思想。
一個項(xiàng)目的開發(fā)流程會包括：需求、設(shè)計、開發(fā)、測試、部署和運(yùn)維，如果一定要嚴(yán)格的劃分DevOps解決的是哪個階段的問題，我們可以把它歸類到開發(fā)到運(yùn)維這一個過程。在傳統(tǒng)方法上，開發(fā)到運(yùn)維劃分為不同的職能，權(quán)限上有嚴(yán)格限制，溝通與協(xié)作上存在很多壁壘。而在現(xiàn)今的互聯(lián)網(wǎng)環(huán)境中，一方面要求對產(chǎn)品采取更頻繁的變更與發(fā)布，另一方面又要滿足部署與運(yùn)維對生產(chǎn)環(huán)境要求的安全性、可靠性與穩(wěn)定性。而DevOps提供的就是這樣的解決方案，即滿足頻繁變更發(fā)布的要求，又保證整個生產(chǎn)系統(tǒng)的安全及穩(wěn)定。
據(jù)說，在DevOps的幫助下，一個大型產(chǎn)品可以做到單天上十次的發(fā)布。當(dāng)然，這不是一個標(biāo)準(zhǔn)，就像項(xiàng)目管理理論提倡的那樣，適合自己的才是正確的，任何標(biāo)準(zhǔn)的方法或理論對一個組織來說都不是完美的，要為不同的產(chǎn)品、不同的團(tuán)隊(duì)、不同的公司文化做適合的剪裁。
作者：阿藍(lán)，一個女兒的寶爸。個人公眾號【一步成長】（ID：alanwriting）專注于“個人認(rèn)知與能力的提升、自我的發(fā)現(xiàn)與成長”。如果您對如下領(lǐng)域也感興趣：“能力提升、寫作、個人成長、親子關(guān)系”，那我們有相同的愛好，歡迎你關(guān)注和留言，謝謝！
