可以說是的。一般都什麼重要的訊息都會第一時間發布在群裡，並且當天開會時再強調一遍，確保每個相關隊員都能知道。
q2：我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
按照之前討論過的優先順序以及專案實際進展來決定，先實現優先順序高的，優先順序靠後的在時間不足的情況下推遲實現。
q3：專案的出口條件（exitcriteria–什麼叫「做好了」）有清晰的定義麼?
定義：介面優美、使用友好、無明顯bug。
以及乙個終極評判標準：該專案可否成為團隊成員的自留產品。
q4：對於可能的變更是否能制定應急計畫?
可以的。
q5：員工是否能夠有效地處理意料之外的工作請求？
可以的，他們都很聰明:d
q6：我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
-個人覺得在管理這一塊我們團隊做的還算可以，暫時沒有發現有什麼太大的問題。
第n周新增**（行）
累計**（行）
本週學習耗時(小時)
累計學習耗時（小時）
重要成長
1803
8039
9學習了json的使用，還有分配原則的相關嘗試
2355
1158
2332
學習了前端知識，android studio的初嘗試，還有一點js相關的學習
3600
1758
2052
android studio的更多學習，還有一點okhttp
Alpha事後諸葛亮
aruba小組cento專案postmortem 408409 410428 429431 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？主要解決文字摘錄愛好者的摘錄癢點 應用間切換的不方便。定義清楚，我們知道要做的東西會是個什麼樣子。需求分析階段，典型使用...
Alpha事後諸葛亮
我們的軟體要解決的問題是對福大校內各個任務群 拼車群的資源整合，方便校內學生以更高的效率拼到車或發布任務。另外還有乙個板塊用來給大家討論。定義得清楚。有。目標達到了。功能都完成了，也按計畫交付了，但是尚未對外開放。使用者對重要功能的接受程度和我們事先的預想一致。我們離目標更近了。比如需要更早的開啟專...
alpha事後諸葛亮
達到了一部分的目標並按照計畫時間交付，但還未達到原計畫的使用者數量。軟體還未開放公測，小範圍內測中。使用者對重要功能的接受程度和我們事先的預想基本一致，離目標越來越近了。經驗教訓 想做的東西太多，但時間和準備上的不充足，讓我們不得不放棄許多功能。如果歷史重來一遍，我們會重新分析需求，細化任務分配，挑...