스크럼-스프린트 외부에서 작업하는 개발자

스크럼 팀

• 3 x 개발자
• 2 x 테스터
• 1 x 자동화 테스트 분석가

우리는 개발자가 테스트하지 않고 테스터가 개발하지 않는다는 점에서 다기능 팀이 아닙니다. 이것이 문제의 근본 원인이라고 생각합니다.

우리는 현재 2 주 스프린트를합니다.

스프린트가 시작될 때 모두가 바쁘고, 개발자는 개발 작업을 시작하고 테스터는 테스트 준비 (테스트 케이스 작성 등)를하고 있습니다.

테스터가 준비를 마치면 개발 작업이 완료되기를 기다리거나 개발 작업이 완료되고 개발자가 피드백 / 버그를 기다리고 있습니다.

개발자는 여기에 가려운 발목을 잡고 현재 스프린트 외부에있는 백 로그의 항목에 대해 작업하기 시작합니다. 이것은 현재 스프린트에서 다음 스프린트 작업을 개발하는 이상한 영향을 미쳤습니다. 나에게 이것은 기분이 좋지 않습니다.

경영진의 관점에서 볼 때 개발자는 책상에 앉아있는 것보다 작업을하는 것이 아니라 스크럼 팀의 목표와 초점이 현재의 스프린트에만 집중해야한다고 생각합니다. 우리 팀이 다기능이지만 불행히도 달성 할 수 없기를 바랍니다. 테스터는 개발 작업을 수행하는 데 필요한 기술이 없으며 대부분의 개발자는 테스트가 그 아래에 있다는 의견을 가지고 있습니다.

이것은 스크럼에서 문제로 간주됩니까? 이것에 대한 해결책이 있습니까? 스크럼은 다기능 팀과 만 작동합니까?

가능한 경우 다른 사람들의 경험을 알고 싶습니다. :)

이는 파이프 라이닝으로 인해 다소 일반적인 문제 입니다. 이 팀은 다기능이지만 성능을 저하시키는 내부 사일로가 있습니다.

먼저 중요하다고 생각되는 몇 가지 사항에 주목하고 싶습니다.

1. 개발자가 미리 반복 작업을하는 경우 계획 회의를 선점합니다. 제품 관리자와 팀은 다음 반복에 가장 유용한 것이 무엇인지 논의해야합니다. 우선 순위는 개발자가해야 할 일이 더 없기 때문에 효과적으로 수행해서는 안됩니다.

2. 반복을 나누고 배열하는 방법에 관계없이 팀에 사일로 작업 전문가가있는 한 모든 사람을 항상 점유하고 단일 계획 회의로 단일 팀을 가질 수는 없습니다. 순수한 폭포 접근 방식을 사용하더라도 "벽에 물건을 던져"피드백을 기다려야합니다.

3. 또한 단일 스토리에 개발 단계, 테스트 단계, 버그 수정 단계가 필요하다는 문제점이 있습니다. 특히 팀이 비효율적 일 수 있습니다. 컨텍스트 전환이 필요하기 때문입니다.

이 상황에는 분명히 비용이 많이 듭니다. 팀이 협업하고 있지 않습니다. QA 팀이 참여할 때마다이 문제가 발생하여 다른 솔루션을 실험 할 시간이 조금있었습니다.

나를 위해 매우 잘 작동 한 것은 다음 두 가지 도구입니다.

1. 모든 팀원 이 일을 처리해야 한다는 원칙을 강조하십시오 . 개발자가 "더 이상 내 문제가 아님"이라고 말하는 방식으로 "dev done"스토리를 거부하십시오. 이는 건설적이고 특허 적으로 거짓이 아닙니다. 팀이 수락 한 스토리를 전달하지 않으면 전달하지 않은 전체 팀입니다.

2. 개발자와 QA 모두의 시간을 점유하려면 페어링하십시오 . 이것은 당신이 선택할 수있는 전문 지식과 도메인 지식을 공유하는 가장 좋은 방법입니다. 개발자는 테스터가 작업을 자동화하도록 도울 수 있습니다. 테스터는 취하기 때문에 코드를 테스트하는 것이 중요한 곳을 개발자에게 보여줄 수 있습니다. 둘 다 협력하고 빠르게 작동하지 않습니다.

이 두 가지 기술을 사용하면 팀의 업무 처리량이 줄어들고 성능이 향상됩니다. 테스터와 개발자는 작업을 교환 할 가능성이 거의 없지만 팀원으로 일하고 서로를 비난하는 대신 내부적으로 문제를 해결할 수 있습니다.

SCRUM 및 스프린트와 관련하여 작업하는 방식에는 문제가 없습니다. 단, 개발자 작업이 더 적은 시간 (그리고 훨씬 더 적은 시간)으로 완료된 후 계획된 시간에 평가 시간에 기록됩니다. 이를 통해 팀은 다음 스프린트를 위해 더 많은 스토리 포인트를 취할 수 있습니다. 결국 스프린트의 요점은 계획을 더 잘 세우는 것입니다. 분명히 당신은 여전히 ​​개선의 여지가 있습니다.

우리는 항상 현재 스프린트에서 다음 스프린트 작업을 개발하고 있습니다

우와! Scrum에서는 기술적으로 불가능합니다. 다음 스프린트에 어떤 백 로그 항목이 있는지, 즉 스프린트 계획 세션에서 다음 스프린트가 시작될 때 설정되어야합니다.

조직이 Scrum을 방해하는 새로운 창조적 인 방법에 대해 배우는 것은 여전히 ​​흥미 롭습니다.

스크럼 은 개인이 아닌 팀을 위해 최적화합니다 . 스크럼의 요점은 팀이 효율적이되는 것입니다. 개발자가 현재 스프린트 이외의 작업을 시작하면 팀을 무질서하게 만듭니다. 또한 스프링을 채우기 위해 충분한 작업을 계획하지 않으면 계획 프로세스에서 다소 실패하고 있음을 보여줍니다.

개발자가 개발 작업이 부족한 경우 테스터, 기술 작가 또는 디자이너 (팀의 모든 사람)에게 도움을 청해야합니다. 그들은 반드시 (그들은,하지만 실제 테스트를 작성하지 않아도 해야 ),하지만 그들은 여전히 테스트 과정에 참여할 수 있습니다. 테스터의 효율성을 높이는 데 도움이되는 스크립트를 작성하거나 테스터와 문제를 논의하고 해당 문제를 극복하는 데 도움을 줄 수 있습니다 (예 : 웹 페이지 요소에 id 속성 추가, 테스터가 제공하는 후크 또는 API 제공) 테스트 등에 사용할 수 있습니다).

문제의 핵심은 개발자가 항상 현재 스프린트에서 작업하지 않는 경우 아직 팀으로 작업하지 않는 것입니다. 스크럼 마스터는주의를 기울여야하며 팀을 개인이 아닌 단위로 일하게해야합니다.

또한 이것이 관리 문제라고 제안합니다. 개발자가 바쁘게 지내도록 압력을가한다면 스크럼을 완전히 수용하지 않은 것입니다. 이것은 스크럼 마스터가 도울 수있는 또 다른 것입니다. 그들은 경영진과 협력하여 스크럼의 작동 방식을 이해하여 개발 팀을 전복시키는 대신 지원하고 격려 할 수 있습니다.

여기서 중요한 문제는 다음과 같습니다.

개발자의 대다수는 테스트가 그 아래에 있다고 생각합니다.

우리가 회사에서이 문제를 처리 한 방법은 개발자가 실제로 작업을 증명할 수 없으면 실제로 작업을 완료했다고 말할 수있는 방법을 물었습니다. 물론, 그것을 증명하는 유일한 방법은 그들이 작성한 코드가 실제로 작동한다는 것을 보여주는 것입니다. 이것은 테스트를 통해 이루어집니다. 테스트에 참여하기로 동의하면 테스트가 더 빨라지고 추가 기능을 코딩하는 데 더 많은 시간이 필요하다는 점을 지적해야합니다 (테스트해야 함).

코드 테스트는 개발자 수준 아래에 있지 않아야합니다. 개발 과정에서 없어서는 안될 부분입니다. 코딩과 분리 할 수 ​​없습니다. 누구나 코딩 할 수 있습니다. 모든 사람이 코딩 한 내용이 실제로 작동한다는 것을 코딩하고 증명할 수있는 것은 아닙니다.

개발자를 바쁘게 만드는 또 다른 방법은 스프린트에서 개발 한 기능에 대한 자동화 된 테스트 코딩 작업을하는 것입니다. 그런 다음이 테스트를 주기적으로 실행되는 회귀 테스트에 사용할 수 있습니다.

어느 쪽이든, 스프린트의 시작 부분에 계획되지 않은 것을하는 것은 큰 아니오입니다. 계획되지 않은 일을하는 것보다 아무것도하지 않는 것이 좋습니다. 이러한 경우에 작성하는 기능은 테스터가 원래 계획된 내용을 테스트하여 바빴 기 때문에 제대로 테스트되지 않았기 때문에 DoD (정의 정의) 기준을 충족하지 않을 가능성이 높습니다. 이것은 버그를 도입하고 제품의 품질을 저하시키는 확실한 방법이며 팀을 하향 회귀 문제 및 컨텍스트 전환으로 유도하여 스트레스, 속도 감소 및 결국 팀으로 인해 팀을 종료합니다.

이론적으로 SCRUM 팀의 모든 구성원은 동일한 지식을 가지고 있어야 각 구성원이 다른 모든 구성원의 모든 작업을 수행 할 수 있습니다. 그렇지 않은 경우 지식을 전파해야합니다.

그러나 실제로는 항상 어떤 종류의 전문화가 있습니다. 소프트웨어는 복잡하고 팀 구성원마다 다른 기술이 있습니다. 팀을 개발자와 테스터로 나누는 것은 전문화의 한 가지 예일뿐입니다.

지식을 확산시키는 데는 경영진이 수용하는 것보다 시간이 더 걸릴 수 있습니다.

내 경험으로는 몇 가지 일을 할 수 있습니다.

• 팀을 너무 작게 만들지 마십시오. 예를 들어 4 명의 개발자와 4 명의 테스터가있는 경우 다른 개발자 나 테스터로 작업을 이동하는 것이 훨씬 쉬우 며이 예와 같이 3/2 만 남게됩니다.
• 더 큰 작업을 분할하십시오. 더 작은 작업이 있으면 더 유연 해집니다.
• 남은 시간이있을 경우 수행 할 수있는 선택적 작업을 정의하십시오.

이러한 제안은 100 % 스크럼 이론이 아닐 수 있지만 먼저 개발 작업을 계속해야합니다. 스크럼은 도구 상자 일뿐입니다.

팀을 비 동기화해야 할 것 같습니다. 그렇게 :

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

테스트 자동화 담당자가 며칠 일찍 시작해야한다는 것을 이해했다면.

그러나 나는 당신의 팀에서 문제를 느낀다 : 나는 자신의 코드를 테스트하지 않는 개발자들에게 문제가있다. 테스트 담당자가 코드를 검토하지 않고 테스트를 준비하는 경우 개발 된 프로그램의 결정 사항을 고려하지 않은 블랙 박스 테스트 만 수행하고있을 것입니다. 소프트웨어의 품질에 만족하십니까?