- 組長部落格
- 作業部落格
項目Postmortem
設想和目标
- 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們的軟體針對的是福大學子來到食堂會猶豫不決無法決定吃什麼的痛點，希望做出一款軟體可以根據大家的口味幫忙決定吃什麼。其中，使用者隻需要回答簡單的問題就可以得到結果，解決了普遍存在的“選擇恐懼症”。軟體的定義還是比較清楚的，這來源于我們生活中自己也遇到的問題。在編寫需求規格說明書時，我們對典型使用者進行了清晰的定義，并且通過問卷調查明确了市場上是存在對于我們的軟體的需求的。
- 我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)
原計劃的目标大部分都已經完成。在實際的開發過程中，我們将一兩個功能放到了beta版本實作。
核心功能有在alpha沖刺結束時按時傳遞。盡管這次沖刺延期了一星期答辯，但大部分功能在一周前也已經基本完成。
我們的軟體分為學生端和商家端，目前完成了學生端的一個釋出版本，但還沒有公開向使用者釋出。
- 和上一個階段相比，團隊軟體工程的品質提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
上一個階段團隊還沒有開始實際開發。如果說團隊現場程式設計作業是上一個階段的話，我們團隊的軟體工程品質的确有提高。主要展現在以下幾個方面：
- 任務分工更加清楚了，每個人有明确的分工，大家之間的配合也從無到有，到熟練。
- 有詳細的文檔編寫、代碼注釋風格要求。
- 團隊成員的技術水準通過學習得到了一定的提升。
- 有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
在項目的規劃階段對于一些具體細節的思考度不足。例如讨論時覺得都讨論的差不多了，但具體實踐時具有難度不得不多占用一些時間。
改進：提高自己的程式設計能力、以及對于程式設計語言和架構的熟練度很有必要。
計劃
- 是否有充足的時間來做計劃?
之前有充分的時間來讨論、構想整個軟體的架構，之前布置的每一項作業——立項報告、需求規格說明書、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、前後端組長作出決定。
- 每個成員明确公開地表示對成員幫助的感謝 （并且寫在各自的部落格裡）：
- 我感謝 _______<展瑞>___對我的幫助， 因為某個具體的事情: 幫助我完成食堂資料的錄入。
- 我感謝 _______<嶽昕>___對我的幫助， 因為某個具體的事情: 幫助我完成食堂資料的錄入。
- 我感謝 _______<志炜>___對我的幫助， 因為某個具體的事情: 為了團隊的辛苦不白費,冒着挂科的風險将安卓端各個頁面整合打包釋出apk。
文垚（前端組）：我學會了Java和Android開發，特别是對Json資料的使用和了解，并且在隊友的教導下學會的git的使用。如果曆史重來一遍，和我會将回答問題界面的UI設計得再優美一點。
煌偉（Web端）：學到了一個團隊是如何合作運作，每個人如何為團隊更好地貢獻自己的一份力量。如果曆史重來一遍，我會在沖刺之前更加充分學習所需要的技能，而不是在沖刺階段邊學邊做
志炜（前端組組長）：如果是對于我個人而言，可能需要做的就是再肝一些吧，但這學期開頭肝了一個多月，快兩個月吧，是以有點想進入點養生狀态，是以這階段即使有熬夜也沒有特别晚就隻到一點多兩點左右，每天差不多可以說是事情都排得挺滿的，也勉強完成。
總結:
- 你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
我們查閱了這個連結來了解CMM/CMMI是什麼。讨論後認為，後端組的工作以及達到了已定義級(Defined)，因為後端組有實作技術工作和管理工作的标準化、文檔化。後端組組長趙暢放出狂言“随便來個人我都能教育訓練到他能寫代碼”。前端組水準介于初始級别(initial)和可重複級(Repeatable)之間。
- 你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
後端組：整個團隊目前處于創造階段。
前端組有不同意見：規範階段吧，還有一些東西能再規範一些。
- 你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
對比Alpha開啟前，我們項目組最重要的改進是真正的能産出代碼，以及對于任務需要的時間有一個度量的标準。還有就是大家對于軟體工程裡的一些概念有了切實的體會，例如文檔、項目進度管理、前後端的合作等。這些是隻聽理論課體會不來的。
- 你覺得目前最需要改進的一個方面是什麼?
趙暢（後端組組長）：Alpha沖刺初期花在學習基礎知識和熟悉架構、程式設計語言上的時間，應該提前去完成，需要提高積極性。
王彬（PM）：應該增強空餘時間的緊迫感，這樣才能避免出現突發事件時的措手不及。
文垚（前端組）：隊員之間的溝通交流還需要進一步的加強，特别是在遇到某些難題時，更應該積極溝通，一起讨論出解決方案。
- 對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
參照《建構之法》P114頁的靈活開發原則，回顧我們的Alpha沖刺過程，我們做得比較好的有：
- 第四條：“業務人員和開發人員在項目開發過程中應該每天共同工作”。團隊現場程式設計是常有的事。
- 第五條：“以有進取心的人為項目核心，充分支援信任他們”。前端組和後端組各有一名組長，分組管理，在他們的帶領下每一個組都把各自的工作完成的不錯。
- 第六條：“面對面的交流始終是最有效的溝通方式”。例如Alpha站立會議、團隊程式設計、開會讨論等等。
- 第九條：“不斷關注技術和設計，才能越來越靈活”。後端組有自己内部的技術文檔和所有接口設計文檔，積累了經驗。
團隊貢獻比例
| 組員 | 貢獻比例 |
|---|---|
| 趙暢 | 19 |
| 王源 | 16 |
| 王彬 | 15 |
| 志炜 | |
| 文垚 | 10 |
| 恒達 | 7 |
| 煌偉 | 6 |
| 展瑞 | |
| 嶽昕 |
答辯總結
小組現場答辯評分
- 去掉一個最高分，去掉一個最低分，小組最終得分為79.86分
| 組号 | 組名 | 打分 |
|---|---|---|
| 1 | 爸爸餓了隊 | 80 |
| 2 | 拖鞋旅遊隊 | 79 |
| 3 | 彳艮彳亍隊 | 84 |
| 4 | 火箭少男100 | 75 |
| 5 | 起床一起肝活隊 | 81 |
| 404 Note Found隊 | 74 | |
| 第三視角 | ||
| 8 | 小白吃 | |
| 9 | 我頭發呢隊 |
第二組的提問
- 問題1:提給使用者的問題是否多樣化？
- 答:我們的問題庫中目前有40道問題,每次使用者需要推薦時我們會從問題庫中随機選出三道題供使用者選擇自己的口味,在beta我們會酌情考慮擴充問題庫的規模.
- 問題2:商家端的功能會有哪些？
- 答:商家端将基于web提供服務,目前已經做好頁面的功能有菜品添加頁面,商鋪端注冊登入頁面,之後在beta階段我們會繼續實作使用者口味分析報告頁面
- 問題3:地圖上的紅點太密集了，也沒有店鋪資訊，能否出線一項展示推薦産品具體位置的食堂的平面圖？
- 答:地圖上的紅點代表每一個店家的位置,紅點大小的問題我們已經找到了解決方法,在後續會使得定位點的大小随地圖縮放等級改變.至于用平面圖展示産品具體位置的功能我們已經在alpha版本中有所考慮目前需要手繪食堂平面圖并收集各個店鋪的相對位置來支撐我們的功能.
第三組的提問
- 問題1:使用者口味是長期形成的，如果使用者的選擇類型一緻，會不會出現一直重複推薦某一道菜品的情況？如果會，那麼你們是如何處理矯正的？
- 答:我們也考慮到這個問題,是以我們在alpha版本的推薦算法中隻針對使用者明确拒絕的菜品更新使用者的口味,并且我們的推薦算法并不隻推薦一道菜肴而是了機率排名前幾位的菜品随機推薦給使用者,一定程度上預防重複推薦一道菜的情況.
- 問題2:菜單更新麻煩，個人感覺如果要進行更新需要一個個去調查，過于麻煩，能否做到與商家合作，通過商家更新資訊來做到實時更新
- 答:菜品更新隻能靠人工這個問題我們也很無奈,不過我們是起步中的開發小組在食堂看來沒有什麼話語權,如果未來我們得到其他方面的資源支援會考慮與商家合作更新我們的菜品資訊.
- 問題3:請問你們提供給使用者測試的題目有多少呢？真的能夠準确的測試到嗎？
- 答:我們的問題庫中目前有40道問題,每次使用者需要推薦時我們會從問題庫中随機選出三道題供使用者選擇自己的口味.使用者的口味是一個主觀的問題,我們隻能力求通過我們的問題擷取使用者當時的一個口味偏好.
第四組的提問(暫無)
- 問題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界面設計比較簡陋，在今後打算怎麼改善？
- 問題2:PPT已經很完整的展示了功能，但是感覺UI界面設計比較簡陋，在今後打算怎麼改善？
- 答:同上
- 問題3:在推薦菜品這方面打算怎麼處理？
- 答:我們将繼續跟進商家的菜品更新
團隊讨論合照
PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | |||
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | ||
| · Analysis | · 需求分析 (包括學習新技術) | ||
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | ||
| · Coding | · 具體編碼 | ||
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | 130 | 160 |
| · Test Repor | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | 120 | 150 |
| 合計 | 135 | 165 |
學習進圖條
| 第N周 | 新增代碼 | 累計代碼 | 本周學習耗時 | 累計學習耗時 | 重大成長 |
|---|---|---|---|---|---|
| 300 | 初步了解基于python的網頁爬蟲原理，閱讀urllib和beatufsoup官方文檔 | ||||
| 學習Blasiq模型設計工具 | |||||
| 200 | 500 | 18 | 簡單python爬蟲編寫，爬取資料處理 | ||
| 580 | 1080 | 25 | 43 | 較複雜C++代碼邏輯的實作 | |
| 1230 | 48 | linux套接字程式設計 | |||
| 1530 | 54 | linux圖形界面程式設計 | |||
| 64 | 視訊制作技能提高、原型制作技能提高、了解MD設計規範 | ||||
| 67 | 圖示設計技能提高、視訊後期制作技能習得 | ||||
| 2030 | 91 | 安卓應用運作原理了解、github團隊代碼管理入門、Android前後端交換流程明晰、了解RESTful API的設計理念、對laravel架構的整體運作機制有初始了解、了解注冊登入背景實作邏輯的可能坑點、學會POSTMAN的基本使用方法 | |||
| 70 | 210 | 101 | 學習jQuery的基本知識,實操安卓UI的美化 |