Beta階段敏捷衝刺總結

設想和目標

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原則，我認爲咱們小組在如下幾個方面作得比較好：

• 團隊的各個成員對團隊目標、角色、產品都有統一的理解
  在咱們開始對產品進行討論的時候，就已經小組達到一個共識，而後在後面不斷地編寫程序完成項目的時候，咱們也會按期交流一下咱們項目的將來走向以及其餘一些與項目相關的內容。
• 增長團隊的自我管理能力 咱們團隊的每一個成員對於咱們的項目都可以比較好的投入到裏面，每一個人都有本身的定位，也都能在計劃時間內完成任務。