Page History
| Info |
|---|
도메인주도 개발(DDD) 가속화를 위한 도구와 방법을 살펴보자 잘 구성된 팀은 모델링할 때 필요하다면 무슨 도구든지 사용할 필요가 있지만 이것을 가지고 거대한 연회는 하지말자 DDD에서는 문서가 대화를 지배하는 상황을 경계해야할 대상으로 언급하고 있습니다. |
DDD
...
모두가 동의할수 없으나, 간단하게 애자일과 DDD를 한문장으로 정의해보자애자일과 DDD가 추구하는 개발방법을 다음과같이 정리해보았습니다.
- 애자일 : 예측 불가한 도메인때문에 비지니스때문에 ,프로젝트의 라이프 사이클을 짧게하여,지속 수정 가능한 유연한 개발방법 도입 ( 주로 폭포수모델의 한계점을 예를듬)
- DDD : 오늘날 소프트웨어 복잡성은 기술보다 도메인의 복잡성및 변화에 기인하며 도메인을 중심에 두고 소통하고 발견하는 개발방법 도입 ( 주로 전문가와 단절이 된체 기술중심으로 문제를 해결하는 방식의 단점을 예를듬)
이야기하는 패러다임은 완전하게 다르나추구하는 방향은 약간 다를수 있으나,변화하고 복잡해지는 비지니스 모델에 대응하기위해어떠한 개발 문화를 가져야할까대응하기위해어떠한 방법론을 가질것인가? 고민하는 부분은 동일하며 목표 유사하며 목표 달성을 위해 사용하는 도구 또한 상당수 공유하고 있습니다.
애자일이 주로 개발문화에대해 영향을 주었다고하면, DDD는 구현코드에서 도메인의 특성을 반영해야하는것을 중요하게 생각하며,구체적인 구현편으로 이어집니다.
애자일또한 이러한 구현에대해 중요하게 생각하고 있었으나 구체적으로 정리된 버전은 존재하지 않습니다.
그러한 의미에서 애자일의 연속성에서 DDD는 중요한 의미를 가집니다. DDD의 구현편은 다양한 프레임워크에서 구현편이 존재하며 마이크로 서비스에서도 DDD가 적용되고 있는 추세입니다. (국내는 제외)
정작 마이크로서비스,쿠버네틱스등 국내에서도 인프라적인 이야기는 많이 되고 있으나 마이크로 서비스 구현체에 활용될수 있는 DDD의 자료가 거의 없거나 정착이 되지 못하는것은 다소 안타깝습니다.
웹영역에서는 OOP를 개발자의 기술적 역량 파악하는데만 사용 되어왔으며 EJB/컨테이너/컴퓨넌트 모델방식으로 어디에 코딩해야하는지만 신경을 쓰게되었으며
개발자는 OOP능력을 대부분 상실해 갔습니다. 결국 이것은 도메인 모델링자체가 실종하는 결과가 되었으나 그래도 작동해 왔습니다.
그동안 객체지향 사상을 기업 규모 어플리케이션이 어떻게 적용할지에 대해 분명한 비전이 없었다란점을 감안하면
DDD는 비지니스 문제 해결을 위해 OOP의 능력을 활용하고 구현체를 제안 하고 있으며 , 이러한 이유로 DDD는 엔지니어 개발자로서 중요하다고 생각합니다.
구현없이 클릭만으로 모든 비지니스 모델을 만들수 있는 그런시대가 분명 올지도 모르지만
DDD는 생소한것이 아니고, 이제는 다양한 웹프레임워크에 녹여있으며 쉽게 검색가능합니다. (국내 적용사례는 거의 없음)
( MVC가 그래왔던 것처럼 빠르게 뿌리내리지는 못할것같으나 언젠가는 국내에서도 활용하는 기업이 생겨날것으로 기대해봅니다.)
- https://www.baeldung.com/spring-data-ddd
- https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation
- https://medium.com/bestmile/domain-driven-event-sourcing-with-akka-typed-5f5b8bbfb823
- https://medium.com/@qasimsoomro/building-microservices-using-node-js-with-ddd-cqrs-and-event-sourcing-part-1-of-2-52e0dc3d81df
- https://microservices.io/patterns/data/domain-event.html
경계해야할것
애자일을 한다고 DDD를 못하는게 아니며, DDD를 한다고 워터폴을 하지말아야 하는것이 아닙니다.
...
경계해야할것
경계해야할것 몇가지를 알아보고, DDD 도입을 위해 유용한 도구를 살펴보겠습니다.
작업셔플
작업 셔플 만을 이용하여 스토리를 잘정리하고,스프린트 단위로 잘 분류하여 프로젝트를 성공시킨다.
경계해야할것은 이것 자체가 애자일-스크럼을 잘 수행한다 라고 생각하는것이다. 우리 프로젝트는 잘 수행되고 있다라고 착각을 일으키는것이다.
화이트보드에 할일을 포스트잇으로 늘어놓고 완료되면 옮기기만 하는것, 이와 같은 방법은 스크럼을 올바르게 사용하는 방법이 아니다.
...
비지니스 전문가를 프로젝트 초기에 참여시킬수 있는 방법이 필요하며 화이트 보드와 포스트잇이면 충분하다.
프로젝트 초기 핵심 도메인 발견에 혼자만의 심오한 생각이 깃든 기획문서, 화려한 목업 UI, 거창한 UML등 과감하게 버리자
핵심 도메인을 발견하고 가속화하는데 걸림돌이 될뿐이다.
모델링은 전문적일 필요가 없으며 그것을 전달하고자 하는 아이디어이면 충분하다.
...
도전과제
툴설명과는 상관없으며 필자의 뇌피셜이 충만하기때문에
필자의 뇌피셜이 궁금하거나 , 태클없는 분만 열어보기를 권장합니다.
...
| title | 내용 |
|---|
여기서 언급되는 시나리오는 지난15년간 다녔던 모든회사에서 동일하게 경험한 내용을 바탕으로
가상화한 내용이며 지극히 개인적인 경험과 생각이 포함된 뇌피셜임을 먼저 알려드립니다.
기획 문서의 완성도는 기획자 고민 한명만으로 이루어 낼수없으며, 애시당초 퍼펙트한 기획문서는 보지못하였다.
최신 완성품의 내용을 반영하는 기획서 또한 보지 못하였다. 기획서에는 내가 궁금한 내용이 없을뿐더러,
심지어 작동방식을 반대로 설명하는 경우도 있다. 작동기준으로 기획서를 반대로 다시 업데이트하는것 또한 웃긴일이다.
신규 기획과정에서 공유되지 않는 잘못된 모델이 (모델이 아니고 정확하게는 심혈을 기울인 UX이다.)
비지니스 모델을 반영을 하지 못한채 오랫동안 묵혀서 기획 완성본에 들어가 숨어있으며
언젠가 기획문서가 완성되어 개발시작가능합니다란 소식을 듣게 됩니다.
개발자는 장대한 기획서에서 틀린 그림찾기를 시작하고 만약 이것을 빨리 찾지못한다고하면
잘못된 채로 작동하게되며, 심각한 경우 그것이 왜 잘못인지 알지못한채 마법의 기능이 될수도 있다.
폭포수 모델에서 이것은 개발자의 노력을 퍼부어 해결해 왔기때문에, 당연하게 기획의 잘못으로 돌려야만 했고
기획은 도움 안되고,개발자만이 최종 해결자란 인식이다. 필자의 경험상 이와 같은 문제는 항상 반복되어왔다.
기획서를 보면 비지니스 요구사항을 분석하여 반영되었기때문에 준수해야한다란 생각보다
비지니스 요구사항이 존재하기나 한가? 한심한 기획서를 많이 봐왔다. 더 잘못된것은 비지니스 전문가를 배제한체,
개발자 해석으로 변경이 일어나고 타협을 한다란것이다. 뭔가 잘못되지 않았는가?
더욱이 비지니스 요구사항을 분석해야 할 기획자가(정확하게는 BA이다),이제는 비지니스 요구사항보다
화려한 UI(목업)을 그리는데 능력을 사용하기 시작하였다. 기획서를 보고해야하기 때문이다.
그리고 최근 목업툴의 발전으로 심지어 프로튼 화면 수준까지 UX가 작동되기까지 한다.
물론 디자인이 중요할때 UX및 레이아웃을 포함 그것 자체를 기획하는 롤이 있고 중요할수도 있습니다.
DDD에서는 어떠한 롤을 누군가가 해야한다란것을 이야기하지 않습니다. 비지니스 전문가,분석가,개발자 개발에 참여한 모든 사람의 소통을 중요하게 생각합니다.
만약 기획롤이 불분명하다고 하면, 디자이너보다 BA의 역활에 가까운것이 또는 커뮤니케이션을 통해 마법과같은 비지니스의 본질을 파악하여
개발자에게 전달할수 있는 역활에 가까워야 한다란것이 저의 생각입니다.
DDD는 단 한문장으로 이것을 이야기 합니다. "문서가 대화를 지배해서는 안된다."
참고자료 : BA의 역활 https://brunch.co.kr/@hyunda/33
DDD에서 이것은 누구탓도 아니다. 다음과 같은 질문을 모두에게 던진다.
도메인과 관련하여 나만 알고 있는것이 무엇이고? 당신은 무엇을 알고있고? 우리는 무엇을 같이 알고 있으며, 앞으로 무엇을 알아내야만 하는가?
그리고 이 과정은 모험과 같아서 끊임없는 탐구라고 정의를 내립니다.
DDD 도입은 해결책이 아닌 해결책을 찾기위한 과정입니다. 그리고 성공/실패라고 정의내리기도 어렵습니다.
| draw.io Board Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
도메인과 관련하여 나만 알고 있는것이 무엇이고? 당신은 무엇을 알고있고?
우리는 무엇을 같이 알고 있으며 , 앞으로 무엇을 알아내야만 하는가?
숨겨진 도메인의 정수를 찾아내고 발견하기 위한 효율적인 방법과 툴을 찾고 이용하는것입니다.
...
Story Mapping
우리가 해야할것이 무엇인가? 사용자의 입장에서 정리를 하는것이다.
애자일에서 등장한 방법이며 DDD와 중복되는 사항만 간략하게 요약해보자
사용자의 입장에서, 사용자가 이해하는 쉬운 용어를 사용해야한다.
그래야 사용자 관점에서의 좋은 소프트웨어를 만들수 있다.
내부에서 사용하는 용어조차 통일된적이 없는상태라고 하면 각각의 다른분야의 전문가들이 모여
사용자의 입장에서 사용하는 용어를 만드는것이 쉬울까?
더 큰 문제는 내부에서 사용할 잘못된 용어조차 존재하지 않았다란 사실이다.
DDD에서는 내부에서 사용할 보편언어를 통일하고, 그 언어기반으로 도메인 모델을 발견하는데 가속화해야하는것을 강조하고있으며
새로운 도메인모델(용어)를 찾는 활동도 포함되어 있습니다. DDD의 모든 활동 심지어 그것이 코드레벨까지 가야함을 강조합니다.
사용자는 당신을 위한 제품을 원하지 않는다.
스토리 맵핑에서 이상적인 문구는 다음과 같아야 하지만
- 사용자로서 이러한 기능이 있으면 편리 할것같다.
숨겨진 본질은 다음과 같습니다.
- OO 로서 이러한 기능이 프론트에 노출되면 좋겠다.
이것은 사용자의 입장에서 생각하라는 이야기가 아닙니다.
사용자 편의성에대해 사용자와 이야기를 한번도 한적없을 뿐더러 수집해본적이 없다란 사실에대해 이야기를 하고있습니다.
역설적으로 필요한 기능에대해 사용자와의 피드백이없으면, 그것은 사용자를 위한 기능이 아니라 당신을 위한 기능이다란 것입니다.
DDD에서는 구체적으로 다음과 같은 이야기를 합니다.
도메인에 대한 깊은 지식 없이 복잡한 은행 소프트웨어를 만드는것이 가능할까?
누가 은행업무를 아는가? 소프트웨어 아키텍트? 아니다. 그는 단지 자기 돈을 안전하게 보관하다가 필요할 때 인출하려고 은행을 이용할뿐이다.
소프트웨어 분석가? 역시 아니다. 그는 모든 자료가 주어졌을 때 해당 주제에 대해 분석할 줄 알 뿐이다.
개발자? 잊어버리자
그럼 누구일까 바로 은행가이다. 은행업무 체계는 거기에 속해 있는 해당 분야의 전문가들이 가장 잘 이해하고 있다.
우리가 출발해야하는 곳은 언제나 도메인이다.
- 도메인 주도 설계란 무엇인가? 16페이지
참고 링크
DDD가 이야기하는 핵심은
...
...
이벤트 스토밍
참여자는 모두 클래스나 데이터베이스가 아닌 이벤트와 비지니스 프로세스에만 집중한다. 집중하여
핵심 도메인 이벤트를 과거순으로 나열한다.
자신이 개발자라고 하면, 잠시 개발자임을 잊자~ 개발자만 알고 있는 전문 용어는 이 세션에 아무런 도움이 되지 않을뿐더러
핵심 도메인 이벤트를 찾는데 방해가 된다. 이과 정에서 개발 전문 용어가 단한번이라도 나오면 비지니스 전문가의 도움을 받는것을 포기하라, 비지니스 전문가에게 ORM에서 N+1의 문제가 무엇인지 10초만에 설명을 할수있으면 그래도 좋다.
그리고 이벤트를 나열하는 단계에서,제약 사항을 예측하면서 초반에 이야기를 끊는것또한 경계해야한다.
이야기를 많이 끊는 것은 대부분 도메인에 자신있다고 여기는 개발자가 대부분 하게되며
필자또한 그랬던적이 있으며 돌이켜보면 대부분 무례했던것같다. 이러한것이 한번 시작되면
도메인 이벤트 아이디어를 수집은 커녕.. 올바른 순서대로 나열하는것은 불가능하다.
중복을 제거하고 중요하지 않은것은 제거하고 진행방법은 아래에 설명된 규칙을 참고하여 진행하면된다.
끊는것 또한 경계해야한다. 끝까지 경청하고 불필요하면 나중에 제거하면된다.
첫단계에서 중요한것은 중복이 있더라도 빠짐없이 도메인 핵심 이벤트를 나열하는것이다.
이것은 아이디어 단계가 아닌, 숨겨진것을 정수를 찾는 활동임에 유의하자
중복을 제거하고, 중요한 이벤트의 순서를 찾아내는것은 아래에 설명된 추가 규칙을 참고하여 진행하면된다.이와같은 방법은 커뮤니티에 대한 수준을 높이는것이 포함되어 있다. 겸손/경청이 중요함을 다시한번 강조
사용되는 포스트잇 색상
수행자,책임자 : 외국 원서는 사물체를 사람으로 표현하는 경향이 있어 조정합니다. 도메인 이벤트에 관련된 중요한 요소(아이템) 도 포함됩니다.
가입에 관련된것이면 고객일수있고 장바구니에 관련된것이면 상품아이템일수 있으며 승인에 관련된것이면 관리자가 될수도 있습니다.
작성순서
이벤트 작성
- 비지니스 프로세스에 촛점을두고 도메인 이벤트를 최대한 만들어라 - 개발자가 아닌것처럼 개발자 친화적인 용어는 금기(db,데이터,알고리즘등)만들어라
- 이벤트는 과거완료형이여야하며 , 큰 그림에대한 스토밍진행중이라고 하면 너무 자세한 이름이라고하면 다른 이름을 사용해야한다.
- 이벤트가 발생하는 과거순으로 준비된 이벤트를 붙인다.(동시일경우 하부에 위치할수도 있다.)
...
- 이벤트가 정해졌다고하면, 이벤트를 발생시키는 명령을 정의
- 가끔 어떠한 명령은 다른시스템에의해 생성된 이벤트일수도 있다.
- 명령이 수행될때 특정 역활이 중요하다고 하면 노란색으로 상위에 붙이다.
- 명령을 생성하다보면, 생각하지 못한 이벤트를 발견할수 있다. 즉각 표현하자
완성된 이벤트 스토밍의 형태
Story Mapping
아래링크 참고 ( 애자일 열풍때 주로 생겨난 방법으로 한글자료도 다수 )
Example Mapping
아래링크 참고
영문 자료만 다수이고, 한글자료가 거의 없네요
...
Example Mapping
스토리 맵의 연장선으로, 스토리가 주로 사용자 입장에서 필요한것들을 정리하였다고 하면
여기서는 그것을 구현하기위해 구체적으로 무엇이 어떻게 작동하는가? QA입장에 더 가깝다.
BDD에 베이스를 둔 내용이며 다음 BDD자료를 참고바란다.
참고 : BDD (Behaviour-Driven Development)
시나리오에 기반을 둔 테스트 케이스가 작성되며, 구현해야할 내용역시 도출가능한것이 최종 목표이다.
표준버전과 약간 다를수 있으며 표준버전은 더 많은 이야기를 하고있다.
여기서는 필자가 실제 이방법을 사용해 진행했던경험을 바탕으로 간소버전으로 정리해보겠다.
스토리 맵핑에서 스토리를 적당하게 나열하기
스토리를 너무 많이 나열하면, 해당 미팅시간에 완료를 다 할수 없으며 관련내용을 적당한수의 스토리만큼 나눠야하며
미팅참가전에 논의해야할 스토리 범위를 알고 있고 적당히 생각하고 있어야합니다.
이것을 나누는 팁은. 아래에 언급될 케이크 먹기좋게 잘라먹기 링크를 참조
사용자로서 구매성공 하면 알림을 받는다. |
|---|
적절한 케이스가 아닐수도 있지만,이것은 사용자 스토리이다. 하지만 이것만 가지고 개발을 진행하기에는 부족해보인다.
사용자 스토리는 개발용어를 포함하여 개발적인 구체적인 내용을 언급하지 않는게 원칙이기 때문이다.
스토리 기준으로 개발팀이 구체적으로 무엇을 구현 해야하는지 지침서 같은게 필요하며
스토리에 룰과 예제를 추가적으로 연결하여 안개속에 가려져있는 구현해야할 사항에대해 정리하는 시간이된다.
참여자는 BA,QA,개발자 그리고 스크럼 마스터가 진행을 할수있다.
규칙 만들기
푸시시스템은 알림 이벤트 수신시 알림을 보내야한다. |
|---|
유져 스토리에 관련된 규칙(Rule)을 여러개 만든다. 이 Rule이 Task단위,개발자에게 할당 될수있음을 고려하자
규칙은 기획(BA),개발,QA등 이 미팅에 참여한 모두가 규칙을 만들어낼수 있다.
이 규칙에서 중요한것은, 그것을 작동 시키는 주체(ex>푸시시스템)를 할수있다면 명확하게 지정하는게 좋다.
만약에 없다고하면 우리는 그러한 시스템을 아직 가지기전 일것이다.
예를들기
사용자가 구매를하면 1초이내에 실시간 알림을 받는다. |
|---|
그리고 미팅참여자는 룰에 기반하여 위와 같이 예를 최대한 많이 만들어낸다.
최대한 많이 만들어내어야한며 , 바보같은 예라도 상관없다.
오히려 바보같은 예시가 도움이 되는경우도 있다. 영어식 표현으로는 given/when/then 이며.
한국식은 예를 들면이다.
위 와같은 예에 질문 응답시간이 필요하며, 이때 개발자는 현실적으로 작동가능한가? 고민을 해야한다.
여기서 결정난것은 실제 구현으로 이어지기 때문이다.
위 예를 개선하는 방법은 다음과 같다.
실시간이란 물리적 제약을 극복하기 어렵고 5초이내이면 충분하기 때문에 푸시시스템의 최소 전송보장시간은 5초로 조정되고
그에 따른 예 역시 5초로 조정될수 있다.
프로덕트 책임자도 이 회의에 참석을 하였으며, 대부분 어떠한 중요한 규칙의 옵션값을 정하거나 필요없는 기능에 대해 없애는 의사결정을 수행하였다.
Task는 어떻게 나누는가?
Example Mapping 이후 Task 단위를 다시 측정하여 할당하는데 또 추가적인 회의가 필요했다.
이 불필요한 시간을 줄여보려고 Rule과 Task 단위를 최대한 맞추려고 노력을 하였으며
이것을 맞추는데 시행착오를 거쳤다. 어떠한 Rule은 프론트와 백앤드가 같이하는 해야만 하는것
심지어 어떠한 Rule은 원격에 존재하는 개발팀의 도움을 받아야했기때문이다.
Rule을 어떠한 방식으로 다시 나뉠것인가? 그룹핑? SubTask?
이러한 맵핑을 사용하는 팀은 이미 애자일문화가 정착이 되어 있고, 유져 스토리를 활용중에 있으며
유져스토리를 다른 방식으로 분류하고 칸반 보드와 일치를 이미 한 상태였기때문에
새로운 Task 분류법이 칸반 보드와 호환이 되지 않는 문제가 발생하기도 하였고 칸반보드를 수정하였다.
Task를 유연하게 만들것인가? 데시보드를 깨트리는 Task 생성을 금지할것인가? 어려운주제이다.
스토리를 어떠한 Task단위로 자를것인가? 란 주제자체가 사실은 아주 어려운 부분이며
Rule은 스토리 베이스로 한번더 나뉜 형태이기는 하나, 일하기 좋은 단위로 나뉜것은 아니며
불일치 하는 경우가 발생할수 있습니다.
스토리를 일하기 좋게 Task단위로 분류할것인가? 다음 자료를 참고합니다.
참고자료 : https://blogs.adobe.com/agile/2013/09/27/splitting-stories-into-small-vertical-slices/
연관된 DDD 이야기를 하자고하면, 바운디드 컨텍스트를 나누고 결정하는것이 가장 어려웠다.
단순하게 4x4 로 쪼갤수 있는부분이아니고 기술문제를 포함 책임영역까지 고려해야하기때문이다.
큰단위를 작은단위로 나누는것은 사실 세심하고 어려운 공정이다
...
.
...
SWOT 분석사용
DDD를 포함 우리의 DDD가 개발 프로세스가 잘 수행되는지 어떻게 알수 있는가? 스프린트가 끝나게 되면
회고를 통해서 현재의 시스템및,개발 프로세스를 포함 문화를 지속 개선해 나가야한다.
이러한 방법들을 사용하더라도 DDD도입은 여러가지 이유에 의해 맞지 않을수 있다.
그중 하나는 개발수준 때문 일수도 있고 이것을 사용할 개발문화가 준비때문일수도 있고
이것을 운영할 전문가가 없거나, 수직적 워터폴 개발문화가 더 맞을수도 있기때문이다.
마무리
DDD는 특정 한명이 공부하여 시작할수있는 스케일은 결코 아니다.
모두가 공부해야하며 시행착오를 통해 서로에게 또 배워야하는 내용이다.
존재하면 스프린트단위로 수행하고, 없다고 하면
DDD,애자일과 별개로 운영할수도 있다.
강점과 기회는 긍정적인것이라 어떠한 타이밍에 누구든 이야기해도 상관없다.
여기서 중요한것은 모두가 동등한 입장에서 약점과 위협을 이야기 할수 있어야 한다는것인데
대부분의 조직문화 특성상 이러한것을 아무장소 아무상황에 말하기는 쉽지않을것이다.
이것을 자연스럽게 지속적으로 이야기하는 문화가 더 중요하며, SWOT는 그것을 이야기할수 있는 방법중 하나일뿐이다.
...
마무리
여기서 소개된 도구가 언제 사용이 되는가? 에 요약이며 언제 얼만큼 사용해야 효과가 있는가? 는 선택과 팀이 학습해야할 과제입니다여기서 소개된 도구가 어떻게 활용이 되는가 간단하게 요약하며 마친다.
- Story Mapping/Impact Mapping : 중요 프로덕트 요구사항 나열 할때할때 -주로 기획주도 사용자로부터 요구사항접수
- 이벤트 스토밍 : 프로덕트 요구사항을 분석할떄분석할떄
- Example Mapping : 실제 어떻게 작동되어야하는지 ? 제약은 무엇인지? 테스트는 어떻게하는지 개발용어가 등장하기 시작하고 Task단위가 나오기 시작하는 단계 더 구체화(개발용어가 이때부터 등장가능하며,케익을 어떻게 짜를까에대한 고민도 병행됨,아래 링크참고)
- SWOT : 스프린트가 끝날때마다 , 모든것을 점검(회고)하고 다음 스프린트에 영향을 줌스프린트 우선순위 조정에 영향을 줌
도메인 전문가로부터 지식을 얻기위해서는 커피한잔이면 충분하다.
커피한잔으로 가능한 일이면, 위 툴은 필요없어도 됩니다.
DDD에서 커피가 가장 강력한 툴인것을 깨닫는 것입니다.
참고자료
- 스크럼 이해하기: https://medium.com/dtevangelist/scrum-dfc6523a3604
- 이벤트 스토밍 : https://syundev.tistory.com/125
- Example Mapping : https://cucumber.io/blog/bdd/example-mapping-introduction/
- 칸반보드 이해하기 : http://www.ciokorea.com/news/132799
- 먹기좋게 케익 나누기1 : https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/
- 먹기좋게 케익 나누기2 : https://www.visual-paradigm.com/scrum/user-story-splitting-vertical-slice-vs-horizontal-slice/