設想和目標
能監聽手機的來電事件，
同時對歌詞檔案的獲取時常會不顯示這個功能未能完善。只按照原計畫交了乙個比較完善的版本。
因為這個專案對我們組來說是屬於學習的階段，所以還達不到上線的程度，自然，原計畫的使用者數量沒有達到。
跟上乙個階段相比，團隊的開發效率明顯
提高了，
分工也更明確了。
出錯，因為第二階段時間相對富餘，所以介面改善得更加人性化，也修復了alpha階段的一些
bug。
對於現階段而言，用這樣的形式交付專案我們都是新手，但是
如果歷史重來一遍，在初期對需求的分析需要有更多的資料從而能更好的分析各個群體的需求，以及在計畫定製，完成計畫的過程需要更多的耐心和督促
，在開發過程中，多花一些時間完善專案
。時間不是特別多，計畫做的比較草率，
在需求分析階段沒有明確的框架和概念，對於專案計畫比較粗略。
成員對於該項目的時間分配不可能做到一致，
大部分以少數服從多數的原則，同時少數的理由如果足夠充分說服其他人，
如果避免不了一些客觀情況，
計畫也是
可以適當變動
的，慶幸的是這次團隊專案沒有大的意見衝突
。原計畫大部分是交付了，但是
沒有都做完，也有
因為一些bug和經驗不足陷
入誤區耽誤開發的時間
，也有花費的時間不夠的原因
。有，有時候發現重點的位置都是在一直迴圈乙個錯誤，應該早點與隊友討論，才不會讓自己一直陷在錯誤裡面
。大部分任務有
，但是功能點的定義和衡量可能沒有那麼詳細得說明。
將來的計畫可能會在分配任務上更加詳細，讓大家都知道自己負責的部分在**，才不會各種混亂
我們學到了計畫在專案開發的過程中是很重要的，計畫決定了整個專案能否進行的很有條理，所以如果歷史重來一遍，我們會詳細的指定計畫，並在一段時間開會對計畫進行重新整改。
人力資源上：我們組的成員只有3個人，任務完成的時間其實是很緊迫的。
開發資源上：android開發
已經是爛大街的技術了，網上也有很多資源可以學習，但是在相對緊湊的時間裡要學會框架的部署，介面的設計，功能的實現，和
sqlite
的使用，從而 做出乙個可以交付的小型的
demo
，其實任務是艱鉅的，不過，因為成熟的技術，大量的學習資源，所以學習到的也很多。
時間資源上：在這次團隊專案總，因為我們要同時學ios，
android
兩門語言，還有其他的課程安排，所以時間是比較不足的。
各項任務所需的時間和其他資源是根據任務量估計的，精度方面，alpha階段做的不大好，對於這樣的開發模式比較生疏，，所以估計有些誤差，但是在第二個
beta
階段就做的相對好一些，精度也準確了。
除了軟體/硬體資源是充足的，其他的資源都相對緊缺，其中最缺乏的還是時間資源。相對於功能的實現，美工和設計的難度對於我們來說不算難，更何況隊裡有兩個女生，在美工設計方面不算有什麼難度。
因為該項目的成員只有3個人，所以每個人都分配了挺多的任務，所以耦合性還是挺大的，很少存在某個任務需要別人來完成。
1.有什麼經驗教訓?如果歷史重來一遍,我們會做什麼改進?
需要改進的方面就是資源要是能多一些就好了，尤其是人力資源和時間資源上。
是，每個相關的成員都能及時知道變更的訊息，因為是乙個宿舍的，成員又只有3個人，對於小型的變動直接發檔案給對方。
從兩個方面考慮，乙個是實現難度，還有資源消耗。如果乙個功能點實現難度是比較大的，**量也比較多，就可以決定推遲，如果是已經花費了一定的時間和人力的資源，且已經明確分配的功能，就是必須實現的功能。
測試發現的bug得到修復。
典型使用者場景得到測試並無bug。
測試矩陣中的典型情況得到測試並無bug。
能，在不影響整體工程完成的情況下，具體情況具體分析，解決。
可以，對於該項目的完成難度，時間充裕的情況下我們是可以處理意料之外的請求的。
6. 我們學到了什麼?如果歷史重來一遍,我們會做什麼改進?
變更是專案開發過程中常見的現象，但是乙個有計畫，有條例的計畫是可以減少變更的出現的，也可以減少資源的消耗，所以，如果歷史可以重來的是，我們會更加重視計畫設計的合理設計的。
在alpha階段，我們沒有明確的設計計畫，所以在
beta
階段的時候，我們就設計了整體工作的框架，一起商議各種任務的實現計畫，對於功能點的實現，是我們三個商議分配的，前端的設計主要是兩個女生負責，後端的實現是三個人共同完成的，測試則有歐陽時康完成，專案的
bug修復和文案記錄主要是我和蘇曉微完成的。
有遇到，一般如果是難度較大的設計工作，就放到後期若是時間允許的情況再商議，若是難度不大的情況，細化之後分配給各個成員完成。
實現sqlite介面的時候產生的
bug最多，起初沒有新增讀取
sd**複審沒有嚴格按照**規範進行，只是針對自己實現的功能**重新審讀。
6. 我們學到了什麼?如果歷史重來一遍,我們會做什麼改進?
開始的時候並沒有對於專案的設計並沒有成文的詳細的計畫，只覺得分配完任務後就可以，各自完成自己的工作，後來發現因為事先設計的計畫不充分，出現了專案完成進度有所誤差。所以乙個明確的設計能起到事半功倍的效果。
我們團隊是有乙個測試計畫的，在beta階段因為在
alpha
階段的時候就已經完成了一部分，所以只針對
beta
階段的工作加以測試。
驗收測試不算正規，只是大致完成。
沒有，採用的是人工測試。
軟體的效能主要是指併發性和壓力測試，
的時候會閃退。
6. 我們學到了什麼?如果歷史重來一遍,我們會做什麼改進?
對於該階段，我們學會了用正式的計畫和框架開發專案，完成情況比較樂觀，但是因為一套完整的管理措施和制度化的規劃，所以實現過程中存在很多的誤差，但是因為成員數量並不多，所以商議調整還算比較及時。
團隊的每個角色是按照每個人的擅長的領域確定的。
有，成員是一起學習一起討論的。
因為我們這個專案只有3個人，所以沒有出現專案合作方面的衝突。
4.我們學到了什麼?如果歷史重來一遍,我們會做什麼改進?
該項目的完成讓我們學會了如何規範正式得按照開發模式開發專案，如果能重來一遍，我們會計畫設計更加詳盡，少走彎路，提高開發效率。
目前團隊屬於cmmi一級，屬於完成級。在完成級水平上，對專案的目標與要做的努力清晰，專案的目標得以實現，但是對計畫與流程的規劃不夠清晰，無法保證任務的完成效率，所以還是屬於完成級的狀態。
磨合的階段，團隊成員還在相互的了解中，對於**格式或者團隊之間的規則還不夠清晰，所以目前還是處於磨合階段。
改進的方面還是團隊的溝通，以及團隊內職責的分化不夠清晰。團隊還是應該經常面對面溝通，多說出自己的意見，提高效率。
部落格要附上全組討論的**
團隊成員在beta階段的角色和具體貢獻：
姓名角色
貢獻值%
張慧敏前端
40蘇曉微
後端37
歐陽時康
pm23
團隊作業9 事後分析（Beta版本）
1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？單個系統的部分功能 是 是 2.我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?完成原計畫第一部分的需求 3.和上乙個階段相比，團隊軟體工程的質量提高了麼？在...
團隊作業10 複審與事後分析（Beta版本）
2017 6 13 22 00pm，以部落格發表日期為準 晚交 0分 遲交一周以上 倒扣本次作業分數 抄襲 倒扣本次作業分數 以每個班級為單位，每個複審人看本班級其餘團隊的總結展示部落格，以及 質量，實際測試結果，決定名次 沒有並列 說明專案的優點和缺點分析 不少於 140 字 複審人看什麼 複審怎...
團隊作業6 事後分析
每個人都會遇到大大小小的問題，解決這些問題只有當面交流，現場除錯修改的效率才是最高的。我們五個人都是第一次做這種專案類的挑戰，我們明顯覺得單打獨鬥是沒有用的，團結就是力量，每個人的鼓勵都是這個外賣軟體前進的每一步。計畫是否有充足的時間來做計畫?不太夠，後面遇到一些，例如後台管理評價系統有些不太懂，又...