過後諸葛亮

時間  2019-11-09
標籤 過後 简体版
原文   原文鏈接

項目Alpha衝刺（團隊) --過後諸葛亮

一、團隊信息

隊員學號 隊員姓名 我的博客地址 備註
221600427 Alicesft https://www.cnblogs.com/LinkF/
221600429 哈噻 https://www.cnblogs.com/liujianhao21/
221600436 Xu~ https://www.cnblogs.com/xzh0517/
221600437 AWX https://www.cnblogs.com/hawx/ 隊長
221600438 ZHC https://www.cnblogs.com/mzhc/
221600440 小冰 https://www.cnblogs.com/xiaobing666/
221600441 拉哇吉 https://home.cnblogs.com/u/banglc/

二、設想和目標

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

答：咱們要開發一款基於三國題材的卡牌通關對戰手機遊戲並附帶遊戲官網。經過屢次答辯與修改咱們對用戶和場景的描述還算清晰。前端

  1. 咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？ )

答：遊戲端和官網的α衝刺計劃都按時昨晚並提交了。laravel

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

答：上一階段主要都在作設計、需求這塊，質量主要體如今分工和討論的結果，這一階段是實現代碼階段，定義好接口和代碼規範以後編寫速度加快。git

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

答：在實現過程當中沒有出現什麼大問題。重來一遍的話，可能會盡可能再美化一下界面。github

三、計劃

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

答：是的，可是由於計劃有時候因技術的認知不到位或者是由於需求有着一些變化總會存在 誤差，因此，後期計劃可能與實際狀況存在一些誤差數據庫

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

答：先是提出不一樣意見，在討論以後，經過投票作出最後的決定。編程

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

答：原計劃任務已按時完成，完成了項目預期的驗收標準。後端

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

答：是的，在完成數據處理接口的以後發現有更好的方法或者是不太符合規範，那麼就須要進行修改。服務器

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

答：有的，經過原型設計、需求分析、以及功能驗收標準來定義和衡量。網絡

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

答：所有按照原計劃進行不太可能，由於這個項目的任務具體到了天，因此，當隊友有一些事情不得不處理的時候，就須要協調其餘組員來一塊兒完成或者是計劃在不偏離最終目標的條件下作必定程度上推遲。或者是當對技術的認知不清楚的時候，就須要從新安排時間學習新技術，在短期內改變計劃但不會影響最終的進度，因此計劃在整體上是有有序的，但在局部會存在變動。架構

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

答：有留下緩衝區，在每項短時間計劃當中，都有留有一天的時間做爲緩衝區；
有用到緩衝區，首先，任何的項目計劃都有可能存在誤差，首先，組員都是沒有任何項目經歷的萌新，對項目的預期估計存在誤差確定離不開這方面的緣由，另外，組員的技術認知以及掌握程度都不深，很難對技術需求以及完成計劃作出準確的預估，因此留有緩衝區解決以上的問題是十分必要的。

  1. 未來的計劃會作什麼修改？

答：在計劃上，仍是留下緩衝區的；緩衝區是給在項目出現非可控因素致使的計劃沒法預期完成的意外留下的，前期的任務會比較繁重（天天的任務時間較以前可能會有所加劇，因此增長該課題的時間成本是十分必要的）。雖然會比較累，可是留下這個緩衝區仍是十分必要的，由於咱們永遠沒辦法意外會在哪一個時候發生。

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

答：整個項目的規劃以及實現，讓咱們真真切切地感覺到了完成一個項目的所須要付出的東 西的確有不少，難度與複雜度也不是通常的高，好比需求的調研，分析，給出預期的原型設計，完成類圖等等對項目的分析與規劃；各類各樣的任務，須要經過組員之間的溝通與協調組員的才能的發揮，在最大程度上實現我的與項目利益的最大化。

若是再來一遍，須要在需求分析階段，把需求用例好好的梳理一遍，是十分必要的，這樣纔可以更加的明確整個項目的目標，否則在前期的時候，很難對項目造成一個有效的認知。而且在任務的安排上仍是須要有一些改進，充分發揮各組員的才能與調動組員的積極性。

四、資源

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

答：時間還算足夠，但先後端，unity都採用了框架來開發都須要時間來學習，測試都有自帶的工具，資源豐富還能夠。在網上和淘寶收集到了大量的圖片資源。

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

答：先劃分任務，而後我的根據自身狀況接受任務，時間精度很粗略，都是一個任務完成再作下一個任務。

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

答：人力、軟件資源充足，測試方面，遊戲端，和官網後端都有自帶的測試工具，資源相對充足。編寫前端時，對那些圖片的像素處理是真的煩，美工仍是很重要的。至於硬件方面,咱們目前擁有的硬件足以支持咱們的開發須要,可是後期若是項目上線的話目前的硬件水平遠遠沒法知足實際須要

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

答：我以爲若是讓一個熟悉所用的框架的人來編寫，無論是時間仍是作出來的質量應該都會更好。

五、變動管理

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

答：有，在作完必定量工做時都有進行彙總和商討，同時隊友也能經過github清楚的瞭解到工做進度。

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

答：通常是當一項任務的完成做爲被其餘多個任務所依賴時，以及根據咱們最初的設計，所要達到的基本功能還有做爲最基礎的底層設計是必須優先實現的，而當一項任務較爲獨立或者在開發過程當中想出的新的不錯的點子則能夠做爲推遲實現的。

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

答：有，就這個項目來講，網站上可以容許用戶註冊登陸查看資料，和遊戲中基本的聯網對戰和必定數量的卡牌保證可遊玩性是做爲「作好了」的最基礎定義，其次再加上較爲符合審美的美術和無嚴重噁心BUG就可以達成咱們認爲的作好了。

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

答：這方面在出現較大的改動（好比遊戲玩法，核心機制）時可能比較難制定出應急計劃，當要是較爲合理地變動（好比戰鬥方式，卡牌設計，UI設計）

六、設計/實現

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

答：在作完需求分析以後就開始了，官網和遊戲分爲兩批人，咱們認爲算是比較合適的時間，人員也是選擇對這些方面有着較深瞭解的人，算是挺合適的。

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

答：有，通常是經過反覆討論最終統一，期間有互相否認提案也有出現相同提案的狀況，整體上是先討論總體再討論細節，細節部分有着比較多含糊之處，花了較多時間討論。

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

答：主要使用UML來進行設計，還有經過製做原型表現可視化設計。雖然在前期的設計就已經對UML類圖、流程圖之類進行了反覆細化和修改，但在開發

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

答：UI的表現層，由於效果的顯示老是比較難表現，其中的邏輯也比較複雜。出現過許多莫名其妙的bug（例如卡牌不顯示或飛走不見之類的）。這主要是因爲代碼的邏輯bug還有對技術掌握的還不夠成熟，其中的原理不夠了解致使的。

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

    答：代碼複審是經過人工本身閱讀代碼再結合工具（例如Resharper之類）。嚴格執行了代碼規範，由於經過使用Resharper可以清晰的看到哪一處的代碼不規範。

七、測試/發佈

  1. 團隊是否有一個測試計劃？
    有

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

答：尚未 由於沒有作到可驗收的版本 可驗收版本將在Beta版本作完

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

答：網站部分主要使用框架自帶的dd打印函數以及一些自帶的驗證函數在開發功能時進行監控測試

咱們完成的Unity 基礎UI 及卡牌的腳本基礎腳本部分不是很須要測試工具測試 沒有使用工具

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

答：Unity 自帶的性能顯示工具 ,使用Apache Bench來測量服務器關鍵接口的QPS

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

答：laravel 本地環境參數 和服務器上不同 ,須要手動設置

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

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

答：每一個人先在一個表格中填入本身擅長的領域,而後根據任務的內容大體肯定每項任務須要的人數,剩下的就全憑我的手速了,這樣作可能會有少數人並未被分配到本身想作的領域 可是由於團隊規模較小,不可能作到團隊成員完美匹配項目

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

答：固然 每一個小項目的劃分都是兩我的以上爲一小組,這樣便於互幫互助 ,此外遇到較爲棘手的難題是會在小組會議上提出 尋求你們的意見及建議
例如在網頁端的上線的時候,遇到中間件搭建的問題,咱們向負責遊戲的同窗尋求了幫助最後成功解決了問題

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

答：項目管理並沒遇到什麼比較嚴重的問題,你們都很是自覺的按時保質保量完成前期計劃要求的進度,而合做方面衝刺階段天天的例會主要解決的就是這個方面的問題.

九、總結:

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

答：達到了CMMI()的程度。咱們團隊遵照了既定的計劃和流程，有資源準備，權責到人。可是尚未一套完整的管理措施，沒有制度化。

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

答：規範初期

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

答：已經有良好的溝通交流能力，團隊合做能力和默契能力也在不斷提高，開發效率有很大提升

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

答：界面的UI是最讓咱們這些不擅長美工的人困擾的

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

答：團隊按期檢討如何可以作到更有效，並相應調整團隊的行爲。過後諸葛亮便是如此。
不管是團隊內仍是團隊間，最有效的溝通方法是面對面的交談。咱們團隊每週都會進行一次例會，把開發過程當中遇到的問題提出來進行面對面溝通交流。

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

答：堅持在開發過程當中將遇到的問題進行面對面交流，出現問題及時修復，不能囤積致使後期工做量增大。衝刺階段天天的博客須要認真完成，總結反思一天下來的工做狀況。

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

答：關於代碼規範和複審：採用一些成熟的大型公司提出的標準來執行，這樣即可以全面的考慮到各類代碼的可讀易讀，又能夠確保沒有歧義；須要有良好的編程習慣，作好代碼中的註釋；第三，咱們還必須考慮到代碼的美觀，須要使用一致的縮進
關於代碼複審： 審覈發現的問題，應該由代碼編寫者本身去修正或者重寫
關於提升代碼管理質量：不要複製代碼；及時測試完成的代碼；進行代碼審查；將整潔的代碼風格做爲一種習慣，時刻意識到整潔代碼的重要性並不斷地提升重構技巧

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

答：模糊不清的方法名會影響代碼的可以使用性。這些模糊不清的名稱應該重命名爲有意義的可能與業務術語有關的名稱，來幫助開發者經過業務上下文 更好地理解代碼。

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

答：軟件工具主要分爲項目管理工具、配置管理工具、分析和設計工具、程序設計工具、測試工具以及維護工具，下一階段咱們要掌握的主要的維護工具，這一方面打算查找視頻進行自學

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

答：綜合管理能力有很大提升，同時學習了更多的知識，不只僅是技術方面的還有人力資源管理、項目管理專業知識等方面。培養了情境領導、人際關係、談判與溝通等技巧能力。

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

答：到網上查找一些已完成的比較成功的項目的項目文檔來瀏覽學習，同時也能夠參考同期優秀小組的項目文檔。

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

答：既然組內已經達成一致要完成一個項目，那就確定每一個人心中都有本身想要作的工做，就例如，有的同窗想作前端，有的想作後臺。按成員意願分配任務。同時能力較強的成員在完成本身的任務後能夠幫扶一下能力較弱的成員。

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

答：軟件工程的概念貫穿了整個項目，從一開始的項目選題到需求分析再到最後的項目版本發佈與後期維護。而項目管理及並不像想象中那麼容易，即便是三年的同窗也不可以配合的盡善盡美。

十、會議照片:

十一、交換組員的交接和培訓方案

換走的成員在團隊中主要負責官網的搭建，交接和培訓任務主要在交接學習資料，工做現場等並幫助新成員上手融入新團隊中。主要有如下幾點

任務交接部分：

  • 整理開發過程當中的接口文檔，即Laravel框架中路由、控制器和視圖的約定、文件管理要求等

  • 移交自學所參考的網絡文檔和視頻教程，幫助瞭解開發任務

    開發培養部分：

    咱們的官網開發主要是使用Laravel框架，開發培養任務主要在於培養新成員的官網開發能力
  1. 大體先對composer類庫管理工具備必定的瞭解，再熟悉Laravel項目的文件結構
  2. 開始瞭解路由、控制器和blade模板視圖三者的配合，對數據庫和Eloquent等作適當瞭解

  3. 對於其餘具體的使用不懂就問度娘

    身爲團隊的前成員，小冰策劃有話說：遇到小問題儘可能本身嘗試解決,這對新成員的融入有幫助，實在不清楚的地方，例如項目後期也許會遇到遊戲與官網對接調整的問題，這涉及到Laravel底層實現的修改，我也會幫忙的

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程