軟體開發中團隊協作與開發流程

簡單，有效工作流程

在團隊協作中，不能想改什麼就改什麼，很多東西是互相依賴和制約的。

我的經驗：
允許同時check-out，這樣提高效率。

一般dev工作流程：

1。開始工作，選擇 work item.

2. sync/build/deploy/simple test, 確保你sync 的版本是能夠正常工作的，這樣可以避免混淆 - 是這個版本本來就有問題呢？還是我的修改導致了這樣的問題？

3。check out 檔案，開始修改。

4。個人測試，通過，在根據情況作必要的整合測試。

5。Code-review （什嗎？ 你們不用做 code-review？），根據code review 的意見在作修改。

6。認為可以check-in 的時候，先sync。再build，再deploy/verify 這樣才能保證check-in 不會導致 build break。

7。Check-in，記住要把 step1 的work item 在check-in windows 中加上。這樣別人才能知道你這個check-in是幹啥的。以後可以從work item 中的“link” 找到與之對應的check-in。

如果代碼合并（merge）的時候有衝突，後面check-in 的同學要負責保證代碼 merge 正確無誤。

另： 一個check-in 可以包括很多檔案，不要一個一個檔案地check-in，而是把所有檔案做成一個 shelfset （參見命令的解釋），把整個shelfset check in。 這樣保證操作的原子性（atomic） - 如果成功，所有檔案都會更新，如果失敗，所有檔案都不受影響。

Check-in Policies
目前，我們設定了三條Check-in Policy，大家在Check-in代碼的時候應該都感受到了：

1。禁止Multi Check-out

2。Check-in必須和Work Item相關聯

3。必須有Code Review

這3條Policy的設定是為了進一步控制Check-in Code的品質，避免代碼衝突。

但是現在遇到了一些問題，突出表現在“只要對一個檔案修改，就會自動check out……這個讓大家晚上的開發出現了不少衝突”。

鄒老師的文章，簡單，有效工作流程中描述了常規的團隊編碼的流程，我們在課上也講過。但是基於以下現狀，我們在開始的頭幾天還是需要把Check-in Policy設定的嚴格一些：

1。經過上次的討論，目前我們20個同學的工作基於同一份Source Control，不使用Branch。這會減少後期Merge的工作量，但對每一次Check-in的要求提高，遇到任何衝突必須馬上解決

2。大家對團隊開發模式還不是很熟悉，對ASP.NET，Community Server的編程模式還在探索之中，在這個過程中很可能修改了本不應該修改的代碼檔案

3。大多數時間不是用在修改原始碼，而是對原始碼的學習、探索中，這時對代碼的修改可能更多基於研究的目的，而不是添加新功能

要解決“只要對一個檔案修改，就會自動check out”的問題，可以在Souce Control中改一下設定，要求必須“明確”的Check-out。這樣大家在本地進行研究的時候不會出現衝突。當你確定要修改code時再check-out。

當然Single Check-out會影響並行開發的效率，我們會在大家逐漸熟悉VSTS的協作環境、流程，對Community Server的開發模式也有了一定瞭解後放寬Single Check-out Policy，但是大家仍然要盡量避免Multi Check-out的情況，以免在Merge時遇到太多的問題。

Daily Report
建議的Daily Report格式： 引用內容Highlights:

1. Blahblahblah…

2. Blahblahblah…

…

Lowlights:

1. Blahblahblah…

2. Blahblahblah…

…

To Do Next:

1. Blahblahblah…

2. Blahblahblah…

…

在Highlights部分總結一天的成果，如完成了哪些Work Items，是否有Feature實現，取得哪些進展，哪些工作是“On Track”的。

在Lowlights部分列出哪些是預期要做，但是沒有完成的，還有哪些沒有解決的問題（Open Issues），進度是否延遲。

To Do Next部分是第二天要開始/繼續的工作，即接下來的打算。這些內容應該發映在後面幾天的Highlights/Lowlights中。

PM可以從團隊成員的Daily Report以及Work Items完成的情況中瞭解整個項目的進度，當然，Face to face的溝通也必不可少。

千萬要避免的情況：每天的Daily Report都是Highlights，但裡程碑就是不能按計划到達……

分工合作 一個自主運行，自我發展，自我約束的境界

沒錯，接下來的工作需要大家自己來管理自己，展示你們團隊風采和協作能力的時候到了。

PM要Drive整個開發的進度，激勵團隊成員，做好團隊內部、團隊之間以及和老師之間的Communitcation工作，切記，PM是Communication Hub。

Dev Lead需要帶領大家進行一些技術痛點的攻關，促進技術討論，協商技術架構的制定。Dev Lead應該清楚的瞭解每個Dev面臨什麼樣的技術問題，有哪些Open Issues，並及時溝通資料庫、編程調用介面等涉及各組之間的依賴性、相關性問題。

Team Lead負責後勤、行政方面的工作，配合我們的各個“委員”做好他們的工作。

Milestone 制定開發階段的裡程碑（或者Internal Release)

從昨天的Review情況來看，很多人對Milestone還是不太理解。制定開發階段的裡程碑（或者Internal Release)，有幾個基本原則：

1。每個裡程碑儘可能獨立，有明確的、詳細的交付成果。必須清晰定義哪些Feature在M1實現，哪些在M2實現

2。裡程碑具有“二分性”，裡程碑只有“做完”和“沒做完”兩種狀態，90%,99%完成都不能算作裡程碑到達

3。沒有“計劃外”的裡程碑，也就是說當所有的裡程碑都到達後整個項目就應該已經完成，所有的任務都應該列到裡程碑中

4。裡程碑沒有按時到達預示著項目的風險，可以採取的措施：a)調整計劃；b)採取矯正措施補救進度拖延

5。各個Team應該把裡程碑進一步細分，以進行更精確的控制

Test
各個Team還有寶貴的一周時間對項目進行最後的完善。建議大家：

進行更多的Usability Test，讓你們的產品更好用，更易用
補充、完善Test Cases，對產品進行完整的測試
在Release之前至少要有一次Full Test Pass，即所有的測試案例通過
準備Final Presentation！

7 Habits of Highly Effective People《高效能人士的七個習慣》，提醒自己：

1、Be Proactive (積極主動)
2、Begin with the End in Mind (以終為始)
3、Put First Things First (要事第一)
4、Think Win Win (雙贏思維)
5、Seek First to Understand then to be Understood (知彼解己)
6、Synergize (統合綜效)
7、Sharpen the Saw (不斷更新)