提問解答

問題一：為什麼要在大學軟體工程課上專門實踐敏捷開發？

作為一名學生，我從沒實踐過任何一種軟體工程方法論，相信大部分同學也是這樣。那麼課程組在一門必修課上選擇敏捷開發是有什麼緣由嗎？

這個問題可能需要課程組回答，但是在這裡我給出自己的理解。敏捷已成為當今網際網路的一大特徵之一，網際網路市場、使用者需求都在快速變化，敏捷開發能指導我們在快速更新迭代自己產品的同時能夠儘可能保證軟體開發質量，讓團隊中的所有人職責明確且發揮最大效率。另外，我個人認為我在敏捷軟工中的鍛鍊讓我受益頗多。

這學期的軟工實踐讓我體會到敏捷開發鮮明的特點：

• 適應性
  • 在團隊專案的過程中，我遇到了開發軟體的難處——開發過程的不可預測性。在我們的開發過程中，首先需求是不確定的，我們從軟體使用者轉變為軟體開發者，因此思考的角度也需要轉變，我們要站在使用者的角度思考軟體的功能；課程組會對我們的進展提出意見和建議，這有時使得我們做出一些改變，例如助教指出我們的issue劃分粒度太粗，指出我們的例會記錄形式的不合理之處，指出我們的燃盡圖曲線的不合理指出等等；另外，我們可能會遇到實現與設計無法匹配的情況，這也要求我們儘快做出調整。
  • 得益於敏捷開發，我們能“敏捷”的適應變化，因為這些問題都能在下一次的例會上得到“敏捷”的解決。
• 充分發揮人的能力
  • 敏捷開發使得專案團隊全員參與到軟體開發中，無論是PM還是DEV。同時敏捷開發要求研發人員獨立自主在技術上進行決策，因為他們是最瞭解什麼技術是需要和不需要的。再者，敏捷開發特別重視專案團隊成員的溝通，任何問題的解決都建立在充分的溝通的基礎上。這要求專案成員需要全身心投入開發，充分發揮自己的創造、溝通能力。

問題二：敏捷開發的同步應該怎麼管理？

敏捷開發之下，一個專案會被劃分成具有一定依賴關係的需求/任務，那麼具有依賴關係的兩個任務的負責人肯定需要同步，但是，每個人都會有自己認領的多個任務，而且對自己認領的所有任務全面負責，同步關係也是紛繁複雜。

我們試想這樣一種情況：AI 完成了一項任務，等待與 BB 同步，但是 BB 的進度落後，AI 和 BB 兩部分與另一邊的工作也需要儘快同步了，但是，AI 負責的別的任務還在做，另一邊的 CC 等著同步，那麼 AI 是選擇幫 BB ？還是選擇自己的另一項任務？又或者說，這個決定是由整個團隊來決定？

這個問題在我看來，首先需要明確敏捷的目標——完成最小可行性產品，再通過多輪迭代進行完善。明確了這個目標，那麼我們能得到開發過程的關鍵路徑，理性而言，如果某項任務停滯，而它恰好在關鍵路徑上，那我們必須把它的優先順序抬高，降低影響。當然，前面提到敏捷軟工適應能力很強，能夠快速變化，AI的決定牽扯到許多人，那麼我認為他需要在下一次例會上提出這個問題，無論他選擇如何，都應該制定迎合這個選擇的團隊計劃。

問題三：敏捷開發究竟敏捷在哪？

我的疑惑在於，衝刺階段竟然有每日例會，每個人都需要準備這個會議，進度報告、製作圖表，這難道不浪費時間？還是說這是必要的犧牲？

能不能少開會，大家約定俗成，反正有看板制度，這樣責任明確，任務也可追溯？

要回答這個問題，我認為必須明確每日例會的作用。結合我這學期的16次例會，我認為例會的作用：

如果沒有例會，“約定俗成”很難真正實現，平常自己一個人開發的時候，總會有別的事情打亂節奏，大部分情況會導致推進軟工專案的優先順序一降再降；而如果有例會，那麼就相當於設定了一系列短期KPI，在例會上，我們需要彙報自己的工作以及領取下一階段的任務，如此這般，誰在拖慢團隊節奏將會一目瞭然，其次，例會要求全員參與，這樣方便大家對接工作，討論並解決開發過程中遇到的問題，有時還需要討論並修改原先的設計，緊湊的例會往往會帶來高效的工作。

問題四：如果一個團隊長期擔任 PM 的人離職了，團隊和新 PM 如何應對？

此問題出自第九章《專案經理》

本章著重介紹了什麼是 PM 、 PM 的作用、以及怎樣算是一個好的 PM 。我最大的感受是，團隊不能沒有一個好的 PM ，PM 相當於一個GPS 導航，粘合劑，風險預警裝置，除了開發和測試，剩下的“髒活累活”都是 PM 負責的，可見 PM 的重要性。

基於本章以及自己的經驗考慮，程式設計師和 PM 是平等的，需要靠長期的磨合來和平相處，如果在某個專案的開發過程中，原來和大家共事愉快、得到支援、得到尊重、積極影響團隊的 PM 離職了，我想會團隊以及新 PM 都會面臨不小的挑戰。那麼我們應該怎麼應對？

本次團隊專案換人階段，我們組的PM-QSY同學認為自己參與軟體本身開發較少，因此主動申請交換，回想起QSY同學所承擔的工作，我想PM離職這件事情還是需要謹慎處理的。QSY同學負責主持會議，協調工作，把握進展，宣發，前端設計等多方面工作。我認為，新PM到來，需要首先進行一次團建，目的在於讓新PM快速融入團隊，快速打破不熟悉帶來的隔閡；然後大家在新團隊第一次例會上列出所有任務以及對應的天數，說明人力資源情況，確定驗收時間點等，以便PM瞭解情況並評估進展以及開展下一步的規劃。

問題五：業餘劇團模式“中央指揮”需要怎麼選擇？

問題六：“中央指揮”面對不同的人希望選擇同一個角色的情況該怎麼處理？意願優先還是能力優先?

業餘劇團模式 (Amateur Theater Team):

這樣的團隊在每一個專案（劇目）中, 不同的人會挑選不同的角色。在下一個劇目中, 這些人也許會換一個完全不同的角色型別。各人在團隊中聽從一箇中央指揮（導演）的指導和安排。在學生實踐專案或培訓專案中, 這樣的事情經常發生。

• 這個“中央指揮”需要怎麼選擇？
  • 泛化而談，也就是一個 Team 的 leader 怎麼選？
    • 進一步， leader 的職責範圍一般是如何的？
      • leader 指導安排太過是否會變成主治醫師模式或者明星模式
• “中央指揮”面對不同的人希望選擇同一個角色的情況該怎麼處理？意願優先還是能力優先?
  • 意願和能力如何平衡？

中央指揮——PM，alpha、beta，雖然負責前端還是後端不會變，但是每個人需要面對的都是全新的工作。我們給出的答案是“工作經驗”也即是否開發過類似的功能優先和能力優先（PM也是如此選的，QSY毛遂自薦，綜合日常印象，我們認為QSY同學有能力擔任）。意願往往需要服務於團隊，如此才能齊頭並進，快速開展相關工作。（事實證明，QSY同學在確定產品功能、接受或拒絕開發團隊的工作成果、細化工作、決定釋出的日期和釋出內容、bug修復等等過程中達到了合格PM的標準）

新問題

問題一

敏捷開發是要一直敏捷下去嗎？或者說是否到一定程度就不需要敏捷了？

問題二

beta之後，我們預期的大部分功能已經完成了，對於產品的維護或者進一步的拓展還需要敏捷嗎？

知識點

需求階段

• NABCD
• 確定需求需要經過完整的需求調研、使用者分析
  • 在團隊專案-初次邂逅，需求分析作業中，我們起初對於“題士”專案需要實現哪些功能進行了充分的討論，確定瞭如支援不同模式下的題目訓練（如順序、按章節、隨機出題）、題目推薦、快速做題、關鍵詞搜尋、題目收藏、錯題收集、題目筆記、題目評論、問答社群、資源共享社群、線上問答pk、做題排行榜、倒計時設定（考試時間倒計時等）等等功能。但是我們很快意識到這樣的需求分析確定出來的結果僅僅只是我們意向出來的使用者想要的，我們需要真正傾聽使用者的聲音。因此，我們決定採用線上問卷調查的方式收集使用者對於一款面向學生考試刷題、學習交流等目的的刷題軟體的需求，問卷問題就是針對我們討論出來的功能進行打分，分值為1-7，功能重要程度逐漸遞增。另外，為了保證收集的問卷的有效性，我們將問卷投放到目標使用者群體所在的微信群/QQ群，並且進行了一定的宣發措施，這樣，我們在需求評審答辯前收集到了202份有效反饋。具體的結果在題士需求分析部落格，這篇部落格指導了我們接下來需要開發的功能，意義重大。
  • 寫在釋出會好一點？另外，我們對於“題士”所支援的平臺也進行了討論，初步確定希望做移動端，這樣使用起來更加方便快捷。我們一致認為不做web端，主打移動端，但是由於IOS端稽核較為嚴苛，因此為了不放棄IOS端的使用者，我們決定同時開發微信小程式。

設計階段

• 前期設計只能做到儘可能完備，後期往往會出現對前期設計的不理解、質疑甚至是反對，這時候需要儘快解決，有時牽扯到其他組員的開發還需要及時溝通討論

  • 在“題士”beta開發階段，除了航概，我們需要支援更多課程，例如計算機導論和經管。但是這樣面臨一個問題，就是切換課程，準確來說，本質上是切換資料。前期設計考慮的比較簡單，只需要把題目進行切換就行，因此在資料庫中把題目和課程進行關聯即可。但是實際上，後期開發資源社群、問題社群、考期日曆和知識卡片等功能時，我們意識到可能也需要涉及資料的切換，最後，我們認為使用者切換課程後，應該想要尋找針對這個課程的資源、討論貼和知識卡片，因此這三個功能需要進行資料切換，因此在資料庫層面也需要和課程進行關聯，需要修改資料庫和介面API，而對於考期日曆，我們認為無論使用者是否切換課程，所有的考期日曆都應該進行展示，以防使用者遺漏。

實現階段

• 實現階段不注意程式碼風格以及基本測試，後期測試和維護大概率面臨很多問題
  • 在alpha階段，我需要實現錯題推薦以及模擬考試功能，這兩個功能一次需要查詢多次資料庫，且資料量較大，實現階段想著怎麼簡單怎麼來，結果在測試階段的壓力測試過程中發現這兩個介面延遲達到幾秒，而且無法承受高併發，之後經過查閱，我發現我沒有理解nodejs的非同步特性，迴圈執行sql語句，每一次迴圈都會await，實際上根本沒有利用非同步程式設計，經過一段時間的學習，我利用Promise將互不相關的sql查詢一起請求，查詢結果非同步到達，優化後的介面延遲降低為幾百毫秒。

測試階段

• 與使用者輸入相關的程式碼往往很容易出錯，因為我們無法預知使用者的行為。
  • 團隊專案的實踐過程中，我們自以為經過了充分的測試，大家都誤以為什麼問題都沒有，但實際上bug往往在不經意間就冒了出來。舉個例子，alpha階段臨釋出的時候，我使用自己的微信賬號登入我們的“題士”小程式，但是發現我怎麼都登不上去，就算登上去了，個人資訊也不對，還經常請求錯誤，但是這個問題我的其他組員都沒有遇到，所以大家也都沒有特別在意，最後才發現原來是我的微信名稱存在單引號，這導致解析的時候出現問題，簡單處理後很快得到解決。這樣的問題在beta階段也遇到了，助教使用自己的微信登入，發現也登入不上，我看到助教的微信名稱帶有emoji，立馬就意識到需要把資料庫的編碼改為utf8-mb4以支援emoji的儲存，否則我們的討論區、評論區啥的也將被emoji攻陷。

釋出階段

• 宣發很重要，同時要關注競品的動向。

維護階段

• 維護階段往往會面臨很多使用者意見，bug要修，但是一些涉及使用者體驗的地方不一定要improve，因為說白了使用者體驗這個東西主觀性很大，只有那些嚴重影響大量使用者使用的才需要儘快解決。

個人專案

初入本課程，上來就是一篇熱身閱讀作業，在這次作業，我回顧了自接觸計算機以來自己的心路歷程，有對大學生活的吐槽，也有對自己個人學習的總結，最後讓我重新思考了未來的發展。

緊接著是個人閱讀作業#2，在本次作業，我閱讀了《構建之法》，瞭解軟體工程需要考慮的方面，並且學習了提問的藝術，另外，我還學習如何使用CI/CD工具。課程前期對於軟工還是有許多問題的，但是現在，經過長達半學期的軟工實踐之後，我認為我對於軟工的已有初步的瞭解。軟體工程是一門研究用工程化方法構建和維護有效、實用和高質量的軟體的學科，軟工突出工程化、高質量，這在我們的實踐中也是重中之重，工程化體現在敏捷開發流程的實踐、各種文件的書寫，高質量體現在CICD的部署、充分的測試以及維護。

然後是案例分析作業，這是我第一次系統性的分析對比市場上同一領域的軟體，瞭解軟體評測基本方法。印象深刻的是找bug的環節，解鎖各種使用軟體的新姿勢， 角色扮演了一位進入酒館點炒飯的顧客。

結對程式設計

得益於強力的隊友my，我在結對程式設計期間充當“領航員”的體驗一直都很不錯。在實踐過程中，隊友身上有許多我值得學習的地方，比如嚴格控制每個方法的複雜度，若出現無法避免的高複雜度方法，則應立即進行覆蓋性單元測試，比如良好的記錄習慣，由於結對專案的工作量並不小，有時候初步完成編碼，但面臨許多有待商榷的地方，這時候我們有兩種方式進行記錄：1. 註釋和TODO程式碼塊；2. 專案issue區記錄，比如通過基礎測試後，隊友總是想方設法構造極端樣例與其他組對拍，並利用效能分析工具檢視壓力測試下的魯棒性。另外，每次部落格我們都會記錄結對過程每個階段所耗費的時間，有時可能會暴露出問題，這些問題會在下一次結對得到解決。總而言之，結對程式設計的實踐使我受益匪淺，有許多收穫值得我銘記。

團隊專案

團隊專案給我帶來的體驗大多是從未有過的，首先就是隊伍人數是以往課程組隊從未達到的，這使得我們面臨的挑戰也並不是一個量級的；其次，很慶幸自己能夠遇到一群優秀的隊友，一起開發出“題士”這款至少我很滿意的軟體，在每個人不遺餘力的努力下，我們順利完成“題士”的Alpha階段和Beta階段，整個過程較為順利，體驗尚佳。

我在專案中負責一部分後端開發和測試的工作，雖然之前資料庫課程實踐的也是後端，但是，這次的專案的複雜度和靈活性要遠遠大於以前的專案，因此在設計、實現和維護上遇到了不少棘手的問題，但尋求了隊友以及網路的幫助後都順利的解決了這些問題。

總的來說，團隊專案讓我痛並快樂著，從設計階段所有人幾乎每週都要肝文件到凌晨兩三點，到衝刺階段每兩天一次例會，甚至五一小長假連肝三天，再到釋出階段QSY帶我們一起做宣發以及接受評審……我們團隊一路走來，一步步實踐著敏捷軟工，讓我直到結束還意猶未盡。

最後，感謝刪庫跑路對不隊全體成員的辛苦付出！感謝課程組以及同僚們對我們專案的所有評測與建議！