1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們的軟體主要是用來解決人們的傾訴情感方面的需求；我覺得我們對典型使用者和典型場景描述的較為清楚，有比較強烈的實際應用需求，因為大家生活的過程中容易受到來自學習、生活、工作等各方面壓力的影響，乙個簡約的傾訴平台更利於使用者接受；具體的描述可以參考需求規格說明書
2.是否有充足的時間來做計畫?
差不多，但是因為大家對開發的流程等不大熟悉，所以還是略有延誤。
3.團隊在計畫階段是如何解決成員對於計畫的不同意見的？
聽隊長的。
4.使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
雖然上線了，但是使用者量還沒達到。但是我們有特意邀請同學體驗一下我們上線的小程式，與我們事先預想一致。我們離目標還是有點距離，但我們對它的前景很看好，在未來可能會對它進行改進發布。
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?1.你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?確定好每個人的工作，在前期做好所有事情的規劃。當然這是馬後炮了，只有經歷過團隊開發才知道規劃這方面有這麼多不足之處。
按照最初的設想，基本上都完成了，而且也成功上線了。
2.有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
暫時沒有，因為大家都要集中精力共同開發。
3.是否每一項任務都有清楚定義和衡量的交付件?
基本上是，除了一些比較模糊、難以劃分的任務。
4.是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
基本上是按照計畫進行，專案製作得還算順利，唯一沒有想到的是後面除錯的時候遇到一些奇奇怪怪的bugs，不過都順利解決了，都是意外。
5.在計畫中有沒有留下緩衝區，緩衝區有作用麼?
有預留，比如將ddl的時間自主地前移，可以有效保證任務按時完成。
1.我們有足夠的資源來完成各項任務麼?
還是可以的，我們組內有程式設計能力很高的成員，專案的完成不是問題，只是大家的經驗不足。
2.各項任務所需的時間和其他資源是如何估計的，精度如何?
感覺一下，精度不高。
3.有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
希望能有更多dl來支援，能更快地從技術上突破。
1. 每個相關的員工都及時知道了變更的訊息?
2. 我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
以專案的開發進度和功能模組來決定。若這個功能在專案的執行中是必不可少的，就是必需實現；若它可有可無，只是錦上添花的話，則可以作推遲處理。
3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
大致定義為以下幾點
4. 對於可能的變更是否能制定應急計畫?
是的，比如我們留下了緩衝區，可以在緊急情況下獲得更多時間、還有多個多技術型成員，可以在應急情況下及時處理問題。
5. 員工是否能夠有效地處理意料之外的工作請求？
是的。1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
在最初的集體會議中就著手準備設計的工作了，大家共同商討決定，還是挺合適的，如果能再早一點就好了。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
有，我們先以「最低要求」來實現，並且記錄本次問題，在專案後期再對這些情況作進一步處理，完善它們。
3. 團隊是否有測試工具來幫助測試？
有使用，它們的效果還很好，但是沒有大規模地進行，因為我們採用邊測試邊開發的思想，盡最大化程度地節省測試，而且我們最後時間似乎不大夠，但最後結果還是令人滿意的。
4. 什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
在我們這個專案中，收、發信的過程容易出現bug，因為它是核心、並且是常常使用的模組。專案構建中我們沒有以一種大局的觀念來進行專案的開發，在前後端等接合的地方容易出現問題。
5.**複審（code review）是如何進行的，是否嚴格執行了**規範？
我們有使用阿里巴巴的**規劃，大家在開發的ide上都安裝了這個外掛程式，所以**大都能按照規範進行。
6.我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
再早一點幹活會更好……
1. 團隊是否有乙個測試計畫？為什麼沒有？
有2. 是否進行了正式的驗收測試？
對安卓機、蘋果機的各主要功能進行了逐一驗證，都通過了。
3. 團隊是否有測試工具來幫助測試？
沒有，都是手動乙個乙個地測試的，因為這個程式的功能不多，量不高，所以這樣測試還能令人接受。對於以後的改進，我認為我們需要學習至少一種自動化測試工具，提高效率。
4. 在發布的過程中發現了哪些意外問題？
小程式上線的時候需要配置網域名稱，並且還要配置ssl，幸好我們小組有成員購買了網域名稱，順利解決，成功上線。
5.我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
測試對於程式來說還是很重要的，它可以發現很多編寫**中暫時未出現的bugs，我們未來還要繼續學習測試相關的手段或方法，若下次還有這種專案，可以使用自動化測試手段來提高效率。
1. 你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?
二級2. 你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?
萌芽階段，還是有很多很多很多需要學習的地方。
3. 你覺得目前最需要改進的乙個方面是什麼?
對專案的看法以及團隊專案的流程，這次開發的過程中，總感覺時間不夠，東西很多，還有很多bug，程式能跑起來已經很不錯了。我們還需要用一種工程的視角來看待這個大作業，希望以後做得更好，提交效率。
事後諸葛亮
我們的軟體是為了提高實驗室協作管理的效率，讓實驗室事務安排變得有秩序，解決實驗室專案監管的視覺化以及學生經常遺忘專案安排的問題。定義較清楚，對典型使用者和典型場景也給出相應的描述。我們原計畫的功能做到了3個，完成部分的模組為日程管理，尚待完成的模組為協作管理，總體而言完成了alpha階段的計畫內容，...
事後諸葛亮
目錄 一 會議 二 設想和目標 2.我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?3.使用者量,使用者對重要功能的接受程度和我們事先的預想一致麼?我們離目標更近了麼?4.有什麼經驗教訓?如果歷史重來一遍,我們會做什麼改進?三 計畫 2.團隊在計...
事後諸葛亮
這個作業屬於哪個課程 這個作業要求在 homework 10863 團隊名稱 鴿子開發組 這個作業的目標 總結軟體開發過程的經驗和教訓 作業正文 如下其他參考文獻 無問題1 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？回答 軟體定義清楚，需解決的問題定義清楚。...