1、基本情況

組長部落格連結：https://www.cnblogs.com/cpandbb/p/14007413.html

答辯總結：

  ·產品偏離了最開始的方向，地圖和刷一刷功能做得沒那麼好，外賣訂單功能雖然做得完整，但卻偏離了一開始的想法。組員答辯結
  束之後，開了會，做了認真的反省，決心在beta衝刺中將我們的專案開發重心重新放回地圖和刷一刷功能，爭取在beta答辯中拿出
  令大家滿意的產品。

討論照片：

工作流程：

  ·Alpha階段的開發工作分為地圖頁面部分、刷一刷頁面部分、外賣訂單功能頁面部分，分配給不同人手，開始進行開發。

分工以及貢獻比例

測試組提問部分

  1、食堂該如何實現預約小桌or大桌？是讓商家幫忙佔座嗎
        該功能有欠考慮，發現其實現的難度大，聽取柯老闆建議後，決定刪去該功能。
  2、商家賬號是後臺手動分配還是商家自己註冊？
        目前是後臺手動分配。
  3、首頁掃一掃的功能是怎樣的？
        掃一掃功能的設想原本是可以直接掃店家的二維碼可以得到該家店的基本資訊以及周圍人對該店的評價，達到避雷的效果，但在柯老闆建議下，決定刪去改功能。
 

2、總結

2.2.1. 設想和目標

  1、我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
        解決在校學生到食堂吃飯不知道吃什麼的問題。
        定義得很清楚。
        典型使用者：在校學生以及學校教職工。
        典型場景：到食堂吃飯，可是檔口太多，不知道吃啥。
  2、我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)?
        我們的地圖功能大概完成百分之八十，刷一刷功能完成比較慘。未能按照原計劃時間交付。由於小程式還在測試階段，使用者暫時只供組內測試，
    希望快點做出更加完善的產品出來供更多人來測試。
  3、使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
        使用者暫時為我們的開發人員，所以大體一致。我們會繼續努力，爭取一步一步向目標靠近。
  4、有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
        經驗教訓：我們把重心放偏了，我們想要完成的功能太多，結果導致亮點功能未能成功完成（也是組長我的鍋嗚嗚嗚）。
        改進：我們會在beta衝刺中把我們的重心移回來，努力完成地圖美化以及刷一刷功能。
 

2.2.2. 計劃

  1、是否有充足的時間來做計劃?
        有很充足的時間來做計劃，我們從團隊建立就開始討論選題內容了。
  2、團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
        團隊在計劃階段沒有什麼不同意見，如果有的話，會進行討論，最後大部分情況下遵從少數服從多數、菜雞服從大佬的規則。
  3、你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
        大部分工作完成了，小部分沒有完成。原因：預想的和現實不一樣，能力不足。
  4、有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
        我們組的重心放錯了，所以在功能實現方面上繞了不少彎路
  5、是否每一項任務都有清楚定義和衡量的交付件?
        一開始沒有考慮這個情況，沒能給每一項任務下一個清楚定義和衡量的交付件，導致後面有些任務節奏有點亂。
  6、是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
        並沒有完全按照計劃進行，在完成專案的時間段中碰上了考試，主要開發人員既要複習考試又要小程式開發，時間趕不及，任務無法
        按原計劃完成。風險可能就是當時沒能想到有些功能實現起來很麻煩而且緊跟著考試，再加上平常還要上課，完成任務時間非常少。
  7、在計劃中有沒有留下緩衝區，緩衝區有作用麼?
        有留下緩衝區。緩衝區起到了很大的作用。
  8、將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
        重新制定我們接下去要完成的任務，合理安排人手來幹活，會考慮加班完成，留下更多的緩衝區。
  9、我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
        計劃制定應該更加詳細，組員之間交流溝通應該更加密切。
        改進：之後會制定更加詳細的計劃，作為組長我也會加強督促組員，讓組員間的溝通交流更加密切。

2.2.3. 資源

  1、我們有足夠的資源來完成各項任務麼?
        組內大家都缺少專案開發經驗，導致學習成本較高，時間資源較為不足。
  2、各項任務所需的時間和其他資源是如何估計的，精度如何?
        各項任務所需時間和其他資源主要由負責完成任務的組員估計，精度一般，只大概估計一下，有一些情況當時未能考慮進去。
  3、測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
        不夠充足。
        我們沒有低估難度，但美工設計實在是得有天分，我們大家地圖平面設計實在做得很差。
  4、你有沒有感到你做的事情可以讓別人來做（更有效率）?
        大家都沒有啥開發經驗，所以也不存在讓別人來做更有效率吧，只能大家一起不斷努力。
  5、有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
        要充分利用資源，抓緊空餘的時間，儘早地完成任務，防止意外情況發生，沒辦法有充足的時間處理。
        如果歷史重來，會在比較空閒的時間安排多一點的任務，在有意外情況（比如考試以及考試複習）發生時，減少任務。

2.2.4. 變更管理

  1、每個相關的員工都及時知道了變更的訊息?
        如果有變更，會在群裡艾特全體成員通知大家，保證訊息通知到位。
  2、我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
        在需求分析部分，我們就已經決定好重點開發內容，但是我們卻跑偏了，很尷尬（組長我背大鍋）。
  3、專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
        專案具備了能完好運轉核心功能及其他相關的基本功能。
  4、對於可能的變更是否能制定應急計劃?
        一開始並沒有制定應急計劃，等到碰到突然地變更時才臨時改變計劃，導致後期的任務完成得比較匆忙。
  5、員工是否能夠有效地處理意料之外的工作請求？
        若出現意料之外的工作請求，會根據組員現有的任務情況來判斷哪個組員比較適合完成，在給予分配，保證能完成請求。
  6、我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
        安排任務時也要考慮一下突發情況，預想好會出現的情況並考慮解決辦法。如果歷史重來，會再考慮周全些，把一些可能出現
     意外情況也考慮進計劃安排裡。
        改進：根據任務重要性和難易程度，合理進行安排。

2.2.5. 設計/實現

  1、設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
        設計工作是在Alpha衝刺快開始的時候，由組長組織會議，組員共同討論決定。是的。
  2、設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
        共同討論解決。
  3、團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
        暫時還沒有，uml挺有用的。
  4、比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
        有區別，但是不大。一開始想法太多，程式碼實現無法實現所有功能。否。
  5、什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
        刷一刷功能。智慧推薦難度太大了，沒辦法做好。剛開始餅畫太大了。
  6、程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
        由於時間不足，暫時沒有進行嚴格的程式碼複審。
  7、我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
        程式碼複審應該隨時進行，而不是等專案完結後再進行。測試要及時趕上。

2.2.6. 測試/釋出

  1、團隊是否有一個測試計劃？為什麼沒有？是否進行了正式的驗收測試？
        有，計劃在專案大致完成時進行測試。
        否，因為專案完成進度還差很多。
  2、團隊是否有測試工具來幫助測試？
        使用微信小程式自帶的真機除錯進行測試。
  3、團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
        小程式還未完全完成，暫時不考慮測量和跟蹤軟體效能。測試工作的效果和需要改進的地方還無法得知。
  4、在釋出的過程中發現了哪些意外問題？
        專案還未完成，還沒有釋出，所以還沒有什麼意外問題。
  5、我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?】
        要留更多的時間來完成測試。
        改進：加緊完成任務，留出更多的時間。

2.2.7. 團隊的角色，管理，合作

  1、團隊的每個角色是如何確定的，是不是人盡其才？
        根據成員意願和能力來確定角色，但是部分組員基礎較差，感覺沒有合理人盡其才。
  2、團隊成員之間有互相幫助麼？
        有，大家互相幫助，不侷限於自己任務。
  3、當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
        進行共同討論來進行解決
        
        我很感謝 黃純樸 對我的幫助，他對這個團隊永遠都是很負責，對於我們每個團隊成員來說他都是至關重要的！

   4、我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
        學會了相關任務的知識，隊友間的合作也越來越順暢。如果歷史重來，會再好好安排一下團隊的角色，爭取更大的人盡其才。

2.2.8. 總結

  1、你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
        初始級別。
  2、你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?\
        磨合。
  3、你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
        任務安排變得更加清晰，小組成員間更加熟悉。
  4、你覺得目前最需要改進的一個方面是什麼?
        小組成員要加強溝通。任務分配要更加清晰。
  5、對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
        原則5-要善於激勵專案人員，給他們以所需要的環境和支援，並相信他們能夠完成任務。
        事例：鼓勵幾個開發大腿，始終相信他們能夠完成任務。