設想和目標
1. 我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
??????在最開始的時候我們就是為了解決集美大學計算機工程學院網頁沒有搜索引擎的問題。因為沒有搜索引擎，在搜索內容時需要根據查找信息所屬的不同區域來查找，這個過程非常不方便用戶信息的得取，也很容易找不到相關信息。我們在Alpha階段最簡單的實現了計算機可以查找信息，并且相應的進行顯示，但是因為沒有部署到服務器上，沒辦法發布出去，不能進行普及，所以Beta階段我們主要解決服務器部署的問題，然后再針對一些小細節來方便用戶體驗，提高用戶使用的滿意度。
關于定義在前期的時候就已經清晰定義了，所以整個設計過程中還是很清楚的。典型的用戶和典型的場景有在需求說明書中詳細給出，主要針對的一直是普通用戶，可以是老師也可以是學生，更可以是想要報考集美大學了解計算機學院的人群。
2. 我們達到目標了么（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了么？原計劃達到的用戶數量達到了么?)
??????我們基本目標都達成了，但是沒有把Beta階段所有的目標都實現。在Beta階段我們計劃了如下：
- 新增其他學院的搜索引擎
- 實現網站的定時爬取以及es的自動同步
- 主界面設置最新通知播報欄
- 新增按時間篩選信息功能
- 擴大使用范圍至移動端
- 將項目部署到服務器
??????但是最終我們的版本里更改了主界面設置最新通知播報欄，從原先設想的多個通知欄變成一個最重要的通知欄，而新增按時間篩選信息功能因為時間的緣故最終沒有去實現它。雖然少了這一部分，但是整個的主要部分都完成了。在用戶調查階段參與測試的用戶79名，相信不久的將來會有更多人使用的。
3. 和上一個階段相比，團隊軟件工程的質量提高了么？ 在什么地方有提高，具體提高了多少，如何衡量的？
??????整體質量效率都有提高。之前在各個功能的實現上都走了很多彎路，然而現在實現的很多功能都可以在預期時間內完成，而且因為期末大家時間比較有限，有幾次隊員沒辦法都到，雖然人數減少了，但是項目的進展并沒有影響。
4. 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?
??????接受程度比我們預計的要高一點，因為最開始做的時候主要突破在界面以及細節完善上，但是只能憑借我們自己的主觀感受來設計。但是后來我們發現，以前針對一個學院的數據時還是可以做到搜索比較精準的，等數據量擴大后，精準度上有所減少，不如第一階段的精確度了，這個應該是關鍵字的索引那邊需要更改，那個關鍵字精確的方法不適應于較大數據量的情況。
5. 有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
??????整個開發下來，我覺得很多的設想需要有延續性，不能看得太眼前，不然可能未來需要動基層建設。如果歷史從來一遍，我覺得我們可以在前期的時候除了關注點在界面設計上，應該在關鍵字索引的地方多下點功夫，應該選擇一個即使數據量比較大但也同樣適用的方法來實現。
計劃
1. 是否有充足的時間來做計劃?
??????是的，預留了一個半天時間專門用來準備beta階段的沖刺計劃。
2. 團隊在計劃階段是如何解決同事們對于計劃的不同意見的？
??????和Alpha階段一樣我們，當產生分歧的時候我們首先會進行討論，最后得出一個大家都滿意的方案，當然每個人都需要做出一定的妥協。
3. 你原計劃的工作是否最后都做完了? 如果有沒做完的，為什么?
??????beta階段的計劃都完成了。這一次我們預留的時間相當充足，最后距離截止時間甚至還有一周。沖刺過程中對計劃有進行一定的調整，不過偏差不大。
4. 有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
??????原定計劃中有一項按時間排序功能，在著手準備的時候發現，主流的搜索引擎有按時間范圍篩選，但沒有按照時間排序的，實際運用上來說按時間排序也沒有什么實際意義。在這一功能的討論上，浪費了我們一些時間，最后刪除了這一功能。所以在做功能的規劃的時候，還是要再多調研一下。
5. 是否每一項任務都有清楚定義和衡量的交付件?
??????對比alpha階段，這一次我們有著清楚的定義，但放棄了過于高標準的定義，追求功能的基本實現。
6. 是否項目的整個過程都按照計劃進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
??????本階段順利的按照計劃進行，最后提前一周完成沖刺。唯一的意外是域名的申請備案，到用戶調查結束都沒有審批下來，好在影響不大。
7. 在計劃中有沒有留下緩沖區，緩沖區有作用么?
??????留下一周的緩沖區，但沒有使用上，原因是用戶調研結果不需要我們做出過多的更改。
8. 將來的計劃會做什么修改？（例如：緩沖區的定義，加班）
??????alpha階段，我們計劃對任務量進行壓縮，留下充足的緩沖空間，這一點我們在beta階段完成的很好了。如果還需要對產品進行迭代，我們可以保持現階段的節奏進行。
9. 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
??????beta階段對比alpha階段來說，更順利，包括技術和溝通上都有了很大的進步。歷史再來一遍的話，我們也許不能做到更好了。
資源
1. 我們有足夠的資源來完成各項任務么?
??????alpha階段已經有基礎了，而Beta階段新增的功能網絡上也有一些參考資料。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
??????根據個人開發階段每個人所需要的時間進行估計，精度較為準確。
3. 測試的時間，人力和軟件/硬件資源是否足夠? 對于那些不需要編程的資源 (美工設計/文案)是否低估難度?
??????測試時間相對Aplpha階段較為足夠。對于缺少筆記本電腦的成員，在除了一定要全體面對面溝通的情況下，我們采取了網上群視頻通話的方式進行共同開發。對于其他資源，美工設計方面在Beta階段無需改進，而對于搜索引擎來說文案并不需要。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
??????Alpha階段雖然是混著做的，但還是有一些大致的成員分工，所以在Beta方面也是考慮了Alpha階段的任務安排情況來進行成員分工，大家都是做自己較為擅長、Alpha階段有經驗的任務，所以還是很合理的。
5. 有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
??????因為計劃新增的功能較多且后階段臨近考試，所以提前完成了項目，計劃新增的功能中有些需要大量的時間研究且難度較高，最后未能完成。計劃時考慮時間和完成難度，做一個更合理的優化計劃。
變更管理
1. 每個相關的員工都及時知道了變更的消息?
??????alpha階段的時候因為沒有太多的使用碼云來同步代碼，所以在beta階段的時候我們有專門注意代碼的上傳，每次沖刺完后都有在碼云上傳相關代碼。同時也有在用qq傳輸，或者u盤。
2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能?
??????必須實現的肯定是不能影響主要程序使用的地方，比如搜索引擎必須能搜索到內容，結果不能錯。推遲的內容是分詞器能不能自行控制。
3. 項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?
??????有清晰的定義，能用搜索引擎來搜到我們學院的內容，有兩個頁面，一個是搜索引擎的干凈整潔首頁面，一個是搜索到內容的顯示頁面，第二個頁面能準確搜索到用戶需要的內容，并且進行一個最優排序。
4. 對于可能的變更是否能制定應急計劃?
??????能，剛開始本來是定制的所有學院都做一個搜索引擎，但是后面發現要完成一個就需要花一下午的時間，所以我們就改為只加了一個航海的搜索，也是因為航海沒有搜索引擎，并且也能證明我們也能把其他的學院都爬下來只是需要時間而已。
5. 員工是否能夠有效地處理意料之外的工作請求？
??????能，當我們PM在沖刺之前給的任務，在進行之后發現還有一些零碎的關鍵任務沒有人去完成，PM會按照大家擅長的部分去分配，并且會說一個截止日期，會在群里面督促大家盡快完成，所以我們每次都能有效的完成意料之外的工作。
6. 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
??????完成一個項目的時候不能死腦筋，必須做完這個才干嘛，有時候需要靈活的運用和方法來促使整個項目的完成，會比一個人鉆牛角尖好得多。這次我們安排了很多次沖刺，時間安排的很棒，不會說因為最后沒時間的趕工，因為大家最后都有考試，所以提前了兩三天就結束項目。
設計/實現
1. 設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
??????設計工作在第一次老師給出這個項目需要幾個幾個星期完成的實驗課，我們在實驗課上就開始討論前端頁面的樣式和要求，同時也在網上查找搜索引擎和爬蟲的相關知識，大家都在實驗課上一起討論，但是這個時間是遠遠不夠的，后面沖刺的時候最開始也有討論過我們程序的走向，討論好后最終定下終稿。
2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
??????用戶測試這一塊，我們是用的調查問卷，在制作調查問卷，提問的時候因為有些考慮到很多人不喜歡填寫調查問卷，所以我們準備把問卷做的簡單一點，我覺得是用戶的建議是最重要的，所以我推崇就一個空，我們的搜索引擎有什么需要改進的么，這樣我們就能拿到我們需要的內容，別人也不會覺得很煩，但是秦玉覺得應該像普通的問一些問題，不然空口答別人可能也沒什么建議，我們要的數據就根本沒有。
3. 什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
??????爬蟲功能產生的Bug最多，因為界面不一樣，學校的網站不是Css結構的，完全是又一個一個的表格寫出來的網頁，所以爬取跟普通的網站爬取又有區別，都是一步一步的學習改進才爬取出數據的，因為對爬蟲理解的不深。我們還沒有發布。同時也是我們對爬蟲了解也不夠深入，只能爬取到紅色標題的內容，但是經過后期的改進已經能爬取全部的內容了。
4. 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
??????代碼復審統一由一個人來規范代碼，嚴格執行了代碼規范，因我們在編寫的時候就在注意代碼的編寫，這樣方便大家的理解同時后期也不用改這么麻煩。
5. 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
??????只有當自己真正開始編寫代碼的時候你才能進步。編程的重要任務還需要分的細致一點，這樣大家都能寫到關鍵的代碼，更多的熟悉爬蟲。
測試/發布
1. 團隊是否有一個測試計劃？為什么沒有？
??????沒有花太多的時間在測試上，只是有一個大概的測試計劃。因為Beta階段完成的功能比較零散，而且很多是在Alpha階段做一些改進（如新增其他學院的搜索引擎），代碼框架都是一致的，所以在搜索速度、爬取速度等方面基本沒有變化。
2. 是否進行了正式的驗收測試？
??????進行了正式的驗收測試。
3. 團隊是否有測試工具來幫助測試？
??????沒有用到，只是用黑盒測試、瀏覽器自帶的性能測試等方法來測試。
4. 團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
??????我們并沒有測量并跟蹤軟件的效能，我們只有代碼測試各個瀏覽器的頁面是否正確，搜索速度，爬取速度等的測試，后階段進行用戶調查，調查問卷中附加了網頁鏈接，其實也是在測試服務器和用戶交互。很有用，讓我們的程序更符合大眾使用的要求，改進了很多我們忽略的點，同時也驗證了服務器性能。
5. 在發布的過程中發現了哪些意外問題？
??????通過用戶調查后得到的數據，發現搜索得到的結果項中的摘要部分，是顯示文章中匹配到的最后一個關鍵字的地方，所以若某文章中該關鍵字出現的位置分布在文章的前部和后部，則會導致摘要顯示的篇幅比較大，其實應該做到像百度搜索出來的結果摘要，顯示固定的大小。
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
??????在發布過程中發現的摘要問題，我們在編寫及測試的時候都沒有意識到，在用戶交互方面還有所欠缺。在編寫項目的過程中，應該更多的以用戶的角度去思考，因為做出來的產品是給用戶用的，而不是程序員本身，當然在技術方面，則是要以程序員的角度尋求最優解。
團隊的角色，管理，合作
1. 團隊的每個角色是如何確定的，是不是人盡其才？
??????這次的角色確定會更多地還是從比較細的方面來劃分，因為beta階段與alpha相比，目標明確了很多，最后分出來的任務也比較細致，然后根據每個人的能力或是意愿來進行任務的分配，大致可以做到人盡其才。
2. 團隊成員之間有互相幫助么？
??????有互相幫助，因為我們平時都是聚在一起來完成這個項目的，因此在遇到困難的時候，一般會直接提出來，然后手頭上比較閑的同學就可以一起來想解決問題，解決完以后積累下來的經驗也會跟其他成員交流，防止踩到同一個坑里。
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
??????遇到了這方面問題的時候，一般就是讓矛盾雙方闡述自己的想法，然后再一起交流，最后達成一致，但是其實經過了alpha階段，我們在這方面都比較成熟和默契，一般不會出現這種問題。
總結
你覺得團隊目前的狀態屬于 CMM/CMMI 中的哪個檔次?
??????屬于第五級 優化級
你覺得團隊目前處于 萌芽/磨合/規范/創造 階段的哪一個階段?
??????我們團隊目前處于創造階段。beta階段我們的團隊成員已經對規范方面有了比較好的實現，然后集體意識也有所提高，對于項目的走向也有一個比較好的把握。
你覺得團隊在這個里程碑相比前一個里程碑有什么改進?
??????相比于alpha階段，首先，我們團隊成員之間的配合更加的有默契， 能夠更好的溝通交流；其次我們在技術能力方面也有很大的進步，從最開始對搜索引擎的貧乏的了解到現在已經能大概掌握其全貌以及具體實現方法；最后，我們團隊在代碼規范方面和管理方面也有了比較大的改進，前一個階段比較不注重規范，主要還是求能實現功能就行，然后在管理方面也沒有使用專門的工具來處理，beta階段開始我們會比較注重這一點。
你覺得目前最需要改進的一個方面是什么?
??????我覺得雖然我們最后完成了這個項目，但是總體的完成效果其實還是有一些瑕疵，主要還是因為我們投入的時間不太多，因此我覺得需要改進的是希望我們團隊的成員能投入更多的時間在項目上，這樣做出來的效果應該會更好一點。
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
??????對照TSP原則，我認為我們小組在以下幾個方面做得比較好：
- 團隊的各個成員對團隊目標、角色、產品都有統一的理解
在我們開始對產品進行討論的時候，就已經小組達到一個共識，然后在后面不斷地編寫程序完成項目的時候，我們也會定期交流一下我們項目的未來走向以及其他一些與項目相關的內容。 - 增加團隊的自我管理能力
我們團隊的每個成員對于我們的項目都能夠比較好的投入到里面，每個人都有自己的定位，也都能在計劃時間內完成任務。
