스크럼에서 스프린트 종료시 경합 / 워크로드를 처리하는 방법

우리 팀은 몇 분 전에 스크럼을 사용하기 시작했습니다. 우리의 프로젝트는 물리적 장치 (로봇과 센서를 생각 함)와 인터페이스하는 소프트웨어를 구축하는 것과 관련이 있으며 일반적인 제품 백로 그는 일반적으로 전체 장치에 제어 장치를 추가하는 것을 나타냅니다.

우리는 여기서 예제에 가까운 작업을 나누었습니다 . 각 장치 통합 기능은 코드, 테스트, 통합 테스트, 피어 검토 등으로 나뉩니다. 분명히 각 제품 백 로그 항목에 고유 한 순서가 있습니다. 일반적으로 스프린트는 2 주 동안 지속되며 팀 구성원은 4-6 명입니다.

스프린트가 끝나면 두 가지 문제가 발생합니다.

• 첫 번째는 스프린트 종료시 모든 사람을 바쁘게 유지 하는 것 입니다.
• 두 번째 (관련)는 시스템의 경합입니다. 스프린트 마지막 며칠 동안 우리는 거의 통합을하게됩니다. 우리는 하나의 통합 시스템 만 가지고 있으므로 사람들은 시스템에 액세스 할 수 없기 때문에 작업을 계속 수행하지 못하는 경우가 종종 있습니다. 스프린트의 끝이므로 스프린트 백 로그에서해야 할 일이 많지 않습니다. 이 사람들은 무엇을해야합니까? 현재 항목이 완료되지 않았기 때문에 제품 백 로그의 상단에서 픽업 항목이 제품 소유자로부터 제대로 수신되지 않았습니다. 기술 부채 에 대한 작업 은 프로젝트 전체에 도움이되지만 스프린트 완료에는 도움이되지 않습니다.

이러한 문제를 피하기 위해 스프린트를 구성하는 모범 사례가 있습니까? 제품 소유자와 협상하기위한 팁?

스프린트가 끝날 때 속도가 느리다는 것이 어떤면에서 좋을 것입니다. 즉, 바쁘게 일하는 한 스크럼 팀에 대해 잘 평가하고 과도하게 최선을 다하지 않는 것을 의미합니다. 스프린트.

이것은 예정된 개념에 대한 개념 증명을 수행하거나 기존 코드를 리팩터링 할 위치를 찾고 코드에서 더 나은 테스트 범위를 얻는 등의 작업을 수행 할 수 있습니다.

스프린트가 끝날 때까지 기다리지 않고 각 작업이 완료되는 즉시 팀이 작업을 통합 할 수 있도록 통합 시스템을 수정해야합니다.

며칠 내에 완료 할 수있을 정도로 짧은 사용자 스토리로 작업하는 것이 좋습니다. 여기서 완성 된 것은 코드 완성, 테스트 및 통합을 의미합니다 .

제공하는 전체 팀의 책임이 아닌 개인 회원이라고 기억 자체가 다음 위에 각 과정을 통해 하나 움직임을 밀어 -, 그것은 가능한 각 작업 TOGETHER에 네 - 투 - 6 명 작업을하는 것입니다. 처음에는 비효율적으로 들릴 수 있지만,보고있는 병목 현상이 그렇게 나쁘면 유효한 옵션 일 수 있습니다.

또한 제약 이론 (Goldratt 's The Goal )을 살펴보고 이러한 통합 병목 현상이 발생하는 이유와 위치를 가장 잘 분석 할 수있는 방법을 알아볼 수 있습니다.

우리는 Kanban 접근 방식을 채택하여이 문제를 해결했습니다.

추적 소프트웨어 (Jira)에는 최소 및 최대 대기열이 있습니다.

우리는 '필요에 따라'손질합니다. 일주일에 한 번, 3 번일 수 있으며, 한계와 수행 한 작업에 따라 달라질 수 있습니다.

이를 통해 제품 소유자가 대기열을 많이 유지하는 데 집중하고 개별 티켓의 미세 관리를 줄일 수 있습니다. 항상 변화는 시간이 걸린다는 것을 기억하십시오.

우리는 여전히 2 주마다 데모를하고 매주 릴리스합니다.

와우, 당신이 로봇을 말하지 않았다면, 당신이 지금 내 팀에 있다고 가정합니다. 우리는 정확한동일한 문제 세트. 매니페스트에 대한 다양한 수준의 충실도와 다양한 성공률로 수많은 민첩한 프로젝트를 수행 한 결과, 스프린트가 너무 짧다는 것이 나의 분석입니다. 우리는 몇 주 동안 문제를 일으키는 2 주 스프린트를하고 있습니다. 하나는 우리가 계획을 세우는 데 지나치게주의를 기울이고 결국에는 죽은 날로 끝나는 것입니다. 두 번째는 매 2 주마다 1-2 일이 소요되는 검토, 회고 및 계획에 대한 거대한 전례입니다. 당신이 말했듯이 다른 하나는 마지막 순간에 통합해야하고 검토 전에 자주 실패하는 시간입니다. 내가 처음으로 성공한 민첩한 프로젝트에는 4 주간의 스프린트가 있었으며, 수집 한 스프린트는 업계 표준에 따라 상당히 크지 만 우리에게는 훌륭했습니다.

편집 : 첫 번째 프로젝트에서 유익한 것이 하나 더 기억되었습니다. 우리는 항상 우선 순위가 높은 제품 백 로그를 보유하고 있었으며 스프린트 작업이 완료되고 다른 스프린트 작업을 사용할 수없는 경우 개발자가 해당 작업을 자유롭게 수행 할 수있었습니다.

두 번째 문제는 아마도 문제가 아닌 # 1을 고치려고 한 결과 일 것입니다. 바쁘지 않은 사람들이 동료를 도울 수 있도록해야합니다. 스프린트 이외의 작업을 수행하는 대신 제한된 통합에 대한 경합이 발생합니다.

또한 스프린트의 끝에 통합하지 말고 지속적으로 통합해야합니다.

이제 막 시작했습니다. 팀에게 회고 과정을 통해이 문제를 스스로 해결할 수있는 기회를 제공하십시오.

둘째, 제품 소유자는 팀을 구성하여 자신을 구성하고 최적화하는 방법을 가장 잘 알고 있어야합니다. 그 대가로 팀은 PO가 고객의 요구를 가장 잘 알고 있다고 신뢰합니다.

이는 새로운 애자일 팀의 일반적인 과제입니다. 팀이 자신의 사일로를 분해하고 성장하기 시작하면 정말 좋습니다.