[Convention] 협업 방식 정리(3) 애자일 + 스크럼 + 개발 프로세스 + 리더의 자질

인프라/etc

[Convention] 협업 방식 정리(3) 애자일 + 스크럼 + 개발 프로세스 + 리더의 자질

Razelo 2023. 2. 18. 23:04

신입 개발자로 일할 경우 사내에서 접하게 되는 개발 문화가 있다.

규모에 따라 다를 수 있겠지만 개발자로 일하는 경우 애자일 문화, 스프린트 방식, 코드 리뷰, 개발 프로세스에 대한 회사만의 특유한 문화를 접하게 된다.

그에 대한 간략한 내용을 정리하고자 한다.

스프린트

일일 스크럼 회의
짧게 회의한다. 15분 ~ 20분 정도, 팀원들이 보여서 어디까지 했고 어제 무얼 했으며 오늘 뭘 했고 어떤 점이 문제인지 이야기한다.

스프린트 원칙

스프린트 기간 중에 서비스의 우선 순위를 바꿔선 안된다.
요구 사항이 생기면 진행 중인 스프린트 내에서의 변경을 해서는 안된다.
스프린트도 갑자기 종료될 수 있는데 이때는 어찌할 수 없는 상황에서만 종료되어야 한다.
스프린트는 정해진 시간 안에 끝내고 연속적으로 진행되어야 한다.
스프린트는 2~4주가 적당하다.

애자일이 무조건 좋다고는 할 수 없다. 워터폴이나 애자일이나 필요에 따라서 적재적소에 활용하면 될 뿐이다.
애자일 안에 스크럼이 포함된다.

스크럼이란 비즈니스 요구를 충족시키는데 초점을 맞추기 위해서 작은 목표를 짧은 주기로 점진적이고 경험적으로 지속적으로 개발하는 관리 프레임워크다. 작은 주기 (스프린트)로 개발 및 검토를 하면서 빠르고 효율적으로 진행하는 협업 방법이다.

즉 고객에 대해서 잘 모르기 때문에 빠르게 가설을 세우고 검증해서 개발 및 개선을 하는 방법론이다.

스프린트는 2~4주간 팀이 목표로 정한 일을 하는 것이다. 새로운 스프린트는 이전 스프린트가 끝나자마자 바로 시작해야 한다.

워터폴

워터폴 방법론은 풍부한 사례와 데이터가 있어서 안정성이 높다. 그리고 수직적이기 때문에 단계별 이해가 쉽고 직관적이다. 즉 명쾌하고 순차적이다. 그러나 사실상 이게 순서대로 진행한다는 것이 쉽지만은 않다. 각 단계의 병행이 힘들기 때문이다. 무조건 순서를 지켜야하기 때문이다. 그러니 마찬가지로 사용자 의견도 반영하기 어렵다. 즉 스타트업에는 적합하지 않다는 뜻이다.

애자일

단계적인 계획보다는 일정한 주기로 검토 및 요구사항을 반영하면서 개발하는 방식이다. 그래서 애자일은 소통과 협업, 빠른 대응과 적용이 중요시되어서 스타트업에 적합하다. 기능에 대한 수정이 유연하고 고객의 피드백 수용이 빠르다. 그러나 계속 늘어나는 요구사항과 불확실한 계획이라는 단점도 있다.

스크럼과 애자일이 같은 것이라고 혼동할 수 있다. 애자일은 일련의 원칙이고 스크럼은 작업을 완료하기 위한 프레임워크다.

애자일의 단점

계획이 불확실하다.
팀을 구성하기가 어렵다.
최종 제품이 요구사항과 다를 수 있다.

애자일은 성과 개선을 위한 수단으로 사용해야 한다.

애자일은 공부해서 배울 수 있는게 아니라 몸소 느껴봐야한다.

시간이 난다면 아래 스크럼 가이드를 읽어보는 것도 좋다.
https://scrumguides.org/scrum-guide.html

스프린트 중 하면 좋은 일

우선 순위가 잘 정리되어있어야 한다.
결정이나 계획을 세웠으면 Jira 티켓 등을 활용한다.

스프린트 중 하지 말아야할 일

속도를 과대 평가하지 말자
스프린트에서 완료할 수 없는 작업을 가져오지 말자.
너무 많은 걸 계획하지 말자
팀원들이 방향을 잃을 정도로 빠르게 작업해선 안된다.
위험도가 높은 작업을 수락해선 안된다.

색다른 견해 그리고 리더의 자질

애초에 리더가 좋아야됨
스크럼도 안좋은 부분이 있긴 함
사실 워터폴이나 스크럼이나 어떤 방법이든 핵심은 어떤 리더가 팀을 끌어갈 지에 달려있음.
리더가 팀의 운명을 정함
사실 그런 리더가 있으면 어떤 프로젝트 관리법을 쓰던 간에 성공함
리더를 잘못 뽑으면 훌륭한 스크럼 프로세스라도 망하게 됨
스크럼은 오히려 풀어놓고 자유로운 얘기를 하려는 방임주의라고 볼 수 있음.
본인이 자신의 일을 못 정하고 얼마나 걸릴지에 대한 측정이 어려운 사람이 있음. 물론 성향 차이임. 하지만 그걸 리더가 봐주고 업무를 확실히 지정해줄 수 있는게 사실 제일 좋은 방법임.
모든 리스크, 능력치를 수치화할 수 있는 리더와 그 사람을 따라갈 수 있는 팀원들이 있다면 어딜 가서든 살아남을 수 있음.
리더가 사람을 대하는 점에서는 배울 점이 있음.
인간성이 좋은 리드는 업무 수완이 좋지 못하다고 말하기도 하고 업무 수완이 좋지만 인간미가 좋지 않다고 얘기되는 리더도 있음. 물론 둘 다 잘하는 사람도 존재함.
리더의 가장 기본은 그 리더가 일을 끝마칠 수 있냐임. 그 외는 이후에 그저 리드가 갖추면 좋은 점들 일 뿐임. 그냥 플러스 요인임.
어떤 리드는 나의 월급 루팡을 실현시켜줄 대상이 될 수 도 있음. 사람을 잘 대하지만 업무 효율은 안나오는 경우임. 이 사람은 결국에는 짤리게 되어있음,.
어떤 리드는 업무 수완은 너무 좋은데 인성이 좋지 못해서 팀원들이 떠날 수도 있음. 어차피 극단인 두 케이스이다.
양극단은 되지 말자.

흔히 보이는 잘 나가는 리드는 본인 만의 기준이 있다. 업무수완, 인간관계를 떠나서 기준을 갖고 있어야 한다. 즉 그 기준이 일관성이 되고 사람들은 그 기준을 보고 따라오는 법이다. 개인차에 따라 누구든 그 기준을 갖고 따라오는 법이다.

그래서 거기에 맞는 사람들이 팀원이 되는 거고 서로 맞는 팀이 형성되고 그 조직은 좋은 성과를 낼 수 있다.

잘하는 프로그래머일 수록 스스로의 발전을 절실히 원한다. 그런 조건이 되는 회사일 수록 좋은 사람이 모이는 건 당연하고 어떤 레벨이건 간에 리더가 되고 싶다면 자신만의 기준을 정해야한다. 성격이 괴팍하고 이상하건 간에 기준이 있어야한다.

자기소신, 일관성, 주위에 흔들리지 않음. 이 세가지가 가장 중요한 자질이라고 꼽힌다.

좋은 리더

리더는 Job queue의 개념으로 볼 수도 있다.
팀원들이 쉬지 않고 돌 수 있게끔 일을 잘 나눠줘야 한다.
리더는 일단은 테크 실력이 좋아야 한다.
적어도 당연히 intermediate 정도는 되야 한다.
언제든 할 수 있는 일을 잘 분배해야한다.
팀원이 놀지 않게끔 해줘야한다. 이게 부려먹는 정도로 굴리는 게 아니라 분배의 측면에서 봐야한다.
잘 분배하고 시간 낭비하며 노는 타임이 없게 진행되어야 한다.
누군가를 믿고 따라갈 수 있는 사람들이 있다는 게 진정한 리더이다.
좋은 리더가 있고 그 사람을 따라갈 수 있는 사람들이 있는 조직은 왠만하면 못하는 게 없다.
신뢰하는 리더가 자리를 옮기면 그 팀도 따라가기 마련이다.

개인적인 견해

엄격한 룰을 두고 해야할 필요성을 느끼진 못하겠다. 다만 이러한 팀 철학의 핵심은 결국 서비스와 구성원을 위함이라는 점은 명확하다. 거추장스러웠던 과정을 덜어내고 민첩하게 움직이자는게 핵심이고 그 과정에서 가벼운 미팅 수준으로의 대화가 진행되는 방식이 되어야한다.

매일 간단하게 10~20분 정도 미팅을 가지고 주기가 끝나면 회고를 가지는 것. 짧은 티켓을 구성해서 자신의 작업을 관리하는 것. 굉장히 매력적인 프로세스다. 개인적으로 회고를 통해 좋았던 점, 개선할 점 등등을 논하는게 가장 마음에 들고 계속해서 발전시킬 여지를 만드는게 핵심이라는 생각이 든다.

토스의 이승건 대표님이 나온 영상이 하나 있다.

기업 문화에 대해 이야기하는 내용인데 한번 시간날때 보면 좋은 영상이다.

https://www.youtube.com/watch?v=82W9lBFT0-c