1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們做的是乙個資訊查詢平台，滿足查詢到相同行程的人即可。定義是這樣定義的，大致是這樣描述的，但是，仔細思考，會有很多隱藏的功能，比如：使用者可以檢視自己發布的活動，自己參加的活動，即將參加的活動等，這在前期全部都忽略了。算是分析考慮不周。以及使用者可以退組，就是自己不能去了，一定要有反饋給系統，不然系統提供給其他使用者的資訊，就不準確，造成本系統的混亂和使用者體驗。在後期討論中，發現前期的場景描述太不全面了。
2.你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
原計畫的工作並沒有做完，有組員說實現複雜，在這麼短的時間，大家還有自己的其他事情的前提下，不想花時間實現，這是現實問題；也有組員說，因為中間老師出亂子，比如伺服器蹦了，還有缺少什麼函式介面，需要另外乙個人的時候，在討論組發訊息，不能及時回覆，所以就去搞其他事情，然後就不想做了........還有乙個組員，因為複雜資料庫方面，後期任務較少，然後每天做一些測試，對他而言，剛剛好，所以能夠很好完成。
3.有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
嗯，有，交流不到位，想法不一致，做出來的和討論的壓根不是一樣的東西，討論的時候有問題，沒有提出來，後面回去按照自己的想法做，所以就做了無用功。腦子是個好東西，希望大家開會都帶著腦子。還有就是，做出來的東西，覺得當初為什麼要做這個，好low的東西，但是要做好，使用者體驗感和安全都考慮足夠好，又好難。
至於專案過程中，文件很多，但是都還是很有必要的，任何乙個環節，如果去掉，就覺得不夠完美，每**告，祈禱獨處作用，文件又是在專案中必須的。
4.在計畫中有沒有留下緩衝區，緩衝區有作用麼?
留了一天緩衝時間，很好，因為在上一階段，有一幾處需要修改，開始的時候保證1個小時能夠完成，任何就做了一天時間，很多時候，想象總是完美，但是實際開發過程中，還是會有很多意想不到的狀況。在這個階段重，留了一天，但是由於這個階段，協調做的不好，所以週末耽擱很多任務，都留在了最後一天解決；並且因為有些功能有點難，比如上傳頭像，需要重新定義資料報格式，最開始打算是在其他必須的功能做完後，再來完善這些難點，沒想到，最後卻成了我們偷懶的藉口了。到了最後，難的都懶得做了。怎麼說，緩衝區說好也好，說不好也不好，主要是pm的組員能否做到嚴格要求自己。
5.將來的計畫會做什麼修改？
6.我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
產品的定位吧，把做什麼樣的產品想透徹，這個功能能給產品帶來什麼，必須的功能，很重要，那麼肯定在前面。像我們小組，主要就是發布和查詢，所以其他關於修改資料等其他輔助功能，留在後面做，先把主要功能實現，一有成就感，二主要問題解決，後期就很輕鬆很多。
7. **複審（code review）是如何進行的，是否嚴格執行了**規範？
因為專案太小，很多東西，幾個人都了然於心，像資料庫具體有哪幾個欄位都清楚，所以並沒有什麼特別的**規範。如果以後做大專案，這個是必須的。
何健：前台，24，因為後期前台設計修改的最多，任務最重；
馬帥：測試、資料庫，19；
蔡凱峰：邏輯層，20；
齊爽爽：專案文件，17。
時間任務
負責人day1--11.2
1.搜尋問題，查詢原因：多次搜尋不出結果；
2.發訊息縮小按鈕
何健群組總人數缺陷；
伺服器正常關閉。
蔡凱峰同乙個人同一時間既可以發布活動，又可以加入多個活動，缺陷改進；
每日測試
馬帥小組會議+部落格
齊爽爽day2--11.3
註冊後跳轉到登入頁面；
註冊時有必填資訊提醒；
同一名戶名註冊失敗，提示；
學校和地區限制
何健修改密碼、及前台頁面修改
何健、蔡凱峰、馬帥
使用者查詢自己發布和參加的活動
何健、蔡凱峰
出行成功按鈕
何健、蔡凱峰、馬帥
測試馬帥
小組會議+部落格
齊爽爽day3--11.4
字型改變bug；
黑色風格頁面改進；
幫助裡面：關於和文件兩項修改；
推出群組按鈕
何健退出群組的實現
蔡凱峰、何健
測試馬帥
小組會議+部落格
齊爽爽day4--11.5
小組會議+部落格
齊爽爽day5--11.6
諸葛亮會議（週日晚6點半信部圖書館）
何健、馬帥、蔡凱峰、齊爽爽
會議分析報告
齊爽爽專案**情況整理： 到底有多少行， 多少檔案， 文件在**，如果乙個新團隊要接手這個專案，他們應該怎麼做？ 這有說明麼？
蔡凱峰何健
準備專案展示+ppt
馬帥因為我們會議在晚上9點在信部路燈下面聊的，所以就後面不得**。
Beta階段測試報告
部分博文的 markdown 沒有解析，部分公式解析不出來 匿名投票可以檢視其他的投票 已經結束的投票還可以繼續投 日程提醒中學生可以修改作業 通知提醒功能每次只能提醒一條 換了別人的賬號，可以看之前那位同學的瀏覽記錄 沒有加入過班級的同學，在一些功能使用中會 crash。助教 a，為了了解學生對該...
Beta階段 測試報告
典型使用者資訊 資訊 描述 姓名，年齡，職業 a，20，大學學生收入無 學歷大學在校本科生 使用目的 選課前想要檢視課程資訊指導選課，上課結束後想要評價課程幫助後來的學弟學妹 使用者偏好 善於並且願意給出客觀評價 所佔比例 80 85 典型場景 典型描述 場景測試 典型使用者 a 使用者的需求 1 ...
個人總結 Beta階段
我們在beta 結束之後，每位寫乙個部落格，回顧並總結自己的beta過程，哪些方面做的好的，哪些方面做得不足需要改進的 分析在alpha階段自己提出的五個問題，針對每個問題，結合自己在本學期的軟工實踐，然後自己給出回答。同時，結合beta過程，再根據你的讀書 教材，部落格，參考書 實踐，提出關於軟體...