達到了一部分的目標並按照計畫時間交付，但還未達到原計畫的使用者數量。
軟體還未開放公測，小範圍內測中。使用者對重要功能的接受程度和我們事先的預想基本一致，離目標越來越近了。
經驗教訓：想做的東西太多，但時間和準備上的不充足，讓我們不得不放棄許多功能。如果歷史重來一遍，我們會重新分析需求，細化任務分配，挑選最重要的功能來做。
有充足的時間來做計畫，在組完隊後我們就找時間討論要做的產品。
在這個階段中，我們進行了討論，提出自己的看法，有的人提出應該實現什麼功能，在這個過程中是否會出現什麼問題等等，對於不同的意見，使用少數服從多數的方式來解決分歧。
原計畫的工作大部分都完成了，包括完成登入註冊模組、 二手商品的發布等。剩餘的部分比如任務發布還沒有做完，主要是因為臨近期末，大家都有一些考試，時間上不太好協調。
肯定是有的，在剛開始做的時候，並沒有很明確的思路，做了不少無用功。
是，每一次alpha衝刺的**都有上傳到github。
並沒有完全按照計畫進行，比如前端和後端之間的介面還沒有完全確定下來，整個專案在相互聯絡方面並沒有乙個明確的規範，不同人完成的任務會有一定程度上的差異，需要統一，這個情況歸結到底還是計畫不夠細緻和溝通問題。風險的話是安全性方面做得不夠，軟體安全係數低，後期時間足夠的話會考慮伺服器安全部分加強安全性的途徑，以及資料庫部分沒有使用者認證。
有的，緩衝區的作用就是可以幫助我們更好地發現問題和更高效地解決問題，進行交流彌補溝通不足和不明確各部分任務完成情況的缺陷。
基本上沒有什麼修改，只需要花時間把整個軟體的功能做完。
完善計畫和定製計畫同樣重要。原計畫的實施情況已經符合我們的預期，但是在過程中總會有一些意想不到的突發情況，因此及時的微調計畫對於整個專案的實行起到了很重要的作用。如果能重來一次，我希望在制定計畫時能夠留下更多的緩衝時間。
相對來說有足夠的資源來完成各項任務 ，我們組有很多大佬！
根據任務需要學習的內容難易程度還有開發難度，給與適當的時間；根據實現功能實現需要什麼來確定資源，精度一般 。
軟硬體，人力基本足夠，時間資源略有不足。關於美工設計與文案確實有所低估，所需資源分配不夠充足。
沒有。組長在分配任務的時候就考慮了每個人的能力。
經驗教訓還是時間估計的有點錯誤，和考試衝突的太頻繁了，如果再來一次的話，我們一定會更加合理的安排好時間，。
是的。根據實際情況決定。
有，基本完成核心功能，無明顯bug，根據實際使用情況和使用者反饋來定義。
暫時沒有制定應急計畫，對於（未來）可能出現的變更，我們會對相關成員進行積極的溝通。
鑑於我們組會議時分工明確，且基本沒有負擔太多的工作，意料之外的工作請求比較少，因此對於突發情況還是能夠接受的。
對於業務邏輯和產品細節要求應該一開始盡可能的確定，且充分考慮其可行性，預估可能遇到的困難，才能減小變更發生的可能性 。
設計工作在選題報告的時候就開始了 ，由組長梅恆權完成，是合適的時間和合適的人。
設計過程中的確有一兩個地方模稜兩可，是由具體設計的成員提出，然後先在ui設計師內部交流出乙個方案，再來詢問其他開發人員意見。
使用了unit test的tdd工具，它很好的幫助將需求和系統的體系架構轉化成**和視覺化。
主體部分與專案開始的uml文件一脈相承，一些小邊幅的修改需要更新uml文件。
搜尋二手商品時產生的bug最多，有時候會搜尋不出來。 發布後尚未發現什麼重大的bug 。
採用結對程式設計的方法，由另一位同學去審查**尋找問題，嚴格執行了**規範。
掌握了不斷學習新技能的能力和各方面的基礎知識。 如果再來一次，會花更多的時間在討論需求上，同時做好**規範。
有測試計畫。未進行正式驗收測試。
直接在手機上安裝我們的軟體進行使用來測試。
檢視各個函式耗時、記憶體占用、cpu佔用率等，找出效能瓶頸；以及在實際訪問頁面時頁面排版、頁面跳轉是否出現bug。在資料庫測試中，測試查詢最占用時間、最占用系統資源的查詢語句，檢測是否存在死鎖等。測試過程中找到的大部分問題已經進行改善優化。
產品暫時還沒有發布，先進行本地的測試。
學到了html、js、css等web前端開發的必備知識；資料庫的設計和實現，資料庫軟體的使用；以及前後端的互動過程，網頁的運作過程，對整個web開發的流程有了更加深入的了解。如果歷史重來一遍，會更加合理安排時間，安排計畫，加強隊員之間的交流。
是根據大家學習意願，自己選擇前端或者後端學習。還算是人盡其才，大家都盡力做好自己的部分工作。
這是肯定有的，總有學得快的或是之前有小部分經驗的人存在，互相詢問和互相討論也是我們團隊學習技術的方式之一。
不論什麼型別的問題，我們團隊的解決方法第一步都是團隊討論，然後進行集思廣益解決問題。
感謝小組的每乙個人！大家在一起努力衝刺，做好自己的任務，沒有人想要划水。
我們在團隊合作方面，能夠及時溝通解決，沒有出現大的問題，在這一方面我們是比較優秀的。
我覺得團隊目前的狀態屬於cmm/cmmi中的可重複級。
我認為我們團隊目前處於規範階段。
在團隊的分工以及協作能力上大大提公升。
目前專案的功能比較少，因此我認為豐富功能才是應該改進的。
隊員姓名
分工貢獻比
梅恆權團隊專案管理員 （隊長）
10%王瑞卿
產品經理
9%楊歡
前端工程師
11%汪倍民
前端工程師
11%關文濤
後端工程師
11%黃奕頌
後端工程師
10%陳夢雪
美工10%
朱慶章美工
10%黃宇航
資料測試
9%胡康
資料測試
9%很遺憾沒有其他小組對我們進行提問：）
psp2.1
personal software process stages
預估耗時 （分鐘）
實際耗時 （分鐘）
planning
計畫20
20· estimate
· 估計這個任務 需要多少時間
2020
development
開發130
310· analysis
· 需求分析 (包括學習新技術)
50180
· design spec
· 生成設計文件
2030
· design review
· 設計複審
2030
· coding standard
· **規範 (為目前的開發 制定合適的規範)
1020
· design
· 具體設計
1530
· coding
· 具體編碼
1520
· code review
· **複審00
· test
· 測試（自我測試， 修改**，提交修改）00
reporting
報告10
20· test repor
· 測試報告00
· size measurement
· 計算工作量00
· postmortem & process improvement plan
· 事後總結, 並提出過程改進計畫
1020
合計160
350第n周
新增**（行）
累計**（行）
本週學習耗時(小時)
累計學習耗時（小時）
重要成長10
01010學會markdown寫部落格
2500
50026
36學會json格式使用 使用request庫呼叫api30
02157使用axure進行原型設計 設計十三水原型
4600
1100
1673
進行ui設計 設計十三水ui50
1100
1088
學會軟體的選題分析60
1100
13101
學會軟體的需求分析
71200
2300
12113
學會對爬取資料進行 處理並分析利用80
2300
10123
學習mysql
9100
2400
10133
學習django
101000
3400
20153
alpha衝刺
Alpha事後諸葛亮
aruba小組cento專案postmortem 408409 410428 429431 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？主要解決文字摘錄愛好者的摘錄癢點 應用間切換的不方便。定義清楚，我們知道要做的東西會是個什麼樣子。需求分析階段，典型使用...
Alpha事後諸葛亮
我們的軟體要解決的問題是對福大校內各個任務群 拼車群的資源整合，方便校內學生以更高的效率拼到車或發布任務。另外還有乙個板塊用來給大家討論。定義得清楚。有。目標達到了。功能都完成了，也按計畫交付了，但是尚未對外開放。使用者對重要功能的接受程度和我們事先的預想一致。我們離目標更近了。比如需要更早的開啟專...
Alpha事後諸葛亮
組長部落格 我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?使用者量,使用者對重要功能的接受程度和我們事先的預想一致麼?我們離目標更近了麼?團隊在計畫階段是如何解決同事們對於計畫的不同意見的？你原計畫的工作是否最後都做完了?如果有沒做完的，為什麼...