迭代還是交付?(2)

　　寫到這里，一個改善現有流程的方法已經自然浮現。弱化里程碑0(如果不是取消的話)，構建初始功能列表。里程碑1選擇一些功能開始迭代開發，迭代結束后發布Beta1，請用戶試用。里程碑2選擇一些功能開始開發，某些功能可能來自用戶對Beta1的反饋，迭代結束后發布Beta2，請用戶試用。里程碑3選擇少量功能開始開發，重點是處理Beta1和Beta2發現的缺陷和獲得的反饋，迭代結束后發布正式版。隨著開發流程的發展，逐漸實現“永遠的Beta版”或“無版本”的軟件。

　　然而，知行合一總是無比困難。實現上述轉變已經超出我的能力范疇。不過，從注重實效的角度，仍舊可以完成一些力所能及的工作。例如，維護一個始終可用的、反映最新開發進展的測試系統;邀請用戶代表參加Sprint演示，聽取他們的意見。另一個好消息是，組織將逐漸把發布周期縮短到3個月(最終目標是1個月)。這顯然是向敏捷邁出的重要一步。

原文轉自：http://www.kjueaiud.com