提問回顧與個人總結

專案

內容所屬課程

2020春季計算機學院軟體工程(羅傑任健) (北航)

作業要求

提問回顧與個人總結

課程目標

培養軟體開發能力

個人部落格

提問部落格鏈結

(1) 單元測試相關問題

這一問題我依然保持原有的觀點：單元測試可由最熟悉**的程式作者來寫，但也需要一定的他人輔助。在這次團隊專案的開發中，這一點我深有體會。乙個人自己寫自己的單元測試，可能會思維受限，考慮不全。那麼多少輔助測試比較合適？又要選擇誰作為輔助測試的人員呢？首先，程式作者自身需要對自己的**進行規範，要有注釋和說明文件，盡可能降低他人理解的成本。其次，不可完全依賴輔助測試，需要讓輔助人員清楚已經覆蓋了哪些測試，避免重複工作，輔助測試則更偏向精準化的補充。再者，輔助測試的人員需是與程式作者工作相似或者對該部分功能比較了解的人員。

（2）軟體團隊的模式

對於不同模式的優劣性問題，我認為「不管白貓黑貓，抓到老鼠就是好貓「。但經過一學期的體驗，我也有了新的認識。無論什麼模式，團隊能達成共識是很重要的，要有明確的共同目標。如果有的人止步於水完任務，有的人卻力求把產品做到最好，那麼設定的目標不同，合作過程中必然產生諸多分歧與矛盾。不同模式中，由於每個人的能力水平不同，達成共識的難易程度也是不同的。若大家都想把專案做好，那麼根據各組的情況選擇合適自身的模式，再加上合理的任務分配與有效的管理與領導，結果也並不會太差。

（3) 關於專案經理

通過這次的團隊合作解決了我的這一問題。我們專案的pm是很有能力的，他在提出需求、協調工作等方面完成得很出色。加上自身馮如杯專案隊長的體驗以及與小夥伴們的溝通，我對pm這一職位有了更深的認識。pm不一定需要苛求技術開發的深度，但對專案廣度上了解的要求很高。若想要將工作分配合理，pm必須要了解各個組員的能力和各個部分工作的大致情況。若想使專案具有競爭力，pm要提出導向性的合理方案，這就要求pm收集大量的使用者需求，並且對相應的技術領域有一定的了解，以衡量開發的可行性。

（4）質量保障的問題

專案可見性對於不同性質的專案，其具體情況不同。我們這次的團隊專案並沒有遇到這樣的問題。由於採用前後端分離的方式，所以階段性的工作都可以展示，可見性較強。

（5）關於創新的迷思

對於這個問題，我依然有之前的疑問。但我想，這樣乙個問題並不需要乙個是與否的答案。

（1）需求階段

需求階段是分析專案的nabcd，主要是學習了如何具體分析需求、做法、好處、競爭、推廣。

首先，我覺得明確需求，並能對各種需求的重要性進行衡量是非常重要的。這一步的關鍵作用在於明確產品定位。「勿忘初心」這一點並沒有想象中那麼容易做到。在我們開發的過程中，由於實現難度等原因，我們確實有些時候偏離了「初心」，那麼及時的回顧需求分析就很必要，這樣才不會搞錯核心功能。

其次，推廣也是門學問。廣撒網的推廣方式並不是最佳的。我們要明確產品的目標使用者，對於不同的細分市場進行針對性的推廣。

（2）設計階段

設計階段主要學習了如何設計技術規格說明書和功能規格說明書。

技術規格說明目的是讓開發者明確需要實現哪些介面以及實現的整體邏輯。功能規格書目的是讓使用者了解產品的頁面原型，對產品的核心功能有初印象。

（3）實現階段

這個階段讓我明白了計畫安排的重要性，其實這一點我們組做的並不是很好。每個人心裡對時間的認知並不相同，有的人是「拖延症患者」，有的人是「積極分子」。並且每個人的作息以及工作習慣都是不同的。那麼要想乙個多人團隊能夠按期優秀地完成乙個專案，那麼預告性與計畫性就很重要。整個團隊需對進度安排有明確的計畫，這需要全組隊員輔助pm完成的。個人也需對自己的工作有計畫安排，並且在能力許可的情況下預留緩衝區。

此外團隊開發中要學會使用便捷的團隊專案管理工具，善用github或是gitee上的issue和pull request。

（4）測試階段

（5）發布階段

根據目標使用者，針對性推廣。發布時要重點宣傳專案的核心功能和解決的痛點。為使用者提供便捷的使用和反饋途經。

（6）維護階段

及時收集使用者的反饋，對提出的bug進行修復，對提出的新需求進行考量採納。若產品有更新，需要告知使用者更新內容。

（1）個人專案

個人專案的難度不大，但是工作量也不小。這一次作業我花了較多時間在框架設計和正確性測試上，效能優化方面也做了一些工作。但從最終的效能得分來看，我做的還不夠。這可能是由於我蒐集資料不足、相關知識缺乏導致的。比如我後來才了解到vs中debug模式和release模式的區別。

（2）結對專案

這是我首次接觸結對程式設計。雖然由於疫情原因，我們並不能面對面進行協作，但線上會議+**共享的方式也讓我們體會到了結對程式設計的諸多好處。在開發層次，結對程式設計能提供更好的設計質量和**質量，兩人合作能有更強的解決問題的能力。在企業管理層次上，結對能更有效地交流，相互學習和傳遞經驗，能更好地處理人員流動。也正是由於這一優點，在團隊專案的開發過程中，我們小組也融入了」結對程式設計「的方法，取得了不錯的效果。結對程式設計也是有著極高的成本的，畢竟需要兩個人的共同時間。那麼，讓過程變得高效就很關鍵。

（3）團隊專案

首先，讓我認識到了前期準備工作的重要性。朋友圈中有很多吐槽前端工作的，他們多表達的是對沒有選擇模板的後悔，從零開發遇到了很多難以解決的問題。完成乙個完整的**，前端的工作是龐大的，邏輯也很複雜，涉及的知識很多。對於前端小白來說，短時間裡從零完成乙個專案是困難的。我很慶幸自己的前期準備工作是充分的。我找了大量的模板和ui元件庫，通過對比從中選擇了最適合我們的。因為模板的教程非常詳細，讓我們迅速建立起了對於整個**框架的理解，也讓我們後來的前端開發變得事半功倍，沒有走彎路。在這裡，我不是提倡走捷徑，學習核心知識也是我們需要的。只是考慮到我們自身的水平和專案的性質，這樣做不失為一種較好的選擇。這件事也讓我深刻地體會到了「磨刀不誤砍柴工」。

其次，軟體工程是一門需要實踐的學科。在開發工程中，我們組摸索出來了一套適合自己的合作方式--」多人結對程式設計「+"石墨文件"。」多人結對程式設計「讓我們組內高效互相學習、分享經驗；」石墨文件「讓我們清楚各個需要填補的」坑「和需要去承擔的」鍋「，精準分配，無遺漏，使每個人對專案的總體進度都有了解。前**傳下來的經驗，必然有其道理，但是否為最適合自己的方法卻並不一定。通過實踐與創新，我們可在規範的流程中進行個性化的補充，找到最適合自己的一套方法。

最後，我很高興能和團隊一起完成這個專案。隊友都很優秀，我們在專案初期就達成了共識：做乙個真正實用的、可流傳的軟體。正是因為這一共同目標，我們在開發過程中始終沒有逃避困難，力求打磨每乙個細節，給使用者最好的體驗。看到註冊人數不斷**，也收到了很多同學的感謝反饋，我們是很欣喜和自豪的。

提問回顧與個人總結

提問回顧與個人總結

提問回顧與個人總結

提問回顧與個人總結

相關推薦