問題和現(xiàn)狀
產(chǎn)品會在臨上線一兩天提出需求變更
在需求評審階段，看不出問題，在執(zhí)行階段，發(fā)現(xiàn)邏輯需要修改。
領(lǐng)導(dǎo)臨時加需求，往往導(dǎo)致加班
上線壓力大，有點亂，有點急，風(fēng)險高，容易出現(xiàn)遺漏問題，臨時版本多
在開發(fā)過程中，需求仍然不確定，導(dǎo)致反復(fù)修改，相關(guān)人員對同一問題的理解偏差較大
后端擴展個信息，測試增加測試案例等等都可能導(dǎo)致客戶端進行修改。
原因分析
從后臺到移動客戶端整個流程太長，涉及人員太多。溝通不充分和依賴等待造成的浪費很大
單純的word文檔，或者口頭說，比較抽象。評審環(huán)節(jié)必不可少，不過光靠評審是不夠的。發(fā)現(xiàn)的風(fēng)險，評估的工作量等都不是很準(zhǔn)確。
交互設(shè)計畢竟是模型，跟實際程序相差比較大。如果做高保真模型，產(chǎn)品將擠占更多的開發(fā)測試時間，導(dǎo)致設(shè)計和實際程序落差更大，開發(fā)的加班更多
PC和APP共用一套后臺，耦合嚴(yán)重，APP開發(fā)“PC思維無線化”現(xiàn)象嚴(yán)重
開發(fā)版本直接上線運行，中間缺少緩沖，風(fēng)險較大
缺乏概要設(shè)計和充分的驗證，導(dǎo)致邊開發(fā)邊改需求，造成不必要的浪費和混亂。
開發(fā)、驗證、上線三個關(guān)鍵動作集中處理，壓力大，風(fēng)險高
如何解決？
在APP和后臺服務(wù)之間增加“獨立網(wǎng)關(guān)”，獨立開發(fā)，獨立部署，作為“APP的后臺，后臺服務(wù)的前端”。
APP和PC各自擁有“獨立網(wǎng)關(guān)”，根據(jù)各自特點獨立開發(fā)，獨立部署，實現(xiàn)解耦，解決“PC思維無線化”問題。
以上兩點可以參考1號店架構(gòu)師王慶友寫的架構(gòu)文章一個可供創(chuàng)業(yè)公司參考的移動APP服務(wù)端架構(gòu)演進方案
- 以APP的“獨立網(wǎng)關(guān)”為切入點，將整個流程分為“APP開發(fā)”和“后臺開發(fā)”兩個相互獨立的部分，解決流程過長的問題。
- “APP開發(fā)”適合用“迭代開發(fā)”的思維，與產(chǎn)品和運營做更充分的溝通。主要任務(wù)是快速應(yīng)對需求端的變化，并將需求變化集中在前端，為后臺開發(fā)提供一個相對穩(wěn)定的環(huán)境。
- “后臺開發(fā)”適合采用傳統(tǒng)的“瀑布模型”，面向“獨立網(wǎng)關(guān)”進行服務(wù)開發(fā)，與終端用戶、產(chǎn)品、運營等實現(xiàn)解耦。主要是實現(xiàn)高并發(fā)，穩(wěn)定可靠的服務(wù)，從本質(zhì)上提升用戶體驗。
- 版本模式分為開發(fā)版本，內(nèi)部試用版本，生產(chǎn)版本。
- 開發(fā)版本采用內(nèi)部release的方式，接開發(fā)服務(wù)器，使用者主要是開發(fā)和測試。
- 內(nèi)部試用版本接“獨立的真實服務(wù)器”，用戶總數(shù)受控制，比如100個。iOS版本在審核期間也可以接這個版本，可以提供提供幾個“超級用戶”，方便審核人員審核。使用者主要是產(chǎn)品，運營，以及經(jīng)過篩選的“認(rèn)證用戶”，比如公司領(lǐng)導(dǎo)、外部合作商戶、內(nèi)部員工、鐵桿粉絲等等。
- 生產(chǎn)版本接“正式的生產(chǎn)服務(wù)器”，用戶比例受控制，采用“灰度發(fā)布”的方式，逐步放開用戶量。使用者主要是產(chǎn)品和運營。
- 將發(fā)布、驗證、上線三個關(guān)鍵節(jié)點在時間上錯開
流程改進
- 第一級：“瀑布模型”，分為“APP開發(fā)”和“后臺開發(fā)”兩個階段，面向“獨立網(wǎng)關(guān)”進行開發(fā)。
- “APP開發(fā)”優(yōu)先，主動應(yīng)對領(lǐng)導(dǎo)、產(chǎn)品、運營等的變更需求；讓抽象的設(shè)計盡早變成實際可用的產(chǎn)品。
- “后臺開發(fā)”待變更基本穩(wěn)定之后，基于特定的APP產(chǎn)品提供具體的實現(xiàn)，專注于高并發(fā)的處理和安全性。
- 第二級：“APP開發(fā)”實行“迭代開發(fā)”。“后臺開發(fā)”采用“瀑布模型”。
- 視覺、開發(fā)、測試、網(wǎng)關(guān)等組成“虛擬的小團隊”，指定一個負(fù)責(zé)人，面向具體業(yè)務(wù)開發(fā)。
- 人數(shù)限定在10人左右。
- 實行“每日站立會議”制度，每人限時1分鐘，講清楚（a）昨天做了什么（b）今天做什么（c）需要什么協(xié)助。
- 如果能能將“虛擬的小團隊”的座位調(diào)在一起，成立“作戰(zhàn)室”，效果會更好
- 管理工具適合迭代模型的“JIRA”
- 第三級：在一個迭代周期中，實行“瀑布模型”。分為“概要設(shè)計”（5工作日），“開發(fā)測試”（10工作日），“版本驗收&&下一版本的需求評審”（5工作日）三個階段。總時間約為4周，1月1次版本迭代?？梢院唵蔚匾栽鲁鯙槠瘘c，月末為截止點。
- “概要設(shè)計”：本階段的輸入是“評審后的交互設(shè)計”，需求已經(jīng)基本穩(wěn)定。
開發(fā)進行概要設(shè)計，在團隊內(nèi)部討論實現(xiàn)方案，對于原型中邏輯不落地的情況及時提出修改意見。
“獨立網(wǎng)關(guān)”設(shè)計API接口，能接的后臺系統(tǒng)就接上，不能接的，提供修改界面，給測試錄入測試用例數(shù)據(jù)。
測試設(shè)計測試用例，并在“獨立網(wǎng)關(guān)”上輸測試用例，創(chuàng)建Mock數(shù)據(jù)。
視覺進行頁面設(shè)計，有問題或者變更及時和開發(fā)測試溝通。
領(lǐng)導(dǎo)、產(chǎn)品、運營等需求方原則上不要再變更需求，不過實在有必要，這是最后的變更機會，這個階段變更的代價還是可接受的。- “開發(fā)測試”：開發(fā)、網(wǎng)關(guān)、測試、視覺等進入實際的執(zhí)行階段，以“虛擬小團隊”模式進行，“每日站會”也可以開展起來，團隊內(nèi)部及時溝通。
領(lǐng)導(dǎo)、產(chǎn)品、運營等需求方在這個階段不要提需求變更，給執(zhí)行團隊一段穩(wěn)定的干活時間。如果有興趣，可以參與相關(guān)“虛擬小團隊”的“每日站會”，及時了解進展?fàn)顩r，能提供相應(yīng)幫助就更好了。- “版本驗收&&下一版本的需求評審”：產(chǎn)品和運營團隊接管產(chǎn)品，進行驗收。如果條件允許，可以切換到“內(nèi)部試用真實服務(wù)器”，這取決于后臺開發(fā)狀況。根據(jù)實際產(chǎn)品體驗情況，提出下一版本的需求變更。評審下一版本的需求。
開發(fā)在這個階段做新需求的技術(shù)預(yù)研，驗收階段的hotfix，代碼重構(gòu)，歷史遺漏bug的解決等事項。為下一階段的開始做好充分的準(zhǔn)備。- 管理工具適合瀑布模型的“禪道”
獨立網(wǎng)關(guān)
APP端的API為iOS、Android、weex、H5統(tǒng)一提供數(shù)據(jù)服務(wù)
對多個后臺服務(wù)做聚合，對APP提供粗粒度的數(shù)據(jù)，以減少遠程網(wǎng)絡(luò)調(diào)用次數(shù)。比如當(dāng)前的首頁要訪問4次網(wǎng)絡(luò)，可以在這里進行“聚合”，讓APP只要一次網(wǎng)絡(luò)訪問，就能展示必要數(shù)據(jù)。
提供服務(wù)器切換功能。根據(jù)版本號，可以切換“開發(fā)服務(wù)器”，“內(nèi)部試用服務(wù)器”，“正式服務(wù)器”三種。對APP提供統(tǒng)一的訪問地址。
提供后臺配置功能，有些地方叫CMS。在開發(fā)階段，可以給測試配置測試案例，正式使用時給運營配置動態(tài)數(shù)據(jù)。
提供緩存數(shù)據(jù)服務(wù)。如果后臺服務(wù)沒好，可以在這里提供開發(fā)需要的Mock數(shù)據(jù)，讓整個流程形成閉環(huán)。
提供公共邏輯，比如安全，監(jiān)控，日志等，也可以配合后臺加鎖，加隊列，減輕數(shù)據(jù)庫訪問壓力等等。
提供“智能升降級”功能，隔離問題接口
提供流量控制開關(guān)，為“灰度發(fā)布”提供技術(shù)基礎(chǔ)
關(guān)鍵點
與傳統(tǒng)模式的核心區(qū)別是：由“后臺功能推動” 演變?yōu)?“前端需求拉動”。后臺可以延后一個或者半個周期實現(xiàn)，面向“獨立網(wǎng)關(guān)”的數(shù)據(jù)接口編程。在溝通上，大家討論的“標(biāo)的”由以前的“想法、Word文檔、交互原型、設(shè)計圖、動畫、demo... ...”轉(zhuǎn)變?yōu)椤皩崒嵲谠诘漠a(chǎn)品”（應(yīng)該說是半成品，后臺數(shù)據(jù)落地就是成品了）。
App開發(fā)和PC開發(fā)相互獨立，互不影響。PC和APP的特性不同，沒有必要強調(diào)一致，也沒有必要同步發(fā)展。
由后臺“技術(shù)驅(qū)動”，改為前臺“需求拉動”，將一個很長的技術(shù)鏈分為兩個階段，面向“獨立網(wǎng)關(guān)”這個接口編程
是中間產(chǎn)品，是半成品，并不僅僅是Mock數(shù)據(jù)。在開發(fā)服務(wù)器上，70%以上的接口都是真正接上的，只有不超過30%的新增接口，才會在“獨立網(wǎng)關(guān)”上先定義APP API，然后提供Mock數(shù)據(jù)。并且這個mock數(shù)據(jù)由測試選取“典型的測試案例”，“獨立網(wǎng)關(guān)”提供通用的key-value數(shù)據(jù)庫，以這個API的id為key，內(nèi)容就是一個json。在后期的性能提升中，這個通用的key-value數(shù)據(jù)庫還可以作為緩存服務(wù)存在。
真正的開發(fā)時間還是“2周不變”?！霸O(shè)計一周”是為了加強技術(shù)團隊內(nèi)部的溝通，包括開發(fā)之間，開發(fā)與測試之間的溝通?！膀炇找恢堋笔菫榱思訌娂夹g(shù)部門與需求部門之間的溝通。
瀑布模型優(yōu)點是風(fēng)險管控嚴(yán)格，適合后臺開發(fā)。迭代模型優(yōu)點是溝通方便，適合APP客戶端。以“獨立網(wǎng)關(guān)”為切入點，兩邊用不同的開發(fā)模型
職能型組織有利于專業(yè)技術(shù)積累。項目型組織有利于消除部門墻，利益趨向一致?！伴_發(fā)的兩周”采用項目型組織，專注于目標(biāo)的達成；“技術(shù)和驗收的兩周”采用職能型組織，重點在技術(shù)的積累。
