此作業要求參見：
組名：板磚
組長：李惠璨
組員：張傳玉 朱航序 趙新萍 樊培毅 魏琛
設想和目標
1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
2. 我們達到目標了麼（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？ 原計畫達到的使用者數量達到了麼?)
原計畫的目標已實現，沒有按照交付時間實現，使用者原定30人，現在已達到45人。，
3. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
原計畫使用者30人，目前使用者49人，我們離目標更加接近，使用者對於我們的主要功能可以接受，但是還是有很多不足之處，例如功能單一，介面簡陋。
有什麼經驗教訓? 如果歷史重來一遍,我們會做什麼改進?
合理安排每個人的任務量，首要任務是做出可執行的最小執行版本出來。
計畫
1. 是否有充足的時間來做計畫?
有充足的時間做計畫，每天都會開會討論安排任務，時間大多20分鐘以上。
2. 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
對於不同意見還是要考慮可執行性以及大多數人能否接受，如果大多數人能夠接受就可以。
3. 你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
原計畫完成。
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
沒有5. 是否每一項任務都有清楚定義和衡量的交付件?
是的6. 是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
按照計畫執行，但是專案再發布審核時遇到了比較大的麻煩。文字內容安全檢測以至於發布了很多版本沒有通過，第一次做這種小程式沒有預想到這樣的意外。
7. 在計畫中有沒有留下緩衝區，緩衝區有作用麼?
沒有，緩衝區還是讓任務留有一定的餘地，無法完成的情況下可以找其他人協助。
8. 將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
最好再安排計畫時提前一些，這樣會使得整體專案更有規劃性
我們學到了什麼?如果歷史重來一遍,我們會做什麼改進?
一定要盡快實現專案的主要功能，在之後新增功能以及改善都會容易很多，也不會焦慮。
資源
1. 我們有足夠的資源來完成各項任務麼?
有。2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
都是安排一天之內能夠完成的的任務量，精度也就是一天了。
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
測試的時間不是很充足，有些bug還是上線之後使用者反饋才發現的，還好及時人力資源足夠，沒有低估美工以及文案的難度，文案是很需要花心思的。
有什麼經驗教訓?如果歷史重來一遍,我們會做什麼改進?
應該把任務分配的給更加細緻一些，讓每個人都得到應有的任務量。
變更管理
1. 每個相關的員工都及時知道了變更的訊息?
知道2. 我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
小組討論，優先順序高的先實現，優先順序低的可以推遲。
3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
有，實現服務通知。
4. 對於可能的變更是否能制定應急計畫?
能5. 員工是否能夠有效地處理意料之外的工作請求？
能，團隊成員都有很好的能力來處理意外。
我們學到了什麼?如果歷史重來一遍,我們會做什麼改進?
成員之間一定要互相溝通，交流進展，有難題可以一起解決。
設計/實現
1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
在專案分析階段完成，由朱航序以及李惠璨完成，是合適的時間合適的人。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
沒有3. 團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？ 比較專案開始的 uml 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 uml 文件？
沒有使用這類工具
4. 什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
實現服務通知的時候產生的bug最多，首先是對服務通知的基礎模板**不熟悉，雲函式的呼叫和本地函式的呼叫有區別，在傳送資訊是一直報錯：40003，bug顯示獲取不到使用者的openid,查閱了很多資料也沒有解決，使用了四五種方法來避免這樣的bug,但是最後的結果都不盡人意，最後通過把openid儲存到資料庫中，從資料庫中選資料存放到雲函式中設立的陣列中，再然後在傳送函式裡使用陣列裡的資料進行傳送，歷經波折。
發布之後遇到的bug主要是獲取日期的問題，在雲函式中獲取的日期當小於十號的時候是1，2，3，而我們選取的資料是01，02，03。主要原因是我們在測試的時候是二十幾號所以沒有遇到這樣的問題，當月季更新時就出現了這樣的問題。
5. **複審（code review）是如何進行的，是否嚴格執行了**規範？
多次複審，嚴格執行了**規範。
我們學到了什麼?如果歷史重來一遍,我們會做什麼改進?
多做測試，避免後期很多問題。
測試/發布
1. 團隊是否有乙個測試計畫？為什麼沒有？
有2. 是否進行了正式的驗收測試？
沒有
3. 團隊是否有測試工具來幫助測試？
有，使用了小程式自帶的測試工具，真機測試的方式
4. 團隊是如何測量並跟蹤軟體的效能（performance）的？壓力測試（stress test）呢？ 從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
沒有進行這樣的測試
5. 在發布的過程中發現了哪些意外問題？
審核不通過，這是乙個很嚴重的問題，為了解決這項問題我們也嘗試了很多種的方案，最直接的是去除文字新增功能，使用選項代替，但是我們在開始的時候並不想過早的放棄我們的這一功能，所以使用了http呼叫的的方式，請求測試鏈結，測試輸入文字是否符合規範，但是在反饋時卻出現乙個問題，wx.reques函式裡面返回不了狀態值，然後我們又嘗試了將這個函式放在按鈕的js中不需要重新呼叫函式，在真機測試的時候執行的很完美，但是
在預覽時出現了問題，在退出開發模式時程式不執行http呼叫，最後我們為了盡早專案上線，只能使用picker代替文字輸入。
我們學到了什麼?如果重來一遍,我們會做什麼改進?
需要給發布時間留夠足夠的時間來應付可能發生的意外，不能把時間湊得剛剛好。
團隊的角色，管理，合作
1. 團隊的每個角色是如何確定的，是不是人盡其才？
根據成員的能力來分配任務，人盡其才。
2. 團隊成員之間有互相幫助麼？
有3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
團隊討論，討論出合理的方案
事後諸葛亮會議
作業資訊 專案內容 所屬課程 18web方向軟體工程 作業簡介 按照專案回顧模板開展事後諸葛亮會議並撰寫回顧報告 作業要求 團隊專案 任務四 第二次衝刺 作業目的 通過回顧軟體設計 開發 測試 構建 發布的整個過程以及團隊合作狀態總結經驗教訓 參考資料 學生姓名 張家林 撰寫人 於金池 趙政綱 王建...
事後諸葛亮會議總結
問 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？答 問題和需求明確，但是典型使用者，典型場景好像只是只是口頭說說了。問 是否有充足的時間來做計畫 答 我們覺得需求和計畫是這次實踐中最重要的問題，當然有。問 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？問...
20201029 3 事後諸葛亮會議
此作業要求參見 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？我們軟體要解決的問題是 在逢年過節的時候，需要給親朋好友傳送祝福語，發給不同的人需要是不同文字內容的，我們解決的就是將祝福語先分類再提供給使用者，使用者根據自己的需求進行選擇。我們的軟體定義的清楚...