一、提問回顧與新的問題

學期初的提問連結：2021年軟工 個人閱讀作業二

Q1：單元測試的構造與編寫者問題

重開發而輕文件的敏捷開發如何保證單元測試樣例構造的合理性？開發人員負責自己模組單元測試的編寫會不會造成需求上的理解性問題？

​ 在結對專案構造單元測試和團隊專案完成後端介面的單元測試過程中我對這一問題有了更加深入的理解。結對專案中我和另一位同學交叉構造單元測試樣例，即介面和單元測試不由同一人編寫；而在團隊專案中，我一人負責與資料庫相關的各介面的編寫和單元測試的構造，即介面和單元測試是由同一人編寫。通過實踐我發現，這兩種方式都能達到較好的效果，即無論開發人員是否負責自己模組的單元測試編寫都不會造成需求上的理解問題。回顧結對專案和團隊專案過程，我發現我編寫程式碼時往往是從邏輯的角度對需求進行拆分，安排具體的 if

Q2：錯誤處理路徑的單元測試覆蓋問題

在實際的工程中對於錯誤處理路徑的單元測試究竟應該提出什麼樣的要求呢？

​ 在團隊專案後端的開發過程中，Alpha階段初期是在每個介面中檢查請求方法型別並拋405，但在Beta階段中由於介面數量驟增而使用了包裹器統一檢查請求方法型別，則原有介面中的檢查程式碼已經成為死程式碼卻沒有被及時刪掉。在檢視單元測試覆蓋率報告的時候，我才發現這一問題並及時刪去了上述死程式碼，避免了其邏輯上的混亂與體量上的臃腫。我認為這一情景體現了對錯誤處理路徑單元測試嚴格要求的益處，即應當儘量保證單元測試覆蓋所有程式碼路徑，包括錯誤處理路徑，而如果模組中的某個錯誤處理路徑很難到達，那也許要想想是否可以把這個錯誤處理拿掉。

Q3：結對程式設計的效率問題

作者認為這樣的結對程式設計方式大有裨益，可以時時刻刻處於複審的環境之中，提高程式碼質量和開發效率，然而事實真的如此嗎？

​ 對於這個問題，在結對專案的 第三階段總結 中已經對結對程式設計的需求分析、架構設計、質量管理、結對方式等多方面進行了詳細的分析與體會，並提出了數個關於結對程式設計的小建議，在此不再贅述。總體而言，結對程式設計的效果遠好於我在本學期初的預期。

Q4：敏捷開發中的時間預估與備案問題

作者認為預估任務距完成所需的時間是一個重要的資料，需要進行預估，還提出了用燃盡圖對任務進行跟蹤的方式，這樣的方式從理論上來說固然好，但我對其在實際開發過程中落地的效果如何表示疑問

。

​ 在團隊專案的計劃過程中，我們嘗試給每個任務都確定一個預估時間，並使用燃盡圖進行跟蹤，然而在開發過程中，我們發現任務實際完成所需的時間遠大於我們的預估，在此基礎上的燃盡圖難以反映專案的實際進展，對我們造成了一定的困擾。事後反思，其一大原因即是團隊成員之間對彼此的技術力不太熟悉，難以準確預估特定成員完成特定任務需要的時間。但是在Beta階段中隨著團隊成員的逐漸熟悉，這樣的情況已經有所改觀，因此可以預見的是，較為穩定的開發團隊能夠做到較為合適的時間預估，從而使得所述的一系列進度管理方式能夠落到實處。

Q5：技術創新的關鍵性例證問題

作者認為，“銥星計劃”想法有很多不靠譜的地方，雖然技術上有巨大創新但使用者量太少，最終導致了其不到一年時間就申請破產保護，成為了一項租賃業務。然而，這真的代表著技術創新的關鍵性有待考證嗎？

​ 在軟工的實踐過程中我並沒有涉及到技術創新關鍵性有關的問題，也沒有通過其它途徑有更深入的瞭解，因此目前仍認為這個例證是不合適的。但從另一個角度思考，全書都在極力強呼叫戶的重要性，課程組在團隊專案的全過程中也極力強呼叫戶方面的資料，那麼把這個例證僅作為對於使用者重要性的強調也未嘗不可。

​ 在團隊專案的實現過程中，我又產生了如下的新疑問：

• 如何確定什麼時候結束計劃階段進入開發階段？或者說，什麼樣的計劃才是足夠好的？
  • 在Alpha和Beta階段的實際開發中，我們都先是經歷了數天的計劃階段再進入兩週的衝刺開發階段，可是就實際情況而言，計劃結束時新增的Issue往往粒度過大，遠不能滿足真實需要。舉例而言，計劃初期我們就決定需要一個靜態的專案展示頁，並將這一任務分解成為“尋找模板”和“往裡面填字”兩個小任務，至此看起來似乎很難再進行分解了，因為更具體的內容得找到模板才知道。而若在計劃階段就找好模板，將每一部分的填字劃分成多個小任務，這樣的做法卻聽起來似乎更接近於瀑布模型，這造成了對我的迷惑。更為嚴重的是，這一問題也會反映在燃盡圖上，當真正找到了模板，細化了任務併發成Issue，開發人員會驚人地發現：“怎麼我寫了一天，Issue還變多了？”從而造成難以把握專案真實進展的困境。

二、知識點提取與構建

• 需求階段
  • NABCD是一個有效的方法
  • 在面對紛繁複雜的需求和團隊成員的各類奇思妙想時，使用NABCD對其進行解構和組合是一個可行的方案，其包含了使用者、自身、競品三個方向上的內容，形成“三面包夾芝士”，通過這樣的分析，我們可以使用簡明的語言描述自己專案的特點，從而對軟體工程的後續各個階段做出方向上的指導。
• 設計階段
  • 使用典型使用者和典型場景進行功能設計
  • 在需求分析的過程中已經抽象出了我們真正關心的屬性與其之間的關係，在設計階段我們需要弄清楚軟體應當如何解決這些需求，以及現實世界的實體和屬性在軟體系統中是怎麼表現和交換資訊的。在此過程中，使用典型使用者與典型場景可以幫助團隊從使用者角度快速進行功能的設計，高效而實用。
• 實現階段
  • 推動資訊共享與溝通
  • 在開發過程中，保持資訊共享和保障高頻溝通是很重要的。“敏捷”的靈魂即為對隨時出現的變化進行快速反應，這一特點需要建立在隨時溝通之上。當然，隨時溝通不是時時溝通，仍然需要留出必要的不受打擾時間進行開發工作。
• 測試階段
  • 場景測試一定要做
  • 作為開發人員進行軟體開發的過程中，往往是按照模組進行開發和測試，而使用者在使用過程中並不是獨立使用各個模組，而是將軟體作為一個整體來使用。所謂“不識廬山真面目，只緣身在此山中”，跳出開發人員的角色，站在使用者角度上對軟體進行使用測試，在我看來尤為重要，其不僅可以發現模組間整合上出現的問題，還可以發現各流程中難以使用的部分。
• 釋出階段
  • 招數：砍掉功能
  • 有一個模組看起來不能實現預期的設計需求，時間快到了，怎麼辦？砍！從團隊開發的歷史經驗來看，如果類似的功能需要N個單位時間才能最終完成，那麼我們沒有理由相信新功能會花少於N個單位時間，有時候砍掉功能是更明智的選擇。
• 維護階段
  • 使用5WHY進行反思
  • 5WHY指的是在問“為什麼”的時候，要多問幾次，層層推進，找到問題的根源。其關鍵在於，從現象和結果入手，不管面子問題，不管小團隊的邊界，沿著因果關係鏈條，打破砂鍋問到底，直至找出原有問題的根本原因。如果針對一個問題能從各個方面深入探究，我們很可能得到一顆樹狀圖，根部就是問題，各個枝幹是分類，各個葉節點就是具體的原因，在此基礎上便可以列出各類因素中主要和次要的原因，並可以討論改進的方法。

三、課程理解與體會

​ 本學期的敏捷軟工課程大體上按個人部落格、結對程式設計、團隊專案三步走，在不考慮本課程所花費時間的情況下，這樣的安排是較為合理的，能夠讓我循序漸進地加深對敏捷軟工的理解。

​ 在個人作業中，我通過對一些部落格資料和《構建之法》的閱讀，初步瞭解了敏捷軟工的機制與亮點，在此基礎上對現有軟體案例進行分析，對軟體工程一詞有了更加深刻的理解與體會。案例分析部落格也是我迄今為止篇幅最長、投入精力與時間最大的一篇部落格，其中從調研、評測、分析、規劃等多個角度對洛谷和LeetCode進行了深入剖析，對之後的團隊專案中作為PM的我具有一定的指導意義。

​ 在結對程式設計中，最大的收穫即為了解並逐漸熟悉了CI的操作，雖然團隊專案中我沒有參與CI的搭建，但確實已經理解了CI的妙處。除此之外，結對專案更大程度上磨練了我的心態，讓我面對折磨的需求時依然能夠擁有良好的心態以面對，其他關於結對程式設計的感想與建議已經在 結對專案第三階段總結 中較為詳盡，在此不再贅述。

​ 團隊專案是本課程的重頭戲。在我們的團隊專案 觀隅——整合式資料集視覺化平臺 的開發過程中，我作為PM和後端開發，與全體團隊成員一起奮鬥並實現了這一符合我們預期的專案。作為PM，我制定了各類介面，不斷協調進度，並驚歎於實際軟體開發過程中非程式設計資源的要求之高。作為後端開發人員，我實現了一眾介面並構造了基本全覆蓋的單元測試樣例，在不斷修Bug的過程中也有所成長。在這“做中學”的過程中，我不僅將從書中看到的敏捷軟工理論應用於實際開發，解決了諸多困惑，還在與隊友齊心協力合作開發的同時鍛鍊了溝通與協調能力，也在大量部落格的書寫過程中鍛鍊了寫作能力，可謂獲益匪淺。

​ 最後，感謝謎語人隊全體成員的辛勤付出。

四、一點腦洞

​ 在我看來，課程組在團隊專案的全過程中極力模擬真實企業中的軟體開發場景，又是調研使用者，又是轉會，又是每日例會。但我認為，這樣的模擬要在我們每日能投入給軟體工程的時間比較富餘時才有意義，不然就是“秦兵又至”的折磨。《構建之法》中多次提到：“在理論上，理論和實踐是一回事，但在實踐上，理論和實踐是兩回事。”敏捷軟工這一課程設定的各階段從學到東西的角度上來說固然好，但我認為其從某種意義上來說忽視了實踐上的困難，即忽視了本科學生和真實企業開發人員之間的不一致性，忽視了學生上一門課和企業開發一個軟體這兩個場景之間的不一致性。

​ 若是作為企業中的開發人員，拋開有薪酬帶來的驅動力不談，至少能夠做到每天大於8小時的時間投入；然而作為本科學生而言，迫於其他課程的壓力，在一些時間段內很可能每天沒有一分鐘是能投入給軟工的，為了補償這一時間段內的零投入，往往又需要數天的每天數十個小時的投入，兩週的開發時間往往被自己壓縮到不足十天，燃盡圖前鬆後緊，這樣的進度顯然是不健康的。除了從自己身上找原因之外，我認為也可以從外部尋求解決方式。

​ 一言以蔽之，以上的矛盾即為時間上的矛盾，那麼有沒有一個時間段能讓我們有可能在全過程全身心投入軟工開發，也能讓課程模擬真實開發環境效果更好呢？思前想後，我的答案是暑期，即如果將敏捷軟工課程的團隊專案放到暑期來做，就像軟體學院的小學期那樣的形式，是否會取得更加的效果呢？