| 這個作業屬於哪個課程 | <2021春軟件工程實踐S班> |
|---|---|
| 這個作業要求在哪里 | <軟件工程實踐總結&個人技術博客> |
| 這個作業的目標 | 回顧整個課程進行具體總結 |
| 其他參考文獻 | 《構建之法》 |
第一部分：課程回顧與總結
1. 回頭看看
1.1 問題鏈接
1.2 問題解答
問題一：
解答：
在上面的問題中，我主要提出了因為每位成員在工作過程中的進度各有不同，有的人可能會整個團隊的進度，那么該如何解決這個問題。
我對這個問題的答案是：
其實這個問題主要是項目負責人來解決的。
首先，項目負責人在布置任務的時候要盡量做到細化，每人的工作內容具體到天。在公司的實體項目團隊中每天早上都是會開例會，來分析前一天做了什么，是否達到了昨天預期的工作任務，以及今天應該做什么。
其次，在感覺到團隊成員有怠慢或者遇到一些情況時，項目負責人要做到及時跟進，了解情況。
① 如果是成員怠慢，要考慮一下是因為這個項目越做越沒意思還是因為這個成員個人問題（三分鍾熱度，不能堅持等等），若是項目越做越沒意思那么應該重新審核一下需求，若是成員個人問題，盡量與成員進行溝通，激發成員戰斗力。
② 如果是因為成員在項目中遇到了一些難題（BUG等），要及時開會討論，大家一起解決，不要把難題丟給一個人解決。
最后，如果遇到了你無法解決的問題時，一定要向上級反應情況。這種反應情況不是打小報告，而是你無力解決切為項目考慮的情況下向上級尋求解決方案。
問題二：
解答：
對於第二個問題我覺得是可行的
- 一方面是由於這個觀點本來就是我自己提出的。（否定自己的觀點很沒面子的好嘛）
- 另一方面，我在比賽當中用的就是這種方法，讓除產品外的成員負責一部分的需求工作能夠讓成員在有限的時間內更好的了解需求，明確自己應該做什么。讓前端配合UI進行設計能讓前端更好的理解設計原理，能夠解決很多前端在布局方面的問題。讓后端與前端配合能夠更好的進行前后端接口的對接。對於這種配合方式我畫了個圖，如下：
問題三：
解答：
對於這個問題呢，其實我當時想的是比較片面的，回過頭結合前面的內容再看這一段話，其實作者是告訴我們應該正確選擇開發方式，確定敏捷開發是否適合本團隊的使用。
我這里看到了一篇文章，我覺得放在這里很合適：
問題四：
解答：
對於這個問題嘛。。。。我的答案有這幾點
- 對於需求來說，這塊不用防也沒必要防。在問卷調查的時候調查的是大家有哪些痛點，分析的是用戶的行為，就算問卷被別人抄襲了，數據也未必能被抄襲。
- 在做項目的時候一定要快！要用最快的時間把需求、設計、開發等做完，盡早上線把握先機。在等別人還沒來得及抄襲的時候就先把項目做好，讓別人只能跟着你的步伐去走。
- 如果你的項目已經上線了，然后擔心被抄襲，那么大可不必。在需求這塊，我們沒辦法證明自己的版權，因為需求源於用戶，用戶是大眾的。不過我們可以將這種行為認為是被模仿，有的時候被模仿並不是壞事，作為學生而言，被模仿是一種認可，而且往往很多創新都是從模仿、抄襲中借鑒而來的。（eg:QQ，這個就不多說了，懂得都懂）
- 對比需求的保護，我目前更看重技術的保護。一款產品的核心往往不在於需求，而在於技術。把握好核心技術，其他東西愛咋搞咋搞。（再次提一下，騰訊這塊做的就很好）
問題五：
解答：
這個問題我們團隊在軟工實踐中剛好就有遇到。以我現在的經驗對這個問題的答復是：
- 在需求過程中，團隊成員一定要做好需求復審，反復對需求進行考量打磨。如果前期需求階段不願意花費時間進行復審，那么在開發階段可能會耽誤數十倍的時間去”補褲檔“。（數十倍一點不誇張）。
- 如果前期需求沒做好，在開發階段真的遇到了這種問題，那么最好的辦法就是版本迭代。先將原來的需求實現，然后測試發布，在這之后讓用戶來告訴你這個需求合不合適以及要改哪些。最后進行不同版本的更新。
2. 碩果整理
我在項目的需求/設計/實現/測試/發布階段（一共5個階段）中，每個階段收獲最大的知識或能力是什么？
2.1 需求階段
在這個階段我收獲最大的是將我書本學習到的關於需求方面的知識進行了實踐。以前做的一些項目或賽題都是命題式的，而這次的項目確是一個開放性的，讓我有了更大的施展空間。而且這次項目做的是游戲，我以往做的都是網站或者APP的服務式項目，游戲項目對於我來說是一種挑戰。
2.2 設計階段
設計階段我們這個項目有很多靈感是來源於PC端的Super Bunny Man，我們將PC的界面設計成了移動端。在設計初我本來是想使用AXure來制作原型的，但我之前沒做過游戲的原型，而且游戲中的動畫效果在原型中也無法展現，因此我又get到了一個新技能，使用U3D來做原型。
2.3 實現階段
實現階段主要是編程和UI，在這塊我主要做的是UI的部署，這也是我第一次做游戲的UI，在這個過程中通過不斷的調試，讓我對游戲UI的部署有了根深的了解。同時，在這個過程中我也學到了怎樣與開發人員更好的溝通，怎樣使用GitHub等工具。
2.4 測試階段
在測試階段我主要做的還是UI方向的測試，並且配合其他測試人員進行測試報告的撰寫。從中更加熟悉了測試的相關工作以及對接相應人員。
2.5 發布階段
發布階段我主要的工作是用戶問卷調查及反饋數據的分析，由於我們的游戲是Apk的形式存在的，沒有在應用平台上線，所以體驗的用戶比較少。那么就將這些少量的用戶作為目標用戶，發放問卷並進行訪談。最后在將這些結果進行匯總。從中我收獲最大的地方是在用戶訪談，讓我感受到了不同人的不同看法，這讓我在以后的需求工作中對同理心的培養有着很大的幫助。
3. 靜下來想想
結合自己在個人項目/結對編程/團隊項目的經歷，談談自己的理解或心得。
我就來說是團隊項目吧，因為團隊項目周期比較長而且相對於個人和結對項目來說，在團隊項目當中大伙付出的都比較多。
3.1 對團隊項目的心得
在”瘋狂TUT“這個項目中，我們在前期的時候本來是想做”王者榮耀“翻版的，但是我感覺做翻版並沒有任何意義，對王者而言，PC端有LOL，移動端有王者，再做也沒辦法做出很好的創新，為此我們專門開了次會來討論，最后決定將PC端的super bunny man移植為移動版，並進行創新。
在這次實踐中，我第一次接觸了游戲方向的產品工作，讓我對游戲的開發也有新的認識，在Github等軟件也有了更熟練的操作，並回顧了大三上學的C#編程。
對於這次的總結呢，因為我是做產品方向的，我最大的感觸還是需求方面，起初，我們的需求非常亂，簡直就是想一出是一出，有點像頭腦風暴，但是風暴過后我們並沒有整理歸納，導致在開發階段問題百出，還要邊開發邊做需求。不過還好，最后還是做過來了，結果也得到了相應的肯定。總體來說是非常不錯的。
3.2 對課程的心得
在課程的最開始，我記得老師說過，我們專業的每位同學必須要有編碼，我有點不是很認可。
我認為一個標准的開發團隊應該有產品經理，美工，開發人員，測試人員這四部分組成，但要清楚的是，在產品經理和美工這兩個崗位是不需要編碼的。如果這兩塊沒有專人負責，那么整個產品線將會亂套。
我的建議是一個團隊中，8或9個人里面有1~2人是可以不編碼的。
說到這里有人可能會說：“軟件工程的學生不會編碼那應該干嘛？”
我的答案是：首先，不會編碼和不編碼是兩碼事。其次，軟件工程難道考核的僅僅只是編碼能力嗎？如果是，那我們為什么不叫這個專業是程序專業，而為什么偏偏要叫“軟件工程”。既然有了“工程”二字那就說明了它需要規划+設計+實現+測試這個過程。其次，《構建之法》當中也有專門說明：軟件=程序+軟件工程。
因此，我認為老師對代碼要求卡的太死了。如果是為了避免有人划水，工作日志和任務表單是能夠明確說明的。
雖說“三個臭皮匠頂，一個諸葛亮”。但在軟件開發中，讓專門的人做專門的事，比一群業余人士去做有用的多。軟件開發更注重的是效率，而不是人力。（可能以我現在的身份和地位說這句話有點沒權威性，但我認為它是對的）
第二部分：個人技術總結
1. 工作總結
其實做游戲是我之前沒有想到的，在第一次作業的時候，我有兩個目標，一個是在前端方向有更深入的學習，另一個是培養產品經理的思維與能力。
做了游戲之后呢，我在前端方面的學習就只能靠自己私下去學啦，那么該課程就全心學習產品經理。
因為之前有往產品方向進行學習，並且在服務外包與軟件設計實驗室也是設計組成員，對產品和UI有一定的基礎。所以，在是整個軟件工程當中呢，我大部分充當的是產品經理和UI角色。同時，為了讓自己有一定代碼量，我也參與了部分編碼和測試。
作業要求說的是從“個人技術學習角度和團隊開發技術角度中選擇你最擅長的一個相關技術”，但我在整個課程中學習到的大多是產品方面。我覺得需求和設計兩個階段也是有技術的，而且並不亞於編程， 所以我想下面的個人技術總結主要寫產品需求方面的，希望老師和助教諒解。
這里簡單慶祝一下，通過不斷的努力，我在上周拿到了京東產品經理崗的實習offer！嘻嘻。
2.技術博客
博客鏈接：