項(xiàng)目完整流程
需求分析
-
了解背景
為什么做這個(gè)事情
-
質(zhì)疑需求是否合理
這個(gè)需求為什么要做酝碳，是否符合我們的產(chǎn)品伴网，開發(fā)也是用戶
-
需求是否閉環(huán)
需求是否考慮全面逃沿，分析功能操作前透揣，操作時(shí)和操作后所帶來的數(shù)據(jù)變化暮的，以及引起的對其他功能的影響
-
開發(fā)難度如何
最好現(xiàn)場評估開發(fā)中的難點(diǎn)之處，集思廣益
-
是否需要其他支持
考慮某個(gè)需求是否需要其他端人員的支持淌实，并提出
-
不要急于給排期
不要急于需求分析現(xiàn)場給排期，根據(jù)自己實(shí)際情況做好統(tǒng)籌兼顧
技術(shù)方案設(shè)計(jì)
-
求簡猖腕，不過度設(shè)計(jì)
做出滿足需求的基礎(chǔ)設(shè)計(jì)即可
-
產(chǎn)出文檔
更清晰設(shè)計(jì)方案中的細(xì)節(jié)拆祈，也便于之后復(fù)盤
找準(zhǔn)設(shè)計(jì)重點(diǎn)
組內(nèi)評審
和 RD CRD 溝通
發(fā)出會(huì)議結(jié)論
開發(fā)
-
如何反饋排期
預(yù)留風(fēng)險(xiǎn)時(shí)間，最好多出 1/4 時(shí)間倘感；
考慮其他插入工作
考慮其他依賴人員的排期 -
符合開發(fā)規(guī)范
git 規(guī)范
注釋規(guī)范
模塊組件規(guī)范 -
寫出開發(fā)文檔
公共 API
公共 UI 組件
公共函數(shù)方法 -
及時(shí)單元測試
單元測試是檢驗(yàn)代碼質(zhì)量的重要工具
-
Code Review
Code Review 不僅僅是去看對方的代碼寫得規(guī)不規(guī)范放坏、細(xì)節(jié)上有沒有小問題，更多的是：
- 暫時(shí)忘記對方的代碼老玛，如果讓你來實(shí)現(xiàn)這個(gè)需求淤年，你會(huì)如何設(shè)計(jì)钧敞，跟對方的設(shè)計(jì)思路一致么？差異在哪里麸粮？誰的更優(yōu)溉苛？
- 暫時(shí)忘記具體的需求（或者你原本就不知道需求），看著對方的代碼弄诲，是否能夠理解他想完成一件什么事情么愚战？他理解需求了么？他完成的好么齐遵？
其實(shí) CR 就是對設(shè)計(jì)和實(shí)現(xiàn)的再次確認(rèn)寂玲，在反復(fù)較量的過程中，相互學(xué)習(xí)和成長梗摇。如果以上兩個(gè)問題存在否定的答案拓哟，那就有必要好好寫寫 CR 評語了。
- Mock API | 模擬數(shù)據(jù)
聯(lián)調(diào)
- 和 RD CRD 技術(shù)聯(lián)調(diào)
- 讓 UE 確定視覺效果
- 讓 PM 確定產(chǎn)品功能
PM 加需求怎么辦伶授？
- 不能拒絕
- 按照公司規(guī)定断序，走流程變更流程
- 否則，項(xiàng)目組和 leader 重新評審谎砾，重新評估排期
<br />
測試
- 提測發(fā)郵件逢倍，抄送項(xiàng)目組
- 測試問題要詳細(xì)記錄
- 避免 QA 和 FE 信息不對稱，有問題要及時(shí)溝通
上線
- 上線之后及時(shí)通知 QA 回歸測試
- 上線之后及時(shí)同步給 PM 和項(xiàng)目組
- 如有問題景图，及時(shí)回滾较雕。先止損，再排查問題
