石頭成認為我先前對反覆週期的看法，其評論重點在於”以為「反覆週期要很短」的實踐方式，將會造成程序員為趕進度而破壞工作紀律”。石頭成對此指出，敏捷方法對程式紀律的要求其實非常高，並且強調在使用者「貼身防守」的情況下，開發紀律豈能不好。
換言之，石頭成的觀點認為關鍵在於使用者參與，只要使用者積極參與，開發者的程式「紀律」必定會好。同人認同石頭成所說的，在軟體開發過程中，使用者參與是非常重要的一件事。但卻想提醒：過於強調使用者參與而忽略開發者與使用者之間的彼此承諾，卻是足以讓整個軟體開發的活動，陷入失序，甚至造成無止盡地混亂現象，使得開發團隊無法掌控，因為他們缺乏控制混沌的紀律。
控制混沌，所仰賴的紀律並非石頭成所言的程式紀律，而是 Time-Boxing 的制衡與緩衝手法。因此，Time-Boxing 的做法在反覆式開發的過程中是不可或缺之器。雖然，誠如石頭成所強調，在強調使用者參與的開發方法中，將溝通與開發兩者分開是很奇怪的一件事，但其實 Time-Boxing 的概念，並不意味將溝通與開發分開來看。相反地，而是讓我們更有能力去調適並滿足使用者需求，而不是窮於應付使用者目前不清楚或無法確定之需求。正因為如此，Time-Boxing 與調適性規劃（adaptive planning）正是反覆演進式開發最基本的兩大實務呀。
記得同人曾與過一個專案，該專案每天早上都會召開早會以回饋專案的狀態，同時讓與會人員提出專案碰到的問題及討論出因應之策。有一次，在早會當中，有人提出一個問題，那就是下週我們即將推出一個版本，但客戶的高階主管卻要求我們必須改變報表輸出的格式。
正當大家在熱烈討論技術上該怎麼做，可以使我們快速回應這個變動時，我警覺到了客戶這個要求是不合理的，因為這個變動是結構性的改變。於是，我對客戶的這個要求提出我的質疑：
我們曾經徵詢過客戶的意見，因此在架構初期的階段，我們將報表用 Excel 的方式輸出，以方便他們的作業方式。雖然，現在客戶的高層認為應該以 PDF 的方式輸出，但此舉將改變我們報表輸出的核心架構，不管怎麼做，對我們而言都是大工程，而這個版本交付在即，加上這個需求，我們是不可能如期交付可運作的軟體的。所以，我們應該把這個需求移至下一個反覆期中，而不是在這個反覆期中，應付客戶的需求。
同人的這個意見，正是著眼於Time-Boxing的基本實務，而得到專案經理的同意，於是與客戶溝通後，將轉 PDF 的功能移到後續的反覆期中完成，也使我們如期完成該次反覆期的工作，使客戶對我們的工作成果感到滿意。這個故事也讓我們體會到了，軟體應優先完成那一部分，使用者與開發者的觀點常常是落差甚大的，但不見得使用者的意見永遠是對的。對於企業之需求及開發者採用的技術有著高度不確定的複雜系統而言，使用者的貼身防守並不見得到良好的開發結構。因為，使用者對技術及軟體架構的觀念太薄弱了，簡單的系統或許他們可以防止開發人員亂搞，對於較複雜的系統，他們可是力有未逮呀！這也就是為什麼規劃反覆期的工作內容需要 Client-Driven 及 Risk-Driven 兩種觀點的協調，而這是需要開發者與使用者之間相互溝通與調適的。
擁抱改變並不意味著混沌，在持續不斷的變動之海中，必須有一個穩定的點。因此，我們必須遵守在反覆與漸增開發方法中的一個規則：一旦某個反覆正在進行當中，外部的 stakeholder 不能改變這個反覆中的工作內容Craig Larman (2003), Agile and Iterative Development: A Manager’s Guide, Addison Wesley. Ch2.。Time-Boxing 的用意在於緩衝、在於控制風險，不讓整個開發過程中因為無窮止的不斷地改變而造成混亂而失去控制，但它更不是拒絕改變或是凍結需求，而是讓開發者集中心力把焦點放在最關鍵或最優先的問題上。換句話說，在開發過程中，Time-Boxing 可限制變動只會發生在一定的範圍中，而不讓變動太過激烈而造成開發團隊的崩解，或是尋求靜態平衡而造成一片死寂，它所追求的是處於混沌邊緣的動態平衡，使系統富有足夠的穩定與彈性。
在實務上，使用者提出一個需求，當開發者評估若不會動到軟體架構或不會影響反覆期既定目標的達成時，是可以允諾使用者的這個需求在目前的反覆期達成，否則就應將此需求納入後續的反覆中。尤其是開發者應當要小心，增加額外功能不應該影響到目前正在開發系統的完整性。特別是當軟體系統需要重構時，同時增加功能又同時改動架構其實是很容易造成軟體結構上的紊亂，因為開發者很容易弄不清楚是新功能的問題還是改動架構的問題，所以 Time-Boxing 常牽涉到技術上風險的問題，其必要性是開發團隊不可忽略的呀。
自動引用通知: 同人的生活派對 » 被遺漏的需求
自動引用通知: 同人的生活派對 » 合約與需求變更