福大軟工 · 第十一次做業 - Alpha 過後諸葛亮（團隊）

寫在前面

• 林燊大哥
• 一路走來，好不容易，終於完結了。

設想和目標

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

• 解決的問題
  • 用戶在進店以前沒法得知店鋪的優劣，經過現有產品獲取店鋪信息須要手動輸入店鋪名，繁瑣且耗時。而咱們的產品能夠經過掃描店鋪招牌的方式來獲取店鋪信息，其中掃描的方式分爲普通拍照和AR兩種，步驟簡單且高效。
• 定義是否清楚
  • 通過咱們前期的需求分析、問卷調查、組內決策等一系列審覈後最終定義下的軟件，咱們認爲這也是兼具完備定義以及強健性的一款軟件。
  • 在咱們看來，定義得十分清楚，若是有疑問的小夥伴歡迎你們來交流~
• 典型用戶
  • 常常在城市廣場（例如永嘉天地、萬達廣場等）消費的顧客
  • 初來乍到福州，想去周邊城市廣場瞭解、餐館的顧客
• 典型場景
  • 設想這樣一個場景：當你在廣場上，面對一排又一排的店鋪，而你想知道某家店的評價等信息時，現有軟件的工做流程爲：

而若是使用咱們的產品則變爲：

其中效率的提升是顯而易見的。

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

• 原計劃功能實現狀況
  • 基本上實現，除了沒能將服務器搭在雲平臺上。
  • 前端實現簡介、可用性強的界面
  • 後端算法徹底實現，但鑑於「強迫症」，咱們仍然會在後續作出改進。
  • 數據部分數量過少，沒有達到預期目標，僅收錄27家商鋪。
• 是否按原計劃交付時間交付
  • 是的，在答辯當天咱們展現了咱們的成果，儘管咱們熬了夜才完成。
• 原計劃預期的用戶數量是否達到
  • 原計劃沒有預期可以有用戶使用，只是在咱們團隊內部進行測試。

3. 用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼?咱們離目標更近了麼?

• 用戶量和預想的一致。
• 用戶對重要功能的接受程度仍是超出預期的，當把掃描招牌識別店鋪名的功能作出來的時候，團隊成員都感到很神奇。

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

• 遇到的困難真的是不可勝數，甚至單獨寫一篇博客都不爲過。下面從技術方面的問題和非技術方面的問題中各說幾個吧。
• 技術方面：
  • 在訓練CRNN模型的時候，在數據集分配上不是很合理，致使模型效果不佳。若是在數據集充足的狀況下，將全部數據集按照8:1:1進行分割，分別分配給訓練集、開發集和測試集。若是數據量小的話，按9:1分配給訓練集和測試集。這樣就可以提高模型效果。
  • 開發過程當中常常遇到服務器鏈接不成功的問題，一開始認爲Okhttp有幫咱們自動開子進程，後來才發現十分不穩定。咱們發現仍是本身手動設置一個子進程來的更加的穩定。
  • 不要低估了任何一個項目的開發難度和工做量，開發人員的人數最好要比一開始預期的要多，不然一旦發現工做量太大，這時候想再加入新人來開發，會更加耗時。一樣開發人員多，能夠有更多的時間和精力來把項目作得更好。否則就會像咱們一個，幾個開發只能肝肝肝！
  • 前端界面不精美，這個問題咱們也很絕望啊，因此說團隊必定要有一個女生，九個男生的審美，咱們真的盡力了！
  • 算法部分在考慮摩爾紋的前提下很難有較好的識別結果。
• 非技術方面：
  • 低估了前端開發的難度，分配的人手不足。可是由於你們都是新手，當咱們意識到這個問題的時候，已經來不及從新分配人手去學習了。
  • 一開始過於草率的選擇開發基於安卓系統的應用，後來才意識到或許採用微信小程序開發能夠更省時並且效果更好。
  • 在衝刺階段和兩門考試以及其餘實踐課程的做業deadline衝突嚴重，組內成員時間嚴重不足。並且部分紅員還須要兼顧學院的學生工做，時間更加不足。至少在咱們看來，這是個無解的問題...
  • ...

計劃

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

• 咱們很早就開始了計劃，時間上是很充足的，可是咱們沒有足夠重視這個環節，並無投入過多的時間在這個方面，這也是算是個教訓。

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

• 咱們團隊在解決成員之間的分歧的時候仍是比較愉快的，基本上你們都會很直白的表達本身的意見，而後你們討論，在討論中解決問題。

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

• 俞辛
  • 我原計劃的工做是寫博客以及文檔。沒有都作完。有兩篇博客是有鈞昊同窗幫我完成的，沒作完是由於我因爲實驗室的事情去了南京兩天，沒有辦法完成博客。
• 柏濤
  • 我原計劃的工做是使用QQ登陸和數據的上下傳。使用QQ登陸和數據的下載部分完成，數據的上傳遇到了一些bug，還沒有解決。沒有java和安卓開發基礎，在開發學習過程當中會遇到許多不可預知的困難，不知道該怎麼解決。
• 宇航
  • 我原計劃的工做是製做相機AR模塊，協助界面製做。相機模塊已製做完畢，AR模塊未完成，部分界面製做完畢（主體導航欄，活動中心）協助製做了登陸用戶等界面。
• 燊
  • 我原計劃的工做是完成算法的並行化設計和完成推薦算法，推薦算法完成，並行化設計由於服務器硬件緣由沒有完成。
• 宏巖
  • 我原計劃的工做是拍攝數據集並對拍攝的店鋪照片進行標註、爬取永嘉天地店鋪的簡介和評論信息，把爬取的信息導入數據庫並與後端鏈接。數據集拍攝和信息爬取的任務已經完成，數據庫鏈接方面還有一些問題，最後只能經過txt文件的方式解決。未能實現的緣由之一是本身對時間的分配不當，中間還去南京參會，致使沒有時間去了解數據庫的遠程訪問問題。緣由之二是未能和開發組達成共識，共同討論數據的要求，致使後面倉促的開發。
• 喜源
  • 我原計劃的工做是前端、上傳照片至服務器和短信登陸。有作完，可是身爲開發組的組長，整組總體的實現沒有完成的很好，我有着不可推卸的責任。
• 志豪
  • 我原計劃的工做是製做一個好看耐看秒天秒地的前端。沒有作完。最後實現的前端只能說勉強能看，不能讓你們滿意。緣由：審美不行，時間不足，不夠用心。
• 愷翔
  • 我原計劃的工做是訓練可識別商店名的CRNN模型。有作完，目前對現有數據集訓練模型，正確率達到98%。
• 鈞昊
  • 我原計劃的工做是完成商鋪招牌檢測，基於YOLO算法的實現以及算法服務器端的架設與接口，有作完。目前對現有數據集訓練，設定IOU>0.5爲正確標準的狀況下正確率可達到90%，但因爲對於大目標如商鋪招牌的容錯性較高，因此實際效果更優。

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

• 存在有部分事情沒有太大意義，但難保在Beta衝刺上
• 好比雲服務器上的搭建，咱們在測試算法的過程當中就發現了單核CPU的運行效果不佳的問題了，但還是抱着試試看的心態來嘗試繼續搭建，最終效果也不盡如人意。
• 可是咱們計劃在Beta版本將服務器僅做爲咱們一個雲端數據庫，這樣也能使咱們事先配置好的低廉雲服務器也能發揮出自身的做用。

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

• 每一項任務都有很清楚的定義，但未必都有清楚的衡量標準，由於例如前端美感這一類隨開發人員審美變化大的任務沒辦法定下標準。

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

• 並無整個過程都按計劃進行。雲服務器沒能投入使用，由於咱們購買的服務器性能不足以運行咱們的程序，而性能的好的服務器買不起。**（柯老闆要不要考慮一下天使投資？）

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

• 沒有，由於計劃時不瞭解緩衝區的概念。

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

• 未來會將任務集中在一段時間完成，而不是平攤到整個任務週期。

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

• 學到了長痛不如短痛，一次性完成任務是最好的。

資源

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

• 除了購買服務器所需的資金外，其餘資源十分充足。不管是技術方面的人才仍是文檔方面的人才，多如牛毛。

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

• 各項任務所需的時間和其餘資源的估計是基於團隊成語過往經驗以及詢問前輩所得，十分粗糙。
• 精度方面，咱們沒有確切估計，可是相比於咱們諮詢的過往前輩，咱們在本項目上的耗時相對更多一些，可是質量方面卻無從考究。

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

• 測試的時間，人力是夠的，由於開發的速度並不會太快。硬件也是足夠的，組內有須要的測試設備（一臺安卓機）。軟件的話則不太夠，由於沒有測試的經驗，純手工測試。

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

• 過後來看確實是有所低估，致使成果不夠美觀。
• 美工方面的確是一個須要咱們花時間去作的問題，咱們在Beta階段也會付諸努力來完成但不只僅限於美工這件事。

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

• 組內來看的話，每一個人都在本身最合適的位置上，可是若考慮到效率這一方面的話，確定多少回存在有差別性。
• 適合的位置並不表明完成地相對更有效率，因此多少會有一點。

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

• 開發組的同窗任務量過大，即便有的人不擅長開發，爲了任務的推動也應該轉去開發。

變動管理

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

• 在咱們的分組內的成員都知道了變動的消息。例如開發組有本身的羣，隨時在羣內交流。

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

• 通常是PM根據實際狀況決定。

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

• 咱們計劃要完成的功能就是咱們的出口條件。

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

• 能，文檔組的同窗在本次任務過程當中就承擔了 「救火隊員」 的任務。

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

• 若是與當前的任務不衝突的前提下，可以很好的解決。

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

• 計劃趕不上變化，不管如何都會出現意外狀況（好比現場編程任務難度大，影響了alpha版本開發的進度）。在計劃的時候要設置緩衝區以應對未知的變動。

設計/實現

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

• 設計在分工結束後就由各小組組長完成，目前看來時間是合適的，人選則未必是最合適的。

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

• 有，比方說不肯定這個任務能不能按這樣的設計實現，解決方式詢問有經驗的前輩。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？

• 測試是在安卓開發神器Android Studio裏面進行的，開發組成員表示仍是很好用的。

4. 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

• 狀態仍是有很大區別的，緣由是項目開始時的文檔是基於咱們的空想完成的，實際開發過程當中不斷地在調整。固然須要更新（事實上咱們也確實在作這件事）。

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

• 服務器的算法Bug最多，由於測試的圖片有多種多樣的複雜狀況（例如柯老闆課上說的被樹擋住了招牌的大部分文字）。開發的時候就考慮到了，可是這個是要經過大量的訓練才能解決，開發過程當中只能盡力而爲。

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

• 時間緊任務重，未能進行代碼複審，也未能嚴格執行代碼規範。

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

• 代碼複審應該隨時進行，而不是等項目完結後再進行。代碼規範亦是如此。

測試/發佈

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

• 只有一個十分粗糙的計劃，就是每完成一個功能以後就進行測試。

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

• 因爲經驗不足，未能進行驗收測試。

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

• 開發組採用Android studio進行測試。

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

• 暫無這部分的工做。

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

• 軟件暫未發佈。

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

• 分配足夠的人手進行測試，同時測試計劃應該緊隨開發計劃以後指定，並隨實際開發進度調整。

團隊的角色，管理，合做

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

• 角色主要是成員自薦，基本上自薦以後就完成了分工。目前看來基本上達到了人盡其才。

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

• 這個是百分之百有的，我相信任何一個組都有，由於每一個人都會遇到困難，這不可避免，所以就須要進行團隊互助。

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

• 不論什麼類型的問題，咱們團隊的解決方法第一步都是團隊討論，而後進行集思廣益解決問題。

每一個成員明確公開地表示對成員幫助的感謝：

• 感謝喜源在考試複習期間抽出寶貴的時間幫我解決了數據上傳服務器的問題。

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

• 咱們學到了溝通是解決問題的惟一途徑。在這個方面，我認爲咱們團隊是作得比較好的，改進的部分暫時未發現。

---

總結

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

• 處於初始級。咱們的開發過程基本符合下面的定義。尤爲是 「成功依靠的是我的的才能和經驗」 而不是成熟的軟件工程管理制度。

軟件工程管理制度缺少，過程缺少定義、混亂無序。成功依靠的是我的的才能和經驗，常常因爲缺少管理和計劃致使時間、費用超支。管理方式屬於反應式，主要用來應付危機。過程不可預測，難以重複。

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

• 處於磨合的階段，正向規範的階段邁進。由於在alpha中，咱們沒有一個規範的制度或者說相關開發文檔，在接下來的開發中，咱們會注意改進。

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

• 在團隊的分工以及協做能力上大大提高。

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

• 一個規範的軟件開發制度。
  對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。
• 主張簡單
  • 一開始咱們計劃主界面作的十分複雜，有許多入口，相似下圖
    
    而基於主張簡單的原則，咱們的主界面十分簡潔，突出了咱們的主要特點功能。

• 軟件是你的主要目標
  • 開發過程當中，不是必定要寫的文檔（指沒寫這個文檔軟件就沒法開發）的文檔咱們都沒有寫。
• 擁抱變化
  • 咱們時刻有計劃外的人手（文檔組、測試組、數據組）能夠應對開發過程當中出現的變化

現場討論圖片：

Q&A

第一組

• 以目前的服務器配置,在高併發場景下,是否依然能保證服務器的相應效率?
• 答：目前測試用的服務器配置只有單核的CPU、2G內存、並且沒有GPU加速，即便是跑算法都顯得有些吃力；若是考慮高併發的狀況下，如果有較優的服務器配置，配合上相似thriff框架，是能夠在必定程度上保證高併發場景下的效率的。
• 在演講中說到,爲了小範圍場景下的準確率使得算法傾向過擬合,這是否會影響產品後期的擴展?
• 答：過擬合只是爲了在現有數據集前提下達到更優的效果，按期擴展產品的同時，咱們也須要按期更新咱們的模型，對於較傾向於算法的軟件這樣作也是不免的。
• 是否考慮過用本身的電腦進行內網穿透來運行相應算法以此彌補低價服務器的性能瓶頸?
• 答：目前服務器已經搭建在本身的電腦上了，課上僅僅是吐槽了一下！

第二組

• 社區功能是用來幹什麼的？
• 答：很差意思，本次alpha衝刺時間有限沒有來得及完成；計劃於Beta階段完成，主要是用於多用戶間溝通分享的一個平臺。
• 是否能收錄相關店鋪的菜單，方便用戶進行評價及分享？
• 答：固然，店鋪相對應的信息，咱們也是都會收錄的，這也是一項十分耗時的工程。
• 推薦店鋪功能是基於什麼樣的算法？
• 答：目前是計劃採用相似基於時間衰減因子的推薦算法，基於用戶歷史記錄來提升推薦的置信度，但後續可能會略有修改！

第三組

• 單核服務器問題的解決？
• 答：目前服務器已經搭建在本身的電腦上了，這也能彌補低價服務器的性能瓶頸。
• 美工界面方面如何改善？
• 答：計劃經過屢次組內溝通來進行修改了，咱們也會在Beta階段投入更多的人力資源來完成UI以及前端開發上。
• 店鋪種類問題,多樣性如何解決？
• 答：題目中的「多樣性」能否理解爲多類商鋪？關於多樣性店鋪識別的話，主要是基於目標檢測+文字識別模塊來完成的。

第五組

• 美工界面問題怎麼解決？
• 答：計劃經過屢次組內溝通來進行修改了，咱們也會在Beta階段投入更多的人力資源來完成UI以及前端開發上。
• 算法方面很詳細，感受真的沒什麼能夠說的，就是有點複雜看的人不太懂。
• 答：這一點，咱們會在後續的PPT製做上改進的，咱們僅是爲了展現一下alppha開發的部分流程。
• 識別問題，雖然大家的識別功能已經很是好了，可是還能夠繼續增強。
• 答：感謝貴組的鼓勵。

第六組

• 算法確實強大，但用戶界面纔是用戶對產品的第一印象，因此若是沒有挖到人才，怎麼解決用戶界面的美化？
• 答：挖人這一說辭僅是開開玩笑，咱們很相信咱們的美工——志豪同窗！咱們也會經過後續的軟件迭代來解決美化問題的。
• 團隊主要宣傳算法，那團隊貢獻度計算是否偏重算法？
• 答：咱們更主張按勞分配，算法只是咱們但願展現的一個亮點。
• 推薦算法的依據，好比收藏、點贊之類的數據來源？
• 答：「爬蟲」獲取以及部分實體拍攝的數據。

第七組

• 能不能提個建議：下次展現，能不能別拋出那麼多具體的實現算法？咱們認爲用戶不會想知道大家是用什麼算法實現的，甚至用戶也不懂，用戶只在意大家實現的結果是什麼樣的。
• 答：這一點，咱們會在後續的PPT製做上改進的，咱們僅是爲了展現一下alppha開發的部分流程，感謝您的建議。
• 識別出來的店鋪信息包含什麼？只有店鋪名稱和店鋪簡介？推薦部分會有什麼內容？
• 答：包含有店鋪名稱、簡介、用戶評論信息等，基本上是法律容許範圍內，儘量多的獲取商鋪信息，並選取返回給用戶。推薦部分則是包含基於用戶歷史的一個推薦商鋪。
• 服務器問題和流上傳消耗過多流量問題怎麼解決
• 答：目前已經將服務器搭建在本地容許，損耗流量問題，咱們會設定定時、定幀的方式來解決。

第八組

• AR識別做爲特點功能是否有足夠的吸引力？
• 答：我的認爲AR是一個很是博人眼球的一個功能，也能吸引大量感興趣的用戶。
• 有沒有考慮增長提升用戶對產品需求度的功能
• 答：後續功能的話，會在Beta階段由組內從新商討後來決定，盡請期待。
• 組內對alpha版本的分工如何評價？下階段,有沒有要改進的地方？
• 答：咱們是以組內再分組的形式來完成分工的，你們也都一致認爲這是很好的一種分工形式，每個小組也都有組長管理，最後彙總給PM。

第九組

• PPT已經很完整的展現了功能，可是感受UI界面設計比較簡陋，在從此打算怎麼改善？
• 答：UI界面的美工問題，咱們後續會由咱們組的美工擔當——志豪同窗來監督、改善。
• 算法和UI界面設計的差距有點大，該如何改進
• 答：咱們認爲算法和UI界面上的差距問題也很難知足每一個用戶的需求，咱們團隊也一致認爲這樣的銜接方案是十分簡潔的。
• 今天只展現了部分核心功能，請問在從此還有那些必要的功能可擴展
• 答：從此還會考慮推薦商鋪功能、社區功能的實現。

得分

第一組	第二組	第三組	第四組	第五組	第六組	第七組	第八組	第九組	平均分
67	77	73	83	70	70	75	84	66	73.57

貢獻度及分工

貢獻度

名	貢獻度	工做量比例
燊	10%	10%
鈞昊	14%	14%
俞辛	11%	11%
宏巖	10%	10%
喜源	12%	12%
柏濤	13%	13%
宇航	12%	12%
愷翔	10%	10%
志豪	8%	8%

分工

工做流程

我的部分

PSP

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

|       | 	合計  | 355 | 335

學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時（小時）	累計學習耗時（小時）	重要成長
1	200	200	6	6	學習PyQt5的基本使用
2	500	700	12	18	學習Qt開發
3	300	1000	3	21	學習python爬蟲
4	200	1200	4	25	學習安卓經常使用控件
5	400	1600	7	32	學習安卓XML的使用
6	600	2200	7	39	學習安卓開發中數據庫的使用
7	300	2500	8	47	學習安卓QQ登陸SDK
8	400	2900	24	71	安卓網絡傳輸
9	300	3200	12	83	安卓SQLite數據庫的使用
10	300	3500	6	89	學習騰訊地圖SDK