티켓에 대한 예상 시간을 만들 때 테스터 (QA)에 걸리는 시간이 티켓 예상에 포함되어야합니까? 우리는 이전에 테스터 시간없이 항상 추정했지만 항상 포함하는 것에 대해 이야기하고 있습니다. 티켓 출시까지 1 주일이 걸리는 총 시간을 알아야하므로 출시 전 마지막 스프린트에 적합합니다.

팀에서 제한적인 리소스 인 경향이 있기 때문에 개발자 시간에 대한 평가는 항상 이해했습니다. 한 동료가 테스터 시간 이전에 일했던 곳도 포함되었다고 말합니다.

분명히 이것은 개발자가 좋은 범위로 단위, 통합 및 UI 테스트를 작성하는 프로세스를위한 것입니다.

내 권장 사항 : 티켓에 테스트 시간을 포함 시키거나 테스트 작업 자체를 나타내는 티켓을 추가하십시오. 다른 접근 방식을 사용하면 필요한 실제 작업을 과소 평가하게됩니다.

개발자 시간은 종종 병목 현상이 있지만 경험상 테스트에 제약을받는 많은 팀이 있습니다. 제한 자원이 증거가없는 것으로 가정하면 물릴 수 있습니다.

동료로서 테스트 시간을 고려하지 않은 성공적인 조직을 보지 못했습니다.

설명에 대한 부록 : 개발자가 자동화 된 테스트, 특히 단위 테스트 (통합 테스트가 더 효과적 임)를 작성하더라도 제대로 테스트하기에는 충분하지 않습니다.

품질 보증 담당자가 관련된 경우 시간을 다른 방식으로 추정해야합니다. QA 직원을 급여에서 제거하기로 결정한 경우에만 근무 시간이 사실상 사라지고 추정에서이를 제거 할 수 있습니다. 그러나 이것은 무시하기 쉬운 부작용이있을 것입니다. 그리고 여전히 성능, 스트레스, 보안 및 승인 테스트가 누락되었을 수 있습니다.

예 , 강조

테스트는 개발 프로세스의 일부입니다. 팀에서 실제로 소프트웨어 테스트에 시간을 소비하는 경우 테스트에 소요 된 시간이 추정치의 일부 여야합니다.

이것이 민첩한 경우 전체 스토리 포인트의 일부로 테스트 노력을 포함시킵니다. 예를 들어 개발 노력은 1 일이고 1 일은 2 포인트 스토리가 될 것입니다.

그것은 당신의 정의가 무엇인지에 달려 있지만, 일반적으로 개발 완료, 비즈니스 승인 및 테스트는 반복에서 사인 오프됩니다. DoD가 단지 비즈니스 수용 인 경우 테스트 노력을 스토리 포인트에 포함시킬 필요는 없지만 여전히 추적해야합니다.

견적은 티켓을 완성하는 데 필요한 모든 작업을 설명해야합니다. 테스트가 티켓의 필수 부분 인 경우 견적에 포함되어야합니다. 테스트가 별도의 티켓이라면 그렇지 않아야합니다.

dev-only 5와 dev-only 8의 차이점은 dev-and-QA 5와 dev-and-QA 8에 비례하기 때문에 이야기 포인트를 사용하기 시작하면 당연히 모든 퍼지가 발생할 수 있습니다.

테스터 시간 작업을 포함하는 것을 보았습니다. 나는 별도의 이야기가 작동하는 것을 보았습니다. 나는 그룹별로 작업을 수행하는 것으로 추정되는 별도의 작업을 보았습니다. 모든 과정이 당신을 위해 봉사 한 후에는 그 반대가 아니라 당신에게 의미가있는 것을하십시오.

당신이 이것에 대답 할 수 없다는 사실은 당신이 왜 견적을 작성하는지 (또는 적어도 당신이 견적을 작성하는 이유에 대해 동료와 동의 하지 않음)을 모른다 는 것을 암시 합니다 . 이는 추정치에 테스트를 포함해야하는지 여부를 결정하는 것보다 더 큰 문제입니다.

견적을 작성하는 이유를 알아 보거나 동의하십시오. 특정 팀이 특정 시간에 달성 할 수있는 일을 예측하는 경우, 그 팀의 예상 팀이 테스트를 수행하는지 여부에 따라 대답이 달라집니다. QA 팀이 분리되어 있고 자체 일정이있는 경우 주어진 티켓에서 귀하 (개발자)가 얼마나 많은 테스트 시간을 필요로하는지 알고 싶어 할 것입니다. 그들은 당신의 숫자를 무시하고 자신의 숫자를 넣을 수 있습니다. 그들은 그들이 시간을 추정 시간과 별도로 추적 할 수 있습니다.

반면에 한 팀이 모든 개발, 테스트 및 QA를 수행하고 시간 추정의 목적이 팀이 특정 시간 프레임에서 수행하는 작업을 예측하고 계획하는 것이라면 물론 시간 추정에는 다음이 포함되어야합니다. 명시된 목표를 달성하기 위해 팀이 수행해야하는 다른 작업과 함께 품질 관리. 문제를 해결하기 위해 모든 티켓에 대해 킥오프 모임을 갖거나 완료시 약간의 서류를 작성해야하는 경우 관리자의 시간이 어딘가에 있어야 합니다. 당신은 그것을 무시할 수 없습니다.

모두 하나의 팀이지만 "개발자"와 "테스터"역할이 분리 된 경우, 분할의 한 쪽에서 만 작업 할 수있는 티켓이 많고 Gantt 차트가 표시 될 수 있습니다. 두 개의 개별 팀에 대한 차트처럼 보입니다. 이 사실은 다른 방법론보다 일부 방법론을 더욱 화나게 할 것이므로 계획 때문에 분할하는 것이 더 나을 수도 있지만, 분할하지 않으면 팀이 수행해야 할 모든 것을 발권하고 추정해야합니다. .

예측의 목적이 예측 및 계획 이외의 다른 경우 (예 : "우리는이를 포함하는 빈 의식을 무의식적으로 따르기 때문에"또는 "경영진이 우리를 초과 근무에서 벗어나기 위해 막대기로 사용하기 때문에"), 또는 "우리는 고정 가격 입찰을해야하고 숫자가 엄청나게 공식화 되었기 때문에"(John Wu 덕분에) ;-) 포함해야하는 것을 파악하기가 더 어려울 수 있습니다.

사용자 스토리 / 피처 / 티켓을 실제로 수행하기 위해 수행해야하는 모든 작업을 항상 추정하십시오. 우리는 이것을 DoneDone 이라고 부릅니다 .

우리는 생산 준비가 완료되었습니다 .

여기에는 모든 수동 및 탐색 테스트뿐만 아니라 사용자 수락 테스트도 포함됩니다.

애자일 팀은 언제든지 완성 된 작업의 새로운 부분을 공개 할 수 있어야합니다. 같이:

작동하는 소프트웨어는 기본 진행 측정입니다.

테스트하지 않은 경우 작동하는지 어떻게 알 수 있습니까? 이제 개발 시간이 시간의 병목이라고 생각합니다. QA 엔지니어로서 대부분의 팀은 테스트 용량에 병목 현상이 있거나 바로 가기 만하는 것으로 생각합니다.

긴 이야기를 짧게하려면 테스트 노력도 추정하십시오. 속도에 영향을 줄 수 있음을 명심하십시오 . 스토리 포인트에서 상대 추정을 수행 한 경우 테스트가 이미 평균 속도에 통합되었을 수 있습니다.

여기에 매우 중요한 것이 있습니다 : 모든 추정에는 가정과 배제가 수반되어야합니다 .

여기에는 개발 전용, 설계 및 개발, 개발 및 단위 테스트, 수용 테스트 적용 범위, 인프라 구축 등의 내용이 포함됩니다.

프로젝트 매니저로 추정 문서를 제공하는 경우, 그들은을위한 클라이언트 또는 (있는 경우 내부 프로젝트)에 대한 작업 지시 또는 작업의 문에 그 문서를 변환하려고 PMO . 그들은 수 오버 헤드를 추가하기위한 경험에 의한 계약 또는 세트로 설정되어 있습니다 (예를 들어, 일부 프로젝트는 다음 표지 관리 및 프로젝트 관리에 Y의 %를 추가, QA를 충당하기 위해 X % 추가 할 수 있습니다) 세트 공식이있다. 그리고 당신은 두 번 세고 싶지 않습니다. 반면에 자동으로 추가하지 않을 수도 있습니다.

연습이 다릅니다. 이 숫자를 사용하는 사람은 숫자의 의미를 알아야하며 테스트 시간을 포함하는지 여부를 명시해야합니다.

시간은 추정에 포함되어야하지만, 당신은 대신에, 테스터 시간을 예상하지 말아야 테스터가 자신의 시간을 예상해야한다 .

테스트 시간을 포함하지 않으면 소요되는 총 시간을 잘못 추정 할 수 있지만 개발자 시간과 테스터 시간은 상호 교환 할 수 없습니다 (특히 테스터와 반복적으로 병렬 작업을하기 때문에 반복적으로 수행 할 수 없기 때문에). 또한 테스터가 변경 사항을 테스트하는 데 필요한 시간을 예측할 수있는 위치에 있지 않으며 테스트 승무원 만 그렇게해야합니다.

캡슐화

저는 소프트웨어 개발 관점과 언어에서 이것에 접근 할 것입니다.

• 당신은 큰 기계에서 작은 코그입니다.
• 팀 외부에서 발권 시스템이 팀에 대한 인터페이스 / API 역할을합니다.
• 발권 시스템을 사용하는 비즈니스 사용자는 개발자가 아닙니다

우수한 소프트웨어 디자인에서 최대한 단순화하고 캡슐화해야합니다.

따라서 비즈니스 사용자의 관점에서 프로세스를 보려면 실제로 두 가지에 대해서만 신경을 씁니다.

1. 비용은 얼마입니까?
2. 아직 끝났나요?

비즈니스 사용자가 팀의 내부 프로세스에 대해 알도록하는 것은 나쁜 관리입니다. public내부 상태에 액세스하는 것과 유사합니다 .

팀의 내부 상태를 보호하지 못하면 다른 팀이 리소스를 관리하고 내부 상태를 망칠 수 있습니다.