事後諸葛亮
事後諸葛亮
一、項目的預期計劃
項目計劃書
二、項目的現實進展
已經實作的功能:
- 該平台可以供人尋找兼職
- 尋找丢失的物品
- 閑置物品交易,表白牆等等
- 以及使用者可以自己釋出需求資訊,供他人解決
三、完成項目過程中的體會
- 這次沖刺,首先感受最深的就是時間不夠用,需要學習和消化的新知識太多,平時還要上課和複習部分課程。不過在隊友的幫助下,還是一步一步的完成了這次沖。這次沖刺也暫時告一段落,會好好調整心情,提前開始為下一次沖刺做準備。
- UI設計上,以前經驗較少,是以還是慢慢學習使用較為基礎的東西,設計過程中創些小demo進行試驗,fragment的使用,以及調用系統導入的矢量圖會導緻某些機型上崩潰的問題困擾了我們很久,直到現在也尚未解決
- 可能是沒有經驗吧,感覺做一個軟體是真的不容易,雖然我做的隻是一小部分,但是中間還是出現了很多bug。感謝百度,感謝隊友。
四、團隊成員的分工及在Alpha階段的工作量比例
姓名 | 貢獻量 |
王熙航(隊長) | 15 |
李冠銳 | 14 |
曾磊鑫 | 12 |
鄭沐榕 | 11 |
楊藝勇 | |
劉傑 | |
聶寒冰 | |
戴俊涵 | |
五、下階段展望與團隊總結
下階段展望
- 增加會員功能
- 完善資訊稽核的功能
- 新增釋出短視訊功能
- 改善界面,美化界面
團隊總結
- 需求了解要透徹,需求關乎項目要做什麼,要達到什麼樣的結果,需要在需求階段了解清楚,做到心中有數。另外需求是工作量評估的基礎,要想工作量評估适當且充分,不出現大幅度偏差,就需要客觀了解需求
- 工作量評估做到群策群力,我們會把整體計劃拆分成細小的功能點,然後按照組員的特點,配置設定到具體的開發負責人。由于很多功能點都是互相關聯,單方面評估往往不能反應真實的情況,是以我們會召集專門的評估會議,對某一個功能點由對應的開發負責人和相關的人員一起來确定,確定大家的資訊對稱
- 代碼品質控制擺到重中之重,良好的代碼品質需要工程師付出很多的努力,這些努力都是值得的,為後期測試、BUG診斷、擴充等降低了難度,減少不必要的時間花費
- 單元測試要完全覆寫,開發人員做單元測試,一是檢查自己的代碼是否有缺陷,做到對自己代碼負責;二是可以站在測試的角度去思考問題,可以減少後期測試不必要的測試點,讓項目進度整體可控
- 保持團隊成員的積極性,工作都是人做出來的,組員的工作積極性是項目好壞的決定性因素。做好項目,先必須讓團隊氛圍良好。讓每一人都具備主人翁意識,都可以有自己發展的空間,在自己的領域裡有所建樹,這也是我們團隊能在中後期趕上進度的根本原因,因為大家整個項目開發過程中都保持了強大的積極性,樂在其中
- 項目開發過程中往往是曲折往複的,需要我們的耐心和決心。按時完成一個項目,不管大小,都代表了一種做成事情的能力,比項目本身更重要,它讓我們對未來做成更多事充滿了信心
100) ? false:true" x-data="topBtn" @click="scrolltoTop" x-cloak>