2012年12月8日晚上，和兩位朋友聊天，他們從國外的大企業工作了多年，回國創業，成立了一家軟體公司，按照敏捷的方法進行了2年的軟體開發，在實踐中有些具體的問題，大家在一起進行了溝通討論，從敏捷方法的文化，到敏捷方法的具體實踐的做法，溝通了大概3.5小時，第1個小時的溝通我忘記了錄音，後邊的溝通我做了錄音，根據回憶和錄音，將討論的問題做了整理如下，屬於“非典型企業的典型問題”。

1 在實施敏捷方法時，遇到了“形似而神不似”的問題，敏捷方法的“神”是什麼？

       我總結為兩條：質量與溝通。很多企業是沒有把握住這2條，而導致敏捷的失敗。

先說質量：

        （1）      在敏捷方法中，

        （2）      質量的含義包含了內部質量和外部質量，外部質量是使用者可以感知的，是對需求的符合性。內部質量是開發人員所感知，決定了軟體的易維護性。內部質量決定了外部質量，敏捷方法是二者並重的，而並非僅僅關注了外部質量，而傳統的方法往往僅關注了外部質量。

        （3）      質量的管理首先關注質量的投入，質量的投入表現在質量管理的活動上：測試驅動的開發，靜態檢查工具的使用，結對程式設計，程式碼走查等。沒有質量的投入就沒有質量的產出。敏捷的方法對於質量的投入應該如何投入，給出了具體的實踐，而並不是停留在概念上。

        （4）      提升軟體開發效率的最有效的方法是減少不返工，一次做對是提升效率的最有效的方法，因此就要預防錯誤，預防錯誤的方法包括和開發人員對需求的理解達成一致，結對設計，測試驅動的開發，結對程式設計等。

       再說溝通：

        （1）      敏捷方法為什麼可以少寫文件，因為他通過口頭交流的方式替代了文件交流！有哪些具體的口頭交流的手段呢：在策劃會議上專案組的成員對使用者故事做了溝通和討論，開發人員做了結對程式設計，每天開了站立會議，使用者代表或產品負責人在過程中實時的做功能測試等等，這些手段都保證了在文件比較少的前提下，可以保證產品的方向、產品的具體功能不會偏離使用者需求。

        （2）      在敏捷方法中溝通了什麼？首先是需求、其次是設計、再次是進展、最後是經驗教訓！在需求方面溝通了對需求的理解，需求是否實現了，需求的溝通是重中之重。使用者故事是用來講的，是使用者講給開發人員聽的，開發人員是否實現了聽來的故事，是需要講故事的人進行確認與驗收的。對於需求、對於進展都要儘早的報告壞訊息：需求理解錯了；需求無法實現；需求實現錯了；需求沒有按時實現！

       在敏捷的宣言中講到了4條宣言，在XP的方法中有4個價值觀，在這些描述中我體會下來最關鍵還是這2條。

       對於每個開發人員要將上邊的兩條落實到他們的每個人的細節行動上，做這件事情你是否保證了質量，是否通過溝通減少了錯誤的發生。

2 關於敏捷實踐的團隊文化

       團隊的文化，就是互補的文化，就是互相配合，互相幫助的文化。在中國的教育體系中，從小學到大學都沒有培養團隊協同的思想與理念。每個人的單兵作戰能力還可以，但是大家不知道如何形成一個團隊，從專案經理到團隊的成員都缺少這方面的思想認識或具體的做法。團隊的文化中包括了積極主動的文化，互相協調的文化。比如在開站立會議時，就有人只是關注自己的工作，不關注團隊中其他人的工作，你的是你的，我的是我的，而不是我們的。也有的人認為我的就是我們的，是我們的，就不是我的，不是我的我也就沒有責任。

       如何形成團隊的文化？

        （1）     在一個公司中，企業的文化首先是老闆的文化，老闆的一言一行影響了員工。我們可以比較一下聯想、華為、富士康等企業的文化，你就可以發現這個結論。如果一個團隊沒有形成一個良好的文化，首先領導就要反思，是否自己的言行出了問題？

        （2）     小團隊容易形成團隊的文化，而大的團隊形成文化比較困難。小團隊靠人治，大團隊靠法治。在敏捷的方法提倡小團隊，其中一個好處，就是容易形成這種互相配合，互相協同的文化。

        （3）     文化體現在細節中，文化需要不斷的進行重複強化。要從每個細節活動中去反思是否符合團隊的文化。

        （4）     文化的載體有2個：規章制度與人。通過企業的規章制度體現企業的文化，通過以老帶新來傳承文化。

3 關於scrum master的重要性

       敏捷的方法看上去簡單，實施起來的比較難，敏捷方法的實踐少，但是要求每條實踐必須做到位，做紮實，真要做到位就要求scrum master必須很熟悉scrum的基本原則與基本思想，簡單的站立會議，有些scrum master就不能控制局面，一提到問題就討論如何解決問題。可以寫一個check list，在開站立會議前的1分鐘，把站立會議的要點重複一遍，慢慢的把這些思想滲透到每個人的骨髓中。就好像文化大革命時，天天念毛主席語錄一樣。

       所以對於scrummaster而言要培養其基本的技能：如何主持會議？不僅僅要理解scrum的要求，而是要具備這些技能，公司裡熟悉SRUM方法的人可以作為scrum master的導師，旁觀scrum master的活動，然後指出其缺點，在實踐中指導提升其基本的技能。專案組的成員也要重視每次迭代結束時的回顧活動，通過自我總結提高團隊的整體能力。Scrum master並非固定的，是可以變化的，通過這種方式也可以發現團隊中適合做master的人。有的團隊每天站立會議的主持人是變化的，大家輪流主持，這也是一種很好的嘗試，通過這種方法發現人才。

4 如何挑選scrum master？

       挑選什麼樣的人做master，選組織能力強的人擔當，而不是一定是選擇技術能力強的人，master的作用是要發揮整個團隊的能力，激發大家的能力。不是scrum master有多強，而是整個團隊有多強！

5  敏捷實踐背後的道理最需要理解

       有些比較雜的任務，不夠清晰的任務，比如寫文件等是否適合採用敏捷的方法來管理？

       在XP中有結對程式設計，適用到對客戶的支援時可以借鑑結對的思想，如何保證質量？如果通過溝通減少中間記錄，對於文件的編寫我們可能不實用結對編寫文件，但是我們是否可以對這個文件進行評審呢？在寫文件之前我們是否對文件做了結構的設計呢，就象我們走系統隱喻一樣呢？是否做了方案的討論，我們都可以借鑑敏捷的實踐過來，你也可以把他作為一個使用者story，一個story就是一個需求而已。

       只要明白了敏捷的思想了，你只要類比就可以了，比如使用者故事的四段論，看上去很簡單，誰要這個功能？什麼功能？為什麼要這個功能？有了這個功能如何驗收？不能假想功能，做了功能沒有人使用，要這個功能要解決什麼問題？目的是否明確？通過驗收的標準進一步澄清目的。我們把這個思想類比到日常工作中，我們給一個員工下達一個任務時，常常發生對方沒有按我們的要求完成任務，需要進行返工，尤其是佈置任務的人比較繁忙時，往往是簡單說了一句，佈置一下任務就放手讓別人去做事情了。如果我們借鑑使用者故事的方法，我們可以這樣給其他人安排任務，我想讓你做什麼事情，為什麼要做這件事，你做完了以後，我會檢查哪幾點，這樣的話就可以減少很多這種誤解和返工。看上去使用者故事是很簡單的一條實踐，但是你需要仔細琢磨這條實踐解決了什麼問題，他背後的道理是什麼。

6 CMMI和敏捷方法的比較

       CMMI在做的初期往往編寫了大量的文件，隨著對CMMI的理解越來越深刻，與實際的結合越來越緊密，文件會越來越精簡。

       敏捷的方法再初期做的時候，往往感覺很簡單，但是越做就會感覺到越複雜，一個很簡單的活動如果想做到位，有很多注意事項。敏捷的方法會越做複雜。

       CMMI的實踐如通白開水，沒滋沒味，敏捷的實踐如果陳年老酒，需要慢慢咂摸，越咂摸越有味。

7 關於研發人員與測試人員的比例問題？  程式碼走查->單元測試->系統測試

       開發可以轉測試人員，測試人員轉開發人員比較難。

       在敏捷方法中強調了2種測試：單元測試與功能測試。Po關注的是需求是實現了，關注了外部質量，開發人員關注了內部質量，易於維護，易於設計，在敏捷中首先強調了內部質量，其次是外部質量。單元測試在發現缺陷的手段中是排在第二位的手段，第一位的手段是程式碼走查。如果做好了單元測試，可以減少系統測試的投入。

       在很多軟體公司中測試人員與開發人員的比例是1:2甚至是1:1，在系統測試上投入了大量的人力，為什麼呢，因為前期的單元測試投入的少，從而加大了後期的系統測試的工作量。就如同一個足球隊，安排了1個守門員不夠，再去增加多個守門員一樣。如果單元測試做到位了，系統測試人員與開發人員的比例不用強求。

8 關於使用者故事

       非軟體的活動，技術的難點的解決都可以視同為一個使用者故事，使用者故事就是一個需求。

       如果不是使用者提出的故事，而是我們自己提出的故事，應該越精簡越好，先出個東西，先上市。

       使用者故事是可以協商的。協商的是什麼？協商的是驗收標準！使用者需求劃分了優先順序，驗收的標準也可以劃分優先順序！

 使用者故事如果太大，需要拆小。可以把某個驗收準則視同為一個故事。故事不能減少，特性、驗收標準可以減少。

9 關於開發速度

 欲速則不達。平穩的開發速度如何理解？如果提升軟體開發的效率，不返工就能提高速度？如何不返工？在做之前做了充分的設計，傳統的方法是寫文件，評審，敏捷的方法是討論，是三個臭皮匠頂一個諸葛亮。

       每次迭代結束後，大家做回顧，提升團隊的能力，每次迭代結束後團隊的整理能力應該有長進，開發的速度越來越快，越來越穩定，是個正反饋的自適應的過程。

要通過成功走向成功來激勵員工，每次迭代要能成功結束，而不是每次迭代都要會失敗。每次迭代結束後要調整下一次迭代的開發速度，確保下一次迭代是切實可行的。

10 關於敏捷方法的質量管理

       領導是否意識到了欲速則不達？領導是否給專案組建立了一個敏捷的環境！很多公司在實施敏捷時往往是領導沒有正確的理念，總是催促專案組加快進度，還是回到了快而髒的開發模式上了。

       在推TDD之前，應該先推程式碼的靜態檢查。每天的站立會議時，昨天的任務是否做完了，應該進行檢查是否對靜態檢查出的缺陷都修復了。

       要訓練開發人員消除“差不多”的思想，不要做什麼事情達到差不多的狀態就行了，而是要一次做對。開發人員在上學的時候就缺乏這種訓練，在學校裡寫程式就是寫一個能run出正確結果的程式就可以了，並沒有進行完備的測試，也沒有注重程式碼的內部質量。

11 如何使用高水平的人？

       老闆很有水平，很明白，啥都自己幹，下邊的人時間長了就形成了依賴心理，就不會動腦去做事情了，高水平的人應該如何使用？如何充分發揮高水平的人的作用？就是讓他去培養人，培養出高水平的多個人來，這才是價值最大化，這才能形成一個團隊。否則鞭打快牛，最能的人最辛苦，別人不成長起來，就累死老黃牛。

領導太能，怎麼辦？領導去培養一批人，培養一個團隊出來，培養自己的接班人。