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

一、基本情況

1.(2.1) 基本情況（10分）：

• 組長部落格連結：已在部落格開頭給出

• 現場答辯總結

  • 點名介面最好可以做成單人單頁，上滑簽到，下滑未到，越方便越好，增加姓名拼音
  • 多人介面可以考慮改成對答到的不操作，未到的點選，減少使用者點選次數
  • 增加隨機點名，增加點名資料視覺化模組

• 全組討論的照片
  

• 評估團隊中每個人對本次作業的貢獻比例，描述為本次作業的工作流程、組員分工、組員工作量比例

二、總結思考

• 2.2.1 設想和目標（4分）
  1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述 ？
  我們的軟體致力於幫助上課老師和督導隊成員通過上傳excel表格生成小程式內的點名表進行快速點名並且生成點名完的excel表格。該軟體主要是針對教師點名方面，將教師點名的功能做到極致化，便捷化，使用最少的動作，完成教師對點名的需求。我們的典型使用者是上課老師和督導隊成員，典型場景是老師上課點名和督導隊下課點名。

  
  2.我們達到目標了麼?（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)
  原計劃完成的功能：通過excel表格上傳點名表、多人介面的快速點名表、點名結果的基礎視覺化、分成老師點名和督導隊點名兩種。
  按照原計劃時間交付了。小程式還未完善完全，沒有上線，目前沒有使用者。
  3.使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
  小程式目前沒有上線，沒有使用者。
  使用者對於我們多人點名介面有覺得比單人介面更方便的，也有覺得單人更直觀更美觀的。確實沒有預想到部分使用者對於excel表格上傳的功能不滿意，想要通過直接爬取教務處資料生成點名表，也有部分使用者覺得生成點名表不如二維碼簽到。
  根據客戶的需求，我們會不斷完善，離最終目標更進一步。
  
  4.有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
  在合作的過程中，沒有定下每次alpha衝刺的總任務和個人任務，對於ddl沒有明顯的緊迫感，以至於在最後幾天特別忙。
  會重新協調好組內分工，落實每個人的任務和進度，對未完成任務的組員進行督促和幫助。

• 2.2.2 計劃（5分）
  1.是否有充足的時間來做計劃?
  有做計劃，但時間不算充足，前兩次衝刺大部分時間用於學習這次專案所需的新知識。
  2.團隊在計劃階段是如何解決組員對於計劃的不同意見的？
  通過線下開會交流，線下開會完善制定計劃明顯比線上更有效率。
  3.原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
  個人簽到頁面和拼音顯示未能完成。
  計劃時打算做多人和單人兩種簽到介面，因為多人簽到更難，想要先完成多人再做單人，結果沒想到最後時間不夠，沒能完成單人簽到介面。
  拼音顯示是因為npm的拼音庫在下載安裝後，會直接導致下載後的微信小程式軟體崩潰，目前沒查明原因。
  4.有沒有發現做了一些之後看來沒必要或沒多大價值的事?
  在做這次專案之前先用墨刀做了個原型設計，發現完全沒用……
  5.是否每一項任務都有清楚定義和衡量的交付件?
  每一項任務都有很清楚的定義，但測試報告和前端做出來的成果難以有清晰的衡量標準，測試報告沒有其他相似產品的對比，而且畢竟每個人對於前端的審美存在一定差異。
  6.是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
  意外：沒有想到前端對於微信小程式的學習佔了太多時間，以至於後面幾次alpha衝刺瘋狂趕工。
  風險：第三方庫的匯入，在匯入npm的拼音庫的過程中，匯入後的專案一編譯就報廢，慶幸有備份專案。確實沒法想到匯入第三方庫能直接報廢專案，之前做專案從沒遇到這種情況。
  7.在計劃中有沒有留下緩衝區，緩衝區有作用麼?
  最開始的幾次alpha衝刺有留下緩衝區，因為不清楚對於這次專案，需要學習多久的微信小程式相關知識。
  8.將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
  緩衝區仍會保留，但是不應設定太久的緩衝區，過長的緩衝區只會導致組員的鬆懈和推遲計劃。組長會更加嚴厲的督促組員的進度完成情況，如果沒有完成，會建議組員利用自己的多餘時間進行加班，不要拖累組內其他同學。
  9.學到了什麼? 如果歷史重來一遍, 會做什麼改進?
  緩衝區不宜設定太久，應該定下清晰且嚴厲的目標計劃，只有落實到每次的具體計劃ddl才能讓組員有緊迫感，有為了完成計劃而加班的自願。

• 2.2.3 資源（3分）
  1.我們有足夠的資源來完成各項任務麼?
  有。人力資源分為前端六人，後端六人。雲端資源是購買了微信小程式的付費伺服器套餐。硬體資源主要依靠組員自己的電腦。
  2.各項任務所需的時間和其他資源是如何估計的，精度如何?
  有在網上查詢相關類似專案的時間和資源，也詢問了網上做過類似專案的前輩，可惜都沒有明確的答案，於是靠自己以往做專案的經驗預估了，可惜精度不盡人意，對於後期任務所需時間估計太少。
  3.測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
  足夠，十人小組不缺人力資源，硬體資源用安卓機進行測試，電腦進行程式碼編寫以及雲開發。
  並未低估難度，畢竟這是一個服務類的微信小程式，最基本的前端介面肯定不能滿足客戶的需求和審美。於是在製作前端的過程中運用了第三方庫進行進一步美化，目前看起來沒有問題。
  4.你有沒有感到你做的事情可以讓別人來做（更有效率）?
  組內來看的話，沒有。大家都是第一次開發微信小程式，每個人都在自己最合適的位置上。
  5.有什麼經驗教訓? 如果歷史重來一遍, 會做什麼改進?
  對於前期學習微信小程式開發的時間資源安排過多，以至於後期具體開發太緊迫。
  會要求組員花費更少的天數去學習相關知識，否則拖累其它部分的同學。

• 2.2.4 變更管理（4分）
  1.每個相關的員工都及時知道了變更的訊息?
  我們會在交流群中通知，保證每個成員都能及時瞭解變更訊息
  2.我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
  必須實現的功能是我們確定專案後定下的產品準備實現的功能，推遲的是我們在完成預定目標後仍有空餘時間才會考慮的對產品細節進行優化的功能
  3.專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
  出口條件是預定功能能夠正常使用
  4.對於可能的變更是否能制定應急計劃?
  若出現可能的變更我們會根據專案當前進度和剩餘時間制定應急計劃
  5.組員是否能夠有效地處理意料之外的工作請求？
  部分組員處理意外情況的能力一般，但通過組內其他人員的幫助仍能有效處理意料外的工作請求
  6.學到了什麼? 如果歷史重來一遍, 會做什麼改進?
  我們在中途更換過整個專案的立意，全部推倒重做了一遍，但在工作過程中因為專案的變更小組內工作的分配做的不是很好，導致了工作效率的不足。如果重來一遍，在專案變動後應該立刻重新進行具體的工作分配來提高工作效率

• 2.2.5 設計/實現（4分）
  1.設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
  設計工作大概是在alpha衝刺階段二，對微信開發工具有了基礎以後由後端組討論完成的。由於組員需要時間學習相關工具的使用，所以最開始並無法完成相關的設計，僅僅只是對要實現的功能進行了討論和彙總，並做出相應的原型以作為程式開發的模板。因此不可避免地導致實際開發的時間被壓縮。
  2.設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
  在程式功能設計部分遇到過。我們通過團隊協商，在考慮了時間成本和操作難度後，對功能進行了一定的優化和捨棄。
  3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
  我們使用的是微信開發工具對小程式進行設計。微信開發工具的各項功能，如模擬器，雲開發等簡化了小程式開發的過程，顯著加快了我們的工作效率。
  4.比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
  總體設計上並沒有太大的區別。我們主要是在uml的基礎上對相關的功能進行了拓展和延伸，因此沒有必要更新uml文件。
  5.什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
  對excel檔案的資料進行上傳和匯入資料庫出現的bug最多。主要原因是對程式碼的理解和使用不夠熟練。釋出以後尚未發現更多重要的bug（我們主要實現了程式的基本功能實現和debug，功能開發還有相當的工作量）。
  6.程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
  程式碼複審主要是在測試過程中遇到問題後再尋找相關的程式碼進行復審。因為本組內的程式碼開發者都是初學者，因此對於程式碼規範的實現並沒有強求。
  7.學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
  進行程式設計的過程中使用相應的工具能夠加強對程式框架的認識，加快設計開發的進度，也方便與其他成員進行交流。如果歷史重來一遍，我們會在專案初期就開始進行一部分設計的工作，以減少對實際開發工作時間的佔用，留下更多的空間。

• 2.2.6 測試/釋出（3分）
  1.團隊是否有一個測試計劃？為什麼沒有？是否進行了正式的驗收測試？
  因該專案還沒有完工，還有部分功能沒有實現，所以沒有一個具體的測試計劃，只有在完成一個小階段之後會進行一次專案流程的實現，觀察到此為止是否存在問題。
  2.團隊是否有測試工具來幫助測試？
  微信小程式自帶的程式就可以進行實機測試，觀察測試結果。
  3.團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
  因為軟體的功能較為直接，可以通過直接觀察檢視軟體的效能。測試功能與軟體的實際執行結果基本一致，在雲資料庫檢視方面還存在一些問題，沒有按照ID順序進行觀測，需要改進。
  4.在釋出的過程中發現了哪些意外問題？
  目前仍處於開發完善階段，還未進行軟體的正式釋出。
  5.學到了什麼? 如果歷史重來一遍, 會做什麼改進?
  在進行專案的測試時，正常應該分出人員對軟體進行專門的測試分析，但是在進行分工時，怕考慮到測試人員的工作量只有在軟體完成基礎開發之後才能夠進行，害怕浪費勞動力，就沒有分配人員這個專門對這個方向進行處理，而是後端人員在完成部分之後就進行單獨測試，效率較低，有沒有系統規劃。重來一遍的話，會分出單獨的人員進行軟體的測試，如果前期工作量不夠可以安排文章的撰寫部分增加工作量。

• 2.2.7 團隊的角色，管理，合作（3分）
  1.團隊的每個角色是如何確定的，是不是人盡其才？
  團隊首先進行了大致的分工，一開始除了部分組員有比較明確做後端或前端，大部分組員都是按興趣選，不管前端還是後端都有大量的知識和技術需要學習。然後前端和後端組都需要選出一位代理人，進行及時溝通，進行前後端內容的交接；
  和人盡其才可能還是有不小差距的
  2.團隊成員之間有互相幫助麼？
  有的，對於前端頁面的搭建互相詢問技巧，前後端一起尋找介面處的BUG......
  3.當出現專案管理、合作方面的問題時，團隊成員如何解決問題？ 每個成員明確公開地表示對成員幫助的感謝 （彙總至組長部落格）：
  出現問題會在QQ群及時溝通，在站立會議時一起再集中討論

感謝彙總：

• 吳彬：我感謝謝元對我的幫助， 因為某個具體的事情:為學習開發過程提供了學習和借鑑資料。
• 吳子澳：我感謝賴莘龍對我的幫助， 因為某個具體的事情:幫我實現前端介面，一起改BUG找資料
• 謝元：我感謝吳超凡對我的幫助，在我對報錯毫無頭緒時幫助我一起debug；
• 賴莘龍：我感謝吳子澳對我的幫助，因為某個具體的事情：前端點名頁面無法正常點名的時候是他花了大量時間幫助我解決了這個問題，在前端介面設計方面他也給了我很多建議。
• 夏明旻：我感謝許茹婷對我的幫助， 因為某個具體的事情: 我負責寫點名記錄的前端介面，其中要使用到block迴圈，在編譯執行的時候頁面直接變成空白了，讓本來就崩潰的我更崩潰了，我和許茹婷說明了這個原因，她安慰我說不要急我們一起debug，讓我得到了許多安慰。學到了遇到問題要保持冷靜，慢慢找錯誤，而不是逃避。如果歷史重來一遍，我會盡快完成其他課程的課設，將更多時間投入到軟工上。
• 陳祉鏹：我感謝吳超凡、謝元對我的幫助，在我因為個人原因導致進度落後時，是他們主動、仔細地向我講解了他們的最新進度，讓我有機會趕上進度。我感謝組長吳子澳對我的幫助，不停地督促我們趕進度，讓我們不至於又DDL工作。
• 許茹婷：我感謝夏明旻對我的幫助，由於我不知道怎麼進一步美化介面，帶我瞭解colorui，設計出更好看的介面。學到了colorui的使用，如果再來一遍，我會用所學的將介面設計得更美觀流暢。
• 羅進：我感謝吳子澳的幫助，因為某個具體的事情:在我苦於如何優化介面時為我提供了建議和幫助。
• 吳超凡：我感謝賴莘龍對我的幫助， 因為某個具體的事情: 前端和後端之間進行的溝通都是不斷溝通了解的，溝通之中明確了具體的問題和需求。在面對不瞭解的領域時候，先明確自己為了完成這個目標需要做什麼，需要學什麼，具體要用什麼工具能做出來。在開始行動，而不是學一半才發現這個工具沒有用。
• 莊婉蘋：我感謝組長吳子澳對我們組的奉獻，因為某個具體的事情：在整個過程中非常有耐心地統籌我組的工作。學到了小組分工細緻的重要性。如果重來一遍，會縮短一點學習的時間，通過實踐更有針對性地去學知識。

4.學到了什麼? 如果歷史重來一遍, 會做什麼改進?
團隊分工不夠合理，交流不夠，沒有合理利用人力資源，後面的Beta衝刺要更好的發揮十人組的優勢

• 2.2.8 總結（4分）

  • 吳子澳：
    前期的分工不夠明確，中期督促組員工作，促進前後端的交流互動做的不好，另外Alpha衝刺前期花了大量的時間看視訊學習，但是後面上手做，查資料，明顯學的更快，看視訊學習不太適合這種衝刺任務的情景
  • 謝元：
    從這次的專案學到了很多知識，不只有前端的基礎相關語言，還有微信小程式特有的前端語言，以及微信小程式雲開發相關知識，如何操作雲資料庫，編寫雲函式等等。雖然有點不愉快的經歷，但確實很充實，完善了自己。
  • 賴莘龍：
    在alpha衝刺的過程中，我學到了關於構建一個框架完善的前端介面應該具備的各種知識，也對如何呼叫後端的資料有了基本的瞭解，最讓我感觸良多的是光看視訊是學不到太多東西的，還是要自己動手一步步做下去對知識的印象才會深刻
  • 吳彬：
    在專案開始前我對軟體開發的流程，微信小程式的開發並沒有瞭解。因此才在專案的初始階段花費了大量的時間去了解和學習。通過這次專案，我學習了微信開發工具的使用，加強了對前後端的理解和認識，對軟體開發中各部分成員的任務有了瞭解，對今後的就業選擇有了一定認識。
  • 夏明旻：
    這次alpha衝刺裡有其他課程的考試、課設，說實話非常緊張；我們小組也因為溝通問題出了很多差錯，進度也比較慢，也沒有達到老師的預期，畢竟是第一次集體做一個專案，希望自己在beta衝刺裡可以在組裡再多出一些力。
  • 陳祉鏹：
    本次Alpha衝刺總體感覺不好，剛好其他專案衝突，又有考試，時間安排雜亂，而且團隊內的分工還是沒有明確，感覺又是各做各的，慶幸組內有些人很積極地完成了許多部分的任務，不至於成果都沒做出來，希望在接下來的beta衝刺中組員們能更好地協調溝通，更有效率地完成這個專案。
  • 許茹婷：
    本次Alpha衝刺由於正好碰上我的考試，所以把事情堆到了後期“衝刺”，由於時間不夠充分，導致設計出的介面不夠美觀，還要小組其他成員來善後，感覺非常抱歉，希望beta衝刺中可以做完做好所有的工作。
  • 羅進：
    本輪衝刺讓我充分的認識到自己所學知識的不足，也讓我學到了很多前端和小程式開發的知識，讓我對一個專案的開發有了更深的認識。
  • 吳超凡：
    本輪衝刺總感覺一直在忙，但是沒有效率，也沒有好的成果，要學的東西太多了，要實現一個軟體的開發各個方面都要有所瞭解，小組內的成員在之前都沒有接觸過這方面的內容，導致在發過程中沒有一個人對小組進行帶領，都是自己摸索著前進，也沒有什麼統籌規劃，到最後只知道做了，但具體哪一步做的什麼作用在哪都不瞭解，要是有個大佬帶著走可能就會輕鬆許多吧。
  • 莊婉蘋：
    學會了微信小程式前端介面的實現，豐富了小組合作的經驗。