我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
要做一個遊戲，定義的很清楚，實作出來的效果貼近定義，對使用者和場景有清晰描述
我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)
原計劃目标提早實作，還多做一些額外的功能
和上一個階段相比，團隊軟體工程的品質提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
提高了，在代碼管理和代碼測試方面，具體來說規範了commit和實作了代碼覆寫率測試
使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
基本一緻，增加了詳細的新手引導，優化了使用者體驗，離目标更近了
有什麼經驗教訓? 如果曆史重來一遍,我們會做什麼改進?
吸取了上次的教訓，我們這次的設想與目标較為接近，基本不需要改進
是否有充足的時間來做計劃?
很充足
團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
開會讨論，然後投票
你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
計劃的都提前做完了，還做了很多額外的工作
有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
有一些，比如UI的改進完成後發現沒原來的效果好又換回去了
是否每一項任務都有清楚定義和衡量的傳遞條件?
有大緻的傳遞條件，跑起來大家覺得沒問題就行
是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
基本按計劃進行，意外時策劃換人了，但是屬于估計内
在計劃中有沒有留下緩沖區，緩沖區有作用麼?
有，拿緩沖區做了額外的内容
我們學到了什麼? 如果曆史重來一遍,我們會做什麼改進?
組員們的工作效率有點高，下次會做更多的計劃
我們有足夠的資源來完成各項任務麼?
基本足夠，在3D模組化方面沒有相關人才，隻能找免費資源
各項任務所需的時間和其他資源是如何估計的，精度如何?
由PM和負責人溝通來估計時間，精度還不錯
測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
測試方面比較足夠。沒有低估難度，但模組化資源确實不夠，總是做不出想要的效果
你有沒有感到你做的事情可以讓别人來做（更有效率）?
沒有
找一個會模組化的男生
每個相關的員工都及時知道了變更的消息?
知道，因為每天開會
我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
一開始定下需要完成的基本任務，以基本任務優先
項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
定義的比上次清晰，我們達到了我們定義的做好了的标準
對于可能的變更是否能制定應急計劃?
沒有提前制定計劃，有機動人員負責應急
員工是否能夠有效地處理意料之外的工作請求？
能
這次做的比上次好，基本不會有改進
設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
在開發還沒開始的時候，由主策劃和其他策劃完成，是合适的時間合适的人
設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
沒有，因為模棱兩可的上次都解決了
團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
有用畫圖工具（sketchbook、ps、ai）幫助設計。設計文檔有小改進，考慮了更多的細節
什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
螢幕适配功能問題較多，釋出後發現不同機型會出現一些特殊的bug，光線渲染表現也不一樣。因為沒有經驗，沒考慮這麼多
代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
代碼複審沒有進行，代碼規範比較嚴格
寫代碼前要考慮不同平台的适應問題，不要進行這麼多修修補補
團隊是否有一個測試計劃？為什麼沒有？
有測試計劃，邊寫邊測。最後釋出後有一個機型測試
是否進行了正式的驗收測試？
是
團隊是否有測試工具來幫助測試？
unity自帶的testrunner工具，CodeCoverage插件
在釋出的過程中發現了哪些意外問題？
吸取了上次的教訓，這次在釋出上沒碰到嚴重的問題，主要是不同手機的自适應問題
會中途就測試不同的手機
團隊的每個角色是如何确定的，是不是人盡其才？
角色是自主報名+PM調配，是
團隊成員之間有互相幫助麼？
有，幫的還蠻多的
當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
頻繁溝通，避免沖突出現；如果沖突出現則交流解決；減少每次commit的工作量，頻繁commit
公開感謝
黃賢昊 我要感謝何瑞幫助我處理了技術部落格的問題
何瑞 我要感謝吳昭邦和馬嘉幫我完成了Unity測試部分的工作
朱俊豪 我感謝吳桐雨對我的幫助，因為：具體設計了部分界面UI；
我感謝何瑞對我的幫助，因為：協助調整了場景光源；
我感謝馬嘉對我的幫助，因為：優化了合成效果(齒輪）；
我感謝黃賢昊、何瑞對我的幫助，因為：提供了部分遊戲背景音樂。
梁河覽 我感謝吳桐雨對我的幫助，因為在Beta階段她和我一起做新手引導，當時互相幫做工作。
吳昭邦 我感謝馬嘉對我的幫助，因為他幫助我更換了齒輪模型。
吳桐雨 我感謝朱俊豪、梁河覽、黃賢昊對我的幫助，因為前兩位同學在我不會導入素材走投無路的時候非常熱心地幫我解決問題，後一位同學在我不會設計關卡走投無路的時候非常熱心地為我指明方向。
馬嘉 我感謝梁河覽對我的幫助，因為他幫我接手了新手引導部分的工作。
你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
管理級
你覺得團隊目前處于萌芽/磨合/規範/創造階段的哪一個階段?
心态到了創造階段，但是技術和能力沒到（主要在模組化方面）
你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
有了美術同學，美術方面有很大改進，還有新手引導和使用者體驗。會在開發中導出中間版本，即時根據回報修改計劃
你覺得目前最需要改進的一個方面是什麼?
遊戲的難度曲線存在一些問題，最後幾關相比之前較為簡單
對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
盡早并持續地傳遞有價值的軟體以滿足顧客需求
在Beta階段開發中有持續導出中間版本并收集和回應回報
經常釋出可用的軟體，釋出間隔可以從幾周到幾個月，能短則短
Beta階段基本一周釋出一個版本
無論團隊内外，面對面的交流始終是最有效的溝通方式
雖然由于疫情原因無法見面，但我們幾乎每天通過騰訊會議溝通
可用的軟體是衡量項目進展的主要名額
我們組衡量一個工作是否完成的主要方法就是看這個功能在實際軟體中的效果
隻有不斷關注技術和設計，才能越來越靈活
遊戲方面經常出現需要學習的新内容，例如新手引導時的gif視訊導入，我們團隊一直在學習新的技術
保持簡明——盡可能簡化工作量的技藝——極為重要
Beta階段簡化了成本和分數系統，讓其簡單易懂。簡化了合成指南，去除了其中備援的資訊
以有進取心的人為項目核心，充分支援信任他們
程式總能提前完成任務，鼓舞團隊士氣，PM也常常提出指團隊前進方向，合理的配置設定最适合的人完成任務
代碼管理的品質具體應該如何提高？ 代碼複審和代碼規範的品質應該如何提高？
代碼管理沒有太大問題，沒有提高需求
整個程式的架構如何具體提高？ 如何通過重構等方法提高品質，如何衡量品質的提高？
寫之前思考架構，盡量避免重構
其它軟體工具的應用，應該如何提高？
unity功能強大，本身支援很多插件
項目管理有哪些具體的提高？
任務粒度分的更細，提前準備任務提前完成後的後續任務
項目跟蹤使用者資料方面，計劃要提高什麼地方？例如你們是如何知道每日/周活躍使用者等資料的？
由釋出平台的回報，由于是單機遊戲是以沒有活躍使用者，計劃提高使用者回報，在遊戲内提供回報接口
項目文檔的品質如何提高？
目前品質挺好的
對于人的上司和管理， 有什麼具體可以改進的地方？
績效考核上對任務工作時間有更細的評判
對于軟體工程的理論，規律有什麼心得體會或不同意見？
成員
心得與體會
何瑞
β階段的收獲就是深刻地感受到設計階段的重要性。在遊戲的設計之初，我們其實并未明确的定義各個關卡中哪些元件是可重用的，形成一個技術文檔，是以開發後各個關卡中備援的prefab比較多，後期調整各個關卡都有的元件時發現要對每一關都做調整，而不是隻用改一個prefab，這非常不簡潔。其次就是加深了對Unity的了解，結合官網手冊和百度解決了不少開發中的實際問題。
馬嘉
我在beta階段，更加深刻地了解了軟體工程項目的理論，了解了軟體工程項目中各個角色的定位和職責。還有就是體會到了軟體工程項目中，成員之間的溝通很重要，溝通能提高效率。
吳昭邦
技術方面。主要學習了如何利用unity實作簡單遊戲功能，還學習了unity裡的動畫控制和坐标關系等知識
團隊方面。鍛煉了團隊交流和團隊協作的能力，作為一個大的項目，團隊成員之間的合作非常重要，因為一個環節的完成情況會影響到其他的環節，是以大家都會互幫互助，争取盡早盡好地完成任務。而且和一個團隊的成員在一起工作還會各自學習到他人解決問題的方法，他人思考問題的方式。大家通力合作，最後可以說是完美地完成了這個軟工項目，這個過程用到的所有方法所有交流都是寶貴的經驗。
黃賢昊
在Beta階段，作為一個PM主要學到的東西是如何為團隊介紹一個新成員，包括對新成員的上手引導和工作安排，這些工作都是以前沒有預想過的。另一方面，在軟體開發上，我認識到了中間版本的重要性，通過釋出中間版本，可以即時發現一些bug和設計上的問題，即時調整開發内容和方向
梁河覽
在Beta階段學了很多東西。更了解怎麼合理分工，然後有問題的話隊員之間讨論解決問題，互相幫助工作。學了unity上的很多功能。
現在我感覺我的unity能力進步很大。
吳桐雨
經過Beta階段的學習，靈活開發的思想已經直擊我的靈魂深處，密集的會議與交流幫助我快速熟悉了工作，頻繁傳遞新版本能幫助大家不斷審視過去的工作進而進行改進。然而，由于前期的爆肝，我的身心已經不堪重負了。我建議在個人項目與結對項目期間能少些部落格作業，讓下屆小同學能有一顆健康的肝髒。
朱俊豪
回顧整個課程，我們學習到了一些軟體工程的理論知識，并且以實踐體會學習，我們團隊做了一款具有教育意義的程式設計啟蒙遊戲。在團隊開發的過程中，采用“靈活開發”的方式，以需求為目标，與隊友的讨論合作令人進步。對該課程而言，學習到軟體工程知識是較重要的。課程組應以更具體的方式考察各組對軟體工程知識的實踐。
