在平常的前端項目中,咱們常常須要對需求任務進行功能點Task分解,分解Task是爲了更合理地進行開發資源分配,也是爲了更準確地對項目進行評估和管理。然而若是分配不合理的話,便會帶來許許多多的問題,致使開發及管理不順暢,甚至會致使項目延期或失敗。前端
咱們一般使用什麼方式來進行Task分解的呢?做爲一個項目的前端負責人,如何進行合理的Task分解並分配給相應的開發?做爲業務開發人員,咱們該如何安排天天的Task?當在項目中遇到問題時如何拋出問題?react
若是沒有一個合理且相對統一規範的Task分解,業務開發人員甚至不知道天天須要作什麼,遇到問題也感受無門,並且前端項目管理人員也很差對前端項目的總體進度及狀態有個很好地把控,這便給項目帶來了風險。weex
因此,咱們須要儘早地創建起適合團隊在項目開發中使用的前端Task分解參考,指導着前端團隊在項目開發中進行合理且統一的Task分解,讓前端項目開發過程更加流暢,讓項目的風險降到最低。下面分享的是本身在前端團隊中創建的Task分解的一些實踐經驗。字體
全部前端項目開發,全部的界面都聽從着結構+表現+行爲的三大組成原則。flex
結構指的是一個界面的總體骨架,從結構中,咱們能看到這個界面的全部組件元素,若是是h5項目,那麼標籤即是界面的結構組成基本單位,若是是react項目,那麼等組件即是界面的結構組成基本單位。優化
表現指的是界面結構的具體樣式展示,加上表現,咱們便能肯定這個界面最終的靜態呈現是什麼樣的,例如設置字體的大小顏色、設置按鈕的樣式、實現一個動效。設計
行爲指的是這個界面功能動態實現,例如列表的數據請求並渲染、按鈕點擊事件地響應處理等。cdn
不一樣團隊在Task分解上可能存在差別,但應統一保持一些通用原則。blog
具體的分解方式是爲了讓前端項目管理者及業務開發者在項目開發中對功能點分解達成一致。分解的粒度要保持適中,不能過粗也不能過細。若是太粗的話,在項目開始前,不利於項目的任務分配,在開發中,不利於觀察項目的進度和狀態。若是太細的話,則會增大項目管理者及業務開發者對Task的管理成本,反而會影響到具體的開發任務。vps
按照前端的特性,我是按照一個界面(由結構+表現+行爲組成個體)爲基本單位來進行Task劃分。
一、對一個界面來講,先以界面的靜態呈現爲一個維度來進行劃分,將結構+表現的實現做爲一個Task,若是界面有交互效果實現,則將交互效果的實現做爲一個Task。
二、而後以界面的行爲實現爲一個維度來進行劃分,將該界面的前端業務功能實現做爲一個Task,將接口聯調做爲一個Task,若是還有第三方依賴,例如跨平臺應用開發,須要原生提供相應功能,則將第三方依賴做爲一個Task。
項目需求
實現豆果美食學烘焙中的精華模塊。包含三個界面,精華文章列表界面,發帖界面和文章詳情界面。
UI設計圖
Task分解
將精華模塊按照以下方式分解後,並進行對應Task的開發評估。
精華模塊包含三個界面,分別對三個界面進行Task分解,下面對精華文章列表頁的分解進行詳細解釋。
對於精華文章列表頁,按照界面展示來分解,能夠將精華文章總體界面結構+表現實現做爲一個Task,能夠分配給擅長UI繪製的人員,評估開發時間爲1人天。
將精華文章動效處理-列表滑動控制界面元素做爲一個Task,讓開發人員對動效的處理更聚焦且用心,評估開發時間爲0.5人天。
將文章列表頁的業務功能實現做爲一個Task,業務功能實現能夠分配給另外的人來作,評估開發時間爲1人天。
將列表頁的接口聯調做爲一個Task,當接口不支持聯調時,Task則轉化成問題,放入問題列表中進行跟蹤,評估時間爲0.5人天。
將看大圖功能調用做爲一個Task,假設列表頁的實現是經過跨平臺技術(rn、weex)來實現,看大圖功能由原生提供,一樣,若是原生不能按時提供,一樣也做爲問題放入問題列表中由前端項目管理者統一監控。
由上可看出,Task的劃分合理起到的做用仍是很大的。既有利於資源的合理分配,又能提升項目開發中的規範流程,並且還有利於前端項目的管理。當在團隊中推行Task分解規範的時候,最重要的仍是要基於本身團隊,要與團隊成員進行充分溝通和指導,一塊兒高效地完成前端項目任務。