概述
? ? ? ? 身處移動(dòng)時(shí)代，移動(dòng)產(chǎn)品競(jìng)爭(zhēng)激烈、功能體驗(yàn)日新月異，不論軟件產(chǎn)品還是硬件產(chǎn)品，產(chǎn)品迭代速度日益加快，從硬件產(chǎn)品而言，即便是卓越如iPhone，也從最開(kāi)始從從容容兩年打磨一個(gè)產(chǎn)品被逼著敏捷至一年（甚至半年）推出一個(gè)新品；而軟件行業(yè)，產(chǎn)品迭代更新速度更快，從古老的年度版本，到現(xiàn)在月度版本甚至雙周周版本，大家都在追求速度致勝、產(chǎn)品快速試錯(cuò)。而所有這一切，都繞不開(kāi)一個(gè)詞——敏捷。
? ? ? ? 其實(shí)敏捷運(yùn)作已經(jīng)談了很多年了，只是理想很豐滿、現(xiàn)實(shí)很骨感?，F(xiàn)階段中國(guó)IT界的主要矛盾就是先進(jìn)的團(tuán)隊(duì)運(yùn)作思想與落后的人員專業(yè)能力之間的矛盾，時(shí)代變化太快，個(gè)人要不斷適應(yīng)技術(shù)、團(tuán)隊(duì)的變化與要求，就需要不斷緊跟時(shí)代步伐、自我提升，而且這種提升不僅需要專業(yè)能力方面的提升，甚至還需要思維意思的轉(zhuǎn)變，說(shuō)實(shí)在話很難、很累！畢竟大部分人終究還是喜歡窩在自己那個(gè)最熟悉的安全區(qū)，悠然度日，不然何為生活呢。
? ? ? ? 扯得有點(diǎn)遠(yuǎn)了，趕緊收回來(lái)——敏捷迭代是個(gè)好東西，能讓產(chǎn)品更快速、更精確地應(yīng)對(duì)用戶需求的變化。但是，正所謂好馬需要好鞍配，先進(jìn)快速的團(tuán)隊(duì)運(yùn)作模式，也需要相應(yīng)強(qiáng)力高效的人員配置才能與之相匹配，才能發(fā)揮其最大價(jià)值。如若不然，產(chǎn)品就會(huì)走上顛簸之路或者偽敏捷之路，前者的體現(xiàn)是敏捷反而會(huì)導(dǎo)致版本穩(wěn)定性下降，后者的表現(xiàn)是在快速版本周期內(nèi)只能做小打小鬧式修改，并不能真正使產(chǎn)品核心功能完成迭代式演進(jìn)、不斷提升產(chǎn)品品質(zhì)。
迭代模型說(shuō)明
? ? ? ? 當(dāng)然，除了角色能力這一關(guān)鍵因素，合適的敏捷運(yùn)作流程也是甚為關(guān)鍵，兩者是相得益彰的，為講清楚這一點(diǎn)，筆者特意將所在產(chǎn)品團(tuán)隊(duì)的敏捷迭代模型規(guī)劃圖貼出來(lái)，以便做針對(duì)性講解。
? ? 圖中要素說(shuō)明：
1、綠色字樣的是整個(gè)團(tuán)隊(duì)的核心里程碑交付節(jié)點(diǎn)；
2、藍(lán)色字樣是各角色各階段工作需完成里程碑節(jié)點(diǎn)；
3、此迭代模型迭代周期為三周，故僅適用于后臺(tái)開(kāi)發(fā)工作量在兩周以內(nèi)的需求，如果后臺(tái)開(kāi)發(fā)周期超過(guò)兩周，建議另起后臺(tái)版本專做后臺(tái)開(kāi)發(fā)，待開(kāi)發(fā)完成后再統(tǒng)一納入前端版本規(guī)劃；
時(shí)點(diǎn)周名稱約定與工作要點(diǎn)說(shuō)明
? ? ? ? 版本按周劃分工作、制定里程碑，按照時(shí)間順序依次命名為前置第一周（后臺(tái)開(kāi)發(fā)與UI設(shè)計(jì)周）、前置第二周（中臺(tái)開(kāi)發(fā)周）、版本第一周（前端開(kāi)發(fā)周）、版本第二周（測(cè)試周）、版本第三周（發(fā)布周）。
? ? ? ? 前置第一周：也叫后臺(tái)開(kāi)發(fā)與UI設(shè)計(jì)周，主要工作是完成全量需求的分析工作與原型開(kāi)發(fā)工作、完成核心需求UI設(shè)計(jì)、完成核心需求的后臺(tái)方案設(shè)計(jì)、完成核心需求后臺(tái)開(kāi)發(fā)、中臺(tái)啟動(dòng)方案設(shè)計(jì)、疑難需求的前端技術(shù)可行性預(yù)研，以及相應(yīng)時(shí)點(diǎn)的需求范圍確定會(huì)、后臺(tái)方案評(píng)審會(huì)等里程碑會(huì)議；
? ? ? ? 前置第二周： 也叫中臺(tái)開(kāi)發(fā)周，主要工作為完成全量UI設(shè)計(jì)稿交付、完成全量后臺(tái)開(kāi)發(fā)、完成中臺(tái)方案設(shè)計(jì)、完成核心需求開(kāi)發(fā)、完成前端方案設(shè)計(jì)，以及相應(yīng)時(shí)點(diǎn)的需求詳細(xì)宣講會(huì)、全量UI設(shè)計(jì)評(píng)審會(huì)、中臺(tái)方案評(píng)審會(huì)、前端方案評(píng)審會(huì)；
? ? ? ? 版本第一周：也叫前端開(kāi)發(fā)周，主要工作是前端開(kāi)發(fā)以及前后端聯(lián)調(diào)、完成中臺(tái)開(kāi)發(fā)、測(cè)試用例設(shè)計(jì)、根據(jù)需求交付進(jìn)度進(jìn)行的代碼Review工作、啟動(dòng)Sit測(cè)試，以及相應(yīng)時(shí)點(diǎn)的測(cè)試用例評(píng)審會(huì)；
? ? ? ? 版本第二周，也叫測(cè)試周，主要工作是完成前端開(kāi)發(fā)、進(jìn)行Sit測(cè)試、產(chǎn)品介入冒煙測(cè)試、UI完成視覺(jué)還原工作，以及后臺(tái)在預(yù)部署環(huán)境灰度發(fā)布、生產(chǎn)發(fā)布，中臺(tái)在預(yù)部署環(huán)境灰度發(fā)布；
? ? ? ? 版本第三周，也叫發(fā)布周，主要是完成SiT測(cè)試、開(kāi)始并完成UAT測(cè)試、完成中臺(tái)生產(chǎn)環(huán)境發(fā)布、完成App生產(chǎn)環(huán)境發(fā)布提審，以及相應(yīng)時(shí)點(diǎn)的產(chǎn)品上線評(píng)審會(huì)；
各角色職責(zé)與能力要求說(shuō)明
? ? 產(chǎn)品經(jīng)理角色：
? ? ? ? 此角色既要求專業(yè)的移動(dòng)產(chǎn)品鑒賞能力，也需要專業(yè)的需求分析能力，還要有較強(qiáng)的版本規(guī)劃意識(shí)。上圖版本迭代周期雖然為兩周，但實(shí)際運(yùn)作是五周，版本核心需求的梳理與規(guī)劃要至少前置兩周完成，以便后臺(tái)開(kāi)發(fā)人員能提前兩周啟動(dòng)后臺(tái)方案設(shè)計(jì)與開(kāi)發(fā)工作；需求的交付目標(biāo)是專業(yè)細(xì)致的需求描述文本與詳實(shí)清晰的交互原型稿（推薦用Azure快速繪制），絕不能遺漏核心交互流程分支與重點(diǎn)需求邊界條件，交互原型稿至少要符合主流移動(dòng)產(chǎn)品交互規(guī)范。
? ? ? ? 需求描述堅(jiān)決拒絕一句話需求，杜絕大而全的全場(chǎng)景粒度需求。前者說(shuō)明產(chǎn)品經(jīng)理缺乏最基本的專業(yè)需求分析能力，后者說(shuō)明產(chǎn)品經(jīng)理對(duì)需求粒度把握能力不夠。前者就不說(shuō)了，重點(diǎn)說(shuō)說(shuō)后者，這是最常見(jiàn)的需求交付形式，因?yàn)榭瓷先バ枨竺枋鍪亲钊媲逦?，也最能直觀體現(xiàn)產(chǎn)品經(jīng)理的辛苦勞動(dòng)程度。但其實(shí)這是最危險(xiǎn)的需求交付方式，因?yàn)榱６忍?，雖然主流程不至于遺漏，但是二級(jí)、三級(jí)細(xì)化分支場(chǎng)景無(wú)法面面俱到，從而容易導(dǎo)致異常分支流程疏漏或者重要低頻細(xì)節(jié)被忽略，也不利于開(kāi)發(fā)團(tuán)隊(duì)做需求工作量評(píng)估，測(cè)試團(tuán)隊(duì)不容易深挖業(yè)務(wù)場(chǎng)景。
? ? ? ? 需求的梳理雖然最初是基于業(yè)務(wù)場(chǎng)景來(lái)開(kāi)展的，但最終落地應(yīng)該是以業(yè)務(wù)流程為維度來(lái)實(shí)現(xiàn)的。一個(gè)完整業(yè)務(wù)場(chǎng)景如果包含兩條及以上操作流程，就要考慮做需求拆分。如果一個(gè)流程操作鏈太長(zhǎng)（例如超過(guò)五步），甚至需要做二次截?cái)嘈苑植?，最終拆分基準(zhǔn)是能保證一個(gè)需求的開(kāi)發(fā)工作量能比較準(zhǔn)確的評(píng)估出來(lái)。如果以上圖三周模型來(lái)量化的話，一個(gè)需求最好能由單人不超過(guò)5人天完成（三周迭代，不考慮聯(lián)調(diào)工作量，單人獨(dú)自開(kāi)發(fā)時(shí)長(zhǎng)不會(huì)超過(guò)7人天）。
? ? ? ? 產(chǎn)品經(jīng)理的需求開(kāi)發(fā)工作起點(diǎn)其實(shí)是還要早于五周的，因?yàn)橐ＷC在前置第一周周一二的時(shí)候?qū)⒑诵男枨蟮脑透褰桓冻鰜?lái)，這是產(chǎn)品經(jīng)理的第一個(gè)里程碑，用于與后臺(tái)開(kāi)發(fā)團(tuán)隊(duì)、UI設(shè)計(jì)團(tuán)隊(duì)做主流程交互與核心頁(yè)面數(shù)據(jù)的第一遍串講；產(chǎn)品經(jīng)理的第二個(gè)里程碑式前置第一周周四輸出全量需求的原型交互稿，然后組織各個(gè)角色核心成員做版本的需求范圍明確，此會(huì)議上需要評(píng)議出版本最終要交付的全量需求，此為需求的第二遍串講；產(chǎn)品經(jīng)理的第三個(gè)里程碑是版本前置第二周的周一二，結(jié)合全量UI初稿給全團(tuán)隊(duì)成員做詳細(xì)需求宣講與UI評(píng)審；接下來(lái)的兩周產(chǎn)品經(jīng)理團(tuán)隊(duì)的主要工作就是下個(gè)版本的需求分析了，當(dāng)前目標(biāo)版本的工作就是正式版本第二周（即測(cè)試周）介入冒煙測(cè)試，版本第三周進(jìn)行UAT驗(yàn)收測(cè)試以及版本上線支持工作。
? ? UI設(shè)計(jì)師角色（統(tǒng)稱，包括所謂UE/UX與UI）：
? ? ? ? 如果UI團(tuán)隊(duì)夠大，一般會(huì)細(xì)分為UE/UX設(shè)計(jì)師與UI設(shè)計(jì)師兩類角色，前者負(fù)責(zé)整體交互設(shè)計(jì)與體驗(yàn)把關(guān)，后者負(fù)責(zé)將前者的設(shè)計(jì)進(jìn)行落地實(shí)現(xiàn)。如果是小團(tuán)隊(duì)，基本就只會(huì)有UI設(shè)計(jì)師角色。不論哪種團(tuán)隊(duì)組織模式，都要求設(shè)計(jì)師具備較深的移動(dòng)交互素養(yǎng)積累，具備一定的設(shè)計(jì)創(chuàng)意能力與交互規(guī)范度意識(shí)。移動(dòng)端的設(shè)計(jì)從來(lái)都是首先服從于主流交互體驗(yàn)、硬件局限與主流用戶習(xí)慣，然后再進(jìn)行局部創(chuàng)新與品牌融入。最忌諱設(shè)計(jì)師在交互流程與交互方式上做所謂的創(chuàng)新，去顛覆現(xiàn)有用戶操作習(xí)慣。如果一種全新的交互方式，你是第一個(gè)1，那用戶就會(huì)成為你后面的0，將你無(wú)限放大；但如果你只是后來(lái)的1，那用戶就會(huì)把你變成小數(shù)點(diǎn)后面的1，然后在前面加無(wú)數(shù)個(gè)0，最終將你拋棄。在移動(dòng)交互的世界里，用戶從來(lái)都是懶惰、因循守舊的。
? ? ? ? 對(duì)于設(shè)計(jì)師而言，除了本身的專業(yè)設(shè)計(jì)能力要求外，還要求有很強(qiáng)的需求理解能力、需求具化能力與一定的體驗(yàn)執(zhí)著，畢竟所謂的設(shè)計(jì)潮流日新月異，我們既要緊跟主流，也要適當(dāng)沉淀，不要為變而變，一切以能為產(chǎn)品創(chuàng)造更多用戶價(jià)值為衡量標(biāo)準(zhǔn)。
? ? ? ? UI團(tuán)隊(duì)的工作起點(diǎn)是緊跟產(chǎn)品需求交付進(jìn)度的，在前置第一周的周一，產(chǎn)品經(jīng)理交付核心需求原型稿之后，即開(kāi)始進(jìn)行核心需求的設(shè)計(jì)工作。UI團(tuán)隊(duì)的工作進(jìn)程總體是與后臺(tái)團(tuán)隊(duì)同步的：第一個(gè)里程碑是在前置第一周周四完成核心需求UI設(shè)計(jì)初稿的輸出，期間當(dāng)然需要UI與產(chǎn)品做持續(xù)的需求澄清與核心交互確認(rèn)；然后在前置第二周的周一二完成全量需求的初稿輸出并組織UI評(píng)審，此評(píng)審一般是跟需求詳細(xì)宣講一起組織，既做UI評(píng)審，也用于給開(kāi)發(fā)做需求實(shí)現(xiàn)的直觀展示；最后，結(jié)合評(píng)審意見(jiàn)進(jìn)行UI終稿修訂，在版本正式啟動(dòng)的第一周周二前后實(shí)現(xiàn)第二個(gè)里程碑——全量UI終稿輸出；在這之后，UI就要開(kāi)始準(zhǔn)備下一版本的UI輸出工作了，而在當(dāng)前版本剩余的主要工作是版本第二周周四前后給前端開(kāi)發(fā)做視覺(jué)還原，以評(píng)閱并調(diào)校需求的最終實(shí)現(xiàn)效果。
? ? 后臺(tái)開(kāi)發(fā)角色：
? ? ? ? 在上圖三周迭代模型中，后臺(tái)開(kāi)發(fā)是最早啟動(dòng)的，綜合技術(shù)能力要求也是最高的，但是可以專注于單一微服務(wù)模塊的開(kāi)發(fā)。后臺(tái)開(kāi)發(fā)團(tuán)隊(duì)需要在僅僅依托產(chǎn)品原型交互稿的基礎(chǔ)上完成核心需求的方案設(shè)計(jì)與開(kāi)發(fā)工作，需要很強(qiáng)的需求抽象能力與方案設(shè)計(jì)能力，同時(shí)要有一定的雙版本并行開(kāi)發(fā)能力，從上圖中可以看到，后臺(tái)開(kāi)發(fā)人員大部分時(shí)候是既要進(jìn)行當(dāng)前版本的聯(lián)調(diào)與bug修復(fù)工作，同時(shí)也要進(jìn)行下一版本的后臺(tái)開(kāi)發(fā)工作，其交付質(zhì)量的保障是通過(guò)拉長(zhǎng)聯(lián)調(diào)驗(yàn)證時(shí)長(zhǎng)來(lái)最終保障的（總計(jì)5周）；
? ? ? ? 后臺(tái)開(kāi)發(fā)團(tuán)隊(duì)的工作時(shí)點(diǎn)也是緊跟產(chǎn)品需求交付進(jìn)度的，基本與UI設(shè)計(jì)工作并行，其第一個(gè)里程碑在前置第一周周二前后，需要完成核心需求的方案設(shè)計(jì)與評(píng)審；其第二個(gè)里程碑是前置第一周的周四前后，核心交付項(xiàng)是后臺(tái)接口設(shè)計(jì)文檔，中臺(tái)基于此才能開(kāi)始中臺(tái)方案設(shè)計(jì)工作；第三個(gè)工作里程碑是在版本第一周周一前后完成全量后臺(tái)開(kāi)發(fā)工作；第四個(gè)里程碑到了版本第二周周二，將后臺(tái)代碼發(fā)布到預(yù)部署灰度發(fā)布環(huán)境測(cè)試；第五個(gè)里程碑是版本第二周周四，將后臺(tái)代碼發(fā)布到生產(chǎn)環(huán)境驗(yàn)證，到此當(dāng)前版本的后臺(tái)工作基本就算結(jié)束了，版本第二周后臺(tái)主要精力放在下一版本的后臺(tái)方案設(shè)計(jì)與開(kāi)發(fā)。
? ? 中臺(tái)開(kāi)發(fā)角色：
? ? ? ? 在移動(dòng)團(tuán)隊(duì)中，除了核心后臺(tái)，一般還有API網(wǎng)關(guān)這一中臺(tái)開(kāi)發(fā)角色。中臺(tái)既用于聚合不同后臺(tái)服務(wù)，也用于做一些與業(yè)務(wù)無(wú)關(guān)的全局性管理與監(jiān)控的工作，例如登錄、日志管理、接口攔截與監(jiān)控等。中臺(tái)開(kāi)發(fā)人員的技術(shù)能力要求相關(guān)低一點(diǎn)，但是對(duì)于整體后臺(tái)業(yè)務(wù)熟悉度要求很高，這樣才能知道一個(gè)中臺(tái)接口的實(shí)現(xiàn)需要從哪些后臺(tái)服務(wù)中提取數(shù)據(jù)。中臺(tái)開(kāi)發(fā)人員也需要一定的雙版本并行開(kāi)發(fā)能力。
? ? ? ? 中臺(tái)開(kāi)發(fā)團(tuán)隊(duì)的工作時(shí)點(diǎn)是緊跟后臺(tái)開(kāi)發(fā)交付時(shí)點(diǎn)的，一般在前置第一周周四前后開(kāi)始中臺(tái)方案設(shè)計(jì)工作（既后臺(tái)完成后臺(tái)接口方案設(shè)計(jì)文檔的交付）；第一個(gè)里程碑節(jié)點(diǎn)出現(xiàn)在前置第二周周一前后，需要交付中臺(tái)方案設(shè)計(jì)文檔并組織方案評(píng)審，中臺(tái)方案評(píng)審最后也是跟詳細(xì)需求宣講會(huì)一起，既能減少會(huì)議次數(shù)，也能反哺需求澄清，從中臺(tái)角度幫助產(chǎn)品完善需求場(chǎng)景與邊界條件；中臺(tái)的第二個(gè)里程碑是在版本第一周周一前后，需要交付中臺(tái)接口設(shè)計(jì)文檔（其實(shí)最好能提前到前置第二周周四）；中臺(tái)的第三個(gè)里程碑節(jié)點(diǎn)出現(xiàn)在版本第一周周四前后，需要完成全量需求的中臺(tái)開(kāi)發(fā)工作，并與后臺(tái)完成聯(lián)調(diào)；中臺(tái)的第四個(gè)里程碑節(jié)點(diǎn)是版本第二周周四，將中臺(tái)代碼發(fā)布到預(yù)部署灰度發(fā)布環(huán)境供測(cè)試進(jìn)行灰度測(cè)試；中臺(tái)的第五個(gè)里程碑節(jié)點(diǎn)是版本第三周周二，將中臺(tái)代碼發(fā)布到生產(chǎn)環(huán)境，供測(cè)試進(jìn)行生產(chǎn)Uat測(cè)試，至此當(dāng)前版本中臺(tái)的工作基本就算結(jié)束了，當(dāng)前周中臺(tái)的主要工作放在下一版本的中臺(tái)方案設(shè)計(jì)與開(kāi)發(fā)上。
? ? 前端開(kāi)發(fā)角色：? ?
? ? ? ? 其實(shí)整個(gè)敏捷迭代模型都是圍繞前端開(kāi)發(fā)人員的工作時(shí)點(diǎn)來(lái)設(shè)計(jì)的，既是因?yàn)榍岸私桓恫攀钱a(chǎn)品可測(cè)試的功能交付，也是因?yàn)榍岸寺?lián)調(diào)驗(yàn)證通過(guò)了才算得上真正意義上的中后臺(tái)交付通過(guò)。前端功能因?yàn)橹苯用嫦蛴脩?，因此需求?zhǔn)備程度是最充分的，但是可供緩沖的開(kāi)發(fā)時(shí)長(zhǎng)也是最短的，因此對(duì)于前端開(kāi)發(fā)的交付質(zhì)量其實(shí)是最高的，基本不允許方案失誤或單個(gè)需求級(jí)別的開(kāi)發(fā)返工，一旦出現(xiàn)往往就會(huì)導(dǎo)致版本延期。從運(yùn)作經(jīng)驗(yàn)來(lái)看，三周版本迭代，真正可用于前端開(kāi)發(fā)的時(shí)間最多也就在七天左右，因此每個(gè)版本的需求交付量，就可以基于單人七人天來(lái)做量化評(píng)估。
? ? ? ? 前端開(kāi)發(fā)團(tuán)隊(duì)的工作時(shí)點(diǎn)相對(duì)固定，基本是在前一版本測(cè)試轉(zhuǎn)Uat之后開(kāi)始進(jìn)行當(dāng)前版本的方案設(shè)計(jì)，一般是在前置第二周周二前后；前端開(kāi)發(fā)的第一個(gè)里程碑節(jié)點(diǎn)出現(xiàn)在前置第二周周四左右，也即與前一版本的發(fā)布時(shí)點(diǎn)重合，可以在前一版本的上線評(píng)審會(huì)上作下一版本的前端方案評(píng)審；前端開(kāi)發(fā)的第二個(gè)里程碑是在版本第二周周二前后，此時(shí)需要完成所有需求的前端開(kāi)發(fā)工作與自測(cè)試；前端的第三個(gè)里程碑節(jié)點(diǎn)就是App版本的發(fā)布，也即版本第三周周四；對(duì)于前端而言，并沒(méi)有一個(gè)明確的里程碑節(jié)點(diǎn)來(lái)做專門的代碼Review工作，代碼Review工作是細(xì)分到每一個(gè)需求的，哪個(gè)需求完成了開(kāi)發(fā)與自測(cè)試，即可找核心員工作代碼Review工作，Review之前需求才可以轉(zhuǎn)測(cè)試，這樣既保證了代碼Review的時(shí)效性，也降低了單次Review的工作量從而能較好地保證Review質(zhì)量。
? ? 測(cè)試角色：
? ? ? ? 測(cè)試團(tuán)隊(duì)的工作啟動(dòng)是最晚的，基本要到前置第二周周四之后才能開(kāi)始測(cè)試用例設(shè)計(jì)工作（因?yàn)橐缺ＷC前一版本的驗(yàn)證通過(guò)、發(fā)布上線）；其第一個(gè)里程碑出現(xiàn)在版本第一周周四左右，需要完成所有需求測(cè)試用例的輸出同時(shí)組織用例評(píng)審會(huì)議，此時(shí)前端開(kāi)發(fā)的需求也已經(jīng)完成一大半了，就可以立馬進(jìn)行Sit測(cè)試；測(cè)試的第二個(gè)里程碑是Sit測(cè)試結(jié)束，出現(xiàn)在版本第三周周二（當(dāng)然也可以前置到第二周周四）；之后就是轉(zhuǎn)Uat測(cè)試，帶周四Uat測(cè)試完成即可以組織版本上線評(píng)審會(huì)議，然后開(kāi)始下一版本用例設(shè)計(jì)工作。
? ? ? ? 綜上所述，敏捷迭代運(yùn)作必然是多角色工作遞延啟動(dòng)、并行運(yùn)作，而且環(huán)環(huán)相扣的，對(duì)每一個(gè)角色的要求都很高，任意一個(gè)角色拖后腿都會(huì)影響整個(gè)團(tuán)隊(duì)進(jìn)度，迭代運(yùn)作初期團(tuán)隊(duì)人員可能會(huì)比較累（特別是產(chǎn)品跟設(shè)計(jì)，差不多要同時(shí)準(zhǔn)備兩個(gè)版本的需求與設(shè)計(jì)稿），但是一旦運(yùn)作節(jié)奏順暢了，在交付節(jié)點(diǎn)反而會(huì)比較輕松，因?yàn)橹饕ぷ髁吭谇懊嬉呀?jīng)完成了。
? ? ? ? 不過(guò)，此模型要求各角色成員一定要有產(chǎn)品主人翁意識(shí)，充分發(fā)揮各人的主觀能動(dòng)性，盡可能把事情往前趕，這樣才能事半功倍、穩(wěn)步快跑。
九大原罪
? ? ? ? 同時(shí)，此模型非常強(qiáng)調(diào)各個(gè)里程碑的交付質(zhì)量，堅(jiān)決禁止需求錯(cuò)誤或者方案錯(cuò)誤級(jí)別的返工行為，以下便是筆者帶領(lǐng)團(tuán)隊(duì)進(jìn)行迭代運(yùn)作過(guò)程中總結(jié)的九條迭代原罪以及相應(yīng)影響：
? ? 原罪一：
? ? ? ? 產(chǎn)品經(jīng)理的移動(dòng)產(chǎn)品專業(yè)積累不夠，功能規(guī)劃能力欠缺，對(duì)于核心需求缺少前瞻性規(guī)劃，版本迭代只能且做且走，無(wú)法達(dá)到前后端雙版本差量并行運(yùn)作的高速要求，導(dǎo)致版本迭代節(jié)奏受累需求交付節(jié)奏，版本周期無(wú)法穩(wěn)定下來(lái)，團(tuán)隊(duì)開(kāi)發(fā)節(jié)奏被頻繁打亂；
? ? 原罪二：
? ? ? ? 產(chǎn)品經(jīng)理需求分析意識(shí)匱乏，無(wú)能力區(qū)分業(yè)務(wù)需求與功能需求，更不懂如何把用戶需求轉(zhuǎn)化成真正產(chǎn)品功能需求，經(jīng)常直接把用戶訴求當(dāng)成產(chǎn)品需求納入版本規(guī)劃，從而造成需求細(xì)節(jié)不明確、重要場(chǎng)景遺漏、業(yè)務(wù)流程沖突等問(wèn)題，最終導(dǎo)致UI返工、中后臺(tái)方案調(diào)整與開(kāi)發(fā)反復(fù)、版本延期等嚴(yán)重后果；
? ? 原罪三：
? ? ? ? UI設(shè)計(jì)師缺乏專業(yè)的移動(dòng)產(chǎn)品設(shè)計(jì)素養(yǎng)，對(duì)基礎(chǔ)移動(dòng)交互規(guī)范漠視，經(jīng)常創(chuàng)造“新的”交互流程，導(dǎo)致用戶習(xí)慣輕易被破壞、體驗(yàn)流暢性下降；
? ? 原罪四：
? ? ? ? UI設(shè)計(jì)師一味追求所謂最新設(shè)計(jì)潮流，缺乏品牌植入意識(shí)與設(shè)計(jì)能力，最終導(dǎo)致App風(fēng)格體驗(yàn)經(jīng)常變換，用戶的產(chǎn)品熟識(shí)度降低，甚至造成業(yè)務(wù)流程沖突、UI設(shè)計(jì)返工，拖慢前端開(kāi)發(fā)進(jìn)度；
? ? 原罪五：
? ? ? ? 核心開(kāi)發(fā)人員技術(shù)能力欠缺，對(duì)需求的技術(shù)實(shí)現(xiàn)復(fù)雜度缺少量化評(píng)判，導(dǎo)致工作量評(píng)估失誤，直接影響版本周期評(píng)估；
? ? 原罪六：
? ? ? ? 核心開(kāi)發(fā)人員方案設(shè)計(jì)能力欠缺，導(dǎo)致概要方案錯(cuò)誤、經(jīng)常性返工，最終影響開(kāi)發(fā)進(jìn)度、版本延期；
? ? 原罪七：
? ? ? ? 普通開(kāi)發(fā)人員技術(shù)能力欠缺抑或任務(wù)分工沒(méi)有量才為用，導(dǎo)致代碼交付質(zhì)量差、開(kāi)發(fā)返工，最終影響項(xiàng)目進(jìn)度；
? ? 原罪八：
? ? ? ? 測(cè)試人員專業(yè)能力欠缺，測(cè)試用例無(wú)法深入業(yè)務(wù)場(chǎng)景，造成重要場(chǎng)景遺漏或者關(guān)鍵細(xì)節(jié)漏測(cè)，最終影響版本交付質(zhì)量；
? ? 原罪九：
? ? ? ? 自動(dòng)化測(cè)試建設(shè)缺失，導(dǎo)致測(cè)試人員在原有功能回歸測(cè)試方面耗費(fèi)太多時(shí)間，造成有效測(cè)試時(shí)長(zhǎng)偏低、測(cè)試效率低下，迭代周期內(nèi)測(cè)試覆蓋度明顯不夠，最終影響版本上線穩(wěn)定性；
綜述
????????敏捷軟件團(tuán)隊(duì)的管理與運(yùn)作，是最能直觀體現(xiàn)木桶理論的，不論哪個(gè)角色，只要出現(xiàn)能力短板，都會(huì)被無(wú)限放大、進(jìn)而影響到整個(gè)團(tuán)隊(duì)的運(yùn)作效果，因?yàn)檐浖芷谥懈黜?xiàng)工作雖然可以雙版本（甚至多版本）并行運(yùn)作，但是單一版本內(nèi)的各項(xiàng)工作內(nèi)容終究還是串行運(yùn)作、彼此依賴的，都是牽一發(fā)動(dòng)全身。即便上述迭代模型是以前端開(kāi)發(fā)為中心而設(shè)計(jì)的，但是各個(gè)角色并沒(méi)有主次之分，只有職責(zé)先后之別。
? ? ? ? 如果人員能力基本滿足要求，嚴(yán)格按照上述運(yùn)作模型迭代，App的運(yùn)作效果應(yīng)該基本可以達(dá)到個(gè)60分，但如果要達(dá)到80分甚至90分，除了有賴Product Owner的精細(xì)化管理、Scrum Master的專業(yè)引導(dǎo)，更有賴于各個(gè)角色自身專業(yè)能力的質(zhì)變。軟件行業(yè)是精益流程與卓越個(gè)人共同助益才能達(dá)到巔峰的，既需要“照章辦事”的黃牛精神，也需要獨(dú)當(dāng)一面的“個(gè)人英雄主義”引領(lǐng)。? ? ? ??
