사용자스토리 애자일

Ⅰ-0

사용자 스토리와 애자일

이충헌([email protected]) 넥스트리소프트㈜

2013.8.19

Ⅰ-1

사용자 스토리와 애자일 - 목차 1. SW 개발 접근 방법

2. Agile 역사

3. 사용자 스토리

4. 스토리 점수

작성자: 이충헌([email protected])

"올바른 성장과 따뜻한 나눔"

1. SW 개발 접근 방법

변형과 변환을 거치는 SW 개발 과정 • 다양한 커뮤니케이션 채널이 발생하고, 채널 간 이해를 통해 개념을 발전 혹은 왜곡 현상 나타남

• 비즈니스 개념을 출발로 하여 구현모델에 이르는 SW 개발 과정은 이러한 차이를 극복하기 위한 다양한 방법을 개발 방법론으로 정립함

비즈니스 개념

분석 모델

설계 모델

구현 모델

비정형 구술 언어 자유로운 형식의 문서

내용보다는 양에 치중하는 너무나 많은 종류의 문서들

정형적인 문서 (UML, ERD 등) 개발조직에 특화된 문서

소소 코드 실행 파일

차이 (GAP) 극복에 대한 다양한 방법



변형과 변환으로 발생된 왜곡을 해결하는 방식 • 베를린 필하모닉 콘서트 홀

danperry.livejournal.com/117871.html



현실의 SW 프로젝트 • SW 프로젝트의 성공률은 30% 조차 되지 않음

• 거의 대부분의 프로젝트는 이미 실패한 상태에서 출발함

• 실패의 범위를 줄이려는 노력을 지향하는 SW 개발 접근 방법 추구

• 궁극적인 SW 개발에 대한 가치를 (올바로) 동작하는 SW에 초점

SW 공학센터 (2010 SW 공학백서) https://www.software.kr/library/paperList.do?method=paperList&bs_id=8&bi_code=bbs_book&requirePage=1


2. Agile 역사

Agile의 시작 • 1986년 Harvard Business Review지에 실린

‘The New New Product Development Game’ (Takeuchi and Nonaka)

• 혼다, 캐논, 후지 제록스와 같은 기업이 모든 작업 절차를 단일 과정 내에 수행하는 방식 (all-at-once product development)을 통해 팀 단위로 유연한 제품을 개발하는 내용을 소개

• 권한이 이양되고(empowered), 자기 조직화된(self-organized) 팀 문화의 중요성을 강조

mis.postech.ac.kr/class/MEIE780_AdvMIS/paper/part3/32_The%20new%20product%20development%20game.pdf


2. Agile 역사

Scrum의 탄생 • 1995년, Ken Schwaber가 OOPLSA 1995에 처음으로

‘SCRUM Development Process’ 논문 게재

• 복잡하게 얽혀있는 시스템 개발은 유연성을 극대화시키고 적절한 통제를 필요로 함

• 개발팀으로 하여금 느슨한 공정(imprecise process)을 사용하여 복잡한 환경 내에서 적절하게 작업하도록 하는 방식이 필요

• 복잡한 시스템 개발은 급격하게 변화하는 환경 내에서 발생함

www.agilix.nl/resources/scrum_OOPSLA_95.pdf


2. Agile 역사

XP(eXtreme Programming)의 탄생 • 1996년, Kent Beck과 Ward Cunningham이 시작

• 5가지 핵심가치를 기반으로 하는 단순한 규칙을 적용하는 기법

• 필요한 것만 추구하는 단순함 (simplicity), 매일 대면하는 의사소통 (communication), 동작하는 SW 전달과 동시에 피드백 반영 (feedback), 실패에 대한 두려움이 없는 적극적인 변화 수용에 대한 도전 의식 (courage), 아무리 작은 일이라도 현재 역할에 대한 상호 존중 (respect)

extremeprogramming.org


2. Agile 역사

Agile Manifesto • 2001년, 2월 Utah의 Wasatch 산에 있는 Snowbird 스키 리조트에서 Extreme Programming, Scrum, DSDM(Dynamic Systems

Development Method), Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming 등의 방식을 대표하는 17명의 인원들이 Agile SW 개발 방식에 대한 선언문을 발표

agilemanifesto.org

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals.

Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


2. Agile 역사

Open UP • 2006년 초, Eclipse 진영에서 IBM의

Basic Unified Process(BUP)를 변형하여 오픈소스 진영의 개발 프로세스로 발전

• RUP / UP의 핵심적인 내용에 선택적으로 수행하는 절차를 모두 없애 간소화하여 더 단순한 개발 프로세스로 변경

• 애자일과 반복적인 개발 방식의 소규모 팀(3~6개월 동안의 3~6명 개발)을 목표로 간소화시킨 개발 방식

epf.eclipse.org/wikis/openup


2. Agile 역사

Engineering 관점의 SW • 2009년, Tom DeMarco의 ‘Software Engineering :

An Idea Whose Time Has Come and Gone?’ (IEEE Software, 2009)

• ‘측정할 수 없는 것은 통제할 수 없다’라는 명제는 더 이상 의미가 없다.

• SW 개발에서 일관성과 예측을 위해 통제를 했었고, on time과 on budget을 위해 SW 프로젝트를 끝내기 위해 우리 스스로를 고문했지만, 이러한 통제가 가장 중요한 요소가 되지 못했음.

• 더 중요한 목표는 세계를 변화시키거나 기업을 바꾸거나 비즈니스를 변화시키는 SW를 만드는 것임.

www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf


2. Agile 역사

Enterprise Agile • Lean Software Development

: 도요다 생산 방식에서 차용, 지속적인 프로세스 개선 목적

• SAFe (Scaled Agile Framework) : Scaling Software Agility, Agile Software Requirements의 저자인 Dean Leffingwell이 대표모 프로젝트에 적합하도록 프로세스를 개선

• Kanban : Lean과 JIT(Just-In-Time) 생산을 위한 일정 관리 체계로 기존 수요-예측의 ‘push’ 방식에서 수요에 대한 ‘pull’ 방식을 적용

scaledagileframework.com



요구사항 • 커뮤니케이션 문제 (새로운 SW를 사용하기 원하는 사람은 새로운 SW를 만드는 사람과 의사소통을 수행)

• 서로 다른 관점(perspective)에 있는 사람들로부터의 정보에 시스템을 결정됨

• 의사소통을 좌우하려는 양측이 충돌하면 프로젝트는 좌초됨

• 비즈니스가 의사소통을 좌지우지하는 경우, 개발자가 요구하는 기능과 납기를 준수할 수 있는지에 대한 관심을 두지 못하거나 혹은 개발자가 무엇을 만들지를 정확하게 이해했는지에 대해 무시한 채 기능이나 일정만을 강요함

• 개발자가 의사소통을 주도하는 경우, 기술적인 전문 용어가 비즈니스의 언어를 대체하며 개발자들은 비즈니스로부터 경청하여 필요한 것이 무엇인지를 배울 기회를 놓침

• 자원 분배에 대해 감정적으로 가득 차고 정치적인 이슈는 공유하는 문제가 되어야 함

• 자원 분배 문제가 어느 한편에 치우쳤을 때 프로젝트는 실패함

• 개발자가 문제를 짊어지면(“전 어떻게 하든 상관없구요, 어찌되었든 8월까지 끝낼께요”와 같은 표현) 추가할 기능에 대해 품질을 고려하지 않거나, 부분적으로만 기능을 구현하거나, 고객이나 사용자가 관여해야만 하는 수많은 결정사항들을 만들어냄

• 고객이나 사용자가 자원 분배 문제를 짊어지면 프로젝트 초반에 구현 및 삭제 기능 결정에 끝없는 토론 과정이 길어져서 결국 원하는 기능을 담지 못하는 결과를 낳음

通卽不痛不通卽痛

동의보감 (허준)



SW 프로젝트의 예측 • SW 개발은 정확하게 예측할 수 없음

• 사용자들에게 초기 버전을 최대한 일찍 보여주고, 이들이 새로운 아이디어나 의견 변화에 대응해야 함

• SW가 눈에 보이는 것이 아니기에, 대부분의 개발자들이 얼마나 걸릴지를 추정하는 아주 어려운 시간을 가짐

• SW 개발에 있어서 완벽한 PERT 차트를 기대하기는 어려움

• 당장 눈에 있는 정보를 기반으로 결정해야 함. 그것도 자주.

• 프로젝트 기간 전체에 걸쳐서 이러한 결정 과정을 넓혀야 함

• 이렇게 함으로써 가능한 한 초반에 그리고 자주 정보를 획득하는 절차를 가질 수 있음을 보장함

• 이러한 절차에 사용자 스토리가 적합한 기법임

안개고지전투 - vizend.tistory.com/38



정의 • 시스템 사용자 혹은 구매자에게 가치가 될 만한 기능을 기술한 내용

• 계획과 기억을 위해 사용되는 작성된 이야기 기술 [Card]

• 상세 내용을 구체화시키는데 도움이 되는 이야기에 대한 대화 [Conversation]

• 상세 내용을 전달하고 문서화시키고 스토리가 완전한지를 결정하는데 사용될 수 있는지를 점검 [Confirmation]

• “Card는 고객 요구사항을 문서화시키는 것이 아닌 요구사항 자체를 나타냄”

• Card가 스토리의 텍스트를 포함하고 있는 반면에 세부사항은 결국 대화(Conversation)통해 나타나며 확인(Confirmation) 과정에서 기록됨

alaverdyan.com/readme/2011/11/getting-a-user-story-ready-for-a-sprint-%E2%80%93-story-status/



스토리 카드 작성 방법 • Independent : 스토리 간에 의존성을 회피. 카드의 결합과 분리

• Negotiable : 스토리 카드는 기능에 대한 짧은 기술을 표현. 고객과 개발자간의 대화를 통해서 세부사항들은 협의 및 협상

• Valuable : 각각의 스토리는 고객이나 사용자에게 가치가 있어야 함. 고객이나 사용자가 직접 작성하는 스토리 카드

• Estimatable : 스토리가 동작하는 코드로 바꾸는데 걸리는 시간을 예측할 수 있어야 함. 상대적인 스토리 크기

• Small : 예측이 가능하고 우선순위를 매길 수 있고 테스트할 수 있을 정도의 크기

• Testable : 스토리에 대한 구현이 완료되었다는 기준을 결정하기 위한 테스트를 표현



사용자 역할 모델 • 사용자 역할은 사용자들에 대한 특징을 그룹핑하고 시스템과의 의도된 상호작용을 특징짓는 정의된 속성들의 집합

• 역할 모델링 단계 초기 사용자 역할에 대한 브레인 스토밍

초기 역할에 대한 구조화

역할에 대한 정리 (병합)

역할 정제



사용자 역할 식별 기법 • 페르소나 (persona)

• Extreme Character

uxcosmos.tistory.com/109

영화 ‘하면 된다’ (2000, 박대영 감독, 안석환, 정준, 박진희 출연)



Agile Software Requirements Model

www.scaledagileframework.com/agile-software-requirements-model



좋은 사용자 스토리 • 사용자의 역할을 기술하는 스토리로 시작

• 스토리를 더 작은 단위로 나눌때에 기술적인 관점이 아닌 기능적인 관점으로 나눔

• 의미있는 목적을 달성하는데 충분히 끝내는 스토리를 작성

• 스토리 카드에 제약사항을 표시

• 가장 가까운 인터레이션의 스토리에 초점을 맞추지만, 확장성을 염두하여 더 멀리 있는 이터레이션의 스토리를 고려

• 가능한 한 UI 이슈는 더 오래 유지하라

• 어떤 내용은 스토리가 아닌 것도 있다

• 스토리에 사용자 역할을 포함하라

• 한 사용자에 대해 스토리를 작성하라

• 수동태가 아닌 능동태 형식으로 스토리를 작성하라

• 이상적으로는 고객이 스토리를 작성하며 우선순위를 매긴다

• 스토리 카드를 넘버링하지 마라

• 목적을 잊어버리지 마라


4. 스토리 점수

예측 (estimation) • 팀 단위로

• 각 스토리에 대해

• 점수로 환산하여 측정

Delphi 신전


4. 스토리 점수

Wideband Delphi 예측 방식 • RAND 사에서 5-60년대에 예측 기법으로 Delphi 방법을 개발

• 70년대에 Barry Boehm과 John A. Farquhar가 Wideband라는 이름을 붙여서 발전

• Planning Poker

greatkim91.tistory.com/129

greatkim91.tistory.com/178


4. 스토리 점수

속도 (velocity) • 이터레이션 내에서 완료한 작업의 수(스토리 포인트)를 계산

• Burn-down chart

vizend.tistory.com/34

Ⅰ-23

스크럼(Scrum) - 목차 1. 스크럼

2. 역할

3. 활동

4. Agile Game Framework

5. WIP

6. Scaling Agile @ Spotify

작성자: 이충헌([email protected])


1. 스크럼 (Scrum)

스크럼이란 • 혁신적인 제품이나 서비스를 개발하는 애자일 방식

Feature A

Feature B

Feature C

Iteration Planning

Iteration Review

Feature A

Feature B

Feature C

Iteration (1 week to 1 calendar month)

Product Backlog

self-organizing, cross-functional team


1. 스크럼 (Scrum)

구성 요소 • 역할 : Product Owner / ScrumMaster / Development Team

• 활동 : Sprint / Sprint Planning / Daily Scrum / Sprint Execution / Sprint Review / Sprint Retrospective / Product Backlog Grooming

• 산출물 : Product Backlog / Sprint Backlog / Potentially Shippable Product Increment

www.informit.com/articles/article.aspx?p=1952809


2. 역할

Scrum 팀 • Product Owner

– 제품 개발에 있어서 가장 중앙에 위치한 역할

– 구축할 기능을 결정하고 순서를 결정하는 단일 권한을 소유

– 스크럼팀이 추구할 명확한 비전을 모든 구성원과 의사 소통

• ScrumMaster

– 스크럼이 추구하는 가치, 원리, 기법을 이해하고 포용할 수 있도록 팀원들을 도움

– 프로세스에 대한 리더쉽을 발휘하고 가장 성과가 나고 조직에 특화된 스크럼 방식을 추구하도록 팀을 돕는 코치 역할

– 팀 생산성에 방해되는 장애물들을 제거하여 작업에 몰두할 수 있는 여건 마련

– 스크럼팀의 리더 역할을 수행하지만, 관리자는 아님

• Development Team

– SW 개발에 있어서 다양한 역할을 정의하여 이를 특정 담당자가 수행하는 형태가 아닌 개개인이 다양한 역할을 수행할 수 있는 기능을 가로지르는 (cross-functional) 구성원으로 구성

– 제품소유자로부터 독립적으로 목표를 달성하기 위해 가장 최고의 방법을 결정하도록 자기 조직화(self-organized)됨

– 통상 5-9 명으로 개발팀을 구성

– 그 이상 많은 구성원이 있는 경우 별도의 스크럼팀을 구성하여 Scrum of Scrums 구성이 가능


3. 활동

Product Backlog • 제품소유자는 제품 백로그에 작업 내용과 순서를 등록하여 기재

• 최초에는 제품소유자 관점의 필요한 기능들이 식별

• 제품 개발을 진행하면서 새로운 기능이나, 기존 기능의 변경, 오류, 기술적인 향상 등이 추가

• 우선순위가 높은 항목들이 상위에 위치

• 제품 백로그 항목을 만들고 정제하고 추정하고 우선순위를 매기는 행위가 grooming이라고 함.

Feature A | 5

Feature B | 3

Feature C | 2

Defect 23 | 5

Refactor X | 8

Feature D

Feature E

Feature F

Product Backlog

우선순위가 높은 항목들

우선순위가 낮은 항목들

항목 생성/정제

항목 우선순위

항목 예측

Product Grooming

상대적인 크기 예측 (일반적으로 스토리 점수)


3. 활동

Sprint • 작업들을 완료하는 하나의 시간 단위 (1개월 단위까지)

• 한 스프린트 내에서 완료한 작업은 고객이나 사용자에게 가시적인 가치를 만들어내야 함

• 스프린트는 타임박스 형태로, 고정된 시작과 종료일이 존재하며 동일한 기간으로 구성

• 새로운 스프린트는 이전 스프린트 종료 다음에 바로 시작

• 한 스프린트 내에서 수행하는 작업이나 목표는 되도록 바뀌면 안됨

Sprint 1 Sprint 2 Sprint 3 Sprint 4

시작일 종료일

최대 1개월 분량의 타임박스


3. 활동

Sprint Planning • 제품 백로그에서 한 스프린트에서 수행할 항목들을 결정하는 작업 (한 스프린트는 2~4주 정도의 기간)

• 제품 소유자와 개발팀은 해당 스프린트에서 달성할 목표를 정의하는 스프린트 목표에 합의

• 정해진 목표에 부합하는 항목을 제품 백로그에서 우선순위에 따라 지속적인 페이스로 작업할 수 있는 내용을 선정

• 백로그 내의 항목에 대해 수행할 작업으로 나누어서 sprint backlog로 구성

Feature A | 5

Feature B | 3

Feature C | 2

Defect 23 | 5

Refactor X | 8

Feature D

Feature E

Feature F

Product Backlog

Feature A | 5

Feature B | 3

Feature C | 2

UI 코딩 5시간

테스트 자동화 8시간

DB 작업 6시간

에러 로깅 추가 12시간

아이콘 생성 8시간

테스트 여유시간 2시간

그래픽 라이브러리 설치 8시간

테스트 자동화 6시간

개별 기능들 더 작은 작업들로 나뉨

개별 작업은 시간 단위 추정

Sprint Planning

Sprint Backlog


3. 활동

Sprint 실행 • 스크럼 마스터의 코치로 기능을 완성하기 위한 모든 작업을 수행

• “완료”(done)는 좋은 품질의 기능을 완성하기 위해 필요한 모든 작업이 수행되었음을 의미

• 작업을 수행하는 과정에서 개발팀에서 어떠한 순서로 그리고 어떠한 방법으로 작업을 수행하라고 말하지 않음

• 팀 구성원들은 자신의 작업을 정의하고 스프린트 목표를 달성하는데 최선의 방법이라고 느끼도록 자기 조직화되어서 수행

Sprint Backlog

Feature A

Feature B

Feature C

Sprint 실행

개별 스프린트에서 보내는 시간의 대부분이 스프린트 실행에 사용됨

개별 기능(feature)은 해당 기능을 완료하기 위해 팀이 수행하는 작업들로 구성


3. 활동

Daily Scrum • 스프린트 동안 매일 (가능하면 동일 시간에) 개발팀 구성원들은 15분 이내의 짧은 미팅을 수행

• 미팅 동안 되돌아보고-개선하는(inspect-and-adapt) 활동을 수행

• 짧은 회의를 위해 일어서서 회의한다고 하여 daily stand-up 미팅이라고도 함

• 세가지 내용에 대한 질문에 돌아가면서 답변하는 형태 – 지난 일일 스크럼 동안 작업한 내용이 무엇인가

– 다음 일일 스크럼까지 계획된 작업 내용이 무엇인가

– 진행하는데 있어서 걸림돌이 되는 장애나 문제가 무엇인가

• 일일 스크럼은 문제를 해결하는 활동이 아니며 스프린트 백로그의 현황에 대한 공유 시간

• Scrum 팀 이외의 다른 사람도 회의 참석이 가능하지만, 발언권이 없음 (돼지와 닭)

www.kennethvr.be/blog/2011/07/28/scrum-and-scrum-roles


3. 활동

완료 (done) • 스프린트의 결과는 잠재적으로 탑재가능한 제품의 증분(potentially shippable product increment)

– 스크럼 팀에서 합의한 것을 완료라는 합의된 정의에 따라 실제로 수행한 내용

• 수행한 작업은 좋은 품질을 보장하고 잠재적으로 배포가 가능한 형태

• 설계, 구축, 통합, 테스트, 문서화라는 작업이 수행하여 완료한 제품의 완전한 (일부) 기능

• 탑재(shipping)는 비즈니스적인 결정이며, ‘탑재가능한’이라는 의미가 실제로 배포하는 것을 의미하지는 않음 – “고객 배포를 정의할 만큼 충분한 기능이나 고객 워크플로우를 가지는가”

– “고객은 2주전에 배포한 내용에 또 다른 변화를 받아들일 수 있는가”

• ‘잠재적으로 탑재가능한’이라는 의미는 스프린트에서 구축한 것이 실제로 완료되었으며 스프린트의 결과를 배포하기 전에 완료를 위해 필요한 중요하게 수행하지 않은 작업이 없음을 의미

deviq.com/shipping-is-a-feature


3. 활동

Sprint Review • 스프린트 동안 구축한 제품에 대해 되돌아보고-개선할(inspect-and-adapt) 내용을 토의

• 스프린트 리뷰에는 스크럼팀, 이해관계자, 후원자, 고객, 그 밖에 관심있는 구성원들이 참여하여 대화에 참여

• 대화의 초점은 방금 완료한 기능에 대한 검토

• 스크럼팀 이외의 사람들은 개발 내용에 대해 공유하고 방향성을 제시, 동시에 스크럼팀은 고객이나 사용자들의 관점에서 제품에 대한 잦은 피드백을 얻음으로써 비즈니스적이고 마케팅 측면에 대한 깊은 인식을 획득

Inspect

Adapt Sprint Review


3. 활동

Sprint Retrospective • 스프린트 리뷰 이후, 그 다음 스프린트 계획 전에 수행

• 스프린트 리뷰는 제품에 대해 되돌아보고-개선을 하는 시간인 반면에, 스프린트 회고는 절차(프로세스)에 대해 되돌아보고-개선을 하는 시간

• 개발팀, 스크럼 마스터, 제품소유자는 스크럼에서 수행한 것과 그렇지 않은 것을 토의하고 관련된 기술적인 이슈를 이야기함

• 더 나은 스크럼팀이 되는데 도움이 되는데 필요한 지속적인 프로세스 개선(continuous process improvement)에 초점

• 스프린트 회고를 한 뒤에 그 다음 스프린트에 적용할 개선점이나 기법을 식별해야 함

• 스프린트 회고가 끝난 뒤에 그 다음 스프린트 계획을 다시 반복해서 시작함

Inspect

Adapt

Sprint Retrospective


4. Agile Game Framework (AGF)

게임을 통해 애자일 절차 습득 • 단순하지만, 절차를 익히는데 좋은 기법

• 계획(추정)에 대한 전반적인 이해

• 애자일 프랙티스의 활용 방법

• 스토리 카드에 대한 우선순위 결정 방법

vizend.tistory.com/36


5. WIP (Work In Process)

Work in process • 시작된 상태이지만 아직 끝나지 않은 작업으로, 제품 개발 동안 WIP를 식별하고 적절하게 관리해야 함

• 경제적으로 의미있는 배치 크기를 사용

• 재고(inventory)를 식별하고 일정한 흐름을 유지

• 놀고 있는(idle) 작업자가 아니라, 놀고 있는 작업에 초점

• 지연에 대한 비용을 고려

A

B

C

D

20 5

10 14 A

12 17 B

11 13 C

17 15 D

50 18 첫번째

50 34 전체

1

18

19

15

15

4

20


5. WIP (Work In Process)

Work in process • WIP를 줄일수록 전체 프로세스 동안 더 빠른 흐름을 얻음 (더 짧은 리드타임)

• 시작하는 것을 멈추고 끝내는 것을 시작하라 (stop starting and start finishing)

• WIP를 제한하는 것을 엄격하게 통제하는 것이 아니라, 개선에 대한 시작점임

• WIP의 수를 제한하는 것이 더 나은 흐름을 유발시킴

• 해당 팀에 하나의 정확한 WIP 제한이 존재하지 않음

• 너무나 높은 WIP은 작업을 놀게 하고, 너무나 낮은 WIP은 사람을 놀게 만든다

agile4freshmen.blogspot.kr/2012/01/kanban-overview.html

www.outsystems.com/blog/2010/11/scrum-vs-kanban.html


6. Scaling Agile @ Spotify

스웨덴의 Spotify 사 • 서비스 지향적인 회사, 100개의 서로 다른 시스템과 독립적인 유지 및 배포

• Squad : 하나의 스크럼팀과 유사

• Tribe : 관련된 영역의 작업을 하는 Squad의 집합

• Chapter : 동일 Tribe 내에서 유사한 기술을 가진 그룹

• Guild : 유사한 관심사를 가진 그룹, Chapter와 달리 Tribe를 건너뛰어 구성

dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf


참고 서적 및 문헌

서적 • User Stories Applied : For Agile Software Development, Addison-Wesley, Mike Cohn, 2004

• Essential Scrum : A Practical Guide to the Most Popular Agile Process, Addison-Wesley, Kenneth S. Rubin, 2012

• Kanban in Action, Manning, Marcus Hammarberg & Joakim Sunden, 2013

사이트 • agilealliance.org, Agile Alliance

• scaledagileframework.com, Scaled Agile Framework

• scrumguides.org, Scrum Guide

• scrumalliance.org, Scrum Alliance

사용자스토리 애자일

Technology