連結部分
隊名：女生都隊
組長部落格： 部落格連結
作業部落格：部落格連結
一、設想和目标
1、我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
- 我們軟體解決的問題是：幫助使用者以科學的方式養成良好的生活習慣，在必要的時候發送給他們一些生活習慣類小提醒，幫助使用者提升生活幸福感。同時，能夠以寵物陪伴的方式來幫助使用者更好的完成自己定義的任務及系統的旅程任務。
- 已經定義的十厘清楚。（詳情可參見 需求分析報告PDF 提取碼: x24e ）
- 典型使用者為：廣大年輕一輩（12歲-32歲）人群 。（在需求分析報告PDF 提取碼: x24e 中已有描述）
- 典型場景：福大學生——小陳。（在需求分析報告PDF 提取碼: x24e 中已有描述）
2、我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)?
- 還未完全達到目标，原計劃功能已完成6個：登陸注冊、添加打卡任務、和“我”說話、顯示任務清單、旅程分類、天氣提醒推送。剩下的任務将在Beta版本完成。
- 在Alpha版本規定時間完成傳遞。并進行Alpha版本課堂展示。
- 原定計劃中未對使用者數量做出明确定義。使用者量還需要在Beta版本完成之後進行推廣擷取。
3、使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
- 暫時還未進行推廣，是以還沒有使用者量。離目标更近一步。
4、有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
- 應該提前對項目的整個開發流程以及可能會遇到的問題進行預測，未雨綢缪，并且提前制定好各階段詳細的人物及傳遞時間。如果重來一遍的話，我們會嚴格要求按照指定的傳遞時間進行項目的完成，并且根據每次完成的情況适當調整下一次的任務安排，并且會提前制定好後期使用者量的明确目标。
二、計劃
1、是否有充足的時間來做計劃?
- 計劃是有的，但是由于各種不可抗力的原因，最後的實施有所偏差
2、團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
- 溝通是最有力的方式，盡量找到一個大家都較為滿意的方案
3、你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
- 原來的計劃在連續肝了幾晚後基本都完成了；不過在前後端對接上還是有不少問題沒解決，因為在整合項目的時候已經沒什麼時間了。
4、有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
- 在功能設計上有點過于複雜，給自己挖了不少坑
- 在使用後端架構上走了太多彎路
5、是否每一項任務都有清楚定義和衡量的傳遞件?
- 沒有，由于整個項目的計劃沒有很順利的進行，是以所有的标準基本都是現場溝通，再進行調整
6、是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
- 整個過程并沒有完全按照計劃進行
- 在項目過程中，由于沒有經驗，踩了很多坑，在項目對接上也有很多問題
- 風險的話在于使用者的行為分析，因為實作這個的困難有點超出預計
7、在計劃中有沒有留下緩沖區，緩沖區有作用麼?
- 有：休息休息休息！！！
- 作用就是休息之後肝的更有勁了！
8、将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
- 計劃就是繼續肝！，平時就學好自己的負責的部分，在做項目的時候就大家一起肝
- 該休息就休息，該加班就加班，沒什麼是熬夜解決不了的！
9、 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
- 學到了很多東西，伺服器的部署、後端的搭建、界面的設計實作、資料庫搭建等等
- 如果重來一遍，首先一定不要再給自己挖那麼多坑了！，其次就是要加強的對任務的分析，提前學習好要用到的知識，預估好任務的困難程度，而不是到最後再修改
三、資源
1、我們有足夠的資源來完成各項任務麼?
- 有足夠的資源來完成各項任務。我們組有前端後端算法都接觸過的人，并且還有美工，人才濟濟，大家都相處的很好，配合都很甜。
2、各項任務所需的時間和其他資源是如何估計的，精度如何?
- 各項任務所需時間是按照從前開發的經驗來看的，并且随着項目開發的過程的進度來進行不斷地修改，精度不太準确，有一些之前沒有遇到的bug出現，導緻耗費了許多的時間，是以個别地方在alpha階段沒有及時的完成。
3、測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
- 測試的時間，人力和軟體/硬體資源不足夠。
- 由于後端出現了一些問題，是以在前後端互動的時候出了一些的問題，導緻閃退等問題，測試出現了許多的問題。
- 并未低估難度。我們組有一個專門做美工的和專門做文案的人員，她們都能在規定時間内完成任務，并且是又快又好！（簡直是太贊了！團隊的效率和審美水準都被她們拉高了！）
4、你有沒有感到你做的事情可以讓别人來做（更有效率）?
- 我覺得我做的事情讓會Android Studio的同學來做的話，完全是可以的！甚至有可能做的比我好（特别是審美和細節方面）”
5、有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
- 我們應該在配置設定任務的時候，盡量把每個人都配置設定任務，并且讓每個任務都盡量詳細，不會出現那種有的人不了解任務，在原地徘徊的情況，導緻木桶理論，項目的總體進度被降低。并且我們應該清楚任務的難度，給任務配置設定相應的事件，讓時間和資源達到最大化！
四、變更管理
1、每個相關的員工都及時知道了變更的消息?
- 是的，每當有變更我們會在群裡艾特全體成員并告知變更細節。
2、我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
- app的主線功能即必須實作的功能，而較為細節的功能及擴充功能則可以推遲。
3、項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
- 有，項目基本功能完整，邏輯完整，測試無bug。
4、對于可能的變更是否能制定應急計劃?
- 大部分能，大部分變更還是在可控範圍内的。
5、員工是否能夠有效地處理意料之外的工作請求？
- 大部分情況下能，小部分情況前後端協調互助一下，最終也能處理好。
6、我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
- 學到了前後端的協調以及團隊協作。如果曆史重來一遍，我們在項目最開始就定好架構，前後端同時進行。
五、設計/實作
1、設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人嗎？
- 原型設計的初稿是團隊共同讨論，并由雅輝和秋琴繪制的。由于團隊讨論定稿較為粗糙，之後雅芳和钰蕙對原型設計進行了修改和細化。這些工作是在進行需求分析報告的時候完成的（上一次團隊作業）。在項目的開發過程中又對原型進行了調整。參與原型設計的基本是前端實作的人員，是以原型設計會根據前端人員的想法和實作情況進行更新疊代。故時間和人員都是比較合适的。
- 資料庫和接口的主要設計由恩澤完成，并配置設定給君曦、金海進行細化。三位同學均是後端實作的同學，在開始後端工作前即完成了設計并于前端同學确定了接口的設計，時間和人員都是合适的。
2、設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
- 有碰到模棱兩可的情況，在前端組中頁面跳轉的邏輯成員之間存在分歧，而後端組中對資料庫設計情況也存在一些争議。
- 前端組讨論以後，決定頁面調整以簡潔、清晰為主，确定了最終版本。後端組的成員也通過交流和讨論确定了資料庫的設計，并進行了明确的分工。
3、團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML，或者其他工具來幫助設計和實作？這些工具有效嗎？
- 單元測試是在Android Studio中完成的，Android Studio的測試環境對于安卓開發友好而友善。
4、比較項目開始的UML文檔和現在的狀态有什麼差別？這些差別是如何産生的？是否要更新UML文檔？
- 差別還是比較大的。因為在項目開發過程中發現最初的文檔存在一些細節模糊不清的情況，故需要進行更新，以更好的輔助開發。
5、什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的Bug？為什麼我們在設計/開發的時候沒有想到這些情況？
- 在開發過程中，許多功能都産生了Bug，産生功能最多的bug應該是消息推送的實作，因為團隊大部分人是為了這門課程才入門相關語言和系統環境。釋出之後，發現在前端中活動之間的資訊傳遞和前後端的資訊傳遞還存在Bug，資訊存儲存在問題，這是由于團隊成員對于開發過程不熟悉，對于前後端互動概念較為模糊。
6、代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
- 由于時間原因我們還沒有進行代碼複審。但在開發前前端組和後端組的同學對于代碼規範進行了讨論和規定，對于檔案（或變量）的命名、代碼的注釋、空格和縮進等内容進行了規範，團隊執行代碼規範情況尚可。
7、我們學到了什麼？如果曆史重來一遍，我們會做什麼改進？
- 我們學到了許多東西，團隊成員對于項目開發的流程有了更深的了解和切實的感悟，對于一個項目開發所需的人員、工具和分工情況都有了自己的認識。如果曆史重來一遍，我們會花更多時間在設計階段對于細節進行更深入的讨論，以避免模糊不清的情況影響項目開發進度。
六、測試/釋出
1、團隊是否有一個測試計劃？為什麼沒有？
- 團隊是有測試計劃的，在項目的開發過程中每完成一個子產品都是有進行測試的，是一直都有在測試的。但是由于app沒有太過完善，測試也隻是一些很簡單的查bug，是以沒有放出來，計劃後期在12月初app完善了進行黑盒測試。
2、是否進行了正式的驗收測試？
- 還沒有進行正式的驗收測試，前端和後端在一些部分還沒有完全的合并，預計在12月初開始進行測試。
3、團隊是否有測試工具來幫助測試？
- 測試工具，負責測試的同學預計用GT和itest、Jmeter測試app 的性能，Android studio有可以優化的工具。
4、團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
- GT和itest這些測試工具可以測試app的效能，GT是app 的随身調試平台，可以在手機上随時檢視調試。測試工作的作用，因為我們的app有常駐背景，耗電量和效能已經常駐期是必須要考慮在内并且進行一定的優化的。改進優化的地方目前想到的是減低能耗。
5、在釋出的過程中發現了哪些意外問題？
- 目前app還沒有到釋出階段，app的打包預期不會很大的問題，用Android studio自帶的打包工具。
- 曆經數十天的熬夜團隊很多從小白到可以負責前端或者後端的某一個子產品了，不同的隊員學到的知識不同，後端學習了如何搭建資料庫，如何通過接口和前端實作關聯，并且學習到了如何從雲端擷取實時資料，前端的隊員很多有過開發項目的基礎，但也學習了很多的邏輯調用方面的知識。如果曆史重來一遍的話我們會提早開始開發我們的項目，熬夜實在是痛苦啊。
七、團隊的角色，管理，合作
1、團隊的每個角色是如何确定的，是不是人盡其才？
- 我們的團隊角色确定是根據個人能力進行安排的。前端組的三名女生在AS方面比較熟練，就承擔了組内前端部分的任務；後端部分由幾個學習能力比較強的男生承擔，互相之間合作順利；文檔、PPT、演講等部分由代碼能比較弱和在該方面有競賽經驗的同學完成。
- 總體來說我們的團隊分工明确，做到了人盡其才。
2、團隊成員之間有互相幫助麼？
- 有。我們的團隊項目很大一部分都是在一起（熬夜）完成的，在項目的完成過程中出現的問題會直接詢問，現場解決；單獨完成時遇到的困難也會進行線上溝通（QQ的火花就是這麼來的）
3、當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
- 我們的消息團隊在凝聚力方面做的很好，除了技術方面的問題以外其實沒有什麼項目管理方面的問題。各個小組的成員之間關系都很親近，在合作溝通方面進行的 很順利，不同的小組經曆了這一段時間的磨合也很熟絡，合作過程中也很順利。
4、每個成員明确公開地表示對成員幫助的感謝 （并且寫在各自的部落格裡）：
- 我感謝潘海東同學對我我們的幫助， 因為給我們推薦了阿裡雲伺服器，幫助我們節省了時間。
5、我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
- 通過這次的alpha沖刺，我們在團隊分工、管理、合作方面學到了：在分工的過程中要根據每個人的能力和興趣進行分工。作為一個團隊項目，合作的成功與否決定了項目是否能成功，隻有每個人選擇好自己的團隊定位，把自己的的能力盡可能地發揮出來，才能讓整個團隊取得好的成績。
- 如果再選一次的話，我們的選擇依然會是這樣。
八、總結
1、你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
-
初始級(initial)
工作無序，項目進行過程中常放棄當初的計劃。 這或許就是我們小組Alpha沖刺時候的狀态了，由于其他科目和ddl的壓力，我們小組選擇一切從簡，複雜的項目要麼删了，要麼丢到Beta沖刺。 開發項目成效不穩定，項目成功主要依靠幾個有能力的人（簡稱“大腿”）的經驗和能力。希望beta沖刺的時候能達到 可重複級(Repeatable) 。
2、你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
-
處于規範階段
我想經過了團隊程式設計和這次Alpha沖刺，我們團隊已經磨合得挺好的，但是對于團隊每個人負責代碼的部分并沒有處理的很好，還是需要時間達到“規範”。
3、你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
- 目前（alpha階段）相比于上一個裡程碑（需求分析），整個團隊得溝通更多了，大家在技術方面也有了很大的提升，團隊的協作能力更好了。
4、你覺得目前最需要改進的一個方面是什麼?
- 技術方面是我們目前最需要改進的方面
5、對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
- 業務人員和開發人員在項目開發過程中應該每天共同工作。
- 無論團隊内外，面對面的交流始終是最有效的溝通方式。
- 我們小組在Alpha 沖刺階段大部分人都是在一起編碼并進行讨論的，這個比線上各自打代碼效率提高許多。
- 簡明為本——它是極力簡化不必要的工作量的技藝。
- 小組在完成每個功能之前都會讨論下這個功能是否是我們的主體，我們經常講當初需求報告裡寫的不需要得功能給删了。
團隊照片
答辯總結
評估團隊中每個人對本次作業的貢獻比例，描述為本次作業的工作流程、組員分工、組員工作量比例
工作流程
- 組長确定每個Alpha沖刺階段必須要完成的任務，并進行分工；
- 對分工安排進行公示，若組員提出有意義、有建設性的建議，則對相應部分進行修改；
- 組員執行分工安排，在規定時間内傳遞自己負責的部分；
- 組長或相關負責人進行彙總，并對格式進行訂正。
| 姓 名 | 任務工作量（60） | 個人參與度（10） | 完成及時性（10） | Leader評分（20） | 得分（100） | 貢獻比例(%) |
|---|---|---|---|---|---|---|
| 恩澤 | 60 | 10 | 20 | 100 | 12.0 | |
| 秋琴 | ||||||
| 雅芳 | ||||||
| 钰蕙 | ||||||
| 銀山 | 40 | 9 | 15 | 74 | 8.8 | |
| 季城 | 18 | 78 | 9.3 | |||
| 君曦 | 50 | 17 | 87 | 10.4 | ||
| 金海 | ||||||
| 雅輝 | 90 | 10.8 | ||||
| 婉怡 | 2 | 5 |
求出本組的現場答辯得分：去除最高總分，最低總分，求平均分（保留1位小數）
去除最高總分，最低總分，求平均分得：52.6
收集其他組對本組提出的問題，并回答
團隊提問回答環節
第一組的提問：
問：後端的主要算法可以介紹下嗎？
答：後端伺服器主要通過阿裡雲搭建的，伺服器推送是通過app內建極光推送實作，具體的資料分析算法目前還未完善。
第二組的提問：
問：對于自律的人其實用處不大，不自律的更沒有用，使用者會不會沒有保證？
答：我們設計app的目的主要是起到一個輔助作用，願意提升自己的人通過我們的app可以得到良性回饋，再加上寵物互動，我相信是會有許多人喜歡嘗試的。至于用處不可能說是用了之後就能改變一個人的，這是一個循序漸進的過程。
第三組的提問：
問：主打寵物界面如何美觀且完善？
答：這個當然是通過壓榨美工實作了（xd）。
第四組的提問：
問：你們是打算用什麼來吸引使用者？
答：app主打的自律牌相信本身就能吸引到一部分想改變自己的人，再加上可愛的界面和寵物也能吸引一些小姐姐。
第五組的提問：
問：希望可以設計寵物各個階段的不同動畫形态。
答：這個我們目前已經實作了，當然後續還會添加其它寵物的（再次壓榨美工xd）。
第六組的提問：
問：寵物是動态還是靜态的，如果是動态，是用gif還是3d引擎？
答：是動态的噢，目前是用gif實作，3d引擎的話目前能力有限以後會考慮的。
第七組的提問：
問：如果要常駐背景，耗電量能不能小一點？
答：首先我們是極不希望常駐背景的，目前還是在尋找方法來解決背景推送面臨的問題。如果迫不得已要強制常駐背景的話，當然會盡可能減少耗電。
第八組提問：
問：對于一事手機自帶的月曆有日程提醒，你們這個項目的優勢在哪呢？
答：優勢在于人性化的提醒，不僅僅是自己設定日程，更帶有暖心的日常提醒，也具有更大的靈活性。
第九組問題：
問：對于需要這個軟體的使用者來說寵物界面是否會太花裡胡哨？
答：寵物作為主界面，我們設計的風格偏向簡約的暖色調，不會設計的太花哨。後面也會繼續完善。
第十一組問題：
問：寵物怎麼動起來，不能是放gif吧？
答：目前使用gif，如果時間和能力允許，會改進。
第十二組問題：
問：你們打算如何實作寵物界面？是否使用圖形學技術？
答：寵物現在已經使用gif實作，目前沒有考慮使用圖形學技術。
PSP與學習進度條
PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | ||
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | 1450 | 1750 |
| · Analysis | · 需求分析 (包括學習新技術) | 120 | 150 |
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 70 | |
| · Coding | · 具體編碼 | 1200 | 1500 |
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | 25 | |
| · Test Repor | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| 合計 | 1490 | 1780 |
學習進度條
| 第N周 | 新增代碼（行） | 累計代碼（行） | 本周學習耗時（小時） | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 1 | 103 | 14 | 學會了十三水的玩法，對原型設計有了一定的基礎 | ||
| 400 | 503 | 24 | 學習C# winform開發，完善具體設計思路 | ||
| 3 | 1313 | 1816 | 30 | 54 | 實作核心算法“自動分牌” |
| 4 | 1153 | 2969 | 22 | 76 | 界面設計與代碼實作，完成各窗體與接口的實作 |
| 91 | 詳細了解商業計劃書以及産品介紹視訊的制作 | ||||
| 6 | 111 | 學習了UML類圖的繪制，了解需求規格說明書的書寫 | |||
| 7 | 3089 | 116 | 學習了Android Studio，查資料能力增強，對算法有了一定的架構 | ||
| 8 | 1230 | 3319 | 35 | 151 | 對Android的API調用，伺服器部署，使用spring boot架構+tomcat，後端API功能實作 |
作者：阿澤Libertas
出處：https://www.cnblogs.com/azeLibertas/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。