十五章講的是穩(wěn)定和發(fā)布階段。軟件生命周期的最后階段往往是最考驗團隊的。從代碼完成到最終發(fā)布軟件，需要經(jīng)歷：完成代碼、集成測試、Bug修復、Alpha發(fā)布、DCR Bug修復、Beta發(fā)布、外部測試、RTO等。軟件團隊的各個角色代表，組成會診小組。對于每個Bug可以決定采取哪一個行動，修復、設計本來如此、不修復、推遲。對于更加復雜的香茅油，還有三個方面更高的要求：第一步，開發(fā)者提交參加會診的Bug和修改方案，以及伙伴測試結果。第二步，會議決定是否通過修改方案。第三步，執(zhí)行。DCR，設計變更，首先要知道問題在哪，問題的影響；如果不修改會有什么后果；幾種修改方案，各種方案的優(yōu)缺點和成本。接著決定DCR的執(zhí)行次序，會診所有DCR，按照影響、成本排序，得到一個自上而下的名單，根據(jù)現(xiàn)有資源，按照名單執(zhí)行。還有其他的招數(shù)：ZBB、最后的回歸測試、砍掉功能、修復Bug的門檻逐漸提高、逐步凍結。在軟件發(fā)布會，開一個會議總結，有利于發(fā)現(xiàn)軟件的問題。

十六章講的是IT行業(yè)的創(chuàng)新。發(fā)明創(chuàng)造往往伴隨的是靈光一現(xiàn)，偉大的創(chuàng)新就緊隨其后。創(chuàng)新的想法一開始并不一定會被接受，而在以往的基礎上進行的擴展或許有更好的效果。在創(chuàng)新的時候我們應該要考慮到幾點：從中能得到什么，與現(xiàn)階段的相比有什么優(yōu)勢，和目前大眾的習慣是否相符，避免過于復雜的技術。很多創(chuàng)新者卻不是最后的領導者。創(chuàng)新的招數(shù)：SWOT分析框架、動量和加速度、技術產品的發(fā)展周期、效能過剩和競爭的各個階段、四個象限劃分產品、打出組合拳和套路。

轉載于:https://www.cnblogs.com/ao2chen/p/6940455.html

總結

以上是生活随笔為你收集整理的《构建之法》7的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。