事後諸葛亮

前言

• 為什麼我們要事後諸葛？戳這裡告訴你答案！

• 隊名：PMS

• | 組長|成員 |

  |-------|-------------|

  | ★ | 530 雨勤 |

  | | 311 旭 |

  | | 403 俊 |

  | | 223 元 |

  | | 437 海輝 |

設想和目标

• 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

  • 軟體開發旨在解決簡單監控場景下，人工監測人車流量費時費力且效率低下的問題
  • 典型使用者：校方、園區管理者等
  • 典型場景：校園、園區、商場等

• 我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)?

  • Alpha階段核心部分完成，但最終目标未能圓滿達成

  • | | 原計劃完成 | 實際完成 | 未完成的原因 |

    |-------|-------------------------------------------|-------------------------------------------------------------------------------------------------------|--------------------|

    | √ | 簡單場景下，車輛檢測與追蹤 | 非密集無遮蔽場景下，準确率98.05%；密集有遮蔽場景下，準确率66.67% | |

    | √ | 簡單場景下，行人檢測與追蹤 | 非密集無遮蔽場景下，準确率95.45%；密集有遮蔽場景下，準确率70% | |

    | √ | 熱力顯示 | 單一顔色疊加的表示區域流量密度 | |

    | | PC端桌面界面，及與子產品對接 | 具備基本跳轉、能夠調用視訊 | 了解全新的界面知識，不明确 |

    | | 視訊摘要 | 背景分離、視訊切割 | 時間問題未完成後半部分，不利于展示 |

• 有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?

  • 教訓：設計階段沒有做好文檔工作，導緻後期對接工作難做
  • 改進：重視設計，做好文檔

計劃

• 是否有充足的時間來做計劃?

  • 由于教學計劃變動，原項目整體計劃受到較大影響，前期架構尚未确定的情況下進入Alpha沖刺，總體上十分匆忙，經曆實際短促但内心煎熬的算法确立階段後，為趕進度盲目地進入代碼階段，很多文檔借口問題沒有妥善計劃，導緻最終整合收尾階段出現較大問題

• 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？

  • 衆志成城，沒有意見

• 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

  • 工作計劃完成度見上文表格，未能完成的原因如下：

  • 時間

    • 沖刺階段提前，很多前期準備還沒做好
    • 其他課程安排、電工實習、期末考試等等因素，橫向看每個小組都面臨着同樣的問題，但縱向看确确實實的影響着項目進度與品質

  • 算法

    • 我們的項目以算法為驅動，在算法方案确定前我們的項目推進都是停滞的

  • 語言

    • 組内大佬速成QT、Python
    • 不同語言的對接是另一阻塞項目進度的重要原因

  • 設計

    • 一開始突然進入alpha沖刺，受到核心算法未成型的瓶頸制約，而後急急忙忙進入編碼階段，對于接口、文檔沒有認真的考量，導緻最終進入對接階段部分代碼需要重構

• 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

  • 雨勤

    • 人車子產品最終使用了相同的架構去實作，兩子產品工作内容重合大，其實可以進行子產品合并

  • 旭

    • 沖刺到淩晨發瘋打遊戲——死神VS火影

  • 俊

    • 在MFC與QT之間糾結，浪費了很多時間

  • 元

    • 和 @旭 一起肝到淩晨發瘋，對打遊戲

• 是否每一項任務都有清楚定義和衡量的傳遞件?

  • 沒有
  • 這一項确實疏忽了，由于每個成員所負責的子產品都相對獨立，是以計劃上隻要求目前事項完成後能夠傳遞可對接的完整子產品，而沒有對每一項細節任務都做出傳遞件要求

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

  • 并非完全按照計劃進行
  • 原計劃Alpha沖刺就是單純的編碼實作，其他任務應在此之前完成，但受教學計劃變更，包括架構搭建、算法設計的内容也納入到Alpha沖刺階段中，時間上比較緊張。由于項目主要依靠算法驅動，沖刺頭幾天算法未成型，進度完全停滞
  • 上述問題即技術開發風險
  • 因為接口文檔沒有設計好，使得對接時，出現了很大的問題，到現在還存在一定的困難。

• 在計劃中有沒有留下緩沖區，緩沖區有作用麼?

  • 沒有緩沖區，前期進展緩慢，後期百米沖刺。

• 将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）

  • 将資料形成輸出報告
  • 從監控場景中提取其他交通參數，如：速率等

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

  • • 學會了基于Blob架構的運動目标的提取檢測與追蹤
    • 改進：訓練分類器，更加明确行人、汽車、電動、自行車的分類

  • • 如果能重來，我們就不會選實驗班，如果不選實驗班，就不用選軟工實踐，如果要在這個選擇上加一個期限，我希望是一輩子

  • • 如果能從來，你将看不到這篇部落格裡關于我的内容。

  • • 把Python改成C++吧

  • 海輝

    • 如果給我一次可以重新選擇的機會，老師你可能就看不到我了

資源

• 我們有足夠的資源來完成各項任務麼?

  • • 顯然不夠

  • 算法、論文與代碼

    • 網上有較多的相關資源，部分資源通過FQ也可獲得

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

  • 一項任務所需時間參照子產品實作難度、已有資源多寡、需要重新學習的内容多寡來估計
  • 精度上存在較大誤差，有一些難以排除的bug和其他人為因素會對之産生幹擾

• 測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?

  • 測試的主要問題在于資源，我們的産品需要大量視訊資源才能驗證準确率和識别速度，但網上獲得的視訊大多隻能适應初期調試，進入認真的測試階段後就需要我們自行采集視訊，并進行實地測試

• 你有沒有感到你做的事情可以讓别人來做（更有效率）?

  • • 之前在校園内兜了一圈找場景拍視訊，後來發現我的是渣手機并不能對焦到足夠測試的畫面，拍進來無數無效内容，手抖的也厲害，這方面應該交給專業人士 @俊

  • • 沒有，舍我其誰，我**無所不能。

  • • 沒有，舍我其誰，我**無所不能。（組長沒有隊形）

• • • 永遠要把下一秒當成Deadline來對待才能讓自己在真正的Deadline到來時更加從容

  • • 一定要嘗試在國外的網站去找資料，才能比較有效率。

  • • UI的知識應該從一開始就學，不應該到時間了開始，比較難。

  • • Python改c++

  • • 一定要參加會議，不能再缺席了。

變更管理

• 每個相關的員工都及時知道了變更的消息?

  • 每晚有站立會議，群内交流也比較及時

• 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?

  • 必須實作：核心功能
  • 推遲實作：錦上添花的功能、因為種種原因無法在計劃内完成的功能

• 項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

  • Alpha版驗收标準
    • 人車檢測與追蹤：簡單監控場景下，非密集無遮蔽的情形，準确率大于90%；密集有遮蔽的情形，準确率大于70%
    • 視訊摘要：錯誤率（漏檢、錯檢）低于10%
    • 熱力顯示：彌補在人流量、車流量大的情況下的準确率。
    • 圖形界面：具備與原型相似的UI

• 對于可能的變更是否能制定應急計劃?

  • 可以

• 組員是否能夠有效地處理意料之外的工作請求？

  • 能

設計/實作

• 設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？

  • 所有組員共同參與，所有集思廣益，一人操刀規整

• 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？

  • 沒有。我們的子產品分工明确，子產品之間耦合較小

• 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？

  • 使用了UML來輔助設計實作
  • 因為UML，使得我們對代碼編寫時的子產品有更加清晰的認識。
  • UML文檔相對發生改變，由于視訊摘要和熱力顯示使用了OpenCV内嵌的檢測算法，消除了對人車檢測子產品的依賴，準确率相對下降，但大幅提高了檢測速度，而小幅影響此子產品的效果

• 什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

  • 界面對接Bug
  • 對人車的分類方法還不完善
  • 由于大家都是DoingByLearning，很多問題在前期不能預見

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

  • Alpha階段以最小可用為實作目标，未進行代碼複審
  • 沒有做好文檔工作，代碼規範不存在的

測試/釋出

• 團隊是否有一個測試計劃？為什麼沒有？

  • 人工+程式的測試方案
  • 測試資料集來自組内成員到各場景人工采集

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

  • 已經進行，但測試資料量較小，還需進一步測試

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

  • 為了對比人工和程式檢測的效果差别，采用人工檢驗每個視訊資料的正确率

• 在釋出的過程中發現了哪些意外問題？

  • 沒有完成界面對接，Alpha版釋出的仍是控制台程式

團隊的角色，管理，合作

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

  • @俊負責一切面子工程
  • 由假期已接觸OpenCV @勤 @旭 @輝 完成核心功能
  • 由 @元 完成熱力圖顯示功能
  • 在功能配置設定上，每個人都負責自己比較擅長的功能，算是人盡其才。

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

  • 有，大家在項目的進展中，無論是在技術還是生活中都互相幫助，相親相愛。

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

  • 聽組長的。

• 每個成員明确公開地表示對成員幫助的感謝 （并且寫在各自的部落格裡）：

  • 我感謝 @大家 對我的幫助， 因為大家脾氣好。

總結:

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

  • 首先我們查了查什麼是CMM/CMMI,根據我們的了解我們達不到CMM的層次，我們應該整處于CMMI的低級層次。

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

  • 規範

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

  • 相較于之前的團隊創立之初的迷茫，現如今大家都趨于對技術、團隊合作的熟悉，更加遵守團隊計劃。

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

  • 時間利用，我們團隊在時間利用上存在較大的問題，每次都會在趨于deadline時還有一部分工作沒有完成，希望能在今後改進！

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

  • （1）圍繞有積極性的個人建構項目，給予他所需的環境和支援。在針對Alpha版本的對接工作中，小組成員盡力幫助 @俊 完成界面與程式的對接，包括學習QT等
  • （2）最富有效率的是，面對面交談。我們小組每天晚上都會進行面對面的站立式會議，并在平常經常面對面溝通項目的進展等。、
  • （3）每隔一段時間，團隊會檢討如何才能更好的進行工作，并相應做出調整。我們團隊在初期遇到很大的問題，進度很慢，我們在咨詢了導師，自我溝通後做出了調整，使項目能正常進行。

照片君