第十一次做業 - Alpha 過後諸葛亮

拖鞋旅遊隊團隊過後諸葛亮會議

前言

• 隊名：拖鞋旅遊隊
• 組長博客：http://www.javashuo.com/article/p-covktpqa-u.html
• 時間：2018-12-1 20:00
• 地點：生活三區31#3樓活動室
• 參會人員： 拖鞋旅遊隊全體成員
• 與會圖片：
  

項目Postmortem

設想與目標

• 1.咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？
  咱們軟件要解決的是喜歡記錄分享旅遊生活的人羣的旅遊記錄分享功能。相關定義、典型用戶以及典型場景已經經過UML圖和需求分析報告清晰地描述。
• 2.咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)?
  在alpha衝刺階段，按時達到了原計劃的要求。目前仍處於內測階段，只在小範圍內挑選特定用戶交流使用，還沒有大面積投放給用戶使用。在beta衝刺階段開始時會陸續提交試用版本，讓用戶進一步參與軟件設計。
• 3.用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?
  在alpha版本下，用戶的滿意程度符合咱們的預期，能夠自信地說，咱們離目標更近了。
• 4.有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?
  原型設計很是重要，經常起到先導做用。咱們在作alpha版本以前沒有重視原型設計，後來在實現時出現漏洞，不得不返工重構，浪費了時間。若是歷史重來一遍，在設想階段，應儘量的完善原型設計，減小重構次數。

計劃

• 1.是否有充足的時間來作計劃？
  從肯定團隊開發項目到具體實踐，作計劃的時間很少。但隨着項目的推動，咱們也在不斷的完善細化計劃。
• 2.團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？
  咱們經過集中討論的方式，在小組討論會上收集不一樣意見，由PM和技術組長進行整合，再提出統一的解決方案。
• 3.你原計劃的工做是否最後都作完了？若是沒有完成，爲何？
  alpha衝刺階段原計劃工做都完成了。沒有完成的部分是由於在計劃以外的拓展功能實現較困難，須要花費較多時間。
• 4.有沒有發現你作了一些過後看來不必或沒多大價值的事?
  由於在Alpha版本分工前，對整個項目的架構和功能界面都已經定義比較清楚，因此在這方面卻是比較少。可是，因爲以前沒對團隊條件的充分理解，也能夠說是疏忽吧，作不了原本計劃好的事而不得不先丟棄。在以前咱們一直暢想着加入榜單功能以及基於地理位置的比較有意思的功能，而在後來發如今此方面微信定義了門檻，須要《電信業務增值許可證》，而這也須要公司主體纔可以辦理，所以咱們只能暫時廢棄以前對這方面作的工做。
• 5.是否每一項任務都有清楚定義和衡量的交付件?
  有些有，有些沒有。對於核心功能，每一個任務都有清楚的定義和衡量的交付件，可是對於小功能，由於比較簡單，在alpha階段尚未十分清晰的定義。
• 6.是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?
  到目前爲止，項目的整個過程都按照計劃進行。項目中隊友GitHub的使用狀況不容樂觀，在簽入代碼時花費了較多時間。
• 7.在計劃中有沒有留下緩衝區，緩衝區有做用麼?
  有，有留下一天的緩衝區用來修改和debug。
• 8.未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）
  在目前核心功能都已經基本完成的狀況下，未來的計劃會更多的傾向功能完善和拓展，會擴充緩衝區時間，留出較多時間用來收集用戶建議和測試。
• 9.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
  完善計劃和定製計劃一樣重要。原計劃的實施狀況已經符合咱們的預期，可是在過程當中總會有一些意想不到的突發狀況，所以及時的微調計劃對於整個項目的實行起到了很重要的做用。若是能重來一次，我但願在制定計劃時可以留下更多的緩衝時間。

資源

• 1.咱們有足夠的資源來完成各項任務麼?
  目前的資源足夠咱們完成各項任務。
• 2.各項任務所需的時間和其餘資源是如何估計的，精度如何?
  各項任務所須要的時間和其餘資源是有PM人爲估計的，對時間的估計精度偏差在小時之內。資源估計精度偏差較大。
• 3.測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?
  測試，人力和軟件/硬件資源足夠，但對於美工設計和文案設計這些主觀難以定性衡量的資源難度較大，要設計出符合預期甚至超出預期的產品須要反覆迭代。
• 4.你有沒有感到你作的事情可讓別人來作（更有效率）?
  沒有，團隊分工明確，各司其職，對待本身負責的模塊工做效率已經足夠高。
• 5.有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?
  初期分配學習時間不是很合理。在時間分配上，若是可以重來一次，在初期分配學習任務的時間會縮短，提早進入實戰環節。

變動管理

• 1.每一個相關的員工都及時知道了變動的消息?
  是的，對於變動會及時通知相關成員。
• 2.咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?
  根據功能在整個項目的重要程度。核心功能在alpha版本實現，剩下的完善部分放到beta版本。
• **3.項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?
  全部頁面整合在一塊兒，經過了各項測試，就「作好了」。
• 4.對於可能的變動是否能制定應急計劃?
  能。團隊支持變動，對於變動能及時定製相應計劃。
• 5.員工是否可以有效地處理意料以外的工做請求？
  部分員工經驗不足，不能獨自有效的處理，可是在PM和技術組長的帶領下可以有效的應對變動。
• 6.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
  GitHub的使用能大大提升工做效率，若是可以重來一遍，在項目開始前應該進行相應的GitHub使用培訓，減小用QQ傳代碼的頻率。

設計/實現

• 1.設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？
  設計工做在alpha衝刺的前三天，由經驗豐富的PM完成。設計時間合適，人選合適。
  
• 2.設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？
  在PM設計過程有遇到模棱兩可的狀況，團隊開會討論解決。
• 3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？
  有，團隊使用Visual Studio 2017自帶的性能測試工具進行測試。這些工具能夠很好的幫助咱們測試，進行代碼規範和debug。
• 4.比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？
  最開始的UML文檔給出了一個大致的框架，在根據這些框架逐一實現時會作出必定修改甚至重構，這些區別產生的緣由是需求的變動以及計劃變動。爲了項目完整性，咱們有及時更新UML文檔。
• 5.什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?
  照片地理位置解析和登陸。在照片信息解析方面，須要對經緯度的格式轉換，以及一系列的流程，在這裏咱們共用了五個接口，目前也沒有特別好的解決這個問題，在分析後發現是計算過程精度的丟失，有所改進。登陸方面，因爲安卓手機的數據沒有辦法很好地清除，致使用戶不知足條件，確可以使用功能（固然沒法返回結果）。目前尚未發佈，都是團隊內部人員在測試，以上就是主要的bug。問題主要在於設計/開發前沒有很好地理清邏輯，也有點忽視了這方面。
• 6.代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
  代碼複審沒有很詳盡，在程序可運行可讀的狀況下進行代碼複審，沒有嚴格的執行代碼規範。
• 7.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
  設計很豐滿，實現很骨感，在實現的過程當中總會出現知識和非知識層次的困擾。若是歷史再來一遍，但願在alpha衝刺開始前團隊先集中訓練。

測試/發佈

• 1.團隊是否有一個測試計劃？爲何沒有？
  有。團隊根據功能圖表有詳細的測試計劃。
• 2.是否進行了正式的驗收測試？
  尚未，目前功能尚未所有實裝，所以尚未進行正式驗收測試。
• 3.團隊是否有測試工具來幫助測試？
  有，團隊使用Visual Studio 2017自帶的性能測試工具進行測試。
• 4.團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？
  目前尚未考慮測量軟件的效能，會在beta版本中考慮。
• 5.在發佈的過程當中發現了哪些意外問題？
  前端的測試並不理想。GitHub操做不注意致使用戶信息泄露。
• 6.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
  輔助工具的使用不熟練，若是能重來加強GitHub的使用，熟悉VS201七、LoadRunner等負載測試工具的使用.

團隊的角色，管理，合做

• 1.團隊的每一個角色是如何肯定的，是否是人盡其才？
  團隊角色由隊員本身申報，再由PM根據狀況調整。每一個隊友獲得符合其意願的職務，工做效率合格，算是人盡其才吧。
• 2.團隊成員之間有互相幫助麼？
  有的，團隊合做總會出現問題，無論是技術上的仍是非技術上的，團隊分爲幾個小組，每一個小組在執行任務時遇到問題相互討論，互相幫助解決。
• 3.當出現項目管理、合做方面的問題時，團隊成員如何解決問題？
  團隊合做融洽，不多出現合做問題，當出現問題時，聽PM安排。沒有什麼是合做解決不了的問題，若是有，那就一瓶奶茶搞定。
• 每一個成員明確公開地表示對成員幫助的感謝
  我感謝組長蘇路明對個人幫助， 由於某個具體的事情: 全部的事情，都是他在管理，人員分工，博客撰寫，項目進度的管理，很是的辛苦，十分感謝有一位這樣盡職盡責的隊長。

總結

• 1.你以爲團隊目前的狀態屬於CMM/CMMI中的哪一個檔次？
  咱們團隊對團隊協做開發經驗比較欠缺，目前還處於磨合階段吧。因此咱們前端後端基本上都處於初始級別，部分達到可重複級，目前也在積極向第一組學習，爭取以後能達到可重複級以上。
• 2.你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?
  我以爲團隊目前還處於磨合的階段。首先，大部分紅員對團隊開發都是0經驗，也沒有很好的團隊開發意識。其次，因爲客戶課程的緣由，咱們並無不少的時間可以坐在一塊兒面對面編程（感受這點第六組特別棒，積極向他們學習）。目前團隊也慢慢開始都有了團隊開發的意識，團隊成員的開發風格、代碼風格也在慢慢統一（這點以爲第一組作得特別棒，在被迫手動合併代碼，幫成員寫對接部分時在好幾份代碼風格差別較大的代碼中游走，真的太難受了）。
• 3.你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?
  這階段的任務能夠說是比較重吧，時間也比較緊迫，團隊的積極性提高了很多。團隊也慢慢愈來愈像一個團隊，總體團隊意識也有所加強。

• 4.你以爲目前最須要改進的一個方面是什麼?
  團隊協做能力，這方面提高了會很大幅度地提高工做效率，不少問題也都會跟着解決。

• 5.對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。

  敏捷原則：
  1.1 簡單----使未完成的工做最大化的藝術----是根本的。
  1.2敏捷過程提可持續的開發速度。責任人、開發者和用戶應該可以保持一個長期的、恆定的開發速度
  1.3 不斷地關注優秀的技能和好的設計會加強敏捷能力
  1.4 即便到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優點

答辯總結

【團隊中我的的貢獻比例】

學號	成員	參與	貢獻比例
031602428	蘇路明	博客撰寫，整合前端，對接後端，測試，改善原型	12
031602401	陳瀚霖	首頁地圖頁面開發，照片顯示頁面開發	10
031602406	程曉宏	自動生成旅遊故事算法、設計，接口開發，過後博客撰寫	10
031602438	葉一帆	後端接口設計，接口開發，對接前端，測試	14
031602407	何家健	用戶中心、反饋頁面開發，短故事模板選擇頁面開發	9
031602410	黃海潮	記錄方式相關頁面開發	9
031602429	王錦揚	短故事模板設計，評分表設計、記錄	7
031602442	鄭孔宇	可視化地圖開發	10
031602439	俞凱欣	短故事模板設計，評分表設計、記錄，視頻錄製	8
031602421	林世傑	自動生成旅遊故事算法、設計，接口開發，PPT製做、演講	11

【評審表格設計】

• 評審表

【答辯總結】

• 評分：去除最高分（83）最低分（73）後的平均分：76.71

  組號	團隊名	評分
  1	爸爸餓了	73
  2	拖鞋旅遊隊	81
  3	彳艮彳亍	78
  4	火箭少男100	75
  5	起牀一塊兒肝活隊	83
  6	404 Note Found	79
  7	第三視角	77
  8	小白吃	74
  9	我頭髮呢	73

【問題&回答】

第一小組的問題：

• Q1:爲何沒有使用版本管理工具管理代碼？
• A1:咱們有使用git工具來管理代碼，只是在使用過程中，多數開發成員對git並不熟悉，沒能很好地上手，只好由PM來代替實現。
• Q2:大家要怎麼解決UI不夠美觀的問題？
• A2:我以爲Alpha版本我只專一於作某些部分，因此並無對全部的界面進行UI改善，我相信所有界面通過UI設計改善後美觀程度還能夠，在對功能的實現有徹底把握的狀況下咱們纔會再去考慮更好地改善UI。
• Q3:大家分工是否不明確？
• A3:咱們的團隊分工在團隊成立以後就比較明確，固然咱們也會視任務狀況進行再次分配，可是不會改變成員的分工主方向。

第三組的問題

• Q1:地圖上的照片定位標記當數量達到必定量時，或許會不方便於用戶的查看，出現重疊遮擋的狀況，是否有考慮過如何優化呈現形式的想法呢？
• A1:這一問題咱們一直有在考慮，如今團隊成員也在學習聚合信息，相信在Beta版本咱們能夠解決這一問題。
• Q2:本來的功能設計中有 h5 等形式的發佈，能夠細說一下具體的實現方式嗎？最終大家的產品總體會是一個怎樣的效果？
• A2:H5等形式的發佈，是被包含在分享方面。具體的實現方式是使用用戶數據生成動態h5頁面，用戶可分享至朋友圈，理想效果可參考易企秀等。總體效果敬請期待。
• Q3:大家目標中的短故事、文字等的記錄，在地圖上的標註大概以怎樣的形式來展示？
• A3:這部份內容並不會在地圖上顯示標註，這部分主要是用在用戶記錄和分享上面。

第四組的問題

• Q1:爲何實現功能偏少呢？
• A1:在課堂上，咱們有提到這一部分，看起來咱們實現的功能是比較少，可是其中有許多的邏輯結構以及核心功能花費了咱們很是多的時間，目前看來咱們的計劃進度也是符合預期的。
• Q2:開發組進展過慢？
• A2:我以爲咱們的開發進度基本上是符合預期的。基本實現了核心功能，也完成了Alpha的任務。

第五組的問題

• Q1:爲何對於以前一次的答辯過程當中提到的問題沒有考慮全面，只有選擇性的解決了部分的問題？
• A1:在此部分咱們的主要任務並不在於此，同時咱們的考慮也都是通過團隊討論慎重決定，也基本是有理有據的。
• Q2:爲何在展現的過程當中，基本上在吹大佬完成了什麼工做，其餘成員有點太過於放低自我？
• A2:咱們的主講人可能滑稽感染能力較強，致使大家產生這方面的誤解，其實咱們的成員對分配的任務（仍是比較均衡的）完成度仍是比較好的。
• Q3:在小程序上，美工方面也是有所不足，上傳照片方面也是有所受限，怎麼解決？
• A3:美工方面咱們在完成功能的方面纔會考慮進一步改善，上傳照片方面咱們目前沒有很好的辦法，可是團隊討論也有個比較好的權衡辦法。

第六組的問題

• Q1:爲何旅遊故事沒有展現？
• A1:由於Alpha版本咱們分配成員設計旅遊故事生成算法，相關方面的功能實現是安排在Beta階段。
• Q2:我的感受旅遊軟件APP更好，有沒有考慮？
• A2:這方面競爭較大，同時與咱們的定位和挖掘的需求有較大的差別，目前不會考慮。
• Q3:進度有點慢？
• A3:咱們的能力比較有限，我以爲咱們的開發進度基本上是符合預期的。基本實現了核心功能，也完成了Alpha的任務。

第七組的問題

• Q1:怎麼提升UI設計？
• A1:我以爲Alpha版本我只專一於作某些部分，因此並無對全部的界面進行UI改善，我相信所有界面通過UI設計改善後美觀程度還能夠，在對功能的實現有徹底把握的狀況下咱們纔會再去考慮更好地改善UI。
• Q2:經過此次展現感受組內分工不明確？
• A2:咱們的團隊分工在團隊成立以後就比較明確，固然咱們也會視任務狀況進行再次分配，可是不會改變成員的分工主方向。
• Q3:開發進度較慢，完成度較低是爲何？
• A3:咱們的能力比較有限，我以爲咱們的開發進度基本上是符合預期的。基本實現了核心功能，也完成了Alpha的任務。
• Q4:是否還存在git使用問題？
• A4:團隊成員目前對git使用還不夠熟悉，還存在點問題，咱們成員也在積極學習，相信在Beta版本咱們能夠較好地使用git。

第八組的問題

• Q1:技術上的問題怎麼解決？還有待改善
• A1:狂啃資料，爆肝。

第九組的問題

• Q1:怎麼解決UI界面不夠美觀，有些按鈕顯得不和諧問題？
• A1:我以爲Alpha版本我只專一於作某些部分，因此並無對全部的界面進行UI改善，我相信所有界面通過UI設計改善後美觀程度還能夠，在對功能的實現有徹底把握的狀況下咱們纔會再去考慮更好地改善UI。
• Q2:爲何有些界面過於簡陋看不出功能是否可用？
• A2:我以爲Alpha版本我只專一於作某些部分，因此部分界面只完成了前端部分，尚未與後端對接。
• Q3:進度有點慢？
• A3:咱們的能力比較有限，我以爲咱們的開發進度基本上是符合預期的。基本實現了核心功能，也完成了Alpha的任務。

【其餘組提出的意見和建議】

• 後期要增強功能的完善
• 建議使用 git 進行版本管理
• UI界面須要美化
• 優化 UI 以及部分操做邏輯，但軟件更易用。
• 對現有功能進行完善並添加新的功能。
• 能夠嘗試經過接口其餘方式實現其餘風格的轉化，用戶參與度上對簽到能夠採用獎勵制
• 但願可以?先考慮優化一下大衆羣體及一些重度用戶戶的用戶戶體驗， 好比如柯老師這樣的萬圖用戶。
• 在地圖的標註上面能夠採起更加友好美觀的界面互動形式。
• 加快項目推動。
• 下次能夠着重講解功能實現進度

我的部分

• 我的學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時(小時)	累計學習耗時（小時）	重要成長
-----	--------------	--------------	------------------	--------------------	-----------------
5	1000+	1000+	30	40	Lua流程控制學習、
6	1000+	2000+	5	45	複習java
7	1000+	3000+	10	55	lua學習
8	200+	3200+	5	60	Java web框架學習
9	300+	3500+	5	65	Java web框架學習
10	300+	3800+	5	70	Java web框架學習
11	300+	4100+	5	75	Java web框架學習
12	500+	4600+	8	83	服務器負載均衡學習