篇首語(yǔ)：個(gè)人技術(shù)再高，不懂得團(tuán)隊(duì)管理是白搭繁疤；管理理念再先進(jìn)诗轻，沒(méi)有在一線技術(shù)崗位奮斗過(guò)贮聂，也是白搭。

這篇文章主要分為三部分：

1.移動(dòng)團(tuán)隊(duì)架構(gòu)設(shè)計(jì)

2.敏捷開發(fā)流程優(yōu)化

3.團(tuán)隊(duì)實(shí)踐Tips

懇請(qǐng)各位技術(shù)大咖和管理大師批評(píng)拍磚认臊，感激不盡圃庭。

一、移動(dòng)團(tuán)隊(duì)架構(gòu)設(shè)計(jì)

1. 團(tuán)隊(duì)構(gòu)成

一個(gè)完整的移動(dòng)團(tuán)隊(duì)包含四個(gè)部分，團(tuán)隊(duì)Leader（項(xiàng)目經(jīng)理）剧腻、產(chǎn)品團(tuán)隊(duì)拘央、開發(fā)團(tuán)隊(duì)、測(cè)試團(tuán)隊(duì)书在。

1.1產(chǎn)品團(tuán)隊(duì)

產(chǎn)品團(tuán)隊(duì)的主要精力始終應(yīng)當(dāng)聚焦于需求灰伟，聚焦于產(chǎn)品本身。而非測(cè)試儒旬、進(jìn)度管控栏账、質(zhì)量管控等。
產(chǎn)品團(tuán)隊(duì)在整個(gè)隊(duì)伍中的工作職責(zé)包括：
（1）明晰需求和交互邏輯栈源，并且有效地傳達(dá)至開發(fā)團(tuán)隊(duì)和測(cè)試團(tuán)隊(duì)挡爵。每天跟進(jìn)開發(fā)人員，掌控哪些需求是“技術(shù)不友好”的甚垦，是否需要調(diào)整邏輯茶鹃。關(guān)鍵詞，每天艰亮，謹(jǐn)防到了發(fā)版前幾天才驚覺(jué)需求存在邏輯問(wèn)題或者開發(fā)人員做出了并非產(chǎn)品團(tuán)隊(duì)想要的東西闭翩。
（2）處理需求Bug。這里著重說(shuō)明是需求類Bug垃杖，而非承擔(dān)測(cè)試工作或處理其他類Bug男杈。測(cè)試團(tuán)隊(duì)提出的Bug，經(jīng)過(guò)開發(fā)人員分析后调俘，如果是產(chǎn)品需求類的Bug伶棒，產(chǎn)品團(tuán)隊(duì)需要分析Bug，決定是否需要重新定義業(yè)務(wù)邏輯彩库。
（3）需求評(píng)審肤无，制定交互設(shè)計(jì)規(guī)范和UI規(guī)范。
（4）需求驗(yàn)收骇钦。開發(fā)完成宛渐，測(cè)試接近尾聲后，驗(yàn)證最終的開發(fā)功能是否與需求一致眯搭。
（5）發(fā)版驗(yàn)收窥翩。根據(jù)本次迭代的需求清單、Bug清單以及開發(fā)和測(cè)試團(tuán)隊(duì)的反饋鳞仙，決定是否發(fā)版寇蚊，如果存在需求問(wèn)題或嚴(yán)重Bug問(wèn)題，則需要提議延遲發(fā)版棍好。

1.2測(cè)試團(tuán)隊(duì)

為什么需要單獨(dú)的測(cè)試團(tuán)隊(duì)仗岸？
（1）不可以過(guò)多依賴開發(fā)人員自測(cè)允耿。開發(fā)人員自測(cè)很多時(shí)候是根據(jù)自己編碼的邏輯測(cè)試，需要測(cè)試人員從其他角度發(fā)現(xiàn)問(wèn)題扒怖。
（2）不可以依賴產(chǎn)品經(jīng)理進(jìn)行測(cè)試较锡。產(chǎn)品經(jīng)理應(yīng)當(dāng)更多關(guān)注頁(yè)面轉(zhuǎn)化率、用戶體驗(yàn)盗痒、交互邏輯等產(chǎn)品本身的特性蚂蕴，而且測(cè)試非其專長(zhǎng)，測(cè)試人員的測(cè)試用例才是測(cè)試依據(jù)积糯。
（3）需要測(cè)試團(tuán)隊(duì)高關(guān)注Bug掂墓。測(cè)試團(tuán)隊(duì)可以第一時(shí)間驗(yàn)收發(fā)現(xiàn)Bug的修復(fù)情況谦纱，確保發(fā)版前已發(fā)現(xiàn)Bug修復(fù)完善看成。
一個(gè)移動(dòng)開發(fā)團(tuán)隊(duì)開發(fā)與測(cè)試的建議比例為6:1，2個(gè)Android開發(fā)跨嘉，2個(gè)IOS開發(fā)川慌，2個(gè)MobileAPI開發(fā)，1個(gè)測(cè)試祠乃。測(cè)試人員在團(tuán)隊(duì)中的工作職責(zé)應(yīng)當(dāng)包括：
（1）需求（二次）評(píng)審（測(cè)試用例評(píng)審）梦重。產(chǎn)品經(jīng)理、開發(fā)團(tuán)隊(duì)亮瓷、測(cè)試團(tuán)隊(duì)?wèi)?yīng)對(duì)需求達(dá)成一致琴拧。
（2）手動(dòng)測(cè)試，包括正常用戶邏輯操作測(cè)試與非邏輯測(cè)試嘱支，如邊界條件下的測(cè)試蚓胸。
（3）全功能回歸測(cè)試、探索測(cè)試除师、渠道包測(cè)試沛膳、MobileAPI測(cè)試、壓力測(cè)試汛聚、Monkey測(cè)試锹安。
（4）用戶Bug反饋及投訴跟進(jìn)及處理。
當(dāng)測(cè)試資源不足倚舀，應(yīng)該提議那些未經(jīng)完全測(cè)試的功能不要上線叹哭，為團(tuán)隊(duì)明確本次發(fā)版的風(fēng)險(xiǎn)，要么延期發(fā)版痕貌，要么暫且砍掉未完全測(cè)試功能风罩，禁止帶著嚴(yán)重Bug發(fā)版。

1.3開發(fā)團(tuán)隊(duì)

開發(fā)團(tuán)隊(duì)是互聯(lián)網(wǎng)團(tuán)隊(duì)存在的基石芯侥。這里不累述泊交。開發(fā)團(tuán)隊(duì)最忌諱的幾點(diǎn)乳讥，希望其他團(tuán)隊(duì)留意：
（1）一句話需求。一句話需求讓老子如何開發(fā)廓俭，自由發(fā)揮嗎云石？
（2）產(chǎn)品需求頻繁變動(dòng)。再變需求試試研乒，信不信老子明天帶刀上班汹忠？
（3）產(chǎn)品團(tuán)隊(duì)業(yè)務(wù)邏輯不清晰。不能做就滾蛋雹熬，工資給我宽菜，老子又干產(chǎn)品又干開發(fā)！
（4）UI設(shè)計(jì)圖標(biāo)注不清晰竿报。設(shè)計(jì)圖不標(biāo)注铅乡，到時(shí)候UI驗(yàn)收的時(shí)候，就別給老子逼逼屏幕適配不當(dāng)?shù)膯?wèn)題烈菌！

1.4團(tuán)隊(duì)Leader（項(xiàng)目經(jīng)理）

項(xiàng)目經(jīng)理不需要關(guān)心具體技術(shù)實(shí)現(xiàn)阵幸，只需要清楚業(yè)務(wù)總體邏輯和項(xiàng)目進(jìn)度。同時(shí)芽世，項(xiàng)目經(jīng)理對(duì)團(tuán)隊(duì)是否高效有直接影響挚赊。項(xiàng)目經(jīng)理的工作職責(zé)包括：

（1）制定開發(fā)計(jì)劃與測(cè)試計(jì)劃，如果開發(fā)團(tuán)隊(duì)和測(cè)試團(tuán)隊(duì)沒(méi)有Leader济瓢，也需要分配開發(fā)任務(wù)和測(cè)試任務(wù)荠割。協(xié)調(diào)產(chǎn)品團(tuán)隊(duì)、開發(fā)團(tuán)隊(duì)旺矾、測(cè)試團(tuán)隊(duì)蔑鹦，盡可能安排進(jìn)更多的需求。每次迭代初期宠漩，項(xiàng)目經(jīng)理需要完成的任務(wù)計(jì)劃包括：

• 需求名稱
• 產(chǎn)品經(jīng)理
• 需求描述
• UI人員
• 基礎(chǔ)UI提供時(shí)間
• 后續(xù)UI提供計(jì)劃
• MobileAPI開發(fā)
• MoblieAPI聯(lián)調(diào)時(shí)間點(diǎn)
• Androd開發(fā)人員
• Android開發(fā)周期
• Android關(guān)鍵時(shí)間點(diǎn)及任務(wù)
• IOS開發(fā)人員
• IOS開發(fā)周期
• IOS關(guān)鍵時(shí)間點(diǎn)及任務(wù)
• 測(cè)試人員
• 測(cè)試周期
• 測(cè)試關(guān)鍵時(shí)間點(diǎn)及任務(wù)

（2）根據(jù)項(xiàng)目風(fēng)險(xiǎn)举反，及時(shí)調(diào)整計(jì)劃，并著重解決產(chǎn)品扒吁、開發(fā)火鼻、測(cè)試三個(gè)方面存在的瓶頸問(wèn)題。記錄項(xiàng)目每個(gè)需求的時(shí)間軸雕崩，按照敏捷開發(fā)流程魁索，會(huì)有如下幾個(gè)階段：

• BackLog：代辦
• Doing：正在開發(fā)中
• CC：開發(fā)完成，等待測(cè)試
• Testing：測(cè)試中
• Done：測(cè)試完成

（3）監(jiān)督產(chǎn)品團(tuán)隊(duì)盼铁、開發(fā)團(tuán)隊(duì)粗蔚、測(cè)試團(tuán)隊(duì)工作職責(zé)的履行及工期計(jì)劃的合規(guī)情況。

（4）項(xiàng)目完工后主持總結(jié)會(huì)議饶火，去偽存真鹏控。

2.架構(gòu)設(shè)計(jì)

2.1兩種模式

移動(dòng)團(tuán)隊(duì)的開發(fā)團(tuán)隊(duì)包括Android致扯、IOS和MobileAPI三個(gè)團(tuán)隊(duì)組成，主要有兩種架構(gòu)模式：平行模式和垂直模式当辐。
平行模式：即Android抖僵、IOS、MobileAPI團(tuán)隊(duì)各自作為獨(dú)立團(tuán)隊(duì)缘揪。項(xiàng)目初期耍群，團(tuán)隊(duì)約定好MobileAPI接口格式和聯(lián)調(diào)時(shí)間，就可以各自開工找筝，到了聯(lián)調(diào)時(shí)間蹈垢，進(jìn)行集成測(cè)試。產(chǎn)品團(tuán)隊(duì)與測(cè)試團(tuán)隊(duì)也保持獨(dú)立袖裕。
垂直模式：按照模塊曹抬，拆分團(tuán)隊(duì)。如將教育APP拆分成題庫(kù)模塊陆赋、課程模塊沐祷、直播模塊等嚷闭，每個(gè)模塊配置一個(gè)小團(tuán)隊(duì)攒岛，包含Android、IOS胞锰、MobileAPI等更小的團(tuán)隊(duì)灾锯。同時(shí)將產(chǎn)品團(tuán)隊(duì)和測(cè)試團(tuán)隊(duì)也進(jìn)行拆分，分配到每個(gè)模塊中嗅榕。
對(duì)比兩種模式顺饮，進(jìn)行利弊分析：
（1）需要根據(jù)團(tuán)隊(duì)規(guī)模決定采取哪種模式。團(tuán)隊(duì)沒(méi)有成規(guī)模之前凌那，不宜拆分兼雄，應(yīng)當(dāng)采用平行模式。垂直模式有助于每個(gè)模塊的成員專注于自己的業(yè)務(wù)模塊帽蝶，提高開發(fā)效率赦肋，但是一旦發(fā)生人員流動(dòng)，就需要有新成員加入励稳，其熟悉業(yè)務(wù)模塊開始到實(shí)際產(chǎn)生開發(fā)能力為止佃乘，需要時(shí)間周期長(zhǎng)，對(duì)于小團(tuán)隊(duì)而言驹尼，反而降低了效率趣避。
（2）大團(tuán)隊(duì)也不是采取垂直模式就一定能提高效率，需要看團(tuán)隊(duì)的主要工作偏向新翎。當(dāng)團(tuán)隊(duì)主要處于開發(fā)階段程帕，采用垂直模式有助于提高開發(fā)效率住练。但是當(dāng)團(tuán)隊(duì)主要處于重構(gòu)階段，就會(huì)產(chǎn)生問(wèn)題愁拭。當(dāng)計(jì)劃重構(gòu)項(xiàng)目的時(shí)候澎羞，每個(gè)模塊的進(jìn)度不一致，有的有時(shí)間重構(gòu)敛苇，有的在做需求妆绞，有的在測(cè)試，很難推行重構(gòu)枫攀。
（3）總而言之括饶，短期看，小團(tuán)隊(duì)采用平行模式優(yōu)勢(shì)比較大来涨。從長(zhǎng)期看图焰，隨著業(yè)務(wù)規(guī)模擴(kuò)大，按模塊拆分小團(tuán)隊(duì)蹦掐，小團(tuán)隊(duì)內(nèi)根據(jù)工作內(nèi)容再拆分更小團(tuán)隊(duì)的垂直模式是大勢(shì)所趨技羔。

對(duì)于團(tuán)隊(duì)領(lǐng)導(dǎo)而言，管理寬度不是越廣越好卧抗，超過(guò)6人會(huì)帶來(lái)管理效率的極大降低藤滥。

2.2垂直模式的模塊化分工

任何一個(gè)企業(yè)級(jí)App，都會(huì)包含很多模塊社裆。一旦團(tuán)隊(duì)滿足垂直模式變革的要求拙绊，就要逐漸轉(zhuǎn)變?yōu)榇怪蹦Ｊ健F(tuán)隊(duì)Leader要確保每一個(gè)模塊都有1-2個(gè)開發(fā)人員非常熟悉它的業(yè)務(wù)邏輯泳秀，長(zhǎng)時(shí)間在該模塊開發(fā)和維護(hù)标沪。被分配到某個(gè)模塊開發(fā)的開發(fā)人員，在熟悉該模塊業(yè)務(wù)邏輯的前提下嗜傅，還要清晰知道這個(gè)模塊包含哪些View（Activity、Fragment）违寞、Model（Bean坞靶、Entity）蝴悉、Controller（Adapter）拍冠。當(dāng)然簇抵，在模塊化分工的時(shí)候碟摆，有一些Tips：

（1）用戶中心典蜕。這種模塊包含個(gè)人信息愉舔、訂單伙菜、錢包贩绕、操作記錄淑倾、系統(tǒng)消息、積分等零零碎碎的功能假瞬，通常沒(méi)有太多技術(shù)含量，而且繁瑣剪芥。最好安排技術(shù)實(shí)力一般溉躲、吃苦耐勞的程序員，也適合新人了解項(xiàng)目時(shí)安排的模塊锻梳。

（2）核心業(yè)務(wù)模塊疑枯。這里應(yīng)當(dāng)匹配最多的資源荆永，同時(shí)準(zhǔn)備預(yù)備人員可以調(diào)動(dòng)。通常每次迭代核心業(yè)務(wù)模塊需求增加最多豆村，需要最踏實(shí)勤奮的開發(fā)人員（勤奮老牛）掌动，同時(shí)線上每次出現(xiàn)問(wèn)題都能及時(shí)處理坏匪，有一定的加班強(qiáng)度适滓。

（3）實(shí)驗(yàn)性模塊凭迹。這個(gè)模塊是公司最先進(jìn)的技術(shù)實(shí)力的提現(xiàn)苦囱，需要那些技術(shù)實(shí)力最強(qiáng)撕彤，探索欲望同樣強(qiáng)烈的人羹铅，也可以滿足他們內(nèi)心自我實(shí)現(xiàn)的需求。

二职员、敏捷開發(fā)流程

敏捷迭代中的敏捷的含義就是按時(shí)交付扮授，不斷調(diào)整策略专肪，即時(shí)開發(fā)并發(fā)布嚎尤，做到資源利用率最大化。理想中的最佳情況是雹拄，隨時(shí)開發(fā)測(cè)試完成滓玖，隨時(shí)提交到線上势篡，而不借助發(fā)版禁悠，這就需要用到插件化編程和腳本編程碍侦，這是龐大的課題隶糕，如果技術(shù)強(qiáng)大到可以實(shí)現(xiàn)枚驻，就不會(huì)有迭代周期這個(gè)概念了尔邓。
通常情況下我們沒(méi)有這個(gè)技術(shù)實(shí)力梯嗽，兩行哥也沒(méi)有沈撞，所以繼續(xù)聊聊迭代周期的事缠俺。常見(jiàn)的開發(fā)迭代周期有四周和兩周壹士，App迭代更新躏救，修復(fù)線上Bug盒使，增加新功能少办，不僅能提高用戶體驗(yàn)英妓，還能增加App在用戶面前的曝光度蔓纠。一個(gè)完整的迭代周期內(nèi)需要完成的工作包括：需求準(zhǔn)備、工期安排纯出、需求開發(fā)敷燎、內(nèi)測(cè)群測(cè)暂筝、版本發(fā)布。

1.四周迭代的節(jié)奏

1.1第一周

四周的第一周主要是用于修復(fù)上版Bug懈叹、需求準(zhǔn)備乖杠、工期安排，說(shuō)明如下：
（1）總結(jié)上次迭代出現(xiàn)的問(wèn)題澄成，同時(shí)修復(fù)上個(gè)版本遺留的Bug以及上個(gè)版本線上發(fā)現(xiàn)的Bug胧洒。之所以上版本遺留Bug，是因?yàn)樯蟼€(gè)迭代周期可能由于工期不足未能修復(fù)墨状，或者為了防止修復(fù)此Bug造成更加嚴(yán)重的隱患卫漫，所以留到下次迭代來(lái)處理。
Tips：如果上期迭代發(fā)現(xiàn)了重大Bug列赎，需要立刻停止其他需求的開發(fā)源葫，全力修復(fù)Bug并立刻上線块促。上線完成后薇搁，應(yīng)當(dāng)調(diào)整本期迭代需求，適當(dāng)減少新需求，防止本期迭代工期不足僻澎。不到萬(wàn)不得已秉氧，不要版本回退作媚。
（2）盡可能做一些代碼重構(gòu)。根據(jù)包式法則，產(chǎn)品需求永遠(yuǎn)為最高優(yōu)先級(jí)任務(wù)目標(biāo)掩驱，完成需求之后剩余的時(shí)間才可以進(jìn)行代碼優(yōu)化及重構(gòu)。而且代碼重構(gòu)放在每個(gè)迭代周期第一周來(lái)做，主要是保證穩(wěn)定性，留有長(zhǎng)達(dá)三周的時(shí)間去修復(fù)及驗(yàn)證重構(gòu)后帶來(lái)的隱藏問(wèn)題俊犯。
（3）產(chǎn)品團(tuán)隊(duì)在開發(fā)和測(cè)試團(tuán)隊(duì)做上述兩點(diǎn)的同時(shí)绢彤，可以準(zhǔn)備初步的需求文檔饶氏。一旦需求文檔到位皮仁，整個(gè)開發(fā)團(tuán)隊(duì)可以共同參加需求確認(rèn)會(huì)势誊，將需求劃分至具體開發(fā)人員和測(cè)試人員，工期評(píng)估也同時(shí)進(jìn)行册烈。如果測(cè)試資源不足，那就需要砍掉一些需求窑滞，確保上線的功能都是經(jīng)過(guò)足夠測(cè)試的此改。
（4）工期評(píng)估完成后共啃，需要著手解決App開發(fā)會(huì)原型圖占调、MobileAPI的依賴。UI團(tuán)隊(duì)和MobileAPI團(tuán)隊(duì)可以先行一步移剪。條件允許的話纵苛，UI團(tuán)隊(duì)和MobileAPI團(tuán)隊(duì)?wèi)?yīng)當(dāng)比App開發(fā)團(tuán)隊(duì)優(yōu)先一個(gè)迭代周期怀吻，避免App和MobileAPI開發(fā)并行的風(fēng)險(xiǎn)。如果MobileAPI進(jìn)度落后，可以暫時(shí)提供假數(shù)據(jù)。

1.2第二周至第三周

這兩周主要全力開發(fā)及測(cè)試踱蠢。隨著需求被一個(gè)一個(gè)開發(fā)完成茎截，測(cè)試工作也隨后開展。第三周周五赶盔，所有需求應(yīng)當(dāng)開發(fā)完畢企锌，就算沒(méi)有開發(fā)完畢，只要核心需求開發(fā)完畢于未，就應(yīng)當(dāng)停止新需求開發(fā)撕攒，剩余需求最好延期至下個(gè)迭代周期，這個(gè)時(shí)間點(diǎn)稱為CodeComplete沉眶。這樣做的目的是為了保證最后一周測(cè)試工期不被耽擱打却。對(duì)于新插入的需求，應(yīng)當(dāng)評(píng)估其緊急程度谎倔，緊急需求列入開發(fā)計(jì)劃柳击，并將原計(jì)劃的需求中非核心需求延期至下一次迭代。測(cè)試團(tuán)隊(duì)的測(cè)試用例評(píng)審應(yīng)當(dāng)在第三周內(nèi)完成片习。

1.3第四周

第四周進(jìn)入全面測(cè)試階段捌肴。開發(fā)人員在前兩天要把高優(yōu)先級(jí)Bug全部修復(fù)蹬叭，確保本周Bug日清。有條件的話状知，測(cè)試團(tuán)隊(duì)可以用腳本跑Monkey秽五，并將Crash日志進(jìn)行分析歸類。周三開始測(cè)試包應(yīng)當(dāng)趨于穩(wěn)定饥悴，所有開發(fā)人員應(yīng)當(dāng)全部參與測(cè)試工作坦喘。同時(shí)，公司內(nèi)部測(cè)試開啟西设，所有公司其他成員參與測(cè)試瓣铣。在公司內(nèi)部測(cè)試前，需要測(cè)試團(tuán)隊(duì)發(fā)布簡(jiǎn)短說(shuō)明贷揽，明確本期迭代新功能棠笑，如何區(qū)分“需求”與“BUG”，Bug提交規(guī)范禽绪。周四晚上CodeFreeze蓖救，周五進(jìn)行全功能回歸測(cè)試。不要指望自動(dòng)化測(cè)試印屁，對(duì)于中小型互聯(lián)網(wǎng)企業(yè)循捺，需求變動(dòng)頻繁，一個(gè)測(cè)試用例往往一個(gè)版本迭代后就廢棄库车，不值得投入大量人力物力去做巨柒。

2.兩周迭代的節(jié)奏

2.1第一周

第一周產(chǎn)品團(tuán)隊(duì)講解需求，分配工作任務(wù)柠衍。周一開發(fā)人員會(huì)比較空閑洋满，用來(lái)修復(fù)線上Bug。周二開始至下周周三共計(jì)7天用于全力開發(fā)與測(cè)試珍坊。所有的需求必須在這7天內(nèi)完成牺勾，MobileAPI聯(lián)調(diào)也需要在此期間完成。測(cè)試團(tuán)隊(duì)需要在本周周四及周五完成測(cè)試用例編寫阵漏。

2.2第二周

開發(fā)及測(cè)試會(huì)持續(xù)到本周周三晚驻民，此時(shí)間節(jié)點(diǎn)CodeComplete，不在增加新需求的代碼履怯。未完成的需求全部推遲至下個(gè)版本迭代回还。周四開始所有測(cè)試人員和開發(fā)人員進(jìn)入測(cè)試階段，Android和IOS交叉測(cè)試叹洲。周四下午產(chǎn)品團(tuán)隊(duì)對(duì)產(chǎn)品進(jìn)行驗(yàn)收柠硕，并且周四開始Bug日清。周五進(jìn)行全功能回歸測(cè)試，當(dāng)天只修復(fù)高優(yōu)先級(jí)Bug蝗柔，其他Bug推遲至下個(gè)版本迭代修復(fù)闻葵。周五晚上封版CodeFreeze。

三癣丧、團(tuán)隊(duì)實(shí)踐Tips

1.讓開發(fā)人員參與測(cè)試

當(dāng)開發(fā)人員完成所有的需求后槽畔，接下的一段時(shí)間的主要工作形式為：測(cè)試人員提出Bug，開發(fā)人員修復(fù)Bug胁编。這段時(shí)間開發(fā)人員相對(duì)比較空閑厢钧，而CodeComplete之后也不應(yīng)當(dāng)安排新的開發(fā)需求。這時(shí)候應(yīng)當(dāng)每天找一段時(shí)間掏呼，將開發(fā)人員集中起來(lái)坏快，將App所有的功能測(cè)試一遍。
A開發(fā)人員測(cè)試B開發(fā)人員完成的功能邏輯憎夷，B開發(fā)人員測(cè)試A開發(fā)人員完成的功能邏輯；Android開發(fā)人員測(cè)試IOS版本的功能昧旨，IOS開發(fā)人員測(cè)試Android版本的功能拾给。對(duì)于找出Bug的成員，獎(jiǎng)勵(lì)一份免費(fèi)晚餐或者晚餐加一根雞腿都可以兔沃。這種做法主要用來(lái)解決測(cè)試資源不足的問(wèn)題及迭代周期中末期開發(fā)人員閑置的問(wèn)題蒋得。

2.靜時(shí)

靜時(shí)是軟件公司術(shù)語(yǔ)。對(duì)于互聯(lián)網(wǎng)公司人員而言乒疏，開發(fā)人員的時(shí)間被嚴(yán)重碎片化额衙，任何人都可以被干擾，其邏輯思路被打斷怕吴。比如線上突然發(fā)現(xiàn)一個(gè)需要修復(fù)的緊急Bug窍侧，比如產(chǎn)品團(tuán)隊(duì)突然提出一個(gè)緊急需求。必須將碎片化的時(shí)間連續(xù)化才能提高效率转绷。
具體的做法是：每周有幾個(gè)下午伟件，產(chǎn)品團(tuán)隊(duì)、開發(fā)團(tuán)隊(duì)议经、測(cè)試團(tuán)隊(duì)關(guān)掉所有通訊方式斧账，包括公司QQ、微信煞肾、線上通訊工具咧织，不在進(jìn)行溝通與交流，全身心投入自己的工作中去籍救。產(chǎn)品團(tuán)隊(duì)习绢、開發(fā)團(tuán)隊(duì)、測(cè)試團(tuán)隊(duì)每個(gè)團(tuán)隊(duì)靜時(shí)的時(shí)間不同钧忽，比如周一下午是產(chǎn)品團(tuán)隊(duì)的靜時(shí)毯炮，周三下午為開發(fā)團(tuán)隊(duì)的靜時(shí)逼肯，周五下午為測(cè)試團(tuán)隊(duì)的靜時(shí)。但是這樣也會(huì)導(dǎo)致其他問(wèn)題桃煎，如果確實(shí)有緊急情況而缺乏專人處理就是比較嚴(yán)重的問(wèn)題篮幢。這時(shí)應(yīng)該由每個(gè)團(tuán)隊(duì)輪流指派1-2名值守人員作為對(duì)外的統(tǒng)一窗口，處理各種情急情況为迈，或?qū)⒕o急情況記錄三椿，靜時(shí)以后再轉(zhuǎn)告專人。每天下午下班前一個(gè)小時(shí)靜時(shí)結(jié)束葫辐，團(tuán)隊(duì)之間恢復(fù)交流搜锰，處理靜時(shí)階段的各種問(wèn)題。最后記得在靜時(shí)實(shí)行前通知其他團(tuán)隊(duì)耿战，如果有緊急事項(xiàng)蛋叼，盡早處理。