Skip to content

Agile software development

애자일 소프트웨어 개발(Agile software development) 혹은 애자일 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다. 최근에는 애자일 게임 보급 등의 여파로 소프트웨어 엔지니어링 뿐 아니라 다양한 전문 분야에서 실용주의적 사고를 가진 사람들이 애자일 방법론을 적용하려는 시도를 하고 있다.

개념

애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다. 계획이 없는 방법론의 경우, 앞으로의 일을 예측하기 힘들고 효율적이지 못하다는 점에서 취약점을 가지고 있으며, 계획에 너무 의존하는 경우는 그 형식적인 절차를 따르는데 필요한 시간과 비용을 무시할 수 없으며, 전체적인 개발의 흐름 자체를 느리게 하는 단점을 가지고 있다.

그렇기 때문에 애자일 방법론에서 택한, 그리고 다른 고전적인 방법론, 예를 들면 폭포수 모델 또는 나선 모형과 구별되는 가장 큰 차이점은 less document-oriented, 즉 문서를 통한 개발 방법이 아니라, code-oriented, 실질적인 코딩을 통한 방법론이라는 점이다.

그러므로 애자일 개발 방법론은 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 adaptive style 이라고 할 수 있다.

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다. 예전에는 애자일 개발 프로세스는 "경량(Lightweight)" 프로세스로 불렸다. 익스트림 프로그래밍 (XP:eXtreme Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있다.

간단한 설명

Methodology-agile.png

Agile-development-diagram.png

종류

애자일 개발 프로세스로 불리는 개발 방법론에는 다음과 같은 것들이 있다.

  • 익스트림 프로그래밍 (Extreme programming) (XP) - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트우선 개발(TDD)을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.
  • 스크럼 (Scrum) - 30일마다 동작 가능한 제품을 제공하는 스프린트(Sprint)를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.
  • 크리스털 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.
  • Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.
  • Adaptive Software Development, ASD - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. 내용적으로는 다른 방법론들과 유사하지만, 합동 애플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는 것이 조금 다르다.
  • 익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다. 다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다.

상기 소개된 애자일 개발 프로세스들은 각자 다른 특징과 적용 범위가 있으며, 서로 조합도 가능하다. 애자일 개발 프로세스를 채용하고 있는 프로젝트에서는 특정 방법론만을 채택해서 매뉴얼대로 흉내만 내는 것이 아니라, 여러 방법중에서 자신의 프로젝트에 맞는 부분을 취사 선택하여 조합하고, 또 독자적인 방법을 만들어 냄으로써 큰 효과를 올리고 있다. 이러한 애자일 개발 프로세스의 제창자들은 애자일 연합이라는 자유로운 조직을 만들고, 애자일 개발 프로세스의 보급에 힘쓰고 있다.

애자일 프레임워크 활용할 때, “이것만은 주의하자”

잦은 팀원 교체
팀원들이 다른 프로젝트 작업을 위해 빠지거나 정기적으로 팀 의례에 참여하지 못할 경우 팀의 속도(Velocity)는 떨어지게 된다.
이상적인 스크럼 팀은 3 ~ 9명으로 구성된 소규모 팀이어야 한다. 5명을 최적의 팀 크기로 보는 사람들도 있다. 그러나 적절한 팀 규모 못지 않게 중요한 점은 적절한 시간 동안 팀 구성원을 일정하게 유지하는 것이다. 팀원들이 너무 자주 바뀌면 팀의 성공 가능성은 낮아진다. 안정적인 팀은 스스로의 생산 능력을 잘 파악할 수 있고 이는 예측 가능성을 높여 궁극적으로 생산성 향상으로 이어진다.
스프린트 포인트 과대평가
어제 날씨를 통해 정확한 스프린트 백로그를 구축하면 너무 많은 평가 포인트를 집어넣어 스프린트를 위험에 빠트릴 가능성을 줄일 수 있다.
스프린트에 팀에서 소화 가능한 작업의 양을 과대평가하는 것은 스크럼에서 흔히 발생하는 문제다. 서덜랜드, 해리스, 리들은 팀이 다음 스프린트에서 완료할 수 있는 포인트의 수를 가장 정확히 예측하는 방법은 이전 스프린트에서 팀이 완료한 포인트의 수를 보는 것이라고 강조했다(이것을 속칭 "어제 날씨"라고 함). 스스로의 처리 능력을 잘 아는 팀은 과욕을 부리는 실수를 피하여 스프린트의 성공 가능성을 높일 수 있다.
지나치게 많은 작업을 진행
스웜은 항목들을 '완료' 범주로 더 빨리 옮겨 속도를 높일 수 있게 해준다.
지나치게 많은 작업을 진행하는 스크럼 팀은 스프린트를 성공적으로 마치기가 어렵다. 저자들은 "스웜(swarm)"을 통해 가치가 큰 백로그 항목들을 하나의 그룹으로 처리하여 최대한 신속하게 완료할 것을 제안한다. 스웜 접근법을 택하는 팀들은 스프린트 동안 더 많은 일을 할 수 있다.
불충분한 인터럽션 시간 할당
인터럽션에 대비하는 팀은 인터럽션이 발생하지 않는 경우에도 그렇지 않은 팀에 비해 훨씬 더 효율성이 높다.
인터럽션은 모든 스프린트에서 발생한다. 즉, 버그와 같이 처리하고 넘어가야 할 일들이 발생한다는 의미다. 스크럼 팀의 일반적인 문제 중 하나는 각 스프린트에서 백로그에 없는 문제를 처리하는 데 충분한 시간을 할당하지 않는 다는 것이다. 서덜랜드는 과거 경험을 기반으로 각 스프린트의 인터럽션에 할당할 시간을 계산할 것을 권장한다. 또한 인터럽션에 소비된 포인트가 할당된 포인트를 초과할 경우, 납품 날짜에 영향을 미칠 가능성이 높으므로 회사 전체에 해당 팀에 대한 인터럽션을 최소화하도록 종용하기 위해 스프린트를 중단할 것을 권장한다.
버그 방치
발생 당일 수정되지 않은 버그를 3주 후 수정하려면 최대 24배 더 많은 시간이 걸릴 수 있다.
애자일의 핵심 목표는 매 스프린트가 끝나는 시점에 정상적인 코드를 얻는 것이다. 그러나 스크럼 팀은 매일 일과를 끝나는 시점에 깔끔하고 정상적인 코드를 얻는 것을 목표로 잡아야 한다. 이는 버그가 발생하는 즉시 최대한 신속히 해결해야 함을 의미한다. 신속하게 수정되지 않은 채 방치되는 버그는 향후 수정에 더 많은 시간을 잡아먹게 된다.
비상 상황을 선언하기 전에 너무 오래 기다림
무엇이 문제인지 또는 무엇을 해야 할지 살펴보면서 행동을 지연하지 말라. 전투기를 조종할 때는 무슨 일이 일어나는지 알아내기도 전에 죽을 수 있다.
스프린트가 계획을 이탈할 것이 확실시되면 시간 낭비하지 말고 사전에 정해진 비상 절차에 착수해야 한다. 스프린트의 초기에 심각한 문제(예: 너무 많은 백로그 항목)를 처리하지 않고 시간을 낭비하는 경우가 매우 많다. 일부 작업 분담부터 스프린트 중단에 이르기까지, 강력한 조치를 취해야 할 시점을 최대한 신속하게 결정하는 것은 스크럼 마스터가 할 일이다.
장애물을 그대로 두기
장애물은 개성이 강한 사람, 스프린트를 방해하는 경영진, 또는 그 외의 다양한 인적 문제일 수 있다. 이러한 장애물은 프로세스 개선과 동일하게 취급하여 최대한 신속하게 해결해야 한다.
스프린트 성공을 가로막는 장애물을 정기적으로 파악하고 해결하지 않는 팀은 계속해서 성과가 떨어진다. 서덜랜드, 해리스, 리들은 각 스프린트에서 가장 큰 장애물 하나를 파악한 다음 사용자 스토리를 만들고 다음 스프린트에서 이를 해결할 것을 권장한다. 정기적으로 장애물을 제거하면 이전 스프린트보다 더 많은 일을 할 수 있게 되므로 속도가 높아진다.
팀원들의 행복 지수를 평가하지 않음
스크럼 마스터는 팀의 행복도를 모니터링하여 속도 저하를 미리 예측하고 조치를 취할 수 있다.
스크럼 팀원이 행복하지 않다면 이는 팀 역량에 부정적인 영향을 미치게 된다. 불만의 요소는 회사, 팀의 업무 방식 또는 자신의 역할 등 다양하다. 저자들이 추천하는 방법은 스크럼 마스터가 정기적으로 팀원들에게 각자의 행복도 수준을 평가하도록 하는 것이다. 팀 행복도가 낮아지는 경우 최대한 신속하게 원인을 조사해서 방해물과 장애물을 파악해야 한다.
가속에 실패
조기에 일을 마치는 팀은 스스로의 스프린트 완료 능력에 대한 확신이 있으므로 일반적으로 행복도 지수도 더 높은 경향이 있다.
스프린트에 할당된 작업을 마치지 못하는 스크럼 팀은 앞으로 나가지 못한다. 스프린트에 더 많은 일을 할당하거나 장애물을 제거하지 못하거나 인터럽션을 적절히 계획하지 않을 경우 제때 일을 마칠 수 없고 스프린트는 실패하게 된다. 여기 언급한 다른 일반적인 문제점들이 해결되면 팀은 예상 시간보다 빨리 할당된 작업을 마치게 되고, 백로그의 부가적인 작업을 현재 스프린트에서 처리함으로써 속도를 높일 수 있다.

Projects

  • Planbox
  • 아틀라시안(Atlassian)의 지라(Jira)
  • 액소소프트(Axosoft)
  • 린킷(LeanKit)
  • 마이크로소프트 비주얼 스튜디오 팀 파운데이션 서버(Team Foundation Server)
  • 랠리(Rally) 애자일 플랫폼
  • 텔레릭 팀펄스(Telerik TeamPulse)

See also

Favorite site