目錄3. 答辯總結（6分）
4. 全組討論的**（1分）
5. psp與學習進度條（4分）
我們達到目標了麼（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？ 原計畫達到的使用者數量達到了麼?)?
使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
是否每一項任務都有清楚定義和衡量的交付件?
是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
在計畫中有沒有留下緩衝區，緩衝區有作用麼?
將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
各項任務所需的時間和其他資源是如何估計的，精度如何?
測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
你有沒有感到你做的事情可以讓別人來做（更有效率）?
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
對於可能的變更是否能制定應急計畫?
員工是否能夠有效地處理意料之外的工作請求？
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？
比較專案開始的 uml 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 uml 文件？
什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
**複審（code review）是如何進行的，是否嚴格執行了**規範？
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
是否進行了正式的驗收測試？
團隊是否有測試工具來幫助測試？
團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
在發布的過程中發現了哪些意外問題？
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
團隊成員之間有互相幫助麼？
當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的部落格裡）：
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?
你覺得團隊在這個里程碑相比前乙個里程碑有什麼改進?
你覺得目前最需要改進的乙個方面是什麼?
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
組員貢獻百分比
分工備註
楊世傑17%
後端表現很好
陳文彬15%
ui表現很好，擁有穩健的開發步伐
林巨集海15%
前端表現很好
林文濤12%
ui表現很好
龔洋林10%
前端符合預期
蘇偉歡10%
後端符合預期
活躍林小棠
10%後端
符合預期
張越洋4%
製作ppt、展示、寫部落格
沒有按時完成部落格和ppt
沒有預先模擬ppt展示，導致展示時重心偏移
沒有把控好開發進度
缺乏溝通
鄧志雄4%
提問、評分、製作評審表
符合預期
王淇弘3%
測試嚴重缺乏溝通
小組評分情況
146.8
252.8
346.6451
549.8
654.6
754.6
845.2
950.4
1048.6
1149.2
1243.2
小組提問回答1
篩選裡是否考慮加任務分類？
有的，將在beta版本上線
3如何平衡賞金機制？
是指發布者給予的酬勞嗎，根據市場**發布者自由決定
4怎麼保證所發出的任務的時效性？
發起者可設定任務持續時間或到期時間，beta版本上線
5市場上的任務懸賞是否具有預設排序？如何更好的讓別人查詢到想要的懸賞資訊
預設按發布時間排序，後續加入信用高的人將優先展示；可使用篩選/搜尋功能
6如何確保支付的安全性？
通過完善流程後續跟進
7能否保證支付的安全和線上支付？
線上支付步驟較為繁瑣，若反響較好後續會加入
8後端演算法如何更新任務，例如通過什麼演算法對任務進行排序？
信用度優先，其次按照時間降序
9可以通過支付的信用問題，設定每個使用者的信用分嗎
後續可以考慮
10如果是不碰面的任務，如何解決支付問題？
線上支付，通過完成訂單進行反饋
11申請較為繁瑣，反響較好後續將會繼續跟進
12狀態設計是否完備？
目前有未接單，已接單，beta版本將跟進已完成狀態
無psp2.1
personal software process stages
預估耗時（分鐘）
實際耗時（分鐘）
planning
計畫30
10· estimate
· 估計這個任務需要多少時間
3010
development
開發50
40· analysis
· 需求分析 (包括學習新技術)
5040
· design spec
· 生成設計文件00
· design review
· 設計複審 (和同事審核設計文件)00
· coding standard
· **規範 (為目前的開發制定合適的規範)00
· design
· 具體設計00
· coding
· 具體編碼00
· code review
· **複審00
· test
· 測試（自我測試，修改**，提交修改）00
reporting
報告40
50· test report
· 測試報告05
· size measurement
· 計算工作量05
· postmortem & process improvement plan
· 事後總結, 並提出過程改進計畫
4050
合計120
110第n周
新增**（行）
累計**（行）
本週學習耗時（小時）
累計學習耗時（小時）
重要成長10
000無
2300
3005
5不應毫無規劃就打**、學會用axure畫簡陋的原型圖
31100
1400
2328
學習網路介面的使用、學習pygame模組的使用40
1400
1543
學會畫燃盡圖50
1400
1053無6
01400356
意識到事先規劃的重要性
7153
1553
1265
明白了團隊開發的一般流程、如何使用管理團隊**、初步學習軟體測試80
1553
1075
學習11組組長陳鄭鏵的跑宿舍「交流」。反思
第02組 Alpha事後諸葛亮
目錄3.答辯總結 6分 4.全組討論的 1分 5.psp與學習進度條 4分 我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?使用者量,使用者對重要功能的接受程度和我們事先的預想一致麼?我們離目標更近了麼?有什麼經驗教訓?如果歷史重來一遍,我們會做...
第02組 Alpha事後諸葛亮
我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？答 我們 雪人兄弟2019 是一款懷舊遊戲，主要目的在於喚起使用者童年記憶的同時在遊戲中加入我們的獨特風格，讓玩家感到更加地愉悅和舒心。我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到...
第02組 Alpha事後諸葛亮
我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？答 我們 雪人兄弟2019 是一款懷舊遊戲，主要目的在於喚起使用者童年記憶的同時在遊戲中加入我們的獨特風格，讓玩家感到更加地愉悅和舒心。我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到...