設想和目標
-
我們的軟件要解決什么問題？是否定義得很清楚？
我們開發的軟件為一款3D手機游戲，旨在與市場上已有的“自走棋”類型的游戲競爭，一來利用移動端優勢凸顯手游的輕量化，使得用戶可利用碎片化時間游玩，二來通過游戲內的局域/廣域網聯機功能使用戶可以享受到快速方便的社交功能。但相比於其他團隊，上述中玩家的痛點並不明顯或重要，軟件整體相比於同類游戲競力有限。
-
是否對典型用戶和典型場景有清晰的描述？
對於用戶分析，我們在分析階段列舉出了四種典型的玩家群體，分別為大、中、小學生與專職游戲主播。典型用戶的構造有以下問題：1.用戶特點中主要考慮的是用戶的游戲時間/支付能力，而用戶對“自走棋”的游戲機制與策略游戲的可接受度，是分析時有所忽略的 2. 四種用戶群體交集過小，典型用戶跨度大而單類用戶描述不夠詳盡，以致參考價值有限。在發布階段中，團隊推廣時面向的群體也基本是校內大學生群體，無法說明其他典型用戶的潛在比例。
-
原計划的功能做到了幾個？ 按照原計划交付時間交付了么？
在原計划中，游戲整體將具有以下功能：游戲對局內戰斗，卡牌管理，難度等參數設置，局域網聯機，特殊卡牌等功能，而α階段中的目標與實際完成的為前三者。交付按時完成，但形式上有變化，原計划5月5日在華為應用商城，Taptap等平台上線游戲，由於一切中國大陸游戲必須進行獲得游戲版本號，平台不允許軟件上架，故團隊制作了網頁的發布平台與反饋博客。
-
原計划達到的用戶數量達到了么? 用戶量，用戶對重要功能的接受程度和我們事先的預想一致么？我們離目標更近了么？
目標用戶數量為："α階段軟件發布一周后軟件下載量大約在100人左右，活躍用戶量預計只有20-50人"（NABCD分析），實際中截至5月14日前，游戲服務端統計到軟件累計注冊人數為82人次，下載量估計大於等於注冊人數。而活躍用戶量（即在首次游玩后又在5天內重新登錄的用戶）達到了43人次，原計划中的用戶數量已基本達到。根據用戶反饋，主要意見為“游戲內容過少”，一方面α階段無聯機功能，游戲性有一定折扣；另一方面α階段中游戲元素較單一，僅有召喚物卡牌，場景僅5張地圖。
有什么經驗教訓？如果歷史重來一遍，我們會做什么改進？
- 在有限時間內作更加充分的調研，開發前收集更多的用戶需求反饋，合理評估項目/軟件的價值。
- 更理性評估開發技術棧，α階段中大部分成員是跨自身技術棧開發，如果歷史重來一遍，團隊將從項目質量保證與開發工作量兩方面權衡技術選型。
- 突出差異化功能，α階段沒有准確定位軟件及其核心差異化功能，導致開發工作缺少重心，較競品軟件特點不突出。
計划
-
是否有充足的時間來做計划?
事實上，我們做計划的時間是比較緊的，沒有特別充裕的時間來做計划。
首先在選題階段，由於我沒需要在3天時間，就完成選題，完成基本需求分析，以及拍攝項目介紹視頻，在這個階段我們沒有考慮項目計划；
然后是進一步需求分析形成技術規格說明書和團隊貢獻分分配原則，雖然給了一周的時間，但完成這個作業我們查找了許多資料，參考了許多的往屆博客，開展了討論，進行了調研；這個階段我們也沒有太多時間做計划。
好在我們英明的PM-lcy同學，考慮到了我們alpha階段的計划部署，為我們擬定了初步的計划，並根據意願優先原則做了初步的分工，到了我們alpha階段的第一次meeting，我們已經形成了初步的計划框架，經過了1h左右的進一步討論，我們敲定了alpha階段項目的計划，包括在什么平台進行開發，到測試階段前的任務分解和分配，軟件后續發布和推廣的基本擬定，還找到了我們項目的模型素材和基本框架。
-
團隊在計划階段是如何解決同事們對於計划的不同意見的？
我們在敲定計划的階段比較順暢，基本沒有什么分歧，若有不同意見，我們會采用如下流程：
- 意見雙方各自發表自己的觀點；
- 其他成員各自發表自己的觀點；
- 若還不能解決分歧，則組內進行投票表決，或是由PM裁定。
-
你原計划的工作是否最后都做完了? 如果有沒做完的，為什么?
我們計划的工作基本做完了，但是由於交接工作的不到位，部分任務存在delay現象。
-
有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
在使用Unity內置的Plastic SCM進行版本控制后，還要用git進行重復的操作，而且不如Plastic直觀便捷，沒有實際意義。
-
是否每一項任務都有清楚定義和衡量的交付件?
對於前期我們計划中的分工任務，我們都有定義和一定的交付標准；
對於后期我們根據實際情況改變和增加的任務，我們沒有明確在書面上做出定義和交付標准，因為時間確實比較緊急。
-
是否項目的整個過程都按照計划進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
整個項目基本按計划進行，但是在我們測試和發布階段，發現由於交接工作的不到位，音樂組件出現一些問題，這造成了一定的加班和延誤。
同時這也是我們沒有考慮到的風險，因為當時已經在測試的末期，產品即將發布，若出現臨時問題導致發布需要延遲，一定程度上影響用戶反饋和意見收集，以及我們后續階段的工作部署。
-
在計划中有沒有留下緩沖區，緩沖區有作用么?
計划中留下了一些緩沖區，在測試階段若還有工作沒有完成，可以先忽略這一部分。
緩沖區作用似乎並不大，因為我們最后發現出現問題的時候，已經是測試階段的末期了。
-
將來的計划會做什么修改？
總的來說，alpha階段我們的開發基本順利，出現的一些問題是由於交接工作的不到位造成的；在beta階段我們會加強交流工作，不僅是任務小組內的交流，還有任務小組間的交流。
我們學到了什么？如果歷史重來一遍，我們會做什么改進？
-
在alpha階段，我們進行了團隊合作和軟件開發的體驗，我們學會了軟件項目，不僅僅是電腦前敲代碼，還有團隊交流，相互幫助解決困難，還有產品的發布和推廣，收集用戶意見進行改進，以及總結和展示成果。
-
如果歷史再來一遍，我們會加強交流工作，任務小組內部先交接好，保證各模塊沒有問題，再和其他任務小組的模塊進行交接。
資源
-
我們有足夠的資源來完成各項任務么?
只要肯找，資源總是有的。從結果來看，確實有足夠的資源來完成各項任務。
-
各項任務所需的時間和其他資源是如何估計的，精度如何?
基於難度與現有開發經驗進行估計。對於技術學習、游戲邏輯、布局框架等方面的估計還是比較准確的，但細節方面(如UI的調整等)則低估了需要的時間。
-
測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
測試的時間和人力基本足夠，但硬件資源不能說足夠。主要原因為安卓機型五花八門，不同機型可能有着很大的區別，想要測試完全幾乎不可能。
-
你有沒有感到你做的事情可以讓別人來做（更有效率）?
大家基本沒有這種想法。由於大家基本都沒有接觸過unity，每個人的學習路線基本都被任務分配給特化了，因此不存在這種情況。
我們學到了什么？如果歷史重來一遍，我們會做什么改進？
- 團隊成員之間的溝通是非常重要的，發現問題要及早提出；另外，測試也非常重要。如果重來的話，我們會預留更多的時間來進行測試。
變更管理
-
每個相關的員工都及時知道了變更的消息?
是的。
-
我們采用了什么辦法決定“推遲”和“必須實現”的功能?
首先根據Alpha階段指定的的功能規格說明書中所明確的必須實現的“主干功能”，如“游戲對戰demo”，“對戰邏輯”，“登錄注冊模塊”，“卡牌管理模塊”，是無論如何都要在Alpha階段完成的，並且需要進行多次迭代，PM則根據例會中各組的進展匯報來進行下階段迭代中“必須實現的功能”相關工作的部署。
而對於“非主干功能”，如“音樂音效設置”，“UI細節設計”等，則由PM根據工作燃盡圖與各組隊員目前的主干任務完成情況來進行斡旋抉擇，即是否“推遲”。
-
項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?
采用ISO/IEC 25010:2011國際軟件工程產品質量標准來對Alpha階段的軟件項目是否滿足出口條件進行評估，評判指標主要分為功能適用性、性能效率、兼容性、易用性、可靠性、安全性、可維護性、便攜性八個方面進行評估，具體參見Alpha階段總結 - 軟件質量評估模塊
-
對於可能的變更是否能制定應急計划?
能，對於可能的變更制定應急計划的能力依賴於不同小組間交流協作能力，與PM的統籌安排能力。
-
員工是否能夠有效地處理意料之外的工作請求？
我們在需求分析與任務划分初期將整個項目分為：前后端鏈接、UI設計、對戰demo設計三大板塊，每個板塊由不同組的同學負責，並且由於在Alpha階段啟動初期，所有同學花費了一周的時間對自己負責板塊的基礎、拓展知識與技術棧進行了全方位的學習，因此當遇到意料之外的工作請求時，每個同學都能有效地對其進行處理。
設計/實現
-
設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
計工作是在alpha開發階段的開始制定的，由PM組織大家商量、由有玩過多種游戲經驗的嚴宇皓和對於功能相似的游戲比較熟悉的李辰洋主要設計，其他人負責補充完成的。由於我們在一開始就設計好了游戲，因此后面不需要重構，開發過程也較為順利；主要設計者對整體的架構掌握較好，因此他們是合適的設計人選。
-
設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
在設計的時候我們積極撰寫開發文檔，對於功能的要求和預期情況都說明的較為清楚，因此沒有碰到模棱兩可的情況。我們團隊解決這類問題的最好辦法就是把溝通和修改放在開發前面，強調並保證了溝通的有效性，從而避免這種情況出現。
-
團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？ 比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
我們使用了UML來幫助我們進行設計和開發，它對於我們后續的開發具有重要作用。UML圖很好的展示了整體項目的架構，幫助大家理解其他人的工作，找准自己在項目中的定位。此外，UML圖很好的幫助我們理清了整體的思路，明白各項工作的前后順序，使工作有條不紊的進行。項目開始時的UML文檔只有項目總體架構，沒有過多的設計具體的細節。現在的UML文檔中包含了各個部分的UML文檔，在初始UML的基礎上補充和完善了大量的細節。這實際上是開發過程中一個必然的現象，UML圖會隨着功能完善而更加完備。我們的UML圖在團隊內部的石墨文檔上有共享，每次會議討論過后都會更新UML文檔。
-
什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
在用戶登錄界面產生的Bug最多，因為這部分涉及到的邏輯較多，包括前后端交互、界面跳轉邏輯等。在發布以后，由於我們的密碼是以明文傳輸的，因此會被截獲，造成用戶的信息泄露。由於一開始設想是單機游戲，並沒有考慮登錄，是課程要求統計訪問量以后才新加的，測試不夠嚴密，開發比較匆忙導致了這種情況的發生。
-
代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
代碼復審是由負責同一模塊功能的同學交叉審查來完成的。我們在審查過程中，首先查看代碼的注釋是否規范，函數依賴關系、調用關系是否清晰，整體功能和邏輯是否與預期相符；然后，再深入審查，逐行檢查代碼中是否有未考慮的情況，有沒有未初始化的變量。總體而言，我們較好地執行了代碼規范，組內同學對其他人的代碼較為滿意。
我們學到了什么？如果歷史重來一遍，我們會做什么改進？
- 首先，我們學習到了溝通和交流的重要性，在任務開始之前盡早溝通，明確任務和責任的划分，對提高我們的代碼開發效率、避免反復重構具有重要意義。然后，我們學習到了代碼規范的重要性，多加注釋、進行代碼復審有助於我們在開發過程中盡早發現代碼中的問題，縮短debug時間。如果能夠重來一遍，我們會在一開始制定任務時更加合理的分配工作量和工作情況，盡可能減少組內有人完成了任務而無事可做、另一些同學由於任務量較大而無法完成對接的情況。此外，我們還會更加重視用戶的安全性保護，花更多時間在用戶安全性功能的設計上。
測試/發布
-
團隊是否有一個測試計划？為什么沒有？
團隊測試計划見Ghost Tactics測試報告
-
是否進行了正式的驗收測試？
在發布前進行系統的驗收測試。
-
團隊是否有測試工具來幫助測試？
Unity中使用NUnit進行單元測試，后端使用Django自帶的測試框架進行自動化測試。
而對於場景測試，平台兼容性測試，只能進行人工手動測試。
-
團隊是如何測量並跟蹤軟件的效能（Performance）的？壓力測試（Stress Test）呢？ 從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
用Unity Test Runner運行性能測試，僅進行測試，由於在各種機型上游戲運行流暢，因此不大需要對性能結果進行分析。
-
在發布的過程中發現了哪些意外問題？
發布中apk包名錯誤，icon缺失，且在一款特定機型上出現花屏，可能原因是該機型顯示驅動不兼容的問題，該問題更多的應由ROM廠商負責。
我們學到了什么？如果歷史重來一遍，我們會做什么改進？
- 平台兼容性測試要盡量尋找更多的真機進行測試，然而，普通開發者團隊並不能尋找到十分全面的機型，這時，就需要展開公測，面向大眾進行測試，這樣在測試的覆蓋面上將會更寬更廣。
- 另外，我們的后端並未進行壓力測試，其中原因主要為本階段對后端的服務訪問量不大， 然而在下一階段，需要同在線玩家共同聯機游戲，這就可能造成大量的訪問量，而壓力測試也就必不可少了。
團隊的角色，管理，合作
-
團隊的每個角色是如何確定的，是不是人盡其才？
在角色分配之前，通過面對面的開會討論，確定最終的分工情況，首先要滿足每個人的最大興趣，興趣是最好的老師，而消極情緒一定會帶來低效率的工作，讓大家每個人選擇自己最願意的分工，正式其中的要義。
-
團隊成員之間有互相幫助么？
團隊成員經常性的交流溝通，讓問題及早的發現，也讓成員間遇到問題能夠共同解決，通常，在一個模塊的開發有困難時，其他成員都很樂意進行幫助。
-
當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
最好的辦法就是溝通，並且，最重要的是，平等，不要因為這個部分你懂而他不懂，就趾高氣昂，大家在交流、在開發中，都是平等相處的。
每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的博客里）：
| 成員 | 感謝信 |
|---|---|
| lcy | 我感謝yyh，因為某個具體的事情：在對接卡牌管理時十分的耐心和細致 我感謝qy，因為某個具體的事情：在場景設計上，對於我不是那么成熟的建議，保持着肯定的態度 我感謝zzx，因為某個具體的事情：在聯網開發中，提出了設計中存在的隱患，感受到了他的真知灼見 我感謝wcf，因為某個具體的事情：在項目聲音效果出現問題時，立馬放下自己的事情着手進行解決 |
| zsk | 我感激lcy，充分做好了Alpha階段一個PM該做的事，合理管理、分配了整個團體的任務 我感激yyh，同為UI設計小組的隊友，他用自己精湛的技術和一絲不苟的工作態度將我折服。 我感激qy，在場景與UI對接遇到問題時能及時找到問題所在，是不可或缺的優秀隊友。 |
| yyh | 我感謝lcy，因為他擔任PM，整個團隊在其管理下得以有序運行 我感謝zsk，因為他與我共同出謀划策、共同開發，完成了UI部分的編寫 我感謝zzx，因為他承擔了答辯的大部分工作，而我只是相應地在旁邊提供應援 |
| zzx | 我感謝qy，因為他主動擔任了場景開發組內的領導者角色，並承擔了大部分游戲場景/腳本的開發工作 我感謝yyh，因為在α答辯日時我所作准備不足，在提問時無法對一些問題給評委合理的解釋，是他及時幫助我完成應答 我感謝lcy，因為他是在進行服務端開發時兼任PM，工作量占比最大。同時在α階段中完整詳細制定開發計划，並保證進度的落實 |
| wcf | 我感謝lcy，因為他管理能力出色，將整個團隊的工作梳理得非常有條理 我感謝zsk，因為他勇於擔當，出現bug了總是第一個上去修復 我感謝zzx，因為他檢索素材又快又准，總是能夠找到合適的圖標和音頻 我感謝qy，因為他設計的地圖精美而巧妙，給予了我開發過程中較大的幫助 我感謝yyh，因為他的代碼書寫規范，接口定義清楚，與他對接時總是十分順利 |
| qy | 我感謝zzx，因為他在轉會期間挺身而出，在大家都不願意冒風險，離開當前上手的項目，去接受一個新的項目和環境的情況下，主動成為我們組轉會的人。 |
總結
-
你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
目前團隊處於CMMI中的Managed Level，在團隊的項目開發中，已有了需求管理，項目的計划、監督、控制，產品質量管理的基本項目管理手段和策略，但只有一個初步的過程標准化的概念，如項目源代碼管理、文件樹結構、代碼結構等標准的一個初步規定，但尚未到達下一階段。
-
你覺得團隊目前處於 萌芽/磨合/規范/創造 階段的哪一個階段?
團隊現處於磨合階段之后，且剛剛踏上規范階段的路途。各個規范的制定尚且沒有一個確定的形式，只是為了項目開發中的方便而進行口頭約定。
-
你覺得目前最需要改進的一個方面是什么?
目前團隊內部不夠活躍，在討論中大家還是有話不好意思說，需要更多的團隊凝聚力。
-
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
-
盡早並持續的交付有價值的軟件以滿足客戶需求。
在Alpha階段的開發中，我們致力於盡早完成能夠開始基本游戲的場景和demo，並在聽取周圍同學的意見上，美化卡牌展示UI、增加多個地圖場景等功能，以此更好跟進用戶的需求。
-
以有進取心的人為項目核心，充分支持信任他們。
充分支持團隊中的創新聲音，對於好的點子，即使多一些工作量，也要去完成。
-
無論團隊內外，面對面的交流始終是最有效的溝通方式。
遇到問題，遇到項目進度階段性變化，遇到需求的調整，以開會面對面商榷的形式進行溝通交流，保證信息的流通和交流的充分。
-
-
正如我們前面提到的， 軟件的質量 = 程序的質量 + 軟件工程的質量，那團隊在下一階段應該如何提高軟件工程的質量呢？
-
代碼管理的質量具體應該如何提高？ 代碼復審和代碼規范的質量應該如何提高？
在源代碼管理上，我們將繼續在Unity前端部分使用PlasticSCM版本控制軟件進行管理，他的優勢在我們的Alpha階段已體現的淋漓盡致，從場景模塊的沖突處理，到素材文件的快速PUSH、PULL，相較於gitlab有着更高的使用價值。
對於代碼復審，將繼續由團隊中同一組的其他組員對待審核人的代碼進行復審。
對於代碼規范，依舊依照Unity開發手冊進行。
-
整個程序的架構如何具體提高？ 如何通過重構等方法提高質量，如何衡量質量的提高？
下一階段，前端將引入多人戰斗模式，這一模式需要將AI和在線玩家進行抽象歸類，這一部分需要對程序結構進行微調，以達到更低的耦合性。
對於后端，在基於Django的框架下的開發已經能夠保持較好的模塊性。
-
其它軟件工具的應用，應該如何提高？
對於Android IDE的使用，需要更加熟練對多平台模擬器的建立，從而更好的對多平台下的兼容性進行測試。
-
項目管理有哪些具體的提高？
規范項目文件命名，依據不同功能進行歸類和排布。
規范git commit，依舊存在無意義commit msg的情況。
-
項目跟蹤用戶數據方面，計划要提高什么地方？例如你們是如何知道每日/周活躍用戶等數據的？
目前我們通過記錄用戶登陸時間和次數進行用戶數據跟蹤，接下來計划引入用戶游戲時長的計算來更好的跟蹤用戶游戲數據。
-
項目文檔的質量如何提高？
項目文檔也需要文檔復核，將交由PM對描述不清晰、不到位的地方進行追加補充。
-
對於人的領導和管理， 有什么具體可以改進的地方？
目前實行的團隊內小組分工制的管理結構是較為高效且合理的，PM只需要對小組之間進行協調，小組內自行進行分工調整和進度跟進。因此此處暫無需要調整的地方。
-
對於軟件工程的理論，規律有什么心得體會或不同意見？
軟件工程不只是算法和程序的結合，軟件=程序+軟件工程，這個公式在團隊開發中發揮着巨大的作用，在多人合作中，做到1+1=2是一件很難的事情，管理正是解決多人合作中諸多低效因素的最佳手段。
-
