How’s your team’s agile?
여러분 팀의 애자일은 안녕하신가요?
다소 자극적으로 들릴수도 있겠지만 길지않은 기간동안(스타트업에서 하루는 다른 일반 회사의 일주일과 같…쿨럭) 애자일 방법을 도입한 스타트업을 다니면서 애자일 방법으로 소프트웨어를 개발하는 방법에 대해 느꼈던 나의 생각을 한마디로 표현한 문장이다. 솔직히 애자일 방법론에 대해서 깊이 있는 지식을 가지고 있지 않고 제대로 알고 있다고 말하기도 어렵다. 그래서 앞으로 말하는 내가 느꼈던 애자일은 잘못 알고 느낀 것일 수도 있다. 몇년 뒤에 내가 적은 이러한 생각들이 달라질 수도 있다. 그래도 지금 내가 진행하고 있는 이 소프트웨어 방법론에 대한 내느낌을 정리해 보면 좋을 것 같아서 이 글을 적어본다.
“애자일”이라는 단어가 신앙처럼 느껴진다.
수많은 테크 기업(?)들의 채용공고를 보면 하나같이 “우리 회사는 애자일 방법론을 도입하고 있어요.” 이다. 지금 다니고 있는 회사 뿐만 아니라 이전에 다닌 회사도 애자일 방법론을 도입해서 개발을 진행했었다. 폭포수 개발 방법에 대한 단점이 부각되면서 애자일 개발 방법이 대두되고 너도나도 도입하는 것은 유행에 민감한(?) IT세계에서 어찌보면 당연한 것이겠지만 분면 애자일 방법론에도 단점은 존재하고 자기 회사와 핏이 맞지 않음에도 불구하고 억지스럽게 애자일 개발방법을 도입하고 있는지는 고민조차 하지 않고 애자일 개발 방법을 맹신하고 있다고 느껴졌다.
애자일이 모든것을 해결해 주지 않는다.
애자일 개발 방법은 쉽게 말해 짧은 주기로 개발하고 짧은 피드백을 받으면서 소프트웨어를 개발 또는 발전시켜 가는 것이라 할 수 있다. 무계획과 고정된 계획으로 개발하는 방법에 대한 단점을 보완하기 위한 것으로 내가 생각해도 아주 이상적인 개발방법이라 생각한다. 애자일 방법은 여러가지가 있는데 내가 경험한 방법은 칸반 방식과 스크럼 방식이다. 두 방식 모두 좋은 장점들을 가지고 있지만 단점들도 분명 가지고 있고 관리자들은 이러한 단점을 어떻게 해결해야 할지 분명 고민해야 한다. 다른 방법들은 솔직히 경험해 보지 않아서 어떤 장단점을 가지고 있는지 모르겠다. 여기서 내가 말하고 싶은 것은 애자일 방법도 분명 단점을 가지고 있으니 모든것을 해결해 주리라 맹신하지 않았으면 한다는 것이다.
잦은 방향성의 변화는 작업자에게 허탈함을 선사한다.
위에서도 얘기했지만 애자일 방법의 핵심은 짧은 주기의 개발과 피드백이다. 그런데 관리자 혹은 기획자들이 이 짧은 주기와 피드백을 이유로 애써 진행했던 기능들을 가볍게 버려버리는 것을 보고 겪었었다. 스타트업이니까 시장에 대한 변화에 민감해야 하는것은 맞고 필요없는 기능이라면 과감하게 버려야 하는 것은 분명 미래를 봤을 때 더 나은 선택일 수 있다. 하지만 이러한 경험이 쌓이고 쌓이다 보면 구성원들의 허탈함은 쌓여만 갈것이고 좋은 소프트웨어를 만들기위한 노력보다는 “어차피 안될 가능성도 있으니 대충 빨리 만들어서 보여주자” 라는 마음으로 기능을 만들어내는 상황까지 올 수도 있다. 애자일하다는 핑계로 자신들의 방향이 변하는 것에 대한 면죄부를 부여하진 말았으면 한다.
어떤 경우에는 폭포수 방법이 나을 수도 있다.
예를 들어 이제 막 창업을 한 신생기업이라고 생각해 보자. 새롭게 출시할 기능에 대한 논의를 깊이 한 후 기능에 대한 정의를 먼저 다 갖춘 후에 그 기능을 1차적으로 완성하는 것을 목표로 달려나가는 것이 조금식 점진적으로 기능을 개발해 나가는 것 보다 나을 수 있다. 고객에 대한 피드백도 어느정도 기능이 있어야 나오는 것이니 말이다.
스크럼와 칸반은 각각의 단점이 존재한다.
위에서도 살짝 얘기했지만 나는 애자일 방법 중 스크럼 방식과 칸반방식으로 개발을 한 경험을 가지고 있다. 이전 회사에서는 개발 프로세스를 칸반으로 하였다가 스크럼으로 바꾼후 다시 칸반으로 바꾸었었고, 현재는 스크럼과 칸반을 혼합한 방식으로 개발하고 있다. 이렇게 진행하면서 느꼈던 단점들을 적어보면 아래와 같다.
스크럼
일정한 주기를 가지고 해당 기간 내에 작업할 백로그를 정의한 후 해당 백로그를 처리하는 방식이다. 눈에 띄는 특징중 하나는 스프린트 기간 내 정해진 백로그 외에는 작업하지 않는 것인데, 인원이 많지 않는 스타트업의 특성 상 TF 조직이 아니고선 유지보수와 이슈에 대응을 하지 않을 수 없다. 그런 경우 이러한 스크럼의 특징을 지키기는 어렵다. 이에 대한 보완으로 스토리포인트를 부여할 때 유지보수 또느 이슈 처리에 대한 포인트를 남겨두고 진행하는 방법이 있다.
칸반
칸반은 보드를 두고 요구사항이 적힌 백로그들을 쌓아놓은 후 작업자들이 작업할 수 있을 때에 백로그의 작업을 진행하는 방식이다. 칸반의 주요 룰은 WIP(Work In Progress)를 제한하고 그 이상 절대 작업을 진행하지 않는 다는 것이다. 한명의 작업자가 하나의 작업을 진행하는 것은 어찌보면 당연하다. 하지만 실무를 하다보면 하나 이상의 작업을 할 수도 있기 때문에 반드시 인원수 만큼의 제한을 하기보다는 조금 넉넉히 제한을 걸어두는 게 좋아 보인다. 칸반방식은 스크럼과 달리 이슈에 대한 대응을 언제든 할 수 있기 때문에 유지보수를 병행하기에 좋은 방법이다. 하지만 관리자는 특정 프로젝트에 대한 작업사항에 대한 가시성을 확보하기 쉽지 않다는 문제가 있다. 이에 대한 보완으로 스크럼방식에서 하는 데일리 스크럼을 하면서 작업자의 진행사항을 체크 또는 독려할 수 있다.
스프린트 후에는 휴식이 필요하다.
운동 선수도 스프린트 후에는 휴식시간을 가진다. 소프트웨어 개발도 마찬가지라 생각한다. 스크럼방식으로 개발을 진행하는 경우 신규 기능 추가에 대한 요구사항을 타이트한 기간동안 채워놓기만 한다면 우리의 소프트웨어의 부채는 날이 갈수록 증가할 것이다. 애자일한 조직이라면 소프트웨어에 대한 부채를 해결하는 책임을 모두 개발자에게 지게해서는 안된다고 생각한다. 구성원 모두가 너 나은 소프트웨어를 위한 노력을 해야 하며 그러기 위해서는 기존 기능에서의 문제점을 해결하거나 조금은 쉬어가는 스프린트 기간을 중간중간 두어서 내실을 다지는 시간을 가져야 한다.
데일리 스크럼은 스프린트를 진행하는데 장애물이 있는지 확인하고 그것을 제거하기 위한 활동이다.
스크럼 방식으로 개발할 때 데일리 스크럼을 통해 매일 구성원들이 스프린트를 진행하는데 장애물이 있지 않는지 확인한다. 하지만 데일리 스크럼이 어느샌가 작업에 대한 보고를 하는 시간으로 변질되는 것을 많이 보았다. 작업 진행을 공유하는 것은 중요하다. 하지만 작업 진행에 대한 보고하는 시간으로 데일리 스크럼이 변질된다면 정작 중요한 장애물이 존재하는 지에 대한 인지를 못할 수도 있으니 조심해야 한다.
데일리 스크럼은 작업자의 진행사항을 체크하고 용도로 사용되기도 한다.
칸반은 작업자가 요구사항을 처리할 수 있을 때 우선순위를 판단해서 알아서 작업하는 방식으로 업무를 처리한다. 그래서 Due Date가 없다. 빨리 처리하면 다음 작업을 빠르게 가져갈 것이고 작업 처리가 늦어지면 그만큼 다음 작업은 늦춰질 것이다. 모든 구성원이 양심에 맞게 작업을 처리해 간다면 문제가 되지 않겠지만 그렇지 않을 수도 있다.(우리의 동료를 믿자.) 스크럼에서 사용하는 데일리 스크럼을 칸반에서 사용하면 작업자의 진행 여부나 우선순위 조정 등 작업자끼리 소통을 통해 작업 내용을 정리할 수 있으며 추가로 작업자의 진행을 독려할 수 있는 부수적인 효과도 누릴 수 있다.
애자일이 잘되려면 구성원들이 도메인에 대한 지식이 풍부해야 한다.
폭포수 개발방법이 실패하는 원인중 하나가 구성원들이 가지는 도메인에 대한 지식의 불일치라고 생각한다. 이해관계자는 기획과 개발에 관심을 두지 않고 요구사항만 얘기하고, 기획자는 개발에 대한 고려없이 요구사항에 대한 기능을 정의하며, 개발자는 도메인에 대한 깊은 이해 없이 요구사항이 정의된 기획서를 보고 개발을 진행한다. 폭포수 개발방법은 피드백이 없기 때문에 긴 시간 개발이 마무리 된 후 이해관계자는 자신이 원하는 기능이 아님을 인지하게 되고 그 프로젝트는 실패를 향해 달려가게 되는 것이다. 나는 앞에서 말한 조건이 그대로라면 애자일 방법도 워터폴 방식과 크게 달라지지 않을 것이라 생각한다. 단지 빠르게 피드백을 받기 때문에 문제 인식을 빨리 할 뿐이지 요구사항이 수정되고 또다시 도메인에 대한 이해가 없이 개발이 진행 된다면 수정요구사항이 수없이 반복될 뿐일 것이다. 애자일 방법을 잘 수행하기 위해서는 모든 구성원이 도메인에 대한 지식과 오너십을 가지고 있어야 하며 그래야 우리의 프로젝트는 성공을 향해 점진적으로 나아갈 것이다.
애자일에서 기획자/관리자의 역할은 무엇인가?
애자일 방법에서 Product Owner라는 직책을 가진 구성원이 존재한다. Project Manager 또는 기획자가 존재하던 조직에 있던 사람들은 PO라는 직책이 생소할 것이다. PO라는 직책은 있었지만 애자일에서 정한 직책에 맞게 역할을 수행하진 않았다. 오히려 PM의 역할에 가까웠던 것 같다. 내가 느끼기에 기획자는 PO의 역할 중 일부분을 가져가지만 동일한 직책은 아니다 라고 느껴졌다.
애자일 방법에서 기획자의 역할은 많이 줄어들거나 필요하지 않다라는 얘기를 들은 적이 있는데 내 생각은 좀 다르다. PO의 역할은 필요로 하고 기획자는 이러한 PO의 역할과 많으 부분에서 닮아 있다. 만약 PO 없이 프로젝트를 진행한다면 아마 구성원들은 힘든 프로젝트를 진행하게 될 것이다.
지금까지 내가 가진 애자일에 대한 생각에 대해 적어보았다. 우리가 현재 도입한 애자일 방법이 만능이 아니라는 얘기가 대부분이다. 그럼 어떻게 하면 좋을까? 사실 어떠한 정답은 없다. 폭포수 방식에 대한 회의감을 느끼고 애자일 방법이 붐을 일으키고 있지만 이 애자일 방법 또한 시간이 지나고 문제점들이 부각되면서 워터폴과 같은 신세를 질수도 있다. 가까운 미래에는 이 방법을 보완한 새로운 방법이 생길 수도 있다. 내가 생각하는 현재의 해결 방법은 조직의 상황에 맞게 적용하자 이다. 이론적으로는 완벽할 수 있다. 하지만 현실은 그렇지 않다. 그럼 이론적으로 이상향을 추구할 것이 아니라 현재 조직의 상황에 맞게 방법을 바꿔보는건 어떨까? 앞으로 이런 문구가 채용사이트에서 많이 보였으면 좋겠다.
우리에게 잘 맞는 개발방법을 가지고 있어요.
[https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EA%B0%9C%EB%B0%9C](https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C){: target=”_blank” }
https://en.wikipedia.org/wiki/Kanban_(development)
[https://ko.wikipedia.org/wiki/%ED%8F%AD%ED%8F%AC%EC%88%98%EB%AA%A8%EB%8D%B8](https://ko.wikipedia.org/wiki/%ED%8F%AD%ED%8F%AC%EC%88%98%EB%AA%A8%EB%8D%B8){: target=”_blank” }