13組-Beta衝刺-總結
一、基本情況
1.組長部落格連結
https://www.cnblogs.com/cyt199709/p/15616525.html
2.現場答辯總結
3.全組討論的照片
4.分工情況
| 工作流程 | 組員姓名 | 具體分工 | 組員工作量比例 |
|---|---|---|---|
| 登陸介面 | 陳藝天 | UI | 13% |
| 溫致鵬 | 功能 | 13% | |
| 主介面 | 陳藝天 | UI | 14% |
| 溫致鵬 | 功能 | 10% | |
| 設定欄 | 陳藝天 | 功能 | 13% |
| 溫致鵬 | UI | 13% | |
| 個人中心 | 陳藝天 | 功能 | 13% |
| 溫致鵬 | UI | 11% | |
| 總工作量佔比 | 陳藝天 | 53% | |
| 溫致鵬 | 47% |
二、總結思考
2.1 設想和目標
（1）我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述 ？
答：我們的軟體首先要解決使用者桌面過於混亂的問題。我覺得定義的比較清楚，因為市面上產品有太多可以供我們借鑑的了。同理，因為本組成員都是相關應用的資深使用者，所以對典型場景都會比較瞭解。
（2）我們達到目標了麼?（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)
答：從實現程度上來看已經八九不離十了。但目前還沒有投入市場，所以使用者調查不足。
（3）使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
答：使用者量也需要投入市場後一段時間再做評定，按正常進度進行的話肯定是離目標更進一步的。
（4）有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
答：經驗教訓可能就是喜歡臨時抱佛腳吧。如果重來一遍肯定會更加迅速高效完成任務。
2.2 計劃
（1）是否有充足的時間來做計劃?
答：因為是畢業班。沒有學弟學妹們時間那麼多，所以時間顯得有點倉促。
（2）團隊在計劃階段是如何解決組員對於計劃的不同意見的？
答：這個很簡單。每個成員負責不同的模組，全權負責，這樣就沒有不同意見了。
（3）原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
答：：原計劃的工作肯定事都做完了。沒做完的可能就是和預想的那段差距吧。比如UI的和諧美觀程度等等。但是我們時間實在不多，所以只能以實用為主。
（4）有沒有發現做了一些之後看來沒必要或沒多大價值的事?
答：有吧。比如有一些功能其實是畫蛇添足的比如個人中心裡面的一些東西啥的，因為我們這個APP是沒有伺服器的也沒有相關連鎖產品，所以這個東西頗有點畫餅的意味。
（5）是否每一項任務都有清楚定義和衡量的交付件?
答：基本都有。具體可以看每一輪的Alpha衝刺。
（6）是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
答：專案分為四個模組，有條不紊進行。本著以實現功能為主，所以功能實現了，測試下沒什麼bug可以正常執行就行。
（7）在計劃中有沒有留下緩衝區，緩衝區有作用麼?
答：留了兩天左右的緩衝區。緩衝區沒有起到作用，因為都按時完成了，哈哈。
（8）將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
答：因為Beta衝刺週期縮短，所以縮短至1天。
（9）學到了什麼? 如果歷史重來一遍, 會做什麼改進?
答：統籌協調規劃能力提高、C語言程式碼運用能力提升、抗壓能力提高。如果再來一遍肯定更加快速完成任務。
2.3 資源
（1）我們有足夠的資源來完成各項任務麼?
答：有的。時間=資源。
（2）各項任務所需的時間和其他資源是如何估計的，精度如何?
答：根據程式碼量來確定。根據後續完成情況來看和估計得差不太多。
（3）測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
答：軟體比較小， 我們叫了其他幾個同學來測試，完全足夠。我們從來沒有覺得美工設計和文案是很簡單的事。
（4）你有沒有感到你做的事情可以讓別人來做（更有效率）?
答：有。畢竟人外有人天外有天吧。我感覺在座的大部分人的水平都是隨便把我們兩個吊起來打的。大家程式碼的功力水平都不一樣，只是因為我倆負責這個專案得獨立完成。
（5）有什麼經驗教訓? 如果歷史重來一遍, 會做什麼改進?
答：經驗教訓可能就是喜歡臨時抱佛腳吧。如果重來一遍肯定會更加迅速高效完成任務。
2.4 變更管理
（1）每個相關的員工都及時知道了變更的訊息?
答：兩個人。他考研複習回來的時候宿舍裡說一句就OK。
（2）我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
答：站立會議！站立會議！站立會議！開了六次呢。
（3）專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
答：可以穩定執行（檢測），誤報率在10%以下，能夠抗基本干擾（戴帽子、趴在桌子上等）。
（4）對於可能的變更是否能制定應急計劃?
答：專案太大可能管理不來，但是我們的專案很小。就算是重做也沒什麼問題。但是目前加起來2000行的程式碼確實比較繁瑣，畢竟現在面臨升學、就業壓力，很多事情顧不上。
（5）組員是否能夠有效地處理意料之外的工作請求？
答：我們的工作都是按部就班的，基本沒啥意料之外的。
（6）學到了什麼? 如果歷史重來一遍, 會做什麼改進?
答:統籌協調規劃能力提高、C語言程式碼運用能力提升、抗壓能力提高。如果再來一遍肯定更加快速完成任務。
2.5 設計/實現
（1）設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
答：設計工作在團隊作業釋出的前10天左右，由組長（陳藝天）完成。從時間來看未雨綢繆沒啥問題，人選上看，陳藝天沒有面臨考研，自然會比溫致鵬更適合。
（2）設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
答：沒有的。1就是1，2就是2，涇渭分明。
（3）團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
答：團隊主要使用UML來協助設計和實現。這些工具在一定程度上理清了專案的流程、隊友的實現思路，指導了專案的完成。
（4）比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
答：專案開始的UML和現在的狀態存在一定的偏差。偏差來源主要是使用的技術方法不同。UML文件計劃更新。
（5）什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
答：當然是主介面。承擔了軟體的主要功能。在測試的時候出現了拖拽不進去、閃退等情況。設計的時候個人認為是沒辦法預見的，畢竟很多時候寫程式碼就是摸著石頭過河（對我們這種程式碼渣來說）。
（6）程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
答：程式碼複審交給各個隊友分別進行。比如組員A負責的模組由組員B稽核，組員B負責的模組由組員A稽核。大家都比較嚴格執行了程式碼規範。
（7）學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
答：統籌協調規劃能力提高、C語言程式碼運用能力提升、抗壓能力提高。如果再來一遍肯定更加快速完成任務。
2.6 測試/釋出
（1）團隊是否有一個測試計劃？為什麼沒有？ 是否進行了正式的驗收測試？
答：想要有。但是理想很豐滿現實很骨感。畢竟不能算是實戰專案，個人認為最大的意義就是鞏固舊知識學習新知識，畢竟是課程設計嘛。進行了驗收測試，驗收標準可以看專案需求分析報告。
（2）團隊是否有測試工具來幫助測試？
答：暫時沒有使用測試工具。
（3）團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
答：主要看CPU佔用度。在實現各種功能如拖拽、自動整理的過程中記憶體佔用情況。
（4）在釋出的過程中發現了哪些意外問題？
答：未出現意外問題。
（5）學到了什麼? 如果歷史重來一遍, 會做什麼改進?
答：統籌協調規劃能力提高、C語言程式碼運用能力提升、抗壓能力提高。如果再來一遍肯定更加快速完成任務。
2.7 團隊的角色，管理，合作
（1）團隊的每個角色是如何確定的，是不是人盡其才？
答：軟體四個模組每人負責各個模組的UI和功能，基本上人盡其才了，畢竟人力資源有限（只有2人）
（2）團隊成員之間有互相幫助麼？
答：難兄難弟再不互幫互助等著掛科麼。（瘋狂暗示）
（3）當出現專案管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝 （彙總至組長部落格）：
答：
陳藝天：我感謝溫致鵬對我的幫助， 因為某個具體的事情: 請我吃了頓楊國富麻辣燙
溫致鵬：我感謝陳藝天對我的幫助， 因為某個具體的事情: 每天早出晚歸準備考研， 出了程式碼的任務別的都沒時間做，所以感謝他完成了其他瑣碎的事情。
（4）學到了什麼? 如果歷史重來一遍, 會做什麼改進?
答：統籌協調規劃能力提高、C語言程式碼運用能力提升、抗壓能力提高。如果再來一遍肯定更加快速完成任務。