提問回顧與個人總結

問題解答與分析

Q1: 單元測試應該由誰來寫？程式作者還是其他人？

關於單元測試的問題，本身就得迴歸到實踐中才能得到結果。自己在結對程式設計的時候參與到了單元測試，而在團隊專案的時候也嘗試部署前端頁面的單元測試，但是後者難度較大，以及學習成本較高便沒有繼續嘗試。最終對於自己當時的疑問也有了比較明確的回答，單元測試還是得熟悉程式碼的人去測試。

這裡還是引用書上的觀點

單元測試必須由最熟悉程式碼的人（程式的作者）來寫：

程式碼的作者最瞭解程式碼的目的、特點和實現的侷限性。所以，單元測試沒有比作者更合適的人選了

在嘗試單元測試過後，自己也清楚，為了更全面的覆蓋程式碼測試，首先就是得要對程式碼足夠的熟悉，一個不太熟悉的程式碼從理解上需要一定精力，此外還需要對程式碼構思清晰，程式碼側重點在哪兒都需要足夠熟悉。這一點在自己結對程式設計的時候便有體會，自己在編寫程式碼上貢獻較少，於是大部分精力放在了單元測試上，這個時候即使是對結對程式設計所編寫的程式碼有所瞭解，但對細節的理解還是不如作者本身清晰，也花費了頗多精力，所以自己也肯定了這個問題的答案。

回到當時自己疑問的點上，自己當時比較關心的是程式作者可能對需求定位不是非常清晰，這一點也在自己團隊專案中得到了解答。一個專案進行需求分析的時候，往往是一個團隊都進行參與的，所以一個良好的程式碼編寫者，對需求的理解也是相當清晰的，也就沒了當時的疑問。

Q2: PM（產品經理）的定位問題

自己不是產品經理，所以對該問題的理解可能還是存在一定偏差，但是感謝我們的PM@QSY。在他的身上我也看到了一個合格的產品經理所應具備的能力:

帶領團隊形成團隊的目標/遠景, 把抽象的目標轉化為可執行的, 具體的, 優美的設計。

管理軟體的具體功能的生命週期 (需求/設想/設計/實現/測試/修改/釋出/升級/遷移/淘汰)。

代表

客戶和使用者的利益, 主動收集使用者反饋, 預期使用者新的需求。 協調並決定各種需求的優先順序。

收集團隊專案管理和軟體工程的各種資料, 客觀地分析專案實施過程中的優缺點, 推動專案成員持續改進, 從而提振士氣。

這裡摘取了當時所列舉了幾個產品經理所該做的工作，而這幾個工作也是在團隊專案中我們PM所體現的較為閃光的地方以及我認為產品經理所應突出的地方。首先，就是產品經理是團隊的主心骨，其對專案的態度影響了整個團隊對專案的態度，也正是PM認真負責的態度，使得我們整個刪庫跑路對不隊上下齊心，完成了超過2w行的專案。另外對於專案進度的把握和人員任務的合理分配，也是PM所應有的能力，專案開發週期應根據需求和參與人員的能力進行裁定，任務的分配更是得根據人員的能力裁定，這裡我們就得到很好的分工。最後，PM也是作為與客戶交流的一個重要環節，代表著客戶與使用者的利益，積極收集使用者的反饋，並根據反饋，指定合理的新需求，這一點我們PM也做的很到位。

Q3: 結對程式設計具體實施產生的問題

當時所疑問的點在於如何去確定結對程式設計的具體實施才能發揮每個人所長的同時考慮效率？這一點在進行結對程式設計前，自己可能太糾結於"一起"這個概念了，認為"一起"就是兩個人做重複的工作，從而降低了程式設計的效率，在自己參與到結對程式設計當中時，我才發現，這種一起，不是對工作的重複，而是對類似前後端獨立程式設計那種做法的另一方面，一個人的程式碼編寫完成之後由另外一個人複審，這一過程就保障了整體程式碼的正確性。此外：

駕駛員和領航員不斷輪換角色，不要連續工作超過一個小時，每工作一小時休息15分鐘。領航員要控制時間。

不得不承認，當時進行結對程式設計的時候，編寫強度確實有點高，如果讓某一個長時間高度精神集中，那麼會降低效率和準確性。

但是，以上的分析只是解決了自己對於"一起"的疑問，而本次的結對程式設計更是在應對作業來看，使得整體對二人能力最大化發揮感受不是特別明顯。自己對於如何發揮自己所長還是保留疑問，如一個人如果思維敏捷，擅長編寫程式碼，而另外一個人心思縝密，擅長對細節深究，擅長進行測試，那最終是採用結對程式設計"領航員與駕駛員身份不斷輪換"的方法更適合二者還是，讓二者專精與各自領域更合適？

Q4：如何正確地處理顧客的需求

顧客的需求，首先是在產品開發前就應該確定的，明白使用者的痛點所在。就如本次的團隊專案來說，使用者的痛點就是在於需要一款便捷性極高的刷題軟體。專案開發前所理解的需求便是整個專案的重中之重，需要高度重視，於是我們團隊便對此進行分析然後得出較為合適的解決方案。

而在上述過程中，更多的是開發者在幫顧客的需求做決策，這裡就解決了部分"不合理顧客需求"，同時也根據開發者對專案的把握，從而挖掘出了屬於專案的閃光點。

而後的過程，也需要和顧客進行更多的合作——使用者反饋。在團隊專案中，我們建立了反饋群，群中時常會收到對某些需求的反饋。比如能夠統一對模擬考試的題目進行判斷的需求、題型擴充套件的問題。這些問題在開發階段，都不是很極端的問題，都可以的得到良好的解決，這一過程就是當時疑問的解答——“如何正確引導顧客提出切合自身需要並切合實際的需求，以及如何挖掘使用者需求中的"閃關點"，從而形成自己的產品優勢？”

先是根據使用者需求為使用者做決策，再根據使用者反饋，取捨進行改進。例如所提及的題型擴充套件，兼顧便捷性和我們實現的難度，選擇題可以很好適應這個專案，但是填空題就難度較大，同時還有其他形形色色的解答題。這裡我們收到使用者反饋後，與使用者協商，最終推出了知識卡片和資源社群兩個優勢功能，幫使用者解決問題。

Q5：在績效評定中，引用某著名網際網路公司的一個二維評價體系（書P407）中，價值觀該如何定義？

這裡還是再次反駁書中的觀點:

如果價值觀不斷提高, 但業績平平, 則是聽話的小白兔, 或者哈巴狗。 可以給機會, 但是機會不多了。

如果業績很好, 但價值觀不太對路 (不太聽話?), 則是一條野狗。 要堅決清除, 不然功高震主

價值觀絕對不能跟聽話關聯。一個團隊內，絕對不是以絕對標準來推進專案的，也絕不是一旦使用者提出需求，就需要往自己專案堆的。價值觀的存在，只要不是違反道德法律規範，都應該在一個專案中存在，求同存異是基本準則。在思維碰撞中，去理性分析取捨，而不是一股腦的就是上。就比如，我們的專案最求的是便捷性，這個時候，在使用者反饋階段中，有人提出需要網頁PC端的刷題軟體，對於該需求，是否要“聽話”？經過了本次的團隊專案之後，我對之前自己的反駁更堅定了，同時也能給出自己的定義:價值觀是公司/團隊，為了公司/團隊更好發展，而不斷磨合碰撞的產物。

新問題

• 專案開發週期短的前提下，磨合期和適應期短，如何快速定位開發者的能力從而安排合適的工作？
• 對於課程教學的疑問，教學在技術上給予的幫助如何體現，整個學期體驗下來，關於技術方面的知識全靠自學，而如果遇到困難，例如自己對於前端單元測試的困難，在自身難以通過簡單查閱資料理解的前提下，課程組能否以及如何提供幫助？

學到的"知識點"

需求

需求分析階段最重要的知識點就是:NABCD。系統的來分析專案的需求。

NABCD主要從需求、做法、好處、競爭、推廣五個方面進行具體分析，這個五個方面幾乎囊括了專案所需考慮的內容。五個點一個點都不能忽視其重要性：需求，是產品的靈魂所在，明確自己的產品是面向什麼使用者，解決什麼使用者痛點是開發者不可忽視的；做法則是在尚未編碼之前，對如何解決的一種大致方案給出；好處或者說產品主打的優勢，是專案能夠讓使用者產生良好印象的關鍵；競爭則是對現有產品橫縱向的對比，值得借鑑的可以借鑑，不足的地方可以作為自身閃光點而體現；推廣，則是最容易被忽視，但也是非常重要的一個點，直面使用者群體，何時何地進行推廣都是講究，就如專案本身的刷題軟體，如果在開學進行推廣，根據受眾習慣，幾乎沒有人會在此時進行刷題，所以投放時間點應該在臨近烤漆階段，此外明白推廣受眾，做到精準地點對點的推廣也會使得產品優勢得到擴充套件。

設計

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

• 技術規格說明書：明確整個專案所使用的技術棧。這一點就是需要對自己能力的一種評估，以及如何根據需求選擇合適的技術棧，例如本專案是設計刷題軟體，那麼後端就需要一種能夠很好處理高併發、高負載等效能問題的技術棧。而前端，為了更好的迭代開發和適應多平臺釋出的功能就需要選擇例如UNI-APP這種結合Vue元件化優勢和多平臺開發的開發框架。
• 功能規格說明書：這一點就是對需求的做法的進一步細化，細化到需要給使用者提供一個怎麼樣的UI介面，針對於每一個頁面能夠解決使用者什麼需求，以及如何體現自己的產品的優勢。功能規格書可以說是比較複雜的一個說明書，但是在開發階段來說，正是前期定下了每個頁面的UI設計和功能，使得開發階段流程更加迅速。

實現

本人在團隊專案參與到的是刷題軟體的前端頁面設計與功能實現，學到的知識點便是為了適應迭代開發而產生的元件化設計思路。

因為前端採用了以Vue為主要框架的Uni-APP，保留了Vue的元件化特色。在開發過程中，設計了諸如答題元件、日曆元件、評論元件等自行設計的元件用於產品的開發，簡化了程式碼的同時也提高了可維護性，尤其是答題元件，在Beta階段時，對答題頁面進行優化時，設計答題相關的部分只需修改元件便可實現優化。此外，Vue支援匯入其他元件，並支援對規範的元件進行修改，使得自己開發階段中，對如uni-checkBox元件UI設計不滿意時可以直接進行修改。

測試

在團隊專案中，因為前端單元測試難度較大，所以沒有進行規範的單元測試。進行了模擬使用者行為的真實測試，即自己去體驗產品，這裡收穫到的就是針對化測試知識。

測試不一定需要覆蓋所有程式碼分支，而是應該對需求強烈的功能進行集中測試，保障功能完善。此外對於該功能的細節再進行測試，模擬更多可能會出現的行為操作，這種以需求為導向核心的測試便是測試時所應看重的。

釋出

釋出主要學到的知識點就是：學會合適的時機進行推廣。

這一部分在上文有所描述，重點就是需要知道，什麼時候，什麼地點以什麼方式進行推廣。我們的專案最終選擇，在烤漆並在對應的課程微信大群，面向群體的集中微信大群進行推廣，以文字、產品介紹視訊等方式進行推廣，效果也很好。

維護

維護階段主要學會的是如何收集反饋。

這裡我們採用的是建立反饋群的方式，在推廣的時候鼓勵受眾進入反饋群進行反饋。對於反饋的內容收集，如果是BUG，則需要明確是如何復現的，需要即使修復；如果是新需求，需要和使用者進行溝通，明確產品定位之後，適當對新需求給出解決方案並詢問使用者能否接受。

理解和心得

個人專案

本學期的個人專案，主要就是幾篇部落格的撰寫。前面兩篇部落格個人閱讀作業#1,個人閱讀作業#2主要就是對軟體工程的一個匯入，在較短時間內建立起對整個軟體工程瞭解的大體框架。並在帶著疑問進行了到之後其他的其他專案中，一個學期過來，之前的疑問大部分也得到解決具體可以參考前面部分，而自己對軟體工程的期許也完成了大部分。

而後的案例分析作業中,通過對成熟軟體的使用和BUG尋找與分析，清晰了軟體評測的思路和方法，以及對BUG復現反饋的能力，從使用者的角度對產品進行評測，這與之後以開發者的開發者的視角去評測方向不同，但也可以反過來幫助自己加強對軟體評測的理解——使用者往往會針對自己所想要用的功能進行評測，然後對與自己使用習慣產生較大偏差的方面進行反饋。

總體而言，個人專案更多是對理論的一種思考，和軟工的入門。

結對程式設計

結對專案算是自己第一次接觸的東西。有點類似與之前資料庫的前後端開發但又有顯著的差別。後者工作相對十分獨立，前者則是對同一個專案進行合作程式設計，讓1+1>2。

領航者和駕駛員的身份輪換也很值得自己去探究。尤其是結對雙方的認識評價，結對強調的是這一個“對”，成對程式設計不單單是兩個人一起做事，更是兩個人一起把事情做好，需要默契度和足夠的分工分配。這一點在結對程式設計的時候自己和隊友都儘量在這一過程中不斷放大自己的閃光點，所以即使整個結對程式設計，無論是工程量還是難度都很大，我們結對的效果還是相當不錯的。此外，結對程式設計這種一個人寫程式碼和一個人複審程式碼的過程，也讓自己學會了如何規範化編寫程式碼（程式碼規範加直觀的程式碼註釋）以及閱讀他人程式碼的能力，以及最後完成的單元測試，也讓自己明白了一個合格的專案也最終離不開充分的程式碼測試。

團隊專案

首先，很慶幸自己能夠遇到一群優秀上進負責人的隊友使得我們的刪庫跑路對不隊能夠最終開發出題士這一款功能較為齊全的產品。全體成員也能夠一起經歷Alpha階段和Beta階段，讓整個專案的迭代沒有出現太多的波折。自己在專案中一直擔任的都是題士產品的前端開發人員，以自己先前做資料庫網頁Vue框架開發的經驗，以“在實踐中學習”的態度，從零開始學會了Uni-app和小程式開發流程，這一過程雖然遇到了很多BUG，但最終也還是得益於團隊的幫助和自己上網查詢，方得解決問題。

總的來說，團隊專案最讓人感慨，從一開始六個人一起為了需求分析和技術規格計劃書編寫忙到凌晨3點多，到後面專案開發時協商API介面以及功能和頁面的優化，再到最後一起推廣產品，這一步步都是軟體工程開發的流程，更是整個團隊合作向前的腳步。

知識點都不是在課堂上學習到的，都是自己在課後實踐過程中一點點積累而成的，這也是自己認為團隊專案比較具有挑戰性的一點。然而當經歷過Alpha階段之後，Beta階段開發更加得心應手，這足以體現自己在實踐過程中自身能力的提高。

最後，感謝刪庫跑路對不隊全體成員的辛苦付出!

課程建議

對於中期換人的建議，首先很感謝課程組在本學期還是採納了同學們的意見，採用了每組出人進行協商的辦法，保留人員可以繼續在本小組開發做法。希望課程組能夠繼續保持，能夠更多聽取學生的意見，不是說學生的意見要毫無保留地答應，而是可以鄭重地考慮一下大家的意見，畢竟真的能提出意見的人，都是對自己專案、對課程的真心熱愛。

                                                                                 |