작년에 1회로 시작한 애자일 코리아 2012가 지난 토요일(1일)에 열렸다. 작년에도 가고 싶었지만 같은날 여러 컨퍼런스가 겹쳐서 참석못했는데 이번에는 참여를 했다. 이번 애자일 코리아는 포스코센터에 있는 마이크로 소프트의 세미나실에서 개최되고 프로그램은 다음과 같다.
(페르소나와 커뮤니케이션으로 풀어보는) 애자일을 실천하는 사람들이 겪는 어려움 - 최보나
작년 xper에서 활동도 많이 하시고 ThoughtWorks에서 일하시는 Analyst로 일하시는 최보나님의 세션이었고 (자기 소개하실때 소트웍스의 발음이 확 굴러가서 다른 회사인줄 알았;; 참고로 소트웍스는 마틴 파울러가 있는 회사다.) 커뮤니케이션에 대한 이야기였다. 시작할 때 T자형 인재와 A자형 인재에 대한 이야기로 시작하셨는데 T자형은 도요타에서 제시한 인재유형으로 익히 알다시피 하나에 깊은 지식을 가지고 있고 넓은 상식을 가지고 있는 인재형이고 A자형 인재는 T자형 인재유형에서 다른 사람들을 융합해 주는 커뮤니케이션 능력을 가진 인재유형을 말한다. 다음은 애자일 선언이다.
- 프로세스나 도구에 앞서 개인과 상호작용을
- 포괄적인 문서화에 앞서 작동하는 소프트웨어를
- 계약 협상에 앞서 고객과의 협력을
- 계획준수에 앞서 변화에 대한 대응을
사례 1
신페이는 15명 팀에서 일하며 팀원들의 애자일 경험년수의 평균이 5년정도 된다. 팀원들은 개인역량이 뛰어나고 자기조직화가 잘되어 있어서 문제가 없을 줄 알았는데 신페이는 "이 프로젝트가 어디로 가고 있는가?"라는 고민을 시작했다. Analyst[Analyst라는 역할이 국내에는 없기 때문에 정확히 이해는 안가지만 다른 분께 물어본바에 의하면 고객의 요구사항을 분석해주는 사람이라고 한다. 팀의 업무와 고객을 연결해주는 역할이 아닌가 싶다.]인 신페이는 각 팀원들이 정확히 무슨 일을 하고 있는지 알고 있지 못했다. 이를 해결해 주는 것이 1일 스크럼인데 각 팀원들이 각자 잘하다보니 스크럼은 뻔한 회의가 되었고 지루하고 의미없는 회의가 되어 그 중요성이 사라져 버렸다. 그래서 시각적인 회의를 도입해서 팀원들이 원형으로 앉아있는 것이 아니라 화이트보드를 바라보고 화이트보드에 스토리보드등 내용을 적어서 참여도와 집중도를 높였다. (시각적인) 커뮤니케이션이 답니다.
사례 2
필 클락은 미국과 인도로 나누어진 30명 정도의 팀에서 일하는데 여기에는 3개의 회사가 속해있고 팀원들은 애자일 경험도 별로 없었다. 이 팀의 문제는 사람들이 말이 안통한다는 것이었다.(언어가 다르다는 얘기는 아니다.) 비즈니스 하는 사람들이 하는 말을 기술자들이 제대로 이해못해서 결과물이 다르게 나오는게 문제였기 때문에 "테크니컬한 사람과 비즈니스하는 사람이 어떻게 소통할 수 있을까?"를 고민하기 시작했다. 그래서 BDD와 Cucumber를 팀내에 도입해서 비즈니스를 하는 사람들이 테스트와 인수테스트를 작성하도록 해서 개발자들이 완료의 기준을 정확히 잡을 수 있도록 했다. (도구를 이용한) 커뮤니케이션이 답이다.
사례 3
지납 난디는 10명 정도의 팀에서 애자일을 경험한 평균은 2-3년정도가 되는데 이 팀에는 소위 수퍼개발자라고 하는 사람들이 몇명있어서 문제가 생기면 누구나 이사람들에게 물어봐서 해결을 한다. 하지만 지납 난디는 이 수퍼개발자들이 오히려 고민거리가 되었는데 이 팀에서는 1일 스크럼 이후에 그날 누구랑 페어 프로그래밍을 할지를 추첨식으로 정해서 같은 사람과 계속 페어프로그래밍을 하지 않도록 하고 있었다. 수퍼개발자와 페어프로그래밍을 하게 되면 잘하는 개발자들이 그렇듯이 무수한 단축키로 빠르게 개발하면서 설명도 자세하게 하지 않기 때문에 오히려 더 어렵고 그 수준차이가 너무나서 오히려 자괴감이 들게 되어서 당일날 페어 프로그래밍의 짝을 선정하는 과정이 두렵게 느껴지기 시작했다. 그래서 이 팀에서는 일일 스크럽 이후에 1:1 피드백을 도입해서 매일 1:1로 커피먹으러 나가서 회고를 하도록 했다. 지납 난디와 같은 생각을 하던 사람들이 여럿이 있었기 때문에 이에 대한 얘기를 들은 수퍼개발자는 변하기 시작해서 설명도 자세히 해주고 페어프로그래밍에서 키보드도 다른 사람에게 내어주기 시작했다. (personal한 환경에서 하는) 커뮤니케이션이 답니다.
어려움에 부딪혔을 때는 문제의 답이 커뮤니케이션이 아닐까 고민해 봐야 한다. 보통 애자일을 도입하거나 프로세스를 확 바꾸는 것을 시도하기 쉬운데 의외로 많은 문제는 커뮤니케이션에 있고 이를 통해서 해결할 수 있다.
최보나님의 발표는 무난한 느낌이었다. 중요한 혹은 핵심적인 내용이 이런 경우가 많은데 너무 중요한 한편으로는 또 너무 뻔하기 때문에 어떤 임팩트를 주기는 어렵다. 자칫 지루하고 뻔할 수 있는 주제를 사례를 들어서 설명해서 흥미롭게 들을 수 있었다. 누구나 커뮤니케이션이 중요하다는 건 당연히 인지하고 있지만 의외로 또 쉽게 잊을 수 있는 부분이기도 하다. 사례처럼 간단히 문제가 해결되지는 않겠지만 그 과정자체가 커뮤니케이션인거니까... 다른 내용보다도 애자일 하는 사람은 지속적으로 개선하는 사람이라는 말이 인상적!
Lean Startup in Practice - 정지웅
클럽배닛의 CEO이신 정지웅님이 린 스타트업을 자사에 적용한 경험담을 나누어 주셨다. Eric Ries는 스타트업을 세상에 존재하는 문제를 해결해서 사업화하기 위한 특수한 목적을 가진 조직이라고 정의했고 스타트업은 그 반응을 증명하기 전에는 회사라고 부르기도 어렵다. 다시 말하면 불확실성속에서 많은 위험요인을 감수하고 세상에 존재하는 문제를 보다 명확히하고 그에 대한 해답을 찾아 시장과 고객앞에서 증명해내는 조직이라고 할 수 있다. 그래서 스타트업은 불확실성에 관한 것이고 새로운 실험적인 방법을 시도해 봐야하고 90%이상의 스타트업은 실제로 실패한다. 그럼 왜 실패하는가?가가 문제인데 대부분의 스타트업은 다음의 문제-해답-비용-타이밍의 4가지 요소에서 확실성을 확보하기 전에 모든 자원을 잃고 소멸되게 된다.
- 고객이 원하는 진짜 문제를 찾아내지 못함.
- 진짜 문제를 찾았더라도 그에 맞는 해답을 찾아내지 못함.
- 진짜 해답을 찾았더라도 그 해답을 증명하기 위해 너무 많은 비용을 소모.
- 많은 비용이 뒷받침되더라도 많은 시간을 소요해서 시장의 상황이 달라지면 문제와 해답은 모두 무효가 됨.
폭포수 방법은 문제와 해결방법이 명확한 경우에 좋다. 정지웅님이 스타트업을 시작하면서 처음에는 1forMe라는 서비스를 만들었다 1forMe는 Etsy의 카피캣으로 핸드메이드 셀러마켓이었는데 핸드메이드를 하는 사람들이 다들 좋다고 해서 금새 셀러들을 모았는데 오픈하고 나니 국내에서는 핸드메이스 시장이 작어서 고객이 없었다. 이 문제를 못보고 폭포수 방법론으로 개발해서 런칭까지 한 후에 문제를 발견하고도 해결하는 대신 사이트를 리뉴얼 했었다. 두번째는 Torsto라는 서비스였는데 파워블로그들의 공동구매를 플랫폼화한 서비스로 이미 존재하는 문제를 비즈니스모델로 만들었다. 반응도 좋아서 오픈 첫날 매출이 천만원이나 찍었었지만 이제 사람들이 블로그의 공동구배를 믿지 않게 되는 분위기라 시장의 타이밍이 좋지 았았다. 하지만 pivot을 하지 않고 활성화를 해볼려고 폭포수 프로세스로 밀어붙였고 더이상 성장하지는 못하고 다른 서비스로 확장할 수 있는 모델도 아니었다.
애자일 방법론은 고객이 자신들이 원하는 것을 제대로 설명을 못하기 때문에 개발프로세스를 짧게 반복하면서 고객이 진정 원하는 것을 찾아내는 과정이다. 이와 비슷하게 린 스타트업은 불확실한 문제를 점진적으로 검증하면서 그에 맞는 해결책을 함께 만들어나가는 비즈니스 방법론으로 시장조사에 기초해서 애자일 프로세스를 적용하고 시장소자 데이터나 상황이 달라지만 애자일 프로세스를 재 적용한다. 언제든지 달라질 수 있기 때문에 ongoing review하고 ongoing development한다. 무엇이 맞는지에 대한 보장이 없으니 핵심만으로 아이디어를 빨리 구현하고 실제 수치를 측정한다. 사용자의 의견같은거 말고 수치로 측정할 수 있는 데이터를 만들로 린으로 검증하는 과정을 방복한다.
IDEAS 과정에서는 무엇이 문제인지 알수 없으므로 계속 회의하지만 아이디어단계에서는 답이 나올 수 없다. BUILD 과정에서는 빨리 오픈하고 빨리 피드백을 받아야 한다. 중요하지 않은 기능을 다 제거해야 하는데 중요한 기능을 생각하는 것보다 훨씬 적을 수 있기 때문에 가장 중요한 것에 집중하고 나머지는 계속 버려나가는 과정을 반복해야 한다. MEASURE 단계에서는 객관적인 지표를 뽑아내야 한다. 각자 선호하는 것들이 있지만 여기서 필요한건 객관적인 지표이다. 수많은 지표들이 있는데 무엇이 중요한지를 결정해야 하고 지표를 실제로 A/B 테스팅등으로 확인해 보고 사용자의 피드백을 받아야 한다. 린 스타트업의 원리는 답을 알기힘든 큰 변화를 추구하는 개인이나 신규 서비스를 만드는 소규모 조직이나 신규 사업을 하는 내부 조직등 어디나 적용할 수 있다. 실제 적용할 때는 pivot을 하는 용기를 내는 것이 정말 중요하고 pivot을 하는 것은 생각보다 어렵다.
개인적으로는 오랜만에 정지웅님을 뵙게 되서 반가운 세션이었다. 몇번 얼굴을 뵌 적이 있어서 SNS에서 소식은 듣고 있었는데 사실 클럽베닛이 이렇게까지 성공을 하고 있는 줄은 몰랐다. 이 세션은 개발에 대한 세션이라기 보다는 스타트업의 프로세스에 대한 세견이었지만 이런쪽에 대해선 잘 모르기 때문에 더욱 흥미로왔다. 린 스타트업책은 한번 읽어봐야겠다.(번역서 얘기를 들은것 같은데 검색해봐도 못 찾겠다. ㅠㅠ) 일단 몇년간 실패를 한 경험은 나눈 세션이라서 알차고 좋았다.
ATDD: 스펙도 애자일하게 쓰자 - 황상철
스펙을 제대로 작성하는 것은 구식이다?에 나오는 "스펙을 한번이라도 제대로 작성해 본적이 있는가?"라는 글을 보시고 발표를 하기로 했다고 하셨다. 스펙(Specification)은 문서나 다이어그램 등이 있는데 그럼 스펙은 언제 얼마만큼 작성해야 하는가? 황상철님은 스펙은 개발전에 쓰고 개발을 할 수 있으면 멈추면 되고 다시 개발을 할 수 없게 되면 스펙을 쓰면 된다고 하셨다.(표준이나 WBS등이 중요한게 아니다.) 스펙 작성에는 대표적으로 UML이 있는데 오랫동안 UML을 가르쳤지만 여태까지 UML을 잘 쓰는 개발자는 한번도 본적이 없다고 하셨다. 그럼 개발자가 UML을 잘 모르는게 잘못인가생각하면 그렇지는 않다. 보통 UML은 너무 복잡하기 때문에 개발자들은 잘못 그릴까봐 오히려 안그리게 된다. 그 외에 유즈케이스가 있는데 유즈케이스는 코드수정에 따른 버전업이 문제다.
그러면 스펙과 코드가 일치하지 않는 것이 정말 문제인지 생각해 보자. 문제라고 가정해보면 Specification by Example에서 제시한 Living Document가 대안이 될 수 있는데 여기서 얘기하는 스펙은 코드와 시스템을 의미한다. 스펙에 해당하는 코드는 JUnit등으로 작성한 유닛테스트나 Cucumber등으로 작성한 테스트가 있고 이것을 시스템(specflow)으로 만들 것을 제시하고 있다. 그럼 문제가 아니라고 생각하면 어떤가? 스펙도 우유처럼 유통기한이 있어야 한다. 스펙을 어떤 기간동안의 스냅샷으로 보고 그 기간동안만 맞추면 되고 그 이후에는 코드로 보면 된다. 현재 하고있는 nForge 프로젝트에서는 Markdwon으로 스펙을 쓰고 있는데 팀원들이 다양한 OS를 사용하고 있기 때문에 어디서나 쉽게 작성하고 출력을 자유롭게 할 수 있기 때문에 Markdown을 선택했다. 스펙에는 반드시 완료조건(AC, Acceptable Condition)을 적어서 개발이 완료되어야 하는 조건을 명시하고 있다. 스펙에 AC를 잘 작성해 놓으면 테스트 시나리오는 대부분 커버할 수 있다. 추가적으로 테스트를 피라미드로 나타내면 맨 아래 유닛테스트가 있고 그 위에 서비스테스트가 있고 가장 위에 UI 테스트가 있다. UI 테스트가 제대로 이득을 보지 못하는 이유는 서비스 테스트를 제대로 하지 않기 때문이라고 생각하는데 보통은 유닛테스트를 작성한 다음에 UI 테스트를 작성하곤 한다. 서비스 테스트의 영역을 넓히는 것이 좋다.
다른 세션에 비해선 짧은 세션이었다.(20분 정도였나?) 이 세션을 듣고 생각해 보니 나는 스펙을 작성해 본 적이 없다. 예전에 회사에서는 CMMI 한다고 문서들을 만들기도 했지만 그건 보여주기 문서였지 사실 개발을 위한 문서는 아니었다. 그래서 처음에 들을 때 이 스펙을 나는 기획서라고 생각하고 있었다.(어떤 의미에선 비슷하기도 하지만 어쨌든 기획서를 보고 개발을 하기 때문에) 사실 문서화를 좋아하는 편은 아닌데(코드에 문서가 섞이는걸 더 선호한다.) 세션을 듣다 보니 개발자가 개발할 내용을 확실히 하기 위해서 적는 것을 스펙으로 이해했고 저런 문서를 개발자가 정리하면 개발영역도 명확하고 다른 사람들과 의논하기에도 괜찮겠다는 생각이 들었다. 담에 해봐야지...
댓글 없음:
댓글 쓰기