문서를 영문으로 보려면 영문 확인란을 선택하세요. 마우스 포인터를 텍스트 위로 이동시켜 팝업 창에서 영문 텍스트를 표시할 수도 있습니다.
번역
영문

스크럼의 Lean

By David Starr. David Starr는 Scrum.org에 대한 수석 소프트웨어 기술자이며, 여기서 그는 소프트웨어 개발직 개선에 역량을 집중하고 있습니다. 그는 또한 온라인 기술 커뮤니티인 ElegantCode.com을 설립했습니다.

2012년 7월

Lean Thinking을 사용하여 스크럼 팀을 개선하는 데 도움을 제공하는 다양한 방법과 함께 스크럼 프레임워크 고유의 Lean 품질을 검사합니다.

Team Foundation Server

Overview

Seeing Scrum Through the Lean Lens

Toward Leaner Scrum

Conclusion

반응 속도가 빠른 소프트웨어 개발에 대한 현재 논의는 언제나 Scrum, Lean 및 Kanban-소프트웨어 개발 작업을 계획하고 감독하고 실행하는 세 가지 도구-를 포함합니다. 이러한 도구는 스크럼 프레임워크와 Lean Thinking은 함께 잘 작동한다고 주장하는 일부 agile 실제 사용자와 이러한 도구를 소프트웨어를 제공하는 근본적으로 다른 방법으로 생각하는 다른 사람에 의해 종종 비교 및 대조됩니다.

스크럼은 아주 유명하며 Agile 개발 방법을 사용한다고 주장하는 팀 중 92%가 스크럼을 사용합니다[1]. 성공한 스크럼을 갖는 것은 많은 팀들이 기본 스크럼 프레임워크보다 그들의 성숙도에 유의하도록 합니다. 이 문서에서는 Kaizen 또는 지속적인 개선의 마음가짐으로 Lean 및 Kanban 기술을 사용한 스크럼 프레임워크 확장을 탐색합니다.

Ken Schwaber 및 Jeff Sutherland가 1995 년에 도입한 스크럼 프레임워크는 소프트웨어를 반복적으로 그리고 점진적으로 전달할 때 팀이 함께 작업을 하는 방법입니다. 스크럼 팀은 지난 한 달 동안 지속된 스프린트라는 시간 상자에 작업을 구성하여 각 스프린트에서 완벽한 집합과 작동 기능을 구현했습니다.

스크럼 프레임워크는 이해하기 쉬우며 소프트웨어 개발 팀과 고객에게 상당히 보편화되어 있습니다. 스크럼은 작업을 증가시키고 소프트웨어를 출시하기 위해 스프린트 전체에 초점을 맞추는 부서간 및 자기 조직화된 팀을 승격합니다.

스크럼은 스크럼의 역할, 아티팩트 및 이벤트를 문서화하는 스크럼 가이드에서 체계적으로 설명되어 있습니다. 스크럼 가이드는 스크럼의 작성자가 유지 관리하고 Scrum.org에서 온라인으로 사용할 수 있습니다.

Lean Thinking은 낭비를 줄이고 시스템의 전체적인 흐름을 개선하는 데 초점을 맞추어 시스템에 접근하는 방법입니다. Lean은 제조에 대한 다양한 기록을 가지고 있고 최근 몇 년 동안의 소프트웨어 개발에서 인기를 얻었습니다.

소프트웨어 개발에 적용되면 Lean Thinking은 다음 7가지 원칙으로 구현됩니다. 첫 번째 원칙은 Lean 소프트웨어 개발: Agile Toolkit[2]이라는 책에 게시되었습니다.

  1. 낭비 제거

  2. 학습 확대

  3. 가능한 늦게 결정

  4. 최대한 빨리 배달

  5. 팀 역량 강화

  6. 무결성 빌드

  7. 전체를 참조하십시오.

이러한 원칙을 소프트웨어 제품을 전달하는 작업에 적용하는 것이 최종 목표는 아닙니다. 의사 결정 시 도움을 받아 시 전체 시스템을 향상시키는 기술을 선택하려면 사람들은 "Lean을 수행하라"는 말 대신 Lean 원리를 사용하라는 말들 듣습니다. 예를 들어, TDD (테스트 주도 개발)은 개발 단계마다 소프트웨어를 검사함으로써 소프트웨어의 무결성을 확보하고, 이는 개발 프로세스 동안 무결점 소프트웨어 구축하는 린 규칙과 일맥상통합니다.

Lean Thinking의 에 루트 기술 하나는 폐기물 및 적시 배송에 초점을 맞추고 이러한 작업을 수행할 때 발생하는 과중한 부담을 방지하는 형식 메서드에서 Lean Thinking을 사용하는 Kanban[3]입니다. 스크럼과 달리 Kanban는 반복적인 증분 메서드가 아닙니다. Kanban은 반복 시 만들어지는 대신 다섯 가지 핵심 활동으로 작성됩니다.

  1. 워크플로 시각화

  2. 제한 작업 진행 중(WIP)

  3. 흐름 관리

  4. 프로세스 정책을 명시적으로 만들기

  5. 공동으로 개선

칸반을 사용하는 여러 팀은 종종 매우 다른 프로세스를 갖습니다. Kanban 메서드는 프로세스를 관리하여 의도적으로 최적화하는 단순한 기술의 집합입니다. Kanban은 스크럼을 포함한 이미 배치된 프로세스에 손쉽게 적용됩니다.

작업 소프트웨어의 증가가 일관되게 각 스프린트에 제공되면 스크럼 팀은 자신의 방법을 향상시키는 새로운 방법을 모색합니다. 효율적인 스크럽의 핵심은 연속적인 개선의 마음가짐인 Kaizen입니다. 건강한 Scrum 팀은 거의 확실히 Kaizen에 중점을 둔 많은 규칙을 사용합니다. 상대 평가와 같은 도구와 기술, 첫 번째 개발 테스트, 빌드 자동화 및 쌍 프로그래밍은 스크럼 팀의 집에서 모두 가능합니다.

다른 도구, 기술 및 방법이 스크럼을 보완할 때 잘 작동할 뿐만 아니라 scrum.org에서 스크럼 확장 모델이 설명 및 관리됩니다. 이와 같은 스크럼으로 모델 확장을 통해 커뮤니티에게 스크럼을 보완하고 프레임워크와 함께 작동하는 방법을 문서화할 것을 권장합니다. 이 책을 쓸 당시 스크럼 내에서 Lean 실습에 적용할 여러 가지 확장이 구체적으로 제안되었습니다.

Lean Thinking을 스크럼에 추가하는 장점은 명백한 사실입니다. 많은 스크럼 전문가가 스크럼 연습에 Lean Thinking을 적용하여 더 많은 성능 및 품질을 실현했으며 이는 결코 놀랍지 않습니다.

Scrum Framework 는 다음 역할, 아티팩트 및 이벤트로 구성되어 있습니다. 기본 Scrum Framework에 익숙하지 않은 경우 계속하기 전에 Scrum 가이드를 읽으십시오.

역할

아티팩트

이벤트

  • 제품 소유자

  • Scrum 마스터

  • 개발 팀

  • 제품 백로그

  • 스프린트 백로그

  • Increment

  • 스프린트

  • 스프린트 계획

  • 일일 스크럼

  • 스프린트 미리 보기

  • 스프린트 회고

스크럼 가이드는 이러한 구성 요소가 함께 작동하는 방법에 대한 규칙을 만들지만 Lean Thikning은 스크럼 역할, 아티팩트 및 이벤트의 상호 작용을 더 최적화하기 위해 프레임워크를 제공합니다. 스크럼 팀은 각 스프린트를 제공하기 위해 제품 백로그의 하위 집합을 선택하고 적절한 품질과 기능을 가진 증분을 제공하는 데 초점을 맞춥니다. Lean Thinking을 사용하면 스프린트 전체 작업 흐름을 부드럽게 하고 전체 값 스트림 낭비를 줄일 수 있습니다.

스크럼과 린 둘 다 높은 품질을 유지하기 위해 노력하는데 이는 전반적인 수행 작업이 성공하려면 꼭 필요한 일입니다. Lean 소프트웨어 개발 및 스크럼이 동작에서 공유하는 원칙을 보려면 Lean Thinking의 렌즈를 통해 스크럼의 역할, 아티팩트 및 이벤트를 단순히 분석만 하면 됩니다.

다른 모든 이벤트용 컨테이너인 스프린트를 제외하고 스크럼 이벤트는 실제 모임입니다. Lean Thinking은 일반적으로 회의를 낭비로 간주하며 낭비를 꾸준히 제거해야 합니다.

이로 인해 스크럼 이벤트가 불필요하다는 결론이 내려질 수 있습니다. 그러나, 스크럼의 각 이벤트들은 계획 없이(또는 임의적으로) 주최되는 회의를 없애기 위해 신중하게 설계되었습니다. 스크럼 이벤트를 잘 실행하여 모임이 줄어들었고 계획되지 않은 중단에 응답하는 시간이 감소했습니다.

각 스크럼 이벤트는 무엇인가 검사하고 적용하도록 설계되었습니다. 검사는 학습 효과를 높이고 만드는 과정에서 무결성을 구축하는 Lean의 원칙을 지원합니다. 스크럼 이벤트 기간 동안에 계획, 요구 사항 또는 기타 아티팩트를 조정하면 린의 원칙에 따라 의사 결정 지연과 전체 보기를 지원합니다. 다음 표에서는 스크럼 이벤트와 각 이벤트 동안 검사하고 적용할 사항을 보여줍니다.

event

검사됨

조정됨

백로그 정리

제품 백로그

제품 백로그

스프린트 계획

제품 백로그

이전 증가

스프린트 목표

스프린트 백로그

일일 스크럼

스프린트 백로그

스프린트의 목표를 향한 진행

스프린트 백로그

일일 계획

스프린트 미리 보기

최신 증가

최신 스프린트

제품 백로그

제품 백로그

다른 장기 계획

스프린트 회고

최신 증가

최신 스프린트

스크럼 팀 자체

기술 사례

스크럼 팀 동작

기술 사례

스크럼 내에서 사용되는 작업 관리 방법

스크럼 아티팩트는 가능한 간단하게 되어 있으며 더 이상 간단할 수 없습니다. 요구 사항, 계획 및 스크럼 팀에서 제공하는 소프트웨어는 이러한 작업을 수행하는 데 필요한 세부 정보만 포함할 경우 매우 유용합니다.

완벽한 세상에서는 사람들이 간단히 말하는 것 이상의 요구 사항을 만들 필요가 없습니다. 이상적으로는 소프트웨어를 만든 사람이 소프트웨어를 요청하는 사람을 이해하며 요구 사항에 대한 중간 식이 필요하지 않습니다. 밀접한 고객 관계를 가진 매우 작은 팀에서는 가능하지만 단순히 확장되지는 않습니다. 계획을 위해 기능을 제공하기 전에 요구 사항을 만들어야 합니다. Lean은 요구 사항을 Lean Thinking의 일반적인 낭비인 재고로 판단하므로 이를 최소화해야 합니다.

스크럼에서 요구 사항은 양식이나 구조를 거의 규정하지 않는 제품 백로그에서 관리됩니다. 제품 백로그 항목을 매우 세부적이거나 완벽하게 표현해야 한다는 요구 사항은 없습니다.

작업을 계획하기 위해 제품 백로그와 요구 사항을 유지해야 하지만 완벽한 사용은 실제 이들을 작업하는 개발 팀에 조금 앞서 제품 백로그 항목을 만들고 구체화하는 것입니다. 효과적인 스크럼 팀은 결코 수행할 수 없는 제품 백로그에 요구 사항을 만드는 일이 방지됩니다.

완벽한 세계에서는 계획할 필요도 없을 것입니다. 개발 팀은 컨텍스트와 요구 사항의 비용을 무시하고 단순히 큐에서 다음 기능 요청을 받을 수 있습니다. 이 간단한 처리 작업 모델은 매우 유연하지만 소프트웨어 개발이 본질적으로 복잡한 행위라는 것을 고려하지 못합니다. 상당히 복잡한 제품 개발은 해당 계획이 단순하고 세부 정보가 부족하더라도 계획 자체로부터 이익을 얻습니다.

스크럼 가이드에서는 스프린트 백로그를 스프린트용으로 선택한 제품 백로그 항목의 하위 집합 및 이들을 제공하는 계획으로 정의합니다. 스프린트 백로그에는 최소한 매일 조정된 스프린트의 예상된 작업의 재고품(폐기물)이 표시됩니다. 이러한 매일의 구체화를 통해 계획은 결코 약속이 아니며 개발 팀이 구현 결정을 최근의 책임 시점까지 연기할 수 있습니다.

스크럼 팀은 요구 사항을 만들고 비용을 최소화하기 위해 거의 충분하지 않도록 계획을 세웁니다. 재고 최소화에 대한 이러한 Lean 방법을 사용하면 의사 결정을 지연시키고 스프린트 내에서 재고를 최소화하기 위해 팀에게 권한이 부여되고 팀은 자기 조직할 수 있습니다. 요구 사항 또는 계획에 집중하기 보다 스크럼 팀은 각 증가에서 전달되는 값에 집중합니다.

각 스프린트는 작동하는 소프트웨어 중 하나 이상의 증가 배달을 포함합니다. 제품 증가는 Lean Thinking에서 낭비로 간주되지 않는 유일한 스크럼 아티팩트입니다. 그렇다 하더라도 제품 증가에 낭비가 있을 수 있습니다. 폐기물은 사용되지 않는 기능, 결함, 불완전한 기능, 유지하드 코드 또는 불완전하게 팩터링된 디자인의 형태로 제공될 수 있습니다.

고성능 Scrum 팀은 제품 자체의 낭비를 거의 제거합니다. 대개 이는 스프린트 동안 증가를 자주 검사하고 항상 높은 품질을 유지하여 수행합니다. 이렇게 하면 무결성을 구축하는 가장 기본적인 Lean 원칙이 실현됩니다.

또한 스크럼 팀에서는 증가를 전달할 때 Lean 원칙을 염두에 둠으로써 혜택을 얻습니다. Scrum Framework는 스프린트 검토 시 검사를 위해 증가가 열려 있도록 합니다. 스프린트 검토 시 증가에 대한 피드백을 받는 것은 학습 효과를 높이기 위한 기본 사항입니다.

스크럼에서 규정된 역할은 스크럼 팀에 권한을 부여하고 긴장의 균형을 맞추기 위해 신중하게 균형을 맞추어야 합니다. 스크럼 마스터, 개발 팀 및 제품 소유자가 협력하여 성공하기 위해서는 모든 사람이 다른 사람의 관점을 볼 수 있어야 합니다. 이러한 공동 작업을 통해 팀 구성원이 스크럼 시스템을 전부로 간주하게 할 수 있고 다른 역할보다 한 가지 역할을 선호하여 스크럼을 차선의 상태로 만드는 모든 결정을 투명하게 할 수 있습니다.

스크럼 공동 생성자인 Jeff Sutherland는 성공적인 Lean 구현의 기본은 상향식 인텔리전스와 조정 관리자과 함께 작업하는 권한을 부여 받은 작업자라는 사실을 인지하고 있습니다. 스크럼의 자기 조직화 개발 팀은 지시하는 대신 조직에서 학습을 독려할 수 있는 Lean Thinking에서 권한을 부여 받은 직원을 구체화합니다.

스크럼의 고유한 특징은 스크럼 마스터의 역할이며, 스크럼 가이드에서는 다음과 같이 설명합니다.

스크럼 마스터는 스크럼을 이해하고 적용하는 일을 담당합니다. 스크럼 마스터는 스크럼 팀이 스크럼 이론, 방법 및 규칙을 준수하도록 함으로써 이를 수행합니다. 스크럼 마스터는 스크럼 팀의 섬기는 리더입니다.스크럼 가이드 - 2011년 10월

좋은 스크럼 마스터의 주요 기술과 활동 중 하나는 용이함입니다. 대부분의 경우 스크럼 마스터는 스크럼 이벤트를 이용합니다. 스크럼 마스터는 관리자이며 비록 스크럼을 채택하고 준수하기는 하지만 사람들은 아닙니다.

스크럼에서 노출된 문제를 고려 및 해결하기 위해 Lean Thinking을 사용하면 높은 반환 값이 나오며 이는 Kaizen 문화권을 유지하는 좋은 방법입니다. 스크럼 팀은 여전히 Lean을 스크럼에 적용하는 방법을 학습하고 있지만 많은 방법이 스크럼 팀을 더욱 효율적으로 만드는 것으로 증명되었기 때문에 인기를 얻고 있습니다.

Lean 원칙을 직접 지원하는 지식 작업에서 사용되는 많은 일반적인 방법과 기술이 있습니다. 이러한 여러 가지 방법은 스크럼 팀에 실현할 수 있는 방법을 알고 탐색합니다.

다음은 확실히 기술에 대한 단독 목록이 아니라 Lean 실행자에 일반적인 기술을 사용하여 일부 스크럼 팀이 기술을 향상시키는 방법의 단순한 예제입니다. 또한 여러 가지 방식으로 각 기법을 적용할 수 있습니다. 몇 가지 Lean 기술을 여기에서 설명합니다. 스크럼 팀은 이 문서에서 설명하는 것과 다르게 다음 시나리오에 접근할 수 있습니다.

가장 기본적인 Lean 연습은 낭비를 제거하는 것일 것입니다. Lean은 원하는 결과를 생성하는 데 반드시 필요하지 않은 것의 낭비를 고려합니다. 소프트웨어의 일반적인 낭비는 다음과 같습니다.

  1. 사용하지 않는 코드 또는 기능

  2. 재작업을 초래하는 결함

  3. 무엇인가를 기다리느라고 소비한 지연 또는 시간

  4. 한 사람, 팀 또는 비즈니스 프로세스를 다른 사람에게 인계

  5. 매우 자세한 요구 사항

  6. 충분하지 않은 요구 사항

  7. 저속 또는 품질이 좋지 않은 통신

일부 낭비는 피할 수 없으며 필요하기도 합니다. 예를 들어, 가장 엄격한 정의에서 요구 사항 문서는 낭비입니다. 요구 사항을 나타내는 색인 카드는 결국 클라이언트에 전달되지 않습니다. 따라서 인덱스 카드는 낭비입니다. 요구 사항 카드 자체는 제품 기능이 아니라 기능을 만드는 데 사용할 작업을 나타냅니다. 요구 사항 카드는 개발자가 생각하고 작업을 추적하도록 지원합니다. 대부분의 팀은 이것을 필요한 방법으로 알고 있지만 쉽게 낭비로 식별됩니다.

일부 낭비는 필요하지만 대부분 줄이거나, 최적화하거나, 제거할 수 있습니다. 너무 오랫동안 기다려 코드를 체크인할 수 없는 등 소프트웨어 개발 가치 스트림에서 몇몇 낭비를 쉽게 인식하여 제거합니다. 개발을 시작하기 전에 많은 요구 사항 문서 작성 같은 소프트웨어 개발 팀에서 발견된 다른 낭비는 문화로 자리를 잡았으며 이를 근본적으로 변화하기 위해서는 상당한 노력과 시간이 필요합니다.

스크럼은 6개월 동안 배치되었습니다. 개발 팀은 2주일에 각 스프린트에서 한 번 작동하는 증분을 생성하고 있으며 측정된 모든 품질 지표는 긍정적인 추세를 반영합니다.

스크럼 마스터는 생산성과 품질을 높이기 위한 팀 지도에 대해 논의하기 위해 만납니다. 스크럼 마스터는 Lean Thinking에 규정된 대로 낭비를 제거할 것을 제안합니다. 아이디어를 시도하는 것에 동의하여 스크럼 마스터는 폐기된 사례를 살펴보고 즉시 제거할 것과 관리할 시간이 필요한 것 두 가지로 목록을 분류합니다.

첫 번째 목록은 스크럼 마스터 자체나 개발 팀에서 제거해야 할 낭비가 포함하고 있으며 권한이나 대기는 필요하지 않습니다. 다른 것은 "낭비 백로그"라고 명명되었으며 모두가 동의하는 낭비를 식별하지만 변경하는 데 많은 시간 또는 노력이 소요됩니다. 두 목록의 예는 다음과 같습니다.

즉시 처리

낭비 백로그

  • 이를 위해 유지해야 하는 빌드 컴퓨터에서 수동으로 일부 빌드를 수행 중입니다.

  • 웹 사이트 패키징은 수동 ZIP 프로세스입니다. 이것을 자동화합니다.

  • 개발자는 모두 공유 개발 데이터베이스를 사용하고 있으며 데이터 변경은 개발 흐름을 자주 중단시킵니다. 각 개발자가 전용 개발 데이터베이스를 갖고 있는 모델로 이동합니다.

  • 테스트는 기능이 있을 때까지 작성되지 않습니다. 테스트 전문가에게 테스트 우선 방식을 장려하고 교육합니다.

  • 모든 기능을 코딩하기 전에 만든 UML 모델입니다.

  • 같은 개발 팀 멤버들이 소규모, 임시 토론을 위해 사무실 사이를 오고 가도록 하는 사무실 레이아웃에 의해 차단된 통신.

  • 가능하면 배포가 수동 작업이 되지 않도록 설치 관리자를 도입합니다.

  • 버그 추적 보고서 시스템의 많은 필드가 필요하며 거의 사용되지 않습니다. 이러한 필드에 대한 데이터를 만드는 데 걸린 시간은 옵션으로 만들어 저장할 수 있습니다.

이 목록을 바탕으로 스크럼 마스터가 즉각적인 개선을 위한 실질적인 제안을 가지고 해당 스크럼 팀에 접근합니다. 스크럼 마스터는 더 높은 수준의 품질을 위해 팀을 코치하지만 자기 조직적 특성을 지닌 스크럼 팀에는 변경 내용을 평가하고 이를 재정의하기 위한 계획을 만드는 팀이 필요합니다.

스프린트 회고는 개선에 대한 아이디어를 공유하고 이러한 아이디어를 실행하기 위해 지원을 얻는 전용 포럼입니다. 효과적인 스프린트 회고는 종종 개선을 확립하고 Kaizen 문화를 지원하는 계획을 만들어냅니다. 백로그에서 추적한 낭비를 제거하거나 개선하면 스크럼 팀 외부에서 작업해야 할 수 있습니다. 이는 업무가 조직에서 스크럼 사용을 향상시키고 민첩성을 장려하는 것이 포함된 스크럼 마스터의 책임입니다.

5명으로 구성된 개발 팀이 다양한 결과를 가지고 3개의 4주 스프린트를 완성하며 12주 동안 스크럼을 사용해 오고 있습니다. 생성 중인 증분이 스크럼을 구현하기 전에 만든 소프트웨어 보다 높은 품질을 가지지만 더 작은 작업이 완료되는 것처럼 보이고 개발 팀 구성원도 공동으로 작동하지 않습니다. 일일 스크럼은 상황이 개선되지 않는 것처럼 보여도 팀의 각 사람이 격리되어 자신의 작업을 수행함을 알리는 알림을 제공합니다.

스프린트 계획 과정에서 개발 팀은 스프린트에 대해 선택한 각 제품 백로그 항목을 배달하는데 요구되는 작업의 '할 일' 목록을 만듭니다. 이 방법으로 스프린트 계획 동안 스프린트 백로그와 스프린트에서 개발 팀의 진행 상황을 추적하는 메커니즘을 만듭니다.

개발 팀은 스프린트에서 진행율을 추적하기 위해 개발 팀 작업 영역에 있는 벽에 표시된 작업 보드를 사용합니다. 마지막 스프린트 과정에서 스크럼 마스터는 일일 스크럼 전 매일 보드의 사진을 찍었습니다. 일부 사진은 아래 표시됩니다.

작업 보드, 1일

1일

작업 보드, 4일

4일

작업 보드, 9일

9일

작업 보드, 14일

14일

작업 보드, 17일

17일

작업 보드, 20일

20일

스크럼 마스터는 이러한 사진을 개발 팀과 공유했습니다. 일부는 다음과 같이 확실해졌습니다.

  • 개발 팀에 구성원이 있는 것보다 더 많은 작업이 정기적으로 진행 중입니다.

  • 두 번째 날에 개발자는 기능 C의 모든 작업을 "진행 중" 상태로 가져와 스프린트가 지속되는 동안 그 상태를 유지합니다.

  • 기능 B는 스프린트가 끝날 때까지 작업하지 않았고 완료되지 않았습니다.

  • 기능 C는 스프린트를 통해 작업했지만 완료되지 않았습니다. 기능 C에서 작업하는 개발자는 익숙하지 않은 문제가 발생했을 때 도움말 부족으로 실망했습니다. 약간의 도움에도 감사할 데일리 스크럼에서의 교묘한 암시에도 불구하고, 다른 팀 멤버는 그들의 작업에만 집중했으며 기능 C에 대해 책임을 느끼지 않았기 때문에 결코 구체화되지 않았습니다.

  • 기능은 스프린트 계획 중에 우선 순위에 따라 스프린트 백로그에 배치되었습니다. 그러나, 전달된 다른 기능보다 더 높은 우선 순위를 가지도록 주문된 기능 B가 스프린트에서 완료되지 않아 제품 소유자가 매우 실망하였습니다.

  • 여러 기능이 한꺼번에 진행 중이면 코드의 전혀 다른 부분이 동시에 모두 변경됩니다. 스프린트 과정에서 개발자가 자신도 모르는 사이 서로 다른 코드에 영향을 주었기 때문에 여러 빌드 실패 및 재작업을 초래하였습니다.

이러한 모든 관찰 내용은 한 번에 여러 가지 작업을 수행하는 개발 팀의 작업 방식을 가리키게 됩니다. 작업 간 주의를 전환하고 많은 항목에 동시에 초점을 맞추면 개발 팀 구성원은 오버로드된 느낌을 받고 스프린트 백로그의 작업에 압도당합니다. 따라서 각 팀 구성원은 자신의 작업에 초점을 맞추고 팀의 구성원이 아닌 개인으로서 행동합니다.

스프린트 회고 과정에서 스크럼 마스터는 기술을 시도하기로 결정한 개발 팀에게 WIP 제한의 개념을 설명했습니다. 개발 팀은 다음 스프린트에서 WIP를 줄이도록 설계된 세 개의 새로운 규칙을 구현하기로 결정했습니다.

  1. 스프린트 백로그의 기능은 위에서 아래로 순서대로 구현됩니다.

  2. 3개 이상의 항목을 한 번에 진행할 수 없습니다. 네 번째 항목이 진행 중이면 팀은 시스템에서 왜 병목 현상이 발생했는지 결정하기 위하여 일시 중지합니다.

스크럼 마스터는 다음 스프린트 동안 다시 사진을 촬영했습니다. 여러 사진이 아래에 표시됩니다.

작업 보드, 2일

2일

작업 보드, 8일

8일

작업 보드, 12일

12일

작업 보드, 20일

20일

스프린트 회고 과정에서 이 최신 스프린트 동안 어떤 변화가 생겼는지에 대한 다음의 관찰을 진행한 개발 팀이 사진을 다시 공유합니다.

  1. 개발 팀 멤버들은 보다 복잡한 항목에서 함께 작업했습니다. 의견은 작업을 수행하는 방법에 따라 가끔 달랐지만 문제가 해결되었고 팀의 진행률이 전체적으로 빨라졌습니다.

  2. 개발 팀 멤버들은 이전에 집중하지 못했던 제품 기능에 대해 학습하기 시작했습니다. 각각 전체적으로 제품에 대한 집합적 소유권의 느낌을 보고했습니다. 이것은 자신들이 이해하는 기능에 대해서만 집중하는 개인의 이전 방법을 완벽하게 보완하는 방법이 되었습니다.

  3. 한 번에 코드의 여러 영역에서 변경을 조정하는 복잡성은 획기적으로 감소되었습니다. 사실 개발 부서의 생산성이 크게 증가되었습니다.

  4. 기능 E가 스프린트 내에서 완료되지 않았지만 전달된 모든 기능에서 기능 E 보다 우선 순위가 높았습니다. 제품 소유자는 만족했으며 이러한 낮은 우선 순위 기능 없이도 클라이언트에 증분을 제공하기로 결정했습니다.

스프린트 계획 중의 스프린트 백로그 작성이 스프린트에 선택한 작업의 일괄 처리 크기를 제한하지만 향후에 스프린트 내에서 WIP 제한하면 처리량이 빨라지고 생산성을 높일 수 있습니다. 스프린트 동안 WIP를 제한하면 공동 작업 증가하고 기술 전문가가 다른 사용자가 인식하지 못하는 작업을 수행할 위험이 감소합니다.

소프트웨어 개발에서 어떤 일이 발생하기를 기다리면서 많은 시간이 소비되었습니다. 이런 형태의 낭비는 대부분의 개발 팀에서 쉽게 찾을 수 있습니다. 새 스크럼 팀은 스프린트 동안에 다양한 일을 대기합니다.

  • 작업을 수행할 권한

  • 완료까지 긴 프로세스

  • 다른 팀 또는 개인으로부터 핸드오프

  • 실행할 테스트 또는 완료할 유효성 검사

  • 필요한 리소스에 액세스

  • 팀 외부인의 협력

대기 중인 스크럼 팀보다 더 안 좋은 비효율성은 고객과 비즈니스가 소프트웨어를 통합하고 포장하여 배송하는 데 기다리는 시간입니다. 이 문제는 개발 조직의 크기에 따라 증가합니다. 더 많은 개발자나 팀이 프로젝트에 합류하면서 단일 제품에 그들의 작업을 통합하는 비용이 증가합니다.

스크럼에 구축된 최장 대기 시간이 스프린트입니다. 모든 스크럼 이벤트에 대한 컨테이너로서 스프린트 기간은 한 달 또는 그 이하여야 한다는 것이 유일한 요구 사항입니다. 이는 소프트웨어의 작동 중인 증분을 기다리는 데 소비된 시간을 한 달로 제한합니다. 대부분의 스크럼 팀은 더 자주 작동하는 증가를 제공합니다.

한 회사에 크고 복잡한 소프트웨어 제품에서 작업하는 6개의 Scrum 팀이 있습니다. 각 스크럼 팀은 특정 기능 영역에 집중하며 작업은 마스터 제품 백로그를 통해 협조됩니다. 스프린트는 3주 길이이며 모든 개발 팀의 작업을 통합합니다.

이전에는 스프린트는 2주일 길이였지만 제품 규모가 커짐에 따라 제품 만들기의 복잡도도 커졌습니다. 통합 작업을 수용하기 위해 스프린트 길이를 증가하기 위해 작업을 통합하는 데 더 많은 시간 필요한 새 스크럼 팀이 추가되었습니다.

3주차는 이제 흔히 통합 주라고 합니다. 새로운 기능을 주 코드 줄에 통합하는 것이 이 기간 동안의 주요 활동입니다. 통합 팀은 각 개발 팀의 담당자와 함께 각 통합 주를 설정합니다. 이들이 통합 작업을 지시합니다.

통합 팀은 통합 문제를 해결하기 위해 작은 변경을 요청하지만 통합 주 동안 새 기능을 허용하지 않습니다. 이를 통해 통합 팀의 요구에 반응하여 통합 주 동안 애드혹 코드가 너무 빨리 변경됩니다.

다음 그림은 스프린트 동안 일반적인 구성 관리를 보여줍니다. 개발 팀은 스프린트를 시작할 때마다 자신의 개발 분기를 만듭니다. 이들은 2주가 끝날 때 코드를 병합합니다. 3주차 동안 개발 팀은 필요하면 통합 팀의 요청을 서비스합니다.

3주 및 6개 팀을 보여 주는 스프린트 차트

스프린트 동안 통합은 필요하지만 이 통합을 달성하기 위해 6개 스크럼 팀 용량의 3분의 1이 현재 사용 중입니다. 이 시간 동안 팀의 역량은 대부분 스프린트 외적인 활동에 쓰입니다. 위의 예제에서 팀 5는 통합 주 동안 거의 작업을 하지 않았습니다.

통합 주의 비용 증가하면 종종 컨텍스트를 전환해야 하는 스크럼 팀의 흐름이 중단됩니다. 일부 팀은 주중 작업 동안 생산성을 높이기 위해 개별적으로 코드 줄을 분기하여 전반적인 복잡성이 증가하고 좋은 결정을 내리는 데 필요한 투명도를 되돌리고 있습니다.

팀의 스크럼 마스터들은 옵션을 논의하기 위해 만납니다. 마스터가 해당 팀과 연결하는 하나의 스크럼는 각 스프린트의 첫 번째 2주 동안 성공적으로 WIP를 제한했습니다. 스크럼 마스터는 모든 팀이 WIP를 한 번에 하나의 기능으로 제한할 경우 각 기능이 완료될 때 잠재적으로 작업을 통합할 수 있는지 관찰합니다.

이 예가 모든 개발팀에서 사용되었다면 어떤 팀도 그들의 작업을 통합하기 위해 2주까지 대기할 필요가 없습니다. 새 기능을 통합을 기다리는 대신 각 팀은 작동하는 각 기능에 대해 Done1의 정의의 주 코드 줄 부분에 대한 통합을 고려할 수도 있습니다.

완료에 대한 정의는 개발 팀이 해당 제품 백로그 항목을 "완료됨"으로 간주하기 위해 스프린트에 대해 선택한 각 제품 백로그 항목에 적용되어야 할 사항에 동의하는 스크럼의 개념입니다. 완료의 정의에 대한 자세한 내용은 MSDN 기사, 실행 및 실행 취소을 참조하십시오.

다음 스프린트 회고 과정에서 개발 팀은 각 기능이 완료될 때 그들의 작업을 통합하도록 노력하는 것에 대해 동의합니다. 이들은 다음과 같은 새 규칙을 설정하고 적용합니다.

  1. 각 개발 팀은 WIP를 한 번에 한 기능으로 제한합니다.

  2. 기능은 메인 코드 줄에 통합될 때까지 완료되지 않습니다.

  3. 새 기능을 사용하기 전에 개발 팀에서 새로 복사한 줄로 해당 코드 줄을 업데이트합니다.

결과 활동은 다음 그림으로 표현됩니다.

보다 부드러운 흐름을 보여 주는 스프린트 차트

새로운 규칙은 기능을 전달할 때 원활한 흐름을 팀에서 경험하도록 했습니다. 통합 주가 없기 때문에 개발팀은 스프린트의 3주 동안 더 이상 가만히 앉아있거나 일이 중단되는 경우가 없습니다.

스프린트 동안 변경 내용을 통합하는 데 걸리는 시간은 처음 통합보다 더 많지만 연속 통합 모델에 익숙해지면 각 개발 팀의 생산성은 증가합니다. 시간이 지나면 스프린트가 증가함에 따라 기능이 추가됩니다.

기능과 관련하여 수행 중이라면 기능을 메인 코드 라인에 통합한다는 의미이기 때문에 기능이 잘 수행되고 있는지는 더 이상 문제되지 않습니다. 완료의 정의는 이제 각 개별 기능의 주 코드에 대한 통합을 포함합니다. 통합에 실패할 위험이 획기적으로 줄어듭니다.

마지막으로 코드를 통합하는 개발팀의 대기 시간을 줄이기 위한 결정은 개발팀의 전제 생산성을 향상시키며 통합주가 필요하지 않도록 합니다. 따라서 스크럼 팀은 더 짧은 스프린트로 돌아가 제품 소유자는 더 많은 것을 더 자주 제공할 수 있습니다(해당될 경우).

지연 커밋은 Lean 소프트웨어 개발의 가치로 표현되는 원래 Lean 원칙 중 하나입니다. 이 원칙은 종종 결정을 내리기 위해 "마지막 순간까지 책임을 다하려고 대기"하는 것으로 설명됩니다.

Thinking과 마찬가지로 일련의 조치에 중간에 하나의 조치를 커밋하는 의사 결정 시 발생하는 값은 없습니다. 문제에 대한 가장 가능성 있는 정보를 알 수 있도록 결정을 내려야 할 때까지 기다리지 않은 이유는 무엇입니까? 이는 잘못된 의사 결정의 위험을 제한하고 더 많은 선택이나 표면에 발생하는 동작의 경로를 위한 시간을 허용합니다.

스프린트를 계획 과정에서 개발 팀은 스프린트에 대해 선택한 PBI를 구현할 방법에 대한 세부 계획을 세웁니다. 종종 추가 정보를 학습하면서 스프린트 동안 계획이 변경됩니다. 이들은 작업이 덜 명확할 때 계획이 더 많이 변경된다고 말합니다. 사용하지 않는 요구 사항이 낭비라는 것을 알면 팀은 이 계획을 재작업하는 것을 피할 것입니다.

한 작업 과정을 커밋하려면 기타 옵션은 포기해야 합니다. 이 문제는 아이디어를 취소하는 커밋을 인식하도록 합니다. 특정된 기능을 구현하는 여러 가지 방법이 있지만 일련의 조치를 이미 선택한 경우 개발자는 혁신 거절에 대한 문제와 가능성을 접근하는 다른 방식을 고려하는 것을 중지할 수 있습니다.

개발 팀은 스프린트 백로그에서 더 크고 작은 항목을 허용하기로 결정합니다. 실제로 그들이 제품 백로그 항목이 세부 계획 없이 스프린트에 허용될지 결정합니다.

개발 팀은 이제 나중에 더 많이 알게 되었을 때 세부적인 계획을 만들기 위해 기다립니다. 이를 위하여 작업을 실제로 시작할 때 큰 스프린트 백로그 항목을 더 작은 조각으로 분리합니다. 이를 통해 실제로 필요할 때가지 세부적인 계획은 연기되며 팀은 구현에 대한 마음을 작업 시점에 더 가깝게 변경할 수 있습니다. 또한 더 이상 유효하지 않은 계획을 실행하지 않고 가장 좋은 가능한 계획을 사용할 수 있습니다.

따라서 기능을 구현할 시간이 되면 구현 옵션을 더 잘 이해하게 됩니다. 개발 팀은 스프린트에서 이전 기능을 구현할 동안 제품에 대한 자세한 내용을 알게 되었고 필요하면 조사 시간을 허용했습니다.

Kanban 메서드의 첫 번째 단계는 팀에서 사용하는 실제 워크플로를 시각화해야 합니다. 이를 통해 Lean은 "전체 원리"를 보며 비즈니스 프로세스 문서 또는 일부 다른 기존 모델에서 규정한 이상적인 버전이 아니라 실제 워크플로우를 표시해야 합니다. 유용한 시각화는 실제로 발생하는 것을 나타냅니다.

작업 시각화가 있으면 그 내부의 작업을 추적할 수 있습니다. 일반 스테이지 게이트 또는 폭포의 개발 프로세스 샘플 모델은 아래와 같으며 몇 가지 기능이 진행 중입니다.

6개의 게이트에 5가지 기능이 있는 Waterfall 차트

스크럼 팀은 수 년 동안 워크플로 시각화를 사용하여 스프린트의 작업을 확인해 왔습니다. 스크럼 개발 팀의 워크플로우 시각화의 가장 일반적인 형태는 "작업 보드" 또는 간단히 "스크럼 보드"입니다. 이러한 시각화는 일반적으로 위의 모델보다 더 간단하며 다음 모델과 유사하게 보입니다.

Scrum 보드

이 일반적인 워크플로 가상화 형태는 교차 기능적 개발 팀의 스크럼 개발 팀의 영향을 크게 받았습니다. 교차 기능 개발 팀은 Scrum 프레임워크의 특성을 정의하는 데 집중하고 있습니다. 부서간 업무 팀은 각 스프린트에 작업 소프트웨어를 전달하는 데 필요한 모든 능력을 가지고 있습니다. 팀 멤버는 동시에 소프트웨어 개발의 많은 활동을 수행합니다.

교차 기능 팀은 함께 하나의 기능을 구현할 때 처럼 한 번에 모든 것을 조금씩 수행할 수 있습니다. 이는 전문가가 한 번에 모든 활동 수행에 포커스를 맞추는 계획 기반 모델과는 매우 다릅니다. 또한, 부서간 팀 구성원들은 전문 분야를 가질 수 있습니다. 그러나, 모든 팀 구성원들은 개인 전문 분야에 활동이 속해 있든 속해 있지 않든 간에 정기적으로 소프트웨어 개발한 필요한 모든 활동을 다함께 수행하여야 합니다. 교차 기능 소프트웨어 개발 팀은 전담 전문가를 능가하는 경향이 있습니다.

개발 팀이 작동하는 소프트웨어의 증가를 제공하고 있지만 팀 구성원들의 공동 작업이 잘 이루어지지 않고 있습니다. 코더는 스프린트의 종료 전 유효성 검사를 서둘러 마쳐야 하는 테스터에게 코드를 전달하기 전에 격리된 상태로 문제를 해결합니다.

이 경우 개발 팀이 때때로 이를 생략하고 불완전한 회귀 테스트를 증분에 제공하도록 스프린트의 끝에서 테스트가 발생하는 데 필요한 시간을 거의 남기지 않습니다. 기능 재발 테스트가 사전에 허용된 생산에서 결함이 발견됩니다.

스크럼 마스터는 각 스 프린트 내에서 발생하는 실제 워크플로우를 모델링하기 위해 개발 팀과 함께 작업을 합니다. 팀이 일일 스크럼에서 일반적인 스크럼을 사용한다 할지라도 실제 워크플로우는 스테이지 게이트 프로세스임이 곧 명확해집니다. 팀은 실제 워크플로를 반영하기 위해 다음 모델을 생성합니다.

5단계의 초기 워크플로

스크럼 마스터는 팀 간 작동 방식으로 작업을 통해 얻는 잠재적인 생산성 증가를 이해하는 데 도움이 됩니다. 모호하기는 하지만 팀 구성원들은 보다 교차 기능적이 되도록 워크플로를 개선하는 데 동의합니다.

개발 팀은 시각화를 있는 그대로 두고 스프린트에서 모니터링 작업을 하는데 사용하지만 단계를 축소하는 모든 기회를 찾는 데 동의합니다. 즉, 팀은 두 개의 단계가 하나의 단계로 결합될 수 있는 기회를 찾기 때문에 핸드오프가 는 공동 작업으로 교체됩니다. 이는 개발 팀 내에서 개인들이 상호 작용을 하는 방법을 신중하게 변경함으로써 시간의 거의 소요되지 않습니다. 각 스프린트 회고에서 팀이 만든 개선을 반영하기 위해 모델을 수정합니다.

먼저 Arnie와 Kyle은 디자인과 코딩 단계의 병합을 위해 공동 작업하기로 동의합니다. 이들은 여러 가지 방법을 시도하여 공동 작업을 개선하려 했고 곧 워크플로가 다음과 같이 변경되었음을 알게 됩니다.

4단계의 수정된 워크플로

이 개발 팀은 코드를 구현하여 다음과 같이 변경되기 전에 기능 회귀 테스트에 실패했다는 사실을 곧 알게 됩니다.

2단계의 최종 워크플로

다음 몇 개월에 걸쳐 개발 팀은 배송 파이프라인에서 단계의 수를 줄일 수 있는 기회를 찾습니다. 전문가가 그들의 지식을 공유하고 팀을 통해 워크플로우를 더 원활하게 하기 위해 모든 사람이 최선을 다할 때 실제적으로 변합니다. 팀 멤버는 더 많은 공동 작업이 발생할 때 스스로 "전문화된 일반론자"라고 생각하기 시작합니다.

팀의 공동 작업이 증가할수록 따라 개발 중인 소프트웨어에 대한 집단 지식과 서로의 역할에 대한 통찰력이 높아집니다. 이러한 공동 작업을 통해 자연스럽게 스프린트 동안 작업 단계가 축소되어 스프린트 내에서 발생하는 워크플로우의 더 간단한 시각화에 반영됩니다. 개발 팀은 이제 교차 기능적이며 아래 표시된 내용에 따라 실제 워크플로를 봅니다.

수행할 작업, 수행 중인 작업, 수행한 작업

팀이 워크플로우 스크럼에서 발생한 제거 프로세스 단계에 대한 반복적 리플렉션은 맨 처음에 진행 중인 단일 개발 단계를 규정합니다. 이는 완벽하게 최적화된 Kanban 보드가 어떻게 자신을 전통적인 스크럼 보드로 보여주는지를 표시합니다.

많은 소프트웨어 기술은 생성 프로세스에 무결성을 빌드하는 데 초점을 맞춥니다. 소프트웨어 디자인 패턴, 첫 번째 개발 기법 테스트, 리팩터링 및 쌍 프로그래밍 모두는 만들어질 때 소프트웨어의 품질을 높이려 합니다. 만들기 프로세스 초기에 품질을 증가시키는 방법을 사용하면 팀은 "나중에 품질을 테스트"하기 위해 팩트 후 품질 검사에 의존하지 않아도 됩니다.

개발 팀은 테스트 우선 개발 기술을 경험했으며 개발하는 동안 개발자가 만든 단위 테스트에서 승인 기준의 Given/When/Then 형식을 성공적으로 사용하고 있습니다.

Given/When/Then 승인 기준 형식

지정된 <일부 초기 컨텍스트>

<어떤 작업이 발생>할 경우

그 다음 <결과>

팀은 개발자가 디자인을 안내하고 자동화된 테스트 도구로 자주 코드를 테스트하기 위해 의존하는 훌륭한 단위 테스트 프로그램을 자주 테스트 하는 테스트 도구를 가집니다.

이 방법은 단위 테스트 수준에서 작동하지만 개발 팀의 테스트 전문가는 기능 테스트에 대한 수용 기준을 만드는 데 여전히 Microsoft Word 문서를 사용합니다. 기능을 코딩하고 완료한 후 수동으로 유효성을 검사합니다. 코드 작성자가 기능이 완료됐다고 생각할 때까지 이러한 테스트가 실행되지 않기 때문에 상당수의 결함은 테스트 전문가에 의해 발견됩니다. 이는 스프린트 내에서 재작업을 발생시키고 때로는 스프린트 검토 전에 기능이 완료되지 않습니다.

스프린트 회고에서 승인 기준 워크플로를 논의하는 동안 개발 팀은 다음을 시도하기로 결정합니다.

  1. 테스트 전문가는 승인 기준을 Microsoft Word 문서가 아니라 내부 구현이 없는 자동화된 테스트 실패로 만듭니다.

  2. 새 자동화된 테스트는 오전 5시와 오후 3시에 매일 실행되어 테스트 통과 및 실패에 대한 보고서를 생성합니다. 새로 만든 테스트는 항상 실패합니다.

  3. 코더에서 작동하는 새 기능을 선택하면 코더는 스텁된 수용 테스트의 기능을 구현하여 시작합니다.

  4. 테스트는 코더로 조정하지만 코더를 만든 테스트 전문가와 공동 작업으로 원래 테스트 목적을 유지합니다.

  5. 테스트에 통과할 때까지 기능은 완료되지 않습니다.

  6. 모든 테스트는 스프린트가 끝날 때 통과해야 합니다.

이 기술을 사용하는 몇 개의 스프린트 후에 결함과 재작업이 줄어들었습니다. 개발 팀은 하루에 두 번 자동화된 테스트 실행으로 업데이트된 보고서를 업데이트하여 테스트 통과 및 실패가 하나의 추세로 표시될 수 있음을 알았습니다. 팀은 테스트를 실행할 때마다 자동으로 업데이트되는 보고서를 만듭니다. 보고서는 2주 스프린트 과정 동안 수집한 수락 테스트 통과와 실패 결과를 보여줍니다. 그래프는 다음과 같습니다.

자동화된 승인 테스트 차트

개발 팀은 일반적인 번다운(burndown) 차트 보다는 일일 스크럼에서 이 보고서를 검토할 때 더 많은 가치를 찾습니다. 스크럼 마스터는 이 새 그래프가 스프린트 백로그의 중요한 역할을 할 수 있는지 확인합니다.

스크럼 가이드에서는 스프린트 백로그를 스프린트용으로 선택한 제품 백로그 항목의 집합과 및 이들을 제공하는 계획으로 지정합니다. 이 개발팀의 이 계획은 수락 시험이 실패하여 수립되었고, 완료까지의 진행 상황은 시험 성공/실패 수에 따라 추적되었습니다. 스프린트 백로그에서 작업을 사용하는 경우와 마찬가지로 테스트가 추가, 삭제되거나 스프린트 전체에 걸쳐 수정될 수 있습니다. 대개 지정된 테스트를 만들면 몇 일 내에 해당 기능을 구현할 수 있습니다.

실제 자동화된 테스트를 요구 사항과 기능 회귀의 메커니즘으로 사용한다는 것은 테스트가 요구 사항임을 의미합니다. 이를 통해 또한 자동화된 테스트를 통과시키는 진행으로 스프린트 작업을 볼 수 있습니다. 이와 같은 첫 번째 테스트 개발 기술에서는 팀이 팀 스크럼을 사용하는 것에 대해 생각하는 방식을 다시 정의했고 요구 사항 검사를 프로세스 자체 생성 삽입하여 제품에 무결성을 구축했습니다.

상당히 인기 있는 Scrum Framework의 많은 측면이 Lean 원칙을 지원합니다. 스크럼 팀이 성숙하고 발전하여 Lean 사고가 반복적이고 점진적인 개발을 높이는 데 효과적인 도구라는 것을 깨닫게 되는 경우가 종종 있습니다.

특정 기술이 나타나고 사라지는 동안 정상적인 소프트웨어 개발 팀을 유지하기 위해 개선에 계속 관심을 가지는 것은 매우 중요합니다. Scrum Framework는 Kanban에서 발견된 것 같은 Lean 개선 방법을 수용하기에 충분한 융통성이 있습니다. Lean Thinking의 렌즈를 통해 스크럼를 보면 더 나은 품질, 더 높은 생산성을 내고 낭비를 줄일 수 있습니다.

의도적으로 스크럼 팀의 구현을 최적화 하는 작업은 까다로울 수 있습니다. 개선 방법을 찾을 때 완벽함이 충분함의 적이 되도록 하지 마십시오. 완벽한 스크럼은 고객에게 소중한 고품질의 작업 소프트웨어를 제공하는 것 보다는 중요하지 않으므로 먼저 실제적으로 제품을 개선하는 작업에 초점을 맞춥니다.

참조

  1. West, D. (2011). XXXXX. Forrester Research

  2. Poppendieck, M. P. (2003). Lean 소프트웨어 개발: Agile Toolkit. Addison Wesley 전문가입니다.

  3. Anderson, D. (2010). Kanban - 기술 비즈니스를 위한 성공적인 혁신적 변경. Blue Hole Press.

커뮤니티 추가 항목

표시: