스크럼 방법에 대한 회의와, FDD 방법론에 대한 고민

스크럼 모델에 대한 고민

요즘 애자일 스크럼 방법론에 대한 회의를 느끼고 있습니다.

가장 널리 사용된다는 스크럼 방법론이고, 예전 몇몇 회사에서도 톡톡히 재미를 봤던 방법론이기 때문에 새로운 팀에 스크럼 방법론을 적용하기 위한 시도를 하고 있습니다.

그런데, 이 스크럼 방법론이 동작하지를 않습니다.

스크럼의 전제 조건인 즉슨, 스크럼팀이 Product(상품/서비스) 단위로 움직인다는 개념을 가지고 있습니다.

즉 특정 기능이나 모듈에 대해서 특정 팀이 계속해서 오너쉽을 가지고 개발을 진행하는 모델로, 이렇게 하면, 상품에 대한 경험이 지속적으로 쌓인다는 장점이 있습니다. 그리고 기획자 (Product Owner : PO)가 팀 내에 있기 때문에 궁극적으로는 각 서비스가 독립적으로 스스로 기획 부터 개발, 테스트까지 같이 될 수 있는 장점이 있습니다.

결과적으로는 팀이 무진장 빨라지고, 타 팀에 대한 의존성이 없이 개발을 나갈 수 있기 때문에 상당히 효율적이기 때문에 많은 개발팀이 택하는 방법론입니다.

그런데 이 방법론에는 몇가지 문제가 있습니다.

일단 서비스나 상품별로 쪼겔 수 있는 만큼의 팀 규모가 되야 하며

각 기획 인원과 개발팀으로 이루어진 팀이 그에 맞는 실력을 가지고 있어야 한다는 전제가 있습니다.

특히나 각 서비스가 서로 의존성을 가지고 있다면 전체 팀의 스피드에 문제가 될 수 있습니다.

간단하게 신문사 서비스가 있다고 가정하져. 시스템은 저작도구, 앱 그리고 웹 등으로 구성되어 있다고 합시다.

이때 어떤 새로운 기능을 넣으려고 하면, 저작도구 팀, 앱팀, 웹팀이 스피드를 같이 맞춰서 나가야 합니다.

근데 한팀의 역량이 안 따라와 주면, 전체 서비스 개발에 진도가 맞지 않게 됩니다.

예전에. 모 회사에서 새로운 서비스를 개발할때가 있었는데, 여러 시스템이 많이 얽혀 있었고, 스크럼 방법론으로 PO 기반의 개발을 하고 있었습니다. 이러다 보니, 중앙에 있는 웹 포탈 시스템이 요건에 대한 부하를 많이 받게 되더군요. 새로운 요건이 들어왔을때, 각 개별 서비스는 그 기능만 개발하면 되지만 반대로 포탈은, 포탈 자체의 개선 이외에 신규 서비스에 대한 기능 개선 요건을 처리해줘야 하기 때문에 어려운 점이 종종 있었습니다. 그나마 상품이 잘 나눠져 있는 상태라서 잘 Working을 했는데, 이번에는 상황이 좀 다른것 같습니다

내부에 시스템 종류는 아직 크게 많지는 않으며, 팀 규모가 스크럼 팀 형태로 운영하기에는 애매한 사이즈이고.

기획이 각 프로덕 기반으로 나오는게 아니라, 기능 기반으로 나오고 있기 때문입니다. (사실 이게 지금은 맞는 모델 같네요.)

그러다 보니, 여러 기능을 한 스프린트에 동시 개발하다 보면, 여러 서비스 컴포넌트들이 동시에 여러 기능에 대한 요건을 여러 기획자로 부터 받게 되서 개발팀이 혼란이 생기는 경우가 있습니다.

예를 들어 이런거져, 앞의 신문사 서비스의 예를 계속해서 이야기 해보면, 네이버 연동 서비스 기능, 로그 수집 기능 추가, 새로운 신문 기사 컨텐츠 타입 추가 라는 기능들이 각각의 기획자로 부터 나왔다고 봅시다. 그런데 각 기능을 정의한 기획자가 각각이다 보니, 스크럼 모델과는, 다르게 PO가 상품 별로 있는 것이 아니기 때문에, 저작도구,앱팀,웹팀과 같은 개발팀이 이 여러가지 요건에 대해서 우선 순위를 정하기가 매우 어려워집니다. 아울러 안 좋은 경우 각 기획자를 개발팀이 코디네이션 해야 하는 문제까지 생길 수 가 있습니다. 결국은 개발팀내의 새로운 PO나 PM이 필요할 수 도 있고, 이런 역할이 없을 경우, 오히려 개발자가 이런 역할을 겸임해야 하기 때문에 오버로드가 생길 수 있게 됩니다. 그렇다고 작은 조직안에서 기능 기획 이외에, 각 상품(서비스)별로 기획자를 넣는 것은 새로운 오버로드가 될 수 있습니다

그러면 어떻게 이 문제를 해결해야 할까?

기능 위주로 개발을 하는 애자일 개발 방법론이 있는데, 이를 FDD (Feature Driven Development)라고 합니다.

이름은 있는데, 그렇게 크게 유행하는 방법론이 아니라서, 덮어 두고 있다가 요즘 들어서 주의 깊게 살펴보고 있습니다.

개발을 상품이나 서비스 단위가 아니라 신규 기능 단위로 하는 개발 방법론입니다.

이 방법론을 선택할 경우에는 각 개발 컴포넌트별 코디네이션이 대단히 중요합니다. 신문사 시스템 예제의 웹/앱,저작도구 와 같은 개발팀이 있을 경우, 하나의 신규 기능을 개발하기 위해서 전체 팀에서 필요한 내용을 중재하기 위한 프로젝트(또는 프로그램 관리자)와 전체 시스템 흐름을 정의할 수 있는 아키텍트의 역할이 필요하게 됩니다.

아울러 개발하고자 하는 피쳐의 크기가 작을때, 동시에 몇개의 피쳐를 더 개발하고자 하면, 각 팀의 개발 속도가 어느정도 맞아야 하느넫 이를 조율하는게 큰 문제로 다가옵니다. 단순하게 각 개발팀의 역량이나 사이즈의 문제가 아니라, 기능에 따라서, 각 팀이 개발해야 하는 개발량이 매번 다를 수 있다는 것입니다. 그러면 어떤 개발팀은 놀고 어떤 개발팀은 항상 바쁜 현상이 발생하게 됩니다.

이를 해결 하려면, 크로스 앤지니어링을 통하여 리소스를 유연하게 운용할 수 있는 방법이 필요하게 됩니다.

즉, 어떤 기능에 대해서 개발할 양이 앱팀이 적고, 웹팀이 많으면, 앱팀의 리소스를 웹팀으로 그 기능을 개발하는 동안만 배치해서 개발을 하고 빠지는 운영 방식이 필요합니다. 이를 위해서는 팀간의 개발 도메인 뿐만 아니라 각 시스템에 대한 이해도가 높아야 하기 때문에 대단히 어려운 방식이지만, 반대로 요즘 같은 풀스택을 기본으로 하는 스타트업에는 적절한 방식이 될수 있습다. 

내지는 서비스별로 개발팀을 나누는 게 아니라 (앱,웹팀, 저작도구 팀), 기술별로 팀을 나눠서 운용을 하고, 각 기능별로 임시 팀을 만들어서 운용하는 방법이 있을 수 있습니다. 예를 들어 안드로이드, 웹 프론트, 백앤드 팀이 있다고 하고 각 팀이 특정 기능을 개발하고자 할 때, 기능을 개발할 인원을 착출해서 개발을 진행하고 끝내는 방식입니다. 이렇게 하려면, 각 팀의 개발 인원이 각 서비스에 대해서 잘 알고 있어야 한다는 전제를 가지고 있습니다. 즉 웹 프론트 앤지니어가 저작도구, 웹을 동시에 건들 수 있어야 합니다. 이 경우, 각 서비스에 대한 도메인 지식 수준이 높아야 하기 때문에 개발자가 여기저기 서비스에 컨택스트 스위칭을 해야 하는 부담이 생기기 때문에 큰 서비스에서는 사용을 하기 어려운 모델이라고 볼 수 있습니다.

팀에 대한 리더쉽을 잃지 않기 위해서 각 기능별로 PM 역할을 하는 사람이 정의되어야 합니다.

또한 각 기술별로 리더쉽을 유지하기 위해서는 앱,웹 등 기술별로 팀장을 둬서 역량 개발이나 일반적인 관리 업무를 수행하고, 개발 업무는 기능별 PM이 관리해야 합니다. 즉 하나의 개발자에 두명의 메니져가 생기는 모델인데 이를 매트릭스 팀 모델이라고 합니다. 

요즘은 개발 프로세스와, 팀 모델링 방법론에 관심이 많습니다. 관심도 가져야 하구요.

대기업 만큼 풍부한 리소스를 쓸 수 없으니, 최적화를 통한 기동성 확보 방법에 대한 고민중인데, 좋은 방법이 없을까요?