1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
幫助解決福大學生遇到的各種疑問，定義的算是清楚，有
2. 我們達到目標了麼（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？ 原計畫達到的使用者數量達到了麼?)?
並沒有達到目標，原計畫的功能大概完成了百分之七八十左右，現在還只是alpha階段，還沒有交付時間。
3. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
現在完成的內容和預想還有所偏差，主要功能實現還有問題，當然離目標更近了。
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
設想的很美好，現實很骨感，在我們設想的初期想了很多可以加的內容，剛開始想的時候比較有激情，高估了自己，想到什麼功能都一直往上加，然後後面在完成的過程中，發現實力跟想法相差懸殊，很多都捨棄了，沒有開發經驗，太天真。
如果歷史重來一遍，會根據自己的實際能力去設想一些功能，不要是太複雜的那種，否則既耗時耗力了，又沒有什麼成效，這樣對專案進度有很大的影響。
1. 是否有充足的時間來做計畫?
時間肯定不會充足，沒有人會覺得時間太多。在平時還有其他的課程要上，也不能把所有的時間都投入給軟工實踐，加上是第一次進行專案開發，所以我們的計畫就不是很細緻也不完善。
2. 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
對於計畫的不同意見，有進行相關的討論分析，如果有反對意見會再進行商量，然後看情況整改。
3. 你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
沒有。一開始的分工沒有特別明確，沒有將功能模組分配到個人，每個人都集中在同乙個模組，導致專案卡殼的時候每個人都沒有什麼新的進展了，沒有經驗，要花費的時間太多，一邊學習一邊做，一直有問題的時候激情就少了很多，進展就慢了，使很多原計畫的工作沒時間可以完成。
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
現在暫時沒有吧。
5. 是否每一項任務都有清楚定義和衡量的交付件?
定義的不是很清楚，一開始劃分的任務都是一整個模組的大任務，沒有細化到小版塊，而每個人負責的也比較模糊，通常都是在完成的過程中才進行分配。
6. 是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
沒有按照計畫進行，計畫的完成時間和實際的完成時間不一致，導致很多原定計畫不得不推遲或者捨棄。andriod的頁面跳轉有點問題。風險現在還暫時沒發現。
7. 在計畫中有沒有留下緩衝區，緩衝區有作用麼?
沒有，課業太多，一般的時間都是在晚上，也沒有其他空餘時間可以擠出來了。
緩衝區可以在一些意外發生的時候減少對實際進度的影響。
8. 將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
可以增設計畫緩衝區，然後將計畫的分工內容細緻一下。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
乙個良好的專案計畫是很重要的，這樣專案的執行過程也會更加有條不紊，有效率。
如果歷史重來一遍，將對計畫表做更詳細的規劃，分配好每乙個環節，以及每個人負責的模組，每個人完成自己的模組後再進行整合改進，就不會出現乙個環節停滯，所有人都一起停滯的現象了。
1. 我們有足夠的資源來完成各項任務麼?
現在任務量還比較小，資源還是夠用的。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
按照任務的分類來估計，如果是同乙個模組相似內容用時就估計少一點，但是由於我們是learning by doing，在某些任務上就經常會遇到瓶頸卡殼了，一開始是估計每天平均完成三四個任務這樣的，但是現實卻是有些任務花費了兩三天研究才解決，或者還未解決，所以在各項任務時間的估計上精度不是大。
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
現在還沒有進行測試，感覺人力上還是不夠的，沒有更加專業的人員，大家都是從起點開始一邊學習一邊完成的，力量還不是特別大。還好吧。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
團隊成員現在擁有的能力還是不夠的，如果讓能力更強的人來做，當然會更有效率。
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
合理分配好每個人力資源。
1. 每個相關的員工都及時知道了變更的訊息?
有團隊的群聊，訊息傳送很方便，如果是重大的變更，會討論研究讓每個相關人員都知道，如果只是一些細小的，只有負責該模組的人知道。
2. 我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
emmmm，沒有清晰的定義，覺得實現的功能和預想的差不多，然後在測試環節沒有什麼出錯，就感覺做好了吧。
4. 對於可能的變更是否能制定應急計畫?
盡自己所能制定。
5. 員工是否能夠有效地處理意料之外的工作請求？
經驗不足，不能有效處理，耗費的時間較多。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
在專案的完成過程中，肯定會發生一些意外，不得不對專案某些模組進行變更，但是處理卻不夠有效率。會先預想有什麼可能發生的變更，制定相應的應急計畫。
1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
在專案開始的初期，由團隊成員分工共同完成，要先設計再實現功能，所以時間應該合適吧，因為都是新手，所以合不合適還需要時間磨合。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
沒有遇到什麼比較模稜兩可的情況
3. 團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？ 比較專案開始的 uml 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 uml 文件？
還沒有運用單元測試和測試驅動的開發。有利用uml幫助設計，將設計都梳理了一遍，但是在開發的過程中也很少利用它了，通過安排表完成任務更加清晰一些。uml文件沒有什麼變化。
4. 什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
現在功能內容還比較少，產生的bug主要是資料顯示上有問題，**方面有問題，在研究中。
5. **複審（code review）是如何進行的，是否嚴格執行了**規範？
現階段還沒有進行**複審，**規範上每個人都有自己的編碼習慣，沒有在一開始就制定嚴格的**規範。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
在實現的一開始就要制定嚴格的**規範，在之後的整合過程中才能避免出現更多問題。
1. 團隊是否有乙個測試計畫？為什麼沒有？
現在還沒有測試計畫，因為專案還沒有開發完全，就沒有去想測試的事情。
2. 是否進行了正式的驗收測試？
沒有1. 團隊的每個角色是如何確定的，是不是人盡其才？
是在專案開發過程中慢慢確定的，邊學邊做，談不上每個人有什麼特別的才。
2. 團隊成員之間有互相幫助麼？
有的3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
分析問題，然後進行討論，看問題出現的原因，商議後共同解決問題。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
分配好每個團隊成員的角色，對每個人的任務有清晰的定義，讓專案的分工更加明確，才能更好的進行，加強溝通和交流。
你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?
cmm你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?
磨合你覺得目前最需要改進的乙個方面是
團隊每個成員的分工需要更加細緻一些。
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
1、以有進取心的人為專案核心，充分支援並信任他們
我們的組長非常有進取心，我們非常支援信任她，組長經常用她的進取心來感染我們，鼓勵我們繼續前行！
2、無論團隊內外，面對面的交流始終是最有效的溝通方式
在專案的開發過程中，我們每一天都有進行面對面的溝通交流，了解每乙個成員所遇到的問題，並一起解決。
事後諸葛亮
我們的軟體是為了提高實驗室協作管理的效率，讓實驗室事務安排變得有秩序，解決實驗室專案監管的視覺化以及學生經常遺忘專案安排的問題。定義較清楚，對典型使用者和典型場景也給出相應的描述。我們原計畫的功能做到了3個，完成部分的模組為日程管理，尚待完成的模組為協作管理，總體而言完成了alpha階段的計畫內容，...
事後諸葛亮
目錄 一 會議 二 設想和目標 2.我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?3.使用者量,使用者對重要功能的接受程度和我們事先的預想一致麼?我們離目標更近了麼?4.有什麼經驗教訓?如果歷史重來一遍,我們會做什麼改進?三 計畫 2.團隊在計...
事後諸葛亮
這個作業屬於哪個課程 這個作業要求在 homework 10863 團隊名稱 鴿子開發組 這個作業的目標 總結軟體開發過程的經驗和教訓 作業正文 如下其他參考文獻 無問題1 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？回答 軟體定義清楚，需解決的問題定義清楚。...