Alpha 過後諸葛亮

前言

• 過後諸葛亮？做業名真的很差聽，下一屆還要沿用嗎？

• 隊名：小白吃

• 通向hjj博客的任意門

---

思考總結

設想和目標

1. 咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？
   • 咱們軟件很明確的定義爲，解決食堂用餐結算點單效率低下的問題
   • 典型用戶：在校大學生
   • 典型場景：大學食堂
2. 咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)?
   • 原計劃功能：自選菜品自主結算，非自選菜品在線點單，用餐數據分析反饋
   • 實現狀況：
     • 自主結算和在線點單功能已基本實現，除支付環節由於資質問題暫時難以實現
     • 數據分析功能，已實現「猜你喜歡」菜品推薦模塊
   • 交付和用戶：軟件功能基本實現，但實際投入使用存在困難，暫時沒法投入使用
3. 用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?
   • 暫未投入使用，用戶實際接受成度未知
   • 產品完成度好，固然離目標更近了
4. 有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?
   • 總體實現難度大，若是重來一遍，會考慮換個項目

計劃

1. 是否有充足的時間來作計劃?
   • 計劃老是趕不上變化，最開始的計劃根據進度不斷調整，到最後就拋棄了計劃，趕+肝
2. 團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？
   • 計劃階段討論都很順利，沒有太多不一樣的意見，可能這也是不足的地方。
3. 你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?
   • 團隊總體項目推動很順利，alpha版本的計劃都作完了
4. 有沒有發現你作了一些過後看來不必或沒多大價值的事?
   • 後敬甲：在alpha答辯裏，作了現場演示環節，但出了bug評估下來反而成了減分項
   • 劉浩：額外作了數據集，花費大量時間，後期並無用到
   • 澤明：訓練了多批數據集，最後只用到一個權重，利用率很低
   • 葛亮：不少界面沒有一塊兒討論，最後沒有對接到項目中
   • 黃澤：瞭解了後端的知識，沒有實際應用（由於被大佬搞完了）
   • 靜茹：找了不少圖標和設計的一些界面，沒有所有用到
   • 文斌：最開始使用的編程語言沒有選擇好，花了一些時間學習其餘的知識
5. 是否每一項任務都有清楚定義和衡量的交付件?
   • 沒有，你們都在一塊兒作，溝通都很及時，沒有絕對標準，標準隨時溝通調整，你們都以爲ok就直接整合對接
6. 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?
   • 沒有徹底按照計劃進行，計劃老是調整中
   • 前端界面在一開始的設計不夠規範，後期實施中不少界面不得不推翻重作
   • 風險主要是熬夜+時間，固然也估計到了
7. 在計劃中有沒有留下緩衝區，緩衝區有做用麼?
   • 有緩衝區：睡眠+翹課
   • 有用，deadline前的效率都至關高，有時間就有產出
8. 未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）
   • 在團隊合做方面，仍是繼續和之前同樣，團隊在一塊兒工做是最重要的，基本一週七天會有五天晚上都在一塊兒
9. 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
   • 後敬甲：
     • 在團隊的合做中，收穫了不少課程之外的東西，很重要但很差描述
     • 若是能重來，要參與到項目的編碼工做中去，才能更好跟進進度
   • 劉浩：
     • 基本瞭解並參與了整個小程序的開發流程（全棧工程師瞭解一下）
     • 若是能重來，要提升效率和溝通，避免沒必要要的熬夜
   • 澤明：
     • 學習到以項目進程和做業deadline，來驅動本身學習。
     • 若是能重來，我要作前端
   • 葛亮：
     • 瞭解了小程序的開發流程，前端開發的知識。
     • 若是能重來，會選擇不買書，去百度
   • 黃澤：
     • 學到了不少前端語言和知識。
     • 若是能重來，會全面、有條理、計劃地學習小程序開發
   • 婧茹：
     • 學到了前端的界面製做知識和認識到本身和大佬的差距
     • 若是能重來，會選擇專一前端製做，好好學習
   • 文斌：
     • 學到了推薦算法和加深了對python的使用
     • 若是能重來，我必定拉個隊友，不想一我的剛了，同時也會提升本身的學習效率

資源

1. 咱們有足夠的資源來完成各項任務麼?
   • 咱們完成了任務，但時間和資金的資源限制，沒有作到完美
2. 各項任務所需的時間和其餘資源是如何估計的，精度如何?
   • 時間主要是按任務量估計，時間按各自的安排估計
   • 精度很差，不能老是保持高效且時間安排總會有意外的衝突
3. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?
   • 測試沒有系統、詳細的安排，在最終整合以後，有作了簡單的測試，沒有花費不少時間
   • 人力資源足夠（即使咱們組人數最少），硬件缺一個好的GPU服務器來提升算法的速度
   • 美工是作的很很差的一點，在後期實施上出了不少問題，低估了難度
4. 你有沒有感到你作的事情可讓別人來作（更有效率）?
   • 這個問題很挑事兒，沒有問你們
5. 有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?
   • 後敬甲：
     • 分工不夠仔細、明確，對你們配合效率有必定影響
     • 若是能重來，要把分工作的更加明確，有調整要及時通知到你們
   • 劉浩：
     • 選題會要從新考慮，考慮到本身的時間和精力支配
     • 若是能重來，好好考慮選題
   • 澤明：
     • 代碼命名很差，給編程帶了不少額外的麻煩
     • 若是能重來，會作好代碼規範，培養好的編程習慣
   • 葛亮：
     • 原型設計時，沒有參考開發文檔，設計界面不夠規範，後期有不少界面須要返工重作，浪費了不少時間
     • 若是能重來，會在一開始學習好開發文檔，遵守貴伐開發界面
   • 黃澤：
     • 沒有規範好界面，不少界面在後期都作了大面積調整甚至重作
     • 若是能重來，會在一開始溝通並肯定好界面，避免後期的大幅度調整甚至重作
   • 婧茹：
     • UI設計不夠規範，開始的時候用手稿代替工具設計，在後期形成了許多麻煩
     • 若是能重來，會好好學習UI設計，作好界面的設計
   • 文斌：
     • 對python的使用不夠熟練，致使使用的時候常常得查找資料
     • 若是能重來，會好好的，系統的學習python，熟練對python的使用

變動管理

1. 每一個相關的員工都及時知道了變動的消息?
   • 咱們隊在團隊編程這點作的很好，基本天天都會在雙創一塊兒工做，因此有變動你們都會及時知道
2. 咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?
   • 一開始就決定了主體功能，主體功能沒有調整過，附加功能都屬於可推遲（但並無推遲）
3. 項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?
   • 能作到實現除支付功能外的其它功能就好
4. 對於可能的變動是否能制定應急計劃?
   • 沒有提早制定應急計劃，但有變動時會及時作出反應和調整
5. 員工是否可以有效地處理意料以外的工做請求？
   • 你們的及時調整都很棒，對於意外的發生也能作出迅速的反應
6. 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
   • 一塊兒工做真的很重要！！！

設計/實現

1. 設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？
   • 整個模式的設計是在項目初期，由pm和老師溝通商定的
2. 設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？
   • 沒有
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？
   • 有UML圖來幫助設計，也有不少的設計素材網站爲咱們提供了不少tu'pian'su'cai圖片素材
4. 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？
   • 文檔更加豐富了，會在項目推動中，不斷完善、更新文檔
5. 什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?
   • 支付功能整個就是個bug，由於資質不夠沒法申請微信支付
   • 尚未發佈
   • 有想到，但確實沒法申請，但在軟工角度來說，這只是其中一個模塊，不能由於這個模塊放棄整個項目
6. 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
   • 現階段沒有執行代碼複審，也沒有嚴格的代碼規範

測試/發佈

1. 團隊是否有一個測試計劃？爲何沒有？
   • 有制定詳細的驗收標準，但沒有詳細的測試計劃
   • 「完成，比完美更重要」，現階段已完成項目爲主
2. 是否進行了正式的驗收測試？
   • 否
3. 團隊是否有測試工具來幫助測試？
   • 暫未考慮
4. 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？
   • 暫未考慮
5. 在發佈的過程當中發現了哪些意外問題？
   • 支付功能未解決，暫時不考慮發佈
6. 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
   • 仍是以完成項目功能爲首要任務，測試方面暫時沒有精力、時間考慮

團隊的角色，管理，合做

1. 團隊的每一個角色是如何肯定的，是否是人盡其才？
   • 團隊角色肯定，以尊重我的意願爲首要因素，再根據實際狀況協商肯定角色
2. 團隊成員之間有互相幫助麼？
   • 固然，天天的工做都是和諧友愛、互幫互助的~
3. 當出現項目管理、合做方面的問題時，團隊成員如何解決問題？
   • 我要感謝團隊中的每個人，感謝你們的努力和付出，感謝你們的互相幫助和配合，每一個人個性、能力都不一樣，但咱們都在求同存異，互相配合，每一個人都很nice！

總結

1. 你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?
   • 屬於CMMI一級，完成級
2. 你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?
   • 磨合基本完成，接下來是規範
3. 你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?
   • 你們彼此更加熟悉，互相的配合會比以前更有效率
4. 你以爲目前最須要改進的一個方面是什麼?
   • 任務驗收的規範化作的很差，在alpha階段美工方面出了很大問題，沒有溝通好界面的設計，以後會增強溝通、明確目標
     5.對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。
   • 圍繞有積極性的我的構建項目，給予他所需的環境和支持。咱們在alpha階段，劉浩同窗在除了完成我的的後端部分之外，對團隊其它成員及其負責的部分，都有很大的幫助。
   • 在團隊內部，最具備效果而且富有效率的傳遞信息的方法，就是面對面的交談。團隊在雙創有實驗室，因此咱們基本天天都會在雙創一塊兒工做，在此特別感謝盧哥哥爲團隊申請的場地

上照片！

（歡迎在alpha階段後加入的新同窗：安哥和小白! PS:後敬甲的頭真的放不進去了）

---

答辯總結

團隊貢獻比

成員	alpha衝刺	alpha答辯	貢獻比
敬甲	機動+UI設計	ppt修改+任務分配+演示視頻拍攝+博客整理	14
葛亮	自選模塊界面製做	休息	13
黃澤	首頁+非自選模塊製做+接口對接	界面功能臨時優化、調整	16
靖茹	我的信息界面製做+數據週報界面製做	答辯演練+現場記錄	13
澤明	視覺識別算法訓練及優化	答辯演練+ppt修改	13
文斌	猜你喜歡算法	ppt製做及演講	13
劉浩	後端服務器配置及部署+先後端對接+任務分配	界面功能臨時優化、調整	18

本組現場答辯分數

組號	對本組的評分
1	76
2	79
3	77
4	70
5	75
6	82
7	81
8	81
9	76

平均分：77.86

提問及回答

• 問題收集與回答

第1組
一、微信支付的資質問題在beta階段有機會解決嗎?

答：emmm，若是作得完，考慮註冊個公司試試？（手動狗頭）

二、是否考慮用本身的主機進行內網穿透運行相應算法彌補雲服務器算力不足的缺點?

答：目前以完善功能模塊爲主，服務器性能問題暫時先不考慮。

三、在高併發場景下,服務器如何保證運行效率,是否會出現識別時排隊等待識別結果的現象?

答：使用gunicorn輔助flask框架實現併發功能，實現並行檢測，因爲服務器條件比較簡陋因此效果不是很明顯

第2組
一、在商家店鋪界面購買的食品到店自取嗎，根據什麼憑證來取食品？

答：在商家店鋪界面購買的食品由顧客去檔口自取，會設計排號碼

二、假若掃描不出食品，是否可以進行自主選擇？

答：能夠，識別不出菜品屬於低機率問題，如若出現，用戶能夠進入店鋪勾選所選菜品後繼續支付，而且提供反饋報錯機制。

三、商家端具備哪些具體的功能？

答：商家端主要包括：在線店鋪管理功能和流水管理功能

第3組
一、好像價錢計算有誤，有一份圖是17塊，是個人錯覺嗎，有這麼貴嗎？

答：價錢計算並無錯誤，價格是在標註數據集時咱們本身標註的，並無嚴格按照實際狀況去標註，因此現場演示出現了價格高於實際狀況的問題，以後會去實際落實價格更改數據庫

二、如何解決錯誤識別致使的用餐延誤問題，是否變相的使得本來快捷的目的失去了意義？

答：識別錯誤已經控制在極小機率（現場演示有瑕疵，是由於拍手機上的圖片會有摩爾紋影響），以後會繼續完善、下降錯誤率

三、對於高併發狀態下，響應速度會樂觀嗎？

答：使用gunicorn輔助flask框架實現併發功能，實現並行檢測，因爲服務器條件比較簡陋因此效果不是很明顯

第4組
一、識別上仍然存在必定的誤判率，誤判的結果導向偏嚴重，是否存在大量擴充數據集相似的改進方式？

答：誤判率已經控制在較低機率，後期會繼續擴充數據集、訓練算法，以進一步下降誤判率

二、是否考慮了響應時間？

答：服務器的性能對響應時間影響較大，後期若是資金足夠會更換響應時間

三、價錢計算貌似存誤，是否考慮從新計算？

答：價格計算不存在問題，只是在數據集標註時未按實際狀況標註，後期會實際落實更改數據庫

第5組
一、若是識別錯誤而致使少付了錢，事後有沒有可能發現？

答：咱們會爲商家和學生均提供反饋申訴機制

二、若是識別錯誤或響應較慢，是否反而下降告終帳效率？

答：識別速度會在以後有資金的狀況下更換服務器，能夠大幅提升結算速率。

三、請問大家會從哪些方面改進大家的算法？

答： 主要是兩個方向：提升識別速率和擴大識別範圍

第6組
一、您好，菜品識別出錯，支付完成以後，是否有設計申訴反饋的功能？

答：會在後期設計申訴反饋機制

二、您好，單核的服務器難以支持軟件開發，考慮怎麼解決嗎？

答：後期在有資金支持狀況下，會更換服務器

三、您好，怎麼進一步提升圖片識別的精確度?

答：會繼續拍攝數據集，訓練算法，提升識別精度和識別種類

第7組
一、服務器問題可否找出較爲合理的解決辦法？

答：但願後期能有機會使用更好的服務器。

二、現場演示出現了未識別出的狀況，可是仍直接進入結算界面，這樣是否是會對賣家形成損失，有沒有考慮識別精確度

答：現場演示的照片是在手機上拍的，摩爾紋對識別結果影響很大，實際狀況在已有菜品種類中，識別精度很高，錯誤機率很低

三、手動標註的工做量巨大，是否考慮其餘有效的辦法？

答：目前是沒有其它有效的辦法，只能靠隊員本身來完成

第9組
一、若是出現掃描出錯的狀況，致使商家少收入和學生多付錢的狀況該怎麼辦？

答：識別出錯，咱們會提供給商家和學生端雙向的申訴反饋機制。

二、對於不是碟裝的菜品可否也能很好的識別？

答：咱們的識別計算功能目前值針對，自選的碟裝菜品

三、食堂就餐時間時對該程序的使用是高併發的，那麼如何解決高併發問題？

答：使用gunicorn輔助flask框架實現併發功能，實現並行檢測

---

PSP與學習進度條

PSP表格

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

學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時（小時）	累計學習耗時（小時）	重要成長
4	0	340	5	25	Leangoo工具學習
5	300	640	15	40	哈希算法、優先隊列、結構體等c++內容複習
8	0	640	10	50	d代碼方面暫無
10	0	640	5	55	Github代碼管理學習、leangoo工具完善
12	100	740	5	60	瞭解了些python，寫博客能力++
13	200	940	10	70	寫博客繼續++、ppt製做++、錄屏++、頭髮--、睡眠------