答：我們的軟體要解決的是包括北航在內的全國高校物理實驗的問題。定義比較清晰，對典型使用者和典型場景有比較清晰的描述，在需求規格說明書中有。
答：專案經理第一周花了較多的時間進行整體的規劃與設計，在後期細化任務的時候至少提前三天根據不同的執行力和效率將大任務細分為小任務。所以還是有充足的時間用來做計畫。
答：計畫階段我們曾經就使用什麼語言的後端框架產生過分歧，最終解決方法也很簡單，無條件服從框架設計者的建議。
答：使用者量達到了預想，活躍使用者量超過了預期目標。經驗教訓就是：軟體開發是以使用者需求為核心進行主導，不是以技術核心為主導，需要在行動前調查清楚使用者的真實需求。如果重來一遍，我們會考慮讓大家自由選擇任務的種類與範圍，根據自己的能力選擇。
答：沒有全部做完，到答辯展示為止，一直也沒有做完1091實驗處理的支援。沒有做完是因為錯誤地估計了處理實驗資料與報告所需要的時間，並且後期根據使用者投票動態優先選擇了1021作為殺手級實驗，所以1091實驗處理暫時擱置。
答：有。因為安排的失誤，專案經理在過程中讓某位同學去收集預習報告，但是由於該同學收集的方式方法不對，所以導致預習報告的質量較差，最終沒能發揮其價值。
答：並不是。關於一些學習的任務雖然專案經理有要求交付一些demo但是由於涉及領域過大，專案經理本身也無法衡量那個demo做出是否是該學習成本帶來的比較好的成果。其他任務都有較清楚的定義與交付結果的說明。
答：未來計畫將考慮到每個人每天合適的時段與技術能力，爭取還是在固定領域範圍內進行分配任務。加班這點本身估計在β階段要常有了，編譯課設和其他科目考試的壓力隨之而到，還有像隊員參加了像馮如杯這樣的比賽，每週都要開組會，所以時間相比α階段少了很多。
答：在團隊開發的過程中可能會遇到之前定的計畫或任務不合理的情況，這種情況下需要動態調整區域性計畫，將計畫調集成理，不能一直根據過時的計畫嚴格執行，那樣執行效果會有很大折扣。如果重來一遍，我希望能在最開始的時候就制定好每個人合理的學習範圍，早點開始學習相關知識。
答：我們之前是沒有足夠的資源的。最終是專案經理花錢購買了網域名稱，買了阿里雲的2g記憶體的伺服器（不是9.9！）並且完成了網域名稱備案等工作。考慮到網域名稱和推廣的便捷性，最終沒有使用老師發放的伺服器。
答：各項任務的時間和學習成本均控制在一天4小時範圍內可以完成的情況下，估計方法就是根據經驗和大致的熟練度以及孜孜不倦的跟蹤進度、報告與重新估算，精度相對比較高。
答：在**上線前對於主流的十個瀏覽器進行了全方位的黑盒測試，並且進行了5次伺服器壓力測試。最終在優化latex編譯的情況下能夠支援無延遲併發16個人同時生成實驗報告，在更換伺服器記憶體為2g後，能支援到40人以上。對於不需要程式設計的資源略微低估難度，但是在ui方面投入比較大，並且為了減輕前端邏輯的壓力採用了前端友好的方案實現。
答：實話來說，如果再有人能幫我（專案經理）做點模版替換的**就好了，鍋太多有點累啊。
答：暫時沒有什麼太多這方面的經驗教訓…
答：大部分時候是的，但有些時候（比如聯絡不上的時候）沒法通知到全部。
答：我們根據初期的使用者投票和問卷調查，決定了推遲某些實驗的處理，提前了一些比較熱門的實驗的處理的優先順序，根據使用者
答：這一點我們專案做得不夠好，沒有足夠明確的清晰的出口條件
答：這個沒有….
答：這個應該可以處理，專案經理給定工作請求時會通過結對程式設計的方式給予一定的新手入門和指導，從而能夠有比較好的處理問題的能力和針對具體問題有著具體的解決方案。
答：這一點上我們覺得做的還是相對較好，重來一遍我們在這方面會更加積極與更加注重結對程式設計。
答：因為團隊專案的需求早就提前確定好了，是由專案經理和框架設計者一起完成的。
答：有，我們團隊的處理方法是一起找一些demo。或者誰有經驗聽誰的，比如框架就完全交給邢浩來做，前端交給魯聃，latex生成pdf的可行性和有效性是由我提出的。
答：設計上我們使用了mockplus進行原型設計，但是在測試方面非常遺憾，我們本次沒有使用除黑盒和灰盒測試外並沒有設計標準的單元測試來保證資料處理的正確性，這是本次團隊專案中最大的失誤。
答：資料處理部分產生的bug最多，因為本身沒有進行單元測試。每個資料處理檔案最終版都有約600行左右，所以沒有單元測試的情況下很難保證其正確，尤其是它還要涉及到與latex文字檔案的互動時。在設計與開發時一開始是為了減少隊員的學習成本，預想著是專案經理最後來做測試…最後發現鄒老師說的真對，誰負責的誰做單元測試最好，否則**交付的質量很難保證。
答：**複審是由嚴格的管理層次進行的，資料處理的主程式設計師、前端工程師、後端工程師的**都需要經過我的複審。大部分**是遵從**規範的，沒能做到所有的都嚴格執行**規範。
答：針對我們專案本身的特點，我們覺得測試先行是比較好的方式。在開發程式完成之前，需要先經過測試才可以成功交付。
答：原先是打算開發完後測試的…後來發現黑盒測試好做，單元測試被忽視了，一開始計畫沒到位。
答：進行了正式的驗收測試，測試了10個瀏覽器上約40項的顯示效果與功能情況。
答：做壓力測試時使用了乙個本來是用來攻擊**的工具，一開始觀察了一下執行xelatex時所耗記憶體，後來發現居然有200m有餘，最後發現三個無延遲併發伺服器就宕機了，資料庫的連線會被沖毀。在比較了pdflatex、lualatex等多種編譯系統後，使用了記憶體占用最小的編譯系統pdflatex，它一次執行占用約20~30m。在壓力第二次測試時還是比較樂觀，30次併發無延遲**服務崩潰，但是伺服器沒有宕機。第三次測試時表明16個併發無延遲生成報告操作是支援的最高上界。最終我們在前端使用了2s以內隨機延遲的post請求時間來減緩同時併發的資料量，最終認定可以發布。
答：發布後遇到了幾次因為伺服器阿里雲內建掃瞄程式而導致記憶體過小的情況，這種情況使用者訪問延遲非常高，後來通過一些優化手段大致解決了這個問題。
答：測試先行是有必要的，如果歷史重來一遍，即使有學習成本我們也要每個開發人員都進行單元測試。
答：我覺得團隊目前的狀態屬於已定義級別，有維護的標準文件，有嚴格的**複審流程，團隊協作比較協調。
答：我覺得我們團隊目前還是處於磨合階段，雖然我很想說我們團隊進入了規範階段，但是確實沒有。整個目標與框架的設計有幾位隊員還是不太理解 ，目前了解整個流程與工作路徑的人只有我和前端工程師和後端工程師、資料處理組的組長，還有兩位同學目前沒有參與過乙個流程的開發來，下個階段會逐步引導他們體會完整地操作流程。
答：既然沒有前乙個里程碑，我們這個里程碑所做之事是種奠基，也是一種開創。我認為我的團隊在本個里程碑中展示出的團隊協作是相當不錯的。
答：最需要改進的就是測試的方面。
討論**：
專案經理大出血，大家一起慶功宴（看我的表情tut，笑得最歡的是吃的最多的！！）
Alpha階段事後分析
團隊計畫的任務都已經完成，計畫內容可以檢視我們的github issue，關閉的issue都是已經完成的任務計畫。根據前幾次部落格的燃盡圖也可以看出，我們團隊在alpha階段最開始進度慢於預期，主要是因為團隊成員對於前端頁面開發都不熟悉，邊學邊開發需要消耗大量時間，但是在alpha階段的後期我們團隊...
Alpha階段事後分析
我們軟體要解決的問題在我們的專案功能規格書中定義得很清楚。對典型使用者和典型場景也有比較清晰的描述。但是問題在於我們在並沒有優先去實現課程評價 的最核心功能，所有工作任務的優先順序並沒有定義好。我們團隊花費了充足的時間來計畫每個任務，具體在專案管理可見。我們預估了每個專案的完成所需時間。我們alph...
M1的事後諸葛亮
原先不知道還有這個，所以比較晚。下面進入正題 我們組負責的是學霸系統中webui方面的使用者管理。經過四個星期的奮鬥 plan coding review 算是基本完成了alpha版本。一下是對於m1階段開發的一些總結以及感悟 1.設計很重要。在m1的開頭，對專案整體的把握不是很好，導致設計上有一些...