前言: 對於初入職場的前端小白來說,一整個項目來了,頓時感覺壓力山大,張皇失措,也總會感到手忙腳亂。其實不用怕,拆分步驟,把每個步驟做好,做細,一切都迎刃而解,猶如順藤摸瓜般暢快淋漓。 目錄: 概念的介紹(可略) 項目分哪幾個階段(每個階段註意什麼) 如何排期 解決問題的方法 概念的介紹: PM(產 ...
前言:
對於初入職場的前端小白來說,一整個項目來了,頓時感覺壓力山大,張皇失措,也總會感到手忙腳亂。其實不用怕,拆分步驟,把每個步驟做好,做細,一切都迎刃而解,猶如順藤摸瓜般暢快淋漓。
目錄:
- 概念的介紹(可略)
- 項目分哪幾個階段(每個階段註意什麼)
- 如何排期
- 解決問題的方法
概念的介紹:
PM(產品經理)
負責需求的提出和項目的引導。PM根據產品特點和發展目標提出一定的需求,並協調各方資源投入開發。
若需求層面有不清晰的地方,應當向PM溝通確認,如:需要做什麼、希望達到什麼效果、哪些內容應重點保證、哪些效果可以適當取捨等;
RD(後端)
負責後端介面和數據邏輯。一般複雜邏輯和內部數據會交由後端處理,並通過介面與前端交互。
FE(前端)
負責Web頁面(M頁)的界面展示和用戶交互。一般樣式、交互、動效等用戶側的效果/體驗由前端負責,並通過介面與後端進行數據交互。
QA(測試)
負責整體質量把控。在開發人員開發聯調完成後,一般需要由QA進行系統性的測試,從而糾偏糾錯&查缺補漏,保證上線質量。
若QA誤提bug或誤給人員,應協助處理:若為QA環境/測試方式問題可協助定位說明、若為介面問題可協助定位轉發、若為需求理解不一致可找PM確認;
若問題已解決,應及時關閉bug,使QA可以儘早驗證。
Native(客戶端,Android&iOS)
負責客戶端APP的界面展示、用戶交互等,並向M頁提供WebView容器。轉轉APP、58APP、趕集APP等開發人員即為native開發人員,當頁面運行於這些APP中時,對應native就是瀏覽器環境的提供者,比如我們想在原聲的app中設置title就需要調用native提供的方法。
ui(用戶界面)
負責項目的頁面樣式,動畫效果的設計。
項目分哪幾個階段:
通常一個項目簡單分為 四步:
-
需求階段
• 收集需求 • 分析需求 • 產出需求 • 需求文檔 • 評審需求 • 分配資源 • 技術調研 • 評估工作量 • 制定排期 -
開發階段
• 介面評審 • 測試用例評審 • Coding • 自測 • 聯調 • 提測 -
測試階段
• 冒煙測試 • 功能測試 • 相容性測試 • 性能測試 • 回歸測試 -
上線階段
• 總結
需求階段
PM明確需求並協調好各方人力之後,一般會發起需求評審,將開發、測試等相關人員聚集在一起,闡述需求具體內容並接受反饋和建議。
需求評審主要意義在於:
- 明確需求,確保各方理解一致。避免實現過程與預期效果背道而馳。
- 風險評估,問題及早暴露。若PM預期方案中存在較大的技術問題,技術人員可在評審時予以指出,從而及早思考對策。
- 交流碰撞,方案權衡。技術人員反饋各內容實現難度和實現成本,PM權衡哪些內容優先實現,哪些內容採用替代方案,哪些內容予以捨棄。
需求評審環節FE應做的事:
閱讀、梳理需求文檔。PM一般會先發需求文檔,後進行需求評審。評審前應先閱讀好文檔,並梳理其中的疑惑點和技術難點。
明確需求。評審過程應充分理解自己所需要完成的內容,不清晰之處應向PM確認、明確。
溝通反饋。有潛在的技術問題/風險,應及時向PM反饋,使其提前思考應對/替代方案。
理解目的。理解PM此次需求的主要目的,明白需求中哪些內容應重點保證,哪些內容可以適當取捨,避免在某些棘手卻無關緊要的小功能上面浪費過多精力。
註意:
需求評審主要目的在於需求,具體實現細節應在會後相關人員自行溝通,避免耽誤其他人時間。
排期
需求明確之後,然後排期,即:預期什麼時候開始投入開發、什麼時候能達到什麼進度、什麼時候可以上線等。
開發階段
梳理需求,對整體效果進行功能拆分和模塊拆分,包括:樣式、動效、交互、數據介面、native介面、外部資源等,把功能細化。
相容性測試:多為樣式相容性。儘可能在各終端下進行測試,尤其是低端安卓機下,出現問題的可能性比較大。
測試階段
有些難點邏輯以及測試點及時和QA同學溝通,反饋
上線階段
主動把“測試用例”(也就是所有的功能點)在 重新走一遍
如何排期:
簽到活動排期.jpg
一個項目的工作量約五天,你最好把排期細化,假如你5天沒有做完,那大家會覺得你不靠譜久而久之,覺得你能力不行,如果你訂了五天,但是四天就搞定了,在同事之間大大增加信任 也會增加自己的信心,可見一個好的排期多麼重要。
通常情況下,FE需要等UI出圖然後排期,但排期前也可以做些整理
理清需求中:
依賴哪些外部資源,如:需要rd提供哪些介面、需要pm提供哪些數據(埋點、分享文案、分享圖片...)、ui圖中哪些需要切圖,如何佈局,哪部會後期可能頻繁改動,是否需要sdk新增native介面支持等等。
需要實現哪些效果,如:下拉刷新、無限載入、tab吸頂、動畫特效等
有哪些交互,如:按鈕點擊響應、下拉響應等
有哪些模塊,如:Banner模塊、分類入口模塊、商品列表模塊等
時間&風險評估
評估各模塊各功能的工作量和可能存在的風險,工作量估算為時間,風險項預留一定時間,累加得到大概的整體所需工時。
結合自身其它工作安排和其它項目進度,估算可投入新項目的時間段,得到初步排期。
推動依賴資源
對於需要依賴的外部資源,應當提前聯繫相關人員,使其提前做好準備,避免需要時缺失影響後續流程。
根據依賴資源的預期就緒時間,調整排期。
技術調研
對於需求中較不熟悉較無把握存在較大風險的內容,優先進行技術調研。
這樣,一是可以更科學地評估工作量,及早修正排期;二是可以避免無謂的支出,比如若將難題留到最後,可能會發現難題實在無法解決,不得不調整需求修改方案,導致此前開發全部都要推倒重來。
解決問題的方法
1.對於新手來講編碼中我們要關心兩件事,一,數據的變化 。二,數據變化後結構樣式的變化。
2.很多看似很棘手的問題,往往都是自己粗心所導致的比如變數名字不對啊,少打個符號,環境問
題也不容忽視,二分法要常用,簡單講就是先拿掉一部分代碼,看另一部分有沒有誤。
3.若開發過程中發現項目工作量與預期有嚴重出入,或遇到高優先順序項目介入等特殊情況,導致無法按照預期時間點完成項目內容,應當儘早向項目其他人員反饋,方便其修改時間安排。
4.事情一件一件做,最好不要多線程容易漏掉事情,專心做一件才會做的更好。
5.把每天要做的事情寫在有道或者印象筆記里,也知道哪些需要做,哪些不需要做,到最後周報也不會忘記。
6.多用google搜索,到最後你會發現google搜索的人,技術就是比百度搜索的人要好一點。
7.溝通方法很重要,在講述一個問題時要把問題的背景以及目的等說清楚,可以很快讓聽者明白你的意圖。
作者:嘿黑蝸牛
鏈接:http://www.jianshu.com/p/750d6ec53bd5
來源:簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權,非商業轉載請註明出處。