高效程序員的45個習慣 敏捷開發修煉之道 讀書筆記 第八章 敏捷協做

按期安排會面時間

簡單立會(站着的會議)，保證會議快速進行。

每一個人都應該回答

1.昨天有什麼收穫？

2.今天計劃要作哪些工做？

3.面臨着那些障礙？

建議：若是要詳細討論某些問題，能夠在立會以後，在召集相關人員。

通常在上班後半個小時到一個小時以內舉行。

使用立會。立會可讓團隊達成共識。保證會議短小精悍不跑題。

團隊成員是豬（開發人員、產品全部者和協調者），非團隊成員（管理層、支持人員、QA等）是雞，

原本講的是農場裏的動物們打算一塊兒開飯店，準備用燻肉和雞蛋做爲早餐提供。對於雞來講要參與進來，對於豬來講，就要放血投入了。

 

架構師必須寫代碼（+1）

不要作powerpoint架構師，只會繪製各類各樣的設計圖，必須投入的編程中。

優秀的設計從積極的程序員哪裏開始演化。積極的編程能夠帶來深刻的理解。不要使用不肯意編程的架構師----不知道系統的真實狀況，是沒法展開設計的。

 

實行代碼集體全部制

讓開發人員輪換完成系統不一樣領域中不一樣模塊的不一樣任務。

固然有些代碼須要特定的知識，人多了反而容易誤事。

 

成爲指導者

分享本身的知識頗有趣——付出的同時便有收穫。還能夠激勵別人活得更好的成果，並且提高了整個團隊的實力。

你會感到給予別人教誨，也是提高本身學識的一種方式，並且其餘人亦開始相信你能夠幫助他們。

 

容許你們本身想辦法

給比人解決問題的機會。指導他們正確的方向，而不是直接提供解決方案。每一個人都能從中學到很多東西。

 

準備好後再共享代碼

毫不要提交還沒有完成的代碼。故意簽入編譯未經過或是沒有經過單元測試的代碼，對項目來講，應被視做玩忽職守的犯罪行爲。

但通常下班前都應該提交一下。

 

作代碼複查

複查全部的代碼。對於提高代碼質量和下降錯誤率來講，代碼複查是無價之寶。若是以正確的方式進行，複查能夠產生很是實用而高效的成果，要讓不一樣的開發人員在每一個人物完成後複查代碼。

 

及時通報進展與問題

每日立會能解決。