[Gamma階段]過後分析博客

目錄

• Gamma階段過後分析博客
  • 設想和目標
  • 計劃
  • 資源
  • 變動管理
  • 設計/實現
  • 測試/發佈
  • 團隊的角色，管理，合做
  • 總結
  • 討論照片

Gamma階段過後分析博客

做業要求：Gamma階段過後分析

設想和目標

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

  咱們軟件要解決的問題是：現階段各種組隊招募、實習招募信息經常被埋沒在大量微信聊天消息中，翻閱十分困難，且申請流程差別巨大，招募、申請的效率極低。

  解決方法：經過微信小程序爲同窗們提供一個統一的，功能全面的招募信息發佈平臺，讓同窗們能夠方便快捷的完成組隊的招募、申請。

  咱們團隊對於要解決的問題定義很是清楚，對於目標用戶羣體的劃分也很是準確，具體，就是各個大學中的，但願組織或加入別人項目的同窗們。

  這一點在Gamma階段中依然保持不變。

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

  原計劃功能的實現：在三個迭代事後，咱們經過30個不一樣頁面，完成了預期的所有功能。還加入了標籤、搜索、分類檢索、數學建模模塊等額外功能。

  交付時間：在Beta階段中，因爲小程序審覈條件忽然變嚴致使了交付時間的拖延。在Gamma階段咱們吸收了教訓，預留了充足的時間給發佈階段。最後提早完成了交付。

  用戶數量：截止2019.06.17日，咱們的用戶數量達到了400，比咱們的預期成果高很多。

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

  和以前兩個階段相比，咱們的軟工質量的提升主要體如今如下兩個方面：

  • 團隊合做更加順利

    在Gamma階段中，團隊通過了以前的磨合，各自分工明確，從開始的計劃階段，到開發階段，再到最後的測試、發佈階段，每一個人都對本身的職責有很是清晰的認識。這樣其實PM沒有天天催着成員完成任務，成員也會以很高的積極性、自覺性去完成本身份內的工做。

  • 設計、接口文檔的完善

    在Gamma階段中，咱們的前、後端設計文檔都更加規範了。在前端咱們有詳細的頁面設計，經過PPT預先對頁面佈局、UI、配色進行設計，並對其中可互動部分作了示意。

    而在後端，咱們對全部接口都有詳細的設計文檔，包括接口的名稱、參數名、參數類型、返回值名稱、返回值類型、不一樣錯誤碼的含義、各個參數的合法性檢查條件等等。

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

  用戶對主要功能，即發佈、申請及相關管理功能的接受度挺高。這一點主要得益於在Beta、Gamma階段中不斷修復BUG的努力。相比Alpha階段，Gamma階段的產品BUG數量降低了很是多，如今幾乎沒有明顯的影響體驗的BUG。能夠說離最初的目標，即完成一個「完整的產品」近了不少。Alpha和Beta階段的成果更像是「原型」而非產品。

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

  根據用戶反饋進行產品的修改是很是重要的。根據用戶反饋進行改正的效率每每遠大於閉門造車， 團隊本身 悶頭苦想。

  若是重來一遍：咱們會在每一個階段的最終發佈前一週先發佈一個版本，並收集儘可能多的用戶反饋，根據用戶反饋修改後再發布迭代的最終版本。這樣每一個迭代發佈的產品質量會高不少。

計劃

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

  是的，由於每階段前都有半周時間做爲計劃與設計的時間，所以計劃時間充足。

  咱們的計劃流程是：

  • 在開發階段前，通過討論，由PM決定這一階段的整體目標，並以周爲單位分解整體目標
  • 每週前由PM規劃本週的工做流程，將本週工做分解至不超過2天時間的具體工做。

  這樣的計劃流程，保證了在每日任務不會過於臃腫的狀況下，對項目總體進展有精準的掌握，確保主要任務的順利完成。

  這一點在Gamma階段依然保持。而且在每一個迭代末尾的發佈後，咱們就會考慮下個迭代的大體方向。

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

  對於不一樣意見，咱們會給成員充足的時間，經過語言、手稿等方式展現本身的想法，闡述這麼作的緣由，最後達成共識，或少數服從多數。對於不一樣類型的問題，好比規劃、設計類問題，前端問題，後端問題，咱們會着重考慮PM、前端負責人、後端負責人的意見。

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

  咱們原定的主要功能所有都完成了。

  有一些規劃之初就做爲「有時間的話能夠完成」的額外任務沒有作完。例如發佈舉報功能、提醒功能。

  沒有完成的主要緣由有：

  • 在既定頁面上添加某些功能，難以保證頁面整齊美觀，可能須要大幅改動頁面，會花費很是巨大的精力，得不償失。
  • 期末階段，你們有比賽、期末複習、期末大做業、實習要忙，各有各的事，時間緊缺。

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

  從最後的結果來看，我的資料頁面彷佛並無什麼用。

  之因此作我的資料頁面，是覺得最初設計中，打算讓用戶直接上傳一個文件做爲申請一個招募時的簡歷，所以實現了一個我的資料頁面，儲存用戶的一些基本信息。可是因爲微信小程序不容許上傳除了相冊中的照片、視頻意外的文件，因此沒法實現。爲了解決這個問題咱們實現了簡歷模板的功能。而我的資料中填寫的項目，簡歷中基本都有。

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

  任務定義：

  • 前端：具體頁面的原型圖，其中按鈕的功能
  • 後端：數據庫的詳細設計規格，接口的詳細設計規格

  交付件：

  • 前端：可體驗的前端頁面
  • 後端：可供前端直接調用的後端接口

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

  在Beta階段的發佈中，碰見了一個很大的意外，致使咱們的發佈被拖延了一段時間。

  意外及風險：在Beta階段中，咱們前兩次發佈小程序時順利經過。可是在修復了部分BUG後，進行第三次發佈時（除了修復了BUG之外與第二次發佈沒有任何區別），咱們的發佈以「我的版小程序不能有信息發佈功能」爲理由被打回。以後的審覈一直沒有經過。直到咱們升級爲了企業版小程序。

  沒有估計到的緣由：沒有想到徹底同樣的小程序，一天前毫無阻礙的經過了審覈，一天後就再也沒法經過審覈了。。。這一點某種程度上來講是不可預知的。。。

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

  緩衝區：Gamma階段中，因爲有Beta階段的教訓，咱們留出了將近一週的時間做爲發佈的緩衝時間。

  做用：避免出現一些意料以外的問題再次出現。同時，也爲宣傳留出更多時間，以積攢更多的用戶量。

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

  若是有下一階段的話，你們會盡可能先大概告知最近的狀況，將你們的複習、大做業、比賽等等佔用時間的事項更多的、更詳細的歸入計劃範圍。

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

  咱們的經驗：不一樣類型的任務儘可能分離，讓不一樣成員完成。儘可能讓每一個人在同一時間內只負責某一種類型的工做。這樣能夠提升你們完成任務的速度和質量。

  若重來一遍，咱們會嘗試將每一個人每日的工做更新在ISSUES中，不知這樣的話會不會讓每日任務的追蹤、燃盡圖更加合理。

資源

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

  同Alpha階段同樣，資料基本足夠。最緊缺的是時間資源，由於有團隊成員忙於實（jia）習（ban）、考研加分相關的比賽，Gamma階段還有各科期末的考試、大做業等。

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

  在Gamma階段，各項任務須要的時間主要是根據前兩個階段的經驗來估計的。從最後的結果來看，咱們對各項任務時間的估計仍是很是準確的。

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

  測試階段的各種資源足夠。由於留出了足夠的時間進行測試。

  在有了Alpha階段的經驗以後，咱們正確意識到了非編程任務的難度，並分配專人完成相關任務。

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

  咱們一致贊成最後Gamma階段的分工是比較合理的，拋開我的能力的些微差距，你們完成任務的效率都是較高的。

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

  一些難以直接統計、難以數字化的資源也很是重要。好比在申請企業版小程序時，有認識的朋友、同窗擁有註冊企業，能夠提供幫助的話，就是一項很是可貴、很是寶貴的資源。

  咱們會作的改進：若是重來一遍，咱們會提早了解產品所在的平臺有何限制，而不是僅僅瞭解這個平臺有何優勢。

變動管理

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

  是的。由於每日的討論及交流很是頻繁，團隊成員每每也一塊兒吃飯、上課，所以消息的同步速度很快。

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

  咱們認爲一個功能的重要程度，取決於這個功能的缺失對產品的功能完整性及用戶體驗的影響程度，也就是「刪去這個功能會造多大的影響」。

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

  Gamma階段的出口條件歸納爲：完成一個界面美觀的數學建模比賽組隊模塊。
  數學建模模塊的具體功能以下：

  • 填寫、修改數學建模相關信息功能
  • 用戶填寫問卷後，根據用戶填寫的答案自動打分，並匹配相應隊友
  • 經過搜索對特定用戶發出組隊邀請
  • 經過首頁推薦模塊對匹配的隊友候選發出邀請
  • 管理本身發出、收到的全部邀請
  • 用戶不滿意當前隊伍時，能夠自行退出當前隊伍
  • 當A用戶向B用戶發出了邀請，且B用戶還未答覆，或B用戶與A用戶處於同一隊伍時，再也不向A用戶推薦B用戶

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

  能。若每日總結時發現有任務未能完成，會對本週接下來的任務、項目整體計劃進行及時的更改。

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

  能。好比臨時新添接口的設計、展現用各界面的屏幕捕捉gif等，這類臨時工做咱們會優先分配給平時完成任務較少的同窗，即保證了公平，也給他們賺取更高貢獻分的機會。

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

  咱們的經驗：一開始的計劃越詳細，後面須要作的更改就越少，實現時所做的無用功就越少。

  若是重來一遍：咱們會在每一個迭代計劃階段的一開始，就完成每一個頁面的佈局、功能設計，這樣先後端都能有更加具體的目標，所須要作的更改就更少。

設計/實現

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

  時間：設計工做在設計與發佈階段完成。

  負責人：產品的功能、頁面設計由PM完成。同時也採納了其餘成員的合理建議。

  後端接口由PM、前端、後端共同討論決定每一個接口功能後，由SZY彙總爲具體的文檔。

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

  基本沒有這種問題。由於咱們對最後所要實現的目標很是明確。所以計劃階段基本沒有這樣的狀況。

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

  使用的工具：使用了單元測試。使用的工具是Django Coverage。還進行了服務器的壓力測試，使用了locust。除此以外還使用了git bash管理代碼，issues管理任務，process on進行原型圖的設計。

  這些工具仍是能提升相應任務的完成效率及質量。

  沒有使用UML文檔，可是有先後端相應的詳細設計文檔。

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

  產生BUG最多的是一些邏輯關係複雜部分，好比在數學建模模塊推薦隊友時的屏蔽規則。

  沒有想到的主要緣由是須要屏蔽的狀況較多，可是屏蔽條件由不過過多，由於總體用戶量有限。

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

  代碼複審：代碼複審主要由先後端的負責人進行。

  對於代碼規範的執行程度仍須要提升。尤爲是前端。

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

  咱們的經驗：微信小程序自己還不是很是成熟，其內置的許多工具在安卓和IOS系統的適配上存在許多問題，必定要對於兩種操做系統作詳細的測試。

  若是重來一遍：咱們會在實現每一個頁面後就儘可能對兩種系統都進行測試。這樣能夠更完全的檢查系統適配問題。在所有完成後再進行測試，很容易有遺漏，而且那時所有功能都已經完成，可能會出現「牽一髮而動全身」的狀況。

測試/發佈

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

  有。在開發階段結束後分別對先後端進行測試，分別進行了不一樣機型的功能測試、單元測試和服務器的壓力測試。詳細測試請見Gamma階段測試報告

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

  是的。在申請發佈小程序前，咱們對全部頁面及功能都進行了一邊複查。

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

  使用了Django coverage來跟蹤咱們的單元測試的代碼覆蓋率，利用Locust來對服務器的壓力負載能力進行了測試。詳情一樣見Gamma階段測試報告

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

  微信小程序自帶有對各頁面的截載時間統計功能。這些工具主要可讓咱們瞭解哪些頁面加載的最慢，最影響用戶體驗，並有針對性的對好比與後端的通訊方式、交換的數據等方面進行修改。

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

  在Beta階段中，咱們前兩次發佈小程序時順利經過。可是在修復了部分BUG後，進行第三次發佈時（除了修復了BUG之外與第二次發佈沒有任何區別），咱們的發佈以「我的版小程序不能有信息發佈功能」爲理由被打回。以後的審覈一直沒有經過。直到咱們升級爲了企業版小程序。

  沒有估計到的緣由：沒有想到徹底同樣的小程序，一天前毫無阻礙的經過了審覈，一天後就再也沒法經過審覈了。。。這一點某種程度上來講是不可預知的。。。

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

  咱們的經驗：單元測試很是有用。保持單元測試的跟進，可讓測試全面、簡單不少。

  若是重來一遍：若是重來一遍，咱們會提早申請企業版小程序。避免發佈出現問題。

團隊的角色，管理，合做

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

  肯定依據：根據每一個成員的性格，以及其在以前階段中的表現來決定。

  由於有以前階段的經驗，具備必定參考， 所以每一個人的分工都是你們認爲比較合理，比較適合本身的。

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

  有。不懂的問題請教其餘成員、在平時的交流中幫助其餘成員等等。

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

  出現問題時，首先經過QQ、微信通知對方，能在線解決的小問題爭取在線解決。若問題比較複雜或者麻煩，就到某一方的寢室詳細討論，當面解決。

總結

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

  咱們認爲，在通過了三次迭代事後，咱們的團隊基本達到了「已管理級」的要求。

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

  咱們認爲咱們的團隊達到了「規範」階段的基本要求。

  • 咱們的全部討論、工做都是透明的，成員也比較承認PM的能力，先後端各自成員也有必定的自管理。
  • 由於分工的細化、固定，再也不須要PM不斷的提醒、催促成員完成各自任務。
  • 咱們的目標統一明確，有較高的一致性。
  • 你們的合做很是愉快，關係友好。

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

  咱們認爲能夠將Issues交由負責完成任務的相關成員本身管理，而再也不是PM統一管理。這樣ISSUES的進度追蹤自己就起到了一個監督本身完成每日工做的功能，其次，也能對總體實現過程有更好的記錄，這樣能更好的發現存在的問題。

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

  我認爲咱們小組作的最好的是：

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

    咱們團隊的成員面對面溝通的時間遠大於在線交流時間，尤爲是前、後端主要開發人員，在開發時基本是當面一塊兒編程，保證了交流的效率。

  • 可用的軟件是衡量項目進展的主要指標

    在計劃時，每階段任務基本以可以使用的，功能完整的頁面做爲任務目標，由於這一目標涵蓋了具體的前端頁面以及配套的後端數據庫。

    在實際開發過程當中，每日總結時也以具體頁面的完成狀況、頁面中功能的完整度做爲衡量的主要指標。

  • 投資最大化

    在Gamma階段，因爲與期末重疊，所以時間緊張。因此咱們將有限的時間都花費在了必要的頁面、功能上。最後直接根據用戶反饋進行改進，儘可能實現投資最大化。

• 在下一階段中咱們要改進的地方

  • 尋找更可靠、更好看的UI控件：本身開發大部分UI是很是浪費時間、很是不划算的。網上有許多現成的代碼。儘可能少重複造輪子能夠留出更多時間實現其餘功能。
  • 宣傳工做的增強：因爲微信小程序自己很是便捷，不須要下載，不須要註冊帳號，經過微信能夠直接進入並登錄。所以對於小程序來講，宣傳的效用比是很是高的：只要讓潛在用戶知道該小程序的存在，由於使用的成本很是低，用戶就有很高的機率會進行嘗試。

討論照片