模板
教程
環境
性能
功能
管理
諾基亞實施敏捷軟件開發的前世今生(2)
敏捷和瀑布對接所面臨的問題，我們就曾經歷過一次事件，我個人對此印象很深刻。某天中午時分收到印度同事來信，說他們發現了一個bug，需要我們團隊的幫助。我時任團隊(團隊名：Thunder;取意雷霆一擊)ScrumMaster，我判斷認為不需要現在打擾團隊，可以等到Scrum日會時再告知團隊成員并商量處理方案，于是乎，從班加羅爾-杭州這個角度來看的話，我們并未作出回應。讓我吃驚的是，下午大概2~3點的時候，又收到對方的一封郵件催促，郵件內容大意是，要求我們盡快或立刻調試解決此bug，他們有50多名測試人員因為這個bug的阻礙而無法繼續干活……
FemtoGW項目擴張很快，我們很快又填充了很多前西門子的同事，也增加了很多新招聘進來的同事。不得不說，就我所接觸過的那幾位前西門子的同事，的確能力很強，包括丁俊華、滕帆(兩人最開始都在Thunder，后來去其他團隊擔當ScrumMaster，也是我們虛擬架構師團隊的成員)等，以及和我不爭不相識的測試同仁劉哲文。當然，我還見識了出自華為的盧紅旭同學敢加班敢熬夜的牛逼精神，就是可惜這小子花了太多時間在炒股上。
王婆賣瓜，自賣自夸。要問我誰最棒，我一定告訴你，那就是我們Thunder團隊的兄弟們(包括幾位姐妹)最棒!雖然一直都是人來人往，但Thunder的精神卻一直延續著。我還記得他們都是(如有遺漏，敬請諒解，并聯系我加進來)：李程遠、丁俊華、滕帆、陸宏斌(后繼任ScrumMater至今)、胡振東、張博濤、胡笳、Zhao Congxin(女)、張翠香。我依然記得，曾經，因為Sprint即將結束，我們卻被一個小bug給困擾無法通過持續集成，我和陸宏斌、胡振東一起加班奮戰到凌晨3點多終于搞定，帶著極大的滿足感打車回家，但是……等我到家門口一掏褲兜才發現忘記拿鑰匙，兜里總共只有100來塊前，剛好夠打車到公司往返的路費……
我還記得，第一個Sprint，我們就100%全部滿足了DoD的所有要求，這幾乎是我們團隊甚至項目所有團隊的唯一一次，而且這個DoD的還設定得非?？量?，沒記錯的話，我們要求代碼覆蓋率必須超過85%、圈復雜度低于5。也正因為太苛刻難以達成，后來就降低了其中的一些要求。不過，其中有一條要求到最后也沒有改變或者是拿掉，那就是：DONE意味著除了在本機或測試機上測試通過，還必須在CI環境下測試通過。這其實是一個非?？量痰臈l件，團隊越多越苛刻。能夠做到這一點，時任部門經理陳濯非(昵稱：Trophy;他雖不在項目里掛名，但卻非常關注和投入這個項目)的大力支持功不可沒，我們從一開始就明確了CI紀律必須遵守不得違反，一旦build失敗所有人都不準check-in代碼。為了幫助團隊做到這一點，我們組建了一個虛擬的CI團隊，我記得至少包括我、@秦之遠、黎晰和其他幾個開發，組成類SWAT團隊。專門負責照顧CI實踐的健康運轉，如果CI出現問題，例如build失敗，我們就要集合起來，去定位問題然后分發問題甚至直接解決問題，確保CI系統中的build一直正常。而@秦之遠也就是從這個時候，開始鉆研CI，并逐漸成長為組織內當仁不讓的CI專家。
@hanzhi竇是我們的產品負責人(Product Owner，簡寫為PO)，在此之前，他是我們CCC(Chorus Competence Center)的幾名技術專家之一，有著深厚的技術積累。加入FemtoGW項目后，就走上了敏捷的道路，成為了一名PO。關于PO這塊的工作，和他交流、學習是上佳之選，我就不再廢話。不過有一點，我想要告訴大家，FemtoGW項目包括老產品近600人的研發，我們用來管理產品列表的工具都是Excel。我想老竇對我最深刻的印象，估計是“刺頭”，每次Sprint評審會議，30幾好人濟濟一堂，總能聽到我抗議、反駁其他團隊介紹其需求已經DONE的結論，我堅持要求嚴格地按照DoD的標準判決，DONE就是DONE，NOT-DONE就是NOT-DONE，沒有中間的灰色地段。尤其是在所有團隊連續三四個月都無法DONE掉任何一個用戶故事(因為CI的build一直fail)，老竇非常想要通過DONE來增進團隊的成就感、提振團隊士氣的時候，我卻一如既往的堅持不妥協(呃，Thunder團隊自己也無法DONE，CI影響到的是所有團隊)……
當時，我們還對一個重要實踐進行了嘗試 —— ATDD(Acceptance Test Driven Development，接收測試驅動開發)。我則幾乎全程參與了這個嘗試，但我個人感到非常遺憾的是，后半程王獻接手后，他跟老竇一起把它從一個實踐變成了一個流程。我跟王獻和都是好友，但這個操作，我個人確實難以認同，因為我認為ATDD的關鍵就在于互動和交流，這個流程則極大地削弱了它們的作用，或者說“解除了對它們的依賴”。
當時在組織內有好幾個改進措施，都給ATDD的嘗試打下了基礎。
對robotframework的全面采納和推廣：我是測試自動化組最初的兩名成員(我和俞森，組長是鄒仲毅)之一，經歷了多個工具的興衰，時任robotframework內部培訓師和測試自動化教練。robotframework的試點非常成功，也很適合敏捷這種研發模式，所以被大范圍推廣，以圖提高自動化比例。這個工具本身就是面對接收測試(Acceptance Test，敏捷下有了新的含義，和過去的UAT不同)的，也支持ATDD。
用戶故事興、功能SPEC衰：敏捷轉型對我們當時沿用的研發模式和流程產生了極大的沖擊，其中就包括FRS(Feature Requirement Specification)，此feature非彼feature，不是敏捷環境下常說的特性，可看做是多個模塊構成的一個小功能集。當時對于開發和測試來說，這是一份非常重要的文檔，它是開發和測試的依據。轉向敏捷之后，有了用戶故事，FRS就顯得有些多余，然后陳學凱牽頭在想辦法如何能妥善地處理或轉化這份文檔的內容。商討過程中，結合robotframework測試用例的一些特點，我提出了“Executable Requirement”(可執行需求)的設想，我想這跟Gojko Adzic在《實例化需求》中提到的“Living Documentation”(活文檔)有異曲同工之妙(ps. 他也采訪過我哦，英文版鳴謝名單里有)。
Elisabeth Hendrickson：這主要是對我個人的影響。Elisabeth是敏捷測試方面的專家，曾獲得敏捷聯盟2010年的Gordon Pask大獎，她曾開辦有Quality Tree公司提供敏捷、敏捷測試方面的咨詢，由于剛剛加入了Pivotal Labs公司，她已經不再經營此業務。我非常有幸能夠在我迷茫和猶豫的時刻，參加了她的敏捷測試和ATDD培訓(5天)，這位受人尊敬的專家(據Michael Bolton八卦說，好像是Brian Marick吧都認為跟她搶單失敗一點都不丟臉)也和我有相似的觀點，讓我倍受鼓舞，更加堅信我的測試理念和堅持并非不切實際也絕不理想化。她介紹ATDD的文章，可以在她網站上免費下載，點擊這篇博文即可。
