Page History
...
애자일에서 등장한 방법이며 DDD와 중복되는 사항만 간략하게 요약해보자
사용자의 입장에서, 사용자가 이해하는 쉬운 용어를 사용해야한다.
그래야 사용자 관점에서의 좋은 소프트웨어를 만들수 있다.
내부에서 사용하는 용어조차 통일된적이 없는상태라고 하면 각각의 다른분야의 전문가들이 모여 사용자의 입장에서 사용하는 용어를 만드는것이 쉬울까?
...
새로운 도메인모델(용어)를 찾는 활동도 포함되어 있습니다. DDD의 모든 활동 심지어 그것이 코드레벨까지 가야함을 강조합니다.
사용자는 당신을 위한 제품을 원하지 않는다.
스토리 맵핑에서 이상적인 문구는 다음과 같아야 하지만
- 사용자로서 이러한 기능이 있으면 편리 할것같다.
본질은
- 기획자로서 이러한 기능이 프론트에 노출되면 좋겠다.
이것은 사용자의 입장에서 서라는 이야기가 아닙니다. 사용자와 어떠한 기능이 있으면 편리할것같다란 이야기를 한번도 이야기하고
수집해본적이 없다란 사실에대해 이야기를 하고있습니다.
역설적으로 필요한 기능에대해 사용자와의 피드백이없으면, 그것은 사용자를 위한 기능이 아니라 당신을 위한 기능이다란 것입니다.
DDD에서는 구체적으로 다음과 같은 이야기를 합니다.
도메인에 대한 깊은 지식 없이 복잡한 은행 소프트웨어를 만드는것이 가능할까?
누가 은행업무를 아는가? 소프트웨어 아키텍트? 아니다. 그는 단지 자기 돈을 안전하게 보관하다가 필요할 때 인출하려고 은행을 이용할뿐이다.
소프트웨어 분석가? 역시 아니다. 그는 모든 자료가 주어졌을 때 해당 주제에 대해 분석할 줄 알 뿐이다.
개발자? 잊어버리자
그럼 누구일까 바로 은행가이다. 은행업무 체계는 거기에 속해 있는 해당 분야의 전문가들이 가장 잘 이해하고 있다.
우리가 출발해야하는 곳은 언제나 도메인이다.
- 도메인 주도 설계란 무엇인가? 16페이지
참고 링크
...
완성된 이벤트 스토밍의 형태
...
Example Mapping
아래링크 참고
영문 자료만 다수이고, 한글자료가 거의 없네요
스토리 맵의 연장선으로, 스토리가 주로 사용자 입장에서 필요한것들을 정리하였다고 하면
여기서는 그것을 구현하기위해 구체적으로 무엇이 어떻게 작동하는가? QA입장에 더 가깝다.
대부분의 테스트케이스는 여기에서 도출이 가능하며, 구현해야할 내용역시 여기에서 파악가능해야하는것이 최종 골이다.
표준버전과 약간 다를수 있으며 표준버전은 더 많은 이야기를 하고있다.
여기서는 필자가 실제 이방법을 사용해 진행했던경험을 바탕으로 간소버전으로 정리해보겠다.
스토리 맵핑에서 스토리를 적당하게 나열하기
스토리를 너무 많이 나열하면, 해당 미팅시간에 완료를 다 할수 없으며 관련내용을 적당한수의 스토리만큼 나눠야하며
미팅참가전에 논의해야할 스토리 범위를 알고 있고 적당히 생각하고 있어야합니다.
이것을 나누는 팁은. 아래에 언급될 케이크 먹기좋게 잘라먹기 링크를 참조
사용자로서 구매성공 하면 알림을 받는다. |
|---|
적절한 케이스가 아닐수도 있지만,이것은 사용자 스토리이다. 하지만 이것만 가지고 개발을 진행하기에는 부족해보인다.
사용자 스토리는 개발용어를 포함하여 개발적인 구체적인 내용을 언급하지 않는게 원칙이기 때문이다.
스토리 기준으로 개발팀이 구체적으로 무엇을 해야하는지 개발 명세서 같은게 필요하며
스토리에 룰과 예제를 추가적으로 연결하여 안개속에 가려져있는 구현해야할 사항에대해 정리하는 시간이된다.
참여자는 BA,QA,개발자 그리고 스크럼 마스터가 진행을 하였다.
규칙 만들기
푸시시스템은 알림 이벤트 수신시 알림을 보내야한다. |
|---|
유져 스토리에 관련된 규칙(Rule)을 여러개 만든다. 이 Rule이 Task단위,개발자에게 할당 될수있음을 고려하자
규칙은 기획(BA),개발,QA등 이 미팅에 참여한 모두가 규칙을 만들어낼수 있다.
예를들기
사용자가 구매를하면 1초이내에 알림을 받는다. |
|---|
그리고 미팅참여자는 룰에 기반하여 위와같이 예를 최대한 많이 만들어낸다.
최대한 많이 만들어내어야한며 , 바보같은 예라도 상관없다.
오히려 바보같은 예시가 도움이 되는경우도 있다. 영어식 표현으로는 given/when/then 이며. 한국식은 예를 들면이다.
실시간이란 물리적 제약을 극복하기 어렵고 5초이내이면 충분하기 때문에 푸시시스템의 최소 전송보장시간은 5초로 조정되고
그에 따른 예역시 5초로 조정될수 있다. 프로덕트 책임자도 이 회의에 참석을 하였는데, 대부분 어떠한 중요한 규칙의 옵션값을 정하거나
필요없는 기능에 대해 없애는 의사결정을 수행하였다.
Task는 어떻게 나누는가?
Example Mapping 이후 Task 단위를 다시 측정하여 할당하는데 또 추가적인 회의가 필요했다.
이 불필요한 시간을 줄여보려고 Rule과 Task 단위를 최대한 맞추려고 노력을 하였으며
이것을 맞추는데 시행착오를 거쳤다. 어떠한 Rule은 프론트와 백앤드가 같이하는 해야만 하는것
심지어 어떠한 Rule은 원격(정확하게는 호주개발팀)에 존재하는 개발팀의 도움을 받아야했기때문이다.
Rule을 어떠한 방식으로 다시 나뉠것인가? 그룹핑? SubTask?
이러한 맵핑을 사용하는 팀은 이미 애자일문화가 정착이 되어 있고, 유죠스토리를 활용중에 있으며
칸반보드를 통해 데시보드화가 되어있는 상태였다.
그렇다. 새로운 Task나누는 방식이 도입을 하면 이때까지 사용했던 칸반보드와 호환성이 깨지는일이
발생하
Task를 나누는것은 개발팀의 규모및 릴리즈를 하는방식에 따라 달라질수 있는 부분이다.
1 Rule은 Task단위로 한명의 개발자에게만 할당되어야함- 1 Rule은 여러 Task를 가질수 있으며 여러 개발자에게 할당가능
- SubTask가 완료되고 기존 동작에 영향을 끼치지 않으면, Task는 미리 배포되어도 상관없음
스토리를 어떻게 Task단위로 잘 자를것인가? 란 주제자체가 사실은 아주 어려운 부분이며
Rule은 스토리 베이스로 한번더 나뉜 형태이기는 하나, 일하기 좋은 단위로 나뉜것은 아니며
불일치 하는 경우가 발생할수 있습니다.
참고자료 : https://blogs.adobe.com/agile/2013/09/27/splitting-stories-into-small-vertical-slices/
연관된 DDD 이야기를 하자고하면, 바운디드 컨텍스트를 나누고 결정하는것이 가장 어려웠다.
단순하게 4x4 로 쪼갤수 있는부분이아니고 기술문제를포함 책임영역까지 고려해야하기때문이다
...
.
...
SWOT 분석사용
DDD를 포함 우리의 개발 프로세스가 잘 수행되는지 어떻게 알수 있는가? 스프린트가 존재하면 스프린트단위로 수행하고, 없다고 하면
DDD,애자일과 별개로 운영할수도 스프린트가 끝날때마다 점검을 하고, 다음 스프린트일때 우선순위항목을 결정하는데 사용할수 있다.
강점과 기회는 긍정적인것이라 어떠한 타이밍에 누구든 이야기해도 상관없다.
여기서 중요한것은 모두가 동등한 입장에서 약점과 위협을 이야기 할수 있어야 한다는것인데
어떤 대부분의 조직문화 특성상 이러한것을 말하기가 아무장소 아무상황에 말하기는 쉽지않을것이다.
이것을 자연스럽게 지속적으로 이야기하는 문화가 더 중요하며, SWOT는 그것을 이야기할수 있는 방법중 하나일뿐이다.
...
마무리
여기서 소개된 도구가 언제 사용이 되는가? 에 요약이며 언제 얼만큼 사용해야 효과가 있는가? 는 선택과 팀이 학습해야할 과제입니다.
- Story Mapping/Impact Mapping : 중요 프로덕트 요구사항 나열 할때할때 -주로 기획주도 사용자로부터 요구사항접수
- 이벤트 스토밍 : 프로덕트 요구사항을 분석할떄분석할떄
- Example Mapping : 실제 어떻게 작동되어야하는지 ? 제약은 무엇인지? 테스트는 어떻게하는지 개발용어가 등장하기 시작하고 Task단위가 나오기 시작하는 단계 더 구체화(개발용어가 이때부터 등장가능하며,케익을 어떻게 짜를까에대한 고민도 병행됨,아래 링크참고)
- SWOT : 스프린트가 끝날때마다 , 모든것을 점검(회고)하고 다음 스프린트에 스프린트 우선순위 조정에 영향을 줌
도메인 전문가로부터 지식을 얻기위해서는 커피한잔이면 충분하다.
...
- 스크럼 이해하기: 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
- 먹기좋게 케익 나누기 : https://blogs.adobe.com/agile/2013/09/27/splitting-stories-into-small-vertical-slices/