一、組長部落格連結
組長部落格
二、總結思考
設想和目标
- 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
- 我們的APP主要解決大學生閑置物品處理問題，定義的很清楚，使用者清晰，我們的APP現階段主要針對的是福州大學學生，典型場景有閑置物品過多無法處理。
- 我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)?
- 達到了一部分目标，除了社群分享功能我們大部分都實作了，ALPHA版本已經初步完成，現階段還沒有投入使用，還處于待測試階段。
- 使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
- 還未到此階段。
計劃
- 是否有充足的時間來做計劃?
- 由于考試和其他課程的安排，我們的時間很緊張，是以計劃匆忙，并不是十分完備。
- 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
- 通過會議讨論和線上交流。
- 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
- 沒有全部做完，主要是因為時間緊張，技術方面有些欠缺。
- 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
- 有一點，比如我們的交易功能中的某些子產品。
- 是否每一項任務都有清楚定義和衡量的傳遞件?
- 是，每日的任務都已經在計劃中明确。
- 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
- 項目基本是按照計劃進行，意外就是社群功能沒有添加進去，沒想到會有考試及課程的時間沖突。
- 在計劃中有沒有留下緩沖區，緩沖區有作用麼?
- 在計劃中沒有留下緩沖區。
- 将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
- 在将來的計劃中，會盡量做到考慮的全面一些，同時留下緩沖區，加強風險管理。
- 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
- 學到了很多新技能。我們會量力而行，減少不必要的功能子產品。
資源
- 我們有足夠的資源來完成各項任務麼?
- 我們的資源目前足夠我們來完成現階段的各項任務。
- 各項任務所需的時間和其他資源是如何估計的，精度如何?
- 開始時精度很粗略，後來因為任務的逐漸加重，也因為大家這些日子一直忙着課程考試，抽出時間寫任務已經是最大，是以沒有再去想細化精度問題。
- 測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
- 人力資源是足夠的，硬體資源在現階段也是足夠的，而對于美工和文案我們最開始的确都低估了難度，真正上手才發現并不簡單。
- 你有沒有感到你做的事情可以讓别人來做（更有效率）?
- 我們現階段的事情都是可以自主完成的，而且一些設計如果交給别人來做反而會沒有辦法事後溝通修改，反而會加大工作量。
- 有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
- 我們會認真做資源配置設定。
變更管理
- 每個相關的員工都及時知道了變更的消息?
- 能，會議的交流和QQ群的溝通都比較順暢。
- 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
- 根據功能的重要程度和難易程度，如果是關系到後續工作或者其他同學工作的核心功能必須按時實作，以免拖慢整體進度。對于工作量很大但是并不影響其他工作和後續進行的可以适當推遲。這些功能的确定由小組讨論決定。
- 項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
- 有。經大家的讨論，考慮到時間問題和大家技術水準，在alpha階段我們隻關注于交易的核心功能。包括發帖子產品。我們的出口條件就是：選擇日期、類别進行交易，可以準确記錄當天的訂單和標明日期檢視當天的明細，選擇年月檢視消費類别的比例。
- 對于可能的變更是否能制定應急計劃?
- 在進行這個項目時由于時間關系并沒有制定應急計劃。但在我們計劃與實際出現偏差時，我們會及時調整計劃。
- 員工是否能夠有效地處理意料之外的工作請求？
- 大部分能。組長會把工作請求給相應的技術人員實作。
-
- 我們學到了Android開發的相關知識。
設計/實作
- 設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
- 設計工作是在需求确定之後，有團隊中擅長這一方面的同學來完成的，是合适的時間和合适的人。
- 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
- 很多，大家都不知道如何解決，也有時候會出現一些小問題但是能個人解決也就沒有影響團隊。
- 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？
- 我們暫時還沒有用這些工具來測試，因為這一階段大家對自己的工作也隻是勉強完成。
- 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
- 項目開始時的UML和現在的狀态有一點小差別，隻要在于有些功能還沒有實作，暫時還不需要更新UML文檔
- 什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
- 像是不知道Android有沒有友善快捷直接調用的Http，部分接口操作難以完成之類的出現了一堆bug。
-
- 學到了很多的專業技術，學會了代碼規範，接下來在代碼的規範控制上要做的更多。
測試/釋出
- 團隊是否有一個測試計劃？為什麼沒有？
- 有，但是沒有很規範。
- 是否進行了正式的驗收測試？
- 是，有邀請同學等作為使用者和測試隊員對軟體整體的功能在釋出平台上進行測試。
- 團隊是否有測試工具來幫助測試？
- 沒有。
- 團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
- 我們通過邀請室友、朋友或者假扮使用者來測試并跟蹤軟體的效能，并詢問回報或得出結論，再根據這些來繼續改進完善。這些測試工作是有用的，去測試後發現要改進的還是很多，有一些還是之前沒有發現的。而我們找到的改進有：界面不夠完善/功能有所欠缺。
- 在釋出的過程中發現了哪些意外問題？
- 出現一些之前沒注意的bug。
-
- 要注重測試，測試人員要熟練掌握測試工具的使用，能夠使項目的完成事半功倍。
團隊的角色，管理，合作
- 團隊的每個角色是如何确定的，是不是人盡其才？
- 根據每個成員的擅長領域和技術能力決定。做到了人盡其才。
- 團隊成員之間有互相幫助麼？
- 有，遇到問題大家都會一起讨論、一起想辦法，解決問題。
- 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
- 通過集體會議來解決管理問題。
- 我感謝朱曉倩對我的幫助， 因為某個具體的事情:感謝小朱陪我一起熬夜教我Java，熬不下去的時候真的很需要一個小夥伴的鼓勵。
- 學到了團隊互助。
總結
- 你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
- CMM/CMMI一共分為五個等級，(1)初始級(initial)；(2)可重複級(Repeatable)；(3)已定義級(Defined)；(4)已管理級(Managed)；(5)優化級(Optimizing)。我覺得我們處于CMMI二級，有明确的任務分工。
- 你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
- 我們團隊目前還處于磨合階段。
- 你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
- 對于團隊來說，大家的凝聚力要比前一個裡程碑時強很多，自覺性、自主性、學習能力都有所提高。對于項目來說，改進很大，因為上一個裡程碑時我們隻有形沒有狀，經過了ALPHA階段後，我們有了一個較完整的結構。
- 你覺得目前最需要改進的一個方面是什麼?
- 目前最需要改進的方面是APP的附加功能。
- 對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
-
原則：在團隊内部，最具有效果并且富有效率的傳遞資訊的方法，就是面對面的交談。事例：我們團隊每隔幾天都要開一次會議，如果有什麼疑問，可以直接面對面提出。
原則：每隔一定時間，團隊會在如何才能更有效地工作方面進行檢討，然後相應地對自己的行為進行調整。事例：我們團隊每隔幾天都要開一次會議，探讨工作進度和工作任務等，大家會提出使工作更有效的建議，如是否調整計劃，修改工作任務，調整任務配置設定等。
-
三、答辯總結
貢獻比例
|||||
|:-----😐:----😐------😐
|姓名|總分|貢獻比例|
|童景霖|43|12%|
|黃永福|45|13%|
|鄭志強|45|13%|
|許宏健|26|4%|
|劉禦帆|26|4%|
|葉澤林|39|5%|
|陳鴻立|45|13%|
|侯熠珉|26|4%|
|陳心怡|38|8%|
|唐 怡|38|8%|
|萬本琳|38|8%|
|朱曉倩|38|8%|
現場答辯得分
|:-----😐:----😐
|組号|分數|
|01|54.6|
|02|54.6|
|03|49.8|
|04|48（除去最低分)|
|05|51|
|06|52.2|
|07|52.2|
|08|54.6|
|09|56.4（除去最高分）|
|10|55.8|
|平均分|53.1|
建議及改進總結
第一組
無問題
第二組
Q:轉讓品質問題
A:我們的APP隻是提供一個線下二手交易的平台，而品質問題則是要由使用者之間自行溝通。
第三組
Q:示範内容不夠充足
A:我們下次會更加充足準備。
第四組
Q:對原始的産品進行優化改進
A:我們會對我們二手交易功能進一步優化。
第五組
Q:實作更多的功能，把伺服器搞好
A:我們伺服器已經基本搞定，但是前端的功能還需要進一步完善。
第六組
Q:功能還有一些欠缺，可以繼續加油完善，圖形界面可以
設定的更好
A:好的，謝謝！
第七組
Q:進一步完善，并修改bug
A:會繼續加強完善。
第八組
Q:後端資料庫互動完善
第九組
Q:前端、後端功能還未完善
A: 會繼續加強完善。
小組讨論合照
PSP表格
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| ** Planning ** | 15 | **20 ** | |
| · Estimate | · 估計這個任務需要多少時間 | 20 | |
| Development | 開發 | 490 | **380 ** |
| · Analysis | · 需求分析 (包括學習新技術) | 300 | 200 |
| · Design Spec | · 生成設計文檔 | 10 | |
| · Design Review | · 設計複審 | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 30 | 40 |
| · Coding | · 具體編碼 | 100 | 80 |
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | ||
| · Test Repor | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| total | 合計 | 530 | 415 |
學習進度
| 第N周 | 新增代碼（行） | 累計代碼（行） | 本周學習耗時（小時） | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 11 | 2200 | 8 | 98 | 學習Java和Android studio | |
| 12 | 2400 | 3 | 101 | ||
| 500 | 2900 | 109 | 熟悉html和css |