애자일 스터디

본 글을 여러 정보글을 토대로 본인이 정리해 본 글이다.

 

애자일

• 소프트웨어 개발 프로세스 중 하나

• 아무런 계획없는 '주먹구구식'과 계획이 지나치게 많은 방법들 사이 타협점을 찾고자 하는 방법

• 대표적으로 xp, 스크럼, 칸반 등이 있음

• 기존에는 문서로 보여줬다면 애자일은 코드 로 보여줌!!

• 좀 더 작은 단위로 개발을 해서, 해당 부분을 직접 고객에게 선보이고 피드백을 빠르게 전달받아 수정이나 이슈처리에 대한 기민한 대응을 하자

배경

💡

소프트웨어 위기
소프트웨어 위기의 원인은 전반적인 소프트웨어 프로세스의 복잡성과 소프트웨어 공학이 전문분야로서 상대적으로 미성숙한점에 관련되어 있다. 소프트웨어 규모의 대규모화, 복잡화에 따른 개발비용 증대 하드웨어 비용에 대한 소프트웨어 가격 상승폭 증가 유지보수의 어려움과 개발정체 현상 발생 프로젝트 개발 및 소요예산 예측의 어려움 신기술에 대한 교육 및 훈련의 부족 위기는 여러 가지 증상으로 나타났다: 프로젝트 예산이 초과되었다. 프로젝트 일정이 지연되었다. 소프트웨어가 비효율적이었다. 소프트웨어 품질이 낮았다. 소프트웨어가 요구 사항을 만족시키지 못하는 일이 빈번히 일어났다. 프로젝트는 관리 불가능했고 코드 관리는 힘들었다. 소프트웨어가 고객의 손에 전달 되지 못했다. 소프트웨어 위기를 "길들이고자" 다양한 과정과 방법론이 지난 수십 년간 개발되어 다양한 수준의 성공을 보였다. 그러나, 널리 양해된 견해는 "만병 통치약은 없다" 즉, 단일한 접근 방식으로 프로젝트 초과와 실패를 모든 경우에서 방지할 수 있는 것은 없다는 것이다. 일반적으로, 소프트웨어 프로젝트가 대규모이고, 복잡하고, 요구 조건이 명확하지 않고, 낯선 측면을 내포할 경우 여전히 사실상 커다랗고 예측 불가능한 문제에 취약하다.

스크럼 - 핵심 단어: 스프린트

• 반복적이고 점진적인 개발방법

• 여러 반복주기로 이뤄지며 각 반복주기가 종료될때마다 부분적으로 완성된 결과물이 만들어지도록 함

• 반복주기는 스프린트(Sprint)라고 하며 하나의 스프린트는 1~4주로 구성됨(보통 2주 정도)

• 즉, 각 스프린트마다 목표는 실행 가능한 제품을 만들어서 배포하는 것

  각 스프린트의 결과물 - 잠재적으로 출시 가능한 제품 증분(Potentially Shippable Product Increment)

역할

1. 제품 책임자(Product Owner: PO)
   • 제품 백로그를 관리, 작성하고 이해관리자로부터 요구사항을 추출하여 제품 백로그에 반영한다.
   • 요구사항에 우선 순위를 매기고 각 스프린트마다 우선순위를 관리, 조정한다.

2. 스크럼 마스터(servant leader)
   • 개발의 측면에서 PO가 말한 비즈니스 기능들을 개발 가능한 단위로 쪼개고 조율하는 역할
   • (개발 가능한 단위의 분리는 최대한 작은 단위로 쪼개는 것이 좋다)

   💡

   관리자 페이지 개발 (bad)

   관리자 페이지 내 회원가입기능 중 이메일 인증 부분 개발(good)

   • 일반적인 PM과는 다르게 개발 팀원들을 코칭하고 개발팀이 프로젝트 진행중 문제가 생겼을 때 잘 해결할 수 있도록 도와주는 역할
   • 개발팀원들이나 스크럼에 참여하는 사람들이 스크럼을 제대로 알고 수행하고 있는지에 대한 책임을 가지며 스크럼의 이론, 규칙들을 잘 따르도록 보장해야함

3. 개발팀
   • 고객으로부터 받은 요구사항을 가지고 제품을 개발, 테스트하는 팀(5~7명)
   • 따로 리더 없음 - 민주적인 구조
   • 자기 조직화(self-organization)되어 있어 외부의 명령 없이 스스로 스프린트 목표를 달성하기 위해 최상의 방법을 결정

제품 백로그(Product Backlog)

• 제품 책임자(PO)가 사용자 스토리 를 기반으로 작성

• 이해관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록

• 우선순위를 가짐
  • 제품 백로그의 우선순위 및 변경에 대해서는 원칙적으로 제품 책임자가 관리의 책임과 소유권을 가짐

💡

제품 백로그는 언제 구체화하나 ? 보통 일정이 정해진 SI 프로젝트에서는 제품 백로그 목록 수준으로 준비 단계에서 도출하고, 상세한 작성은 스프린트 내에서 구체화시킨다. 단, 스프린트 내에서 구체화되면서 프로젝트의 예산이나 일정을 초과되는 일이 발생할 수도 있다. 이 경우 스프린트 주기 내에 달성 가능한지 여부를 검토하고, 제품 책임자와 우선순위에 대해 조정해야 한다. 제품 백로그를 어떻게 관리할지는 아래 제품 백로그 관리 부분을 참고한다.

• 제품 백로그는 릴리즈 계획 및 각 스프린트 수행을 위한 Input으로 사용

• 스프린트 수행시 선택된 제품 백로그에 대해 “스프린트 백로그” 추출

사용자 스토리(ser Story)

• 고객이나 개발자가 모두 이해할 수 있도록 고객이 작성하는 것

• 카드, 대화, 테스트 라는 세 측면을 이용하여 작성

  카드

  • 요구사항 문서화가 아닌! 고객의 요구사항 표현!
  • ‘나는 ~로써 ~하기 위해 ~하고 싶다’라는 카드를 작성하며 who, why, what 정보가 모두 포함되어 있어야 함

  대화

  • 카드 내용의 세부사항을 구체화시킴으로서 인수기준이 정해지고, 이해의 공유(shared understanding)를 촉진

  테스트

  • 대화에서 논의한 인수 기준을 통해 스토리의 완료 여부를 판단
  • 긍정적인 테스트와 부정적인 테스트를 모두 사용하여 인수 기준이 만족되었는지 판단

• 스토리포인트(Story Point)를 통해 점수를 메겨 개발 규모를 추정

• 사용자 스토리가 하나의 스프린트 내에 완료할 수 없을 만큼 크다면, 좀 더 작은 크기로 여러 개의 사용자 스토리로 분할

• 사용자 스토리는 사용자가 사용하는 기능 위주로 표현이 되므로, DB성능, 편리한 UI 등과 같은 비기능적 요구사항은 사용자 스토리 외의 다른 방식으로 백로그에 수집이 되어야 함

💡

관리자 페이지 내 로그인 부분 개발 이라는 이슈카드에 대해서, 철수는 3h 순이는 1h 영자는 5h라고 제안했네요. 그럼 가장 길게 추정한 영자와 가장 짧게 추정한 순이가 그 자리에서 바로 본인이 왜 그렇게 추정했는지 사람들을 상대로 설명을 합니다. 그리고 나서 다시 플래닝 포커를 하는거죠. 철수 2h 순이 2.5h 영자 3h 간격이 줄어들긴 했지만 또 일치 하지 않는군요. 그럼 가장 짧은 철수와 가장 긴 영자가 또 이야기를 하죠. 이런 작업이 모든 개발자가 만장일치가 나올 때 까지 진행합니다. 핵심은 모든 이슈카드에 대해 만장일치 입니다.

스프린트

스프린트 계획 회의

• 제품 백로그를 기반으로 스프린트 목표와 스프린트 백로그를 계획

• 스프린트 계획 파트1과 스프린트 계획 파트2로 나뉨
  • 파트1 - 스프린트 동안 무엇(what)을 할지 우선순위가 높은 아이템들을 검토 및 목표 설정
  • 파트2 - 파트1에서 결정한 무엇을 어떻게(how) 실행할지에 대해 설정
  • 스프린트 약속(Sprint Commitment) - 각 스프린트가 끝날 때마다 어떤 결과물을 내놓을 것인지에 대한 현실적인 목표 설정(스프린트 회의 끝쯤에 설정)

스프린트 백로그 작성

• 제품백로그에서 결정된 우선순위를 기반으로 스프린트에 분배한 리스트

• 각각의 요구사항을 task 단위로 나누어 개발자들이 나눠서 작업을 수행

• 스크럼 보드(Scrum Board) 제작

스프린트는 플래닝을 통해 해당 스프린트에 진행할 작업을 정하고 시간을 추정했기 때문에, 플래닝때 정해진 작업을 스프린트 기간 내에 완료하는 것을 목표로 달립니다

• 카드를 끌어다 in progress 부분에 옮겨두고 작업을 진행

일일 스크럼 미팅(스탠드업)

• 스크럼 회의 - 매일 오전 데일리 미팅을 진행 해 오늘 할 일을 공유하고 어제 한 일을 간단히 리뷰(15분 정도)

• 어제 했던일과 오늘 할일, 수행중 문제점이나 장애요인 등을 공유

• 일일 스크럼 미팅을 함으로서 프로젝트 후반부에 문제점이 갑자기 발생하는 것을 예방

• 번다운 차트(Burndwon Chart)를 통해 진척도를 추적한다

• 가로축은 1회 스프린트 기간, 세로축은 남은 작업량

스프린트 리뷰 및 회고

스프린트 리뷰

• 스프린트동안 개발한 증분의 기능을 고객을 포함한 이해관리자들에게 보여주고 피드백을 받는 과정

• 고객의 피드백이나 여러 사항들을 정리하여 다음 스프린트에 반영되도록 제품 백로그를 다시 갱신

• 스프린트의 한주당 스프린트 리뷰시간은 한 시간으로 제약되어있으며 스프린트 리뷰를 준비하는데 30분을 넘지 않도록 해야함

스프린트 회고

• 스프린트를 진행한 후 스프린트 마지막날 스프린트 기간 동안 진행한 작업들을 플래닝 내용을 가지고 회고 진행

• 프로젝트를 진행하면서 좋았던점이나 문제점, 미진한 점 등을 도출 → 다음 스프린트를 보다 더 나은 방향으로 개선

다음 스프린트 시작

• 스프린트가 회고 후 휴식 기간없이 다음 스프린트를 진행

칸반 - 핵심 단어: WIP

• 칸반과 스크럼의 가장 두드러지는 차이는 스프린트 기간이 정해져 있지 않다는 것

• 칸반 역시 이슈카드가 들어올 때마다 데일리 미팅에서 플래닝 포커를 통해 시간 추정 작업 진행

• 이슈카드는 기한없이 backlog에 쌓이게 되고, 급한 작업단위 순서대로 in progress에 이슈카드를 넣고 처리

• In Progress바에 넣을 수 있는 이슈카드의 갯수는 제한되어 있음

나가며

주로,

프로젝트같은 종료일이 정해져야 하는 업무가 많이 발생하는 경우는 스크럼,

지속적인 업무를 다루며 프로젝트 개발 및 ops까지 함께 다뤄야 하는 상대적으로 작은 단위의 팀에서는 칸반을 사용하는 것이 효율적입니다.

💡

HotFix라는 이슈를 다루는 관점에 대한 스크럼과 칸반의 차이입니다. HotFix란 말 그대로, 예측되지 않았던 요청입니다. 스크럼에서는 HotFix는 해당 스프린트에 “절.대.”넣지 않습니다. 스프린트 진행 중 발생하는 모든 HotFix는 무조건 다음 스프린트의 백로그로 쌓이게 되고 다음의 업무가 됩니다. 칸반에서는 HotFix 또한 바로 프로젝트 backlog에 쌓습니다. 쌓여진 Hotfix를 바로바로 처리할 수 있죠. 해당 프로젝트를 끝내기 위해 처리해야 할 이슈카드로 동일하게 취급합니다.

출처

• https://medium.com/@unini/애자일과-워터폴-그리고-애자일의-친구들-스크럼과-칸반-d53c23aadd57

• https://medium.com/pocs/스크럼의-진행-과정-b6faa13e0e8c