目錄html
做業要求: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階段的成果更像是「原型」而非產品。
有什麼經驗教訓? 若是歷史重來一遍,咱們會作什麼改進?
根據用戶反饋進行產品的修改是很是重要的。根據用戶反饋進行改正的效率每每遠大於閉門造車, 團隊本身 悶頭苦想。
若是重來一遍:咱們會在每一個階段的最終發佈前一週先發佈一個版本,並收集儘可能多的用戶反饋,根據用戶反饋修改後再發布迭代的最終版本。這樣每一個迭代發佈的產品質量會高不少。
是否有充足的時間來作計劃?
是的,由於每階段前都有半周時間做爲計劃與設計的時間,所以計劃時間充足。
咱們的計劃流程是:
這樣的計劃流程,保證了在每日任務不會過於臃腫的狀況下,對項目總體進展有精準的掌握,確保主要任務的順利完成。
這一點在Gamma階段依然保持。而且在每一個迭代末尾的發佈後,咱們就會考慮下個迭代的大體方向。
團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的?
對於不一樣意見,咱們會給成員充足的時間,經過語言、手稿等方式展現本身的想法,闡述這麼作的緣由,最後達成共識,或少數服從多數。對於不一樣類型的問題,好比規劃、設計類問題,前端問題,後端問題,咱們會着重考慮PM、前端負責人、後端負責人的意見。
你原計劃的工做是否最後都作完了? 若是有沒作完的,爲何?
咱們原定的主要功能所有都完成了。
有一些規劃之初就做爲「有時間的話能夠完成」的額外任務沒有作完。例如發佈舉報功能、提醒功能。
沒有完成的主要緣由有:
有沒有發現你作了一些過後看來不必或沒多大價值的事?
從最後的結果來看,我的資料頁面彷佛並無什麼用。
之因此作我的資料頁面,是覺得最初設計中,打算讓用戶直接上傳一個文件做爲申請一個招募時的簡歷,所以實現了一個我的資料頁面,儲存用戶的一些基本信息。可是因爲微信小程序不容許上傳除了相冊中的照片、視頻意外的文件,因此沒法實現。爲了解決這個問題咱們實現了簡歷模板的功能。而我的資料中填寫的項目,簡歷中基本都有。
是否每一項任務都有清楚定義和衡量的交付件?
任務定義:
交付件:
是否項目的整個過程都按照計劃進行,項目出了什麼意外?有什麼風險是當時沒有估計到的,爲何沒有估計到?
在Beta階段的發佈中,碰見了一個很大的意外,致使咱們的發佈被拖延了一段時間。
意外及風險:在Beta階段中,咱們前兩次發佈小程序時順利經過。可是在修復了部分BUG後,進行第三次發佈時(除了修復了BUG之外與第二次發佈沒有任何區別),咱們的發佈以「我的版小程序不能有信息發佈功能」爲理由被打回。以後的審覈一直沒有經過。直到咱們升級爲了企業版小程序。
沒有估計到的緣由:沒有想到徹底同樣的小程序,一天前毫無阻礙的經過了審覈,一天後就再也沒法經過審覈了。。。這一點某種程度上來講是不可預知的。。。
在計劃中有沒有留下緩衝區,緩衝區有做用麼?
緩衝區:Gamma階段中,因爲有Beta階段的教訓,咱們留出了將近一週的時間做爲發佈的緩衝時間。
做用:避免出現一些意料以外的問題再次出現。同時,也爲宣傳留出更多時間,以積攢更多的用戶量。
未來的計劃會作什麼修改?(例如:緩衝區的定義,加班)
若是有下一階段的話,你們會盡可能先大概告知最近的狀況,將你們的複習、大做業、比賽等等佔用時間的事項更多的、更詳細的歸入計劃範圍。
咱們學到了什麼?若是歷史重來一遍,咱們會作什麼改進?
咱們的經驗:不一樣類型的任務儘可能分離,讓不一樣成員完成。儘可能讓每一個人在同一時間內只負責某一種類型的工做。這樣能夠提升你們完成任務的速度和質量。
若重來一遍,咱們會嘗試將每一個人每日的工做更新在ISSUES中,不知這樣的話會不會讓每日任務的追蹤、燃盡圖更加合理。
咱們有足夠的資源來完成各項任務麼?
同Alpha階段同樣,資料基本足夠。最緊缺的是時間資源,由於有團隊成員忙於實(jia)習(ban)、考研加分相關的比賽,Gamma階段還有各科期末的考試、大做業等。
各項任務所需的時間和其餘資源是如何估計的,精度如何?
在Gamma階段,各項任務須要的時間主要是根據前兩個階段的經驗來估計的。從最後的結果來看,咱們對各項任務時間的估計仍是很是準確的。
測試的時間,人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?
測試階段的各種資源足夠。由於留出了足夠的時間進行測試。
在有了Alpha階段的經驗以後,咱們正確意識到了非編程任務的難度,並分配專人完成相關任務。
你有沒有感到你作的事情可讓別人來作(更有效率)?
咱們一致贊成最後Gamma階段的分工是比較合理的,拋開我的能力的些微差距,你們完成任務的效率都是較高的。
有什麼經驗教訓? 若是歷史重來一遍,咱們會作什麼改進?
一些難以直接統計、難以數字化的資源也很是重要。好比在申請企業版小程序時,有認識的朋友、同窗擁有註冊企業,能夠提供幫助的話,就是一項很是可貴、很是寶貴的資源。
咱們會作的改進:若是重來一遍,咱們會提早了解產品所在的平臺有何限制,而不是僅僅瞭解這個平臺有何優勢。
每一個相關的員工都及時知道了變動的消息?
是的。由於每日的討論及交流很是頻繁,團隊成員每每也一塊兒吃飯、上課,所以消息的同步速度很快。
咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?
咱們認爲一個功能的重要程度,取決於這個功能的缺失對產品的功能完整性及用戶體驗的影響程度,也就是「刪去這個功能會造多大的影響」。
項目的出口條件(Exit Criteria – 什麼叫「作好了」)有清晰的定義麼?**
Gamma階段的出口條件歸納爲:完成一個界面美觀的數學建模比賽組隊模塊。
數學建模模塊的具體功能以下:
對於可能的變動是否能制定應急計劃?
能。若每日總結時發現有任務未能完成,會對本週接下來的任務、項目整體計劃進行及時的更改。
員工是否可以有效地處理意料以外的工做請求?
能。好比臨時新添接口的設計、展現用各界面的屏幕捕捉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 中的哪一個檔次?
咱們認爲,在通過了三次迭代事後,咱們的團隊基本達到了「已管理級」的要求。
你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?
咱們認爲咱們的團隊達到了「規範」階段的基本要求。
你以爲目前最須要改進的一個方面是什麼?
咱們認爲能夠將Issues交由負責完成任務的相關成員本身管理,而再也不是PM統一管理。這樣ISSUES的進度追蹤自己就起到了一個監督本身完成每日工做的功能,其次,也能對總體實現過程有更好的記錄,這樣能更好的發現存在的問題。
對比敏捷的原則,你以爲大家小組作得最好的是什麼?
我認爲咱們小組作的最好的是:
不管團隊內外,面對面的交流始終是最有效的溝通方式
咱們團隊的成員面對面溝通的時間遠大於在線交流時間,尤爲是前、後端主要開發人員,在開發時基本是當面一塊兒編程,保證了交流的效率。
可用的軟件是衡量項目進展的主要指標
在計劃時,每階段任務基本以可以使用的,功能完整的頁面做爲任務目標,由於這一目標涵蓋了具體的前端頁面以及配套的後端數據庫。
在實際開發過程當中,每日總結時也以具體頁面的完成狀況、頁面中功能的完整度做爲衡量的主要指標。
投資最大化
在Gamma階段,因爲與期末重疊,所以時間緊張。因此咱們將有限的時間都花費在了必要的頁面、功能上。最後直接根據用戶反饋進行改進,儘可能實現投資最大化。
在下一階段中咱們要改進的地方