프로젝트 관리 청사진 1부: Agile, Scrum, Kanban 및 Lean의 포괄적인 비교

개요

오늘날 소프트웨어 개발에는 많은 방법론이 사용됩니다. Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming 등과 같은 유행어를 들어보셨을 것입니다.

이 기사에서는 이러한 용어를 정의하고 서로 어떻게 관련되고 어떻게 다른지 논의합니다. 앞서 언급한 많은 유행어들은 원래 Toyota Manufacturing System(TPS)에 기반을 둔 Lean Manufacturing의 개념을 기반으로 하므로 먼저 이에 대해 이야기하겠습니다.

린 방법론

린 및 린 제조의 기원

"린"이라는 용어는 원래 Henry Ford에서 영감을 받은 Sakichi Toyoda, Kiichiro Toyoda, Taiichi Ohno가 개발한 TPS(Toyota Production System)를 기반으로 한 제조 모델을 설명하기 위해 만들어졌습니다. TPS는 1950년대부터 1970년대까지 "모든 폐기물의 완전한 제거"라는 철학에 초점을 맞추고 제조에 혁명을 일으켰습니다. TPS는 1990년 "세계를 바꾼 기계"가 출판되면서 "린 제조"로 알려지게 되었습니다.

TPS는 Toyota에서 세 가지 광범위한 유형의 폐기물을 식별했습니다.

• Muda: "쓰레기"로 번역됩니다. Toyota에서 확인된 7가지 유형의 무다는 나중에 8가지 유형이 추가되었습니다. 이것들은:
  • 결함: 결함 을 찾고 수정하는 데 필요한 노력
  • 과잉 생산: 수요보다 앞서 생산
  • 대기 중: 다음 생산 단계를 기다리는 중, 중단 등
  • 미사용 재능: 능력을 충분히 활용하지 않고, 훈련이 미흡한 경우 등
  • 운송: 가공에 필요하지 않은 움직이는 부품 또는 제품
  • 재고: 완성된 재고 및 진행 중인 작업
  • 모션: 처리에 필요한 것보다 더 많이 움직이거나 걷기

  • 과잉 처리: 열악한 툴링 또는 제품 설계에서

• 무리: "과중한 짐"으로 번역됩니다. Muri는 일반적으로 mura에서 발생하지만 muda에서 발생할 수도 있습니다. 무리는 고장, 결근, 안전 문제 등으로 나타납니다.
• 무라: "불균일함"으로 번역됩니다. Mura는 고객 요구의 변동, 제품당 프로세스 시간 또는 다양한 작업자에 대한 주기 시간의 변동에서 찾을 수 있습니다. 무라가 감소하지 않으면 무라의 가능성이 증가하므로 무다가 발생합니다. Mura는 공급망에 개방성을 만들고, 제품 디자인을 변경하고, 모든 운영자를 위한 표준 작업을 생성하여 줄일 수 있습니다.

TPS는 다음 두 가지 핵심 개념을 적용하여 낭비를 없애기 위해 노력했습니다.

• Jidoka: 느슨하게 번역된 "인간의 손길을 통한 자동화"는 "품질은 제조 과정에서 구축되어야 합니다!"라고 규정합니다. 즉, 문제 발생 시 즉시 설비를 정지시켜 불량품이 생산되는 것을 방지합니다.
• Just-in-Time: "필요한 만큼, 필요할 때, 필요한 만큼만" 만드는 것.

TPS가 발전함에 따라 이러한 핵심 기둥과 가치는 Jidoka 및 JIT의 개념을 기반으로 구축되고 확고히 자리 잡았습니다.

• 지속적인 개선:
  • 도전: 꿈을 실현하기 위한 용기와 창의성으로 장기적인 비전을 세우고 도전
  • Kaizen: 비즈니스 운영을 지속적으로 개선하고 항상 혁신과 진화를 추구하며 한 번에 하나의 무다를 제거합니다.
  • 겐치 겐불(genchi genbutsu) : 겐치 겐불(genchi genbutsu)을 실천하고, 정확한 결정을 내리고, 공감대를 형성하고, 최고의 속도로 목표를 달성하기 위해 사실을 찾기 위해 근원에 갑니다.
• 사람에 대한 존중:
  • 존중: 서로를 존중하고 이해하기 위해 최선을 다하고 책임감을 갖고 최선을 다하여 상호 신뢰 구축
  • 팀워크: 개인 및 직업적 성장 촉진, 개발 기회 공유, 개인 및 팀 성과 극대화
• Andon: 상태 또는 문제의 시각적 표시기
• Heijunka: 평준화 또는 생산 평준화를 의미
• Hansei: 자기 반성을 의미합니다. 효율성을 개선하기 위해 작업자는 더 나은 프로세스를 찾기 위해 현재 프로세스 이면의 가정에 도전해야 합니다.
• Kanban: 생산을 제어하는 ​​시각적 도구로 사용되는 간판
• 포카요케: 실수 교정 또는 오류 교정이라고도 함
• 풀 시스템: 필요한 만큼 재료를 워크스테이션으로 끌어옵니다.
• Seiri: 낭비를 반영하는 원칙입니다. Seiri는 불필요한 것은 제거해야 한다고 지시합니다. 이것은 TPS의 원래 7가지 낭비를 모두 포함합니다.
• 표준화: 인간의 움직임을 중심으로 모든 작업을 구성하고 무다 없이 효율적인 생산 순서를 만듭니다. 이는 품질, 일정한 속도로 이어지는 데 도움이 되며 지속적인 개선을 가능하게 합니다.

아래 다이어그램은 핵심 개념과 핵심 가치가 서로 어떻게 관련되어 있는지 보여줍니다.

린 관리

Toyota Product System과 Lean Manufacturing은 시간이 지남에 따라 진화했으며 관리를 비롯한 여러 영역에 적용되었습니다.

린 매니지먼트는 지속적인 개선과 사람에 대한 존중이라는 핵심 가치를 적용하고 낭비를 지속적으로 개선하고 제거하기 위해 여러 번 반복되는 5가지 규범적인 린 원칙 세트로 정제했습니다.

1. 가치 식별: 제품군별로 최종 고객의 입장에서 가치를 지정합니다.
2. 가치 흐름 매핑: 각 제품군에 대한 가치 흐름의 모든 단계를 식별하고 가능한 한 가치를 창출하지 않는 단계를 제거합니다.
3. 흐름 만들기: 제품이 고객에게 원활하게 흐르도록 가치 창출 단계가 빡빡한 순서로 발생하도록 합니다.
4. 당기기 설정: 흐름이 도입되면 고객이 다음 업스트림 활동에서 가치를 끌어낼 수 있습니다.
5. 완벽 추구: 가치가 지정되면 가치 흐름이 식별되고 낭비되는 단계가 제거되고 흐름과 끌어당김이 도입되고 프로세스를 다시 시작하고 낭비 없이 완벽한 가치가 생성되는 완벽 상태에 도달할 때까지 계속합니다.

이러한 원칙과 린 관리의 다른 측면은 1996년 Womack & Jones가 "린 사고(Lean Thinking)"를 출판했을 때 공식화되었습니다.

린 소프트웨어 개발

이후 Lean은 관리, 소프트웨어 개발 및 기타 분야에 적용되었습니다.

1980년대와 1990년대에 소프트웨어 개발 산업은 전통적인 폭포수 방식을 사용하여 실행되는 프로젝트가 점점 더 오래 걸리면서 위기에 직면했습니다. 이로 인해 비즈니스 요구 사항을 파악하고 소프트웨어 솔루션을 제공하는 데 상당한 지연이 발생하는 경우가 많았습니다. 때때로 이 지연은 항공 우주 산업과 같이 특정 요구 사항이 있는 특정 산업에서 수년 또는 수십 년 동안 측정되었습니다.

이러한 다년간의 기간 동안 요구 사항, 시스템 또는 전체 비즈니스가 변경되었습니다. 종종 프로젝트는 도중에 취소되거나 범위를 완료했지만 전달한 내용이 프로젝트 시작 시 식별된 비즈니스 요구 사항을 더 이상 충족하지 못한다는 사실을 알게 됩니다.

Waterfall 방법론은 이해 관계자가 필요한 것이 무엇인지 확신하지 못하더라도 계약서를 작성해야 할 때 모든 것을 생각하는 것에 대해 보상했습니다. Waterfall 방법론은 요구 사항 또는 설계 단계에서 결정을 내리도록 강요했으며 이러한 결정은 계약을 변경하고 프로젝트에 비용을 추가하지 않고는 변경하기가 매우 어려웠습니다. 많은 수의 소프트웨어 프로젝트가 완전히 실패했거나 예산을 초과하여 늦게 제공되었거나 필요한 것을 제공하지 못했습니다.

이러한 일반적인 좌절은 Waterfall을 개선하려는 다양한 사상가 리더들로 이어졌습니다. 초기 사례에는 프로토타입을 신속하게 개발하고 요구 사항을 추가로 개발하기 위해 비즈니스와 협력하여 요구 사항 및 설계 단계를 단축하여 낭비를 줄이는 데 중점을 둔 RAD(Rapid Application Development)가 있습니다. 소규모 프로젝트가 완료되고 기능이 지속적인 반복으로 추가되는 반복적인 개발을 향한 움직임도 있었습니다. 이러한 방법론이 도움이 되었지만 Waterfall과 관련된 핵심 문제를 해결하지는 못했습니다.

1990년대와 2000년대 초반에 몇몇 저자들은 소프트웨어 개발에 린 원칙을 적용하는 것에 관한 책을 출판했습니다. Robert Charette 박사는 1993년에 "린 소프트웨어 개발"을, 2003년에 "린 소프트웨어 개발의 12가지 원칙"을 출판했습니다.

Tom과 Mary Poppendieck은 2003년에 "린 소프트웨어 개발: 애자일 툴킷"을 출판했습니다. 이 책은 린 제조의 7가지 형태의 낭비와 직접적인 상관관계가 있는 린 개발의 7가지 원칙에 대해 자세히 설명했습니다. 두 개의 서로 다른 Lean 출판물과 Agile(다음 섹션에서 설명) 간의 유사점과 차이점은 아래 다이어그램에 나와 있습니다.

린과 애자일의 차이점

Charette 박사에 따르면 Lean과 Agile의 주요 차이점 중 하나는 Agile은 상향식이고 Lean은 하향식이라는 것입니다.

애자일 프레임워크

애자일의 기원과 애자일 선언문

Charette와 Poppendiecks가 책을 출판한 시기에 같은 문제를 해결하기 위해 Agile Framework가 만들어졌습니다. 2001년 2월, 애자일 개척자 그룹이 유타주 Snowbird에서 열린 악명 높은 Snowbird 회의에서 만나 해결책을 모색했습니다.

그 결과 변화하는 요구 사항과 고객 요구 사항에 적응하고, 낭비를 줄이며, 점진적이고 반복적인 접근 방식을 사용하여 더 빠르게 혜택을 제공하려는 방법론에 대한 일련의 가치와 원칙을 제시한 Agile Manifesto가 탄생했습니다.

애자일 선언문은 다음과 같이 읽습니다.

“우리는 소프트웨어를 개발하고 다른 사람들이 하도록 도와줌으로써 더 나은 소프트웨어 개발 방법을 찾고 있습니다. 이 작업을 통해 우리는 다음을 가치 있게 생각하게 되었습니다.

• 프로세스 및 도구에 대한 개인 및 상호 작용
• 포괄적인 문서보다 작업 소프트웨어
• 계약 협상을 통한 고객 협업
• 계획 에 따른 변경에 대한 대응

즉, 오른쪽 항목에 가치가 있으면 왼쪽 항목에 더 가치가 있습니다.”

애자일 선언문 뒤에 있는 12가지 원칙은 매니페스토의 가치와 일치합니다.

“우리는 다음 원칙을 따릅니다.

1. 우리의 최우선 과제는 귀중한 소프트웨어를 조기에 지속적으로 제공하여 고객을 만족시키는 것입니다.
2. 개발이 늦어도 변화하는 요구 사항을 환영합니다. 애자일 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.
3. 작업 소프트웨어를 몇 주에서 몇 달까지 자주 제공하고 더 짧은 기간을 선호합니다.
4. 비즈니스 사람과 개발자는 프로젝트 전반에 걸쳐 매일 함께 작업해야 합니다.
5. 동기 부여된 개인을 중심으로 프로젝트를 구축하십시오. 그들에게 필요한 환경과 지원을 제공하고 그들이 일을 완수할 수 있도록 신뢰하십시오.
6. 개발 팀과 개발 팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.
7. 작동하는 소프트웨어는 진행 상황의 주요 척도입니다. 애자일 프로세스는 지속 가능한 개발을 촉진합니다.
8. 스폰서, 개발자 및 사용자는 무한정 일정한 속도를 유지할 수 있어야 합니다.
9. 기술적 우수성과 우수한 디자인에 대한 지속적인 관심은 민첩성을 향상시킵니다.
10. 수행하지 않은 작업의 양을 최대화하는 기술인 단순성은 필수적입니다.
11. 최고의 아키텍처, 요구 사항 및 디자인은 자체 구성 팀에서 나옵니다.
12. 정기적으로 팀은 어떻게 하면 더 효과적일지 숙고한 다음 그에 따라 행동을 조정하고 조정합니다."

위의 가치와 원칙은 Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka 및 폐기물 감소와 같은 Lean 원칙의 적용입니다.

소프트웨어 개발에 적용된 애자일 원칙

Agile은 Agile 가치 및 원칙 집합을 적용하는 모든 프로세스에 적용되는 포괄적인 프레임워크입니다.

몇 가지 예는 다음과 같습니다.

• 익스트림 프로그래밍
• 스크럼
• 칸반

스크럼

쓰레기의 간략한 역사

스크럼은 애자일 선언문에 서명한 여러 사람을 포함해 여러 사람이 별도로 고안한 애자일 원칙을 적용하는 프레임워크입니다.

• Hirotaka Takeuchi와 Ikujiro Nonaka는 백서 "The New Product Development Game"에서 제조 맥락에서 "스크럼"이라는 용어를 처음 도입했습니다. 1986년 Harvard Business Review에 발표되었습니다.
• Jeff Sutherland, John Scumniotales 및 Jeff McKenna는 1993년 Easel Corporation에서 스크럼을 구현했습니다.
• Ken Schwaber는 1990년대에 그의 회사인 Advanced Development Methods에서 스크럼이 된 것을 사용했습니다.

Schwaber와 Sutherland는 1990년대 내내 협력하여 소프트웨어 개발 맥락에서 프레임워크를 개발하고 개선했으며 다양한 회의에서 연설했습니다. Schwaber는 Mike Beedle과 함께 2001년 "스크럼을 사용한 애자일 소프트웨어 개발"이라는 책에서 방법을 설명했습니다.

Schwaber는 계속해서 두 가지 주요 스크럼 인증 기관을 만들었습니다.

• Scrum Alliance: 2001년에 만들어졌습니다. Certified Scrum 인증 시리즈를 설정합니다.
• Scrum.org: Schwaber가 Scrum Alliance를 떠난 후 2009년에 만들어졌습니다. 병렬 Professional Scrum 인증 시리즈를 설정합니다.

시간이 지남에 따라 Scrum이 원래 소규모 팀(7명 또는 마이너스 2명)을 위해 설계되었으므로 스크럼 프레임워크를 더 큰 팀 및 프로젝트로 확장하는 문제를 해결하기 위해 여러 프레임워크/인증 기관이 만들어졌습니다.

• SAFe: 확장된 애자일 프레임워크
• LeSS: 대규모 스크럼
• Scrum@scale: Jeff Sutherland가 만든 규모의 스크럼

스크럼 가치

스크럼 얼라이언스에 따르면:

스크럼은 팀이 짧은 주기로 제품을 제공하여 빠른 피드백, 지속적인 개선 및 변화에 대한 빠른 적응을 가능하게 하는 간단하면서도 믿을 수 없을 정도로 강력한 원칙 및 관행 세트입니다.

스크럼은 애자일 원칙을 적용하는 소프트웨어 개발을 위한 규범적이고 점진적이며 반복적인 프레임워크입니다. 스크럼 가치와 원칙은 아래 차트에 요약되어 있으며 린 및 애자일 가치 및 원칙과 크게 일치합니다.

스크럼 개요

작업은 일반적으로 1-3주인 스프린트라고 하는 짧은 시간 상자 반복으로 나뉩니다. 이것은 Waterfall의 심층 계획과 완전히 대조됩니다. 현재 스프린트에 계획된 작업은 Product Backlog(Pull System, Heijunka)라고 하는 작업 항목의 우선순위 백로그 상단에서 선택되며, 스프린트가 시작되면 고정됩니다. 목표는 각 스프린트가 끝날 때 소프트웨어가 작동하여 빠른 피드백을 가능하게 하는 것입니다.

스프린트가 끝나면 팀은 완료된 작업, 스프린트가 어떻게 진행되었는지 검토하고 다음 스프린트를 계획하기 위해 모입니다. 스프린트 길이와 스프린트 의식 및 케이던스는 각 스프린트에 대해 고정되어 있습니다.

스프린트는 스프린트에서 작업을 완료하는 데 필요한 모든 기술을 포함하는 교차 기능 팀에 의해 실행됩니다. 일일 계획 및 진행 상황 추적은 스크럼 보드 및 스프린트 번다운 차트와 같은 시각적 아티팩트를 사용하여 수행됩니다.

스프린트의 작업은 우선 순위가 지정된 백로그에서 가져옵니다. 이러한 방법을 따르면 시간이 지남에 따라 요구 사항을 변경할 수 있으며 최종 사용자로부터 지속적인 피드백을 받을 수 있습니다.

아래의 마인드 맵 다이어그램은 다음 섹션에서 논의될 Scum의 주요 개념 중 일부를 간략하게 설명합니다.

스크럼 역할

스크럼에는 세 가지 역할이 있습니다.

• 스크럼 마스터 : 스크럼 마스터는 스크럼 팀의 서번트 리더입니다. 그들은 협업을 촉진하고, 장애를 제거하고, 스크럼 프로세스를 시행 및 보호하고, 팀을 보호하는 팀의 코치입니다. 이것은 일반적으로 그들이 스프린트 의식을 조직하고 촉진하고, 제품 소유자가 적절하게 우선 순위를 지정하고 정리된 백로그를 갖고 있는지 확인하고, 팀이 스프린트에 과도하게 커밋하도록 압력을 가하지 않도록 하고, 범위가 스프린트는 완료의 정의가 준수되도록 합니다. 그들은 팀 구성원(Genchi Genbutsu)에게 작업을 할당하지 않으며 프로젝트 전달에 대한 책임이 없습니다.
• 상품주인 : 상품의 오너는 상품의 배송을 책임지는 '말랑말랑한 목'입니다. 제품 소유자는 구축하려는 비전을 정의하고 해당 비전을 팀과 조직에 전달합니다. 제품 소유자는 비즈니스 및 시장 요구 사항을 소유하고 제품 백로그 생성 및 관리를 통해 수행해야 하는 모든 작업의 ​​우선 순위를 지정합니다. 그들은 언제 어떤 기능을 출시할지 결정합니다. 그들은 팀 및 기타 이해 관계자와 협력하여 모든 사람이 제품 백로그의 항목을 이해하고 있는지 확인합니다. 그들은 스프린트 데모에서 스프린트에서 완료된 작업을 수락하거나 거부합니다.
• 팀 구성원 : 스크럼 팀은 일반적으로 5~7명의 구성원으로 구성된 자체 구성의 교차 기능 팀입니다. 프로젝트의 모든 사람은 함께 작업하고 서로를 도우며 건축가, 프로그래머, 디자이너 또는 테스터와 같은 고유한 역할에 반드시 얽매이지 않습니다. 모두가 함께 작업 세트를 완료합니다. Scrum 팀은 각 스프린트를 완료할 수 있는 작업의 양을 계획하고 계획을 소유합니다(Genchi Genbutsu).

스크럼 흐름, 활동 및 행사

위에서 논의한 바와 같이 스크럼에는 정의된 흐름과 일련의 의식 및 활동이 있습니다. 스프린트의 흐름은 다음과 같다.

스프린트 계획:

스프린트가 시작되기 전에 스크럼 마스터는 스프린트 계획 회의라고 하는 스크럼 팀 및 제품 소유자와의 회의를 촉진합니다. 여기서 제품 소유자는 다가오는 스프린트의 목표를 식별하고 팀은 목표에 따라 작업을 계획합니다.

이것은 일반적으로 다음 활동으로 수행됩니다.

• 스프린트 용량: 팀은 일수, 팀원 수, 휴일 등을 고려하여 스프린트 용량을 결정합니다.
• 스프린트 목표: 제품 소유자는 스프린트의 목표가 무엇인지 식별합니다. 제품 백로그의 우선 순위를 목표에 따라(즉, 관련 스토리가 맨 위에 있음) 정리하는 것이 중요합니다.
• 작업 선택: 예상 용량에 도달할 때까지 백로그 상단에서 스프린트로 스토리 또는 작업을 가져옵니다. 스토리가 입력되면 제품 소유자는 제품 소유자와 스크럼 팀이 스토리를 잘 이해할 때까지 스토리를 설명하고 팀의 질문에 답하고 필요에 따라 스토리를 업데이트합니다. 이 활동이 완료되면 팀은 제안된 초기 스프린트 범위를 갖게 됩니다.
• 작업 분류: 스크럼 팀은 스토리를 완료하고 모든 승인 기준과 DoD를 처리하는 방법을 계획하는 데 중점을 두고 각 스토리에 대해 자세히 논의합니다. 그들은 이야기를 완료하는 데 필요한 하위 작업 목록을 생성합니다. 하위 작업 목록이 완료되면 스토리의 견적이 검토되고 필요한 경우 업데이트됩니다.
• 스프린트 약속: 모든 스토리가 세분화되고 추정치가 업데이트되면 제안된 초기 스프린트 범위가 검토됩니다. 스프린트에서 스토리를 제거하고 백로그에 다시 넣거나 추가 스토리를 추가할 수 있습니다. 이것이 완료되면 스크럼 팀(스크럼 마스터 또는 제품 소유자가 아님)만이 스프린트에서 작업을 완료하기로 약속하고 스프린트가 시작됩니다.

스프린트를 위해 커밋된 작업 또는 범위의 총량은 스토리 포인트로 측정됩니다.

스프린트 실행

스프린트 동안 팀 구성원은 작업할 스프린트 할 일 목록의 맨 위에서 작업 항목(사용자 스토리, 작업 등)을 가져옵니다. 다양한 팀 구성원이 다양한 작업 항목 또는 해당 하위 작업에 대해 작업합니다. 그들은 완료될 때까지 스크럼 보드의 한 열에서 다음 열(일반적으로 할 일 > 진행 중 > 테스트 > 완료 또는 일부 변형)로 항목을 이동하여 적절할 때 항목의 상태를 업데이트합니다.

진행 상황은 완료된 작업의 양과 스토리 포인트로 측정된 남은 작업의 양을 보여주는 번다운 차트를 사용하여 추적됩니다. Y축에는 남은 스토리 포인트가 표시되고 X축에는 남은 시간이 표시됩니다. 번다운 차트는 스토리가 완료되면 업데이트됩니다.

매일 스크럼 마스터는 다음에 중점을 둡니다.

• 일일 스탠드업 미팅을 진행하여 하루를 계획하고 진행 상황을 검토합니다(아래 참조).
• 팀이 그날의 계획을 가지고 있는지 확인합니다.
• 장애물 제거
• 방해 요소로부터 스프린트 범위와 팀을 보호합니다.
• 팀이 번다운 차트 및 기타 스크럼 통계를 유지 관리하는 데 도움이 됩니다.

일일 스탠드업

스프린트의 매일이 시작될 때 스크럼 마스터는 하루를 계획하고 스프린트 진행 상황을 검토하기 위해 스크럼 팀 및 제품 소유자와 15분간의 간단한 회의를 진행합니다. 이것은 모든 사람이 스크럼 보드 앞에 서서 스프린트 보드의 특정 항목을 참조하여 회의의 각 사람이 2분 이내에 다음 질문에 답변하는 짧은 회의입니다.

• 어제 뭐했어?
• 오늘 무엇을 할 계획입니까?
• 작업을 완료하는 데 방해가 되는 장애물이 있습니까?

이를 통해 모든 사람이 모든 사람이 무엇을 하고 있는지, 어떤 진전이 있는지 확인하고, 필요한 장애 및/또는 도움을 식별할 수 있습니다.

스프린트 완료

스크럼 마스터는 다음 스프린트를 계획하기 전에 스프린트를 마무리하기 위해 두 가지 행사를 진행합니다.

스프린트 데모

스프린트가 끝나면 스크럼 마스터는 완성된 각 스토리가 작업 소프트웨어에서 제품 소유자와 나머지 팀에게 시연되는 스프린트 데모 회의를 촉진합니다. 제품 소유자는 모든 수락 기준이 충족되면 스토리를 수락하거나 스토리를 거부합니다. 스토리가 거부되면 부족함이 식별되고 스토리가 나중에 완료되거나 전혀 완료되지 않도록 우선 순위에 따라 제품 백로그에 다시 넣습니다. 종종 제품 소유자가 수락하지 않는 스토리 부분은 별도의 스토리로 분할되고 원래 스토리는 닫힙니다.

스프린트당 완료된 스토리 포인트의 총 수(Velocity)가 계산되고 스프린트가 종료됩니다. 속도는 팀의 출력 수준을 추적하는 데 사용되며 기능 또는 릴리스가 완료될 시기를 예측하는 데 사용됩니다.

스프린트 회고전

스프린트 데모 후 다음 스프린트 계획 회의 전에 스크럼 마스터는 팀이 방금 완료한 스프린트를 반영하고 잘 된 부분과 잘 되지 않은 부분에 대해 토론하는 스프린트 회고전을 촉진하여 지속적으로 점진적으로 프로세스를 개선할 수 있습니다. 시간 경과에 따른 품질(Kaizen, Hansei). 팀이 토론을 생성하는 데 사용할 수 있는 회고 형식이나 연습 문제가 많이 있습니다.

개선 조치 항목의 목록이 생성되며 때로는 제품 백로그에 항목이 추가되거나 DoD 또는 팀 헌장에 대한 변경 등이 발생합니다.

제품 백로그 관리

제품 백로그 생성

스프린트를 계획하거나 실행하기 전에 제품 소유자는 작업의 제품 백로그를 생성해야 합니다. 백로그는 일반적으로 제품 소유자가 작성한 스토리라는 기능 개발 항목으로 시작하며 시간이 지남에 따라 팀 구성원이 잠재적으로 생성한 개발 또는 QA 작업, 스파이크 및 결함 등이 채워집니다. 백로그의 모든 항목은 우선 순위에 따라 정렬됩니다.

백로그 정리

초기 제품 백로그가 생성되고 우선 순위가 지정되면 진행 중인 백로그 정리 프로세스가 인계받습니다. 목표는 항상 최소한 백로그의 상위 항목을 충분히 정리하고 추정하여 스프린트 계획 회의 중에 스프린트로 가져올 준비가 되도록 하는 것입니다. 이는 일반적으로 제품 관리자 및 스크럼 마스터가 촉진하는 팀과 정기적으로 진행 중인 백로그 정리 회의를 통해 수행됩니다.

회의 전에 이야기 목록이 팀에 전송되어 팀이 검토하고 그루밍 회의를 준비할 수 있습니다. 그루밍 미팅에서 각 항목은 수락 기준, 복잡성, 위험, 크기, 구현 전략 등의 측면에서 논의됩니다. 수락 기준 및 스토리의 기타 세부 사항은 팀, 제품 소유자 및 스크럼 마스터까지 검토 및 수정됩니다. 이야기에 대한 공통의 이해를 갖는다. 이 시점에서 스토리는 플래닝 포커라는 기술을 사용하여 스토리 포인트로 추정됩니다.

스토리 포인트 추정

스토리 포인트는 스토리가 이전에 알려지고 잘 이해된 작품과 비교되는 상대적 크기를 사용하는 노력의 단위입니다. 당신은 항상 "이 이야기가 더 크거나, 더 작거나, 거의 같은 크기입니까?"라는 질문을 다른 작품과 동일하게 묻습니다.

피보나치 척도(1, 2, 3, 5, 8, 13, 21…)는 가장 일반적으로 사용되는 척도로 각 증분이 이전 것보다 약 2배 더 큽니다(즉, 5포인트 스토리는 3점짜리 이야기처럼 큽니다.) 때로는 티셔츠 크기(XS, S, M, L, XL) 또는 물고기(미노우, 금붕어, 송어, 참치, 고래 등)와 같은 다른 비늘이 사용되기도 합니다. 어떤 것의 상대적인 크기를 다른 것과 비교할 수 있는 모든 척도가 작동합니다.

스토리 포인트는 개발, 테스트, 디자인 및 완료 정의에 필요한 기타 기타 작업을 포함하여 스토리를 구현하기 위한 팀의 전체 노력을 나타냅니다. 추정치는 작업량, 복잡성 및 위험을 고려합니다. 이야기의 상대적 크기가 결정되면 척도의 크기가 추정치로 할당됩니다.

팀은 전체 팀이 참조 스토리로 이해하는 "가장 중간" 크기의 스토리를 선택하여 먼저 추정 기준을 설정하여 스토리 포인트 추정 프로세스를 준비합니다. 크고 작은 몇 가지 추가 참조 기사도 선택됩니다.

스토리 포인트 추정은 그루밍 미팅 중에 수행되며 때로는 Planning Poker를 사용하여 스프린트 계획 중에 수행됩니다.

1. 각 팀원/추정자는 카드 세트를 가지고 있습니다.
2. 백로그 항목은 위에서 설명한 대로 한 번에 하나씩 논의됩니다.
3. 항목이 완전히 논의되면 각 추정자는 추정치를 나타내는 카드를 개인적으로 선택합니다.
4. 모든 추정자가 추정을 마치면 동시에 카드를 공개합니다.
   • 모든 추정치가 일치하면 추정자는 다른 백로그 항목을 선택하고 동일한 프로세스를 반복합니다.
   • 추정치가 다를 때 추정자들은 합의에 도달하기 위해 문제를 논의합니다.

스토리 포인트 추정의 장점은 다음과 같습니다.

• 빠른: 예상은 이미 완료된 제품 백로그 항목에 상대적입니다.
• 충분히 정확함 : 범위에 대한 개요를 제공하고, 향후 작업을 계획하고, 우선 순위를 지정하고, 기대치를 관리하기에 충분히 정확합니다.
• 불확실성 수용: 스토리 포인트는 알 수 없는 시간 범위를 지정합니다. 특정 피보나치와 같은 스토리 포인트 시퀀스에서 선택하면 불확실성을 포착할 수 있습니다.
• 팀 스포츠: 모든 사람(개발자, 디자이너, QA, 제품 관리자)이 참여합니다. 작업의 규모를 결정하기 위해 여러 관점을 사용하지만 작업을 수행하는 팀 구성원만이 추정할 수 있습니다.
• 팀 속도 측정: 팀이 스프린트에서 수행하는 작업의 양과 작업에 소요된 시간을 측정합니다. 팀이 향상되면 동일한 크기의 스토리를 더 빨리 완료하여 시간이 지남에 따라 스토리 포인트 속도가 빨라집니다.

출시 예측 및 추적

스토리 포인트 추정은 다음 기술을 사용하여 릴리스 계획 컨텍스트에서도 사용됩니다.

1. 크기를 조정할 모든 이야기 나열
2. 작은 것부터 큰 것 순으로 나열하시오.
   • 첫 번째와 두 번째 사용자 스토리를 살펴보세요.
   • 더 큰 것을 결정하고 더 큰 것을 아래에 넣으십시오
   • 그런 다음 다음 항목을 선택하고 다른 두 항목에 상대적으로 적합한 위치를 결정합니다.
   • 모든 이야기가 이제 목록에 있을 때까지 이 과정을 반복합니다(가장 작은 것부터 큰 것 순으로).
3. 스토리 크기 조정

팀의 속도와 결합된 릴리스의 모든 스토리에 대한 스토리 견적을 통해 릴리스가 완료되고 진행 상황을 추적할 수 있는 시점을 예측할 수 있습니다. 이는 릴리스 번-업 차트에 자주 표시됩니다.

스크럼 아티팩트 및 용어

• 제품 백로그: 기능(스토리), 기술 작업, 스파이크 및 결함을 포함할 수 있는 지정된 제품에 대한 모든 작업 항목의 백로그 목록
• 릴리스 번-업: 릴리스 수준에서 진행 상황을 표시하고 Sprint Velocity를 사용하여 릴리스가 완료될 시기를 예측하는 데 사용되는 그래픽 차트입니다. 완료된 스토리 포인트는 Y축에 표시되고 스프린트는 X축에 표시됩니다.
• 스프린트 백로그: 주어진 스프린트에서 완료할 모든 작업 항목의 백로그 목록입니다. 스프린트 백로그의 내용은 스프린트 계획 회의에서 합의됩니다.
• 스크럼 보드: 스프린트를 위해 커밋된 작업의 진행 상황을 추적하는 테이블 스타일 보드입니다. 상태는 수직 열의 상단에 표시되고 작업 항목은 완료될 때까지 각 상태에서 이동됩니다. 스크럼 보드는 스프린트 계획 회의 중에 채워지고 스프린트가 끝나면 재설정됩니다.
• 스프린트 번다운( Sprint Burndown): 스프린트 기간 동안 스토리 포인트로 측정된 완료 및 남은 작업의 양을 보여주는 그래픽 차트입니다. Y축에는 남은 스토리 포인트가 표시되고 X축에는 남은 시간이 표시됩니다.
• 스프린트 속도: 스크럼 팀이 스프린트에서 완료한 스토리 포인트 수.
• 장애 백로그: 팀이 계속 작업할 수 있도록 스크럼 마스터가 해결해야 하는 장애 목록입니다. 팀 구성원이 차단되면 팀과 스크럼 마스터에게 가시성을 제공하기 위해 장애물 백로그에 항목을 추가합니다.
• 에픽: 에픽은 관련된 여러 사용자 스토리로 구성된 대규모 작업입니다.
• 사용자 스토리: 사용자 스토리는 최종 사용자 관점에서 소프트웨어 기능에 대한 설명입니다. 사용자 스토리는 사용자 유형, 사용자가 원하는 것과 그 이유를 설명합니다. 사용자 스토리는 요구 사항에 대한 간략한 설명을 작성하는 데 도움이 되며 수락 기준을 포함합니다. 사용자 스토리는 제품 소유자가 만들고 유지 관리합니다.
• 작업: 작업은 사용자 스토리와 직간접적으로 관련될 수 있는 스크럼 마스터 또는 팀 구성원이 입력한 작업입니다. 그것들은 일반적으로 본질적으로 기술적이며 수용 기준을 포함할 것입니다.
• 스파이크: 스파이크는 사용자 스토리를 구현하거나 추정하는 방법을 결정하기 전에 조사, 프로토타입 및/또는 설계해야 할 때 사용되는 특별한 유형의 작업입니다.
• 하위 작업: 하위 작업은 사용자 스토리 또는 작업을 완료하기 위한 구현 단계로 입력되는 작업입니다. 그들은 일반적으로 스프린트 계획 회의 중에 팀에 의해 입력됩니다.
• 스토리 포인트 추정: 피보나치 척도(1, 2, 3, 5, 8, 13, 21…)를 기반으로 하는 상대적 크기 추정 척도
• 수락 기준: 제품 소유자가 스토리를 완료된 것으로 수락하기 전에 완료해야 하는 모든 스토리에 포함된 스토리별, 테스트 가능한 항목 목록입니다.
• 완료의 정의(DoD): 스토리가 완료된 것으로 간주되기 전에 완료해야 하는 일반적인 단계 또는 기준의 목록입니다. 팀은 이에 동의하고 모든 이야기에 나열할 필요가 없도록 문서화합니다.

스크럼의 장점과 단점

Scrum의 주요 이점은 Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System 및 Iterations와 같은 린 개념뿐만 아니라 Agile 가치와 원칙의 적용입니다. 이러한 원칙을 적용하면 프로젝트 팀이 지속적인 피드백을 받고 변화하는 요구 사항과 불확실성에 빠르게 적응하고 낭비를 줄이고 가시성과 투명성을 높이고 지속적인 개선을 위해 노력할 수 있습니다. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

칸반

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.