| 團隊名稱 | 打代碼一定要笑 |
|---|---|
| beta階段随筆集合 | 團隊作業第六次——beta沖刺+事後諸葛亮 |
設想和目标
1. 做這個項目的背景、意義是什麼？要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
這個項目背景的是現代大學生對于浪費時間在瑣事上愈發的厭惡而引發的，意義在于節約碎片化的時間。要解決大學生不想去取快遞及其他生活瑣事。定義的很清楚，典型使用者就是學生，典型場景：一個住在3樓的大學生，周末有個快遞到了，可他不想去拿，想在宿舍呆着，于是他用‘取經’釋出了一個任務，住在同一棟樓5樓的另一個人剛好願意去拿快遞，他在取快遞的路上通過‘取經’檢視到了3樓同學的任務，幫他順路拿了還賺去了積分。
2. 項目達到目标了麼（原計劃的功能做到了幾個？在原計劃之上是否有所拓展)
原計劃的功能基本都完成了，還拓展了一些功能，比如忘記密碼，管理者日志等。
3. 和alpha階段相比，團隊軟體工程的品質提高了麼？在什麼地方有提高，具體提高了多少，如何衡量的？
和alpha階段比，團隊軟體工程的品質提高了，具體展現在大家對于發現的bug都能很流暢的配合協調解決，不會出現像alpha階段時互相掣肘的情況。
4. 設想使用者量是多少, 使用者對重要功能的接受程度和我們事先的預想一緻麼?
設想是一個福大的師生量，調查的使用者對于功能都是肯定的，主要還是在界面美觀上有所建議。
5. 有什麼經驗教訓? 如果曆史重來一遍，我們會做什麼改進?
對于美工的态度吧，從使用者回報中來看有點太過于忽略美工的重要性。
計劃
1. 和alpha階段相比，每天是否時間規劃的更好?
和alpha階段相比，因為事前制定了每個人的詳細工作，是以每天的時間規劃都更好。
2. 團隊在beta階段是如何解決隊友對于計劃的不同意見的？
對于不同的意見一般通過讨論解決，我們組的所有人都是講理且價值觀差不多的人，一般讨論到後面都會有統一意見。
3. 你們原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
基本全部完成。
4. 是否每一項任務都有清楚定義和衡量的傳遞件?
是的，品質是不能放松的。
5. 項目是否出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
beta階段還好，沒有大的意外，按部就班吧。
6. 在計劃中有沒有留下緩沖時間，緩沖時間有作用麼?
有，經曆alpha階段的意外後，我們提前預留了3天的加班時間，最後用了兩天。
7. 我們學到了什麼? 如果重來一遍, 我們會做什麼改進?
組員學到了很多了新技術，而且配合的更好了。
資源
1. 有足夠的資源（可以是時間、開發資源等）來完成各項任務麼?
這次時間時間資源是夠的，就是人手有點不足，拖得久了點。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
經曆alpha階段，我們對于所需時間的預估都變得更好了，精度控制在一天以内。
3. 和alpha階段相比，測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
這次測試花費了3天的時間，不停的修修改改，還好時間充足，即使完成了。人力又有點不足，畢竟我們組隻有6個人。美工設計的話，就按最低要求進行了。
4. 變更的組員工作如何？如果未變更是否項目完成效率會更高？變更的組員學到了什麼？對于可能的變更是否能制定應急計劃?
變更的組員工作還算可以，就是速度偏慢，未變更的話也不會更有效率，變更的組員學到了新的關于前端的知識，我們對他的工作，安排了另一個同學兜底防止意外。
5.有沒有感到某個成員做的事情可以讓别人來做（更有效率）?有什麼經驗教訓? 如果曆史重來一遍, 你們會做什麼改進?
沒有，大家各司其職，即使有的同學慢一點，也不會影響到大局。
設計/實作
1. 項目是否經曆重構？為什麼需要重構？
有，Controller重構過，因為一開始的設計不合理,方法之間的耦合程度比較高，出現一個地方出現錯誤的時候，會大面積的受到影響，不易定位錯誤的位置同時，修改一處代碼可能會牽一發而動其身。
2. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
有進行單元測試。現在的uml文檔會更加明确，互相之間表達更加明确了。
3. 什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
管理者操作影響使用者端的bug是最多的，因為管理者端和使用者端的負責人不一樣，是以有些地方了解不一樣，導緻最後的呈現結果有差距。
4. 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
代碼複審由各自大子產品下不同子產品的負責人進行，要求嚴格執行項目開始時規定的設計文檔。
5.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
有些産品細節還是要明确，否者會出現了解上的偏差。
測試/釋出
1. 和alpha階段相比，測試工作有提高嗎？在哪些地方提高了？
有，測試的範圍和次數變多了很多，力求細節。
2. 團隊是否有一個測試計劃？
是。
3. 團隊是否有測試工具來幫助測試？
Visual Studio等。
4. 團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
軟體測試由測試人員進行性能測試，從軟體實際運作結果來看有一些效果。
5. 在釋出的過程中發現了哪些意外問題？
管理者操作導緻使用者端顯示意外，出現無法操作的‘死任務’。
6.我們學到了什麼? 如果重來一遍, 我們會做什麼改進?
對于軟體的測試可以嘗試使用更為專業的工具，傳統的方法有點落伍。
團隊的角色，管理，合作
1. 團隊的每個角色是如何确定的，是不是人盡其才？
在alpha的基礎上，林昌锴同學撞到管理者端，保證使用者端的統一性。
2. 團隊成員之間有互相幫助麼？
有，大家有問題都會在開會時提出自己還未解決的問題，對于自己了解的方面都會去幫助。
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
出現這種問題時，一般都是通過開會讨論決定的。組長在其中進行了解及調解。
總結
1. 組員們自我總結
在beta總結部落格裡有，留個傳送門。
傳送門
2. 你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
第三檔次，吧。
3. 你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
規範階段
提高軟體工程的品質
1. 代碼管理的品質具體應該如何提高？ 代碼複審和代碼規範的品質應該如何提高？
這點沒有考慮，我們隻考慮了規範，沒有想過進一步的提高，
2. 整個程式的架構如何具體提高？ 如何通過重構等方法提高品質，如何衡量品質的提高？
至少開發規約要遵守
3. 其它軟體工具的應用，應該如何提高？
我們運用很多新工具，都是靠CSDN的大佬的文章一步一步摸索的，還是需要多去查資料，才能很好的運用。
4. 項目管理有哪些具體的提高？
要更注重細節的确定，否者實施了在修改很麻煩。
5. 項目文檔的品質如何提高？
多參考其他大企業的公開文檔。
6. 對于人的上司和管理， 有什麼具體可以改進的地方？
小團隊主要還是制度管理為主，人情管理為輔。
項目展示
1.示範視訊
示範視訊
提取碼：x3g2