設想和目标
-
我們的軟體要解決什麼問題？是否定義得很清楚？
我們軟體要解決的就是音樂播放器由于功能的繁瑣，進而導緻它不适用部分手機記憶體太小，老年人使用不友善等問題，我們的音樂播放器隻通過擷取到本地音樂的播放源，對應音樂的專輯背景，對其進行播放，以及音樂的歌詞滾動，清單的循環方式進而減小了app的記憶體占用，以及簡單明了的使用方法。
定位就是一款不占記憶體，功能簡單的播放器。
-
我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)
我們完成了大部分的目标，播放器在安裝到本地後能擷取到音樂，圖檔，同時也能對歌曲進行順序播放，随機播放等功能，能監聽手機的來電事件，同時對歌詞檔案的擷取時常會不顯示這個功能未能完善。隻按照原計劃交了一個比較完善的版本。因為這個項目對我們組來說是屬于學習的階段，是以還達不到上線的程度，自然，原計劃的使用者數量沒有達到。
2.和上一個階段相比，團隊軟體工程的品質提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
跟上一個階段相比，團隊的開發效率明顯提高了，分工也更明确了。在上一個階段，播放器安裝後還總會因為一些原因閃退，播放聲音出錯等，在這個階段播放器改善後，整個播放器能完整使用，因為第二階段時間相對富餘，是以界面改善得更加人性化，也修複了alpha階段的一些bug。
3. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
對于現階段而言，用這樣的形式傳遞項目我們都是新手，但是部分還是一緻的，老年人用起來還是比較順手，不存在不知道該怎麼使用這個播放器的地方，而針對年輕人的群體，雖然記憶體小，但是沒辦法實時的擷取新歌，無法滿足他們的需求，進而還是和我們事先預想的有偏差。離目标還是有一定的距離。
4. 有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
如果曆史重來一遍，在初期對需求的分析需要有更多的資料進而能更好的分析各個群體的需求，以及在計劃定制，完成計劃的過程需要更多的耐心和督促，在開發過程中，多花一些時間完善項目。
計劃
-
是否有充足的時間來做計劃?
時間不是特别多，計劃做的比較草率，在需求分析階段沒有明确的架構和概念，對于項目計劃比較粗略。
2. 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
成員對于該項目的時間配置設定不可能做到一緻，大部分以少數服從多數的原則，同時少數的理由如果足夠充分說服其他人，如果避免不了一些客觀情況，計劃也是可以适當變動的，慶幸的是這次團隊項目沒有大的意見沖突。
3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
原計劃大部分是傳遞了，但是沒有都做完，也有因為一些bug和經驗不足陷入誤區耽誤開發的時間，也有花費的時間不夠的原因。
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
有，有時候發現重點的位置都是在一直循環一個錯誤，應該早點與隊友讨論，才不會讓自己一直陷在錯誤裡面。
5. 是否每一項任務都有清楚定義和衡量的傳遞件?
大部分任務有，但是功能點的定義和衡量可能沒有那麼詳細得說明。
6. 在計劃中有沒有留下緩沖區，緩沖區有作用麼?沒有
7. 将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
将來的計劃可能會在配置設定任務上更加詳細，讓大家都知道自己負責的部分在哪裡，才不會各種混亂
8 .我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
我們學到了計劃在項目開發的過程中是很重要的，計劃決定了整個項目能否進行的很有條理，是以如果曆史重來一遍，我們會詳細的指定計劃，并在一段時間開會對計劃進行重新整改。
資源
-
我們有足夠的資源來完成各項任務麼?
人力資源上：我們組的成員隻有3個人，任務完成的時間其實是很緊迫的。
開發資源上：Android開發App已經是爛大街的技術了，網上也有很多資源可以學習，但是在相對緊湊的時間裡要學會架構的部署，界面的設計，功能的實作，和sqlite的使用，進而 做出一個可以傳遞的小型的demo，其實任務是艱巨的，不過，因為成熟的技術，大量的學習資源，是以學習到的也很多。
裝置資源上：開發這樣小型的App，裝置資源是不足為慮的。
時間資源上：在這次團隊項目總，因為我們要同時學iOS，Android兩門語言，還有其他的課程安排，是以時間是比較不足的。
-
各項任務所需的時間和其他資源是如何估計的，精度如何?
各項任務所需的時間和其他資源是根據任務量估計的，精度方面，alpha階段做的不大好，對于這樣的開發模式比較生疏，，是以估計有些誤差，但是在第二個beta階段就做的相對好一些，精度也準确了。
-
測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案）是否低估難度?
除了軟體/硬體資源是充足的，其他的資源都相對緊缺，其中最缺乏的還是時間資源。相對于功能的實作，美工和設計的難度對于我們來說不算難，更何況隊裡有兩個女生，在美工設計方面不算有什麼難度。
-
你有沒有感到你做的事情可以讓别人來做（更有效率）?
因為該項目的成員隻有3個人，是以每個人都配置設定了挺多的任務，是以耦合性還是挺大的，很少存在某個任務需要别人來完成。
1.有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
需要改進的方面就是資源要是能多一些就好了，尤其是人力資源和時間資源上。
變更管理
-
每個相關的員工都及時知道了變更的消息?
是，每個相關的成員都能及時知道變更的消息，因為是一個宿舍的，成員又隻有3個人，對于小型的變動直接發檔案給對方。
-
我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
從兩個方面考慮，一個是實作難度，還有資源消耗。如果一個功能點實作難度是比較大的，代碼量也比較多，就可以決定推遲，如果是已經花費了一定的時間和人力的資源，且已經明确配置設定的功能，就是必須實作的功能。
-
項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
APP無崩潰、閃退等現象。
測試發現的Bug得到修複。
典型使用者場景得到測試并無bug。
測試矩陣中的典型情況得到測試并無bug。
-
對于可能的變更是否能制定應急計劃?
能，在不影響整體工程完成的情況下，具體情況具體分析，解決。
5. 員工是否能夠有效地處理意料之外的工作請求？
可以，對于該項目的完成難度，時間充裕的情況下我們是可以處理意料之外的請求的。
6. 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
變更是項目開發過程中常見的現象，但是一個有計劃，有條例的計劃是可以減少變更的出現的，也可以減少資源的消耗，是以，如果曆史可以重來的是，我們會更加重視計劃設計的合理設計的。
設計/實作
-
設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
在alpha階段，我們沒有明确的設計計劃，是以在beta階段的時候，我們就設計了整體工作的架構，一起商議各種任務的實作計劃，對于功能點的實作，是我們三個商議配置設定的，前端的設計主要是兩個女生負責，後端的實作是三個人共同完成的，測試則有歐陽時康完成，項目的bug修複和文案記錄主要是我和蘇曉微完成的。
-
設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
有遇到，一般如果是難度較大的設計工作，就放到後期若是時間允許的情況再商議，若是難度不大的情況，細化之後配置設定給各個成員完成。
-
團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
沒有用到單元測試，該項目是基于移動平台開發的一款小型App，暫時沒有用到代碼測試工具測試，我們在跟進項目的完成情況的時候一般是直接在模拟器或者真機上運作測試。
-
什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
實作sqlite接口的時候産生的bug最多，起初沒有添加讀取sd卡的權限，導緻歌曲加載錯誤，以及涉及到資料的加載，和最近播放的音樂的資料的封裝，這些都是需要實作的，是以要全面得考慮才可以。
5. 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
代碼複審沒有嚴格按照代碼規範進行，隻是針對自己實作的功能代碼重新審讀。
6. 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
開始的時候并沒有對于項目的設計并沒有成文的詳細的計劃，隻覺得配置設定完任務後就可以，各自完成自己的工作，後來發現因為事先設計的計劃不充分，出現了項目完成進度有所誤差。是以一個明确的設計能起到事半功倍的效果。
測試/釋出
-
團隊是否有一個測試計劃？為什麼沒有？
我們團隊是有一個測試計劃的，在beta階段因為在alpha階段的時候就已經完成了一部分，是以隻針對beta階段的工作加以測試。
-
是否進行了正式的驗收測試？
驗收測試不算正規，隻是大緻完成。
-
團隊是否有測試工具來幫助測試？
沒有，采用的是人工測試。
-
團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
軟體的效能主要是指并發性和壓力測試，由于這款音樂播放器是基于本地資源的操作，是以不存在并發性的問題，我們是在不同型号的手機上進行測試，功能效果還行。
5. 在釋出的過程中發現了哪些意外問題？
在釋出的過程中發現有些手機安裝之後第一次啟動的時候會出現閃退的情況，再次運作的時候又可以運作了，可能是App的穩定性存在問題導緻手機安裝App的時候會閃退。
6. 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
對于該階段，我們學會了用正式的計劃和架構開發項目，完成情況比較樂觀，但是因為一套完整的管理措施和制度化的規劃，是以實作過程中存在很多的誤差，但是因為成員數量并不多，是以商議調整還算比較及時。
團隊的角色，管理，合作
1. 團隊的每個角色是如何确定的，是不是人盡其才？
團隊的每個角色是按照每個人的擅長的領域确定的。
2. 團隊成員之間有互相幫助麼？
有，成員是一起學習一起讨論的。
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
因為我們這個項目隻有3個人，是以沒有出現項目合作方面的沖突。
4.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
該項目的完成讓我們學會了如何規範正式得按照開發模式開發項目，如果能重來一遍，我們會計劃設計更加詳盡，少走彎路，提高開發效率。
總結:
1.你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
目前團隊屬于CMMI一級，屬于完成級。在完成級水準上，對項目的目标與要做的努力清晰，項目的目标得以實作，但是對計劃與流程的規劃不夠清晰，無法保證任務的完成效率，是以還是屬于完成級的狀态。
2. 你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
磨合的階段，團隊成員還在互相的了解中，對于代碼格式或者團隊之間的規則還不夠清晰，是以目前還是處于磨合階段。
3. 你覺得目前最需要改進的一個方面是什麼?
改進的方面還是團隊的溝通，以及團隊内職責的分化不夠清晰。團隊還是應該經常面對面溝通，多說出自己的意見，提高效率。
部落格要附上全組讨論的照片
團隊成員在Beta階段的角色和具體貢獻：
| 姓名 | 角色 | 貢獻值% |
| 張慧敏 | 前端 | 40 |
| 蘇曉微 | 後端 | 37 |
| 歐陽時康 | PM | 23 |