스크럼을 사용하면 사용자 스토리의 교장 및 이러한 스템 핑 작업 등이 완제품으로 반복됩니다.스크럼 - '기타'모든 것을 어디에서합니까?
하지만 실제로 구현해야하는 100 가지 기능이 있다고 가정 해 보겠습니다. 실제로 일반적인 UI (예 : UI 디자인) 작업을 수행 할 때까지는 개발자가이 작업을 수행 할 수 없습니다. 이 기능에 대한 전체적인 생각이 필요합니까?), 또는 반드시 기능으로 명시되지 않는 기본 요소를 작성해야합니다.
그럼, 어떻게 될까요?
필자가 알기로는 스크럼에서는 각 사용자 스토리를 구현하는 데 필요한 것을 빌드하는 것입니다. 따라서 작업중인 사용자 스토리에 대한 기능을 구현해야하는 경우에만 기능이 아닌 기본 사항을 작성해야합니다.
제 생각에는 가능한 가장 많은 것들을 "이야기"로 포함시키는 것이 가장 좋습니다. 그래서 모든 사람들이 시간이 적용되는 것을 잘 볼 수 있습니다.
그러나 예기치 않은 작업 (예 : 컴퓨터가 고장 났을 때 다시 설치)은 항상 수행해야합니다. 이 작업을 수행하는 방법 중 하나는 반복 당 300 스토리 포인트의 속도가있는 경우 각 반복에서 자유 시간의 몇 퍼센트를 남겨 두는 것입니다 (예 : 처음에는 이야기가 250 개만있는 경우). 예기치 않은 것들에 자리를 비우십시오. 다음 반복에서 과거 기록에 따라이 값을 조정할 수 있습니다.
기본적으로 각 기능 내에서 발생합니다. 이는 수행하기보다는 말하기가 쉽지만 점진적인 소프트웨어 개발의 요점입니다.
예를 들어, 반드시 '기능으로 반드시 명시되지는 않은'기본 구성 요소를 많이 작성하는 대신 기능을 필요로하지 않는다고 의심해야하며 해당 기능에 필요한만큼만 빌드하십시오 문제의.
비 기능적 작업은 여전히 제품 백 로그에서 수행 할 수 있습니다. 필자는 스크럼을 사용할 때 분명히 그렇게했습니다. 제품 소유자에게 왜 중요한 것으로 간주되어야하는지 설명해야만 했으므로 시간을 할애 할 수있었습니다. 제품 소유자가 자신이 매우 중요하다고 생각하지 않는다면, 그들은 끝나지 않으며 소유자는 결과를 가지고 살아야합니다. 로드 테스트와 같은 요청에 대한 요청을 무시하고 넘어지면 몇 번 물기 때문에 그들은 돌아갈 것입니다. :)
반면에 비 기능적 요구 사항이있을 수 있습니다 당신은 원래 중요하다고 생각하지만, 아무런 영향을 미치지 않고 시들해질 수 있습니다. 때때로, 다만 때때로, 개발자의 본능은 진정으로 게이팅 요인 작업에 대한
, 당신이 바로 제품 소유자와 정직 있는데 당신이 그들을해야 할을 주장하는 생각 :) 잘못이다. 프로젝트를 계속 진행하는 데 필요한 정도로 제품 소유자와 함께 할 수 없다면 UI 디자인을 얻지 못하는 것보다 더 큰 문제가 있습니다.
보조 작업을 필요한 첫 번째 기능으로 구축합니다. .
제품 백 로그와 스프린트 백 로그 간의 차이를 구분하는 것이 중요합니다. 제품 백 로그에는 "방법"이 아닌 "무엇/왜"를 나타내는 사용자 스토리가 들어 있습니다. 스프린트를 위해 스토리가 선택되면 스토리는 스토리를 빌드하는 데 필요한 작업으로 분류됩니다. 예 : 'UI 디자인'은 '구매할 항목 선택'이야기에 대한 작업입니다.태스크가 종속성을 가질 수 있도록 스프린트 계획 레벨에는 아무런 해가 없습니다. 사실, 대부분의 시간에는 다른 제품 백 로그 항목을 쉽게 사용할 수있는 작업이 있습니다.
희망 하시겠습니까?