事後諸葛亮

前言

• 事後諸葛亮？作業名真的不好聽，下一屆還要沿用嗎？

• 隊名：小白吃

• 通向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
靖茹	個人資訊界面制作+資料周報界面制作	答辯演練+現場記錄
澤明	視覺識别算法訓練及優化	答辯演練+ppt修改
文斌	猜你喜歡算法	ppt制作及演講
劉浩	後端伺服器配置及部署+前後端對接+任務配置設定		18

本組現場答辯分數

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

平均分：77.86

提問及回答

• 問題收集與回答

第1組

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

答：emmm，如果做得完，考慮注冊個公司試試？（手動狗頭）

2、是否考慮用自己的主機進行内網穿透運作相應算法彌補雲伺服器算力不足的缺點?

答：目前以完善功能子產品為主，伺服器性能問題暫時先不考慮。

3、在高并發場景下,伺服器如何保證運作效率,是否會出現識别時排隊等待識别結果的現象?

答：使用gunicorn輔助flask架構實作并發功能，實作并行檢測，由于伺服器條件比較簡陋是以效果不是很明顯

第2組

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

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

2、倘若掃描不出食品，是否能夠進行自主選擇？

答：可以，識别不出菜品屬于低機率問題，如若出現，使用者可以進入店鋪勾選所選菜品後繼續支付，并且提供回報報錯機制。

3、商家端具有哪些具體的功能？

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

第3組

1、好像價錢計算有誤，有一份圖是17塊，是我的錯覺嗎，有這麼貴嗎？

答：價錢計算并沒有錯誤，價格是在标注資料集時我們自己标注的，并沒有嚴格按照實際情況去标注，是以現場示範出現了價格高于實際情況的問題，之後會去實際落實價格更改資料庫

2、如何解決錯誤識别導緻的用餐延誤問題，是否變相的使得原本快捷的目的失去了意義？

答：識别錯誤已經控制在極小機率（現場示範有瑕疵，是因為拍手機上的圖檔會有摩爾紋影響），之後會繼續完善、降低錯誤率

3、對于高并發狀态下，響應速度會樂觀嗎？

第4組

1、識别上仍然存在一定的誤判率，誤判的結果導向偏嚴重，是否存在大量擴充資料集類似的改進方式？

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

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

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

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

答：價格計算不存在問題，隻是在資料集标注時未按實際情況标注，後期會實際落實更改資料庫

第5組

1、如果識别錯誤而導緻少付了錢，過後有沒有可能發現？

答：我們會為商家和學生均提供回報申訴機制

2、如果識别錯誤或響應較慢，是否反而降低了結賬效率？

答：識别速度會在之後有資金的情況下更換伺服器，可以大幅提高結算速率。

3、請問你們會從哪些方面改進你們的算法？

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

第6組

1、您好，菜品識别出錯，支付完成之後，是否有設計申訴回報的功能？

答：會在後期設計申訴回報機制

2、您好，單核的伺服器難以支援軟體開發，考慮怎麼解決嗎？

答：後期在有資金支援情況下，會更換伺服器

3、您好，怎麼進一步提高圖檔識别的精确度?

答：會繼續拍攝資料集，訓練算法，提高識别精度和識别種類

第7組

1、伺服器問題能否找出較為合理的解決辦法？

答：希望後期能有機會使用更好的伺服器。

2、現場示範出現了未識别出的情況，但是仍直接進入結算界面，這樣是不是會對賣家造成損失，有沒有考慮識别精确度

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

3、手動标注的工作量巨大，是否考慮其他有效的辦法？

答：目前是沒有其它有效的辦法，隻能靠隊員自己來完成

第9組

1、如果出現掃描出錯的情況，導緻商家少收入和學生多付錢的情況該怎麼辦？

答：識别出錯，我們會提供給商家和學生端雙向的申訴回報機制。

2、對于不是碟裝的菜品能否也能很好的識别？

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

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

答：使用gunicorn輔助flask架構實作并發功能，實作并行檢測

個人部分

感謝

首先感謝黃澤在寫微信小程式前端代碼的時候對于我的騷擾沒有感到不适2333

感謝馬斌斌在我覺得無事可做的時候給我學習簡單的python資料可視化

感謝pm的心理輔導算嗎23333

感謝浩哥亮哥和盧哥哥的不曾嫌棄= =

• PSP表格

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

學習進度條

第N周	新增代碼（行）	累計代碼（行）	本周學習耗時(小時)	累計學習耗時（小時）	重要成長
	500		25		1熟悉了c++有關vector,map用法 2學習了正規表達式 3學習了狀态轉換圖和有窮自動機
	50	550		33	看了有關軟體的使用，原型模型以及建構之法
	600	1350	48		修煉心性，debug能力有提升，心理素質加強= =
			86	感覺這周過于松弛= =，後面要狠命還了
11	150	1160		97	終于實作了頁面的跳轉= =，商家端頁面設定
12	100	138		105	初識matplotlib，sql-connector