스크럼-스프린트 중에 팀원들이 바쁘다

따라서 스크럼 스프린트는 특정 기능 세트를 구현해야하는 고정 된 시간입니다. 그리고 스크럼 팀은 이러한 기능을 제공하기 위해 최선을 다하는 모든 사람들로 구성되며, 대부분은 일반적으로 개발자와 테스터입니다.

이러한 규칙을 설정하면 전체 스프린트 동안 이러한 모든 사람들을 바쁘게 유지하는 방법이 궁금 할 것입니다. 스프린트의 시작 부분에는 아직 테스트 할 것이 없으며 스프린트의 끝 부분에는 일반적으로 개발 / 수정할 것이 거의 없습니다.

나는 이것을 처리하는 두 가지 접근법을 보았지만 어느 것도 문제를 올바르게 해결하지 못하는 것 같습니다.

1) 팀 구성원이 작업이 없을 때마다 무엇을해야할지 결정하도록합니다.

단점 :

• 그들이 무엇을 철저히 계획하지 않으면 (즉, 주요 리팩토링, 새로운 테스트 프레임 워크로 전환), 그들의 작업은 쓸모 없거나 중간 쯤에 갇혀있을 수 있습니다
• 다른 한편으로, 그러한 작업을 계획하는 데는 많은 시간이 걸릴 수 있으며 고객은 즉각적인 가치를 제공하지 않는 팀 시간을 낭비하는 것을보고 실망 할 수 있습니다
• 이러한 작업은 일반적으로 철저하게 추정 할 수 없으므로 원칙이없는 작업자가 스크럽 보드 나 다른 곳에 반영하지 않고 YouTube 고양이를 보는 데 시간을 보내는 것이 매우 쉽습니다.

2) 스프린트에 개발 전용 공간을 마련하고 스프린트가 완료된 후 테스트를 시작하십시오 (개발자가 다음 스프린트에서 기능 작업을 시작할 때)

단점 :

• 현재 스프린트의 기능을 개발하는 동안 개발자는 이전 스프린트의 버그를 수정하여주의를 산만하게하며 현재 스프린트 중에 수행 된 것으로 추정되는 작업량을 수행하지 못할 수 있습니다.
• 두 개의 스크럼 보드가 필요합니다. 하나는 현재 스프린트 기능을위한 것이고 다른 하나는 이전 스프린트 버그를위한 것입니다.

그래서 내 질문은 : 스프린트 동안 개발자와 테스터 사이에 작업을 올바르게 분배하여 아무도 작업에 과부하가 걸리거나 작업이 끝나지 않도록하는 방법은 무엇입니까? 위에서 설명한 접근 방식을 개선 할 수있는 방법이 있습니까? 아니면 더 나은 접근 방법이 있습니까?

스프린트의 시작 부분에는 아직 테스트 할 것이 없습니다

정말? 검증 할 필요가 없습니까? 고객과 논의 할 내용이 없습니까? 평가할 와이어 프레임이 없습니까? 테스트 할 계획이 없습니까?

스프린트가 끝나면 일반적으로 개발 / 수정 할 것이 거의 없거나 거의 없습니다.

나는 프로젝트에서 그 장소에 가본 적이 없다. 더 이상 할 일이 없습니까? 항상 무언가가 있습니다. 모든 테스트가 완전히 자동화 되었습니까? CI는 어떻게 보입니까? 데이터베이스 액세스 계층을 더 간단하게 리팩토링 할 수 있습니까? 그리고 빈 버그 목록과 백 로그로 아무것도 한 적이 없습니다. 폭포 테스트 단계에서 개발자들이 무엇을 했습니까?

나는 어떤 사람들이 '스크럼'이 무엇인지 아닌지에 대해 매우 종교적인 것을 알고 있습니다. 나는 그것에 대해 덜 신경 쓰지 못했습니다. 하지만 여기에 두 가지 문제가 있다고 생각합니다.

1. 고객과 개발자와 협력하여 올바른 것을 구축하고 올바르게 구축하고 있는지 확인하는 대신 개발자가 코드를 '완성'하면 코드를 테스트하는 '전통적인'QA 부서. Lisa Crispin 의 민첩한 테스트 사분면 을 살펴보십시오 . 최고의 테스터는 소프트웨어 개발 라이프 사이클의 모든 단계에 참여하며 최고의 개발자는 자체 테스트를 작성합니다.

2. 단일 스프린트 내에서 짧은 시간 내에 완료하기 쉬운 작업으로 분할되는 우선 순위가 정해진 크기의 백 로그를 갖지 않고 1 주 / 2 주 스프린트의 스크럼 시간표에 너무 근접하려고합니다 . 당신이 이것을 가지고 있다면 항상 더 많은 일을해야 할 것입니다. 이 스프린트에서 작업 한 마지막 기능이이 스프린트의 릴리스에는 포함되지 않지만 항상 다음 스프린트로 이동할 수 있습니다.

곁에. 소규모 응집력 팀이 있다면 역할이 덜 중요합니다. 생산 코드 작성이 허용되지 않는 라벨 테스터를 가진 사람이나 테스트 이상이라고 생각하는 개발자를 라벨을 붙인 사람 대신, 모든 사람들이 팀이 성공하기 위해 필요한 모든 일을해야합니다. 그것들은 필요합니다. 이것을 교차 기능 팀이라고합니다.

의견에서 @Cort Ammon이 제기 한 추가 사항. 민첩한 선언문은 계약 협상을 통한 고객 협업에 대해 이야기합니다. 너는 ~라고 말한다:

고객은 팀이 즉각적인 가치를 가져 오지 못하는 시간을 낭비하는 것을보고 실망 할 수 있습니다

설명하기가 어려울 수 있으며 고객이 때때로 매우 어려울 수 있음을 이해하지만 이것은 큰 위험이 될 것입니다. 그들은 그들의 소스 코드 / 고객 관계 / 비즈니스 / 당신이 그들을 위해 개발하고있는 것을 당신을 신뢰하고 있습니다. 그들이 당신이 최선의 이익을 위해 전문적으로 행동한다고 ​​믿을 수 없다면, 당신은 문제가 있거나하는 것입니다.

전문가로 간주되지 않는 소프트웨어 개발자에 대한 게시물 을 작성 했습니다 . 전문 의사, 변호사, 토목 기사는 고객의 요구 사항을 일부 변경 한 고객과 대면하여 품질을 낮추고 신음하는 것이 아닙니다. 고객에게 문제가 될 것이라고 알릴 것입니다. 고객이 밀었다면 전문가는 책임을지기 때문에 맹목적으로 열등한 기준을 세우지 않을 것입니다. 우리는 전문적인 입학 시험을 치르지 않으므로 책임을지지 않습니다. 그렇다고해서 더 나아지지 말아야한다는 의미는 아닙니다.

요약하면, 스프린트의 시작과 끝에서 사람들의 효율성을 높이려고 노력하는 것에 대해 너무 걱정하지 않고 팀 내에서 더 넓은 문제의 증상으로 간주합니다. 당신은 들어 본 적이 익스트림 프로그래밍 (XP) . XP에서 적용 할 원칙은 의사 소통과 존중입니다.

• 팀이 자신이 생각하는 최선을 다하도록 존중하십시오. 나는 고양이 비디오를 많이 볼 수 있다면 개발자가 약하거나 잘못 취급하고 있다고 주장합니다.
• 통신. 개발자가 서로, 테스터, 관리자, 고객과 대화하는 경우 모든 사람이 다음에 어떤 일이 벌어지고 있는지 잘 알고 있어야하며 그렇지 않은 경우 질문 할 수 있습니다.

첫 번째 요점은 스크럼은 모든 개인이 아니라 팀을 최적화 하는 것 입니다. 팀이 생산적이고 효율적이면 작업 시작 또는 종료시 누군가가 유휴 상태인지 여부는 중요하지 않습니다.

그러나 내가 한 모든 팀에는 항상 많은 작업이 있습니다. 몇 가지 특정 문제를 해결하겠습니다.

스프린트의 시작 부분에는 아직 테스트 할 것이 없습니다.

문자 그대로 의미가있을 수 있지만 테스터의 유일한 작업은 "테스트하는 것"이라고 생각합니다. 그들이 테스트를 시작하기 전에 할 수있는 일이 많이 있습니다. 우선 제품 소유자 및 개발자와 만나 요구 사항을 완전히 이해할 수 있습니다. 테스트 계획 작업, 테스트 데이터 수집 등으로 바쁠 수 있습니다. 훌륭한 프레임 워크가 있다면 사전에 자동화 된 테스트를 시작할 수 있습니다.

스프린트가 끝나면 일반적으로 개발 / 수정 할 것이 거의 없거나 거의 없습니다.

아직 해결해야 할 사항이 부족한 개발 팀을 보지 못했습니다. 그러나 그것은 스프린트가 끝날 때 그들이해야 할 일이 아닙니다. 스프린트가 끝날 무렵 테스터가 제품을 테스트하는 데 도움을 주어야합니다. 자동화 된 테스트를 작성하는 데 도움을 줄 수 있으며 테스터가 작성한 테스트 및 픽스처 / 키워드 등을 코드 검토 할 수 있습니다. 문서 팀과 함께 작업을 마치는 데 도움을 줄 수 있습니다.

나는 이것을 처리하는 두 가지 접근법을 보았습니다 ... 1) 팀 구성원이 작업이 없을 때마다 무엇을 해야할지 결정하게하십시오.

당신의 생각의 결점은 개인이 과제를 다 썼다는 것입니다. 작업은 팀 전체에 속합니다. 현재 스프린트에서 팀에게 남은 이야기 나 작업이있는 한 다른 작업을 수행해서는 안됩니다 .

스프린트에 공간을 만들어 개발을 위해

이 접근 방식은 기존의 스크럼 또는 민첩성 정의에 속하지 않습니다. 민첩성의 핵심은 전체 팀이 공통의 목표를 향해 노력하는 것입니다. 즉 , 스토리를 완성하는 데 필요한 모든 작업은 디자인, 개발, 테스트, 문서 등 스프린트로 표현되어야합니다.

마지막으로 이것이 유일한 다른 실행 가능한 솔루션은 아닙니다. 당신은 진정한 해결책을 무시합니다. 즉, 모든 팀원은 스프린트에서 이야기를 끝내는 데 도움이되도록 필요에 따라 참여해야합니다.

목표는 팀 목표이지만 각 개인이 개별 목표를 갖는 것처럼 작성하고 있습니다 ( "내 작업 완료"). 누군가 할 일이 없으면 현재 진행중인 작업을보고 도움을 제공 할 수 있습니다. 또는 다음 작업이나 스토리를 수행하여 작업을 시작할 수 있습니다.

내가 일한 모든 민첩한 상점에서 테스터는 닭 으로 간주 되므로 개발자처럼 스프린트에서 타임 박스로 표시되지 않습니다. 소프트웨어를 사용하기 전에 테스터는 계획을 작성하고 소프트웨어를 수신 할 수있는 환경이 올바르게 설정되어 있는지 확인해야합니다. 이것의 일부로서 그들은 디자인 문서와 같은 것을 눈여겨 봐야합니다.

다음으로 스프린트를 채우십시오. 물론 추정이 검은 예술이기 때문에 스프린트가 끝나면 스프린트가 끝날 때 여가 시간이 없어야 합니다 .

스프린트가 끝날 때 개발자에게 여가 시간이있는 경우이 시간을 추적하여 가치를 추가하고 있는지 확인하십시오 (새로운 프레임 워크 학습, 분석, 추가 테스트 등).

버그 수정은 스프린트에 넣을 수있는 활동입니다. 기능에 기여하므로 가치를 더합니다. 이것은 다음 스프린트에서 시간을 도난당한 것으로 보아서는 안됩니다.

이상적인 세상에서, 당신의 팀은 기능 이 다를 것 입니다. 모든 사람은 자신의 전문 분야를 가지고 있지만 모든 사람이 다른 전문 분야로도 일할 수 있습니다. 테스터가 가장 간단한 작업을 코딩 할 수 없으면 교차 기능 팀이없는 것입니다.

스크럼 방식은 팀이 서로 기능을 발휘할 수 있도록하는 것 입니다. 테스터는 어쨌든 테스트 자동화 기술을 갖추어야합니다. 덜 복잡한 것들을 코딩하는 짧은 단계입니다.