애자일과 린, 그리고 워터폴
더 나은 소프트웨어 개발 문화 만들기
본 글은 애자일 관련 4번째 글이며, 첫 번째 작성하였던 아래 글에서부터 이어진다. 애자일에 대해서 다소 생소하다면, 앞 글을 먼저 읽어 보기 바란다.
위 글을 발행하고 여러 댓글이 달렸고, 그중 다소 글에 대해 부정적인 의견도 있었다. 해당 의견을 접하고 다시 필자의 글을 읽어보니, 다소 애자일 예찬론(?) 형태로 작성된 것을 부인할 수는 없었다. 나름대로 객관적인 자세로 작성하려고 하였으나, 그게 마음만큼 쉽지 않은 듯하다. 그리고 방법론은 흡사.. 종교와도 비슷(?)한 경향이 있어서, 필자가 애자일이 아닌 방식은 마치 존중하지 않는 것으로 비칠 수도 있었을 법도 하다.
해서 이번 글에서는 필자를 비롯하여 애자일 관련하여 항상 화두가 되는 몇 가지 이야기를 해볼까 한다. 또한 이를 애자일뿐만이 아니라 린과 워터폴의 경계와 활용처에 대해서도 조금 더 명확하게 구분하는데 의의를 두고자 한다. 이는 필자가 최근에 소프트웨어 개발의 본 고장인 샌 프란시스코의 한 소프트웨어 업체와 3개월간 함께 프로젝트를 진행하면서 경험하고 깨달은 것들을 통해 조금 더 명확한 글을 쓸 수 있기 때문이기도 하다.
본 글은 필자가 믿고 추구하는 방향이 아예 배제될 수는 없다고 생각한다. 오류나 이슈가 있다고 생각되면 주저하지 말고 댓글로 남겨주기 바란다. 서로 다른 의견을 통해서 조금 더 가치 있는 내용으로 진화한다면 더할 나위 없이 좋겠다.
그럼 시작해보자.
AGILE
어느 소프트웨어 개발팀이 애자일의 스크럼을 적용하여 어느 정도 안정적으로 팀이 운영되고 있다고 가정해보자. 애자일을 열심히 적용하다 보면 기존에 폭포수 형태로 일하는 방식과는 사뭇 다르게 일을 하는 것을 느낄 수 있다. 이터레이션이 짧아지고 한층 작아진 범위에 집중하여 개발을 하기 시작한다. 체력 소모도 예전에 비해 훨씬 더 할 수 있다. 애자일을 잘 적용하고 있다면, 팀 간의 커뮤니케이션이 예전에 비해 월등히 좋아졌을 것이다. 본인이 하는 일이나 팀원이 하는 일들이 투명성 있게 드러나기 시작한다. 예전 같았으면 수면 위에 오르지 않았던 리스크들을 데일리 미팅 때 스멀스멀 올라온다. 동료가 어느 부분에서 헤매고 있는지 쉽게 알 수 있고, 팀 내 잘 아는 동료의 도움으로 4시간 삽질할 거 10분 만에 해결하고 배워버리고 말았다. 예전에 비해서 개발할 때 느끼는 답답함이 많이 사라졌을 것이다. 좋은 형상이다.
하지만, 여전히 무엇인가 부족한 느낌이 있다. 애자일이 선진국에서 흔히 사용하는 방법론이라고 해서 힘들게 배워서 팀 내에 전파하여 프로젝트를 수행하고 있으나, 혹자는 이런 생각을 할 수 있을 것이다.
내가 지금 누군가에게 정말 필요한 소프트웨어를 만들고 있는 건가?
소프트웨어는 분명 만들어지고 있고 진도도 잘 빼고 있지만, 지금 팀이 만들고 있는 제품이 정말 왜 필요한 건지, 어떤 문제점을 해결하기 위해 만들어지고 있는 건지 이해가 부족한 상태에서 개발을 하는 경우가 많기 때문이다.
필자는 이 부분을 개선하기 위해서, 사용자 스토리는 사용자가 직접 써야 하고, 해당 사용자 스토리의 완료 유무는 고객이 직접 인수 테스트를 하면서 해결해야 되겠다고 생각했었다. 물론, 고객을 스크럼 팀의 PO(제품 오너)로 두는 것이 가장 좋다고 주장하는 책이나 사람도 있다. 필자도 시도하고는 있다.
하지만, 실제로 그것이 쉽게 가능한 건가? 같은 회사의 내부 고객 대상으로 시스템을 만들어도, 내부 고객과 한 팀을 이루어 프로젝트를 하는 것은 사실상 불가능하다. 그리고 사용자가 직접 쓰는 사용자 스토리? 실은 어느 사용자도 사용자 스토리를 직접 작성하거나, 해당 구현 사항이 끝났다는 것을 최종 확인하는 역할(해당 기능에 대한 책임을 지는 것)을 하고 싶어 하지 않는다. 단지, 본인이 가지고 있는 문제를 정말 해결해 줄 수 있는지에만 관심이 있을 뿐이다. 게다가 변덕도 심하다. :)
애자일의 대부분의 도구들(스크럼, XP, 칸반 등)은 소프트웨어를 개발하는 데에 주로 집중하고 있다. 하지만, 정말 필요한 것을 만들고 있는 지를 측정하는 방법이나, 측정 결과를 어떻게 활용하는지에 대한 설명은 다소 부족한 것을 알 수 있다.
그렇다면 이 부족함을 어떻게 채울 수 있을까? 바로 린 (LEAN)에서 찾아볼 수 있다.
LEAN
간혹 린의 개념이 애자일 족보 밑에 있는 것으로 오해하는 경우가 있는데, 그렇지 않다. 린은 린 제조(Lean Manufacturing)에서 유래한 개념으로, 제조 공정에서 쓸데없는 낭비를 최소화 하자는 데에 기인하고 있다. 린에서의 낭비는 제조 공정상에 과한 부담을 주거나 공정상 균형이 잘 맞지 않는 업무량 등에서 발생한다고 말하고 있다. 또한, 제품 혹은 서비스를 소비하는 고객 관점에서 일하기 위해서는 고객이 구매할 의사가 있는 어떠한 행위나 프로세스가 바로 '가치'라고 말하고 있다. 이 사상은 도요타의 생산 시스템을 의미하는 TPS(Toyota Production System)에서 유래되었고, 2003년 경 Mary Poppendieck와 Tom Poppendieck 가 린의 원칙들과 애자일 프랙틱스를 접목하여 LSD( Lean Software Development)라는 이름으로 책을 쓰면서 애자일의 한 가지 도구를 만드는 데 중요한 역할을 하게 되었다. 또한, 2008년도에 Eric Ries라는 친구가 스타트업에서 고수해야 할 것들을 린 기반으로 풀어쓴 책이 바로, 린 스타트업(Lean startup)이다. 아마도, 근래에 소프트웨어 유관 비즈니스에 관심 있는 분이라면, 린 스타트업이라는 용어는 쉽게 접했을 것이라 생각한다. 필자는 린을 린 스타트업에서 주요하게 생각하는 개념 위주로 설명을 진행해보겠다. 아래 이미지는 린 스타트업 모델을 도식화한 것으로, "User Story Mapping"을 집필한 Jeff Patton 님의 블로그에서 가져왔다.
린 스타트업 모델 (출처: http://www.boomtownaccelerator.com/most-startups-are-about-discovery/)린 스타트업 얘기만 해도 할 얘기가 많지만, 크게 2가지 개념만 짚고 넘어가자.
1) BUILD - MEASURE - LEARN 사이클
린 스타트업에서 가장 중요한 3가지 꼭지는 바로 BUILD - MEASURE - LEARN이다. 만들고, 측정한 다음, 배운 것을 다시 반영하여 만드는 것이다. 여기서 측정한 결과가 기존에 가지고 있던 계획과 다르다면 과감히 전환(pivot)을 해야 한다. 다른 말로는 Fast Fail이라 언급할 수도 있을 것이다. 실은 국내 정서상 누군가가 계획하고 상부의 지시로 시작한 일이 굳이 하지 않아도 되는 일을 알게 되더라도 그만두는 일이 쉽지가 않다. 어쩔 수 없이 그냥 진행하는 경우도 많다. 하지만, 린에서는 급변하는 세상의 변화에 민첩하게 대응하라고 주문한다. 만약, 측정한 결과가 기존에 가지고 있는 가정(assumption)들을 검증(validation)하고, 다양한 가설(hypothesis)들을 증명(prove)한다면, 프로젝트는 가속 페달을 밟으며 점점 빠르게 순항할 수 있을 것이다.
2) MVP(Minimum Viable Product)
이때, 소프트웨어를 사용할 사용자(보통 여러 형태의 사용자가 존재한다) 중 가장 중요한 타깃 사용자를 선정하고, 이 타깃 사용자를 대상으로 소프트웨어의 가장 중요한 기능이지만 최소한의 범위의 제품을 통해 조기에 사용자의 피드백을 받는 것이 무척 중요하다. 이때, 말하는 작고 미완성체이지만, 사용자에게 이 제품의 가치를 증명해 낼 수 있는 제품을, 린 스타트업에서는 MVP라고 한다. 이 MVP를 선정하는 과정 역시, 무척 중요하다고 볼 수 있다. 그리고 여기서 중요한 대목 중에 하나는, MVP는 말 그대로 최소한의 범위가 되어야 한다. 즉, 최소한의 공수를 들여야 한다. 굳이 동작하는 소프트웨어일 필요는 없다. 종이에 그린 스케치가 될 수도 있을 것이고, 저수준(low-fidelity)의 와이어프레임(wireframe)이 될 수도 있겠다. 소프트웨어를 바로 만들지 않는 이유는 아주 단순하다. 필요 없을 수가 있기 때문이다. 굳이, 필요 없는 것을 미리 만들 필요가 없다는 것이고, 어느 정도 필요하다고 검증이 된 기능에 대해서만 구현에 들어가자는 것이다.
간혹 이 부분에서 고개를 갸우뚱하는 분들이 있을 듯하다. 애자일이라 하면 어찌 되었든 간에 빨리 만들어서 사용자에게 최대한 빨리 보여주고 피드백을 받아서 고쳐 나가야 되는 것이 아닌가 하는 생각에 애자일과 상충(?) 되지 않느냐라고 할 수도 있겠다. 제품 디자인은 비록 동작하는 소프트웨어가 아니더라도 거의 흡사하게 동작하는 수준의 고수준(high-fidelity)으로 작성이 가능하다. 그리고 굳이 비슷하지 않아도, 사용자에게 보여주고 피드백을 받을 수 있는 수준이라면 그 어떤 것이라도 상관이 없다는 것이다. 여기서 코드 한 줄 작성하는 것이 오히려 비용이 많이 발생하는 것을 알 수 있다. 안타깝게도 국내에서는 소스 코드 작성하는 일이 비싸다는 인식이 대부분 없다는 것도 오해를 불러일으킬 소지가 충분히 있어 보인다.
User Centered Design based on User Research
자, 그렇다면 가장 중요한 사용자를 선출하고, 어떤 기능으로 제품 컨셉을 증명할지 정했다고 치자. (이 과정도 해보면 쉽지 않다.) 어떻게 이 MVP를 가지고 측정 및 배울 수 있을까?
현재 필자가 함께 일한 회사에서는 정성적 사용자 리서치(Qualitative User Research)를 통한 사용자 중심 제품 디자인에서 해법을 찾고 있다. 팀 내에 이 업무를 주로 수행하는 롤을 제품 디자이너(Product Designer)라고 부른다. 이는 단순히 UI/UX에 대한 디자인을 하는 사람만을 일컫지 않는다. 프로젝트가 시작될 때 함께 비즈니스 모델을 고민해보고, 페르소나를 통해 특정 타깃 사용자를 깊이 이해하는 데 노력하며, 해당 사용자가 앞으로 개발할 소프트웨어를 사용하였을 때 어떤 부분에서 행복해하는지 전체 팀원과 함께 고민한다. 어느 정도 아이디어가 구체화되면 스케치 역시 팀 단위로 진행한다. 꼭 제품 디자이너가 가장 좋은 디자인을 보여주는 것은 아니다. 이렇게 모여진 스케치들을 가지고 팀 투표를 통해 메인 컨셉을 정한 뒤, 스케치 도구들을 활용하여 디자인을 하기 시작한다.
이런 과정에서 팀원들이 사실이라고 믿고 있었던 많은 정보들이 실은 수많은 가정들이고 가설임을 알게 된다. 제품 디자이너들은 이러한 가정/가설들을 검증/증명하기 위해, 타깃 사용자와의 인터뷰를 진행한다. 이를 위하여 실제로 제품을 사용할 사용자와 직접 대면하는 것이 무척 중요하다. 간혹, 이러한 사용자를 잘 이해하고 있는 사람의 피드백 기반으로 프로젝트를 진행하는 경우도 있다. 실은 굉장히 많다. 하지만, 그러한 사람들은 대부분 이해관계자(Stakeholder)인 경우가 많다. 실제로 제품을 사용하지 않는 사람이지만, 제품의 성공 유무에 따라 본인의 업무 성과에 영향을 미치는 사람들일 수 있다. 실제 사용자를 직접 만나는 것이 키 포인트다.
User Centered Design (출처: https://www.pinterest.com/pin/391672498814890532/)인터뷰 역시 정형화된 프로세스가 존재한다. 그리고 질문하는 방법, 거짓 긍정(False Positive)을 최소화하는 방법에 대해 명확한 방향을 제시한다. 한 가지 예를 들어보자. 호텔 예약 시스템을 만든다고 해보자. 몇 달간 밤새 작업한 산출물을 가지고 사용자에게 인터뷰를 해보자. 인터뷰에 대한 트레이닝을 받지 않은 사람이라면 이런 식으로 인터뷰가 시작될 가능성이 높다.
저희 팀이 지난 몇 달간 고생해서 만든 호텔 예약 시스템을 보여드리겠습니다. 지금 보고 있는 화면은 처음 URL을 방문하였을 때 보이는 메인 화면으로 상단에 메뉴가 보이고 중간 좌측에 호텔을 예약하는 패널이 붙어 있습니다. 이 버튼을 누르시면 체크인/체크아웃 날짜를 선택하는 달력 박스가 나올 것입니다. 그리고 에약 버튼을 누르시면 바로 예약이 가능합니다. 무척 쉽지 않나요?
필자가 조금 오버하긴 했지만, 보통 이런 식의 인터뷰가 될 가능성이 높다. 무엇이 문제일까?
인터뷰어는 인터뷰이에게 너무 많은 정보를 제공하고 있다. 이런 정보들은 사용자가 처음 화면을 접할 때 가장 먼저 눈에 들어오는 것이 무엇인지, 어떤 부분이 헷갈리는 부분인 지, 구현한 기능이 예상대로 동작하는지 알 수가 없다. 게다가 마지막 질문처럼 '쉽지 않나요'라는 질문에 대부분 쉽다고 답을 할 것이고 정형적인 거짓 긍정이 될 가능성이 높다. 이렇게 짧은 답을 유도하는 형식의 질문들을 보통 폐쇄형 질문(closed-ended question)이라고 부른다.
그럼 어떤 식의 질문이 좋은 질문일까? 아래와 같이 진행해 보면 어떨까?
저는 전문 리서치 기관에서 사용자의 호텔 예약에 관한 불편함을 해결하기 위한 조사를 진행하고 있습니다. 최근에 호텔을 이용해 보신 적이 있으신가요? 호텔을 이용하실 때 미리 예약을 하시는 편이신가요? 만약, 그렇다면 마지막으로 호텔을 예약하실 때의 경험을 공유해주시겠습니까? 지금 제가 보여드리고 있는 화면은 호텔 예약을 하기 위한 화면입니다. 어떤 것이 보이시는지 말씀해 주시겠어요? 만약, 님께 호텔 예약을 정말 쉽게 할 수 있는 마법의 지팡이가 있다면, 어떤 것을 해보시겠어요?
처음 이런 인터뷰를 접하게 되면 다소 당황할 수 있겠다. 가장 중요한 것은 순수한 인터뷰이의 피드백을 받기 위해 본인이 알고 있는 정보들은 최대한 공유하지 않아야 한 다는 사실이다. 이러한 질문들은 답을 단답식으로는 줄 수 없는 질문들이며, 주제에 대한 지식이나 기분 등을 전체적으로 줄 수 있게끔 유도한다. 이러한 질문들을 개방형 질문(open-closed question)이라고 부른다. (개방형 질문에 대한 구체적인 설명은 이 링크를 통해서 참고할 수 있다.)
그리고 어떠한 피드백을 받았을 때 반드시 이유를 물어야 한다. 가령, "음.. 이런 버튼이 하나 추가되면 무척 편하겠군요!"라는 답변을 받았다면, "실례가 되지 않는 다면, 이유를 설명해 주실 수 있을까요?"라는 식으로 계속 WHY를 묻고 이해해야 한다. 인터뷰 관련된 내용은 필자가 본 글에서 더욱 자세히 설명하기에는 제약이 많은 듯싶다. 고객 인터뷰 관련하여 조금 더 자세히 알고 싶다면 아래에 링크의 책을 추천한다. 아주 얇고 자그마한 책이지만, 어떤 식으로 사용자에게 질문을 해야 하는지, 그리고 답변에 대해서 어떤 식으로 통찰을 이끌어나가는지에 대해 도움이 될 것이다.
http://www.talkingtohumans.com/
해당 책을 2016년 12월 13일부로, 필자가 번역하여 공개하였다. pdf나 웹 뷰어로는 무료로 이용이 가능하니, 관심 있는 분들은 아래 링크에 방문해보기를 바란다.
http://espressobook.com/@tthumans
So, what should I use?
그렇다면 애자일, 린, 워터폴.. 다양한 방법론들 중 우리 프로젝트에 걸맞은 방법론은 무엇일까?
크게 2가지 척도로 구분할 수 있겠다. 사용자의 문제점을 얼마나 잘 알고 있는지와 이 문제점을 풀기 위한 솔루션이 무엇인지 구체적으로 알고 있는 지를 생각해 보아야 한다.
1) 사용자의 문제점도 명확히 알고 있고, 솔루션이 무엇인지도 알고 있다.
이런 경우는 워터폴로 진행이 가능하다. 예를 들자면, 한 도서관의 모든 도서를 전산화하는 프로젝트를 한다고 해보자. 인터넷으로 보고 싶은 책을 쉽게 검색하여 원하는 장치로 책을 제공하는 프로젝트이다. 책장들의 연결 부위를 제거하여 낱장으로 스캔할 수 있게 작업을 한 뒤, 특수 스캐너로 모든 책의 페이지를 스캔한다. 스캔한 이미지는 책 단위로 압축되어 스토리지에 저장되고, 스캔이 완료된 건에 대해서는 웹 사이트를 통해 열람이 가능해진다. 분해된 책은 다시 물리적으로 원복 한다.
예시가 적절한지는 조금 의문이 간다. ㅡㅡㅋ 실은 유사한 프로젝트를 경험한 적이 있다. 첫 번째 경험은 규모가 무척 작은 프로젝트였고, 특전사에서 수기로 작성하던 낙하산 관리기록부를 전산화하는 프로젝트였다. 그냥, 종이에 직접 사람이 기입하던 것을 웹 애플리케이션으로 옮기는 정도였다. 또 하나의 경험은 대형 제조사 프로젝트로 전 세계의 30여 개의 공장의 제조 실행 시스템을 통합 개발 및 확산하는 프로젝트였다. 개발 및 시범 적용, 전체 확산까지 3년이 넘는 시간이 걸렸고, 항상 300여 명의 개발자가 상주하고 있었다. 이 프로젝트는 5개 Major 시스템과 십여 개의 작은 시스템을 하나로 통합한 뒤, 전체에 적용하면서 커스터마이징하는 형태로 진행이 되었다. 이 역시, 전환/통합 대상 시스템이 정해져 있고, 쉽고 안전한 기술 기반으로 상용 솔루션과 오픈소스를 적절하게 섞어서 진행한 프로젝트이다. 또한, 글로벌 프로젝트에다가 많은 인력들이 동시에 여러 곳에서 작업을 하다 보니, 사전 계획 수립 및 이행이 철저하게 지켜져야만 했다. 아무래도 대형 SI성 프로젝트는 워터폴 형식이 아니고서는 수행하기 어렵지 않을까 싶다.
2) 사용자의 문제점을 명확히 알고는 있지만, 솔루션이 무엇인지 잘 모르겠다.
이런 경우는 애자일이 잘 맞는다. 일단, 사용자를 위해 어떤 제품을 만들어야 할지 명확하게 안다는 것은 프로젝트가 흘러가야 할 길라잡이가 명확하다는 뜻이다. 필자가 경험한 프로젝트 중 좋은 사례가 하나 있다. 해당 프로젝트는 생보사의 차세대 시스템의 일부를 구현하는 것이었다. 코볼로 되어 있던 기존 시스템을 자바로 전환하면서 새로운 요구사항을 반영하는 과정이었다. 필자에게 떨어진 미션은 일반 사용자가 화면에서 버튼을 눌러서 하던 작업을, 수백, 수천 명의 그룹 단위 대상으로 정기적으로 수행하는 시스템 개발이었다. 물론, 온라인상에 구현되어 있는 동일 로직을 그대로 재활용해야 하는 미션이었다. 이 부분의 솔루션을 개발하기 위해서는 매우 다양한 방법이 존재하였고, 어떤 방법이 최선인지 초기에는 가늠하기 쉽지 않았다. 해서, 해당 시스템은 다양한 솔루션을 짧은 이터레이션 기반으로 제공하여 사용자 및 기존 시스템 관리 인력들에게 피드백을 받으면서 방향을 조정해가며 수행을 하였다. 이런 경우, 애자일은 무척 훌륭한 도구임에 틀림이 없다고 생각한다.
3) 사용자의 문제점이 무엇인지 모호하며, 솔루션 역시 모르겠다.
가장 답답한 경우다. 이런 프로젝트가 어디 있겠냐고 반문하는 분도 있을지 모르겠다. 하지만 의외로 이런 프로젝트가 생각보다 많다. 가령, 어설픈 기획 혹은 너무나 추상적이 단계의 아이디어를 기반으로 시작한 프로젝트라고 생각해보자. 프로젝트의 시작이 정말 순수하게 특정 사용자의 문제점을 해결하기 위해서 시작한 것이 아니라, 정치적인 이유로 시작하는 경우도 분명 존재한다. 프로젝트가 굴러는 가고 있고, 무엇인가 잘 못 돼가고 있는 것 같은데 여러 가지 이해관계가 얽히고설켜서 멈출 수가 없다. 혹은 열의를 가지고 나름대로의 기준으로 꽤 의미 있는 프로젝트를 기획하여 시작하였으나, 실은 그 아이디어가 판타지인 경우도 비일비재하다. 이런 경우, 린에서 해법을 찾을 수 있을 것이다. 프로젝트를 시작하기 전에 유저 리서치를 통해 겨냥하고자 하는 사용자층의 문제점을 파악할 수 있을 것이다. (실은, 이 부분은 디자인 씽킹에서도 많은 방법을 제시하고 있다.) 타깃이 정해지면, 구현하기 전에 최소한의 시간과 비용으로 만들고자 하는 제품에 대한 디자인을 만들고(Build)고 사용자의 피드백을 통해 정량적인 수치들을 도출(Measure)하며, 이를 통해 배운 것(Learn)을 제품에 반영한다. 컨셉을 잘 못 잡았다고 판단이 되면 과감히 포기하고, 정말 필요한 솔루션 개발로 전환(Pivot)한다.
4) 사용자의 문제점은 모르겠는데, 솔루션을 알고 있다.
좀 황당할 수도 있겠지만, 이런 경우도 존재한다. 바로, 선투자를 통한 기술 확보나, 문제가 발생하지 않았지만 앞으로의 문제를 해결해 나가야할 운영 조직 등을 들 수 있겠다. 앞으로 생길 사용자의 문제점들을 예상하고 미리 솔루션을 확보하는 경우이다. R&D 조직이나, 상용 솔루션 고개 센터 등에서 많이 찾아볼 수 있겠다. (참고로 미리 계획을 세울수 없으나 한 시점에 해당 팀이 처리할 수 있는 일의 양을 정의(처리 속도)한 뒤, 들어오는 일을 실시간으로 처리하는 방식을 애자일에서는 칸반이라고 한다. 칸반도 이 영역이라고 볼 수도 있겠다.)
이렇게 4가지 유형을 나름대로 나누었지만, 실은 명확하게 선을 긋기에는 무리가 있다. 프로젝트 상황에 따라 적절하게 조합하여 사용하는 것이 좋을 것이다. 그리고 근래에는 애자일과 린의 조합은 이미 많은 기업에서 성숙하게 활용하고 있다. 좋은 적용 사레 두 곳을 살펴보자.
Nordstrom Innovation Lab : Post Agile
아래 도식은 미국의 유명한 백화점인 노드스트럼의 이노베이션 랩에서 제시하는 프로세스이다. (2016년 5월 29일 기준으로 공식 웹 사이트가 접속이 불가하여 핀트레스트에 저장되어 있던 이미지를 찾아왔다. 본래 출처는 다음과 같다. http://secure.nordstrominnovationlab.com/pages/our_process_told_as_our_team_s_timeline)
출처 : http://pureandapplied.tumblr.com/post/112457000165/agile-discovers-a-solution-lean-startup디자인 씽킹 + 린 스타트업 + 애자일의 멋진 조합이다. 디자인 씽킹을 통해 고객들을 주의 깊게 살펴보고 공감함으로써 아이디어와 기회를 도출 및 구체화를 한 뒤, 린 스타트업의 BUILD-MEASURE-LEARN 사이클을 돌면서 배움의 결과에 따라 전환(Pivot)할지 지속(Persevere) 여부를 결정한다. 여기서 BUILD는 애자일을 활용한다. 이 랩은 위 혁신 사례 중 하나로 썬 글라스 매장에 고객을 위한 태블릿 앱을 만든 과정을 유튜브에 공개하였다. 현장에서 개발 환경 및 실 테스트 환경을 구축하여 제품화하여 바로바로 검증하는 과정이 무척 인상 깊다. 아래 링크를 참고하기 바란다.
Nordstrom Innovation Lab: Sunglass iPad App Case Study: https://youtu.be/2NFH3VC6LNs
Pivotal Labs
1989년에 설립하여 애자일의 XP, 린 제품 개발, 사용자 리서치 기법들을 조합하여 독특한 소프트웨어 개발 문화를 유지하고 있고, 세상에 전파하는 것이 주 비즈니스인 곳이 있다. 바로 피보탈 랩스이다. 회사 비전만 보아도 이를 알 수 있다.
Transform How the World Builds Software
실은 이 글도 이 곳에서 프로젝트를 수행하면서 배운 것들을 정리하고 나누고자 하는 차원에서 작성하게 되었다. 글의 본문 내용은 모두 당사의 개발 문화 관련된 설명과 같을 것으로 생각된다. 조금 더 자세한 설명은 아래 링크를 참고하기 바란다.
Pivotal Labs Process: http://pivotal.io/labs/process
실리콘 밸리의 많은 회사들이 피보탈 랩스의 영향을 받은 것도 흥미롭다. GE 역시 하드웨어 중심 회사에서 소프트웨어 및 분석 회사로 탈바꿈하기 위해서 피보탈 랩스를 벤치마킹하여 GE Software를 설립하고, 사무실 레이아웃 및 개발 문화 역시 그대로 옮겨 왔다고 한다. 실은 필자의 회사도 그중에 하나가 되지 않을까 기대한다.
이번 글에서 필자는 애자일, 린 그리고 워터폴에서 조금 더 구체적으로 구분하고, 어떤 경우에 어떤 방법론이 더 잘 맞을지 언급을 하였다. 그리고 이러한 방법론들을 잘 조합하여 사용하고 있는 곳들을 살펴보았다. 최대한 개인적인 의견을 배제하고 특정 사례를 비판(?)하는 오해를 일이 킬 만한 내용들을 지양하였지만, 혹자에게는 그렇게 비쳐지 않을까 다소 조심스럽다. 혹시 글의 내용에 대해 피드백이 있다면 부정적이라도 꼭 받았으면 하니, 댓글에 남겨주기 바란다.
다음 글에서는 댓글 요청이 있으면 위의 개념들을 실제로 잘 적용하여 실행하고 있고, 이를 바탕으로 다른 회사에 본인들의 소프트웨어 개발 문화를 전파하는 전도사 역할을 하는 회사와 협업 프로젝트에서의 경험담을 바탕으로, 상세 실천 방법에 대해서 소개해 보도록 하겠다.
오늘도 대한민국에 더 좋은 소프트웨어 개발 문화를 향하는데 조금이라도 기여하였으면 하는 바람이다. :)
