每日站會、代碼審查、結對編程 之開源中國實踐

在我來到開源中國以後，嘗試將每日站會、代碼審查、結對編程這三種編程實踐帶入團隊。而這個過程，我我的以爲是一項很是寶貴的體驗。我以爲能夠拿出來和你們分享。

先介紹下目前咱們團隊的結構：3名Java開發，1名前端，2名實習。

如下我不會詳細介紹它們分別是什麼，也無心討論它們有什麼好處壞處，本文側重分享在實踐它們的過程可能遇到的問題，以及咱們是如何處理的。

每日站會

每日站會 （Stand-up ）：是天天進行的會議旨在在組隊成員之間進行狀態更新。'半實時'的狀態容許參與者瞭解到潛在的挑戰以及用於處理一個困難或者耗時的問題的協調精力。它在一些敏捷軟件開發過程當中有着特定的價值，譬如Scrum，可是一樣能夠在任何開發方法論中被使用。術語 「站」 衍生於經過保持與會人員站立的狀態（長時間站立會致使不適）從而幫助控制會議的時間的實踐。

咱們天天會早上花十幾分鍾（具體時長看團隊大小），你們一塊兒站（是站）在卡牆前過卡。卡牆其實就是Team中的任務看板。就這樣，咱們從「已驗收」列到「待辦中」列，從上往下，一張卡一張卡的過。這裏的卡是指定義了一個小功能需求的卡片。 

站會不過是向領導彙報

我在實踐每日站會的時候，發現很多人把每日站會當成一種「向領導彙報」的過程。好比他們會習慣地彙報：我昨天作了1，2，3 blabla。一大串，彷彿說得少就是作的少。因此這個過程，我不斷地指正，大家不是在向領導彙報，咱們只須要對這件事情負責，說到你的卡時，你就說你的卡的當前狀態就行了。慢慢地團隊裏就養成了對事不對人的文化。爲何呢？每日站會就是提醒咱們每日的工做就是對這些「事」負責。

隨着時間遷移，咱們的團隊就慢慢習慣了這種站會。也會在站會上開一些開玩笑了。不要認爲這是浪費時間，這是團隊文化中很重要的一部分。

站會時間把控問題

站會還可能會遇到的問題是站會時間的把控。因此，咱們每日站會會有一個主持人。若是你們說偏題了，主持人就必須指正，讓相關人在站會後本身討論。若是你們討論的這個問題是個大問題，那麼，也是在站完會後再討論。另外，主持人還要是輪換的，這樣就能夠將團隊全部成員帶入項目。

站會上的新人問題

每日站會經常遇到的問題是過卡時，這我的說得太細了，把功能的具體實現細節都說出來了。這時，咱們不該該當即打斷他。出現這樣的狀況，說明他必定是新人。咱們應該選擇在站會後單獨找他重申一次每日站會的目的和內容。固然，一開始實踐每日站會時，團隊裏除了你每一個人都不懂時，你就有必要立刻指正了。

代碼審查

代碼審查（Code review）是指對計算機源代碼系統化地審查，經常使用軟件同行評審的方式進行，其目的是在找出及修正在軟件開發初期未發現的錯誤，提高軟件質量及開發者的技術。代碼審查常以不一樣的形式進行，例如結對編程、非正式的看過整個代碼，或是正式的軟件檢查。 

我今天沒有什麼好說的

一開始，我實踐時，遇到的最大問題是：團隊成員喜歡說，我今天沒有什麼好說的。這句話聽起來冷漠，其實背後的緣由是你們不徹底理解代碼審查是什麼，而不是由於他們真的沒什麼好說的。

這時，我會說：只要你今天作了的事情，你均可以說。而後，他們經常不知從何提及，接着，一上來就給咱們講代碼細節。

遇到這種狀況，咱們須要再強調一遍代碼審查須要說什麼：上下文、你是如何解決問題的、解決過程遇到什麼問題……有時被審查的人可能說的不夠明白，我就會幫助補充。

這個過程，你可能會發現有些人在表達能力上的不足，致使聽的人一頭霧水。個人作法是理解他說的，而後嘗試幫助他更好表達出來。這樣，提高他的表達能力的同時，讓他在團隊裏也更有歸屬感。

說得太多了

有時，有些成員可能會說的很是很是細。多人這樣了，就會致使代碼審查的時間過長。發生這種狀況，將表達能力的問題排除外，大概就是這我的沒考慮哪些應該是本身應該重點說出來的。這時leader就要站出來指正了。

沒寫代碼怎麼審查？

其實，咱們實踐的代碼審查並非十分嚴格。由於有時，咱們一天下來沒有寫代碼，而是作調研工做。遇到這種狀況，被審查人也須要主動分享他今天的習得。有時，他說出來某個問題，也許其餘成員也遇到過一樣的問題，並解決了。這樣就爲團隊節約時間。

結對編程

結對編程（Pair programming）是一種敏捷軟件開發的方法，兩個程序員在一個計算機上共同工做。一我的輸入代碼，而另外一我的審查他輸入的每一行代碼。輸入代碼的人稱做駕駛員，審查代碼的人稱做觀察員（或導航員）。兩個程序員常常互換角色。 

如何將結對編程帶入團隊？

咱們的作法由一個懂得結對的人分別和團隊裏每個人進行結對。結對前，詳細說明結對可能遇到的狀況，好比雙方有爭執，一直都是一我的寫的狀況，雙方都遇到不懂的狀況……而後，結對時穿插結對編程的知識。

團隊成員中的兩個都沒有結對編程的經驗，怎麼辦？

實際狀況是咱們遇到更麻煩的事情。

由於我在前端不擅長，因此我決定讓兩名前端結對。問題來了，這兩我的都不會結對，在溝通方面也不是很是擅長。讓他們結對後，我發現他們一塊兒結對的時間很是少，一天下來基本就是各作各的。這時，我發現不對勁。我就分別找他們談。爲何要分別呢？是但願他們大膽說本身的感覺。

在和他們談了以後，發現根本緣由是他們沒有徹底理解結對編程的目的。這時，找到他們倆再重申一遍結對編程是爲了什麼，以及如何結對。

新人對結對編程經常有的疑惑？

他在寫代碼，我看着有什麼用？

軟件開發是一項集體腦力活，知識的流動在這項活動中很是關鍵。結對編程是促進知識流動的行爲。

看別人寫代碼的人，咱們稱爲「觀察者」。寫代碼的人，咱們稱爲「駕駛員」。觀察者的職責是對寫代碼的人的代碼進行審查。其實除了這點，我更看重的是這個分享思惟方式的過程，會加速雙方的成長。這個過程還能營造一種相互學習的文化。

我以爲我一我的一會兒就寫完了

說這句話的人的能力不會差。其實有這樣的想法很正常。這時，咱們就鼓勵他多分享。當我深究下去時，他說寫那些東西根本不須要動腦。還很得意的樣子。不知道大家有沒有發現其中的問題：他在作體力活。更大的問題是：他還不知道本身在作體力活。這時，我會說：當你在作體力活時，和機器沒有區別，說明你在退步，這時，你應該跳出來，挑戰本身，好比coach別人，或找到一種避免這種體力活的方法。

若是你有什麼疑惑，可在本文評論留言。

如下是小結

每日站會，代碼審查，結對編程實踐的前後順序的？

本質上是沒有前後順序的。可是若是你是一位新來的leader，你就須要考慮你加入的團隊的狀況了。咱們是先施行每日站會，代碼審查。最近一個月纔開始實施結對編程。爲何呢？由於對這些編程實踐，若是強硬推行，可能會受到排斥。你須要時間讓團隊成員消化。

給人留下「什麼都管」的印象

因爲我帶來了這些新的實踐，看到團隊成員實踐過程的一些問題就會指出，因此常常給人「什麼都管」的印象。

當leader什麼都管時，leader要問本身爲何什麼要管，而團隊成員也要反問本身爲何什麼都要被管。排除leader的性格問題外，大多數時，是由於團隊還處於比較初級的階段。你問問本身，團隊裏有多少人能夠本身作leader的就知道了。leader應該跟你們說清楚這點。這樣你們就理解你了。可是這個「初級」的階段要多長時間？就要看你何時培養出另外一個leader了。

你會發現我在本文沒有談什麼M捷或者精Y，是由於我想就事論事，不想談理論，只想解決實際問題。

問題來了，你發現團隊中沒有人會結對，你做爲leader不懂得如何結對編程時，怎麼將結對編程帶入團隊中呢？

這時就須要請外援了。好聽一些，請諮詢顧問。若是你以爲看了個人文章，以爲我還行，也能夠找我。我在開源中國衆包發佈了一個專家服務： 將每日站會、代碼審查、結對編程帶入團隊

固然，你以爲看這文章對你有幫助，也能夠打賞10元：