石頭成提出他對敏捷開發方法反覆週期的看法，以站在實務經驗來看，他認為兩週為一個反覆期、兩個月為一個釋出期的週期太長了，不足以擁抱改變，他認為要做到以「工作天」為反覆週期，才是「敏捷的反覆式開發過程」。
石頭成的看法讓我想到點空間的一段討論，大家探討eXtreme的中文字面意義。致力於 OOSIG 的 Open Design 理念請參見《UML精華第三版》之譯者序。的光正兄提到：
書中曾經提到一個隱喻：「將收音機的聲音轉到最大」。換言之，隨時隨地穿插Testing、Coding、Analysis、Design，甚至不再有Iteration，或者將Iteration的期間減至最小。
在Waterfall年代，我們分成R->A->D->C四個Iteration做事，慢慢地，我們用Incremental的方式將專案切成更多的Iteration。切到最細，就是XP的Daily Build、Continuous Integration。就Waterfall與XP來說，兩者恰好位於光譜的兩個極端，
這也是XP之所以eXtreme的原因。完整的光譜應該是Waterfall->RUP->XP。
或許Waterfall的問題大家早就心知肚明，況且RUP正好是XP的「先行者」，炮火就往那裡打了。
當然，光譜還是有可能繼續往右走，MDA + AOP 或許是 Candidate。
不過，關於敏捷開發方法反覆週期，我最欣賞後來 Peter Ho 大哥提出的重要觀點，他提到：
Iteration 的真諦在於 Timed-box 而非 Decomposition，重點在於 produce business values，意近「commitment」，乃制衡 Agility 與 Discipline 不可或缺之器。（或云 Risk Control）
所以我認為，開發之反覆期及交付期的「長短」並不是關鍵所在，而是在「承諾」的時間之內，交付可運作的系統。因此，開發者必須在有限的時間內開發出能為需求者創造出企業價值的軟體，而那些現在無法確定及過於枝微末節而繁瑣的部分，應等到確定之後及較晚期的反覆期再來完成。至於系統那些部分可以創造企業價值，又那些部分比較起來，優先順序不高，應擺在後面的反覆期，則是開發者與需求者溝通後的共識。
一般而言，軟體開發者及需求者，對開發系統的優先順序而言，往往有迥然不同的兩種觀點。以開發者的角度而言，應在早期的反覆期中優先開發高風險及開發困難度較高的部分，也就是風險驅動（risk-driven）；而以需求者的角度而言，應該由可以認知完成系統那些部分可以帶來最高的企業價值的客戶（或客戶的代理者－行銷或產品經理）來決定系統開發的優先順序，也就是客戶驅動（client-driven）。
然而，在軟體開發過程中，太過偏向任一觀點都是有所徧頗的。因為，客戶無法體會技術的困難度或風險，而開發者卻往往不能體會企業價值。因此，兩種的觀點必須予於融合，混合風險驅動與客戶驅動的觀點來決定開發工作的優先順序Craig Larman (2003), Agile and Iterative Development: A Manager’s Guide, Addison Wesley.。
因此，在專案管理四變數中，開發者不應調整時程、成本與品質等限制，但卻可調整規模的限制，讓進行中的反覆如期結束。這就是所謂的 Timed-box 的做法，固定反覆期的結束時間，而在此反覆做不完的部分應該移到後續的反覆，而非將反覆結束時間往後推移。這也代表著軟體開發者承諾了每一次反覆期結束就會交付一些需求者最迫切的功能出來，並且在後續的反覆期中逐步演進及增加新功能，開發的過程當中，強調因應變化的彈性但也同必須具備紀律，讓持續改善不斷地落實。
換句話說，落實持續改善要靠紀律，正如 Peter Ho 在點空間同一篇回應文章提到的：＂測試先行的效用在尋找符合需求的替代作法；重構的可貴在為了促進簡明以實現優美＂，態度上未重視紀律，要企求持續改善是不可能做到的。其實，開發的反覆週期在於讓開發者體認在於應變與紀律的節奏感，而不單只是工作的分解與切分而已，所以時間長短不是關鍵所在，有沒有承諾才是真正重要的事呀！
自動引用通知: 同人的生活派對 » Time-Boxing 於軟體反覆演進的必要性