> [!abstract] Introduction > 이번 글에서는 애자일*Agile* 소프트웨어 모델에 대해 알아봅니다. 애자일 모델이 등장하기 전까지 소프트웨어 기업들은 마지막에 배포를 한번 하는 게 끝이었기 떄문에 빠르게 변화하는 시장에 대처하기 어려웠습니다. 그렇다면 애자일은 무엇이 다르길래 시장의 변화에 빠르게 대처할 수 있는 걸까요? # Meet Your Agile Team 만들고자 하는 소프트웨어의 규모가 커질수록 제일 어려운 것은 바로 고객에게 신뢰를 주는 일인데, 이를 이해하기 위해 잠시 고객의 입장에서 생각해보자. 소프트웨어 개발을 위해 고객은 돈을 들여 개발 팀을 고용한다. 그런데 저 사람들이 소위 '월급루팡'인지 아닌지 어떻게 알 수 있을까? 다시 말해 내가 돈을 들여 고용한 개발팀이 해야 할 일을 잘하고 있는지 어떻게 확인할 수 있을까? 뭔가 버그가 있다면서 작업 시간은 길어지고 결과물은 확인도 못하고 있는 상황에서 과연 그들을 믿을 수 있을까? ![[TheAgileTeam.png]] 그런 의심이 든다면, 지금이 바로 애자일 팀을 만날 시간이다. 애자일 팀은 누구이며, 애자일이 도대체 무엇인지 알아보자. # 애자일은 모호하다 애자일 팀은 소프트웨어 제품 개발에 관여하는 여러가지 직무를 가진 사람들로 구성되어 있다. 소프트웨어는 개발자*Dev*, 프로젝트 관리자*PM*, 비즈니스 애널리스트*BA*, UX 디자이너*UX*, 품질 보증 팀*QA* 등 다양한 분야의 협력을 통해 만들어지지만, 각 팀원의 역할은 모호하다. 서로가 서로의 업무에 일부 관여하는 부분도 있고, 이러한 전통적인 직무로는 분류할 수 없는 팀원도 있다. ![[AgileVagueRole.png]] 일단 애자일 모델 하에서 일하는 팀은 모든 구성원이 개발 과정에 참여한다. 이 사람은 이 일을 했고 저 사람은 저 일을 했으니 전체 개발 과정에 각자 지분이 있다던가 그런 이야기가 아니다. 애자일 팀에서는 모든 팀원이 한자리에 모여 개발 전반에 관여하기 때문에 각자의 업무를 종류에 따라 분류하기 어렵고, 그래서 모든 팀원이 프로젝트에 대한 주인의식을 가지고 작업하는 구조가 만들어진다. 하지만 그렇다고 해서 애자일이 그저 아무런 구조 없이 주먹구구식으로 일한다는 뜻은 아니다. ![[AgileContinuousActivities.png]] 애자일의 업무 방식도 기존의 업무 방식과 크게 다르다. 기존의 모델들이 전체 과정을 업무의 종류에 따라 단계별로 쪼갰다면, 애자일에서는 전체 업무 기간을 일정한 시간 단위로 쪼개고 모든 일을 그 단위로 쪼개서 한다. 기존에는 특정 기간 내에 특정 유형의 업무를 끝낸 것과 달리 애자일에서는 모든 업무가 여러 시간 단위에 걸쳐 연속적으로 발생한다. 전체 업무 프로세스가 작은 단위의 프로세스로 쪼개져 동시에 이루어진다는 뜻이며, 이러한 업무 단위를 타임박스*Timebox*라 부른다. 애자일의 핵심은 바로 이 타임박스를 고정시키는 것이다. # 애자일은 선택과 집중이다 애자일에서는 타임박스의 단위를 대략 2~3주로 잡고, 1개월을 넘지 않는다. 그런데 끽해봐야 2~3주 밖에 되지 않는 시간 안에 시장에 내놓을 수 있는 제대로 된 완제품을 만들기란 거의 불가능한 일이다. 그렇다면 애자일에서는 전체 업무를 어떻게 쪼개는 걸까? 애자일 모델에서 프로젝트를 계획하는 일은 평소에 할 일을 적는 것과 크게 다르지 않다. 다만 애자일에서는 할 일 목록을 마스터 스토리 목록*Master Story List*이라 부르고, 각 항목을 유저 스토리*User Story*라 부른다. ![[AgilePlanning.png]] 마스터 스토리 목록은 프로젝트에서 해야 할 모든 일을 담고 있다. 여기에 적혀있는 것은 고객이 소프트웨어에서 원하는 모든 기능이며, 무엇이 중요한지는 고객이 정한다. 팀 내에서는 각 기능을 완성하기까지 얼마나 걸릴지를 산정하고 고객은 원하는 기능의 우선순위를 정한다. 덕분에 애자일 팀은 각 타임박스마다 구현하기로 한 기능에만 집중할 수 있게 된다. 이때 지켜야 하는 또다른 원칙은 바로 개발 범위*Scope*를 희생할지언정 타임박스나 품질을 희생시키지는 않는다는 것이다. # 애자일은 유동적이다 애자일 모델에서 이렇게 타임박스를 짧게 잡으면서 얻는 또다른 이점은 바로 고객과 자주 만날 수 밖에 없다는 것이다. 애자일 모델에서는 타임박스가 시작할 때마다 고객과 만나 회의를 한다. 고객은 팀과 만날 때마다 개발 중인 제품이 원하는 대로 작동하는지 확인하고 피드백을 줄 수 있다. 애자일 팀은 고객으로부터 지속적으로 피드백을 받고, 이를 통해 계획을 유동적으로 변경할 수 있다. ![[ChangeCourseWhenNecessary.png]] 계획이라는 것이 항상 원하는 대로 갈 수는 없는 노릇이다. 그런데 기존의 개발 프로세스에서는 모든 계획을 다 수립하고 다음 단계로 넘어가니 설계 과정이나 구현 과정에서 문제가 생겨도 이 계획을 수정하기가 쉽지 않다. 테스트 단계에서 계획을 처음부터 재검토해야 한다면 그때 오는 스트레스는 이루 말할 수 없다. 다행히 애자일 팀은 이러한 문제로부터 훨씬 더 자유롭다. 그도 그럴 것이 애자일 팀은 타임박스마다 작은 목표를 하나씩 달성하기 때문에 다음에 뭘 할지를 굳이 미리 정하지 않아도 되고, 필요할 때 계획을 변경하면 된다. # The Agile Manifesto 이렇듯 애자일 팀은 처음부터 끝까지 기존과는 전혀 다른 방식으로 개발에 임하게 된다. 어떤 프로세스에서 일하고 어떤 도구를 사용하는가보다 팀원 간의 상호작용을 중요시하고, 문서보다 실제로 작동하는 소프트웨어를 중시하며, 계약을 통한 협상 대신 고객과의 협업을 중시하고, 정해진 계획에 따르기보다 다가오는 변화에 대처한다. 그 뒤에는 아래와 같은 12개의 원칙이 존재한다. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face–to–face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity – the art of maximizing the amount of work not done – is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 이러한 원칙 하에서 애자일 팀이 일하는 과정은 계획 수립부터 실제 개발과 배포 및 운영 방식까지 다양하게 나타난다. 구체적인 내용은 다른 글에서 설명할 날이 올 것이다. --- # 출처 - Rasmusson, J. (2014) _The agile samurai: how agile masters deliver great software_. United States: Pragmatic Bookshelf.