[Gamma階段]過後分析博客

Gamma階段過後分析博客

做業要求:Gamma階段過後分析前端

設想和目標

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

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

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

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

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

  • 咱們達到目標了麼(原計劃的功能作到了幾個? 按照原計劃交付時間交付了麼? 原計劃達到的用戶數量達到了麼?)微信小程序

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

    交付時間:在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是很是浪費時間、很是不划算的。網上有許多現成的代碼。儘可能少重複造輪子能夠留出更多時間實現其餘功能。
    • 宣傳工做的增強:因爲微信小程序自己很是便捷,不須要下載,不須要註冊帳號,經過微信能夠直接進入並登錄。所以對於小程序來講,宣傳的效用比是很是高的:只要讓潛在用戶知道該小程序的存在,由於使用的成本很是低,用戶就有很高的機率會進行嘗試。

討論照片

相關文章
相關標籤/搜索