Alpha階段項目展示

團隊成員簡介

團隊成員	角色	個人部落格位址
劉峻辰	後端開發
焦雲鵬
趙智源	測試&伺服器部署
肖萌威	前端開發
楊亦鑫
羅奧升	PM

産品網頁連結

團隊項目的目标，預期的典型使用者，預期的功能描述，預期的使用者數量在哪裡？

團隊項目目标

在Alpha階段展示的時候，有200使用者量，每日40活躍量。

團隊預期典型使用者

學生類型	使用本産品目的	使用場景
重修某課程學生	重修某課隻想及格	查詢評論，了解課程通過率
學霸	想知道選哪個教師更能學到更多的知識	檢視往年的評價，了解課程要求以及教師的情況
隻想刷GPA的學生	為了有更高的GPA	查詢評價，了解課程給分情況
隻想混學分的學生	為了通過課程	查詢評價，了解課程難度和通過率

教師類型
授課教師	了解同學們對課程的真實評價	檢視評論，了解學生意見
教學品質把控人員	把控教學品質	查詢曆年評價，了解不同課程的學生反映情況以及課程發展狀況

團隊預期功能描述

系統功能	驗收标準
注冊功能	填寫使用者資訊之後注冊完成，同一個郵箱隻能注冊一個賬号
登入功能	正确填寫使用者名和密碼登入成功，否則彈窗提醒密碼錯誤。解決密碼明文儲存的問題
搜尋功能	實作關鍵字搜尋，可以依據使用者輸入的關鍵字搜尋出相應課程
課程資訊	顯示所有的課程資訊
評價顯示	分頁儲存評論資訊，一頁顯示五條評論，顯示評論人的頭像以及ID
評價功能	能夠正常送出評論，評論字數限制為200，不支援匿名評論，隻支援中文

目前使用者數量

目前的使用者數量是我們從Django背景查詢得到的。

事先定義的軟體下載下傳量達到了麼？為什麼沒有達到？

網站的unique visitor數目為728(截止2019.4.25早上10點)。如下圖所示:

網站的注冊使用者還差大概50人達到預期的200人，主要還是推廣這方面我們團隊的所有成員都沒有經驗，目前還僅僅是通過在北航相關的群裡宣傳，但是效果并不理想。

與此同時，在4月22号晚上伺服器遭受攻擊，資料庫回檔，是以損失了不少已經注冊過的使用者和部分潛在使用者。

網站被攻擊記錄

還有一個原因在于除了評分、評價和登入之外所有的功能都不需要注冊，是以注冊使用者較少而通路量不小。

團隊的成員如何分工協作的？有什麼經驗教訓？

分工協作

整個團隊分為四個小團體。分别是：前端開發，後端開發，測試&伺服器部署以及PM。

前端開發的負責人是肖萌威，後端開發的負責人是劉峻辰，測試團體的負責人是趙智源，項目經理是羅奧升。

在Alpha階段，我們主要是采用了石墨文檔來釋出任務，管理團隊的任務進度以及成員貢獻。

經驗教訓

在整個Alpha階段，從項目經理的角度來看，整個小組的工作進行地還算有條不紊。

雖然我們在正式進行工作之前有預估過完成某項工作的時間以及難易程度，但是并沒有确定好每個工作的優先級。

在團隊的溝通與交流上，我們做的蠻不錯，大家各司其職。不過也出現了因為個人原因導緻項目的延期，這和PM的通知不到位有關。

在beta階段，我們的主要改進的地方在于首先要确定好每個工作的優先級，同時要完善我們的團隊成員，尤其是美工，最後還需要再次規範整個團隊的風格和設計文檔，以便于測試和維護。

團隊是如何進行項目管理的？

Alpha階段主要是采用了石墨文檔進行管理，連結如右所示：項目管理。

團隊在正式動工之前，首先确定了我們要完成的最核心的部分，即核心功能：評價功能。由此延伸到了注冊登入，查詢課程，課程評分等等其他的功能。

前後端開發成員依據這些需要完成的功能，分别在石墨文檔上确定了自己的工作任務、預估完成時間、任務難度以及接口規範等等。

測試成員依據石墨文檔，編寫相應的測試樣例，最終将測試結果回報給前後端的成員。

PM則依據難度，修改BUG所需要的時間即任務完成度，以及完成任務的時間等資訊來評判每個人的工作情況和團隊貢獻。

團隊如何平衡 時間/品質/資源 争取如期完成任務的？

在配置設定工作小組之前，我們首先了解了每個成員的能力水準和工作意願，然後配置設定到各自的工作小組内。

為了確定完成進度，我們在配置設定任務之前，預估了每個任務的難度以及完成時間，遵循“能者多勞”，“多勞多得”的原則，将難度和學習成本較高的任務分給了實力更加強勁的同學。

為了防止摸魚劃水情況的出現,團隊制定了針對因個人原因而未能及時完成任務的懲罰措施。

為了確定完成品質，我們在文檔上規範了接口格式，代碼風格，命名風格，重新設計了網站架構，前後端完全分離。

以上其實都是次要的，主要還是大家的熱情都比較高漲，積極主動地去交流，團隊才能如期完成任務。

有些項目是在原來的基礎上改進的，那麼我們團隊的軟體工程項目品質有什麼樣的提高？例如，代碼覆寫率從原來的x增長到y？

• 增加代碼注釋 代碼注釋從原來項目的基本沒有提升到現在的20%左右，同時保證大部分函數都有函數行為注釋。部分函數如驗證請求等出于安全原因沒有注釋。
• 完善代碼規範 我們以PEP-8規範為基礎建立了自己的代碼規範。例如我們的命名遵循模型單詞首字母全大寫，連結camelcase，函數使用下劃線分割。同時在完成代碼編寫後，使用Pycharm的格式化功能格式化代碼，修正換行等問題。
• 建立高效交流 我們除了使用issue外，還充分利用微信群，石墨文檔進行交流。同時我們明确了bug的最長響應時間，確定每個bug都有人快速修複。後端還在石墨文檔上建立了接口速查表，幫助前端快速了解接口變更，幫助測試提高測試覆寫率。

在産品之外，團隊代碼的軟體工程品質如何？如何用資料來證明？

測試用例數目，代碼覆寫率數目

齊全的文檔在哪裡？

前端設計文檔

後端接口文檔

測試報告

部署文檔

測試文檔

原來的項目有些代碼混亂，沒有注釋，沒有詳細的文檔，你們的項目是如何更好解決這個問題的？明年的同學繼續開發這個項目，會不會出現類似的抱怨？如果一個新學生在一台新機器上想編譯并運作你的項目， 請問能順利完成麼？有什麼樣的文檔能指導新學生？

項目齊全的文檔，注釋，代碼規範以上都有提到，此處便不再贅述.

明年的同學應該不會出現這種抱怨。

在Alpha階段釋出說明部落格和部署文檔中，有談及如何編譯運作我們項目的問題，按照步驟來即可順利完成。

對于項目的目标使用者是一般學生的項目， 你們如何找到學生做需求分析？他們給你什麼樣的回報？

我們利用了手裡的班級群資源，分别在大三，大二，大一的班級群中找到了部分熱心的學生做需求分析。

大一的學生因為未曾分專業，并且他們可自己選擇課程很少，是以回報較少。

大二，大三的學生則更多地希望評價真實，能夠提供有效的資訊。

所有的項目都會收集到使用者的資料，請問你們對這類資料做了什麼樣的分析，這些分析如何驗證或推翻了原來的假設？這些資料如何幫助項目改進軟體工程的品質？

該部分由于Alpha階段目前的使用者和評論數較少，是以還沒有辦法對資料進行分析。

不過目前我們有以下的想法：

• 依據不同使用者針對某課程的評論資訊，評論時間，擷取某課程的評論趨勢

• 依據所有課程的評分和評價資訊，擷取各個評分檔課程的分布和趨勢

• 依據某個教授的所有課程的評分和評價資訊，擷取這個教授的好評度

團隊項目的實際進展（拷貝那些 scrum 過程中的燃盡圖即可），釋出的功能（拷貝釋出文檔），在哪裡釋出了軟體（3 – 10 個網址）， 使用者回報的截屏。說明在項目管理中，scrum的燃盡圖是如何真實反映項目的狀态的？或者燃盡圖美化了狀态？

燃燼圖

燃燼圖如上所示，燃燼圖能很好地反應項目所有任務的每天的完成狀況，對項目管理十分友善。

釋出功能

釋出的功能在Alpha階段釋出說明可見。

軟體釋出地

由于我們的産品是網站，是以并沒有釋出地之說。

使用者回報的截屏

團隊成員在Alpha階段的角色和具體貢獻

		團隊貢獻分
		53
		52
		54
		47
		50

其中，趙智源寫了測試報告部落格，劉峻辰寫了釋出部落格，highcharts繪制美觀燃燼圖部落格，網站被攻擊記錄部落格，肖萌威幫助寫了網站被攻擊記錄部落格，其餘的部落格均由PM完成。

前端設計文檔由肖萌威、楊亦鑫共同完成，測試報告由趙智源完成，後端接口文檔由劉峻辰、焦雲鵬共同完成。

PM羅奧升則完成了4次群推廣，處理了10個使用者的回報。

具體工作和評分在項目管理中有詳細記錄。

測試所發現的BUG數目，覆寫率，在測試報告和測試文檔中有詳細記錄。

團隊從使用者那裡得到了什麼回報，有什麼樣的bug？這是預料之中的還是沒想到的？

使用者回報的情況中，出現了一個讓我們始料未及的BUG，那就是使用者名為中文時，使用該使用者名登入會報錯。

總結，整個團隊在Alpha階段學到了什麼，對軟體工程的教育，對這個具體的課程有什麼批評建議？Beta階段有什麼計劃？

整個團隊在Alpha階段主要體驗了軟體開發團隊在做完一個産品的一個版本的整個流程。前端，後端以及測試有相應的技術提升以及溝通能力的提升。而作為PM的我則學到了更多的管理經驗，如何去統籌協調整個團隊，盡可能調動每個成員的積極性。

我們希望這門課程能夠讓學生更多的自由，主要是讓學生選擇自己友善的管理團隊的方式，我們團隊曾因為想用石墨文檔而不用issues與助教争論許久。

beta階段的主要計劃是首先确定好每個任務的優先級，然後在已有版本的基礎上增加新的功能，具體也可以在我們的項目管理上見到。