alpha階段問題總結隨筆

這個作業屬於哪個課程

2020春|s班 (福州大學)

這個作業要求在**

團隊作業第六次——beta衝刺+事後諸葛亮

團隊名稱

如果有一天我變得很有錢

這個作業的目標

對alpha階段團隊出現的問題進行總結反思

作業正文

其他參考文獻

無達到目標了嗎？

核心模組中：我們基本完成了手動記賬部分的功能；完成了報表展示的大部分功能；自動記賬部分只是簡單地完成了週期記賬的功能，檔案記賬部分沒有寫完；其他功能如同步功能等，都只完成了部分。不過總的來說，我們在alpha衝刺中完成了大部分的任務，算是達成了原來預想的目標。

經驗教訓

在設計的時候在團隊名等地方出現了些意見不和的問題，浪費了些時間去討論，而且有時候討論的事情可能沒有太大意義。這時候就需要乙個人統一大家的意見，並且朝著這個方向去實現。

設計階段對產品的定位沒有定位的很清楚，出現了老師和同學們對產品的一些誤解：對於記賬軟體的目的，就是為了讓使用更清楚的了解自己的消費習慣，更持久的儲存資料等。我們只能更進一步的優化產品的流程和體驗做到相對的足夠「方便」，而無法避免掉記賬本身固有的「麻煩」的屬性。

設計時沒有對後期實現的產品做出進一步的規劃、對預想到問題做出進一步的思考，導致後面出現了問題，會出現沒有相應的應急預案，只能臨時想辦法解決的情況。

人力/軟體/硬體資源相關；對於不需要程式設計的資源（美工設計等）是否低估難度？

由於開發比較緊張，且沒有給出足夠的緩衝時間，測試的時間稍顯不足，只完成了對專案的基本測試，可能缺少對測試的系統的安排。

不需要程式設計的資源在我們這也是不存在的，總體工作量大，只有每個人都參與才能保證專案完成

有沒有感到某個成員做的事情可以讓別人來做（更有效率）？

說沒有那是不可能的。不過畢竟是團隊開發，有的人比較熟有的人感到陌生，很正常。還是要多包容吧，說不定以後工作自己就是效率較低的那乙個。

計畫及資源部分的經驗教訓

應重視設計階段的文件和風險的評估，對介面和分工做出更細緻的完善工作。我們組對計畫的重視還是不夠完善，事先對介面文件的定義不夠清楚，一些功能也沒有定義驗收標準。導致後期實現的時候需要花時間去完善介面的定義。在驗收的時候也出現了不知道怎麼算驗收合格。

出現進度滯後時需要及時跟進確認，避免對整體計畫的影響

應盡量預留出更多的機動時間，出現意外時能補上進度，並且可以對專案進行更全面完善的測試。

對組員應盡量做更加充分的了解，明確組員的優缺點和長處，對分工進行改進。

專案開始時的uml文件和現在的文件有什麼區別，是否需要更新

uml圖的改進：基本上依靠最開始的設計完成了程式的實現，不需要做修改。

什麼功能產生的bug最多，為什麼開始沒有想到

設計及實現部分反思總結

改進：