6. 애자일

6.1. 기존의 방법론

전통적인 프로젝트 방법론에는 여러가지 문제점이 가지고 있다.

요구사항은 수시로 변경되지만 기존 프로젝트 방법론에서는 대응할 수 있는 방법이 없다. 개발자들은 공들여 만든 설계도 그대로 구현을 하지만, 얼마 가지않아 고객은 새로운 기능을 요구하고 기존의 설계가 쓸모 없어 지게된다. 아마 고객은 동작하는 소프트웨어를 보게 되면서 자신이 원하는 것을 더 정확하게 알게된다.

결국 설계를 다시하게 되고 개발자는 모든 엣지 케이스를 다룰 수 있는 설계를 하기 위해 다시 시간에 쫒기게 된다. 결국 프로젝트를 제시간에 끝낼 수 없게 된다.

개발자는 요구사항 변경한 고객을 원망한다. 그리고 매니저는 다음 프로젝트 실패하지 않기 전보다 더 복잡하고 엄격한 설계 문서와 프로세스를 요구한다. 그리고 추가된 문서나 프로세스 때문에 프로젝트 기간은 더 늘어지고, 요구사항 변경때마다 설계 변경과 함께 많은 자료를 수정하게 된다. 결국 개발자의 반은 설계를 문서를 업데이트 하고 있고, 반은 밤새 코드를 작성한다.

악순환의 끝에 개발자는 점점 단위 테스트나 인수 테스트를 당장 쓸모 없는 것으로 보고 작성하거나 실행하지 않는다. 결국 완성된 시스템은 많은 결함을 가질 수 있으며, 결합도가 매우 높아서 사후 테스트 거의 불가능하고 유지보수하기 어려울 것이다.

코드를 작성하면서 설계를 고려한다면 매우 유연하고 변경 가능한 코드를 만들 수 있다. 다른말로 얘기하면 코드를 작성하는 매 순간마다 설계는 변경되며, 지속적 통합에 따라 신뢰할 수 있는 설계 및 소프트웨어가 완성되는 것이다. 애자일은 요구사항 변경에 민첩하게 반응할 수 있으며, 최소의 비용으로 최대의 효율을 내는 방법론 중 하나이다.

아래는 기본적인 애자일 아이디어이다. 애자일 선언문 을 참고하면 더 좋다.

  • 프로세스와 툴보다 개인과 상호작용이 우선이다.
  • 포괄적인 문서보다 동작하는 소프트웨어가 우선이다.
  • 계약 협상보다 고객 협력이 우선이다.
  • 계획을 따르는 것보다 변화에 대한 반응이 우선이다.

선언문에 따르면 오른쪽의 행위도 중요하지만 왼쪽의 행위가 더 가치있다고 한다.

Agile에는 여러가지 방법론이나 프레임워크가 존재한다. (XP, Scrum 등) 이러한 방법론 이해를 위해 실제 Agile 프로젝트 관리 시스템이 어떻게 동작하는지 보면 좋은데, 조대협님의 Scrum 프로젝트 관리 가 잘 정리된 포스트중 하나이다.

6.2. Extreme programming(익스트림 프로그래밍, XP)

Extreme programming은 실천가능한 이상적인 방법으로 고객으로부터 최대의 요구사항을 얻어내며, 잦은 요구사항 변경이 프로젝트 전체에 영향을 주지 않도록 하는 유연한 모델이다. 반복적이고 점층적인 방식으로 소프트웨어를 개발하는 방법론이다.

XP는 Agile 방법 중에서 가장 유명한 실천 방법이다. 요구사항 분석단계에서 사용자 스토리로 고객 요구사항을 정리하고, 반복 계획 및 릴리스 계획을 세워 프로젝트를 진행한다. 실제 반복을 진행하기 전에 스파이크를 진행한다. 스파이크란 프로젝트 초기에 스토리를 진행하기 앞서 사용할 기술(라이브러리, 프레임워크)을 조사하고, 요구사항에 관련된 배경지식을 습득하는 단계이다. 스파이크를 통해 앞으로 진행할 스토리의 속도를 쉽게 추측할 수 있다.

6.2.1. 사용자 스토리

사용자 스토리는 사용자나 고객에게 가치를 주는 기능을 기록한 것이다.

사용자 스토리는 3가지로 구성된다. CCW라는 약어를 붙일 수 있다.

  • 서술(Written Description): 서술 형태로 카드에 작성되며, 계획하거나 대화를 이어나가기 위해 사용된다.
  • 대화(Conversation): 대화를 통해 세부사항을 구체화한다.
  • 인수 테스트(Confirmation, 확인): 테스트를 통해 구체적인 부분을 문서화하며, 스토리의 완료 여부를 판단한다.

장점은 다음과 같다.

  • 문서보다 구두 의사소통을 강조한다.
  • 사용자와 개발자 모두가 이해할 수 있다.
  • 계획 수립에 적당한 단위이다.
  • 반복적 개발에 효과적으로 사용된다.
  • 스토리를 크게 유지함으로써, 세부사항이 필요할때 까지 뒤로 미룰 수 있다. (전체적인 윤곽을 잡을 수 있다)

사용자 스토리의 세부사항은 인수테스트나 주석을 통해 작성할 수 있으며, 완료되었는지는 인수테스트를 실행해 보면서 알 수 있다. 주석에 세부사항을 담는 것 보다는, 해결된 쟁점 또는 고객과 대화를 계속 이을 수 있도록 하는 키워드를 쓰는 것을 권장한다.

사용자 스토리 수집은 물고기를 그물질하는 것과 유사하다. 처음에는 성긴 그물을 이용해서 큰 물고기 부터 잡으며, 이후에는 더 촘촘한 그물을 이용해서 물고기를 잡을 수 있다. 마찬가지로 사용자 스토리도 처음엔 큰 목적 스토리를 수집하고, 나중에는 고객과의 대화를 통해 목적 스토리를 여러개의 닫힌 스토리로 나눈다. 그리고 스토리를 수집하는 매 순간에는 어떤 사용자가 어떤 행위를 하는지 수집해야 한다.

구체적으로 스토리를 수집하는 방법에는 사용자 인터뷰, 스토리 작성 워크샵이 있다. 먼저 스토리 작성 워크샵에는 먼저 고수준의 컴포넌트간 상호작용하는 프로토타입(충실도 낮은 프로토타입)을 그리고, 그것을 기반으로 고객에 여러 상황에서 어떻게 동작을 행동할지 브레인스토밍한다. 또한 점점 프로토타입을 개선해나간다. 그리고 사용자 스토리 목록을 도출해낸다. 개발자는 스토리 수집에 도움을 줄 수 있지만, 작성된 내용의 책임은 고객에게 있다.

다른 수집 방법은 워크샵을 열고 사용자 역할이나 등장인물을 하나씩 선택하여 관련된 스토리를 작성하는 것이다.

6.2.1.1. 스토리의 종류

사용자 스토리는 추상적인 것과 구체적인 것을 다 표현할 수 있다.

  • 목적(Epic) 스토리 (다른 스토리를 작성하는데 도움이 되는 큰 스토리)
  • 닫힌 스토리 (테스트로 완료될 수 있는 스토리, 상세한 스토리와는 다름)
  • 제약사항 스토리 (구현될 수 없으며 규칙처럼 지켜야 하는 스토리, 스토리 점수가 없고 반복에 포함되지 않는 스토리)

위 스토리를 상황에 따라 적절히 사용하면 된다.

  • 일반적으로 프로젝트가 큰 경우 먼저 목적 스토리를 작성하고, 스토리가 선택되어 반복이 시작될때 고객과 함께 적당한 크기의 스토리로 분할한다.
  • 《예전 DB를 그대로 사용해야 한다》 가 하나의 제약사항 스토리 라면, 하단에 제약사항이라고 표기하여 제약사항 사용자 스토리임을 나타낼 수 있다.

6.2.1.2. 전통적인 방식

전통적인 요구사항 작성법에는 한계가 있다.

  1. 요구사항 분석은 개발자 입장에서 재해석 된 것이며, 문장은 불완전 요소를 많이 포함한다. 개발자는 이를 잘못 해석할 수 있다.
  2. 고객은 프로젝트가 진행되고 동작하는 소프트웨어를 보고 고객은 더 많은 것을 배우게되고, 고객 자신이 원하는 것을 더 구체적으로 알 수 있게 된다. 또 어떤 고객은 개발자에게 자신이 요청했던 시스템이라는 것을 인정하면서도 원했던 것은 아닌거 같다라고 말을 하기도 한다.

예를들어 천재적인 분석가가 모든 요구사항을 파악(불가능한 일)했다고 하자. 그리고 실제 개발하면서 필요한 모든 세부 사항을 개발했다고 하자. 하지만 결국 고객의 요구사항은 변경되며 모든 것을 원점에서 시작해야한다.

반면 사용자 스토리는 대화를 통해 고객과 개발자는 즉각적인 상호 피드백을 받을 수 있으며, 서로 요구사항 이해와 학습을 할 수 있게 도와준다.

6.2.2. 릴리즈 계획

릴리즈는 주요 기능들을 포함한 제품을 고객에게 공개하는 것을 뜻한다. 개발자는 고객과 함께 수집된 스토리를 살펴보면서 대략적인 스토리 점수를 추정하는 작업을 한다. 큰 스토리는 작은 스토리로 스토리를 나눌 수 있다. 그리고 난 뒤, 고객은 스토리의 우선순위를 결정해야한다. 기본적으로 개발자는 고객에게 스토리의 크기를 알려야 하고, 아키텍처 관련된 스토리의 우선순위를 높이도록 노력해야 한다.(JIRA에서는 Chore 타입으로 분리되는 듯) 하지만 충돌할 경우 고객의 우선순위를 더 우선시한다.

우선순위를 부여하기 어려운 경우 스토리를 나눌 필요가 있을 수도 있다. 그리고 우선순위를 기반으로 어떤 스토리를 릴리즈에 포함시킬지 결정해야 하며, 추정된 스토리 점수의 합과 팀의 속도를 기반으로 몇번의 반복에서 릴리즈가 될 수 있는지 계산해본다. 이미 릴리즈 날짜가 결정되어 있다면 어떤 스토리를 포기하거나 더 할지 고려해야 한다. 고객은 솔직하게 마감일을 설정해야 하며 버퍼를 두어서는 안된다. 가령 릴리즈 안정을 위해 1달 일찍 릴리즈를 당기는 것은 허용되지 않는다.

마지막으로 결정된 스토리를 각 반복에 우선순위대로 할당해야한다.

6.2.3. 반복 계획

큰 스토리가 포함되어 있다면 큰 스토리를 일정을 수립할 수 있을 정도로 작고, 완료 가능한 닫힌 스토리로 쪼갠다. 고객과 대화를 통해 스토리를 분석하고 스토리를 태스크로 나누고 각 개발자는 태스크를 가져간다.

6.2.4. 빠른설계

각 반복 시작 후 일반적으로 빠른 설계 회의(quick design session)를 갖게된다. 설계의 산출물이 정해진것은 아니며, 선택된 스토리를 정확하게 분석하고 여러가지 스케치를 통해 숨어있는 추상화를 꺼내는 작업을 한다. 분석 단계에서 사용할 수 있는 도구는 다음과 같다. 가장 중요한 것은 각 도구의 산출물을 기반으로 코드 설계를 시작하는 것이다.

  • 사용자 스토리 (반복에서 반드시 구현 해야할 것) 및 인수 테스트 (고객의 요구사항을 이해하는데 도움이되며, 스토리 작성 전이나 반복 중에 작성)
  • 유즈 케이스 (상세화된 스토리, 다이어그램 포함, out of date)
  • 도메인 모델링 (out of date)
  • 인터페이스 스케치 (out of date)
  • 클래스 다이어그램 (out of date)
  • 시퀀스 다이어그램 (out of date)
  • 테스트 코드(TDD) (up to date)
  • 작업 계획 세우기
  • ERD 작성 (out of date, 꼭 DB가 필요한 시점에 DB설계를 시작해야 함)

6.2.5. 반복

반복이 끝날때 쯤 사용자 인수 테스트(Acceptance test)를 수행하여 스토리가 완성되었는지 확인한다. 그리고 사용자 피드백을 기반으로 필요하면 새로운 스토리를 만든다.

6.2.6. TDD

TDD는 기본적으로 개발자의 코드를 검증할 수 있으므로 개발자에게 가치 있는 작업이 된다. 테스트 없이 원하는 프로그램이 잘 동작하는지 알 수 없다. 또한 호출자의 관점에서 프로그램의 인터페이스에 관심을 갖게 하여 코드 설계를 고민하도록 만든다. 또한 실행가능한 문서의 한 형태로 남을 수 있으며, 항상 최신의 튜토리얼이 된다. 하나의 산출물이 다양한 목적으로 사용되므로 효율적이다. 그 외에도 강제로 주변 환경과 분리된 테스트 가능한 프로그램을 만들 수 있게 하는 효과가 있다.

6.2.6.1. 전통적인 방식

구체적으로 전체적인 설계를 한 뒤 코딩하는 것은 여러가지 설계 사항이 고려되지 않고 성급하게 특정 방식에 초점이 맞춰진 채로 진행될 가능성이 높다.

6.2.7. 반복 계획의 가치

  • 반복이 진행될 수록 고객은 더 구체적이고 정확한 것을 말할 수 있게 된다.
  • 고객은 반복에서 얻은 지식을 바탕으로 더 자세한 아이디어를 갖게 되고, 프로젝트를 이끌어 나간다.
  • 개발자 역시 프로젝트 초반에 비해 도메인에 대한 지식이 많이 쌓이게 되므로, 더 완벽한 분석, 설계, 구현을 할 수 있다.
  • 반복계획을 사용하면 고객이 원하는 것 부터 순서대로 구현할 수 있음
  • 팀의 퍼포먼스를 측정하여 프로젝트 예상 소요 기간과 비용을 측정할 수 있다.
  • 각 반복의 끝에 시연을 하고 고객으로부터 피드백을 받을 수 있다.

6.2.8. 반복 계획과 점진적 설계

스토리 단위로 설계, 구현을 반복하는 것은 어떤 가치를 줄까? 이전 방식에 비해 어떤 점이 나을까? 처음부터 전체 설계를 하는 것은 몇가지 위험성을 갖고 있다. 고객은 프로젝트가 진행되는 중간에 새로운 요구사항을 전달하거나 기존의 요구사항을 변경한다. 이는 부정하고 싶어도 부정할 수 없다. 일단 요구사항이 바뀌면 전체 설계는 틀어지게 된다. 어떤 개발자는 재사용을 위한 설계를 하려고 한다. 이는 지나치게 추상적인 프레임워크가 되거나, 또는 재사용이 불가능하게 된다.

또한 설계를 한번에 끝내는 것은 쉽지 않다. 설계에 참여한 개발자들은 구현이 어려운 많은 에지 케이스를 생각하고 있기 때문이다. 프로젝트의 시작에 운좋게 좋은 설계를 얻었다고 하더라도 요구사항이 변경된다. 애자실 설계 원칙을 포함한 XP 방법론과 점진적 설계를 활용하면 이러한 어려움을 해결할 수 있다.

반복 계획이 적용될 경우 사용자의 변경 요구사항을 수용할 수 있을 정도로 유연하다.