【基於微信小程序的社區電商平臺】Alpha叠代心得
項目團隊：小豆芽
開發周期：11.5-12.2（Alpha版本）
設想和目標
1. 我們的軟件要解決什麽問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
- 解決問題：當前電商平臺賣家買家角色固化，買家在沒有尋求到心儀商品時無法記錄並告知他人，賣家出售商品無法確認是否有市場有需求；
- 軟件定義：基於微信小程序，實現一款可以個性化發布心願或商品，借助圈子個性化營銷的電商小程序；
- 典型用戶：熱愛線上購物的小夥伴；
- 典型場景：肥宅的家中；
2. 我們達到目標了麽（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麽？ 原計劃達到的用戶數量達到了麽?)
目前來看Alpha版本的計劃基本完成。
- 預期實現功能：首頁瀏覽商品，點擊相應商品可以查看其詳情/評論，以及可以選擇加入購物車/關註賣家/直接購買三個功能，搜索欄可以搜索商品，發布模塊實現發布心願/商品，心願單界面對已發布心願的修改或刪除，“我的”模塊是修改用戶昵稱頭像，綁定郵箱手機號，填寫收貨地址，查看購物車和交易記錄等。
- 驗收交付：在第一階段驗收成果，以上功能基本實現，遺留的問題就是微信支付的接口個人小程序無法調用，這是技術之外的又一大難題。
- 用戶數量 這一指標不在本次計劃範圍之內，用戶反饋模塊還未知；
3. 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致麽? 我們離目標更近了麽?
- 在這一階段不考慮上線，接受程度還未知，不過這一模塊的開發目標還是更近了。
4. 有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?
- 在確認需求階段不僅要有創新有難度，還要做好任務難度衡量，因為比較特殊的是這個項目創新需求是團隊自己來提，很容易導致任務難度不在能力範圍之內，比如微信支付功能，在後續開發時才知道個人無法調用，實現困難。
- 會在之後遇到類似情況吸取教訓，歷史不會重來一遍，不後悔選擇這個項目，遇到問題和團隊一起想辦法去解決就OK。
計劃
1. 是否有充足的時間來做計劃?
- 按照課程流程來說，4-6周做出項目整體計劃的完善與原型制作，時間還是充足的；後期開發按照計劃來進 行，有改動也是酌情而定；
2. 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
- 團隊有不同意見很正常，原型計劃階段是開會大家輪流在黑板上畫出自己的簡單構思，大家覺得可行的辦法記錄下來最後一起匯總，這一階段不同意見還不是很大的沖突。
- 數據庫設計階段因為不同意見難以調和確實有點小沖突，哈哈哈哈不過也是很有趣了，既然你不讓我我不讓你最終決定：找老師！在老師指導下發現有些功能單獨做出表會提高檢索效率，有些不必太過精細。準備階段就這樣結束，之後就是開發了。
3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麽?
- 目前這一階段計劃的工作除了微信支付這個小意外，其余基本完成，後期會討論是否去掉這一功能，畢竟可行性的確受硬性條件限制（沒有公司也沒有錢）
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
- 這個只不過有些不熟悉走了太多彎路浪費時間（比如備案）。
5. 是否每一項任務都有清楚定義和衡量的交付件?
- 是，小程序擁有清晰的框架，這一階段基本一個界面對應前端一個文件夾和後臺一個jsp。
6. 是否項目的整個過程都按照計劃進行，項目出了什麽意外？有什麽風險是當時沒有估計到的，為什麽沒有估計到?
- 計劃自然趕不上變化，因為備案原因，一開始只能用ip訪問實現一些小功能，發布上傳圖片必須要域名通過，所以和團隊暫時擱置了這部分，開始其他功能界面開發，險就險在驗收前五天終於完成備案，開始突擊發布模塊和整合所有功能。
7. 在計劃中有沒有留下緩沖區，緩沖區有作用麽?
- 緩沖區的話。。周天驗收，計劃周五通宵完成所有剩余模塊，周六這個緩沖區測試bug，小修改什麽的，不然在deadline最後一天來完成心裏壓力也是有點大。有用是有用，就是通宵才發現以後還是好好養生吧
8. 將來的計劃會做什麽修改？（例如：緩沖區的定義，加班）
- 之後項目註重於算法和美工，所以和前期不一樣，每周都要有個deadline吧，不然算法這塊真不是最後突擊就有用的，而且希望能避免刷夜，真扛不住扛不住。
9.我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
- 整個項目發展到現在，收獲最大的就是真切感受到了一個軟件的生命周期是怎樣運轉的，coding是重要，但是前期的充足準備更能讓開發事半功倍。重來一次，會在需求討論時候多方面考慮。
資源
1. 我們有足夠的資源來完成各項任務麽?
- 可以完成任務，但還沒有到充足的程度，時間比較緊張，沒錢也是硬傷。。。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
- 時間安排大致按照計劃，有些模塊難度較大會延長時間，都是看情況而定，精度不高。
3. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
- 測試的時間不太多，完成每一功能自己會先測試，最終匯總再次測試，但是因為考慮的方面不太全，這次驗收來看還是有遺漏。
- 人力資源還是可以的，軟件/硬件這部分，服務器也是學生價，被吐槽無數次。
- 前期原型設計和過程中的文案，難度可以接受，只不過就是投入時間很重要。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
- 分工還是較為合理的，每一階段每個人都有不同的任務，開發階段也不能只靠代碼能力強的同學。
5. 有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?
- 美工文檔方面還是要精細註重的，接下來這一階段希望整體更加規範。
變更管理
1. 每個相關的員工（組員）都及時知道了變更的消息?
- 是的，每一次變更或討論都會在群裏通知。
2. 我們采用了什麽辦法決定“推遲”和“必須實現”的功能?
- 按照叠代計劃優先級以及實際情況實現可行性。
3. 項目的出口條件（Exit Criteria – 什麽叫“做好了”）有清晰的定義麽?
- 能夠達到叠代計劃裏的預期功能即可。
4. 對於可能的變更是否能制定應急計劃?
- 在微信支付無法實現的情況下選擇調整優先級先做下一功能塊，應急計劃還是視情況來定的。
5. 員工(組員)是否能夠有效地處理意料之外的工作請求？
- 可以，在測試的時候需要更多測試數據，後臺同學能夠及時處理好向數據庫再次添加數據。
6. 我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
- 開發階段溝通很重要，所以這幾周面對面溝通編程時間強度加大。再有一次仍會如此。
設計/實現
1. 設計工作在什麽時候，由誰來完成的？是合適的時間，合適的人麽？
- 設計階段在最初4-6周，PM完成框架匯總大家意見，可以改進的地方隊友再進行修改。時間人員分配較為合適。
2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
- 功能塊細分的時候意見不統一會再次溝通。
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麽？ 比較項目開始的 UML 文檔和現在的狀態有什麽區別？這些區別如何產生的？是否要更新 UML 文檔？
- 運用UML，讓每一個功能塊細化，自然也是在改進，因為項目進行中不同的小意外與實現度加大，UML也是要修改的。
4. 什麽功能產生的Bug最多，為什麽？在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況?
- 發布信息模塊，因為不同其他只是向服務器請求數據，這塊需要上傳數據，因為不太熟悉還有時間問題，bug較多，這一階段還未發布上線。
5. 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
- 小組之間相互檢查代碼，還沒有嚴格執行代碼規範。
6. 我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
- 沒有哪一階段是不重要的，原型設計與代碼規範要註重。
測試/發布
1. 團隊是否有一個測試計劃？為什麽沒有？
- 目前還沒有，會在項目coding結束後集體進入測試，形成測試文檔。
2. 是否進行了正式的驗收測試？
- 是，這是由課程老師安排助教來進行的。
3. 團隊是否有測試工具來幫助測試？
- 目前還沒有。
4. 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用麽？應該有哪些改進？
- 目前還沒有。
5. 在發布的過程中發現了哪些意外問題？
- 目前還沒有。
6. 我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
- 測試階段更要註重細節，今後會投入更多測試檢查時間。
團隊的角色，管理，合作
1. 團隊的每個角色是如何確定的，是不是人盡其才？
- 按照每個人的意願分配，完成效果也很好。
2. 團隊成員之間有互相幫助麽？
- 有，每一次開會編程遇到問題都是互相幫助解決的。
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
- 開會前期每個人會把問題都提出來，面對面溝通最高效。
- 我感謝項目組每個小夥伴，每個人都在努力做好這個項目，才能讓項目進展到現在，也感謝隊友 張鑫平 對的幫助，因為前端開發遇到難題在其講解下才明白問題出在哪裏，該怎麽解決。
4. 我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
- 團隊精神很重要，目前團隊氛圍也很好。接下來會一起攻克剩余的難點。
總結:
你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
- 應該是處於CMM初始級。
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
- 磨合向規範轉型。
你覺得團隊在這個裏程碑相比前一個裏程碑有什麽改進?
- 溝通交流更多，合作效率提高。
你覺得目前最需要改進的一個方面是什麽?
- 開發的代碼規範性問題。
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
- 不論團隊內外，傳遞信息效果最好和效率最高的方式是面對面的交談。
- 這也是目前開發階段我們一直遵守的原則，面對面交談與開發減少不必要的模棱兩可之處，及時發現問題並解決。
- 可工作的軟件是進度的首要度量標準。
- 最基本的測試就是打開小程序看運行情況，能不能和數據庫進行增刪改查的操作是這一階段最主要的工作。
最後這個照片環節，雖然開發階段偷偷收集了隊友大量黑照做表情包，哈哈哈哈但通宵戰友情不能這麽被出賣，那就醬啦。
【基於微信小程序的社區電商平臺】Alpha叠代心得