- 一.總結思考
- 1.設想和目標
- 2.計划
- 3.資源
- 4.變更管理
- 5.設計/實現
- ①設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
- ②設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
- ③團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？
- ④比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
- ⑤什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
- ⑥代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
- ⑦我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
- 6.測試/發布（3分）
- 7.團隊的角色、管理、合作
- 8.總結
- 討論照片
- 二.答辯總結
- 個人PSP
- 個人學習進度條
- 一.總結思考
- 1.設想和目標
- 2.計划
- 3.資源
- 4.變更管理
- 5.設計/實現
- ①設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
- ②設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
- ③團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？
- ④比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
- ⑤什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
- ⑥代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
- ⑦我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
- 6.測試/發布（3分）
- 7.團隊的角色、管理、合作
- 8.總結
- 討論照片
- 二.答辯總結
- 個人PSP
- 個人學習進度條
一.總結思考
1.設想和目標
①我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
我們的借唄app定義得很清楚，要解決的是“學校活動室借還困難與線下物品借還困難”的問題。
典型用戶
a.需要短時間使用某件物品的有(租)借入需求的用戶。
b.想將閑置物品借出共享的有(租)借出需求的用戶。
c.想提高管理、分配活動室/物資效率的管理者和被繁瑣借用流程所擾的借方。
典型場景
②我們達到目標了么（原計划的功能做到了幾個？ 按照原計划交付時間交付了么？ 原計划達到的用戶數量達到了么?)?
功能還差幾個未完成，例如“消息模塊”的推送學校、學院通知的功能，和數據分析功能。
已經按照原計划交付時間交付了，還未達到原計划的用戶數量。
③用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?
接受程度按照周六早晨的答辯來說和我們的預想大概一致，我們離目標更近了
④有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
學到了在做規划的時候不能將餅畫的太大，目標還是得定在可實現范圍內
如果歷史重來一遍，我們會更加細化考慮預設的軟件功能，在能力所致范圍內給大家帶來更多的驚喜功能。
2.計划
①是否有充足的時間來做計划?
從布置團隊作業開始，我們就通過會議討論好了大致的分工和APP要做的方向，但是過程中做計划的時間不多，但隨着項目的完善，我們也在不斷改善自己的計划。
②團隊在計划階段是如何解決同事們對於計划的不同意見的？
通過會議討論，大家提出各自的 意見，覺得合理可行的即通過，在項目的實際進行過程中，在產品經理畫好大致框架的情況下，UI和前后端各自視情況而定，大佬說的都對。
③你原計划的工作是否最后都做完了? 如果有沒做完的，為什么?
林睿（組長）：原計划的任務是總體進度的跟進和博客，算是做完了，不過期間由於考試等原因改過幾次進度
鄧澤源：分析算法基本完成，加權優化還在改進中，為什么沒做完，因為要考試要恰飯要睡覺要禿頭的啊 靚仔
張慶焰：原計划的前端和與后端的交互基本上完成，沒做完的有部分UI圖還沒做好
姚彬錕：完成社區界面的設計和還有登陸界面
朱宏 ：原本想把數據分析做好，結果生活還是太難了
蔡雅菁：產品經理的工作完成，主要任務是計划“借唄”app的整體框架與細節、做ppt和寫計划書
吳潔敏：原計划的UI界面基本上做完了，沒有完善好，打雜工作沒做好，組長大大賽高
周鑫煌：有。沒做完還能為什么？當然是因為沒時間啊！書不用讀嗎？作業不用寫嗎？考試不用復習嗎？（靈魂三問）
王景弘：原計划的UI設計工作最后都做完了
陳展鴻：原計划的內容沒有完全做完（因為還有beta沖刺），只能說alpha沖刺內容已經做完
陳觀鴻：前端任務完成百分之八十，還有一部分前后端對接任務還沒完成，因為前后端對接不太會
④有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
林睿（組長）：貌似沒有
鄧澤源：真的想不出來，大概是沒有吧
張慶焰：由於之前有過安卓項目經歷，所以並沒做什么沒必要或者沒多大價值的事
姚彬錕：完成的任務基本都是提前已經設計好且必須要完成的任務，那些瑣碎而沒多大價值的事情我們在設計階段就已經排除了
朱宏 ：.感覺畫再多的ui，最后也會被實現的復雜性打倒
蔡雅菁：好像沒有？個人感覺我們組分配任務還挺合理的，每個人都完成自己的分內之事，然后不斷學習
吳潔敏：有，之前設計的UI界面中有的部分並沒有設計好，有時寫博客太過拖拉，效率不高
周鑫煌：發現沒有去研究運用一些設計模式，投入的時間大部分在重復的垃圾代碼上，再多的代碼量也顯得沒有價值。
王景弘：的確有一些事是事后看來沒必要的，例如前一兩例的UI設計，因為剛剛入門所以對很多要求都不甚明了，直接導致做了大概四五個小時的廢版，然后推倒重做，后面想來如果做之前有充分的溝通交流就不會這么浪費時間了
陳展鴻：沒有，做的全都是有意義的事，每一個模塊都有其特定的功能
陳觀鴻：都挺有價值的，這得歸功於大佬帶的好，我就完成了他說的部分，沒有多余部分，zqy太猛
⑤是否每一項任務都有清楚定義和衡量的交付件?
有的有，有的沒有，有的部分在前期做的時候並沒有考慮完善。但有項目經歷的前后端大佬的部分做的會比較好。在開始真正編寫代碼之前，前后端人員有進行詳細的溝通，並制定了前期的計划，例如制定了一些接口的規范、所使用的技術規范，總體而言，對於每一項任務都有較為清楚的定義。
⑥是否項目的整個過程都按照計划進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
首先我們制定了一些計划，並且有按照計划一步一步實現，但是在開發的過程中難免會遇到一些重要但是開始沒有計划到的內容，於是就會脫離計划去完成那些重要內容，項目並沒有出現大的意外，風險嘛，目前還沒估計，因為項目還沒真正完成，所以還沒考慮。
⑦在計划中有沒有留下緩沖區，緩沖區有作用么?
有留下一些時間用於前后端交互和修改debug，就是盡早的打完代碼。有作用，讓前后端交互和改bug的時間不會擠到最后。
⑧將來的計划會做什么修改？（例如：緩沖區的定義，加班）
目前一些核心的界面及后端基本上已經完成，在此基礎下，會盡快完善剩余的一些界面，規划好deadline，再擴展緩沖區做debug，以防最后匆忙慌亂。還准備在項目最終完成前留下一些用戶測試的緩沖區，以完善一些功能。
⑨我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
學到了要留下緩沖區做前后交互和debug，不能將計划制定的剛剛好。
如果歷史重來一遍，我們會更細分各自要做的任務，讓前后端人員更加輕松一些，將任務分配的更平均一些。並且要在一開始就細分好每個任務的deadline，讓項目有條不紊的進行。
3.資源
①我們有足夠的資源來完成各項任務么?
我們有足夠的資源來完成各項任務（但時間資源有些稍微不充分）
②各項任務所需的時間和其他資源是如何估計的，精度如何?
我們所需的時間是根據人員的分配以及個人能力估計的，精度大致相同
③測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
測試的時間和資源都足夠，對於不需要編程的資源未低估難度
④你有沒有感到你做的事情可以讓別人來做（更有效率）?
可能懂技術的人來擔任和分配任務會更合適一點，這樣更清楚如何分工
⑤有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
對於時間分配來說，由於碰上了考試多的一周，所以時間分配上不是特別充裕
如果歷史重來一遍，我們會對時間安排更加上心，不會拖到時間不夠的時候才完成
4.變更管理
①每個相關的員工都及時知道了變更的消息?
是的，我們建立了群聊，每次有什么比較重要的變更都會艾特相關成員通知，確保每個人及時收到消息。
②我們采用了什么辦法決定“推遲”和“必須實現”的功能?
我們嚴格的對每個界面進行設計，如果有x->y，也就是必須先有y才可以做x，那么必須實現的就是x，可以推遲的就是y。當然有一部分y是拓展的功能不是app主要部分的話，我們也會推遲。
③項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?
我們認為進行測試完，總體功能都能實現，不出現明顯錯誤的情況為做好了。做好了后仍然會進行優化。
④對於可能的變更是否能制定應急計划?
沒有什么特殊的應急計划，遇到了就是加班加班加班。
⑤員工是否能夠有效地處理意料之外的工作請求？
我們規定請求都轉到組長那里處理，這樣減輕了開發人員的壓力，讓他們有大部分時間花在自己那一部分的開發，然后意料之外的事情大家會一起思考解決。
⑥我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
考慮的東西還是不夠多，很多地方考慮的仍然不夠細致，如果歷史重來一遍，我們會對每一塊內容進行更加細致的分析，前期准備做的更好。
5.設計/實現
①設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
設計工作從Alpha之前的十天就已經開始准備了，設計人由 周鑫煌，張慶焰，陳展鴻三人為核心開展，其余組員提意見和建議，在alpha沖刺前，就已經完成了大致的項目結構。我覺得是一個合適的時間，也是合適的人。
②設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
在前端設計中，會產生和UI圖的布局有少許差別的情況，算是模棱兩可，此時的話，就會以前端設計為主，等項目成型后，再由美工去提意見，然后進行修改，小問題的話，就先做出來，然后再去扣細節。
③團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？
使用過單元測試來測試API的對接是否可用。
④比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
項目開始的UML比較沒有那么的細致，現在的細節比較多，這些去別的產生是由於隨着開發進行，有一些功能被我們去放棄，而有一些細節部分，又被我們加上去，所以產生了區別。是應該更新UML文檔。
⑤什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
首頁布局上出的BUG比較多，主要是因為布局相對復雜。UI需求是一個Header(作為廣告位) + Tab(切換類別) + 瀑布流列表，最初想通過ViewPager實現，后來發現這樣做會造成滑動沖突，導致Header無法上滑被隱藏，換用RecyclerView后基本能實現想要的效果，但是瀑布流有時item的尺寸又會出BUG，改了蠻久。發布后發現服務器對高並發的處理能力不是很強，只要一秒200次請求，服務器響應時間就變得很長，這時再請求，就會導致前端誤以為服務器無響應，而只簡單的報告網絡異常。主要還是因為開發的時候測試規模比較小，沒有考慮過高並發的情況。
⑥代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
由兩位大佬親自審查，嚴格執行了代碼規范，從常規項和安全性兩個角度進行審查。
常規項：代碼能夠工作么？它有沒有實現預期的功能，邏輯是否正確等。所有的代碼是否簡單易懂？代碼符合你所遵循的編程規范么？這通常包括大括號的位置，變量名和函數名，行的長度，縮進，格式和注釋是否存在多余的或是重復的代碼？等等
安全性：所有的數據輸入是否都進行了檢查（檢測正確的類型，長度，格式和范圍）並且進行了編碼？在哪里使用了第三方工具，返回的錯誤是否被捕獲？
從這幾個方面開始入手。
⑦我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
會加強對功能的強化和細節方面的處理，希望能在beta沖刺有所進步
6.測試/發布（3分）
①團隊是否有一個測試計划？為什么沒有？是否進行了正式的驗收測試？
有一個測試計划，由前后端一起執行，進行了非正式的驗收測試。
②團隊是否有測試工具來幫助測試？
有，我們利用JUnit測試工具。
③團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
目前沒有做關於軟件性能的測量。下次一定。
④在發布的過程中發現了哪些意外問題？
發現通過我們的發送請求給教務處的時候，對安全性的封裝還不夠，不影響使用，但會影響軟件安全性，正在修改中
⑤我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
我們不會將接口暴露出來，也會做好封IP准備。
7.團隊的角色、管理、合作
① 團隊的每個角色是如何確定的，是不是人盡其才？
先根據每個人實際已掌握的技術特長安排相關的前端（后端）主要負責人，帶着一些沒有接觸過實際項目開發的同學一起進行學習開發，再保證不影響開發效率的情況下共同進步。還有一些同學負責文檔編寫，ppt制作等，雖分工不同但人盡其才。
② 團隊成員之間有互相幫助么？
團隊中的技術大佬帶着技術小白共同進步學習。
③ 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的博客里）
我感謝澤源對我的幫助，因為某個具體的事情：澤源真的很能頂，雖然出現了意外但是答辯還是很精彩
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
我們學到了如何合作與溝通，如果歷史重來一遍，我們會在答辯前做更充分的准備
8.總結
①你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
我們認為目前團隊還處於CMMI一級，執行級的檔次。因為大部分同學沒有太多開發經驗，很多開發上的問題還是第一次接觸，還是只能奔着實現項目需求出發。希望未來可以繼續努力，鍛煉出更強的軟件綜合開發能力，往更高一級水平邁進。
②你覺得團隊目前處於 萌芽/磨合/規范/創造 階段的哪一個階段?
處於規范階段，因為隊內有前端后端技術大佬，在項目等實際開發落地上少走了很多彎路，但是對一些開發規范例如接口文檔的編寫等方面還需要進一步加強。
③你覺得團隊在這個里程碑相比前一個里程碑有什么改進?
團隊分工配合更加明確，項目的初代版本功能已經基本實現。
④你覺得目前最需要改進的一個方面是什么?
改進關於用戶信息加密的部分，因為綁定用戶學號涉及到用戶的教務處密碼。
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
我覺得我們小組做的最好的原則是“避免不必要的開銷”。因為從產品設計階段開始，我們便致力於減少不必要的時間浪費。例如最初的產品設計，我們就從實際可行性出發，不去幻想一些天馬星空的需求，從是否能實現或規定時間內能否學會為基礎進行設計，避免花費大量的時間去畫餅但最后技術上卻無法實現而改文檔需求。
討論照片
二.答辯總結
①貢獻比例
②工作流程
③現場答辯得分
53.1分
④回答其他小組對本小組的提問
1.如果借出去的東西遭到破壞，應該怎么辦?（第二組）
如果遭到破壞之后，借出者向我們反映的話我們會聯系借用者讓他們私下解決，我們只起到一個平台的作用，對於具體的破壞程度與賠償事宜還是得當事人來解決，平台會對破壞者進行信用分數的扣除
2.個人信息是否能得到安全保障？（第三組）
能得到安全保障，對於使用者的用戶密碼我們只是在登陸的時候拿去與教務處對接匹配，並不會私自保存
3.對於用戶的信用評級有沒有一個比較客觀的方法來完成？（第四組）
每次借還的時候我們會讓借用者拍照留底，若借出者發現有損壞並且平台人員核實之后會酌情扣除借用者的分數
4.如何解決后台信息透明化（第五組）
我們不會將接口暴露出來，也會做好封IP准備。
5.上午演示的時候，感覺不是單純的網絡問題 ，做過壓力測試嗎？（第六組）
實情是福哥對我們服務器進行了攻擊；沒做過壓力測試
6.永福搞你們，你們有沒有把他錘爆？（第七組）
暫時沒有，但四十米大刀在快遞來的路上了
7.你們后端是怎么協調租借流程的？（第八組）
討論得出的啊，就幾個人商量一下出來的
8.想問一下你們的分工是怎么做的，感覺ppt中每次alpha進度有一定進度。（第九組）
分工就是按照個人能力來分配的，每次都有進度是因為我們把任務分的很細，細水長流
9.今天早上演示時候說是網絡問題，但我覺得會不會是程序的問題？或者說是服務器的問題？（第十組）
不是程序的問題，是服務器的問題，服務器被福哥攻擊了
10.並發的問題，你們的接口寫完沒測試性能的嗎?（第十一組）
目前還未做相關方面的測試，下一階段做
11.后端的最大並發多少？敏感信息是否加密傳輸?（第十二組）
最大並發還未做，敏感信息例如賬號密碼暫時還未加密傳輸，之后會補充優化
個人PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時 (小時) |
實際耗時 (小時) |
|---|---|---|---|
| Planning | 計划 | 0 | 0 |
| · Estimate | · 估計這個任務需要多少時間 | 1.5 | 2 |
| Development | 開發 | 0 | 0 |
| · Analysis | · 需求分析 (包括學習新技術) | 0.9 | 1.4 |
| · Design | · 生成設計文檔 | 0 | 0 |
| · Design Review | · 設計復審 | 0 | 0 |
| · Coding Standard | · 代碼規范 (為目前的開發制定或選擇合適的規范) | 0 | 0 |
| · Design | · 具體設計 | 0 | 0 |
| · Coding | · 具體編碼 | 0 | 0 |
| · Code Review | · 代碼復審 | 0 | 0 |
| · Test | · 測試(自我測試，修改代碼，提交修改) | 0 | 0 |
| Reporting | 報告 | 0 | 0 |
| · Test Report | · 測試報告 | 0 | 0 |
| · Size Measurement | · 計算工作量 | 0.1 | 0.1 |
| · Postmortem & Process Improvement Plan | · 事后總結, 並提出改進計划 | 0.5 | 0.5 |
| · 合計 | 1.5 | 2 |
個人學習進度條
| 第N周 | 新增代碼（行） | 累計代碼（行） | 本周學習耗時（小時） | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 12 | 12 | 基本了解了原型圖的設計理念與實現方法，掌握了墨刀的基礎用法 |
| 2 | 412 | 412 | 20 | 32 | 構思算法，實現基本框架 |
| 3 | 660 | 1072 | 36 | 68 | 算法改進 |
| 4 | 148 | 1220 | 15 | 83 | 了解接口的使用，學習了github使用規范 |
| 5 | 0 | 1220 | 15 | 98 | 明確了團隊項目選題 |
| 6 | 0 | 1220 | 15 | 113 | 明確了團隊項目需求 |
| 7 | 0 | 1220 | 3 | 118 | 幫忙找了需要的數據，之后要努力學習技術 |
| 8 | 0 | 1220 | 3 | 121 | 重新安排了alpha階段的分工，驗收團隊的成果 |
| 9 | 0 | 1220 | 3 | 121 | 驗收團隊alpha階段的成果，准備alpha答辯，完成alpha事后諸葛亮 |