理順軟件開發各個環節-17（開發管理-評審、覆盤及上線支持）

5.10關於評審

　　評審是研發過程（不只是開發過程）中質量控制的一種機制，所謂「三人行，必有吾師焉」，利用多人的智慧和經驗，對分析結果、方案設計、計劃、代碼等進行審覈，發現不足，澄清表達不清之處，對下一階段工做的開展進行事前質量控制。

　　評審基本是儘可能利用團隊或公司的能力，有時甚至借用外部資源。但因爲評審每每是多人蔘與的過程，提升評審效率，增強評審效果，是須要重視的。

　　據個人經驗看，評審有兩種低效的狀況：

• 評審會開成討論會，或開成頭腦風暴會，漫無邊際；
• 參會者對評審材料不熟悉，或者沒有仔細審閱，提不出問題，草草了事。

　　理想的狀況是，參會者對評審材料都已仔細審閱，並各自將疑問記錄下來，每人至少3個問題，在評審會上，按照論文答辯的形式，參會者將預先準備的問題提出，主講人逐個解答釋疑，如問題確實存在，則記錄在案。最後，形式評審結論，是按照經過評審、按照評審意見修訂後直接經過，仍是修訂後從新評審。

 

5.11項目覆盤

　　敏捷開發對項目覆盤特別重視，實際上經過項目覆盤，對當前階段的工做作一個回顧，有發生了哪些問題，遺留問題有哪些，有哪些值得發揚和保持的作法等等。

　　經過項目覆盤，分析問題背後的緣由，尋找避免發生相似問題的方案和機制；彙總遺留問題，做爲下一階段的開發任務的輸入備忘；總結經驗，造成知識庫文章或開發約定等。

　　項目覆盤機制，是團隊自我完善的成長之路。

 

5.12上線發佈技術支持

　　即便有測試團隊的測試，仍難以保證上線發佈不出差錯。這是由於線上環境和測試環境有所區別，另外，也難以作到充分的測試。

　　雖然運維人員對上線有其常規的升級方案，如測試計劃和版本回滾方案。但某些場合，仍須要開發人員在線支持，如緊急版本發佈。

　　從開發團隊的角度，支持版本上線發佈，除了人在現場外，應儘可能作到代碼的可測試性，如日誌信息，測試接口等；或支持灰度發佈功能等，這些都是利於上線發佈的技術支持。