beta階段事後分析
設想和目標
我們的軟件要解決什麽問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
我們的網站希望提供一個課程評價平臺，幫助同學更好的了解每一門課的信息和評價。也提供了一個同學發表自己關於課程的想法的平臺。
網站定位清晰。我們面向的典型用戶就是每一個選課存在困難的學生，幫助他們在選課時間段很好的了解到上一屆學生每一門課的評價。我們達到目標了嗎？
我們beta階段的目標是在alpha階段的基礎上實現功能的擴充和界面的美化。在實現過程中，我們實現了對評價增刪改的支持，對評價下討論功能時支持，對用戶信息以及活動記錄的顯示，以及界面美化功能的實現。基本達到目標，但細節上仍然不夠完美。
和上一個階段相比，團隊軟件工程的質量提高了嗎？在什麽地方有提高，具體提高了多少，如何衡量的？
我們的開發仍然沿用上一階段的流程，由於對開發環境有更好的理解，所以開發效率有所提升。但是在軟件工程的質量上我們並沒有明顯的提高。這是我們這一階段沒有仔細思考反思的地方。
用戶量，用戶對重要功能的接收程度和我們時間預想的一致嗎？我們離目標更近了嗎？
我們最終的用戶量並不多，沒有能夠拿到有效的用戶反饋意見。但是我們從測試人員處得到了一些反饋信息，並根據反饋優化了用戶體驗和功能上的BUG。我們離目標更近了。
有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?
在預想功能設計時需要更加貼近用戶需求，設計重點不應是我們想做什麽樣的功能，哪些功能是方便實現的，而應該思考用戶需要什麽樣的功能，然後才是思考怎樣實現這一功能。即從用戶的角度思考問題。
計劃
是否有充足的時間來做計劃？
相比於alpha階段，軟工的beta階段和編譯等課程沖突較多，因此計劃的時間減少，但相對來說還是比較充足。
團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
在計劃階段團隊成員共同討論，過程中存在不同的想法和意見，但在交流過程中全面權衡之後，都能夠達成共識，定下合理的計劃。
你原計劃的工作是否最後都做完了？如果有沒做完的，為什麽？
我們在原計劃中的工作基本都完成了，並擴充了“討論中的艾特其他人”的功能。但是細節的處理還是存在一些實現方式問題，這是在實現前沒有提出一個好的規範導致的。
有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
我們做了一些功能說明文檔和各類流程與數據庫ER圖之類的說明文檔。但是在開發中這些內容我們並沒有用到。
是否每一項任務都有清楚定義和衡量的交付件?
有。在GitHub的issue中對每一個任務都有較為詳細的描述和需要實現的目標。但是衡量部分做的不夠好，不能保證每個任務都有明確的衡量條件。
是否項目的整個過程都按照計劃進行，項目出了什麽意外？有什麽風險是當時沒有估計到的，為什麽沒有估計到?
項目中出現過一些問題。由於跟其他課程沖突，有一個issue在實現過程中進度拖的比較久，導致項目進展拖延較多。在經過協調處理之後完成了這個issue。在這之後項目都按照正常進度進行。與其他課程沖突這一風險我們在計劃時有考慮到，因此對最終結果影響並不是很大。
在計劃中有沒有留下緩沖區，緩沖區有作用麽?
有留下緩沖區，也起到了作用。當項目進度出現問題後，緩沖區起到了作用，並依靠它趕上了進度，讓最終開發結果沒有受到影響。
將來的計劃會做什麽修改？（例如：緩沖區的定義，加班）
將來的計劃中應當考慮到不可預知的風險對項目的影響。
我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
好的計劃能有效地推進整個項目的進展。在計劃前，對項目開發本身有一個較清晰的整體印象，對於做出一個好計劃很有用。
資源
我們有足夠的資源來完成各項任務麽?
我們有足夠的資源完成各項任務。開發過程中出現問題後能夠通過網絡很快的找到解決方案。同時老師也能提供幫助，例如提供網站服務器。
各項任務所需的時間和其他資源是如何估計的，精度如何?
對於任務時間和其他資源的估計沒有特別的方法，而是根據對其大致理解進行預估。因此精度並不高。
測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
在beta階段我們團隊轉會轉出一人，所以在人力上不是特別足夠。但是合理分配每個人的工作量之後，還是能夠應對。測試的時間比較趕，好在測試人員張華傑工作迅速，又有alpha階段的經驗，在時限內完成了測試工作。我們在非編程方面的預估沒有低估其難度，制定了專門的issue完成界面美工設計。
你有沒有感到你做的事情可以讓別人來做（更有效率）?
的確會存在這種情況，將任務分給理解項目更好的成員實現將會更有效率。但這只是短期的高效率，長期以來將會導致團隊上限由某幾個成員決定。只有每個人都對工程有較好的理解，才能使團隊上限更高。
有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?
合理分配資源和時間，將任務分配到最合適的人。同時留出時間給測試階段。
變更管理
每個相關的員工都及時知道了變更的消息?
這一點我們做的比較好，變更消息都能及時在群裏通知。同時沖刺階段密集的scrum meeting也是很好的消息交流渠道。
我們采用了什麽辦法決定“推遲”和“必須實現”的功能?
確定核心功能，和核心功能密切相關的功能時必須實現的功能，相關度不是很大的功能將會推遲。相關決定事宜都會在例會中討論得出結果。
項目的出口條件（Exit Criteria – 什麽叫“做好了”）有清晰的定義麽?
出口條件就是很好地完成預先定下的目標，整個項目沒有功能，性能和用戶體驗上的bug。並且開發成果符合規範。
對於可能的變更是否能制定應急計劃?
項目並不龐大，團隊的開發流程相對靈活。因此遇到緊急變更都能夠盡快商討出合適的應急計劃。
員工是否能夠有效地處理意料之外的工作請求？
團隊凝聚力較強，團隊成員對於項目開發都很積極，都能夠有效的處理意料之外的工作請求。
我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
開發過程不可能永遠按照計劃來，臨時的需求都需要對計劃進行變更，這對團隊對於突發情況的控制和處理的要求較高。同時要求團隊成員有較強的凝聚力，遇到困難共同解決。
設計 / 實現
設計工作在什麽時候，由誰來完成的？是合適的時間，合適的人麽？
設計工作是在上一項功能完成之後，下一個功能實現前做的，只針對具體功能進行設計。
後端設計主要由PM劉斯盾完成，前端設計則由易子沐完成。
針對每一個功能進行設計，能細化設計內容，避免後期因為局部設計考慮不周而推翻重來的情況。關於設計角色的選擇，後端讓劉斯盾負責，是由於他的編碼能力比較強，前端讓易子沐負責，是由於他的審美比較靠譜。兩個選角都相當合適。設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
由於是階段性設計，每次設計的內容都很細致，所以沒有出現模棱兩可的情況。
團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麽？ 比較項目開始的 UML 文檔和現在的狀態有什麽區別？這些區別如何產生的？是否要更新 UML 文檔？
很遺憾，我們團隊沒有使用測試工具來幫助設計與實現。
什麽功能產生的Bug最多，為什麽？在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況?
前端的JS動態效果有一些bug，導致出現一些難以理解的動態效果。但這些問題都不影響正常使用。導致這些bug的根本原因還是我們對前端工程的理解程度還不夠，對工具的熟練運用程度還有待提高。
代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
很遺憾，我們沒有做代碼復審。
我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
由於用工程化方法去設計和實現是一件很繁瑣的事情，而且在短期內也看不到它的優勢，所以我們在項目開發工程中並沒有重視它。另一方面，我們的整體規劃與具體分工上出了問題，導致大家沒有強制的義務去接手工程化操作。因此，如果歷史能重來一遍，我們會把每個人的具體職能劃分清楚，而不是分配角色，將工作落實到個人，這樣大家就沒有理由去避免應該屬於自己的那份任務。
測試
團隊是否有一個測試計劃？為什麽沒有？
我們團隊的測試計劃大體分為兩個部分，一個部分是團隊成員完成當前任務編碼以後，對自己的代碼做自我測試，並且傳到本地服務器上進行驗證。另一部分是基本功能都實現之後，由測試人員對整合於服務器上做整體的功能、性能、兼容測試。
是否進行了正式的驗收測試？
進行了正式的測試，測試結果發布在beta階段的測試文檔上。
團隊是否有測試工具來幫助測試？
有測試工具，測試主要通過scrapy框架進行模擬訪問。通過scrapy模擬訪問搜索頁面（達到130人每秒），然後通過使用瀏覽器內置的網絡訪問插件觀測和記錄模擬訪問過程中和模擬訪問前的訪問時間變化。
團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用麽？應該有哪些改進？
這部分與alpha階段類似。
有關功能可用性和兼容性的測試主要通過在不同機型和不同運行環境下通過用戶的反饋進行測試。而網站穩定性的測試主要通過scrapy的框架對網站的主頁和數據查詢頁面進行模擬訪問進行，再通過瀏覽器自帶的網頁反應時間功能獲取結果。
但是測試的結果要比alpha階段好很多，顯著表現就是兼容性方面有了比較大的進步，出錯的幾率減小了。而且得到了穩定性方面依舊是一個比較大的問題，在130同時訪問的情況下，服務器的反應速度明顯降低。
應該部署效能更好的服務器，從而解決穩定性方面的缺陷。在發布的過程中發現了哪些意外問題？
1.預期部署的阿帕奇框架由於時間的原因沒有部署成功。
2.宣傳的效果不夠好。
3.穩定性方面還存在一些問題，難以完美支撐較多的用戶。我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
學到了測試方面的一些知識和提前做好風險評估的重要性。
改進：
1.提前確定一些框架的學習成本來選擇是否選擇這種框架。
2.在開發完成之前就應該制定好一些宣傳的方式，來更好的吸引用戶。
3.選擇更適合用戶實際數量的服務器部署方式。
團隊合照
beta階段事後分析