此作業要求參見：
1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們軟體要解決的問題是：在逢年過節的時候，需要給親朋好友傳送祝福語，發給不同的人需要是不同文字內容的，我們解決的就是將祝福語先分類再提供給使用者，使用者根據自己的需求進行選擇。
我們的軟體定義的清楚，對典型使用者和典型場景有清晰的描述。使用者：15-35歲的青年人；場景：節日、生日、日常早中晚。
2. 我們達到目標了麼（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？ 原計畫達到的使用者數量達到了麼?)
達到目標了，alpha原計畫功能做到4個，已經按照原計畫時間交付完成，使用者數量達到165人，完成原定目標。
3. 和上乙個階段相比，團隊軟體工程的質量提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
上乙個階段進行了選題，沒有進行具體實現功能。但是我們在團隊合作上提高了，分工任務更明確，通過每天的to do list體現出來是有提高的。
4.使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
使用者對重要功能的接受程度和我們事先的預想一致。在採訪的使用者之中，有大概70%的使用者對小程式進行了讚賞，也有30%的使用者為我們提出了意見。我們離目標更近一步了。
有什麼經驗教訓? 如果歷史重來一遍,我們會做什麼改進?
在前期我們的目標是不明確的。如果歷史重來一遍，我們會在階段初始就明確劃分各自的職責，這樣有利於提高軟體開發的效率。
1. 是否有充足的時間來做計畫?
有充足的時間，每天的站立會議我們會討論明天的計畫。
2. 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
我們讓大家提出預案，提出了三種方案，在開會過程中對各個方案進行提問，選出最經得起推敲的方案。
3. 你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
原計畫的工作最後都完成了。
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
有的。比如我們在開會過程中決定事情太過糾結，很耽誤時間。
5. 是否每一項任務都有清楚定義和衡量的交付件?
有的。在完成任務之後，我們會把結果公布在工作群當中。
6. 在計畫中有沒有留下緩衝區，緩衝區有作用麼?
有留下緩衝區，我們會把計畫定的比實際計畫晚一點，為了給出充分的改錯時間。
7. 將來的計畫會做什麼修改？
會把任務更加細分，讓大家更加明確自己的職責。
我們學到了什麼?如果歷史重來一遍,我們會做什麼改進?
我們學到了在計畫時應該更明確一些。如果歷史重來，我們會把計畫劃分的更細緻。
1. 我們有足夠的資源來完成各項任務麼?
有足夠的資源。組內有分別擅長前端開發、後端開發、gui設計、內容設計的人員。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
任務制定時，需要完成該任務的人員會估計任務的難度而確定時間，以天為精度。
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
由於小程式擁有便捷性的優勢，人力和軟硬體的資源足夠。對於不需要程式設計的資源沒有低估難度，在前期計畫時我們就確認，我們的小程式在內容設計上是重中之重。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
沒有，我們在分配任務時，大家都會評估自己更擅長某一方面，進而分配任務。
有什麼經驗教訓?如果歷史重來一遍,我們會做什麼改進?
在資源整合過程中，應該考慮多用技術而不是以人力為主。如果重來一遍，我們思考技術能給我們帶來怎樣的提公升。
1. 每個相關的員工都及時知道了變更的訊息?
都能及時知道，有變更我們會及時發到工作群裡。
2. 我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
我們在站立會議的時候進行討論，對所有任務進行排序，而且會考慮一些任務之間的先後順序。
3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
在alpha階段，我們把程式跑通作為出口條件。
4. 對於可能的變更是否能制定應急計畫?
會制定應急計畫。因為我們實際的計畫時間比規定的早一天，如果出問題會在這個時間進行修正。
5. 員工是否能夠有效地處理意料之外的工作請求？
可以。因為我們將七個人分為三組，我們在有安排變動時，會在組內直接交接任務。
我們學到了什麼?如果歷史重來一遍,我們會做什麼改進?
我們學到了在團隊管理中，要考慮以任務為團隊的驅動，讓大家明確自己的職責，如果再來一次，我們會找尋一種任務與人員之間的平衡。
1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
設計工作在每週課後，由組長組織會議大家共同**而成。是在合適的時間，全體成員都會參與。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
有碰到模稜兩可的情況，團隊會進一步將任務明確或者細分。
3. 團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？ 比較專案開始的 uml 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 uml 文件？
由於**量較少，沒有使用這些工具
4. 什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
沒有5. **複審（code review）是如何進行的，是否嚴格執行了**規範？
是1. 團隊是否有乙個測試計畫？為什麼沒有？
有測試計畫，但僅侷限於團隊內部測試。
2. 是否進行了正式的驗收測試？
沒有進行正式驗收測試。
3. 團隊是否有測試工具來幫助測試？
沒有測試工具。
4. 團隊是如何測量並跟蹤軟體的效能（performance）的？壓力測試（stress test）呢？ 從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
在alpha階段沒有涉及效能和壓力測試。
5. 在發布的過程中發現了哪些意外問題？
沒有發生意外。
我們學到了什麼?如果重來一遍,我們會做什麼改進?
我們學習到了測試是軟體開發很重要的組成部分。如果重來一遍，我們會將測試納入工作的重要組成部分之一。
1. 團隊的每個角色是如何確定的，是不是人盡其才？
我們是根據成員對自身的認知來決定的。做到了人盡其才。
2. 團隊成員之間有互相幫助麼？
有互相幫助，在團員時間有衝突的時候，及時調整了集體活動時間。
3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
通過開會進行討論，解釋自己的觀點來說服大家。
總結:
你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?
cmmi一級，執行級。
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?
處於磨合階段
全組討論的**
事後諸葛亮會議
作業資訊 專案內容 所屬課程 18web方向軟體工程 作業簡介 按照專案回顧模板開展事後諸葛亮會議並撰寫回顧報告 作業要求 團隊專案 任務四 第二次衝刺 作業目的 通過回顧軟體設計 開發 測試 構建 發布的整個過程以及團隊合作狀態總結經驗教訓 參考資料 學生姓名 張家林 撰寫人 於金池 趙政綱 王建...
事後諸葛亮會議
此作業要求參見 組名 板磚 組長 李惠璨 組員 張傳玉 朱航序 趙新萍 樊培毅 魏琛 設想和目標 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？2.我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?原計畫的...
事後諸葛亮會議總結
問 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？答 問題和需求明確，但是典型使用者，典型場景好像只是只是口頭說說了。問 是否有充足的時間來做計畫 答 我們覺得需求和計畫是這次實踐中最重要的問題，當然有。問 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？問...