一、sprint總結
當談到團隊，我開始真的不知道團隊是怎麼樣的，怎麼樣進行工作的，要該怎麼出力團隊的關係，有時候會涉及到個人問題，是不是該考慮進來，但是很多時候是不能的，每一個人作為團隊的一份子，有義務將自己的想法、意見表達出來，有義務為了團隊的利益而放棄一些屬於自己的東西，有義務多為團隊做貢獻。一個自私自立的人不可能在團隊里長久的生存。我們應該有一說一，有一做一，為了團隊目標的達成而共同努力。這是一個人能夠在團隊裡生存的基礎，這也是團隊能夠團結一致向前走的基礎。然後，團隊合作要處理好隊員與隊員之間的關係。既然是團隊，就必須保證團隊隊員之間的同心協力，共同進退。在這個過程，我們也完成了開始預期的效果，當然這也是需要團隊的配合，努力的成果，所以就是榮譽不是個人的，而是整一個團隊的，沒有團隊的幫助，也不會如今的成果。
二、發言
韓麒麟發言總結：介面做得比較簡潔明瞭，而且有熱點推送等介面，下一次的時候介面的美化還可以做得更好一點，內容可以更豐富一點，多樣化一點，；在做專案的時候，每個人的風格都不太一樣，所以做出來的東西都帶有各自的風格特色，最後整合的時候作品就顯得有點不倫不類的，希望下次可以統一一下風格。
王俊傑發言總結：這次成功完成任務，每個人都完成了屬於自己的任務，值得繼續努力，但是做出來的專案還是比較簡單，不夠特別出色因為各科的大作業都要準備答辯，時間比較緊張。但是我們還是盡力的去配合團隊，達到之前預期的效果。但是我們還是希望下一次任務做得更好，可以把各方面做得更好。
列志華髮言總結：我覺得這次的專案我做的很好，你不要問我為什麼，總之就很好，但是還是要在下一個衝刺中完善自己的任務，要使介面更好看，要使用頁面更多元化，還要做一個後臺系統，實現更改資料庫的資料，方便管理員的管理網站內容。
黃柏堂發言總結：第一次多人分工合作，使自己在這次任務做的沒有理想中的那麼好。首先，介面不夠美觀；其次，功能不夠齊全，還有功能不夠做的更細節；最後，程式碼難以與團隊程式碼結合。但是，在下次任務中，我需要更加把勁做好屬於自己的任務。我們會做的更好
三、生產率分析
我們的燃盡圖一開始的時候都不能按時的完成每天的任務，那是因為一開始我們的課程都比較滿，實在是抽不出時間來按時完成任務，導致任務進度一拖再拖，但後來到了週末，我們能抽出時間在專案上了，所以我們的燃盡圖在後期就開始呈現出加快進度的趨勢，以後我們會盡量的協調時間，按時完成任務。而且在後期就對於這個專案的理解還有對使用者需求更加理解。所以做起來就更加得心應手了，效率比前期高了幾個等級。
四、回顧結論
在之後就要美化一下頁面，增加內容的趣味性
圖片：
五、讀後感
第8章：講訴了專案需求的分析，如何做好需求分析，需求分析的步驟，讓我明白要完成一個專案，需求分析是十分重要的，同時，軟體開發不可能一次滿足所有利益相關者的要求，但我們一定要讓這些相關者在這個階段有機會提出他們的意見和需求，同時要弄清楚“他們想從軟體中得到什麼”。軟體的開發過程，就是“使用者最需要的東西”在一條關係鏈中傳送、轉換、實現、扭曲、或丟失的過程。如何確定"使用者最需要的東西"我們可以靠一些經過實踐證明行之有效的辦法，其中許多具體做法既可以用在軟體需求的收集階段，也可以用在測試階段，下面就是經常用的使用者調研方法：1.焦點小組、2.深入面談、3.卡片分類、4.使用者調查問卷、5.使用者日誌研究、6.人類學調查、7.眼動跟蹤研究、8.快速原型調研、9.A/B測試。
第9章：講訴了專案經理的功能，主要介紹微軟的Program Manager，他是產品開發和測試的補充，負責產品的長期發展和市場推廣。為此專案經理必須在一系列的專案計劃、組織和控制活動中做好領導工作，從而實現專案目標。
第10章：這章講述的是典型使用者和場景。按我的理解，這章是講程式必須在使用者的要求下找到他們真正的需求，程式功能不能缺失，但也不要有太大擴充性，否則不利於軟體的維護和安全。還說了規格說明輸對我們專案開發的幫助，規格說明書還可以分為軟體功能說明書和軟體技術說明書，只有通過實踐才能夠寫好規格說明書。
1）功能說明書
定義相關的概念->規範好假設->避免誤解，界定一些便界條件->描述主流的使用者/軟體互動步驟->一些好的功能和副作用->服務質量
（2）功能說明書模板
（3）技術說明書
（4）功能驅動的設計
構建總體模型->構建功能列表->制定開發計劃->功能設計階段->實現具體功能