스크럼으로 요구 사항을 수집

Question

내 개발 팀은 스크럼 methodolody, 꽤 노력하고 있습니다. 우리는 번 다운 차트에 의해 추적되는 스프린트로 분류되는 우선 순위 제품 백 로그를 가지고있다.

문제는 제품 관리자 (이해 관계자로부터 요구 사항을 수집하는 사람)가 스프린트 시작 전 며칠이나 스프린트 세트에 대한 요구 사항에 대한 개요를 제공한다는 것입니다.

우리는 그들을 살펴본 다음 기술적으로 그리고 합리적인 시간 내에 실현 가능한 것으로 수정합니다. 이것은 경영진, 다른 제품 관리 및 이해 관계자의 검토를 위해 퇴장 당하며, 일반적으로 수정/조정되어 원이 계속되어 모든 문제가 해결됩니다.

한편 스프린트 시작 날짜가 우리에게 있으며 우리는 꽤 안정적인 요구 사항을 파악하기 시작합니다. 일단 이러한 작업이 끝나면 요구 사항이 약간 변경되면서 코드를 조정할 수있는 끝없는 시간을 갖게됩니다.

요구 사항을 고정적으로 생각해서는 안되는 것을 알고 있지만, 우리는이를 심하게 관리하고 민첩한 개발에 폭포 요구 사항 접근 방식을 적용하려고합니다.

개선 제안이나 경험이있는 사람이 있습니까?

편집 : 이것은 아마도 우리에게 가장 나쁜 시나리오 일 수 있습니다 - 때로는 요구 사항이 매우 안정적이며 실제로 스크럼을 올바르게 사용합니다! 그러나 더 자주 우리는 스프린트에서 위의 시나리오를 보았습니다. 그래서 나는 질문했습니다. 위의 내용이 실제로 적절한 스크럼이 아니라는 것을 알고 있습니다.

Answer 1

이해 관계자를 스크럼에 가져 오십시오; 그 (것)들을 불러내 어 제품 매니저를 통해서 어떤 "중국 속삭임든지"el elimate. 또한 개발자가 아닌 백 로그의 우선 순위를 정하는 것이 필요합니다. 이해 관계자가 스크럼에있을 때 그들은 변화의 파급 효과를 더 잘 볼 수 있으며 변화를 멈추지 않고 변화가 어떻게 반복에 영향을 주는지 더 좋은 개념을 갖게됩니다.

변경 요구 사항; Agile Manifesto ... "변화를 받아들이십시오!"

친절,

댄

Answer 2

예. 그리고 이것은 중요합니다 : 스프린트가 시작된 후 이야기에 대한 변경 사항을 수락하지 마십시오.

이것은 허용되지 않는다는 것을 제품 소유자에게 알리기 위해 스크럼 마스터 대신 많은 노력이 필요합니다. 그들에게 강조해야 할 중요한 점은 개발자가 지정한대로 스토리를 추정하고 전달할 것을 약속하는 것이며, 변경 사항이 있으면 해당 노력이 무효화된다는 것입니다.

스프린트가 시작된 후 요구 사항이 합법적으로 변경되는 경우가 있습니다. 여기서 스프린트를 완전히 중단하는 것을 고려하십시오. (주의를 기울여야합니다.)

제품 소유자가 지나치게 유연하지 않다고 판단되면 스프링 길이를 줄이는 것이 좋습니다. 나는 스토리가 아주 작아지면서 최소 1 주일의 스프린트를 사용하는 가게에서 일했습니다.

자세한 내용은 Agile Project Management 및 Ken Schwaber의 스크럼을 참조하십시오.

Answer 3

Google은 제품 소유자를 대신하여 요구 사항을 수정하는 직원이 팀에 있습니다. 가끔씩 우리는 just-in-time 요구 사항을 가지고 있습니다. 때로는 약간의 재 작업이 필요합니다. QA는 릴리스의 최신 스프린트에서 정식으로 검토 된 요구 사항을 수용합니다.

팀은 제품 소유자가 명확하게 정의한 작업 만 커밋해야하며, 그렇지 않은 경우 팀을 추정 할 수 없습니다. 아마 당신은 당신의 반복을 단축하여 단지 안정적인 요구 사항 만 계획 할 수있을 것입니다.

프로세스에서이 검토주기를 명령하면 스프린터 블 항목을 제품 관리자/관리/이해 관계자가 승인 한 항목으로 제한 할 수 있습니다.

Answer 4

아무도 실제로 제품 백 로그를 소유하지 않은 것입니다 (즉, 고유 한 제품 소유자가 없음). 가장 중요한 제품 백 로그 항목이 각 반복 전에 준비 상태가 아닌 것처럼 보입니다. 이것들은 명백한 주요 장애물이며, 해결되어야합니다. ScrumMaster가 해결해야합니다.

Answer 5

"스프린트 시작일이 다가오고 있으며 우리는 꽤 안정적인 요구 사항을 파악하기 시작했다. 일단 완료되면 요구 사항이 조금씩 바뀌면서 코드를 미세 조정하는 무한한 시간을 갖게된다."

애자일 방법 또는 스크럼이라고하지 마십시오.

그건 그냥 미친 짓이야.

스프린트가 시작된 후 조정할 경우 제대로하지 않을 것입니다.

당신은 (실제로 당신의 격려하는) 나쁜 행동을 가능하게하고 있습니다. 그들이 의 요구 사항을에 도달하기 전에 얻을 수 없다면 두 가지 선택이 있습니다.

1. 대기. 이것에 아무런 문제가 없습니다. 장기적으로는 저렴합니다.

2. 시작. 하나. 요구 사항은 스프린트 기간 동안 고정되므로, "조정"없이 스프린트를 완료해야한다. 변경 사항은 백 로그의 일부가됩니다.

   • 더 짧은 스프린트를 할 수 있습니다.

   • 비틀기는 자신의 문제를 일으키고 있다고 생각할 때까지 간단히 백 로그 할 수 있습니다.

또한, 경영 검토의 많은 매우 민첩하지 않습니다. 그 자체가 아닙니다. 잘못되었습니다. 그러나 그것은 신뢰의 부족을 나타냅니다. Agile은 개발자와 제품 소유자 간의 공동 작업과 상호 작용을 의미합니다. 그것은 관리 검토의 또 다른 계층을 의미하지 않습니다.

Answer 6

나는 다른 것에 동의한다; 귀하의 제품 소유자가 존재하지 않습니다. 약정을하기위한 충분한 견고한 요구 사항을 충족하고 제품 소유자가 그 약속에 동의 할 때까지는 스프린트를 시작할 수 없습니다. 일단 약속이 이루어지면 스프린트를 포기하고 계획을 변경하지 않는 한 어느 당사자도 스크럼의 맥락에서이를 변경할 수 없습니다. 물론, 당신은 이것을하지 않고 있습니다.

귀하의 스크럼 마스터가 프로세스의 책임자로서의 책임을 따르지 않는다는 내용이 추가로 명시되어 있습니다. 왜 스프린트 백 로그 상품을 선택할 수있는 유효한 제품 잔고가 없을 때 스프린트를 시작하게하는 이유는 무엇입니까? 스크럼 마스터가 있습니까?

나는 팀이 일을 끝내려하고있는 것 같지만, 실제로 일어나고있는 일은 잘 관리 된 제품으로 백 로그를 가질 필요가없는 제품 관리자에게 나쁜 행동을 유발한다는 것입니다. 스프린트가 시작되기 전에 미리 정의 된 사용자 스토리를 준비한다.

스크럼에 스크럼 마스터와 제품 소유자가 있고, 스프린트가 시작되기 전에 스프린트 백 로그에서 제품 소유자와 팀 간의 계약이 필요합니다. 이러한 할당 된 역할을 가지지 않고 스크럼 프로세스를 따르지 않으면 중단 될 수 있습니다. 예, 악의적 인 행동을 지적하는 스크럼 부분을 피하는 것이 더 쉽지만 인정 될 때까지 나쁜 행동을 변경하지는 않습니다. 광기의 정의는 다른 결과를 기대하면서 계속해서 똑같은 일을 반복한다는 것을 기억하십시오. 결과를 변경하려면 작업 내용을 변경해야합니다.