1.總結的提綱內容
計畫
1. 是否有充足的時間來做計畫?
beta版本時間與alpha衝刺時間是一樣的，但是安排上比第一次更合理，所以完成的任務與預期相差無幾。
2. 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
在qq群裡討論或者每日會議上討論
3. 你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
大部分的都完成了，有些小細節沒有完成，因為程式大部分已經完成，有些細節要更改就的把程式在大部分進行重寫，非常麻煩。
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
與上一階段類似，沒辦法避免。在程式設計的時候往往會有很多節外生枝的**，後面發現並沒有什麼卵用，最後又刪掉了。
5. 是否每一項任務都有清楚定義和衡量的交付件?
這個倒是沒有。因為每個隊員都有自己的見解，所以一般都沒有強制的要求。
6. 是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
專案的整個過程都按計畫進行，大部分功能基本都實現了，到後面出現了bug在修復上有比較大的問題。
7. 在計畫中有沒有留下緩衝區，緩衝區有作用麼?
有留下緩衝區，基於團隊成員的能力水平參差不齊導致進度會有所偏差所以留下緩衝區是必要的
8. 將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
在不影響進度的情況設定更為合理的緩衝區，盡量不要加班。
資源
1. 我們有足夠的資源來完成各項任務麼?
因為團隊裡的人員充足，所以各自分配的任務也不緊湊，足夠來完成各項任務。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
在任務中估計主要**的編寫時間會花比較多的時間，測試部分主要是人工測試，會比較快。
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
人力資源/硬體資源還是比較足夠的。對於那些不需要程式設計的資源我們一開始以為比較簡單，但實際操作**現的問題難度超出了我們的估計。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
這種問題可以適當向組長提議，但是如果其他人的任務已經在進行，如果交換的話還需要進行交付可能會花費更多的時間，所以又需要考慮更多的細節，所以即使有這種感覺最好是請教你認為能更有效率完成的那個人來讓自己變得更有效率吧。
變更管理
1. 每個相關的員工都及時知道了變更的訊息?
是的，因為在團隊做出變更問題的時候我們都會在群上通知，讓每個成員都知道。
2. 我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
要具體根據程式裡面的銜接關係，一般是先要把主要功能給實現了。
3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
這個沒有，一般覺得程式可以執行了，相應的任務完成了就ok了。
4. 對於可能的變更是否能制定應急計畫?
沒有。一般都是在問題發生的時候才會關注到。
5. 員工是否能夠有效地處理意料之外的工作請求？
有時候有，有時候沒有。突發事件往往是意想不到的，但是有些問題在程式設計的時候往往會有意識到，就會自然的有點防範的相對的措施。
設計/實現
1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
設計工作在最初專案剛剛起步的時候就開始了，組長採
集各組員意見進行安排的。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
模稜兩可的工作是可以模糊的混過去，但是在alpha階段吃過虧了，雖然說過程比較重要，但是分數多少會影響到自身的心態，所以在beta階段模稜兩可的情況團隊比較認真對待，通過組內討論來決定乙個方向的。
3. 團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？
主要是人工測試。
4. 什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
在主介面的數字使用問題，發布之後的重要bug倒是沒有發現，在開發的時候我們主要是去實現功能的，沒有考慮到這些數字的多次使用情況，把情況過於理想化導致沒有考慮到這些可能出錯的環節。
5. **複審（code review）是如何進行的，是否嚴格執行了**規範？
我們嚴格執行了**規範，在複審上沒有話太多的功夫，主要是對有bug的部分**進行了多次審視試圖修復。
測試/發布
1. 團隊是否有乙個測試計畫？為什麼沒有？
測試計畫是由，但是與alpha階段一樣進行的是人工測試，落實情況在這一階段並沒有說比上一階段優越多少，這點做得不夠好。
2. 是否進行了正式的驗收測試？
3. 團隊是否有測試工具來幫助測試？
沒有。4. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
我們團隊主要是通過手動測試並跟蹤軟體的效能的。從實際執行的結果來看，這些測試工作多少還是有一點用的，但是仍然有很多的問題測試不出來，有些bug由於手動測試比較容易忽視掉。
5. 在發布的過程中發現了哪些意外問題？
發布過程的意外問題沒有發現。
附件：cmm/cmmi將軟體過程的成熟度分為5個等級,以下是5個等級的基本特徵：
1． 初始級
軟體過程是無序的，有時甚至是混亂的，對過程幾乎沒有定義，成功取決於個人努力。管理是反應式的。
2． 已管理級
建立了基本的專案管理過程來跟蹤費用、進度和功能特性。制定了必要的過程紀律，能重複早先類似應用專案取得的成功經驗。
3． 已定義級
已將軟體管理和工程兩方面的過程文件化、標準化，並綜合成該組織的標準軟體過程。所有專案均使用經批准、剪裁的標準軟體過程來開發和維護軟體，軟體產品的生產在整個軟體過程是可見的。 目前，公司需要申請的就是已定義級別，通常稱為cmmi3。由此，我們可知cmmi3是cmmi其中的乙個等級。
4． 量化管理級
分析對軟體過程和產品質量的詳細度量資料，對軟體過程和產品都有定量的理解與控制。管理有乙個作出結論的客觀依據，管理能夠在定量的範圍內**效能。
5． 優化管理級
可集中精力改進過程，採用新技術、新方法。擁有防止出現缺陷、識別薄弱環節以及加以改進的手段。可取得過程有效性的統計資料，並可據進行分析，從而得出最佳方法。 每個等級都被分解為過程域，特殊目標和特殊實踐，通用目標、通用實踐和共同特性。
總結
1.你覺得團隊目前的狀態屬於cmm/cmmi中的哪個檔次?
二級，已管理級
2.你覺得團隊目前處於萌芽/磨合/規範/創造階段的哪乙個階段?
目前團隊已經完成了beta階段的衝刺，我覺得我們進入了不成熟的規範階段。
3.你覺得團隊在這個里程碑相比前乙個里程碑有什麼改進?
團隊的任務分配和積極性比上一階段好多了，beta階段進行會比alpha更得心應手。
4.你覺得目前最需要改進的乙個方面是什麼?
組內成員要對程式提出自己的意見盡量去實現。
b. 部落格要附上全組討論的**
2.團隊成員在alpha階段的角色和具體貢獻：
名字
角色
團隊貢獻分
可驗證的貢獻
陳麟鳳pm主要**撰寫，分配工作
陳宇杰dev
部分**，部落格
黃海鴻test
測試，部落格
康建燦dev
部分**，測試
許明濤test
測試，部落格
張志傑dev
主要**撰寫，部落格
事後諸葛亮分析
這個作業屬於哪個課程 這個作業要求在 homework 11154 這個作業的目標 事後分析報告 目錄1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？答 我們軟體主要解決班級裡面用通知群作為通知手段的一些痛點。定義其實並不是特別清楚，還有一些場景沒有描述。2....
事後諸葛亮分析
一.設想和目標 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？我們的軟體預期在實現最基本的打卡工具的基礎上，新增番茄鐘專注功能和社交圈子吸引使用者，定位明確。但有些使用邏輯略顯累贅，後期稍有修改，但還有地方可以做到更好。2.我們達到目標了麼 原計畫的功能做到...
事後諸葛亮分析
目錄我們的軟體要解決使用者想聊天卻找不到人時，可以在網路上找到有緣人排洩情緒。在前面的部落格中已經有很清楚的定義和對典型使用者和典型場景有清晰的描述。團隊有充足的時間來做計畫，同事們對於計畫的不同意見時，先相互辯論，如若不能解決，則採取各退一步的方式進一步協商。每一項任務都有清楚定義和衡量的交付件，...