애자일을 프로젝트에 적용해보기

들어가기

음... 이번에 포트폴리오 목적으로 개인 프로젝트를 진행할 예정이다. 여기에 애자일(Agile)이라는 개발프로세스를 적용해 보고 싶어서 애자일에 관해 조금 공부해 보고 있다. 이 글은 내가 공부하는 애자일이라는 녀석을 정리하는 글이다.


폭포수와 애자일

애자일은 무엇이고? 대체 왜 쓰나?

애자일 방법론이 뭐냐? 아주 단순하게 후려친다면, 프로젝트의 시작~종료 기간 까지 폭포수 방법론의 프로세스를 여러번 반복하는 것이다.

폭포수 방법론의 프로세스

소프트웨어 요구사항 기술 - 소프트웨어 설계 - 소프트웨어 구현(또는 코딩) - 테스트와 디버깅 - 설치 - 소프트웨어 유지보수

애자일 방법론의 프로세스

폭포수 방법론 1번 사이클 - 폭포수 방법론2번 사이클 - .... - 폭포수 방법론 n번 사이클

폭포수 방법론은 소프트웨어 전체에 대한 요구사항을 분석한 다음에 소프트웨어 설계 단계로 넘어간다. 따라서 단계단계 들어가는 인력은 한정되며, 시간은 많이 들어간다.

애자일 방법론은 소프트웨어 전체에 대한 요구사항을 분석하는 대신 가장 중요하고 필요한 기능에 대한 요구사항을 분석하고, 그 기능에 한정하여 다음단계로 진행한다.

폭포수 방법론은 소프트웨어 전체로 단 한번의 개발 프로세스를 진행하며, 애자일은 소프트웨어를 기능별로 잘게 쪼개고 그 쪼개진 기능을 중심으로 개발프로세스를 여러번 진행하는 것이다.

애자일 프로세스가 추구하는 목표는 정해진 기간 내에 일부 기능을 빨리 완성하여 제공함으로써 고객들의 참여를 앞당기자는 것이다.

고객이 소프트웨어를 테스트하는 시점을 앞당김으로써 고객의 피드백을 빨리 받을 수 있으며, 이는 소프트웨어를 변경할 수 있는 시간을 확보할 수 있다. 또한, 초반에 모든 요구사항을 분석 설계하는 것이 아니라 점진적, 반복적으로 소프트웨어를 개선해나가는 것이다.

지금까지 상당수의 프로젝트가 초반에 많은 부분을 결정한 다음에 프로젝트 중, 후반에 변화를 막으려는 시도를 했다. 그러나 미래를 예측하고 변화를 막는다는 것은 거의 불가능에 가깝다. 변화를 막을 수 없다면 변화에 빠르게 대응할 수 있는 방법을 찾는데 시간을 투자하는 것이 바람직하다.

애자일 방법론이란 인간의 불완전성을 인정하고, 변화를 빠르고 유연하게 받아들이기 위한 개발 방법론이다.


애자일 프로젝트 진행 원칙

  1. 변화를 막을 수 없다면 변화에 빠르게 대응하는 방법을 찾아라
  2. 최대한 빠르게 피드백을 받을 수 있는 개발 프로세스와 개발환경을 만든다.
  3. 개발 프로세스와 개발 환경은 항상 진행형이다. 단지 개선될 뿐이다.

실제 프로젝트에 적용할 애자일의 방법론적 요소

첫째, 우선순위가 높은 기능을 최대한 빨리 개발하고, 피드백을 받아 점진적으로 개선한다. 지금까지 개발 과정을 살펴보면 프로젝트 초기에는 설계에 일정시간을 투자하고, 서버 측 api를 개발한 다음 클라이언트 기능을 개발하는 과정으로 진행했다. 그런데 새롭게 진행하는 프로젝트는 초반 설계 기간을 최소화 하고 우선순위가 높은 기능을 선택한 다음 설계, 서버 측 개발, 클라이언트 측 개발, 테스트, 개선하는 방식으로 개발을 한다.

둘째, 프로젝트 반복 주기를 여러번 두어 반복 주기에서 개발한 기능을 시연하고 피드백하는 시간을 가진다. 또한, 매 반복주기마다 회고시간을 가짐으로써 개발과정에서 좋았던 점과 나빴던 점을 찾아내어, 개선할 부분은 개선하고 좋은점은 지속적으로 활용할 수 있게 한다. 이런과정을 통해 프로젝트에 참여하는 구성원들의 협업과 개발 환경을 지속적으로 개선해나갈수 있다.

셋째, 익스트림 프로그래밍(eXtreame Programming, XP)에서 제안하는 실천 방법 중 테스트 주도개발(Test Driven Developement, TDD)과 짝 프로그래밍(Pair Programming)을 도입한다. 점진적으로 설계를 발전시키면서 API를 발전시켜야 하므로 프로젝트를 진행하면서 수없이 많은 리팩토링을 해야 한다. 이런 과정에서 TDD는 필수나 다름없다. 특히 데이터베이스 테이블에 대한 리팩토링까지 고려해야 하기에 TDD는 더 중요하게 인식된다.

애자일 프로세스는 정형화된 규칙과 실천 방법을 수행하는 것이 아니다.프로젝트에서 발생하는 문제점을 개션하려는 노력으로 만들어진 실천 방법과 개발환경이 모두 애자일 프로세스의 일부가 될 수 있다.


실제 프로젝트에 적용할 애자일의 기술적(도구) 요소

1.이슈관리 시스템을 활용한 프로젝트 관리

기존의 정보 공유 방법은 한 번에 매우 많은 정보를 프로젝트 구성원에게 전달해야 했기 때문에 문서의 활용도가 낮을 수 밖에 없었다. 이슈관리시스템으로는 프로젝트를 기능별로 요구사항 분석, 화면 분석내용을 분리 할수가 있다. 기능을 구현하는 담당자라면 이슈관리시스템에서 해당 기능만 확인하면 관련된 모든 정보를 얻을 수 있다. 만약 기능을 변경해야 한다면 이슈관리시스템에서 해당 기능의 내용만 수정하면, 이슈관리시스템에서 수정된 기능과 관련된 담당자에게 변경 사항을 알려주는 방식으로 프로젝트가 진행된다.

2.위키를 이용한 문서관리

끊임없이 변화하는 문서를 관리하고 소프트웨어 개발자가 접근하기 쉽게 하는 데 위키(WIKI)를 활용할 수 있다. 위키는 하나의 문서를 여러명이 동시에 편집할 수 있고, 웹 브라우저만 있으면 어디에서나 접근할 수 있어 변화하는 요구사항을 쉽게 반영 할 수 있다.

3.Mylyn 이클립스 플러그인을 활용한 태스트 기반 개발

Mylyn 이클립스 플러그인은 jira, Bugzilla, trac 과 같은 이슈관리 시스템과 개발툴의 통합은 개발자와 개발자, 개발자와 QA사이에 발생하는 의사소통 비용을 줄여준다. Mylyn은 점점 더 복잡해지고 대형화되는 프로젝트의 업무들을 기능 단위로 묶어서 관리한다. 한번에 여러개의 업무에 집중하는 대신 이슈관리 시스템에 등럭된 기능의 우선순위대로 업무에 집중하게 하고 해당 태스크와 관련된 리소스를 관리하는 콘텍스트(context) 기능을 제공한다.

4.지속적인통합개발환경(CI)

지금까지 수동으로 해왔던 빌드, 테스트, 배포 작업을 자동화 하고, 문제가 발생하면 개발자에게 빠르게 피드백할 수 있는 개발 환경이 그 무엇보다 중요하다. 지속적인 통합개발 환경은 개발자에게만 이점을 주는 것이 아니라 최신 소스를 개발 서버에서 바로 테스트 가능하기 때문에 프로젝트에 참여하는 고객, 업무분석가(기획자), 디자이너, 개발자, QA 모두에게 이익이 된다.

5.테스트 주도 개발(Test Driven Developement, TDD)

테스트를 먼저 작성하고 구현 코드를 만드는 TDD에서는 단위 테스트를 필수로 만들어야 하므로 좋은 개발 습관을 익히기에 좋은 방법이다. 단위 테스트를 만드는데 익숙하지 않은 개발자나 초보 개발자가 TTD기반으로 개발하는 것은 학습 효과면에서도 좋은 방법이다. 그러나 모든 기능을 TDD 기반으로 개발할 필요는 없다. 지속적인 통합 개발 환경의 효과를 높이려면 테스트 코드가 반드시 필요하므로 테스트의 중요성을 인식하고, 자연스럽게 테스트 코드를 만들어나갈 수 있는 환경을 만들어야 한다.


애자일 프로젝트 진행시 핵심 포인트(업무단위가 아닌 기능단위 개발)

정보의 흐름을 업무단위가 아닌 기능단위로 바꾸면, 최초 업무분석 단계에서 모든 기능을 사용자 스토리 기반으로 추출하게 된다. 즉 프로젝트의 업무단위가 아니라 기능단위로 프로세스를 짧은 주기로 반복하는 것이 핵심이다. 프로젝트의 전체 요구사항 분석 -> 화면설계를 진행하는 것이 아니라. 회원관리 기능에 대한 분석 -> 회원관리 기능에 대한 화면설계를 진행함으써 작은 기능 단위로 프로젝트를 진행하는 것이 포인트이다.

사용자스토리(글이나 말로된 고객의 요구사항)를 통해 기능의 범위와 기능의 리스트를 정리하는 것이 중요하다.


스프린터(마일스톤 = 기능단위 개발 프로세스 반복 주기)를 진행하는 방식

스크럼 개발 프로세스에서 스프린터를 시작할 때 해당 스프린터의 목표와 개발할 사용자 스토리를 계획하는 미팅을 가지는 것과 스프린터을 완료한 다음 마지막에 회고를 두며, 문제점을 파악하여 지속적으로 개선해나간다.

일일회의 15분 , 어제한일과 오늘 할일을 이야기하고 현재 이슈사항만 짧게 공유 한다. 기타 이슈사항은 관련자끼리 따로 회의 한다.

용어정리

반복주기: 스프린트 또는 마일스톤. 반복주기의 기간설정은 보통 1주에서 4주 정도로 잡는다.


사용자 스토리 추출 및 스토리 포인트 산정 방법

사용자가 프로젝트 초기에 소프트웨어의 기능을 사용하게 지원하는 것이 무엇보다 중요하다. 미리 소프트웨어를 사용해보면 자신이 원하는 기능이 무엇인지를 정확하게 이해할 수 있다. 그 후에 사용자가 정말 원하는 기능이 무엇인지를 파악하게 된다. 이렇게 애자일 프로세스의 반복적, 점짐적인 개발프로세스로 사용자의 피드백을 빨리 받을 수 있게 해야 한다.

그러나 프로젝트를 시작하는 시점에 어떤 기능을 개발할지 전혀 알지 못한다면 프로젝트를 진행할 수 없다. 프로젝트를 시작하는 시점에 해당 프로젝트에서 구현해야 할 기능을 사용자 관점에서 사용자의 언어로 분석하는 것이 사용자 스토리이다. 이렇게 추출된 사용자 스토리는 사용자와 지속적으로 의사소통을 하는 용도로 사용한다.

소프트웨어에 대한 사용자 스토리를 모두 추출한 다음에 진행해야 하는 부분은, 각 사용자 스토리별 우선순위와 개발시간의 산정이다. 사용자 스토리별로 소요될 개발 시간을 스토리 포인트라고 한다. 스토리 포인트는 일반적으로 절대적인 시간이 아니라 기준이 되는 사용자 스토리에 대한 상대적인 시간을 산정한다.

사용자 스토리를 추출하고 스토리 포인트를 산정하는 작업은 프로젝트에 참여하는 모든 구성원이 함께 진행하는 것이 좋다. 스토리 포인트를 산정할 때 스토리 포인트가 큰 사용자 스토리일 경우 1의 차이를 판단하기 어렵다. 따라서 스토리 포인트가 커질수록 스토리 포인트 사이의 간격을 크게 하는 것이 더 유용하다. (1, 2, 3, 5, 8, 13, 20, 50, 기권)


사용자 스토리의 우선순위 결정

사용자 스토리의 스토리 포인트를 산정한 후에는 사용자 스토리의 우선순위를 결정해야 한다. 스토리 포인트 산정은 개발자가 주도하지만 우선순위 결정은 업무 분석가(기획자)가 주도하는 것이 일반적이다. 그런데 업무 분석가에게 상,중,하로 우선순위를 결정하도록 요청할 경우 대부분의 사용자 스토리를 상으로 결정하게 된다. 업무 분석가의 관점에서는 모든 사용자 스토리의 중요도가 높은 것으로 결정해야 기능이 구현될 것으로 보이기 때문이다. 이런 결과는 업무 분석가와 개발자 간에 신뢰가 부족한 경우 더 자주 발생한다. 우선순위를 결정하는 취지에 대해서 충분히 설명해도 결과는 약 90%가 상, 나머지 10%가 중이 된다. 하에 해당하는 사용자 스토리는 하나도 없다.

이 문제를 해결하려면 업무 분석가와 개발자 사이의 신뢰를 회복하는 것이 무엇보다도 중요하다. 그리고 이에 대한 해결책으로 각 사용자 스토리를 상, 중, 하가 아니라 상상, 상중, 상하... 처럼 좀더 세분화 하는 것이 효과적이다.

마이크 콘(불확실성과 화해하는 프로젝트 추정과 계획, 인사이트 2008)은 우선순위를 결정해야 할 때 반드시 고려해야 하는 네가지 요소는 다음과 같다.

  1. 해당 기능의 재정적(금전적) 가치
  2. 해당 기능을 구현하거나 지원하는데 드는 비용
  3. 해당 기능을 구현하기 위해 배워야 할 지식이나 구현 과정에서 새롭게 창출되는 지식의 양과 그 중요성
  4. 해당 기능을 구현함으로써 제거되는 위험 요소의 양

마이크 콘은 가치와 위험성의 관계를 설명하면서 가치도 높고 위험성도 높은 기능을 제일 먼저 개발해야 한다고 설명한다. 이런 기능을 먼저 개발하면서 고객에게 가장 많은 가치를 전달할 수 있을 뿐만 아니라 프로젝트의 위험 요소를 빨리 제거할 수 있기 때문이다. 그 다음으로 구현해야 할 기능은 가치가 높고 위험성이 낮은 기능이다.