反覆週期的長短只是結果，關鍵是使用者參與程度

同人針對我的《敏捷方法實務研討會會後筆記3》寫了篇評論。確實，週期的長短並不是關鍵。因為以「日」為單位的反覆週期，是敏捷方法重視使用者參與，將使用者拉進開發工作之後，自然而然就會發生的必然結果。敏捷方法則透過密集的溝通行為，一舉將反覆式開發的週期縮短到以「工作天」為單位 (敏捷方法實務研討會會後筆記3)。

在強調使用者參與的敏捷方法中，將這兩者分開是很奇怪的事。試想，如果使用者就在開發團隊旁邊，看著開發團隊設計、測試，卻要使用者兩個星期後才回饋需求變化，這豈不怪異？當使用者就在開發團隊身旁時，看到使用介面設計不符預期設想，當然要反應變化。看到開發團隊的測試案例中，有疏漏的情況，或是資料不符實際情形時，當然也要立即反應。使用者在看到問題時，不但會立即反應，更想要儘快看到修正結果。在使用者高度參與的情形下，反覆週期自然就會縮短到以工作天為單位。反覆週期變短只是結果，關鍵是使用者參與的程度。

同人的評論重點，則是他所看到的一個反面意見，即有些人把「反覆週期要很短」當成實踐方式，以為這將造成程序員為趕進度而破壞工作紀律。這是那些人見樹不見林的印象。敏捷方法對程式紀律的要求其實非常高。為了要趕上「較短的週期」而要求 programmer 趕工而不顧程式碼的結構性，仍是大忌(敏捷編程個人感想)。再者，當使用者就在開發團隊旁邊看著時，開發成員敢亂搞一通嗎？在使用者「貼身防守」的情況下，開發紀律豈能不好。