동일한 제품을 사용하는 여러 개발 팀의 경우 "완료"에 대한 정의


12

스크럼 테스트 중 하나에는 여러 개발 팀이 동일한 제품에서 작업을 수행 할 때 "완료"를 가장 잘 설명하는 정의에 대한 질문이 포함되어 있습니다.

정답은 해당 개발 팀이 결합 된 작업을 잠재적으로 해제 할 수 있도록 "완료"라는 정의를 가져야한다는 것입니다.

이 퀴즈에 대한 정답에서 분명하지 않은 것은 다음과 같습니다.

  • 팀이 "완료"에 대해 다른 정의를 가질 수 있습니까? 어느 정도까지?
agile  scrum 

제품을 직접 출시하는 팀과 다른 팀에서 사용중인 동일한 작업을 생각해보십시오.
— Ian

또는 예를 들어 영어 버전의 소프트웨어는 프랑스어로 번역되기 전에 배송 될 수 있습니다.
— Ian

이런 종류의 혼란은 내가 아무 일도하지 않았다고 말하는 이유입니다. 대신 나는 항상 우리가 한 일을 정확하게 말합니다. 무언가가 이루어 졌는지 결정하는 것은 협상입니다. 선언이 아닙니다. 어떤 정의를 따르 든 관계없이
— candied_orange

답변:


16

모든 팀이 다른 팀이 완료 한 작업을 고려하여 "완료"를 정의하면 기능이 완료된 것입니다.

각 팀이 "완료"를 다르게 정의하고 다른 팀이 해당 정의에 대해 알기를 기대하는 경우 몇 가지 문제가 발생합니다.

  • 통합 문제가 발생하면 어떤 팀도 문제를 해결할 책임이 없습니다. 결국, 통합을 시작할 때 "완료"되었으므로 다른 팀의 작업과 관련이 있어야합니다.

  • 소수의 팀이 많으면 특히 팀간에 차이가있을 때 모든 사람의 "완료된 정의"를 기억하기가 어렵습니다.

  • 완료의 정의는 통합 작업이 제대로 작동하고 있다는 것을 포함하지는 않습니다.

승인 된 답변은 모든 팀의 작업이 통합되어 제대로 작동 할 때까지는 수행되지 않았다고 분명히 밝히고 있습니다. 릴리스 가능해야하며 최종 사용자가 전체적으로 수용 할 수 있어야합니다.


의견에 대한 응답으로 편집 : 모든 팀이 동일한 정의를 가지고있는 것은 아닙니다. 이는 모든 팀 정의 완료의 일부 가 더 큰 시스템이며 다른 통합 구성 요소가 손상되지 않았 음을 의미합니다.


나는 당신의 용서를 간청하지만 정답은 "완료"의 단일 정의에 대해 아무 말도하지 않는 것 같습니다. 또한 통합 특성이 포함되어 있는지 확실하지 않습니다. 두 팀이 서로 다른 고객 전용의 동일한 API를 완전히 다른 방식으로 구현하고 있다고 가정 해보십시오. 그러나 공식적으로 그들은 여전히 ​​동일한 제품을 연구하고 있습니다.

2
@Andremoniy, 정답은 실제로 단일 DoD 에 대해 아무 말도하지 않지만 모든 팀의 DoD가 전체 제품이 계속 작동한다는 공통 요소를 가져야한다는 것을 의미합니다. 다른 API 구현을 수행하는 다른 팀의 예는 단일 제품이라고 할 수 있다고 확신하지 않습니다.
— Bart van Ingen Schenau

2
@Andremoniy : 한 팀이 다른 팀의 작업에 의존하자마자 부품이 다른 위치에 배치 된 경우에도 통합 문제가 발생할 수 있습니다. 예를 들어, 하나의 마이크로 서비스가 다른 마이크로 서비스를 예상치 못한 부정확 한 방식으로 사용하는 경우 통합 문제이기도합니다.
— Bart van Ingen Schenau

2
@Andremoniy : 두 팀이 동일한 DoD를 사용해서는 안된다는 것이 맞지만, 변경 사항이 다른 팀에 부정적인 영향을 미치지 않아야한다는 규칙을 공유 할 수 있습니다 (작업이 뒷면과의 인터페이스 변경을 포함하는 경우 주로 트리거 됨) 엔드 서버).
— Bart van Ingen Schenau

1
@Andremoniy : 귀하의 의견에 감사드립니다. 제기 한 일부 문제를 해결하기 위해 답변을 업데이트했습니다.
— Greg Burghardt

6

한 팀이 "완료"를 "개발 완료"(즉, 리포지토리에 병합 된 코드)로 정의하고 다른 팀은 "테스트 완료"(즉, Q / A로 릴리스되고 테스트 된 코드)로 정의하는 상황을 상상할 수 있습니다.

전반적인 제품 상태가 크게 정의되지 않아 실제로 출시 할 수 있는지 여부를 말하기가 어렵 기 때문에 본질적으로 심각한 문제가 발생할 수 있습니다.


모든 팀이 동일한 정의를 공유해야한다는 정답을 고려하십니까?

예, 간단한 이유로 일반적인 정의가 있어야한다는 데 동의합니다. 복잡한 프로젝트는 하위 프로젝트 (예 : 마이크로 서비스)가 전체 제품 (예 : MyCool ERP)을 구축하는 트리 구조로 간주 될 수 있습니다. 따라서 특정 시점에 새 버전의 제품을 출시 할 수 있는지 알고 싶습니다. 그러나 특정 하위 구성 요소에 대해 다른 DoD가있는 경우이 정보를 추론하기가 매우 어려워집니다.
— Pawel Gorczynski
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.