애자일, 이제는 알아야 합니다.
애자일 원칙과 스크럼, 애자일에 대한 애자일한 고찰
들어가며
'애자일한 방식', '애자일하게 일하기', '토스의 넥스트 애자일'...
여기서 도대체 애자일은 무엇인가?
애자일(Agile)은 민첩한, 기민한 이라는 뜻을 지닌 형용사로, 유연성과 적응성, 협업과 지속적인 개선을 강조하는 프로젝트 관리 방법론을 말할 때 주로 쓰이는 단어이다.
오늘날 시장의 불확실성은 날로 높아져가고 있다. 고객 니즈를 정확하게 예측하는 것은 매우 힘들뿐더러, 설령 한 시점에서 니즈를 읽었다해도, 그게 언제 또 변할지 모르는 실정이다. 트렌드가 빠르고 불규칙적으로 변화하고 있고, 고객 니즈 또한 이에 따라 매우 가변적이기 때문이다. 고객 수요를 예측하는 것의 의미가 퇴색된 오늘날, 제품을 빠르게 만들어 출시한 뒤 고객의 반응을 살펴보고 피드백을 수용하여 제품에 살을 붙이는 방식, 즉, 급변하는 시장환경에 기업이 유연하게 대응하도록 나타난 것이 바로 '애자일'이다.
좀 더 방법론의 관점에서 접근하자면, 애자일은 신속한 반복 작업, 즉 짧은 개발 주기의 반복을 통해 점진적으로 프로젝트에 살을 붙여 나가는 소프트웨어 개발 방식이다. 애자일의 핵심은, 고객에게 가치를 최대한 빠르게 전달하고, 변화에 유연하게 대처하며, 수평적인 커뮤니케이션과 협업을 중시하는 것에 있다. 애자일 방법론은 2001년 소프트웨어 개발자들에 의해 만들어진 '애자일 소프트웨어 개발 선언'에 기반한다. 선언의 핵심은 다음과 같다.
2001년 애자일 소프트웨어 개발 선언 일부 발췌
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치있게 여긴다
애자일 선언문을 읽어보면 알 수 있듯이, 애자일이란 것이 무조건적으로 지켜져야 하는 일련의 규정이라기보다는 소프트웨어 개발에 대해 새로운 관점을 제시하고 방향을 잡아주는 길잡이에 가깝다.
아직 애자일에 대한 개념이 모호하지 않은가?
그럼 보다 확실히 방향성을 잡아줄, 애자일 12 원칙을 살펴보자.
애자일 12 원칙
(출처: Visual Paradigm)1. 가치있는 소프트웨어를 초기부터 지속적으로 제공하여 고객을 만족시키자.
애자일 팀은 가능한 한 초기에 빠르게 '고객의 최소 요구사항을 충족하는(MVP)' 소프트웨어를 제공한다. 그 후 사용자와 이해관계자로부터 피드백을 수집하여 제품이 요구사항을 충족하는지 확인하고, 피드백을 추후 제품 개선에 반영한다.
2. 개발 후반부 일지라도 요구사항 변경을 환영하자.
애자일 팀은 프로젝트 진행 중 요구사항이 언제든 변경될 수 있다는 것을 인식하고, 필요한 경우 이를 수용할 수 있는 준비 태세를 갖춰야 한다. 변경을 '방해'가 아닌 제품 개선의 '기회'로 여겨야 한다.
3. 되도록 짧은 간격으로 소프트웨어를 배포하자.
애자일 팀은 제품을 완성하기 전에 가능한 한 짧은 간격으로 작동하는 소프트웨어를 제공하는 것을 목표로 해야 한다. 고객으로부터 최대한 빨리 피드백을 받고 제품을 개선하기 위함이다.
4. 경영팀과 개발팀은 매일 함께 일해야 한다.
애자일 팀에서는 매일같이 커뮤니케이션하는 것을 중시한다. 성공적인 프로덕트는 비즈니스와 개발 양측 모두의 인사이트와 이들 간의 섬세한 조율을 필요로 하기 때문이다. 또한 팀 간 투명성과 신뢰를 쌓기 위해서도 커뮤니케이션은 필수적이다.
5. 동기부여된 개인들로 프로젝트 팀을 구성하자.
그들에게 필요한 환경과 서포트를 제공하고 믿고 맡기자.
애자일 철학의 핵심은 개개인과 팀들에게 '신뢰'와 '자율성'을 토대로 권한을 부여하는 것(Empowering)이다. 따라서 애자일 팀은 일을 완수할 능력과 자신이 있는 개개인들로 구성되어야 하며 일을 시작하기 전 책임 소지가 분명하게 규정되어야 한다. 애자일에서는 임파워먼트를 지향하고, 마이크로 매니지먼트는 지양한다.
6. 개발팀과(혹은 끼리)의 대화는 되도록 대면으로 진행하자.
대화는 되도록이면 (화상회의일지라도) 대면으로 이루어지는 것이 좋다. 대면 대화를 통해서 오해(miscommunication)를 최소화할 수 있고 면대면으로 대화할 때 진정성이 가장 높기 때문이다.
7. 작동하는 소프트웨어를 진척의 주요 척도로 삼자.
프로젝트의 성공은 얼마나 많은 업무가 완수되었고 비용과 시간을 들였는지가 아닌, 소프트웨어가 실제로 작동하는지 그리고 유저의 요구사항을 충족하는지를 기반으로 평가되어야 한다. 문서 작성보다 소프트웨어 자체에 집중해야 한다. 쉽게 말해 보이는 것에 집착하지 말고 본질에 충실하자는 뜻이다.
8. 지속가능한 개발을 하자.
스폰서, 개발자 및 유저는 일정하게 일정 속도를 유지할 수 있어야 한다.
애자일 소프트웨어 개발은 장기적인 프로세스이기 때문에 팀이 지속 가능한 속도로 일할 수 있어야 하며, 이를 위해서는 효율적인 의사소통, 협업 및 계획이 필요하다. 번아웃과 팀의 이탈을 방지하기 위해 워라벨(Work-life balance) 또한 중시되어야 한다.
9. 우수한 기술과 우수한 디자인에 지속적으로 관심을 갖자.
기술의 우수성과 좋은 디자인에 대한 지속적인 관심은 민첩성을 향상시킨다.
우수한 기술과 우수한 디자인은 유지보수, 성능, 확장성 등 소프트웨어의 중요한 측면을 개선하는데 도움을 준다. 이를 위해 애자일 팀은 기술적 역량과 뛰어난 디자인에 대한 지속적인 학습과 개선을 추구해야 한다. 다음과 같은 말이 있다. "바빠서 기술적 개선을 하지 못한다면, 항상 바쁘기 때문에 영원히 뒤처질 뿐이다."
10. 최대한 심플함을 유지하자.
단순성(완수되지 않은 작업량을 최대화하는 기술)은 필수적이다.
"Simple is the best" 란 말이 있듯이 복잡성을 최소화하고 필요 이상의 작업을 배제하는 것이 중요하다. 시스템을 가능한 간단하게 유지함으로써, 불필요한 작업과 비용을 줄일 수 있기 때문이다. 이를 위해서는 프로젝트 목표를 명확히 이해하고, 불필요한 추가 기능 및 복잡성을 제거하는 것이 중요하다. 이러한 접근 방식은 팀이 더 빠르고 효율적으로 작업할 수 있게 하고, 최종 제품을 더 간결하고 사용하기 쉬운 형태로 제공할 수 있게 한다.
11. 자기 조직화 팀을 구성하자.
최고의 아키텍처, 요구 사항 및 디자인은 자기 조직화 팀에서 나온다.
애자일은 자기 조직화 팀을 지향한다. 자기 조직화 팀은 일반적으로 팀 멤버들이 자신들의 역할과 책임에 대한 적절한 이해와 자율성을 가지며, 팀 내부에서의 협업과 의사소통이 원활하게 이루어진다. 이들은 각자의 전문 분야에서의 지식과 노하우를 바탕으로 높은 수준의 창의성과 혁신성을 지니고, 문제를 해결하고 새로운 아이디어를 구상하는 능력이 뛰어나다. 마지막으로 이들은 자율적인 의사결정 능력을 가지고 있어서 빠른 대처가 가능하다.
12. 정기적으로 회고하도록 하자.
팀은 정기적으로 보다 효과적인 방법을 모색하고, 이에 맞게 행동을 조율하고 조정한다.
애자일 팀은 자기 주도적으로 일하는 과정에서 자신들의 성과와 작업 방법에 대한 점검과 수정을 주기적으로 수행할 수 있어야 한다. 이는 '회고'라고도 불리며, 팀이 일을 진행하면서 나타난 문제점을 파악하고, 그에 대한 해결책을 모색하는 과정을 말한다. 회고를 통해 팀은 문제점을 빠르게 발견하고, 더 나은 성과를 얻을 수 있도록 자신들의 작업 방식을 지속적으로 개선해나갈 수 있다. 회고는 일반적으로 주기적으로 수행되며, 회의나 인터뷰 등 다양한 방식으로 진행된다.
스크럼
스크럼은 '애자일'의 가장 대표적인 프레임워크다. 켄 슈와버와 제프 서덜랜드에 의해 1990년대 초반에 개발되었다. 이들이 작성한 '스크럼 가이드'에서 스크럼의 정의를 살펴볼 수 있다. 그들은 스크럼을 다음과 같이 얘기한다.
스크럼은 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법을 활용하여 가치를 창출하도록 도와주는 경량 프레임워크이다.
스크럼은 사람에게 상세한 지침을 제공하기보다는 사람들 간의 관계와 소통을 안내한다.
(출처: Scrum Alliance)위의 그림에 나오는 스크럼 프레임워크의 핵심 용어들을 하나씩 살펴보도록 하자. 스크럼 프로세스를 중심으로 풀어나가보도록 하겠다. 프로세스에 대해 설명하기 전 먼저 스크럼 팀이 뭔지 간단히 짚고 넘어가자.
스크럼 팀
스크럼팀은 스크럼 조직의 기본이 되는 단위이다. 프로젝트 수행에 필요한 모든 역량을 갖춘 팀으로 통상 한 명의 스크럼 마스터, 한 명의 프로덕트 오너, 그리고 개발자들로 구성된다. 스크럼 팀 내에는 하부 팀이나 수직구조가 없으며 자율적으로 운영된다.
스크럼 프로세스
1. 프로덕트 백로그 생성(Product Backlog)
: 프로덕트 오너는 프로덕트를 개선하기 위해 업무에 우선순위를 부여하고 이를 프로덕트 백로그에 정렬한다. 여기에는 프로덕트 목표 설정 또한 포함된다.
2. 스프린트 플래닝(Sprint Planning)
: 스프린트 목표를 설정하고 무엇을 수행해야 하는지, 어떻게 수행할지 계획을 수립한다.
3. 스프린트 백로그(Sprint Backlog)
: 개발자는 프로덕트 백로그에 정렬된 업무 중 스프린트 기간 동안 수행될 수 있는 업무를 스프린트 백로그에 정렬한다. 여기에는 스프린트 목표 설정이 포함된다. 스프린트 백로그는 스프린트의 목표를 저해하지 않고 목표와 얼라인 되는 선에서 유연하게 변화될 수 있다.
4. 스프린트(Sprint)
: 스프린트 과제가 진행되는 주기를 지칭하는 것는으로 주로 한달 또는 그보다 짧은 기간동안 진행된다. 바로 이 스프린트 동안 프로덕트 목표를 달성하기 위해 필요한 모든 업무가 수행된다. 하나의 스프린트가 끝나면 바로 다음 스프린트가 진행되며, 진행하는 동안에는 스프린트 목표 달성을 저해하는 기간, 과제 가감 등의 변경은 불가능하다.
4-1. 데일리 스크럼(Daily Scrum)
: 스프린트 동안, 팀은 '데일리 스크럼' 혹은 스탠드업 회의라 불리는 간략한 회의를 매일 진행하게 된다. 데일리 스크럼은 팀이 제품 증가분 제공이라는 목표에 집중 할 수 있도록 도와준다.
4-2. 증가분(Increment)
: 매 스프린트에서 팀이 개발한 제품 기능을 말한다. 현재 만드는 기능은 이전에 만든 기능들과 합쳐진다는 의미에서 증가분과 누적의 개념을 활용한다. 각 증가분의 합, 즉 기능의 합을 통해 온전한 서비스를 구현할 수 있다. 가치를 제공하기 위해 증가분은 반드시 사용 가능한 것이어야 하며, 오직 완료된 업무만이 증가분에 포함될 수 있다.
5. 스프린트 리뷰(Sprint Review)
: 스프린트의 마지막에 스크럼 팀과 이해관계자들이 결과물을 점검하고 다음 스프린트를 위해 조정하는 시간을 갖는다. 프로덕트 증가분을 전체 제품에 추가하는 단계이기도 하다.
6. 스프린트 회고(Sprint Retrospective)
: 스프린트 리뷰가 끝나면 팀은 스프린트 과정을 회고하고 개선점을 찾는 회의 시간을 갖는다. 팀은 무엇을 잘 했고, 어떤 점이 개선될 수 있는지, 그리고 다음 스프린트를 위해 어떤 변화가 만들어져야 하는지에 대해 의논한다.
끝맺으며
애자일 방법론에는 정해진 답이 없는만큼 무조건적인 수용이 아닌 프로젝트나 팀의 상황과 필요에 맞게 적응(Adapt)시키고 조정(Adjust)하는 유연한 사고방식이 동반되어야 한다. 그것이 바로 애자일 정신이 아닐까?
출처
https://www.productplan.com/glossary/agile-principles/
https://resources.scrumalliance.org/Article/overview-scrum-framework
