이전 기사에서 나는 결국 (조만간) 전달 실패로 이어질 스크럼 팀 내부의 잘못 개발된 습관에 대한 논의를 시작했습니다. 이 기사에서는 이 주제를 한 번 더 확장하고 이제 팀 내부의 기능적 프로세스에 초점을 맞추고자 합니다.
그것들은 팀의 기술적 우수성만큼이나 중요합니다. 내부 사람들이 제공하려는 작업에 대해 매우 숙련된 경우에도 완벽을 위한 그들의 노력을 망칠 수 있는 영역이 여전히 있습니다. 그리고 프로젝트 관리 결정의 직접적인 책임과 명확한 의도와 예측 가능한 활동으로 팀을 지원하기 위해 목적에 맞는 프로세스로 팀을 지원하는 능력이 있기 때문에 그들의 잘못이 아닙니다.
목차
고유한 기술을 가진 고도로 분리된 팀
팀에 숙련된 개발자가 있고 완벽하게 독립적이며 약속을 지키고 합의된 스프린트 콘텐츠를 스프린트가 끝나기 직전에 제공할 수 있다고 상상해 보십시오. 이러한 완벽한 시나리오(어쨌든 발생할 가능성이 매우 높음)에서도 팀 구성원 간에 기술이 엄격하게 분리되어 있으면 팀이 (계속 증가하는) 백로그 기능을 따라잡는 데 문제가 발생합니다.
몇 가지 예
- 팀에는 자동화된 파이프라인을 변경하거나 플랫폼 내부의 서비스를 관리할 수 있는 1~2명의 DevOps 엔지니어가 있지만 나머지 팀은 그런 일에 대해 전혀 모릅니다. 그런 다음 개선과 같은 스크럼 의식에서 이러한 이야기를 논의하면 참여하지 않고 회의에 매달리거나 그 반대의 경우도 마찬가지이므로 대부분의 팀이 시간을 낭비하게 될 것입니다. DevOps 개발자는 나머지 기능 중심 이야기에 관심이 없을 것입니다. 회의 시간도 대부분 낭비됩니다.
- 전체 팀을 위한 단일 데이터베이스 전문가가 있습니다. 팀이 개발 중인 시스템의 데이터 솔루션의 복잡성과 사용량에 따라 이 사람은 특히 우선 순위를 고려할 때 곧 완료할 기회가 없는 스토리로 인해 지속적으로 과부하가 걸릴 수 있습니다. 설상가상으로 다른 스토리도 기다려야 합니다. 데이터베이스 스토리에서 제공하는 데이터 소스에 의존하기 때문입니다.
- 특정 제품이 주로 백엔드 개발을 지향하는 경우 경우에 따라 유일한 프런트엔드 개발자가 있습니다(때때로 UI 애플리케이션에도 약간의 변경이 필요하기 때문입니다). 이 경우에도 대부분의 스크럼 행사는 이 팀원의 지식이 프런트 엔드에만 제한되고 다른 것은 중요하지 않기 때문에 시간 낭비입니다.
결론을 내리는 곳
위의 경우에 결과는 사람들이 시간을 낭비하거나 백로그 수요를 따라잡지 못하는 것입니다. 그들은 나머지 팀이 다음 스토리 작업을 시작하는 것을 막고 있거나 스프린트 내에서 활용되지 않는 시간이 너무 많기 때문에 스크럼 팀의 전반적인 효율성을 효과적으로 감소시키고 있습니다.
그러나 팀에는 여전히 이 정도의 개발자가 있습니다. 외부에서 볼 때 팀 내부의 사람들이 특정 기술 세트에 너무 치우쳐서 어떤 이야기를 맡을 수 없다는 것은 눈에 띄지 않습니다. 따라서 그들은 능력이 허락하고 스토리의 우선 순위도 선호하더라도 스토리로 다른 팀원을 도울 수 없습니다.
제품 소유자가 팀을 위해 의미 있는 스프린트 콘텐츠를 구성하는 것조차 어렵습니다. 제품 소유자는 모든 단일 스토리에서 얼마나 많은 사람들이 작업할 수 있는지, 더 많은 유사한 스토리가 동시에 스프린트에 제공되는지를 염두에 두어야 하기 때문입니다. , 실제로 그러한 이야기를 작업할 수 있는 사람들이 있지만 그 이야기로 시작할 기술이 없더라도 궁극적으로 팀의 역량은 넘쳐납니다.
딜레마 해결
해결해야 할 딜레마이며 프로젝트 관리자는 선택할 경로를 알고 있어야 합니다. 특히 다음 중에서 선택합니다.
- 더 넓은 콘텐츠에 대해 작업할 수 있는 많은 풀스택 개발자가 있지만 많은 주제에 대한 전문가는 아닙니다. 그래서 그들은 넓게 갈 수 있지만 깊지는 않습니다. 그러면 배송이 빠르게 진행될 수 있지만 품질이 저하될 수 있습니다.
- 각 기술에 대한 전담 전문가가 있지만 한계를 받아들이고 더 잘 맞는 인쇄 콘텐츠에 더 열심히 노력합니다. 그런 다음 사람들은 깊이 파고들어 훌륭한 이야기를 만들 수 있지만 이야기는 순차적으로 접근해야 하므로 전달하는 데 시간이 더 오래 걸립니다.
약한 제품 소유자
이것은 정의상 반드시 “프로세스 문제”는 아니지만 견고한 스토리의 생성은 팀이 견고하고 개발 팀과 호환되기를 원하는 프로세스로 이해할 수 있기 때문에 그렇게 취급합니다.
내가 의미하는 약함은 사람의 지식 속성을 의미할 필요가 없으며 오히려 개발자가 이해할 수 있고 제품 로드맵 관점에서 명확하게 이해할 수 있는 팀 스토리를 제공하는 제품 소유자의 능력을 의미합니다. 이 두 가지 모두 성공적인 스크럼 팀에 매우 중요합니다.
스토리에 개발자가 목적, 기능적 가치 또는 기술적 기대치를 명확하게 이해할 수 있는 세부 정보가 부족한 경우 기본적으로 두 가지 시나리오가 발생할 수 있습니다.
- 개발자는 제품 소유자가 실제로 원했던 것과 다른 것을 만들 것입니다. 대부분의 제품 소유자는 그러한 세부적인 수준에서 스토리의 진행 상황을 추적할 수 있는 능력이 없었고 대부분의 PO는 그 일이 (마법처럼) 일어날 것이라고 예상하기 때문에 스프린트 자체 중에 파악하기조차 어렵습니다.
- 개발자는 스토리를 만들기 시작하기보다 이야기를 명확히 하고 반복해서 논의하는 데 너무 많은 시간을 할애할 것입니다. 여기에는 많은 추가 통화, 반복적인 동의 및 작업을 후반 스프린트 단계로 연기하는 작업이 포함됩니다. 스토리에 대한 원래 추정치가 더 이상 정확하다고 간주할 수 없고 스토리가 스프린트 내에서 종료될 수 없고 다음 스프린트로 롤링되는 지점에 도달합니다. 최악의 경우 다음 스프린트에서 상황이 반복됩니다.
자기 성찰의 시간
일반적으로 인정하기 어렵지만, 제품 소유자는 반성할 시간을 찾고, 생성된 백로그 스토리를 살펴보고, 이 둘 사이에 여전히 합리적인 연결이 있는지, 즉 로드맵이 있는 경우 제품 로드맵 비전과 최종적으로 비교해야 합니다. 조금도. 그렇지 않다면 그것이 가장 먼저 해결해야 할 일입니다. 때때로 솔루션은 제품 소유자가 팀과 너무 멀리 떨어져 있고 자신의 목표와 너무 멀리 떨어져 있음을 인정하는 것입니다.
이 경우 팀의 제품 소유자 부분이 해결됩니다. 다른 것이 없다면, 비즈니스 콘텐츠보다는 팀의 콘텐츠를 지향하는 견고한 비즈니스 분석가를 팀에 데려오는 것(이 경우 이미 제품 소유자가 있음)은 팀의 총 비용 증가.
고정된 일정이 없는 테스트 프로세스
스크럼 스프린트 내에서 테스트 활동이 구체적인 일정에 빡빡하지 않으면 어떻게 됩니까?
언뜻 보기에 이는 애자일/스크럼 팀에 바람직한 것으로 보일 수 있습니다. 유연성은 언제나 환영하며 외부에서 발표할 때 좋게 들립니다.
내 경험에 따르면 이러한 자유의 결과는 유연성보다 더 많은 혼돈입니다. 이에 대한 솔루션이 개발이 완료된 직후 전용 테스트 단계를 통해 “스프린트 내부 폭포”를 생성해야 한다는 의미는 아닙니다. 이 경우에는 결코 올바른 접근 방식이 아닙니다. 스크럼 테스트 전략 및 애자일 테스트 수명 주기에 대한 내 게시물에서 이에 대한 자세한 내용을 읽을 수 있습니다.
우리는 여전히 약간의 유연성을 허용하고 현재 개발 팀과 팀이 제공하는 제품 속성에 가장 적합해 보이는 테스트 일정을 선택할 수 있습니다. 그러나 이 선택으로 달성해야 하는 두 가지 주요 목표가 있습니다.
이러한 조건이 충족되면 팀은 자연스럽게 피팅 프로세스에 적응하고 납품 일정은 계획되지 않은 장기 테스트 활동의 영향을 받지 않습니다.
결국 가장 중요한 것은 안정적이고 예측 가능한 스프린트 릴리스이며, 이 블로그의 마지막 지점으로 연결됩니다.
정의되지 않은 릴리스 프로세스
이제 이것은 각 스크럼 팀에게 너무나 분명한 것입니다. 그러나 이상하게도 일반적으로 가장 과소평가된 프로세스 중 하나이기도 합니다.
종종 스크럼 팀은 릴리스가 각 스프린트 후에 있을 것이라고 말하지만 견고한 프로세스로 뒷받침되지는 않습니다. 그러면 실제로는 릴리스 시간 동안 많은 혼란스럽고 예측할 수 없는 활동이 발생합니다. 갑자기 모든 사람이 “릴리스 작업”에 몰두하게 되고 아무도 새로운 스프린트 스토리를 계속 개발하는 데 집중할 수 없게 됩니다. 스프린트 메트릭이 꺼져 있고 릴리스는 3인칭(일반적으로 클라이언트)의 관점에서 임의의 예측할 수 없는 활동처럼 보입니다.
사람들은 백로그, 스프린트 콘텐츠, 개발, 테스트에 너무 집중하고 결과를 보여주기 때문에 이 모든 작업이 완료되면 다음 스프린트가 이미 진행 중이며 이미 시간을 낭비하고 있다는 사실을 잊습니다.
출시할 좋은 시간을 찾고
그렇다면 팀은 정확히 언제 프로덕션으로의 실제 릴리스를 수행해야 합니까? 결국 중요한 단 하나의 중요한 것.
그 질문에 대한 대답은 당신이 가지고 있다고 가정할 때 그 과정에 있습니다. 다음에 따라:
- 팀이 스프린트에서 생산하는 콘텐츠의 복잡성,
- 스프린트 지속 시간,
- 시스템에서 영향을 받는 구성 요소 수
- 변경 사항을 사용하고 요청하는 사람의 수,
반복되는 릴리스 프로세스를 설정하고 앞으로 진행해야 합니다. 프로세스의 정확한 규칙은 다시 유연하게 정의할 수 있습니다. 그러나 테스트 활동과 마찬가지로 예측 가능하고 미래의 구체적인 날짜로 예정된 견고한 습관으로 만들면 의지하고 참조할 수 있습니다.
선택할 선택
이러한 프로세스의 가능한 형식은 다음 중 하나일 수 있습니다.
- 다음 스프린트 동안 현재 스프린트의 기능 테스트를 완료하고 해당 스프린트가 끝날 때(테스트가 완료되면) 콘텐츠를 릴리스합니다. 즉, 각 릴리스에는 마지막 스프린트의 콘텐츠가 없지만 이전 2개 스프린트의 스토리가 포함됩니다.
- 릴리스 전 마지막 스프린트는 항상 이전 두 스프린트의 콘텐츠를 테스트하는 데 전념합니다.
- 이것은 “테스트 스프린트” 동안 개발이 중단된다는 것을 의미하지 않습니다. 해당 테스트 스프린트에서 개발된 콘텐츠가 아직 다음 릴리스에 포함되지 않을 것이라고만 말합니다.
- 이미 충분한 자동화된 테스트 활동이 있는 경우 각 스프린트가 끝난 후 릴리스를 수행하도록 노력하십시오. 그렇다면 이것은 헌신적인 사람들이 그 며칠 동안 100% 집중하는 매우 엄격한 과정일 것입니다. 여전히 나머지 개발 팀에 어떤 식으로든 영향을 미치지 않아야 합니다.
- 주로 최종 사용자의 관점에서 괜찮을 경우 한 달에 한 번 또는 N개월에 한 번 릴리스하도록 선택할 수도 있습니다. 이렇게 하면 각 스프린트에 대한 테스트 측면의 노력이 증가합니다(각 릴리스에 대한 콘텐츠가 더 커짐). 그러나 다른 한편으로는 시간이 지남에 따라 반복되는 활동의 양이 줄어드는 것을 의미하며, 이 경우 팀에 이점이 있을 수 있습니다. 결과적으로 기능이 실제로 더 느린 케이던스로 프로덕션에 제공된다는 사실에도 불구하고 팀은 릴리스 사이에 더 많은 새로운 기능을 빌드할 수 있습니다.
그러나 이미 몇 번 언급했듯이 이러한 프로세스 중 어떤 프로세스를 선택할지는 그다지 중요하지 않습니다. 팀이 그 프로세스를 얼마나 잘 고수하고 그것을 힘든 습관으로 만들 것인가가 훨씬 더 중요합니다.
릴리스 관리 프로세스 및 사례에 대한 이 가이드를 읽을 수도 있습니다.