前言

• 小組名：沒有bug！
• 專案：短視訊APP

思考總結

設想與目標

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

• • 我們軟體主要是實現一個創新型的短視訊APP，在以往的短視訊APP的基礎上增加了一些新的功能，打造一個勞逸結合的視訊平臺
  • 典型使用者：學生
  • 典型場景：娛樂、學習

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

• • 原計劃實現功能：使用者自主上傳觀看娛樂視訊，檢視、修改個人資訊以及一部分社交功能
  • 實際情況：由於視訊使用的是阿里雲的視訊點播服務，使用過程中遇到一些問題，目前還沒有解決，所以說除了視訊的上傳和播放意外的其他功能都基本實現了
  • 交付和使用者：軟體功能基本實現，但實際投入使用存在困難，暫時無法投入使用

　　  3.　和上一個階段相比，團隊軟體工程的質量提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？

• • 這次是第一次迭代開發，沒有上一階段

　　  4.　使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

• • 暫未投入使用，使用者實際接受成度未知
  • 產品完成度好，當然離目標更近了
  • 首先是交流方面，我覺得我們組算是比較好的，這點可以繼續保持，然後是專案管理方面，我們沒有使用第三方的託管平臺，但是由於分工十分明確，基本是1-2個人負責一個模組，所以也沒有出現程式碼你改我我改你，導致崩潰的狀況，但是這點以後還是要使用，萬一人多了呢

計劃

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

• • 每週都有計劃這周該做的事情，同時總結上一週的計劃實現情況　　　　

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

• • 我們分工比較明確，但是遇到某一個功能點的實現時，我們會一起考慮難易度以及效率等問題，然後決定實現的方式以及交給哪個模組、哪個人去解決　　

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

• • 大部分跟著計劃在走，目前最大的問題就是視訊的問題，之前是由於域名一直沒有備案下來，所以工作一直沒有進展　　　　

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

• • 除了最開始學習後臺開發的知識的時候，應該沒有了吧　　　　

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

• • 我們的主要的對接就是APP和伺服器的方面，我（伺服器）在實現每一個功能前都會先考慮需要什麼、我要返回什麼，然後和APP那一塊的人進行交流，決定最後的方案，然後開發的時候我會寫好日誌，在交付上基本沒有遇到什麼問題　　

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

• • 除了視訊點播那一塊出了點意外，其他的都還蠻順利的
  • 風險的話，就是域名備案時間那麼長我門是真的沒有想到的，至於為什麼沒有想到，我們也是第一次啊...　　　　

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

• • 第一次迭代中並沒有留下緩衝區，一直到迭代末期都在不停的加班中　　　　

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

• • 儘量在保證質量的情況下加快開發吧，最好能留下一個星期進行緩衝測試，如果可以的話我們想對程式碼結構進行一些調整

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

• • 主要是各方面的知識和團隊之間的交流配合吧，如果歷史再來一遍，我覺得我們會主要對程式碼結構著重調整

資源　　

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

• • 我覺得我們最缺的應該是時間吧，其次是前輩的支援（有些問題真的一時半會我們琢磨不出來啊）　　　　

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

• • 並沒有太仔細的去考慮這方面的問題，我們開發前會大致上思考一下這個功能實現的難易度、需要的時間，然後決定花多久解決　　　　

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

• • 時間肯定是不夠的，測試機型確實沒有多少（就我們幾個組員的手機，但是目前我們也沒有考慮機型的問題），美工方面，我們ui做的確實蠻醜的，打算在後期美化一下，現階段主要實現功能　　

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

• • 硬要說的話，我不擅長寫這種型別的文章，技術總結、開發日誌都還好　　

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

• • 早一點備案吧

變更管理

1. 每個相關的員工都及時知道了變更的訊息?

• • 我們每一次對專案進行的更改都是大家一起決定的，所以大家都是知道的　　

2. 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

• • 優先順序高的必須先實現，至於技術有難點而優先順序有沒有那麼高的，又一直遲遲解決不了的就會推遲（放置在一邊）　　

3. 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

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

• • 沒有提前制定應急計劃，但有變更時會及時做出反應和調整

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

• • 目前還算可以吧，對於加/改需求這回事，算是適應下來了吧　　

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

• • 寫好開發日誌能省很多事情

設計/實現

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

• • 設計是專案開始時，大家一起和指導老師一起完成的　　　　

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

• • 所有的都是大家一起決定的，並沒有模稜兩可的情況，倒不如說大家都有自己的想法，競爭的很激烈就是了　　　　

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？ 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？

• • 我們用starUML設計了UML圖　　　　

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

• • 要說bug的話肯定是Android端的最多，因為實在是太迷了
  • bug目前都已經修復了　　

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

• • 程式碼規範這一點並沒有嚴格執行，因為大家都還是以進度為首要目標

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

• • 會注重程式碼結構吧　　　　

測試/釋出　　

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

• • 沒有，都是做完一個功能測試完這個功能，功能什麼時候能做完我們不清楚，所以測試計劃也計劃不了　　

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

• • 進行了，在alpha版本做完之後對整個APP進行了測試　　

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

• • 沒有　　

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

• • 我們主要是對功能的測試，效能方面並沒有考慮　　　　

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

• • 無　　　　

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

• • 求求你多給點時間吧

團隊的角色，管理，合作

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

• • 這個是大家自己選擇的，然後稍微做了下調整　　

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

• • 我是一個人做一個模組的，對於我來說只有功能實現方面會去和他們討論吧，技術上並沒有什麼互相幫助，但是我感覺交流配合什麼的還是蠻好的吧　　

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

• • 一起討論，誰能說服其他人就用他的方法嘍　　　　　　

總結

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

• • 屬於CMMI一級，完成級

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

• • 應該算是規範階段吧

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

• • 大家寫程式碼越來越得心應手，結構上有了一部分的改進，配合變得更加默契　　　　

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

• • 介面的美化吧，現在的介面真的慘不忍睹...