拖鞋旅游隊(duì)團(tuán)隊(duì)事后諸葛亮?xí)h

前言

• 隊(duì)名：拖鞋旅游隊(duì)
• 組長博客：https://www.cnblogs.com/Sulumer/p/10054510.html
• 時(shí)間：2018-12-1 20:00
• 地點(diǎn)：生活三區(qū)31#3樓活動室
• 參會人員： 拖鞋旅游隊(duì)全體成員
• 與會圖片：
  

項(xiàng)目Postmortem

設(shè)想與目標(biāo)

• 1.我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
  我們軟件要解決的是喜歡記錄分享旅游生活的人群的旅游記錄分享功能。相關(guān)定義、典型用戶以及典型場景已經(jīng)通過UML圖和需求分析報(bào)告清晰地描述。
• 2.我們達(dá)到目標(biāo)了么（原計(jì)劃的功能做到了幾個(gè)？ 按照原計(jì)劃交付時(shí)間交付了么？ 原計(jì)劃達(dá)到的用戶數(shù)量達(dá)到了么?)?
  在alpha沖刺階段，按時(shí)達(dá)到了原計(jì)劃的要求。目前仍處于內(nèi)測階段，只在小范圍內(nèi)挑選特定用戶交流使用，尚未大面積投放給用戶使用。在beta沖刺階段開始時(shí)會陸續(xù)提交試用版本，讓用戶進(jìn)一步參與軟件設(shè)計(jì)。
• 3.用戶量, 用戶對重要功能的接受程度和我們事先的預(yù)想一致么? 我們離目標(biāo)更近了么?
  在alpha版本下，用戶的滿意程度符合我們的預(yù)期，可以自信地說，我們離目標(biāo)更近了。
• 4.有什么經(jīng)驗(yàn)教訓(xùn)? 如果歷史重來一遍, 我們會做什么改進(jìn)?
  原型設(shè)計(jì)非常重要，常常起到先導(dǎo)作用。我們在做alpha版本之前沒有重視原型設(shè)計(jì)，后來在實(shí)現(xiàn)時(shí)出現(xiàn)漏洞，不得不返工重構(gòu)，浪費(fèi)了時(shí)間。如果歷史重來一遍，在設(shè)想階段，應(yīng)盡可能的完善原型設(shè)計(jì)，減少重構(gòu)次數(shù)。

計(jì)劃

• 1.是否有充足的時(shí)間來做計(jì)劃？
  從確定團(tuán)隊(duì)開發(fā)項(xiàng)目到具體實(shí)踐，做計(jì)劃的時(shí)間不多。但隨著項(xiàng)目的推進(jìn)，我們也在不斷的完善細(xì)化計(jì)劃。
• 2.團(tuán)隊(duì)在計(jì)劃階段是如何解決同事們對于計(jì)劃的不同意見的？
  我們通過集中討論的方式，在小組討論會上收集不同意見，由PM和技術(shù)組長進(jìn)行整合，再提出統(tǒng)一的解決方案。
• 3.你原計(jì)劃的工作是否最后都做完了？如果沒有完成，為什么？
  alpha沖刺階段原計(jì)劃工作都完成了。沒有完成的部分是因?yàn)樵谟?jì)劃之外的拓展功能實(shí)現(xiàn)較困難，需要花費(fèi)較多時(shí)間。
• 4.有沒有發(fā)現(xiàn)你做了一些事后看來沒必要或沒多大價(jià)值的事?
  因?yàn)樵贏lpha版本分工前，對整個(gè)項(xiàng)目的架構(gòu)和功能界面都已經(jīng)定義比較清楚，所以在這方面倒是比較少。但是，由于之前沒對團(tuán)隊(duì)條件的充分理解，也可以說是疏忽吧，做不了本來計(jì)劃好的事而不得不先丟棄。在之前我們一直暢想著加入榜單功能以及基于地理位置的比較有意思的功能，而在后來發(fā)現(xiàn)在此方面微信定義了門檻，需要《電信業(yè)務(wù)增值許可證》，而這也需要公司主體才能夠辦理，因此我們只能暫時(shí)廢棄之前對這方面做的工作。
• 5.是否每一項(xiàng)任務(wù)都有清楚定義和衡量的交付件?
  有些有，有些沒有。對于核心功能，每個(gè)任務(wù)都有清楚的定義和衡量的交付件，但是對于小功能，因?yàn)楸容^簡單，在alpha階段還沒有十分清晰的定義。
• 6.是否項(xiàng)目的整個(gè)過程都按照計(jì)劃進(jìn)行，項(xiàng)目出了什么意外？有什么風(fēng)險(xiǎn)是當(dāng)時(shí)沒有估計(jì)到的，為什么沒有估計(jì)到?
  到目前為止，項(xiàng)目的整個(gè)過程都按照計(jì)劃進(jìn)行。項(xiàng)目中隊(duì)友GitHub的使用情況不容樂觀，在簽入代碼時(shí)花費(fèi)了較多時(shí)間。
• 7.在計(jì)劃中有沒有留下緩沖區(qū)，緩沖區(qū)有作用么?
  有，有留下一天的緩沖區(qū)用來修改和debug。
• 8.將來的計(jì)劃會做什么修改？（例如：緩沖區(qū)的定義，加班）
  在目前核心功能都已經(jīng)基本完成的情況下，將來的計(jì)劃會更多的傾向功能完善和拓展，會擴(kuò)充緩沖區(qū)時(shí)間，留出較多時(shí)間用來收集用戶建議和測試。
• 9.我們學(xué)到了什么? 如果歷史重來一遍, 我們會做什么改進(jìn)?
  完善計(jì)劃和定制計(jì)劃同樣重要。原計(jì)劃的實(shí)施情況已經(jīng)符合我們的預(yù)期，但是在過程中總會有一些意想不到的突發(fā)情況，因此及時(shí)的微調(diào)計(jì)劃對于整個(gè)項(xiàng)目的實(shí)行起到了很重要的作用。如果能重來一次，我希望在制定計(jì)劃時(shí)能夠留下更多的緩沖時(shí)間。

資源

• 1.我們有足夠的資源來完成各項(xiàng)任務(wù)么?
  目前的資源足夠我們完成各項(xiàng)任務(wù)。
• 2.各項(xiàng)任務(wù)所需的時(shí)間和其他資源是如何估計(jì)的，精度如何?
  各項(xiàng)任務(wù)所需要的時(shí)間和其他資源是有PM人為估計(jì)的，對時(shí)間的估計(jì)精度誤差在小時(shí)以內(nèi)。資源估計(jì)精度誤差較大。
• 3.測試的時(shí)間，人力和軟件/硬件資源是否足夠? 對于那些不需要編程的資源 (美工設(shè)計(jì)/文案)是否低估難度?
  測試，人力和軟件/硬件資源足夠，但對于美工設(shè)計(jì)和文案設(shè)計(jì)這些主觀難以定性衡量的資源難度較大，要設(shè)計(jì)出符合預(yù)期甚至超出預(yù)期的產(chǎn)品需要反復(fù)迭代。
• 4.你有沒有感到你做的事情可以讓別人來做（更有效率）?
  沒有，團(tuán)隊(duì)分工明確，各司其職，對待自己負(fù)責(zé)的模塊工作效率已經(jīng)足夠高。
• 5.有什么經(jīng)驗(yàn)教訓(xùn)? 如果歷史重來一遍, 我們會做什么改進(jìn)?
  初期分配學(xué)習(xí)時(shí)間不是很合理。在時(shí)間分配上，如果能夠重來一次，在初期分配學(xué)習(xí)任務(wù)的時(shí)間會縮短，提前進(jìn)入實(shí)戰(zhàn)環(huán)節(jié)。

變更管理

• 1.每個(gè)相關(guān)的員工都及時(shí)知道了變更的消息?
  是的，對于變更會及時(shí)通知相關(guān)成員。
• 2.我們采用了什么辦法決定“推遲”和“必須實(shí)現(xiàn)”的功能?
  根據(jù)功能在整個(gè)項(xiàng)目的重要程度。核心功能在alpha版本實(shí)現(xiàn)，剩下的完善部分放到beta版本。
• **3.項(xiàng)目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?
  所有頁面整合在一起，通過了各項(xiàng)測試，就“做好了”。
• 4.對于可能的變更是否能制定應(yīng)急計(jì)劃?
  能。團(tuán)隊(duì)支持變更，對于變更能及時(shí)定制相應(yīng)計(jì)劃。
• 5.員工是否能夠有效地處理意料之外的工作請求？
  部分員工經(jīng)驗(yàn)不足，不能獨(dú)自有效的處理，但是在PM和技術(shù)組長的帶領(lǐng)下能夠有效的應(yīng)對變更。
• 6.我們學(xué)到了什么? 如果歷史重來一遍, 我們會做什么改進(jìn)?
  GitHub的使用能大大提高工作效率，如果能夠重來一遍，在項(xiàng)目開始前應(yīng)該進(jìn)行相應(yīng)的GitHub使用培訓(xùn)，減少用QQ傳代碼的頻率。

設(shè)計(jì)/實(shí)現(xiàn)

• 1.設(shè)計(jì)工作在什么時(shí)候，由誰來完成的？是合適的時(shí)間，合適的人么？
  設(shè)計(jì)工作在alpha沖刺的前三天，由經(jīng)驗(yàn)豐富的PM完成。設(shè)計(jì)時(shí)間合適，人選合適。
  
• 2.設(shè)計(jì)工作有沒有碰到模棱兩可的情況，團(tuán)隊(duì)是如何解決的？
  在PM設(shè)計(jì)過程有遇到模棱兩可的情況，團(tuán)隊(duì)開會討論解決。
• 3.團(tuán)隊(duì)是否運(yùn)用單元測試（unit test），測試驅(qū)動的開發(fā)（TDD）、UML, 或者其他工具來幫助設(shè)計(jì)和實(shí)現(xiàn)？這些工具有效么？
  有，團(tuán)隊(duì)使用Visual Studio 2017自帶的性能測試工具進(jìn)行測試。這些工具可以很好的幫助我們測試，進(jìn)行代碼規(guī)范和debug。
• 4.比較項(xiàng)目開始的 UML 文檔和現(xiàn)在的狀態(tài)有什么區(qū)別？這些區(qū)別如何產(chǎn)生的？是否要更新 UML 文檔？
  最開始的UML文檔給出了一個(gè)大體的框架，在根據(jù)這些框架逐一實(shí)現(xiàn)時(shí)會做出一定修改甚至重構(gòu)，這些區(qū)別產(chǎn)生的原因是需求的變更以及計(jì)劃變更。為了項(xiàng)目完整性，我們有及時(shí)更新UML文檔。
• 5.什么功能產(chǎn)生的Bug最多，為什么？在發(fā)布之后發(fā)現(xiàn)了什么重要的bug? 為什么我們在設(shè)計(jì)/開發(fā)的時(shí)候沒有想到這些情況?
  照片地理位置解析和登錄。在照片信息解析方面，需要對經(jīng)緯度的格式轉(zhuǎn)換，以及一系列的流程，在這里我們共用了五個(gè)接口，目前也沒有特別好的解決這個(gè)問題，在分析后發(fā)現(xiàn)是計(jì)算過程精度的丟失，有所改進(jìn)。登錄方面，由于安卓手機(jī)的數(shù)據(jù)沒有辦法很好地清除，導(dǎo)致用戶不滿足條件，確能夠使用功能（當(dāng)然無法返回結(jié)果）。目前還沒有發(fā)布，都是團(tuán)隊(duì)內(nèi)部人員在測試，以上就是主要的bug。問題主要在于設(shè)計(jì)/開發(fā)前沒有很好地理清邏輯，也有點(diǎn)忽視了這方面。
• 6.代碼復(fù)審（Code Review）是如何進(jìn)行的，是否嚴(yán)格執(zhí)行了代碼規(guī)范？
  代碼復(fù)審沒有很詳盡，在程序可運(yùn)行可讀的情況下進(jìn)行代碼復(fù)審，沒有嚴(yán)格的執(zhí)行代碼規(guī)范。
• 7.我們學(xué)到了什么? 如果歷史重來一遍, 我們會做什么改進(jìn)?
  設(shè)計(jì)很豐滿，實(shí)現(xiàn)很骨感，在實(shí)現(xiàn)的過程中總會出現(xiàn)知識和非知識層次的困擾。如果歷史再來一遍，希望在alpha沖刺開始前團(tuán)隊(duì)先集中訓(xùn)練。

測試/發(fā)布

• 1.團(tuán)隊(duì)是否有一個(gè)測試計(jì)劃？為什么沒有？
  有。團(tuán)隊(duì)根據(jù)功能圖表有詳細(xì)的測試計(jì)劃。
• 2.是否進(jìn)行了正式的驗(yàn)收測試？
  還沒有，目前功能還沒有全部實(shí)裝，因此還沒有進(jìn)行正式驗(yàn)收測試。
• 3.團(tuán)隊(duì)是否有測試工具來幫助測試？
  有，團(tuán)隊(duì)使用Visual Studio 2017自帶的性能測試工具進(jìn)行測試。
• 4.團(tuán)隊(duì)是如何測量并跟蹤軟件的效能的？從軟件實(shí)際運(yùn)行的結(jié)果來看，這些測試工作有用么？應(yīng)該有哪些改進(jìn)？
  目前還沒有考慮測量軟件的效能，會在beta版本中考慮。
• 5.在發(fā)布的過程中發(fā)現(xiàn)了哪些意外問題？
  前端的測試并不理想。GitHub操作不注意導(dǎo)致用戶信息泄露。
• 6.我們學(xué)到了什么? 如果歷史重來一遍, 我們會做什么改進(jìn)?
  輔助工具的使用不熟練，如果能重來增強(qiáng)GitHub的使用，熟悉VS2017、LoadRunner等負(fù)載測試工具的使用.

團(tuán)隊(duì)的角色，管理，合作

• 1.團(tuán)隊(duì)的每個(gè)角色是如何確定的，是不是人盡其才？
  團(tuán)隊(duì)角色由隊(duì)員自己申報(bào)，再由PM根據(jù)情況調(diào)整。每個(gè)隊(duì)友得到符合其意愿的職務(wù)，工作效率合格，算是人盡其才吧。
• 2.團(tuán)隊(duì)成員之間有互相幫助么？
  有的，團(tuán)隊(duì)合作總會出現(xiàn)問題，不管是技術(shù)上的還是非技術(shù)上的，團(tuán)隊(duì)分為幾個(gè)小組，每個(gè)小組在執(zhí)行任務(wù)時(shí)遇到問題相互討論，互相幫助解決。
• 3.當(dāng)出現(xiàn)項(xiàng)目管理、合作方面的問題時(shí)，團(tuán)隊(duì)成員如何解決問題？
  團(tuán)隊(duì)合作融洽，很少出現(xiàn)合作問題，當(dāng)出現(xiàn)問題時(shí)，聽PM安排。沒有什么是合作解決不了的問題，如果有，那就一瓶奶茶搞定。
• 每個(gè)成員明確公開地表示對成員幫助的感謝
  我感謝開發(fā)組長（葉一帆）對我的幫助， 因?yàn)槟硞€(gè)具體的事情: 在開發(fā)過程當(dāng)中，基本都是我們兩個(gè)在對接前后端，思考改善程序的邏輯結(jié)構(gòu)。同時(shí)也有一個(gè)點(diǎn)，他是比較專業(yè)的后端開發(fā)，改變了我之前對接口功能看法，在對信息安全，數(shù)據(jù)庫安全有了比較大的改進(jìn)認(rèn)知。

總結(jié)

• 1.你覺得團(tuán)隊(duì)目前的狀態(tài)屬于CMM/CMMI中的哪個(gè)檔次？
  我們團(tuán)隊(duì)對團(tuán)隊(duì)協(xié)作開發(fā)經(jīng)驗(yàn)比較欠缺，目前還處于磨合階段吧。所以我們前端后端基本上都處于初始級別，部分達(dá)到可重復(fù)級，目前也在積極向第一組學(xué)習(xí)，爭取之后能達(dá)到可重復(fù)級以上。
• 2.你覺得團(tuán)隊(duì)目前處于 萌芽/磨合/規(guī)范/創(chuàng)造 階段的哪一個(gè)階段?
  我覺得團(tuán)隊(duì)目前還處于磨合的階段。首先，大部分成員對團(tuán)隊(duì)開發(fā)都是0經(jīng)驗(yàn)，也沒有很好的團(tuán)隊(duì)開發(fā)意識。其次，由于客戶課程的原因，我們并沒有很多的時(shí)間能夠坐在一起面對面編程（感覺這點(diǎn)第六組特別棒，積極向他們學(xué)習(xí)）。目前團(tuán)隊(duì)也慢慢開始都有了團(tuán)隊(duì)開發(fā)的意識，團(tuán)隊(duì)成員的開發(fā)風(fēng)格、代碼風(fēng)格也在慢慢統(tǒng)一（這點(diǎn)覺得第一組做得特別棒，在被迫手動合并代碼，幫成員寫對接部分時(shí)在好幾份代碼風(fēng)格差異較大的代碼中游走，真的太難受了）。
• 3.你覺得團(tuán)隊(duì)在這個(gè)里程碑相比前一個(gè)里程碑有什么改進(jìn)?
  這階段的任務(wù)可以說是比較重吧，時(shí)間也比較緊迫，團(tuán)隊(duì)的積極性提升了不少。團(tuán)隊(duì)也慢慢越來越像一個(gè)團(tuán)隊(duì)，整體團(tuán)隊(duì)意識也有所增強(qiáng)。

• 4.你覺得目前最需要改進(jìn)的一個(gè)方面是什么?
  團(tuán)隊(duì)協(xié)作能力，這方面提升了會很大幅度地提升工作效率，很多問題也都會跟著解決。

• 5.對照敏捷開發(fā)的原則, 你覺得你們小組做得最好的是哪幾個(gè)原則? 請列出具體的事例。

  敏捷原則：
  1.1 簡單----使未完成的工作最大化的藝術(shù)----是根本的。
  1.2敏捷過程提可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個(gè)長期的、恒定的開發(fā)速度
  1.3 不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會增強(qiáng)敏捷能力
  1.4 即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢

答辯總結(jié)

【團(tuán)隊(duì)中個(gè)人的貢獻(xiàn)比例】

學(xué)號成員參與貢獻(xiàn)比例

031602428	蘇路明	博客撰寫，整合前端，對接后端，測試，改善原型	12
031602401	陳瀚霖	首頁地圖頁面開發(fā)，照片顯示頁面開發(fā)	10
031602406	程曉宏	自動生成旅游故事算法、設(shè)計(jì)，接口開發(fā)，事后博客撰寫	10
031602438	葉一帆	后端接口設(shè)計(jì)，接口開發(fā)，對接前端，測試	14
031602407	何家健	用戶中心、反饋頁面開發(fā)，短故事模板選擇頁面開發(fā)	9
031602410	黃海潮	記錄方式相關(guān)頁面開發(fā)	9
031602429	王錦揚(yáng)	短故事模板設(shè)計(jì)，評分表設(shè)計(jì)、記錄	7
031602442	鄭孔宇	可視化地圖開發(fā)	10
031602439	俞凱欣	短故事模板設(shè)計(jì)，評分表設(shè)計(jì)、記錄，視頻錄制	8
031602421	林世杰	自動生成旅游故事算法、設(shè)計(jì)，接口開發(fā)，PPT制作、演講	11

【評審表格設(shè)計(jì)】

• 評審表

【答辯總結(jié)】

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

  組號團(tuán)隊(duì)名評分

  1	爸爸餓了	73
  2	拖鞋旅游隊(duì)	81
  3	彳艮彳亍	78
  4	火箭少男100	75
  5	起床一起肝活隊(duì)	83
  6	404 Note Found	79
  7	第三視角	77
  8	小白吃	74
  9	我頭發(fā)呢	73

【問題&回答】

第一小組的問題：

• Q1:為什么沒有使用版本管理工具管理代碼？
• A1:我們有使用git工具來管理代碼，只是在使用過程當(dāng)中，多數(shù)開發(fā)成員對git并不熟悉，沒能很好地上手，只好由PM來代替實(shí)現(xiàn)。
• Q2:你們要怎么解決UI不夠美觀的問題？
• A2:我覺得Alpha版本我只專注于做某些部分，所以并沒有對所有的界面進(jìn)行UI改善，我相信全部界面經(jīng)過UI設(shè)計(jì)改善后美觀程度還可以，在對功能的實(shí)現(xiàn)有完全把握的情況下我們才會再去考慮更好地改善UI。
• Q3:你們分工是否不明確？
• A3:我們的團(tuán)隊(duì)分工在團(tuán)隊(duì)成立之后就比較明確，當(dāng)然我們也會視任務(wù)情況進(jìn)行再次分配，但是不會改變成員的分工主方向。

第三組的問題

• Q1:地圖上的照片定位標(biāo)記當(dāng)數(shù)量達(dá)到一定量時(shí)，或許會不方便于用戶的查看，出現(xiàn)重疊遮擋的情況，是否有考慮過如何優(yōu)化呈現(xiàn)形式的想法呢？
• A1:這一問題我們一直有在考慮，現(xiàn)在團(tuán)隊(duì)成員也在學(xué)習(xí)聚合信息，相信在Beta版本我們可以解決這一問題。
• Q2:原本的功能設(shè)計(jì)中有 h5 等形式的發(fā)布，可以細(xì)說一下具體的實(shí)現(xiàn)方式嗎？最終你們的產(chǎn)品整體會是一個(gè)怎樣的效果？
• A2:H5等形式的發(fā)布，是被包含在分享方面。具體的實(shí)現(xiàn)方式是使用用戶數(shù)據(jù)生成動態(tài)h5頁面，用戶可分享至朋友圈，理想效果可參考易企秀等。整體效果敬請期待。
• Q3:你們目標(biāo)中的短故事、文字等的記錄，在地圖上的標(biāo)注大概以怎樣的形式來展現(xiàn)？
• A3:這部分內(nèi)容并不會在地圖上顯示標(biāo)注，這部分主要是用在用戶記錄和分享上面。

第四組的問題

• Q1:為什么實(shí)現(xiàn)功能偏少呢？
• A1:在課堂上，我們有提到這一部分，看起來我們實(shí)現(xiàn)的功能是比較少，但是其中有許多的邏輯結(jié)構(gòu)以及核心功能花費(fèi)了我們非常多的時(shí)間，目前看來我們的計(jì)劃進(jìn)度也是符合預(yù)期的。
• Q2:開發(fā)組進(jìn)展過慢？
• A2:我覺得我們的開發(fā)進(jìn)度基本上是符合預(yù)期的。基本實(shí)現(xiàn)了核心功能，也完成了Alpha的任務(wù)。

第五組的問題

• Q1:為什么對于之前一次的答辯過程中提到的問題沒有考慮全面，只有選擇性的解決了部分的問題？
• A1:在此部分我們的主要任務(wù)并不在于此，同時(shí)我們的考慮也都是經(jīng)過團(tuán)隊(duì)討論慎重決定，也基本是有理有據(jù)的。
• Q2:為什么在展示的過程中，基本上在吹大佬完成了什么工作，其他成員有點(diǎn)太過于放低自我？
• A2:我們的主講人可能滑稽感染能力較強(qiáng)，導(dǎo)致你們產(chǎn)生這方面的誤解，其實(shí)我們的成員對分配的任務(wù)（還是比較均衡的）完成度還是比較好的。
• Q3:在小程序上，美工方面也是有所不足，上傳照片方面也是有所受限，怎么解決？
• A3:美工方面我們在完成功能的方面才會考慮進(jìn)一步改善，上傳照片方面我們目前沒有很好的辦法，但是團(tuán)隊(duì)討論也有個(gè)比較好的權(quán)衡辦法。

第六組的問題

• Q1:為什么旅游故事沒有展示？
• A1:因?yàn)锳lpha版本我們分配成員設(shè)計(jì)旅游故事生成算法，相關(guān)方面的功能實(shí)現(xiàn)是安排在Beta階段。
• Q2:個(gè)人感覺旅游軟件APP更好，有沒有考慮？
• A2:這方面競爭較大，同時(shí)與我們的定位和挖掘的需求有較大的差異，目前不會考慮。
• Q3:進(jìn)度有點(diǎn)慢？
• A3:我們的能力比較有限，我覺得我們的開發(fā)進(jìn)度基本上是符合預(yù)期的。基本實(shí)現(xiàn)了核心功能，也完成了Alpha的任務(wù)。

第七組的問題

• Q1:怎么提高UI設(shè)計(jì)？
• A1:我覺得Alpha版本我只專注于做某些部分，所以并沒有對所有的界面進(jìn)行UI改善，我相信全部界面經(jīng)過UI設(shè)計(jì)改善后美觀程度還可以，在對功能的實(shí)現(xiàn)有完全把握的情況下我們才會再去考慮更好地改善UI。
• Q2:通過這次展示感覺組內(nèi)分工不明確？
• A2:我們的團(tuán)隊(duì)分工在團(tuán)隊(duì)成立之后就比較明確，當(dāng)然我們也會視任務(wù)情況進(jìn)行再次分配，但是不會改變成員的分工主方向。
• Q3:開發(fā)進(jìn)度較慢，完成度較低是為什么？
• A3:我們的能力比較有限，我覺得我們的開發(fā)進(jìn)度基本上是符合預(yù)期的。基本實(shí)現(xiàn)了核心功能，也完成了Alpha的任務(wù)。
• Q4:是否還存在git使用問題？
• A4:團(tuán)隊(duì)成員目前對git使用還不夠熟悉，還存在點(diǎn)問題，我們成員也在積極學(xué)習(xí)，相信在Beta版本我們可以較好地使用git。

第八組的問題

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

第九組的問題

• Q1:怎么解決UI界面不夠美觀，有些按鈕顯得不和諧問題？
• A1:我覺得Alpha版本我只專注于做某些部分，所以并沒有對所有的界面進(jìn)行UI改善，我相信全部界面經(jīng)過UI設(shè)計(jì)改善后美觀程度還可以，在對功能的實(shí)現(xiàn)有完全把握的情況下我們才會再去考慮更好地改善UI。
• Q2:為什么有些界面過于簡陋看不出功能是否可用？
• A2:我覺得Alpha版本我只專注于做某些部分，所以部分界面只完成了前端部分，還沒有與后端對接。
• Q3:進(jìn)度有點(diǎn)慢？
• A3:我們的能力比較有限，我覺得我們的開發(fā)進(jìn)度基本上是符合預(yù)期的。基本實(shí)現(xiàn)了核心功能，也完成了Alpha的任務(wù)。

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

• 后期要加強(qiáng)功能的完善
• 建議使用 git 進(jìn)行版本管理
• UI界面需要美化
• 優(yōu)化 UI 以及部分操作邏輯，但軟件更易用。
• 對現(xiàn)有功能進(jìn)行完善并添加新的功能。
• 可以嘗試通過接口其他方式實(shí)現(xiàn)其他風(fēng)格的轉(zhuǎn)化，用戶參與度上對簽到可以采用獎(jiǎng)勵(lì)制
• 希望能夠?先考慮優(yōu)化一下大眾群體及一些重度用戶戶的用戶戶體驗(yàn)， 比如如柯老師這樣的萬圖用戶。
• 在地圖的標(biāo)注上面可以采取更加友好美觀的界面互動形式。
• 加快項(xiàng)目推進(jìn)。
• 下次可以著重講解功能實(shí)現(xiàn)進(jìn)度

個(gè)人部分

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

• 個(gè)人學(xué)習(xí)進(jìn)度條

第N周新增代碼累計(jì)代碼本周學(xué)習(xí)時(shí)間累計(jì)學(xué)習(xí)時(shí)間(小時(shí))重要成長

1	200	200	5	5	對Axure的學(xué)習(xí)
5	200	400	12	17	html,css的學(xué)習(xí)
7	400	800	8	25	對c中各種函數(shù)的學(xué)習(xí)
8	500	1300	8	33	微信web開發(fā)者工具的使用,css,js的學(xué)習(xí)
12	200	1500	6	39	wxml,wxss的學(xué)習(xí)和使用
13	300	1800	6	45	微信中js的運(yùn)用和微信接口的調(diào)用

• 個(gè)人體會

  感謝

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

  我們學(xué)到了什么? 如果歷史重來一遍, 我們會做什么改進(jìn)?

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

  你覺得團(tuán)隊(duì)目前的狀態(tài)屬于 CMM/CMMI 中的哪個(gè)檔次？

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

  你覺得團(tuán)隊(duì)目前處于 萌芽/磨合/規(guī)范/創(chuàng)造 階段的哪一個(gè)階段？

  • 我覺得我們團(tuán)隊(duì)目前處于磨合階段。

  你覺得團(tuán)隊(duì)在這個(gè)里程碑相比前一個(gè)里程碑有什么改進(jìn)?

  • 對自己所開發(fā)的產(chǎn)品有更多的了解，對微信小程序的開發(fā)有更深的理解。

  你覺得目前最需要改進(jìn)的一個(gè)方面是什么?

  • 對UI界面的設(shè)計(jì)和統(tǒng)一風(fēng)格。

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

  • 我認(rèn)為我們組做得最好的幾個(gè)原則有：敏捷流程應(yīng)能保持可持續(xù)的發(fā)展。 領(lǐng)導(dǎo), 團(tuán)隊(duì)和用戶應(yīng)該能按照目前步調(diào)持續(xù)合作下去。我們每天都在為產(chǎn)品進(jìn)行更新與修復(fù)bug；只有不斷關(guān)注技術(shù)和設(shè)計(jì)才能越來越敏捷。我們每天都在學(xué)習(xí)新的技術(shù)以及更好的UI界面設(shè)計(jì)；無論團(tuán)隊(duì)內(nèi)外，面對面的交流始終是最有效的溝通方式。我們經(jīng)常互相溝通來更加方便的對接前后端。

轉(zhuǎn)載于:https://www.cnblogs.com/kkyblog/p/10055478.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。