目錄我們的軟體要解決使用者想聊天卻找不到人時，可以在網路上找到有緣人排洩情緒。在前面的部落格中已經有很清楚的定義和對典型使用者和典型場景有清晰的描述。
團隊有充足的時間來做計畫，同事們對於計畫的不同意見時，先相互辯論，如若不能解決，則採取各退一步的方式進一步協商。
每一項任務都有清楚定義和衡量的交付件，基本上沒什麼發現做了一些事後看來沒必要或沒多大價值的事，一步一步探索都是值得的。
專案的整個過程沒有都按照計畫進行，對於每日規劃的任務有時沒有當日完成。
將來的計畫會對一些冗餘的**進行優化，並且可行的話增加一下新功能。
資源不太充足，比如時間和人力，物力資源。
好的程式需要更多的時間和更多的人力，還有伺服器、宣傳所需的資金等等。
各項任務所需的時間和其他資源是根據其複雜度和開發者的熟練程度估計的，精度比較準確。
測試的時間比較少，能用於測試的軟硬體資源也比較少，有些還需要資金。
由於隊員都是同個宿舍，每個相關的員工都及時知道了變更的訊息。
專案的出口條件（exit criteria – 什麼叫「做好了」）在前面部落格已有清晰的定義。
對於可能的變更能制定應急計畫。
組員都能夠有效地處理意料之外的工作請求。
設計工作在專案之初由組員共同協商完成。
設計工作碰到模稜兩可的情況時，團隊採取走一步算一步策略，遇到困難時協商或者上網查詢習慣資料。
團隊運用了單元測試（unit test）。
聊天功能產生的bug最多，因為**量非常大，需要掌握的知識儲備也多。
**複審（code review）是由編寫者自己複審，嚴格執行了**規範。
團隊有乙個測試計畫，在之前部落格已經發布過了。也進行了正式的驗收測試，團隊測試工具有來幫助測試。
從軟體實際執行的結果來看，這些測試工作都很有用。
在發布的過程中發現有人註冊不了，排查過後才知道是密碼長度問題。
團隊的每個角色在專案開始之初已經分配好了，人盡其才。
團隊成員之間互相幫助，取長補短，共進退。
沒有出現專案管理、合作方面的問題。
團隊目前的狀態屬於 cmm/cmmi 中的已定義級檔次。
團隊目前處於規範階段。
目前最需要改進的乙個方面是能力還需提公升。
對照敏捷開發的原則, 我們小組做得最好的是以下原則：
1-我們的最高目標是通過盡早和持續第交付有價值的軟體來滿足客戶；
2-要不斷交付可用的軟體，週期從幾周到幾個月不等，越短越好
3-要善於激勵專案人員，給他們以所需要的環境和支援，並相信他們能夠完成任務
4-可用的軟體是衡量進度的主要指標
5-要做到簡潔，盡可能減少不必要的工作，這是一門藝術
團隊成員在alpha階段的角色和具體貢獻（總分80分）
名字角色
團隊貢獻分
蔡鑫源dev
20羅漢光
pm24
紀培浩dev
22拜合提亞爾
test
14
事後諸葛亮分析
這個作業屬於哪個課程 這個作業要求在 homework 11154 這個作業的目標 事後分析報告 目錄1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？答 我們軟體主要解決班級裡面用通知群作為通知手段的一些痛點。定義其實並不是特別清楚，還有一些場景沒有描述。2....
事後諸葛亮分析
一.設想和目標 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？我們的軟體預期在實現最基本的打卡工具的基礎上，新增番茄鐘專注功能和社交圈子吸引使用者，定位明確。但有些使用邏輯略顯累贅，後期稍有修改，但還有地方可以做到更好。2.我們達到目標了麼 原計畫的功能做到...
事後諸葛亮分析報告
目錄隊伍名 銀河超級無敵艦隊 專案 招新通 集合貼 團隊作業6 複審與事後分析 一 會議 二 設想和目標 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？解決招新時的招新成員資料整理繁雜的痛點，定義清楚，是。詳情可見需求規劃說明書。是否有充足的時間來做計畫?有。我...