App的開發過程（轉載）

來源：https://www.cnblogs.com/sanwenyu/p/7234616.html

不一樣的項目管理模式或許會有徹底不一樣的流程步驟。可是專業性幾乎是保證產品質量的惟一準則。

App的開發過程主要分爲如下階段，本文會按順序爲你們簡單地說明：

一、需求梳理、分析

二、產品原型圖繪製

三、UI 設計

四、項目經理 & 技術負責人對接需求

五、技術方案 & 架構設計

六、項目排期 & 任務分解

七、產品研發階段

八、交付測試階段

九、最後，按原計劃上線

第一步：需求梳理、分析

針對這個idea來一場從內到外的洗禮，在此假設用戶需求分析已經肯定 , 接下來根據提煉的真實用戶需求來肯定產品需求。

產品經理將會根據溝通中的相關資料的word、ppt、jpg等等東西翻譯成邏輯語言，最簡單的就是產出一張產品功能腦圖或者一份功能列表。

產品功能腦圖

一份功能列表

第二步：產品原型圖繪製

初步產品功能需求梳理清楚以後，產品經理持續跟進，反覆溝通肯定產品原型圖。

PS：咱們出通常是全局流的圖，程序員哥哥們比較喜歡（白眼）。

產品原型圖

同時根據具體的項目需求，會搭配一套產品業務流程的泳道圖：

產品業務流程的泳道圖

常規的是用axure出一份帶簡單交互的原型：

簡單交互的原型

簡單點，用墨刀作一份帶交互的原型。

墨刀帶交互的原型

第三步：UI設計

UI設計，包含風格稿和內頁設計。

風格稿會根據產品需求提供的目標用戶類型、客戶傾向、LOGO等信息，以及肯定作風格稿的2-3個頁面的原型圖，來進行風格稿設計。

待風格稿確認後進行內頁設計，包括設計效果、頁面元素、彈出頁面等等。

風格稿

風格稿

全部頁面設計完後會統一發給客戶作進一步溝通，而後統一修改優化。

Zeplin

Zeplin可以幫助前端更好地理解設計師意圖，而設計師又能快速獲得前端反饋的協做，從而減小設計師與前端的溝通錯位，使得二者在「界面元素」和「交互動做」上造成一致。

Zeplin

invision用於設計先行能減小後端技術工程問題，設計的迭代越快，軟件開發就越能在時間點的把控上作到極簡。

invision

設計定稿後並非設計師的工做結束了，以後還有一段週期的切圖、標註工做 。

標註

切圖

sketch

多維度運用zeplin、sketch、invision等等協做工具從細節上詮釋產品開發的每個產品需求，在時間上保證高效，在結果上保證了產品技術層面與設計層面的完美融合以及項目的高效進度和最後的優質呈現。

第四步：項目經理&技術負責人對接需求

項目經理對接上這些需求，第一個工做是細化需求，將這些翻譯成技術能更好理解地語言，搭配着原型圖或設計稿來召開技術會議，統一講解新項目的需求。

細化需求

第五步：技術方案 & 架構設計

技術負責人在清楚瞭解整個項目的需求以後會開始構思整個項目的技術方案，根據產品需求，提供易擴展、可持續迭代的技術框架方案。

整個項目的技術方案

可持續迭代的技術框架方案

第六步：項目排期 & 任務分解

同時，項目經理在和研發團隊溝通確認後對項目進行分解以及排期，以此來保證項目進度和質量。

項目管理

第七步：產品研發階段

這個階段就是各端技術按照排期規劃開始編碼，期間各類對接、調試以及撕逼。我不是程序猿，這塊就很少寫了，貼幾張他們技術wiki的截圖吧。

Wiki對接

Wiki對接

Paw 讓測試 API 變得輕鬆愉悅，能夠構建內部和外部的資源。它能夠在不一樣的環境下進行測試，也能夠引用來自其餘請求響應的數據。

PAW

它能夠定義不一樣的環境，因而能夠輕鬆地在開發、臨時和生產環境中進行切換，而無需從新配置任何端點（endpoint）。而且還能夠在一個請求的消息體中引用另外一個請求中返回的值，這可以節省大量時間。

第八步：交付測試階段

測試工程師基本全程跟進，從最先期對接完詳細產品需求以後就開始編寫測試用例：

測試用例

而後配合項目各個里程碑節點進行功能測試和性能測試，將問題按優先級劃分統一反饋：

測試過程