| 這個作業屬於哪個課程 | 2021春軟件工程實踐|W班(福州大學) |
|---|---|
| 這個作業要求在哪里 | 軟件工程實踐總結&個人技術博客 |
| 這個作業的目標 | 1、 回顧自己列出的5到10個問題：嘗試解答、繼續分析、提出新問題 2、5個階段中，每個階段收獲最大的知識或能力是什么？ 3、結合自己在個人項目/結對編程/團隊項目的經歷，談談自己的理解或心得 4、技術博客 |
| 其他參考文獻 | 《構建之法》 |
一、回顧問題
為了征求用戶意見，所給出的核心功能是一種假設（假設用戶會使用）嗎？假設和實際用戶使用如果存在很多差別怎么辦？
在軟件工程實踐過程中，有一環【需求分析】的過程，在這個過程中，團隊運用NABCD模型進行需求分析，基本確立產品的需求。后續通過KANO模型，將需求分為基礎型、興奮型等，對需要實現的需求有更進一步的了解。這兩個環節的分析，均是基於前期用戶需求問卷調查的結果進行的，因此初步保證了解了用戶需求，產品中的核心功能會是用戶需要的。在后期，產品一般會經過正式發布前，邀請具有代表性的用戶進行【用戶測評】，了解用戶對成品的評價，進一步確認用戶對核心功能的使用情況，幫助開發團隊正式發布前對產品進行修改。
雖然結對編程存在開發者之間可能就某一問題發生分歧，產生矛盾，造成不必要的內耗等缺點，但就效率來說依舊是一種高效的工作方式。那碰到溝通不合、不喜歡公開工作方式和技術水平的合作伙伴，選擇什么樣的方式會比較好呢？
個人認為，就工作內部而言，溝通不合產生的原因有可能是雙方沒有提前確立開發功能的具體細節，那么久需要兩位開發人員在正式開發前確立雙方的工作內容，並確立結果論。同時，在確立工作內容之后，雙方可以各自進行開發，給雙方的隱私（工作方式和技術水平）保留余地，最后交接時只需要分享開發結果即可。就工作以外的內容，那么就依賴於各自的性格和溝通方式等等，並不應該是工作中需要考慮的內容。
敏捷對團隊的要求前兩點皆為“自主”，若是有一個團隊同時具備老手和新手，每個人能力不盡相同，此時應該用木桶原理去評判這個團隊嗎？
個人認為，不能就木桶原理概括所有的團隊合作。在木桶中，每一塊木頭之間沒有任何聯系，而在實際開發中，每一位成員不是機械的、不與他人產生聯系而獨自存在的。每一位成員都在接收來着團隊其他成員的影響，或增長技術，或改進溝通方式。如果通過木桶原理，希望說明團隊的實力取決於短板，我認為這是片面的。在開發過程中，團隊成員的實力是在動態變化的，每位成員都有成長的可能。在本次軟件工程實踐中，團隊中經常有互幫互助的小組存在，團隊分前后端開發，即使團隊中每人實力不相同，團隊整體的任務進度並沒有收到過大的影響。
但是，本次項目團隊基本由熟人組成，團隊中互幫互助的現象是自然產生的，由此，我不認同單一的木桶原理覺得團隊實力的結論。那么，在企業級項目團隊開發過程中，團隊成員的互幫互助是否是必要的呢?
當項目的需求與軟件的利益相對立的時候，團隊該如何做選擇呢？
在前期，我在博客中提出廣告相關內容，我依舊有當廣告的利益與用戶需求產生矛盾時，軟件團隊如何做選擇這個困惑。如果拋棄軟件的這個實體，回到軟件的利益上，運營團隊/銷售團隊或是其他軟件直接獲益者可選擇的、獲取軟件利益的方式還有很多種，比如，知識付費，個人認為這是一種對用戶良好的獲取利益的方式。所以，在選擇上，也許可以通過討論獲取利益的具體方式解決團隊面臨的選擇。
如何判斷自己的想法是可行的呢？如何找到創新的方向呢？
實踐出真知，一般認為實踐是檢驗想法的最優方法。不過，我認為可以添加一些實際的要求，比如，提前確立目標，當發現目標不可達時及時止損。
如果去了解一些創新者的故事，可以發現很多創新的想法是來自於生活中的觀察。創新也是在建立滿足需求的基礎上，而在分析需求的時候都會分析【痛點】，痛點來自於生活中出現的問題，所有找到創新的方向應當從發現問題開始。
二、個人收貨
需求階段
在需求階段，項目團隊去構思一個產品，並設計問卷進行問卷調查，了解用戶需求。然后使用需求分析模型對需求進行分析，確立需求。接着，繪制UML類圖、活動圖、用例圖，設計原型，編寫需求分析文檔。最大的收貨主要是如何高效開會和如何處理團隊中不同的意見。首先是會議，在會議前對會議內容進行梳理，並在會后進行會議記錄對高效開會非常有幫助，會議時長明顯縮短，工作安排更清晰，也把需要討論的內容都完成。
設計階段
在設計階段，項目團隊依照前期進行的需求分析開始系統設計和數據庫設計，在系統設計中，注重設計體系結構和功能模塊。在設計階段，由於有了前期明確需求，這個階段開展比較順利。主要學習的內容是如何在自己無經驗和不了解的情況下展開工作，在本階段開始時，大家對體系結構的部分幾乎不了解，也沒有設計經驗，所以在第一個小階段會議上一起討論這個部分，並分配給兩位成員一起完成。
實現階段
在實現階段，項目團隊開始進行開發，在alpha階段基本完成前台，beta階段完成后台。在實現階段，我的工作基本是進行項目管理和團隊管理，在這個階段很多是對前面獲取到的組織會議、解決問題的能力的使用。在alpha階段，團隊在前后端連接中出現了溝通不暢的問題，在沖刺結束后，小組進行反思，在beta階段，該問題得到了改善。
測試階段
在測試階段，前期前后端的單元測試、功能測試及界面測試都很好完成了，但是集成測試由於接口對接存在問題，在兩次沖刺中都是稍微延后進行的。在這個階段就認識到，溝通真的很重要很重要，很多小的錯誤，可能是由於后端忘記修改接口文檔，可能是變更沒有讓全體成員完全知曉，可能是出現問題沒及時去找后/前端開發人員溝通，現在看來，這都是通過溝通可以解決的問題，所以在沖刺階段，及時、有效的溝通非常重要。
發布階段
在發布之后，項目組進行了用戶使用調查，根據調查結果分析軟件使用情況、是否符合用戶需求等。在這個階段，通過用戶反饋，可以看到很多站在開發者或管理者角度沒有考慮到的問題。比如，發布的第一個版本包含網絡檢查的功能，項目團隊認為這個功能可以提升用戶體驗感，是用戶友好的功能。然而，在發布之后，該功能是用戶反饋最多的功能，用戶提到，該功能會帶來流量消耗和過多的動畫影響整體使用感受。之后，項目組基於此決定取消該功能。由此認識到，用戶的需求和項目組分析的需求可能會存在偏差，用戶並不會完全以我們想象的方式去使用產品。
三、心得體會
-
溝通很重要。如前文所示，項目在進行前后端連接時，有效、及時的溝通能幫助解決許多問題。同時，溝通也有很多種方式。在結對編程中，我和結對的小伙伴發現，直接的對話比間接發信息，溝通效率更高。因此，在結對過程中，前期我們選擇QQ語音通話進行溝通，后期我們選擇線下編程進行討論。
-
站在用戶角度考慮，有時能幫助決策。這是在項目團隊實踐的整個過程中體會到，在項目開發過程中會面臨許多【需求】，如何去挑選最核心、最基礎的需求，是團隊需要考慮的問題，在這個問題上，個人認為，站在用戶角度能夠幫助決策，通過用戶使用場景的模擬，確定最核心、最基礎的需求。
-
解決問題的能力很重要。無論是在結對編程還是團隊編程中，或多或少都會遇到各種問題，可能是技術上的bug，可能是設計細節沒有明確，可能是需求設計不明確，可能是實現方式不清晰，在遇到問題時，選擇“我也不知道誒”、“不懂誒”、“隨便吧”的答案會把問題，像是把黃豆留在鞋墊下一樣，永遠停留在【待解決】的狀態。在兩次實踐中，我學習到，解決問題基本是找到問題來源，梳理，給出解決方案，只需要比回答上述答案多一點點的耐心。
四、技術博客
技術概述：本節通過傳聲筒游戲，為初學者講解Promise對象的屬性及常使用方法、執行機制等。在開發中，讀取文件、axios都使用了Promise。本節難點是then方法的執行機制。