產品版本生產怎麼快起來

1、按業務場景做系統分析/系統設計,測試以設計文件為測試依據.設計文件是否符合需求,由需求的提出人也就是產品經理去校驗。

 

測試以原始需要為測試分析測試用例設計是產生設計缺陷最大的問題根源；

 

設計沒有按照業務場景設計，是程式碼實現的時候才發現業務流程跑不起來而需要導致修改設計的罪魁禍首。

 

設計沒有按照業務場景設計，所以我們們在測試期才發現原始需求就模糊在測試階段還在和產品經理討論需求。

 

2、現有核心子系統核心模組的業務知識、程式碼實現知識的沉澱，讓人先把現狀瞭解清楚。不清楚業務，不清楚現有程式碼，是開發慢（需要理解或遲遲不敢下手），是出BUG，是開發不滿足設計的罪魁禍首。

 

3、平臺提供穩定性保證機制，這樣上層子系統就少出BUG。時間主要耽誤在修補BUG。

 

4、多提供程式碼審查工具（要能做出工具必然前提是把現有版本中的BUG有徹底的分析和理解），這就BUG出的少。時間主要耽誤在修補BUG。

 

5、開發Leader在功能設計中期開始參與程式碼骨架編寫與設計，藉此手段深刻理解業務，深刻理解業務怎麼通過修改現有程式碼進行滿足，深刻理解現有程式碼怎麼小心翼翼的改才不會引出更多的麻煩錯誤。我們們現在修改一個功能莫名引起其他模組出BUG是最頭疼的。通過開發Leader的綜合經驗技術功底來保證。

 

也只有這樣，開發leader才能深刻理解業務需求，才能真正做好資料庫設計與修改管理，才能把效能隱患在前期就找到，把效能在設計期就保證了，這樣就不需要在後期花大量時間在效能優化。

 

這5步，本質上來說是通過分工，通過方法論來得到實現的，所以我們們思考問題解決問題，要用方法和機制去達到長久保證，而不是人海戰術加班戰術嚴控戰術經驗人戰術。

 

武漢做設計方法論的優化、設計與測試的一體化配合、設計與開發leader的分工配合、開發Leader和普通開發的配合、平臺的保證、業務知識/程式碼實現知識的沉澱、程式碼審查工具/現有版本BUG徹底逐條分析，這是關鍵。

 

希望大家對這些關鍵都有明確的關鍵行動、行動計劃到人到時間，只有這樣才能執行，才能達到我們們的目標。想法好，方向對，也能真正去做了才能成功。

 

在這個基礎上，再去嘗試SCRUM的一個月迭代衝刺一次、單元測試與自動化測試/同步持續測試。