敏捷之旅-段念說豆瓣成長的土壤

      作為敏捷之旅北京站的籌劃人員，在討論請那位業界比較享譽盛名的人士進行keynote演講時，我一直不是很理解為什麼小組成員極其推崇豆瓣的段念進行最重要的第一個Keynote的演講，孤陋寡聞的我在百度和他微博上得到的資訊實在看不出來他有什麼亮眼的地方，當時我對自己說了，答案只能在大會現場才能知道了，而在段念講完之後，我感覺渾身在輕輕的顫抖，因為段念講述的生長正是我苦苦尋找的東西。

      因為是一個以‘敏捷開發’為主題的大會，所以段念上來先向聽眾問了如下幾個問題：是不是有團隊使用敏捷，就是敏捷呢？建立一個準確的流程和體系，敏捷就能持續了嗎？敏捷開發中要程式員做的自承諾，是否是資本家壓榨工作所使用的圈套？敏捷如何提高效率？

      種種問題，段念的回答也非常簡潔，一個工作方法是否能夠解決團隊的問題，根本在於能否實踐團隊中顯示出效果；作為一個實踐者，豆瓣本身是在沒有規劃的情況下使用敏捷的，讓整個團隊自動自發去喜歡上某種工作方式和工具，比建議一個明確的流程和體系更能吸引才華橫溢而又有個性的工程；

     就機構組織敏捷轉型來說，越往核心層(管理層)其本身的價值差異不大，都是為了創造出一個高效的工作團隊，時刻都有具體的成果出現；但是因為這些成果展出對於實際進行工作的團隊而言，突然出現的改變造成的不適應，往往會造成這些工作團隊為了迎合高層的指示而做敏捷，但是在具體工作上還是使用習慣上的工作模式，因此可以說敏捷轉型在企業中越向外擴充，其差異越大。因此段念建議：敏捷最好是生長出來的，而不是計划出來的。

     豆瓣開始僅有一個簡單的社區，而隨著使用者在社區內自發的組織進而開發出了讀書、電影、線下活動等功能，這可謂是豆瓣豆瓣生長的特性，根據這種特性，也定義了豆瓣的敏捷不可能是領導層組織、設計出一個該生長模式,豆瓣本身僅僅是為發展提供了一個良好的環境和土壤。

      段念本身認為豆瓣在敏捷實踐之中，還是存在很多問題，尤其強調隨著開發工程師人員的增加，彼此之間的溝通往往會出現問題，同時豆瓣堅持小團隊，保持團隊人數少於10人。同時豆瓣本身提倡快速迭代，快速發布，並且是讓使用者不會覺得豆瓣有巨大的變化，但實際上豆瓣每天在UI上都在不斷髮生的改變，嘗試發掘使用者的喜好，因此如果好奇的人如果三年前有切對豆瓣的頁面，會發現和今天豆瓣的UI是巨大的。

      產品經理尤其不喜歡敏捷開發，因為他們認為敏捷開發往往代表者民主，需要同工程師協商決定的可行性，而產品經理們認為不通過商量他一天可以想出7個決定，如果和工程師進行商量，可以1個決定都確定不好。

      工程師有較好的品質意識，為此他們還創造了一個happy day，具體的方式就是找出工作日的一天，工程師們針對某個問題進行集體攻關，各自編寫代碼，看誰能夠最好的解決這個問題。隨著豆瓣面向業務開發的不斷增加，工程師的數量也在增加，這時候面對一個具體的開發項目該如何分配工程師去進行工作就成了一個實際的問題，因為當工程師完成這個項目之後，可能立刻就會加入到另外一個項目中去，而之前項目需要這個工程師去修改之前工作出現的bug或者新功能的時候，這個工程師本身已經沒有時間了，因此豆瓣的工程師們發明了‘攻城機動隊’這個組織，他們的大本營在‘攻城師濕地’，當他們的指揮官PM(產品經理)過來帶領攻城師們去攻關新的項目的時候，這些攻城師上次項目出現的問題，留在‘攻城師濕地’的會協助他們解決這些問題。

      豆瓣提供的土壤和空氣培養除了有解決問題並抱有解決問題心態的工程師，在豆瓣內部工程師們可以隨便調侃別的團體完成的產品，而這些產品的研發團隊卻不敢怒吼回擊：“如果覺得不好就自己做一個”，因為豆瓣的工程師可能會真的抽時間做出一個更好的產品，段念說這是一個玩笑，但是擁有如此土壤的豆瓣，絕對擁有如此執著的工程師。
------------------------------------------------------------------我的微博：http://weibo.com/192jiang我的豆瓣：http://www.douban.com/people/fulmination/

本文出自 “麒麟天空” 部落格，轉載請與作者聯絡！