애자일에 대해서

포스팅으로 무엇을 적을까 고민하다가 이전 회사에서 애자일 개발방법론과 기능별로 구성되어 돌아가는 조직이란 재밌는 경험을 해본적이 있었어서 그 중에 애자일과 스크럼에 대해서 적어볼까 합니다.

애자일과 스크럼 이야기

우리는 개발을 어떻게 해야할까요?

여기 Mindless 개발 방법론을 예로 들어보겠습니다.

Mindless 개발 방법론

  • 생각없이 개발하기
  • 예전에 해왔던대로 늘 해왔던대로
  • 왜 이렇게 해야되는지에 대한 의문을 가지지 않기
  • 남들이 해왓던대로 하기

.

.

.

그냥 딱 봐도 이상하지요? 그럼 우리는 어떻게 개발을 해야하는지.
애자일은 무엇인지 같이 알아보도록 하죠.

애자일이란 무엇인가요? 🤔

애자일, 애자일 하는데 애자일은 도데체 무엇인가요?
새로운 기술인건가요?
아니면 무슨 프로그래밍 언어인건가?
SW 개발하는 곳에서 끊이지 않고 화자가 되는 이것의 정체는 무엇일까요?

진부하지만 에자일의 사전적 단어의 뜻에 대해서 먼저 알아봅시다.

Agile : 날렵한, 민첩한, (생각이)빠른, 이해가 빠른

이걸 조금 응용해보면

  • 생각이 빠른 방법론
  • 민첩한 방법론
  • 혹은 프로세스

위와 같이 정리가 가능하겠네요.

조금 예를 들어서 살펴보죠. 출판을 예로 들어보겠습니다.

  1. 어떤 저자가 프로그래밍 기술 서적을 쓰기로 마음을 먹음
  2. 출판사에 저자의 기획안을 제출
  3. 출판사는 여러 가지 기준을 통해 저자의 책을 출판하기로 결정
  4. 저자와 출판사는 계약서에 싸인을 하고 저자는 집필을 시작
  5. 서로 약속한 탈고일까지 6개월 정도 걸린다고 하였을 때, 저자는 집필을 하고 출판사는 띄엄 띄엄 프로그레스를 점검하면서 간혹 저자에게 오는 질문과 원고에 대한 조언과 피드백을 줌

이 때 생길 수 있는 문제점

저자와 출판사가 약속했던 책의 최종 모습에 대한 초안이 있었지만 계획이 틀어질 수 있습니다.

  • 마감일까지 끝내지 못 함
  • 저자가 포기하거나 잠수를 타는 경우
  • 초기에는 저자에게 입문자용으로 요구했으나 탈고 후 글을 읽어 보니 입문자에게 너무 어려운 경우
  • 저자 입장에서는 쉬운 수준이라고 생각되는 것이 화근
  • 이 책을 그대로 출판할 것인지, 다시 쓸 것인지, 그대로 출판한다면 난이도로 인해 예상했던 부수보다 훨씬 못 미칠때는 어떻게할지

정말 난감한 상황이죠. 먼가 계획된 일이 제대로 안돌아가고 마무리가 안되는 상황이 오는 경우가 아예 없다고는 할 수가 없죠.

근본적인 원인 파악

  1. 저자와 출판사 간의 의견 차이
  2. 6개월 후 탈고한 전체 글을 읽기 전 까지는 미완성이고, 내용을 확인 할 수 없었다.
  3. 6개월이 지난 후에 문제점이 발견되어 고치려고 하니, 비용이 너무 많이 든다.
  4. 그렇다고 그냥 출판하지나 출판사가 원하는 모습이 아니다
  5. 급하게 고친다고 하더라도 책의 품질은 떨어질 것이다
  6. 만약, 집필 초기에 문제점을 발견 했더라면, 쉽게 수정 할 수 있었을 것이다.

전제가 잘못되었거나 구현이 잘못 되었을 경우 돌아가기가 힘든 케이스가 생깁니다.

실은 여기서 책을 만드는 과정은 SW를 만드는 과정과 너무나 비슷합니다.

출판의 경우

제안 -> 기획 -> 계약 -> 집필 -> 탈고 -> 교정 ->출판

SW 개발의 경우

요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포

이와 같이 순서대로 일이 진행되고 다시 되돌아 갈 수 없는 구조로 일하는 방식을 SW세계에서는 폭포수 모델이라고 합니다.

폭포수 모델(waterfall model)을 조금 더 자세히 살펴보면

제품의 요구사항을 정의하고, 소프트웨어 아키텍쳐를 디자인하며,
제품을 개발하고, 테스트를 하여 확인하며, 유지한다 인데요.

그래서 워터폴은 이와 같이 위의 도서 출판에서 잘못 된 경우와 같이

  • 불확실성이 높으면 적절치 못한 접근법
  • 불확실성이란? 마음이 바뀜, 본인도 어떤문제인지 모름, 우리의 능력 부족, 팀단위의 인터렉션이 힘듬

탑이 추상적이라면 바텀으로 가면서 구체적으로 떨어지는게 워터폴 방법론입니다.

그렇다면 워터폴 방식은 잘못된 방식인것인가? 결론만 말하면 꼭 그런것만은 아닙니다.

경우에 따라서 워터폴이 맞을 수도 있습니다. (개념적으로만..현실은..ㅠ)

  • 돈이나 사람과 같은 미리 준비해야 되는 것들이 있기 때문에 한정된 리소스를 기반으로 계획을 잡기 좋음

  • 현재 해결하고자 하는 문제점이 무엇인지 명확하고, 솔루션 역시 구체적이라면 해볼만 하다.
    • 예를 들면 100 페이지의 책을 만드는데 한사람당 1페이지씩 할달량을 주었을때는 쓸만
  • 계획을 세우는 사람은 편하다.
    • 만약 순서에 보태어 수학을 푸는 사람들 즉, 식에 값을 대입해서 시험문제를 푸는 학생들의 경우에는 일반적으로는 이렇게 구분지어 생각하는게 상식에 맞다고 생각됩니다. 깔끔해지는것 같고. 그렇지만 간단한 문제를 가지고 하면 단계를 나누지만, 문제가 복잡해지거나 상황이 불확실성이 높으면 초보자들의 경우 병렬로 진행하기가 어렵습니다.

그래서 워터폴은 불확실성이 낮을 때 적합합니다.
다르게 말하면 에자일은 불확실성이 높을 때 적합하다고 볼 수 있습니다.

그럼 왜 계획한 프로젝트가 실패하는 원인은 뭘까요?

대부분의 원인은 바로 ‘잦은 고객의 요구사항 변경’ 때문입니다.

고객은 말그대로 갑에서 시키는것일 수 있고 내부에서의 프로젝트 오너나 외부 부서에서의 요청 등 다양한 요구사항일 수 있습니다.

이러한 문제를 해결하고자 2001년에 SW세계의 거장들이 모여서 선언문을 작성하였습니다.

애자일 소프트웨어 개발 선언문

참여: Kent Beck, James Grenning, Robert C. Martin 등

자바 테스트 프레임워크인 JUnit 으로 유명한 켄트백 아저씨의 저서 ‘익스트림 프로그래밍’ 36페이지를 보면 아래와 같은 내용을 찾을 수 있습니다.

Kent Beck

소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에, 문제가 되는 것은 변화가 아니다. 그보다는 변화를 극복하지 못하는 우리의 무능력이 문제다.

그래서 애자일은 결국 일종의 ‘유연하게 일하는 방식’ 입니다.

기존 소프트웨어 개발 생명주기나 프로젝트 관리 방법론에 변화를 주는 접근방식으로

  • 더 나은 의사소통
  • 지속적인 변화 관리
  • 우선순위에 따라 중요한 것 먼저

해야되는걸 잊어먹었다던지,
이해를 잘 못해서 개발을 잘 못 했다던지,
단위별 작업 시간이 어렵거나 예상치 못하게 길어져서 딜레이가 되었다던지,
이런 변화부분에 잘 대응을 해야하기 위해서입니다.

여기서 에자일을 잘하기 위해서는 단위를 쪼개고 나눠서 ‘분석’, ‘설계’, ‘구현’, ‘테스트’를 각 단계마다 하는 것인데요.
근데 이걸 잘못 이해할 수 있습니다. 예를 들면 아래의 그림과 같이요.

이 그림과 같이 무언가 볼 수 있는 것을 만들면서 커뮤니케이션을 하고 이해가 잘못된건 바로 잡고 고쳐나가는 과정을 쭉 이어서 한다면 실패할 확률도 좀 더 줄어들 수 있습니다.

기존 방법론과의 비교를 하면 다음과 같습니다.

자 그럼, 애자일이 좋은건 알겠는데 도대체 어떻게 해야하는걸까요? 🤔

그래서 나온 Best Practice 들이 있습니다.

  • 스크럼(Scrum)
  • Kanban (Visual Card)
  • XP(eXtreme Programming, xp)
  • 티켓 주도 개발(ticket-driven development, TiDD)
  • 래셔널 통합 프로세스(Rational Unified Process, RUP)
  • 그 외 수많은 개발방법론들

이 중에 저는 일반적으로 에자일이라고 하면 많이들 쓰이는 프로세스인 스크럼을 써보았습니다.

스크럼이란 럭비에서 유래한 용어입니다. 공수가 불분명할 때, 팀원들이 어깨동무를 하고 상대편과 원을 이루고 어깨를 맞닿은 상태에서 중앙에 럭비공을 놓아서 경쟁하는 것을 말합니다. 아마도 팀원들과 협업하여 소프트웨어를 개발하는 모습이 럭비의 스크럼과 모양새가 비슷(?)한 듯하여 지어진 이름이 아닐까 싶습니다.

애자일 스크럼의 전체 프로세스를 도식

변화에 빠르게 대응하고 만들기위해 스크럼에 맞게 팀을 조직하는게 목표이며 대표적인 역활은 아래와 같습니다.

  • Product Owner(PO) : 제품 책임자. 제품에 대한 요구사항 즉 백로그를 작성하는 주체이다. 어떤 백로그부터 개발을 해야할지 우선순위를 정하는 유일한 사람. 팀 밖의 이해관계 당사자들과의 대화를 하는 유일한 사람이여야 되며, 팀에 들어오는 외압(?)을 컨트롤 할 수 있어야 한다.
  • Scrum Master(SM) : 스크럼 팀의 스크럼이 잘 수행할 수 있도록 도와주는 역할이다. 과제 리더와 같이 의사결정을 내리는 주체가 아니고, 최대한 객관적인 시각에서 팀에 문제가 생겼을 때 해결해주는 역할. 여기서 문제는, 팀 구성원 간의 오해나 이해의 부족으로 인해 생기는 여러 가지 분쟁이나, 하는 일에 대한 우선순위 선정, 일이 끝났을 때 정말로 일이 잘 끝났는지 내려진 정의를 확인해보고 투명하게 의사결정을 할 수 있게 가이드 하는 역할. 에자일 코치가 있으면 더 좋다.
  • Team Member : 원활한 커뮤니케이션을 위해 일반적으로 팀원은 피자 2개를 한 끼 식사를 먹을 수 있는 인원(Two-pizza team)인 7~8명을 넘지 않는게 좋다.
    Self organized 스스로 결정하고 진행할 수 있는 사람들이 역활들을 다 갖고 있는 조직. 예를 들면 기획 + 개발 + 디자인 + QA + 운영 이 합쳐진 Cross Functional 조직이 되고 독립적으로 기획과 개발을 할 수 있어 제품 출시가 가능한 조직을 말한다.

스크럼의 주요 용어

  • 백로그 (Backlog)
    • 요구사항 리스트, 제품의 개발 대상 목록. 애자일에서는 요구사항을 User Story 라고 부른다.
    • 주요 기능은 사용자 관점에서 기술해야 한다. As a (User), I want do (somthing) -> 나는 (사용자로써), (무엇)을 한다.
    • 직관적으로 보는 시점으로 기술한다.
  • 스프린트 (Sprint)
    • 애자일은 짧은 기간 동안에 동작하는 SW를 사용자에게 제공하면서 피드백을 받아서 고쳐 나가는 것이다.
    • 이 ‘짧은 기간’을 일반적으로 이터레이션(Iteration)이라고 하며, 스크럼에서는 스프린트(Sprint)라고 한다.
    • 보통 1주~4주의 기간을 상황과 조직에 맞게 선정한다.

스프린트 계획 미팅 (Spring Planning Meeting)

플래닝 포커 포인트포커

이 때 스토리는 유저의 행동을 기반으로 정의하고 플래닝을 시작합니다.
각 스토리는 몇점이라는 것은 한 사람이 이 일을 했을 때 몇일이 걸린다는 개념이며, 만약 4명이 하루 8시간씩 1주일이 걸린다 치면 20 스토리. 이걸로도 스프린트 백로그 가능한 수치를 어느정도 산정할 수 있습니다.
이 방식의 장점은 불확실성을 한번 짚고 넘어갈 수 있다.

일일 스크럼 미팅 (Daily Scrum Meeting)

  • 늘어지지 않기 위해 스탠드업 미팅
  • 시간은 10~15분을 사용
  • 돌아가면서 각자 3가지를 공유 (어제 한일, 오늘 할 일, 이슈 사항)
  • 이 때 각자 돌아가면서 공유를 끝내는걸 먼저 목표로 한다. 중간에 다른 대화가 들어오지 않게 한다.
  • 이슈가 있으면 스크럼 미팅이 끝난 이후에 이슈에 관련된 사람들이 모여서 정리를 하고 공유를 한다. (스크럼보드든 메일이든)
  • 가급적 정해진 시간에 수행하고 불가피하면 유연하게 옮길 수도 skip 할 수도 있다. (빡빡하지 않게)

  • 소멸 차트 (Burn-down Chart)

스프린트의 스토리 포인트들의 합이 이상적으로 줄어드는 모습을 목적으로 합니다.
참고로 훌륭하게도 JIRA 에서 이 차트기능을 지원 해줍니다.
하지만 경험상 지라 티켓 관리가 결국 일이 되버려서 잘안되고 스크럼 마스터가 잘 케어해줘야 합니다.

  • 스프린트 리뷰 (Sprint Review)

스프린트가 종료되는 시점에 팀원 전체가 모여서 각자 한일을 리뷰하며, 코드 리뷰나 산출물을 모두 함께 모여서 살펴보는 시간을 가집니다.

스크럼 보드 (Scrum Board)

스토리들을 포스트잇으로 작성하여 붙이고 옮겨가는 방식입니다.
데일리 스크럼할 때 이슈사항이 생길 경우 빨간색같이 표시가 잘되는 포스트잇을 사용하여 또 붙이기도 합니다.
지라의 칸반보드와 다른점은 프로젝트를 형상화하여 언제든 지나가면서든 볼 수 있고 체크 할 수 있다는 장점이 있습니다.

스프린트 회고 (Sprint Retrospective)

스프린트 기간 동안에 팀 내부에서 발생한 여러 가지 일들을 되돌아 보고 잘한 것, 개선할 것, 새로 시작한 것을 도출해나가는 과정입니다.

3Fs(Fact, Feeling, Finding) 라고도 하며,

  • 포스트잇으로 각자 잘한 것, 못한 것, 개선할 것을 2개 씩 생각하여 보드에 부착
  • 각자 맘에 드는 포스트잇에 스티커를 한개씩 부착
  • 다음 스프린트에서 개선할 목표로 선정
  • 솔직하고 별거 아닌 얘기도 할 수 있을 정도로 얘기를 하는것이 좋다.

끝으로 애자일에 대해 제가 느낀 점을 말하자면,

  • 대체적으로 무턱대로 애자일이 좋다고 느끼는건 구글에서 한다더라, 페이스북에서 한다더라, 링크드인에서 한다더라. 하면서 우리도 하면? 구글이네! 라는 느낌이 강하다.
  • 각 개인의 역할 중요도가 크기 때문에 전체적인 난이도가 높은 편이다.
  • 애자일은 개발 방법의 도구일 뿐 이거 안하면 에자일 아니에요 라는 식의 단어에 얶메이지말고 용어도 사용하지 말자.
  • 팀에 필요한 것을 하나하나씩 적용해보는게 좋다.
  • 이케아 효과(자기가 돈 주고 직접 만든 가구에 대해서 가치를 높게 평가)로 팀원들이 오너쉽이 생기게 하는게 목표
  • 서로 질문하는 커뮤니케이션으로 협력하는 관계가 되는게 목표

마무리는 켄트백 아저씨의 말을 인용하며 애자일 이야기를 마칩니다.

애자일이란 생산성(productivity)과 인간성(humanity)을 동시에 추구하는 것이다. 결국에는 개발자가 행복하게 개발할 수 있는 방법을 찾는 것이다.

- Kent Beck

Reference

http://doroshy43.tistory.com/entry/WBS%EB%9E%80-Work-Breakdown-structure https://ko.wikipedia.org/wiki/%ED%8F%AD%ED%8F%AC%EC%88%98%EB%AA%A8%EB%8D%B8 https://ko.wikipedia.org/wiki/%EC%8A%A4%ED%81%AC%EB%9F%BC(%EC%95%A0%EC%9E%90%EC%9D%BC_%EA%B0%9C%EB%B0%9C_%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4) https://brunch.co.kr/@pubjinson/6 http://agile.egloos.com/ https://brunch.co.kr/@insuk/