의존성을 관리하지 말고 제거하라

테스팅 번역 자료들

by techbard 2023. 2. 7. 23:24

by ILLIA Pavlichenko

당신이 큰 조직에서 일한 적이 있다면 아마 "의존성"이라는 단어에 대해 들어봤을 것이다. 나는 의존성을 관리할 것이 아니라 제거해야 한다고 확신한다. 나는 이 기고에서 시스템 다이어그램을 통해 스크럼 팀이 왜 의존성으로 고통받고 있으며 의존성이 어떻게 조직의 민첩성에 영향을 주는지 그리고 이 이슈에 대한 근원적인 해결책은 무엇인지 살필 것이다.

어떻게 해서 의존성이 팀의 발전을 저해하는가

의존성이 높을수록 해당 스프린트의 후반으로 가면서 기능을 완성할 기회가 점점 적어진다. 따라서 백 로그 큐에서 출시까지 (주기 시간) 도달하는데 평균적으로 기능 구현에 더 많은 시간이 들어간다. 결과적으로 조직이 빠르게 잠재 가치를 시장에 내놓지 못하기 때문에 민첩성은 떨어진다. 이것이 조직적인 스트레스의 원인이 된다.

일반적인 경영진은 이런 조직적인 스트레스에 "나누어 공략하는" 방식으로 대응한다. 예를 들어 품질에 문제가 있다면 자신만의 KPI를 가진 별개의 "품질 통제" 조직을 만드는 식이다. 경영진이 새로운 직능, 새로운 유닛, 새로운 컴포넌트 팀을 만들면 조직의 파편화가 가속화된다. 더 많은 파편화가 이루어지면 심지어 더 많은 의존성이 생겨난다.

#의존성 → 기능 구현이 스프린트 후반에 완성됨 → 평균 주기 시간 → 조직적인 스트레스 → "나누어 공략하기" → 조직적인 파편화

높은 평균 주기 시간은 조직을 덜 민첩하게 만든다. 따라서 스크럼 팀은 어떤한 의존성도 가져서는 안 된다!

복합 기능 팀은 (cross-functional team) 그 팀에 속하지 않은 사람에게 의존하지 않고 과업을 수행할 수 있는 모든 역량을 지닌다. 스크럼에서는 이런 팀 모델을 유연성, 창의성 그리고 생산성을 최적화하기 위한 방법으로 사용한다.
- 2017년 스크럼 가이드

왜 의존성이 발생하나?

큰 조직과 함께 일해 온 나의 오랜 경험으로 볼 때 왜 의존성이 창궐하는지에 대한 몇 가지 이유가 있다.

컴포넌트 팀을 ("버스 팀", "분석 팀", "안드로이드 팀", "통합 팀") 바탕으로 한 불완전한 조직 체계. 이것은 강력한 파편화의 원인이 된다.
불완전한 복합 기능 (다수의 기술 부족).
비이성적으로 복잡한 아키텍쳐 구조는 ("우리 조직에는 256가지 시스템이 존재한다") 복합 컴포넌트와 복합 기능 스크럼 팀의 생성을 방해한다.

의존성을 제거하는 방법

의존성 문제는 두 가지 방법으로 해결할 수 있다. 하나는 신속 해결 방식이며 또 다른 하나는 근본적이며 장기간의 해결 방식이다.

신속 해결 방식은 예를 들어 추가적인 조정자 역할을 신설하거나 특별한 기법을 ("보드 위에 줄로 연결") 사용하는 등 의존성을 관리하거나 시각화하는 것이다. 맞다. 이것이 생존하고 계속 움직이는데 도움이 된다. 당신은 의존성을 관리하고 시각화하는 예술가가 된다. 당신의 작업은 이런 식으로 보일 것이다.