M2過後總結

照片

 

 

設想和目標

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

"北航"Clubs旨在於解決北航校內社團管理與學生參與社團活動的困難的問題，經過構建一個校內社團發佈活動or資訊的平臺，使學生能夠經過網站獲取社團活動信息，使社團能夠經過後臺管理活動，羣發通知。

典型用戶和典型場景在以前的Alpha階段產品功能說明書以及Beta階段開發目標中有說明；但典型場景的分析在beta階段作的不太詳細。

是否有充足的時間作計劃？

有，在M1以前就已經完成了很大一部分的項目產品設計、項目計劃與項目設計。而由於種種因素，M1未能實現當時的所有計劃，因此有不少留在M2繼續完成。而在M2開始以前，PM也已經根據實際進度、時間以及最新的需求作好了規劃。

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

與M1計劃階段不一樣，隨着項目的深刻，成員們對項目需求的瞭解也不斷加深，逐漸有了本身的對項目規劃的見解。因此在M2的設計中，PM與成員間的溝通討論更加多，不少計劃都是共同制定出來的。

相對於M1的改進

M1的設想和目標有些太過籠統，並且忽視了時間因素；

M2中的設想目標更加切合實際，也更加靈活

若是歷史重來一遍, 咱們會作什麼改進

對新階段的典型場景從新進行細緻分析

   

   

計劃

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

用戶以及社團的修改頭像、修改密碼這兩項功能未實現。

未完成主要是由於開發時間過於緊張，外加這兩項功能並非核心需求，因此就選擇了捨棄。

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

有。

後端：一開始計劃用leancloud實現消息實時推送，因此初期花費了大量時間學習，還發布了一些文檔。但中期通過商討消息實時推送難度太大，同時不太適合PC端且徹底能夠由更簡單的刷新界面操做代替，因此初期的學習leanclound顯得十分多餘、佔用時間。

前端：初期學習的react vue.js到開發階段也並未用到，但佔用了時間成本

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

定義：全部任務都以TFS任務的形式規範。全部人都是根據實際進度狀況實時建立任務、更改任務狀態，以便讓TFS任務直觀真實體現當前成員工做量與進度

衡量：要求天天在進行彙報時要有簽入記錄做爲衡量當日工做量的依據，簽入記錄能夠是代碼簽入或者文檔簽入

4. 是否項目的整個過程都按照計劃進行，有什麼風險是當時沒有估計到的，爲何沒有估計到?

　　前期較爲順利，後期則偏離計劃較多。主要緣由就是後期其餘課程（數學建模、編譯、數據庫理論考試+實驗課設）對軟工開發時間的巨大擠壓。其實一開始是考慮到這些風險的，但對風險的影響顯然是估計不足的。在其餘課程的衝擊下，有一段時間，軟工開發幾乎處於停滯狀態。

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

由於預料到後期其餘課程會佔用大量時間，M2計劃階段預留了緩衝區。雖然仍然沒能避免一些熬夜衝刺，但對總體項目的最終順利完成仍是有一些做用的。

相對於M1的改進

1. 對任務的定義和衡量有了更健全的機制
2. 預留了緩衝區

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

1. 將計劃作的更加細緻全面一些，減小無效任務的產生，避免作沒有價值的事，讓開發更加有效率
2. 計劃時考慮更多的外界干擾因素，綜合規劃

   

 

設計/實現計劃

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

　　設計在M1結束後就開始進行，主題由PM江昊完成，但此次整個團隊都參與討論了計劃的產生，而且在後期也經過每日例會一塊兒不斷調整。

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

      無

團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？

      設計：團隊借用E-R圖來對後端Model層設計進行建模處理，有效的推進了後端數據庫的創建與後端dev對項目的認識。

      實現：M2繼續借用API文檔來規範先後端接口，實現先後端交互。有效的下降了先後端工做的耦合性，提高了項目效率。

繼續沿用M1的單元測試

同時，M2開始用GIT管理代碼，開發效率提升，發生錯誤的概率也下降

什麼功能產生的Bug最多，爲何？

      前端 社團後臺界面。

      緣由：界面元素較多，而且功能較複雜，前端技術細節本就難處理，因此實現時遇到了不少BUG和困難。

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

      很遺憾，同M1同樣，由於時間緣由，後端雖進行了代碼複審，但並無一套嚴格的流程，只是後端dev之間口頭交流，粗略審查。

      代碼規範方面初期執行的較好，後期由於進度緣由不理想。 

相對於M1的改進

1. 計劃的修改經過每日例會進行，更加靈活，更多人蔘與
2. 用GIT管理代碼
3. 更加劇視前端

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

1. 規劃好代碼複審機制，開發時嚴格執行
2. 測試能夠應用更多的工具來提升效率，目前只是單元測試和fiddler

   

 

資源

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

　　M2最稀缺的就是時間資源，嚴重不足。 而其餘資源則較爲充足，並且比較M1來講，學習應用GIT提供的管理資源對咱們的項目有很大的幫助。

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

　　同M1同樣作的不夠理想，估計時間主要是經過PM來估計的，因爲PM對一些技術細節以及外界因素瞭解得並很少，所以精度比較低。

用戶測試的時間，人力和軟件/硬件資源是否足夠？

　　前端沒有作專門測試，然後端花去了約三分之一的時間進行測試，人力、軟件、硬件資源都足夠。

你有沒有感到你作的事情讓別人來作更有效率？

咱們的分工比較明確，你們完成得都較好，不適宜更換任務。

相對於M1的改進

GIT的介入提高了效率

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

 1. 重視時間的估計，考慮多重因素的影響，綜合規劃整個項目。時間會影響到成敗。

 2. 每週的開會更細緻一點，對可能發生的意外狀況提早進行預估。

   

 

變動管理

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

有了GIT，代碼的更新能夠直觀的看到，可以及時知道變動的消息。

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

      同M1同樣，主要經過每日例會以及平時開發過程當中成員與PM之間的面對面交流來決定。會根據咱們項目的具體狀況，選擇處於當前核心需求的功能來進行實現；而對於那些可有可無或者實現難度過於大的功能會考慮予以捨棄。

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

      咱們本階段的目標就是實現web端的社團綜合管理平臺，因此"作好了"的直接效果就是網頁上各個功能以及排版都可以實現其應有的功能，這也是比較好測試的。頁面整合後，可以經過各項的測試，這樣就算是"作好了"。

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

      應急計劃就是面對時間緊缺的狀況，回選擇削減一些非核心需求的功能來緊急應對。

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

      有了M1的經驗，M2每次出現意料以外的工做請求時，pm都會和dev商討提出可行的解決方案。並且從結果來看，意料以外的工做的處理的狀況仍是不錯的。

相對於M1的改進

GIT的介入避免了只能經過QQ傳遞代碼的麻煩，並且能夠處理代碼版本衝突、版本變動等帶來的代碼管理風險

   

 

測試/發佈

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

同M1相同

　　團隊有明確的測試計劃。後端的測試主要是編寫單元測試，功能測試和壓力測試。

　　前端的測試主要是場景測試和在不一樣瀏覽器及不一樣環境下的測試。

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

　　後端測試完成了單元測試和功能測試模塊，也實施了壓力測試。

　　前端測試計劃均已完成，並進行了驗收。

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

　　後端進行測試主要使用rails自帶的單元測試模塊，來編寫單元測試和功能測試。

　　利用Fiddler4這一工具，來測試相應的API邏輯，對傳入的請求和返回的響應進行檢查。

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

　　效能測試以前咱們並無考慮，主要由於時間有限，因此只作了一些基礎性的測試。向效能測試和負載測試會在Beta階段進行，對於效能方面，　　咱們團隊計劃經過增長服務器的數量，將邏輯計算和數據交互分開進行，進而提升服務器的響應效能。對於負載方面，咱們團隊打算將數據庫改用MySql實現，而且將後端rails框架改進爲能夠並行訪問。

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

無

相對於M1的改進

1. 後端執行了壓力測試

2. 加強用戶場景測試

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

  Fiddler不免有一些繁瑣與麻煩，應該尋找一些更高效的測試工具

 

補充問題：

1. 對比敏捷的原則, 你以爲大家小組相對於M1作得最好的是什麼? 
   1. 處理需求變化更加及時

      M1階段在應對各類突發情況時，顯得過於被動，對項目總體需求和進展的把控也不足。而在M2中，伴隨着更多的溝通交流，這一點作得更加到位。可以及時根據進度調整需求變化以及更新TFS任務

   2. 可以時時總結並提升團隊效率

      M2初期關於scrum meeting作的是不夠好的，寫得太過簡略，並且標準控制的也不嚴格。中期經過一次例會，一位同窗提到了這點，並提出了本身的意見，通過討論被你們接受。以後迅速更改了scrum meeting發佈模式，後幾篇的博客質量明顯上升。這就是一個可以時時總結並提升團隊效率的例子。

而在M1中作的比較好的幾點也保持了下來。

I.保持簡明——儘量簡化工做量的技藝——極爲重要

經過API文檔，將項目任務細化爲前端與後端。

後端採用rails框架，自帶MVC結構，後端三人分別去作Model層，Controller以及Router。

前端採用界面也JS代碼分離開發的方式，將任務分爲UI設計界面實現，界面動態化展現。

經過以上的開發模式，雖然你們是各自編碼，可是各個部分之間的耦合度很是低，整合起來比較簡單明瞭。每一個人只須要專一於本身的技術領域，學習成本下降，開發效率提高。

II. 不管團隊內外，面對面的交流始終是最有效的溝通方式

咱們每週都有小組會議。每週例會主要議題有兩個，第一個是該周目標與任務安排，第二個是介紹採用的新的技術方案or開發工具、開發方式。第一個議題，使每一個隊員明確本身的任務，任務明確，是一個開發人員進行開發的最大動力。第二個議題，使隊員知道接下來將如何和隊友合做，如何什麼樣的技術實現將要開發的功能。
好比，咱們在討論用戶狀態控制時，涉及到後端的Token存儲、API調用、前端sessionStorage存儲以及header傳遞身份信息的驗證方式，將整個技術流程介紹完畢，先後端隊員就理解如何更好的和對方配合了。

III. 以有進取心的人爲項目核心，充分信任他們

咱們團隊有明確的前端負責人和後端負責人。平時遇到一些問題，PM直接和負責人溝通，負責人再和本身組內人員分工討論。PM充分信任負責人。把任務交給他們十分方向。這樣PM纔有更多的時間和精力宏觀規劃，總體把握。若是PM老是擔憂任務完成狀況和質量，或者老是追着每一個人催促進度，那麼就沒有充足的精力規劃項目，項目質量就會降低。

   

2. 整體相對於 M1 改進的地方

I.TFS任務的規範化。TFS任務採用實時建立、更新的策略，嚴格按照真實進度來進行，可以更好的進行敏捷開發。

II.UI獲得了部分美化。

III.使用了GIT做爲代碼管理工具，大大提升了代碼管理效率。解決了諸如代碼共享、代碼版本更新、代碼版本衝突等潛在問題。M2中幾乎沒遇到代碼版本帶來的麻煩。

IV. 後端執行了壓力測試。

V. 加強了用戶場景測試。

   

1. 仍需改進的地方

I. 前端測試機制仍不完善，互相之間的溝通交流也需增強。

II.仍需更重視代碼規範。先後端代碼的規範並不很嚴格，這會對未來的進一步開發產生較大的影響。

 

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

我以爲團隊目前的狀態屬於可管理級級別，有過程紀律和功能性，，團隊協做比較協調，但仍缺少嚴格的代碼複審流程。

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

我以爲咱們團隊目前處於磨合階段。