本文總結(jié)了開發(fā)團(tuán)隊(duì)中,在引入Scrum Master角色后在團(tuán)隊(duì)中是如何做的收壕，以及在一個(gè)版本迭代后的復(fù)盤總結(jié)。方便今后在工作中隨時(shí)查閱轨蛤，希望對(duì)你有所幫助蜜宪。
0.相關(guān)術(shù)語解釋：
PM :是Project Manager的縮寫，項(xiàng)目主管或項(xiàng)目經(jīng)理祥山，主要負(fù)責(zé)統(tǒng)籌規(guī)劃項(xiàng)目進(jìn)度及產(chǎn)品生命圃验，其工作職能直接對(duì)公司高層負(fù)責(zé)。作為項(xiàng)目的管理者缝呕，PM通常會(huì)參與到一個(gè)或多個(gè)項(xiàng)目的管理與決策工作中澳窑。
TL: 是Team Leader的縮寫，主要負(fù)責(zé)整個(gè)項(xiàng)目的統(tǒng)籌供常，安排等摊聋。細(xì)分之下有移動(dòng)端 團(tuán)隊(duì)Leader,服務(wù)器團(tuán)隊(duì)Leader 或整個(gè)開發(fā)團(tuán)隊(duì)的Leader等等。
PO: Product Owner的縮寫栈暇，字面意思是產(chǎn)品或業(yè)務(wù)負(fù)責(zé)人麻裁，即熟悉該產(chǎn)品所有業(yè)務(wù)相關(guān)的邏輯、流程源祈、設(shè)置等方面事宜的人員悲立，一般可由產(chǎn)品經(jīng)理擔(dān)任，也可由熟悉業(yè)務(wù)的開發(fā)人員擔(dān)任新博。
PRD: Product Requirement Document 的縮寫薪夕，即產(chǎn)品需求文檔。
Scrum：是迭代式增量軟件開發(fā)過程赫悄，通常用于敏捷軟件開發(fā)原献。
1.什么是Scrum Master?
敏捷開發(fā)中的SM即Scrum Master，字面意思是敏捷專家或者敏捷大師埂淮，即熟悉敏捷開發(fā)模式及敏捷實(shí)施流程的人員姑隅。一般可由敏捷團(tuán)隊(duì)當(dāng)中的開發(fā)負(fù)責(zé)人擔(dān)任，部分能力很強(qiáng)且懂技術(shù)的產(chǎn)品經(jīng)理也可擔(dān)任這個(gè)角色倔撞，因涉及到工作量評(píng)估和分派等工作讲仰，最好都是由技術(shù)能力較強(qiáng)的人員擔(dān)任。
2. Scrum Master的職責(zé)痪蝇？和PM有什么區(qū)別鄙陡？
以下Scrum Master 簡(jiǎn)稱為SM冕房。
SM的職責(zé)：
簡(jiǎn)單來說主要有：組織會(huì)議、早會(huì)趁矾、臨時(shí)溝通會(huì)耙册、Sprint Review等等，重在協(xié)調(diào)資源 毫捣，推動(dòng)項(xiàng)目進(jìn)度详拙。
為了確保scrum被理解和正確使用并使得Scrum的收益最大化。主要職責(zé)如下：
1蔓同、保證團(tuán)隊(duì)資源合理利用饶辙；
2、保證各個(gè)角色及職責(zé)良好協(xié)作斑粱；
3弃揽、解決團(tuán)隊(duì)開發(fā)中的障礙；
4珊佣、作為團(tuán)隊(duì)和團(tuán)隊(duì)外部的接口，協(xié)調(diào)解決溝通中的問題披粟；
5咒锻、保證開發(fā)過程按計(jì)劃進(jìn)行，組織Scrum Planning Meetings（Sprint計(jì)劃會(huì)議）, Daily Stand-up Meeting（每日站會(huì)）, Sprint Review Meeting（Sprint評(píng)審會(huì)）和 Sprint Retrospective Meeting（Sprint回顧會(huì)）守屉。
區(qū)別：
在Scrum指南中惑艇，唯一一個(gè)經(jīng)過授權(quán)的角色理論上應(yīng)該是PO。然而在Scrum中拇泛，SM在團(tuán)隊(duì)中是沒有授權(quán)的滨巴，換句話說，敏捷項(xiàng)目團(tuán)隊(duì)既沒有Manager也沒有Leader俺叭。PM都是經(jīng)過在項(xiàng)目層面上經(jīng)過授權(quán)的恭取，SM的職責(zé)是確保scrum的正確使用并使得Scrum的收益最大化，SM可以兼職熄守，所以我們團(tuán)隊(duì)實(shí)行了SM 輪值蜈垮。
3. 實(shí)際迭代開發(fā)中我們是怎樣做的？
本次迭代開發(fā)我們?nèi)匀徊捎昧嗣艚蓍_發(fā)裕照，同時(shí)實(shí)行了 SM輪值的實(shí)行辦法攒发，以項(xiàng)目迭代為周期，做為一個(gè)迭代的項(xiàng)目負(fù)責(zé)人組織開發(fā)工作晋南。
會(huì)議主題：總結(jié)復(fù)盤本次開發(fā)中的經(jīng)驗(yàn)和需要改進(jìn)的地方惠猿。
參與人員：產(chǎn)品經(jīng)理、UI設(shè)計(jì)负间、移動(dòng)端開發(fā)（Android偶妖、iOS開發(fā)姜凄、H5開發(fā)）、服務(wù)器開發(fā)餐屎、團(tuán)隊(duì)負(fù)責(zé)人檀葛、擔(dān)任本次的SM。
以下是對(duì)最近一次迭代開發(fā)任務(wù)做一次總結(jié)復(fù)盤腹缩。
3.1.關(guān)于PM
開發(fā)任務(wù)需求及開發(fā)時(shí)間的確定
開發(fā)任務(wù)需求一般來源于市場(chǎng)或上級(jí)Boss屿聋。角度不同，需求和實(shí)際開發(fā)中的安排也不同藏鹊，上級(jí)希望多润讥、快、好盘寡、省楚殿，盡快看到產(chǎn)品實(shí)現(xiàn)。而實(shí)際開發(fā)落地得根據(jù)目前的開發(fā)情況來定竿痰，此時(shí)對(duì)上級(jí)的需求PM需要好好評(píng)估脆粥，可以對(duì)需求分階段拆解，首先滿足主要需求影涉，突出產(chǎn)品特色变隔，對(duì)一些現(xiàn)階段不是很重要的開發(fā)任務(wù)可以放到二三階段，對(duì)上級(jí)溝通時(shí)要表達(dá)出對(duì)未來產(chǎn)品的規(guī)劃蟹倾，先實(shí)現(xiàn)主流需求匣缘，即先搭建產(chǎn)品體系，再完善細(xì)節(jié)鲜棠，一步步穩(wěn)步推進(jìn)肌厨。PM要抗住壓力，根據(jù)公司實(shí)際情況來合理與上級(jí)溝通豁陆。
需求盡量詳盡柑爸，增加交互設(shè)計(jì)；
需求詳細(xì)的同時(shí)盒音，不要過度設(shè)計(jì)竖配，簡(jiǎn)單功能復(fù)雜化，細(xì)節(jié)和需求做到均衡里逆，時(shí)間允許的情況下进胯，做出高保真原型設(shè)計(jì)及交互設(shè)計(jì)。
以User Story（用戶故事）為單位輸出PRD原押；
產(chǎn)品需求最好以故事用例來體現(xiàn)胁镐，方便用戶、開發(fā)團(tuán)隊(duì)理解，讓開發(fā)人員到底要做啥盯漂。
需求評(píng)審前至少提前4小時(shí)將PRD發(fā)給項(xiàng)目組提前查閱颇玷，期間與項(xiàng)目組成員溝通完成答疑；
評(píng)審會(huì)議鼓勵(lì)大家多提問就缆，對(duì)于疑問點(diǎn)一定要有結(jié)論（無爭(zhēng)議或確定最終回復(fù)時(shí)間）帖渠。
3.2.關(guān)于UI設(shè)計(jì)
如果開發(fā)時(shí)間充分，可添加設(shè)計(jì)交互設(shè)計(jì)竭宰，這個(gè)也可以是產(chǎn)品需求階段實(shí)現(xiàn)空郊，做一個(gè)高保真的交互設(shè)計(jì)。
另外關(guān)于視覺呈現(xiàn)和需求的平衡切揭，允許有調(diào)整的地方狞甚，如果在實(shí)現(xiàn)某一個(gè)功能上，在時(shí)間和開發(fā)資源消耗過多的情況下廓旬，不一定要堅(jiān)持按UI設(shè)計(jì)效果實(shí)現(xiàn)哼审，希望能適當(dāng)兼顧開發(fā)人員的開發(fā)習(xí)慣，如兼顧Android和iOS 開發(fā)設(shè)計(jì)規(guī)范和用戶正常的使用習(xí)慣孕豹，不過度在一個(gè)簡(jiǎn)單的小功能上過度創(chuàng)新涩盾。
關(guān)于移動(dòng)端Android端的設(shè)計(jì)規(guī)范不在此展開討論，如大家有疑問可在文末留言討論励背。
3.3.關(guān)于服務(wù)器后端開發(fā)人員
團(tuán)隊(duì)開發(fā)中春霍，前端和后端 同步 開發(fā)，不可避免會(huì)出現(xiàn)服務(wù)器崩潰的問題椅野，一般由于服務(wù)器要時(shí)常部署重啟所致终畅。
另一原因籍胯，由于服務(wù)器的內(nèi)存不足等原因竟闪，幾個(gè)項(xiàng)目的內(nèi)存占有率太多，無法及時(shí)釋放杖狼，所以開發(fā)中炼蛤，服務(wù)器時(shí)常崩潰無響應(yīng)。
解決辦法：
根據(jù)公司需求及實(shí)際情況蝶涩，適當(dāng)增加服務(wù)器存儲(chǔ)空間;
開發(fā)中理朋，經(jīng)常檢測(cè)服務(wù)器是否崩潰，及時(shí)重啟绿聘，同時(shí)在開發(fā)中告知開發(fā)人員嗽上，服務(wù)器要重啟，保持信息同步熄攘。
開發(fā)中為了保持信息同步兽愤，可以這樣做：
后端人員在必要的停服時(shí)刻，需要口頭通知前端開發(fā)人員;
后端服務(wù)開發(fā)同學(xué)，必須保證服務(wù)掛掉可以自動(dòng)重啟浅萧，比如逐沙，使用 supervisor 進(jìn)程管理；
后端服務(wù)開發(fā)環(huán)境實(shí)現(xiàn) CI（持續(xù)集成）洼畅，即：當(dāng)某個(gè) feature 提交后吩案，即可自動(dòng)重新編譯并 supervisor 運(yùn)行;
3.4.關(guān)于移動(dòng)端開發(fā)
開發(fā)人員之間要互看代碼Code Review,行成良好的代碼風(fēng)格。相互學(xué)習(xí)帝簇，共同進(jìn)步徘郭。
iOS和Android發(fā)現(xiàn)兩端的差異性后，應(yīng)及早提出并統(tǒng)一己儒；
3.5.關(guān)于測(cè)試
測(cè)試人員崎岂，在tapd的缺陷創(chuàng)建時(shí)，必須與需求進(jìn)行關(guān)聯(lián)闪湾；
先發(fā)送“提測(cè)郵件”冲甘，再正式進(jìn)行測(cè)試，提測(cè)郵件也需發(fā)送給產(chǎn)品和UI途样，并提醒他們驗(yàn)收江醇。
測(cè)試時(shí)，除了功能測(cè)試何暇，UI測(cè)試也得同步進(jìn)行陶夜，開發(fā)該Bug的同時(shí)也把UI細(xì)節(jié)優(yōu)化了。
測(cè)試用例
測(cè)試驅(qū)動(dòng)開發(fā)裆站，需求評(píng)審?fù)ㄟ^后条辟，測(cè)試用例應(yīng)該及時(shí)編寫出來，盡早進(jìn)行測(cè)試用例評(píng)審宏胯，這樣可以及時(shí)消除大家對(duì)需求理解上的偏差羽嫡，這個(gè)環(huán)節(jié)其實(shí)很重要，大家往往容易忽略肩袍，一個(gè)合格的測(cè)試人員不僅僅是簡(jiǎn)單的進(jìn)行功能測(cè)試杭棵，開發(fā)之初的測(cè)試用例建立有助于開發(fā)團(tuán)隊(duì)保持信息同步，盡早發(fā)現(xiàn)需求背后的問題氛赐，盡早解決魂爪，問題越到最后，解決越耗時(shí)艰管，還會(huì)影響項(xiàng)目進(jìn)度滓侍。
舉個(gè)栗子，測(cè)試人員根據(jù)產(chǎn)品需求整理了一個(gè)測(cè)試用例牲芋，以思維導(dǎo)圖形式呈現(xiàn)效果撩笆，如下圖所示：
小結(jié)：及時(shí)建立測(cè)試用例尔破，盡早評(píng)審，保持信息同步浇衬。
3.6.關(guān)于驗(yàn)收
測(cè)試收尾階段懒构，PM及時(shí)驗(yàn)收，反饋產(chǎn)品的使用問題耘擂。細(xì)節(jié)問題交給測(cè)試人員跟進(jìn)胆剧。
3.7 關(guān)于SM
SM需要單獨(dú)創(chuàng)建迭代版本，組織技術(shù)評(píng)審會(huì)議（排期）醉冤，盡量以Story為單位設(shè)置任務(wù)點(diǎn)秩霍，大家一起創(chuàng)建任務(wù)清單，推動(dòng)大家完成任務(wù)評(píng)估并提前設(shè)置好起止時(shí)間蚁阳；工期與公司要求沖突的铃绒，反饋給PM，商討應(yīng)對(duì)方案（趕工螺捐、延期颠悬、縮減需求范圍）；
SM組織每日站立會(huì)定血，建議提前5分鐘通知大家思考下會(huì)議發(fā)言內(nèi)容赔癌，會(huì)議期間輪流發(fā)言（期間不要打斷，發(fā)言完成后再提問）澜沟；結(jié)合tapd故事墻（看板）進(jìn)行例會(huì)灾票；幫助大家養(yǎng)成及時(shí)關(guān)閉任務(wù)的習(xí)慣；
SM是上帝視角茫虽，是組織者刊苍，不要做裁判；充分調(diào)用項(xiàng)目全員的參與度濒析，鼓勵(lì)大家積極發(fā)言正什，尤其是偏內(nèi)向、習(xí)慣被動(dòng)溝通的同事悼枢；
SM要做好周知工作埠忘，讓項(xiàng)目相關(guān)方（業(yè)務(wù)脾拆、PM馒索、團(tuán)隊(duì)內(nèi)部）充分了解本次迭代的上線時(shí)間、期間進(jìn)度名船、風(fēng)險(xiǎn)绰上。
如果沒有和團(tuán)隊(duì)商議，請(qǐng)不要代表團(tuán)隊(duì)做任何承諾渠驼。哪怕是一個(gè)很小的需求變更蜈块，都需要和團(tuán)隊(duì)溝通后確定。
時(shí)間管理：管理和開發(fā)時(shí)間的平衡建議三七分，管理工作比較繁瑣百揭，會(huì)消耗大量碎片化時(shí)間爽哎，因此在開發(fā)任務(wù)中不要分配優(yōu)先級(jí)過高的任務(wù)給SM。
4.關(guān)于協(xié)同管理工具的使用
4.1 tpad
PM任務(wù)的在tpad建立和分配
任務(wù)建立時(shí) 可以按功能模塊劃分器一，先建立功能點(diǎn)课锌，在功能點(diǎn)下建立二級(jí)子需求，分別建立如Android祈秕、iOS端渺贤、服務(wù)器端開發(fā)子需求，這樣做 方便建立關(guān)聯(lián)任務(wù)请毛，及時(shí)追蹤任務(wù)進(jìn)度志鞍。
舉個(gè)栗子：
在''里程及保養(yǎng)信息'功能點(diǎn)中建立三端(Android、iOS方仿、服務(wù)器網(wǎng)關(guān)端)的開發(fā)任務(wù)固棚，關(guān)聯(lián)同一個(gè)任務(wù)。
開發(fā)人員的任務(wù)認(rèn)領(lǐng)仙蚜、時(shí)間評(píng)估與開發(fā)中的狀態(tài)更新
開發(fā)人員認(rèn)領(lǐng)任務(wù)后玻孟，及時(shí)變更開發(fā)人員，評(píng)估開發(fā)時(shí)間鳍征，開發(fā)中及時(shí)更新任務(wù)狀態(tài)
關(guān)于開發(fā)任務(wù)時(shí)間的評(píng)估
需求評(píng)審進(jìn)行前黍翎，可以先將PRD發(fā)出來，進(jìn)行技術(shù)調(diào)研艳丛，方案選擇匣掸，在評(píng)審時(shí)評(píng)估時(shí)間更準(zhǔn)確。
4.2 藍(lán)湖
藍(lán)湖,PM喜歡用的產(chǎn)品原型設(shè)計(jì)協(xié)作平臺(tái)之一氮双，需求變更時(shí) 會(huì) 及時(shí)在線同步更新碰酝。
4.3 磨刀
磨刀，UI喜歡用的產(chǎn)品設(shè)計(jì)協(xié)作平臺(tái)之一戴差，UI 變更時(shí)會(huì)及時(shí)在線同步更新送爸。同時(shí)也支持在上面標(biāo)注 ，方便開發(fā)人員查看開發(fā)中用到的UI細(xì)節(jié)暖释， 如用到的顏色值袭厂、距離，以及交互細(xì)節(jié)等等球匕。
Tips:目前移動(dòng)端用的這就這個(gè)平臺(tái)協(xié)同開發(fā)纹磺，設(shè)計(jì)稿以iOS的尺寸 375x1334尺寸，一稿兩用亮曹，支持Android和iOS平臺(tái)橄杨，以單位px標(biāo)注單位秘症。
5.關(guān)于項(xiàng)目組溝通
溝通會(huì)一直貫穿整個(gè)開發(fā)周期，在時(shí)間緊式矫，任務(wù)重的情況下乡摹，如何有效溝通 是整個(gè)團(tuán)隊(duì)都需要持續(xù)精進(jìn)的地方。
1.關(guān)于需求的溝通
需求任務(wù)發(fā)起之初采转，以郵件趟卸、在線電子文檔，如 Web離線查看文件和Axure原始文檔查看PRD(產(chǎn)品需求說明書文檔)氏义。在正式召開需求評(píng)審前前锄列，項(xiàng)目組最好能提前看下相關(guān)文檔，有疑問盡早記下來惯悠，需求評(píng)審中如果涉及到的信息比較多邻邮，會(huì)議時(shí)間長(zhǎng) 往往會(huì)忽略很多細(xì)節(jié)，所以在需求評(píng)審中鼓勵(lì)大家一定要集中精力并對(duì)需求盡可能刨根問底克婶，對(duì)于疑問點(diǎn)一定要有結(jié)論（無爭(zhēng)議或確定最終回復(fù)時(shí)間）筒严，否則在開發(fā)過程中，遇到問題再來討論調(diào)整會(huì)耽誤的時(shí)間更多情萤。反觀以前的開發(fā)迭代鸭蛙，因需求的復(fù)雜程度不同，有爭(zhēng)議不可避免筋岛，我們只能在開發(fā)中多磨合盡量減少娶视。
2.關(guān)于開發(fā)中的每日站例會(huì)
早會(huì)的目的 不要拘泥于形式，不僅僅簡(jiǎn)單匯報(bào)一下Done睁宰、Doing肪获、To Do。 除了匯報(bào)當(dāng)前自己的開發(fā)任務(wù)與進(jìn)度外柒傻，有問題最好及時(shí)拋出來孝赫，此時(shí)SM會(huì)協(xié)調(diào)推動(dòng)，保證項(xiàng)目按進(jìn)度走红符。
早會(huì)召開前后青柄，及時(shí)同步更新tapd的狀態(tài)。
3.開發(fā)中的溝通
開發(fā)期間遇到的問題需要PM答疑或者涉及到需求改動(dòng)的點(diǎn)预侯，一定要在tapd留痕并@相關(guān)人致开，做到信息同步，避免只做口頭溝通雌桑、避免只有部分人了解需求變更喇喉；
建議SM確定一個(gè)溝通頻次祖今，例如每隔50分鐘與上下游進(jìn)行討論校坑，50分鐘內(nèi)做開發(fā)與記錄問題拣技，避免頻繁打斷相關(guān)人的開發(fā)思路；
如果不能做到按功能點(diǎn)交付測(cè)試耍目，那么在集中提測(cè)階段膏斤，建議每日兩次站立會(huì)赫冬，提升bug修復(fù)效率朝巫。
4.關(guān)于加班時(shí)溝通
如前端任務(wù)重時(shí)需要加班，而服務(wù)器開發(fā)人員工作不重時(shí) 下班就收工了结啼。這時(shí)前端開發(fā)人員有服務(wù)器方面的問題時(shí)毅访，往往得不到及時(shí)響應(yīng)沮榜，所以服務(wù)器開發(fā)人員最好能留一個(gè)能及時(shí)響應(yīng)，此時(shí)開發(fā)人員喻粹，可以留下來學(xué)習(xí)或者打游戲都是允許的蟆融，只要能及時(shí)響應(yīng)前端開發(fā)人員聯(lián)調(diào)服務(wù)器，保持一個(gè)良好的開發(fā)氛圍很重要守呜。
6.關(guān)于團(tuán)隊(duì)開發(fā)小結(jié)
1.各個(gè)開發(fā)人員型酥，關(guān)注好開發(fā)的上下游，及時(shí)主動(dòng)告知項(xiàng)目情況查乒，注重交流的專業(yè)性和效率性弥喉。
2.擁有產(chǎn)品思維，站在用戶角度考慮問題玛迄，及可能全面由境，有問題及時(shí)提出，大家共同解決蓖议。
以上藻肄，是關(guān)于SM職責(zé)的思考和Sprint Review中的總結(jié)思考，希望對(duì)你有所幫助拒担。如有疑問嘹屯，歡迎大家留言討論。
參考資料：
1.啥是Design Sprint設(shè)計(jì)沖刺?
2.敏捷開發(fā)：做一個(gè)合格的Scrum Master
