alpha衝刺-過後諸葛亮

做業要求

這個做業屬於哪一個課程	軟件工程1916-W(福州大學)
這個做業要求在哪裏	項目Alpha衝刺
團隊名稱	基於雲的勝利衝鋒隊
項目名稱	雲評：高校學生成績綜合評估及可視化分析平臺
這個做業的目標	alpha階段總結

團隊成員信息

隊員學號	隊員姓名	我的博客地址	備註
221500201	孫文慈	https://www.cnblogs.com/swc221500201/
131601207	陳序展	https://www.cnblogs.com/chenxuzhan/
221600414	馮凱	https://www.cnblogs.com/codingkai/	隊長
221600415	傅德泉	https://www.cnblogs.com/dqblog/
221600416	黃海山	https://www.cnblogs.com/hhs-blog/
221600417	黃樂興	https://www.cnblogs.com/hlxing/
221600439	<script>	https://www.cnblogs.com/aaaaaaaaaaaaaa/

設想和目標

• 咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

1.福州大學軟件工程實踐這門課程主要依託於博客園進行做業的線上發佈、提交等環節，但因爲博客園自身功能的限制，對於每次學生提交的博客及做業的成績和統計分析每每須要老師和助教經過在Excel表格上進行許多繁瑣且重複的操做才能完成，這種人工進行統計與分析的方式不只極大的佔用了助教和老師的時間，也致使同窗沒法直觀清晰的看到本身的成績與能力分析。咱們的軟件就是爲了解決在實踐教學中的這一痛點問題。
2.咱們軟件的定義是比較清楚的。
3.對於典型用戶和典型場景有較清晰的描述，咱們與該門課程的老師進行了屢次的交流，肯定了較爲明確的需求。

• 咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)

咱們alpha階段的目標是登陸、註冊、新建評分維度、新建班級、編輯班級、加入班級的對應功能，咱們完成了全部計劃的功能，按照原計劃交付時間交付了，原計劃並無計劃用戶數量。

• 和上一個階段相比，團隊軟件工程的質量提升了麼？ 在什麼地方有提升，具體提升了多少，如何衡量的？

和上一個階段相比，團隊軟件工程的質量提升了，主要是在於團隊成員之間互相合做的默契度提升以及任務的分配更爲合理，成員完成度更好。主要經過功能的完成度來衡量。

• 用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

由於咱們目前整個系統還未完成，所以用戶量還沒法統計。用戶對重要功能的接受程度和咱們事先的預想基本一致。咱們離目標更近了。

• 有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

咱們對於需求的分析不夠細緻，致使先後端在某些功能出現了不統一的現象。若是歷史重來一遍，咱們會更加細緻的分析咱們的需求。

計劃

• 是否有充足的時間來作計劃?

團隊相信好的計劃規劃，會避免中期走彎路，節省時間成本，因此安排了足夠的時間作計劃。

• 團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？

同事各抒己見，在小問題上尊重隊長和代碼能力較強同窗的想法。在大問題上，爲尊重每位同窗的意見，在詳細闡述想法後全員投票，票出決定。

• 你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

基本完成。

• 有沒有發現你作了一些過後看來不必或沒多大價值的事?

沒有。

• 是否每一項任務都有清楚定義和衡量的交付件?

是。

• 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

否，項目前端設計最先是讓一位同窗主要負責，可是成果並非很能讓人滿意，致使後面重構代碼。仍是沒有了解好隊員的能力，是否須要協做，不是獨自完成，過程也須要更多監督。

• 在計劃中有沒有留下緩衝區，緩衝區有做用麼?

通常在一天以內，當天完不成的任務，確保要在次日以內加班完成，不能拖過久，不然會影響總體的項目進度。

• 未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

未來的計劃應該可以按時或者提早完成，由於alpha階段咱們已經對後期的工做作了總體的部署規劃，部分beta階段的任務已經完成。

• 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

學到了提早規劃的重要性，在項目過程當中，須要及時跟進隊友手裏的工做，把關質量，而不是最後不行從新來過。

資源

• 咱們有足夠的資源來完成各項任務麼?

有，咱們的前端和後端開發同窗都有足夠的項目經驗和技術能力應對需求設計，項目開發和文檔編寫任務。

• 各項任務所需的時間和其餘資源是如何估計的，精度如何?

根據之前開發相似項目的經驗，估計目前各種任務的時間；通過估計時間和實際時間的比較，偏差精度在一天之內。

• 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?

測試的時間，人力和軟件/硬件資源基本足夠，由於咱們開發的同窗都有必定的項目經歷，對於前端和後端的開發框架比較熟悉，而且擁有阿里雲服務器部署項目，加上在五一假期時間有充足完成開發測試工做；對於不須要編程的資源沒有低估難度，由於這個課程對於這方面的要求較高，因此咱們團隊在這方面提供了足夠的重視，而且也花費了較多的時間。

• 你有沒有感到你作的事情可讓別人來作（更有效率）?

沒有，由於咱們各司其職，分工明確，在分配任務的時候充分考慮到了每一個人擅長的方面。

• 有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

在任務開始前總覺得有較多的時間來完成任務，結果形成了前期拖延，後期忙碌的現象；改進:嚴格按照計劃時間表來完成任務，不把今天的事情拖到明天作。

變動管理

• 每一個相關的員工都及時知道了變動的消息?

能夠。全部的變動消息均發佈在QQ羣之當中，而且都會進行口頭的傳遞。

• 咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

評估功能的實現成本以及重要性。儘可能實現項目中的關鍵性功能，對於一些實現難度大，花費時間超過課程結束時間的，暫時採起推遲。

• 項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

前端頁面美觀，用戶體驗良好；實現需求文檔中的功能，而且功能能有必定的可靠性和容錯性。

• 對於可能的變動是否能制定應急計劃?

能夠，小組每一個成員都有相對應的任務，遇到可能的變動，會進行必定的協調和組員商討，保證項目可以持續進行。

• 員工是否可以有效地處理意料以外的工做請求？

能夠。員工都比較認真負責，包容必定範圍的需求變動。

• 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

咱們提高了對變動請求的處理能力。若是再來一遍，咱們會多常常溝通交流，理解相互之間的難處，提高團隊的開發效率。

設計/實現

• 設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

1.原型設計在項目原型設計答辯前一週完成的，由負責前端的同窗完成的，是合適的時間，合適的人。
2.數據庫和系統設計在項目原型需求最終肯定以後完成的，由負責後端的同窗完成的，是合適的時間，合適的人。

• 設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

有些需求不是很明確，團隊跟「客戶」約了時間重現確認了需求。

• 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？ 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

團隊運用了junit進行單元測試，JProfile來進行性能分析，使用IDEA做爲集成開發環境。UML文檔和如今的大致上同樣，有些不同的部分後來已經有所更改。

• 什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

評分和做業模塊涉及的數據內容比較多，分散在多張表裏面，BUG比較多，在發佈以前已經修復。

• 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

使用eslint進行代碼質量控制，代碼總體架構和規範都有着嚴格的要求。

測試/發佈

• 團隊是否有一個測試計劃？爲何沒有？

團隊對項目的功能模塊作了集成測試，對每一個類作了單元測試。

• 是否進行了正式的驗收測試？

alpha階段的功能進行了測試，正式的驗收測試將在項目完成以後進行。

• 團隊是否有測試工具來幫助測試？

使用postman進行接口測試.

• 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？

十分有用，能夠在開發過程當中查找不足，及時作相關的修改優化。

• 在發佈的過程當中發現了哪些意外問題？

生產環境和開發環境的配置差別，使得項目在部署的時候存在配置問題，沒法啓動web服務器，以後修復了BUG並順利發佈。

• 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

1+1>2，團隊總體的力量不僅是每一個人能力的累加，團隊成員之間密切的配合可使得整個項目的開發進度大大加快。若是歷史重來，咱們團隊可能會在前期需求方面作更加細緻的調研。

團隊的角色，管理，合做

• 團隊的每一個角色是如何肯定的，是否是人盡其才？

根據每一個成員擅長的技能和我的意願進行分配，每一個成員都獲得了滿意的崗位。

• 團隊成員之間有互相幫助麼？

成員之間互幫互助，有不懂的地方，你們都會熱心的去幫助解決。

• 當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

開會討論產生解決辦法。

總結

• 你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

可重複級(Repeatable)檔次。

• 你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?

創造階段

• 你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

你們配合更加默契，項目開發逐漸走上正軌。

• 你以爲目前最須要改進的一個方面是什麼?

項目總體實現細節有待優化。

• 其它軟件工具的應用，應該如何提升？

邊學邊用，在實踐中掌握。

• 項目文檔的質量如何提升？

團隊總體強制使用同一的規範進行約束，後期再進行文檔複審。

感謝環節

• 陳序展：感謝fk同窗對個人幫助，由於我是初次接觸Vue框架，學習和使用過程當中遇到一些問題，馮凱同窗每次都會熱心地幫我解決問題。

• 馮凱：感謝團隊的每一位成員，你們在項目合做期間都各司其職，認真對待本身負責的任務，期間你們都很配合其餘人的工做，爲項目的順利開發打下了基礎，但願你們可以再接再礪。

• 黃海山：感謝fk同窗天天爲咱們提供詳細的任務需求，使得開發任務清晰明確，效率高。天天都會認真地整理咱們彙總的博客資料，還會耐心地指出其中的不足，提供修改建議。

• 黃樂興：感謝codingKai對個人幫助。在此次項目中，組長規劃了每一個組員的工做，並定下了一個又一個的DDL，讓我能有必定的壓迫感，更加高效地去編寫程序。當我遇到困難後，組長也會耐心地引導我，爲我提供必定的幫助。

交換組員的工做交接和培訓方案

工做交接：

• 新來的成員在以前的團隊中負責的部分和本團隊「離職」的成員在業務上基本一致，所以web端的基本功仍是有的，只須要對vue框架的使用和團隊的代碼規範作進一步要求和學習便可。

培養計劃

• 學習vue框架的使用和組件化開發
• 熟悉項目的接口的對接
• 對項目的代碼規範作要求，保證新編寫的代碼徹底符合本團隊的代碼規範
• 對界面的總體樣式作統一要求，保證新開發的界面的樣式和原來的樣式基本一致

alpha階段總結開會照片