第10組 Alpha事后諸葛亮

鏈接部分

隊名：女生都隊

組長博客： 博客鏈接

作業博客：博客鏈接

一、設想和目標

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自帶的打包工具。

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

• 歷經數十天的熬夜團隊很多從小白到可以負責前端或者后端的某一個模塊了，不同的隊員學到的知識不同，后端學習了如何搭建數據庫，如何通過接口和前端實現聯動，並且學習到了如何從雲端獲取實時數據，前端的隊員很多有過開發項目的基礎，但也學習了很多的邏輯調用方面的知識。如果歷史重來一遍的話我們會提早開始開發我們的項目，熬夜實在是痛苦啊。

七、團隊的角色，管理，合作

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

• 我們的團隊角色確定是根據個人能力進行安排的。前端組的三名女生在AS方面比較熟練，就承擔了組內前端部分的任務；后端部分由幾個學習能力比較強的男生承擔，相互之間合作順利；文檔、PPT、演講等部分由代碼能比較弱和在該方面有競賽經驗的同學完成。
• 總體來說我們的團隊分工明確，做到了人盡其才。

2、團隊成員之間有互相幫助么？

• 有。我們的團隊項目很大一部分都是在一起（熬夜）完成的，在項目的完成過程中出現的問題會直接詢問，現場解決；單獨完成時遇到的困難也會進行線上溝通（QQ的火花就是這么來的）

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

• 我們的消息團隊在凝聚力方面做的很好，除了技術方面的問題以外其實沒有什么項目管理方面的問題。各個小組的成員之間關系都很親近，在合作溝通方面進行的 很順利，不同的小組經歷了這一段時間的磨合也很熟絡，合作過程中也很順利。

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

• 我感謝潘海東同學對我我們的幫助， 因為給我們推薦了阿里雲服務器，幫助我們節省了時間。

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

• 通過這次的alpha沖刺，我們在團隊分工、管理、合作方面學到了：在分工的過程中要根據每個人的能力和興趣進行分工。作為一個團隊項目，合作的成功與否決定了項目是否能成功，只有每個人選擇好自己的團隊定位，把自己的的能力盡可能地發揮出來，才能讓整個團隊取得好的成績。
• 如果再選一次的話，我們的選擇依然會是這樣。

八、總結

1、你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?

• 初始級(initial)
  工作無序，項目進行過程中常放棄當初的計划。 這或許就是我們小組Alpha沖刺時候的狀態了，由於其他科目和ddl的壓力，我們小組選擇一切從簡，復雜的項目要么刪了，要么丟到Beta沖刺。 開發項目成效不穩定，項目成功主要依靠幾個有能力的人（簡稱“大腿”）的經驗和能力。希望beta沖刺的時候能達到 可重復級(Repeatable) 。

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

• 處於規范階段
  我想經過了團隊編程和這次Alpha沖刺，我們團隊已經磨合得挺好的，但是對於團隊每個人負責代碼的部分並沒有處理的很好，還是需要時間達到“規范”。

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

• 目前（alpha階段）相比於上一個里程碑（需求分析），整個團隊得溝通更多了，大家在技術方面也有了很大的提升，團隊的協作能力更好了。

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

• 技術方面是我們目前最需要改進的方面

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

1. 業務人員和開發人員在項目開發過程中應該每天共同工作。

2. 無論團隊內外，面對面的交流始終是最有效的溝通方式。

• 我們小組在Alpha 沖刺階段大部分人都是在一起編碼並進行討論的，這個比線上各自打代碼效率提高許多。

3. 簡明為本——它是極力簡化不必要的工作量的技藝。

• 小組在完成每個功能之前都會討論下這個功能是否是我們的主體，我們經常講當初需求報告里寫的不需要得功能給刪了。

團隊照片

答辯總結

評估團隊中每個人對本次作業的貢獻比例，描述為本次作業的工作流程、組員分工、組員工作量比例

工作流程

• 組長確定每個Alpha沖刺階段必須要完成的任務，並進行分工；
• 對分工安排進行公示，若組員提出有意義、有建設性的建議，則對相應部分進行修改；
• 組員執行分工安排，在規定時間內交付自己負責的部分；
• 組長或相關負責人進行匯總，並對格式進行訂正。

姓 名	任務工作量（60）	個人參與度（10）	完成及時性（10）	Leader評分（20）	得分（100）	貢獻比例(%)
恩澤	60	10	10	20	100	12.0
秋琴	60	10	10	20	100	12.0
雅芳	60	10	10	20	100	12.0
鈺蕙	60	10	10	20	100	12.0
銀山	40	9	10	15	74	8.8
季城	40	10	10	18	78	9.3
君曦	50	10	10	17	87	10.4
金海	50	10	10	17	87	10.4
雅輝	50	10	10	20	90	10.8
婉怡	10	0	2	5	17	2.0

求出本組的現場答辯得分：去除最高總分，最低總分，求平均分（保留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	計划	15	5
· Estimate	· 估計這個任務需要多少時間	15	5
Development	開發	1450	1750
· Analysis	· 需求分析 (包括學習新技術)	120	150
· Design Spec	· 生成設計文檔	10	10
· Design Review	· 設計復審	20	20
· Coding Standard	· 代碼規范 (為目前的開發制定合適的規范)	10	10
· Design	· 具體設計	70	50
· Coding	· 具體編碼	1200	1500
· Code Review	· 代碼復審	20	10
· Test	· 測試（自我測試，修改代碼，提交修改）	0	0
Reporting	報告	25	25
· Test Repor	· 測試報告	0	0
· Size Measurement	· 計算工作量	20	50
· Postmortem & Process Improvement Plan	· 事后總結, 並提出過程改進計划	5	10
	合計	1490	1780

學習進度條

第N周	新增代碼（行）	累計代碼（行）	本周學習耗時（小時）	累計學習耗時（小時）	重要成長
1	103	103	14	14	學會了十三水的玩法，對原型設計有了一定的基礎
2	400	503	10	24	學習C# winform開發，完善具體設計思路
3	1313	1816	30	54	實現核心算法“自動分牌”
4	1153	2969	22	76	界面設計與代碼實現，完成各窗體與接口的實現
5	0	2969	15	91	詳細了解商業計划書以及產品介紹視頻的制作
6	0	2969	20	111	學習了UML類圖的繪制，了解需求規格說明書的書寫
7	120	3089	5	116	學習了Android Studio，查資料能力增強，對算法有了一定的框架
8	1230	3319	35	151	對Android的API調用，服務器部署，使用spring boot框架+tomcat，后端API功能實現