過後分析$\alpha$

時間 2020-05-09

標籤過後分析 alpha 简体版

原文原文鏈接

項目	內容
課程：北航-2020-春-軟件工程	博客園班級博客
要求	過後分析
咱們在這個課程的目標是	提高團隊管理及合做能力，開發一項滿意的工程項目
這個做業在哪一個具體方面幫助咱們實現目標	組織組員對$\alpha$階段的任務進行總結，對過去進行反思

VisualPytorch發佈域名+雙服務器以下：
http://nag.visualpytorch.top/static/ (對應114.115.148.27)
http://visualpytorch.top/static/ (對應39.97.209.22)javascript

過後分析會圖：html

1、設想和目標

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

在定義需求時，咱們要解決的，是剛入門深度學習的初學者，缺少一個良好、方便、直觀的學習途徑的問題。咱們的目標，則是經過提供一個圖形化的在線平臺，用戶能夠經過拖拽的方法連成網絡，或者使用咱們提供的經典模型，自動生成程序，而且教初學者本地部署模型，加載數據並進行訓練。java

整體而言，咱們對典型用戶和典型場景的定義描述仍是比較清晰的。具體的描述在團隊項目選擇與功能規格說明書中。python
咱們達到目標了麼（原計劃的功能作到了幾個？按照原計劃交付時間交付了麼？原計劃達到的用戶數量達到了麼?)linux

在擴展模型的功能上，咱們成功實現了對網絡層的擴展，而且實現了模型保存的與預覽的功能，還對界面進行了比較完全的優化。不過，仍是有一些功能上的目標沒有完成，好比網絡封裝成基本模塊的功能，因爲前端jsplumb版本的限制沒有實現，不事後端以及json接口定義都已準備好，計劃於$\beta$階段實現此功能。另外，經典模型也已經搭建完成，現保存在超級帳號中，計劃於$\beta$版本中實現對全部帳號的開放。nginx

項目最終成功地按照原計劃交付時間進行了交付，這歸功於任務劃分的科學性與咱們組各個成員的我的積極性和良好的團隊合做。git

項目最終並無達到原計劃的用戶數量100人，僅僅達到了目標的三分之二。一方面，可能因爲咱們的項目正如一些同窗的反饋所言，不是那麼吸引人；另外一方面，咱們的宣傳渠道並不普遍，只是在計算機學院的大羣「SCSE1706菜市場」和軟件工程的課程羣進行了宣傳。以「過後諸葛亮」的方式思考的話，多是在咱們6系中，對深度學習和pytorch有較深瞭解的學生，不太會對咱們這樣主要面向初學者的項目感興趣；而對深度學習興趣不大的人，則不太關注咱們的項目（固然也有可能只是都不愛看羣罷了）。github

總的來看，咱們仍是基本達成了目標的主要部分，但還有一些本來打算實現的目標被放棄或者沒有達到。正則表達式
和上一個階段相比，團隊軟件工程的質量提升了麼？在什麼地方有提升，具體提升了多少，如何衡量的？

項目目前處於$\alpha$階段，咱們也不是很清楚上一屆團隊工程化方法的執行狀況，僅僅是看他們的博客，很差作一個比較。不過，就我的猜想而言，咱們的軟件工程質量應該仍是和上一屆有差距的，作這個判斷的依據就是今年的新冠疫情。因爲疫情緣由，在整個開發階段，團隊都只能使用在線會議軟件這種比較低效的方式來進行Scrum Meeting，衝刺階段更是連找張桌子圍在一塊兒開發的機會都沒有（雖然因爲計劃比較合理，咱們也沒太進行趕進度的衝刺），在很大程度上影響了一些工程化方法的實施。這個影響應該說在以前的結對項目中就已經能夠感受出來了。等到了$\beta$階段，咱們但願至少可以以本身爲參照，在軟件工程的質量上獲得提升。雖然開會的方面沒辦法提高了，但能夠在其餘方面有所提升，例如目標的設置、計劃的制訂等等。
用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

雖然用戶量並無達到預想的水平，但就反饋來看，用戶對重要功能的接受程度仍是達到了咱們的預期的。所以，能夠說咱們確實是離目標更近了。
有什麼經驗教訓? 若是歷史重來一遍，咱們會作什麼改進?

假如重來一遍，咱們能夠考慮及時更改前端插件，完成更多的計劃功能。另外的話，會考慮加快一下總體進度，同時優化分工，爭取完成更多內容。

2、計劃

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

計劃階段時間比較充足，也開了數次網絡會議進行討論。
團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？

其實總的來講，對於計劃的意見都比較明確，並且因爲分工比較早並且重疊的部分很少，即便有改進，也基本上是在本身的分工內進行的改進，意見的衝突並很少。若是遇到這種問題，通常都是在開會時就予以解決，經過討論來儘可能達成一致，最終的決定權在PM手上。
你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

除了前面提到的內容之外都作完了。沒作完的緣由也提到了，主要仍是卡在了前端插件上。
有沒有發現你作了一些過後看來不必或沒多大價值的事?

暫時沒有。就目前來看，即便在如今的版本中沒有利用上的代碼和接口定義，也是爲$\beta$版本的開發作準備的。至於這些代碼之後會發揮多大的做用，要在下一個版本中進行驗證。
是否每一項任務都有清楚定義和衡量的交付件?

除了一些學習性質的任務外，都有比較清楚的定義和衡量的交付件，通常都是實現網頁的某項改進/某個功能，前端和後端都是如此。
是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

項目的整個過程基本是按照計劃進行的，但也出現了一些意外，好比先後端之間可能由於溝通不夠，已經對git運用不熟練致使代碼版本控制不當，出現接口對接不上的問題，使得某些功能沒法正常工做，例如加載已保存模型。不過這種開發人員內部問題帶來的風險並不算大，由於很快能夠經過及時溝通和debug來解決。從去年學長的對Visual Pytorch的開發經從來看，開發中有可能遭遇到更嚴重的問題，包括但不限於服務器被黑掉。這樣的風險在接下來的開發中務必要重視，並採起備份等方法予以防範。
在計劃中有沒有留下緩衝區，緩衝區有做用麼?

在計劃中基本沒留下緩衝區，不過計劃總體而言時間劃分仍是比較充裕和寬鬆的，不太存在計劃在規定時間內沒法完成的狀況。
未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

未來的計劃中，可能會涉及到更爲複雜的開發內容，從這個角度考慮，應該設置必定的緩衝區，而且儘可能細化項目的時間指標，好比設置指望完成時間和最晚完成時間。至於加班的問題，就須要確保在遇到問題時，先後端至少各有一人能及時進行反饋。
咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

在計劃部分，咱們學到了如何將一項大的工程拆分紅小的開發項目進行敏捷開發。若是歷史重來一遍，咱們會讓每一個開發項目的要求變得更爲細緻，儘量天天都能完成至少一個小項目。

3、資源

咱們有足夠的資源來完成各項任務麼?
已有資源：靜態資源與服務器咱們都已經拿到；有兩個星期的開發時間。
不足資源：時間不太夠用，使得完成的功能不能達到預期的需求；1核1G服務器的配置不太夠用，許多期待完成的功能（如在線運行代碼）不能完成；同時中途兩位同窗參與度不高也成爲了咱們缺少人手的窘況。
各項任務所需的時間和其餘資源是如何估計的，精度如何?
估計是按照咱們之前的開發經驗。作這樣的估計實際上是存在較大誤差的，由於具體解決問題的時間包含了學習新知識，一邊學習一邊開發很難在一開始就明確估計到所須要的時間。
測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?
資源是足夠的。咱們自己就很是重視美工與設計，知道這是很重要很費時的一部分，因此不存在低估。
你有沒有感到你作的事情可讓別人來作（更有效率）?有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?
咱們作事情都是分工來作的，在具體操做過程當中，分工的問題就存在比較模糊的界限。咱們最終商議仍是會根據對所作模塊的專業性來進行分工。咱們前段時間遇到了一個具體的問題：前端的表單須要校驗，可是咱們不知道須要向後端傳送怎樣的數據。校驗問題原本是前端來作，可是咱們要求後端提供具體的正則表達式來幫助前端進行校驗，這就是一個專業的人作專業的事較好的例子。

4、變動管理

不存在人員上的變動，僅有工做內容的變動。

每一個相關的員工都及時知道了變動的消息?
暫無變動。因爲你們基本上每兩天就又一次會議，小道消息傳播得比較快。
咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?
在羣裏討論技術細節和時間，若是條件容許就作，不容許就不作。好比「支持網絡層封裝」的功能由於時間不容許就推遲了。
項目的出口條件（Exit Criteria）是否獲得清晰的定義?
功能都完成了就算出口了。可是說實在的，在這個項目裏面咱們沒有用到太多。
對於可能的變動是否能制定應急計劃?
基本沒有，大多時候由PM單獨找人或本身完成應急工做。
員工是否可以有效地處理意料以外的工做請求？
能。規定全部請求都轉到PM那裏處理，這樣減輕了開發人員的壓力，讓他們能集中精力在本身那一畝三分地上。

5、設計/實現

設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？
整體設計工做是由PM在第一次scrum meeting前完成。PM監督整個設計階段並最瞭解需求，因此是合適的時間和合適的人。
設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？
遇到過，例如先後端對於接口文檔的認識分歧致使寫法不統一，解決方法是在對接時相互協商解決。
團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？
在設計階段咱們畫了網站的視覺圖來幫助前端設計，後端部分在編寫代碼生成函數時運用了單元測試驗證代碼的有效性，並使用了python的coverage庫進行代碼覆蓋率檢查，其餘使用的工具包括github等，這些工具備效的加快了團隊開發的速度。
什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?
前端畫布部分存在較多BUG。緣由是前端參數和網絡層模塊很是多，而且對大小寫和內容格式有嚴格要求，在閱讀設計文檔時容易看錯併產生編寫錯誤。同時在圖像展現方面與文字有時難以兼容，出現了較多顯示BUG。
代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
代碼複審主要由每一個模塊負責的同窗本身進行，整體而言不太嚴格，須要在下一階段增長相應制度保證工程質量。
咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
應由測試引導項目的開發，而且設計應該更加清晰明確。若是重來一遍，咱們會花更多時間完善設計文檔，而且在項目開發時編寫更多測試用例。

6、測試/發佈

團隊是否有一個測試計劃？爲何沒有？
有，每一個團隊成員對本身負責的代碼進行單元測試，並模仿真實用戶使用網站功能進行測試。
是否進行了正式的驗收測試？
沒有一個整體的驗收測試，主要由各自分別進行。緣由是你們經驗不夠豐富，須要在下一階段完善此方面。
團隊是否有測試工具來幫助測試？
使用了coverage、unittest和pycharm、spyder自帶的測試工具幫助測試。
團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？
每一個開發人員經過使用網站對最終成品進行黑盒測試，測試結果直接反映了實際運行結果，同時先後端分別進行單元測試和代碼覆蓋率檢查。這些測試工做有效消除了工程中的大量BUG。能夠經過增長單元測試案例以及先後端交互測試等內容進一步豐富測試過程。
在發佈的過程當中發現了哪些意外問題？
服務器部署過程仍是挺費事的，與本地運行不一樣，在服務器上部署須要比較熟悉linux，而且學習nginx、uwsgi的交互方式。兩位組員在去年之外學長的幫助下花了2天完成了部署工做。部署過程當中還發現了意想不到的bug，如頁面跳轉出錯。

發佈到同窗羣中時，發現紅包被搶得差很少了，可是網站的訪問量和使用狀況增加不大，這仍是對咱們沉重的打擊。

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

學習到了各種測試工具的使用方法以及測試案例的編寫。若是重來一遍，咱們會把測試作得更充分，並制定一個更加完善的測試計劃。

7、團隊的角色，管理，合做

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

首先將隊員按意願分爲前端和後端兩類，對於界面、javascript比較熟悉的去了前端，對於python或者pytorch比較熟悉的人去了後端。

在前端和後端都發布了任務的拆解，基本上是按意願去認領對應的工做的，認領和分配的工做都是各自擅長的一塊。所以很大程度上都能發揮各自的特長，能夠說作到了人盡其才。
團隊成員之間有互相幫助麼？

有。由於有些工做一我的作起來比較耗時耗力，而且兩我的一塊兒作時會考慮得更加全面。所以在許多任務上，尤爲和集成、部署相關的任務，均爲多人協做完成，在任務過程當中相似於結隊項目同樣緊密交流。
當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

出現項目及合做的矛盾和衝突時，交由PM對問題進行協調。在會議上組織討論相關問題的解決方法，並安排具體到人去解決相關問題。

8、總結

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

處於可重複級。創建了基本的管理制度和規程，管理工做有章可循。初步實現標準化，開發工做比較好地按標準實施。變動依法進行，作到基線化，穩定可跟蹤，新項目的計劃和管理基於過去的實踐經驗，具備重複之前成功項目的環境和條件。
你以爲團隊目前處於萌芽/磨合/規範/創造階段的哪個階段?

處於磨合與規範之間，小組經過alpha階段的磨合正逐步朝規範化前進。
你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

在規範化管理代碼與分工上有着不錯的提高。
你以爲目前最須要改進的一個方面是什麼?

對於Github與Git的一些功能使用還有不足之處，代碼簽入流程也有值得改進的地方，尤爲是測試部分。
對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。
- 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該可以保持一個長期的、恆定的開發速度。
- 團隊天天都會有新的代碼簽入，在學習階段結束後，保持了快速穩定的開發速度。
- 團隊定時總結如何提升效率, 並付諸行動。
- 每週三週五週日均有團隊會議，對開發進行總結與展望。

下一階段應該如何提升軟件工程的質量

代碼管理的質量具體應該如何提升？代碼複審和代碼規範的質量應該如何提升？
代碼管理將延續現有體系，但在審覈上須要更爲嚴格。
alpha階段有屢次因對git操做不熟悉而致使衝突的狀況。在撰寫了相應文檔的前提下，這種錯誤的出現是不該當的。
因爲開發人數相對其餘組較少，且不能面對面工做，所以複審只能靠我的進行。代碼規範方面，則繼續遵循相應文檔便可。
整個程序的架構如何具體提升？如何經過重構等方法提升質量，如何衡量質量的提升？
經過重構的方法來提升工程質量，是一種不得已而爲之的方式，耗時耗力，還會大幅度地延緩項目進度。局部的重構是能夠接受的，但項目總體的框架，是一開始就設計好的。
其它軟件工具的應用，應該如何提升？
目前使用pycharm/sublime/postman/spyder/coverage/unittest等工具，足以支持開發。beta階段的開發任務應該也能被這些工具cover。
項目管理有哪些具體的提升？
此前issue並無實際投入使用，beta階段會嚴格安裝issue拆解執行。
項目跟蹤用戶數據方面，計劃要提升什麼地方？例如大家是如何知道每日/周活躍用戶等數據的？
經過專門的前端頁面讀取後端數據信息。暫時沒有須要提升的地方。
項目文檔的質量如何提升？

現有的文檔已經較爲詳細，詳見項目展現——文檔與規範。下一階段可能會根據迭代的功能進一步細化文檔。

對於人的領導和管理，有什麼具體能夠改進的地方？請看《構建之法》關於PM、績效考覈的章節，或者《人件》等參考書
事實上做爲PM並無太多的權力，反而有太多須要承擔的責任，使得任務量過重：

本組7人中有一名同窗4月下旬纔拿到電腦參與實際開發，另外一名同窗則從第一次會議後渺無聲息
使得人手不足不少任務不能按照預期要求開發。許多任務都交由PM手上
爲了與那兩位同窗交流，PM也花費了較大的時間成本去與兩位同窗交流
要說這是PM的過錯也不太合理，更多的是兩位同窗我的的緣由

對於軟件工程的理論，規律有什麼心得體會或不一樣意見？（期中做業見我的博客）

心得體會見項目展現——每人總結

對比敏捷的原則，你以爲大家小組作得最好的是什麼？

儘早並持續地交付有價值的軟件以知足客戶的要求
項目早期交付的版本只實現了主體的功能和一些簡單的輔助版本，保證項目儘早、如期的上線。咱們提供了客戶評論和反饋區，能夠實時有效地收到用戶的意見，而後根據原定計劃結合客戶的意見修改項目，持續地交付有價值的軟件。
敏感流程歡迎需求的變化，並利用這種變化來提升客戶的競爭優點
結合收到的用戶的反饋來修改項目，能夠更好地掌握客戶當前的需求是什麼，根據用戶的需求來改進項目，當需求發生變化時，也能夠項目及時改進來跟上用戶需求的改變
常常發佈可用的軟件，發佈間隔能夠從幾周到幾個月，能短則短
項目在發佈以後，會按期根據客戶的反饋增長相應輔助功能以及修復客戶使用時出現的一些bug，保證按期不間斷更新，保證用戶的體驗。
可用的軟件是衡量項目進展的主要指標
咱們組首先實現項目的主體功能，在內部自測經過以後保證主體功能沒有bug以後，當即發佈上線，在後續，按照原先的計劃結合客戶的反饋不斷更新，保證了項目進展如期有條不紊地推動。
不管團隊內外，面對面的交流始終是最有效的溝通方式
因爲處於疫情期間，面對面交流很困難。咱們的團隊每週按期三次在騰訊會議上開線上會議，這樣的形式可能效果不如面對面交流，但咱們認爲這是疫情期間最好的會議交流形式。
以有進取心的人爲項目核心，充分支持信任他們
很少說了，pm牛逼，前端牛逼，後端牛逼。
只有能自我管理的團隊才能創造優秀的架構、需求和設計
咱們組內採用明確的評分機制，每人天天都要填寫當天的工做進度，根據每一個人的工做量以及工做的完成質量，用預先組內共同商定的計算算法計算每人的得分，保證了組員有勞有得，只有公平的分數分配才能激勵成員更好的完成工做