福大軟工 · 第十一次作業 - 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. 在釋出的過程中發現了哪些意外問題？

• 軟體暫未釋出。

• 配置設定足夠的人手進行測試，同時測試計劃應該緊随開發計劃之後指定，并随實際開發進度調整。

團隊的角色，管理，合作

1. 團隊的每個角色是如何确定的，是不是人盡其才？

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

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

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

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

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

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

• 我感謝喜源對我的幫助，因為在我開發遇到困難的時候，他幫了我很多，他會很有耐心地指導我不懂的地方。

我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?

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

總結

1. 你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?

• 處于初始級。我們的開發過程基本符合下面的定義。尤其是 “成功依靠的是個人的才能和經驗” 而不是成熟的軟體工程管理制度。

軟體工程管理制度缺乏，過程缺乏定義、混亂無序。成功依靠的是個人的才能和經驗，經常由于缺乏管理和計劃導緻時間、費用超支。管理方式屬于反應式，主要用來應付危機。過程不可預測，難以重複。

2. 你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?

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

3. 你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?

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

4. 你覺得目前最需要改進的一個方面是什麼?

• 一個規範的軟體開發制度。

  對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

• 主張簡單
  • 一開始我們計劃主界面做的十分複雜，有許多入口，類似下圖

    

    而基于主張簡單的原則，我們的主界面十分簡潔，突出了我們的主要特色功能。

• 軟體是你的主要目标
  • 開發過程中，不是一定要寫的文檔（指沒寫這個文檔軟體就無法開發）的文檔我們都沒有寫。
• 擁抱變化
  • 我們時刻有計劃外的人手（文檔組、測試組、資料組）可以應對開發過程中出現的變化

現場讨論圖檔：

Q&A

第一組

• 以目前的伺服器配置,在高并發場景下,是否依然能保證伺服器的相應效率?
• 答：目前測試用的伺服器配置隻有單核的CPU、2G記憶體、而且沒有GPU加速，即使是跑算法都顯得有些吃力；如果考慮高并發的情況下，若是有較優的伺服器配置，配合上類似thriff架構，是可以在一定程度上保證高并發場景下的效率的。
• 在演講中說到,為了小範圍場景下的準确率使得算法傾向過拟合,這是否會影響産品後期的擴充?
• 答：過拟合隻是為了在現有資料集前提下達到更優的效果，定期擴充産品的同時，我們也需要定期更新我們的模型，對于較傾向于算法的軟體這樣做也是難免的。
• 是否考慮過用自己的電腦進行内網穿透來運作相應算法以此彌補低價伺服器的性能瓶頸?
• 答：目前伺服器已經搭建在自己的電腦上了，課上僅僅是吐槽了一下！

第二組

• 社群功能是用來幹什麼的？
• 答：不好意思，本次alpha沖刺時間有限沒有來得及完成；計劃于Beta階段完成，主要是用于多使用者間溝通分享的一個平台。
• 是否能收錄相關店鋪的菜單，友善使用者進行評價及分享？
• 答：當然，店鋪相對應的資訊，我們也是都會收錄的，這也是一項十分耗時的工程。
• 推薦店鋪功能是基于什麼樣的算法？
• 答：目前是計劃采用類似基于時間衰減因子的推薦算法，基于使用者曆史記錄來提高推薦的置信度，但後續可能會略有修改！

第三組

• 單核伺服器問題的解決？
• 答：目前伺服器已經搭建在自己的電腦上了，這也能彌補低價伺服器的性能瓶頸。
• 美工界面方面如何改善？
• 答：計劃通過多次組内溝通來進行修改了，我們也會在Beta階段投入更多的人力資源來完成UI以及前端開發上。
• 店鋪種類問題,多樣性如何解決？
• 答：題目中的“多樣性”可否了解為多類商鋪？關于多樣性店鋪識别的話，主要是基于目标檢測+文字識别子產品來完成的。

第五組

• 美工界面問題怎麼解決？
• 算法方面很詳細，感覺真的沒什麼可以說的，就是有點複雜看的人不太懂。
• 答：這一點，我們會在後續的PPT制作上改進的，我們僅是為了展示一下alppha開發的部分流程。
• 識别問題，雖然你們的識别功能已經非常好了，但是還可以繼續加強。
• 答：感謝貴組的鼓勵。

第六組

• 算法确實強大，但使用者界面才是使用者對産品的第一印象，是以如果沒有挖到人才，怎麼解決使用者界面的美化？
• 答：挖人這一說辭僅是開開玩笑，我們很相信我們的美工——志豪同學！我們也會通過後續的軟體疊代來解決美化問題的。
• 團隊主要宣傳算法，那團隊貢獻度計算是否偏重算法？
• 答：我們更主張按勞配置設定，算法隻是我們希望展示的一個亮點。
• 推薦算法的依據，比如收藏、點贊之類的資料來源？
• 答：“爬蟲”擷取以及部分實體拍攝的資料。

第七組

• 能不能提個建議：下次展示，能不能别抛出那麼多具體的實作算法？我們認為使用者不會想知道你們是用什麼算法實作的，甚至使用者也不懂，使用者隻在乎你們實作的結果是什麼樣的。
• 答：這一點，我們會在後續的PPT制作上改進的，我們僅是為了展示一下alppha開發的部分流程，感謝您的建議。
• 識别出來的店鋪資訊包含什麼？隻有店鋪名稱和店鋪簡介？推薦部分會有什麼内容？
• 答：包含有店鋪名稱、簡介、使用者評論資訊等，基本上是法律允許範圍内，盡可能多的擷取商鋪資訊，并選取傳回給使用者。推薦部分則是包含基于使用者曆史的一個推薦商鋪。
• 伺服器問題和流上傳消耗過多流量問題怎麼解決
• 答：目前已經将伺服器搭建在本地允許，損耗流量問題，我們會設定定時、定幀的方式來解決。

第八組

• AR識别作為特色功能是否有足夠的吸引力？
• 答：個人認為AR是一個非常博人眼球的一個功能，也能吸引大量感興趣的使用者。
• 有沒有考慮增加提高使用者對産品需求度的功能
• 答：後續功能的話，會在Beta階段由組内重新商讨後來決定，盡請期待。
• 組内對alpha版本的分工如何評價？下階段,有沒有要改進的地方？
• 答：我們是以組内再分組的形式來完成分工的，大家也都一緻認為這是很好的一種分工形式，每一個小組也都有組長管理，最後彙總給PM。

第九組

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

得分

			第四組						平均分
67	77	73	83	70		75	84	66	73.57

貢獻度及分工

貢獻度

名		工作量比例
	10%
	14%
	11%
	12%
	13%
	8%

分工

工作流程

個人部分

PSP

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

學習進度條

第N周	新增代碼(行)	累計代碼(行)	本周學習耗時(小時)	累計學習耗時(小時)	重要成長
1	300		15		map 容器的性能瓶頸分析
2		8	23	完成基本功能的實作及附加功能的構思
3				31	學習 python 中與附加功能相關的庫，例如 wordcloud
4			36	學習了分而治之alpha版本事項和用例圖的繪制
			44	學會了簡單的原型設計和寫沒人看的劇本
6		740		52	學習了xml和Android studio的一些簡單使用，以及簡單的P圖技術，熟悉了python語言，學會用python畫直方圖
7		790		57	熟悉了前端和python語言
		990		64	熟悉了前端和制作，前端一些特效的學習，AR技術的學習，前後端的連接配接