실행 및 실행 취소
Ken Schwaber 및 David Starr 지음, Scrum.org
2012년 1월
완료 증가를 제공하는 데 있어 Agile 소프트웨어 개발에 성공하는 것이 중요합니다. 실제 및 이론적인 예제를 사용하여 저자는 "완료됨"의 인식과 "완료됨"의 현실 사이의 차이와 이러한 차이가 프로젝트 성공에 영향을 미치는 방식을 설명합니다. 이러한 예제를 사용하여 저자는 팀이 그들에게 적합한 완료됨의 정의로 시작하는 데 도움을 줄 수 있는 도구와 전략 그리고 팀이 종속성, 상태 및 "완료됨"의 의미를 통신하는 데 도움을 줄 수 있는 메서드를 계속 설명합니다.
적용 대상
응용 프로그램 수명 주기 관리; Team Foundation Server
이 문서의 내용:
소개
Anna의 회사에서 투명도 손실
사람들이 생각한 일이 일어났습니까
실제로 발생한 사항
단원
Nanomedtronics AZ에서 기술적 부채
사람들이 생각한 일이 일어났습니까
실제로 발생한 사항
단원
여러 팀과 기술적 부채 증폭
A Datum Corporation의 릴리스 계획
사람들이 생각한 일이 일어났습니까
실제로 발생한 사항
단원
작업 완료를 위한 대규모 기술
스크럼의 스크럼
연속 통합
결론
스크럼은 반복적이고 증분적인 Agile 프레임 워크입니다. 팀은 이를 사용하여 신속하게 "완료"의 증분 또는 각 반복 또는 스프린트에 대해 잠재적으로 사용 가능한 소프트웨어 기능을 제공합니다.
“완료”는 간단하지만 종종 잘못 해석되는 단어입니다. 제게는 완성, 마무리, 완료를 의미합니다. 완료한다는 것은 할 일이 아무것도 남아 있지 않다는 것을 의미합니다. 완료는 정의하기가 간단합니다. 그러나, 완료 증분을 배달하는 것이 스크럼 및 애질리티에 있어 보다 핵심적이고 까다로운 요구 사항의 하나로 남아있습니다.
신속성을 위해서는 전달을 완료하고 각 스프린트가 작동하는 소프트웨어의 증가를 사용할 준비가 되어야 합니다. 아직 대부분의 스크럼과 Agile 팀은 부분적으로 완료된 미완성 증가를 생성합니다. 스크럼 팀에 스프린트에서 제품 백로그 요구 사항이 완전히 완료되지 않을 이유를 물었을 때 팀 구성원은 종종 "시간이 많지 않았습니다."라고 답변합니다.
이 백서에서는 초창기 스크럼의 실제 사례 연구의 예제를 통해 수행된 증분과 관련이 있는 문제를 해결합니다. 이름 및 해당 관련 위치가 변경되었지만 개인은 자신과 자신의 힘든 작업을 인식해야 합니다. 이 문서 전체에서 모든 스프린트는 달리 언급이 없는 한 매월 반복됩니다.
Anna의 회사에서 투명도 손실
Anna는 속성 제목 변경에 대한 부서 영수증을 자동화해야 합니다. 그녀가 일한 회사는 북미 대부분에서 가스 파이프라인을 제작하고 운영했습니다. 그녀의 부서가 처리했고 자신이 가로지르는 땅을 소유한 사람에게 로열티를 지불했습니다. Anna의 부서에서 받은 제목 정보는 인쇄물 또는 속성 변경 문서였습니다. 볼륨이 상당히 커지므로 Anna는 피드와 로열티 지불 프로세스를 자동화하기를 원했습니다.
개발 팀은 스크럼을 사용하는 Anna에 대해 로열티 시스템을 구축할 것을 제안했습니다. 그녀는 매달 검사할 사용 가능한 소프트웨어의 사용 가능한 부분을 가질 수 있었습니다. 그녀도 우리 팀 다음에 수행할 것에 대해 매달 그녀의 의도를 변경할 수 있는 권한이 있었습니다.
세 번째 스프린트가 끝날 때 한 지방에서 피드를 받았으며 오래된 데이터로 통합했습니다. 간단한 SQL 솔루션을 사용하는 것을 보여주었습니다. Anna는 직원의 제품 백로그 대부분이 이 지역에 있었기 때문에 기뻐했습니다.
그녀는 개발 팀이 제공한 소프트웨어를 사용하여 그녀의 직원이 즉시 시작할 수 있도록 SQL을 가르치길 원했습니다.
그녀가 이것을 사용하려는 이유가 무엇이었습니까? 분명 그녀는 스프린트로 마무리 중인 것을 소프트웨어로 완료 중인 것으로 해석했습니다!
Anna에게 이것을 가능한 신중하게 말했습니다. 그녀는 몹시 화가 났습니다. “완료되지 않았다는 것은 어떤 의미입니까? 첫 번째 증분, 두 번째 증분을 보았고 이제 사용해 보고 싶습니다. 배포한 후에 사용할 수 있도록 우리에게 SQL을 가르칩니다.”
처음부터 느낌은 좋지 않았습니다. Anna에게 완료되었다고 말했습니다. 하지만 완료의 형식은 아니었습니다. 이는 사용자에게 표시하기 위해 수행되었지만 소프트웨어를 사용하기 전에 여전히 해결해야 할 문제가 있었습니다.
일부 들어오는 레코드를 처리할 수 없습니다. 우리는 버리는 대신 이들을 저장하고 관리하는 시설이 필요했습니다.
들어오는 레코드의 여러 필드가 문서화 이외의 목적으로 사용되었습니다. 이것으로 무엇을 해야 합니까?
기존 데이터베이스의 필드에는 참조 정보처럼 보이는 포인터 또는 정보가 포함되어 있습니다. 이것은 모두 데이터베이스를 통해서 이루어졌습니다.
들어오는 피드를 실행하고 데이터베이스를 쿼리하고 있을 때 시스템이 여러 번 충돌했습니다. 이러한 충돌 동안 데이터가 손상된 것 같습니다.
Anna는 자신이 수행한 유형의 작업을 완료하기까지 시간이 얼마나 걸리는지 우리에게 질문했습니다. 다른 두 스프린트가 증분을 사용 가능하게 만드는 데 필요했다고 예상했습니다. 그녀는 부서 사용을 위해 계속 준비하라고 말했습니다. 그녀는 다음 날 아침 만나자고 "요청했습니다".
다음날 아침 Anna, 그녀의 상사, 개발 이사가 그 곳에 있었습니다. 이들은 내가 장점으로 내세운 투명도가 제공되지 않았다는 실망을 내비쳤습니다. 이들은 내가 해결되지 않은 문제를 버그로 기록한 것과 다르게 처리해야 했다고 느꼈습니다. 이들은 모두에게 제공된 번다운 보고서에 반영된 진행률이 올바르지 않았다는 이유로 방해를 받았습니다.
회의를 마친 후 진격 명령은 다음과 같았습니다.
조사하고 4개의 버그를 수정합니다.
Anna의 부서가 사용을 시작할 수 있도록 처음 3개 증가를 마치고 배포합니다.
수행된 정의가 비즈니스에서 즉시 사용 가능한 Anna의 정의와 동일하도록 우리의 엔지니어링 기술과 시험 자동화를 개선합니다.
요구 사항이 수정되지 않는 한 처리된 것으로 간주되지 않도록 결함 기록 방법을 변경합니다.
우리 모두가 수업을 통해 배움을 얻는다면 이번이 좋은 학습 기회가 될 것이라고 들었습니다.
사람들이 생각한 일이 일어났습니까
시스템에 대한 기준 계획을 개발하는 경우 이해 관계자와 Anna가 발생할 것이라고 생각한 것을 나타냅니다. 개발 팀은 출시가 될 것처럼 진행율을 보고했고 사람들은 이 보고서를 신뢰했습니다.
개발 팀은 이 계획에서 설명한 대로 작업이 진행 중임을 표시함으로써 옳은 일을 하고 있다고 생각했습니다.
실제로 발생한 사항
속도는 스프린트에 대한 개발 팀이 생산성에 대한 측정이자 기록입니다. 속도는 각 스트린트를 측정하고 생산성의 패턴을 설정하는 데 사용됩니다.
개발 팀은 각 스프린트에서 계획을 맞출 수 있도록 완료된 8개의 작업 단위에 대해 지속적인 속도 8을 필요로 했습니다. 어떤 원인으로 인해 8 아래로 속도가 저하되면 이러한 항목에서 모든 작업을 완료하지 않은 것입니다.
매우 잘 작동하는 기능을 제공했지만 사용하거나 빌드하기에는 충분하지 않았습니다. 나중에 개선할 예정입니다. 실행 취소 작업을 다시 예측했을 때 다른 14개 작업 단위가 추가되었습니다.
초기 작업 시작이 얼마나 어려운지 파악한 뒤 가능성이 있는 20개월 일정을 반영하여 전체 계획을 다시 시작하였습니다. Anna의 개발 부서는 2개월마다 Increments를 릴리스하여 새로운 피드를 활성화했습니다. 새 자동화된 피드로 전체 수동 작업을 크게 줄일 수 있어 시스템이 시작된 후 22개월 동안 가동되면 점강적이 됩니다.
단원
진정한 투명도는 증가를 보고 있는 누구나 같은 사실을 보고 이해해야 합니다. 증가의 투명 검사는 Anna가 위험과 수익 예측을 관리하는 것을 허용해야 합니다. 그러나 증가가 투명하지 않았기 때문에 그녀는 효과적으로 계획할 수 없었습니다.
프로젝트를 시작할 때 Anna는 릴리스 목표를 설정했습니다. 스프린트 1 다음에 그녀는 사용할 수 있다고 생각되는 증분을 검사하여 목표에 대한 진행 상황을 평가했습니다. 그녀는 표를 향해 증분 진행률에 따라 스프린트 2에서 수행할 작업을 결정했습니다. 진행이 부적절하다고 생각했다면 그녀는 프로젝트를 취소했을 수 있습니다.
스프린트3이 끝날 때 Anna는 전체의 3/10이 완료되었다고 믿었는데 그것은 명백히 잘못된 생각이었습니다.
불행하게도 각 증가를 보여주기에 충분한 만큼만 수행했습니다. 실행 취소 작업은 Anna 부서에서 증가를 사용할 수 없게 만들었고 검사하기에 불투명해졌습니다.
증가를 검사할 때 불투명도는 차갑고 젖은 수건으로 온도계를 덮는 것과 같습니다. 자동 온도 조절기는 실제 실내 온도를 정확하게 이해하지 않고 냉각되어야 할 때 부정확하게 난방을 시작합니다.
투명한 증분 없이 이해 관계자는 실제로 발생하는 작업에 대해 올바로 이해하지 않으며 적합하지 않은 올바르지 않은 조치를 취할 수도 있습니다.
즉, 완벽한 투명도 없이 효과적으로 검사하고 적용하는 팀의 기능이 손실됩니다.
Nanomedtronics AZ에서 기술적 부채
기술적 부채는 소프트웨어가 완료된 것으로 간주되려면 완료해야 하는 지연된 작업입니다. 기술적 부채는 잘못된 설계, 코드 중복 및 테스트되지 않은 기능 같은 다양한 형식을 취합니다. 다음 예제에서는 프로젝트 동안 완료된 작업으로 기술 부채의 원인 및 영향을 설명합니다.
Nanomedtronics AZ는 소규모 신설 소프트웨어 회사입니다. 수명에 중요한 제품의 새 릴리스에서 작업하는 하나의 스크럼 팀이 있습니다. 이 중요한 제품은 고혈압으로 고생하는 환자의 막힌 혈관을 청소하기 위해 나노 로봇에서 사용하는 소프트웨어입니다.
사람들이 생각한 일이 일어났습니까
팀이 시작할 때 무언가를 한 달의 스프린트에서 완료함으로 변환하기 위해 제품 백로그 항목을 선택하여 작업을 수행할 것인지 묻습니다(더 이상의 사용 가능하고 전달할 수 있는 작업이 남아 있지 않음). 개발 팀은 완료 증가에 대한 요구 사항을 완벽하게 개발할 모든 기술을 갖추었습니다.
스크럼 팀이 첫 번째 스프린트를 시작하면서 10개월 내에 완수해야 하는 작업이 80단위가 있는 것을 보았습니다. 따라서 개발 팀은 의무적으로 각 스프린트에 대해 8개의 작업 단위를 선택했습니다. 이들이 단순히 스프린트당 8단위 임을 추론하면 회사에서 지정한 10개월 내에 이는 완료됩니다.
개발 팀은 각 스프린트가 끝날 때 작업 중인 증가를 보여주었습니다. 모든 외관에서 스크럼이 실행되었고 계획한 대로 제품을 제공하기 위해 Nanomedtronics AZ가 트랙에 있었습니다.
실제로 발생한 사항
개발 팀 영역을 넘어 명확하지 않은 것은 제공된 각 증분에서 실제로 일부 불량 구현, 중요하지 않은 버그, 반복된 논리 및 일반적으로 복잡한 코드가 포함되었습니다. 또한, 개발팀은 스프린트에서 시간에 대한 압박감을 느낄 때 시험을 중단하였으므로 증분은 완전히 시험되지 않았습니다. 일정 및 가공 품질을 맞추려고 노력은 개발 팀이 방침을 유지하는 방법입니다.
팀은 열심히 일했고 10개월 동안 제품을 만들었습니다. 고객은 소프트웨어를 구현하고 사용하는 데 대해 기뻐했고 준비를 마쳤습니다. 그러나 개발팀은 아래의 새 기술적인 부채 그림처럼 48 단위의 미완성 작업을 모았습니다.
.png "완료된 작업 및 완료되지 않은 작업")
Nanomedtronics AZ의 팀은 진정으로 달성해야 할 모든 활동 및 작업을 완료하는 것을 고려하지 않습니다. 다음은 팀이 고려하지 못한 일을 포함하며 결코 소진되지 않습니다. 포함할 수 있는 더 많은 것들이 있습니다.
분석
디자인
종속성 분석
성능 테스트
안정성 테스트
리팩터링
Immunological 응답 테스트
제품에서 작업하는 다른 팀의 작업과 통합
총체적인 모든 팀의 기여도 증가하도록 다른 팀의 작업을 통합 테스트
릴리스 정보
제품을 판매할 6개 문화권으로 국제화
사용자 승인 테스트
재발 테스트
코드 검토
완료를 만들려면 위의 작업을 수행하고 스프린트의 끝에서 통합 증분해야 합니다. 그러나 대부분의 개발 팀은 위의 모든 작업을 완료하지 않습니다. 이들은 모든 스프린트에서 일부 “완료되지 않은” 작업을 남겨 둡니다. 이를 통해 일부 잘못된 설계, 중복된 코드, 지나치게 복잡한 논리, 테스트되지 않은 기능 또는 성능, 또는 다른 형태의 불완전함에 대한 증분이 발생합니다. 이는 팀이 소프트웨어에서 기술 부채를 만드는 방법입니다.
Nanomedtronics AZ는 그들이 제품에 고객에게 전달해야 할 모든 기능을 포함하지만 많은 결함이 있고 실제로 제품을 시장에 출시하는 데 필요한 패키징 및 마무리 작업이 부족하다는 사실을 알게 되었습니다. 개발 팀은 스프린트 마다 8 단위의 이미 잘못된 속도를 가정하여 완료하는 데 또 다른 6주가 소요되는 추가 작업의 백로그를 실수로 만들었습니다.
6개월 동안 제품이 배송되기를 기다리는 것은 회사 지도자에게는 허용되지 않으며 제품은 작업이 완료되고 3개월 후에는 배송되어야 합니다. 제품 출하 시 손실된 잠재력은 3개월 지연이 아니지만 개발 팀에 새 기능을 추가하는 느려진 기능은 미래의 스프린트에서 기술 부채를 해결해야 합니다.
단원
기술 부채로 인해 제품 소유자와 이해 관계자가 경험에 근거한 결정을 내리는 데 필요한 true 진행률과 투명도를 가리게 됩니다. 기술 부채로 인해 기술적인 문제를 수정하는 데 많은 시간을 소비하고 나쁜 품질로 인해 손실을 보게 됩니다.
대부분의 상황에서 릴리스되면 실행 취소 작업의 50% 이상이 제품에 유지됩니다. 따라서 작업 실행 취소는 지속적인 부채로 규정됩니다. 기술 부채로 인해 제품이 신속하게 손상되어 결국 소프트웨어를 다시 작성이나 제품 포기 같은 부정적인 비즈니스 결정을 강제하게 됩니다.
여러 팀과 기술적 부채 증폭
개발 팀은 스프린트에서 수행하는 것 만큼의 작업만 신중하게 선택해야 합니다. 개발 팀은 경험을 통해 작업이 얼마나 많이 진행되었는지 압니다. 그러나 팀은 다른 많은 작업을 수행하려면 자동화된 빌드와 회귀 테스트 같은 현대 엔지니어링 사례를 사용해야 합니다. 이러한 것들이 적용되지 않았다면 수동 작업은 네 번째 또는 다섯 번째 스프린트에 압도되는 경향이 있습니다.
세 명의 프로그래머와 두 명의 QA 전문가의 개발 팀을 생각하십시오. 매일 프로그래머는 소스 코드 시스템으로 코드를 확인합니다. 테스트 중이며 버그를 찾아 올바른 프로그래머에게 제공됩니다. 체크 인 코드와 검색하고 보고 중인 결함 간에 시간이 경과되었습니다. 이 시간 동안 다른 프로그래머가 잘못된 코드 위에 코드를 체크 인 했을 수 있습니다. 초기 문제를 해결하는 데 필요한 노력은 이제 더 큽니다. 개발팀이 계속 퍼실리티를 빌드하고 시험하면 오류가 즉시 감지될 수 있습니다. 사람들이 조사하고 해결한 다음 진행할 수 있습니다. 추가 작업 및 낭비를 피할 수 있었습니다.
많은 조직은 소프트웨어를 빌드하기 위해 둘 이상의 스크럼 팀을 사용합니다. 이런 일이 발생하면 위 단원에서 설명한 기술적 부채 문제가 크게 증폭됩니다. 결함 코드 상단의 코드를 체크인하는 기회가 크게 향상됩니다. 소프트웨어의 증가하는 취약성을 교정하는 비용은 작업을 진행하면서 기하 급수적으로 증가합니다.
A Datum Corporation의 릴리스 계획
최근에 인프라 소프트웨어 회사인 A Datum Corporation이라고 하는 다른 회사에서 일했습니다. 기본 제품 라인은 250명의 프로그래머를 포함하여 800명 이상의 개발자를 채용합니다. 개발 인프라는 부분적으로 자동화되었고 부분적으로는 수동이었습니다. 테스트는 종종 몇 일씩 지연되었습니다. 프로그래머에 의한 결함이 있는 코드 확인, 발견 및 보고 간 소유된 시간은 10일 이상이었습니다.
이렇게 많은 프로그래머의 복잡성을 최소화하기 위해 각 개발 팀은 자체 코드 분기에 대해 작업했습니다. 개발 관리자는 종속성을 최소화하는 제품 백로그 요구 사항을 구성했습니다. 각 개발 팀 매일 메인 코드에 개발된 코드를 병합하면 잠재적인 재작업의 양을 최소화할 수 있습니다.
그러나 관리자는 시간이 너무 많이 걸렸다고 느꼈습니다. 관리자는 세 번째 스프린트마다 모든 코드 분기를 루트에 병합하기로 결정했습니다. 통합 테스트는 결함을 찾은 다음 해결합니다. 릴리스 후보는 3개월마다 준비됩니다.
사람들이 생각한 일이 일어났습니까
다음 그림은 계획된 릴리스 일정 및 주기를 보여줍니다.
.png "계획된 릴리스 일정 및 주기")
원래 계획은 다음으로 간주되었습니다.
9 스프린트
3 릴리스 후보, 그런 다음 전체 릴리스
800명 개발 조직
실제로 발생한 사항
9개월의 스프린트 후에 이 조직이 릴리스 날짜에 도달하면 제품은 릴리스에 대한 준비가 되지 않은 것입니다. 6번째 릴리스 후보는 5,000개 이상의 결함이 있었고 2,000개 이상의 제품 백로그 요구 사항이 완료되지 않았습니다. 과연 어떻게 될 것인지 궁금했습니다. 3개월마다 출시 후보를 지켜 보았습니다. 조사할 때 데모는 각 개발 팀의 코드 분기에서 온 것임이 발견되었습니다. 통합이 발생하지 않았습니다. 통합 테스트가 발생하지 않았습니다.
릴리스 날짜에 필요한 속도를 유지하기 위해 개발 팀은 모든 통합 작업을 지연시켜 많은 양의 기술 부채를 만들었습니다. 결과는 예정된 출시 날짜에서 8개월 지연되었습니다. 단어 "릴리스 후보"에는 아무런 의미가 없었습니다.
다음 그림은 실제 프로젝트와 안정화에 필요한 시간을 보여줍니다.
.png "안정화에 필요한 실제 프로젝트 및 시간")
릴리스 후보는 각 팀에 대해 코드분기에서 부분적으로 작동하는 기능을 갖고 있었습니다. 릴리스하기 전에 5개월의 “안정화” 기간이 필요합니다. 다른 무엇보다 배송을 지연시키는 특정한 한 가지 결함은 "나쁜 성능"입니다. 이 문제는 첫 번째 스 프린트에 기록되었습니다.
단원
같은 소프트웨어에서 작업하는 다른 팀들은 결국 자신의 작업을 병합하게 됩니다. 통합 소프트웨어가 작동할 수 있도록 하면 통합 위험을 줄이고 자주 발생해야 합니다.
여러 팀의 작업이 병합되기를 기다리는 것은 병합의 비용을 지연시킬 수 있는 유혹입니다. 그러나 이러한 지연의 궁극적인 비용은 관련된 팀의 수와 통합해야 할 지점 수로 자세히 설명됩니다.
작업 완료를 위한 대규모 기술
여러 팀에서 "완료" 상태에 도달하는 것은 어렵습니다. 관련된 복잡성은 많습니다. 팀 간 종속성과 코드 분기의 종속성이 존재합니다. 배율이 복잡하여 비용이 들지만 해 볼만한 일이며 팀이 하나로 통합되어 전달할 때 엄청난 가치를 얻을 수 있습니다.
여러 팀이 함께 작업할 때 유용한 여러 가지 기법이 있습니다.
스크럼의 스크럼
많은 스크럼 팀이 같은 프로젝트에서 작업하는 경우 이러한 작업을 조정하는 기술이 필요합니다. 저는 ''스크럼스 오브 스크럼"을 권장합니다. 이는 각 팀의 스크럼 후 즉시 매일 행해지는 이벤트입니다. 각 팀의 기술자가 일부 참석합니다. 각 팀 담당자는 자신의 팀이 어떤 작업을 수행했는지 설명합니다. 그 사람이 향후 계획하고 있는 작업이 무엇인지 설명합니다. 이 정보를 바탕으로 담당자는 필요한 모든 재작업, 향후의 모든 종속성 그리고 일정을 재조정해야 하는 모든 작업에 대한 식별을 시도합니다.
스크럼의 스크럼은 많은 조직에 유용했습니다. 그러나 이 방법은 부적합합니다. 문제가 알려진 것 보다는 적게 예상되는 이유로, 종속성 및 재작업은 성공적으로 식별될 수도 있고 아닐 수도 있습니다. 예기치 않은 종속성으로 인해 재작업이 초래되었고 테스트에 실패합니다. 일부 팀은 종속성 작업과 재작업에 각 스프린트의 50% 이상을 소비합니다.
연속 통합
XP(Extreme Programming)를 사용하려면 팀 작업의 연속 통합과 통합 테스트가 필요합니다. 모든 팀에 확장되지 않는 이유는 무엇입니까? 두 팀 또는 50개의 팀이 있을 경우 팀은 모든 스프린트의 끝에서 통합, 통합 테스트 증분 값을 생성해야 합니다. 이렇게 하려면 팀은 자주 자신들의 작업을 통합해야 합니다. 통합 취소된 작업은 잠재적으로 해결되지 않은 종속성을 포함할 수 있으므로 연속 통합이 최상의 솔루션입니다.
모든 작업의 연속 통합은 간결한 생산 기술과 비슷합니다. 간결한 생산 라인에서 전체 생산 공정 동안 품질 평가에 많은 기술들이 사용됩니다. 편차 또는 품질 문제가 발생하면 생산 라인이 중단됩니다. 연속 통합 및 통합 테스트는 소프트웨어 제품 개발을 위한 동일한 기법을 제공합니다.
만약 연속적인 빌드 또는 테스트에 실패하였다면, 어렵겠지만 모든 팀 및 팀 구성원들이 코딩을 중단할 것을 권장합니다. 지속적인 작업은 결함 위에 빌드될 가능성이 있으며 오류의 리플 효과를 초래합니다. 연속 통합이 사용되는 경우 팀은 통합 오류를 방지하기 위해 서로 긴밀하게 작동합니다. 작업 습관이 개선되고 낭비가 줄어들고 품질이 증가합니다.
스크럼을 도입하는 대부분의 조직은 모든 엔지니어링 기술 및 완료 증가를 빌드하는 도구를 시작하지 않습니다. 완료 증분을 달성하는 엄격한 프로그램을 시작하고 추적해야 합니다. 50명 이하의 구성원이 있는 그룹은 스트린트 내에 완료된 증분 완성 상태에 빠르게 도달할 수 있습니다. 5백명 이상의 개발자가 있는 조직은 종종 이 지점에 도달하는 데 수 년이 소요됩니다.
증가 실행 취소는 낭비를 만들고 팀이 진정한 민첩성을 얻지 못하도록 합니다. 완료되지 않은 작업의 실제 비용은 증가분에서 기능이나 함수의 부족 보다 훨씬 더 많습니다. 비용에는 더 낮은 예측 가능성과 더 높은 위험에 따르는 비용뿐만 아니라 증분이 완료될 경우 필요한 재계획 및 재작업에 의한 낭비가 포함됩니다.
많은 조직은 민첩성의 혜택을 원하며 스크럼을 이용하여 혜택을 얻습니다. 완료 증가를 제공하는 데 있어 Agile 소프트웨어 개발에 성공하는 것이 중요합니다. 팀은 의미가 있는 완료의 정의로 시작한 후 시간이 지남에 따라 의도적으로 정의를 확장해야 합니다. 그럴 경우에만 정품 신속성을 달성합니다.