단일 백 로그로 이동하는 여러 스크럼 팀

우리는 현재 작년에 자체 제품 백 로그를 해결하는 5 개의 스크럼 팀을 보유하고 있습니다. 각 팀은 자체 전용 시스템에서 작업하지만 기본 기술은 동일합니다.

단일 백 로그를 수행하는 기능 기반 팀으로 이동하는 것에 대해 많은 토론이있었습니다. 그 이유는 우리의 주요 시스템 중 하나에 상당한 양의 작업이 있으며 올해의 모든 작업을 수행하기에 충분한 용량이 없기 때문입니다. 제가 생각하기에 중요한 또 다른 이유는 포트폴리오의 변화에 ​​신속하게 적응할 수있는 유연성이 뛰어 나기 때문입니다.

단일 백 로그에서 작업하도록 두 팀을 변경하기로 결정했지만 개발자는 다른 시스템에 대한 경험이 없습니다. 우리가하는 일 중 하나는 경험 시스템 개발자를 팀으로 옮기는 기술입니다.

제 질문은 둘 이상의 다른 시스템에 대한 단일 백 로그로 이동 한 경험이 있습니까? 당신의 도전은 무엇입니까? 작동 시키려면 어떻게해야합니까?

단일 백 로그를 사용하여 약 6 개의 프로젝트를 관리합니다. "약"은 프로젝트를 차별화하려는 방법에 따라 다르므로 말합니다.

느슨하게도 5-6 명의 제품 소유자가 있으며 그 중 일부는 하나 이상의 제품을 소유하고 있습니다. 우리는 7 명의 개발자와 시간이있을 때 코딩하는 팀장으로 구성된 소규모 팀이 있습니다. 우리는 프로세스 담당자와 함께 아이디어를 파이프 라인으로 옮기는 몇 명의 복음 전파자가 있습니다. 물론, 몇몇 사람들은 여러 가지 모자를 쓰고 물건을 어지럽히지만 내 대답으로는 무시할 것입니다. 흥미롭게도 공식적인 스크럼 마스터가 없습니다.

백 로그를 함께 병합 할 필요는 없었지만 사용자 측에서 간단한 작업처럼 들립니다.

일을 체계적으로 유지하는 것은 큰 고통이 될 수 있으므로 여기에 고려해야 할 몇 가지 사항이 있습니다.

• 거버넌스가 핵심입니다. 파이에 관리 손가락이있는 사람은 모두 중요한 변경을하기 전에 다른 사람과 통신 해야합니다 . 그리고 / 또는 변경을하는 사람들은 자신의 권한으로 편안해야합니다 (그리고 나쁜 변경을 위해 열을 가할 준비가되어 있어야합니다). 우리의 체인지 메이커는 강력한 경영진 지원을 받고 있으며 영역 주위에 선이 명확하게 그려져 있습니다. 그러나 의심이 들면 변경하기 전에 묻습니다.

• 백 로그 그루밍, 우선 순위 지정 및 시작과 관련하여 더 많은 오버 헤드가있을 수 있습니다. 모든 소유자를 정기적으로 모으기가 어렵 기 때문에 의식으로서의 우선 순위가 가장 큰 문제입니다. 우리는 우선 순위를 협상하거나 우선 순위를 낮추지 않는다는 나쁜 소식을 전하기 위해 여러 가지 중간 단계를 사용합니다.

• 우리의 많은 일은 외부의 헌신에 의해 주도됩니다. 그것은 우리의 결정에서 자율성의 일부를 제거하지만 그것은 사업의 현실입니다. 당신의 개발자들은 그 변화를 알고 있어야합니다. 통제력 상실이 감지되면 깃털이 주름 질 수 있습니다. 우리는 과도하게 커밋하지 않으려 고 노력하며, 스프린트에 들어가기 위해 노력했던 일부 제품 소유자에게 "아니오"라고 말해야했습니다.

• 일반적으로 두 가지 방법을 사용하여 제품 백 로그 항목이 속한 제품에 태그를 지정합니다. 우리는 그루밍과 다른 작업을 더 쉽게하기 때문에 두 가지를 모두 사용합니다.

  1. 제품 이름 또는 속기 버전으로 PBI 제목을 소개합니다.
  2. 전체 제품을 나타내는 별도의 필드가 있으며이 필드도 채워 져야합니다.

• 우리는 교차 훈련에 의식적인 노력을 기울여야하며 모든 사람들이 다양한 영역에서 손을 잡도록해야합니다. 우리는 개발 팀과 관련하여 매우 큰 코드 기반을 가지고 있습니다. 우리가하는 일부 코드는 매우 전문화되어 있습니다. 우리 팀장은 그 점에서 훌륭하고 우리의 헌신 수준을 한 단계 낮추어 교차 훈련으로 인한 비 효율성을 감당할 수 있습니다. 이와 관련하여 강력한 팀장을 확보하는 것이 중요합니다.

• 스프린트 시간 프레임을 유지하기 위해 최선을 다합니다. 신입 팀원과의 복잡한 프로젝트는 약속을 통해 흔치 않은 출혈로 이어집니다. 분기 주변의 프로세스가 실제로 도움이 될 것입니다. 우리의 모든 작업은 지점에 대해 수행 된 다음 트렁크 릴리스로 다시 병합됩니다. 또한 임시 트리거 외에도 야간에 실행되는 빌드 서버가 있습니다. 빌드를 중단 한 개발자는 24 시간 이내에 문제를 알고 해결합니다. 기간. 24 시간 내에 해결하지 못하면 커밋이 롤백되고 선임 개발자가 슬픔을 느끼게됩니다. 그리고 선임 개발자들은 빌드를 유지하는 데 가장 어려움을 겪습니다.

• 코드 연습과 검토가 더욱 중요해졌습니다. 다양한 영역의 변화에 ​​대해 모든 사람에게 최신 정보를 제공합니다.

• 마찬가지로 일일 스탠드 업에는 모든 개발자와 UI 직원이 포함됩니다. 우리는 유익한 협력적인 의사 소통과 너무 많은 사람들의 비 효율성의 가장자리에 있습니다. 그러나 우리는 스탠드 업을 15 분 미만으로 유지하고 측면 토론에서 빠르게 진행할 것입니다. 일반적으로 5-10 분 안에 완료됩니다.

• 속도 또는 전체 커밋 및 번 다운 속도와 같은 메트릭스에 미치는 영향에 대해서는 말할 수 없습니다. 이러한 측면은 우리가 면밀히 따를만큼 충분히 중요하지 않았습니다. YMMV이므로 고려하십시오. 이것은 또한 각 팀이 스토리 포인트에 대해 상당히 유사한 정의를 가지고 있다고 가정합니다. 그렇지 않은 경우 병합 후 초기 추정치를 엉망으로 만듭니다. 또한 이전과 동일한 측정 단위를 사용하지 않기 때문에 기록 비교에 몇 가지 문제가 발생합니다. 쉬운 방법은 메트릭을 "새 팀"으로 선언하고 병합 후에 데이터 수집을 시작하는 것입니다.

• 우리는이 접근법에서 상당한 이점을 보았습니다. 우리는 모든 손이 한 영역에 집중되어 있고 단기간에 많은 변화를 일으킬 수있는 스프린트가있었습니다. 특정 프로젝트에 일반 개발자 수의 두 배를 빠르게 적용 할 수있는 가치를 과소 평가해서는 안됩니다. 그러나 교차 훈련을 미리해야합니다. 또한 테스트주기 나 그루밍 등으로 인해 "아무것도하지 않는"개발자가 없다는 것을 의미합니다. 우리는 항상 해결해야 할 잔고가 있습니다.

• R & D 프로젝트에 시간을 투자하십시오. 그렇지 않으면 균열을 극복하기가 너무 쉬워서 해당 영역에 투자 할 기회를 잃게됩니다.

• 자아가없는 코딩 작업을 실제로 수행하면 해당 영역에 전문가가있을 수 있지만 코드 영역의 소유자는 없습니다. 다른 스타일이 한 영역에 도입되면 타박상 자아의 기회를 막는 것이 중요합니다. 새 코드가 팀 표준을 충족하고 작동하는 한 좋을 것입니다. 전문가가 수행 한 방식이 아니기 때문에 중요하지 않습니다.

• 관련된 팀이 동일한 코딩 규칙과 스타일을 사용하고 있는지 확인하십시오. 통합에 대한 귀하의 시도에 혼란을 초래하는 불일치와 같은 것은 없습니다.

• 회고를 계속 유지하고 그룹으로 유지하십시오. 작동하는 것, 작동하지 않는 것, 다르게 시도해야 할 것에 대한 모든 사람들의 피드백을 얻는 것이 중요합니다. 이를 통해 팀 내에서 동지애를 유도하고 개발 프로세스에 대한 소유권을 부여 할 수 있습니다.

정답은 "팀에게 물어보기"입니다. 이것이 자기 조직화의 원칙으로 작업을 빠르게 수행 할 수 있도록 스스로 구조를 변경할 수 있어야합니다. 팀의 많은 사람들이 외부인보다 더 많은 컨텍스트 지식을 가지고 있으며 가장 좋은 것을 알고 있습니다. 여기에는 제품 소유자도 포함됩니다.

나는 당신이 여기에 와서 옳지 않은 것이 있고 숨겨진 우려를 가지고 있기 때문에 질문을했습니다. 올바른 결정을 내릴 수 있도록 팀과 논의 할 몇 가지 조언을 드리겠습니다.

제품 소유자

백 로그에 대한 제품 소유자는 하나 뿐이며 비즈니스 담당자 또는 비즈니스를 대표하는 사람이어야합니다. IT 관리가되어서는 안됩니다. 큰 백 로그에는 많은 항목이 있으며 여러 팀이 있으면 단일 PO가 처리하기에는 너무 클 수 있습니다. 이러한 이유로 백 로그를 별도로 보관할 수 있습니다.

PO가 여러 개인 경우 팀이 단일 PO 및 백 로그에 대한 스프린트에 전념해야하므로 반드시 여러 백 로그가 필요합니다. 그 이유는 팀이 제품 소유자 우선 순위 간의 충돌을 관리 할 필요가 없기 때문입니다.

제품 개발 및 유지 관리

유지 관리 팀은 여러 가지 작은 개선 사항, 여러 제품에 대한 버그 및 여러 제품 소유자와 협력합니다. 이러한 BAU 팀은 여러 제품 소유자 간의 충돌을 예약하고 관리 할 수 ​​있도록 IT 관리 지원이 필요합니다.

프로젝트 팀은 컨텍스트 전환을 최소화하고 한 번에 하나의 훌륭한 제품을 제공하기 위해 한 번에 하나의 제품에만 집중해야합니다. 상황 전환은 어느 정도의 기술적 부채를 가진 많은 평범한 제품을 제공 할 수 있습니다.

상황 전환

여러 제품 또는 다른 기능을 사용하면 컨텍스트 전환이 발생하여 팀의 생산성이 저하됩니다. PO는 다음 작업을 수행 할 때 어떤 팀에서 어떤 작업을 수행해야하는지에 이것을 고려해야합니다. 전환의 양은 중요하지 않으며 이론적 인 문제가 아니라 실제 상황이며 이로 인해 팀의 생산성이 80 %까지 떨어집니다.

좋은 PO는 그룹 기능 및 작업 유형을 시도하여 팀이 컨텍스트 전환을 줄 이도록하여 성능을 향상시킵니다.

위험

안타깝게도 경영진은 팀에 시간, 돈, 예산 및 비즈니스 압력의 위험을가하려고 시도합니다. 팀은 이에 동의함으로써이를 수락합니다. 개발 전문가는 의사 결정의 사실과 영향을 설명하고 비즈니스 자체의 위험을 감수해야합니다.

예

• 말도 안되는 시간에 동의합니다. 차라리 업무를 제대로 수행하고 비즈니스가 시간 문제를 관리하도록하기 위해 어떤 노력을 기울여야하는지 말하십시오.

• 추정치. 비즈니스는 팀이 복잡성과 불확실성의 세계에서 정확하게 추정 할 것을 기대합니다. 팀은 예상치 못한 문제로 추정치가 초과 될 경우이를 완화하기 위해 무엇을하고 있는지 비즈니스에 문의해야합니다. 팀은 지방을 고려해서는 안되며 대신 사업을해야합니다.

• 기술 부채 팀은 완전히 테스트 된 고품질 코드를 평가하고이를 추정해야합니다. 즉 압력으로 인한 결함 작성을 중지해야합니다. 비즈니스의 품질 저하를 원할 경우 위험을 감수하고 문제가 발생할 때의 위험이 있습니다.

전문 직업 의식

합의 된 품질에 맞는 것을 구축함으로써 전문가가 되십시오. 당면한 사실을 바탕으로 최고의 능력을 예측하십시오. 이러한 사실이 변하면이를 전달하고 추정치를 조정하십시오. 개발 팀으로서 훌륭한 제품을 개발하고 비즈니스 위험을 감수하지 마십시오. 기대를 전달하고 관리합니다.

검사 및 적응

팀은 항상 개선 할 수있는 방법을 모색해야합니다. 팀이 더 나아질 것이라고 생각되면 시도해야합니다. 그런 다음 개선 사항이 있는지 확인하십시오. 마지막으로 그들은 새로운 접근 방식에 적응하고 개선하거나 작동하지 않으면 폐기해야합니다. 개선을 추구하려는 의도는 항상 존재해야합니다.

결론

궁극적으로 백 로그 관리는 PO의 선택입니다. 작업 대기열을 관리하려는 방법은 그들에게 달려 있습니다. 유일한 생각은 모든 팀의 작업 파이프 라인을 건강하고 양호한 상태로 유지해야한다는 것입니다. 따라서 결정하는 것은 PO에 달려 있습니다.

계약

스프린트 계획 세션에서 팀은 명확하고 모호하지 않으며 정렬 된 정리 된 제품 백 로그 항목 목록을 기대해야합니다. PO와 짧은 토론을 통해 팀은 PO가 무엇을 원하는지 정확히 알아야합니다. 무엇을 . 그런 다음 팀은 구축 방법에 중점을 둡니다.

PO가 잘 준비된 계획 회의에 오면 누가 백 로그를 관리하는지 관심을 갖습니다. PO가 스프린트 계획 회의에 준비되지 않은 경우 SM이이를 해결해야하며, 이는 완전히 받아 들일 수없고 팀 문제가 아니기 때문에 잘 보이도록해야합니다.

우리는 최근에 다른 팀의 백 로그를 흡수했습니다. 팀에는 한 명의 멤버 만 있었지만 (많은 팀은 아니지만) 백 로그에는 실제 작업이 있습니다. 우리는 그들의 작업에 익숙하지 않으며 우리의 작업에도 익숙하지 않습니다.

백 로그가 병합 되더라도 모든 사람이 즉시 모든 작업을 수행해야하는 것은 아닙니다. 기대하는 것은 불합리하므로 모든 백 로그에서 모든 것을 즉시 수행 할 수 있다는 것에 대해 너무 걱정하지 마십시오.

대신 두 팀이 이전에 작업했던 것과 정확히 일치하도록 시작하십시오. 유일한 차이점은 모든 것이 동일한 백 로그에 있다는 것입니다.

그런 다음 모든 반복 / 스프린트마다 각 팀의 구성원 중 일부가 다른 백 로그의 스토리에 대해 작업하게합니다. 모든 사람이 익숙하지 않은 항목을 동시에 작업하지 않도록함으로써 서로의 시스템을 학습하는 비용을 분산시킬 수 있습니다 . 시간이 지남에 따라 팀은 점차 서로의 지식을 흡수합니다.

모든 학습을 사전에 수행하면 성능이 크게 저하 될 수 있습니다. 고위 경영진의 직원은 반드시 주목해야하며, 새 팀이 열악한 성과를 보상 할 수 있기를 바라면서 다른 팀의 백 로그를 흡수해야합니다.

귀하 (또는 경영진)가 두 팀에 대해 병합 된 백 로그를 작성하려는 이유는 시스템 중 하나에 대한 백 로그 항목 만 선택하고 두 팀이 모두 작업하게하려는 것이기 때문입니다.

이런 경우에는 익숙하지 않은 시스템에서 작업해야하는 팀의 많은 마찰이 예상됩니다. 팀은 이전에 작업하던 시스템에서 계속 작업하기 위해 모든 빨대 (예 : "홈"시스템과 관련된 작은 백 로그 항목)를 가져갈 것으로 예상합니다. 누가 그들을 비난해야합니까? 당신이 잘하지 않는 일을하는 것은 재미 없다. 그리고 다른 팀이 당신이 잘하지 못하는 것으로 우수하다는 사실은 당신을 더 바보처럼 보이게하기 때문에 악화시킵니다.

따라서이를 성공으로 이끄는 유일한 방법은 두 팀을 분리하여 두 개의 혼합 된 팀으로 구성하는 것입니다. 그래야만 모든 개발자가 (현재) "중요한"시스템에서 빠르게 속도를 높일 수 있습니다.

그렇게하는 것은 그리 좋지 않습니다. 이전 회사는 대기업에서는 다른 사람들이 다른 작업을 수행했기 때문에 단일 제품 단일 팀 모드로 전환했습니다.

프로젝트 간 전환에도 노력이 필요하며, 오버 헤드 개발을 시작할 새로운 사람이 있다면 정말 큰 것입니다. 개발 된 시스템, 다른 저장소 등에 대한 액세스 권한을 가져야합니다.

나는 전문화를 선호하고, 사람들이하는 일을 알고, 필요한 모든 정보를 가지고 있으며, 프로젝트의 함정을 알고 있으며, 사람들은 프로젝트에서 프로젝트로 옮기고 일할 수 있도록 모든 페니를 빨아 들여야한다는 느낌이 들지 않습니다. 그들.

그들이 프로젝트에서 유휴 상태에 있더라도 프로젝트에서 프로젝트로 점프하는 것보다 익숙한 것에서 훨씬 더 생산적입니다.