1.團隊名稱和專案名稱
- 風啟團隊
- 寢室分配管理系統
2.學習和使用的新平臺
- APIcloud手機APP開發平臺很大的幫助了我們完成專案。
3.學習和使用的新工具
- mockplus原型設計工具，設計自己專案的原型，對自己專案有一個初步的印象。
- Enterprise Architect畫類圖，用例圖等，明白自己專案的功能。
4.學習和使用的新語言
- css語言（因為主要任務是前端介面要用到html及css語言）
5.學習和掌握的新方法
- MarkDown排版方法
- 簡單前端介面設計
6.完成的程式碼量
- 前端介面大概400多行
7.經驗總結
- 完成一個專案開發需要很多東西不光是學習我們從未接觸的知識還要學習團隊協作能力。
- 完成一部分任務要及時總結，有錯誤要及時改正。要養成勤總結的習慣。
- 老師教過的知識在專案中用到的很少，說明對學的知識沒有很好的掌握。
8.對學弟學妹的建議和告知
- 學習本課程會接觸很多新東西，不要害怕難、學不會，盡力去學。
- 認真對待每次老師佈置的作業，提升自己的程式設計能力。
- 在做專案這一塊要儘早制定計劃，小組成員團結協作。
9.對自己團隊的分析
我們團隊經歷過萌芽階段、磨合階段、規範階段、創造階段。
- 萌芽階段：只是匆忙組了隊，還沒有了解彼此的能力，初步建立了專案。
- 磨合階段：在對專案進行規劃時，隊員產生了分歧，最後通過上網瞭解相關資訊及查閱書籍達成共識。
- 規範階段：通過聆聽、討論，成員互相之間更加了解，認識到並欣賞各自的能力和經驗。
- 創造階段：隊員做自己的任務，團隊的注意力集中到如何完成專案上。
10.補充
- 1.生魚片模型中什麼時候上一個階段會結束呢？如何簡化大瀑布帶著小瀑布這種變型使這種問題能解決更多問題嗎？
- 我看了《構建之法》，有這個問題，書中講述了瀑布模型以及瀑布模型的變型，有生魚片模型，大瀑布帶著小瀑布。生魚片模型描述各相鄰模組像生魚片那樣部分重疊，大瀑布帶著小瀑布是為解決子系統之間進度不一，技術要求迥異的模型。 但是我還是些問題不太懂，就像書中提到的困擾，生魚片模型中什麼時候上一個階段會結束呢？如何簡化大瀑布帶著小瀑布這種變型使這種問題能解決更多問題嗎？（第五章團隊和流程P96）
- 回答：在生魚片模型中每一個步驟是分離的，有些步驟可能一同進行也可能一同完成。這說明這種模型有侷限。在大瀑布帶著小瀑布模型中，我們看到每個環節我們可以簡化這個模型例如在編碼除錯和子系統測試這裡，我們可以分類，把功能類似的一起測試，減少了多次測試的麻煩。 2.我們應如何選擇適合我們團隊的敏捷流程？
- 敏捷流程很多方法論，例如FDD,SCRUM,XP這些方法論都是人們自己總結出來的，但它不是萬能的，它有自己的適用範圍，它也可以為我們指引方向，那麼我們應如何選擇適合我們團隊的敏捷流程？書中也提出了這個問題讓我們思考，看了這些問題我發現我們團隊需要考慮的問題很多的，只有儘可能做到全面我們的專案才能更好的完成。（第六章敏捷流程P121）
- 回答：敏捷流程是總結出來的方法，它並不是萬能的，它對於我們做專案有參考功能，我們也能根據這些方法完善我們的功能。- 3.我們團隊如何找到適合自己的需求分析方法？選誰來當PM（專案經理）？
- 書上說PM（專案經理）可以通過需求分析找到需求，第八章也找到很多需求分析的做法，我還是有困惑，我的困惑是我們團隊如何找到適合自己的需求分析方法？選誰來當PM（專案經理）？（第九章專案經理P186）
- 回答：由於我們的專案是手機APP，我們就需要找到典型使用者詢問他們對我們專案的需求，我們根據她們的需求增添專案功能。至於PM就像書中提到的像樂隊中的指揮一樣，她懂得如何讓隊員最大的實現自身價值，她善於發現隊員的優點和缺點，她也具有引導的能力。 - 4.使用UML建模有什麼侷限？
- 在理論課上我們講了UML建模，主要學習了用例圖，順序圖，類圖，這三種不同的用例圖有自己都有的優點，我還有疑問，我的疑問是使用UML建模有什麼侷限？如何更全面的建模？搜尋了相關網頁發現UML建模標準化的同時也讓工程管理多了很多工作，要專門花精力來維護這麼一套東西，是很花人力物力的。那麼在這個基礎上我們如何改進這些侷限呢？
- 回答：UML建模只是對專案的初步規劃，如果專案後期有變動或者沒有達到最初的期望，那麼建模的用處也不大。可以根據儘可能根據自己的能力，建立適合自己團隊的模型。 - 5.如何有效的測試軟體？在測試階段怎樣衡量構建的質量？
- 書中說到測試團隊拿到一個構建之後，就會按照測試計劃，測試各自負責的模組和功能，這個過程可能出現10個或100個以上的bug，我還是有疑問，我的疑問是就像書中的提問，如何有效的測試軟體？在測試階段怎樣衡量構建的質量？（第十三章軟體測試P260）
- 回答：選擇適合自己專案的測試軟體，比如我們組做的是APP就要通過不同的手機進行測試，通過對APP進行壓力測試及相容性測試等觀察結果來衡量構建的質量。 - 6.通過四個象限對一個產品進行劃分，有什麼侷限？
- 在書中講如何通過四個象限對一個產品的功能進行分類，第一象限是殺手產品，第二象限是外圍功能，第三象限是輔助需求，第四象限是必要需求。針對這四個象限也有不同的處理的方式，但是我還有困惑，我的困惑是需求分析中通過四個象限對一個產品進行劃分，有什麼侷限？（第八章需求分析P344）
- 回答：通過四個象限對一個產品進行劃分，可以讓團隊對自己的專案有明確的想法，也可以決定怎麼處理不同型別的功能。但是這些劃分只是給自己專案的功能進行排序， 7.團隊如何能讓所有人都明確驅動和責任？
- 在書中練習與討論裡我看到了一個問題我也有相同的疑問，我的疑問是團隊如何能讓所有人都明確驅動和責任？在《夢斷程式碼》讀後感中說到，有理論認為，傳統的軟體公司用工資，職位，績效考核等讓一群經過面試和培訓的人在嚴格定義的流程下一起工作（大教堂/Cathedral模式）。其實，用開源，社群，共享的模式會更好，但是作者舉例反對了這個觀點並說明了“義務”勞動並沒有起到好的效果，這是關於驅動的問題。而責任與驅動是密切相關的，如果一個專案被拖延，遲遲不能完成，員工陸續離開公司，他們都沒有承擔自己的責任。我認為一個團隊要讓所有人明確驅動和責任就要溝通，內部外部都要溝通，而且要讓隊友明白自己的任務，併為自己的任務努力，制定規矩，以及獎懲制度，讓自己的專案如期完成。團隊應如何制度規矩？（第十七章人，績效和職業道德P379）
- 回答：我認為團隊可以每週進行會議總結，每個隊員彙報自己的完成任務的情況。組長對專案及每個隊員的任務進一步分析並制定規則，讓組員意識到自己的驅動與責任。
11.個人發揮
在這次團隊合作做專案中，我學到了很多，也很開心，意識到團隊協作的重要性。