Agile is Dead.
애자일의 본질과 목적은 "프레임워크"라는 미명하에 죽어버렸습니다.
원문
Agile is dead
by Dave Thomas (July 14, 2015)
REVISITED
Dave Thomas는 "Manifesto for Agile Software Development"라는 애자일을 설명할 때 가장 많이 인용되고 사용되는 애자일 소프트웨어 개발 선언문을 함께 작성한 사람 중 한 명입니다.
이 강연에서 Dave Thomas는 초기 시점 이후의 애자일 소프트웨어 개발이라는 컨셉의 변화에 대해 설명하며, IT 업계가 속도감 있는 소프트웨어 개발 방식에 대한 선언문의 가치와 원칙에서 벗어나 지나친 상품화, 프레임워크를 사용하지 않으면 안 된다는 불안을 조장하는 전략, 새로운 용어 및 "멋진" 방법론 및 도구에 더욱 초점을 맞추고 있다는 점을 강조합니다.
"속도감 있게 소프트웨어를 만들기 위해 무엇을 하자!"라는 선언문의 시작이선언문에서 "Agile"은 빠르게 성장하는 이라는 형용사적인 의미로서 사용되었으나, 현재는 해당 단어가 명사로서, 그리고 상업화됨으로써 선언의 가치가 상실되었고, 애자일 관련 제품 및 서비스의 판매에 중점이 두어졌습니다.
"애자일 하게 일하는 방법", "애자일에 대한 10가지 진실" 등의 단어들로 상업화되어 왔죠. 자격증은 물론이구요.그리고 이렇게 Agile Alliance, scrum.org 같은 단체들이 생기고, 컨설팅 등을 통해 제품을 만드는 방식에서 프레임워크를 도입하며 "왜 이렇게 일해야 하는지"에 대한 강조보다는 "요건이 명확해야 개발할 수 있다." "프레임워크를 도입하지 않으면 애자일 하지 않다." "업무를 진행하고 지키기 위해선 반드시 특정한 업무들을 해야 한다."라는 말로 애자일을 공포의 대상으로서 받아들이게 하는 것이 문제를 양산한다고 이야기 합니다.
"우선 취직을 위해서, 그리고 내가 애자일을 할 수 안다라고 하려면 우선 자격증을 따세요."라는 형태로 바뀌는 것이죠그리고, Dave는 "Agile"의 개념은 애자일 방법론에만 국한되지 않으며, 변수에 이름을 짓는 것에서부터 배포를 결정하는 것까지 모든 소프트웨어 개발의 모든 측면에 적용되어야 한다고 강조하고, 단지 정해져 있는 프로시져를 따라가는 것이 애자일한 방법이 아니라고 말합니다.
그럼 뭘 해야 할지 어떻게 아나요?
알 수 없어요! 지금 팀이 어떤 상황에 있고, 목표를 향해서 걸어가면서 무슨 문제를 발견하는지 찾아나가기만 하면 됩니다.최종적으로 Dave는 개인과 팀이 자신들만의 해결책을 적용하고, 전문가의 조언이나 프레임워크가 팀의 업무방식에 잘 적용되지 않을 수 있는 규칙에 대해서는 의존하지 않고, 본인들의 방법을 찾을 용기가 필요하다고 강조합니다.
결과적으로는 "Agile"이라는 것은 작은 단계를 밟고 결과를 평가하고 수정을 통해 빠르게 변화를 수용하고 적응해 나가는 것이다라는 것이죠.
"방법론"에 기대기보단 우리가 어떻게 하는 것이 잘하는 것인지를 솔직하게 이야기하고 개선하는 용기가 가장 필요합니다. "Agile is Dead"라는 영상은 사실, 본질적인 가치를 잃게 된 애자일에 대해 많은 연사들이 같은 타이틀로 다양한 주제로 이야기했었던 내용입니다. (이번에는 단어에 대한 부분이었고, 앨런 홀럽은 Estimation에 대한 주지로 이야기했죠. 이건 다음에 리뷰할게요.)
조직에 "애자일"이라는 이름으로 스크럼 또는 칸반을 회사에 적용하고, 프레임워크를 적용하는 실무자로서 또 종종 폭포수의 형태와 다른 업무방식을 강의를 통해 설명하는 저도 가장 중요한 가치라는 부분을 놓치고 업무를 설명할 때도 많습니다. 그리고 그럴 때마다 "애자일 방법론에서 시키는 대로 했는데 잘못되고, 그래서 애자일은 잘못된 개발 방법이다."라는 잘못된 방향으로 흐를 때도 많죠.
이젠 애자일이라는 단어만 봐도 욕부터 장전하시는 분들도 많죠사실 방법론이 되건 어떤 것이 되건 다 상관없다고 생각합니다. 결국 우리가 일을 잘하기 위해선 이걸 피하는 겁니다.
우리는 너무 바빠서 네모난 바퀴를 동그란 바퀴로 바꿀 시간 같은 건 없어!업무 환경을 개선하거나 만드는 방식을 바꿀 때 항상 마주하는 상황입니다.
"일단 지금은 바쁘니까 예전에 하던 대로 하자."(잘못된 경우를 답습하면서 시스템의 문제만을 지적)
"이것도 좋고 저것도 좋은 거 같으니까 대충 섞자."(근본적인 부분을 알지 못하고 기시적인 느낌으로 진행을 결정, 잘못된다면 어느 부분이 달라서인지 파악이 불가한 행태로 업무를 진행)
"그냥 잘 안된 것 같으니, 원래대로 고수하자"(목표와 결과 달성의 연결점이 없고, 이전 과의 장단점에 대한 분석 없이 관성대로 업무 수행)
이렇게 일하는 대신, 이렇게 해야 한다고 생각합니다.
1. 우리가 잘 못하고 있는 부분에 대한 명확한 분석
2. 이를 잘하기 위해 도입할 수 있는 방안의 마련
3. "변경한 방식이 성공했다."라는 목표의 구체적인 설정
4. 목표한 방식을 수행하고, 성공/실패의 파악
5. 개선할 포인트를 찾고 개선
그리고 이렇게 하기 위해선, 변경점은 최대한 명확하고 작게, 그리고 목표한 부분에 조정은 최대한 적게 하는 것이 중요합니다.
물론 그래서 제가 엄청 잘하냐라고 한다면...
.
.
.
저도 잘 못합니다!
저도 잘 못해요. 저도 잘하고 싶습니다!하지만 가장 중요한 건, Dave 아저씨가 이야기한 것처럼, "우리가 어떤 상황 인지를 파악하고, 작은 과정들을 하나씩 밟아가고, 배운 것을 기반으로 개선해 나가는 자세를 만든다."의 마음가짐을 가지고 사용자들이 원하는 제품을 만들어 나가야 한다는 것이고 이게 진짜 사용자들이 원하는 좋은 제품을 민첩하게 만들어 가는 방식이 아닐까 합니다. Revisited 글 말고, 다음에는 작게 개선하고 목표를 설정하고 회고하는 실제로 진행했던 과정을 한번 공유드릴게요. 앞으로는 적어도 매달 하나 정도의 글을 써보려 합니다! 2024년에는 더 자주 뵙도록 하겠습니다!
