軟體工程 garbagesorting專案postmortem
設想和目標
1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
解決垃圾分類**問題
定義清楚
有清晰描述
2. 是否有充足的時間來做計畫?
計畫時間是比較短的，但是我們在工程中不斷完善這個計畫。
3. 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
人少，好協商。
如果歷史重來一遍, 我們會做什麼改進?
我們會重點分析好客戶的需求，做好前期的準備工作，增加測試時間，測試壓力規模。
計畫1. 你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
都做完了。
2. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
比較少有這樣的事，前期分工比較明確，對工作的認識比較清楚，所以沒做什麼無用功。
3. 是否每一項任務都有清楚定義和衡量的交付條件?
是4. 是否專案的整個過程都按照計畫進行?
沒有，因為中間有其他事情（備考）耽誤了。
5. 在計畫中有沒有留下緩衝區，緩衝區有作用麼?
有，考試後都是緩衝區，有作用，能有時間做優化。
6. 將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
將來會抓緊工作，爭取多留一些緩衝時間，因為軟體可能有一些不足需要新增豐富的功能。
如果歷史重來一遍, 我們會做什麼改進?
大家都很自覺，希望下次能按計畫。
資源1. 我們有足夠的資源來完成各項任務麼?
有，在網上能找到一些資料庫資料和具體功能的教學部落格
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
時間看自覺，精度不大
3. 使用者測試的時間，人力和軟體/硬體資源是否足夠?
硬體是足夠的，時間不夠，人力夠，軟體是夠的。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
沒有。如果歷史重來一遍, 我們會做什麼改進?
變更管理
1. 每個相關的員工都及時知道了變更的訊息?
2. 我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
以工作的重要性決定推遲和必須實現，與專案關係不大的功能推遲，關係密切的列為必須實現。
3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
功能完善，bug少
4. 對於可能的變更是否能制定應急計畫?
能5. 員工是否能夠有效地處理意料之外的工作請求？
有如果歷史重來一遍, 我們會做什麼改進?
多開會交流，更合理的分配工作
設計/實現
1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
張雨軒是設計員，我們認為他是合適的人員。設計時間也是專案開始時，比較合適。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
有，協商+實踐檢驗
3. 團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？
uml有用到，其他的太複雜，沒用學會用
4. 什麼功能產生的bug最多，為什麼？
搜尋功能，很多時候搜不到結果或者結果沒有準確性
5. **複審（code review）是如何進行的，是否嚴格執行了**規範？
沒有嚴格是**規範，但組員們的風格都比較好，都有注釋，縮排。
如果歷史重來一遍, 我們會做什麼改進?
在專案開始就設計好軟體架構和資料庫結構，規範**
測試/發布
1. 團隊是否有乙個測試計畫？為什麼沒有？
有測試計畫
2. 是否進行了正式的驗收測試？
3. 團隊是否有測試工具來幫助測試？
沒有，完全自己測試
4. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
團隊人工測試，主要看搜尋時間來判斷功能的效率，有用，介面切換時載入應該再快一點。
5. 在發布的過程中發現了哪些意外問題？
如果歷史重來一遍, 我們會做什麼改進?
做好測試計畫，用好的測試軟體來幫助測試。
（會議）
1) 對比敏捷的原則, 你覺得你們小組做得最好的是什麼?
計畫是隨著專案進度而不斷變化的，從而更加適應計畫的變化
團隊專案總結
設想和目標 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？我們的軟體要解決的就是讓學生們可以自由的處理他們不想要但並未失去價值的東西 並且對典型使用者和典型場景有清晰的描述。2 是否有充足的時間來做計畫？我們有充足時間來做計畫 3.團隊在計畫階段是如何解決團...
團隊 團隊程式設計專案作業名稱 專案總結
1.專案名稱 象棋遊戲 2.小組成員 高魯瑩，王梓晗，董馨遙，楊璐，崔曉爽，安澤鵬 3.開發背景 周圍有很多人喜歡玩象棋遊戲，本以為是很簡單的開發過程，沒想到費了這麼多周折，開發出的也僅僅能進行人機對戰。4.需求分析 棋盤棋子的局面 滑鼠響應控制棋子移動 棋子的走法規則 人機對弈的搜尋演算法 勝負判...
專案團隊失敗總結
在一次創業專案中，我獲得了大量的經驗教訓，我深刻反思了一下作為技術人員自身的問題，包括團隊中其他人的行為，也包括我個人的錯誤處理方法。產品方向 專案團隊自認為對gamebryo非常了解，專案負責人宣揚客戶端人員實力可以重新打造更加優化的3d引擎版本，實踐說明我們的團隊不具備相應的實力，而且我們開發遊...