項目總結 模式 IV 學習 緊急 依然 成功 最新 雙向

團隊項目用戶驗收評審——《WAP團隊》

1、驗收準備的相關文檔鏈接：

2、驗收意見的驗收意見表鏈接：

3、關於源代碼管理的10 個問題

（1） 你的團隊的源代碼控制在哪裏？用的是什麽系統？如何處理文件的鎖定問題？ 我們的項目在github上托管，采用git的方式進行版本控制，這個是我們在開發伊始就達成的共識，針對這種多人多任務的開發模式，我們認為git是再好不過的選擇，於是我們從開發到現在一直采用這種方式
我們團隊的在處理文件的鎖定問題上是不加鎖的，也就是說我們的成員可以自由遷入遷出。由於現階段的開發規模比較小，於是為了最大化效率，我們沒有對文件遷入遷出進行過多的限制。將文件在遷入遷出時加鎖，顯然可以保證源代碼修改的同步性，減少不必要的沖突和錯誤，但是這樣的缺點是顯而易見的，由於缺乏了並行性，項目開發的效率就被極大地降低了，極端情況下很有可能因為一個人的失誤，導致全隊項目的擱淺。反之，我們采用自由遷入遷出的方式，則與前者的優缺點互反了。的方式，則與前者的優缺點互反了。 （2） 如何看到這個文件和之前版本的差異？ 如何看到代碼修改和工作項 （work item），缺陷修復 （bug fix) 的關系。 github進行更新後，可以看到本地的版本和最新的版本之間的不同之處。 同時，在本地上傳自己的文件到分支之後也可以查看自己或者是別人上傳的文件在以前的版本的基礎上，修改了哪些地方。 點開項目的commit的記錄，點擊相應的SHA版本哈希值之後可以進入到如下的頁面 我們在上面圖片裏面可以看到的是”+”標註的是在原文件的基礎上增加的代碼的記錄，”-“標註的是在原文件的基礎上刪掉的代碼的部分，顏色顯示也不同。 其實我們團隊是以任務為單位和模塊進行的開發，這種開發模式在任務分配之處就已經給該任務提供了描述。 之後在完成任務push之前還要在commit時加上任務完成情況的描述，方便我們在以後通過git log指令產看相應的git的記錄。這樣的雙向映射的機制保證了我們每一次提交的版本目的明確，特征鮮明。 (3) 如果某個文件在你簽出之後已經被別人修改，並且簽入了，那麽你在簽入你的修改的時候， 如何合並不同的修改（merge)? 你用了什麽工具來幫助你？ 在git中執行合並即可自動合並Git修改的部分。但是，也存在無法自動合並的情況。如果在遠程數據庫和本地數據庫的同一個地方都發生了修改的情況下，因為無法自動判斷要選用哪一個修改，所以就會發生沖突。另外，git會顯示本地數據庫和遠程數據庫同一個地方的不同修改，這時候就需要我們手動解決沖突，暫時沒有想到什麽好的工具可以解決不借助人力自動解決這個問題，只能依據規定和協商解決這一問題。 （4） 你有20個文件都是關於同一個功能的修改，你要如何保證這些文件都同時簽入成功（修改的原子性），或者同時簽入不成功？ git作為一個成熟的源代碼版本管理系統本身就可以保證在簽入時的原子性，所以在我們的項目開發流程中沒有遇到部分修改可以上傳而某些部分的修改不能上傳的混亂狀態。
(5)你的PC 上有關於三個功能的修改， 但是都沒有完成，有很多文件處於半完工的狀態，這時你要緊急修改一個新的 bug，如何把本地修改放一邊，保證在幹凈的環境中修改這個 bug, 並成功地簽入你的修改 --- changelist management。 （6）規範操作和自動化 （7）如何給你的源代碼建立分支？ (8) 一個源文件，如何知道它的每一行都是什麽時候簽入的，為了什麽目的簽入的 （解決了哪個任務，或者哪個bug）？ （9） 如何給一個系統的所有源文件都打上標簽，這樣別人可以同步所有有這個標簽的文件版本？ 一般來說我們會有兩個版本的‘Last Known Good’，一個是剛寫完的源代碼，另一個是經過運行測試之後的調整源代碼。我們會采取後面這種版本，因為一般來說這是較優的那種。然後在上傳到github上，根據commit記錄大家就可以同步這個版本。

（10）你的項目的源代碼和測試這些代碼的單元測試，以及其他測試腳本都是放在一起的麽？ 修改源代碼會確保相應的測試也更新麽？你的團隊是否能部署自動構建的任務？

我們沒有選擇自動測試，也沒有在Git上支持自動測試，測試都是自行手動測試，保證編譯和運行正常。

4、驗收過程

本次驗收主要是采用團隊互評的方式，兩個團隊根據各自準備好的相關的驗收資料分別對各個小組的開發的系統進行驗收。每個組分工好角色，在驗收場景，通過甲方、乙方的方式進行驗收，記錄人員記錄驗收的情況，最後總結。

5、實施過程場景照片

6、團隊成員的具體分工、占整個實驗任務的工作量比例及完成各自任務的實際時間

小組成員	具體分工	占整個實驗任務的工作量比例	實際時間
馬宏偉	後臺、前端完善，系統演示	19%	7h
周欣	前端完善，博客撰寫，資料整合，項目主持	20%	8h
烏勒紮	PPT制作、系統演示前準備	17%	6h
杜有海	過程文檔	14%	3h
馬麒	實施文檔	15%	3h
郝明宇	驗收過程相應資產填寫及校隊	15%	3h

7、各成員項目總結

（1）周欣：每一次都認真對待，認真去做，無論結果如何，好與壞，依然努力。對於本次項目，雖然不是主要負責人，但是對於每一次作業實驗，我確實兢兢業業地去完成。但是，每一次結果卻都不理想，有可能別人覺得沒有什麽，但是對於付出了辛勞和努力的同學無疑是一種打擊，不但打擊了我們完成作業的信心，更是打擊了我們努力堅持的心。然而，最後，我想說雖然獲得的成績與付出不成正比，但是，也學到了方方面面很多知識，增益我所不能，如果再有這樣的學習機會，一定會換一種方式去對待。另外，在這最後，謝謝老師的指導，對於項目的不足之處，我們會繼續改進。

（2）馬宏偉：本次項目由團隊成員進行開發，代碼由我主導編寫，最終程序完成了基本功能，界面和詳細功能不夠完善，主要是詳細設計方面存在一些不足，以後會改進的。

（3）烏勒紮：我們的系統是從教師和學生的雙方利益出發而開發的。開發期間我們分工合作，發揮了各個隊友間的特長，以達到最好的效益和質量，因為能力的限制，每個人負責的模塊有大有小，但最重要的是大家的共同努力，大家都學到了很多東西，這個項目是對我們大三第二學期這半年來所學知識的一次總結和檢測，我們認為只有通過這樣的項目實訓，對我們所學知識的一次全面檢測，從而使我們認識到知識內容的不足和知識框架的缺陷之處，然後有的加以彌補知識。由於我們能力有限，做出來的和我們想象中的還差一點，我們會繼續努力做的更好，也很感謝我們的老師和助教團隊，為我們做了這麽多，因為有了這次的團隊經驗，我覺得對我們以後工作學習上都會有很大的幫助，無論做出來的如何，我們每個人都學會了制作軟件的過程。

（4）杜有海：此次實驗加深了對數據庫基本原理和理論的理解，鞏固了對系統分析與設計的應用，進一步提高我們綜合運用所學知識的能力。同時也發現很多學過的東西沒有理解到 位，不能靈活運用於實際，不能很好的用來解決問題。另外，在結對過程中，痛隊員之間的不斷磨合與努力，我們可以一步一步地改進我們的設計，提高我們的專業知識與能力等等。非常感謝擁有這樣的機會去學習。

（5）馬麒：任務的順利完成離不開老師的幫助和小組成員的共同努力，雖然我們小組只有幾個人，但我們是一個有組織，有效率，有團隊精神的小組。在任務的完成中有明確的分工，有共同的目標，讓我深刻的體會到什麽叫有效率的團隊。為以後的學習和處理此類問題有了很好的前車之鑒。

（6）郝明宇：此次實驗加深了對數據庫基本原理和理論的理解，鞏固了對系統分析與設計的應用，進一步提高我們綜合運用所學知識的能力。同時也發現很多學過的東西沒有理解到位，不能靈活運用於實際，不能很好的用來解決問題。隊員們分工合作，彼此相互學習到很多。

8、項目組總結

通過一學期的學習，七次團隊協作。到目前，基本上完成了項目的開發，前期所預想的功能也實現了。雖然有不足的地方，但我們會繼續改進，把系統完善，希望可以用於市場，起到應有的作用。雖然，前面的幾次學習有些東西被否定了，我們小組成員也受到了很大的打擊，付出了一個學期的努力，卻換來那不如意的成績。但是，最終，對於我們自己所做的東西，我們仍然會把它努力做好。另外，在這一學期的學習中也學到了很多知識，對於軟件的開發不再是一張白紙，至少我們知道開發軟件需要經過哪些過程，需要做哪些工作等等。還有，對於軟件的測試需要怎麽去做，有哪些測試的方法可以使用，用戶和開發人員能對軟件測試做什麽工作，對軟件的驗收我們要做哪些相關的準備工作等等。總而言之，經過本次的學習，使我們受益匪淺，增益我們所不能。

團隊項目用戶驗收評審——《WAP團隊》