交換組員的工作交接和培訓方案
工作交接
- 新成員馮凱，考慮到項目技術不同，學習項目技術的成本過高，經過商討讓其負責對beta的成品進行驗收和測試；原成員fishkk的工作均攤到其他三個后端成員上；
培訓方案
- 閱讀熟悉之前的項目文檔，熟悉測試要求，能達到根據驗收標准完成驗收報告的程度；
設想和目標
1. 我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
我們的軟件主要針對大學生社交，還有日常的校園互助、校園小應用；
1.信息壁壘
2.信息可靠性不知曉
3.社交圈子窄
4.資源無法合理利用
5.問卷調查困難
6.學校開展活動，學生參與積極性不高
在選題報告中有詳細的定義；
在選題報告對典型用戶和典型場景都有清晰的描述；
2. 我們達到目標了么（原計划的功能做到了幾個？ 按照原計划交付時間交付了么？ 原計划達到的用戶數量達到了么?)
原計划的功能基本完成；
原計划並沒有完成完整項目的打算，所以尚未可以交付；
原計划未列出用戶數量要求；
3. 和上一個階段相比，團隊軟件工程的質量提高了么？ 在什么地方有提高，具體提高了多少，如何衡量的？
軟件工程的質量提高了
會議的效率；編碼的規范；如果用工作量/時間來衡量的話，相比團隊建立初提高了1.5-2倍；
4. 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?
Alpha階段並沒有預估上線和擁有用戶；
我們目標更近了，論壇社交模塊基本完成；只剩余一些校園小應用，可以再后續第一版本發布之后，進行增量開發；
有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
在最早的團隊的會議中忽略了團隊建設，而只是討論分工，導致大家雖然在一起做項目，但是感情並沒有建立起來；在后續的合作中發現維系一個高效的團隊，這種互相認可和情感交流是很重要的
在制作文檔的時候過度拘泥於老師的題目要求，為了完成而完成，而未真真切切的去考慮軟件工程思想的要求；文檔服務於軟件工程，應該主要着眼於項目的實際，做出切實可用的文檔；
在預估Alpha工作量的時候，預估的工作量是沒有太大偏差，但是缺少對能否按時完成的估計；
-
我們會做什么改進？
做好團隊建設；
在后續的文檔制作中更加用心，着力於服務項目的開發；為后來者留下一個好的基礎（老師詢問是否願意將項目傳給下一屆，我們是十分願意的）；
預估工作量和安排計划之前，應該統計一下成員可以付出的時間再進行計划安排；
計划
1. 是否有充足的時間來做計划?
在Alpha沖刺前我們花了數天的時間來分配學習任務，后面又有對計划和分工組織會議進行討論；
2. 團隊在計划階段是如何解決同事們對於計划的不同意見的？
我們對於計划的意見比較統一；計划是組長提出，隊友分析討論的結果，因為很早就對成員進行了分工，所以並未出現意見沖突；
3. 你原計划的工作是否最后都做完了? 如果有沒做完的，為什么?
未完全作完，還剩余前后端對接的工作；
對成員的時間、精力缺乏統計和考量，擬定的工作量太大（十天335小時的工作量）；
4. 有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
接口設計這一塊設計了一些暫時沒有用到的接口；現在看來是可以放到beta階段做的；
前端使用weex作為主界面，對於h5和小程序不支持，其實完全可以使用vue來寫，這樣平台都能通用；
5. 是否每一項任務都有清楚定義和衡量的交付件?
對每一項任務都有一個測試和驗收，驗收測試之后才進行下一部分的開發；
6. 是否項目的整個過程都按照計划進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
按照計划進行，未出現什么意外；
沒有遇到什么稱得上風險；代碼按照原定的安排有序開發；如果前后端對接沒有完成是風險的話，沒有估計到是因為對成員的時間、精力缺乏統計和考量，擬定的工作量太大；
7. 在計划中有沒有留下緩沖區，緩沖區有作用么?
沒有留下緩沖區；
緩沖區有利於應對突發事件；處理項目的風險；
8. 將來的計划會做什么修改？（例如：緩沖區的定義，加班）
緩沖區設立應該怎么考量？其實隊員除了軟工實踐這門課程還有其他很多事情要忙；按期完成工作都是一個挑戰；
如果要靠隊員通宵來定義這個緩沖區的話，不設置也罷；
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
技術上：后端學到了spring boot的開發；前端學到了vue、uni-app、weex的入門知識；測試上對於測試工具和測試方法有了更深刻的理解；
團隊上：我們更加熟悉團隊協作來完成項目這個流程；對於一些軟件工程的理論和思想在“做中學”中有了更深刻的理解；
如果重來一遍，我們可能還是會選擇這些技術棧，因為這些技術實用，並且上手並不太困難；
資源
1. 我們有足夠的資源來完成各項任務么?
資源上主要只需要時間資源；這方面我們是短缺的；
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
對於后端，按照每個接口2個小時；前端一個界面4個小時；精度比較准確，我們實際的開發所需時間相差不多；
3. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
對於測試，我能專門安排了一個隊友來進行測試的工作，對於軟件有免費的軟件使用，硬件並無太高的要求，這些都已滿足需求；
美工設計/文案在之前的原型設計、選題報告等都已經完成了；這次Alpha並無這些資源要求；
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
從現在的成員滿意度來看，大家對自己的工作情況、工作成果都是比較滿意的；學習的技術也是自己原先想學的，所以技術上並沒有這一塊的想法；
但是對於博客的撰寫，成員“星夜、痕”的文筆不錯，如果讓他來做，應該會比衡與墨做的更好；
有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
經驗教訓，因為沒有慘痛的過程，所以沒有什么教訓；
經驗這一塊來說，項目實時進度的把控對於PM來說很重要；在Alpha沖刺之前就要充分設計和考慮項目需要用到的技術，並且提前布置成員學習，這樣才不會在Alpha階段手忙腳亂；
改進：時間的分配需要慎重考量，過重的工作量會導致無法預期完成；團隊的前端和后端應該進行更多的交流；在會議討論工作之余，要做好團隊建設；
變更管理
1. 每個相關的員工都及時知道了變更的消息?
通過每日會議和實時的qq討論，大家沒有錯過實時的變更消息（其實也沒多少變更消息）；
2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能?
在Alpha之前就覺得好了優先完善論壇和帖子功能，先不完成校園小應用；這一方面的考量是來自於工作量的估計；時間不足以我們完成所有的功能；
3. 項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?
在之前的系統設計驗收標准中有明確的定義；
4. 對於可能的變更是否能制定應急計划?
能；應急加班；哈哈，大家都很給力；所幸沒有什么大的變更，僅僅是接口參數調整啊，界面增加按鈕啊，這樣的一些小變更；
Alpha后換人這個變更，對於換人，由於技術上並沒有完全依托於某一個成員，並且比較困難的部分也在Alpha階段完成了，所以換人對於項目並沒有太大的影響；
5. 員工是否能夠有效地處理意料之外的工作請求？
沒有遇到；基本是按照預期的流程計划走的；工作安排會提前協調好；
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
驗收很重要，前一步驟沒有驗收好會導致后面的工作做的不好；
應對變更的最好方法就是平均的安排任務，盡量不要把任務和技術積壓到一個人身上；還有就是提前布局，無論是技術學習還是工作安排；
改進的話，對於隊友的學習情況缺少反饋和幫助，導致隊友上手較慢，所幸安排學習的早，不然會導致突發情況的時候過於倚重某個成員，計划無法變更；
設計/實現
1. 設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
在Alpha之前就進行了設計工作，大家一起完成的；
是合適的時間，合適的人；
2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
沒有，在原型設計之前的需求分析中，大家都進行了很細致的討論，這為后面的設計工作做了鋪墊；
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？ 比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
使用Junit來進行了單元測試；使用Jprofie進行了性能分析；
這些工具很有效，在移交測試人員進行測試之前就減少了很多bug；
uml相比alpha之前有了一些字段的增加，在實際開發中漏發現之前漏考慮了；
有對uml的文檔進行更新；
4. 什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
每個功能都有差不多的bug產生，因為隊友對於框架熟悉程度不夠，對於后端開發理解不夠；
Alpha階段 尚未發布，項目還未完成；
Alpha階段 尚未發布，項目還未完成；
5. 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
測試時同時檢查了代碼規范； 整合時再度檢查了代碼規范；
是，嚴格執行了代碼規范；
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
設計必須要充分，這樣開發才會省力；
改進人力檢查代碼規范很辛苦，應該給ide裝上一個檢查代碼規范的插件；
測試/發布
1. 團隊是否有一個測試計划？為什么沒有？
有，先測接口，再驗收界面，再測試前后端對接后的成品；
2. 是否進行了正式的驗收測試？
是；對於不合格的部分回滾開發人員修改，直到測試通過；
3. 團隊是否有測試工具來幫助測試？
使用postman進行接口測試；Junit進行單元測試；
4. 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
使用Jprofie進行了簡單的效能分析；
是有用的；但是還是不夠全面；
改進：增加對后端的壓力測試；
5. 在發布的過程中發現了哪些意外問題？
Alpha尚未發布；
我們學到了什么? 如果重來一遍, 我們會做什么改進?
測試要全面而具體，並且回滾要及時並且嚴格；單元測試應該融入到項目開發之中；
改進：編碼實現對接口進行自動化測試；對后端進行壓力測試；
團隊的角色，管理，合作
1. 團隊的每個角色是如何確定的，是不是人盡其才？
從成員的原有技術棧、成員的興趣來考量；
除了衡與墨覺得“星夜痕”的文筆更好，如果讓他來撰寫博客會更好之外基本人盡其才；
2. 團隊成員之間有互相幫助么？
會；遇到問題會一起討論然后解決；
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
解決最好的方式是線下交流；事實也驗證了這一點；
感謝總結：
221600219 衡與墨
最感謝的是 真·大熊貓 ，謝謝你對我的包容和理解，並且主動在項目中承擔了很多的工作，分擔了很多的壓力，你的責任心有時候讓我自慚形愧，和你合作真的很幸運，希望你能考研到理想的學校；
其次感謝fishkk，對於很多后端的工作，都安排到了你的身上，感謝你一直的支持和理解；
感謝星夜、痕，在有些時候，我提出問題的方式太尖銳，感謝你一直以來包容我，理解我，和你搭檔真的很開心；
感謝其他的隊友：kilig、巴啦啦魔仙、lc，你們一直都很信賴我，非常積極的完成工作，項目的順利進行，離不開你們；
221600240 真·大能貓
我感謝組長衡與墨對我的幫助， 因為app前端從未接觸過，對我來說是一個全新的領域，是組長給了我入門的途徑以及在開發過程中幫我解決了一些我解決不了的問題，也感謝所有隊友對我負責的模塊的建議，讓我能更好的完善我的工作。
221600212 kilig
我感謝 組長衡與墨 在包括結對在內的整個軟件工程，給我帶來許多幫助，積極帶領我們的團隊有條不紊的完成任務，承擔了很多責任，在這次活動負責的測試任務也讓自己收獲不少，這次的沖刺對於我今后的學習是一個很重要的指導。
221600235 fishkk
我感謝 組長衡與墨 對我的幫助， 因為某個具體的事情: 對於沒有后端開發的經驗我來說，在后端開發過程中因為過於依賴前端發生了一些不必要的疏忽，感謝組長大人的及時提醒和指正，這對於我今后的后端開發學習是一個很重要的建議和指導。
221600236 巴啦啦魔仙
我要感謝 組長小墨 這個項目做到今天這個地步他的付出是相當重要的，他有過做項目的經歷，針對我們每個人都能很合理的安排任務，對於技術也懂得比較多，告訴我們應該學習什么技術。如果沒有他，該次軟件實踐，我可能就像和以往的實踐課程一樣應付了事，不會學到這么多東西，沒機會接觸到何如組織一個大型的項目。還有，他今天請我喝奶茶了，謝謝組長的奶茶。
221600103 lc
我感謝隊友真·大能貓和組長小墨的幫助，在這次項目中我們負責前端開發。當我在開發界面的過程中碰到了困難時，通過求助得到了他們及時的幫助。我也因此在這次開發過程中學到了不少知識，也在不知不覺中養成一些好的習慣，學到解決問題的好方法。
221600205 星夜、痕
我感謝小墨對我的幫助。在Alpha沖刺之前，小墨就為我們統一推薦提供了一系列方便快捷的軟件：IDEA編譯軟件、navicat 數據庫軟件、postman測試軟件。之后還給我們尋找到spring boot入門視頻以及spring boot web進階 和 Hibernate注解的慕課網教學。也就是說，在 Alpha沖刺之前，小墨就為我們做了很多鋪墊。然而，在實際寫代碼的時候，我還是出現了一些問題，而且是很嚴重的那一種。在寫代碼的時候，我依舊是采用以前寫代碼的方式，創建自己的一個項目，然后參考網上教程和隊友們寫的代碼，自己寫一份。舉一個簡單的例子：就像是當時我不了解 token 接口的怎么寫，然后我就把小墨寫的token接口一句一句的照搬到自己創建的項目中。但后來是長平點醒了我，我們是一個團隊，況且github的作用便是把自己寫的代碼融入到團隊項目中，善於運用隊伍里已有的方法，而不是根據自己的需要，從團隊代碼中扣取一部分來自己創建的項目中。這大概是一種里程碑式的心態轉變，也讓我更喜歡和熱愛我們的團隊。再次感謝小墨隊長。
總結:
你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
檔次二：CMMI二級，管理級；
這個級別的表述：
在管理級水平上，企業在項目實施上能夠遵守既定的計划與流程，有資源准備，權責到人，對相關的項目實施人員有相應的培訓，對整個流程有監測與控制，並與上級單位對項目與流程進行審查。企業在二級水平上體現了對項目的一系列的管理程序。這一系列的管理手段排除了企業在一級時完成任務的隨機性，保證了企業的所有項目實施都會得到成功。
你覺得團隊目前處於 萌芽/磨合/規范/創造 階段的哪一個階段?
規范階段；
你覺得團隊在這個里程碑相比前一個里程碑有什么改進?
效率上、人員默契上、技術能力上都得到了較大的提高；
你覺得目前最需要改進的一個方面是什么?
改進：開發專門的測試腳本，方便測試；
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
4、在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
5、圍繞被激勵起來的人個來構建項目。給他們提供所需要的環境和支持，並且信任他們能夠完成工作。
6、在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交談。
8、敏捷過程提可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。
12、每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。
4 -> 我們的業務開發人員都在校內，業務和開發兼顧；
5 -> 我們充分信任隊友；
6 -> 我們每天面對面交談（每日立會）；
8 -> 開發速度穩定；每天都有規定的進度安排；
12 -> 在每次每日立會都會對之前的工作進行反思；
正如我們前面提到的， 軟件的質量 = 程序的質量 + 軟件工程的質量，那團隊在下一階段應該如何提高軟件工程的質量呢？
1. 代碼管理的質量具體應該如何提高？ 代碼復審和代碼規范的質量應該如何提高？
使用專門的idea插件來提高規范編碼；
2. 整個程序的架構如何具體提高？ 如何通過重構等方法提高質量，如何衡量質量的提高？
重構使用微服務架構，解耦系統，分成多個服務，降低系統的耦合度，提高系統的容量；
3. 其它軟件工具的應用，應該如何提高？
多查閱idea、Hbuilder x的使用教程；
4. 項目管理有哪些具體的提高？
分工上、工作量預估上；
5. 項目跟蹤用戶數據方面，計划要提高什么地方？例如你們是如何知道每日/周活躍用戶等數據的？
還未上線，暫時沒有這個考量；可以實現對應的接口和管理界面來呈現每日/周活躍用戶等數據；
6. 項目文檔的質量如何提高？
減少口語化；多使用標准的項目文檔詞匯來進行描述；
7. 對於人的領導和管理， 有什么具體可以改進的地方？ 請看《構建之法》關於PM、績效考核的章節， 或者 《人件》等參考書
重視團建，營造良好的團隊氣氛；
8. 對於軟件工程的理論，規律有什么心得體會或不同意見？ 請看閱讀作業。 (這個作業的期中閱讀)
理論來源於實際，實際不能只看理論；在實際中思考理論是更可取的方法；
事后諸葛亮討論會議照片
我們在覓蜜喝奶茶，一起聊天，總結alpha的收獲並思考改進的方法；
