作為創(chuàng)業(yè)公司很重要的一個環(huán)節(jié)就是在有限的時間和資源下把產(chǎn)品需求落地為產(chǎn)品，也就是研發(fā)和項目管理，毫無疑問，這個階段的主角是開發(fā)人員，那作為一個PM，把做項目管理的過程也當(dāng)成做產(chǎn)品的過程的話，是不是應(yīng)該多思考下怎么面向開發(fā)人員來優(yōu)化整個研發(fā)過程和項目管理流程。本文就是我們?nèi)绾瓮ㄟ^優(yōu)化開發(fā)環(huán)境搭建，代碼管理，需求生命周期管理，開發(fā)任務(wù)分配和追蹤，項目整體進(jìn)度管理來提高研發(fā)過程中開發(fā)人員效率，通過持續(xù)集成和交付讓開發(fā)中的問題更早暴露，通過合理的測試反饋工具讓開發(fā)人員最快定位和解決問題。

一點前提條件和背景

印象中很多關(guān)于產(chǎn)品和開發(fā)為了進(jìn)度撕逼的段子，其實作為一個開發(fā)轉(zhuǎn)的產(chǎn)品，對這兩塊都有所了解，就我的看法是研發(fā)效率不止是研發(fā)人員本身的技術(shù)能力和工作效率，而是整個研發(fā)過程和項目管理流程的效率，但我自己理解的高效的研發(fā)和項目管理有兩個前提：

• 公司內(nèi)各團(tuán)隊有個大家認(rèn)同的溝通協(xié)作方式：因為所有的流程和工具都是為人所用的，只有團(tuán)隊有主動性去溝通協(xié)作才能提高效率，這也是我這個系列第一篇寫“異地創(chuàng)業(yè)團(tuán)隊如何做團(tuán)隊溝通協(xié)作”的原因。
• 盡量清晰的需求定義：產(chǎn)品經(jīng)理的任務(wù)就是讓研發(fā)團(tuán)隊開發(fā)正確的任務(wù)，我所碰到的開發(fā)延期或者交付失敗很多時候就是由于自己對需求的認(rèn)識不夠，開發(fā)中過多需求的變更造成的，一個表達(dá)清楚，考慮完善的需求定義才能保證下面的研發(fā)和管理是不是在做無用功，所以本系列的第二篇是“聊聊針對異地團(tuán)隊的需求協(xié)作和原型、設(shè)計的評審”

說到創(chuàng)業(yè)團(tuán)隊的研發(fā)和項目管理的實踐，就逃不開先要說一下我們研發(fā)和項目管理中的工具作為背景：

• 即時交流和協(xié)作：Slack，這個我在“異地創(chuàng)業(yè)團(tuán)隊如何做團(tuán)隊溝通協(xié)作”里重點談到過，鑒于它的開放性，已經(jīng)基本連接了我們用到的文件管理，設(shè)計評審，持續(xù)集成，測試分發(fā)，Bug Report等一系列工具。
• 代碼管理：Git+Gitlab，自己搭建Git和Gitlab一定程度上保證了代碼的安全性，不過維護(hù)和備份都是個會耗費精力的問題，對沒有專業(yè)運維的創(chuàng)業(yè)團(tuán)隊推薦直接Github托管。
• 項目管理：Redmine，老實說Redmine一直都不是項目管理上的最佳方案，專業(yè)級的有JIRA，輕量的有Asana、Tower等很多，我們就是已經(jīng)習(xí)慣了，有一套Githooks在上面，并沒有什么動力去換。
• 持續(xù)集成：Jenkins，雖然Java的坑也很大，維護(hù)起來也不時被坑，不過功能和插件確實齊全，搭起來也不易，有興趣的可以嘗試Travis CI或者Gitlab CI。

最后切入正題了，本篇涵蓋的是我們在研發(fā)過程和項目管理流程，以及當(dāng)中在DevOps上做的一些努力去優(yōu)化開發(fā)人員的體驗，就試著從各個環(huán)節(jié)總結(jié)一下，因為不同團(tuán)隊的研發(fā)流程和項目管理都不一樣，各位看官可以挑有興趣的來看：

• 研發(fā)環(huán)境的搭建：包括如何kick off新開發(fā)者，如何搭建日常開發(fā)環(huán)境
• 代碼的管理：包括源碼管理，Code Review和組織公共庫
• 需求在研發(fā)中的生命周期管理：包括功能需求清單，功能需求定義和其中的開發(fā)任務(wù)項分配和狀態(tài)管理
• 項目進(jìn)度的管理：包括如何通過Redmine有效的執(zhí)行敏捷開發(fā)
• 研發(fā)階段的產(chǎn)品測試和反饋：包括在產(chǎn)品測試和反饋中的一些經(jīng)驗和工具分享
• 持續(xù)集成和持續(xù)發(fā)布：包括如何針對Web, Android和iOS分別搭建持續(xù)集成和發(fā)布

一、研發(fā)環(huán)境的搭建

如何讓團(tuán)隊新的開發(fā)者盡快上手

對新的開發(fā)人員，一般都會有開賬號，裝系統(tǒng)，配環(huán)境，跑代碼這些過程，我自己發(fā)現(xiàn)每次都低估這些工作的耗時，以前就發(fā)現(xiàn)有時候不小心就一兩天過去了還沒跑起來代碼，一兩周還沒搞清楚目前產(chǎn)品的功能，我總結(jié)了兩點加快這個進(jìn)度的方法：

1.加快能讓代碼跑起來的速度

有很多可以加速的環(huán)節(jié)，一個比較重要的就是自動構(gòu)建代碼，就是指開發(fā)人員checkout代碼后通過簡單的構(gòu)建腳本就能完成代碼依賴安裝，代碼編譯，單元測試運行，也就是我們常說的跑起來。以Web為例，可以通過npm的腳本完成npm依賴的安裝，然后用gulp完成代碼的構(gòu)建和運行，這也是持續(xù)集成的基礎(chǔ)。

2.對產(chǎn)品功能需求和目前進(jìn)度的了解

在背景的里說的保持一個盡量清晰的需求定義的一個用途就在這，新的開發(fā)人員可以通過瀏覽產(chǎn)品的需求文檔來了解產(chǎn)品功能，我們的做法是在Redmine上把“系統(tǒng)功能匯總(含已排期未完成功能)”作為一個Custom Query，將所有功能的PRD列出來，有兩種視圖可以選擇，一個就是下圖這樣按照產(chǎn)品線，能看到每個產(chǎn)品線的功能：

另一個視圖就是按照功能完成的時間來歸類，可以知道以前每個版本都做了什么功能，未來有什么功能正在排期中：

如何方便開發(fā)人員進(jìn)行日常開發(fā)調(diào)試

目前對于Web開發(fā)來說，一般構(gòu)建的過程中代碼都會進(jìn)行混淆、合并、CDN地址替換、CSS Sprite生成等等操作，造成在Dev服務(wù)器上調(diào)試很不方便，我們采取的解決方法是在web的Gulp構(gòu)建流程中分不同的Build Target，本地調(diào)試使用未混淆的代碼加本地搭建的Python環(huán)境，連接Dev數(shù)據(jù)庫，方便Web開發(fā)人員本地調(diào)試。

二、代碼管理

首先最重要的就是代碼必須用源碼管理工具，我們一直用的Git。代碼的查看和管理都在Gitlab上，可以查看代碼，code review，合并分支，打版本tag之類的，不過Gitlab對開發(fā)者不是必須要用的，所有這些操作都能用git command解決的事情，有兩點我覺得需要關(guān)注的：

1.怎么讓開發(fā)人員高效的使用第三方庫

項目開發(fā)的過程中去抽象公共組件，使用第三方庫或開發(fā)工具都可以提高開發(fā)效率，但需要做好模塊和版本管理，有時候碰到一個開發(fā)人員引入了一個不合理的依賴，或者學(xué)習(xí)成本陡峭的組件，每個參與開發(fā)人員都要增加學(xué)習(xí)成本。這個一般都是根據(jù)不同的技術(shù)棧有相應(yīng)的一套工具可以使用，我們自己在Web、Python、iOS、Android上面都有自己習(xí)慣的選擇，需要加新的組件或者替換正在使用的都可以一起討論之后加入，以免發(fā)生重復(fù)或者后期的分歧。我們主要考慮的點有下面這些。

2.如何做新功能開發(fā)的代碼管理

只要多人開發(fā)，而且多功能并行開發(fā)都避免不了要考慮如何管理代碼，一般有Feature Toggle和Git Branching兩種，目前我們根據(jù)自己的需求定義了一個Git brancing model，對于復(fù)雜的新功能建立feature branch來開發(fā)：

雖然我個人更喜歡Feature Toggle的方式，不過實踐起來需要的模板開發(fā)和構(gòu)建方式上的配合，不如Git Branching對開發(fā)來說上手更簡單一些，暫時就沒有更換，建議看一下Baidu FEX的<<Feature Flag 功能發(fā)布控制>>去考慮自己適合哪一種。

三、需求在研發(fā)中的生命周期管理

對于開發(fā)人員來說，開發(fā)工作一般是圍繞著具體的功能需求進(jìn)行的，而背景中提到過的“清晰的需求定義”就是研發(fā)的主要輸入，由負(fù)責(zé)的PM來主導(dǎo)需求(User Story)的狀態(tài)更新，本節(jié)以一個功能需求(User Story)為例，先上一個時序圖來說明單個功能在研發(fā)中的生命周期是什么樣的：

從功能需求(User Story)的時間線上可以看出來其分為下面幾個狀態(tài)：

PM創(chuàng)建后協(xié)作編寫需求文檔(New) -> 需求確認(rèn)(Confirmed) -> 開發(fā)中(In Progress) -> 待測試(Wait for test) -> 已完成,可以上線(Finished) -> 完成,可以關(guān)閉(Closed)

可以劃分為需求確認(rèn)，需求開發(fā)，需求測試和上線三個階段：

1. 需求確認(rèn)

對于需求文檔的編寫和確認(rèn)，不同團(tuán)隊方式不一樣，我在前一篇《“聊聊針對異地團(tuán)隊的需求協(xié)作和原型、設(shè)計的評審”》聊了如何通過怎么協(xié)作完成清晰的需求定義，我的理解是包括功能需求的前置條件和后置條件，用戶流程和規(guī)則，完整的產(chǎn)品交互原型，評審確認(rèn)的設(shè)計稿。下圖為在Redmine上定義的一個功能需求(User Story)

2. 需求開發(fā)

在需求定義清晰后，開發(fā)前需要整個開發(fā)團(tuán)隊的參與確認(rèn)任務(wù)的分配。任務(wù)分配的原則就是將功能需求對應(yīng)的任務(wù)按樹形結(jié)構(gòu)分解，敏捷開發(fā)里的學(xué)名就是“Work Breakdown Structure (WBS)”，保證其中每個任務(wù)都是可以開發(fā)，并且是可以測試的。下圖就是一個功能需求對應(yīng)的任務(wù)的實例：

具體到其中一個單獨的任務(wù)項(Task)，里面會有它所屬的功能需求(User Story)，當(dāng)前的狀態(tài)，優(yōu)先級，任務(wù)指派的開發(fā)者，任務(wù)所屬的產(chǎn)品線(Web, iOS, android…)，一個簡單的任務(wù)描述的，所屬的milestone，預(yù)計開發(fā)時間和結(jié)束時間，任務(wù)當(dāng)前的狀態(tài)和進(jìn)度等等。如下圖所給的就是一個Task的實例：

從上文中“需求在研發(fā)中的生命周期”的時序圖上可以看出其對應(yīng)的任務(wù)的生命周期是如何管理的，包括前端和后臺之間的任務(wù)協(xié)作是如何完成的，簡單來總結(jié)的話Task有下面幾種狀態(tài)：

新建 -> 開發(fā)中 -> 待代碼復(fù)查(目前僅junior developer需要被code review) -> 待測試 -> 反饋 -> 完成(可以上線) -> 關(guān)閉(上線以后可以關(guān)閉)

開發(fā)人員主要負(fù)責(zé)的就是開發(fā)的同時更新自己任務(wù)的狀態(tài)，看起來狀態(tài)蠻多，如果開發(fā)需要每次登錄redmine來改也確實蠻累，在實踐的過程中我們引入了一下優(yōu)化的方法：

為Redmine自定義一些Git hooks來更新狀態(tài)。通過自定義git提交語法，讓Git提交能自動更新在Redmine相應(yīng)的issue上，既節(jié)省了更新狀態(tài)的時間，又能保持一個干凈的git logs。下面是我們定義的Git提交語法：

[component] Abc: (Issue #Id) + Message (Issue Status)

• [component] 就是任務(wù)所屬的模塊，比如[ios], [android], [backend], [web]，這和Jenkins的Build Job綁定，當(dāng)有相應(yīng)模塊的代碼提交就會觸發(fā)相應(yīng)部分的持續(xù)集成和交付。
• Abc 就是操作的Action是什么，比如Add, Mod(ify), Ref(actoring), Fix, Rem(ove) and Rea(dability)，用來讓代碼提交信息的目的看起來比較清晰。
• (Issue #Id) 就是對應(yīng)的Task的Id是什么，為了將changelog和task綁定在一起。提交以后就會自動更新Redmine的Task：

Server端接口文檔自動生成。在需求定義里可以將規(guī)則和邏輯寫的很清楚，但在前端和服務(wù)端協(xié)作開發(fā)的過程中，如果服務(wù)端沒有文檔可能會經(jīng)常被前端打斷，詢問接口具體參數(shù)的名稱或參數(shù)類型，也是比較煩的事情，可以考慮用Documentation Generator在代碼中添加注釋來自動生成文檔，我們使用的“Sphinx”作為Python的文檔生成工具，用Python的推薦使用。

開發(fā)中的持續(xù)集成和交付。這個后面會專門來講如何操作，具體的意義就是開發(fā)人員提交代碼之后在Dev服務(wù)器上進(jìn)行自動構(gòu)建和發(fā)布，這樣一方面每次提交都做Lint檢查，有單元測試的做單元測試，降低代碼最后集成的時候出現(xiàn)問題的風(fēng)險，另一方面讓PM可以盡早的接觸到成品，盡早進(jìn)行反饋。

2. 需求測試和上線

當(dāng)單個功能需求下面對應(yīng)的所有任務(wù)都開發(fā)完成后，由PM進(jìn)行測試和反饋，在確認(rèn)與PRD一致后可以由PM更新為“待測試(Wait for test)”。這里“待測試(Wait for test)”的意義就是該功能需求可以在發(fā)布到測試服務(wù)器(Test Server)，由業(yè)務(wù)團(tuán)隊及測試用戶參與測試。當(dāng)測試沒有問題后，如果是Web功能則根據(jù)上線計劃上線到Production Server；如果是Native App，則按照版本計劃，可能需要固定時間發(fā)布或者等待幾個功能完成后一起發(fā)布。

由于這里講的是單個功能需求的研發(fā)周期，而測試和上線更多是在整個項目這個Scope上來討論，所以針對測試和上線的部分在后面持續(xù)集成和發(fā)布的部分會來細(xì)說。

四、項目進(jìn)度的管理

順著上面的思路，當(dāng)你有單個需求研發(fā)的流程后，整個項目的管理就是管理所有的需求，安排優(yōu)先級和迭代計劃，然后對所有需求進(jìn)行同樣的研發(fā)流程管理。敏捷開發(fā)里把一個迭代周期稱為一個Sprint，每個Sprint做一次產(chǎn)品發(fā)布，然后回顧Sprint內(nèi)的問題，規(guī)劃下一個Sprint的開發(fā)任務(wù)，如下圖：

我們的實踐不完全是Scrum，但比較接近，我們的迭代周期為一周，保證每周至少都往Production上做一次同步。項目的進(jìn)度管理在Scrum的實踐里其實就是在它的三個Meeting時完成的：

• Sprint Planning Meeting：從整個產(chǎn)品的Product Backlogs里一起規(guī)劃出下一個Sprint要完成的功能，可能對應(yīng)著很多團(tuán)隊的需求評審會
• Daily Standup Meeting：在一個Sprint里每天和開發(fā)人員一起回顧昨天的開發(fā)進(jìn)度，討論碰到的問題和確認(rèn)當(dāng)天的工作計劃，其實對應(yīng)著為開發(fā)人員詬病的項目日報
• Sprint Review Meeting：在一個Sprint結(jié)束回顧項目進(jìn)度，問題和下一個Sprint的計劃，一般對應(yīng)著PM要做的項目周報

在產(chǎn)品體驗的優(yōu)化中有個理論就是在所有直接接觸用戶的‘Touchpoint’上進(jìn)行體驗優(yōu)化，其實我個人覺得這三個Meeting就是項目進(jìn)度管理里的Touchpoint，在這三個Meeting上PM會和開發(fā)人員或者Product Owner進(jìn)行接觸，如果這里體驗不好就會影響項目的管理。其實我們總結(jié)的優(yōu)化方案也比較簡單，就是通過項目管理工具Redmine去實現(xiàn)的功能需求和開發(fā)任務(wù)的“看板”：

Sprint Planning Meeting

平時積累下的需求我會建立一個Future Milstone來存放，這樣在Planning Meeting上可以直接以這些作為Product Backlogs，作為產(chǎn)品以后可以去做的內(nèi)容，這些需求可以按照功能模塊來組織，然后在Sprint Planning Meeting上一起規(guī)劃出下一個Sprint要完成的功能：

Daily Standup Meeting

每日的站立會議是粒度最細(xì)的會議了，就是追蹤每個人每天的任務(wù)情況，在這里我們在Redmine上建立一個叫“本周需要完成的任務(wù)(開發(fā)人員)”的Custom Query，將這個Sprint里的任務(wù)按照不同類別( 網(wǎng)站，后臺管理，iOS或者Android)來歸類，作為我們的看板：

對于開發(fā)人員，只需要按照前面提到的提交代碼來更新任務(wù)狀態(tài)，完全不需要額外的工作就可以匯報自己每天的進(jìn)度。每天早上一上班，所有的開發(fā)人員聚在一起，按照不同的類別一個個過任務(wù)項，同步昨天完成的任務(wù)，確定今天的任務(wù)，有疑問的就在早會解決。

Sprint Review Meeting

對于項目進(jìn)度Review來說，Scrum的看板管理是將任務(wù)項按照狀態(tài)來分類，這樣能更清晰的看出來哪些已經(jīng)完成，哪些還沒有開始，可以通過變換Custom Query來實現(xiàn)：

不過Sprint Review Meeting一般就不只是研發(fā)團(tuán)隊參與，為了輔助相關(guān)的業(yè)務(wù)人員和測試用戶一起來Review，我們通過在Redmine上建立一個叫“本周已經(jīng)完成的任務(wù)(業(yè)務(wù)人員)”的Custom Query準(zhǔn)備上線的功能，里面是這個Sprint已經(jīng)完成的功能，將已經(jīng)完成功能的按照來歸類，PM可以按照這個來測試已經(jīng)完成的功能，全部完成測試提交到測試服務(wù)器以后，相關(guān)的業(yè)務(wù)人員和測試用戶也可以按照這些任務(wù)來試用，節(jié)省一下每次都要介紹更新了什么的時間:

五、研發(fā)階段的產(chǎn)品測試和反饋

產(chǎn)品發(fā)布到測試渠道后的反饋

當(dāng)產(chǎn)品發(fā)布到測試渠道就是希望在正式發(fā)布前得到業(yè)務(wù)團(tuán)隊或內(nèi)測用戶的反饋，對比開發(fā)人員的測試反饋，業(yè)務(wù)人員和測試用戶的反饋一般都比較抽象，就是問題描述不具體，環(huán)境上下文不清晰，沒有復(fù)現(xiàn)流程，解決這些問題最好借助反饋輔助工具：

• 移動端的Bug反饋工具目前我們使用BugTags，目前只用在Test版本上，可以讓測試人員通過截圖標(biāo)記的方式描述反饋內(nèi)容，發(fā)送時候也會附上環(huán)境和App日志，能節(jié)省不少對于反饋的處理時間。不過這個是顯式的反饋收集工具，需要測試用戶主動提交，如果需要隱式的反饋收集可以考慮AppSee，我自己沒有試用過，但一些測評都表示可以記錄用戶行為的視頻，統(tǒng)計界面點擊熱圖和漏斗分析，不過收費比較高，有機會可以嘗試下。
• 移動端的錄屏工具的話可以選Lookback，其實是個用研的工具，功能就是語言錄屏+面部攝像，目前還在Beta期間，免費試用，可以Mac直接連接錄屏后發(fā)送到它的網(wǎng)站，也可以在它的本地目錄里找到。
• Web端的Bug反饋工具目前只有截屏報bug，我目前沒有找到類似BugTags的可以顯式標(biāo)記問題的反饋工具，曾經(jīng)在《How Google Test Software》里面看到Google曾經(jīng)開源的Chrome插件工具BITE，有各種web上bug記錄和復(fù)現(xiàn)的黑科技，不過在Google Code上一副年久失修的樣子，我沒有勇氣去嘗試，如果有知道其他類似合適的可以推薦一下。
• Web的線上用戶追蹤的話，我們目前使用了Mouseflow，它可以記錄用戶的行為，然后在它的網(wǎng)站上通過iframe你的網(wǎng)站幫你復(fù)現(xiàn)出來，雖然不是100%精準(zhǔn)，但可以觀察一些用戶的行為。

產(chǎn)品發(fā)布前的測試用例表

我自己的經(jīng)驗是每次發(fā)布前的測試都需要產(chǎn)品經(jīng)理親自來做，一方面確認(rèn)發(fā)布功能的正確性，另一方面重新走一遍用戶流程，確認(rèn)產(chǎn)品目標(biāo)可以達(dá)到。測試的方法比較笨，暫時就是通過Google Sheet維護(hù)一張測試用例的表，如果是移動端就每個版本維護(hù)一個測試用例表，開發(fā)版測試時會把表格分享給所有開發(fā)人員，每個人都可以遍歷測試用例提交自己發(fā)現(xiàn)的問題。測試用例表的結(jié)構(gòu)為：

一級目錄，二級目錄，三級目錄，用例名稱，優(yōu)先級，前置條件，執(zhí)行方式，操作步驟，預(yù)期結(jié)果，測試狀態(tài)，測試備注，是否自動測試覆蓋

六、持續(xù)集成和持續(xù)發(fā)布

前幾年有一段為海外客戶做移動產(chǎn)品設(shè)計開發(fā)和咨詢的經(jīng)歷，這里面一個重要的痛點就是不停發(fā)測試版給客戶，征求意見和反饋，但對于移動app來講之前每次打包都需要打斷開發(fā)人員，等待編譯，改文件名加版本號，上傳等一系列繁瑣的過程，然后還經(jīng)常因為客戶沒有裝最新版而造成溝通時間的浪費，所以早期我們就開始著手建立持續(xù)集成和持續(xù)發(fā)布體系來避免這些問題。

我理解的一個完善的持續(xù)集成應(yīng)該包括代碼提交后的構(gòu)建->部署->測試->發(fā)布幾個階段，可以看‘The Product Managers’ Guide to Continuous Delivery and DevOps’上這個圖來理解：

自動構(gòu)建

在上文Redmine的Git hooks提到過githooks在持續(xù)集成中的作用，其實就是當(dāng)Git Commit Message出現(xiàn)相應(yīng)的模塊，就會在代碼提交成功后能在持續(xù)集成服務(wù)端(CI Server)觸發(fā)相應(yīng)的Server，Web，iOS或android端的自動構(gòu)建，這是持續(xù)集成的基礎(chǔ)。

這里面有個針對開發(fā)這邊的優(yōu)化就是盡量縮短自動構(gòu)建的時間消耗，我們的Web編譯就是個反例，優(yōu)化前有10來分鐘的時間，現(xiàn)在穩(wěn)定在3分鐘，還有優(yōu)化空間：

持續(xù)部署

部署分為客戶端部署和服務(wù)端部署兩種，就是構(gòu)建以后要把可運行的代碼發(fā)布到相應(yīng)的服務(wù)器和手機端。

持續(xù)測試

這部分在服務(wù)端和每種客戶端都分為單元測試和集成測試，理論上來說能在持續(xù)集成的過程中執(zhí)行測試，是對產(chǎn)品質(zhì)量極大的提升，不過對團(tuán)隊的規(guī)模和時間要求比較高，一般還是按自己的實際情況來。

自我檢討來說我們客戶端的單元測試這塊做的比較少，自動化集成測試的話每個項目都只對主要流程做一下覆蓋，這也是個從Linkedin早期開發(fā)流程里看到的經(jīng)驗，可以通過分析用戶行為得到主要用戶流程，然后先自動化測試這些流程。早期在Android開發(fā)的時候?qū)嵺`過，通過Jenkins+Spoon+Robotium可以在CI上跑多種不同的Android設(shè)備來對主要流程截圖，實現(xiàn)多設(shè)備的測試，在CI的效果是這樣的：

雖然效果確實不錯，可以在持續(xù)集成階段發(fā)現(xiàn)在什么版本或者分辨率下出現(xiàn)問題，但用Robotium測試寫起來還比較麻煩，后來我在Github上fork過一些優(yōu)化測試的方法進(jìn)行優(yōu)化，但如果不是非常長期維護(hù)的產(chǎn)品還是慎用吧。

持續(xù)交付

持續(xù)集成后的持續(xù)發(fā)布是我們主要需要解決的痛點，發(fā)布的對象分別是給開發(fā)和測試人員的Dev版，給內(nèi)測用戶的Test版和給最終線上用戶的Production版，發(fā)布的渠道又分為Web端和Mobile端，需要分別來考慮，一個涵蓋上面所有的情況項目的Jenkins大概是這樣的：

在之前Gitflow的圖上有展示到，我們將發(fā)布的dev,test和production分為三個不同的服務(wù)器：

• 對于Dev服務(wù)器就是由Git hooks來觸發(fā)，每次代碼提交都會更新Redmine對應(yīng)的Task，然后Redmine發(fā)郵件給這個Task的Watchers，同時觸發(fā)CI集成新版本到Dev上。
• 對于Test服務(wù)器就是當(dāng)有新功能測試完成，準(zhǔn)備上線的時候，就先同步到Test服務(wù)器上，通知內(nèi)測用戶下載測試，相當(dāng)于Staging服務(wù)器。
• 對于Production的正常的流程就是當(dāng)Sprint Review Meeting之后，按照確認(rèn)要上線的功能進(jìn)行發(fā)布。這里我有個習(xí)慣就是發(fā)布的時候在CI上檢查一下發(fā)布對應(yīng)的redmine tasks，避免有不該被同步的內(nèi)容。

需要注意的就是，Web的持續(xù)交付相對來講比較簡單和成熟，但Android端和iOS端處理起來都比較麻煩，首先就是對于Production版本，都不能直接發(fā)布到AppStore或者國內(nèi)的一堆Android市場，能在CI上做的就是build好production以后自動在Git上打版本tag。然后對于Test版本的分發(fā)，可以考慮使用Testflight或者國內(nèi)的蒲公英，綁定到CI上，可以集成好以后直接發(fā)布上去，然后通過Slack建立測試用戶Channel，自動發(fā)送通知消息，收到通知可以直接點擊下載安裝。

后記

關(guān)于團(tuán)隊溝通，需求協(xié)作和項目管理三塊的總結(jié)終于寫完了，很久沒碼文字了，寫出來感覺蠻生硬，很多地方?jīng)]有說清楚，不過水平確實也就這樣了。寫的過程中還是想到不少現(xiàn)在的方法里面有缺陷的地方，正好給自己一個ToDo List，以后去優(yōu)化。

作者：王超（微信號arnold_wangchao），創(chuàng)業(yè)者，5年互聯(lián)網(wǎng)產(chǎn)品管理經(jīng)驗。本文轉(zhuǎn)自我個人的blog

本文由 @王超 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。