프롤로그
새벽에 아주 우연히 열린 디코방에서 협업에 관한 이야기로 시작된 이야기는 스크럼과 스프린트 그리고 애자일에 대한 주제로 각자의 경험과 질답들이 오고 갔습니다. 평소에 생각하고 있는 애자일에 대한 방법에 대해 자연스럽게 이야기를 할 수 있게 되면서 공유해봄직한 좋은 내용들이 많아서 그때의 메모와 기억을 바탕으로 문답식으로 재구성을 해보았습니다.
워딩이나 내용들을 기억에 의존해서 작성을 하고 있기에 그 때의 내용이나 워딩, 순서등을 그대로 옮기기 보다는 협업과 애자일, 그리고 스프린트나 스크럼에 대한 내용들을 더 전달 할 수 있도록 각색했다는 점 양해부탁드립니다.
다 같이 새벽까지 함께 이야기를 나눠주신 많은 분들께 감사의 말을 전합니다.
일단 스프린트와 데일리 스크럼을 무작정 시작했는데...
전에 했던 테오 얘기를 듣고 스프린트과 데일리 스크럼을 무작정 시작을 했는데 다들 열정도 있고 반응도 좋았고 실제로도 많은 효과를 보고 있어요. 하다보면 맞춰진다고 했던대로 진행을 하다보니 저희만의 방법이 생기더라구요.
: 와! 좋네요! 칸반, 스프린트, 스크럼 그런 애자일이라는거 아무리 책으로 봐도 글로만 익혀봐야 모르죠 ㅎ 일단 해보면 말씀하셨던대로 함께 방법을 찾아가게 되는거 같아요!
네~ 그래서 저희 스프린트는 2주단위로 일을 끊고 있어요. 그리고 2주 단위로 회고를 하고 있어요 금요일시작해서 금요일 끝 이런식으로 하고있고 회고는 테오 스프린트에서 배웠던 4LS*를 하고 있어요.
: 회고 잘 지키는 거 너무 좋아요!!! +_+ bbb
4LS 회고: Liked, Learned, Lacked, Longed For
좋았던 점, 알게된 점, 더 잘할 수 있던 점, 앞으로 하면 좋을 것 같은 점 들을 각자 적어보고 얘기해보고 그래서 다음 스프린트에서는 어떻게 하면 좋을지 얘기를 해보는 방식입니다. 회고시간의 여유가 있다면 프로젝트, 팀, 개인 등으로 관점을 나눠서 해보는 것을 추천합니다.
https://www.figma.com/community/file/844263431514235259
그런데 이걸 우리 팀에 맞게 적응해가면서 좋은 점을 많이 발견하고 있는데 이제 본격적이 되어가면서 우리 팀에 맞춰가는 과도기적 시기가 오고 있는 느낌입니다. :)
: 호오~ 흥미롭네요! 어떤 상황인가요?
저희가 스타트업이고 일정이 촉박하다보니 갑자기 핫픽스가 생기거나 이슈 우선순위 조정이 필요한 경우가 많아요. 그래서 기획쪽에서는 핫픽스나 수정사항들을 협업툴에 올리고 카드를 만들고 연결하고 문서화를 하는 과정을 번거로워 하고 방법을 찾는 과정에서 다른 기획자들도 데일리스크럼에 오고 싶어해요.
: 개발뿐만이 아니라 기획이나 다른 직군이 스크럼에 오는 것은 좋은 문화가 퍼져가고 있다는 거 아닌가요?
네, 저희 개발팀이 다들 현재 경력이 다들 어린상태라서 그래서 어떻게 하면 애자일하게 빨리 반영을 하고 새로운 피쳐를 만들고 적용을 할지에 대한 애착이 있고 다들 열정이 엄청 있거든요.
: 오오~ 그러면 좋은거 아닌가요? 어떤 상황이 지금 문제가 되는 걸까요?
우리가 해낼수 있는 양은 정해져있는데 의욕과 요구사항이 발생을 과다하게 받아주게 되는 것 같아서 스프린트에서 다 처리를 하지 못한채로 다음 스프린트로 가게 되고 그러고 있는 것 같아요.
: 그렇군요.
그래서 원래 이번 스프린트때 하려고 했던것들 중 보통 절반정도만 하고 나머지는 다음 스프린트로 미루게 되고 이러한 경험들이 스프린트를 점점 안 좋게 만드는 것 같아요.
: 아! 중요한 지점이네요... 이 부분은 꼭 이야기를 드려야 할 것 같아요.
스프린트가 변질되고 있는 신호
“솔직히 우리가 하는 것은 스크럼이 아닙니다!”
https://yozm.wishket.com/magazine/detail/1474/
테오는 어떤게 문제라고 보세요?
: 보통 애자일이나 스프린트가 망해가는 신호가 일정마감과 열정페이를 요구하는 식으로 그리고 관지라의 편의로 전락되는 도구가 되면서 부터라고 생각해요. 스프린트는 주기마다 목표를 정하고 달리는게 아니라 하면서 주기마다 체크를 하는 개념이거든요. 그런데 이걸 대부분이 착각을 하시더라구요.
스프린트를 2주단위로 한다는 것은 2주마다 목표를 세우는 것이 아니라, 2주마다 한 것을 점검하는 개념이다.
이번 2주동안 이
걸 하겠어!!! ㅇㅋ 목표달성... 아 목표 실패 ㅠ (X)
우리가 2주동안 해봤더니 이~~만큼 할수 있네! 지금까지 한 것들은 고객이 만족하나? 우리는 잘하고 있나? (O)
: 스프린트마다 릴리즈를 하고 방향성을 다시 세워보라는 말이 자칫 모든 일을 그 스프린트에 우겨넣어서 해결하고 배포하라는 것처럼 들릴수도 있겠지만 그렇게 되어서는 절대 안됩니다!
그런데 스프린트때 목표를 안 정할수가 있나요?
: 저는 일정을 미리 예측하는 것은 좋은 개발을 하기 위해서는 크게 도움이 되지 않는다고 생각합니다. 일정예측이 필요없다는 것은 아니지만 미리 예측을 하는게 개발 측면에서는 효과적이지 않다고 말씀드리고 싶어요. 최근 저희방에서 얘기가 나왔던 주제하고도 일맥상통한다고 생각합니다.
우리는 출시하기 위해서 고군분투 하는 시기에요. 그래서 이때까지는 이걸 릴리즈하고 싶다라는 목표가 강해진 시기라서 데드라인을 정하고 싶고 그때까지의 일정을 맞추고 싶어하는 것 같아요. 기획자는 일정을 정하고 싶어 하는데 스프린트에서 이 목표를 세우지 않는다면 어떻게 해야 하는 걸까요?
: 일단 대부분의 기획들은 해보지 않은 것들을 시도합니다. 이미 해봤던 것들을 다시 개발하는 일은 드물기도 하거니와 가치가 높다고 보기 어려우니까요. 개발은 고민하면서 일정예측을 한다고 생각하겠지만 대부분의 근거는 자신감과 추정일뿐입니다. (다들 웃음) 해보지도 않은 일에 대해서 근거를 가지고 일정 산출을 할 수가 없어요.
: 개발자가 입밖으로 내놓은 일정은 개발자에게 목줄이 됩니다. 그때까지 못해내면 책임을 져야할 것 같기 때문에 그 마감일자에 맞춰서 야근을 불사하죠. 개발자들의 책임감은 매우 높으니까요. 하지만 야근은 결국 빚을 내는 행위입니다. 야근을 한 만큼 쉬어줘야 다시 원래 컨디션이 돌아와요
: 상상을 한번 해보자면, 두 가지 과제가 있고 하나를 2일 다른 하나를 3일이 걸릴것으로 예측을 했어요. 3일로 예측했던 일정은 사실 너무 쉬워서 금방 끝냈고 여유를 부려가며 일을 했습니다. 나머지 2일로 봤던 일정은 하다보니 사이드가 너무 많아서 밤을 새가며 무리를 해서 겨우 겨우 일정을 맞췄어요. 따지고 보면 그냥 5일동안 그냥 작업을 했다면 야근을 안 했을일에 일정을 예측하고 그걸 약속하는 바람에 야근을 하는 이상한 결과가 되었습니다.
맞는 말 같아요. 개발자에게 일정을 물어보면 바로 대답하기가 힘든 것 같아요.
: 맞아죠. 하지만 실무에서 이런 일들이 비일비재합니다. PM이 마이크로매니징을 하고 일정을 요구하고 계획을 세우면 세울수록 개발은 더 힘들어져요. 이걸 개발자가 몇번을 경험하다보면 일정을 굉장히 보수적으로 잡게 됩니다. 굳이 일정을 당겨서 말을 해줄 필요가 없는거에요. 일정을 널널하게 잡고 그 전에 끝내면 칭찬을 받는데 일정을 빡빡하게 잡고 못 지키면 잘 못하는 개발자가 되는 거에요.
: 그러니까 어느 순간 기획과 회의에 가서 어떻게든 안된다는 이유를 갖다 대면서 일정을 널널하게 확보해오면 좋은 팀장이고 잘하는 개발자가 되고 된다고 말하면서 일정을 빡빡하게 가져오면 무능한 팀장에 개발못하는 팀장이 되는데 아무리 봐도 이상하죠? 사실은 되도록 만들어주는 개발자가 좋은 개발자일텐데 말이죠...
(책 광고 아닙니다.) 왜 개발자는 안된다고 말할까? 사실 된다고 말하는 개발자가 좋은 개발자이다.
: 얘기가 많이 돌아갔는데 하고 싶은 말은 스프린트때 목표나 Task를 과하게 설정하거나 너무 예측하려고 하면 안된다는 거에요. 이게 실패하는 이유는 일정 예측이라는 것은 기획이나 PM 등 관리측면에서 필요한것이지 실무자들에게 필요한 것이 아니거든요. 그래서 맨날 개발자들이 제일 대답하기 힘들고 듣기 싫은 질문이 "그래서 언제까지 가능하세요???"죠. (다들 웃음)
공감은 되는데 그래도 일정이나 목표를 안 정하고 진행을 할 수는 없지 않나요? 그냥 알아서 하세요 한다고 진행이 되는 것은 아니잖아요.
: 그렇죠. 일단 원칙은 일정을 Top-Down으로 꽃지 않는다. 예측하지 않는다에요. 일단 먼저 만들고 나서 속도를 측정하는 것이 중요합니다. 언제까지 가능하세요? 라는 질문이 아니라 언제면 일정이 예측이 될까요? 이런식으로 질문을 해줘야 하지 않을까 생각을 해요.
: 어차피 일정을 예측하려면 조금은 만들어봐야합니다. 아까도 말했지만 그냥 요구사항만 듣고 내린 일정예측은 아무런 근거가 없어요. 그냥 추정일 뿐입니다. 근거를 대려면 만들어봐야만 할 수 있어요. 일정을 예측을 하기 위해서든 배포를 위해서든 어차피 만들어야 하는 것라면 일정을 예측하는데 따로 시간을 들이지말고 그냥 만들어보고 난 다음 속도를 측정하면 되는 거죠.
일단 작게 다같이 만들어 봐야 한다!
요구사항이 많으면 만들수록 예측은 어려워지고 예측을 많이 할 수록 우리는 예측의 늪에 빠져 더 힘들어집니다. 일단 1주만 혹은 2주짜만 혹은 1달만 어쨌든 미니 핵심 프로젝트를 만들어 본다. 구체적인 완성에 대해서는 목표를 세세하게 정하지말고 목표정도만 설정하고 일단 시작해보는 거에요.
이렇게 다 같이 굴려보고 나면 어느순간 꽤나 예측가능한 일정이 나와요. 이런식으로 PM이 아니라 개발자의 시각에서 언제까지 가능할 것 같아요라는 대답이 나오는게 중요합니다. 그 일정이 틀릴 수도 있겠지만 적어도 훨씬 더 좋은 결과를 가지고 올 수 있습니다.
그러면 기획이나 PM은 일정관리를 어떻게 해야 되나요?
: PM은 일정을 예측하는 것이 아니라 진척도를 파악할 수 있도록 로드맵과 태스크를 잘라주고 목표와 진행도를 체크 해주어야 합니다. 일감을 던져주고 쪼아대는게 아니죠. 그렇지 않더라도 누구보다 개발자가 스스로 이 태스크들을 완성하고 싶어하니까요.
: 앞으로 언제까지까 얼만큼 해주세요가 아니라 지금까지 이만큼 했네요. 지금 속도로 보았을때 남은 단순 태스크들을 계산해보면 이정도쯤이면 마감을 할 수 있을 것 같네요. 필요한 시기가 좀 차이가 나니까 조율할 수 있는 방법을 찾아봅시다. 미묘하지만 조금 다르게 현재까지 한것을 중심으로 얘기를 해줘야 하는거에요.
: PM은 언제까지를 얘기하지 말고 태스크의 목표와 개수를 말하면서 헬스트레이너처럼 너무 잘했어요! 하나만 더~~ 하나만 더!! 이런식으로 조련(?)을 해야합니다. 일정을 먼저 들이밀면 절대로 좋은 결과가 나오지 않아요.
그러면 데드라인이라는게 의미가 없는걸까요? 하지만 실전에서 데드라인이 없을수가 없잖아요.
: 그렇죠. ㅋㅋㅋ 당연히 회사니까 데드라인은 정해져있죠. 그래서 더더욱 작게 만들어야 되요. 그리고 언제든 출시를 할 수 있도록 지금 보고 있는 그림에서처럼 큰 그림을 바탕으로 조금씩 발전을 하되 언제든 출시가 가능하도록 하기는 해야 되요.
: 일단 만들어 가면서 3의 시기에서도 출시는 할 수 있도록 해놓을 수 있어야죠. 어쨋든 판단은 위의 몫일테고 실무자들은 힘들지 않을 수 있어요. 그게 아니라 위 방식처럼 했는데 3의 시기에 릴리즈를 해야한다면 야근의 숙명을 피할수가 없겠죠.
그러면 매 스프린트마다 QA를 하시나요?
: 저도 고민이긴 한데 저희는 QA조직이 분리되어 있어요. 저희가 QA시기를 예측해서 요청해야하는 방식이다보니 결국 일정 예측을 해야해서 리소스를 확보해야 하는 방식입니다. 제가 이상적으로 주절주절했지만 현실은 이런법이죠ㅎ 결국 QA일자를 찍기 위해서는 마감날짜를 스스로 정해야하는 문제가 있지만 그 날짜를 만들어내는 과정은 자율적인 판단을 가지고 할 수도 있고 해당하는 날짜가 왔을때에서도 지금까지 한것들을 바탕으로 진행 할 수는 있는 것 같아요. 이상은 이상이고 현실은 현실이니 이상론을 가지고 현실에 타협하는게 애자일 아니겠어요? ㅎ
그러면 QA 일정이나 예측은 들어 맞는 편인가요?
: 몇번은 그랬고 몇번은 안 그랬어요. QA는 사실 예측이 불가능하다고 보시면 될 것 같아요. 어디서 사이드가 튀어나고 문제가 터질지는 모르니까요ㅋ 그래도 이 때는 각오하고 하는 크런치모드이고 다같이 릴리즈를 바라보면서 해보자! 라고 하는 시기라고 끝나면 배포와 휴식과 회식을 기대하며 달려야죠!! 이런거 한번쯤은 있어야 '아... 배포했구나!!!' 하는 짜릿함(?)도 생기는거 같아요. ㅋㅋ
: 그래도 이런 기간이 1달은 안넘어야 될 것 같아요. 안그러면 정신적으로 너무 지치고 힘들더라구요. 이번 달은 죽었다 생각하고 해보자 해서 1~2주까지는 의욕 뿜뿜하고 하는데 3주부터는 지켜가고 그래서 오기로 버티지만 확실히 힘들긴 하더라구요.
그렇게 만들어 봐도 이거는 오래걸리겠다 예상은 하지만 그 예상이 안 먹히는 경우에는 어떻게 하나요? 개발 태스크 예상이 오래 걸리지 않나요?
: FE의 경우 태스크는 사용자 행동을 중심으로 작성을 하고 있어요. given - when - then을 따라서 이런 상황에서 이렇게 하면 이렇게 된다. 이정도로요 기획서를 태스크로 옮기는 수준이기 때문에 태스크 자체는 엄청 세부화해서 쪼개지게 되구요. 그 쯤되면 태스크 1개를 구현하는 시간은 누가 특별히 오래 더 걸리고 이런것들은 별로 없이 비슷비슷해지는거 같아요.
: 대신 지연이 될 만한 것들은 미리 골라서 전달을 해야 된다고 생각해요. 크게 2가지 인데 하나는 기술 검토가 필요한 것 혹은 외부에서 해결을 해줘야 하는 것들 이런 것들에 대해서는 시간 조정이 필요하고 조율이 필요한것 같아요. 이러한 커뮤니케이션 교통정리를 잘 하는것이 또 PM이 해줘야 하는 역할인 것 같아요.
이후 이어진 질문과 답변 시간
Q. 그러면 실제로 데일리 스크럼을 어떻게 진행하시나요?
: FE파트와 프로젝트의 스크럼양상이 달라요 주로 파트 스크럼은 공유나 공감 수다 친목에 가깝고 프로젝트 스크럼이 조금 더 일적으로 얘기를 하게 되는거 같아요. 파트에서 차출해서 프로젝트로 결성되는 방식이다 보니까요.
파트
- 기본적인 지금 뭐했고 뭐하고 있고 뭐할거라는 얘기들을 합니다. 환기성으로 각자 할 일을 상기하면 좋은 것 같아요.
- 뭐했고 뭐할거고.. 요새 어때요??? 거의 친목용! 각자 하는 거 공유하고 나면 이후 친목으로 1시간가량 떠들고 놉니다.
- 한풀이용도 있는거 같아요. 요새 좀 바쁘다 일이 몰린다 등. 으쌰으쌰... 바쁘거나 회의가 있으면 알아서 헤어져요.
- 새로운 기술 나왔더라!! 써봤어요?? ㅋㅋ 어때요?
- 우리 세미나 할까요? 스터디 해볼까요? 회식 어디로 갈까요? 이런 이야기들...
프로젝트는 사실 팀바팀인데 저희가 하고 있는 방식은 기획에서 과제산정을 해서 들고오면 뉴 피쳐 킥오프를 합니다. 그러면 다같이 스프린트 방식으로 한번 만들어보고 아이디어나 디자인이나 기술검토 같은 것을 해봅니다. 그리고 나서 기획, UX는 이제 전체 태스크를 쭉 펼쳐가면서 정리하면서 그 양을 보고 대략 일정을 가늠해봅니다. 디자인은 각 화면별로 디자인이 끝나면 실제 디자인으로 교체를 해주고 개발은 태스크를 개발하면서 진행도를 체크하고 있어요.
프로젝트
(기획 - UX - 디자인 - 마크업 - FE - BE - QA 다 들어옵니다. 데일리 1시간)
-
뉴피쳐 킥오프
- 구글스프린트를 따라서 MAP -> 스케치 -> 결정 -> 개발 -> 테스트
- 기술검토 확인하고 일정 검토하고 디자인 컨셉잡고 개발 공수잡고
- 대략적인 일정을 추측해본다. (기획과 개발이... )
-
본격적인 개발
- 기획, UX는 태스크 지도를 만들기 시작합니다.
- 디자인은 만들어서 지도에서 이미지만 교체해줍니다.
- 개발 - 마크업도 각자 일하는데 매일 매일 각자 진행사항 브리핑을 하고 애로사항 확인합니다.
- 매주 금요일 쯤에 다 같이 데모 + 회고 (중요!)
-
QA
- 이슈는 모두가 참여하고 버그 발견되면 일단 무조건 JIRA (깃헙 이슈)
- 데일리스크럼에서는 QA가 먼저 버그리포팅을 다시 해준다.
- 너무 많으면 개발에서 이해안가는 이슈들 요청한다.
- 기획은 계속 우선순위를 조정한다. (말 가리개 같은건데... 이슈개수 10개 넘어가면.. 하기 싫어져요...ㅋㅋㅋ)
- 그래서 우선순위 리벨런싱을 해서 집중할수 있게 해주는거... Highest High Mediaum Low
- 7개 넘어가면... 사람이 잘 대응력이 사라진다고 해야하나?? 칸반 WIP 참조
- 내가 가지고 있는 이슈를 6개 이상 가지지 마라.
- 기획은 말없이 일정 예측만 계속 하는 것... 위로 가서 보고하고 몸빵하고. ㅋㅋㅋ
-
끝나면... 회식하고 회고하고 좀 쉬면서 슬슬 다음 피쳐로 넘어갑니다. 쉬는 동안 리팩토링도 필요하면 좀 하구요.
Q. 기획이랑 디자인과 개발이랑 동시에 진행이 되는건가요?
: 주단위로 보면 그렇긴 한데 각자가 집중하는 시간대가 달라요. 구글스프린트를 따라서 MAP -> 스케치 -> 결정 -> 개발 -> 테스트 순으로 이어지면 주로 기유가 월화수, 디자인은 화수목, 개발은 수목금 이런식으로 집중하게 되는 것 같아요.
: 하다보면 중간에 공휴일이 있는 날도 있고 휴가도 있어서 꼭 1주일에 맞추지 못하는 경우도 생기기는 하는데 적당히 큰 틀에서 맞춰가되 매듭을 지으면서 가려고 하는게 제일 중요한거 같아요. 일단 만들어진 것들을 통해서 다같이 한번 검증을 해보고 가는 거요.
Q. 구글스프린트는 아이디어를 실험해보는게 목적이잖아요. 이걸 실제 실무에서 스프린트를 하는거랑은 다른것 같은데 이걸 통해서 어떤것을 얻고자 하는 건가요? 프로토타입을 만드는게 목적인가요?
: 딱 잘라 말하기는 어려운데 말씀하신 것처럼 구글 스프린트의 아이데이션과 데모에만 있는 것은 아니구요. 8시간 전부 여기에만 몰아넣고 아이디어를 찾아내는 활동보다는 조금더 가볍게 여러번 굴리면 되구요 프로토타입도 있겠지만 조금 다른 거 같아요. 프로젝트를 하다보면 직군별로 열심히 하는 것과 잘하는 것과 얻고자하는 이해관계가 참 다르거든요. 그걸 적절히 서로가 원하는 방향으로 시도해볼 수 있다는게 큰 거 같아요. 예를 들어보면,
기획자:
이~~~~~~~~~~~~~~~만큼 아이디어와 문서를 다 그려와서는...
"이거 언제까지 얼만큼 가능해요? +_+"
기획이 힘들어하는 것은 엄청 고민해서 만들어 갔는데 개발자가.
개발자: "이거 그렇게 구현이 안되는 건데요"
디자인:
그릴땐 몰랐는데 구현된 걸로 보니까...'아.. 생각보다 별로네? 어떻하지?'
: 기획자는 일정을 원하고 개발자와 디자인을 뭘 만들어야 하는지 이해도 필요하지만 이걸 왜 만들어야 하는지 얼도당토 않은 건지 정말 만들고 싶은건지 그리고 내가 만든 서비스에 대해서도 어느정도는 관여를 하길 바랍니다. 예쁜 디자인과 잘 만든 기능도 기획에서 가치가 없으면 만들 가치가 없는 기능이니까요.
: 그래서 기획이 오히려 열심히 많이 만들어올수록 자세히 만들어올수록 디자인과 개발에서는 더 봐야할 것도 많고 이의를 제기할 것도 많아지고 그게 아니더라도 그냥 코딩해주는 기계 취급을 받는게 싫어집니다. 디자인도 마찬가지구요.
: 그러니까 미리 너무 많이 기획해서 리뷰 받지말고, 일정 산정에 어려움 겪지 말고 다같이 고민하면서 진행을 하다보면 자동으로 다같이 기획에 참여를 하면서 컨텍스트도 공유를 하면서 리뷰도 되면서 일정 산출을 하면서도 조금씩 개발도 같이 되고 있는 모두가 해피한 형태로 갈 수 있기 때문에 이렇게 하려고 하는거에요.
Q. 태스크는 어떤식으로 작성하고 관리하나요?
: 이것은 전에 블로그에도 한번 쓴 적이 있어서 여기 를 참고 해보시면 될 것 같아요.
: 짧게 따로 설명을 드리자면 초반에 스프린트를 통해서 만드어진 프로토타입등을 바탕으로 일단 생각하기 쉽게 화면(screen)을 먼저 다 그려봅니다. 그리고 각 화면에서 할 수 있는 사용자의 행동(when)을 모두 추려냅니다. 그리고 행동을 전후로 바뀌는 결과에 대해서 작성을 하구요(then) 그리고 같은 행동에 대해서 다른 결과가 나올 수 있는 경우를 모두 찾아내서 조건(given)으로 추려내어서 하나의 스토리를 각각 태스크로 분리하게 됩니다.
: 시행착오를 겪어가며 해본 방식들인데 기존 기획서보다는 조금 더 개발자 친화적인 형태가 좀 생소할수도 있겠지만 뭘 개발을 해야할지 분명하게 해주고 개발 진척도 파악에 용이해서 이런 방법을 쓰고 있어요.
: 이후 QA에서는 JIRA를 통해서 Task 관리를 하고 있습니다. 버그나 이슈 관리는 JIRA가 아니면 Github을 이용하는 것도 좋은 거 같아요. (개인적으로 JIRA를 선호하지는 않거든요. ㅎ)
Q. 플래닝 포커는 어떤가요? 애자일책에서 보면 스토리 포인트로 산정하고 하는 방식들이 있던데요 그런것을 하시나요?
: 아주 주관적인 발언이라는거 미리 얘기드립니다. 저는 개인적으로 플래닝 포커를 선호하지는 않습니다. 결국 하다보면 성급한 일정 예측의 늪으로 빠진다고 생각해요. 대신 같은 파트?? 아니 개발자들끼리 해 보는 것은 의미가 있다고 생각합니다. 일정이 애매할때에는 집단지성을 모아보고 일정 예측에 대해서 이야기를 해보면 생각지도 못한 부분들을 서로 공유할 수 있게 되어 좋은 것 같아요. 스프린트하고는 살짝 안 맞는 느낌이라서 기획하고는 하지 마세요. ㅎ
Q. 스프린트를 못지키면 어떻게 피드백을 하나요?
: 아니에요. ㅠㅠ 못 지키면이라는 발상부터 잘못되었다라고 생각합니다. 스프린트가 끝나고 하는 회고라는 잘된점과 그렇지 않은 점에 대해서 스스로 검증할 수 있는 프로세스가 있으니까 굳이 별도의 피드백의 형태는 필요가 없는 것 같아요. 스스로 생각해서 좋은점과 해야할 것들을 적어보면 다 성장을 한다고 생각을 합니다. 이걸 피드백을 굳이 해버리면 자기방어로 인해서 변명을 하려고 하게 되어서 오히려 역효과라고 생각합니다.
: 그리고 못 지키면이라는 워딩에서 벌써 스프린트의 목표치를 정하는 우를 범하고 있다고 생각해요. 다시 강조하지며 스프린트는 목적을 위해 단기간에 그걸 이루기 위해서 뛰는 것이 아니라 일단 달려보고 나서 정해진 시간이 되면 지금까지 한 것을 체크하고 점검하고 다시 뛰고 이렇게 하는거라고 생각해주세요.
Q. 스크럼 단계에서 일정 산출이나 프로젝트를 진행하기 위해서는 기능 정의를 다 해야할텐데 이걸 하지 말라고 하는 걸로 들려서 헷갈려요.
저는 스프린트 자체를 잘못 이해하고 있는 것 같은데 아까 알려주신 변질된 스프린트에 대한 글을 읽어 보고 있는데 스프린트는 제품의 가치를 정하는 회의이다 라는 식으로 얘기하는 것 같아요. 그래서 스프린트에서 기능 얘기가 나오고 있으면 잘못된 스크럼이다 라고 글에 적혀져 있어요.
테오가 얘기하는 것은 다 같이 모여서 빠르게 제품을 만들고 그 제품을 또 다시 그걸 가지고 얘기하고 그걸 가지고 구상이 나오면 개발을 시작하는 것이라고 이해를 했어요. 그래서 좀 헷갈리는 것 같아요. 이제 빠르게 프로토타입을 만드려면 기능 얘기를 할거잖아요. 그걸 보면서 프로토타입 얘기를 하면서 또 다른 기능이 필요하다고 얘기를 하게 될것 같아요. 그런데 만들어야할 기능과 목표를 얘기하는게 잘 못된 거라고 하니까 너무 헷갈리네요.
: 충분히 무슨 말인지 공감이 됩니다. 그게 잘 되었다면 애자일무용론부터 시작해서 갖가지 애자일에 대한 오해라던가 무수한 책이나 글들이 나오지 않았을거에요. 잘되고 있는 스프린트와 그렇지 않은 스프린트는 한끗차이인것 같아요. 당연히 기능 정의를 안 할 리 없고 만들어야 할 기능을 추려내고 목표를 정해보고 만들어 내는 것을 안 할지 없지요.
: 스프린트에서는 우리가 무엇을 목표로 할지 정하고 고민하고 또 방법을 찾아내고 만들어가는 것인데 변질된 스프린트는 오로지 무엇을 개발해야할지 기능 정의만 존재하고 있는 형태입니다. 본질적으로 요구사항과 목표만 있는 상태에서 일정이나 방법론만 바꾼다고 해서 애자일하다거나 할 수 없다고 생각해요.
: 문장이 아니라 현실을 비추어 생각해보았을때 대부분의 경우가 변질된 스프린트에 더 가깝다는 것을 기억하면 이해하기 쉬울거라고 생각합니다. 스프린트가 더 이상론에 가까우니까요. 우리는 대부분 언제까지 무엇을 해야할지로 싸우고 고민하고 계획하고 힘들어 하고 있죠.
Q. 그러면 일정이나 데드라인에 대해서는 말하면 안되는 건가요? 스프린트를 시작하면 윗사람이 일정을 안 물어볼수가 없을 것 같은데요. 룰로 정해야 하나요?
: 데드라인을 회사에 있으면 모를 수가 없죠. 회사의 로드맵이라는게 있는데 예를 들어 사실 모두가 그 일을 7월까지 해야하는 거 다 알고 있죠. ㅋㅋ 그걸 말하지 않는다는 것은 말도 안되고 지나친 비약같은거라고 생각해요.
: 우리가 경계해야하는 것은 역산해가며 가능여부를 따지면서 계속 언제까지 뭘 할 수 있고 그걸 하기 위해서 다음주까지는 이걸 다 해야 해요. 7월 30일날 오픈이니까 6월까지는 뭐가 끝나야 하니까 5월 15일까지는 이 일이 전부 다 되야 하고 이런 계획이나 로드맵 일정을 세우는 것은 오히려 PM의 역할이자 업무라고 생각합니다.
: 다만 그러니까 "다음주까지 이 Task 10개를 마무리 하는 것이 이번주의 목표입니다." 라고 말하면서 매주 목표치를 맞춰 갈 수 있길 바라는식으로 진행을 하는 것을 스프린트라고 하면 안된다는 거에요. 매주 마감이 있는 상태로 흘러간다면 지칠 뿐입니다.
: 오히려 정해진 오픈날을 목표로 다같이 달려가면서 스프린트 주기마다 진행도를 체크하고 점검하면서 '우리는 언제든지 배포할 수 있는 서비스를 작게 유지하다가... 7월말이 되면 그때까지 한 것을 그때 보여줄게. 다 못할 수도 있는데 그래도 배포는 가능하니까 안되면 그건 8월에 배포하면 되지' 이런 형태가 되어야 한다는 거에요.
Q. 테오가 생각하는 스프린트의 큰 장점과 단점은 어떤게 있을까요?
또는 스프린트가 좋았는데 결과물이 안 좋았다. 스프린트가 안 좋았는데 결과물이 좋다. 이런 경우가 있을 수 있을까요?
: 스프린트가 좋았는데 결과물이 안좋을 수는 없다고 생각합니다. 그건 알고봤더니 시간이 더 필요한 과제였던것이고 스프린트를 했기 때문에 더 빨리 확실하게 접어야할 프로젝트임을 알게 해주게 하는것도 스프린트의 성과라고 생각합니다.
: 스프린트의 가장 장점은 중간 데모가 주는 힘이 크다고 생각해요. 일단 뭐든 만든걸 보여주면 모두가 어떻게 개선해야할지 상상하게 되더라구요. 그러면서 더 나은 결과물과 방향을 찾아갈수도 있고 진척도를 눈으로 챙겨 볼 수 있다는게 장점이죠. 그리고 무엇보다 뭐니 뭐니 해도 재밌어요!! 재미!!!!!!! 재미가 제일 큰 장점이라고 생각합니다.
: 단점은... 빡세요! 워라벨 갖다 버려야 할때도 있고 하루하루가 마감이다보니 오히려 3개월치로 일정 잡아둘때가 더 편했지 하면서 농담삼아 말하는 사람도 있었습니다. 그리고 팀빨이나 사람빨을 많이 탑니다. 그래서 팀구성이 중요하고 의지가 많이 필요하다고 생각해요. 변질된 방식으로 진화하던 과거로 회귀하기가 너무 쉬워서 계속 의지를 가지고 해야합니다.
: 그리고 모든 과제가 스프린트로 해결되는 것은 아니기에 무조건 스프린트 최고! 이런게 아니다 이런 것도 단점이라고 하기는 그렇지만 언급해봅니다.
끝으로...
평소 관심을 가지고 있던 스프린트에 대한 이야기를 하게 되면서 많은 이야기를 나눌 수 있어서 좋았습니다. 일단 스프린트와 데일리 스크럼 그리고 회고를 도입하는 것은 애자일하게 일 할 수 있는 가장 쉬운 방법이나 당장 효과를 얻을 수 있는 좋은 방법이라고 생각을 합니다. 그리고 실제로 간단한 장치만으로도 도움을 얻기고 했구요.
이러한 방식으로 진행을 하다보면 스프린트가 프로젝트 관리라는 미명하여 쉽게 변질되는 것을 많이 경험하였기에 가벼운 이야기에서 모두가 고민을 한번쯤은 해본 이야기로 이어졌습니다.
스프린트를 도입을 하면서 변질된 스프린트를 겪게 되면 오히려 사람을 더 힘들고 지치게 만드는 방법이라고 경험하게 되는 경우가 있는 것 같습니다. 예전보나 훨씬 더 일정이 짧아지면서 마감의 주기만 당겨졌다고 느낄 뿐이고 많은 개발자들이 이러한 변질된 애자일에 대해서 싫어하곤 합니다.
스프린트는 짧은 시간에 정해진 목표를 쳐내기 위한 방법론이 아닙니다. 그것은 관리를 하는 입장에서 그냥 쉽게 관리를 하기 위해서 언제까지 할 수 있는 지 묻고 맘에 안드는 대답을 하면 일정을 쪼고 목표를 이루기 위한 시간을 관리하려고 하지만 결과적으로 모두에게 성과를 내지 못하게 하는 방법이라고 생각합니다.
어차피 일정 예측은 미리 할 수 없는데다가 일정 예측을 할수록 힘든거라면 일단 다 같이 해보면서 일정을 산출해가면서 필요한 태스크들을 쭉 펼쳐두고 진행도를 체크를 하면서 앞으로의 목표지향 방식이 아니라 얼만큼 했는지 성과위주로 속도를 측정하고 언제든 출시를 할 수 있다는 형태로 조금씩 만들어 간다면 지금보다는 훨씬 더 즐거운 방식으로 협업을 할 수 있을거라고 생각합니다.
3줄 요약
- 일정 예측을 하려고 하면 할수록 힘들어진다. 일정 예측을 하려면 만들어봐야 알 수 있다. 그렇다면 일정 예측을 미리 하려고 하지 말고 일단 만들어보면서 일정 예측을 하자.
- 스프린트는 구현하고자 하는 기능들을 쳐내기 위한 달리기가 아니다. 일정을 예측하지 않고 달려가면서 정해진 주기마다 점검하고 다시 달리기를 하기 위한 것이다.
- 스프린트는 모두가 함께 하는 것이다.
이야기도 글도 길어졌지만 얘기하고 싶은 것들은 간단하게 요약해보았습니다. 결국 협업은 경험이 더 중요하니까 해보지 않고서는 모르는것 같아요. 그래서 덜 시행착오를 겪을 수 있기를 바라며 이 글이 팀에서 스프린트를 도입하고자 할 때 도움이 되었으면 좋겠습니다.
좋은글 입니다. 스프린트를 진행하면서 비슷한 문제에 대해서 고민했습니다.
많은 도움이 되었습니다.