2019-07-02소프트스킬

애자일이 도대체 뭐길래?

이번 포스팅에서는 소프트웨어 개발 방법론 중 하나인 애자일 프로세스(Agile Process), 줄여서 애자일이라고 부르는 그것에 대해서 포스팅하려고 한다. 최근 많은 조직들이 애자일 프로세스를 사용하고 있고, 필자가 다니고 있는 현 직장도 마찬가지로 애자일 프로세스를 도입해서 사용하고 있다.

많은 조직이 애자일을 그냥 단순히 이슈마다 스토리 포인트를 매겨서 얼마나 걸릴 지 산출한다, 1~2주 단위의 스프린트를 돌린다, 매일 아침 데일리 스크럼 회의를 한다 등 표면적인 것들에 집중하고 있다. 필자의 직장도 애자일을 계속 해서 해왔지만 어떤게 진짜 애자일한 업무 방법인가?에 대해서 다들 의문만 가질 뿐 제대로 배워볼 기회가 없었다.

애자일의 본질은 모른 채 그냥 내가 이렇게 몇번 해봤는데 되게 좋았어! 혹은 다른 회사가 이렇게 하면서 좋아졌대! 정도로 시작했으니 잘 굴러갈리가 없었고 매번 빗나가는 에스티메이션과 망가지는 스프린트로 인한 팀원들의 의욕 저하 등 여러가지 문제점이 발생했다. 그래서 필자의 현 직장인 숨고에서는 꽤나 비싼 돈을 들여 애자일 코치를 초빙해서 약 한달간 애자일에 대한 교육을 시행했던 적이 있다.(그 분 한달 수입이 거의 한 사람 연봉이라 많은 이들이 애자일 코치로의 전업을 꿈꿨다…갓자일 코치…)

그 경험을 바탕으로 필자가 배웠던 애자일에 대한 내용과 직장에서 실제로 여러가지 시도를 해본 후 느꼈던 점에 대해서 한번 얘기해볼까 한다.

애자일을 왜 사용하는걸까?

최근에는 많은 조직에서 이미 애자일 프로세스를 사용하고 있기 때문에 애자일이 무엇인지는 많이 알고 계실거라 생각한다.

애자일(Agile)은 기민하다라는 뜻으로 너무 계획이 없는 개발 방법론과 너무 체계적인 계획이 있는 개발 방법론 사이의 균형을 잡아보자는 의도로 나온 개발 방법론이다.

전통적인 개발 방법론으로는 폭포수 모델(Waterfall)이 대표적인데, 이 개발 방법론의 특징은 바로 앞만 보고 달리되, 굉장히 긍정적인 마인드를 품은 개발 방법론이라는 것이다. 폭포수 모델을 포함한 이런 전통적인 개발 방법론들은 대략 다음과 같은 큰 틀을 가진다

기획 > 디자인 > 개발 > 테스트 > 배포 > 유지보수

굉장히 익숙하지 않은가? 우리도 알게 모르게 여러 번 겪었을 프로세스다. 이 프로세스는 마감 기한을 딱! 정해놓고 그 마감 기한 안에 프로젝트를 끝내기 위해 모든 팀원이 자신이 맡은 일을 끝낸 후 다음 차례로 넘긴다. 이렇게 아무 문제 없이 끝난다면 모두가 행복한 해피엔딩이겠지만 현실은 그렇지 않다.

M06B님의 "무리한 요구를 하는 클라이언트" 카톡 이모티콘

현실 세계에서는 갑인 클라이언트님께서 프로토타입을 보고 수정 사항을 요청할 수도 있고, 인하우스 프로덕트를 개발하는 회사라고 해도 열심히 개발해서 배포했더니 유저의 반응이 예상과는 전혀 다르게 안좋을 수도 있다.

이런 상황에서의 폭포수 모델은 너무 많은 리스크를 팀원들에게 강요한다. 기껏 한두달 열심히 개발했더니 그동안 고생한게 모두 물거품이 되버리기 쉽다는 얘기다. 또한 이런 경우도 생긴다.

기획 > 디자인 > 개발(어? 이건 지금 상황에선 불가능 한데…?)

개발자가 기획 회의에 참여한 경우 이런 경우를 어느 정도 방지할 수 있지만 그렇지 않은 경우 다시 기획자에게 찾아가서 현재 상황과 불가능한 이유를 설명하고 다시 기획 > 디자인 프로세스부터 시작해야한다. 이런 경우, 작게는 시간 낭비부터 시작해서 크게는 팀원간의 감정도 상할 수 있고 그로 인해 팀 사기에도 좋지 않은 영향을 끼치기 때문에 좋은 경험은 아니라고 생각한다. (필자는 팀원들의 감정 상태를 굉장히 중요하게 생각한다)

그럼 전통적인 방법들의 이런 단점을 극복하고자 고안된 애자일이 무엇인지 한번 알아보도록 하자.

애자일 선언에 대해서

애자일 개발 방법론은 2001년 발표한 애자일 선언에서부터 시작한다.

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.

공정과 도구보다 개인과 상호작용을

포괄적인 문서보다 작동하는 소프트웨어를

계약 협상보다 고객과의 협력을

계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

애자일 선언 한국어 원문 agilemanifesto.org

우리는 이 선언에서 애자일이 어떤 것을 지향하는 지 알 수 있다. 이 얘기를 좀 더 쉽게 풀면 이런 식이다.

자, 우리는 팀이니까 따로 놀지말고 커뮤니케이션을 잘하고!
쓸데없는 문서 작성에 너무 시간 뺏기지 말고 일단 작동하는 뭔가를 만들고!
고객이 실제로 가치를 느낄 수 있는 프로덕트를 만들고!
계획은 늘상 변하는 거니까 변화에 대응할 수 있게 유연한 작업 방식으로 일하자!

애자일은 굉장히 이상적이다. 오직 고객만을 위한 제품을 만들기 위해 유연하게 움직이는 조직이 되자는 의미이기 때문이다.

애자일 선언 이면의 원칙(12개 원칙)

애자일은 애자일 선언 외에도 12개의 원칙을 세워놓고 그 원칙을 따르자고 한다.

우리는 다음 원칙을 따른다.

우리의 최우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.

비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.

동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

작동하는 소프트웨어가 진척의 주된 척도이다.

애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.

기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

안 하는 일의 양을 최대화하는 기술이 필수적이다.

최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.

팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

애자일 선언 이면의 원칙 agilemanifesto.org

우리가 애자일 프로세스하면 떠올리는 몇가지 일들은 이 12개의 원칙을 기반으로 생겨난 것이다. 예를 들면 스프린트(Sprint)는 3번 원칙에 기초하며 매 스프린트가 끝날 때마다 행하는 회고(Retrospective)는 12번 원칙에 기초한다. 또한 애자일에서는 거대한 팀보다는 일명 Task Force Team(TF Team)을 선호하는데, 이건 5번에서 기초한다. 그 이유는 거대한 팀보다 작은 팀이 더 유기적으로 움직이기 편하기 때문이다.

이 12개의 원칙은 어떻게 하면 더 애자일하게, 즉 기민하게 프로덕트를 생산하고 고객에게 전달할 수 있는지에 대한 일종의 가이드라인 역할을 하는 셈이다.

애자일의 기본적인 요소들

[출처] https://brainhub.eu/blog/differences-lean-agile-scrum/

애자일은 12개의 원칙에 기초하는 여러 개의 요소를 가지고 있다. 이 포스팅에서는 구성 요소들 중 필자가 중요하다고 생각하는 User Story, Backlog, Estimation, Retrospective를 짚고 넘어가겠다. 한번 간단하게 하나하나 살펴보자.

User Story

애자일은 유저 스토리 기반으로 구성된다. 이 스토리라는 것이 상당히 중요한데, 이건 철저히 유저 중심으로 만들어져야 한다. 우리가 보통 스토리 혹은 이슈를 생성하면 이런 식으로 작성될 확률이 높다.

SD-1234 요청서 페이지 리뉴얼

SD-1235 웹뷰로 되어있는 프로필 페이지를 네이티브로 변경

SD-1236 소셜 로그인을 위한 DB 스키마 설계 및 API 엔드포인트 작성

SD-1237 유저 채팅에 사진 여러 장 한번에 보내기 기능 추가

필자가 애자일 코칭을 받을 때 애자일 코치님이 가장 먼저 지적한 것이 바로 이것이었다. 애자일 코치님은 스토리에 되도록이면 누가(Who) 무엇을(What) 왜(Why)의 세가지 요소가 들어가면 좋다고 했었다. 이렇게 작성된 스토리는 그 제목 자체만으로 팀이 왜 이 스토리를 해결되어야 하는지 설명해준다. 따라서 위의 스토리들은 이렇게 다시 작성되어야 한다.

SD-1234 고객은 요청서를 쉽게 보내기 위해 필요한 정보를 한눈에 확인할 수 있다.

SD-1235 고객은 자연스러운 UX를 위해 프로필 페이지를 웹뷰가 아닌 네이티브로 사용할 수 있다.

SD-1236 클라이언트 개발자는 소셜 로그인 기능 개발을 위해 관련 API 엔드포인트를 사용할 수 있다.

SD-1237 고객은 채팅 내에서 여러 장의 사진을 쉽게 보내기 위해 멀티 셀렉트 기능을 사용할 수 있다.

이렇게 작성된 유저 스토리는 이 스토리들과 전혀 관련없는 제 3의 팀원이 보더라도 별다른 부연 설명없이 원하는 정보를 얻을 수 있다.

그리고 유저(Who)는 반드시 고객이 아니어도 상관없다. SD-1236의 경우 유저는 클라이언트 개발자이다. 이런 경우에도 클라이언트 개발자(Who)는 소셜 로그인 기능 개발을 위해(Why) 관련 API 엔드포인트를 사용할 수 있다.(What)과 같은 정보를 모두 채워서 넣으면 된다. 팀원들은 프로덕트의 생산자이자 서로의 내부 고객이기도 하기 때문이다.

Product Backlog

Product Backlog는 앞으로 처리해야할 여러 개의 유저 스토리로 구성되어 있다. 이 스토리들은 PO(Product Owner)가 정의한 우선 순위대로 정렬되어 있으며 이 우선 순위에 대한 권한은 PO의 직권이다. 일단 이 애자일은 팀원들이 PO가 내린 결정을 신뢰해야 한다는 게 기본 전제 조건이다.

그렇다고 무조건 믿고 까라면 까라는 게 아니고, 당연히 의견이 있다면 자유롭게 토의할 수 있지만 최종 결정은 PO가 한다는 의미이다.

그리고 백로그는 그냥 방치하면 계속 스토리들이 쌓이게 되는데 PO는 주기적으로 이 스토리들이 실행 여부를 판단하여 스토리들을 정리해주는 작업을 해줘야한다. 그렇지 않으면 스토리들이 계속 쌓여서 어떤 스토리가 의미가 있고 어떤 스토리가 의미가 없는 지 판단하는 데 걸리는 시간이 길어지게 된다.

Estimation

Estimation은 한국말로 직역하면 견적 정도의 의미이다. 근데 회사에서는 다들 그냥 에스티메이션이라고 하므로 필자도 거기에 익숙하기 때문에 그냥 에스티메이션이라고 하겠다.

에스티메이션은 PO가 만들어놓은 여러 가지 스토리를 가져와서 실제 그 스토리를 해결할 팀원들이 이 이슈가 어느 정도의 크기를 가진 이슈인지 스토리 포인트를 매기는 것이다.

이때 많이 하는 방법이 1점 === 1시간으로 생각해서 스토리 포인트를 절대값으로 매기는 데, 필자의 직장도 처음에는 1점 === 1시간으로 생각하고 하루에 집중해서 일할 수 있는 시간을 4시간으로 정한 후 4점 === 이 이슈는 하루 정도는 걸리는 이슈다. 라고 에스티메이션하는 방법을 사용했다.

근데 문제는 이 예상이 거의 대부분 빗나간다는 것이다. 물론 자기가 하는 일이 정확히 언제 끝날 지 산정하실 수 있는 굇수분들도 있겠지만 필자와 필자의 팀원들은 그냥 일반인이기 때문에 그러지 못했다. 예상하지 못한 버그가 터지거나 예상하지 못한 회의가 생겼다거나 혹은 갑자기 아파서 병가를 썼다거나 이런 예외 상황은 생각보다 자주 발생했고 그럴때마다 스프린트도 펑펑 터져나갔다.

그래서 택한 방법은 바로 스토리 포인트를 상대값으로 매기는 것이다. 방법은 이렇다. 과거에 지나갔던 스토리 중에 기준이 될만한 스토리를 하나 가져와서 그 스토리에 대해서 팀원들이 그때의 경험을 토대로 에스티메이션을 한다.

SD-1234 사용자는 요청서를 쉽게 보내기 위해 필요한 정보를 한눈에 확인할 수 있다.

철수: 이거 생각보다 일이 없었던 것 같은데? 저는 3.

영희: 이거 디자인하느라 맨날 야근했어. 나는 5.

민철: 난 영희를 좋아하니까 나도 5.

이런 식으로 어느 정도 팀원들의 의견이 수렴이 되면 요청서 페이지의 디자인을 바꿨던 스토리가 5정도 된다라는 기준을 잡을 수 있다. 이제 이 스토리를 기준으로 다른 스토리들의 크기를 상대적으로 측정해나가는 것이다. 측정하는 스토리 포인트는 XS, SM, M, L, XL와 같이 티셔츠 사이즈로 하는 방법도 있고 1, 2, 3, 4와 같은 자연수를 사용해도 상관없다. 어차피 상대적인 크기를 측정하는 것이므로 추상적인 크기만 설정할 수 있으면 된다.

참고로 필자의 회사는 1, 2, 3, 5, 8...의 피보나치 수열을 사용하고 있다.

처음에는 상대적인 크기를 측정한다는 것이 어렵게 느껴질 지 모르지만 필자가 경험해본 느낌으로는 시간을 측정하는 것보단 이 방법이 더 정확했다. 단, 팀이 한 스프린트에 어느 정도의 스토리 포인트를 쳐낼 수 있는지에 대한 정보가 먼저 필요하다.

이건 그냥 적당히 몇번 돌려보면 각이 나온다. 첫번째 스프린트에 40, 두번째 스프린트에는 20을 쳤다면 다음 스프린트에는 평균 값인 30만큼의 스토리만 넣는 것이다.

비록 첫번째 스프린트에 비해 두번째 스프린트는 달성률이 50%나 떨어졌지만 걱정하지말자!

두번째 스프린트에 끝내지 못한 이슈는 세번째 스프린트까지 이어진 후 그 스프린트 안에 끝나기 때문에 다음 스프린트의 달성률은 원래 예상치보다 더 높아지므로 세 스프린트의 평균을 내보면 비슷한 값이 나온다. 그런 식으로 몇번 스프린트를 돌려보면 한번의 스프린트가 도는 동안 팀이 평균적으로 몇 만큼의 스토리 포인트를 쳐낼 수 있는지 각이 나온다.

저번 스프린트에 망한 달성률만큼 다음 스프린트에는 초과 달성될 확률이 높다!

그리고 중요한 건 스프린트 마감일은 데드라인이 아니다. 배포가 예상보다 늦어졌다면 늦어진 이유를 분석하고 다음에 또 늦지않으면 되는거니 너무 부담가지지 말자. 두번 실수하지만 않으면 된다.

Retrospective

회고(Retrospective)는 스프린트를 마무리하는 단계에서 행하는 것으로 필자는 다른 것들보다 이 회고가 가장 중요하다고 생각한다. 회고는 팀이 발전하기 위한 방향을 논의하는 가벼운 회의이다. 절대 무거운 분위기로 진행하는 것이 아니다!

그래서 필자의 직장에서는 회고를 사무실 근처 카페에서 커피를 마시면서 진행하기도 한다. 회고 방법은 타임라인을 그려놓고 팀원들이 각자 따뜻하게 느껴졌던 일과 차갑게 느껴졌던 일을 포스트잇에 적어서 타임라인에 붙히고 투표를 통해 논의하는 방법도 있고 그냥 각자 미리 주제를 정해와서 자유롭게 토론하는 방법도 있다.

이렇게 회고를 통해서 다음 스프린트에 시행할 액션 아이템(Action Item)을 정한 다음 각 액션 아이템마다 담당자를 붙혀준다. 해당 액션을 관리할 담당자가 없으면 흐지부지 해지기 쉽기 때문이다. 담당자가 된 팀원은 다른 팀원들에게 주기적으로 노티를 줘서 책임감을 가지고 그 스프린트 안에 해당 액션 아이템을 처리하는 것을 목표로 한다.

그럼 애자일은 좋은 건가?

일단 필자는 개인적으로 데드라인에 쫓기는 폭포수 모델보다는 1~2주안에 작은 스토리를 처리하고 배포하는 애자일을 좋아하긴 한다. 짧은 시간안에 개발과 배포가 이루어지다보니 사용자의 피드백을 빠른 시간안에 받을 수도 있고 뭔가 배포할때마다 느끼는 상쾌함도 자주 돌아오기 때문에 좋다. 그러나 애자일이 모든 상황에서 항상 잘 듣는 만병 통치약은 아니다. 애매한 상황도 생긴다는 얘기다.

이건 애자일 하지 않아요!

이 대사는 필자가 직장에서 데일리 스크럼 때 꽤나 많이 들었던 말이다. 상황은 대충 이렇다.

뭔가를 해야한다. -> 생각보다 이슈의 크기가 크다. -> 기능 간 디펜던시가 커서 따로 배포는 힘들 것 같다. -> 그냥 한번에 하고 배포하자!

이런 상황에서 누군가 이야기 한다.

흠 근데…이건 애자일 하지 않은 것 같은데요…?

그러면 그 공간에 있는 모두가 머리를 싸매기 시작한다. “애자일하게 이걸 처리하려면 어떻게 해야하지…?” 라는 생각으로 머리가 복잡해지기 시작한다. “그럼 애자일하게 하려면 어떻게 해야할까요?”라고 누군가 서두를 던져보지만 아무도 답을 내지 못한다. 이건 애초에 잘게 쪼갤 수 없는 이슈였기 때문이다.

하지만 애자일의 본질은 이런게 아니다. 어떤 규칙과 규정으로 정해져 있는게 아니란 뜻이다.

물론 애자일 선언과 12개의 법칙이 있긴 하지만 그건 그냥 가이드라인일 뿐이다. 각 팀마다 성격이 다른데 어떠한 방법이 전세계 모든 팀에게 모두 좋은 효과를 보인다는 건 말도 안된다.

필자는 애자일의 기본 가이드 라인을 따라가되, 각 팀에 맞게 유연해서 변형해서 사용하는 것이 더 자연스럽고, 또 그게 맞는 방법이라고 생각한다. 굳이 애자일 선언이나 뭐 저런 법칙이나 그런 걸 굳이 안 따라하더라도 그 팀에 맞는 어떠한 창의적인 방법이라도 괜찮다. 다 일 잘하자고 하는건데 굳이 어떤 규칙을 만들어서 지켜야할 이유는 없다. 일만 잘하면 됐지.

애자일에 너무 얶매이지는 말자

필자는 사실 애자일 선언을 처음 들었을 때 마치 공산주의같다고 생각했다.

마르크스가 처음 마르크스주의를 제창하고 자본론을 집필했을 때의 사회 분위기는 이러했다. 공산주의는 완벽한 체제이고 점점 발전해가며 자본주의는 언젠가 스스로 붕괴할 것이라는 분위기가 노동자들 사이에서 팽배했다. 그러나 현실에 도입된 공산주의는 현실의 벽 앞에 부딪히고 스탈린주의, 마오주의 등으로 점점 변질되어 대부분 독재로 마무리 되었다. 원래는 “우리 모두 함께 잘살아보세!”에서 시작했지만 현실에 강림한 공산주의의 실체는 “우리 함께 못살자”가 되버린 격이다.

마찬가지로 현실의 애자일도 생각보다 순탄하게만은 돌아가지 않는다. 방금 위에서 예를 든 상황도 굉장히 애매한 상황 중 하나이다. 이슈를 쪼갤 수 없어서 한 스프린트안에 배포가 힘들 것 같은데 어떻게 해야한단 말인가?

애자일 선언은 물론 굉장히 좋은 말이고 옳은 말이지만 저기에 너무 집착하게 되면 오히려 일을 위한 일을 만들게 되는 조직이 된다고 생각한다.

우리가 지금 누리고 있는 자본주의도 원래 애덤 스미스 형의 “시장은 냅두면 알아서 잘 굴러간다” 운운하던 예전 그대로라면 망테크였겠지만, 공산주의에서 제창하던 것들을 좋은 방향으로 잘 섞은 뉴딜정책으로 인한 국유화 사업과 복지 정책 등이 포텐터지면서 지금까지 발전하게 된 것이다. 뭐든지 절대적으로 완전한 건 없다.

마찬가지로 필자는 애자일이든 폭포수 모델이든 칸반이든 뭐가 됐든 그냥 일만 효율적으로 잘하면 그만이라고 생각하기 때문에 저 애자일 선언은 그냥 한번 듣고 흘렸다. 그냥 좋아보이는 걸 적당히 섞어서 써도 팀에만 잘 맞는다면 상관없다. 애자일 선언은 너무나도 당연한 말들만 해서 오히려 더 담아두지 않았던 것 같다.

마치며

사실 필자가 애자일 코칭을 받고 나서 느낀건 “애자일에는 정답이 없구나”와 동시에 “아니 그럼 저 애자일 선언이고 나발이고 그냥 기민하게 제품을 배포만 할 수 있으면 아무 상관없는 거 아닌가?”라는 아이러니한 생각이었다.

지금도 필자는 애자일은 그냥 제품을 기민하게 고객에게 배송할 수만 있다면 스프린트를 1주로 하든 2주로 하든 에스티메이션을 어떻게 하든, 방법 따윈 뭐가 됐든 상관없다고 생각한다.

다만 만약 여러분의 팀에서 애자일을 도입해보고자 한다면 제대로 해보는 게 좋다고 생각하기 때문에 필자가 애자일 코칭을 하면서 배웠던 경험들을 공유한다. 팀원들이 단합해서 이것 저것 다 시도해보고 회고를 통해 어떤 점이 좋았는지, 어떻게 하면 우리 팀이 좋은 방향으로 개선될지에 대해 논의하고 실제로 더 나아지는 경험은 쉽게 얻을 수 없는 좋은 경험이기 때문이다. 해보면 되게 재밌다 진짜로.

애자일은 제대로 하려면 생각보다 공부가 굉장히 많이 필요한 개발 방법론이다. 알아야 할 것도 많고 이것들을 각자의 팀에 맞게 응용하고 점검할 수 있는 능력도 있어야 한다. 그러나 필자가 직접 다른 조직에서 경험하거나 근처 개발자들한테 주워들은 얘기를 빌자면, 애자일을 도입한 많은 조직들이 단순히 스프린트를 돌리고 데일리 스크럼 미팅을 하고 JIRA를 사용하기만 하면서 애자일을 한다고 하는 경우도 많이 있다.

우리 팀이 스프린트에 쳐낼 수 있는 스토리 포인트가 어느 정도인지, 또 우리가 애자일을 하면서 외부 고객과 내부 고객들이 만족하고 있는지, 이런 끊임없는 점검이 부재한 애자일은 그냥 1~2주 단위의 데드라인을 반복할 뿐이다. 이거 해봐서 아는데 진짜 죽을 맛이다. 매일 데드라인의 압박을 느낀다는 건…후

이 글을 읽는 여러분이 애자일에 관심을 가짐과 동시에 협업에 대한 열정도 뿜뿜하면서 팀에서 재밌고 즐겁게 일할 수 있기를 바란다.

이상으로 애자일이 도대체 뭐길래? 포스팅을 마친다.