轉:ThoughtWorks University 取經記

ThoughtWorks University 取經記
http://phoenixtoday.blogbus.com/logs/27454013.html

http://phoenixtoday.blogbus.com/logs/28533541.html
四月份我加入了ThoughtWorks公司,由於是應屆畢業生的緣故,緊接着就被派到印度班加羅爾分公司進行了六週的公司培訓。六週的生活是緊張、繁忙而又非常開心的,不但與敏捷開發方法進行了親密接觸也結識了許多聰明、勤奮富有激情的外國同事。在這六週的生活中,前兩週主要是進行公司文化和敏捷開發思想的培訓,後三週就主要進行技能的培訓,最後一週是給所有培訓的ThoughtWorker一個項目,來評估整體培訓的結果。培訓這些內容的主要目的是讓新員工儘快的融入到公司文化中,成爲公司的一份子;還有就是理解敏捷軟件開發的原理並親身體驗真正的敏捷軟件開發方法,從而體會到這種開發方式的種種好處;最後的一個目的當然就是增強新員工的技術水平。本文會分爲兩部分,第一部分介紹ThoughtWorks對公司文化和敏捷開發思想的培訓,第二部分介紹 ThoughtWorks針對具體的團隊開發技能是如何進行培訓的,全文中會穿插一些真實有趣的小故事以及我對相應培訓的一些感想。

公司文化的傳承

對ThoughtWorks有所瞭解的人都知道,公司的文化都是圍繞人與人之間的平等、尊重和加強溝通這幾個方面的。作爲一個新員工,給你帶來的最大感受就是公司自由平等的氛圍和人與人之間和諧友好的關係。

這些平等、自由的思想當然會滲透在培訓課程的點點滴滴之中。第一天的課程中,我們就做了很多的遊戲,其中有兩個很有趣的遊戲,第一個遊戲是老師們給每個人發了一份表格,上面寫了二十多條內容,每一條內容會對應一位老師或學員,例如會有這樣的內容“有一個人擁有iPhone”,“有一個人的體重小於50公斤 ”,或者“有一個人要坐超過二十小時的飛機才能來到班加羅爾”等等,這些問題每一個都是特別設計的,而你的任務就是要在五分鐘之內將所有的內容與人對號入座。遊戲開始的時候,大家跑得跑,叫得叫,笑得笑,整個大廳沸騰了,好不熱鬧,最終有一兩個學員將所有人對號入座,然後大家就集體將所有匹配的結果大聲朗讀了出來。其實到底誰贏了遊戲,並不重要,真正重要的是在這個過程中,大家增進了瞭解,進行了有效地溝通,如果你都不瞭解你的團隊,那如何進行軟件開發呢?從這一個簡單的遊戲,我們所有學員和老師,就從陌生人向朋友邁進了一大步。第二個遊戲叫做“人人都會犯錯誤”,傳達的人人平等的理念更加強烈一些。遊戲規則類似於中國飯桌上經常玩的報數字(遇到含七的數字和七的倍數要說Pass),只不過我們加了一條,就是在你犯了錯誤後,要大聲地說“YES”,同時手腳並用的擺一個姿勢,然後站到圈的末尾。結果在遊戲的過程中一位印度裔的老師Reshema經常出錯,長相可愛的老師Reshema再加上大聲吼叫的 YES以及怪異的手腳並用姿勢,把所有人逗的前俯後仰。這個遊戲使我們明白了,犯錯誤是很正常的事情,你沒有理由去責怪別人,ThoughtWorks也是允許你犯錯誤的,關鍵是犯了錯誤你從中能學到什麼,以及幫助別人怎麼從錯誤中進步。

其實公司的第一堂課根本與敏捷軟件開發和技術無關,可能大家根本無發猜出是講什麼的,連所有的學員都很驚訝公司培訓的第一堂課,竟然是告訴我們什麼是公司認爲的歧視和不平等,在這一堂課中,老師會提出一些問題來讓學員投票,讓我們分辨什麼是歧視和不平等,然後再給出公司的答案,如果大家有疑問可以充分的表達自己的意見,然後再投票。從這第一堂課的內容就可以看到ThoughtWorks是何等的重視人與人之間的平等和尊重了。注重人與人的溝通也體現在公司文化的各個方面,最簡單的一個例子就是宿舍的安排,我本想着可能是不同分公司的員工會住在一起,沒想到剛下飛機就得知自己會和一個澳大利亞的同事還有一個印度的同事住在一間公寓裏,這對於英語不是母語的中國人來說,也真的是捏了一把汗。但是仔細想想,這樣的住宿方式,不但會加強不同學員之間的交流,而且可以更好的瞭解不同區域的文化,瞭解你將來可能一起工作的同事,瞭解他們的想法和行爲方式,這樣纔可能達到真正的尊重和平等。

瞭解ThoughtWorks的人可能都知道,平等和尊重在公司的極致體現不能不說是那些公司的領導層了,每一期學員培訓,Roy(不要說你不知道Roy是誰啊)都會單獨做一次演講,其中的主要內容包括創建ThoughtWorks的原因和歷史,公司經歷過哪些困難以及他本人的一些傳奇經歷。Roy的演講是很有趣的,不過學員們提的問題更加有趣,我和我的舍友就提了一個“假如你被綁架了,你會怎麼辦?”的離奇問題。結果Roy的回答讓人瞠目“其實我是被綁架過的!”然後他就娓娓道來那一次班加羅爾分公司的ThoughtWorker是如何喬裝成綁匪,然後在飛機場對Roy實行了一次“綁架”,之後Roy又爆料出許多被ThoughtWorkers戲弄的故事。從這些Roy的小故事中,你可以發現公司的頭頭腦腦們,喜歡和員工打成一片,有的時候他們會上來拍你的肩膀然後叫你的新外號,有的時候他們會跟你談論他們最近的尷尬經歷,甚至喫飯的時候他們也會被員工灌醉。可見平等和尊重的理念已經深深的植入 ThoughtWorks的文化精神之中。

ThoughtWorks公司的平等和尊重還體現在公司的管理很透明,甚至包括財務收益、開銷等信息都會公開的呈現在新員工的面前。印象中
關於
管理很透明有兩個小故事很深刻,其中之一就是第一週一門課程的內容就是將公司這幾年的收益和開銷完完整整的展現在所有員工的面前,包括總共有多少收入,總共有多少支出,這些支出用在培訓、新建分公司、股東收益等等方面的具體支出數目,並且在課程的最後每個學員還要扮演公司財務部門的角色,模擬體驗一下公司財務部門是如何進行資金運轉和保證現金流的。第二個故事就是Roy在他的演講中提起了2001-2003年公司曾經裁員的事情,原因就是當時IT產業大蕭條,公司處於窘境,Roy說那時是他最爲困難的時期,直到現在都很內疚,仔細想想在絕大多數的公司中,這些內幕消息哪是一個剛進公司還不到十天的人可以接觸到的,但是ThoughtWorks確毫無保留的給我們展現在眼前。其實管理的透明在回國後,也時時刻刻都可以體驗到,ThoughtWorks 北京分公司每月都會做一次月報,讓全公司的同事都知道這個月我們分公司的經營狀況。對於我們這些新員工,在短期內就對公司的各種狀況有了一個整體的瞭解,從而很快的建立起了一種強烈的主人翁精神。

敏捷軟件開發思想的傳承


對於前兩週敏捷開發思想的培訓是非常有趣的,幾乎每節課都有互動的過程,每節課都會有生動的實例讓你體驗到什麼是真正的敏捷軟件開發,爲什麼要使用敏捷軟件開發。

在介紹整體培訓的過程之前,首先介紹一下ThoughtWorks敏捷軟件開發團隊的構成。一般一個開發團隊主要有以下幾種角色:PM,Project Manager項目經理;BA,Business Analyst業務分析;DEV,Developer 開發人員;QA,Quality Analyst測試人員。PM對項目進行全局掌控(有的時候,還會有IM,Iteration Manager對具體的迭代開發進行掌控);BA,主要與客戶進行溝通和業務分析,與開發人員進行交流,與測試人員對整體功能進行討論等等;DEV,主要就是開發應用程序,但同時也要協助業務分析員和測試人員進行工作;QA,主要對開發人員開發出的系統,進行全方位的測試,包括功能測試、性能測試等等。對於團隊整體的開發流程,是一個有序、小步、漸進的過程。ThoughtWorks對敏捷軟件開發思想的培訓也主要針對如何瞭解用戶需求,團隊共享代碼,迭代開發,總結與回顧。

在軟件開發的過程中,能夠準確的理解用戶的需求,將用戶的需求轉變爲開發團隊理解的用例,是一件緊迫而重要的事情。但是,如何纔算好的理解用戶的需求呢?如何能讓我們這些從沒與客戶打過交道的畢業生儘快的學會與客戶溝通的方法呢?這就是我個人非常喜歡ThoughtWorks University的一個方面,在敏捷軟件開發的所有課程,包括對需求理解的課程,設計的非常精妙,不但能夠讓這些觀念深深地紮根人心,而且能讓你體會到真正的軟件開發其實就是應當這樣做得。我們上過一堂用橡皮泥做電話的課程,老師們把大家分成許多小組,每個小組由3-4個學員和一位扮演客戶的老師組成,老師們扮演的客戶是非常的苛刻的,我們的任務就是要做出讓客戶滿意的電話來,每一次開發的過程只有十五分中,分三次開發完成一部完整的電話。在整個開發的流程中,我們體會到客戶的需求是隨時改變的,當他們看到了原型系統,甚至可能推翻之前的所有需求,這時候作爲一個開發人員或者業務分析人員,在你瞭解客戶的需求過程中,不但要求你具有能夠充分理解客戶需求的技巧,更需要你能啓發客戶思考一些它們沒有想到的方面,從而少走一些彎路。在製造電話的過程中,我們幾個小組在第一個開發週期的行動,幾乎都是悶頭造電話,完全忘記了我們有一位客戶坐在我們的桌字旁,當我們有疑問的時候,爲什麼不去直接找客戶進行溝通呢?老師向我們提出了這樣的問題後,我們在後面兩次的迭代中,和客戶進行了頻繁的溝通,最終做出了讓客戶滿意的電話系統。下圖就是我們做出的橡皮泥電話系統之一,你看Reshema老師拿着電話,多麼高興。

不得不提起的回饋信息

加入ThoughtWorks以來,發現回饋信息是公司非常注重的一個方面。在TWU的生活中,不但學員之間兩週會互相給一次書面的回饋信息,每週需要對這一週發生的小到食物好喫與否大到老師的培訓方式等都要提供回饋信息,平時課堂上即使給出的回饋信息更是數不勝數了。由於我們中國學員的母語不是英語,因此在前兩週培訓的過程中,我們有的時候跟不上老師們的語速。結果在第一週五的回顧課程中,不光中國學員,還有許多我們新認識的朋友幫我們提出了這個問題,討論的結果就是我們不但在牆上掛起了“說慢點!”的大幅標語,還發明瞭一個手勢用於提醒老師講話慢點。回饋信息其實確保了大家都在儘自己最大的努力去做好每一個方面,同時也培養出一種公正公開的氣氛,讓我們都朝着自己所樹立的目標前進。

總結

現在想想,公司的一系列生動的培訓課程,不但讓我們瞭解公司文化的本質,更重要的是讓敏捷軟件開發思想深深的紮在了我們心中,我們看到了原來軟件開發的過程可以這樣的豐富多彩。TWU的洗禮其實只是帶我們入門,不過這些課程在我們真正進入項目後,纔會逐漸發揮出一步步深遠的作用,例如我現在從事的項目,就時常讓我想起TWU的課程中老師說的方方面面,再結合當前的親身體驗,可謂是獲益匪淺。希望本篇的內容也能夠對讀者有所啓迪。



在有些人的眼中,ThoughtWorks是一羣拿着卡片到處貼,到處走的奇怪人羣組成的軟件諮詢公司。其實爲什麼使用卡片作爲理解用戶需求的主要機載體,在我去TWU之前也很疑惑。後來,在一堂介紹如何使用卡片理解需求的課程中,終於瞭解到原來其中包含了這麼多奧妙。首先卡片很小,這就迫使業務分析員不能將太多的內容放在同一張卡中,由於一個迭代週期通常是兩到三週,需要給用戶展示一些能用的系統功能出來,這樣就會引起整個團隊思考許多有價值的問題,什麼是最緊要的?什麼是系統的核心?我們要用多長時間來完成這些卡片上的內容?第一個迭代週期能完成多少卡片?我們的團隊開發速度是多少?等等。其次,卡片在卡片牆上是可移動的,因此它很靈活,就如下圖所示,可以將卡片放置在不同的隊列中,通常我們用“在分析中”、“在開發中”、“在測試中”、“結束”等一些狀態表示卡片所處的不同狀態。這樣,當所有團對人員,需要了解當前項目的進度狀況時,只要站到卡片牆前,就可以一目瞭然,如果處理不同卡片的小組需要彼此溝通,在卡片牆上,可以用最快的速度找到相應的人員,甚至,當你有疑惑的時候,卡片可以拿下來仔細研究,只要記得最後放回去就好。卡片的最後一個優點就是對當前項目進行評估,舉一個簡單的例子,當一個團隊的開發狀態是絕大多數的卡片都集中在“在開發”的隊列中,就表示當前開發團隊處於業務分析員和測試人員無事可幹,但是開發人員又過於繁忙的不健康狀態。什麼原因導致的呢?可能是開發速度過慢或者是業務分析員寫的卡片粒度過大,導致開發人員無法及時的完成。由此,當我們站到一個團隊的卡片牆之前,我們看到的不僅僅是一些簡單的卡片,更是整個開發團隊的開發狀態的展示。一張張小小的卡片卻包含了如此多的內容,這真的是我們始料不及的。當然卡片並不是完美無缺的,對分佈式團隊開發就是卡片牆的致命弱點,但這些問題在ThoughtWorks的Mingle軟件中都得到了很好的解決,卡片對我們來說更是一種以用戶爲中心,以團隊溝通爲中心的開發思想,而不僅僅是一種開發方法。
針對眼前的需求,小步前進,不做過多的設計,也是敏捷軟件開發的核心思想之一。ThoughtWorks University通過一個早上的擺積木課程(Lego Game)讓我們充分的理解了過多設計的弊病。這次課程的整體任務是創造未來物種,類似於造電話課程,同樣分爲三個迭代週期,有一位老師作爲客戶伴隨着我們進行開發。這一次,老師們一下給了我們許多點數不同的需求,每個需求對應一張卡,每張卡上有不同的分數表示這張卡的難度,每次迭代有五分鐘的討論,需要確定這次迭代都要完成哪些功能,有十分鐘的設計,還有十五分鐘的開發過程,每次迭代後大家要討論哪些做得好,哪些做得不好的地方。第一次的迭代往往是犯錯誤最多的地方,我所在的小組向客戶許諾了總共加起來十分的卡片,在設計過程中又做了許多不必要的假想,過多的專注於給未來的需求留下餘地,而將自己開發的過程束縛住。最後僅僅搭起來了動物的頭和身體,可是客戶要求的是一個完整的動物,所以第一次迭代我們只有零分,客戶非常的失望。ThoughtWorks 就是這樣,通過學員的犯錯誤,讓我們自己體會,然後通過討論,讓我們自己總結出具體的方法,老師們則是在旁邊指引,這樣的感受怎麼能不深刻呢?經過討論,我們制訂了自己的方針:少許諾,少設計,好好做核心模塊。就這樣,最後我們創造出了未來的一個物種(還有它的孩子)。

迭代的過程也是ThoughtWorks進行敏捷過程培訓的一個重要方面。還是繼續我們的遊戲旅程吧:這一次老師讓我們分成三個小組,分別從培訓大廳的一端將氣球搬運到另一端,每一組有兩個人負責裝運,兩個人負責撐袋子,一個人負責搬運,哪一組能在最短的時間內,將最多的氣球從一個口袋中運到另一側的口袋中就算勝利,如果過程中任何氣球掉在路途中,則不可拾取。第一次的規則是隻能運一次,整個過程給人的感覺就是搬運的人花了很多的時間,承擔了過多的責任,而其他的四名隊員起不到任何的作用,只能邊喊邊焦心的等待。第二次的規則幾乎與第一次一樣,但搬運人可以多次的運輸。結果第二次,我們不但出色的運輸了所有的氣球,而且還比第一次所花的時間更少。玩完遊戲的討論過程中,我們逐漸的明白了,第一次運輸就好比傳統的瀑布式開發,開發人員承擔了許多的壓力,缺少溝通和其他人員必要的幫助,閉門造車造出來的東西,往往並不是客戶心目中想要的東西;而第二次運輸就好比多次迭代的開發過程,開發人員得到更多的信息回饋以及業務分析員和測試人員的幫助,因此能夠開發出更好的軟件產品。就這樣,我們不但理解了迭代開發的原理,更通過親身的體驗明白了這樣做是行之有效的。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章