Alpha階段事後諸葛亮會議記錄

此作業要求參見：

組名：可以低頭，但沒必要

組長：付佳

組員：張俊餘李文濤孫賽佳田良于洋劉欣段曉睿

答：取件幫主要解決東北師範大學淨月校區部分師生沒時間取快遞、不想取快遞而另一部分同學並不排斥取快遞這種兩極分化問題，力求在這二者之間達到乙個動態平衡。

該專案主要有兩個功能，功能一為發布快遞資訊（不想取快遞的人）；功能二為幫忙取快遞（有時間取快遞的人）。

對典型使用者和典型場景的詳細描述參見：檢視入口要求4立會內容部分。

答：有時間，我們小組在選題階段確定選題之後就花費了大量的時間來定義典型使用者、典型場景、需求分析、設計e-r圖、設計原型等。

答：一般是通過每日立會討論，當日會議master會在開會之前提出本次會議將討論的問題，每位組員提前整理自己的想法，會上討論。有不同意見時，組長綜合各位組員意見組織大家進行投票，大家都比較善於溝通，好的意見多數情況下會得到大部分組員的支援。

答：本專案alpha階段共有八名使用者，預計為小組開發人員，由於教師規定測試開發人員不算做使用者，因此重新授權八位使用者。使用者量沒有變化。使用者在幫取的時候更加注重送達時間和送達地點這一點是我們做設計的時候沒有想到的。

我們離目標確實更近了，目前該專案已實現幫取與發布功能。後續將持續優化。

答：原計畫的工作全部完成，且超額完成了beta階段部分工作。

答：沒有，所有的事情在後續工作中經過檢驗都是值得的。

答：是。教師規定的任務顆粒度，我們組在leangoo看板上具體制定了各項任務的負責人、截止時間、任務描述。此外組長會對每乙個有不一意見的任務進行解釋，因此每一項任務都有清楚定義和衡量的交付件。

答：基本上。因為小組每天都會召開立會總結昨日工作，如果該項工作完成會繼續制訂今日計畫；如果未完成，小組成員集體討論未完成原因，確認是否該項任務有一定難度，會重新制訂執行計畫和執行方式。故，該專案在alpha階段大方向始終按照計畫執行。

答：一般會設定緩衝區。例如一般會給任務設定乙個較早的deadline，以方便組長檢查修改。緩衝區為整個專案的按計畫完成增加了保障。

答：每個階段初始分析任務、安排任務比較瑣碎，需要組長更加了解本組人員；功能測試時間要安排的長一點；單元測試要更加全面。

答：學會了按照顆粒度分析任務，劃分任務。如果重來一遍，應該將任務劃分的更加細緻。

答：大部分任務截止時間是組長根據之前開發經驗制訂。例如乙個靜態頁面的時間，乙個查詢功能的時間，多數情況下按照功能來制訂。其他資源只是比較粗糙的制定乙個deadline，具體看執行人自由發揮，沒有考慮精度問題。

答：不富裕但足夠。

答：沒有。我們組成員之間隨著不斷地熟悉在制訂任務分配時有非常細緻的分工，完全依據個人精力和能力來分配任務。

答：經驗是在充分了解現階段任務的基礎上基於對本組成員的了解分配任務，這一點我們做的越來越好。教訓是任務分配要盡早，給開發留出比較充足的時間。如果重來一遍，我們會在alpha階段開始的前半天就制定出任務分配。

答：根據需求分析時制訂的要求，核心功能（幫取與發布資訊）必須實現。具體到問題細節，實現方法a較為困難則尋找實現方法b，若均困難且距離deadline有一定時間則務必實現，不可推遲。否則推遲。比如資料庫存快遞狀態不可以存文字必須存狀態**，原則是必須的，實現方法不限。

答：出口條件理解為「做好了」，能實現核心功能，且實現核心功能的方法符合邏輯，使用者體驗較好。

答：學會了精益求精和與人溝通。在實現的基礎上反覆修改是為了精益求精，修改之後及時告知夥伴以便對方及時更新**，也是對專案的一種負責。如果重來一遍，我們還會按照現在的形式進行，改進應該會是在checkin時對操作描述的更加清晰。

答：本專案先由**組前端成員設計出簡單的頁面，然後進行功能實現。功能實現後前端成員再進行檢查與美化完成詳細ui。是合適的時間，合適的人選。

答：有，但不多。功能性和美觀性抉擇時，選擇功能性。功能實現後再根據時間和能力進行美觀性的改進。

答：沒有運用單元測試（unit test），測試驅動的開發（tdd）、uml工具。運用了 leangoo看板、燃盡圖、todolist、版本控制來幫助設計和實現。測試時選擇開發ide預覽和手機端測試，感覺都挺有效的。

答：發布資訊功能模組bug最多。因為開發人員在新增資訊函式上有乙個衝突沒有解決，而雙方一直沒有發現。

答：我們學會了團隊開發時的版本控制。如果重來一遍，我們將會制訂書面版的**規範並嚴格執行，且每次更新**都要檢查衝突並解決。

答：沒有。時間比較緊張因此未進行。

答：沒有。

答：在手機端可以進行效能測試。從實際看這些測試有用，方便後續的debug和測試。目前對效能測試不多，改進是後續將加大對效能測試分析的力度。

答：發布的時候因為小程式審核需要一定的時間，所以只能對使用者進行單獨的授權才可以使用，但是不影響我們預計的八位使用者這個資料量。

答：經驗是要有乙個詳細的測試計畫，此次開發測試周期短，最後導致幾個遺留問題解決時間較長。如果重來一次，我們會制訂乙個比較好的測試計畫，進行單元測試、功能測試、效能分析等。