어떻게 folk 기술 팀이 균형을 찾았을까?

오늘은 folk 애자일 소프트웨어 개발을 어떻게 접근하는지 말씀드리겠습니다.

애자일 소프트웨어 개발에 익숙하지 않다면 웹상에 유용한 자료들이 있습니다. folk 리듬과 집중이라는 두 가지 목표를 염두에 두고 로드맵을 구축하기로 결정했습니다.

20~50명의 팀을 이끄는 엔지니어링 매니저들에게 folk 개발 워크플로우와 고객 관계를 원활하게 관리하는 이상적인 솔루션으로 입증되었습니다.

👉🏼 folk 사용해 프로젝트와 이해관계자 알림을 한곳에서 체계적으로 관리하세요

이를 위해 우리는 프로젝트를 관리하는 두 가지 다른 방식을 정의했습니다:  

• A: 주요 기능 출시로 이어지는 3주 주기 반복 작업.
• 다른 모든 프로젝트는 지속적인 개선 흐름에 속합니다.

우리의 의도

9월에 저희 기술 팀 규모가 4배로 증가했습니다(2명에서 8명으로). 여전히 소규모 팀이지만, 프로젝트 관리 시스템을 개선해야 한다는 점을 빠르게 깨달았습니다. 지금까지는 칸반 방식을 활용해 작업 백로그를 관리해 왔습니다. 이는 간단한 해결책이었고 초기에는 잘 작동했습니다. 결국 한 번에 3~4개 이슈를 추적하는 건 그리 어렵지 않습니다. 하지만 팀원이 8명으로 늘어나고(곧 더 늘어날 예정) 이 방식은 더 이상 통하지 않았습니다. 이 경험은 엔지니어링 매니저들이 팀 규모를 20명에서 50명으로 확장할 때 흔히 겪는 문제와 유사합니다. 바로 이 때문에 대규모 개발 팀에서 가시성과 협업을 유지하려면 folk 필수적입니다.

우리가 프로세스가 어떤 모습이어야 할지 고민하기 시작했을 때, 다음과 같은 아이디어가 떠올랐습니다:

• 우리는 최소한 3주마다 한 번씩 큰 프로젝트를 출시하고자 했습니다. 아직 제품을 구축 중인 만큼 핵심 기능 개발과 창출을 지속하는 것이 중요합니다. 2주는 너무 짧고 4주는 너무 길게 느껴져 3주를 목표로 정했습니다.
• 지속적인 개선에 시간을 할애해야 했습니다. 지금까지 구축한 제품은 훌륭하며 자랑스럽지만, 완전히 새로운 것(노코드 CRM)을 만들고 있기 때문에 끊임없이 다듬어져야 합니다.
• 우리는 프로젝트가 끝없이 이어져서는 안 된다고 결정했습니다. 확실한 마감일이 필요했습니다.

그 목표들을 혼합하는 것은 쉽지 않았다:

• 개선 작업은 범위 기반으로 진행됩니다. 무언가를 개선하려 할 때, 보통 한 번에 모두 해결하려 합니다. 또한 그 과정에서 다른 문제점들도 발견하게 됩니다. 따라서 마감일을 지키기가 더 어려워집니다.
• 프로젝트는 시간 기반입니다. 하지만 날짜에 집중하면 범위 기반 개선 사항을 추적하기가 더 어려워집니다.

결국 우리는 목표 달성에 있어 리듬과 집중력만큼 중요한 것은 없다고 결론지었다.

리듬은 모두가 계속 나아가도록 하며 프로젝트가 흐트러지지 않게 합니다. 효율성을 유지하고 리듬을 지속할 수 있도록 집중하는 것이 핵심입니다. 이에 따라 우리는 자체적인 애자일 소프트웨어 개발 방식을 마련해야 했습니다. 20~50명의 개발자 팀을 관리하는 스타트업 엔지니어링 매니저에게 folk 이러한 체계적이고 리듬 중심의 개발 방식을 지원하는 프로젝트 추적과 이해관계자 관리의 완벽한 균형을 제공합니다.

👉🏼 folk 사용해 팀과 함께 연락처 기반 알림을 관리하고 3주 주기를 유지하세요

민첩성, 물론 그렇지만...

지금까지 제가 경험한 대부분의 접근 방식은 칸반이나 스크럼이었습니다. 이는 기존 작업 방식에 비해 개선된 느낌이 들었지만, 각각의 약점이 있었습니다: 칸반은 시간 제약이 전혀 없는 반면 스크럼은 시간 제약이 있습니다.

스크럼은 항상 실망과 스트레스의 원천이었습니다. 그 이유는 크게 두 가지입니다:

작업 규모 분류: 추상적 척도로 작업을 측정하면 90%의 경우 잘못된 추정치를 산출합니다. 다행인 점은 추상적 척도를 사용 중이므로 언제든 시스템을 속이고 발을 딛고 일어설 수 있다는 것입니다. 예: "그 작업에 5포인트라고? 말도 안 돼. 13포인트를 의미한 것 같아. 스프린트를 그에 맞게 재검토하자."

계획: 계획이란 특정 기간 내에 추상적인 목표들을 맞추려는 시도일 뿐입니다. 예측하기 매우 어려운 일이지요. 예정된 시점에 끝난 스프린트를 경험한 적이 있는지 의문입니다. 스프린트는 항상 예정보다 일찍 끝나거나—98%의 경우—너무 늦게 끝납니다. 두 경우 모두 좋지 않은데, 이는 스프린트가 제대로 계획되지 않았음을 의미하기 때문입니다.

철의 삼각형을 활용하여 시간과 범위의 제약 조건을 모두 갖춘 시스템을 구축하고자 했습니다. 물론, 매일 새로운 개발자를 채용하지 않기 때문에 자원은 고정된 것으로 간주합니다.

자주 묻는 질문

스크럼과 칸반의 차이점은 무엇인가요?

스크럼은 고정된 기간의 스프린트와 역할 및 의식을 사용하며, 범위는 스프린트별로 계획됩니다. 칸반은 작업 진행량 제한을 적용한 흐름 기반 방식이며 기본적으로 시간 제한이 없습니다. 시간에 얽매인 납품에는 스크럼을, 지속적인 흐름과 신속한 우선순위 설정을 위해서는 칸반을 선택하십시오.

애자일 반복 주기는 얼마나 길어야 할까요?

대부분의 팀은 1~4주를 사용합니다. 기능 규모, 검토 주기, 팀 역량에 맞는 기간을 선택하세요. 3주는 범위와 피드백의 균형을 유지하면서 컨텍스트 전환을 줄여주는 경우가 많습니다. 일관성을 유지하여 안정적인 전달 리듬을 구축하세요.

팀들은 시간 제한 프로젝트와 지속적인 개선을 어떻게 결합할 수 있을까?

분리된 스트림: 주기마다 하나의 주요 기능(시간 제한 적용)을 출시하면서, 소규모 수정 및 사용자 경험 개선 작업에 역량을 집중합니다. 기능 스트림에서는 엄격한 범위 통제를, 개선 스트림에서는 백로그 분류를 통해 일정을 준수합니다.

CRM은 애자일 개발 관리를 어떻게 도울 수 있나요?

CRM은 사용자 및 고객의 연락처, 이해관계자, 피드백을 중앙 집중화합니다. 인사이트를 백로그에 동기화하고, 베타를 세분화하며, 아웃리치를 추적하세요. folk 와 같은 도구는 고객 맥락을 실행과 연결하여 우선순위 설정을 개선합니다.