過後諸葛亮（追光的人）

交換組員的工做交接和培訓方案

工做交接

• 新成員馮凱，考慮到項目技術不一樣，學習項目技術的成本太高，通過商討讓其負責對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 -> 在每次每日立會都會對以前的工做進行反思；

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

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

使用專門的idea插件來提升規範編碼；

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

重構使用微服務架構，解耦系統，分紅多個服務，下降系統的耦合度，提升系統的容量；

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

多查閱idea、Hbuilder x的使用教程；

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

分工上、工做量預估上；

5. 項目跟蹤用戶數據方面，計劃要提升什麼地方？例如大家是如何知道每日/周活躍用戶等數據的？

還未上線，暫時沒有這個考量；能夠實現對應的接口和管理界面來呈現每日/周活躍用戶等數據；

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

減小口語化；多使用標準的項目文檔詞彙來進行描述；

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

重視團建，營造良好的團隊氣氛；

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

理論來源於實際，實際不能只看理論；在實際中思考理論是更可取的方法；

過後諸葛亮討論會議照片

咱們在覓蜜喝奶茶，一塊兒聊天，總結alpha的收穫並思考改進的方法；