애자일 소프트웨어 개발 선언

애자일 소프트웨어 개발 선언

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

Kent Beck           James Grenning  Robert C. Martin
Mike Beedle         Jim Highsmith   Steve Mellor
Arie van Bennekum   Andrew Hunt     Ken Schwaber
Alistair Cockburn   Ron Jeffries    Jeff Sutherland
Ward Cunningham     Jon Kern        Dave Thomas
Martin Fowler       Brian Marick

© 2001, 상기 저자들
이 선언문은 어떤 형태로든 자유로이 복사할 수 있지만,
본 고지와 함께 전문으로서만 가능하다.

From: 앤디 헌트의 인터뷰

고객들과 우리가 속도에 대한 공감을 가지도록 고객을 훈련하는 것도 중요합니다. 일단 고객들이 이것을 깨우치게 되면 그 후에 "그건 일정이 많이 소요될 것입니다. 그 기간 동안 다른 것을 하거나 그 일을 분할해서 수행해도 될까요? 어떻게 결정하는 것이 좋을까요?"와 같은 의견을 제시해야 합니다.

무슨 수를 쓰더라도 반드시 고객을 훈련시켜야 합니다. 애자일에서 말하는 "고객과 가까이서 일하라"는 말은 바로 이런 의미입니다. 즉, "고객의 신임을 얻어라"라는 뜻입니다. 우리가 어떻게 일하는지, 어느 정도 속도로 일하는지, 우리 팀의 업무 처리 속도는 어느 정도인지 고객으로 하여금 보게 해야 합니다. 우리의 능력에 합당한 기대를 가지도록 해야 하죠.

이러한 관계 형성을 통해 적대적인 협상을 피할 수 있습니다. "자, 우리 모두는 당신 회사가 많은 돈을 벌고 성공하기를 바랍니다. 그렇지 않으면 우리 모두 먹고 살 길이 힘들어집니다. 그럼, 이 문제는 어떻게 해결해 나갈까요?"와 같은 공동의 목적을 가지고 협조적인 분위기에서 문제의 해결책을 찾아 나갈 수 있게 됩니다. 1

From: Robert C. Martin 트위터

From: 리팩토링 데이터베이스

이전에 뭐라고 들었든 상관없이, 진화적이고 애자일한 기술은 단순한 "일단 짜보고 고치기(code-and-fix)"2의 새로운 이름이 아니다. 여전히 시스템을 구축하기 이전에 요구사항을 찾아내야 하고 아키텍처와 디자인을 처음부터 끝까지 깊이 생각해야 한다. 그리고 이렇게 하는 한 가지 좋은 방법은 코딩하기 전에 먼저 모델링을 하는 것이다.

– 리팩토링 데이터베이스. 1.2 진화적 데이터 모델링에서 인용

From: UML과 패턴의 적용

Agile 방법과 자세는 무엇인가?

Agile 개발 방법은 일반적으로 고정된 기간 안에 반복적이고 진화적인 개발을 적용하고, 수행 가능한 계획을 세우며, 점진적인 제품의 인도를 장려하고, 다른 중요한 것들과 함께 변경에 신속하고 유연하게 대응하는 기민성(agility)을 권장하는 실행기술들을 갖는다.

상세한 실행기술은 매우 다양하기 때문에 Agile 방법론을 정확하게 정의하는 것은 어렵다. 그러나 계획, 요구사항, 설계가 진화되고 정제되는 짧은 고정된 시간 동안의 Iteration은 모든 방법론이 갖는 기본적인 실행기술이다. 이에 더하여, 단순함, 민첩성, 의사소통, 스스로 조직하는 팀(self-organizing team) 등에 대한 기민한 감각을 반영하는 실행기술이나 원칙을 장려한다.

– UML과 패턴의 적용. 2장. 58쪽.

Agile 모델링이란 무엇인가?

숙련된 분석가와 모델러는 다음과 같은 모델링의 비밀을 알고 있다.

(UML 등의 도안을 통한) 모델링의 목적은 주로 문서화하는 것이 아니라 이해하기 위한 것이다.

다시 말해, 모델링의 실제 활동은 문제나 해결 영역을 잘 이해할 수 있는 방법을 제공할 수 있고 제공해야 한다.

– UML과 패턴의 적용. 2장. 59쪽.

이후, 크레이그 라만은 "Agile Modeling"에 나오는 실행기술과 가치를 소개한다. 요약해 옮겨본다.

  • Agile 방법론을 채택한다고 해서 다른 모델링 방법을 사용하지 않는 것은 아니다. 그것은 잘못된 이해이다.
  • 모델링의 목적은 주로 이해하고 의사소통하기 위한 것다. 문서화가 아니다.
  • 소프트웨어 설계의 대부분을 모델링하거나 UML 를 적용하지 말 것.
    • 간단한 설계 문제는 프로그래밍 단계까지 미루자.
    • 일반적이지 않으며, 어렵고, 다루기 힘든 부분을 모델링하고 UML을 적용하라.
  • 가장 간단한 도구를 사용하라.
    • 화이트 보드같은 빠른 입력과 변경이 가능한 간단한 도구를 고려할 수 있다.
    • 핵심 원칙은 무슨 기술이건 간에 사용하기 쉽고 기민해야 한다는 것.
  • 혼자서 모델링하지 마라.
    • 둘이나 셋이서 이해한 것을 공유하면서 화이트보드에 모델링하라.
  • 병렬로 모델링하라.
    • 예를 들어 한 화이트보드에 동적인 시각의 UML 인터렉션 다이어그램을 스케치하고, 다른 보드에 이를 보충하는 정적인 시각의 클래스 다이어그램을 스케치.
  • 화이트보드에 펜으로 스케치할 때는 "충분함"이라는 간단한 표기를 사용하라.
    • 다이어그램을 상세하게 그리는 것은 중요하지 않다.
  • 모든 모델은 부정확할 것이고, 마지막 코드와 설계는 모델과도 다를 것이다. 테스트된 코드만이 실제 설계를 보여준다.
    • 모든 초기 다이어그램은 한 번 보고 버릴 것으로 가볍게 다룬다.
  • 다른 프로그래머를 위한 다이어그램을 만들지 말고, 개발자 스스로를 위해 객체 설계 모델링을 해야 한다.

From: 엔터프라이즈 애플리케이션 아키텍처 패턴

한 가지 다행인 것은 영구적인 결정이란 없다는 것이다. 아키텍처 리팩터링은 힘들고 예기치 못한 비용이 많이 들지만 불가능한 것은 아니다. 이 경우 여러분에게 해줄 수 있는 가장 좋은 조언은 익스트림 프로그래밍 전체가 마음에 들지는 않더라도 지속적 통합, 테스트 주도 개발, 리팩터링이라는 세 가지 기술적 기법은 진지하게 고려해보라는 것이다. 이러한 기법이 만병통치약은 아니지만 마음을 바꿀 필요가 있을 때 해야 할 일을 훨씬 쉽게 만들어준다. 그리고 여러분이 필자가 만난 그 누구보다 운과 실력이 좋은 사람이 아니라면 이러한 기법이 반드시 필요할 것이다.

– 엔터프라이즈 아키텍처 패턴. 8장 종합. 102쪽.

From: 데브옵스 핸드북

애자일 선언문에 대해.

애자일 매니페스토(Agile Manifesto)는 2001년 소프트웨어 개발 분야의 선도적인 사상가 17명에 의해 탄생했다. 이들은 폭포수 개발(waterfall development)과 같은 중량 소프트웨어 개발 프로세스나 래셔널 통합 프로세스(Rational Unified Process)와 같은 방법론과는 다른, 가벼운 가치 체계와 원칙을 만들고자 했다.

애자일의 핵심 원칙은 "동작하는 소프트웨어를 몇 주 또는 몇 개월의 짧은 기간 동안 자주 출시"하는 것으로 대규모의 폭포수 방식의 출시 대신 소규모 배치 및 증가분 출시(incremental release)에 대한 열망을 강조했다. 다른 원칙들은 고신뢰성 관리 모델에서 자발적으로 일하는 소규모 팀의 필요성을 강조했다.

애자일은 많은 개발 조직의 생산성을 획기적으로 향상시킨 것으로 평가된다.

– 데브옵스 핸드북. 43쪽.

애자일 운동에 대해.

애자일 운동은 2001년에 시작됐다. 애자일 선언문은 폭포수 개발 방법과 같은 중량 소프트웨어 개발 프로세스와 RUP(Rational Unified Process)와 같은 방법론에 맞서기 위해 만들어졌다. 애자일 선언문은 DP와 DSDM과 같은 경량 방법론으로의 전환보다 광범위한 목표를 갖고 있는 소프트웨어 개발 분야의 저명한 사상가 17명에 의해 작성됐다.

애자일의 핵심 원칙은 "2주에서 2달 사이에 동작하는 소프트웨어를 자주 전달하고 더 짧은 시간 간격을 선호하는 것"이다. 소규모이면서 스스로 동기를 부여하는 팀과 높은 신뢰를 갖는 관리 모델에서 작업하는 원칙과 같은 크기의 배치 작업을 강조하는 원칙이 있다. 애자일은 스크럼(Scrum), 스탠드업(Standups)과 같은 도구의 실천 방법과도 관련돼 있다.

– 데브옵스 핸드북. 424쪽.

From: HARD CODE

  • 과잉생산

린은 고객 가치의 흐름을 방해하는 낭비 원인으로 일곱 가지를 꼽는다.

  • 과잉생산 Overproduction
  • 불필요한 운반 Transportation
  • 불필요한 동작 Motion
  • 대기 Waiting
  • 불필요한 공정 Overprocessing
  • 재고 Inventory
  • 결함 Defect

(중략)

과잉생산

첫 번째로 치명적인 낭비 요소는 필요를 넘어선 과도한 생산으로, 소프트웨어 개발에서도 흔히 발생하는 문제다. 이미 명세하고 구현했다는 이유로 기능을 쳐내지 않고 제품을 출시한 적 있는가? 고객이 원하지 않는 기능을 넣은 채 제품을 출시한 적 있는가? 너무 복잡하고, 너무 일반적이고, 너무 확장성 있고, 너무 멋지고, 너무 중복되고, 너무 뒤엉킨 제품을 출시한 적 있는가? 과잉생산은 이루 말할 수 없이 치명적인 낭비다.

(중략)

애자일은 (XP를 포함해) 다양한 린 기법을 모아 놓은 방법론이다. 구체적인 기법이라기보다 기법 모음에 가깝기 때문에 소프트웨어 개발에 접근하는 방식도 다양하고 흥미롭다. 이 중 하나가 럭비 용어를 딴 '스크럼(Scrum)'이라는 프로젝트 관리 기법이다. 팀은 고객 대표와 주기적으로 (대개 30일마다) 만나서 상태를 보고하고, 우선순위를 조정하고, 프로세스를 개선한다. XP와 마찬가지로, 팀 구성원들도 매일 모여 각자 진도를 확인하고 방해 요소를 토론한다.

매달 우선순위를 조정하고 매일 작업을 재조정하는 방식으로 스크럼팀은 고객에게 중요한 업무에만 노력을 집중한다. 낭비는 거의 없다. 또한 주기적으로 프로세스를 개선함으로써 가치 흐름도 지속적으로 최적화한다.

– HARD CODE. 2장.

참고문헌

  • HARD CODE / 박재호 역 / 에이콘출판사 / 발행 2009년 06월 30일 / 원제 : I. M. Wright's Hard Code
  • UML과 패턴의 적용 [3판] / Craig Larman 저 / 김수동 역 / 홍릉과학출판사 / 2005년 12월 10일 3판 1쇄
  • 데브옵스 핸드북 / 진 킴, 제즈 험블, 패트릭 드부아, 존 윌리스 저/김영기 역 외 1명 정보 더 보기/감추기 / 에이콘출판사 / 2018년 07월 06일 / 원제: The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
  • 리팩토링 데이터베이스 진화적 데이터베이스 디자인 / 스캇 W. 엠블러, 프라모드 J. 세달라지 공저 / 정원혁, 이재범, 권태돈, 성대중, 현중균 공역 / 위키북스 / 2007년 06월 29일 / 원제 : Refactoring Databases
  • 세상을 뒤흔든 프로그래머들의 비밀 / 에드 번즈 저 / 김도균 역 / 정보문화사 / 초판 1쇄 발행: 2010년 02월 19일 / 원제: Secrets of the Rock Star Programmers: Riding the IT Crest
  • 엔터프라이즈 애플리케이션 아키텍처 패턴 / 마틴 파울러 저 / 최민석 역 / 위키북스 / 2쇄 2018년 10월 31일 / 원제 : Patterns of Enterprise Application Architecture

하위 문서

주석

  1. 세상을 뒤흔든 프로그래머들의 비밀. 인터뷰 11, 앤디 헌트. ↩

  2. code-and-fix: 이러한 개발 방식은 계획 수립과 분석, 설계의 상위 과정을 무시하고 오로지 코딩(프로그래밍)만을 강조하는, 빨리 일정을 끝내려는 변형된 무리한 속성 과정이다. ↩