Agile Development Principle

안녕하세요. 이현진입니다.

 

저희 팀은 지금 기획 초기 단계에 있고, 프로젝트 진행 전체에 있어서 팀원 모두가 같은 생각을 공유하면 좋을 것 같아서 ‘애자일 방법론’에 대한 글을 작성하게 되었습니다.

 

소프트웨어 마에스트로라는 과정 자체가 6개월이라는 시간안에 완성된 결과물을 만들어야 하기에 체계가 중요하다고 생각합니다. 스타트업은 실행 속도에 회사의 존폐여부가 달려있다고 합니다. 즉 스타트업에게는 지금 뛰지 않는 것이 가장 큰 리스크입니다. 결국 ‘어떻게 뛸 것인가’에 대한 체계가 없다면 망할 수 밖에 없습니다. 반면 대기업은 어떨까요? 대기업은 리스크를 최대한 줄이고 명확한 책임 소재를 가지고 일을 진행하기 위한 체계를 가지고 있습니다. 이는 우리에게 맞지 않습니다.속도가 필요한 조직과, 리스크 관리가 필요한 조직을 구분해서 어떤 식으로 팀의 체계를 구축해 갈지 순서를 정해야합니다.

 

그렇다면, 우리팀에 맞는 체계를 어떻게 만들까요? 우선 다양한 개발 방법론들 중 Waterfall Model, 과 Agile Model에 대해서 알아보도록 하겠습니다.

Waterfall Model (폭포수 모델)

Waterfall Model

폭포수 모델은 폭포수가 떨어지듯 부서별(단계별) 완성된 산출물을 다음 단계로 전달하는 방식의 개발 방법론을 의미합니다.

 

폭포수 모델은 각 부서마다 각자가 맡은 부분에 대해서만 최선을 다하면 됩니다. 또한 완벽한 ‘문서화’를 전제로 진행되기 때문에 부서 간 커뮤니케이션은 최소화합니다. 하지만 폭포수 모델은 한 곳에서 문제가 발생하면 프로젝트 전체에 영향을 주고(사전에 단계별로 정해놓은 기준을 충족하지 않으면 다음으로 넘어가지 않음), 고객의 요구와 시장의 변화에 유연하게 대처하기 힘들다는 단점이 있습니다.

Agile Model

Agile이라는 단어는 무슨 뜻 일까요? 그대로 해석하면 ‘민첩한’이라는 의미를 가지고 있습니다. 즉, 개발 방법론에서의 Agile은 ‘개발진행 상황에 따라 민첩하게 움직일 수 있는가’를 의미합니다. 다음은 개발자들이 이야기하는 ‘애자일하다’를 풀어서 작성해 본 것 입니다.

애자일이란, 하나의 메뉴얼이나 프레임워크가 아닌 유연한 원칙의 적용과 실천입니다.

애자일이란, 한 번에 완성해낼 수 있는 ‘결과’가 아닌, 끊임없이 원칙을 실천해 나가는 ‘과정’입니다.

애자일이란, 작은 계획을 짧은 단위로 세우고 시제품을 만들어 나가는 사이클을 반복함으로써 고객의 요구 변화에 유연하고도 신속하게 대응하는 개발 방법론입니다.

Agile Model

애자일 방법론은 짧은 단위로 계획을 세우기 때문에 시장과 고객의 요구에 유연하게 대응할 수 있습니다. 하지만 조직 내부와 팀원 간에 소통의 문화가 형성되어 있지 않다면 실행이 불가능합니다. 잦은 대화가 싫고 완벽한 문서를 전달받기를 원한다면 애자일 방법론은 알맞지 않습니다. 또한, ‘내' 일의 범위를 넘어서 다른 부분의 업무에 대해서도 적극적인 참여와 이해가 필요합니다. 그렇다면, 애자일 방법론을 어떻게 적용할 수 있을까요?

Scrum

Scrum

애자일 방법론의 종류에는 Scrum, Kanban, Lean등 여러가지가 존재합니다. 이 글에서는 대표적으로 스크럼(Scrum)에 대해 소개하도록 하겠습니다. 스크럼은 특정 개발 언어나 방법론에 의존적이지 않으며, 제품 개발 뿐만 아니라 일반적인 프로젝트 관리에서도 사용가능한 프로세스입니다. 스크럼에서 사용되는 용어에 대해 알아보도록 하겠습니다.

 

• 스프린트(Sprint)
  • 반복적인 개발주기. 기획,개발,리뷰 작업등 최소 단위의 Cycle을 말합니다. 보통 1~4주 단위에서 선택합니다.
  • 한번의 배포가 이루어지기까지의 작업 기간
• 이슈(Issue)
  • 에픽(Epic): 에픽은 많은 사용자 스토리, 많은 작은 단위 업무로 나눌 수 있는 큰 업무의 틀을 말합니다. 하나의 Sprint에 거쳐서 끝나지 않고 여러 Sprint에 걸쳐서 종료되며, 여러 Story들의 집합을 말합니다. 주로 Major Feature들을 중심으로 정의합니다.
  • 스토리(Story): 서비스 고객에게 가치를 줄 수 있는 기능을 서술한 것 입니다. 각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성하는 것이 좋습니다.
  • 태스크(Task): 에픽 또는 사용자 스토리의 하위 작업으로 에픽 / (사용자) 스토리를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업을 말합니다.
  • 서브 태스크(Sub-Task): 스토리의 하위 작업으로 에픽 / (사용자) 스토리를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업을 말합니다.
• 백로그 (Backlog)
  • 제품 백로그(Product Backlog): 제품에 대한 요구사항을 모아둔 곳을 말합니다.
  • 스프린트 백로그 (Sprint Backlog): (제품에 대한 요구사항 중에) 해당 스프린트에 진행할 요구사항을 모아둔 곳을 말합니다.

위 용어를 바탕으로 스크럼 진행 순서에 대해 알아봅시다.

 

1. PO(Product Owner)는 제품의 요구 기능 (User Story)과 우선 순위를 제품 백로그로 정합니다.

2.PO가 정한 제품의 우선 순위에서 어디까지 작업을 할지 팀과 조율한다.

3. 스프린트 목표를 구현 가능하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.

4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.

5. 매회의 스프린트가 종료될 때마다, 스프린트 리뷰(Review)를 통해 만들어진 제품을 검토하고 개선사항을 이해한다.

6. 제품의 리뷰를 통해 제품의 지속적 개선사항 도출이 끝나면, 스프린트 회고(Retrospective)를 통해 팀의 개발 문화(프로세스)에 대한 개선의 시간을 갖는다. (스프린트 Review는 제품을 개선하는 활동이고, 회고는 우리(프로세스, 문화)를 성장시키는 활동이다.

7. 다음 스프린트에서 수행할 백로그를 PO와 필요 인원이 모여 선정하고 계획하는 시간을 갖는다.

 

 

스크럼에 대한 더 자세한 설명은 아래 글을 참고해주세요.

애자일 Scrum 이해하기

우리가 애자일을 배우고 적용해야 하는 이유

우리는 멀티 플레이어가 되어야 한다고 생각합니다.

3명의 인원으로 프로젝트를 완벽하게 기획하고 설계하는 것은 매우 어렵습니다. 또한, 프로젝트를 진행하며 요구 사항이 바뀔 수 있고 돌발상황이 생길 수 있습니다. 이에 유연하게 대응하기 위하여 개발자의 ‘자율성’이 필요하다고 생각합니다. 애자일의 핵심은 개발자의 자발성을 극대화하고 신뢰하는 것에 있습니다. 자율성이 없는 조직은 자발적일 수 없으며, 신뢰받지 못하는 조직은 동기를 얻을 수 없습니다. 프로젝트를 진행하며 자율적으로 개발하되, 동료를 신뢰하며 동료의 의견을 존중하고 이게 아닌 것 같으면 빠르게 다시 돌아가서 수정할 수 있는 애자일한 개발을 해보고 싶습니다.

 

우리 애자일하게 해봅시다.