Alpha沖刺（11/10）

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

前言

• 隊名：拖鞋旅遊隊
• 組長部落格：https://www.cnblogs.com/Sulumer/p/10054510.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操作不注意導緻使用者資訊洩露。

• 輔助工具的使用不熟練，如果能重來增強GitHub的使用，熟悉VS2017、LoadRunner等負載測試工具的使用.

團隊的角色，管理，合作

• 1.團隊的每個角色是如何确定的，是不是人盡其才？

  團隊角色由隊員自己申報，再由PM根據情況調整。每個隊友得到符合其意願的職務，工作效率合格，算是人盡其才吧。

• 2.團隊成員之間有互相幫助麼？

  有的，團隊合作總會出現問題，不管是技術上的還是非技術上的，團隊分為幾個小組，每個小組在執行任務時遇到問題互相讨論，互相幫助解決。

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

  團隊合作融洽，很少出現合作問題，當出現問題時，聽PM安排。沒有什麼是合作解決不了的問題，如果有，那就一瓶奶茶搞定。

• 每個成員明确公開地表示對成員幫助的感謝

  我感謝UI組長（俞凱欣）對我的幫助， 因為某個具體的事情:原先我對UI設計及各種P圖軟體，UI設計軟體，設計方法一竅不通，在他的幫助下我覺得學到了很多東西。

總結

• 1.你覺得團隊目前的狀态屬于CMM/CMMI中的哪個檔次？

  我們團隊對團隊協作開發經驗比較欠缺，目前還處于磨合階段吧。是以我們前端後端基本上都處于初始級别，部分達到可重複級，目前也在積極向第一組學習，争取之後能達到可重複級以上。

• 2.你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?

  我覺得團隊目前還處于磨合的階段。首先，大部分成員對團隊開發都是0經驗，也沒有很好的團隊開發意識。其次，由于客戶課程的原因，我們并沒有很多的時間能夠坐在一起面對面程式設計（感覺這點第六組特别棒，積極向他們學習）。目前團隊也慢慢開始都有了團隊開發的意識，團隊成員的開發風格、代碼風格也在慢慢統一（這點覺得第一組做得特别棒，在被迫手動合并代碼，幫成員寫對接部分時在好幾份代碼風格差異較大的代碼中遊走，真的太難受了）。

• 3.你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?

  這階段的任務可以說是比較重吧，時間也比較緊迫，團隊的積極性提升了不少。團隊也慢慢越來越像一個團隊，整體團隊意識也有所增強。

• 4.你覺得目前最需要改進的一個方面是什麼?

  團隊協作能力，這方面提升了會很大幅度地提升工作效率，很多問題也都會跟着解決。

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

靈活原則：

1.1 簡單----使未完成的工作最大化的藝術----是根本的。

1.2靈活過程提可持續的開發速度。責任人、開發者和使用者應該能夠保持一個長期的、恒定的開發速度

1.3 不斷地關注優秀的技能和好的設計會增強靈活能力

1.4 即使到了開發的後期，也歡迎改變需求。靈活過程利用變化來為客戶創造競争優勢

答辯總結

【團隊中個人的貢獻比例】

學号	成員	參與	貢獻比例
031602428	蘇路明	部落格撰寫，整合前端，對接後端，測試，改善原型	12
031602401	陳瀚霖	首頁地圖頁面開發，照片顯示頁面開發	10
031602406	程曉宏	自動生成旅遊故事算法、設計，接口開發，事後部落格撰寫
031602438	葉一帆	後端接口設計，接口開發，對接前端，測試	14
031602407	何家健	使用者中心、回報頁面開發，短故事模闆選擇頁面開發	9
031602410	黃海潮	記錄方式相關頁面開發
031602429	王錦揚	短故事模闆設計，評分表設計、記錄	7
031602442	鄭孔宇	可視化地圖開發
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
  	第三視角	77
  	小白吃	74
  	我頭發呢

【問題&回答】

第一小組的問題：

• 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:開發進度較慢，完成度較低是為什麼？
• Q4:是否還存在git使用問題？
• A4:團隊成員目前對git使用還不夠熟悉，還存在點問題，我們成員也在積極學習，相信在Beta版本我們可以較好地使用git。

第八組的問題

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

第九組的問題

• Q1:怎麼解決UI界面不夠美觀，有些按鈕顯得不和諧問題？
• Q2:為什麼有些界面過于簡陋看不出功能是否可用？
• A2:我覺得Alpha版本我隻專注于做某些部分，是以部分界面隻完成了前端部分，還沒有與後端對接。

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

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

個人部分

• 個人PSP

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning		15	25
· Estimate	· 估計這個任務需要多少時間	220	350
· Development	開發
· Analysis	· 需求分析 (包括學習新技術)
· Design Spec	· 生成設計文檔	30
· Design Review	· 設計複審 (和同僚稽核設計文檔)		20
· Coding Standard	· 代碼規範 (為目前的開發制定合适的規範)
· Design	· 具體設計	40	60
· Coding	· 具體編碼
· Code Review	· 代碼複審
· Test	· 測試（自我測試，修改代碼，送出修改）
· Reporting	報告
· Test Report	· 測試報告
· Size Measurement	· 計算工作量
· Postmortem & Process Improvement Plan	· 事後總結, 并提出過程改進計劃
合計	515

【學習進度條】

第N周	新增代碼(行)	累計代碼(行)	本周學習耗時(小時)	累計學習耗時(小時)	重要成長
	18.5		熟悉Axure的使用方法、對軟體的原型設計有了更深刻的了解
	113		28.5	47	對算法的構思有更多的了解
	106	219		62	加深掌握了Axure的使用，學會了使用NABCD模型進行需求分析
	211	430	18	80	認識了原型設計的重要性，學會部分原型設計的技能
	252	692		92	進行logo，原型的設計與修改
	50	742		102	logo，原型初步設計完成
	190	932		132	logo，原型完善
			157	海報設計，logo，原型完善
	200	1132		162	logo，原型繼續完善
	100	1232		165	短故事模闆設計