나는 최근에 스크럼에 대해 많은 것을 읽었으며 스프린트 중에 스프린트 백 로그를 변경해도 괜찮은지에 대한 정보가 상충되는 것으로 나타났습니다. 스크럼에 대한 위키 백과의 문서 는 확인하지, 그리고 다양한 말한다 다른 기사 뿐만 아니라이 말을. 또한 저의 소프트웨어 개발 교수는 스크럼 개요에서 같은 것을 가르쳤습니다.
그러나 트렌치에서 Scrum 및 XP를 읽었 으며 작업 보드의 계획되지 않은 항목에 대한 섹션을 설명합니다. 그래서 저는 스크럼 안내서를 찾아보고 스프린트 중에 "스프린트 목표에 영향을 미치는 변경 사항이 없습니다"와 스프린트 목표에 대한 논의에서 "개발팀이 예상 한 것과 다른 경우, 그런 다음 제품 소유자와 협력하여 Sprint 내에서 Sprint 백 로그의 범위를 협상합니다. " 스프린트 백 로그 (Sprint Backlog)에 대한 논의에서 계속됩니다.
스프린트 백로 그는 진행중인 변경 사항을 일일 스크럼에서 이해할 수 있도록 충분히 상세하게 계획된 계획입니다. 개발팀은 스프린트 전반에 걸쳐 스프린트 백 로그를 수정하고 스프린트 동안 스프린트 백 로그가 나타납니다. 개발 팀이 계획을 진행하면서 스프린트 목표를 달성하는 데 필요한 작업에 대해 더 많이 알게되면 이러한 출현이 발생합니다.
새로운 작업이 필요할 때 개발팀은이를 스프린트 백 로그에 추가합니다. 작업이 수행되거나 완료되면 남은 예상 작업이 업데이트됩니다. 계획의 요소가 불필요한 것으로 간주되면 제거됩니다. 스프린트 동안 개발팀 만이 스프린트 백 로그를 변경할 수 있습니다. 스프린트 백로 그는 개발 팀이 스프린트 동안 달성 할 계획 인 작업에 대한 가시적 인 실시간 그림으로, 개발 팀에만 속합니다.
그래서이 시점에서 나는 완전히 혼란스러워합니다. 그것에 대해 생각하면 두 번째 접근법을 취하는 것이 더 합리적입니다. 백 로그의 개별적이고 구체적인 항목은 가장 중요한 것이 아니라 스프린트 목표 인 것처럼 보이며 스프린트 목표를 변경하지 않고 백 로그를 변경할 수 있다는 것이 합리적입니다. 예를 들어, 제품 소유자와 팀이 스토리에 대해 같은 페이지에 있다고 생각했지만 스프린트가 진행되면서 오해가 있음을 알아 차리고 그에 따라 해당 스토리를 구성하는 작업을 변경하는 것이 합리적입니다. . 또는 잊혀진 스토리 나 작업이 있지만 스프린트 목표에 도달해야하는 경우 스프린트 중에 스토리 또는 작업을 백 로그에 추가하는 것이 가장 좋습니다.
그러나 스프린트 백 로그에 대한 변경이 괜찮지 않다는 상당히 단호한 것처럼 보이는 사람들이 많이 있습니다. 어떻게 든 그 위치를 오해하고 있습니까? 스프린트 백 로그를 정의하는 사람들은 어떻게 다른가? 스프린트 백 로그에 대한 나의 이해는 그것이 스토리와 그들이 분류 한 작업으로 구성된다는 것입니다.
어쨌든이 문제에 대한 의견을 보내 주셔서 감사합니다. 스프린트 동안 스프린트 백 로그를 변경하는 이상적인 이론적 스크럼 접근 방식과 개발에 스크럼을 성공적으로 사용하는 사람들이 스프린트 동안 스프린트 백 로그를 변경할 수 있는지 여부를 모두 파악하려고합니다.