（一）設想和目標
1.我們的軟體要解決什麼問題？是否定義的很清楚？是否對典型使用者和典型場景有清晰的描述？
我們的軟體主要解決學生不清楚作業，課後難以解決問題以及不知道課程擺列的問題
2.是否有充足的時間來做計畫？
完成專案的時間不是很短，做計畫的時間足夠用，但是我們沒有很仔細的做出詳細的計畫，在完成專案的過程中，也在不斷的做著計畫。
3.團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
在pm的領導下，每乙個成員都能認真的聽取其他成員給出的不同意見，並通過相互討論協商解決問題，達到意見的一致。
使用者量，使用者對重要功能的接受程度和我們事先的預想一致麼？我們離目標更近了麼？
經過給一些使用者使用alpha
版本，發現使用者對軟體重要功能的接受程度和我們事先預想的差不太多，對重要功能還是很感興趣的，使用者感興趣，也實現了一部分功能，覺得離目標更近了。
有什麼經驗教訓？如果歷史重來一遍，我們會做什麼改進？
（二）計畫
1.你原計畫的工作是否最後都做完了？如果有沒做完的，為什麼？
原計畫的工作最後基本上都做完了。
2. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事？
這一階段做出的鬧鐘功能基本與手機自帶的一致，不能吸引使用者，沒有太大的價值。
3. 是否每一項任務都有清楚定義和衡量的交付件？
有比較清楚的定義和衡量的交付件
4. 是否專案的整個過程都按照計畫進行？
沒有按計畫進行，在安卓手機端進行軟體開發部分的知識學起來比較困難，所以這部分進度比較慢。
5. 在計畫中有沒有留下緩衝區，緩衝區有作用麼？
沒有，在展示的前一天晚上才勉強完成並可以使用。
6. 將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
對下一部分制定適應小組成員完成能力的計畫，嚴格按照計畫實行，留出一定的緩衝期進行測試。
我們學到了什麼？ 如果歷史重來一遍，我們會做什麼改進？
首先要制定好計畫，嚴格按照計畫實施。小組成員每天要講一下自己的進展情況，杜絕不做實事的情況發生。
（三）資源
1. 我們有足夠的資源來完成各項任務麼？
沒有，主要是在安卓手機開發方面完全空白，需要從頭開始學習，比較盲目，感覺看的多，但是最後學到不少東西，獲益匪淺。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何？
沒有什麼明確的依據進行估計，全憑討論覺得大概可以需要多少時間和資源就制定了計畫，因此並沒有什麼精度。
3. 測試的時間，人力和軟體
/硬體資源是否足夠？ 對於那些不需要程式設計的資源
(美工設計/文案
)是否低估難度？
沒有緩衝區進行測試，所以沒測試。
低估了難度，本以為美化很簡單，結果做出來達不到預期的效果。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）？
有，對於熟悉安卓或是有點經驗的人來說，整個第一階段實現的功能，可能不到一天就可以完成，效率很高。
有什麼經驗教訓？ 如果歷史重來一遍，我們會做什麼改進？
首先要找好資源，了解相關的技術難度，根據時間和能力**能不能完成這個軟體。
（四）變更管理
1. 每個相關的員工都及時知道了變更的訊息？
變更都是小組成員一起討論的結果，所以變更的訊息都能及時知道。
2. 我們採用了什麼辦法決定「推遲
」和「必須實現
」的功能？
根據完成需要的技術難度來決定先後順序，簡單的必須實現，難的可以推遲。
3. 專案的出口條件（
exit criteria –
什麼叫「
做好了」
）有清晰的定義麼？
有，預期的功能基本實現就算是做好了。
4. 對於可能的變更是否能制定應急計畫？
沒有應急計畫，沒有考慮過會出現緊急情況。
5. 員工是否能夠有效地處理意料之外的工作請求？
一直按照最初的計畫進行，沒有提出意料之外的請求。
我們學到了什麼？ 如果歷史重來一遍，我們會做什麼改進？
事先要想好可能出現的變更情況，並針對每一種情況做出應急計畫，定期找使用者調研意料之外的請求，並小組討論是否新增。
（五）設計/
實現1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
設計工作是最初由小組一起討論得出的。是合適的時間，合適的人。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
有，在使用者調研的時候，沒有了解使用者真實的想法，我們大都是通過自己想象中的情況來分析的。
3. 團隊是否運用單元測試（
unit test
），測試驅動的開發（
tdd）、
uml，或者其他工具來幫助設計和實現？這些工具有效麼？
沒有用過。應該比較有效吧。
4. 什麼功能產生的
bug最多，為什麼？在發布之後發現了什麼重要的
bug？ 為什麼我們在設計
/開發的時候沒有想到這些情況？
跳轉頁面部分產生的
bug最多，主要是不太熟悉函式的使用。發布之後發現新增的鬧鐘關不上，程序關閉不了。當時實現功能就可以了，沒有關心這些情況。
5. **複審（
code review
）是如何進行的，是否嚴格執行了**規範？
沒有進行**複審，**不規範。
我們學到了什麼？ 如果歷史重來一遍，我們會做什麼改進？
要對程式進行單元測試，每完成一部分測試一部分，及時修復
bug。
（六）測試/
發布1. 團隊是否有乙個測試計畫？為什麼沒有？
沒有計畫，就只是看一下能不能實現功能。第一次團隊合作，不知道還要有測試計畫。
2. 是否進行了正式的驗收測試？
沒有，就只是在班級演示了一下功能。
3. 團隊是否有測試工具來幫助測試？
虛擬機器、手機和應用寶的官方測試。
4. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
只在虛擬機器和手機上進行了測試，沒有用過測量並跟蹤軟體。有用，多運用測量和跟蹤軟體，可以更加及時的發現軟體的問題並改進。
5. 在發布的過程中發現了哪些意外問題？
有些功能在使用時應用會閃退
我們學到了什麼？ 如果歷史重來一遍，我們會做什麼改進？
測試很重要，要學會用一些有助於優化功能的軟體幫助我們改進。
（七）總結
你覺得團隊目前的狀態屬於 cmm/cmmi
中的哪個檔次？
屬於cmm
階段。你覺得團隊目前處於 萌芽/磨合/
規範/創造 階段的哪乙個階段？
目前正處於磨合階段，正相互之間進行磨合，溝通還是不夠。
你覺得團隊在這個里程碑相比前乙個里程碑有什麼改進？
認識成熟了，發現問題不是想象中的這麼簡單，考慮問題比之前稍全面，有了一些溝通。
你覺得目前最需要改進的乙個方面是什麼？
計畫方面，注重使用者體驗，根據他們的需求和意見修改計畫。
Alpha階段專案總結
一 設想和目標 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？我們團隊經討論後確定的第一衝刺階段的團隊目標便是實現基本的 掃瞄與生成還有登陸的介面。定義清楚，任務明確，然而對典型使用者的描述並不清晰。2.是否有充足的時間來做計畫？沒有充分時間做計畫，因為之前...
Alpha階段專案總結
1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？我們的軟體是一款面向高校學生的簡單快速的雲筆記，不僅具有筆記的新增 修改 檢視和刪除功能，還有筆記公開功能，使用者可以根據自己需要公開自己筆記。我們對典型使用者和典型場景做了具體的 來清晰的定義和描述。2.是否有...
Alpha階段專案總結
1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？我們的軟體是為了解決缺乏鍛鍊的大學生普遍存在，運動不足和運動積極性不高的問題。對軟體的作用定義的很清楚。我們對典型使用者和典型場景做了具體的描述。2.是否有充足的時間來做計畫?時間還是不夠，並沒有像預期的一樣完成...