“As a, I want, So that”의 해로움

by David Evans and Gojko Adzic

Posted on September 25, 2014

원문 : Crisp’s Blog : “As a, I want, So that” Considered Harmful

당신이 애자일 프로젝트에서 일하고 있다면, 당신은 틀림없이 업무의 백로그를 기록하는데 스토리를 사용할 것이다. 그리고 당신이 스토리를 사용하고 있다면, 또한 틀림 없이 다음 형식을 사용할 것이다 :

• 사용자 또는 스테이크홀더(실무자) 로서
• (As a user or stakeholder type)
• 어떤 소프트웨어의 기능을 원한다
• (I want some software feature)
• 어떤 비즈니스적인 가치를 위해
• (So that some business value)

애자일 실천법에 관심이 있는 한 사람으로서, 애자일 팀에게 스토리의 중점이 형식이 아니라 텔링에 있다는 것을 상기 시키기 위해, 나는 약간의 대안을 제공하고자 한다. 생각의 공유는 스토리 카드가 아니라, 대화에서 시작된다. 나는 당신에게 짧은 글로 쓴 형태로 스토리를 ‘말하기 위한’ 새로운 방식을 제공함으로써, 당신의 팀이 사람들을 위한, 위대한 소프트웨어를 만들고 있다는 것에 대해 높은 수준의 참여와 관심을 가질 수 있게 만들 수 있길 바란다.

누가, 무엇을, 왜 (Who, What, Why)

“…로서…를 원한다…기 위해(As a…I want…So that…)” 형식의 장점이 무엇인지 부터 알아보자.

• 스토리의 누가, 무엇을, 왜 (Who, What, Why)를 정의한다. 누가 사용할 것인지 또는 누구에게 가치가 있는지? 무슨 기능을 제공해야하는지? 왜 이것이 가치가 있거나 중요한지? 이것 모두는 스토리에 대해 논의할 때 기반이 되는 것들이다.
• 기억하기 쉽다. 한번만 배우면 누구도 까먹기 힘들 것이다.
• 잘 알려져 있다. 이미 사용해 본 사람들은 새로운 팀이나 프로젝트에 참여하더라도, 형식 때문에 혼란스러워 하지 않아도 된다.
• 간결하다. 이 구조는 Who/What/Why가 한 문장으로 표현되도록 권장한다.

그래서, 한 문장으로 핵심을 포함하고, 간단하며, 기억하기 쉬운 이 구조의 단점이 무엇일까? 내 생각에, 이 형식이 점점 망해가는 이유는 자가당착에 빠졌기 때문이다. 참신하고 독창적이었지만, 너무 대중적이었기 때문에 엘리베이터 배경음이 되어버린, 한물 간 히트곡 처럼 되어버렸다. 이 형식은 널리 이용되면서, 이제 입문서에서는 다루지도 않는 정해진 법칙이 되어버렸다. 그것은 더이상 형식의 표현이 아니라, 상상력을 옭아매는 스토리의 껍데기가 되어버렸다. 이제는 아무나, 아무 단어들을 엮어서 애자일 스토리같은 말을 만들 수 있다.

왜 거슬리는가?

스토리를 처음으로 제안할 때, 그 무엇보다도 중요한 것은 그것을 바꾸는 것이 왜 가치가 있는 것인지 분명히 표현하는 것이다. 개발팀의 입장에서는, 아무 것도 하지 않는 것이 항상 가장 쉽고 비용이 적은 선택이기 때문에, 변화를 요구하기 위해선 명백히 합당한 이유가 있어야 한다. 그것은 일반적인 형식에서 “…기 위해(So that…)”절에 들어가야 하지만, 잘못 사용 됨으로서, 이제는 단지 “…를 원한다(I Want…)”에 딸린 표현으로만 남게 되었다. 우리는 무엇을 바꾸어야 하는지 제안하기 전에, 왜 바뀌어야 하는지에 대한 이유를 먼저 설명해야한다.

Chris Matts는 일반적으로 사용하는 스토리 형식을 개선했다. 그는 “So that…“대신, 문장을 “In order to…“로 시작할 것을 제안했다. 이것은 실무자에게 작업의 가치를 전달하기위한 최고의 위치이다.

간단하고 효율적인 대안은 다음과 같다 :

• 어떤 비즈니스적인 가치를 얻기 위해
• (In order to achieve some business value)
• 실무자 로서
• (As a stakeholder type)
• 시스템의 새로운 기능을 원한다
• (I want some new system feature)

누가 신경쓰는가?

스토리 형식의 “…로서(As a…)”부분의 목적은, 시스템이 가져야 할 기능들의 목록을 늘어놓기 보다는, 사용자 관점에서 스토리를 이야기 하도록 하는 것이다. 그것은 우리의 일을 더 인간적으로 만들고, 애자일 팀에게 그들이 단지 소프트웨어를 만들 뿐만 아니라, 사람들이 사용하는 방식에 영향을 준다는 것을 상기시킨다.

스토리 기술의 이점을 최대한 활용하기 위해, 당신은 이 스토리로 인해 생길 영향으로 인해 이득을 얻을 사용자의 퍼소나를 구체화 해야한다. 스토리를 명확하게 하고 싶다면 다음과 같이 형용사를 사용해라. “바쁜 경영진”, “안정지향적인 투자자”, “정규직”, “스트레스 받은 엄마”, “지루한 10대” 등등. “사용자”나 “고객”과 같은 일반적인 표현을 피해라. 만약 당신의 스토리가 모든 사용자들에게 동등한 혜택을 줄 수 있는 경우, “누가(Who)”절을 모두 생략하고, 차별된 혜택을 줄 수 있는 스토리들을 남겨두어라. 다음과 같이 사람이 아닌 것들은 반드시 피해야한다 “시스템”, “데이터베이스”, 또는 “PO(Product Owner)” 까지도. Gojko Adzic는 다음과 같이 말했다. “시스템은 아무것도 원하지 않는다. 시스템은 오직 자고 싶어할 뿐이다.”

스토리가 항상 사용자의 시점으로부터 말해질 필요는 없으며, 또한 항상 “<누구>로서 내가 <무엇을>을 원한다"는 식으로 말해질 필요도 없다. 왜냐하면 우리는 특정 사용자의 요구사항과 상관 없이 가치를 만들어 낼 수 있기 때문이다. 좋은 소프트웨어는 친절한 식당과 같다 - 종종 우리는 요구하지 않아도 제공되는 작은 것들에서 기쁨을 얻을 수 있다.

그러므로 당신은 변경으로부터 이익을 얻는 것이 누구인지 확인할 수 있는 형식을 사용해도 되지만, 변경에 대비하는 형태로 표현할 수도 있다. 이 전통적인 방식의 예시를 참고해보자 :

• 구매자로서(As a),
• 카드 번호를 입력할 때 내 카드 번호와 맞지 않는 카드 종류가 보이지 않길 원한다(I want),
• 그러면(So that) 나는 오직 내 카드 번호와 맞는 종류의 카드만 볼 수 있다.

이것은 딱딱하고 어색하게 들린다. 다음 형식이 더 읽기 좋지 않은가?

• 카드 정보를 입력하는 구매자의 시각적 반응을 돕기 위해(In order to),
• 우리는(We will) 매치되지 않는 카드 종류를 순차적으로 숨길 것이다. 카드 정보가 입력되는 동안.

이 형식에서 우리가 “무엇을(What)” 할 것인지가 “우리가…할 것이다(We will…)”로 표현되면서, 여전히 “누구(Who, 카드 정보를 입력하는 구매자)”를 어떻게 정의 하는지 주목하자.

무엇이 새로운가?

“…기 위해(In order to…)” 구문에서 스토리의 “Why”를 확인했고, “…를 위해(for..)” 또는 “…로서(as a…)”구문에서 “Who”를 확인할 수 있었다. 스토리는 소프트웨어에서 “무엇(What)”이 추가 또는 변경 될 것이라고 기술하면서, 작업을 요청한다.

내가 본 일반적인 문제 중 하나는, 스토리의 “…를 원한다(I want…)”구문은 충분히 명확하지 않고, 가끔 이미 존재하는 동작 또는 기능과 중복 된다는 것이다.

이것을 극복하고 스토리의 “What”이 짧으면서도 핵심을 놓치지 않도록 하기 위해서는, 나는 그것이 제품이 새로이 가질, 지금은 가지고 있지 않은 새로운 동작이나 기능을 강조하도록 동사구로 시작 하는 것을 선호한다.

내가 “우리는…것 이다(We will…)”가 포함된 동사구를 앞에 둔 것에 주목하자. 동사구는 개발팀이 기능이나 동작을 제품에 추가하는 작업이 아니라, 제품이 가져야 할 기능 또는 동작을 기술하여야 한다.

예를 들면, 스토리의 “무엇(What)”이 입력된 신용 카드 앞자리와 일치하지 않은 카드 종류를 숨기는 기능에 대한 것이라면, 다음 문장들에 포함된 제품에 중점을 둔 “우리(We)”는 유효하다 :

• 우리(O)는 카드 종류를 숨길 것이다. 입력된 카드 넘버와 맞지 않을 경우.

그러나 이런 팀에 중점을 둔 “우리(We)”은 그렇지 않다 :

• 우리(X) AJAX 호출을 하도록 만들 것이다. 카드 유효성 확인을 위해 숫자 2자리가 입력되면.

비슷하게, 이 경우에도 유효하다 :

• 우리(O)는 지불 일자를 포함할 것이다. 트랜잭션 리포트에.

하지만 이것은 아니다 :

• 우리(X)는 SETTLEMENT_DATE 컬럼을 추가할 것이다. 트랜잭션 테이블에.

차이가 미묘하다고 느껴진다면, 스스로 작성한 구현 세부사항에서 ‘시스템은…’, 또는 제품을 이름을 사용하여 ‘Ex-Sell(제품이름)은…’ 이라고 사용한 부분을 찾아보아라.

무엇을 바꾸었나?

앞에서 이야기 한 것 처럼, 스토리를 너무 짧게 기술하는 것은 종종 변경사항에 대한 범위를 모호하게 만들 수 있다. 필요한 작업(“What”)이 정확하게 기술되었더라도, 그것을 구현하기 위해 팀의 공수가 얼마나 필요한지는 변경 사항이 지금과 얼마나 차이가 있느냐에 달려있고, 그것은 모두에게 명확하지 않을 수도 있다.

예를들면, 당신이 이 금융 거래 시스템을 위한 스토리의 규모를 추정해야한다고 상상해보자 :

• 규정을 지키면서 거래를 계속 하기 위해,
• 거래자로서, 나는 전체 거래량이 일일 거래량의 90%에 도달했을 때 경고 메시지를 원한다.

요구사항은 명확히 기술되었지만, 우리가 관련 시스템에 익숙하지 않다면, 우리는 표면적으로 드러난 부분이 주요 변경인지 아닌지 이야기 할 수 없다. 다음의 가능성들을 생각해보자 :

• 기존에 일일 거래량에 대한 개념이 존재하는가? (그렇지 않으면, 이 스토리는 새롭게 많은 것을 구축하여야 하고, 높은 복잡도를 가진 작업이 될 것이다.)
• 시스템이 거래자의 일일 거래량을 제한하는 기능을 가지고 있는가? (그렇다면, 이미 존재하는 로직을 이용해 경고하는 작은 기능만 추가하면 될 것 이다.)
• 이미 경고 기능이 있지만, 거래량이 80%에 도달할 때 실행 된다면? (경고 임계치를 90%로 수정하기만 하면 될 것이다.)

이와 같이 핵심은 동작의 기술이 명확하더라도, 스토리를 구현하기 위한 복잡도가 얼마나 되는지 알기에는 충분하지 않다는 것이다. 우리는 또한 기존의 동작에서 얼마나 변경되어야 하는지 알아야 한다.

##”반면에 지금은…(Whereas currently…)”을 사용해보자

내가 이 문제를 해결하기 위해 이용한 방법은, 스토리 형식에 “반면 지금은…(Whereas currently…)” 또는 “대신에…(Instead of…)”로 시작하는 새로운 절을 더하는 것이다.

이 추가 절의 용법은, 제품이 이미 가지고 있는 것과 추가되어야 하는 것 사이를 가능한 명확하게 구분하는 것이다.

아래 예시와 같이, 기존 스토리에 이 방법을 적용하면 다음과 같이 수정 될 것이다 :

• 거래자가 거래량 제한을 최대한 활용하도록 돕기 위해
• 시스템은 총 거래량이 일일 거래량 제한의 90%에 도달 할 경우 거래자에게 경고할 것이다.
• 반면에 지금은 일일 거래량 제한에 도달 하더라도 모든 거래가 정지 될 뿐 아무 경고도 없다.

형식에 얽매이지 마라!

나는 당신에게 스토리의 형식을 표현하는 방법을 수정하기 위한 약간의 아이디어를 줬지만, 형식보다는 당신이 스토리를 정의하고, 논의하고, 구체화하고, 궁극적으로는 구현하기위한 프로세스가 더 중요하다는 것을 기억해야한다.

스토리는 즉시 논의되어야 하는 실제의 정보를 담기위한 이상적인 수단일 뿐이다 - 스토리 카드는 어떻게 당신이 자신의 제품을 개선할 수 있는지에 대한 대화를 담기 위한 어음이다. 당신이 카드에 기록한 정보가 틀리지 않았다고 가정한다면, 어떤 형식이든 논의를 시작하기에는 충분할 것이다. 하지만 카드의 내용이 옳지 못하다면 어떤 형식으로 쓰던 똑같이 나쁠 것이다.

당신의 고객들이 사는 것은 당신의 스토리가 아니다. 그들은 스토리의 결과를 사는 것이다. 스토리의 스타일을 변화시키고, 다양한 형식을 실험해보다보면 새로운 것을 생각해내거나, 결과물을 더 빠르고 정확하게 구현해내거나, 생각들을 공유하는데 도움을 얻을 수 있을 것이다. 추가적으로 다음의 아이디어들도 시도해보자 :

• 스토리의 이름을 먼저 이야기하고, 상세 내용은 대화를 나누고 난 뒤에 추가한다.
• Product Onwer(PO)가 ‘왜(Why)’ 구문을 쓰고, 개발자가 ‘무엇을(What)’ 구문을 쓰게 한다.
• 일반적이거나 모호한 표현을 피한다.
• Primary Actor(시스템으로부터 가치를 얻을 대상, 핵심 유저 또는 스테이크홀더) 이외에 스토리에 관심이 있을만한 새로운 사용자 또는 실무자에 대해서 생각해본다.
• “어떻게 협의 시간을 줄일 수 있을까?” 질문해본다.
• 단어 대신 그림을 이용한다.

스토리를 향상 시키기 위한 조언과 아이디어가 더 필요하다면, 아래의 책을 참고하세요 :

“50 Quick Ideas to Improve Your User Stories” By Gojko Adzic and David Evans