1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我的軟體是要建立乙個失物招領**，是乙個為校園裡的失誤招領工作提供便利的平台。我們對專案的定義比較清晰明了，
也有對典型使用者和典型場景有清晰的描述，
2. 我們達到目標了麼（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？)
嚴格來說，並沒有很好達到預期目標，只能說勉強達標。原先計畫的基礎功能基本全部完成，但計畫的高階功能仍有許多未完成的地方。
3. 和上乙個階段相比，團隊軟體工程的質量提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
專案質量較上一階段確實有了很大的提高。較上一階段優化了許多基礎功能如私聊、審核功能等。衡量標準為測試以及模擬體驗。
1. 是否有充足的時間來做計畫?
有充足的時間作計畫，並有對計畫做出調整。
2. 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
我們會把不同的計畫意見詳細列舉出來，並由提出者述說可行性，最後再在組內投票是否執行。
3. 你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
還有相當一部分工作沒有完成。原因在於團隊專案階段有許多外在的干擾因素（其他科的作業、組員有另外負責專案等）。
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
有一部分，在學習階段繞了一些彎路。
5. 是否每一項任務都有清楚定義和衡量的交付件?
是，制定每項任務前我們都會開會討論其交付條件。
6. 是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
大致照計畫進行，但在開發高階功能被延期了。沒估計到的風險是考試、其他科作業等干擾因素，沒估計到的原因是忽略了
團隊專案所在的環境。
7. 在計畫中有沒有留下緩衝區，緩衝區有作用麼?
沒有8. 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
我們學到了制定計畫要盡可能地充分考慮一切必要因素以及一定的可調節性。如果重新來過，我們會更頻繁地討論來制定團隊計畫。
1. 我們有足夠的資源來完成各項任務麼?
前端方面：人手嚴重不足
後台方面：有隊員有部分專案開發經驗
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
通過任務量以及任務難度來估計。誤差在一天左右。
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
不足夠。對於不需要的程式設計資源算正常的估計了難度。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
沒有5.有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
希望討論能更積極，任務分工能更加合理。
1. 每個相關的員工都及時知道了變更的訊息?
我們每隔一定時間就會召開會議，團隊成員都能即使知道變更訊息。
2. 我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
根據功能分析決定功能的優先順序，再通過實際開發進度以及難度做微調。
3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
有較清楚的定義。
4. 員工是否能夠有效地處理意料之外的工作請求？
處理效率一般。
1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
設計工作在需求分析和alpha衝刺階段都有設計，由pm主導會議，經過大家共同討論後決定。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
沒有，團隊成員會在有疑惑的時候及時提出來。
3. 團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？
有用到單元測試，效果顯著。
4. 什麼功能產生的bug最多？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
發帖模組和私聊模組出現的bug較多，發布後有一些顯示bug以及發帖仍有bug。在設計/開發時，設想比較理想化。
5. **複審（code review）是如何進行的，是否嚴格執行了**規範？
一組的一名人員完成編碼後由該組另一人員完成複審。有嚴格執行**規範。
1. 團隊是否有乙個測試計畫？為什麼沒有？
有制定測試計畫
2. 是否進行了正式的驗收測試？
沒有，因為開發進度比較緩慢。
3. 團隊是否有測試工具來幫助測試？
沒有 4. 團隊是如何測量並跟蹤軟體的效能的？壓力測試呢？ 從軟體實際執行的結果來看，這些測試工作有用麼？
每個模組有負責開發的人員進行測試。 從軟體實際執行的結果來看，這些測試工作有用。
5. 在發布的過程中發現了哪些意外問題？
伺服器問題以及一些底層bug。
1. 團隊的每個角色是如何確定的，是不是人盡其才？
由各個成員根據自身實際情況去選擇。基本每個人的長處都得到了發揮。
2. 團隊成員之間有互相幫助麼？
有。我們會在會議上提出遇到的困難，大家一起討論解決。
3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
通過開展臨時會議進行溝通。
1. 你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?
磨合階段
2. 你覺得目前最需要改進的乙個方面是什麼？
對時間的把握。
6. 專案文件的質量如何提高？
事先對文件的格式進行規範化。當專案版本更新時，統一更新文件內容。
7. 對於人的領導和管理， 有什麼具體可以改進的地方？
希望能對各成員的實力有更好的評估，充分發揮其才能。
姓名角色
貢獻分可驗證的貢獻
張博愉後台開發、pm
18.5
發帖模組部分功能的開發、會議召開、部落格撰寫
張潤柏後台開發
19管理員模組的開發、調整開發計畫
周偉建後台開發
21私聊模組的開發、使用者個人設定功能的開發、伺服器部署
鄭堉涵後台開發
19.5
管理員模組的開發、團隊複審
林梓琦後台開發
20.5
發帖模組開發、制定規範
林欽發前端開發
21.5
專案所有前端功能的開發
軟體工程 事後Postmortem 會議
團隊事後分析會議 會議截圖 設想和目標 1.我們所設計的作品要解決的要求？典型使用者和典型場景？想要解決當代大學生社團以及交友問題。典型使用者 在校大學生 典型場景 社團交流 社團招新 2.與之前我們的個人作業和結對作業相比，有什麼進步？文件寫得更多，技術上的進步，團隊交流以及互相推鍋的能力 3.設...
Alpha事後諸葛會議
可以說是的。一般都什麼重要的訊息都會第一時間發布在群裡，並且當天開會時再強調一遍，確保每個相關隊員都能知道。q2 我們採用了什麼辦法決定 推遲 和 必須實現 的功能?按照之前討論過的優先順序以及專案實際進展來決定，先實現優先順序高的，優先順序靠後的在時間不足的情況下推遲實現。q3 專案的出口條件 e...
事後諸葛亮會議
作業資訊 專案內容 所屬課程 18web方向軟體工程 作業簡介 按照專案回顧模板開展事後諸葛亮會議並撰寫回顧報告 作業要求 團隊專案 任務四 第二次衝刺 作業目的 通過回顧軟體設計 開發 測試 構建 發布的整個過程以及團隊合作狀態總結經驗教訓 參考資料 學生姓名 張家林 撰寫人 於金池 趙政綱 王建...