Alpha衝刺之過後諸葛亮

• 組長博客
• 做業博客

項目Postmortem

設想和目標

咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

咱們的軟件針對的是福大學子來到食堂會猶豫不決沒法決定吃什麼的痛點，但願作出一款軟件能夠根據你們的口味幫忙決定吃什麼。其中，用戶只須要回答簡單的問題就能夠獲得結果，解決了廣泛存在的「選擇恐懼症」。軟件的定義仍是比較清楚的，這來源於咱們生活中本身也遇到的問題。在編寫需求規格說明書時，咱們對典型用戶進行了清晰的定義，而且經過問卷調查明確了市場上是存在對於咱們的軟件的需求的。

咱們達到目標了麼（原計劃的功能作到了幾個？  按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)

原計劃的目標大部分都已經完成。在實際的開發過程當中，咱們將一兩個功能放到了beta版本實現。

核心功能有在alpha衝刺結束時按時交付。儘管此次衝刺延期了一星期答辯，但大部分功能在一週前也已經基本完成。

咱們的軟件分爲學生端和商家端，目前完成了學生端的一個發佈版本，但尚未公開向用戶發佈。

和上一個階段相比，團隊軟件工程的質量提升了麼？ 在什麼地方有提升，具體提升了多少，如何衡量的？

上一個階段團隊尚未開始實際開發。若是說團隊現場編程做業是上一個階段的話，咱們團隊的軟件工程質量的確有提升。主要體如今如下幾個方面：

1. 任務分工更加清楚了，每一個人有明確的分工，你們之間的配合也從無到有，到熟練。
2. 有詳細的文檔編寫、代碼註釋風格要求。
3. 團隊成員的技術水平經過學習獲得了必定的提高。

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

在項目的規劃階段對於一些具體細節的思考度不足。例如討論時以爲都討論的差很少了，但具體實踐時具備難度不得很少佔用一些時間。

改進：提升本身的編程能力、以及對於編程語言和框架的熟練度頗有必要。

計劃

是否有充足的時間來作計劃?

以前有充分的時間來討論、構想整個軟件的框架，以前佈置的每一項做業——立項報告、需求規格說明書、UML圖繪製——都在不斷地讓整個軟件的輪廓在咱們的大腦中變得清晰。

團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？

在計劃階段基本沒有什麼不一樣意見的出現。

你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

基本完成。沒作完的部分有一部分須要較大的工做量而推到了Beta衝刺。

有沒有發現你作了一些過後看來不必或沒多大價值的事?

PM很早敲定了一些接口文檔，然然後來都廢棄了。接口文檔最後由後端實際設計先後端邏輯和設計數據庫的人來完成。可見的確PM不要涉及太具體的代碼部分的內容。

是否每一項任務都有清楚定義和衡量的交付件?

有的。在Alpha衝刺的初期，全組成員開會最主要就是討論清楚整個業務邏輯，討論完業務邏輯，咱們再細分出各個任務，例如前端由幾個頁面組成，後端要寫哪些接口，要設計幾個表等等，這些具體的東西就是具體的交付件。把每一項任務分配給各我的，造成詳細的任務分配。

是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

基本按照計劃運行。有一個意外就是前端組組長請假回家了，致使前端組有三天空檔期，沒有按照原來預想的進度進展下去。（沒辦法預估啊）

在計劃中有沒有留下緩衝區，緩衝區有做用麼?

原本是沒有緩衝區的。可是老師出差，答辯延期了一週。一會兒，隊員緊繃的神經都放鬆了許多。然而，這多餘的一週並無什麼實際的額外效果。由於咱們團隊在一週前也已經基本實現了大部分的功能。新的這一週，PM爲團隊新制定了一些額外的目標，但基本上都沒有完成。這一插曲能夠反映deadline是第一輩子產力這個經典的大道理。

未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

感受目前整個團隊的態勢發展良好，只要維持住目前的節奏就行了。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

趙暢：進度管理十分重要，是咱們學到的一課。Alpha衝刺進行到一半，這個時候忽然有一個額外的做業——團隊現場編程完成一個抽獎系統。這以前你們不緊不慢地學習框架學習語言，好像衝刺結束還有好多天，悠哉遊哉。做業下來了，這時候猛然發現你們實際產出代碼的能力是不足的，因而你們開始爆肝編程來解決這個問題。這項風險沒有估計到，只能說too young too simple. Alpha衝刺結束後再翻《人月神話》，第二章寫着「系統編程的進度安排背後第一個錯誤的假設是：一切都將運做良好，每一項任務僅花費它‘應該’花費的時間」。想起來是一套，作起來是另外一套。好似編程語言、各類工具都易於駕馭，信手拈來，然而實際的開發中是會遇到重重困難的，必定要儘早開始，重視項目的進度（須要PM和組長多把控）。若是重來一遍，必定會要求隊員儘快上手寫代碼，團隊儘快進入可以有實際產出的創造階段。

資源

咱們有足夠的資源來完成各項任務麼?

有的。前端、後端各有一位小組長。這兩位同窗起到了領導做用。學習資源的話，網上的資源十分豐富夠用。服務器方面，騰訊雲10塊錢一個月的產品也是徹底足夠應付目前咱們的玩具產品（感謝騰訊雲）。

各項任務所需的時間和其餘資源是如何估計的，精度如何?

其實一開始咱們敲定了各個任務，但沒有衡量這些任務的完成所需時間，說實話在一開始你們都是零經驗，很難有個肯定的數字。

趙暢：不過這個狀況在你真正去作了必定的開發後就有所改善，例如在有一天我完成用戶接口後，獲知寫一個敲定好邏輯的接口後臺代碼須要的時間數據：寫代碼3個小時，debug+本地測試大概須要兩小時。這部分時間這麼長仍是由於對於php和Web框架不熟悉的緣由。若是把後臺代碼部署到服務器上讓前端對接，在前端不熟練的狀況下要額外多出一天的時間預算。這樣子的精度仍是足夠的，方便PM和小組長把控進度。也方便其餘成員參考，留出多少時間段來進行開發。

測試的時間，人力和軟件/硬件資源是否足夠? 

測試的時間和人力不足夠，感受軟件還有不少缺陷，代碼也不夠完善。你們學習開發知識的同時還要應付考試，爲了完成基本功能就已經費神費心，基本任務完成就感受已經能夠交付了，對於測試和代碼的健壯性不是太上心。

對於那些不須要編程的資源 (美工設計/文案)是否低估難度?

PM：是。將頭腦裏的設想付諸實際，實際上是一件很難的事，在項目中的體現就是雖然閱讀了《material design》的設計教程，但要真正作出符合設計規範的UI界面比想象中困難不少。

你有沒有感到你作的事情可讓別人來作（更有效率）?

恆達：前端界面要個肯定的Ui和審美規格，重寫3次才用框架的我眼淚掉下來。

嶽昕：有的，我以爲我寫的接口後端組裏的大佬們大概幾分鐘就寫完了，而我花了兩三小時，因此有時候會以爲其實我好像能夠更適合web組，畢竟更多的開發經歷是html。大概這就是「羣佬我菜」的感受吧。

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

恆達：任務deadline的提早量若是能更精確就行了，這樣子有利於項目進度的把控。

變動管理

每一個相關的員工都及時知道了變動的消息?

Alpha衝刺時每兩日一次的站立會議交流算是一個很好的方法。此外，線上交流很方便。若是有線上聊天解決不了的技術細節問題，組內（前端組、後端組）或者整個項目組就會進行團隊現場編程來面對面解決。

咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

必須實行的功能就是項目的核心功能和Alpha衝刺實際開發過程當中遇到困難較小的功能。

推遲，通常是由於這個功能可能須要較大的工做量而Alpha衝刺的時間所剩無幾，這時你們就作出推遲到Beta衝刺時完成的決定。

項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

在需求規格說明書中的「Alpha驗收標準」有清晰的定義。

對於可能的變動是否能制定應急計劃?

由於需求和項目的具體邏輯是組內製定的，好像也沒有那種變化程度太過急劇或者有提出什麼十分刁鑽的需求以致於要到「應急」的程度吧。

員工是否可以有效地處理意料以外的工做請求？

項目初期對於任務的劃分基本上涵蓋了整個Alpha衝刺過程。幾乎沒有意料以外的工做變動。通常來講組長佈置給組員的額外的一些小任務（例如多加個按鈕，某個邏輯有點什麼小變動，多寫個接口之類的）團隊成員也能夠及時地完成。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

感受這部分咱們團隊作的仍是不錯的。

設計/實現

設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

在Alpha衝刺的初期，全組成員開會討論清楚整個業務邏輯。但這個不算真正的設計，由於不少內容和細節再實際開發的設計過程當中都由從新敲定。

UI原型設計主要由PM來負責。

到了實際編碼前的設計，例如設計邏輯、設計接口和表，主要由趙暢、王源和王彬來完成。（後端組組長和組員以及PM）

設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

由於都到設計階段了，有什麼模棱兩可的狀況出現都會討論清楚並敲定一個最終的方案。

團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？ 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

沒有運用單元測試，但有測試驅動的開發，每一個接口都有寫測試用例，雖然可能不是很完善。

有設計UML。UML是頗有效的，有的時候對於概念不清淅能夠打開類圖看看，在討論邏輯時打開用例圖和泳道圖幫助理清思路。

開始的UML和如今的文檔確定是有差異的。例如數據庫的字段名字、屬性類型，類圖中對於每個模型的定義或多或少有刪有減等。這些區別的產生是很天然而然的，這裏引用《人月神話》中的一句話：「對於創造者，只有在實現的過程當中，才能發現咱們構思的不完整性和不一致性。」

咱們卻是沒有更新最初的UML文檔，這些最初的UML圖都始終做爲參考，時不時地被打開。真正開發時用的接口文檔都是從新寫的。

什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

前端Android頁面出現的Bug最多，包括例如動畫效果在某些品牌的手機下會致使應用閃退，某些狀況下地圖數據在地圖上繪製不出地標等。緣由，就是在大多數狀況下（運行的好好的）咱們並不清楚是爲什麼致使了這些BUG。多是因爲安卓生態環境的碎片化，各家廠商並無遵循原生安卓的系統設計規範。還有就是有些Bug的產生觸及到團隊成員的知識盲區了。

代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

後端代碼由趙暢負責代碼複審，審閱代碼、註釋以及接口文檔。後端這方面工做作的仍是不錯的。

志煒（前端組組長）：前端組並無很嚴格地進行Code Review，大體merge到master大部分都是本身在進行的，部分存在沒有徹底遵照代碼規範的狀況。個人部分我以爲是沒問題的 我的認爲仍是時間成本的問題吧，但仍是應該規範起來，提升代碼的總體質量。 

測試/發佈

團隊是否有一個測試計劃？爲何沒有？

原本分佈了一位同窗專門負責測試，但最後這個計劃擱淺。

展瑞：由於我原本的任務是負責測試的，可是同時也在後端組作事。期間有一段時間學習了一下測試的相應知識，發現了本身在語言上和一些知識儲備都有相應的不足。開會的時候，基於咱們的代碼比較優秀的前提下，咱們以爲測試任務可能不須要採用自動化測試，並且人工來測試。因此測試計劃被拖後，直至死亡。

是否進行了正式的驗收測試？

在後端，每一個人都寫好接口文檔，都經歷本地的測試，以及服務器測試，才交付前端進一步開發。在整合系完全部功能後，手動考慮多種狀況進行測試驗收。

團隊是否有測試工具來幫助測試？

後端使用postman對每一個狀況都進行了測試。

團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？

頁面整合完後，在不一樣的機型上使用，出現了頁面切換出現一些bug，以及部分機型有閃退的狀況。

在發佈的過程當中發現了哪些意外問題？

發佈了alpha衝刺後的第一個版本，發現了沒有寫logout的按鈕。由於咱們有token機制來使得一名登錄的用戶保持兩小時的活躍狀態，超過兩小時未有操做就須要從新登錄。然而咱們忘了寫退出登陸的按鈕，若是token過時，就永遠沒法再登錄，須要重裝APP才能夠解決這個問題。是個嚴重BUG。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

恆達：假如能重來，會在前端組內更加積極的交流，在前端組內也寫上技術文檔，提升前端界面質量。

團隊的角色，管理，合做

團隊的每一個角色是如何肯定的，是否是人盡其才？

其實只有志煒算是一個熟練工，他做爲安卓前端組的小組長是當之無愧的。其餘人都是徹底的新手，在分配角色時是自願或被指定的，就很隨緣。

固然最後的結果是你們都發揮了本身的做用，大部分人都能作本身擅長的東西。

團隊成員之間有互相幫助麼？

PM：有的。咱們的管理方式爲三位一體：PM、前端組、後端組。前端組由志煒帶隊，志煒有實際的項目經驗，其餘成員有問題均可以請求幫助。

趙暢（後端組組長）：後端組內有造成一份組內本身的技術文檔，有任何問題均可以詢問組內成員或者直接查詢這份文檔，裏面不少問題都有組內成員積累的可行解決方案，省去了不少百度、google的精力。

志煒（前端組組長）：有的，本身Android也寫的比較多，遇到的坑，爬出來的坑，相對而言多一些吧，同組的遇到問題時，能給予一些幫助。使用過的工具也較多一些，也能給出一些推薦。  

當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

討論以後由PM、先後端組長做出決定。

每一個成員明確公開地表示對成員幫助的感謝 （而且寫在各自的博客裏）：

• 我感謝王源對個人幫助，由於和他一塊兒度過了幾個討論邏輯、寫代碼、debug、測試的夜晚。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

文垚（前端組）：我學會了Java和Android開發，特別是對Json數據的使用和理解，而且在隊友的教導下學會的git的使用。若是歷史重來一遍，和我會將回答問題界面的UI設計得再優美一點。

煌偉（Web端）：學到了一個團隊是如何合做運行，每一個人如何爲團隊更好地貢獻本身的一份力量。若是歷史重來一遍，我會在衝刺以前更加充分學習所須要的技能，而不是在衝刺階段邊學邊作

志煒（前端組組長）：若是是對於我我的而言，可能須要作的就是再肝一些吧，但這學期開頭肝了一個多月，快兩個月吧，因此有點想進入點養生狀態，因此這階段即便有熬夜也沒有特別晚就只到一點多兩點左右，天天差很少能夠說是事情都排得挺滿的，也勉強完成。

總結:

你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

咱們查閱了這個連接來了解CMM/CMMI是什麼。討論後認爲，後端組的工做以及達到了已定義級(Defined)，由於後端組有實現技術工做和管理工做的標準化、文檔化。後端組組長趙暢放出狂言「隨便來我的我都能培訓到他能寫代碼」。前端組水平介於初始級別(initial)和可重複級(Repeatable)之間。

你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?

後端組：整個團隊目前處於創造階段。

前端組有不一樣意見：規範階段吧，還有一些東西能再規範一些。

你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

對比Alpha開啓前，咱們項目組最重要的改進是真正的能產出代碼，以及對於任務須要的時間有一個度量的標準。還有就是你們對於軟件工程裏的一些概念有了切實的體會，例如文檔、項目進度管理、先後端的合做等。這些是隻聽理論課體會不來的。

你以爲目前最須要改進的一個方面是什麼?

趙暢（後端組組長）：Alpha衝刺初期花在學習基礎知識和熟悉框架、編程語言上的時間，應該提早去完成，須要提升積極性。

王彬（PM）：應該加強空餘時間的緊迫感，這樣才能避免出現突發事件時的措手不及。

文垚（前端組）：隊員之間的溝通交流還須要進一步的增強，特別是在遇到某些難題時，更應該積極溝通，一塊兒討論出解決方案。

對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。 

參照《構建之法》P114頁的敏捷開發原則，回顧咱們的Alpha衝刺過程，咱們作得比較好的有：

1. 第四條：「業務人員和開發人員在項目開發過程當中應該天天共同工做」。團隊現場編程是常有的事。
2. 第五條：「以有進取心的人爲項目核心，充分支持信任他們」。前端組和後端組各有一名組長，分組管理，在他們的帶領下每個組都把各自的工做完成的不錯。
3. 第六條：「面對面的交流始終是最有效的溝通方式」。例如Alpha站立會議、團隊編程、開會討論等等。
4. 第九條：「不斷關注技術和設計，才能愈來愈敏捷」。後端組有本身內部的技術文檔和全部接口設計文檔，積累了經驗。

團隊貢獻比例

組員	貢獻比例
趙暢	19
王源	16
王彬	15
志煒	15
文垚	10
恆達	7
煌偉	6
展瑞	6
嶽昕	6

答辯總結

小組現場答辯評分

• 去掉一個最高分，去掉一個最低分，小組最終得分爲79.86分

組號	組名	打分
1	爸爸餓了隊	80
2	拖鞋旅遊隊	79
3	彳艮彳亍隊	84
4	火箭少男100	75
5	起牀一塊兒肝活隊	81
6	404 Note Found隊	74
7	第三視角	81
8	小白吃	84
9	我頭髮呢隊	79

第二組的提問

問題1:提給用戶的問題是否多樣化？

• 答:咱們的問題庫中目前有40道問題,每次用戶須要推薦時咱們會從問題庫中隨機選出三道題供用戶選擇本身的口味,在beta咱們會酌情考慮擴充問題庫的規模.

問題2:商家端的功能會有哪些？

• 答:商家端將基於web提供服務,目前已經作好頁面的功能有菜品添加頁面,商鋪端註冊登入頁面,以後在beta階段咱們會繼續實現用戶口味分析報告頁面

問題3:地圖上的紅點太密集了，也沒有店鋪信息，可否出線一項展現推薦產品具體位置的食堂的平面圖？

• 答:地圖上的紅點表明每個店家的位置,紅點大小的問題咱們已經找到了解決方法,在後續會使得定位點的大小隨地圖縮放等級改變.至於用平面圖展現產品具體位置的功能咱們已經在alpha版本中有所考慮目前須要手繪食堂平面圖並收集各個店鋪的相對位置來支撐咱們的功能.

第三組的提問

問題1:用戶口味是長期造成的，若是用戶的選擇類型一致，會不會出現一直重複推薦某一道菜品的狀況？若是會，那麼大家是如何處理矯正的？

• 答:咱們也考慮到這個問題,因此咱們在alpha版本的推薦算法中只針對用戶明確拒絕的菜品更新用戶的口味,而且咱們的推薦算法並不僅推薦一道菜餚而是了機率排名前幾位的菜品隨機推薦給用戶,必定程度上預防重複推薦一道菜的狀況.

問題2:菜譜更新麻煩，我的感受若是要進行更新須要一個個去調查，過於麻煩，可否作到與商家合做，經過商家更新信息來作到實時更新

• 答:菜品更新只能靠人工這個問題咱們也很無奈,不過咱們是起步中的開發小組在食堂看來沒有什麼話語權,若是將來咱們獲得其餘方面的資源支持會考慮與商家合做更新咱們的菜品信息.

問題3:請問大家提供給用戶測試的題目有多少呢？真的可以準確的測試到嗎？

• 答:咱們的問題庫中目前有40道問題,每次用戶須要推薦時咱們會從問題庫中隨機選出三道題供用戶選擇本身的口味.用戶的口味是一個主觀的問題,咱們只能力求經過咱們的問題獲取用戶當時的一個口味偏好.

第四組的提問(暫無)

問題1:

• 答:

問題2:

• 答:

問題3:

• 答:

第五組的提問(暫無)

問題1:

• 答:

問題2:

• 答:

問題3:

• 答:

第六組的提問

問題1:您好，大家的PPT非常精美規範，具體介紹了大家的算法和代碼規範，這方面值得借鑑 。但UI界面設計就略顯遜色，有想過在這方面進行改進嗎。

• 答:分兩方面回答:1.PM我的喜歡簡潔大方的UI設計這在必定程度上反映到了產品的UI設計上,但美醜仁者見仁智者見智. 2.產品目前處在alpha開發階段咱們會在後期針對UI進行相應改進以期符合主流審美.

問題2:您好，大家的PPT顯示的實現功能看起來有點少，大家之前設下的功能還有多少未實現，能夠簡要說明一下嗎，若是已經所有實現，能夠說下後續是否會增長附加功能嗎?

• 答:在alpha開發階段咱們將開發精力放在了產品核心功能--菜品推薦上,在以後咱們的安卓端預計還會添加美食地圖的內容,店鋪風雲榜功能,以及提供用戶瀏覽推薦歷史記錄的功能,這部分功能的接口已經在alpha階段的後端設計中作了鋪墊,會在beta繼續完場上述功能.

問題3:大家軟件的商家功能還未實現，可見大家的進度稍慢，後續大家要調整本身隊的隊員分工和完成時間，來提升進度?

• 答: 在alpha階段咱們的前端將主要精力放在了開發安卓端應用上,但商鋪端的頁面咱們也已經基本設計完成但未在alpha答辯中展現出來:請看咱們的商鋪端頁面

第七組的提問

問題1:是否考慮過提供菜品的相關介紹？

• 答:鑑於並無現成的福大各個食堂的菜品介紹數據來源,而憑咱們目前的力量對每道菜添加菜品介紹也並不現實,因此咱們暫時不會考慮添加菜品介紹的功能.

問題2:地圖有不少地標，但是並不知道這些具體指示的是哪一家店？

• 答:鑑於目前數據庫中並無足夠的用戶信息,咱們會在beta階段將地標設置成顯示商品信息的按鈕,一旦按下地標就會顯示出該商家的店鋪信息與熱門菜餚.

問題3:若是提供多個備選的菜品我仍是不知道選哪個怎麼辦?

• 答:咱們的app只能作到提供就餐建議,最後用戶吃什麼的最終決定權屬於用戶

第八組的提問

問題1:推薦算法是否須要用戶的用餐數據？

• 答:咱們的推薦算法會參考用戶的過往選擇記錄,並根據每一個用戶的偏好生成用戶的口味畫像,在推薦時會依據用戶口味進行推薦決策

問題2:問答的問題與用戶的使用喜愛相關嗎？

• 答:咱們的問題庫中目前有40道問題,每次用戶須要推薦時咱們會從問題庫中隨機選出三道題供用戶選擇本身的口味

問題3:有沒有開發附加功能以增長用戶黏度的計劃？

• 答:咱們的產品理念是將app作成一款方便的工具,當用戶有不知吃什麼的選擇困難時就會想起咱們的app,而在其餘時間咱們也並不想搶佔用戶寶貴的時間

第九組的提問

問題1:PPT已經很完整的展現了功能，可是感受UI界面設計比較簡陋，在從此打算怎麼改善？

• 答:分兩方面回答:1.PM我的喜歡簡潔大方的UI設計這在必定程度上反映到了產品的UI設計上,但美醜仁者見仁智者見智. 2.產品目前處在alpha開發階段咱們會在後期針對UI進行相應改進以期符合主流審美.

問題2:PPT已經很完整的展現了功能，可是感受UI界面設計比較簡陋，在從此打算怎麼改善？

• 答:同上

問題3:在推薦菜品這方面打算怎麼處理？

• 答:咱們將繼續跟進商家的菜品更新

團隊討論合照

PSP

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

學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時(小時)	累計學習耗時（小時）	重要成長
1	500	500	12	12	單元測試的寫法
2	0	500	12	17	Axure RP 8 原型設計工具
3	300	800	16	33	C++爬蟲、regex正則表達式匹配
6	0	800	15	48	UML類圖的製做
7	0	800	20	68	軟件需求規格說明書的書寫
11	0	800	5	73	Laravel後端框架安裝，騰訊雲服務器部署，團隊git的使用
11	100	900	8	81	git分支操做、MVC模型、最基本的http信息傳遞、基本的Eloquent數據模型寫法
11	100	1000	6	87	git多個遠程分支同步操做、json發送與接收、http post方法、curl測試
11	200	1200	8	95	php後臺邏輯、移植數據庫、數據接口、前端頁面接收post表單返回值
12	300	1500	16	111	數據庫調錯、後端調錯、password_hash、timestamp字段
12	200	1700	5	116	git團隊合做
12	100	1800	5	121	postman測試
12	100	1900	3	124	數據庫編碼
13	0	1900	3	127	alpha結束，進行過後諸葛亮會議，暫無其餘技術上的收穫