我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
解決的問題和定義都在[軟軟軟]功能規格說明書和Beta階段的計劃中詳細說明了，都有典型使用者和典型場景的清晰描述。
我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)
原計劃的核心功能都完成了，非核心功能差兩個，分别是群組功能和設定頭像功能，由于沖刺後期有計算機網絡實驗和計算機網絡安全等課程結課導緻開發進度降了下來。
我們的Web應用一直在傳遞，每個核心功能都立即上線。
原計劃是達到300個翻倍，但是和學校公衆号的老師交流過後，認為我們使用的爬蟲技術不太适合大面積推廣，小面積内使用最好，是以在周圍進行傳播，沒有預期的使用校内公衆号宣傳，最後是從Alpha階段的148人到現在的239人，增長了91個使用者。
和上一個階段相比，團隊軟體工程的品質提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
項目的品質提高了，因為在Beta階段我們痛定思痛，借鑒其他小組的項目管理，在Gitee上使用issue和pr進行管理，得到的效果非常好，每一個遷入都有迹可循，每一個功能都有issue可循，每一個功能對應的負責人都十分明确，在最後的計算貢獻中也起到了非常有用的效果。
使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
使用者量239個，第一階段是148個，增加了90個，感覺足夠了。
大體上是一樣的，因為我們自始至終都是面向使用者需求開發，加入了課程的通知和期末考試的提醒，但也砍掉了一些小部分群體使用者的需求，比如課程的測試，這是我們小組讨論之後基于需求的重要程度做出的決定，階段性達成了目标。
有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
盡早使用Gitee、Github等成熟完善的項目管理工具，有了項目管理工具之後感受非常不同！
是否有充足的時間來做計劃?
有的，一周的時間做計劃，具體見UltraSoft - Beta - 設計與計劃。
團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
比如對于想要在這一階段加入的功能比較多，我們比較功能的重要性，按照使用者的優先級排序，征求實際使用産品的使用者的建議，比如課程中心的通知和測試，我們最後選了通知，因為通知面向的範圍更廣，測試面向的使用者群體很少。
你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
沒做完，在計劃階段還沒有烤漆安排，但是在Beta沖刺的最後階段有諸如計算機網絡實驗、計算機網絡安全等不進入烤漆的大作業需要完成，且工作量很大，是以有幾天的時間進展不多，導緻兩個非核心功能沒有完成。
有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
産品角度：沒有，因為我們的需求都是根據使用者的回報進行選擇篩選的，是以都是有需求的，比如使用者需求不是非常強烈的測驗功能砍去
開發角度：正式體驗了項目管理，使用Gitee進行團隊協作，非常有意義
是否每一項任務都有清楚定義和衡量的傳遞件?
有的，每一項任務都需要經過完善的測試才會納入到主分支，并且我們的産品的功能互相之間是互相分離的，大多是查詢任務，易于驗證正确性的，當正确性滿足時即可以傳遞。
是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
意外在于有幾門不進入烤漆的課程，如計算機網絡實驗、計算機網絡安全等課程的考核與Beta沖刺相撞，而且難度很大，導緻考核的幾天開發進度明顯減緩
在計劃中有沒有留下緩沖區，緩沖區有作用麼?
本來沒有設定，但是由于計算機網絡實驗、計算機網絡安全等課程的考核， 被動加入了緩沖區，在緩沖區内沒有大家的進度比較慢，是以之前沒有傳遞的功能可以趕上。
将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
拒絕加班，拒絕熬夜
我們有足夠的資源來完成各項任務麼?
有的，伺服器自給自足，也不需要項目資金；技術棧的學習資源豐富，使用的元件Vuetify有清晰的說明文檔。
各項任務所需的時間和其他資源是如何估計的，精度如何?
粗略根據項目粒度的大小，如增加新的闆塊——消息中心，還是增加舊有闆塊中新的功能——課程中心的課程通知，明顯兩者的任務量是不一樣的，在預估的時候考慮到組員們其他課程的學習，都進行了放大的預估，大多數計劃都提前完成了。
測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
相當夠，由于模版選的好，并沒有特别重的美工設計和文案工作量。
你有沒有感到你做的事情可以讓别人來做（更有效率）?
因為我們在Alpha階段已經有了明确的分工，大家都是選擇了自己擅長的部分，如前端開發，是以理論上來講已經達到了效率的最大化。
每個相關的員工都及時知道了變更的消息?
有微信群的管理和通知非常及時，有時候還有PM私聊确認的情況，是以每個相關的組員都能夠及時知道變更。
我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
是否影響使用者的使用。如頭像功能并不會影響使用者選擇我們産品的決定，是以進行了推遲；但是課程中心中的課程通知，是使用者所需要的，是以屬于必須實作。
項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
我們的項目不是App而是Web應用，是以不需要人為釋出，時刻運作，使用者一直在體驗最新版，是以這個出口條件是時時刻刻都需要滿足的，是以我就想用這三點來概括一下：
伺服器運作正常：提供Web服務的基礎
核心功能正常：使用者能夠登陸就能夠使用功能
新增功能對原有功能無影響：這是面向我們開發團隊，要求了我們增加新功能前需要進行充分的測試，不僅是對新功能的測試，還有對原有功能的回歸測試
我認為做到這三點，持續部署，持續釋出，就已經可以出口了。
對于可能的變更是否能制定應急計劃?
應急計劃面對的問題包括兩類：
新功能的問題：新功能必須經過嚴格的測試并在其他的伺服器上運作成功才加入到主分支中，通過加入前的測試保證不會出現需要應急的場面；
舊功能的問題：如果新功能的加入或者舊功能出現了問題，這裡以由于課程網站的改版導緻爬蟲的驗證出現的問題為例：
或立刻修複不影響使用者的使用（變更爬蟲的代碼以适應新的網站布局）
或臨時取消該功能等待修複（暫停同步課程中心兩天等待測試人員修複）
我們大多數情況下都是立刻修複，以免降低使用者的印象分。
員工是否能夠有效地處理意料之外的工作請求？
能夠處理，比如消息中心的子產品就是在後期臨時添加的，組員能夠非常及時的完成需求。
設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
在正式開發階段前一周PM為主、組員為輔完成，PM根據調查使用者的回報，使用者需要什麼，我們開發什麼，其實組員也屬于我們的使用者，都是使用者需求導向來決定實作什麼。
設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
因為指定需求的時候十分明确，具體到實作之後使用者使用的場景，是以沒有遇到模棱兩可的情況。
團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
有單元測試，具體在測試報告中有呈現。
什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
後端産生的Bug居多，前端也存在但是比較少，主要是由于課程中心的爬蟲邏輯比較複雜容易出bug，而且在新增的增加考試日程中，對于教務系統的爬取邏輯有不同，需要改變登陸的方式，但都是在開發過程中出現的bug，都是解決了才釋出的。
釋出後有一次發現了比較嚴重的bug，就是在增加重複日程的特性時，沒有考慮快速添加日程子產品的修改，導緻快速建立日程中會因為缺少重複日程字段建立失敗，但是我們及時意識到了，說明了每個新功能的上線都應該進行回歸測試。
代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
”同行複審“制度，前端複審前端代碼，後端複審後端代碼，代碼清晰易讀，保證負責的組員在離職後新的接手人可以很快上手，不會存在閱讀代碼晦澀難懂的情況。
團隊是否有一個測試計劃？為什麼沒有？
有測試計劃，具體在測試報告中有呈現。
是否進行了正式的驗收測試？
有驗收時的代碼整體覆寫測試，具體在測試報告中有呈現。
團隊是否有測試工具來幫助測試？
很多團隊用大量低效率的手動測試，請提出改進計劃：至少一個方面的測試要用自動化的測試工具，自動化的測試結果報告，比較測試結果的差異，等等。
測試工具以及詳細内容見偷梁換柱：使用mock.patch輔助python單元測試。
團隊是如何測量并跟蹤軟體的效能（Performance）的？壓力測試（Stress Test）呢？ 從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
我們有同步課程資訊的記錄耗時日志，可以看出軟體的效能還是十分穩定的：
保持在1～3分鐘可以接受的範圍内。
在釋出的過程中發現了哪些意外問題？
暫時沒有意外問題。
團隊的每個角色是如何确定的，是不是人盡其才？
有根據自己的實際經驗選擇的，沒有經驗的同學根據自己的興趣進行了選擇，PM由idea的提出者擔任，因為對項目整體最為了解和熟悉，從結果上來看人盡其才。
團隊成員之間有互相幫助麼？
前端同學之間有互相探讨疑難問題，有bug自己解決不了有組内其他同學幫忙，還有幫助進度慢的同學進行開發；前後端之間也有互相幫助，關于接口的規定和測試時的互相幫助。
當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
我們團隊成員的相處都非常融洽，沒有出現這方面問題，如果出現由PM進行最後的決定。
每個成員明确公開地表示對成員幫助的感謝 （并且寫在各自的部落格裡）：
組員
感謝
Mistariano
感謝組裡的每一個小夥伴帶我愉快走完軟工後半程。印象比較深的是接秘鑰對時fmh深夜了還在推代碼解決遇到的問題，并對新接的代碼做了完善的測試，合作非常愉快；接找回密碼時和lzh同學溝通接口時做了很多輪修改，lzh也非常耐心地和我交流，最終前後端配合實作了功能。此外其他同學也在組會時積極解答我的各種問題。我想我們的項目之是以取得成功，很大一部分源自我們緊密的團隊配合及融洽的團隊氛圍——這是大家共同努力的結果。再次向每個人表示感謝！
Monster
感謝雪燦能抽出時間和我一起進行前後端接口的測試，并且和我一起debug，讓我們的開發程序快了很多！
LiuZH
感謝全組隊友互幫互助，合作愉快！
王FUJI
感謝課程組給我這次機會，很開心和團隊裡的大家一起探索軟體工程；感謝隊友fmh、lqq、lzh、yjc、hdl給予我的幫助還有一起深夜打碼debug的歡樂（雖然如此，但是希望未來熬夜這種事情還有少一點比較好，hh），特别要感謝fmh、lzh帶我入門，在前端開發等方面給了我非常大的幫助！
Kkkk
lqq的兢兢業業恪盡職守夜以繼日孜孜不倦
CookieLau
第一次做PM，非常高興遇到這一群小夥伴，我們一起熬過夜，一起改過bug，一起分析過需求，整個隊伍中沒有一個人拖後腿，大家都非常認真完成布置的任務，非常感謝每一個付出的人，我覺得缺少了每一個人都不能讓我們的項目進展如此順利，最後的效果如此華麗，受到大家的好評。還要感謝轉走的Dz同學，他在Alpha階段也為DDLKiller做出了不可磨滅的貢獻，每一個人都是最棒的！
你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
達到了CMMl三級，明确級。在明确級水準上，所有第二級的要求都已經達到，另外，軟體組織能夠根據自身的特殊情況及自己的标準流程，将這套管理體系與流程予以制度化。這樣，軟體組織不僅能夠在同類項目上成功，也可以在其他項目上成功。科學管理成為軟體組織的一種文化，成為軟體組織的财富。
Gitee的項目管理的引入讓我們從Alpha階段的二級躍升到了三級。
你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
創造階段，大家在基本的需求之外，都對我們的産品和團隊有了一份不可割舍的歸屬感，大家共同為打造一個更好的産品而努力，不需要PM進行督促，自己會按時甚至提前完成任務，還有組員能夠主動完成一些在規劃階段沒有配置設定的任務，我們對其他的組員都特别信任，并且大家也會按照我們的團隊規範進行自己的開發，在測試完備之後簽入主分支，都在為這一個項目付出心血。
你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
團隊方面：我們有了更明确的分工和項目管理，而且成果已經展現，大家也更加上心，不需要PM進行督促會自覺完成配置設定的任務，大家進入了一種齊心協力自治的境界。
産品方面：實作了Alpha階段使用使用者提出的新需求
你覺得目前最需要改進的一個方面是什麼?
站在PM的角度來說，我們組員的各方面都做的已經很滿意了，可能需要改進的地方在于文檔的及時更新和維護，及時搬運到Gitee進行公開。
對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
無論是團隊内還是團隊間，最有效的溝通方法是面對面的交談：我們在Beta階段進行了每日例會，每日進行pr，組員遇到了難題直接在Scrum Meeting後直接留下解答，在Scrum Meeting中送出Pr，不會因為溝通而影響項目的進度
歡迎對需求提出變更 - 即使在項目開發後期，要善于利用需求變更，幫助客戶獲得競争優勢：我們一開始并沒有想到做考試日程的DDL提醒，但是後來在疊代的過程中發現這是使用者在期末的重要需求，于是加上了這個特性。
正如我們前面提到的， 軟體的品質 = 程式的品質 + 軟體工程的品質，那團隊在下一階段應該如何提高軟體工程的品質呢？
代碼管理的品質具體應該如何提高？ 代碼複審和代碼規範的品質應該如何提高？
繼續使用Gitee進行分支的開發，在自己的分支開發後充分測試再PR到主分支進行釋出。
整個程式的架構如何具體提高？ 如何通過重構等方法提高品質，如何衡量品質的提高？
後期可以考慮将前後端分成兩個倉庫，目前雖然已經分離但是依然在一個倉庫内。
其它軟體工具的應用，應該如何提高？
我們使用的測試工具是mock.path，現階段已經足夠使用，但是後期如果規模更大可能需要考慮其他的測試工具。
項目管理有哪些具體的提高？
Pr和Issue分條列點，對應到負責人，每個人的貢獻清晰可見。
項目跟蹤使用者資料方面，計劃要提高什麼地方？例如你們是如何知道每日/周活躍使用者等資料的？
目前已經有詳細的Log記錄，記錄使用者的登入和同步課程中心的操作。
項目文檔的品質如何提高？
及時更新前後端連結的API的JSON格式，加入适當的教學文檔友善其他人接手我們的項目。
對于人的上司和管理， 有什麼具體可以改進的地方？ 請看《建構之法》關于PM、績效考核的章節， 或者 《人件》等參考書
通過了Alpha階段後，我們的團隊已經有了凝聚力和向心力，大家都對這個項目非常上心非常負責，PM的感受特别強烈，從Alpha階段的每天Push擔心項目完成不了到Beta階段的大家完成自己的任務之後甚至主動來找我領任務，主動開發一些在Beta階段的設計中沒有涉及到的東西，這個我覺得是非常難能可貴的。我們獨具特色的采用的shimo文檔開發在Beta階段也被弱化，我認為這是一件好事，因為大家都已經迅速習慣了在Gitee上建立Issue和Pr，有問題直接在項目中解決，我認為這是能夠真正說明我們的項目管理确實取得了進步。
對于軟體工程的理論，規律有什麼心得體會或不同意見？ 請看閱讀作業。 (這個作業的期中閱讀)
在Beta階段對代碼中的備援部分進行了抽離，從自己的實際體驗意識到了行數論是一個很扯的東西，删除了重複的大段邏輯，用一個函數調用形象具體描述之後瞬間清爽
使用者主導，面向使用者開發的思想尤為重要：我們的産品就是面向使用者的，使用者需要什麼，我們傳遞什麼
軟體工程不是聚衆打碼，裡面有互相協作，裡面有需求分析，裡面有項目疊代，裡面有成員之間的互助...團隊沒有凝聚力一個項目很難成功，或者說可能會漏洞百出，因為沒有人考慮項目的未來發展，幹完這個學期就走人的思想十分可怕，幸好我們團隊大家都願意在這門課中真心付出，并且願意為之繼續開發、繼續維護。
在我們的“介紹一下自己吧”——記2020BUAA軟工團隊介紹和采訪中，我們說過：“雖然我們都沒有大型的工程經驗，是一直拼裝起來的軍隊，但是我們相信通過我們團隊的配合一定能夠在軟體工程這門課中發揮出色，不隻是取得成績，而且能做出像樣的、能流傳的、實用的項目出來。”，現在一個學期的兩次沖刺已經結束，我們的成果也已經展現在了大家的眼前，我認為我們的初心已經達到，我們收獲了使用者的好評，得到了老師的認可，感覺這個學期最用心的就是這個項目，感覺就像是自己的親生寶貝一樣，從一行行代碼到一個個函數到一塊塊功能到每一個界面，感覺太不可思議了。
說實話在選擇這麼課程的時候我們也聽說了這門課非常難啃，有無數的部落格，有個人的項目還有結對的項目還有階段的疊代，有一次次的評審，其他兩位老師的課程壓力就沒有那麼大，也不用部落格，也不用疊代，隻有最後的評審。但是回過頭來感覺這一切值了。在個人部落格中我們真正重新認識了自己；在個人項目中我們得到了熱身；在結對項目中我們為後面的分離開發做了準備；在時長一個多月的團隊開發中我們結實了一群可愛的人，做出了令自己驚歎，令自己感激的産品。
如果下一年有學弟學妹問我：軟體工程哪個老師的課好？ 我會如實回答：如果你對自己有要求，如果你想這個學期不碌碌無為，如果你想學期結束收獲滿滿，如果你想逼自己一把，選擇羅傑、任健老師的班級吧。過程會很痛苦，你會看到别人都在玩的時候你在寫部落格，你會看到别人開發的時候你在寫部落格，你會看到别人隻開發一次就結束的時候你在寫部落格，你在開例會，你在Beta階段開發，但是當你的部落格得到了老師的認可，得到了助教的贊賞，得到了《建構之法》作者鄒欣老師的點評，得到了輪子哥Vczh對你的提問的親自回複，得到了《持續行動》《刻意學習》作者Scalers為你特地開賬号的留言，你會感覺，這一切都值了。
全組讨論的照片。
BUAA - UltraSoft - 軟軟軟小組 2020春大三下學期的軟體工程， 全劇終。
但我們DDLKiller的故事還在繼續，不要走開，馬上回來