• 組長博客
• 作業博客

項目Postmortem

設想和目標

• 我們的軟件要解決什麽問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？

我們的軟件針對的是福大學子來到食堂會猶豫不決無法決定吃什麽的痛點，希望做出一款軟件可以根據大家的口味幫忙決定吃什麽。其中，用戶只需要回答簡單的問題就可以得到結果，解決了普遍存在的“選擇恐懼癥”。軟件的定義還是比較清楚的，這來源於我們生活中自己也遇到的問題。在編寫需求規格說明書時，我們對典型用戶進行了清晰的定義，並且通過問卷調查明確了市場上是存在對於我們的軟件的需求的。

• 我們達到目標了麽（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麽？ 原計劃達到的用戶數量達到了麽?)

原計劃的目標大部分都已經完成。在實際的開發過程中，我們將一兩個功能放到了beta版本實現。

核心功能有在alpha沖刺結束時按時交付。盡管這次沖刺延期了一星期答辯，但大部分功能在一周前也已經基本完成。

我們的軟件分為學生端和商家端，目前完成了學生端的一個發布版本，但還沒有公開向用戶發布。

• 和上一個階段相比，團隊軟件工程的質量提高了麽？ 在什麽地方有提高，具體提高了多少，如何衡量的？

上一個階段團隊還沒有開始實際開發。如果說團隊現場編程作業是上一個階段的話，我們團隊的軟件工程質量的確有提高。主要體現在以下幾個方面：

1. 任務分工更加清楚了，每個人有明確的分工，大家之間的配合也從無到有，到熟練。
2. 有詳細的文檔編寫、代碼註釋風格要求。
3. 團隊成員的技術水平通過學習得到了一定的提升。

• 有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?

在項目的規劃階段對於一些具體細節的思考度不足。例如討論時覺得都討論的差不多了，但具體實踐時具有難度不得不多占用一些時間。

改進：提高自己的編程能力、以及對於編程語言和框架的熟練度很有必要。

計劃

• 是否有充足的時間來做計劃?

之前有充分的時間來討論、構想整個軟件的框架，之前布置的每一項作業——立項報告、需求規格說明書、UML圖繪制——都在不斷地讓整個軟件的輪廓在我們的大腦中變得清晰。

• 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？

在計劃階段基本沒有什麽不同意見的出現。

• 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麽?

基本完成。沒做完的部分有一部分需要較大的工作量而推到了Beta沖刺。

• 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

PM很早敲定了一些接口文檔，然而後來都廢棄了。接口文檔最後由後端實際設計前後端邏輯和設計數據庫的人來完成。可見的確PM不要涉及太具體的代碼部分的內容。

• 是否每一項任務都有清楚定義和衡量的交付件?

有的。在Alpha沖刺的初期，全組成員開會最主要就是討論清楚整個業務邏輯，討論完業務邏輯，我們再細分出各個任務，例如前端由幾個頁面組成，後端要寫哪些接口，要設計幾個表等等，這些具體的東西就是具體的交付件。把每一項任務分配給各個人，形成詳細的任務分配。

• 是否項目的整個過程都按照計劃進行，項目出了什麽意外？有什麽風險是當時沒有估計到的，為什麽沒有估計到?

基本按照計劃運行。有一個意外就是前端組組長請假回家了，導致前端組有三天空檔期，沒有按照原來預想的進度進展下去。（沒辦法預估啊）

• 在計劃中有沒有留下緩沖區，緩沖區有作用麽?

本來是沒有緩沖區的。但是老師出差，答辯延期了一周。一下子，隊員緊繃的神經都放松了許多。然而，這多余的一周並沒有什麽實際的額外效果。因為我們團隊在一周前也已經基本實現了大部分的功能。新的這一周，PM為團隊新制定了一些額外的目標，但基本上都沒有完成。這一插曲可以反映deadline是第一生產力這個經典的大道理。

• 將來的計劃會做什麽修改？（例如：緩沖區的定義，加班）

感覺目前整個團隊的態勢發展良好，只要維持住目前的節奏就好了。

• 我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?

趙暢：進度管理十分重要，是我們學到的一課。Alpha沖刺進行到一半，這個時候突然有一個額外的作業——團隊現場編程完成一個抽獎系統。這之前大家不緊不慢地學習框架學習語言，好像沖刺結束還有好多天，悠哉遊哉。作業下來了，這時候猛然發現大家實際產出代碼的能力是不足的，於是大家開始爆肝編程來解決這個問題。這項風險沒有估計到，只能說too young too simple. Alpha沖刺結束後再翻《人月神話》，第二章寫著“系統編程的進度安排背後第一個錯誤的假設是：一切都將運作良好，每一項任務僅花費它‘應該’花費的時間”。想起來是一套，做起來是另一套。好似編程語言、各種工具都易於駕馭，信手拈來，然而實際的開發中是會遇到重重困難的，一定要盡早開始，重視項目的進度（需要PM和組長多把控）。如果重來一遍，一定會要求隊員盡快上手寫代碼，團隊盡快進入能夠有實際產出的創造階段。

資源

• 我們有足夠的資源來完成各項任務麽?

有的。前端、後端各有一位小組長。這兩位同學起到了領導作用。學習資源的話，網上的資源十分豐富夠用。服務器方面，騰訊雲10塊錢一個月的產品也是完全足夠應付目前我們的玩具產品（感謝騰訊雲）。

• 各項任務所需的時間和其他資源是如何估計的，精度如何?

其實一開始我們敲定了各個任務，但沒有衡量這些任務的完成所需時間，說實話在一開始大家都是零經驗，很難有個確定的數字。

趙暢：不過這個情況在你真正去做了一定的開發後就有所改善，例如在有一天我完成用戶接口後，獲知寫一個敲定好邏輯的接口後臺代碼需要的時間數據：寫代碼3個小時，debug+本地測試大概需要兩小時。這部分時間這麽長還是因為對於php和Web框架不熟悉的原因。如果把後臺代碼部署到服務器上讓前端對接，在前端不熟練的情況下要額外多出一天的時間預算。這樣子的精度還是足夠的，方便PM和小組長把控進度。也方便其他成員參考，留出多少時間段來進行開發。

• 測試的時間，人力和軟件/硬件資源是否足夠?

測試的時間和人力不足夠，感覺軟件還有很多缺陷，代碼也不夠完善。大家學習開發知識的同時還要應付考試，為了完成基本功能就已經費神費心，基本任務完成就感覺已經可以交付了，對於測試和代碼的健壯性不是太上心。

• 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?

PM：是。將頭腦裏的設想付諸實際，其實是一件很難的事，在項目中的體現就是雖然閱讀了《material design》的設計教程，但要真正做出符合設計規範的UI界面比想象中困難很多。

• 你有沒有感到你做的事情可以讓別人來做（更有效率）?

恒達：前端界面要個確定的Ui和審美規格，重寫3次才用框架的我眼淚掉下來。

嶽昕：有的，我覺得我寫的接口後端組裏的大佬們大概幾分鐘就寫完了，而我花了兩三小時，所以有時候會覺得其實我好像可以更適合web組，畢竟更多的開發經歷是html。大概這就是“群佬我菜”的感覺吧。

• 有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?

恒達：任務deadline的提前量如果能更精確就好了，這樣子有利於項目進度的把控。

變更管理

• 每個相關的員工都及時知道了變更的消息?

Alpha沖刺時每兩日一次的站立會議交流算是一個很好的方法。此外，線上交流很方便。如果有線上聊天解決不了的技術細節問題，組內（前端組、後端組）或者整個項目組就會進行團隊現場編程來面對面解決。

• 我們采用了什麽辦法決定“推遲”和“必須實現”的功能?

必須實行的功能就是項目的核心功能和Alpha沖刺實際開發過程中遇到困難較小的功能。

推遲，一般是因為這個功能可能需要較大的工作量而Alpha沖刺的時間所剩無幾，這時大家就做出推遲到Beta沖刺時完成的決定。

• 項目的出口條件（Exit Criteria – 什麽叫“做好了”）有清晰的定義麽?

在需求規格說明書中的“Alpha驗收標準”有清晰的定義。

• 對於可能的變更是否能制定應急計劃?

因為需求和項目的具體邏輯是組內制定的，好像也沒有那種變化程度太過急劇或者有提出什麽十分刁鉆的需求以至於要到“應急”的程度吧。

• 員工是否能夠有效地處理意料之外的工作請求？

項目初期對於任務的劃分基本上涵蓋了整個Alpha沖刺過程。幾乎沒有意料之外的工作變更。一般來說組長布置給組員的額外的一些小任務（例如多加個按鈕，某個邏輯有點什麽小變更，多寫個接口之類的）團隊成員也可以及時地完成。

• 我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?

感覺這部分我們團隊做的還是不錯的。

設計/實現

• 設計工作在什麽時候，由誰來完成的？是合適的時間，合適的人麽？

在Alpha沖刺的初期，全組成員開會討論清楚整個業務邏輯。但這個不算真正的設計，因為很多內容和細節再實際開發的設計過程中都由重新敲定。

UI原型設計主要由PM來負責。

到了實際編碼前的設計，例如設計邏輯、設計接口和表，主要由趙暢、王源和王彬來完成。（後端組組長和組員以及PM）

• 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？

因為都到設計階段了，有什麽模棱兩可的情況出現都會討論清楚並敲定一個最終的方案。

• 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麽？ 比較項目開始的 UML 文檔和現在的狀態有什麽區別？這些區別如何產生的？是否要更新 UML 文檔？

沒有運用單元測試，但有測試驅動的開發，每個接口都有寫測試用例，雖然可能不是很完善。

有設計UML。UML是很有效的，有的時候對於概念不清淅可以打開類圖看看，在討論邏輯時打開用例圖和泳道圖幫助理清思路。

開始的UML和現在的文檔肯定是有差別的。例如數據庫的字段名字、屬性類型，類圖中對於每一個模型的定義或多或少有刪有減等。這些區別的產生是很自然而然的，這裏引用《人月神話》中的一句話：“對於創造者，只有在實現的過程中，才能發現我們構思的不完整性和不一致性。”

我們倒是沒有更新最初的UML文檔，這些最初的UML圖都始終作為參考，時不時地被打開。真正開發時用的接口文檔都是重新寫的。

• 什麽功能產生的Bug最多，為什麽？在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況?

前端Android頁面出現的Bug最多，包括例如動畫效果在某些品牌的手機下會導致應用閃退，某些情況下地圖數據在地圖上繪制不出地標等。原因，就是在大多數情況下（運行的好好的）我們並不清楚是為何導致了這些BUG。可能是由於安卓生態環境的碎片化，各家廠商並沒有遵循原生安卓的系統設計規範。還有就是有些Bug的產生觸及到團隊成員的知識盲區了。

• 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

後端代碼由趙暢負責代碼復審，審閱代碼、註釋以及接口文檔。後端這方面工作做的還是不錯的。

誌煒（前端組組長）：前端組並沒有很嚴格地進行Code Review，大致merge到master大部分都是自己在進行的，部分存在沒有完全遵守代碼規範的情況。我的部分我覺得是沒問題的 個人認為還是時間成本的問題吧，但還是應該規範起來，提高代碼的整體質量。

測試/發布

• 團隊是否有一個測試計劃？為什麽沒有？

本來分布了一位同學專門負責測試，但最後這個計劃擱淺。

展瑞：因為我本來的任務是負責測試的，但是同時也在後端組做事。期間有一段時間學習了一下測試的相應知識，發現了自己在語言上和一些知識儲備都有相應的不足。開會的時候，基於我們的代碼比較優秀的前提下，我們覺得測試任務可能不需要采用自動化測試，而且人工來測試。所以測試計劃被拖後，直至死亡。

• 是否進行了正式的驗收測試？

在後端，每個人都寫好接口文檔，都經歷本地的測試，以及服務器測試，才交付前端進一步開發。在整合系完所有功能後，手動考慮多種情況進行測試驗收。

• 團隊是否有測試工具來幫助測試？

後端使用postman對每個情況都進行了測試。

• 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用麽？應該有哪些改進？

頁面整合完後，在不同的機型上使用，出現了頁面切換出現一些bug，以及部分機型有閃退的情況。

• 在發布的過程中發現了哪些意外問題？

發布了alpha沖刺後的第一個版本，發現了沒有寫logout的按鈕。因為我們有token機制來使得一名登陸的用戶保持兩小時的活躍狀態，超過兩小時未有操作就需要重新登陸。然而我們忘了寫退出登錄的按鈕，如果token過期，就永遠無法再登陸，需要重裝APP才可以解決這個問題。是個嚴重BUG。

• 我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?

恒達：假如能重來，會在前端組內更加積極的交流，在前端組內也寫上技術文檔，提高前端界面質量。

團隊的角色，管理，合作

• 團隊的每個角色是如何確定的，是不是人盡其才？

其實只有誌煒算是一個熟練工，他作為安卓前端組的小組長是當之無愧的。其他人都是完全的新手，在分配角色時是自願或被指定的，就很隨緣。

當然最後的結果是大家都發揮了自己的作用，大部分人都能做自己擅長的東西。

• 團隊成員之間有互相幫助麽？

PM：有的。我們的管理方式為三位一體：PM、前端組、後端組。前端組由誌煒帶隊，誌煒有實際的項目經驗，其他成員有問題都可以請求幫助。

趙暢（後端組組長）：後端組內有形成一份組內自己的技術文檔，有任何問題都可以詢問組內成員或者直接查詢這份文檔，裏面很多問題都有組內成員積累的可行解決方案，省去了很多百度、google的精力。

誌煒（前端組組長）：有的，自己Android也寫的比較多，遇到的坑，爬出來的坑，相對而言多一些吧，同組的遇到問題時，能給予一些幫助。使用過的工具也較多一些，也能給出一些推薦。

• 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？

討論之後由PM、前後端組長作出決定。

• 每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的博客裏）：

• 我感謝 _______王源______對我的幫助， 因為某個具體的事情: ______親自指導git團隊協作如何執行，完美避免了分支出現問題的情況_______。

• 我感謝 _____所有團隊成員______對我的幫助， 因為某個具體的事情: ______能夠相互配合幫忙完成Alpha版本的開發_______。

• 我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?

文垚（前端組）：我學會了Java和Android開發，特別是對Json數據的使用和理解，並且在隊友的教導下學會的git的使用。如果歷史重來一遍，和我會將回答問題界面的UI設計得再優美一點。

煌偉（Web端）：學到了一個團隊是如何合作運行，每個人如何為團隊更好地貢獻自己的一份力量。如果歷史重來一遍，我會在沖刺之前更加充分學習所需要的技能，而不是在沖刺階段邊學邊做

誌煒（前端組組長）：如果是對於我個人而言，可能需要做的就是再肝一些吧，但這學期開頭肝了一個多月，快兩個月吧，所以有點想進入點養生狀態，所以這階段即使有熬夜也沒有特別晚就只到一點多兩點左右，每天差不多可以說是事情都排得挺滿的，也勉強完成。

總結:

• 你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?

我們查閱了這個鏈接來了解CMM/CMMI是什麽。討論後認為，後端組的工作以及達到了已定義級(Defined)，因為後端組有實現技術工作和管理工作的標準化、文檔化。後端組組長趙暢放出狂言“隨便來個人我都能培訓到他能寫代碼”。前端組水平介於初始級別(initial)和可重復級(Repeatable)之間。

• 你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?

後端組：整個團隊目前處於創造階段。

前端組有不同意見：規範階段吧，還有一些東西能再規範一些。

• 你覺得團隊在這個裏程碑相比前一個裏程碑有什麽改進?

對比Alpha開啟前，我們項目組最重要的改進是真正的能產出代碼，以及對於任務需要的時間有一個度量的標準。還有就是大家對於軟件工程裏的一些概念有了切實的體會，例如文檔、項目進度管理、前後端的合作等。這些是只聽理論課體會不來的。

• 你覺得目前最需要改進的一個方面是什麽?

趙暢（後端組組長）：Alpha沖刺初期花在學習基礎知識和熟悉框架、編程語言上的時間，應該提前去完成，需要提高積極性。

王彬（PM）：應該增強空余時間的緊迫感，這樣才能避免出現突發事件時的措手不及。

文垚（前端組）：隊員之間的溝通交流還需要進一步的加強，特別是在遇到某些難題時，更應該積極溝通，一起討論出解決方案。

• 對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

參照《構建之法》P114頁的敏捷開發原則，回顧我們的Alpha沖刺過程，我們做得比較好的有：

1. 第四條：“業務人員和開發人員在項目開發過程中應該每天共同工作”。團隊現場編程是常有的事。
2. 第五條：“以有進取心的人為項目核心，充分支持信任他們”。前端組和後端組各有一名組長，分組管理，在他們的帶領下每一個組都把各自的工作完成的不錯。
3. 第六條：“面對面的交流始終是最有效的溝通方式”。例如Alpha站立會議、團隊編程、開會討論等等。
4. 第九條：“不斷關註技術和設計，才能越來越敏捷”。後端組有自己內部的技術文檔和所有接口設計文檔，積累了經驗。

團隊貢獻比例

答辯總結

小組現場答辯評分

• 去掉一個最高分，去掉一個最低分，小組最終得分為79.86分

第二組的提問

• 問題1:提給用戶的問題是否多樣化？

• 答:我們的問題庫中目前有40道問題,每次用戶需要推薦時我們會從問題庫中隨機選出三道題供用戶選擇自己的口味,在beta我們會酌情考慮擴充問題庫的規模.

• 問題2:商家端的功能會有哪些？

• 答:商家端將基於web提供服務,目前已經做好頁面的功能有菜品添加頁面,商鋪端註冊登入頁面,之後在beta階段我們會繼續實現用戶口味分析報告頁面

• 問題3:地圖上的紅點太密集了，也沒有店鋪信息，能否出線一項展示推薦產品具體位置的食堂的平面圖？

• 答:地圖上的紅點代表每一個店家的位置,紅點大小的問題我們已經找到了解決方法,在後續會使得定位點的大小隨地圖縮放等級改變.至於用平面圖展示產品具體位置的功能我們已經在alpha版本中有所考慮目前需要手繪食堂平面圖並收集各個店鋪的相對位置來支撐我們的功能.

第三組的提問

• 問題1:用戶口味是長期形成的，如果用戶的選擇類型一致，會不會出現一直重復推薦某一道菜品的情況？如果會，那麽你們是如何處理矯正的？

• 答:我們也考慮到這個問題,所以我們在alpha版本的推薦算法中只針對用戶明確拒絕的菜品更新用戶的口味,並且我們的推薦算法並不只推薦一道菜肴而是了概率排名前幾位的菜品隨機推薦給用戶,一定程度上預防重復推薦一道菜的情況.

• 問題2:菜譜更新麻煩，個人感覺如果要進行更新需要一個個去調查，過於麻煩，能否做到與商家合作，通過商家更新信息來做到實時更新

• 答:菜品更新只能靠人工這個問題我們也很無奈,不過我們是起步中的開發小組在食堂看來沒有什麽話語權,如果未來我們得到其他方面的資源支持會考慮與商家合作更新我們的菜品信息.

• 問題3:請問你們提供給用戶測試的題目有多少呢？真的能夠準確的測試到嗎？

• 答:我們的問題庫中目前有40道問題,每次用戶需要推薦時我們會從問題庫中隨機選出三道題供用戶選擇自己的口味.用戶的口味是一個主觀的問題,我們只能力求通過我們的問題獲取用戶當時的一個口味偏好.

第四組的提問(暫無)

• 問題1:

• 答:

• 問題2:

• 答:

• 問題3:

• 答:

第五組的提問(暫無)

• 問題1:

• 答:

• 問題2:

• 答:

• 問題3:

• 答:

第六組的提問

• 問題1:您好，你們的PPT很是精美規範，具體介紹了你們的算法和代碼規範，這方面值得借鑒 。但UI界面設計就略顯遜色，有想過在這方面進行改進嗎。

• 答:分兩方面回答:1.PM個人喜歡簡潔大方的UI設計這在一定程度上反映到了產品的UI設計上,但美醜仁者見仁智者見智. 2.產品目前處在alpha開發階段我們會在後期針對UI進行相應改進以期符合主流審美.

• 問題2:您好，你們的PPT顯示的實現功能看起來有點少，你們以前設下的功能還有多少未實現，可以簡要說明一下嗎，如果已經全部實現，可以說下後續是否會增加附加功能嗎?

• 答:在alpha開發階段我們將開發精力放在了產品核心功能--菜品推薦上,在之後我們的安卓端預計還會添加美食地圖的內容,店鋪風雲榜功能,以及提供用戶瀏覽推薦歷史記錄的功能,這部分功能的接口已經在alpha階段的後端設計中做了鋪墊,會在beta繼續完場上述功能.

• 問題3:你們軟件的商家功能還未實現，可見你們的進度稍慢，後續你們要調整自己隊的隊員分工和完成時間，來提高進度?

• 答: 在alpha階段我們的前端將主要精力放在了開發安卓端應用上,但商鋪端的頁面我們也已經基本設計完成但未在alpha答辯中展示出來:請看我們的商鋪端頁面

第七組的提問

• 問題1:是否考慮過提供菜品的相關介紹？

• 答:鑒於並沒有現成的福大各個食堂的菜品介紹數據來源,而憑我們目前的力量對每道菜添加菜品介紹也並不現實,所以我們暫時不會考慮添加菜品介紹的功能.

• 問題2:地圖有很多地標，可是並不知道這些具體指示的是哪一家店？

• 答:鑒於目前數據庫中並沒有足夠的用戶信息,我們會在beta階段將地標設置成顯示商品信息的按鈕,一旦按下地標就會顯示出該商家的店鋪信息與熱門菜肴.

• 問題3:如果提供多個備選的菜品我還是不知道選哪一個怎麽辦?

• 答:我們的app只能做到提供就餐建議,最後用戶吃什麽的最終決定權屬於用戶

第八組的提問

• 問題1:推薦算法是否需要用戶的用餐數據？

• 答:我們的推薦算法會參考用戶的過往選擇記錄,並根據每個用戶的偏好生成用戶的口味畫像,在推薦時會依據用戶口味進行推薦決策

• 問題2:問答的問題與用戶的使用喜好相關嗎？

• 答:我們的問題庫中目前有40道問題,每次用戶需要推薦時我們會從問題庫中隨機選出三道題供用戶選擇自己的口味

• 問題3:有沒有開發附加功能以增加用戶黏度的計劃？

• 答:我們的產品理念是將app做成一款方便的工具,當用戶有不知吃什麽的選擇困難時就會想起我們的app,而在其他時間我們也並不想搶占用戶寶貴的時間

第九組的提問

• 問題1:PPT已經很完整的展示了功能，但是感覺UI界面設計比較簡陋，在今後打算怎麽改善？

• 答:分兩方面回答:1.PM個人喜歡簡潔大方的UI設計這在一定程度上反映到了產品的UI設計上,但美醜仁者見仁智者見智. 2.產品目前處在alpha開發階段我們會在後期針對UI進行相應改進以期符合主流審美.

• 問題2:PPT已經很完整的展示了功能，但是感覺UI界面設計比較簡陋，在今後打算怎麽改善？

• 答:同上

• 問題3:在推薦菜品這方面打算怎麽處理？

• 答:我們將繼續跟進商家的菜品更新

團隊討論合照

• 

• PSP

學習進度條

軟工1816 · 作業（十一）事後諸葛亮