1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們的軟體主要是用來解決，幫同學查課程成績，查體測成績等問題的需求。我覺得我們對系統內的主要功能，的目標還是很明確的，有比較強的實際應用需求，因為同學們在平常選課和查體測成績的時候都異常的困難，所以我們才有這個想法，去做這個小的系統。一方面就滿足自己的需求，也滿足同學們的需求。
2.是否有充足的時間來做計畫?
因為大家對開發的流程等不大熟悉，在計畫上做的一般。
3.團隊在計畫階段是如何解決成員對於計畫的不同意見的？
大家商量討論，投票決定。
4.使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
雖然上線了，但是使用者量還沒達到。我們離目標還是有點距離，在未來可能會對它進行改進發布。
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?1.你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?確定好每個人的工作，在前期做好所有事情的規劃，盡量的把計畫做的完美一點，在使用者需求上也盡可能的多去調查。當然這是馬後炮了，只有經歷過團隊開發才知道規劃這方面有這麼多不足之處。
按照最初的設想，基本上都完成了，而且也成功上線了，但還是有一部份的功能未實現。
為什麼：時間上有點不足，技術上有點困難
2.有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
暫時沒有，因為大家都要集中精力共同開發。
3.是否每一項任務都有清楚定義和衡量的交付件?
基本上是，除了一些比較模糊、難以劃分的任務。
4.是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
基本上是按照計畫進行，專案製作得還算順利，但是最終除錯的時候遇到一些奇奇怪怪的bugs，不過都順利解決了，都是意外。
5.在計畫中有沒有留下緩衝區，緩衝區有作用麼?
有預留，在每個小任務的時候，做計畫都把時間做的寬裕點，可以有效保證任務按時完成。
1.我們有足夠的資源來完成各項任務麼?
有點困難，我們組比較少程式設計能力很高的成員，勉強能完成專案，也學到了很多。
2.各項任務所需的時間和其他資源是如何估計的，精度如何?
感覺一下，然後比感覺的在寬裕一點，但精度不高。
3.有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
希望能有更多程式設計能力很高的大佬來支援，能更快地從技術上和時間上突破。
1. 每個相關的員工都及時知道了變更的訊息?
2. 我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
以專案的開發進度和功能模組來決定。若這個功能在專案的執行中是必不可少的，就是必需實現；若它可有可無，只是錦上添花的話，則可以作推遲處理。
3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
大致定義為以下幾點
4. 對於可能的變更是否能制定應急計畫?
有點難，我們的對較少程式設計能力很高的成員，對應急的事情要多方討論互相查詢資料，但是，我們做的計畫多有寬裕，專案難度不是很大，應急計畫相對來說不是很重要，當然這也是我們的弱點。
5. 員工是否能夠有效地處理意料之外的工作請求？
能。1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
在最初的集體會議中就著手準備設計的工作了，大家共同商討決定，還是挺合適的，每天都有線上的小會，一起討論計畫。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
沒有，雖然我們的專案簡單，但我們的目標很明確。
3. 團隊是否有測試工具來幫助測試？
有使用，它們的效果還很好，但是沒有大規模地進行，因為我們採用邊測試邊開發的思想，盡最大化程度地節省測試，而且我們最後時間似乎不大夠，但最後結果還是令人滿意的。
4. 什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
相對來說，每個小功能的bug多差不多，沒有什麼特別重要的bug，但是在最後功能一體的時候，就有一些奇怪的bug出來，是設計的時候沒有想到的。
5.**複審（code review）是如何進行的，是否嚴格執行了**規範？
由於我們的專案比較小，我們沒有這一塊的功能。
6.我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
再早一點幹活會更好……，再加一些大佬會更好
1. 團隊是否有乙個測試計畫？為什麼沒有？
有2. 是否進行了正式的驗收測試？
對各大瀏覽器都進行了主要功能進行了逐一驗證，都通過了。
3. 團隊是否有測試工具來幫助測試？
沒有，都是手動乙個乙個地測試的，因為這個程式的功能不多，量不高，所以這樣測試還能令人接受。對於以後的改進，我認為我們需要學習至少一種自動化測試工具，提高效率。
4. 在發布的過程中發現了哪些意外問題？
沒有，比較順利。
5.我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
測試對於程式來說還是很重要的，它可以發現很多編寫**中暫時未出現的bugs，我們未來還要繼續學習測試相關的手段或方法，若下次還有這種專案，可以使用自動化測試手段來提高效率。
1. 你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?
二級2. 你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?
萌芽階段，還是有很多很多很多需要學習的地方。
3. 你覺得目前最需要改進的乙個方面是什麼?
對專案的看法以及團隊專案的流程，這次開發的過程中，總感覺時間不夠，要自學的東西很多，程式能跑起來已經很不錯了。我們還需要用一種工程的視角來看待這個大作業，希望以後做得更好，提交效率。
成員學號
職責角色貢獻分（10分滿）
陳觀匯3118005267
測試、撰寫部落格
7.5黃靖
3118005275
前端開發、測試
7朱長江
3118005303
後台開發、測試、撰寫部落格
9阿布都外力.肉孜
3118005266
前端開發、測試
7甄海輝
3118005300
後台開發、測試
9鄧佩昌
3118005270
測試、撰寫部落格
7
事後諸葛亮
我們的軟體是為了提高實驗室協作管理的效率，讓實驗室事務安排變得有秩序，解決實驗室專案監管的視覺化以及學生經常遺忘專案安排的問題。定義較清楚，對典型使用者和典型場景也給出相應的描述。我們原計畫的功能做到了3個，完成部分的模組為日程管理，尚待完成的模組為協作管理，總體而言完成了alpha階段的計畫內容，...
事後諸葛亮
目錄 一 會議 二 設想和目標 2.我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?3.使用者量,使用者對重要功能的接受程度和我們事先的預想一致麼?我們離目標更近了麼?4.有什麼經驗教訓?如果歷史重來一遍,我們會做什麼改進?三 計畫 2.團隊在計...
事後諸葛亮
這個作業屬於哪個課程 這個作業要求在 homework 10863 團隊名稱 鴿子開發組 這個作業的目標 總結軟體開發過程的經驗和教訓 作業正文 如下其他參考文獻 無問題1 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？回答 軟體定義清楚，需解決的問題定義清楚。...