Agile History 탐방하기 - 1
1968년에서 1989년까지
나는 "Agile Saturday 9(AS9)"이라는 토요 모임에 참여 중이다.
AS9은 토요일 아침 9시에 지정된 장소에 모여서 개인의 성장을 위한 학습을 진행하는 모임이다.
모임의 지속기간은 2017년을 마무리하게 되면 2년이란 시간이 된다. AS9은 AC2라는 애자일 관련 교육에서 시작된 모임이다. AC2는 애자일 코치를 위한 교육인데 난이도에 따라 Level 1, Level 2, Level 3로 나뉘고 AS9은 Level 2를 마친 기수의 모임이다.
여하튼 AS9 의 학습이 계속되는 과정에서 정작 애자일에 대하여 제대로 알고 있지 못하다는 의문을 갖게 되었다. 나의 경우 애자일 코치로 활동을 하고 애자일 강의를 해서 개별적인 Practices에 대하여 어느 정도 알고 있다고 생각했지만 본업이 애자일이 아닌 분들에게는 잘 모를 수 있는 부분이었다. 사실 나도 제대로 알고 있다고 하기에도 무리가 있다. 또 한국에서 애자일이 어떻게 시작되었고 왜 지금의 상황에 이르렀는지도 궁금하기도 했다.
우선 한국에서 어떻게 시작되었는지 흔적을 찾기 위하여 열심히 찾아보았다. 몇 가지 숨어있던 것들을 찾을 수 있었는데 이것은 좀 더 정리되고 초창기 멤버들을 인터뷰해보고 정리해볼 생각이다.
애자일의 근본을 찾기 위하여 처음 접근은 Aglie Aliance(https://www.agilealliance.org)를 다시 들여다보는 일이었다. 분명 History에 대하여 정리했을 것이다라는 생각이었다. 역시나 어느 정도 정리는 되어 있었다. Agile Practices Timeline(https://www.agilealliance.org/agile101/practices-timeline/) 이 그것이었다. 그래서 간략하게 정리된 사항을 좀 더 구체적인 것들을 찾아가면서 따라가 보기로 했다.
이번 글을 Timeline 상의 시작점에서부터 1990년 이전의 역사를 답습한 과정에 대한 이야기이다.
1968: “Conway’s Law”
“Conway’s Law” is coined and summarized as follows: “Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.” It has long had the status of folklore rather than of well-supported scientific result, though recent studies have lent it some academic support. (The social aspects of software development remained largely ignored by academic software engineering until the mid-90’s.)
콘웨이의 법칙은 1968년도에 정리되었다는 것이다. 관련하여 자료를 찾아보니 아이디어는 1967년 멜빈 콘웨이가 발표하였고 1968년 National Symposium에서 콘웨이 법칙으로 불리게 되었다고 한다. 콘웨이 법칙은 시스템 구조는 설계하는 조직의 커뮤니케이션 구조를 닮게 된다라는 법칙으로 조직의 구조가 시스템 아키텍처에 영향을 준다는 이야기이다. 아래의 Silicon Valley Organizational Charts를 보면 이해하는데 도움이 되면 최근에는 Microsservice Architecture와 조직 구조로 많이 콘웨이 법칙이 거론되곤 한다.
1970s:
Barry Boehm proposes “Wideband Delphi”, a forerunner of Planning Poker
놀랍게도 Planning Poker 의 근원은 1970년도에 시작되었다. 추정 방식이 1970년도에 시작한 것이 아니라 많은 사람이 함께 추정하는 방식이 시작된 것이다. Wideband Delphi 의 근원은 Delphi Method 에 있다. 전문가들에 의해 추정을 합의하는 방식은 1948년 미국의 RAND연구소에서 개발되어 IT분야뿐만 아니라 군사분야 등 다양한 분야에서 사용되었다. 이 방식에서 참여자 간의 더 많은 상호 작용과 더 많은 의사소통을 포함하기 때문에 Wideband라고 불리게 되었다.
1976:
A series of articles by D. Panzl describing tools with features closely resembling those of JUnit attest to the long history of automated unit testing.
1976년에는 지금의 JUnit과 같은 자동화된 단위 테스트를 제안했었다. "Test procedures: A new approach to software verification"에서 TPL (Test Procedure Language)이라는 별도의 테스트 프로시져 언어를 통해 자동화된 단위 테스트를 코딩하는 방식을 소개하고 있다고 한다. (아직 해당 논문을 읽어 보지는 못했다. 15달러 지불 가치가 있는지 고민중... )
1976:
Publication of Software Reliability by Glenford Myers, which states as an “axiom” that “a developer should never test their own code” (Dark Ages of Developer Testing).
같은 해 글렌포드 마이어스가 "Software Reliability: Principles and Practices"이라는 저서에서 개발자는 결코 자신의 코드를 테스트해서는 안된다고 하였다. 해당 서적으로 보려고 했으나 ebook 이 제공되지 않는 관계로 현재 사용 중인 Safaribooksonline에서 찾은 "The Art of Software Testing, 3rd Edition" 란 책을 읽어보려고 한다. 해당 책을 읽고 정리하는 내역을 다른 글로 정리하고자 한다.
1977:
Creation of the “make” tool for Unix systems - the principle of automating software builds is not a new idea.
1977년에는 Daily Build 에 해당하는 자동화된 빌드에 대하여 아이디어가 제시되었다. 지금의 Continuous Integration 의 시작점이 Unix System에서의 "make" 명령어이다. 나의 경우 make를 당연히 사용하는 것으로 배웠기 때문에 이것이 CI와 연결된다는 생각을 하지 못했다. 애자일 역사를 쫓아가다 보니 이런 부분에서 매우 흥미로움을 느낄 수밖에 없다.
1980년대를 정리하기 전에 80년대를 미리 요약하면 본격적이고 구체적인 애자일의 시작이 80년대라고 말할 수 있을 것 같다. 많은 일들이 벌어진 80년대로 가보자.
1980:
Substantial discussion of incremental development in IBM’s Federal Systems Division can be found in a volume edited by Harlan Mills, ”Principles of software engineering”, specifically an article by Dyer, which recommends organizing “each increment to maximize the separation of its function(s) from function(s) in other increments”; however, the idea is still very much that of a scheduled, phased approach rather than one responsive to change.
Incremental Development에 대하여 시작된 시점은 1980년도이다. 하지만 지금의 애자일처럼 변화에 대응하는 방식이 아니라 계획적이고 단계적인 방식으로 점진적 개발을 이야기하고 있다. "Principles of software engineering" 에서는 Increment 를 Initial increment - Intermediate increment - Interim increment - Final increment 등의 4가지 단계로 설명하고 있다.
1980:
The notion of “visual control” originating in the Toyota Production System is an anticipation of “information radiators”.
애자일에 대하여 알고 있다면 Kanban Board를 들어봤을 것이다. 1980년도에 그의 기원이 되는 정보 방열판(Information radiators)이 도요타에서 사용되었다. 마침 애자일 컨설팅 김창준 대표가 진행하고 있는 애자일 키워드라는 팟캐스트에 관련하여 "정보 방열기"라고 방송이 올라왔다.
1983:
A wide range of “human factors testing” techniques foreshadowing usability testing, used at the Xerox PARC during the design of the Xerox Star, are described in the CHI conference proceedings.
1983년에는 "human factors testing"이라고 하는 Usability Testing에 대하여 이야기되기 시작하였다.
"Human Factors Testing in the Design ofXerox’s 8010 “Star” Office Workstation" 에서는 Selection Schemes Tests, Icon Shape Test, Graphics Tests 등의 사용성 테스트에 대한 이야기를 하고 있다.
1984
An early empirical study by Barry Boehm of projects using prototyping, by essence an iterative strategy, suggests that iterative approaches first started receiving serious attentionaround that time, most probably driven by factors such as the rise of personal computers and graphical user interfaces.
1984년에는 Prototyping을 하는 것이 반복적인 전략이나 제안, 반복적인 접근에서 유용하다고 이야기가 되기 시작했다. 아래의 두 가지 글을 통해 세부적인 사항을 확인할 수 있다.
Prototyping vs. specifying: A multi-project experiment
해당 글에서는 7개의 소프트웨어 팀에게 동일한 소프트웨어 버전을 개발하게 하는데 4개 팀은 일반적인 명시적 접근법(Specifying approach)을 3개의 팀에는 프로토타이핑 접근법(Prototyping approach)을 사용하게 하였고 결과를 비교하였다.
프로토타이핑 접근법을 사용한 팀이 40% 정도의 적은 코드와 45% 정도의 적은 노력을 들여서 거의 동일한 성능을 가진 제품을 만들었다는 결과를 얻었다고 한다.
Prototyping as a tool in the specification of user requirements
해당 글에서는 요구사항이 정확하지 않고 모호한 관계로 제품 생산 과정에서 요구사항에 대한 오해로 이를 수정하는데 많은 비용이 들기 때문에 프로토타이핑을 통해 모호한 요구사항을 구체화하고 수정하는데 드는 비용을 줄일 수 있다고 이야기하고 있다. 프로토 타입 개발에 드는 비용이 전체 개발 비용의 10% 미만 발생하기 때문 저렴하다고 이야기하고 있다.
1984
The notion of “factoring”, an anticipation of refactoring, is described in Brodie’s “Thinking Forth”, where it is presented as “organizing code into useful fragments” which “occurs during detailed design and implementation”.
Refactoring 에 대한 기원은 1984년에 시작되었다. Leo Brodie라는 분이 "Thinking Forth"라는 저서에서 제시하고 있다. 관련된 서적은 무료 다운로드가 가능하니 한번 받아서 읽어 보아도 좋을 것 같다. 나의 경우 마틴 파울러의 "리팩터링" 이란 책을 통하여 개념을 접하게 되었다.
1984
While criticisms of the “waterfall” sequential approach have started much earlier, formulations of alternative incremental approaches are becoming more pointed; a good example is an early paper on ”Knowledge-based communication processes in software engineering” advocating incremental development for the specific reason that “complete and stable specifications are not available”.
폭포수 방법론과 같은 순차적 접근 방법에 대한 비판이 많았지만 아직 점진적 접근법(Incremental Approache) 에 대한 지적도 많은 편이었다. 아마도 새로운 방법에 대하여 익숙치 않음과 불확실성으로 인하여 많은 지적이 있었을 것이다. 소개된 "Knowledge-based communication processes in software engineering" 에서는 Rapid Prototyping Approach 에 대한 이야기를 하고 있다.
1985
Perhaps the first explicitly named, incremental alternative to the “waterfall” approach is Tom Gilb’s Evolutionary Delivery Model, nicknamed “Evo”.
1985년에는 폭포수 모델에 대안으로 첫번째 명시적인 방법이 나왔는데 Evo 라고 불리우는 Evolutionary Delivery Model 이다. Evo 에 대한 것은 2015년에 infoq 에서 다룬 기사가 있으니 이것을 참고하는 것이 나을 것이다.
https://www.infoq.com/articles/evo-agile-value-delivery
1986
In a well-known paper, Barry Boehm presents ”A Spiral model of software development and enhancement”, an iterative model geared to identifying and reducing risks through any appropriate approaches (though the “typical” example presented is based on prototyping).
1986년에는 대학 시절 소프트웨어 공학 시간에 들었던 나선형 모델(A Spiral model) 이 등장하게 된다.
1986
Takeuchi and Nonaka publish their article ”The New New Product Development Game” in Harvard Business Review. The article describes a rugby approach where "the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish." This article is often cited as the inspiration for the Scrum framework.
타케우치 (Takeuchi)와 노나카 (Nonaka)는 하버드 비즈니스 리뷰 (Harvard Business Review)에서 "새로운 신제품 개발 게임"을 발표한다 이것은 Scrum Framework 의 영감이 되었다고 한다.
1988 to 1990:
The rise of event-driven GUI software and their specific testing challenges create an opportunity for “capture and replay” test automation tools provided by companies such as Segue or Mercury; this type of tool dominates the market for the next decade.
1988년 부터는 event-driven GUI software 에 대하여 테스트 자동화 도구가 나오기 시작했다. 기존에 unit test 도구와 달리 UX 에 대한 테스트 자동화 도구가 나온 것이다.
1988:
The “timebox” is described as a cornerstone of Scott Schultz’s “Rapid Iterative Production Prototyping” approach in use at a Du Pont spin-off, Information Engineering Associates.
1988년에 Timebox 라는 Practices 가 나왔는데 쉽게 생각하면 뽀모도르 기법을 떠올리면 된다. 짧은 주기를 가지고 신속하고 반복적으로 프로토타이핑을 하는 기법에 대하여 설명하였다. 이후 1991년에 좀 더 구체적인 Rapid Application Development 으로 발전하게 된다.
1988:
Though the idea of reasoning through design issues by anthropomorphizing objects, as in the CRC technique, may seem quite natural, it has had some formidable detractors, for instance this artlce by Dijsktra ”On the cruelty of really teaching computing science”, which appears just as object-oriented is hitting the mainstream: “in computing science the anthropomorphic metaphor should be banned”.
다익스트라가 .... 음... 이 부분은 난 그냥 넘어간다. 나중에 링크된 글을 천천히 읽어 봐야겠다.
1989:
Ward Cunningham describes the CRC technique in a joint article with Kent Beck; the specific format used for the cards derives from an application designed by Cunningham to store design documentation as a Hypercard stack.
1989년 CRC Technique 에 대하여 워드 커닝행이 켄트벡과 함께 기술하였다. CRC Card를 통해 설계하는 방법은 애자일 컨설팅 김창준 대표가 youtube 에 올려 놓은 동영상이 있다.
https://www.youtube.com/watch?v=iDZvUTXMYbg
다음 글은 90년대의 흔적을 살펴볼 예정이다. 80년도는 애자일 기원의 시대였다면 본격적인 발전은 90년대부터 인것 같다. 아마도 관련된 내용을 훨씬 많이 찾아봐야 하기 때문에 좀 걸릴듯 하다.
