敏捷實踐編年史(敏捷聯盟版)記錄了上世紀六十年代至今敏捷相關實踐的發展史,其英文原版材料來自於國際敏捷聯盟網站(AgileAlliance.org) ,原文連接: https://www.agilealliance.org/agile101/practices-timeline,本文由國內知名敏捷教練李潔(Jerry Li)和廖靖斌(Eric Liao)翻譯成中文版本。html
「康威定律」被提出並歸納爲:「任何組織,在設計系統(不只限於信息系統)時,產生的設計在結構上必然會複製自身組織的溝通結構。」長期以來,「康威定律」都只是被當成民間傳說,而非獲得充分論證的科研成果,儘管最近有些研究爲其提供了一些學術支持。(直到90年代中期,軟件開發的人際交互方面仍然在很大程度上爲軟件工程學術研究忽視。)程序員
Barry Boehm提出了「Wideband Delphi」估算技術,這是「計劃撲克」估算法的先驅。算法
D. Panzl的系列文章描述了具備似於JUnit特性的工具,證實自動化單元測試有着悠久的歷史。編程
Glenford Myers的著做《軟件可靠性(Software Reliability)》出版,其中闡述了一條「公理」——「不該該由開發者來測試本身的代碼」(此時還是由開發者測試的黑暗年代)。設計模式
出現了用於UNIX系統的「make」工具——自動化軟件構建的原則歷來就不是一個新主意。服務器
在Harlan Mills主編的文集中能夠發現,在IBM聯邦系統部中進行了關於增量開發的實質性討論。在Dyer的文章中明確指出「軟件工程的原則是,每一個迭代完成的功能要儘量地與其餘迭代解耦。」session
源於豐田生產系統的「可視化控制(visual control)」概念,是對「信息輻射器(information radiators)」的預期。架構
在CHI(人機交互)大會記錄中描述了,在「施樂之星」的設計期間,施樂帕克研究中心大範圍使用「人類因素測試(human factors testing)」技術,這爲可用性(usability)測試埋下了伏筆。app
Barry Boehm在項目中使用原型,以便在項目早期實驗學習,這本質上是一種迭代策略。這表面此時迭代方法已首次開始獲得認真關注,很可能是因爲諸如我的電腦和圖形用戶界面的興原由素致使的。框架
在Brodie的著做《Thinking Forth》中提出了「構造(factoring)」的概念,書中將其表述爲「把代碼組織成有用的片斷」且這件事情「發生於詳細設計和實現期間」,這是對重構的預期。
對「瀑布」順序式方法的批判早已開始,而對做爲替代物的「增量方法」的構想也正變得愈來愈突出。一個很好的例子是,早期在《軟件工程中基於知識的溝經過程》上一篇文章倡導使用增量開發,具體緣由是「不存在完整和穩定的需求規格」。
或許首個有明確命名的、用於替代「瀑布」的增量開發方法是Tom Gilb的進化交付模型(Evolutionary Delivery Model),綽號是「進化(Evo)」。
在一篇著名的文章中,Barry Boehm提出了「軟件開發和優化的螺旋模型」,一種經過合適的方法(儘管展現的「典型」例子是基於原型,但不只限於原型法)來識別和減小風險的迭代模型。
竹內和野中在哈佛商業評論發表了他們的文章《新新產品開發遊戲(The New New Product Development Game)》。這篇文章描述了一種橄欖球方法,方法中「產品開發過程是在一個精心挑選的多學科團隊的持續互動中產生的,團隊成員從頭至尾都在一塊兒工做」,這篇文章常常被引用爲Scrum框架的靈感來源。
事件驅動的圖形用戶界面軟件的興起,及其功能測試面臨的挑戰,爲Segue 和Mercury等公司開發的「捕獲和回放」類自動化測試工具提供了機會。這類工具在以後十年一致在市場佔據主導地位。
「時間盒(timebox)」被描述爲Scott Schultz的「快速迭代開發成型」法的基石,這種方法應用於杜邦公司的副業——信息工程協會。
儘管經過把對象擬人化(例如CRC技術)來推理設計問題的思想彷佛是很天然的,但仍存在着一些強大的反對者,好比Dijsktra的這篇文章《在實際計算機科學教學中的殘酷性(On the cruelty of really teaching computing science)》,看起來就好像面向對象正在打擊主流思想同樣:「在計算機科學中,擬人化的隱喻都應該被禁止」。
Ward Cunningham與Kent Beck合做的文章中描述了CRC技術。卡片上採用這種特定格式,源於Cunningham設計的應用(其用途是爲了把設計文檔存儲爲超文本卡片堆)。
在一篇ACM SIGPLAN的文章中,Bill Opdyke與Ralph Johnson創造了「重構(refactoring)」這個術語——「重構:一種在設計應用框架和進化面向對象系統中使用的輔助手段」。
黑盒(black box)測試技術仍然在測試學科中佔據主導地位,尤爲是以「捕獲和回放」測試工具的形式進行的測試技術。
因爲快速應用開發(RAD)工具和集成開發環境(IDE)的崛起,「make」類的構建工具譭譽參半。
James Martin在其著做《快速應用開發》中描述的RAD(快速應用開發)方法,或許是第一種把時間盒和迭代(較寬鬆意義上的「整個軟件開發過程的一次重複」)緊密結合在一塊兒的方法。這本書在某個章節中描述了時間盒的細節。
Taligent公司獨立開發了一個測試框架,這個測試框架與SUnit有着驚人的類似。
在一次拜訪Whitesmiths公司時,Larry Constantine創造和報道了「活力二人組(Dynamic Duo)」這個術語:「每一臺終端前有兩位程序員!固然,實際上只能由一位程序員來操做鍵盤編輯代碼,但他們兩個是並肩做戰的。」Whitesmiths公司是由P.J. Plauger建立的編譯器供應商,C語言的實現者之一,存在於1978年到1988年。
在Opdyke的文章《重構面向對象架構(Refactoring object-oriented frameworks)》中,對「重構(refactoring)」這一術語進行了全面的描述。
Wilson等人的文章《合做對實習生程序員的好處(The benefits of collaboration for student programmers)》,是一個「代表結對工做對編程任務特別有好處」的早期實證研究。在結對編程經過極限編程獲得普及以後,出於「驗證」的目的,後續又進行了更加充分的研究。
Jim Coplien 編寫了最初的站立會議模式。
「持續集成(continuous integration)」這個短語已經在使用了,並在敏捷過程這種稱呼以前就出現了這種說法。例如這一年有一篇文章把它與「計劃(scheduled)」集成進行了對比,並建議採用後者,理由是持續集成存在「缺少全面測試」的問題。這也幫助解釋了爲何自動化測試會如此受敏捷團隊的青睞,由於它是持續集成的使能器。
Jeff Sutherland發明了Scrum,並做爲過程在Easel公司使用。
Jim Coplien描述了其對「超級多產的」Borland公司Quattro Pro團隊的觀察結果,注意到他們幾乎徹底依賴於每日會議(daily meeting)「這個項目召開會議遠遠多過作其餘任何事情」,這篇文章也一樣被引用爲對Scrum有巨大的影響。
Kent Beck編寫了用於Smalltalk編程語言的SUnit測試框架。
Coplien在其早期版本的《組織模式(Organizational Patterns)》中,以程序設計模式語言的方式命名了「代碼全部權(Code Ownership)」模式,這有效影響了後來敏捷用語的發展。然而,他倡導專屬的我的代碼全部權,並提醒人們不要採用「集體代碼全部權(collective ownership)」——他把這同於根本就沒有代碼全部權。Coplien認可對「我的全部權(individual ownership」存在異議,但他認爲其模式的其餘方面可以緩解存在的問題。
Alistair Cockburn發表了文章《應用開發中人類因素的增加(Growth of human factors in application development》,提出了爲何迭代方法會逐漸被接受的主要緣由之一是:軟件開發的瓶頸正在轉向(我的和組織)學習,而且人類學習本質上是一個迭代和試錯的過程。
基於與CRC卡一樣的靈感,Ward Cunningham創造了wiki這個概念,成爲後來的維基百科的原型,這無疑是萬維網發展歷史上最具影響力的理念之一。
在最先的Scrum著做中介紹了做爲迭代(iteration)的「衝刺(sprint)」概念,然而其持續時間是可變的。
在首本描寫模式的著做——《程序設計模式語言(Pattern Languages of Program Design)》的「一種有生產力的開發過程模式語言(A Generative Development-Process Pattern Language)」章節中,Jim Coplien以Alexandrian模式風格的形式,給出了「結對開發(Developing in Pairs)」模式的簡短描述。
在1995年3月-4月版的《面向對象程序學報(the Journal of Object Oriented Program)》中,Andrew Koenig最早創造了術語「反模式(antipattern)」:「反模式就像是模式,但它並非真正的解決方案,它提供的東西只是貌似解決方案,但實際上根本不能解決問題。」
在OOPSLA大會上,Ken Schwaber和Jeff Sutherland聯合發佈了Scrum。
Steve McConnell描述了九十年代微軟公司在Windows NT 3.0上使用的「每日構建和冒煙測試(Daily Build and Smoke Test)」技術。其重點不在於自動化而在於應用頻率,即在時間上被認爲是很是「極端」的日循環。
自動化測試是極限編程的一個實踐,但並不強調對單元測試和驗收測試的區分,也沒有要特別推薦的概念或工具。
Ken Schwaber描述了「每日Scrum站會(daily scrum)」(這在其早期的著做中並未出現,例如1995年的文章《Scrum開發過程(SCRUM Development Process)》),這個活動後來被Mike Beedle從新整理成了模式形式。
在Alistair Cockburn的著做《倖存的面向對象項目(Surviving Object-Oriented Projects)》中,描述了非正式地使用敏捷實踐的幾個項目(最先能夠追溯到1993年),但並未給出敏捷的標籤,而只是歸納爲「增量工做,逐個聚焦」。
Kent Beck和Erich Gamma編寫了Junit測試工具,其靈感來自於Beck早期在SUnit上的工做。 在接下來的幾年中,它愈來愈受歡迎,並標誌着「捕獲和回放」時代的結束。
「測試先行(Test First)」被闡述爲「測試驅動(Test Driven)」,特別是在「Wiki」上。
持續集成和「每日站立會議(daily stand-up)」被列入極限編程的核心實踐。
Linda Rising在著做《模式手冊:技術、策略和應用(the patterns handbook: techniques, strategies, and applications)》中轉載了Keonig對反模式(antipattern)的定義。
《反模式——危機中軟件、架構和項目的重構(AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis)》這一著做普及了「反模式antipattern)」這個術語年。
在最先描述極限編程的文章《走向極限編程的克萊斯勒公司(Chrysler goes to Extremes)》中描述了幾個極限編程實踐,例如:自選任務(self-chosen tasks)、測試先行(test first)、三週迭代(three week iterations)、集體代碼全部權(collective code ownership)和結對編程(pair programming)。
在早期的極限編程闡述中,「系統隱喻(System Metaphor)」實踐被提出並用於解決業務與技術之間的知識轉化和認知摩擦問題,然而這個實踐難以理解和沒能推廣。
在一篇寫給《C++報道(C++ Report)》的文章中,Robert C. Martin對「迭代(iterative)」和「增量(incremental)」術語,給出了最先的、敏捷觀念的描述。
在Alan Cooper的著做《交互設計之路(The Inmates are Running the Asylum)》的某個章節中,首次描述了「用戶畫像(Personas)」實踐,基於以前的工做以「目標導向的設計(Goal-Directed design)」來構建。
Kent Beck在一篇IEEE計算機文章《使用極限編程來擁抱變化(Embracing Change with Extreme Programming)》中首次描述了「簡單設計規則(rules of simple design)」,對以前在OTUG郵件列表列表上的討論作了總結。
「重構(refactoring)」實踐,在幾年前就已經被歸入極限編程,並因爲Martin Fowler的同名著做而被普及。
Kent Beck在其著做《解析極限編程(Extreme Programming Explained)》中創造了「大可視化圖表(Big Visible Chart)」這個術語,儘管後來他把此歸結於Martin Fowler。
Ron Jeffries首次提到使用「橡皮糖熊(Gummi Bears)」代替「故事點(story points)」做爲用戶故事的估算單位。(後來此事被歸結於一個由Joseph Pelrine領導的XP項目)
Scrum的每日站立會議形式中的「三個問題(three questions)」爲極限編程團隊普遍採用。
「駕駛員(Driver)」和「領航員(Navigator)」的角色被引入以幫助解釋結對編程,已知的最先來源是一個郵件列表記錄。然而值得注意的是,這些角色的現實性一直都存有爭議,好比Sallyann Bryant的文章《結對編程與神祕的領航員角色》。
Martin Fowler的一篇文章中提供了或許能夠說是對當時可用的持續集成(continuous integration)實踐的最完整描述。
Freeman、McKinnon和Craig在他們的文章《內部測試:用模擬對象進行單元測試(Endo-Testing: Unit Testing with Mock Objects)》中描述了「模擬對象(mock objects)」測試技術,暗指 路易斯·卡羅爾的「假海龜」這一角色。
Ken Schwaber首次描述了「燃盡圖(burndown chart)」。在富達投資集團工做時,他視圖爲Scrum團隊提供一個簡單的工具包,因而發明它,並在其網站上作了正式描述。
術語「團隊速率(velocity)」添加到極限編程相對較晚,用於替代先前的、被認爲過於複雜的概念——「負載係數(load factor)」。
儘管這種實踐遠不是新起的,也不只僅侷限於敏捷團隊;但部分歸功於敏捷實踐的興起,使得「make」類自動構建得以復興。
在美國猶他州瓦薩奇山的雪鳥滑雪度假村,17位從事軟件開發或者幫助他人從事軟件開發的人相聚一堂,以在他們各自不一樣的軟件開發方法中尋找共識。這次會議的產物就是敏捷軟件開發宣言(Manifesto for Agile Software Development)。後來幾位會議成員繼續合做,成立了敏捷聯盟(Agile Alliance)。
Brian Marick,一位「上下文驅動(context-driven)」軟件測試學派的公開成員,參與了致使敏捷宣言發佈的雪鳥事件。他常常把本身描述爲團隊的「預兆測試者」,並把一些探索性測試中的實踐意識引入到敏捷社區中。
按期回顧是敏捷宣言的「團隊要按期檢討如何可以作到更有效,並相應地調整團隊的行爲(At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly)」原則的實踐之一,雖然還不是必然例行的實踐。
Mary Poppendieck的文章《精益編程(Lean Programming)》,引起了對敏捷與精益思想(以精益或「豐田生產系統」而聞名)間結構類似性的關注。
Cruise Control,是第一款「持續集成服務器(continuous integration server)」,在開源許可協議下發布。它能自動監測源代碼倉庫,觸發構建和測試過程,並把執行結果和測試報告檔案發送給開發人員。從2001-2007年能夠看到大量相似工具的出現,致使可能過分關注工具超過了關注實踐自己。
在Norm Kerth的著做《項目回顧(Project Retrospectives)》中描述的可視化手段中,「活力震盪儀(Energy Seismograph)」或許能夠視爲是「妮可-妮可日曆(niko-niko calendar)」的先驅。
Bill Wake的一篇文章指出了敏捷團隊所使用的兩種不一樣喜愛的估算——相對估算和絕對估算(relative and absolute estimation)。
「重構(Refactoring)」終於「破繭化蝶」, Martin Fowler發表言論,描述了Java語言集成開發環境中自動化重構輔助工具的普遍可用性。
在Kaner、Bach和Pettichord的著做《軟件測試經驗與教訓(Lessons Learned in Software Testing)》中介紹了一些探索測試技術的技巧,並首次提到「上下文驅動的軟件測試學派(context driven school of software testing)」。
注:三位做者的全名分別是:Cem Kaner、James Bash和Bret Pettichord。
在《極限編程實施(Extreme Programming Installed)》中描述了「快速設計會話(quick design session)」實踐。
在英國Connextra公司,發明了用戶故事的「role-feature-reason」描述形式。
Jeff Sutherland在其文章《規模化敏捷:在五家公司發明和從新發明了Scrum(Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies)》中,首次給出了「Scrum of Scrums」的描述(總結IDX公司的經驗)。
極限編程社區早期是贊同「回顧(retrospective)」實踐的,好比「XP 2001」大會上的這篇文章《適應極限編程風格(Adaptation: XP Style)》。
爲了區分「交互的(social)」用戶故事與「文檔的(documentary)」傳統需求實踐(諸如用例(use case)),Ron Jeffries提出了用戶故事的3C(Card,Conversation,Confirmation)模型。
《免疫可預見的項目失敗(Immunizing Against Predictable Project Failure)》一文被髮表,本文後來很大程度上使得定義項目章程成爲一項敏捷實踐活動。
在Alistair Cockburn的著做《敏捷軟件開發(Agile Software Development)》,出現了對敏捷項目環境中「反思研討會(reflection workshop)」的首次描述。
術語「項目回顧(Project Retrospectives)」在 Norm Kerth的同名書籍中進行了介紹。
Alistair Cockburn創造了「信息輻射器(information radiator)」這個術語,有部分的擴展隱喻,它把信息傳遞等同於熱量和睦體的發散。
Laurie Williams和Robert Kessler撰寫了《結對編程詳解(Pair Programming Illuminated) 》是專門研究結對編程實踐的第一本書,討論了迄今爲止的理論,實踐和各類研究
極限編程的發明者之一沃德·坎寧安(Ward Cunningham)發表了Fit,這是一種基於Excel表格式的驗收測試工具
Bill Wake 的早期文章提到請注意團隊內對於一些經常使用術語理解可能不一致的問題,例如「完成(Done)」
一個早期的實踐者描述了在更普遍的環境下的運用用戶畫像(personas):Jeff Patton的論文《擊中目標:將交互設計添加到敏捷軟件開發中(Hitting the Target: Adding Interaction Design to Agile Software Development)》也許是在敏捷環境下的第一個正式描述,雖然這個話題至少從2000年開始就在一些郵件組被非正式的討論過。
在將精益理念應用於軟件的早期(未發表)討論中,將未發佈的特性視爲「庫存(inventory)」,Kent Beck提到在LifeWare和幾個其餘的企業運用持續部署。然而,這個想法仍是要花幾年的時間去梳理和整理。
Scrum社區汲取了度量「團隊速度(velocity)」的實踐。
燃盡圖在Scrum社區中得到了普及,以及諸如僅僅反轉垂直方向的「燃起圖」,或者更復雜的「累積流圖(Cumulative Flow Diagram)」,這與燃起很是相似,但彷佛是一個獨立的發明。
計劃撲克的當前形式在James Grenning的一篇文章中被列出。
Rebecca Wirfs-Brock和Alan McKean經過他們關於責任驅動設計(Responsibility-driven design)的書:《對象設計:角色,責任和合做者(Object Design: Roles, Responsibilities and Collaborators)》來推廣CRC卡。
Industrial Logic的Joshua Kerievsky發表了《Industrial XP》,這是一套建議的極限編程的擴展,其中包括項目憲章活動,基本上和他們2001年文章中定義的同樣。
BDD的祖先AgileDox是一個自動從JUnit測試生成技術文檔的工具,它的做者是Chris Stevenson。
Bob Martin將Fit與Wiki(Cunningham的另外一個發明)結合在一塊兒,建立了FitNesse。
Kent Beck 在《測試驅動開發(Test Driven Development:By Example)》一書中簡要提到ATDD,但認爲這是不切實際的。儘管Kent Beck持反對意見,部分歸因於Fit / FitNesse的普及,ATDD成爲公認的作法。
Fit / FitNesse組合讓其它工具黯然失色,成爲敏捷驗收測試的主流模式。
C2 Wiki上的一篇匿名文章描述了乒乓編程(Ping-Pong Programming),這是結合結對編程和測試驅動開發的一個適度流行的變體。
早期的Scrum 培訓資料暗示了將來「完成的定義(Definition of Done)」的重要性,最初只是以幻燈片的形式:「關於完成的故事(The story of Done)」。
Mary和Tom Poppendieck的著做《精益軟件開發(Lean Software Development)》將「敏捷任務板(Agile task board)」描述爲「軟件看板系統(software kanban system)」。
Kent Beck 出版《測試驅動開發(Test Driven Development:By Example)》。
得益於XP Day大會的按期聚會,更多的團隊開始實行項目和迭代的回顧。
用於快速評估用戶故事的INVEST檢查單來自Bill Wake的一篇文章,該文章還爲用戶故事分解獲得的技術任務改寫了SMART縮寫(Specific具體的,Measurable可衡量的,Achievable可實現的,Relevant相關的,Time-boxed時間盒的)。
Mike Cohn在其網站上描述了五列任務板格式;那時候,正如比爾·維克(Bill Wake)收集的相冊展現的那樣,各式各樣的變體仍然比比皆是。
Joshua Kerievsky創造了術語「NUTs(Nebulous Units of Time,模糊的時間單位)」,做爲「故事點」的替代品。
Eric Evans提出了術語「領域驅動設計domain driven design」,並在同名著做中進行了描述,最終成爲「系統隱喻(System Metaphor)」的可行替代品。
每日會議被做爲敏捷核心實踐推廣,隨着任務板普遍使用,「在任務板前面召開每日會議」 成爲最終的關鍵指導原則。(例如Tobias Mayer 描述的那樣)
Kent Beck提出「完整團隊(Whole Team)」做爲以前名爲「現場客戶」的實踐的新名稱。
Alberto Savoia 的文章提出了「極限反饋設備(Extreme Feedback Devices)」,例如熔岩燈或專用監視器,以顯示最近一次集成的結果,這是持續集成的一個重大創新。
爲了驗證他關於弱化「測試」術語而代之以「行爲」的假設,Dan North發佈了JBehave。
INVEST首字母縮略語是Mike Cohn的著做《用戶故事與敏捷方法(User Stories applied)》中推薦的技術之一,在第二章詳細討論了這個技巧。
計劃撲克技術在Scrum社區中開始流行,這是Mike Cohn的著做《敏捷估計與規劃(Agile Estimating and Planning)》中作計劃的多個技術中的其中一個。
術語「Backlog梳理(backlog grooming)」最先記錄的使用源自Mike Cohn在「Scrum開發郵件列表上」的觀點;幾年以後,這個實踐才被更正式地描述。
首個邀請學員思考「完成的定義(definition of done)」的練習出如今Scrum培訓材料中「之後的迭代」部分。
Jeff Patton在文章《It’s All in How You Slice It》明確表達了故事地圖(story mapping)的概念,但並無給出這個名字。
幾個新的工具發佈,證明了社區在BDD上的投入,好比RSpec或者更近的Cucumber 和GivWenZen。
Jean Tabaka在她的著做《協做精解(Collaboration Explained)》一書將項目章程做爲有效協做的關鍵實踐之一; 雖然她明確地引用了《IndustrialXP》,但她的陳述與2001年的文章有所不一樣,表現出受到了其它來源的綜合影響。
North與Chris Matts合做提出了「Given-When-Then 畫布」的概念,將BDD的範圍擴展到業務分析,並將這個方法寫入了《Introducing BDD》。
Akinori Sakata在其文章中首次描述了妮可-妮可日曆(Niko-niko calendars)。
描述持續部署核心的首篇會議文章《部署生產線(Deployment Production Line)》,由Jez Humble、Chris Read和Dan North發表在Agile2006的會議記錄中,是對幾個Thoughtworks英國團隊實踐的整理成果。
Esther Derby和Diana Larsen的《敏捷回顧(Agile Retrospectives)》的出版完結了對敏捷回顧的編纂。
在那個時候,「完成的定義(Definition of Done)」已是一個徹底成熟的實踐,它做爲一個文本化的清單展現在團隊辦公室已經變得很是廣泛。
「Kanbandev」郵件列表的成立,爲受看板啓發的(Kanban-inspired)敏捷規劃實踐的提供了一個討論場所。
來自看板團隊的最先幾份實踐報告被髮布,這些團隊使用了一套特別的稱爲「看板(kanban)」的修訂方案(沒有迭代,沒有估算,持續地帶着WIP限制的任務板),其中包括來自Corbis(David Anderson)和BueTech(Arlo Belshee)的報告。
簡化的三列任務板格式(「Todo」,「Doing」,「Done」)在當時變得比原始的五列版本更流行和更標準。
Alan Cooper在敏捷2008上的主題演講,標誌着敏捷論述和交互設計之間的正式和解,很長一段時間這二者之間被認爲是存在矛盾的。Cooper是被敏捷領袖做爲「外部人士」邀請來的,他在第二年已經被認爲是「很內部的人士」。
Cem Kaner給出了「探索性測試(Exploratory Testing)」的一個新定義,反映了這種測試方法的不斷完善。
Kane Mar以「故事時間(Story Time)」做爲名稱,首先正式描述了「Backlog梳理(backlog grooming)」,並建議把它做爲一個例行會議。
Agile 2008大會專門設置了一個論壇來討論「用戶體驗(User Experience)」的相關實踐,好比可用性測試(usability testing)、用戶畫像(personas),以及紙上原型(paper prototyping)。
Jeff Patton的文章《新的用戶故事Backlog是一張地圖(The new user story backlog is a map)》圖文並茂地詳盡描述了「故事地圖(story mapping)」實踐。
雖然最初提到團隊開始使用「就緒的定義(Definition of Ready)」的時間是在年初,但第一次正式的說明彷佛是從十月開始的,而且很快就被歸入了「官方」的Scrum培訓材料。
「持續部署(continuous deployment)」實踐已經確立,儘管仍有些爭議,由於Timothy Fitz的文章《IMVU的持續部署(Continuous Deployment at IMVU)》仍然飽受評論。這篇文章不只在敏捷領域變得很是重要,並且也是近期備受關注的精益創業或DevOps的核心要素。
兩個致力於探討看板方法的實體機構成立,一個是旨在解決商業問題的「精益系統協會(Lean Systems Society)」,另外一個則是沒有那麼正式而旨在提高社區的知名度的「有限WIP協會(The Limited WIP Society)」。
Freeman 和 Pryce的著做《測試驅動的面向對象軟件開發 (Growing Object-Oriented Software Guided by Tests)》提供了一個整合「模擬對象(Mock Objects)」、「測試驅動開發(TDD)」和麪向對象設計的全面描述。
「Backlog梳理(backlog grooming)」實踐升級爲Scrum的官方元素,並歸入了《Scrum指南(the Scrum Guide)》。
James Coplien發表了文章《兩人智慧賽過一人(Two Heads are Better Than One)》,它提供告終對編程的歷史的概述,能夠追溯到20世紀80年代中期(若是不是之前的話)。
Janet Gregory和Lisa Crispin創建了對「敏捷測試(Agile Testing)」的定義,標誌着該主題的第一個簡潔的定義。