폭포수모델(Waterfall model)
애자일 개발방식은 기존의 개발방식인 폭포수모델의 문제점을 해결하고자 등장했습니다.
그렇다면 폭포수모델은 무엇이고 어떤 문제점이 있을까요?
폭포수모델은 요구사항분석 -> 설계 -> 개발 -> 테스트 -> 배포의 단계로 프로젝트가 진행됩니다.
각 단계순으로 일이 진행되고, 전 단계로 다시 되돌아 갈 수 없는 구조이기에 변화에 대응이 어렵습니다.
해결하고자하는 문제점도 명확하고, 솔루션 역시 구체적이라면 해볼만하지만, 대부분의 소프트웨어 개발은 그렇지가 않습니다.
"소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다.
변화는 반드시 일어나기 때문에, 문제가 되는 것은 변화가 아니다.
변화를 극복하지 못하는 우리의 무능력이 문제다." - by Kent Beck(Junit co-creater)
이렇게 변화에 대응하고자 하기 위해 2001년 애자일 소프트 웨어 개발 선언을 하게 됩니다.
애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
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
© 2001, 상기 저자들
이 선언문은 어떤 형태로든 자유로이 복사할 수 있지만,
본 고지와 함께 전문으로서만 가능하다.
스크럼
애자일을 실천하기 위한 방법들은 스크럼, 칸반, XP, Lean SW Development 등이 있지만,
프로젝트를 진행하면서 활용했던 스크럼에 대해서 알아보겠습니다.
본래의 럭비용어인 스크럼이 개발 프로세스에 적용된 이유는 팀이라는 단어가 주는 의미를 개발 팀에 적용하여 효율적인 성과를 얻기 위해서 입니다.
스크럼은 작은 주기(Sprint)로 점진적인 개발 및 검토를 하며 효율적인 협업방법을 제공합니다.
스크럼 특징 및 활용사례
- 솔루션에 포함할 기능 / 개선점에 대한 우선순위를 부여한다.
- 개발주기는 1~4주 정도로 하고 주기마다 실제 동작하는 결과를 제공해라.
: 특정 기간을 스프린트로 설정한 후에 목표 기능을 해당 스프린트에 완료했습니다.
-
개발주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
-
매일 15분정도 Scrum meeting 회의를 가져라
: 매일 아침 10시 10분 10시 25분까지는 스탠드업 미팅을 가졌습니다. 미팅 시간에는 주로 어제 한 일, 오늘 할 일, 이슈 들을 공유했습니다.
-
항상 팀을 우선으로 생각하라.
: 매일 저녁 코드리뷰시간을 가지면서 팀원들의 태스트 진행 상황 확인 후 어려움이 있다면 서로 돕고, 먼저 해결해야할 이슈들은 같이처리하며 나아갔습니다. -
원활한 의사소통을 위하여, 구분 없는 열린 공간과 마음을 유지하라.
: 프로젝트 진행시간 내에는 슬랙 메신저를 통해서 팀원 이슈발생시 서로 소통하고 도왔습니다.
애자일스크럼을 사용하면서 느낀점
장점
1. 프로젝트를 진행하면서 예상치 못한 이슈들이 많이 발생했었는데 이런 부분을 커뮤니케이션을 통한 협력으로 보다 빠르게 해결해 나갈 수 있었습니다.
2. 짧은 주기로 스프린트가 진행되기때문에 집중력을 갖고 스프린트를 하나씩 해결해 나갈 수 있었습니다.
3. 기능의 우선순위를 정해놓고 순차적으로 진행하기 때문에 기능의 순서에 따라 협업이 가능하다.
단점
1. 아쉬웠던점은 처음 애자일스크럼을 진행하다보니 태스크의 소요시간을 예상하기 힘들었고, 그렇기에 태스크 분배 또한 쉽지가 않았습니다. 추후에는 프로젝트 시작단계에 조금 더 시간을 쏟더라도 태스크 관리 및 스프린트 설정을 보다 세밀하게 해보고 싶습니다.
Reference
