2007년 09월 30일
애자일 선언
애자일 선언을 위키백과와 애자일 선언 홈페이지의 내용을 참고하여 번역해 올립니다.
http://en.wikipedia.org/wiki/Agile_Manifesto
http://agilemanifesto.org/
---------------
애자일 선언은 애자일 소프트웨어 개발의 토대를 강화하는 원칙을 발표한 것이다. 초안은 2001년 2월 11일에서 13일까지 유타의 워새치산맥에 있는 스노우버드 스키 리조트 라운지에서 만들어졌다. 여기에서 기존의 무거운 방법론보다 가벼운 대체방법론들의 필요성에 대해 토의하고자 Extreme Programming, Scrum, DSDM, AdaptiveSoftware Development, Crystal, Feature Driven Development, Pragmaticprogramming 같은 다양한 새 방법론의 대표자들이 만났다.
---------------
Manifesto for Agile Software Development
애자일 소프트웨어 개발에 대한 선언
We are uncovering better ways of developing software by doing it and helping others do it.
우리는 소프트웨어를 개발하는 더 나은 방법을, 직접 실천하고 다른 이들을 도우면서 밝혀내고 있다.
Through this work we have come to value:
이 작업을 하는 동안 우리는 다음을 가치있게 여기게 되었다.
- Individuals and interactions over processes and tools
프로세스나 도구에 앞서 개인과 상호 작용을
- Working software over comprehensive documentation
포괄적인 문서화에 앞서 작동하는 소프트웨어를
Customer collaboration over contract negotiation
계약 협상에 앞서 고객과의 협력을
Responding to change over following a plan
계획 준수에 앞서 변화에 대한 대응을
That is, while there is value in the items on the right, we value the items on the left more.
우리는 왼쪽 항목의 가치를 인정하면서도 오른쪽 항목을 더 중요하게 여긴다.
Kent Beck, Mike Beedle, Arie van Bennekum,
Alistair Cockburn, Ward Cunningham, Martin Fowler,
James Grenning, Jim Highsmith, Andrew Hunt,
Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber,
Jeff Sutherland, Dave Thomas
-----------------------------------------------------------------------------------
Principles behind the Agile Manifesto
애자일 선언의 배경 원칙들
We follow these principles:
우리는 다음 원칙들을 따른다:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
가치있는 소프트웨어를 조기에 그리고 지속적으로 인도해 고객을 만족시키는 것을 가장 우선으로 여긴다.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
개발 후반이라고 해도 요구사항의 변경을 환영한다. 애자일 프로세스는 변경을 고객의 경쟁적 우위 요인으로 삼는다.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
작동하는 소프트웨어를 수 주에서 수 개월의 주기로 자주, 가능한 더 짧은 기간에 인도한다.
Business people and developers must work together daily throughout the project.
프로젝트 기간 내내 업무 전문가와 개발자가 매일 함께 일해야 한다.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
동기부여된 개인을 중심으로 프로젝트를 구축하라. 그들에게 필요한 환경과 지원을 제공하고 업무를 완수할 것으로 믿어라.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
개발팀에게 그리고 팀 내에서 정보를 전파하는 가장 효율적이고도 효과적인 방법은 얼굴을 직접 보고 대화하는 것이다.
Working software is the primary measure of progress.
작동하는 소프트웨어가 진도를 측정하는 제 1 척도이다.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
애자일 프로세스는 지속할 수 있는 개발을 장려한다. 후원자들과 개발자들과 사용자들은 일정한 보폭을 끝까지 유지할 수 있어야 한다.
Continuous attention to technical excellence and good design enhances agility.
기술적 탁월함과 좋은 설계에 대한 끊임없는 관심은 기민성을 강화한다.
Simplicity--the art of maximizing the amount of work not done--is essential.
단순함, 안 해도 되는 일은 최대한 안 하게 하는 기교, 이것이 핵심이다.
The best architectures, requirements, and designs emerge from self-organizing teams.
최고의 아키텍쳐와 요구사항과 설계는 자기 조직화된 팀에서 나온다.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
팀은 정기적으로 더 효과적으로 일할 수 있는 방법을 숙고하고 그에 따라 자신의 행동을 조율하고 수정한다.
--------
2009/3/11 : Toby님의 지적에 따라 잘못된 번역을 수정하고 몇몇 문장을 손 봤습니다.
2009/4/2 : 문서가 망가져서 일부 다시 번역했습니다.
2010/11/23: 번역을 다듬고 오역을 수정함
# by | 2007/09/30 01:08 | 프로그래밍 이야기 | 트랙백(1) | 핑백(6) | 덧글(3)
![[수입] 요요 마가 연주한 엔니오 모리코네 [CD+DVD 듀얼 디스크]](http://image.aladdin.co.kr/coveretc/music/coveroff/2592437362_1.jpg)
![[SACD] 조수미 (Sumi Jo) - Journey To Baroque (바로크로의 여행)](http://image.aladdin.co.kr/coveretc/music/coveroff/1011203995_1.jpg)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
제목 : 애자일 선언
공부 중...more
... * Evolve to continuously obtain feedback and improve / 지속적으로 피드백을 얻고 개선시키기 위해 진화한다. 위의 철학에서 애자일 선언을 어떻게 OpenUP의 언어로 표현했는지 한번 비교해 보시는 것이 좋을 듯 합니다. OpenUP가 XP나 스크럼 보다 공부에 도움이 되는 것은 구체적인 프로세스와 산출 ... more
... 노출타이밍을 위한 예약 등록인지는 잘 모르겠지만)에 올렸다. 애자일 선언은 사실 그 원리(Principles behind the Agile Manifesto : 번역은 여기서)와 함께 이해되어져야지 그 선언만 가지고는 오해하기 쉽다고 생각된다.   Ron Jeffries는 처음 애자일 선언이 만들어지던 때를 회상하면서 그 참 ... more
... 42%, 열에 여섯은 실패한다는 얘기다. 3. 요구사항 변경관리에 소홀하기 쉽다. 애자일의 가치인 "문서보다 실행되는 소프트웨어를" 때문에 잦은 릴리스, 빠른 프로토타입의 중요성이 높아졌다. 문제는 기획(요구사항) 문서만 잘 ... more
... 리를 위해 만들어진 것이라고 합니다. 2001년 2월, 17명의 IT전문가들이 모여서 2박 3일간의 토론 끝에 애자일 선언문이라는 것을 발표하면서 시작되었다고 하죠. 지인이 책을 한권 추천해줘서 익스트림 프로그래밍이라 ... more
... designs emerge from self-organizing teams. (최고의 아키텍쳐와 요구사항과 설계는 자율적인 팀에서 나온다.) http://gyumee.egloos.com/1021784 규모에 상관없이 중요한 조언임을 기억하고 싶다. 분석과 설계가 잘 지켜지지 않기 때문에 추진하는 일들이 자칫 자율성을 망치지 않을까 하 ... more
... rge from self-organizing teams. (최고의 아키텍쳐와 요구사항과 설계는 자율적인 팀에서 나온다.)http://gyumee.egloos.com/1021784 회사 규모에 상관없이 중요한 조언이다.회사 전체적으로 추진하는 일들이 해당 조직의 자율성을 유지하면서 유익하게 ... more
님의 훌륭한 번역을 보고 12가지 원칙을 제 나름대로 약간 변용하여 해석해 보았습니다. (제가 이해한 부분을 정리하는 차원에서)
참고로 말씀드리면
⑴ 유용한 소프트웨어를 조속히 그리고 지속적으로 내 놓아 고객을 만족시키는 것이 우선순위 넘버 원이다.
⑵ 고객의 경쟁 우위를 위해 애자일 프로세스는 변경을 이용한다. 개발 후반이라 해도 변경 요청을 환영한다.
⑶ 가능한 한 짧은 간격으로 빈번하게 실제로 작동하는 소프트웨어를 내 놓는다. (인도 주기 : 2주 ~ 2개월)
⑷ 프로젝트 기간 내내 현업 담당자와 개발자가 날이면 날마다 함께 일해야 한다.
⑸ 의욕적인 사람들 위주로 프로젝트 팀을 구성한다. 그들에게 환경을 제공하고 필요한 것들을 챙겨주고, 제대로 구실할 것으로 믿는다.
⑹ 가장 좋은 커뮤니케이션 방법은 얼굴을 맞대고 이야기 하는 것이다. (이해담당자의 의견 또는 프로젝트 팀 내에서 정보를 전파하는 가장 효율적이고도 효과적인 방법은 면담이다.)
⑺ 진척도 파악을 위한 으뜸 척도는 바로 “작동하는 소프트웨어” 그 자체이다.
⑻ 애자일 프로세스는 지속 가능한 개발을 장려한다. 후원자들, 개발자들, 사용자들 모두 페이스를 꾸준하게 유지할 수 있어야 한다.
⑼ 기술적 탁월함과 좋은 설계에 대해 항상 주의를 기울임으로써 (날씬함과 샤프함을 유지하여) Agility를 강화한다.
⑽ 단순함 - 쓸데없는 일을 최대한 줄이는 기교 - 이것이 핵심이다
⑾ 최고의 아키텍처와 요구사항, 설계는 자율적인 팀에서 나온다.
⑿ 최고의 아키텍처와 요구사항, 설계는 자율적인 팀에서 나온다. 팀은 정기적인 돌아보기를 통해 어떻게 하면 더 효과적으로 일할 수 있을지 논의하고 그에 따라 향후 팀 활동을 튜닝한다.
이상입니다. (아무래도 의역이 필요한 듯 해서..)
⑿ 팀은 정기적인 돌아보기를 통해 어떻게 하면 더 효과적으로 일할 수 있을지 논의하고 그에 따라 향후 팀 활동을 튜닝한다.
-> 매 반복이 끝날 때, 반복 돌아보기(Iteration Retrospective)를 수행한다는 점을 감안하여, 약간 의역했던 겁니다.