拖鞋旅游隊團隊事后諸葛亮會議

前言

• 隊名：拖鞋旅游隊
• 組長博客：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操作不注意導致用戶信息泄露。
• 6.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
  輔助工具的使用不熟練，如果能重來增強GitHub的使用，熟悉VS2017、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 以及部分操作邏輯，但軟件更易用。
• 對現有功能進行完善并添加新的功能。
• 可以嘗試通過接口其他方式實現其他風格的轉化，用戶參與度上對簽到可以采用獎勵制
• 希望能夠?先考慮優化一下大眾群體及一些重度用戶戶的用戶戶體驗， 比如如柯老師這樣的萬圖用戶。
• 在地圖的標注上面可以采取更加友好美觀的界面互動形式。
• 加快項目推進。
• 下次可以著重講解功能實現進度

個人部分

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

• 個人學習進度條

第N周新增代碼累計代碼本周學習時間累計學習時間(小時)重要成長

1	200	200	5	5	對Axure的學習
5	200	400	12	17	html,css的學習
7	400	800	8	25	對c中各種函數的學習
8	500	1300	8	33	微信web開發者工具的使用,css,js的學習
12	200	1500	6	39	wxml,wxss的學習和使用
13	300	1800	6	45	微信中js的運用和微信接口的調用

• 個人體會

  感謝

  • 我感謝葉一帆同學對我的幫助，由于我以前并沒有開發過任何程序，對此并不是很了解，一帆同學發給我許多學習資料，以及在前后端接口對接上給予了我許多幫助。

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

  • 我學會了許多東西例如微信小程序中所需要用的wxml,wxss,js以及echart對地圖的繪制。如果重來一遍我希望能夠提高自己學習的效率。

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

  • 我覺得我們還只處于第二階段。

  你覺得團隊目前處于 萌芽/磨合/規范/創造 階段的哪一個階段？

  • 我覺得我們團隊目前處于磨合階段。

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

  • 對自己所開發的產品有更多的了解，對微信小程序的開發有更深的理解。

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

  • 對UI界面的設計和統一風格。

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

  • 我認為我們組做得最好的幾個原則有：敏捷流程應能保持可持續的發展。 領導, 團隊和用戶應該能按照目前步調持續合作下去。我們每天都在為產品進行更新與修復bug；只有不斷關注技術和設計才能越來越敏捷。我們每天都在學習新的技術以及更好的UI界面設計；無論團隊內外，面對面的交流始終是最有效的溝通方式。我們經常互相溝通來更加方便的對接前后端。

轉載于:https://www.cnblogs.com/kkyblog/p/10055478.html

總結

以上是生活随笔為你收集整理的Alpha 冲刺11——总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。