애자일 스크럼

April 22, 2021

애자일 스크럼

애자일의 스크럼(Scrum)은 특정 개발 언어나 방법론에 의존적이지 않으며, 제품 개발 뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세스 프레임워크입니다. 스크럼(Scrum)은 작은 주기(Sprint)로 개발 및 검토를 하며 효율적인 협업 방법을 제공한다.

Agile Scrum Framework at a glance

Scrum이란?

개요

스크럼은 복잡한 제품을 개발(배포)하고, 유지하기 위한 프레임워크 1995년에 Ken Schwaber와 Jeff Sutherland가 고안

  • 노나카 이쿠지로와 타케우지 히로타카가 1986년 1~2월 Harvard Business Review에 올린 “The New New Product Developement Game”에서 시작
  • 비즈니스 요구를 충족시키는데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발(전달)하는 관리 프레임워크(기법)
  • 사람들이 효과적으로 성취감을 충족하며 협업할 수 있게하여, 복잡하고 정교한 제품을 생산

주요 특징

  • 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
  • 개발 주기는 1~4주 정도로 하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라. (설명:너무 짧으면 개발(분석/설계/개발/테스트) 할 수 있는 시간이 부족하고, 너무 길면 느슨해지고 재작업의 양도 늘어나므로 적용해보면서 필요시 조율 필요)
  • 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라. (설명:해당 주기의 Goal을 작성하지 않으면 목적을 잃은 기능 목록이 될 수 있음)
  • 매일 15분 정도의 Scrum meeting 회의를 가져라. (설명:공유이지 보고하는 자리가 아니다. 교과서적으로 Scrum meeting은 개발팀원만 참여해야하고, 팀원이 아닌 사람은 발언기회는 없다고 한다. 개인적인 생각으로는 수평문화가 되어 있는 Agile Culture의팀이라면 PO 및 관리자가 함께 참석하여 공유하면 좋다고 생각한다. 이들도 참석한다면 이 프로젝트와 관련되어 한일/할일/이슈를 공유해야 한다. 안그러면 한팀이 아닌 관리자 모드로 돌아선다.)
  • 항상 팀을 우선으로 생각하라. (설명:자신의 task보다 주변 이슈가 더 급하면 도와줘야 한다. 마치 배에 구멍이 나면 그 문제 해결이 1순위이다.)
  • 원활한 의사소통을 위하여, 구분 없는 열린 공간과 마음을 유지하라.

Scrum의 추구 가치

용기

옳은 일을 할 수 있도록 팀원간 갈등과 도전을 위한 용기를 가져라!

  • 해당 기능이 이해가 안되거나 문제가 있다면 말할 수 있어야 하고, 더 일을 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득 시켜야 한다. 또한 도전적으로 시도해보는 용기와 완료 할 수 없는 업무량이라고 모두 말 할 수 있어야 한다.

집중

할 일을 하라. 모든 노력과 기술은 성공을 위해 집중하고, 그 외는 걱정(신경쓰지) 마라!

  • 한번에 하나의 일부터 마무리하고, 업무에 집중 할 수 있도록 불필요한 회의 참석은 지양하며, 루틴한 반복 작업은 제거 하거나 자동화해야 한다.

약속(헌신/책임)

팀의 목표 달성을 위해 개개인이 공약한 목표 달성을 위해 팀에 헌신하며, 이를 달성 위해 필요한 모든 권한을 부여하라!

  • 개인보다는 팀성과 달성이 우선이고, Value 있는 SW를 개발 할 수 있게 최대한 지원과 권한이 필요하다.

존중

경력과 경험이 사람을 만든다. 팀원들을 존중하라!

  • 개개인별로 장단점이 있고, 그 사람이 그렇게 할 수 밖에 없는 이유가 있을것이다.

투명성/개방성

프로젝트에 대한 모든 내용을 투명하게 공개하라!

  • 제품백로그, 스크럼 회의, 스프린트 리뷰를 통해 공유되며, 자신에게 불리해도 숨기지 않고 도움을 요청한다.

Scrum의 주요 역할자

Product Owner와 Scrum Master는 서로 보완하는 두 가지 역할을합니다.

제품 책임자(Product Owner)

비즈니스 목표를 충족시키는 제품을 만들기 위해 제품 백 로그를 관리하고 제품을 검토합니다.

  • 제품 백로그(요구사항) 관리/설명
  • 제품 백로그의 우선순위 관리
  • 만족스럽게 개발되었는지 확인

Scrum Framework Product Owner

스크럼 마스터(ScrumMaster)

Product Owner와 Development Team이 가치(Value)와 원칙(Principle)으로 성공적인 제품을 만들고, 조직 변화를 촉진하고 민첩한 작업 방식을 수립하여 유지할 수 있도록 책임을 가집니다.

  • 팀을 보호하고 장애 요소를 해결
  • 일일 스크럼 회의를 진행
  • 모니터링 및 Tracking

Scrum Framework Scrum Master

개발 팀 (Developer)

최선의 기술로 백로그를 개발하여 고객을 만족시킵니다.

Scrum 주요 용어

제품 백로그(Product Backlog)

개발할 제품의 요구사항인 사용자 스토리 집합이며, 우선순위로 관리

Agile Scrum Product Backlog

사용자 스토리(User Story)

과거 요구사항 명세처럼 업무 범위를 구체화하기 위한 개발자 입장이 아닌, User Story는 사용자가 사용하는 관점에서 어떤 가치를 제공할 것인지를 설명

  • PO는 이 기능이 누구에게 무슨 value를 제공하는지를 설명하고, 향후 개발자는 그 기능의 Value를 제공하기 위한 기술적인 역할과 책임을 가짐

Agile Scrum User Story

예를 들면,

  • 채용 담당자로서, 입사 지원자들의 프로필을 보기 원한다. 그래서 나는 채용에 적합한 적임자를 선택할 수 있다.

    • 해설 : 개발자는 시스템을 사용하는 채용담당자가 적입자를 선택할 수 있는 goal을 달성하여 benefit을 얻을 수 있도록 개발을 해야 한다. 만약 단순히 “입사 지원자 검색” 기능만 개발로 끝낸다면 그 목적을 달성할 수 없을 것이다.

완료 기준(Definition of Done), 인수 기준(Acceptance Criteria)

사용자 스토리를 완료시키기 위한 조건 명세(Given, When, Then)

Agile Scrum Definition of done

Agile Scrum Definition of done 1

스프린트(Sprint)

계획,개발,리뷰 작업 등 최소 단위의 Cycle이다. 보통 1~4주 단위에서 선택

잠재적 출시 가능 제품(Potentially Shippable Product Increment) 또는 최소 실행 가능 제품(Minimum Viable Product, MVP)

팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 수준의 제품

Agile Scrum Minimum Viable Product

스프린트 계획 회의(Sprint Planning Meeting)

스프린트 목표와 스프린트 백로그를 계획하는 회의(4주 스프린트 기준 8시간 정도 수행)

스프린트 백로그(Sprint Backlog)

각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

Agile Scrum Sprint Backlog

칸반 보드(Kanban Board)

작업을 시각적으로 업무 상태, 흐름을 보여주는 게시판

Agile Scrum Kanban Board

일일 스크럼 회의(Daily Scrum Meeting)

매일 어제 한일, 오늘 할일, 해결해야 할 장애/문제 요소를 공유하는 회의(매일 15분 정도 수행)

  • 모든 참여자가 보고가 아닌 수평적으로 공유 차원에서 진행해야 하며 팀원이 아니면 발언권은 없다. 개인적인 생각으로는 만약 PO, 관리자 등도 참여한다면 똑같이 3가지를 공유해야 한다. 그렇지 않으면 듣는 자리, 즉 보고 받는 자리로 변질되고, 개발자 관점에서는 관리자가 노는 사람 처럼 보인다. 또한 Sprint Planning에 없는 제3자가 시킨 잡무를 하고 있다는 것도 파악이 가능하다. 장애요소는 화이트보드에 적어놓고 지속적으로 해결한다. 만약 해결보다 쌓이는게 만다면 회사는 팀을 충분히 지원하지 않는 것이며, 일일 스크럼 회의는 생산적이지 않은 낭비로 인식된다.

Agile Scrum Daily Scrum Meeting

스프린트 리뷰(Sprint Review)

스프린트 마지막날 개발자가 개발한 내용을 Stakeholder, 고객, 제품 책임자에게 시연하고 검토(4주 스프린트 기준 4시간 정도 수행)

스프린트 회고(Sprint Restospective)

스프린트 마지막날 좋았던 점, 개선할 점을 도출하고 더 나은 방향으로 개선(4주 스프린트 기준 3시간 정도 수행)

Agile Scrum Sprint Restospective

스크럼 진행 순서

  1. PO는 제품의 요구기능(User Story)과 우선순위를 제품 백로그로 정한다.
  2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다.
  3. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다. (해설:PO는 기능과 우선순위에 대한 권한이 있고, 개발팀은 Sprint내에 해야 할 업무량을 결정할 권한이 있다. 특히 개발경험 있는 PO가 너무 적은 개발량을 문제제기 하기도 하지만, 실제 개발하는 개발팀원의 개발속도(Velocity)로 예측하며 조정이 중요하다.)
  4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
  5. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰(Review)를 통해 만들어진 제품을 검토하고 개선사항을 이해 한다.
  6. 제품의 리뷰를 통해 제품의 지속적 개선사항 도출이 끝나면, 스프린트 회고(Retrospective)를 통해 팀의 개발 문화(프로세스)에 대한 개선의 시간을 갖는다. (해설:스프린트 Review는 제품을 개선하는 활동이고, 회고는 우리(프로세스, 문화)를 성장시키는 활동이다.)
  7. 다음 스프린트에서 수행할 백로그를 PO와 필요 인원이 모여 선정하고 계획하는 시간을 갖는다.

요약

Scrum Framework의 역할 및 Time-Box

Agile Scrum

Scrum Framework의 역할, 산출물, 이벤트

Agile Scrum Role

3개월 단위의 Agile 프로젝트의 전체 진행 모습

Agile Scrum Process


Written by Jeon Byung Hun 개발을 즐기는 bottlehs - Engineer, MS, AI, FE, BE, OS, IOT, Blockchain, 설계, 테스트