지난번 글에서는 스크럼 팀 내부에서 발생하는 잘못된 습관에 대해 이야기하며, 이는 결국 개발 실패로 이어질 수 있다고 지적했습니다. 이번에는 그 주제를 더욱 깊이 파고들어, 팀 내부의 기능적 프로세스에 초점을 맞추려 합니다.
이러한 프로세스는 팀의 기술적 역량만큼이나 중요합니다. 아무리 숙련된 개발자라도, 완벽을 추구하는 그들의 노력을 방해하는 요소들이 존재할 수 있습니다. 이러한 문제들은 팀원들의 잘못이 아닌, 프로젝트 관리 결정의 책임과, 명확한 목표와 예측 가능한 활동을 통해 팀을 지원하는 데 필요한 적절한 프로세스가 부족해서 발생할 수 있습니다.
특화된 기술을 가진 고도로 분리된 팀
팀 내에 숙련된 개발자들이 있고, 그들이 독립적으로 업무를 수행하며, 약속한 스프린트 목표를 정확히 마감 직전에 완료한다고 가정해 보겠습니다. 이런 이상적인 상황에서도, 팀원 간의 기술적 분리가 지나치게 엄격하면 팀이 백로그 작업들을 따라잡는 데 어려움을 겪을 수 있습니다.
몇 가지 사례
- 팀 내에 오직 한두 명의 DevOps 엔지니어만이 자동화된 파이프라인 변경이나 플랫폼 내부 서비스 관리를 담당하고, 나머지 팀원들은 이러한 작업에 대해 전혀 모르는 경우가 있습니다. 이럴 경우, 개선 회의와 같은 스크럼 행사에서 이러한 주제가 논의될 때, 대부분의 팀원은 참여하지 못하고 회의에 그냥 머무르게 됩니다. 반대로, DevOps 엔지니어는 다른 기능 관련 작업에는 관심을 보이지 않아 회의 시간이 낭비될 수 있습니다.
- 팀 전체를 위한 데이터베이스 전문가가 한 명만 있는 경우를 생각해 봅시다. 이 전문가는 팀이 개발하는 시스템의 데이터 솔루션의 복잡성과 사용량에 따라, 특히 작업 우선순위를 고려할 때, 처리할 수 없는 많은 스토리로 인해 지속적으로 과부하에 시달릴 수 있습니다. 더 심각한 문제는 다른 스토리들도 데이터베이스 관련 작업이 완료될 때까지 기다려야 한다는 점입니다.
- 특정 제품이 주로 백엔드 개발에 집중되어 있고, 프런트엔드 개발자가 단 한 명뿐인 경우도 있습니다. 이 개발자는 때때로 UI 수정이 필요할 때만 참여하게 됩니다. 이 경우, 대부분의 스크럼 행사는 시간 낭비가 될 수 있습니다. 왜냐하면 해당 팀원의 지식이 프런트엔드 영역에만 국한되어 다른 작업은 관련이 없기 때문입니다.
결론
위와 같은 상황은 팀원들이 시간을 낭비하거나, 백로그 작업을 따라가지 못하는 결과를 초래합니다. 특정 기술에만 집중된 팀원들은 다른 팀원이 작업을 시작하는 것을 방해하고, 스프린트 내에서 활용되지 못하는 시간이 증가하여 전체 스크럼 팀의 효율성을 저하시킵니다.
팀 내부에 이러한 개발자들이 있다는 것은 외부에서 보기에는 큰 문제가 없어 보일 수 있습니다. 그러나 실제로는 팀원들이 특정 기술 분야에만 너무 치우쳐서, 다른 작업에 참여할 수 없다는 점이 문제입니다. 즉, 능력이 있고 작업 우선순위도 적합함에도 불구하고, 다른 팀원을 지원할 수 없는 상황이 발생하는 것입니다.
제품 책임자(Product Owner)가 팀을 위한 의미 있는 스프린트 내용을 구성하는 것조차 어려워집니다. 제품 책임자는 각 스토리에서 몇 명의 팀원이 작업할 수 있는지, 얼마나 많은 유사한 스토리가 동시에 스프린트에 제공될 수 있는지 고려해야 합니다. 만약 스토리를 작업할 수 있는 인원이 부족하다면, 팀의 역량은 제한될 수밖에 없습니다.
딜레마 해결
이것은 해결해야 할 딜레마이며, 프로젝트 관리자는 어떤 경로를 선택해야 할지 알고 있어야 합니다. 특히 다음 중 하나를 선택해야 합니다.
- 다양한 분야에서 작업할 수 있는 풀스택 개발자를 많이 보유하지만, 각 분야의 전문가는 아닌 경우입니다. 이 경우, 넓게 작업할 수는 있지만 깊이 있는 전문성을 기대하기 어렵습니다. 빠른 배송이 가능할 수는 있지만 품질 저하를 감수해야 할 수도 있습니다.
- 각 기술 분야에 전문가를 두고, 그들의 한계를 인정하고 더 적합한 작업에 집중하게 하는 방법도 있습니다. 이 경우, 팀원들은 깊이 있는 분석과 훌륭한 결과물을 만들 수 있지만, 작업이 순차적으로 처리되어 배송 시간이 더 오래 걸릴 수 있습니다.
역량 부족한 제품 책임자
엄밀히 말해 이것은 “프로세스 문제”는 아니지만, 견고한 스토리 생성은 팀이 효과적으로 운영되기를 원하는 프로세스의 핵심 요소이므로 함께 논의해야 합니다. 여기서 “역량 부족”이라는 말은 제품 책임자의 지식 수준을 의미하는 것이 아니라, 개발자가 이해하기 쉽고 제품 로드맵과 일치하는 스토리로 팀을 이끌어가는 제품 책임자의 능력을 의미합니다. 이 두 가지 모두 성공적인 스크럼 팀에게 매우 중요합니다.
만약 스토리에 개발자가 목표, 기능적 가치 또는 기술적 요구사항을 명확하게 이해할 수 있는 세부 정보가 부족하면, 다음 두 가지 시나리오 중 하나가 발생할 수 있습니다.
- 개발자는 제품 책임자가 실제로 원했던 것과 다른 것을 만들 가능성이 있습니다. 대부분의 제품 책임자는 스토리의 진행 상황을 세부적으로 추적할 능력이 부족하며, 일이 “마법처럼” 완료될 것이라고 기대하기 때문에 스프린트 중에 이를 파악하기 어렵습니다.
- 개발자는 스토리 작업을 시작하기 전에, 내용을 명확히 하고 반복적으로 논의하는 데 너무 많은 시간을 소비할 수 있습니다. 이 과정에서 추가적인 회의, 반복적인 합의, 그리고 작업을 다음 스프린트 단계로 미루는 상황이 발생합니다. 그 결과, 스토리의 원래 추정치는 더 이상 유효하지 않게 되고, 스프린트 내에서 완료할 수 없게 되며, 다음 스프린트로 이월됩니다. 최악의 경우, 다음 스프린트에서 동일한 문제가 반복될 수 있습니다.
자기 성찰의 시간
인정하기 어려울 수 있지만, 제품 책임자는 스스로를 되돌아보고, 생성된 백로그 스토리를 검토하여 제품 로드맵 비전과 합리적인 연관성이 있는지 확인해야 합니다. 만약 그렇지 않다면, 이것이 가장 먼저 해결해야 할 문제입니다. 때로는 제품 책임자가 팀과 너무 멀리 떨어져 있고, 자신만의 목표에만 집중하고 있음을 인정해야 할 때도 있습니다.
이러한 문제를 해결하기 위해, 팀에 비즈니스 콘텐츠보다는 팀의 상황을 더 잘 이해하는 비즈니스 분석가를 추가하는 것이 고려될 수 있습니다. (이 경우, 이미 제품 책임자가 존재하므로 팀 전체 비용이 증가될 수 있습니다.)
고정된 일정이 없는 테스트 프로세스
스크럼 스프린트 내에서 테스트 활동이 구체적인 일정에 얽매여 있지 않으면 어떻게 될까요?
언뜻 보면, 이것은 애자일/스크럼 팀에 바람직한 것처럼 보일 수 있습니다. 유연성은 항상 환영받으며, 외부적으로도 긍정적으로 들립니다.
하지만 제 경험에 따르면, 이러한 자유로움은 유연성보다는 혼란을 초래할 가능성이 더 큽니다. 그렇다고 해서 개발이 완료된 직후 전용 테스트 단계를 두는 “스프린트 내부 폭포”를 만들어야 한다는 의미는 아닙니다. 그것은 결코 올바른 접근 방식이 아닙니다. 스크럼 테스트 전략과 애자일 테스트 수명 주기에 대한 다른 글에서 이 내용에 대해 자세히 알아보실 수 있습니다.
우리는 여전히 어느 정도의 유연성을 유지하면서, 개발팀과 현재 제공하는 제품의 특성에 가장 적합한 테스트 일정을 선택할 수 있습니다. 그러나 이 선택으로 달성해야 할 두 가지 중요한 목표가 있습니다.
- 테스트 활동 중에 개발이 중단되는 것을 최소화합니다.
- 테스트 활동을 팀 내에서 신뢰할 수 있고 반복 가능한 활동으로 만듭니다. (콘텐츠, 발생 빈도, 예측 가능성 측면에서 모두)
이러한 조건이 충족되면, 팀은 자연스럽게 프로세스에 적응하고, 배송 일정은 계획되지 않은 장기 테스트 활동에 영향을 받지 않을 것입니다.
결국 가장 중요한 것은 안정적이고 예측 가능한 스프린트 배포이며, 이는 다음 주제로 이어집니다.
정의되지 않은 배포 프로세스
이것은 모든 스크럼 팀에게 너무나 명확해 보이지만, 일반적으로 가장 과소평가되는 프로세스 중 하나입니다.
스크럼 팀은 종종 각 스프린트 후에 배포가 있을 것이라고 말하지만, 이는 견고한 프로세스로 뒷받침되지 않습니다. 그 결과, 배포 시점에 많은 혼란스럽고 예측 불가능한 활동들이 발생합니다. 갑자기 모든 사람이 “배포 작업”에 몰두하게 되고, 새로운 스프린트 스토리 개발에 집중할 수 없게 됩니다. 스프린트 지표는 제대로 작동하지 않고, 배포는 제3자의 시각에서 임의적이고 예측할 수 없는 활동처럼 보일 수 있습니다.
사람들은 백로그, 스프린트 콘텐츠, 개발, 테스트에 너무 집중한 나머지, 이 모든 작업이 완료될 때쯤이면 다음 스프린트가 이미 진행 중이고, 이미 시간을 낭비하고 있다는 사실을 간과합니다.
배포하기 좋은 시점 찾기
그렇다면 팀은 정확히 언제 실제 프로덕션 배포를 해야 할까요? 결국 중요한 것은 이것 하나입니다.
그 질문에 대한 대답은 이미 프로세스 내에 있다고 가정하고, 다음과 같은 사항을 고려해야 합니다.
- 팀이 스프린트에서 생산하는 콘텐츠의 복잡성,
- 스프린트 기간,
- 시스템에서 영향을 받는 구성 요소의 수,
- 변경 사항을 사용하고 요청하는 사람들의 수
반복 가능한 배포 프로세스를 설정하고, 이를 따라야 합니다. 프로세스의 정확한 규칙은 유연하게 정의할 수 있지만, 테스트 활동과 마찬가지로 예측 가능하고, 미래의 특정 날짜로 예정된 습관으로 만들어야 합니다.
선택 가능한 옵션
이러한 프로세스의 가능한 형식은 다음과 같습니다.
- 다음 스프린트 동안 현재 스프린트의 기능 테스트를 완료하고, 해당 스프린트가 종료될 때 (테스트가 완료되면) 콘텐츠를 배포하는 방식입니다. 즉, 각 배포에는 마지막 스프린트의 콘텐츠가 아니라 이전 2개 스프린트의 스토리가 포함됩니다.
- 배포 전 마지막 스프린트는 항상 이전 두 스프린트의 콘텐츠를 테스트하는 데 집중합니다.
- 이것은 “테스트 스프린트” 동안 개발이 중단된다는 것을 의미하지 않습니다. 다만 해당 테스트 스프린트에서 개발된 콘텐츠는 다음 배포에 포함되지 않을 뿐입니다.
- 자동화된 테스트 활동이 충분한 경우, 각 스프린트가 끝난 후 배포를 수행하도록 노력할 수 있습니다. 이 경우, 며칠 동안 지정된 담당자가 100% 집중해야 하는 엄격한 프로세스가 필요합니다. 그러나 이 과정은 나머지 개발 팀에 영향을 미치지 않아야 합니다.
- 최종 사용자 관점에서 괜찮다면, 한 달에 한 번 또는 몇 달에 한 번씩 배포를 선택할 수도 있습니다. 이렇게 하면 각 스프린트의 테스트 측면에서 필요한 노력이 증가하지만 (각 배포에 대한 콘텐츠가 많아짐), 반복되는 활동량이 시간이 지남에 따라 줄어들어 팀에 도움이 될 수 있습니다. 결국, 기능이 더 느린 속도로 프로덕션에 제공되더라도, 팀은 배포 사이에 더 많은 새로운 기능을 개발할 수 있습니다.
하지만 이미 여러 번 언급했듯이, 어떤 프로세스를 선택하느냐는 그리 중요하지 않습니다. 팀이 얼마나 잘 그 프로세스를 지키고, 습관으로 만들 수 있는지가 훨씬 더 중요합니다.
배포 관리 프로세스 및 사례에 대한 가이드를 읽어보실 수도 있습니다.