第05組 Alpha過後諸葛亮

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) 對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。

主張簡單：咱們團隊的界面簡潔大方，一目瞭然，功能明確，無額外沒必要要的功能。
有目的的建模：咱們團隊在產品的實現過程當中屢次就用戶的角度討論過產品的適用性。
三人行必有我師：咱們團隊集中在一塊兒完成這個項目，有問題互相幫助。

答辯總結

⭐工做流程

• 原型圖的設計和完善
• 先後端代碼規範的編寫
• 前端以頁面爲單位分配任務
  後端以類函數爲單位分配任務
• 前端完成靜態頁面
  後端函數編寫
• 編寫接口文檔，數據庫設計
• 服務器的搭建和接口的測試
• 前端代碼整合
• 先後端數據交互

⭐組員分工及工做量比例

姓名	分工	工做量比例
方瑞雄	後端代碼編寫，博客評分彙總，編寫接口文檔，ppt答辯	10%
鄭裕恆	後端部分函數編寫，數據庫設計，ppt製做，爲前端提供圖片素材	11%
餘廷龍	後端發佈訂單，接單，查看歷史配送單，查看歷史點單四個接口的編寫；一次博客評分，全部接口的測試	10%
潘海東	後端：服務器的搭建，開發環境的配置，參與編寫接口文檔；前端：數據交互	10%
翁世豪	後端查看我的信息函數，刷新點單廣場函數，刷新訂單廣場函數，撰寫博客一次	8%
陳蘇蘇	前端個人訂單/點單，訂單詳情/點單（正在配送），訂單詳情/點單（送達）界面，評審表，撰寫博客一次，評分一次	8%
嚴欣	前端個人訂單/配送，訂單詳情/配送（正在配送），訂單詳情/配送（送達）界面，評審表，撰寫博客一次，評分一次	8%
馬麗華	前端發佈/點單，發佈/配送，修改/點單，修改/配送，填寫信息，註冊，登陸界面，撰寫博客一次，評分一次	8%
張萬聰	前端主頁/點單，下單界面，個人信息（已填）界面，整合前端全部界面，彈窗，小程序的發佈和管理，評分一次	10%
劉詩琳	前端主頁/配送，接單界面，個人信息（未填）界面，評分一次	9%
王玥	前端我的主頁，評價（收到的），評價（評價的），寫評價界面，原創圖片的設計，撰寫博客一次	8%

⭐本組現場答辯分數：

51.3

⭐Q&A

第1組：請問個人信息那裏是從哪裏修改的？視頻裏看到的彷佛沒有修改按鈕
  答：這個功能咱們會放到β版本完成，在α階段尚未這項功能。

第2組：如何保證安全，若是有和你有分歧的人特地接你單，而後給你加點料怎麼辦？
  答：如咱們一開始所說，咱們的用戶協議和評價機制會有效的規避這種風險，但若是發生此類事件咱們平臺也會介入調查；以及咱們也在考慮是否加入以前有同窗提議的功能，對打包好的飯菜貼個小封條等等使飯菜更加安全。

第3組：如何保障接外賣單羣體的安全性？
  答：咱們的羣體面向的是學生，不管點單人仍是接單人都是學生，這一部分羣體大多數都是高素質的，在必定程度上可以提升很多的安全性，加上咱們的安全保障機制（詳見上一條回答），可以使接外賣單的羣體更安全

第4組：如何保證相同的單子不會同時被多人接單？
  答：當一個單子被接後會及時從廣場退出，成功接單時也會彈出「接單成功」的提示，若是衝突，除了接單成功的人，其餘人就不會收到這個提示

第6組：後端沒法獲取手機號，能夠前端第一次登陸獲取
  答：謝謝建議，咱們會嘗試看看的

第7組：可否經過微信登陸？
  答：暫時還不能用微信登陸，可是能夠經過手機號來獲取到微信。

第8組：如今食堂的不少商家都加入了餓了麼，美團等平臺，因此是否再過一段時間大家的項目就沒用了？
  答：咱們的產品從一開始的定位就不一樣於餓了麼和美團，關於不少商家都有加入到餓了麼和美團的問題在以前的幾回答辯中咱們都有作出過回答，首先，咱們的用戶都是學生，而在用餐高峯期打飯的最多的也是學生，在這個時候即便有一些商家有配送外賣的服務也沒有閒暇在這個時候接單配送，在時間上，明顯由學生來帶飯更爲快捷；其次，在食堂中，有一些自助選菜等一些窗口沒法提供送外賣的服務，但咱們的學生能夠。

第9組：沒有按取消訂單時間送到就會取消訂單嗎？
  答：這個取現訂單時間是指發佈訂單後若是在取消訂單時間到仍是無人接單的狀況下改訂單會自動取消，避免發佈訂單的用戶繼續等待，原則上已經被接收的訂單沒法取消。

第10組：是否考慮過商家或外賣小哥也能夠接單，仍是說要限制羣體？
  答：咱們這款產品的出發點就是以學生爲用戶提供一個在宿舍就能夠吃到食堂沒法配送的飯以及讓學生順便賺取少許酬金的平臺，本質上和外賣平臺是有差異的，因此用戶會限制在學生羣體。

第11組：怎麼預防接單後對方忘記送達，是否能夠有一個提示模板？
  答：咱們的產品中會有配送員的電話等信息，點單人能夠隨時與配送員進行聯繫，不過你的這個建議很好，咱們會在以後的開發過程當中考慮加入提示信息。

第12組：爲什麼不採用微信提供的機制，如UnionID和OpenID標識用戶？
  答：以前因爲咱們技術上的一些不足未能實現這一功能，接下來咱們會嘗試完成這一部分。

⭐我的PSP表格

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	· 計劃	30	30
· Estimate	· 估計這個任務須要多少時間	30	30
Development	· 開發	120	240
· Analysis	· 需求分析 (包括學習新技術)	60	80
· Design Spec	· 生成設計文檔	0	10
· Design Review	· 設計複審	0	0
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	10	10
· Design	· 具體設計	10	20
· Coding	· 具體編碼	60	80
· Code Review	· 代碼複審	10	10
· Test	· 測試（自我測試，修改代碼，提交修改）	20	30
Reporting	報告	30	60
· Test Repor	· 測試報告	0	0
· Size Measurement	· 計算工做量	0	0
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	30	60
	· 合計	380	600

⭐我的學習進度條

第N周	新增代碼行數	累計代碼（行）	本週學習耗時（小時)	累計學習耗時（小時）	重要成長
1	90	90	14	14	學會了python
2	40	130	2	16	熟悉了墨刀，pyqt的使用
3	600	630	35	51	熟練了HTML、增強了代碼能力
4	0	0	5	56	主要了解了微信小程序的開發進程，並無打代碼
5	100	730	5	61	學習了數據庫
6（1）	200	930	6.5	67.5	學習了先後端接口的編寫
6（2）	0	930	5	72.5	搭建數據庫環境
6（3）	500	1430	10	82.5	用python操做數據庫
7（1）	100	1530	10	92.5	用python操做數據庫
7（2）	100	1630	10	102.5	用python操做數據庫
7（3）	100	1730	15	117.5	完成先後端交互
7（4）	0	0	3	120.5	完成PPT答辯

⭐全組合照