Transcript Agile Programming, EXTREME PROGRAMMING, & SCRUM

Combacsa’s SPARCS Web Seminar
SOFTWARE DEVELOPMENT #4:
SCRUM
Scrum
Scrum
 Agile Programming Family (Of course …)
 팀 관리 및 제어 프로세스
 팀의 조직구조
 회의의 진행방식
 팀의 운용방식
 목표
 팀원들의 협력을 촉진하여 즉각적인 결과 도출
Scrum 이 싫어하는 상황
 사장님이 프로그래머를 붙잡고 하.는.말.
 “하던 일 멈추고 내가 말하는 기능부터 구현해”
 근무 시간에 주식투자를 하는 A군
 “아니 근데, 진짜루, 난 지금 할 일이 없ㅋ엉ㅋ”
 일주일 내내 혼자 코딩하던 B군의 작업물
 “웹브라우저를 만들기로 했는데 메신저를 만듬”
 Scrum 은 이런 상황을 없애줄 수 있다.
Scrum 핵심 철학
 (한달)동안 할 일의 목록을 확정한다
 그 목록에 없는 일은 이번달에는 안할꺼임 ㅇㅇ
 (매일 매일) 팀원 전체가 모여서 회의한다
 농땡이 피우는 건 하루 이상 못가게 할꺼임 ㅇㅇ
 (한달)동안 사장조차도 팀을 방해할 수 없다
 꼬우면 니가 코딩하셈 ㅇㅇ
According to Scrum,
A Software’s life looks like this :
Scrum 에 따른 프로젝트의 일생
고객의 최초 요구
최초의
제품 백로그
제품 백로그
고객 변심
제품
스
프
린
트
스프린트
계획 회의
최초의
스프린트 백로그
스프린트
백로그
일일 스크럼
일일 작업
제품 증분
스프린트
회고
Cf) 제품 Product
 정의
 프로그램
 성의있는 정의
 우리 팀에서 만드는 프로그램
 좀 더 성의있는 정의
 … 거기까지!
Cf) Product Manager (PM)
 정의
 제품을 관리하는 사람
 좀더 성의있는 정의 (하는 일)
 제품 관리 과정 일체를 총괄
 제품에 대한 외부의 요구를 취합
 내부 팀원들에게 일을 분배
 제품에 대한 정의, 팀이 나아갈 방향 설정
제품 백로그 Product Backlog
스프린트 Sprint
일일 스크럼 Daily Scrum
제품 백로그 Product Backlog
제품 책임자 Product Owner
스프린트 Sprint
스프린트 백로그 Sprint Backlog
스프린트 계획 회의
스프린트 회고 Sprint Review Meeting
일일 스크럼 Daily Scrum
스크럼 마스터 Scrum Master
제품 백로그 Product Backlog
제품 책임자 Product Owner
스프린트 Sprint
스프린트 백로그 Sprint Backlog
스프린트 계획 회의
스프린트 회고 Sprint Review Meeting
일일 스크럼 Daily Scrum
스크럼 마스터 Scrum Master
제품 백로그 Product Backlog
 정의
 제품과 관련된 모든 이야기를 글로 적은 것
 조금 더 구체화한 정의
 제품에 포함되어야 할 기능의 목록
 제품이 지녀야 할 특성의 목록
 제품에 쓰여야 할 기술의 목록
제품 백로그 항목은 누가 제안해?
 누구든 제품에 관심이 있는 사람
 고객 혹은 기획자
 “사용자가 계좌에 접근해서 지난 6개월간의 잔
액을 볼 수 있게 한다.”
 PM
 “소스 코드가 모두 Camel Case 를 따르도록 한다.”
 팀원
 “로그아웃 절차에서 에러가 나는 것을 고친다.”
마케팅 팀
제품 백로그
고객
요구사항
PM
기획 의도
사용자 계정의 삭제가 가
능해야 한다 …
코드 전반에 CamelCase
를 사용해야 한다 …
Iconv 와 ICU 모두 사용 가
능하여야 한다 …
2 종류의 웹 디자인을 모
두 지원해야 한다 …
구형 햅틱 핸드폰에서 접
속할 수 있어야 한다 …
특징, 기능
영업팀
경쟁력을 위
한 추가 기능
기술팀
신기술 도입
고객지원팀
버그 대책
팀원
떠오른 할일
제품 백로그 항목의 구성
 본문
 우선순위
 다른 백로그 항목들에 의해 상대적으로 결정됨
 노력 추정치
 이 백로그 항목을 달성하려면 몇 시간이나 걸려?
 먼저 해결되어야 하는 다른 백로그 항목
제품 백로그의 삶
 프로젝트가 시작될 때
 추상적인 형태의 “기능 목록”
 구체화된 항목들로 점점 분화
 프로젝트 중간
 각 항목들은 점점 더 구체적인 조건을 갖는다
 우선 순위가 변화하고 정확한 추정치를 갖는다
 “끝난” 항목들이 생긴다
 “끝난” 항목들이 새로운 할 일로 재탄생한다
제품 백로그 항목의 예
 포탈 로그인 아이디를 이용하여 로그인할
수 있다.
 우선순위 : 최우선
 예상 소요 노동 : 18시간
 “구현 끝”
 새로 변경된 포탈 로그인 방식을 적용한다.
 우선순위 : 최우선
제품 백로그는 누가 관리하나?
 관리하는 사람이 없다면?
 너도 나도 제품에 원하는 기능이 있다
 너도 나도 제멋대로의 우선순위를 부여한다
 관리하는 사람이 여럿이라면?
 의견 불일치가 자주 일어난다
 결론
 한 명의 유능한 제품 책임자가 관리한다
제품 백로그 Product Backlog
제품 책임자 Product Owner
스프린트 Sprint
스프린트 백로그 Sprint Backlog
스프린트 계획 회의
스프린트 회고 Sprint Review Meeting
일일 스크럼 Daily Scrum
스크럼 마스터 Scrum Master
제품 책임자 Product Owner
 역할
 제품 백로그에 대한 모든 권한을 갖는다
 구체적으로
 제품 백로그에 새로운 항목 추가
 이미 제품 백로그에 있던 항목 수정
 그를 제외한 누구도 백로그에 손댈 수 없다
 반드시 제품 책임자를 거쳐야만 한다
 각 항목의 우선순위 결정
제품 책임자의 속성
 절대 권위를 지닌다
 사장님, 총장님, 대통령 각하조차 제품 책임자
허락 없이 제품 백로그에 손댈 수 없다
 (그래서 보통은 제품 책임자가 알아서 …)
 제품 책임자의 결정을 팀원 모두가 존중한다
 적어도 백로그 내 항목들의 우선순위에 있어서는
제품 책임자가 최종적으로 결정한 순위에는 이의
제기를 하지 않는다
 PM 과는 다소 차이가 있다
PM 과 제품 책임자의 차이
 PM (제품 “관리자”)
 제품이 잘 개발될 수 있도록 하는 비전을 제시
 팀의 인사권, 외부 자원 조달 등의 실권이 있음
 제품 “책임자”
 제품이 잘 개발될 수 있도록 “구체화”
 팀의 프로그래머들의 능력을 예의주시하면서
실제로 필요한 노동량을 예측
 PM 과 달리 “실권” 은 없음, 오직 백로그 담당
새로운 제품 백로그 항목의 추가
 백로그 항목을 구체화한다
 제안한 사람 뿐만 아니라 팀원 모두 이해하도록
 기존 백로그 항목들과 우선순위를 비교한다
 적당한 위치에 신규 항목을 삽입한다
 경험을 근거로, 예상 노동량을 추정한다
 보통 “Man-hour” 라는 단위를 쓴다
 한 사람이 1시간 노동하는 양을 1 Man hour 로 …
쓸 데 없는 기능은 없다
 정신나간 헛소리가 아니라면
모든 기능은 “늦게라도” 구현하면 좋은 것
 따라서 제품 책임자는
 정신나간 헛소리는 필터링한다
 그렇지 않으면 “우선순위를 최하위” 로 낮춰서
제품 백로그에 포함시켜둔다
 먼 훗날 시간이 남아 돌 때 구현할수도 있으니까
제품 백로그는 즉각적이지 않다
 제품 책임자의 의사 결정 != 팀의 의사 결정
 제품 책임자는 가이드라인을 제공할 뿐
 제품 책임자는 가장 존중받는 사람이다
 제품 책임자가 명령권자인 것은 아니다
 따라서
 제품 백로그는 제품 책임자가 시시때때로 갱신
하지만, 즉각적으로 팀에게 영향을 주지는 않는
다
그럼 팀은 무엇을 보고 일하나?
 제품 백로그는
 제품이 걸어가야 할 “비전” 을 구체화한 것
 그러나 지금 당장 팀이 해야 할 일을 모아놓은 것
은 아니다
 그렇다면
 팀에서는 무엇을 근거로 작업을 진행할까?
 답 : 스프린트 백로그 ( != 제품 백로그)
요약
 제품 백로그
 제품에 대한 모든 이야기가 모여있는 목록
 각 항목의 우선순위, 추정노동량 필수
 제품 책임자
 제품 백로그를 편집할 수 있는 유일한 사람
 신규 항목 추가, 기존 항목 수정시 제품을 위한
최선의 판단을 한다
제품 백로그 Product Backlog
제품 책임자 Product Owner
스프린트 Sprint
스프린트 백로그 Sprint Backlog
스프린트 계획 회의
스프린트 회고 Sprint Review Meeting
일일 스크럼 Daily Scrum
스크럼 마스터 Scrum Master
Sprint 스프린트
 사전의 정의
 단거리 경주
 Sprints are short running races in athletics and track
and field.
 정의
 Scrum 에서 말하는 반복 주기 (Iteration) 의 단위
 팀이 외부의 방해를 일체 받지 않고 오직 정해진
작업들만을 진행하는 기간
 프로그램 개발은 당연히 여러 Sprint 로 구성된다.
스프린트에 대한 해석
 프로그래머의 입장
 방해 없이 정해진 양의 일만 할 수 있는 기간
 사장의 입장
 간섭하고 싶어도 일단 기다려야 하는 기간
 제품 관리자의 입장
 프로그래머들의 삽질을 방관할 최대한의 기간
스프린트 주기의 설정
 너무 길면
 PM : 삽질하고 앉아있는 기간이 길어진다
 너무 짧으면
 프로그래머 : 하나의 작업이 끝나지도 않았는데
방해를 받게 된다
 권장되는 스프린트 주기
 1개월
 보통 회사에서 한 프로젝트는 2년쯤 하니까 …
스프린트의 일생
 스프린트 계획 회의
 해당 스프린트의 목표를 정한다
 최초의 “스프린트 백로그” 를 완성한다
 작업 진행
 스프린트 백로그의 모든 항목만 달성하기 위해
열심히 작업한다
 스프린트 회고 (반성의 시간)
제품 백로그 Product Backlog
제품 책임자 Product Owner
스프린트 Sprint
스프린트 백로그 Sprint Backlog
스프린트 계획 회의
스프린트 회고 Sprint Review Meeting
일일 스크럼 Daily Scrum
스크럼 마스터 Scrum Master
스프린트 백로그
 정의
 이번 스프린트에서 반드시 해결하기로 결정된
제품 백로그 항목들의 모음
 제품 백로그의 부분집합이자
 해당 제품 백로그 항목들에 대한 사본의 모음이다
 특징
 팀의 현재 상태를 실시간으로 반영한다
 갱신의 권한이 팀에게 있다 (개인 말고)
 팀원 외부에는 권한이 없다 (제품 관리자조차!)
스프린트 백로그의 역할
 스프린트 기간동안 팀원들은
 스프린트 백로그만 들여다본다
 제품 백로그는 제품 책임자가 시시때때로 갱신
 하지만 팀원들은 스프린트 백로그에만 관심있다
 스프린트 백로그에 없는 일은
 스프린트 기간동안 신경조차 쓰지 않는다
 그걸 신경쓰는 건 다음 스프린트 때나 한다
 제품 책임자가 제품 백로그에 추가해뒀겠지, 뭐.
스프린트 백로그 항목의 증가
 기존 백로그 항목이 복합적이었던 경우
 하나의 백로그 항목이 여럿으로 분화되면서
전체 백로그의 개수가 증가할 수 있다
 팀에서 스프린트 백로그의 모든 일을 끝냄
 팀에서 남은 시간동안 놀기 싫어서
제품 백로그에서 괜찮은 항목을 가져올 수 있다
스프린트 백로그 항목의 감소
 도저히 이번 스프린트 내에
모든 백로그 항목을 달성할 수 없을 때
 팀에서 덜 중요하다고 생각하는,
아직 시작되지 않은 백로그 항목을 없애버린다
 모든 백로그 항목이 진행중이라면?
 완료할 수 있는 수준까지
백로그 항목을 쪼갤 수 있다.
스프린트 백로그 항목의 변화
 추정치의 변화
 다섯 시간 정도 코딩하면 될 거라 생각했는데,
막상 작업을 시작해 보니
스무 시간은 코딩해야 할 것 같다면?
 주저하지 않고
스프린트 백로그에 해당 사항이 반영되어야 한다
 다른 스프린트 백로그 항목의 의존성
 알고 보니 다른 백로그 항목부터 달성되어야 함
어떤 절차로 백로그를 고칠까?
 스프린트 백로그의 탄생
 스프린트 계획 회의
 스프린트 백로그의 변화
 팀원 전체가 참여하는 일일 스크럼 미팅
 그 밖의 방법으로는 변화하지 않는다
 사장님이 아무리 부탁해도 소용 없ㅋ엉ㅋ
제품 백로그 Product Backlog
제품 책임자 Product Owner
스프린트 Sprint
스프린트 백로그 Sprint Backlog
스프린트 계획 회의
스프린트 회고 Sprint Review Meeting
일일 스크럼 Daily Scrum
스크럼 마스터 Scrum Master
스프린트 계획 회의
 Part 1. 스프린트 개발 기능 결정 회의
 스프린트 목표를 설정한다
 Part 2. 스프린트 백로그 결정 회의
 스프린트 목표를
제품 증분으로 만들 수 있는 방법을 찾는다
주요 참가자
 고객
 고객이 원하는 우선순위를 발언할 수 있어야
 제품 책임자
 스프린트 계획 회의 중간에 제품 백로그가 크게
수정되어야 할 수도 있다
 팀원 전체
 팀원들이 할 수 있는 양의 일만 주어져야 한다
스프린트 계획 회의 진행
 백로그 항목들의 선정
 고객과 제품 책임자 등이 서로 높은 우선순위라
생각하는 항목들부터 넣으려고 한다
 우선순위가 높지 않더라도 “간단한” 항목이라
일부러 선정할 수도 있다
 팀은 과도한 노동이 발생하지 않도록 각 항목을
예의주시하며 의견을 피력한다
 팀은
 백로그 항목의 모호성을 고객과 함께 구체화.
스프린트 계획 회의의 시간
 스프린트 백로그가 완성되어야만 한다
 스프린트 목표가 정해져야만 한다
 팀 모두가 백로그 달성에 동의해야 한다
 따라서 보통 단시간 내에는 절대 안 끝남!
 통상적으로 2시간 – 6시간 정도 걸린다고 한다
제품 백로그 Product Backlog
제품 책임자 Product Owner
스프린트 Sprint
스프린트 백로그 Sprint Backlog
스프린트 계획 회의
스프린트 회고 Sprint Review Meeting
일일 스크럼 Daily Scrum
스크럼 마스터 Scrum Master
스프린트 회고
 일어나는 일
 스프린트 목표가 얼마나 달성되었는지 확인
 반성
 왜 일이 잘 진행되었나?
 왜 일이 잘 진행되지 않았나?
 어떻게 해야 더 일을 잘 진행할 수 있을까?
 제품 증분 확정
 열심히 일한 내용을 제품에 반영한다
 스프린트 회고 이후에는 제품 새버전 출시!
스프린트 . 정리
 스프린트
 팀이 방해받지 않고 일하는 “한달” 정도의 기간
 스프린트 백로그
 해당 스프린트 동안 할 일만을 모아놓은 백로그
 스프린트 계획 회의
 스프린트 시작 직전, 스프린트 백로그 확정
 스프린트 회고
 스프린트 끝난 후, 제품 새버전 출시
제품 백로그 Product Backlog
제품 책임자 Product Owner
스프린트 Sprint
스프린트 백로그 Sprint Backlog
스프린트 계획 회의
스프린트 회고 Sprint Review Meeting
일일 스크럼 Daily Scrum
스크럼 마스터 Scrum Master
일일 스크럼 회의 Daily Scrum
 정의
 매일 팀원 전원이 모여 진행하는 회의
 좀 더 자세하게
 매일 팀원 전원이 모여 다음의 세 가지 질문에 대
해서만 짧게 대답하고 끝내는 회의
 각자 지난번 스크럼 이후로 한 일은?
 각자 다음 스크럼까지 할 일은?
 각자 업무 진행에 불편한 점은?
스크럼은 반드시 진행되어야 해
 정해진 시각에!
 고정된 시간을 만드는 것이 가장 좋다
 정해진 장소에서!
 아무래도 고정된 시각에 빌릴 수 있는 곳은 …
 모두가 참석한 가운데!
 한 사람이라도 참석하지 않으면 팀 전체의 진행
상황을 파악하기가 힘들다
스크럼의 목적
 팀의 현황을 팀원 모두가 공유
 서로는 서로가 무슨 일을 하는지 알고
 스크럼 마스터는 팀원들의 문제제기를 듣는다
 스프린트 백로그 수정
 모두가 동의하지 않는 백로그 수정이란 없다
 제품 책임자가 하는 것이 아니다. 팀 전체가 한다
스크럼의 형식
 모인다
 각자 돌아가며
 지난 번 스크럼 이후 이룬 성취를 보고하고
 다음 번 스크럼까지 이룰 성취를 보고하고
 작업의 진행을 방해하는 것을 보고한다
 의사 결정이 필요한 문제를 공유, 결정한다
 스크럼 직후의 소규모 회의를 소집한다
제품 백로그 Product Backlog
제품 책임자 Product Owner
스프린트 Sprint
스프린트 백로그 Sprint Backlog
스프린트 계획 회의
스프린트 회고 Sprint Review Meeting
일일 스크럼 Daily Scrum
스크럼 마스터 Scrum Master
스크럼 마스터 Scrum Master
 정의
 스크럼을 주재하는 사람
 역할
 일일 스크럼 회의를 소집하고 진행한다
 스프린트 기간 내내 팀원들이 스프린트 백로그
를 잘 따를 수 있도록 팀내 의견을 조율한다
 팀원 모두를 스프린트 외적인 요소로부터 보호
한다
누가 스크럼 마스터인가?
 제품 관리자?
 No! 그들은 제품의 개발뿐만 아니라 다른 영역에
대해서도 고민해야 한다.
 제품 책임자?
 No! 그들은 전체적인 제품의 개발 방향 자체만을
고민해야 한다.
 보통 팀을 잘 이끄는 프로그래머가 한다.
스크럼 마스터의 본분
 스프린트 계획 회의에서는
 팀원들의 능력에 알맞은 양의 스프린트 백로그
가 작성될 수 있도록 노력합니다
 일일 스크럼 미팅에서는
 팀원들이 스프린트 백로그를 달성할 수 있도록
팀원들의 동향을 살피고 조율합니다
 스프린트 기간중 외압으로부터 팀을 보호!
예를 들어…
 일일 스크럼 회의에서
 “서버가 너무 느려요”
 “사장님이 자꾸 귀찮게 해요”
 “장기하 음악 없이는 일을 못 하겠어요”
 스크럼 마스터는
 서버 관리자를 닥달한다
 사장님(을 다룰 수 있는 사람)을 닥달한다
 필요하다 싶으면 장기하 앨범을 사 온다 (!)
Summary
고객의 최초 요구
최초의
제품 백로그
제품 백로그
고객 변심
제품
스
프
린
트
스프린트
계획 회의
최초의
스프린트 백로그
스프린트
백로그
일일 스크럼
일일 작업
제품 증분
스프린트
회고
References
 스크럼
 켄 슈와버, 마이크 비들 / 김기웅 역