Alpha事後諸葛亮
隊名：計算機4班好朋友聯盟
組長部落格：組長部落格
作業部落格：作業部落格
**項目Postmortem **
設想和目标（2分）
(1) 我們的軟體要解決什麼問題？
我們的軟體主要解決使用者對想要買到未入駐外賣平台的食堂飯菜的需求。
(2) 是否定義得很清楚？
定義清晰明白。
(3) 是否對典型使用者和典型場景有清晰的描述？
對典型使用者和典型場景具有清晰的描述。
(4)我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)
大部分目标已經實作，原計劃的功能做到了十二個，都是按照原計劃傳遞時間進行傳遞，原計劃中在alpha階段還未安排使用者數量。
(5)使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼?
因為在alpha階段還未安排使用者數量，是以目前并不知道最終使用者量是否與預想一緻，但作為使用者來看待這款産品，我們對重要功能的接受程度差不多打分到及格，仍然還有許多要完善的部分。
(6)我們離目标更近了麼?
感覺完成了許多部分之後，我們感覺離目标正在逐漸接近。
(7)有什麼經驗教訓?
前端和後端在實作需要統籌安排好，到後期再協商容易造成進度的延緩并且改動也會更加困難。
(8)如果曆史重來一遍, 我們會做什麼改進?
改進：任務越早開始越好，盡量不要拖到ddl，容易壓力過大。
計劃（5分）
(1) 是否有充足的時間來做計劃?
是，我們一開始花了一定的時間來進行整個階段的規劃。
(2) 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
團隊會進行互相讨論，或是在開會時一起協商，最後選取多數人的意見進行采納。
(3) 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
原計劃的工作已基本完成。
(4) 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
沒有，整個階段都在進行學習打代碼和進行有必要的交流讨論。
(5) 是否每一項任務都有清楚定義和衡量的傳遞件?
是的。
(6) 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
基本符合計劃的進度進行，在這個過程中項目未出現過比較大的意外。
(7) 在計劃中有沒有留下緩沖區，緩沖區有作用麼?
有留下緩沖區，緩沖區能夠有效地緩解團隊時間安排不當而造成的困難，避免時間過于緊張。
(8) 将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
打算修改計劃中對小程式的登入綁定設計，對趕工時間也要進行修改。
(9) 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
我們學到了如何進行更好的統籌規劃，認識到了整個團隊按計劃推進進度的重要性。如果重來一遍，我們會在前期就趕工并選擇合适的布局，緩解後期加班加點的狀況。
資源（3分）
(1) 我們有足夠的資源來完成各項任務麼?
有，團隊資源相對來說是比較充足的情況。
(2) 各項任務所需的時間和其他資源是如何估計的，精度如何?
各項任務所需時間是通過日常做作業時所花時間和參考别的小組完成進度來進行估計的，精度大約能達到百分之七十。
(3) 測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
測試時間比較不足，人力和軟硬體資源相對來說還好，勉強足夠；對不需要程式設計的資源難度估計相差不多。
(4) 你有沒有感到你做的事情可以讓别人來做（更有效率）?
沒有，大家的效率都差不多。
(5) 有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
經驗教訓：應該合理安排手上的資源，物盡其用，讓每個隊員都能領到自己擅長的任務，擁有最高的效率；
改進：将一些任務進行改動變更，使效率變得更高。
變更管理（4分）
(1) 每個相關的員工都及時知道了變更的消息?
是的，每個員工都能在群裡及時收到變更消息。
(2) 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
對于重要且必要的功能，我們将它定義為必須實作；對于相對來說不那麼緊急重要的，我們選擇暫且推遲它，等到下一階段完成。
(3) 項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
有，當一個頁面完整并且能夠實作對應的功能，并且結果正确，經過測試人員測試後體驗合格則為“做好了”。
(4) 對于可能的變更是否能制定應急計劃?
可以，小組會召開臨時會議進行讨論計劃。
(5) 員工是否能夠有效地處理意料之外的工作請求？
可以。
(6) 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
我們學到了在遇到一些突發狀況時需要迅速反應并做出好的判斷與決策；如果重來一遍，我們會努力使整理反應得更加迅速。
設計/實作（4分）
(1) 設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
我們組的設計工作是從撰寫需求分析報告之前開始的，原創圖檔主要由王玥來設計，原型界面的設計由萬聰和詩琳合作完成。是合适的時間和合适的人。
(2) 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
設計工作有時會有少許意見不統一的情況，一般都是大家一起在開會的時候讨論解決。
(3) 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？
有用到UML來設計用例圖、類圖和活動圖等，很有效。
(4) 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
現在的狀态跟項目開始的UML文檔有一點點差别，主要是我們目前的進度還未能完整的實作最初的計劃以及一些技術上的不足。差别不大，後期會盡量貼近最初的計劃，暫時不會更新UML文檔。
(5) 什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
由于目前的成果有限，是以就現在為止，釋出訂單的時候Bug最多，主要表現在已經釋出的訂單有時不會顯示在最上面，以及顯示的時候會出現一些死的資料。當時沒有想到是因為我們經驗不足，水準不夠，沒有考慮的這麼細緻。
(6) 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
我們前後端在開始編寫代碼之前已經編寫好了代碼規範，基本都有按照代碼規範來編寫代碼，是以之後主要做的是代碼的整合工作，代碼複審較為輕松。
(7) 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
這次沖刺，我們除了學到了自己所負責部分的相關技術，更懂得了團結協作的重要性，如果重來一遍，我們可能還是會像現在這樣，因為我們已經盡自己所能，做到了我們現階段能做到的最好的成果。
- 測試/釋出（3分）
(1) 團隊是否有一個測試計劃？為什麼沒有？
我們團隊在Alpha沖刺階段開始之前的那次會議就已經制定好了整個Alpha沖刺的計劃，其中就包括測試。
(2) 是否進行了正式的驗收測試？
是，我們有通過微信掃描二維碼來驗收目前的成果。
(3) 團隊是否有測試工具來幫助測試？
是，我們通過微信掃描二維碼測試過。
(4) 團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
我們團隊根據手機上掃描的二維碼顯示的實際情況來對産品進行測試，這些測試工作很有用，我們對頁面的排版進行了一些改進。
(5) 在釋出的過程中發現了哪些意外問題？
除了我們産品本身未完善的功能以外，在釋出的過程中未發生意外。
(6) 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
這次沖刺，我們除了學到了自己所負責部分的相關技術，更懂得了團結協作的重要性，如果重來一遍，我們可能還是會像現在這樣，因為我們已經盡自己所能，做到了我們現階段能做到的最好的成果。
- 團隊的角色，管理，合作（3分）
(1) 團隊的每個角色是如何确定的，是不是人盡其才？
團隊中每個人擔任什麼角色首先都是由我們自己來選擇的，先确定大的方向（前端/後端），再内部配置設定具體任務，集體的部分如部落格撰寫，評分之類則按照自願原則，一般采用輪換制。因為任務的領取都是自願的，是以一般都能做到人盡其才。
(2) 團隊成員之間有互相幫助麼？
有，我們團隊在空閑時都會集中在活動室一起完成任務，有問題可以互相求助。
(3) 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
我們團隊未出現此類問題，如果出現，一般會開會讨論共同解決。
每個成員明确公開地表示對成員幫助的感謝 ：
我感謝 __團隊中所有成員__對我的幫助， 因為某個具體的事情: 我們一起走到了現在。
我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
這次沖刺，我們除了學到了自己所負責部分的相關技術，更懂得了團結協作的重要性，如果重來一遍，我們可能還是會像現在這樣，因為我們已經盡自己所能，做到了我們現階段能做到的最好的成果。
總結:（3分）
(1) 你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
還在初始級。
(2) 你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
創造階段。
(3) 你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
大家的配合更加默契了，積極性也有所提高。
(4) 你覺得目前最需要改進的一個方面是什麼?
目前為止我們團隊主要的任務是完成剩餘的工作，暫時還沒有需要改進的地方，如果非要說的話，那就修複一下釋出訂單的bug吧。
(5) 對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
主張簡單：我們團隊的界面簡潔大方，一目了然，功能明确，無額外不必要的功能。
有目的的模組化：我們團隊在産品的實作過程中多次就使用者的角度讨論過産品的适用性。
三人行必有我師：我們團隊集中在一起完成這個項目，有問題互相幫助。
答辯總結
⭐工作流程
- 原型圖的設計和完善
- 前後端代碼規範的編寫
-
前端以頁面為機關配置設定任務
後端以類函數為機關配置設定任務
-
前端完成靜态頁面
後端函數編寫
- 編寫接口文檔，資料庫設計
- 伺服器的搭建和接口的測試
- 前端代碼整合
- 前後端資料互動
⭐組員分工及工作量比例
||||||||
|:--