사용자 스토리 (User Story Applied) -마이크콘 지음- [한주영, 심우곤, 송인철 옮김 ]책 리뷰 [인사이트 출판사] [5/7] [애자일하게!]

바보야 문제는 도메인(Domain)이야!

소프트웨어의 요구사항 컨테이너로 고민하는 개발자들에게

 

애자일 문화와 함께하는 "사용자 스토리 기법"은 어떠한가?

 

기술적인 문제보다 사람 문제로 생기는 문제가 더 까다롭다.

 

추천도 : 5/6

★★★★★☆☆

 

읽은 기간 📅 : 2021년 6월 8일 ~ 7월 14일 [ 1일 1 뽀모도로 투자 ]

 

이 책을 추천하는 이들 👨‍👧

• 애자일 문화와 XP문화를 선호하는 개발자들.
• 무거운 문서화보다는 가벼운 의사소통과 활동으로 요구사항을 도출하고자 하는 개발자들
• 소규모 프로젝트를 운영하는 개발자들

 

난이도 🦈

중하.

 

관련된 책들 📚

1. 애자일과 관련된 책들
2. XP와 관련된 책들
3. "가치"라는 본질을 강조한 론 제프리스의 [The Nature Of Software Development]
   개인적으로는 점수가 낮지만, 애자일에서 추구해야 하는 좋은 철학을 제시해준 책이라 생각해서 관련된 책에 넣어봤다.

 

한 줄 평 ✍️

2004년에 처음 나온 책이라는게 놀랍다. 상당히 선구안적인 책이라 생각한다.

 

---

 

아마겟돈 딜레마.

 

과학자의 도메인과 기술자의 엔지니어링 스킬이 필요한 곳에

 

과학자만 보내야하는가? 기술자만 보내야 하는가?라는 딜레마를 보여주는 영화 아마겟돈.

[ 물론 그 내용이 주는 아니지만... ]

 

결국 기술자가 해결하러 출동한다.

 

소프트웨어 개발도 마찬가지이다.

 

디지털 기술로 전환될 필요성이 있고, 자동화된 프로세스가 필요한 비즈니스 영역들은 아직도 많이 존재한다.

 

데이터화하여 통계로 시각화해야 하고, 빠르게 달라지는 니즈를 파악해야 하고, 빠르게 진화하고 있는 시장의 요구를 만족시켜야 한다. 동시에 사용자 혹은 소비자의 불편함도 최소화해야 한다.

 

제품에서는 오작동과 품질이 주 목적이라면, 서비스에서는 속도와 가용성 그리고 변화하는 정책에 유연한 소프트웨어가 이상적인 정답일 것이다.

 

하지만 소프트웨어를 만들 수 있는 자는 소프트웨어 개발자이다.

 

그래서 소프트웨어 개발자가 직접 나서서 문제를 디지털로 전환시켜주어야 한다.

 

문제는 개발자들은 도메인 전문가보다 핵심 문제가 되는 영역에 대한 이해가 부족하다는 것이다.

 

그래서 많은 개발자들이 프로젝트 진행에 있어서 디지털 서비스화가 필요한 영역에 도메인들을 습득하러 나선다.

 

설문을 하고, 인터뷰도 진행하며 꽤나 큰돈을 들여 워크숍도 진행해본다.

 

그렇게 나온 요구사항들을 얻어내어 유즈 케이스로 구분하고 소프트웨어 공학의 템플릿에 맞게 문서화를 한다.

 

이제 그것을 코드로 전환하기만 하면 된다.

 

문제는 이 일련의 과정에서 수많은 문제 도메인의 세부사항이 놓쳐지는 순간들이 있다는 것이다.

 

인간은 불완전하기에 결코 불확실한 미래에 확실성을 보장해낼 수 없다. 요구사항은 더더욱 그렇다.

 

그래서 개발이 끝날 때 쯔음 여러 가지 예외 케이스들이 드러나게 되고,

 

개발자들은 속으로 온갖 분노를 삭히면서 요구사항 문서를 다시 수정하러 나선다.

 

악순환의 반복이다.

 

예외 케이스가 발생하는 곳은 정책적으로 상당한 변수들이 존재하는 대목인데,

 

이곳을 고정된 요구사항 문서로 메꾸려는 시도는 일시적인 대안밖에 되지 않기 때문이다.

 

되도록 빠르게 요구사항을 제공해줄 수 있는 사용자로부터

 

인수 테스트를 얻어내고

 

최대한 빠르게 인수 테스트의 결과를 보여줘야 한다.

 

이것이 소프트웨어 공학 프로젝트의 경험으로 얻은 진리이다.

 

피땀 눈물이 베인 이론적이진 않지만 휴리스틱 한 최고의 방법이다.

 

최고의 개발자와 설계자들은 이러한 문화에서 본질을 추출해냈고, 그것에 맞는 원칙과 태도 실천법을 정리했다.

 

그것이 바로 XP이고, 이 책의 부록A에서 XP에 요점을 명확하게 정리해준다.

 

사용자 스토리는 거대한 문서화라는 골리앗을 무너뜨릴 수 있는 다윗이다.

 

빠르고 기민하게 움직여서 거대한 움직임으로 얻지 못하는 결과들을 얻어내는 것.

 

그동안의 프로젝트에서 진행된 무겁고 꼼꼼한 문서화라는 골리앗을 XP에서는 "사용자 스토리"라는 개념으로 무찌르려고 한다.

 

개발자는 개발하는 동안에는 사용자가 되어볼 수 있어야 한다.

 

개발자에게 있어서 소프트웨어의 기술도 중요하지만, 무엇보다 더 중요한 것은 "가치"를 전달해줄 수 있는 포인트를 알아내는 것이다.

 

사실 사용자도 자신의 요구사항을 잘 모르는 경우가 허다하기에, 제삼자가 되어 직접 개발로 구현해야 하는 개발자는 이 요구사항들을 빠르게 확인시켜주어야 한다.

 

그 속에서 "가치(Value)"를 찾아내고 사용자에게 전달해주어야 하는 것이다.

 

이 과정에서 DDD가 강조하는 "공유된 지식"과 "공유된 언어 체계"가 필요하다.

 

이곳에서 싹트는 것은 공감이고, 이해이며 "디자인 싱킹" 프로세스에서 중요하게 생각하는 철학이다.

 

그래서 개발자는 따뜻해야 한다.

 

공감할 줄 알아야 하고 

 

의사소통에 있어서 협력적이어야 하며

 

자신이 개발하고 있는 소프트웨어가 앞으로 사용할 사용자들에게 무한한 편리함을 제공해줄 수 있다는 자부심을 가져야 한다.

 

그런 점에서 사용자 스토리 기술에 대해서 좋은 평가를 주고 싶다.

 

어떻게든 자발적으로 참여하게 하고, 나아가 재밌는 활동이기 까지하다.

 

더군다나 소프트웨어에서 부족한 시각적인 지도를 제공해주기도 한다. [인덱스카드의 배치를 통해서... ]

 

여기에 스토리에 점수를 부과하여 추정치를 처리할 수 있고

 

이터레이션과 릴리즈라는 마일스톤 개념으로 프로젝트에 대한 진척도도 파악할 수 있다.

 

거대한 프로젝트에는 맞지 않을 수 있다는 것이 흠이지만

 

요즘 시대는 마이크로 한 시대가 아닌가.

 

2004년에 처음 나온 책이고 2006년에 번역된 책인데

 

15년이 지금 이 시대에 필요한 책이라고 생각한다.

 

MSA에 정말 잘 맞는 방식이 아닌가 하는 생각이 든다. 개인적으로 6~7/7점이지만

 

현재의 클라우드 기술과 실제 프로젝트에 활용했던 사용자 스토리가 아니어서 시대를 담지 못한 아쉬움에 2점을 깎았다.

 

항상 좋은 책을 번역해서 출판해주는 인사이트 출판사에 고마움을 느낀다.

 

저자 마이크 콘과 깔끔하게 번역해주신 한주영, 심우곤, 송인철 옮긴이에게도 감사함을 느낀다.