組長部落格
我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
要解決的是喜歡記錄分享旅遊生活的人群的行跡記錄和分享問題，提供乙個方便的平台，供這些使用者記錄和分享、交流。
相關定義，典型使用者和典型場景已在需求分析報告有清晰的描述。
我們達到目標了麼（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？ 原計畫達到的使用者數量達到了麼？)？
是否按原計畫交付時間交付
原計畫預期的使用者數量是否達到
使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼？ 我們離目標更近了麼？
有什麼經驗教訓？ 如果歷史重來一遍, 我們會做什麼改進？
是否有充足的時間來做計畫？
團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
你原計畫的工作是否最後都做完了？ 如果有沒做完的，為什麼？
有沒有發現你做了一些事後看來沒必要或沒多大價值的事？
是否每一項任務都有清楚定義和衡量的交付件？
是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到？
在計畫中有沒有留下緩衝區，緩衝區有作用麼？
將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
我們學到了什麼？ 如果歷史重來一遍, 我們會做什麼改進？
我們有足夠的資源來完成各項任務麼？
各項任務所需的時間和其他資源是如何估計的，精度如何？
測試的時間，人力和軟體/硬體資源是否足夠？
對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度？
你有沒有感到你做的事情可以讓別人來做（更有效率）？
有什麼經驗教訓？ 如果歷史重來一遍, 我們會做什麼改進？
每個相關的員工都及時知道了變更的訊息？
我們採用了什麼辦法決定「推遲」和「必須實現」的功能？
專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼？
對於可能的變更是否能制定應急計畫？
員工是否能夠有效地處理意料之外的工作請求？
我們學到了什麼？ 如果歷史重來一遍, 我們會做什麼改進？
設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？
比較專案開始的 uml 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 uml 文件？
什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug？ 為什麼我們在設計/開發的時候沒有想到這些情況？
**複審（code review）是如何進行的，是否嚴格執行了**規範？
我們學到了什麼？ 如果歷史重來一遍, 我們會做什麼改進？
團隊是否有乙個測試計畫？為什麼沒有？
是否進行了正式的驗收測試？
團隊是否有測試工具來幫助測試？
團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
在發布的過程中發現了哪些意外問題？
我們學到了什麼？ 如果歷史重來一遍, 我們會做什麼改進？
團隊的每個角色是如何確定的，是不是人盡其才？
團隊成員之間有互相幫助麼？
當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
我們學到了什麼？ 如果歷史重來一遍, 我們會做什麼改進？
我感謝 永福大佬 對我的幫助， 因為？
你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次？
軟體工程管理制度缺乏，過程缺乏定義、混亂無序。成功依靠的是個人的才能和經驗，經常由於缺乏管理和計畫導致時間、費用超支。管理方式屬於反應式，主要用來應付危機。過程不可**，難以重複。ps：我覺得反應式管理挺好的，挺刺激的
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段？
你覺得團隊在這個里程碑相比前乙個里程碑有什麼改進？
你覺得目前最需要改進的乙個方面是什麼？
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則？ 請列出具體的事例。
由於答辯後部分成員存在傷殘情況和其他不可抗力，未能出席本次會議
這再次說明了軟體工程實踐是一門不吉利的課程
成員分工
貢獻度王永福
主要**開發，派任務、催進度、**規範
42%孫承愷
美術監督、現場評審、評分表整理
7%邱暢傑
分享圖生成相關實現
8%丁樞桐
分享圖生成相關實現
8%徐祖豪
評審表設計
4%餘琳玲
答辯ppt
7%林星培
答辯ppt
7%林青霞
答辯ppt
7%張凌昕
alpha大部分部落格
10%組號分值1
57254.634
545658.2
754.6853
956.4
1011
1250.4
平均
54.9
截至本部落格撰寫時(2019-11-24t17:00)，空白小組尚未評分
你們這麼嫖柯老闆的問題真的好嗎
截至本部落格撰寫時(2019-11-24t17:00)，尚未提問
psp2.1
personal software process stages
預估耗時（分鐘）
實際耗時（分鐘）
planning
計畫
2
2
estimate
估計這個任務需要多少時間22
development
開發
1055
17
analysis
需求分析 (包括學習新技術)
1025
design spec
生成設計文件610
design review
設計複審22
coding standard
**規範 (為目前的開發制定合適的規範)
1215
design
具體設計
2436
coding
具體編碼
2436
code review
**複審
1218
test
測試（自我測試，修改**，提交修改）
1530
reporting
報告
6
9
test repor
測試報告23
size measurement
計算工作量52
postmortem & process improvement plan
事後總結, 並提出過程改進計畫24
合計155
172第n周
新增**（行）
累計**（行）
本週學習耗時(小時)
累積學習耗時(小時)
重要成長10
055熟悉axure rp用法20
0510了解原型設計方法30
0515原型設計實戰40
01227團隊專案原型設計50
01542學習kotlin60
01052學習kotlin70
0860學習kotlin80
0767了解kotlin90
0774學習kotlin
Alpha事後諸葛亮
aruba小組cento專案postmortem 408409 410428 429431 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？主要解決文字摘錄愛好者的摘錄癢點 應用間切換的不方便。定義清楚，我們知道要做的東西會是個什麼樣子。需求分析階段，典型使用...
Alpha事後諸葛亮
我們的軟體要解決的問題是對福大校內各個任務群 拼車群的資源整合，方便校內學生以更高的效率拼到車或發布任務。另外還有乙個板塊用來給大家討論。定義得清楚。有。目標達到了。功能都完成了，也按計畫交付了，但是尚未對外開放。使用者對重要功能的接受程度和我們事先的預想一致。我們離目標更近了。比如需要更早的開啟專...
alpha事後諸葛亮
達到了一部分的目標並按照計畫時間交付，但還未達到原計畫的使用者數量。軟體還未開放公測，小範圍內測中。使用者對重要功能的接受程度和我們事先的預想基本一致，離目標越來越近了。經驗教訓 想做的東西太多，但時間和準備上的不充足，讓我們不得不放棄許多功能。如果歷史重來一遍，我們會重新分析需求，細化任務分配，挑...