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