Agile History 탐방하기 - 2
1990년대 이야기
이전 글 : Agile History 탐방하기 - 1 : 1968년에서 1989년까지
이번 글에서는 1990년에서 1999년까지의 History를 살펴보려고 한다. 지난 글과 마찬가지로 Agile Aliance 에 있는 Timeline를 기반으로 살펴보았다.
Agile Practices Timeline
1990:
Bill Opdyke coins the term “refactoring” in an ACM SIGPLAN paper with Ralph Johnson, “Refactoring: An aid in designing application frameworks and evolving object-oriented systems”
1984년 Refactoring 의 기원인 Factoring 의 개념을 이야기하였는데 1990년에 들어서 Refactoring라는 용어를 사용하기 시작하였다. 관련된 논문을 찾아보려고 했지만 흔적만 있고 자료는 찾지 못했다. 하지만 1992년 업그레이드된 논문이 등장하니 해당 자료를 살펴보면 된다.
1990:
Testing discipline dominated by “black box” techniques, in particular in the form of “capture and replay” testing tools
1990년에는 Black Box Testing 의 기원이 시작되었다.
1990's:
Owing to the rise in popularity of RAD tools and IDEs, “make” type tools acquire a mixed reputation
1990년대에는 RAD(Rapid Application development) 툴과 IDE(Integrated development environment)가 인기를 끌면서 자동화 빌드 도구의 기원인 "make" 타입의 도구들이 좋은 평가를 받았다. Java 개발자들이 개발 도구로 eclipse 나 intelliJ를 사용하면서 maven, gradle 등을 사용하고 있는데 1977년에서 기원이 시작되었고 1990년대에 발전하여 지금에 이르렀고 다른 기술들과 결합하여 점점 편리해지고 있는 것이다.
1991
RAD, possibly the first approach in which timeboxing and “iterations” in the looser sense of “one repetition of the entire software development process” are closely combined, is described by James Martin in his ”Rapid Application Development”. This book also describes the details of the timebox in one of its chapters.
1991년 출간된 James Martin 의 "Rapid Application Development"에서 "전체 소프트웨어 개발 프로세스의 한 반복"이라는 느슨한 의미에서 "timebox" 및 "iterations"이 밀접하게 결합된 첫 번째 방법이라고 설명하고 있다고 한다. 아마도 이 책을 읽을 일이 없기 때문에 자세히 설명하지는 못한다. 다만, 1986년 Barry Boehm 의 나선형 모델과 1988년 Scott Schultz 의 “Rapid Iterative Production Prototyping” 에서의 "timebox" 가 묘사되었는데 이것이 발전된 형태라는 것이다.
1991
Independent creation of a testing framework at Taligent with striking similarities to SUnit (source)
링크된 글을 보면 매우 흥미롭다. 테스트 프레임워크의 기원에 대한 이야기인데 SUnit과 JUnit 간의 어떤 것이 기원인지 약간의 논쟁에 대한 에피소드도 포함하고 있다. 위에 링크된 글을 꼭 읽어 보길 바란다.
1992:
“Dynamic Duo” is the term coined by Larry Constantine, reporting on a visit to Whitesmiths Inc., a compiler vendor started by P.J. Plauger, one of the implementors of C: “At each terminal were two programmers! Of course, only one programmer was actually cutting code at each keyboard, but the others were peering over their shoulders.” Whitesmiths existed from 1978 to 1988.
1992년 "다이내믹 듀오"라는 남성 힙합 듀오가 아니라 짝 프로그래밍(Pair Programming)의 기원이 되는 용어가 등장하였다. 참고로 남성 힙합 듀오인 "다이내믹 듀오"는 1999년에 결성되었다. ^^
1992:
A comprehensive description of “refactoring” is presented in Opdyke’s thesis, “Refactoring object-oriented frameworks”
Refactoring에 대하여 제대로 설명하는 자료가 나왔다. "Refactoring object-oriented frameworks"에서 아래와 같은 예제를 들면서 몇 가지 기법에 대하여 소개하고 있다.
1993:
“The benefits of collaboration for student programmers” by Wilson et al. is one early empirical study indicating benefits of pairing for programming tasks specifically. Posterior studies are more abundant and driven by the desire to “validate” pair programming after it had already gained popularity through Extreme Programming.
1993년에는 Pair Programming에 대해 경험적인 검증(?) 작업이 진행되었다. 아직 Pair Programming라는 용어를 사용하지는 않았지만 이후 Extreme Programming에서 사용하게 된다. 연구에서는 1년 차 대학 수준의 컴퓨터 프로그래밍 과목에 대하여 공동 작업을 통해 문제 해결 성능을 향상하였다는 것을 확인하였다.
1993:
Jim Coplien writes the original StandUpMeeting pattern.
1993년에 Stand-Up Meeting에 대하여 소개되었다.
1993:
The phrase “continuous integration” is already in use and thus predates what will later be known as Agile processes, for instance an article written this year contrasts it with “scheduled” integration, and recommends the latter, citing “lack of thorough testing” as one issue with continuous integration; this helps explain why the automated testing favored by Agile teams is an enabler for continuous integration.
자동화된 테스트가 왜 지속적 통합의 원동력이 되는지 설명해주는 글이 작성되었다고 한다. 예정된 통합이 지속적 통합과 비교하여 "철저한 테스트 부족"이 문제가 된다라고 취지인 것 같다. 관련된 글을 찾을 수 있었으면 좋겠지만 그렇지 못했다. 그러나 어떤 이야기를 하고 있는지 충분히 알 수 있을 것이다.
1993:
Jeff Sutherland invents Scrum as a process at Easel Corporation.
마침내 Scrum 이 탄생한다. 1993년... 난 무엇을 하고 있었는가를 생각해보니 흥미롭다.
아래는 Jeff Sutherland이다.
1994:
Jim Coplien, describing his observations of the “hyperprodutive” Borland Quattro Pro team, notes their reliance on almost daily meetings: “the project was made more of meetings than anything else”; this article is also cited as a strong influence on Scrum
Daily Meeting 에 대한 효과를 설명하는 글이 작성되었다. 위의 링크를 클릭하면 "Borland Software Craftsmanship: A New Look at Process, Quality and Productivity"라는 논문을 볼 수 있다. 흥미로운 것은 "Software Craftsmanship(소프트웨어 장인정신)"라는 용어를 사용했는데 아마도 2000년 이후 애자일 History 탐방 글에서 자세한 설명을 보게 될 것이다. 논문의 내용은 Borland Quattro Pro Team 이 수행한 프로젝트에 대한 프로세스 분석이다. 논문을 다 읽어보지는 않았지만 Abstract 의 내용을 보니 8명 이하의 작은 팀으로 구성되어 주당 1000 줄 이상의 코드를 생산했고 사회화된 일상적인 회의(Daily Meeting)를 중심으로 개발 활동을 하였다는 것이다. 또 해당 팀의 프로세스는 다른 프로세스와 달리 다른 결과를 나타내고 있다고 설명하고 있다. 아무래도 해당 논문은 시간을 두고 읽어보는 게 좋을 것 같다.
1994:
Kent Beck writes the SUnit testing framework for Smalltalk (source)
켄트 벡이 SUnit testing framework for Smalltalk 에 대한 칼럼을 작성하였다. 제목 "Simple Smalltalk Testing"으로 두 페이지 분량이다.
1995
Coplien names the “Code Ownership” pattern in Pattern Languages of Program Design, in an early version of his “Organizational Patterns”, a work influential in the later development of Agile discourse. However, he endorses exclusive individual code ownership, and cautions against collective ownership which he equates to no ownership at all. Coplien admits that objections against individual ownership exist, but argues that other of his patterns mitigate those problems.
코드에 대한 공동 소유권에 대한 이야기가 1995년에 거론되었다. XP에서 이야기하고 있는 Practices 중에 Pair Programming 이 대표적인 공동 소유권에 대한 사항으로 보면 될 것이다. 나의 경우 Code Repository 사용을 필수적으로 했고 지속적으로 통합하는 작업을 당연하게 여겼기 때문에 사실 Collective Ownership라는 말을 알고 있지는 않았다. 그냥 당연한 것이라 생각했다. 그래서 이 부분을 이해하는데 솔직히 시간이 좀 걸렸다.
1995
An article by Alistair Cockburn, ”Growth of human factors in application development”, suggests one major reason why iterative approaches gradually gain acceptance: the bottleneck in software development is shifting to (individual and organizational) learning, and human learning is intrinsically an iterative, trial and error process.
아주 흥미로운 기사가 작성되었다. 일하는 방식에 대한 생각을 정리한 기사이다. 기사 내용 중에 처음으로 인상적이었던 부분은 "프로젝트는 사람으로 구성되어 있다."라고 말한 부분이다. 때문에 사람이 프로젝트의 영향을 미치고 사람에 대한 이해에 대하여 언급하고 있다. 다양성에 대한 부분에서부터 소통에 대한 부분을 언급하고 있다. 재미있는 것은 사람은 기본적으로 2가지 Mode 가 있다는 점이다. 실패 모드와 성공 모드가 그것이다. 또 사람은 비선형적이라고 말하고 있다. 실제로 공감하는 부분이다. 사람은 일을 끝내려고 성공 모드를 발휘하기도 하지만 실수나 실패를 맞이하면서 오류를 수정하려고도 한다. 때문에 실패 모드에 대하여 이해하고 방안을 갖추어야 한다. 또 비선형적이어서 사람은 일을 순차적으로 진행하지 않는다. 여러 가지 생각의 가지치기를 하면서 행동도 복잡하게 흐르게 된다. 기사에서는 몇 가지 가이드를 제시하고 있다. 한번 읽어보기를 바란다.
1995
Based on the same inspiration as CRC cards, Ward Cunningham develops the concept of a Wiki, which will later become the ancestor of Wikipedia and undoubtedly one of the most influential ideas in the history of the World Wide Web.
역사를 살펴보면 놀라운 발견을 하곤 한다. 1995년 Wiki의 개념이 와드 커닝햄에 의해 개발되었다. 오늘의 Wikipedia 이면 CRC 카드에서 영감을 얻었다고 한다.
1995
The earliest writings on Scrum introduce the notion of the “sprint” as iteration, although its duration is variable.
Scrum 에 대한 글에서 Sprint라는 용어를 사용하였다. 1~4주의 가변적인 시간을 설명하고 있다. 해당 글은 Scrum에 대하여 자세하게 설명하고 있는 초기 논문으로 보인다. 최근에 보는 Scrum 에 대한 그림과 어떻게 다른지 아래 그림을 통해 살펴보기 바란다.
1995
The pattern “Developing in Pairs” is given a brief description, in Alexandrian pattern form, in Jim Coplien’s chapter “A Generative Development-Process Pattern Language” from the first patterns book, “Pattern Languages of Program Design”.
Pair Programming 의 또 다른 이름이다. "Developing in Pairs"
1995
Andrew Koenig originally coined the term antipattern in the March - April 1995 edition of the Journal of Object Oriented Program: “An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution, but isn’t one.”
Antipattern 이란 용어가 사용되었다. 안티 패턴은 잘 알려진 패턴이지만 비효율적이거나 비생산적인 패턴을 말하는 것이다. 유사한 용어로 Code Smell 이 있다.
1995
Ken Schwaber and Jeff Sutherland co-present Scrum at the OOPSLA Conference.
OOPSLA라는 학회 콘퍼런스에서 Scrum에 대하여 발표가 이루어졌다. 역사를 추적하다 보니 Scrum에 대하여 잘 정리한 곳이 있었다.
http://agileforgrowth.com/scrum-history/
1996:
Steve McConnell describes the “Daily Build and Smoke Test” technique, used at Microsoft for Windows NT 3.0 during the 1990’s; the emphasis is not so much on the automation as on the frequency, the daily cycle being at that time considered “extreme”.
Daily Build 와 Smoke Test 에 대하여 소개가 되었다. Smoke Test 는 본격적인 테스트에 앞서서 테스트 환경과 주요 기능에 대하여 전반적인 확인을 하는 테스트이다. 요즘에는 이 용어를 사용하는 것을 듣지는 못했다. 테스트 관련하여서는 V-model 이 여전히 많이 사용되고 있다.
개인적으로는 Daily Build 의 경우 개발자 문화를 만들기 위해 가장 중요한 요소라고 생각한다. 단순하게 Build 만 하는 것이 아니라 Build 하는 과정에서 Test 자동화를 통해 확인하는 작업도 필요하다. 제품의 개발과정에서 무엇이 잘못되었는지 빠르게 확인할 수 있는 과정이 중요하다는 것이다. 물론 이를 위해서는 각 개발자가 자신이 만든 코드를 매일 통합해야한다. 즉, Continuous Integration 이 되어야 한다는 것이다.
1996:
Automated tests are a practice of Extreme Programming, without much emphasis on the distinction between unit and acceptance testing, and with no particular notation or tool recommended.
XP에서 말하고 있는 자동화된 테스트의 범위는 Unit Test 와 Acceptance Test 의 구분을 하지 않는다고 한다. 앞서 언급한 V-model 에 따르면 Unit Test 와 Acceptance Test 를 개발 단계별로 구분한다. 왜냐하면 V-model 은 Water-fall Model 을 기준으로 설명되었기 때문이다. 개발 문화별로 차이가 있겠지만 애자일을 하는 조직이라도 Unit Test 와 Acceptance Test 를 단계를 분리하여 진행하기도 하고 개발 단계에서 한번에 진행하기도 한다. XP 에서는 그 구분을 하고 있지 않으며 그것을 권장하고 있지만 반드시 그래야하는 것은 아니라고 생각한다. 나중에 기회가 되면 설명하겠지만 TDD(Test Driven Development)와 TAD(Test After Development)를 설명할 수 있을 것 같다. 일단 탐방이기 때문에 다음으로 넘어간다.
1997
Ken Schwaber describes the “daily scrum” (which does not appear in his earlier writings, such as the 1995 article “SCRUM Development Process”), this is later recast in pattern form by Mike Beedle.
사실 Daily Scrum 이란 용어와 Daily Meeting 을 아무생각없이 혼용해서 사용하고 있다. 오히려 Daily Meeting 를 많이 사용한다. 이유는 Scrum 에 대하여 사람들이 싫어하는 부분이 있어서 그런 부분도 있다. Daily Scrum 에 대하여 초기에 설명하고 있는 것에서 요즘과 다르다고 생각한 부분은 Scrum Master 가 질문하는 3가지 질문중에서 "What got in your way of completing this work?" 라고 묻는 부분이다. 해당 질문은 많이 의역이 된 것인지 다르게 바뀌어 있다. 나의 경우 어제 한 일, 오늘 할 일 그리고 현재 가지고 있는 문제사항은 무엇인지 확인한다. 아마도 시간이 지나면서 효율화 과정을 거치면서 변화했을 것으로 추정한다.
1997:
In ”Surviving Object-Oriented Projects”, Alistair Cockburn describes several projects (dating as far back as 1993) informally using the practice, but does not give it a label; he summarizes it as “Work in increments, focus after each”.
링크된 책을 읽어보지 못했다. 객체지향 프로젝트를 잘 수행하기 위해 어떻게 해야하는지에 대한 책에서 어떤 Practices 를 사용하였다고 한다. 요약된 내용을 살펴보니 일부 프로젝트에서 Iteration, Incremental Development 등에 대하여 사용한 내용을 소개하고 있다.
1997:
The testing tool JUnit is written by Beck and Gamma, inspired by Beck’s earlier work on SUnit; its growing popularity over the next few years marks the end of the “capture and replay” era.
JUnit 이 탄생하였다. 현재 JUnit 은 버전 5까지 나왔다. (http://junit.org/junit5/)
1998 to 2002:
“Test First” is elaborated into “Test Driven”, in particular on the C2.com Wiki.
Test First 는 Test Driven 으로 정교화되면서 TDD(Test Driven Development)로 불리워지게 된다.
1998:
Continuous integration and the "daily stand-up" are listed among the core practices of Extreme Programming.
CI(Continuous integration) 와 Daily Stand-up 이 XP(Extreme Programming) 의 핵심 프랙티스로 포함되었다. XP 는 공식적으로는 1999년 발표된다.
1998
Linda Rising reprints Keonig’s definition of antipattern in the The patterns handbook: techniques, strategies, and applications
The book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis popularized the term antipattern.
안티패턴에 대한 정의가 다시 사용되었다. 안티패턴은 1995년 처음 사용된 용어이다.
1998:
The earliest article about Extreme Programming, “Chrysler goes to Extremes”, describes several XP practices such as self-chosen tasks, test first, three week iterations, collective code ownership, and pair programming.
공식적인 XP 의 발표 전에 Article 에서 소개가 되었다. XP에 대한 최초의 글이므로 한번 읽어보기 바란다.
1999:
Early on in the elaboration of Extreme Programming, the “System Metaphor” practice is proposed to address the issues of business-technical translation and cognitive friction, however the practice is poorly understood and fails to catch on.
XP 에서 "System Metaphor" 를 초기에 포함하였으나 복잡한 사연이 있는데 이를 잘 정리한 글이 있으니 해당 내용을 살펴보는 것을 추천한다.
http://aeternum.egloos.com/2517525
1999:
In an article for the C++ Report, Robert C. Martin gives what is perhaps the earliest description of the Agile sense of the terms “iterative” and “incremental”.
Personas are first described in one chapter of Alan Cooper’s “The Inmates are Running the Asylum”, building on prior work in “Goal-Directed design”.
Iterative와 Incremental 에 대한 용어 설명을 사용하였고 Personas 라는 용어도 사용되었다. 페르소나는 가면극에서 사용하는 가면을 말하는데 Agile 에서는 가상의 고객을 묘사한 것을 말한다.
The “rules of simple design” are described for the first time in an IEEE Computer article by Kent Beck, “Embracing Change with Extreme Programming”, summarizing earlier discussions on the OTUG mailing list.
The practice of “refactoring”, incorporated a few years earlier into Extreme Programming, is popularized by Martin Fowler’s book of the same name.
고전으로 유명한 Refactoring 책을 통해 XP 의 리팩토링 방법이 알려졌다.
The term “Big Visible Chart” is coined by Kent Beck in “Extreme Programming Explained”, though later attributed by Beck to Martin Fowler.
Scrum Board, Kanban Board 이전에 Big Visible Chart 라고 불리워진 것 같다.
https://ronjeffries.com/xprog/articles/bigvisiblecharts/
The unit “Gummi Bears”, an alternative to “story points” for estimating user stories, is first mentioned by Ron Jeffries (later attributed to an XP project led by Joseph Pelrine).
Story Points 는 이전에 사용하던 Gummi Bears 라는 것을 대체하는 추정 방식이 되었다. 아래가 Gummi Bears 이다. ^^
1990년대는 너무 많은 변화가 발생하였다. Scrum, XP 등이 탄생하였고 대부분의 중요한 Practices 가 나타난 시기이다. 하나하나 자세히 보고 싶었지만 방대한 역사의 기록을 짧은 시간에 살펴보기 힘들어 간단하게 요약하였다.
이제 2000년대 역사를 살펴볼 예정이다. 이또한 제법 오래 걸릴것 같다.
