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

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

我總結(jié)為兩條：質(zhì)量與溝通。很多企業(yè)是沒有把握住這2條，而導致敏捷的失敗。先說質(zhì)量：

（1）      在敏捷方法中，多快好省四個字進行平衡時，首先是要固定質(zhì)量，在固定質(zhì)量投入的前提下，再去平衡進度、需求和投入，在剩下的這三個要素中，往往先裁剪的是需求！

（2）      質(zhì)量的含義包含了內(nèi)部質(zhì)量和外部質(zhì)量，外部質(zhì)量是用戶可以感知的，是對需求的符合性。內(nèi)部質(zhì)量是開發(fā)人員所感知，決定了軟件的易維護性。內(nèi)部質(zhì)量決定了外部質(zhì)量，敏捷方法是二者并重的，而并非僅僅關(guān)注了外部質(zhì)量，而傳統(tǒng)的方法往往僅關(guān)注了外部質(zhì)量。

（3）      質(zhì)量的管理首先關(guān)注質(zhì)量的投入，質(zhì)量的投入表現(xiàn)在質(zhì)量管理的活動上：測試驅(qū)動的開發(fā)，靜態(tài)檢查工具的使用，結(jié)對編程，代碼走查等。沒有質(zhì)量的投入就沒有質(zhì)量的產(chǎn)出。敏捷的方法對于質(zhì)量的投入應(yīng)該如何投入，給出了具體的實踐，而并不是停留在概念上。

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

再說溝通：

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

（2）      在敏捷方法中溝通了什么？首先是需求、其次是設(shè)計、再次是進展、最后是經(jīng)驗教訓！在需求方面溝通了對需求的理解，需求是否實現(xiàn)了，需求的溝通是重中之重。用戶故事是用來講的，是用戶講給開發(fā)人員聽的，開發(fā)人員是否實現(xiàn)了聽來的故事，是需要講故事的人進行確認與驗收的。對于需求、對于進展都要盡早的報告壞消息：需求理解錯了；需求無法實現(xiàn)；需求實現(xiàn)錯了；需求沒有按時實現(xiàn)！

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

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

2 關(guān)于敏捷實踐的團隊文化

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

如何形成團隊的文化？

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

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

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

（4）     文化的載體有2個：規(guī)章制度與人。通過企業(yè)的規(guī)章制度體現(xiàn)企業(yè)的文化，通過以老帶新來傳承文化。

3 關(guān)于scrum master的重要性

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

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

4 如何挑選scrum master？

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

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

有些比較雜的任務(wù)，不夠清晰的任務(wù)，比如寫文檔等是否適合采用敏捷的方法來管理？

在XP中有結(jié)對編程，適用到對客戶的支持時可以借鑒結(jié)對的思想，如何保證質(zhì)量？如果通過溝通減少中間記錄，對于文檔的編寫我們可能不實用結(jié)對編寫文檔，但是我們是否可以對這個文檔進行評審呢？在寫文檔之前我們是否對文檔做了結(jié)構(gòu)的設(shè)計呢，就象我們走系統(tǒng)隱喻一樣呢？是否做了方案的討論，我們都可以借鑒敏捷的實踐過來，你也可以把他作為一個用戶story，一個story就是一個需求而已。

只要明白了敏捷的思想了，你只要類比就可以了，比如用戶故事的四段論，看上去很簡單，誰要這個功能？什么功能？為什么要這個功能？有了這個功能如何驗收？不能假想功能，做了功能沒有人使用，要這個功能要解決什么問題？目的是否明確？通過驗收的標準進一步澄清目的。我們把這個思想類比到日常工作中，我們給一個員工下達一個任務(wù)時，常常發(fā)生對方?jīng)]有按我們的要求完成任務(wù)，需要進行返工，尤其是布置任務(wù)的人比較繁忙時，往往是簡單說了一句，布置一下任務(wù)就放手讓別人去做事情了。如果我們借鑒用戶故事的方法，我們可以這樣給其他人安排任務(wù)，我想讓你做什么事情，為什么要做這件事，你做完了以后，我會檢查哪幾點，這樣的話就可以減少很多這種誤解和返工?？瓷先ビ脩艄适率呛芎唵蔚囊粭l實踐，但是你需要仔細琢磨這條實踐解決了什么問題，他背后的道理是什么。

6 CMMI和敏捷方法的比較

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

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

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

7 關(guān)于研發(fā)人員與測試人員的比例問題？

開發(fā)可以轉(zhuǎn)測試人員，測試人員轉(zhuǎn)開發(fā)人員比較難。

在敏捷方法中強調(diào)了2種測試：單元測試與功能測試。Po關(guān)注的是需求是實現(xiàn)了，關(guān)注了外部質(zhì)量，開發(fā)人員關(guān)注了內(nèi)部質(zhì)量，易于維護，易于設(shè)計，在敏捷中首先強調(diào)了內(nèi)部質(zhì)量，其次是外部質(zhì)量。單元測試在發(fā)現(xiàn)缺陷的手段中是排在第二位的手段，第一位的手段是代碼走查。如果做好了單元測試，可以減少系統(tǒng)測試的投入。

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

8 關(guān)于用戶故事

非軟件的活動的，技術(shù)的難點的解決都可以視同為一個用戶故事，用戶故事就是一個需求。

如果不是用戶提出的故事，而是我們自己提出的故事，應(yīng)該越精簡越好，先出個東西，先上市。

用戶故事是可以協(xié)商的。協(xié)商的是什么？協(xié)商的是驗收標準！用戶需求劃分了優(yōu)先級，驗收的標準也可以劃分優(yōu)先級！

用戶故事如果太大，需要拆小?？梢园涯硞€驗收準則視同為一個故事。故事不能減少，特性、驗收標準可以減少。

9 關(guān)于開發(fā)速度

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

每次迭代結(jié)束后，大家做回顧，提升團隊的能力，每次迭代結(jié)束后團隊的整理能力應(yīng)該有長進，開發(fā)的速度越來越快，越來越穩(wěn)定，是個正反饋的自適應(yīng)的過程。

要通過成功走向成功來激勵員工，每次迭代要能成功結(jié)束，而不是每次迭代都要會失敗。每次迭代結(jié)束后要調(diào)整下一次迭代的開發(fā)速度，確保下一次迭代是切實可行的。

10 關(guān)于敏捷方法的質(zhì)量管理

領(lǐng)導是否意識到了欲速則不達？領(lǐng)導是否給項目組創(chuàng)建了一個敏捷的環(huán)境！很多公司在實施敏捷時往往是領(lǐng)導沒有正確的理念，總是催促項目組加快進度，還是回到了快而臟的開發(fā)模式上了。

在推TDD之前，應(yīng)該先推代碼的靜態(tài)檢查。每天的站立會議時，昨天的任務(wù)是否做完了，應(yīng)該進行檢查是否對靜態(tài)檢查出的缺陷都修復了。

要訓練開發(fā)人員消除“差不多”的思想，不要做什么事情達到差不多的狀態(tài)就行了，而是要一次做對。開發(fā)人員在上學的時候就缺乏這種訓練，在學校里寫程序就是寫一個能run出正確結(jié)果的程序就可以了，并沒有進行完備的測試，也沒有注重代碼的內(nèi)部質(zhì)量。

11 如何使用高水平的人？

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

領(lǐng)導太能，怎么辦？領(lǐng)導去培養(yǎng)一批人，培養(yǎng)一個團隊出來，培養(yǎng)自己的接班人。