模板
教程
環境
性能
功能
管理
迭代還是交付?
在大學期間，我就是敏捷軟件開發的追捧者。像《XP Explained》、《XP Explained 2e》、《Agile Software Development》、《Pragmatic Programmer》、《Domain Driven Design》這樣的書都讀過兩遍，頗似葉公好龍。后來參加工作，將敏捷理論與中國國情相結合，也有些感悟。于是，我打算以“測試雜感”為題，從測試者的角度寫一批文章，對自己的工作進行回顧和反思。錯漏淺薄之處，還請不吝賜教。
最近一年，我都在做一個企業內用系統。該系統由多個服務組成，以Web Application的形式提供給內部用戶使用。系統每6個月發布(release)一次。一次發布一般由四個里程碑(milestone)組成。里程碑0用一個月左右的時間確定規格文檔和特性列表。里程碑1和里程碑2開發新功能。我們實施敏捷軟件開發，所使用的方法論是Scrum。于是，里程碑1和里程碑2是兩個Sprint，每一個Sprint延續4~6周，總共的開發時間是10~12周。里程碑3延續8周左右，修正已發現的問題，并為部署做一些準備工作。
那么這種開發方法是敏捷的么?
在著名的雪鳥(Snowbird)會議上，敏捷宣言的締造者們希望給宣言起一個好名字。他們最終選擇了敏捷(agile)，因為它是一個“廣告”詞匯。與會者Alistair Cockburn反對使用輕量(light)之類的詞，因為輕量意味著不重要、意味著在拳臺上被重量級的選手打得搖搖晃晃。相反，所有人都會宣稱自己是“敏捷”的，因為它讓人聯想到彪悍的肉食捕獵者、聯想到以閃電般的速度奔向勝利。這是一個人見人愛的標簽。
于是，實施某種敏捷方法的開發發團隊都會毫無例外地宣稱：我們是敏捷的。那么敏捷的核心是什么?請看敏捷聯盟所提出的首要原則(principle)：
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 我們的最高目標是，通過盡早和持續地交付有價值的軟件來滿足客戶。
我觀察到，許多開發者認為迭代是敏捷開發的核心特征。實際上，縱觀敏捷宣言和敏捷原則，大師們強調的是可工作的軟件(working software)和交付(deliver)，而不是迭代(你甚至找不到iteration這個詞)。Cockburn在《水晶方法》中指出“迭代并不提供關于軟件是否能滿足商業用途的端到端反饋”，因此他將“經常交付”作為水晶方法的首要體系特征。在他看來，“經常交付”的作用有：
項目主辦者根據團隊的工作進展獲得重要的反饋。
用戶有機會發現他們原來的需求是否是他們真正想要的，也有機會將觀察結果反饋到開發中。
開發人員打破未解決問題的死結，從而實現對重點的持續關注。
團隊得以調整開發和配置的過程，并通過完成這些工作鼓舞團隊的士氣。
那么“經常交付”的節奏有多快?再看一條敏捷原則：
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 要不斷交付可用的軟件，周期從兩三周到兩三個月不等，且越短越好。
如果a couple of months是上限，那么我們的項目以6個月為周期交付，它會導致什么問題呢?在里程碑0確定整個發布的功能列表，意味著項目經理要預測6個月之后的商業需求，意味著開發者要預測未來5個月的工作量。這不是不可能任務，但準確度也不會很高。而Robert L. Glass認為不準確的需求和估算是軟件項目的首要風險。
再考慮一個情景：大半年前發布了版本V1，剛剛發布了版本V2，現在是V3的里程碑0。由于部署的速度比較慢，用戶剛剛接觸到V2，但是本周末我們就要確定V3的功能列表。于是，V3的功能列表將更多地基于用戶對V1的反饋。這樣，用戶從體驗V1、到反饋意見、到獲得更新(V3發布)需要一年的時間。是的，一年的時間，這對于Web Application是多么的漫長。
在里程碑1和2，我們會用Sprint來實施迭代開發。每一個Sprint結束，我們都會做演示(presentation)。遺憾的是，用戶并不評審我們的演示，因此我們無法獲得他們的反饋。在里程碑3，我們會組織Bug大掃除(Bug Bash)，并邀請用戶也來尋找系統的錯誤。這對于發現歧義和界面錯誤是很有幫助的。遺憾的是，用戶使用系統的時間很短(通常只有1~2天)，我們很難獲得他們深層次的需求。即便獲得，我們也很難做出響應，因為原則上里程碑3是不允許增加新功能的。然而，排在第2位的敏捷原則是：
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 歡迎對需求提出變更——即使是在項目開發后期。要善于利用需求變更，幫助客戶獲得競爭優勢。
與大多數人的直覺相反，即便是Windows 7，也有能力在項目開發的后期做出變更。2008年底，微軟內部用戶開始試用Windows 7，即所謂的吃狗食(dog food);2009年1月，Windows 7 Beta發布;在2009年7月，Windows 7完成RTM。比較RTM版和Beta版，你會發現Windows 7在任務欄(Taskbar)等組件上增加了新功能。這表明，Windows開發團隊根據Beta版獲得的反饋，增加了新的代碼以提供更好的用戶體驗。
為什么Windows這么復雜的軟件也可以“敏捷”?《微軟的軟件測試之道》的第三章提供了一些答案。作者Alan Page參與的大多數的微軟產品都采用螺旋模式或其變體的開發模式。如下圖所示，他們也用里程碑來組織一次發布。關鍵就在那些括號中的“Beta(對應內部測試)”和“業內預覽”。“每一個里程碑發布的產品都是一個完整的產品，都可以用于大范圍的使用。”——通過每一個里程碑的內部測試和業內預覽，大型軟件開發實現了有規律的“模擬發布”，并獲得了“持續交付”所帶來的收益。
