團隊做業9——過後分析（Beta版本）

 

設想和目標

1. 咱們的軟件要解決什麼問題？是否認義得很清楚？

咱們軟件要解決的就是音樂播放器因爲功能的繁瑣，從而致使它不適用部分手機內存過小，老年人使用不方便等問題，咱們的音樂播放器只經過獲取到本地音樂的播放源，對應音樂的專輯背景，對其進行播放，以及音樂的歌詞滾動，列表的循環方式從而減少了app的內存佔用，以及簡單明瞭的使用方法。

定位就是一款不佔內存，功能簡單的播放器。

 

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

   咱們完成了大部分的目標，播放器在安裝到本地後能獲取到音樂，圖片，同時也能對歌曲進行順序播放，隨機播放等功能，能監聽手機的來電事件，同時對歌詞文件的獲取時常會不顯示這個功能未能完善。只按照原計劃交了一個比較完善的版本。由於這個項目對咱們組來講是屬於學習的階段，因此還達不到上線的程度，天然，原計劃的用戶數量沒有達到。    

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

跟上一個階段相比，團隊的開發效率明顯提升了，分工也更明確了。在上一個階段，播放器安裝後還總會由於一些緣由閃退，播放聲音出錯等，在這個階段播放器改善後，整個播放器能完整使用，由於第二階段時間相對富餘，因此界面改善得更加人性化，也修復了alpha階段的一些bug。

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

 對於現階段而言，用這樣的形式交付項目咱們都是新手，可是部分仍是一致的，老年人用起來仍是比較順手，不存在不知道該怎麼使用這個播放器的地方，而針對年輕人的羣體，雖然內存小，可是沒辦法實時的獲取新歌，沒法知足他們的需求，從而仍是和咱們事先預想的有誤差。離目標仍是有必定的距離。

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

   若是歷史重來一遍，在初期對需求的分析須要有更多的數據從而能更好的分析各個羣體的需求，以及在計劃定製，完成計劃的過程須要更多的耐心和督促，在開發過程當中，多花一些時間完善項目。

計劃

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

時間不是特別多，計劃作的比較草率，在需求分析階段沒有明確的框架和概念，對於項目計劃比較粗略。

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

成員對於該項目的時間分配不可能作到一致，大部分以少數服從多數的原則，同時少數的理由若是足夠充分說服其餘人，若是避免不了一些客觀狀況，計劃也是能夠適當變更的，慶幸的是此次團隊項目沒有大的意見衝突。

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

原計劃大部分是交付了，可是沒有都作完，也有由於一些bug和經驗不足陷入誤區耽誤開發的時間，也有花費的時間不夠的緣由。

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

有，有時候發現重點的位置都是在一直循環一個錯誤，應該早點與隊友討論，纔不會讓本身一直陷在錯誤裏面。

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

大部分任務有，可是功能點的定義和衡量可能沒有那麼詳細得說明。

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

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

 未來的計劃可能會在分配任務上更加詳細，讓你們都知道本身負責的部分在哪裏，纔不會各類混亂

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

 咱們學到了計劃在項目開發的過程當中是很重要的，計劃決定了整個項目可否進行的頗有條理，因此若是歷史重來一遍，咱們會詳細的指定計劃，並在一段時間開會對計劃進行從新整改。

 

資源

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

    人力資源上：咱們組的成員只有3我的，任務完成的時間實際上是很緊迫的。

    開發資源上：Android開發App已是爛大街的技術了，網上也有不少資源能夠學習，可是在相對緊湊的時間裏要學會框架的部署，界面的設計，功能的實現，和sqlite的使用，從而 作出一個能夠交付的小型的demo，其實任務是艱鉅的，不過，由於成熟的技術，大量的學習資源，因此學習到的也不少。

    設備資源上：開發這樣小型的App，設備資源是不足爲慮的。

    時間資源上：在此次團隊項目總，由於咱們要同時學iOS，Android兩門語言，還有其餘的課程安排，因此時間是比較不足的。

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

    各項任務所需的時間和其餘資源是根據任務量估計的，精度方面，alpha階段作的不大好，對於這樣的開發模式比較生疏，，因此估計有些偏差，可是在第二個beta階段就作的相對好一些，精度也準確了。

1. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案）是否低估難度? 

除了軟件/硬件資源是充足的，其餘的資源都相對緊缺，其中最缺少的仍是時間資源。相對於功能的實現，美工和設計的難度對於咱們來講不算難，更況且隊裏有兩個女生，在美工設計方面不算有什麼難度。

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

由於該項目的成員只有3我的，因此每一個人都分配了挺多的任務，因此耦合性仍是挺大的，不多存在某個任務須要別人來完成。

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

          須要改進的方面就是資源要是能多一些就行了，尤爲是人力資源和時間資源上。

變動管理

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

是，每一個相關的成員都能及時知道變動的消息，由於是一個宿舍的，成員又只有3我的，對於小型的變更直接發文件給對方。

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

從兩個方面考慮，一個是實現難度，還有資源消耗。若是一個功能點實現難度是比較大的，代碼量也比較多，就能夠決定推遲，若是是已經花費了必定的時間和人力的資源，且已經明確分配的功能，就是必須實現的功能。

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

             APP無崩潰、閃退等現象。

            測試發現的Bug獲得修復。

            典型用戶場景獲得測試並沒有bug。

            測試矩陣中的典型狀況獲得測試並沒有bug。

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

    能，在不影響總體工程完成的狀況下，具體狀況具體分析，解決。

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

           能夠，對於該項目的完成難度，時間充裕的狀況下咱們是能夠處理意料以外的請求的。

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

           變動是項目開發過程當中常見的現象，可是一個有計劃，有條例的計劃是能夠減小變動的出現的，也能夠減小資源的消耗，因此，若是歷史能夠重來的是，咱們會更加劇視計劃設計的合理設計的。

設計/實現

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

在alpha階段，咱們沒有明確的設計計劃，因此在beta階段的時候，咱們就設計了總體工做的框架，一塊兒商議各類任務的實現計劃，對於功能點的實現，是咱們三個商議分配的，前端的設計主要是兩個女生負責，後端的實現是三我的共同完成的，測試則有歐陽時康完成，項目的bug修復和文案記錄主要是我和蘇曉微完成的。

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

有遇到，通常若是是難度較大的設計工做，就放到後期如果時間容許的狀況再商議，如果難度不大的狀況，細化以後分配給各個成員完成。

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

沒有用到單元測試，該項目是基於移動平臺開發的一款小型App，暫時沒有用到代碼測試工具測試，咱們在跟進項目的完成狀況的時候通常是直接在模擬器或者真機上運行測試。

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

    實現sqlite接口的時候產生的bug最多，起初沒有添加讀取sd卡的權限，致使歌曲加載錯誤，以及涉及到數據的加載，和最近播放的音樂的數據的封裝，這些都是須要實現的，因此要全面得考慮才能夠。

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

         代碼複審沒有嚴格按照代碼規範進行，只是針對本身實現的功能代碼從新審讀。

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

          開始的時候並無對於項目的設計並無成文的詳細的計劃，只以爲分配完任務後就能夠，各自完成本身的工做，後來發現由於事先設計的計劃不充分，出現了項目完成進度有所偏差。因此一個明確的設計能起到事半功倍的效果。

測試/發佈

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

咱們團隊是有一個測試計劃的，在beta階段由於在alpha階段的時候就已經完成了一部分，因此只針對beta階段的工做加以測試。

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

驗收測試不算正規，只是大體完成。

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

  沒有，採用的是人工測試。

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

  軟件的效能主要是指併發性和壓力測試，因爲這款音樂播放器是基於本地資源的操做，因此不存在併發性的問題，咱們是在不一樣型號的手機上進行測試，功能效果還行。

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

 在發佈的過程當中發現有些手機安裝以後第一次啓動的時候會出現閃退的狀況，再次運行的時候又能夠運行了，多是App的穩定性存在問題致使手機安裝App的時候會閃退。

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

       對於該階段，咱們學會了用正式的計劃和框架開發項目，完成狀況比較樂觀，可是由於一套完整的管理措施和制度化的規劃，因此實現過程當中存在不少的偏差，可是由於成員數量並很少，因此商議調整還算比較及時。

 

團隊的角色，管理，合做

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

     團隊的每一個角色是按照每一個人的擅長的領域肯定的。

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

    有，成員是一塊兒學習一塊兒討論的。

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

    由於咱們這個項目只有3我的，因此沒有出現項目合做方面的衝突。

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

           該項目的完成讓咱們學會了如何規範正式得按照開發模式開發項目，若是能重來一遍，咱們會計劃設計更加詳盡，少走彎路，提升開發效率。

總結:

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

          目前團隊屬於CMMI一級，屬於完成級。在完成級水平上，對項目的目標與要作的努力清晰，項目的目標得以實現，可是對計劃與流程的規劃不夠清晰，沒法保證任務的完成效率，因此仍是屬於完成級的狀態。    

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

         磨合的階段，團隊成員還在相互的瞭解中，對於代碼格式或者團隊之間的規則還不夠清晰，因此目前仍是處於磨合階段。   

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

         改進的方面仍是團隊的溝通，以及團隊內職責的分化不夠清晰。團隊仍是應該常常面對面溝通，多說出本身的意見，提升效率。

博客要附上全組討論的照片

 

 團隊成員在Beta階段的角色和具體貢獻：

姓名	角色	貢獻值%
張慧敏	前端	40
蘇曉微	後端	37
歐陽時康	PM	23