過後諸葛亮(葫蘆娃隊)

時間 2019-11-09

標籤過後葫蘆简体版

原文原文鏈接

課程名稱：軟件工程1916|W（福州大學）

做業要求：過後諸葛亮（團隊）

團隊名稱：葫蘆娃隊

做業目標：對此次Alpha衝刺階段進行過後諸葛亮總結。

做業正文：過後諸葛亮(葫蘆娃隊)

在本次Alpha衝刺階段，咱們小組的預期目標是在兩個階段（兩週）裏面完成這個遊戲Demo的設計。其中，第一階段（第一週）的目標爲：完成最小基礎場景的搭建、角色以及角色功能的設計。其中角色的設計部分包括外形的設計，而角色功能的設計包括角色的跳躍、移動、飛行等一系列操做的設計。而後第二階段（第二週）的目標爲：對關卡進行設計與搭建以及進行遊戲測試和感想調查。在關卡的搭建上，須要實現前期設計的關卡功能，而在遊戲測試中須要達到遊戲流暢不卡頓。感想調查則是對遊戲進行建議而且提出實質性的建議而後進行討論後對遊戲進行改進。
對於用戶數因爲遊戲未發佈，用戶目前是開發人員。微信

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

軟件工程質量有提升在項目成果上，由於實現了項目雛形。衡量方式是至少有個產品可使用了相較於以前的文檔而言。框架

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

因爲遊戲只在開發測試階段，所以還沒推廣，沒有用戶量。因爲咱們已經實現了遊戲的基礎玩法，距離遊戲大成的目標已經更近一步了。工具

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

要提前進行開發，前期文檔花費時間較多。
若是能重來，咱們必定必定提早學好技術棧（笨鳥先飛）。

2、計劃

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

是，在具體開發項目前已經歷過長時間的需求分析和項目設計，組員也經歷了屢次討論，遊戲的玩法已經在開發前徹底敲定，組員分工也事先獲得合理安排。

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

咱們採起求同存異的方針，先統一組員都同意的設想。對於不一樣的意見，採起折中的辦法，儘可能作到全部人都能接受。若是實在沒法統一意見，那麼採起少數服從多數的原則。

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

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

學習Unity時，因爲視頻是英語口述，且沒有字幕，因此一個視頻須要反覆看幾遍才能大體理解，後來發現某網站有自動字幕功能，且還能自動翻譯，問題就解決了。
另外就是BUG調試重複（由於沒有頭緒，也很差作調試，進度就卡在了調試），花費了隊員時間。

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

是的，基本都有

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

按計劃進行，意外是項目中使用github for unity,來進行unity項目的源碼管理，可是這個插件沒有提供克隆到本地的功能，而直接從github網頁上下載又沒法運行，後面查明瞭是git lfs（大文件管理）方向的問題，最後用用gitkraken和其的提示的幫助文檔，下載了相應文件解決的克隆本地的問題。

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

有的，用於查缺補漏，以及任務交接。

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

根據新隊員掌握適當分配任務。學習一下局域網的實現，並考慮一下工期是否能實現

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

學習了Unity製做簡單遊戲，學習了Github管理代碼，學習了開發前的文檔撰寫，學會了Markdown寫博客。
學會了團隊協做以及時間管理。
若是能重來，咱們會多看視頻早準備。

3、資源

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

有，開發用的Unity已經很成熟，有大量教程能夠學習。並可針對具體任務提供具體教程

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

各項任務的分配是以難度劃分人力等資源的，還綜合了我的的意願和擅長方向。

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

人力資源充足，小組有7個成員。遊戲須要的素材使用的是CorgiEngine資源包上已設計好的組件，因此暫時沒有美工上的問題，可是若是之後要拓展遊戲玩法。文檔、博客的編輯有專門組員來作。

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

有，一些同窗學習能力不是很強，須要別人的幫助。

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

增強團隊交流，對於新掌握的知識，尤爲須要引路人的指引。隊長對與團隊成員學習進度把控很重要。

4、變動管理

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

咱們小組通常若是在項目上有很大的變動，會第一時間在小組的qq羣和微信羣中通知全部小組成員，所以組員接收消息都會比較及時，但不能保證確實每一個人都受到熱銷。

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

因爲咱們小組開發的是遊戲項目，遊戲玩法是整個遊戲的核心。所以咱們把遊戲的基礎玩法列爲必須實現的功能，在α階段必須實現遊戲的基礎玩法。而一些擴展功能，例如更多樣的遊戲玩法或者聯機等功能，咱們決定推遲至β階段來實現。

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

在需求報告裏的性能、界面需求等模塊中有比較清晰的定義。

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

沒有應急計劃，但能經過具體分析具體解決。

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

沒有意料以外，若是有的話就是協助調試BUG了。能處理額外的工做請求，不過花費時間。

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

隊員間的溝通很重要，及時的溝通能避免一些沒必要要的麻煩。若是能重來，咱們會制定應急計劃，加快應對變動的速度。

5、設計/實現

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

設計是由你們討論完成的。一開始你們就討論了地圖的數量，須要的基本的要素（好比場景裏的一些小機關，小物品、道具之類），以及地圖的風格。可是地圖的輪廓沒有定型。差很少應該在合適的時間完成了。

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

有。有時候感受各方面均可以的設計，卻有不一樣組員提出兩個方案。組內討論就解決了。

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

有用uml分析過咱們的項目。先前的uml文檔確實大體前期指導了咱們完成了部分腳本框架的開發，以後仍是在細節方面對其作了不少的補充。基本是測試驅動，咱們先完成了大體框架，再向其中添加咱們想到的東西，一添加足夠多的部分，咱們就進行測試，功能有沒有實現。因此咱們的進展還算順利。

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

主要BUG產生在插件的水土不服。遊戲場景沒有什麼重要bug，由於咱們過程當中作了不少測試，bug在其中就獲得解決。經驗不足。

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

先由編寫者進行自審，然後組長粗審，咱們的腳本代碼比較規範，基本都說明了，一個函數是幹什麼的。

6、測試/發佈

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

有大概的計劃，由於測試對於咱們的遊戲至關重要，基本都是一步步測試過來的。但unity的單元測試部分還處在學習階段，還不能對每一個應該測試邏輯都進行相應的單元測試。

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

進行了部分可是不夠與高效和嚴謹。咱們對最後的功能進行了一個羅列，經過untiy測試插件一個個完成了對其中列出了功能模塊的測試，而且反饋到表格上

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

有。目前只是使用了unity自帶的Editor Tests Runner進行單元測試

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

軟件效能，使用unity內建工具像是 CPU Profiler、Memory Profiler、或是 5.3 纔有的 Memory Analyzer，可是咱們沒有對其深入的學習理解。從軟件實際運行的結果來看，遊戲能保證必定的幀數。因此但願以後貝塔階段能讓團隊中的幾人人深刻理解並進行測量。

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

暫時尚未發佈，項目已經導出，供用戶進行隨意測試，暫時沒有太大問題。

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

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

組內一開始採起任務分配製，每一個人能夠自主認領本身的任務，這樣每一個人均可以找到適合本身能力的任務。而沒有被分配出的任務最後由組長分配，與組員協商，能者能夠多接受任務得到更高的貢獻度。

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

在Unity上開發遊戲是咱們組以前從未接觸過的，所以基本上咱們都是從零開始，邊學習邊開發，遇到不會的難題咱們會交流討論，共同進步。

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

咱們的項目管理者是組長，由組長統籌兼顧各個組員的任務，若是組員在任務分配或者合做方面出現問題，主要方式仍是靠溝通來解決。

8、總結

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

初始級(initial)。工做無序，項目進行過程當中常放棄當初的計劃。管理無章法，缺少健全的管理制度。開發項目成效不穩定，項目成功主要依靠項目負責人的經驗和能力，他一但離去，工做秩序面目全非。

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

磨合

你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

比之前相比工做分配的更加有序些，明白了交流的重要性。

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

能更合理的分配工做，與交接，從而充分調動人員的積極性，同時保證工做方向的統一性與工做時間的相對平衡。

對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。

1.咱們最優先要作的是經過儘早的、持續的交付有價值的軟件來使客戶滿意。
在比較早的階段完成大概遊戲玩法的demo。
2.常常性的交付能夠工做的軟件，交付的間隔能夠從幾周到幾個月，交付的時間間隔越短越好。

鑑於unity與遊戲迭代開發的性質，一個功能添加就能在單個場景遊戲中體現，並且各類角色功能能夠分的比較小而快完成。

正如咱們前面提到的，軟件的質量 = 程序的質量 + 軟件工程的質量，那團隊在下一階段應該如何提升軟件工程的質量呢？

提升可讀性、可維護性、可變動性。
可讀性：不要編寫大段的代碼，合理使用釋義名稱與註釋
可維護性：預測可能發生的變化
可變動性：
經過提升代碼複用提升可維護性
利用設計模式提升可變動性
以職責爲中心，根據職責分配行爲決定類
複審時，針對這幾點嚴格複審與交流修改
同時要讓人員清楚認識到到代碼規範對後續測試的重要性

代碼管理的質量具體應該如何提升？代碼複審和代碼規範的質量應該如何提升？

整個程序的架構如何具體提升？如何經過重構等方法提升質量，如何衡量質量的提升？

因爲咱們小組對架構知識量不足，首先先從規範的架構學習理解，並對代碼進行復審，對不符合要求或者很差理解的部分進行讓大牛與原代碼編寫者合做進行重構，衡量的方式的就是越少的代碼的抱怨，質量就越高。

其它軟件工具的應用，應該如何提升？

對新手從基礎教程入手，老手複審他的使用，並提出建議來改進他的應有技術與規範。

項目管理有哪些具體的提升？

深入明白了項目重要的事先準備，以及過後收尾的測試部分。

項目跟蹤用戶數據方面，計劃要提升什麼地方？例如大家是如何知道每日/周活躍用戶等數據的？

咱們的遊戲項目在以後要計劃給其餘同窗用戶試玩，吸收他們的遊戲意見進行改進，對用戶建議實現進行權重分析排序，在有限時間有效的完成用戶需求提高可玩性。

項目文檔的質量如何提升？

安排重視文檔編寫工做，有良好溝通能力的人編寫文檔，重新手，其餘人的角度去複審。

對於人的領導和管理，有什麼具體能夠改進的地方？請看《構建之法》關於PM、績效考覈的章節，或者《人件》等參考書

在領導和管理方面，就目前的狀況來看，我認爲須要改進的地方有這些。1.在管理軟件的具體功能的生命週期方面能夠加以改進，將每一個方面的生命週期儘量具體的展示出來。2.規格說明書能夠更加細緻而且具備更加良好的閱讀性，使得開發和測試人員不會由於模棱兩可的語句而產生歧義。3.應當主動協調並決定各類需求的優先級，而不是直接將任務攤派下去，這樣就使得全部任務的優先級同樣了。4.帶領其餘成員確保項目保持功能，時間以及資源的合理平衡。在績效考覈方面，如今的貢獻度就是一個很好地績效考覈策略。

對於軟件工程的理論，規律有什麼心得體會或不一樣意見？請看閱讀做業。 (這個做業的期中閱讀)

在軟件開發的過程當中，設計模式是很是的重要，當時在上設計模式的課時，以爲這個課程很是的枯燥無聊，也不知道學了有什麼用。然而在軟件開發過程當中，卻發現，若是選擇了正確的設計模式，會使軟件開發事半功倍，同時軟件的穩定性以及可擴展性也會很是好。還有就是關於軟件測試部分，對於軟件也是相當重要。由於軟件測試能夠發現一些日常根本察覺不了的bug，從而大大提升軟件的可靠性。還有就是軟件開發的瀑布模型有很大的缺點，那就是若是使用瀑布模型開發軟件，後期需求若是有較大更改的話，整個開發會變的很是的麻煩，甚至要推倒重作。同時敏捷開發的缺點也十分的明顯。敏捷開發因爲是在每個階段都進行一輪的開發，測試與發佈，這種開發模式能夠很好地適應用戶需求的變化，可是對於開發人員來講工做量很是繁重。總而言之，就是每種開發模式都有本身的缺陷，只能說沒有最好的開發模式，只有適合的開發模式。

9、會議照片

10、交換組員的交接和培訓方案在進行組員交接的安排上，首先對新進來的組員舉行一個歡迎儀式。而後對他介紹咱們的項目（小人大做戰）的詳細狀況。而後讓他閱讀一下以前發過的博客，其中重點是需求文檔和設計文檔。而後具體對咱們組被交易的組員（歐福源）目前的工做進行介紹而後讓他們兩個重點進行任務對接。培訓方式，以任務分配的針對性教程爲主，包括官方教程與項目文檔和資源包教程的針對內容。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。

過後諸葛亮(葫蘆娃隊)

目錄