1.基本情況：

• 組長博客鏈接：http://www.rzrgm.cn/yaningscnblogs/p/14050343.html
• 答辯總結：答辯中，對于老師提出的意見，我們認為能夠幫助我們更加完善我們小組的產品，我們將基于現有功能，做出相應的修改，使我們的產品功能更加完備。
• 全組討論的照片
  
• 評估團隊中每個人對本次作業的貢獻比例，描述為本次作業的工作流程、組員分工、組員工作量比例（禁止一鍋端平的情況，如果沒有評估，全組平均后，組長得分減 50%）

成員	工作	貢獻比例（%）
吳凝	管理前后端任務進度；新增物品具體頁面，彈窗等功能以及輪播圖等具體樣式；編寫order的models以及新增user的部分接口	35.5
吳奕含	修改評論樣式，添加了隱藏項；修改了后端已完成部分的整合bug	22.5
梁瑾	實現了物品模塊接口	13.5
陳燕琴	嘗試編寫了信息模塊接口代碼	4.5
林碧晴	修改了消息界面的樣式	7
黃嘉穎	實現了用戶信息修改接口	9
張文婕	攥寫團隊的博客，并且進行項目答辯	8

2.總結思考

2.1. 設想和目標（4分）

2.1.1.我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？

答：我們的軟件要解決當前大部分人想要快捷地向周邊制定范圍內的人群借用物品的需求。目前來看，我們的定義大部分是比較清楚地，邊界比較明顯。我們的用戶面涉及比較廣，但是對于典型用戶和典型場景也有了比較清晰的描述。

2.1.2.我們達到目標了么（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了么？ 原計劃達到的用戶數量達到了么?)?

答：我們的目標大部分完成了，原計劃的功能基本實現了，但是由于后端的知識比較匱乏，目前還在學習當中，前后端的對接還在進行當中，因此還不能按照原計劃時間交付，需要延后一段時間。由于目前還沒有將全部功能完善，小程序還沒有進行面世，根據答辯時，老師提出的問題，我們也還需要繼續改進，所以用戶數量為零，還沒有達到我們的目標數量。

2.1.3.用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?

答：用戶量目前還不能在我們的考量范圍內，需要等我們的程序進行全部功能的進一步完善之后，才能開始進行用戶量的計算。目前為止，我們小組成員對程序的試運行時，大部分功能和我們預想一致，我們的接受程度是比較可觀的，但是具體面向用戶是什么情況，還要等待程序面世之后，才能具體進行調查。我們認為，我們在逐步靠近目標了。

2.1.4.有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?

答：從一開始就應該更加具體地明確小組成員的分工情況，并且在項目推行的過程中，應該邊學習，邊進行開發，提高效率。除此之外，也應該多借鑒網上的成功項目，作為模板來設計UI界面。

2.2. 計劃（5分）

2.2.1. 是否有充足的時間來做計劃?

答：是。

2.2.2.團隊在計劃階段是如何解決同事們對于計劃的不同意見的？

答：同事們在遇到意見相左時，可以互相理解，并進行再商討，得到一個雙方都滿意的答案。

2.2.3.你原計劃的工作是否最后都做完了? 如果有沒做完的，為什么?

答：沒有都做完。因為一開始，安排了大部分時間進行相關知識的學習，導致最后的具體操作時間比較少，不能夠完全進行具體功能的實現。

2.2.4.有沒有發現你做了一些事后看來沒必要或沒多大價值的事?

答：有。一個人專門管理前后端所有進度。

2.2.5.是否每一項任務都有清楚定義和衡量的交付件?

答：否。

2.2.6.是否項目的整個過程都按照計劃進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?

答：項目進行過程中，團隊成員在不同階段都有期末考試，時間很緊張，導致原定計劃沒有順利進行。沒有估計到后端推展的難度，因為團隊中成員都對后端不熟悉。前期對UI設計功能展示方面考慮涉及比較多，沒有更多的關注具體界面風格方面的問題，導致后期老師提出我們的界面風格問題，現在還需要花時間繼續改進。

2.2.7.在計劃中有沒有留下緩沖區，緩沖區有作用么?

答：沒有。

2.2.8.將來的計劃會做什么修改？（例如：緩沖區的定義，加班）

答：設置緩沖區，留出富裕時間。適當安排團隊成員進行加班工作，盡量在DDL前將工作完成。

2.2.9.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?

答：學到了應該各司其職。如果再來一遍，我們會一開始就設置好各個板塊的負責人，幫助進度更好地推展。

2.3. 資源（3分）

2.3.1.我們有足夠的資源來完成各項任務么?

答：有。

2.3.2.各項任務所需的時間和其他資源是如何估計的，精度如何?

答：UI優化需要一周左右的時間，后端也需要一周左右的時間。

2.3.3.測試的時間，人力和軟件/硬件資源是否足夠? 對于那些不需要編程的資源 (美工設計/文案)是否低估難度?

答：測試的時間，人力方面比較匱乏，小組只有7個人。對于不需要編程的資源，并沒有低估難度，因為她們的設計對接下來前后端的推展，也有很大的幫助。

2.3.4.你有沒有感到你做的事情可以讓別人來做（更有效率）?

答：后端的負責讓別人來做比較有效率。

2.3.5.有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?

答：我們應該更加合理高效地分配時間，利用好每一分每一秒。

2.4. 變更管理（4分）

2.4.1.每個相關的員工都及時知道了變更的消息?

答：是。

2.4.2.我們采用了什么辦法決定“推遲”和“必須實現”的功能?

答：根據項目的基本功能，以及當前進度，及時地調整我們的功能實現。

2.4.3.項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?

答：在測試端能夠按照我們的預期實現。

2.4.4.對于可能的變更是否能制定應急計劃?

答：能。

2.4.5.員工是否能夠有效地處理意料之外的工作請求？

答：能。

2.4.6.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?

答：從一開始就應該盡可能周全地制定我們的計劃，盡量避免在進行過程當中做變更，也應該做后備方案，以防萬一。

2.5. 設計/實現（4分）

2.5.1.設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？

答：設計工作在Alpha沖刺之前完成，由吳凝和梁瑾完成。是合適的時間，合適的人。

2.5.2.設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？

答：目前為止，還沒碰到過此類情況。

2.5.3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？

答：否，只用了AxureRP9實現。有效。

2.5.4.比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？

答：沒有區別，不需要更新。

2.5.5.什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?

答：有后端涉及的功能Bug比較多，因為我們團隊成員在后端方面的知識都是從零開始的。目前還沒發布。

2.5.6.代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？

答：我們項目還沒有進行到該階段。

2.5.7.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?

答：學到了AxureRP9更多的交互用法。如果能重來，我們會更早進行設計工作的開展。

2.6. 測試/發布（3分）

2.6.1.團隊是否有一個測試計劃？為什么沒有？

答：團隊還在具體實現階段，目前還沒有進展到測試階段，測試計劃還在設計當中。

2.6.2.是否進行了正式的驗收測試？

答：還沒。

2.6.3.團隊是否有測試工具來幫助測試？

答：沒有。

2.6.4.團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？

答:盡可能在測試功能是發現更多問題，帶著問題進行測試。由于還沒有進行實際運行，這些測試工作還沒展開。改進還需要在之后正式測試中發現。

2.6.5.在發布的過程中發現了哪些意外問題？

答：還沒發布。

2.6.6.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?

答：該部分相關知識還沒有學到。

2.7. 團隊的角色，管理，合作（3分）

2.7.1.團隊的每個角色是如何確定的，是不是人盡其才？

答：團隊里的角色是團隊成員各自根據自己喜好認領的，算是人盡其才。

2.7.2.團隊成員之間有互相幫助么？

答：有。

2.7.3.當出現項目管理、合作方面的問題時，團隊成員如何解決問題？

答：聽組長的安排。

2.7.4.每個成員明確公開地表示對成員幫助的感謝 （并且寫在各自的博客里）：

答：我感謝吳凝對我的幫助， 因為某個具體的事情：她給我們后端重新劃分了具體任務

2.7.5.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?

答：團隊合作很重要，有問題就要及時開口向組內其他成員進行提問，尋求幫助。

2.8. 總結（4分）

2.8.1.你覺得團隊目前的狀態屬于 CMM/CMMI 中的哪個檔次?

答：我們認為團隊目前狀態屬于CMM/CMMI一級。

2.8.2.你覺得團隊目前處于 萌芽/磨合/規范/創造 階段的哪一個階段?

答：我們認為團隊目前處于規范階段。

2.8.3.你覺得團隊在這個里程碑相比前一個里程碑有什么改進?

答：更熟悉相關任務，團隊成員之間磨合得比較好，合作起來比較和諧。

2.8.4.你覺得目前最需要改進的一個方面是什么?

答：考慮任務安排的合理性。

2.8.5.對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

答：歡迎對需求提出變更 - 即使在項目開發后期，要善于利用需求變更，幫助客戶獲得競爭優勢，對于項目進展中發現的新問題，可以及時修改原型，提出新的解決方案。
項目過程中，業務人員與開發人員必須在一起，團隊成員始終保持緊密聯系以及合作關系。
要善于激勵項目人員，給他們以所需要的環境和支持，并相信他們能夠完成任務，成員們之間互相信任，可以相互支持與鼓勵。