애자일 선언문과 스크럼
스타트업은 무엇으로 사는가 (6)
애자일 개발은 기술 기반 상품 개발 프로세스다. 코드 기반(codeᐨoriented) 개발 모형으로 폭포수 모델 개발, 나선 모델 개발 등 계획 기반(document oriented) 모델과 대비되는 방법이다. 애자일 개발은 2001년 애자일 선언문에서 본격화됐다. 2001년 발표된 애자일 선언문과 애자일 선언을 뒷받침하는 12원칙에는 고객 만족, 빠르고 반복적인 개발, 경영과 개발의 면대면 협업, 자기조직화 등 린 사고가 강하게 담겨 있다.
애자일 선언문과 12원칙은 다음과 같다.
애자일 선언문
“우리는 소프트웨어를 개발하고 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
∙ 공정과 도구보다 개인과 상호작용을
∙ 포괄적인 문서보다 작동하는 소프트웨어를
∙ 계약 협상보다 고객과의 협력을
∙ 계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은 왼쪽에 있는 것들도 가치가 있지만 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.”
애자일 선언 이면의 원칙(12개 원칙)
1. 우리의 최우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
2. 비록 개발의 후반부일지라도 요구 사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
3. 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화다.
7. 작동하는 소프트웨어가 진척의 주된 척도다.
8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
10. 단순성이(안 하는 일의 양을 최대화하는 기술이) 필수적이다.
11. 최고의 아키텍처, 요구 사항, 설계는 자기 조직적인 팀에서 창발한다.
12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고 이에 따라 팀의 행동을 조율하고 조정한다.
애자일 개발 방법으로는 스프린트(sprint) 기반 스크럼(scrum), 사용자 스토리(user story), 칸반(kanban), 익스트림 프로그래밍(extreme programming, XP), XP의 일종인 테스트 주도 개발(testᐨdriven development, TDD) 등이 있다 [1] [2] [3] [4] [5] [6].
아래 그림은 가장 널리 활용되는 애자일 개발인 스크럼의 프로세스를 보여 준다. 스크럼이란 복잡하고 급변하는 문제에 생산적이고 창조적으로 대응하기 위한 프레임워크로 럭비의 스크럼처럼 상품 개발의 여러 공정이 서로 협력하면서 진행되는 과정을 빗댄 용어이다 [6] [7] [8].
스크럼스크럼 팀은 문제 해결을 위한 최적의 방법을 스스로 찾아가는 자기조직화(selfᐨorganization)를 특징으로 한다. 스크럼 팀은 1명의 상품 책임자, 1명의 스크럼 마스터, 3∼8명의 개발팀으로 구성된다. 이보다 개발자가 많을 경우 스크럼 팀을 나누게 된다. 이해관계자는 스크럼 팀 밖에서 주로 상품 책임자와 소통한다.
스크럼 프로세스는 스프린트, 스프린트 계획, 일일 스크럼, 스프린트 리뷰, 스프린트 리뷰, 스프린트 회고 등 5개의 스크럼 이벤트로 구성된다. 스프린트는 짧게는 1주일에서 1개월 단위의 시간으로 분할된 최소 개발 단위이다. 스크럼 팀은 스프린트 단위로 개발 단위를 완료하고 평가하면서 상품과 프로세스를 개선해 간다. 한편 일일 스크럼을 통해 일과 시작 전 면 대면으로 팀원이 짧게는 10초씩 할 일을 말하고 협업이 필요한 경우 추가로 협업을 논의하는 방식으로 진행한다 [6].
애자일 개발은 수백 명의 개발자가 참여하는 대규모 개발 프로세스에도 적용할 수 있다. 대표적인 대규모 애자일 방법으로는 SAFe(Scaled Agile framework), LeSS(Large Scaled Scrum), DaD(Disciplined Agile development) 등이 있다. 전체적으로 애자일 개발의 방법을 따르되 공정이나 도구, 문서, 계약, 협상, 계획 등을 고려해 활용하는 방식을 취한다.
[1] Beck, K.(2002). Test-driven development: by example. 김창준·강규영(역)(2005). <테스트 주도 개발>. 서울: 인사이트.
[2] Beck, K. & Andres, C.(2004). Extreme Programming Explained. 김창준·정지호(역)(2006). <익스트림 프로그래밍>. 서울: 인사이트.
[3] Anderson, D. J., & Carmichael, A.(2016). Essential Kanban Condensed. Blue HolePress.
[4] Cohn, M.(2004). User stories applied: For agile software development. 심우곤(역).(2006). <사용자 스토리: 고객 중심의 요구사항 기법>. 파주: 인사이트.
[5] Kniberg, H., & Skarin, M.(2010). Kanban and Scrum. 심우곤·인범진(역)(2013). <칸반과 스크럼>. 서울: 인사이트.
[6] 貝瀨岳志, 原田勝信, 和島史典, 栗林健太郞, 柴田博志, 家永英治(2015). スクラム實踐入門 成果を生み出すアジャイルな開發プロセス. 최지현(역)(2015). <스크럼: 조직을 성공으로 이끄는 의사소통 전략>. 부천: 프리렉.
[7] Schwaber, K., & Sutherland, J.(2016). The scrum guide. URL: https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf
[8] Takeuchi, H., & Nonaka, I.(1986). The new new product development game. HarvardBusiness Review, 64, 137-146.
