스프린트에 대한 여러 사용자 스토리를 계획하고 하나의 후보 스토리가 팀에 무언가를 제공하는 일부 외부 제공자에 의존하는 경우. 예를 들어 시스템에 새 API 호출을 추가하거나 시스템 등에서 테스트 계정을 활성화하는 온라인 서비스 공급자가 있습니다.
당신은 그것이 곧오고 있다는 것을 알고 있습니다.
스토리를 완료하는 데 필요한 시간을 제공 하거나 다음 스프린트가 끝날 때까지 기다렸다가 준비가되어 있다는 것을 알면 즉시 시작할 수 있기를 바라며 스프린트에 스토리를 추가 합니까? 그것은 가능한 빨리 이야기를 시작하지 않는 것을 의미합니다.
전자가 의존성으로 인해 잃어버린 'unarned'스토리 포인트를 어떻게 처리합니까? 부분 신용 (eek!) 또는 턱에 가져 가라.
답변:
궁극적으로 외부 공급자가 필요할 때 사용할 수있는 것을 제공 할 것이라고 100 % 확신하는지 여부에 달려 있습니다.
그들이 제 시간에 배달되는지 확신 할 수 없다면 스프린트에 스토리를 추가하지 마십시오. 그러나 그들이 과거에 항상 제공했기 때문에 이번에 제공 할 것이라는 보장은 없습니다.
고객에게이 종속성이 존재하며 작업을 스케줄하기 전에 API (또는 기타)를 사용할 수있을 때까지 기다려야한다는 것을 고객에게 알려야합니다.
긍정적 인 측면에서, 당신이 전달할 수있는 스토리의 측면이있을 수 있습니다. 즉, 가능한 한 의존성을 분리 할 때까지 더 자세히 분석하십시오. 이를 통해 공급 업체가 작업을 제공하기 전에 일부 스토리를 수행 할 수 있습니다.
코드와 써드 파티 API 사이에 인터페이스를 작성하면됩니다. 인터페이스에 코딩하여 나머지 프로젝트를 진행할 수 있으며 실제 API를 사용할 때까지 모의 데이터를 사용하여 예제 데이터를 반환합니다. 그런 다음 실제 API가 도착하면 인터페이스 뒤의 코드를 변경하면 나머지 응용 프로그램에는 영향을 미치지 않습니다. 인터페이스가 변경되지 않을 것이라는 API 공급 업체에 동의 할 수있는 경우에만이 작업을 수행하십시오 (적어도 크게 변하지는 않음).
팀은 헌신하는 팀입니다. 팀에서 외부 개발자 (예 : 외부 개발자)를 기다리고 있다고 느끼면 스토리를 기꺼이 받아들이지 않는다는 것을 알게되었습니다. 이야기는 다루기에 적합하지 않습니다.
외부 리소스와의 지연, 예상치 못한 또는 다른 전달이 예상 및 우선 순위가 변경 될 수 있음을 의미합니다.
모든 정보를 얻을 때까지 팀은 이야기를 완성 할 수 있다고 생각하기에 순진하지 않아야합니다. 그들이 할 수 있다고 말하면 예상되는 형식으로 늦게 도착하거나 전혀 그렇지 않은 경우 모든 사람을 실망시킵니다.
가혹하게 들리지만 요점을 파악하고 싶습니다.
Scrum에는 done에 대한 정의가 있으며 사용자 스토리 준비가 된 정의가 있습니다. 귀하와 같은 상황에서는 모든 이해 관계자가 이해하고 동의 할 준비가 된 정의를 갖는 것이 중요합니다. 예를 들어 다음과 같이 ready 정의에 대한 라인을 갖는 것이 매우 합리적입니다.
제품에 가치를 더하기 위해이 API가 필요한 경우 작업을 시작하기 위해이 API가 실제로있을 때까지 기다려야합니다. 그 동안 우리는 제품에 가치를 부여하는 다른 미국을 할 수 있습니다. 모의 구현과 같은 미국을 좋아하지 않습니다. .
아직 모르는 것을 기다리고 있다면 내일 배달 될 것이라고 100 % 확신하더라도 계획 할 수없는 것 이상입니다. 왜? 모르는 경우 복잡성을 추정 할 수없고 추정 할 수 없으면 계획 할 수 없기 때문입니다.
외부 회사가 따라야하는 "인터페이스"/ "계약"을 사전에 정의한 경우이를 계획하고 서비스 모의를 작성할 수 있습니다. 개발시에는 모의 서비스를 사용하므로 외부 전달에 의존하지 않습니다. 모의에 대해 개발되고 테스트 된 기능이 완료되지 않았기 때문에 실제 서비스가 제공되는 스프린트에 여전히 모의 개발이 계획되어야합니다.
두 가지 시스템은 방법론 자체가 아닌 프로그래머가 통합합니다. 회사가 외부 시스템을 통합하기로 결정한 경우 (최소) 2 개의 엔티티간에 계약이 체결됩니다. 계약 은 통합이 이루어 지도록해야합니다 . 결과적으로, 회사 간의 합의가 두 부서 간의 기술 협력을 필요로하지 않는다면 문제는 개발 방법론이 아닙니다. 문제는 비즈니스 방법론 (기본적으로 계약) 입니다.
이러한 사례를 계획하는 동안 위험을 고려해야 하며 팀 의 속도 를 모르는 경우 해당 마진에 관대해야합니다.
/pm/1400/how-can-a-project-manager-manage-a-dependency-on-an-external-team