Scrum에서 백 로그를 기능 백 로그와 기술 백 로그로 분할해야합니까?

Scrum 팀에서는 백 로그를 사용합니다. 백로 그는 주로 기능적인 주제를 포함하지만 때로는 기술적 인 주제도 포함합니다. 백 로그가 1 개 있으면 다음 스프린트에 대한 주제를 쉽게 선택할 수 있지만 몇 가지 질문이 있습니다.

• 첫째, 개발자 자신이 순수한 기술 항목을 추가 할 수있는 별도의 기술 백 로그를 갖는 것이 더 논리적 인 것 같습니다.이 방법으로 성능을 향상시킬 수 있습니다.이 클래스에는 기술 문서가 부족합니다. 개발자는 항상 주제를 백 로그에 추가하려면 제품 소유자를 통과해야합니다. 이는 제품 소유자에게 불필요한 추가 작업으로 보입니다.
• 둘째, 순수 기능 품목에만 초점을 맞춘 제품 소유자가있는 경우 기술 문서 (예 : 누락 된 기술 문서, 침식되고 리팩토링되어야하는 코드), 디버그 중 항상 문제가되는 클래스 (예 : 안정적인 기반으로 리팩토링되어야합니다. ...) "고객에게 직접 서비스를 제공하지 않기"때문에 항상 목록의 끝에서 끝납니다. 이러한 순수한 기술 항목에 대한 별도의 기술 백 로그와 시간을 모든 스프린트에 예약함으로써 애플리케이션을 기능적으로 개선 할 수 있지만 내부를 건강하게 유지할 수 있습니다.

가장 좋은 방법은 무엇입니까? 백 로그 하나?

나는 전문가는 아니지만 팀당 하나의 백로 그만 가질 수 있다고 말하고 싶습니다. 팀은 긴급한 문제와 연기 할 수있는 문제를 결정해야합니다. 문제를 별도의 유형의 스택으로 분리하면 문제의 핵심이되는 핵심 아이디어, 즉 문제 풀과 각 스프린트가 가장 긴급하게 처리된다는 핵심 아이디어에 위배됩니다. 팀을 (하위로) 나누면 팀과 관련된 작업 유형을 나눌 수 있지만 기본적으로 병렬로 작업하는 팀을 설정하게됩니다. 긴급 성 / 필요성은 다음 스프린트 계획에있어 최고의 결정자입니다. 작업을 분류 할 수 있지만 결정 프로세스에 방해가되지 않아야합니다.

제품 당 하나의 백 로그를 추천하는 사람들에게 내 목소리를 추가하고 싶습니다. 다른 백 로그를 작성하는 것은 합리적인 반응이지만 실제로 핵심 문제를 피하는 것입니다. 제품 소유자가 기능 항목보다 기술 항목을 우선시하지 않는 이유는 무엇입니까? 이 문제를 해결하기보다는이를 해결하는 데 집중해야합니다. 예를 들어 5 가지 이유 기술을 사용하여 문제를 해결할 수 있습니다 .

PO가 기술적 인 문제를 우선시하지 않는 데에는 여러 가지 이유가있을 수 있습니다. 예를 들어, 기술 팀이 기술 부채를 해결하지 않는 장기 비용 ($$)을 설명하지 않을 수 있습니다. 어쩌면 완전히 다른 것일 수도 있습니다. 의사 소통 문제가 발생할 가능성이 높으며 장기적인 해결책은 문제를 해결하고 해결하는 것입니다.

또한, 당신이 생각해야 할 또 다른 질문이 있습니다. 왜 기술 부채가 처음에 발생 했습니까? 기능적 스토리 내에서 리팩토링 등의 작업이 이상적이며 스프린트 내에서 완료되어야합니다. 그것들은 그 자체로 여분의 이야기가되어서는 안됩니다. 그렇지 않으면 잠재적으로 선적 가능한 코드가 없습니다.

당신이 말하는 것은 일반적으로 '기술 부채'입니다. 결함이 할 수있는 것과 같은 방식으로 기술 부채가 스크럼 프로세스에 어떻게 적용되는지 파악하기 어려울 수 있습니다.

제안하는 것은 별도의 '결함 백 로그'가 있음을 제안하고 백 로그를 3으로 나눕니다.

개인적으로, 나는 제품 백 로그 분할을 전혀 옹호 하지 않을 것 입니다. 제품 백 로그의 아이디어는 뛰어난 작업 항목 을 나타내는 것 입니다. 이러한 관점에서, 기능과 기술 부채 항목의 유일한 차이점은 요구 사항이 고객이 아니라 개발 팀에서 온 것입니다. 여전히 작업 항목이며 다른 작업 항목보다 우선 순위를 포함하여 관리해야합니다. 기술 부채 항목에 테스트가 필요한 경우 특히 그렇습니다.이 경우 정규 기능과 정확히 동일한 QA 프로세스를 거쳐야합니다.

프로젝트 당 하나의 백로 그만 있어야한다는 점에서 Onno에 동의합니다. 그렇지 않으면 팀은 기본적으로 제품 소유자의 정당한 결정을 내립니다.

"순전히 기술적 인"품목이라도 사용자와 제품 소유자가 스프린트 백 로그를받을 수있는 실질적인 가치가 있어야합니다. 제품 소유자에게 이러한 이점을 설명하고 비용을 정당화하는 부가 가치를 납득시키는 것이 귀하의 임무입니다. 그리고이 프로세스를 통해 이러한 문제에 대해 생각하고 최소한의 노력으로 프로젝트에 가장 큰 가치를 부여하는 기술적 변경 사항을 선택할 수 있습니다.

위의 모든 답변에 동의합니다. 상업적 현실의 열기 속에서, PO는 기술적 인 것보다 기능적인 이야기를 계속 우선시 할 것이다. 종종 팀의 좌절에. 팀은 사용자 가치가없는 기술적 인 이야기 (속도가 문제가되지 않는 경우 최적화에 관심이있는 사용자)없이 기술적 인 이야기를 삼가야하고, 기능적인 이야기에 의해 암시 된 특정 기술 과제를 보는 법을 배워야합니다. "완료된 정의"도 큰 역할을합니다. 나머지 기능적 스토리는 PO가 우선 순위를 정하기 위해 백 로그에 있습니다.

예 : 기술 문서 : 기술 문서의 가용성 (해당되는 경우)은 DOD에 속하는 일반적인 항목이므로 모든 기능적인 이야기에 업데이트됩니다.

예 : 리팩토링 코드 : 제품 개발에 도움이 될 때 수행해야합니다. 아직 기술 부채로 전환 된 시점이 아닌 (팀은 제품이 어떤 방향으로 진화 할 것인지를 추측해서는 안 됨) 아닙니다. 설계를 검토하는 것도 DoD의 일부가 될 수 있습니다.

MelR에 동의합니다. '기술적'인 것이 있다면, 왜하고 있는지 또는 심지어 사용자에게 단기 및 장기 원인과 결과가 무엇인지 살펴 봐야 합니다.

나는 소위 '기술적 과제'가 비즈니스 가치 방식으로 쉽게 쓰여질 수있는 많은 백 로그를 보았습니다.

기술적 인 작업은 종종 큰 분류 된 이야기의 결과이기도합니다. 그러나 이로 인해 실제 부가가치 (또는 피드백 기회)의 반복이 느려지거나 스프린트 실패가 더욱 악화 될 수 있습니다.

Patrick이 언급 한대로 "부식하고 리팩터링해야하는 코드"와 관련하여 우리가 물어봐야 할 것으로 생각합니다. 시스템 기능 중 어느 부분이 해당 코드에 영향을 미칩니 까? 리팩토링하지 않으면 사용자에게 장기적인 영향은 무엇입니까?

그런 다음 장기적인 기술 부채를 줄이기 위해 "우리가 찾은 것보다 약간 더 나은 것을 남기는"주제가 있는데, 이는 더 넓은 프로젝트에 너무 많은 영향을 미치지 않으면 서 각 스프린트의 작은 이야기의 일부로 수행 될 수 있습니까?

궁극적으로 나는 두 개의 백 로그가 필요하지 않다는 것을 알지 못합니다. 이는 우선 순위가 지정된 요구를 적절하게 늦출 수있는 기회를 열어줍니다. 그러나 기술적 영향에 대해 교육을 받았으며 진정한 가치를 식별 할 수있는 강력한 능력을 가진 제품 소유자가 필요합니다. 스토리를 세로로 나누기-Adobe는 세로 슬라이싱 에 대한 좋은 설명을 제공합니다 .

결코 기술적 인 이야기를 만들어서는 안됩니다. 이것은 일반적인 오류입니다. 당신은 이야기가 비즈니스 요구 사항을 반영해야합니다. 기술적 인 것은 결코 비즈니스 요구 사항에서 나온 것이 아닙니다. 이것이 스크럼 마스터와 팀의 역할로서 목표 또는 스토리에 도달하기 위해 수행해야 할 모든 기술 작업을 평가합니다.

예를 들어 로그인 화면 생성에 대한 이야기라면 아직 생성되지 않은 경우에도 데이터베이스 생성을 고려해야합니다.

PO를 사용하여 IT 팀이 사용자 인 작업을 생성하는 데 문제가 발생하지 않습니다. PO가 업무를 이해하고 비즈니스 가치 측면에서 평가할 수 있다면, 기술적 인 이야기를 만들 수있는 방법이 있습니다. 당신은 시스템을 사용합니다.