敏捷交付！＝反覆式開發法

聽到很多人說：“我們在做敏捷開發，每次發布都分成多個迭代進行開發。”

可是，細問之下發現，他們在每個迭代結束時，開發的軟體無法達到“可上線”的品質要求，甚至軟體根本無法運行起來。

 

他們只關注本反覆式開發法的Story測試是否完成了，有的甚至只關注於開發活動完成了沒有。

 

可真正做到敏捷交付的話，至少要做到：

 

1. 已完成了本迭代Story的測試，並且Bug已修複並驗證通過；

2. 迴歸測試已完成，驗證之前已完成的功能沒有被破壞。

 

想要按這種方式來交付的話，而自動化測試還不完善的話，解決的方式 好象只有一個“增加測試人員的數量”。

因為每次迭代結束之後，都要做迴歸測試。那麼隨著開發的深入，已開發的功能不斷增加，迴歸的工作量也會成指數級增長。

而“增加測試人員”只是“引鳩止渴”，HR只能是拚命去招測試人員。

 

所以，要想做敏捷交付，自動化測試是必修課，而不是選修課。

 

看到這裡，你可能會認為，自己所在的團隊根本無法做到這一點。

 

那麼，我的問題是：為什麼做不到？是現在做不到，還是一直做不到？想做到這一點，要付出哪些努力？多長時間能達到？

 

你使用敏捷交付方式開發軟體，那你先回答這些問題吧！

 

 

如果想做沒有痛苦的敏捷開發，你可以開站會，拆分故事、玩撲克、建立backlog，這些都很容易，但收效不會太大。

 

你一定會遇到更困難的問題，甚至要否定你原來堅持的東西。此時，你的痛苦才顯現出來。

 

只有醫好這些痛苦，你才能享受到敏捷開發的快樂！