問：我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
答：問題和需求明確，但是典型使用者，典型場景好像只是只是口頭說說了。
問：是否有充足的時間來做計畫
?答：我們覺得需求和計畫是這次實踐中最重要的問題，當然有。
問：團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
問：你原計畫的工作是否最後都做完了
? 如果有沒做完的，為什麼
?答：基本做完，有幾個沒做完。沒做完的原因是：不懂怎麼做。比如記憶體消耗過大和tag編輯介面的調整（後邊這個問題看似容易，實則複雜，不好表述）
問：是否每一項任務都有清楚定義和衡量的交付件
?答：對於一些美化工作是有的，但是對於一些增加功能的工作只是實現功能，之後才討論的怎樣確定最終成果。
問：是否專案的整個過程都按照計畫進行
?答：沒有。每個人總有每個人的事，計畫趕不上變化啊！
問：在計畫中有沒有留下緩衝區，緩衝區有作用麼
?答：沒有。導致了上面那個問題的發生。最後就趕啊趕
問：將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
答：細化任務，增加緩衝區。
問：我們有足夠的資源來完成各項任務麼
?答：圖書館加網路是無敵的。
問：各項任務所需的時間和其他資源是如何估計的，精度如何
?答：根據個人能力，讓任務執行者估計所需時間，精確到天。
問：使用者測試的時間，人力和軟體
/硬體資源是否足夠
?答：基本是誰有時間誰測。測試做的不好，需要加強。
問：你有沒有感到你做的事情可以讓別人來做（更有效率）
?答：肯定有。但是人的精力是有限的，盡力就好。
問：每個相關的員工都及時知道了變更的訊息
?答：有時沒有。tfs用起來太麻煩。
問：我們採用了什麼辦法決定「推遲」和「必須實現」的功能
?答：河蟹討論。
問：專案的出口條件
（exit criteria
）是否得到清晰的定義
?答：完全不知道這個是什麼。
問：對於可能的變更是否能制定應急計畫
?答：沒有考慮過這個問題。現在想起來，貌似可以，加班加點就是了。
問：員工是否能夠有效地處理意料之外的工作請求？
答：這都什麼問題啊，沒考慮過。
問：設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
問：設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
答：先放著，實踐可出真知。
問：團隊是否運用單元測試（
unit test
），測試驅動的開發（
tdd）、
uml,
或者其他工具來幫助設計和實現？這些工具有效麼？
答：只有手工測試。測試亟待加強!
問：什麼功能產生的
bug最多，為什麼？
答：基本都是改進，bug都不多。最多的還是上面說過的tag編輯功能，完全就是一大泥球。
問：**複審
（code review
）是如何進行的，是否嚴格執行了**規範？
答：貌似沒人考慮了這個問題。
問：團隊是否有乙個測試計畫？為什麼沒有？
答：沒有。低估了其重要性。
問：是否進行了正式的驗收測試？
答：大家一起手動用了一下全部功能算麼？
問：團隊是否有測試工具來幫助測試？
答：沒有。
問：團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
問：在發布的過程中發現了哪些意外問題？
答：沒有。
最後附圖一張。
ps：組長在照相。。。
事後諸葛亮會議
作業資訊 專案內容 所屬課程 18web方向軟體工程 作業簡介 按照專案回顧模板開展事後諸葛亮會議並撰寫回顧報告 作業要求 團隊專案 任務四 第二次衝刺 作業目的 通過回顧軟體設計 開發 測試 構建 發布的整個過程以及團隊合作狀態總結經驗教訓 參考資料 學生姓名 張家林 撰寫人 於金池 趙政綱 王建...
事後諸葛亮會議
此作業要求參見 組名 板磚 組長 李惠璨 組員 張傳玉 朱航序 趙新萍 樊培毅 魏琛 設想和目標 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？2.我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?原計畫的...
20201029 3 事後諸葛亮會議
此作業要求參見 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？我們軟體要解決的問題是 在逢年過節的時候，需要給親朋好友傳送祝福語，發給不同的人需要是不同文字內容的，我們解決的就是將祝福語先分類再提供給使用者，使用者根據自己的需求進行選擇。我們的軟體定義的清楚...