第09組 Alpha事后諸葛亮

組長博客鏈接###

組長博客

參考鄒欣老師的問題模板進行總結思考###

設想和目標（2分）####

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

• 解決的問題
  我們軟件初期旨在解決福大用戶等車難，租車難的問題，用戶可以通過Pickme平台選擇順風車，快車出行，還可以租用社會閑置車輛。在校園市場運營成熟后，我們會拓展城鎮市場，為社會用戶提供Pickme的出行方案。
• 定義是否清楚
  經過我們前期的需求分析、問卷調查、組內決策等一系列審核后最終定義下的軟件，我們認為這也是兼具完備定義以及強健性的一款軟件。在我們看來，定義得十分清楚，歡迎有疑問的小伙伴提出你們的寶貴意見。
• 典型用戶
  • 校園中面向未購置電動車、自行車的用戶。
  • 城鎮中依賴公共交通、摩托出行的用戶。
• 典型場景
  • 場景一：校園上學高峰期，學生等不到小白，找不到共享單車，而還有很多電動車用戶后座閑置。
  • 場景二：小王想去城鎮中心趕集，但是位置相對偏僻，等公交車要很久，又沒有摩的司機經過。
    以上可以通過我們的平台快速打車，便捷出行。（圖片）

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

• 原計划功能實現情況
  • 部分實現，順風車，快車實現，短租車未完成。
  • 前端實現界面精美，操作簡單。
  • 后端搭建數據庫，服務器，不足之處是響應速度不夠快。
• 是否按原計划交付時間交付
  • 是，我們在答辯前天完成相應工作。
• 原計划預期的用戶數量是否達到
  • 原計划沒有預期能夠有用戶使用，只是在我們團隊內部進行測試。

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

• 用戶量與預期一致。
• 當最終產品出來的時候，我們團隊隊員還是對我們實現的功能十分滿意。
• 我們距離我們的既定目標已經無限接近。

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

• 技術方面
  • 一開始前后端的接口定義不夠規范，導致整合困難
  • 最初前端沒有使用uni-app項目開發，前端代碼都是html文件，導致沒辦法使用uni打包到其他平台上，做出了的都是網頁。
• 非技術方面
  • 時間安排還是不夠合理，我們在alpha沖刺開始之前已經完成接近50%的工作量，但是在alpha沖刺階段，大多數組員都有各種各樣的考試，整個項目進展緩慢，都是集中在答辯前兩天完成的。
  • 任務分配相對合理，能夠按照每個人的能力大小來分配。
  • 貢獻比例分配不夠科學，人為主觀因素明顯。

計划（5分）####

1、是否有充足的時間來做計划?

• 前期我們已經分配好任務，時間上是充裕的，但是最后因為各種原因有所延誤，總體上進展順利。

2、團隊在計划階段是如何解決同事們對於計划的不同意見的？

• 我們組任務分配相對合理，幾乎沒有不同意見，有的小分歧都能通過協商解決。

3、你原計划的工作是否最后都做完了? 如果有沒做完的，為什么?

• 短租車模塊尚未完成。團隊沒有相關經驗，進展緩慢，而且沖刺階段又遇上各種考試。

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

• 前端一開始的開發直接用h5,沒有按照HBuilder的規范，走了彎路。

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

• 每項任務都有清楚的定義，暫無科學的衡量標准，主觀因素占多。

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

• 沒有全都按照計划進行，項目一度出現瓶頸，搭建服務器，網絡請求，地圖嵌入，我們都沒有相關經驗，放緩了項目進度。

7、在計划中有沒有留下緩沖區，緩沖區有作用么?

• 沒有，因為當時給每個任務都預估出充足的時間。

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

• 定期集中敲代碼。

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

• 學到h5,vue，flask,js，SQL server,網絡請求，如果歷史重來，我們會重新分配好每個人應有任務，做好項目監督，保證按期及時完成。

資源（3分）

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

• 沒有，我們的組員都沒有項目開發的經驗，是在邊學邊做中完成的。

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

• 各項任務所需的時間和其他資源是基於過往經驗以及咨詢前輩，精度一般。

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

• 人力足夠，軟件/硬件資源不足，測試方法比較粗糙，基本靠純手工。沒有低估那些不需要編程的資源 (美工設計/文案)，分配了比較有經驗的人完成。

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

• 沒有，每個人都能發揮自己的特長，把自己做的方面做到極致（至少是我們組的最高水平），所以說每個人都是不可替代的。

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

• 前端任務繁重，預估不足，應加派人手。

變更管理（4分）

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

• 都能及時知道消息，我們有自己的交流群，能及時溝通，實在不行就會電話通知。

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

• 根據實際情況決定。

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

• 能夠流暢運行，不出現明顯bug，以后再逐步完善。

4、對於可能的變更是否能制定應急計划?

• 能，后端及時去支援前端。

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

• 時間寬裕的情況下，能很好解決。

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

• 做好應急預案。

設計/實現（4分）

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

• 設計在分工結束后就由各小組組長完成，目前看來時間是合適的，人選是合適的。

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

• 字體選擇的時候出現分歧，通過投票解決。

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

• 大部分測試是在HBuilder上測試，工具功能很強大。

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

• 主體部分與項目開始的UML文檔一脈相承，一些小邊幅的修改需要更新UML文檔。

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

• 網絡請求Bug最多，數據請求和數據處理給我們帶來很大的麻煩。發布后未發現重要bug。這些問題都是未知的，對於我們這些缺乏開發經驗是無法預見的。

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

• 時間緊任務重，未能進行代碼復審，也未能嚴格執行代碼規范。

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

• 在代碼拼接中，需要浪費較多時間去理解其他人的代碼。制定相應的代碼規范。

測試/發布（3分）####

1、團隊是否有一個測試計划？為什么沒有？

• 有一個簡單的計划，對各個模塊功能進行測試。

2、是否進行了正式的驗收測試？

• 由於經驗不足，未能進行驗收測試。

3、團隊是否有測試工具來幫助測試？

• HBuilder內置的模擬器來測試。

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

• 團隊目前不具備這方面的能力。

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

• 暫無意外。

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

• 制定詳細的測試計划，盡量做到事無巨細。

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

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

• 由組長分配，真正做到了人盡其才。

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

• 這個是必須的，每個人都有自己的盲區的，我們通過互幫互助解決不少困難。

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

• 不論什么類型的問題，我們團隊的解決方法第一步都是團隊討論，然后進行集思廣益解決問題。

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

• 我感謝培榮大佬對我的幫助，每當團隊項目陷入困境的時候，培榮大佬總能有辦法解決我們技術難題，使得項目能順利繼續下去。

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

• 我們在團隊合作方面，能夠及時溝通解決，沒有出現大的問題，在這一方面我們是比較優秀的。

總結:（3分）

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

• 初始級。並非是通過健全的制度驅動項目推進，主要靠項目負責人跟進和分配任務。在開發的主要力量中，主要依靠項目負責人的經驗和能力，他一但離去，工作秩序面目全非。

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

• 磨合之上，規范之下，在距離規范化開發還是有一定的距離，我們正努力向規范化前進。

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

• 在團隊的分工以及協作能力上大大提升。

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

• 規定代碼書寫規范。

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

• 遵循協作規則，在項目中取得更好的成功：團隊成員通過討論協作解決問題。
• 穩步工作，不應該有生產爆發：我們組提前做好任務安排和開發計划，給每個模塊留出充足的時間。
• 以簡潔為本，它是極力減少不必要工作量的藝術。：堅持簡潔開發的原則，砍掉一些雞肋的功能，輕文檔，輕流程，重產出，重目標。

全組討論的照片####

答辯總結###

團隊貢獻度

成員	貢獻比例（%）	分工
王耀鑫	3	小組規划、博客撰寫
陳超穎	3	ppt、答辯、博客撰寫
陳湘怡	20	前端
許培榮	28	后端、整合
滕佳	7	前端
何佳琳	7	前端
沈梓耀	3	需求報告，ppt
陳志榮	7	前端、ppt
林銀河	11	后端、數據庫
林明鎮	7	后端
黃恆傑	4	后端

本組的現場答辯得分:52.6

其他組提出的問題

電動車違規駕駛責任歸誰
對於這個問題，在前面的幾次答辯中已經說過很多次。首先目前我們不會在明令禁止不能載人的地方去適用我們的軟件；其次，我們初步只針對福大的校園市場，目前校園電動車載人的現象非常非常普遍；最后，如果實在擔心這個問題，可以選擇我們軟件的短租車模塊，可以自己單獨使用，不用載人。

電動車是不能帶人的，被交警抓了怎么辦，罰款誰出
對於這個問題，在前面的幾次答辯中已經說過很多次。首先目前我們不會在明令禁止不能載人的地方去適用我們的軟件；其次，我們初步只針對福大的校園市場，目前校園電動車載人的現象非常非常普遍；最后，如果實在擔心這個問題，可以選擇我們軟件的短租車模塊，可以自己單獨使用，不用載人。

界面可以在beta階段繼續完善，主打高級整潔
好的，非常感謝建議。

怎么保證電動車是否合規？
我們的司機認證模塊，要求填寫駕駛證的有效期，合規的電動車才會有駕駛證，我們后期如果時間允許，考慮增加上傳駕駛證並進行核實的功能。

要怎么解決加載慢的問題?
我們將考慮優化算法。

你們如何與QQ任務群這樣人數眾多的平台抗衡
不斷完善我們軟件的自身功能，減少bug，以實力贏取顧客的選擇和喜愛。

界面能不能好看一點，左邊固定有點難看
首先每個人的審美不一樣，我們目前確實會比較簡陋，后期會綜合考慮進行界面的美化。

單純的限制身份證號的位數還是很難保證信息的真實有效，這個你們如何解決呢？
這次是因為時間緊，所以只能單純限制身份證號的位數，后面將對此功能進行改進，提高安全性。

我自己血的教訓必須說一下，用web框架做app的性能真的實在是太憨了，如果實在想用一種語法統一多端，更建議用小程序或者flutter
好的，謝謝建議。

界面那里地圖加載比較慢，是否考慮把速度提高。
會的。

你們的應用似乎使用網頁技術進行開發，請問采用什么解決方案打包成應用，與原生系統的互操作性如何？
采用web-vue組件，嵌入html,做成uni-app部分，然后打包成app，原生操作性還可以。

PSP與學習進度條
PSP

• 個人PSP

PSP2.1	Personal Software Process Stages	預估耗時（分鍾)	實際耗時（分鍾)
Planning	計划	30	30
·Estimate	·估計這個任務需要多少時間	620	1100
Development	開發	130	110
·Analysis	·需求分析 (包括學習新技術)	50	190
·Design Spec	·生成設計文檔	30	60
·Design Review	·設計復審	30	20
·Coding Standard	· 代碼規范 (為目前的開發制定合適的規范)	10	10
·Coding	·具體編碼	220	270
·Code Review	·代碼復審	30	30
·Test	·測試（自我測試，修改代碼，提交修改）	--	--
Reporting	報告	10	30
·Test Repor	·測試報告	--	--
·Size Measurement	· 計算工作量	10	10
·Postmortem & Process Improvement Plan	·事后總結, 並提出過程改進計划	30	30
	合計	580	800

學習進度條

第N周	新增代碼（行）	累計代碼（行）	本周學習耗時（小時）	累計學習耗時（小時）	重要成長
1	300	300	10	10	學會了java和墨刀的使用
2	50	350	10	15	學習python的使用
3	200	550	12	27	學習QT5
4	150	700	8	35	學習QT5
5	0	700	1	36	答辯battle
6	200	900	3	39	js
7	300	1200	5	44	數據庫使用及與服務器連接，網絡請求
8	100	1300	2	2	vue開發，博客撰寫