我們的軟體要解決什麼問題？是否定義得很清楚？
答：日常生活中，我們常常會為自己制定計畫或目標，並給這些計畫和目標定下完成的期限，於是light_note網頁版備忘錄應運而生，旨在督促和鼓勵使用者在規定的期限裡完成自己制定的目標，應用的定義也較為清楚。
我們達到目標了麼（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？ 原計畫達到的使用者數量達到了麼?)
答：基本達到了原計畫的功能。交付時間稍晚於原計畫。目前使用者數量僅限於組內成員，未達到原計畫。
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
答：在經驗教訓方面是時間安排，如果再來一次，會指定更加合理更易執行的時間安排。
改進：提高自己的程式設計能力、以及對於程式語言和框架的熟練度很有必要。
是否有充足的時間來做計畫?
答： 有。之前有充分的時間來討論、構想整個軟體的框架，之前布置的每一項作業都在不斷地讓整個軟體的輪廓在我們的大腦中變得清晰。但由於作業實在過多，加上考試複習， 所以程式設計時間是不夠。
團隊在計畫階段是如何解決同事們對於計畫的不同意見的？你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
答： 基本完成。
是否每一項任務都有清楚定義和衡量的交付件?
答： 有。在alpha衝刺的初期，全組成員開會最主要就是討論清楚整個業務邏輯，討論完業務邏輯，我們再細分出各個任務，並在teambition**上進行任務認領和分配，這些東西就是具體的交付件。
在計畫中有沒有留下緩衝區，緩衝區有作用麼?
答：沒有刻意留下緩衝區。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
我們有足夠的資源來完成各項任務麼?測試的時間，人力和軟體/硬體資源是否足夠?
答： 由於本次專案是web應用，測試時涉及到的是各瀏覽器，對硬體資源沒有過多的要求，所以軟/硬資源足夠；但測試的時間和人力不足。
對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
答：是。
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
答：前期準備不充分會影響後期的開發效率。如果重來一遍，由於網上有足夠的資源來讓我們學習開發所需的技術以及熟悉如何開發專案的流程，那麼我會在前期花更多的時間去做足準備，比如深入的去進行需求分析，以及花更多的時間去提高編寫**的能力，同時我們會更加注重對**的測試，以保證程式**的健壯性。
每個相關的員工都及時知道了變更的訊息?我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
答：必須實行的功能：專案的核心功能和alpha衝刺實際開發過程中遇到困難較小的功能。
推遲：由於alpha衝刺的時間不多，所以「推遲」一般是因為這個功能可能需要較大的工作量。
對於可能的變更是否能制定應急計畫?
答：沒有特定去制定應急計畫，遇到問題立刻著手解決。
成員是否能夠有效地處理意料之外的工作請求？
答： 大部分能。有些意外情況自己實現不了，也會請教有經驗的同學的方式幫忙解決。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
答：計畫趕不上變化，開發過程中不會一帆風順，採用一套好的變更管理策略就變得很重要，如果重來一遍，我們會加強對專案進展的相關細節方面的管理，隊員們每日匯報自己完成那部分工作的進度和遇到的困難，是否解決等資訊，以便pm能對專案的進展有全域性的了解，能及時的對工作進行調整，提高整個專案的開發效率。
設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
答：在alpha衝刺的初期，全組成員開會討論清楚整個業務邏輯，並進行任務認領和分配。
設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？**複審（code review）是如何進行的，是否嚴格執行了**規範？
答：由組長複審，基本嚴格執行了**規範，能提高**的整體質量，提高可拓展性。
團隊是否有乙個測試計畫？為什麼沒有？
答：有，每個人都要測試自己部分以及選擇一部分測試。
團隊是否有測試工具來幫助測試？
答：無。
團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
答：各個模組的單元測試由相應的開發組員進行，頁面整合完後，在不同的瀏覽器上使用，進行整體測試。
在發布的過程中發現了哪些意外問題？
答：暫時沒有。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
答：良好的測試是保證**質量的前提，如果重來一遍，我們對不同功能的**，設計覆蓋範圍更加全的資料來進行測試，並且把測試的結果和對結果的分析寫入測試文件。
你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?
答：達到cmmi中的二級，管理級別。
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?
答：磨合階段。
你覺得團隊在這個里程碑相比前乙個里程碑有什麼改進?
你覺得目前最需要改進的乙個方面是什麼?
答：團隊成員仍需要更加積極。
下個階段需要改進什麼？
答：可能沒有下個階段了，但還是敬請期待。
名字角色
團隊貢獻分
可驗證的貢獻
黃源欽pm，dev
40%總體設計，編寫前端**，編寫部分後端**
黃敦鴻dev,test
25%編寫部落格，編寫部分後端**
黃駿鵬dev,test
25%編寫部分後端**
黃華test
5%測試
李洋test
5%測試
事後諸葛亮分析報告
目錄隊伍名 銀河超級無敵艦隊 專案 招新通 集合貼 團隊作業6 複審與事後分析 一 會議 二 設想和目標 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？解決招新時的招新成員資料整理繁雜的痛點，定義清楚，是。詳情可見需求規劃說明書。是否有充足的時間來做計畫?有。我...
事後諸葛亮分析
這個作業屬於哪個課程 這個作業要求在 homework 11154 這個作業的目標 事後分析報告 目錄1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？答 我們軟體主要解決班級裡面用通知群作為通知手段的一些痛點。定義其實並不是特別清楚，還有一些場景沒有描述。2....
事後諸葛亮分析
一.設想和目標 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？我們的軟體預期在實現最基本的打卡工具的基礎上，新增番茄鐘專注功能和社交圈子吸引使用者，定位明確。但有些使用邏輯略顯累贅，後期稍有修改，但還有地方可以做到更好。2.我們達到目標了麼 原計畫的功能做到...