一、
團隊中每個人針對專案回顧模板中的問題，用markdown語法寫下自己的思考和回答並發布到自己的；
我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們的軟體主要解決藥品庫存量的管理，我們定義清楚，我們軟體面對的使用者是醫生和藥品庫存管理人員，面對的場景是醫院
是否有充足的時間來做計畫?
時間還算充足
團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
肯定會有意見不統一的時候，但是我們最後都能達成一致，如果可以重來一遍我相信我們還會準備的更充足一些，再去減少一些不必要的問題。
你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
做完了有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
暫時還沒有
是否每一項任務都有清楚定義和衡量的交付件?
都可以是否專案的整個過程都按照計畫進行，有什麼風險是當時沒有估計到的，為什麼沒有估計到?
組內任務分的太細，所以導致整合的時候出現麻煩。
在計畫中有沒有留下緩衝區，緩衝區有作用麼?
有，可以適當的調節專案中的不足
將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
學到了團隊合作的方式，如果可以重來一遍我們會更好的去溝通問題。
我們有足夠的資源來完成各項任務麼?
有各項任務所需的時間和其他資源是如何估計的，精度如何?
按照任務量去估計，精準度還可以
測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
足夠，沒有低估
你有沒有感到你做的事情可以讓別人來做（更有效率）?
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
我感覺的效率還可以，但是還可以更好。
每個相關的員工都及時知道了變更的訊息?
都可以及時知道
我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
必須實現
專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
有清晰的定義
對於可能的變更是否能制定應急計畫?
有自定員工是否能夠有效地處理意料之外的工作請求？
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
我們需要的是一直不斷地溝通，才能更好的完成。
設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
是合適的時間，合適的人
設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
有，經過不斷地溝通去解決
團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？
是**複審（code review）是如何進行的，是否嚴格執行了**規範？
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
部分**還是有不規範的
團隊是否有乙個測試計畫？為什麼沒有？
有是否進行了正式的驗收測試？
是團隊是否有測試工具來幫助測試？
沒有總結:
團隊合作
專案回顧 總結
設想和目標 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？一些小的功能細節 清楚 有。2.是否有充足的時間來做計畫?有。3.團隊在計畫階段是如何解決同事們對於計畫的不同意見的？投票，用人數多的計畫。使用者量,使用者對重要功能的接受程度和我們事先的預想一致麼?...
個人回顧總結
答 我們的軟體要解決如何讓同學們在愉悅歡快的遊戲中收穫知識，如何把學習變成一件相對不枯燥的事情，我們利用充足的時間做了計畫，並同夏大偉老師進行商討解決了對於需求的滿足。答 有，相對來說時間相對充裕，但是由於我們要做的是遊戲，乙個全新的東西嗎，所以制定計畫有一些費力。答 我們小組意見都會說出來，如果不...
前端基礎回顧總結
1.塊狀元素block level element 塊級元素在瀏覽器顯示時，通常會以新行來開始 和結束 2.內聯元素 行內元素 inline element 和其他元素都在一行上。高度 寬度 行高及頂部和底部邊距不可設定。其寬度為其內容的寬度 萬一需要調整時 display屬性規定元素應該生成的框的...