敏捷的協做

敏捷協做

按期安排會面時間

也許你我的很討厭開會，可是溝通是項目成功的關鍵。咱們不僅要跟客戶談話，還應該與其餘開發人員進行良好的溝通。

立會（站着開的會議）是將團隊召集在一塊兒，並讓每一個人瞭解當下進展情況的好辦法。顧名思義，參與者們不容許在立會中就作，這能夠保證會議快速進行。一我的坐下來以後，會因爲感到溫馨而讓會議持續更長的時間。

要保證會議議題不會發散，每一個人都應該只回答下述三個問題：

• 昨天有什麼收穫？
• 今天計劃要作哪些工做？
• 面臨着哪些障礙？

只能給予每一個參與者不多的發言時間（大約2分鐘）。也許要用計時器來幫助某些收不住話頭的人。若是要詳細討論某些問題，能夠在立會結束以後，再召集相關人員。

一般，立會都是在每一個工做日的早些時候，且你們都在上班時舉行。可是不要把它安排爲上班後的第一件事。要讓你們有機會從剛纔混亂的交通情況中回覆狀態，喝點咖啡，刪除一些垃圾郵件什麼的。要保證會議結束後又足夠的時間，讓你們在午飯以前作很多工做，同時也不要開始得過早，讓每一個人恨不得趕忙結束會議，去喝點東西。通常來講，在你們到公司以後的半個小時到一個小時以內舉行，是個不錯的選擇。

參與會議的人要遵照一些規則，以保證彼此不會分神，並且會議也不會跑題。這些規則有：

• 只有團隊成員能夠發言。他們必須回答上面的3個問題，並且不能展開深刻討論。
• 管理層能夠把要解決的問題記下來，可是不能試圖將會議從每一個人要回答的三個問題引開。

每日立會有諸多好處：

• 讓你們儘快投入到一天的工做中來。
• 若是某個開發人員在某一點上有問題，他能夠趁此機會將問題公開，並積極尋求幫助。
• 幫助團隊帶頭人或管理層瞭解哪些領域須要更多的幫助，並從新分配人手。
• 讓團隊成員知道項目其餘部分的進展狀況。
• 幫助團隊識別是否在某些東西上有重複勞動而耗費了精力，或者是否是某個問題有人已有現成的解決方案。
• 經過促進代碼和思路的共享，來提高開發速度。
• 鼓勵向前的動力：看到別人報告的進度都在前進，會對彼此造成激勵。

具體技巧

• 會議會佔用開發時間，因此要儘可能保證投入的時間有較大的產出。立會的時間最長不能超過30分鐘，10~15分鐘比較理想。
• 若是要使用需提早預約的會議室，就把預約的時間設定爲1小時吧。這樣就有機會在15分鐘的立會結束後，立刻召開更小規模的會議。
• 雖然大多數團隊須要天天都碰頭，但對於小型團隊來講，這樣作可能有點過頭了。不妨兩天舉行一次，或者一週兩次，這對小團隊來講足夠了。
• 要注意報告的細節。在會議中要給出具體的進度，可是不要陷入細節之中。
• 迅速地開始能夠保證會議短小。不要浪費時間等着會議開始。
• 若是以爲立會是在浪費時間，那多是你們尚未造成真正的團隊意識。這並非壞事，有利於針對問題進行改進。

架構師必須寫代碼

架構師應該負責設計和指導。做爲架構師，不該該只是畫一些看起來很漂亮的設計圖，說一些像黑話同樣的詞彙，使用一大堆設計模式——這樣的設計一般不會有效的。

一個設計要解決的是眼前面臨的特定問題，隨着設計的實現，對問題的理解也會發生改變。想在開始實現以前，就作出一個頗有效的詳細設計是很是困難的。由於沒有足夠的上下文，能獲得的反饋頁不多，甚至沒有。設計會隨着時間而演進，若是忽略了應用的現狀，要想設計一個新的功能，或者完成某個功能的提高是不可能的。

做爲設計人員，若是不能理解系統的具體細節，就不可能作出有效的設計。只經過一些高度高闊的、粗略的設計圖沒法很好地理解系統。

可逆性

不存在所謂的最終決策。沒有哪一個決策作出以後就是板上釘釘了。實際上，就時間性來看，不妨把每一個重要的決策，都看做是在變化以前所作出的預先規劃。

好的設計者必須可以捲起袖子，加入開發隊伍，絕不猶豫地參與實際編程。

要鼓勵程序員參與設計。主力程序員應該試着擔任架構師的角色，並且能夠從事多種不一樣的角色。它會負責解決設計上的問題，同時也不會放棄編碼的工做。程序員在拒絕設計的同時，也就放棄了思考。

具體技巧

• 若是有一位首席架構師，他可能沒有足夠的時間來參與編碼工做。仍是要讓他參與，可是別讓他開發在項目關鍵路徑上的、工做量最大的代碼。
• 不要容許任何人單獨進行設計，特別是你本身。

實行代碼集體全部制

任何具有必定規模的應用，都須要多人協做進行開發。在這種情況下，不該該像國家宣稱對領土的全部權同樣，聲明我的對代碼的全部權。任何一位團隊成員，只要理解某段代碼的前因後果，就應該能夠對其進行處理。若是某一段代碼只有一位開發人員可以處理，項目的風險無形中也就增長了。

相比找出誰的主意最好、誰的代碼實現很爛而言，解決問題，並讓應用知足用戶的指望要更爲重要。

當多人同時開發時，代碼會被頻繁地檢查、重構以及維護。若是須要修復bug，任何一名開發人員均可以完成這項工做。同時有兩個或兩個以上的人，能夠處理應用中不一樣部分的代碼，可讓項目的日程安排也變得更爲容易。

在團隊中實行任務輪換制，讓每一個成員均可以接觸到不一樣部分的代碼，能夠提高團隊總體的知識和專業技能。當Joe接過Sally的代碼，他能夠對其進行重構，消除待處理的問題。在試圖理解代碼的時候，他會問些有用的問題，今早開始對問題領域的深刻理解。

另外一方面，知作別人將會接過本身的代碼，就意味着本身要更守規矩。當知作別人在注意時，必定會更加當心。

可能有人會說，若是一個開發者專門應對某一領域中的任務，他就能夠精通該領域，並讓後續的開發任務更加高效。這沒錯，可是眼光放長遠一點，有好幾雙眼睛盯着某一段代碼，是必定能夠帶來好處的。這樣能夠提高代碼的總體質量，使其易於維護和理解，並下降出錯率。

具體技巧

• 不要無心間喪失了團隊的專家技能。若是某個開發人員在某個領域中機器精通，不妨讓他做爲這方面的駐留專家，並且系統的其餘部分代碼也對他開放，這樣對團隊和項目都頗有幫助。
• 在大型項目中，若是每一個人均可以隨意改變任何代碼，必定會把項目弄得一團糟。代碼集體全部制並不意味着能夠爲所欲爲、處處破壞。
• 開發人員沒必要了解項目每一部分的每一個細節，可是也不能由於要處理某個模塊的代碼而感到驚恐。
• 有些場合是不能採用代碼集體全部制的。也許代碼須要某些特定的知識、對特定領域的瞭解，好比一個高難度的實時控制系統。這些時候，人多了反而容易誤事。
• 任何人均可能遭遇到諸如車禍等突發的災難事故，或者有可能被競爭對手僱傭。若是不向整個團隊分享知識，反而增長了喪失知識的風險。

成爲指導者

教學相長
Knowledge grows when given.

與團隊其餘人一塊兒共事是很好的學習機會。知識有一些很獨特的屬性；假設你給別人錢的話，最後你的錢會變少，而他們的財富會增多。但若是是去教育別人，那雙方均可以獲得更多的知識。

經過詳細解釋本身知道的東西，可使本身的理解更深刻。當別人提出問題時，也能夠發現不一樣的角度。也許能夠發現一些新技巧——聽到一個聲音這樣告訴本身：「我之前尚未這樣思考過這個問題。」

與別人共事，激勵他們變得更出色，同時能夠提高團隊的總體實力。遇到沒法回答的問題時，說明這個領域的知識還不夠完善，須要在這方面進一步加強。好的指導者在爲他人提供建議時會作筆記。若是遇到須要花時間進一步觀察和思考的問題，不妨先草草記錄下來。此後將這些筆記加入到每日日誌中。

成爲指導者，並不意味着要手把手教團隊成員怎麼作，也不是說要在白板前進行講座，或是開展小測驗說明的，能夠在進行自備午飯會時展開討論。多數時候，成爲指導者，是指在幫助團隊成員提高水平的同時也提升本身。

這個過程沒必要侷限於本身的團隊。能夠開設我的博客，貼一些代碼和技術在上面。不必定是多麼偉大的項目，即便是一小段代碼和解釋，對別人也多是有幫助的。

成爲指導者意味着要分享——而不是固守——本身的知識、經驗和體會。意味着要對別人的所學和工做感興趣，同時願意爲團隊增長價值。一切都是爲了提升隊友和你的能力與水平，而不是爲了毀掉團隊。

具體技巧

• 若是一直在就同一個主題向不經過的人反覆闡述，不妨記錄筆記，此後就此主題寫一篇文章，甚至是一本書。
• 成爲指導者是向團隊進行投資的一種極佳的方式。
• 結對編程是一種進行高效指導的、很天然的環境。
• 若是老是被一些懶於本身尋找答案的人打擾。
• 爲團隊成員在尋求幫助以前陷入某個問題的時間設定一個時限，一個小時應該是不錯的選擇。

容許你們本身想辦法

「授人以魚，三餐之需；授人以漁，終生之用。」告訴團隊成員解決問題的方法，頁要讓他們知道如何解決問題的思路，這也是成爲指導者的一部分。

瞭解上個實踐——成爲指導者——以後，也許有人會傾向於直接給同事一個答案，以繼續完成工做任務。要是隻提供一些指引給他們，讓他們本身想辦法找到答案，這並非多麼麻煩的事情。這樣作有下面幾點好處：

• 你在幫助他們學會如何解決問題。
• 除了答案以外，他們能夠學到更多東西。
• 他們不會再就相似的問題反覆問你。
• 這樣作，能夠幫助他們在你不能回答問題時本身想辦法。
• 他們可能想出你沒有考慮到的解決方法或主意。這是最有趣的——你也能夠學到新東西。

若是有人仍是沒有任何線索，那就給更多提示吧（或者甚至是答案）。若是有人提出來某些想法，不妨幫他們分析每種想法的優劣之處。若是有人給出的答案或解決方法更好，那就從中汲取經驗，而後分享你的體會吧。這對雙方來講都是極佳的學習經驗。

具體技巧

• 用問題回答問題，能夠引導提問的人走上正確的道路。
• 若是有人真的陷入膠着狀態，就不要折磨他們了。告訴他們答案，再解釋爲何是這樣。

準備好後再共享代碼

相對不使用版本控制系統，更壞的情況是什麼？答案是：錯誤地使用了版本控制系統。使用版本控制系統的方式，會影響生產力、產品穩定性、產品質量和開發日程。特別地，諸如代碼提交頻率這樣簡單的東西都會有很大影響。

完成一項任務後，應該立刻提交代碼，不該該讓代碼在開發及其上多停留一分鐘。若是代碼不能被別人集成使用，那又有什麼用處呢？應該趕忙發佈出去，並開始收集反饋。

另外一方面，若是在任務完成以前就提交代碼，會帶來不少風險。這些代碼可能還有編譯錯誤，或者對其所作的某些變化與系統其它部分的代碼不兼容。當其它開發者獲取最新版本的代碼時，也會受到這些代碼的影響。

一般狀況下，提交的文件應該與一個特定的任務或是一個bug的解決相關。並且應該是同時提交相關的文件，並注有日誌信息，未來頁可以知道修改了哪些地方，以及爲何要作修改。一旦須要對變動採起回滾操做，這種「原子」提交也是有幫助的。

要保證在提交代碼以前，全部的單元測試都是能夠經過的。使用持續集成是保證源代碼控制系統中代碼沒有問題的一種良好方式。

代碼不執行提交操做的其餘安全選擇

• 使用遠程訪問
• 隨身攜帶：U盤
• 使用有帶底座擴展的筆記本電腦：解決多臺電腦上開發形成的延續性問題
• 使用源代碼控制系統的特性：分支與合併。能夠將代碼分爲主幹和開發者分支。

具體技巧

• 有些源代碼控制系統會區分「提交」和「可公開訪問」兩種代碼權限。此時，徹底能夠進行臨時的提交操做。（VS中TFS的擱置集？）
• 有些人但願代碼在提交以前能夠進行復查操做。只要不會太久拖延提交代碼的時間就沒有問題。若是流程的某個部分產生了拖延，那就修正流程吧。
• 仍然應該頻繁提交代碼。不能用「代碼還沒有完成」做爲避免提交代碼的藉口。（至少在開發分支上是如此。）

作代碼複查

代碼剛剛完成時，是尋找問題的最佳時機。若是聽任無論，它也不會變得更好。

代碼複查和缺陷移除

要尋找深藏不露的程序bug，正式地進行代碼檢查，其效果是任何已知形式測試的兩倍，並且是移除80%缺陷的惟一已知方法。

管理層擔憂進行代碼複查所耗費的時間。他們不但願團隊中止編碼，而去參加長時間的代碼複查會議。開發人員對代碼複查感到擔憂，容許別人看他們的代碼，會讓他們有受威脅的感受。

經過嚴格的代碼複查過程，能夠提交質量極高並且穩定的代碼。當開發人員完成某項任務的編碼和測試後，在簽入源代碼控制系統以前，會有另外一名開發人員對代碼作完全的複查。這個過程修復了不少問題，代碼複查不僅針對初級開發者編寫的代碼——團隊中每一個開發人員的代碼都應該進行復查，不管其經驗豐富與否。

那該如何進行代碼複查呢？

• 通宵複查：不太敏捷，不建議這種方式。
• 撿拾遊戲：當某些代碼編寫完成、經過編譯、完成測試，並準備簽入時，其餘開發人員就能夠撿拾起這些代碼開始複查。是一種快速而非正式的方式，保證代碼在提交以前是能夠被接受的。爲了消除行爲上的慣性，要在開發人員之間進行輪換。
• 結對編程：在極限編程中，不存在一我的獨立進行編碼的狀況，編程老是成對進行的。

在代碼複查中要看什麼呢？

• 代碼可否被讀懂和理解？
• 是否有任何明顯的錯誤？
• 代碼是否會對應用的其餘部分產生不良影響？
• 是否存在重複的代碼？
• 是否存在能夠改進或重構的部分？

此外，還能夠考慮使用代碼分析工具。若是這些工具產生的靜態分析結果對項目有幫助，就把他們集成到持續構建中去吧。

具體技巧

• 不進行思考、相似於橡皮圖章同樣的代碼複審沒有任何價值。
• 代碼複查須要積極評估代碼的設計和清晰程度，而不僅是考量變量名和代碼格式是否符合組織的標準。
• 一樣的功能，不一樣開發人員的代碼實現可能不一樣。差別並不意味着很差。除非你可讓某段代碼明確變得更好，不然不要隨意批評別人的代碼。
• 若是不及時跟進討論中給的建議，代碼複查是沒有任何實際價值的。可安排跟進會議，或者使用代碼標記系統，來標識須要完成的工做，跟蹤已經處理完的部分。
• 要確保代碼複查參與人員獲得每次複查活動的反饋。做爲結果，要讓每一個人知道複查完成後所採起的行動。

及時通報進展與問題

接受一個任務，頁就意味着作出了要準時交付的承諾。不過，遇到各類問題從而致使延遲，這種情形並很多見。截止日期來臨，你們都等着你在演示會議上展現工做成果。若是你到會後通知你們工做尚未完成，會有什麼後果？除了感到窘迫，這對你的事業發展也沒有什麼好處。

若是等到截止時間才發佈壞消息，就等因而爲經理和技術主管提供了對你進行微觀管理的機會。他們會擔憂你再次讓他們失望，並開始天天屢次檢查你的工做進度。

假定如今你手上有一個進行了一半的任務，因爲技術上的難題，看起來不能準時完成了。若是這時積極通知其餘相關各方，就等於給機會讓他們提早找出解決問題的方案。也許他們能夠向另外的開發人員尋求幫助，也許他們能夠將工做從新分配給更加熟悉相關技術的人，也許他們能夠提供更多須要的資源，或者調整目前這個迭代中要完成的工做範圍。客戶會願意將這個任務用其餘同等重要的任務進行交換的。

及時通報進展與問題，有狀況發生時，就不會讓別人感到忽然，並且他們也很願意瞭解目前的進展情況。他們會知道什麼時候應該提供幫助，並且你也得到了他們的信任。

發送電子郵件，用即時貼傳遞信息，或快速電話通知，這都是通報你們的傳統方式。還可使用「信息輻射器」，相似於牆體上的海報，提供變動的信息，路人能夠很方便地瞭解其中的內容。以推送的方式（海報、網站、Wiki、博客或者RSS Feed）傳遞信息，他們就沒必要再來問問題了。只要讓人們能夠有規律地查看到須要的信息，這就能夠了。

整個團隊可使用信息輻射器來發布他們的狀態、代碼設計、研究出的好點子等內容。如今只要繞着團隊的工做區走一圈，就能夠學到很多新東西，並且管理層也就能夠知道目前的情況如何了。

具體技巧

• 每日立會可讓每一個人都能明確瞭解最新的進展和形勢。
• 在展現進度情況時，要照顧到受衆關注的細節程度。好比，領導是不會關心一些實現細節的。
• 別花費太多時間在進展與問題通報上面，仍是應該保證開發任務的順利完成。
• 常常擡頭看看四周，而不是隻埋頭於本身的工做。