禿頂頂少年團—事後諸葛亮

設想和目標

1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

   答：我們的軟體主要是一個可以定位(附近）的商城系統，裡面售賣各種日常生活所要用到的商品，可以搜尋附近商家售賣的商品還可以給自己定位。對社群使用者和定位有比較清晰的描述。

2. 我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)

   答：我們目前還只達到目標的五分之二。前端頁面大部分實現，但是由於後端程式碼(賣家)出現一些問題，這導致很大一部分功能沒有實現比如說查詢店家，購買支付等。所以使用者數也沒有達到。

3. 和上一個階段相比，團隊軟體工程的質量提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？

   答：和上一個階段相比，我覺得我們還是有很大的進步的。在做專案的過程中我們之間的合作越來越默契，從一開始自己幹自己的到後來的互相幫助，常常溝通交流讓我感受到了一個團隊的力量。

4. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?

   答：因為我們的專案目前還未研發成功，所以跟我們預想的不太一致。從一開始而言，進步是無疑的，所以我們肯定是離目標越來越近。

有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

所得到的經驗就是當一個人摸索不出答案時，要勇於詢問，因為團隊的力量要比一個人的力量大的多。如果重來一遍，我們會先分析好所有需求，準確快速的查詢搜尋資料，諮詢老師，同學們，早些把專案做出來，一定每天都遷入github程式碼絕對不會忘記！

計劃

1. 是否有充足的時間來做計劃?

答：

2. 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？

答：

3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

答：

4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

答：

5. 是否每一項任務都有清楚定義和衡量的交付件?

答：

6. 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

答：

7. 在計劃中有沒有留下緩衝區，緩衝區有作用麼?

答：

8. 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

答：

有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

資源

1. 我們有有足夠的資源來完成各項任務麼？

   答： 有，與其他團隊相比，我們團隊10個人裡面，具有個人編寫程式能力的成員只有三個，我們團隊中大部分的成員程式設計能力不強，所擅長的的技術也不盡相同，所以導致我們團隊大部分專案開發都需要團隊的集體協作.

2. 各項任務所需的時間和其他資源是如何估計的，精度如何？

   答： 按照任務的複雜度、自身能力來評估；精度模糊，只能估計大概時間。各項任務所需的時間一般是按照任務的難易進行時間估計按期的，分配到個人，會看他的個人綜合處理任務的能力來進行合理分配，比如 UI介面設計比較簡單，分配的時間也就相對較短，小程式各個功能模組的實現和整合的時間花費較長，就需要多給於測試人員和程式碼編寫人員相對多的時間，精度準確到小時為單位.

3. 測試的時間，人力和軟體/硬體資源是否足夠》對於那些不需要編輯的資源（美工設計/文案）是否低估難度？

   答：測試的時間基本是不夠的，因為臨近考試，大部分的課程都需要做課程設計，還忙著複習，加上各個功能模組實現的功能不一樣，需要呼叫介面，選擇好的介面也佔用了一定量的時間，加之程式碼方面是用的PHP，這個是是我們按照B站上面一個教學視訊，邊做專案的同時，邊學習一些基本的程式設計，然後學以致用，所以花了很多時間，美工設計和文案放給幾個程式設計能力相對較弱的成員，大家合理分工，力所能及.

4. 你有沒有感到你做的事情可以讓別人來做（更有效率）？

   答：有，由於每個人擅長的方面不同，所以應該各顯神通，最終完成一個好的專案，確定開始畫用例圖和進行用例描述的時候確實人手不夠，自己也得簡單某些用例存在的必要和每個用例之間的關係，所以有的事確實別人可以代替，所謂當局者迷旁觀者清,自己也有遇到死衚衕的時候，後面也是問了別的專案組的成員，後面解決了.

有什麼 經驗教訓？如果歷史重來一遍，我們會做什麼改進？

基礎不牢的條件下做什麼事情都很困難;首先把基礎打牢，再把任務完成之後一步步優化。最後的結果不盡人意，如果歷史能夠重來，我們會在資料庫的選擇方面還有程式碼編輯語言方面進行選擇，
這樣能更有效率完成我們剩下該完成的模組，同時也謝謝大家一直以來的同心協力.

變更管理

1. 每個相關的員工都及時知道了變更的訊息?

   答：我們組在專案開始的初期就建好了工作交流群，包括QQ群和微信群，對於變更的訊息會通知到每個人，所以團隊成員都能及時瞭解。

2. 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

   答：我們組通過“人物角色”的建立，來決定“推遲”和“必須實現”的功能。使得我們組的開發人員能夠更專注於產品的使用者群。
   滿足首要人物全部要求，滿足次要人物部分需求。

3. 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

   答：我們的需求規格說明書裡有明確的驗收標準，可以根據驗收標準來檢視專案的出口條件。

4. 對於可能的變更是否能制定應急計劃?

   答：沒有制定應急計劃，對於可能的變更會通知專門負責這部分的成員及時跟進，採取相應措施。

5. 員工是否能夠有效地處理意料之外的工作請求？

   答：團隊成員都很團結，能夠有效地處理意料之外的工作請求，除了因某些特殊情況暫時不能參與，其他都能配合要求。

我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

我們在做專案的時候要有隨機應變的能力，學會解決突發的情況， 如果歷史重來一遍, 我們要對細節更加註意，制定詳細合理的應急計劃，另外也要擁有頑強的心態。

設計/實現

1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

答：我們每次的設計工作（編碼前的所有階段）都是通過組長先定初始人選，然後組員內部討論最終決定的，每次任務的人員分工都在每個階段的部落格中詳細體現，也能夠較好的完成工作

2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？

答：遇到此種情況時我們都是通過投票表決少數服從多數解決的

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？ 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？

答：單元測試：十分有效，能很直觀表現出開發最終成果是否正確，並且定義起來也比較方便
UML部分：由於在開發過程中有一些比較難實現的，或者有衝突的功能模組部分，所以需求時不斷在變化的，我們的UML文件相比最初也有一定的變化，但並沒有非常多

4. 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

答：釋出後我們發現小組功能模組有部分功能是沒有成功執行資料互動的，在開發時由於並沒有很好的預留時間導致沒能很好的為隱藏的問題提前預留出解決的方案

5. 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

答：程式碼複審是由前後端兩個部分分別制定一個負責人進行復審的，程式碼規範部分基本上就是結合各自模組開發人員的習慣編寫的，所以執行的比較好

我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

設計與實現都是開發過程中十分重要的環節，要整個小組一起不斷學習，共同探討存在問題才能更好的完成任務，對於一些不合理的設計，如果重來一遍我們會在衝刺過程中留出一定的時間進行重新討論與設計

測試/釋出

1. 團隊是否有一個測試計劃？為什麼沒有？

   答：有， 我們小組前後端分離開發，所以測試計劃是肯定不可少的，通過自下而上的最基本測試方法進行軟體開發過程中的所有必要測試

2. 是否進行了正式的驗收測試？

   答：是的，由於時間的原因，我們的驗收測試只是進行了專案整體的簡單使用，並且體感評判測試等級

3. 團隊是否有測試工具來幫助測試？

   答：我們通過安卓手機登入微信小程式進行黑盒測試，全部採用的手工測試，目前自動化測試還不會沒辦法進行測試計劃改進

4. 團隊是如何測量並跟蹤軟體的效能（Performance）的？壓力測試（Stress Test）呢？ 從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？

   答：軟體沒有正式釋出，還有很多缺陷沒有完善，所以沒考慮到效能問題，以及執行環境問題，所以沒有進行效能測試以及壓力測試。如果從執行結果來看
   測試還是很有用的，找到了許多軟體缺陷，幫助團隊進行了軟體優化。改進的話，手動效率低下，以後學會了自動化測試就利用自動化測試和測試工具
   來進行測試，提高測試效率，其次感覺測試覆蓋面略低，單元測試應該做到100%覆蓋，但是基於個人能力問題並沒有做到該指標。

5. 在釋出的過程中發現了哪些意外問題？

   答：在釋出過程中，軟體並沒有徹底完成，許多功能沒有實現，在部署伺服器的過程中由於每個人本地配置不一，照著統一教程進行配置伺服器卻沒辦法正確完成，
   換了幾個人進行才最終能夠配置本地伺服器，雲伺服器不了了之。

我們學到了什麼? 如果重來一遍, 我們會做什麼改進?

學到了軟體的製作不是一個簡單的過程，需要多人協助配合，一旦其中一個環節出現了問題很容易影響到其他工序。測試部分是軟體開發必不可少的一環，並且測試並不是出現問題就一定是壞事
如果重來，我們應該會給測試環節多1-2天的時間，對整個專案需要測試的地方再次進行評估並且進行相應的測試，如果從來一遍，我們會先制定嚴格的
人物分工，以及工作時間，每天的工作量必須完成，不耽誤後續工作，這次軟體的製作失敗，主要原因酒水出現在這裡，分工配合的失敗，在規定時間內沒有
完成相應的內容製作，當然衝刺時間於期末考試複習時間重疊也是沒有完成任務的一個影響因素。

團隊的角色，管理，合作

1. 團隊的每個角色是如何確定的，是不是人盡其才？

答： 根據大家討論的結果，每個人負責擅長的角色。

2. 團隊成員之間有互相幫助麼？

答：是的，出現問題時，大家會一起討論解決。

3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？

答：當出現專案管理、合作方面的問題時，團隊成員會進行協商，討論出解決方案。

我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

我們學到了團隊合作的益處，當有問題或者出現矛盾時，大家會一起解決，方便快速。如果歷史重來一遍, 我們會更加相信自己的隊友，一起進步，團結和諧。

 
每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的部落格裡）：

陳萍傑：我感謝鄒雪花對我的幫助，每次我任務做不完，他都會來替我承擔一部分任務，我感謝雷情對我的幫助，每次我分工不明確，沒及時組織任務，他都會來幫我分配任務，
唐清磊：我感謝陳萍傑和雷情給我的幫助。因為在UI介面設計中，一開始什麼都不懂，他們教了我很多，其他例如前段的編寫，框架的選擇設計也是一直在幫助我。
嚴雄峰：首先我要感謝我的組員這段時間的陪伴， 比較之前的團隊專案，這次的衝刺更為正式也更讓人緊張，無論是程式碼上還是文件的編寫上都較之前上升了一個臺階。因為微信小程式是自學沒多久，所以熟練度基本是沒有的。而且由於自己個人的時間安排問題，
       遇到的問題比較的多，期間在筆記模組上後端組長幫助良多十分感謝！此外我還要感謝雷倩，她不僅要完成自己的任務外還熱情的幫助其他組員。協助組長萍傑共同管理組員之間的任務，在後期組員分工上銜接的很順利，為專案儘早提交提供了很大的幫助。
陳柱全：我感謝雷情督促我們完成工作，在工作上完成度不夠的時候，會幫忙指出來，ui介面設計的時候還會幫你修改
鄒雪花：在專案進行過程中，遇到了很多的問題，自己百度還是沒能解決，在崩潰到想放棄的時候，是老師和隊友的幫助，讓我克服了一系列問題。
       感謝老師，感謝隊友對我的幫助，自己在專案過程中有提升自己處理問題能力以及抗壓能力，並且學會了專案開發的過程和方法
雷情：我感謝禿頂頂少年團員的每一位組員，還有老師對我們的幫助，團隊的人在我很忙的時候會替我分擔，老師在我們專案進行中也給了很多建議，會悉心為我們答疑解憂。
劉敏：我感謝雷情對我的幫助，老師說用例圖的那節課我什麼都沒聽懂，以至於分配任務時什麼都不會做，雷情浪費自己的休息時間認真給我講解每個細節，
     一步一步教我畫。不止這，還有很多次當我遇到困難或者感覺到迷茫時，她總是給我幫助和鼓勵。所以我非常感謝雷情對我的幫助(=^▽^=)
鄒婷：我感謝禿頂頂少年團每個成員，因為一開始如果不是你們的接受，我也許就不會成為禿頂頂少年團的一員，感謝你們對我工作的包容與支援。
郭航：我感謝陳柱全對我的幫助，因為某個具體的事情:專案測試時對我的指導。
胡楠：

總結:

你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
答：CMMI二級，管理級

你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
答：從磨合到規範

你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
答：任務分配，技術能力上都得到了較大的提高

你覺得目前最需要改進的一個方面是什麼?
答：技術得到提升

對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
答：時時總結如何提高團隊效率並付諸行動。（在每次作業之後都會進行反思）
簡明為本——它是極力簡化不必要的工作量的技藝。（我們只實現了必須的功能）
無論團隊內外，面對面的交流始終是最有效的溝通方式。（幾乎每次開會都會QQ電話或者做一起寫作業）

正如我們前面提到的， 軟體的質量 = 程式的質量 + 軟體工程的質量，那團隊在下一階段應該如何提高軟體工程的質量呢？

1. 程式碼管理的質量具體應該如何提高？ 程式碼複審和程式碼規範的質量應該如何提高？
   答：擁有一個比較適合自己的原始碼管理工具，例如GitHub,當專案有進展就進行嵌入。在編寫程式碼時就注意程式碼規範，如果到後期再進行程式碼規範加大工作量。程式碼進行復審，密切注意專案互動情況。

2. 整個程式的架構如何具體提高？ 如何通過重構等方法提高質量，如何衡量質量的提高？
   答：重構使用微服務架構，解耦系統，分成多個服務，降低系統的耦合度，提高系統的容量；

3. 其它軟體工具的應用，應該如何提高？
   答：多使用idea、eclipse、等工具進行編碼，多查閱工具的使用教程。

4. 專案管理有哪些具體的提高？
   答：任務量化，細化，具體到可以立刻實現；需要有驗收和整合的步驟；分工上、工作量預估上。

5. 專案跟蹤使用者資料方面，計劃要提高什麼地方？例如你們是如何知道每日/周活躍使用者等資料的？
   答：還未上線，暫時沒有這個考量；可以實現對應的介面和管理介面來呈現每日/周活躍使用者等資料；

6. 專案文件的質量如何提高？
   答：
   a.規範表達，使用專業詞彙，減少口語化。
   b.有效的記錄、指導、督促，將文件編寫好。

7. 對於人的領導和管理， 有什麼具體可以改進的地方？ 請看《構建之法》關於PM、績效考核的章節， 或者 《人件》等參考書
   答：
   a.重視團隊成員，多開展團建交流，營造良好的團隊氣氛；
   b.一定要把各個任務可以量化到，大家才能很好的完成，這點在專案工作中，真的是必須的。

8. 對於軟體工程的理論，規律有什麼心得體會或不同意見？
   答：學習理論知識要應用於實際，理論實際要結合起來，將專案執行。

佔比

照片