-
我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們的軟體是設計一個圖書管理系統軟體，解決整個圖書館的書籍管理和使用者借閱書籍等問題。
我們軟體的使用者群體是學校的全體師生，資料是圖書館的書籍、使用者和管理員的資訊，對於軟體的定位十分明確。 -
每個成員在beta 階段的實踐和alpha 階段有何改進?
| 成員 | 改進|
| -- | -- |
| 賴國顥 |我在beta階段之前，對於Qt的開發停留在幾個小頁面，小元件的開發，專案一大，就很混亂；現在我能充分佈局好多個頁面，還有頁面於頁面之間的通訊框架，現在我感覺就算開發的專案再大，我也能做到在開發中對各個物件約束得井井有條 |
| 楊百友 |學到了如何整理文件和進行介面管理 |
| 劉立光 |提高了資料庫的效率，減少了不必要的資料冗餘。 |
| 李子聰 |對postman有了更深的理解和對markdown的使用更加熟練 |
| 李濟遠 |beta階段相較於alpha階段對資料庫的認識更為深入，熟練度更高 |
| 李兆彬 |beta階段在alpha的基礎之上測試工具使用更加熟練，效率更高 |
| 黃永名 |Beta階段更加深刻理解了專案的每個職位的職能，專案程式碼執行邏輯 | -
團隊在beta 階段吸取了那些alpha 階段的經驗教訓?
在alpha階段中，我們對使用者需求的分析不夠仔細完整，有些功能是不應該做的，而有些功能是必須品，缺遺漏了，所以我們總結出要儘量延遲開發，把前面的使用者需求和框架做好了，再開始編碼，這樣開發會更少出錯，也更加高效。 -
12 條敏捷開發的原則中, 團隊做得最好和最不好的各列舉 2 點。
最好的兩點：
(1) 工作軟體超過詳盡的文件：
雖然文件很重要，但更重要的是交付能夠工作的軟體。我們在開發過程中，對工作軟體是精益求精的。
(2) 自我組織超過等級制度：
在團隊合作過程中，我們每個個體都充分主動地參與進來，對於一些沒有在會議中談到的點，我們也可以在私下把他們完成。
最不好的兩點：
(1) 程式碼複用超過程式碼複寫:
我們這次的開發中，很少考慮程式碼的複用性，程式碼幾乎都是獨立的個體。
(2) 最佳實踐 超過最佳工具：
我們都是使用自己會的工具來開發的，沒有考慮到什麼樣的工具更加適合這個專案。 -
對照 The Cathedral and the Bazaar (大教堂和集市), 你的團隊開發模式是哪一種, 優勢/劣勢在哪裡?
我們團隊的開發模式更傾向於封閉的大教堂，這是因為我們可以更加集中盡力去解決當下的問題。
優勢是：這種方法，交流成本更低，可以有更多的時間去進行程式碼的開發和測試；
劣勢是：實際開發出來的功能可能和使用者想要的不一樣，又需要重新加工。
成員貢獻表
| 成員 | 貢獻事項 | 貢獻佔比 |
|---|---|---|
| 賴國顥 | 擔任專案組長，負責統籌全域性，開設會議，組織討論，同時負責部落格的製作和客戶端的開發和測試 | 20% |
| 楊百友 | 主要負責後端伺服器模組，主要工作內容包括設計HTTP協議和介面，登入授權，許可權認證，介面攔截，以及為前端提供資料庫資料獲取服務 | 16% |
| 劉立光 | 負責資料庫設計，透過進行需求分析設計圖書管理系統的關係表 | 12% |
| 李子聰 | 負責團隊的部落格和計劃表等文字工作，及部分測試的工作 | 13% |
| 李濟遠 | 負責資料庫設計，透過進行需求分析設計圖書管理系統的資料庫結構，並根據團隊成員需求及時修改資料庫結構。 | 12% |
| 李兆彬 | 測試，使用postman進行介面功能測試，介面許可權測試和介面攔截測試 | 14% |
| 黃永名 | 收集圖書資料，資料庫（部分）工作內容：主要負責，一是收集圖書的相關資訊和資料。二是資料庫表結構的最佳化和改善，編寫了部分sql語句和說明文件。 | 13% |