我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們軟體要解決社團場地分配和人員資訊變動問題，定義清晰，使用者和場景有清晰描述
是否有充足的時間來做計畫?
是，在做這個專案之前，我們進行了廣泛的人群調研與需求分析，基於alpha階段的工作，beta階段吸取了之前的教訓，效率上有所提高，時間相對充裕。
團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
每晚8點在群內說明自己的今日完後進度，0點說明自己次日的目標計畫，由組長記錄整合，歸檔。
團隊成員對開發中的哪個環節存在疑問在或建議在群內提出，並@相應負責人，不知道負責人時，統一@組長。出現衝突時，組長聽取衝突雙方意見後做最終決策，組員依然反對則在群內發起投票以多數服從少數為原則。
使用者量、使用者對重要功能的接受程度和我們事先的設想一致嗎？我們離目標更近了嗎？有什麼經驗教訓？
使用者量，使用者對重要功能的接受程度未達到一致，但離目標接近了，只實現了進本功能，無法實現較好的功能要求
如果歷史重來一遍，我們會做什麼改進？
對任務時間進行更細緻的安排，對人員任務劃分要更細緻
你原計畫的工作是否最後都做完了?
都已做完
有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
前期倉庫搗鼓了不少時間，本來是使用svn做專案管理，發現課設要求用git，又不得不切換專案管理工具。
是否每一項任務都有清楚定義和衡量的交付件?
對每一項任務都有清晰的說明
是否專案的整個過程都按照計畫進行?
專案整個過程按照階段劃分進行
在計畫中有沒有留下緩衝區，緩衝區有作用麼?
沒有考慮。緩衝區有作用，比如專案出現問題，可以緩一緩
將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
會留緩衝區，應對緊急情況。成員之間建立起互相監督的機制，提高效率。
加強組員交流，減少理解偏差
如果歷史重來一遍，我們會做什麼改進？
大家學到了專案開發有時不是乙個人的事情，一定要相互配合好，每個人都是這之中非常重要的一環，做事不能一意孤行。
要及時完成計畫中的任務。任務分配應該合理而明確。
我們有足夠的資源來完成各項任務麼?
有老師以及同學的幫助，和在網上的各種資料
各項任務所需的時間和其他資源是如何估計的，精度如何?
每晚8點在群內說明自己的今日完後進度，0點說明自己次日的目標計畫，由組長記錄整合，歸檔。
使用者測試的時間，人力和軟體/硬體資源是否足夠?
各項資源都足夠。
你有沒有感到你做的事情可以讓別人來做（更有效率）?
有，但也按時完成了任務。在任務分配時，根據組員的實際情況和意見，進行分配
如果歷史重來一遍，我們會做什麼改進？
在這個階段我們學到很多東西，在團隊方面學會合作互相幫助，在專案上面，學會如何測試，如何美工，如何程式設計。如果歷史重來一遍，分配時，應該更加明確些，具體到某一點的哪些內容，否則會出現隊員做了相同的事，而產生了無用功浪費了人力物力。同時溝通真的很重要，隊員間要多多加強溝通，防止因為誤解隊員的意裡而產生誤會。
再者就是要提前準備好申請服號所需的資料。以及開發流程需要的技術
每個相關的員工都及時知道了變更的訊息?
及時知道，因為我們有任務群，會及時通知
我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
在剛接手專案的時候，我們小組就開過會討論，並確定了專案的核心功能。
專案的出口條件（exitcriteria）有清晰的定義嗎?
一定的使用者先體驗，反饋良好。
對於可能的變更是否能制定應急計畫?
能，每日例會可以及時制定
員工是否能夠有效地處理意料之外的工作請求？
可以。如果得知意料之外的任務請求，我們會經過小組討論接受挑戰，爭取完成任務。
如果歷史重來一遍，我們會做什麼改進？
學到了為防變更而制定應急計畫，如果歷史重來一遍，首先應明確整個開發過程大體要做哪些事，將較大的模組落實到個人負責。
設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
確定需求後開始設計。合適的人
設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
有，討論解決
團隊是否運用單元測試（unittest），測試驅動的開發（tdd）、uml,或者其他工具來幫助設計和實現？這些工具有效麼？
沒有什麼功能產生的bug最多，為什麼？
因為進行**測試時，大家會把出現的問題記錄下來共同解決。多少會存在一些隱蔽的問題剛開始沒能發現
**複審（codereview）是如何進行的，是否嚴格執行了**規範？
在**開發之前我們就有規定**編寫的規範問題，所以為**複審帶來了很大的便利。**複審的工作由參與**編寫的人員來執行，互相檢查彼此的**然後找出問題，再共同解決。因為參與開發的人員不多，所以能夠嚴格執行**的規範
如果歷史重來一遍，我們會做什麼改進？
設計進行改進
團隊是否有乙個測試計畫？為什麼沒有？
沒有。我們是開發一部分功能就先進行測試，測試無誤後才繼續進行後續的開發。
是否進行了正式的驗收測試？
有對每一部分功能進行正式的驗收測試
團隊是否有測試工具來幫助測試？
用夜神模擬器進行測試基本功能
團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
各個模組的測試分配給各個測試組員，這些組員進行用例測試。改進的方面就是大家應該在如何運用測試軟體上多做些學習，這樣可以保證正確的執行測試任務同時節約時間提高效率。
在發布的過程中發現了哪些意外問題？
出現的意外有，發布的時候有晚點，在部落格提交的時候完了一天。
伺服器配置不當，埠開放除錯問題等
我們學到了什麼?如果重來一遍,我們會做什麼改進?
學到了測試計畫的重要性，如果重來將安排嚴謹的測試計畫
1沒有根據每個人的擅長進行劃分
2功能實現不夠完善
3.不同意見時經常開會討論，完善需求
專案整體回顧
專案介紹 專案中所涉及的效果有 抽屜效果，資料載入動畫，輪播圖 其他 此專案總所涉及的一些技術包括上面提到的還有 資料解析 主要是js解析和第三方解析 資料的本地訪問 下面我就這所有功能的實現進行詳細的講解 1.暴走雜誌的頁面內容展示 我一般搭建展示類的頁面時通常喜歡用xb，storybord，也就...
專案回顧2
size large size 11月10號是週三，周二的時候下了一場小雨，週三是晴天。照例早上到公司開專案例會，主要的內容大概是目前專案測試的問題主要集中在申請這塊，有些bug還不是很容易解決。會議之後就進入工作狀態了，這個時候還是主要用打包好的管理工具進行測試。也就是先修改程式，然後提交，然後打...
專案回顧3
04年12月1號專案成功open，休假一天，結果2號的早上鬧表忘記開啟了，第一次華麗的遲到。趕緊給人事打 然後急忙的起床奔公司而去。晚上的時候開會，討論下一步的工作計畫。3 4號這兩天正常工作，當然這時候的正常工作是很忙，而且最早要晚上九點下班，11點下班算正常。5號的時候又來了乙個通宵，6號早上的...