User story를 중심으로 개발하고 싶은 Product Owner와 소프트웨어 아키텍쳐에 따라 차근차근 개발하고 싶은 Tech Lead, 우리에게는 지혜가 필요합니다~! 도와주세요~! 🤔 User story 기반으로 개발하려면 적절하게 user story를 디자인하는 것이 매우 중요합니다. 그 과정에서 Implementation 관점의 장점을 살리는 것과 Product관점의 가치를 살리는 것이 서로 충돌하게 될 수 있습니다... 저도 개발에 오래 했지만... 개발 입장에서는... 무언가를 만들겠다라고 맘을 먹으면 가장 먼저 SW아키텍쳐(깍두기)를 그리고, 깍두기 하나하나를 세부 설계하고 그 단위로 개발하려고 합니다. 이게 편하고 익숙합니다. 예를 들면.. 네트워크 통신 모듈, 동시 세션 관리 모듈, 캐쉬 데이터 관리 모듈... 이런 식이다. 왜냐면.. SW 설계가 class를 단위로 이루어지기 때문이지요. (실제로 이렇게 설계를 해야 확장성이 높은 소프트웨어가 되긴 합니다.) 그런데.. 실제 사용자 사용 사례에 맞추지 않고 설계와 개발을 하게되면... 소위 over specification을 가지는 소프트웨어가 될 공산이 큽니다. 유연한 확장성을 가진 다는 측면에서는 바람직하겠습니다만.. 간단한 메모장 앱을 개발하면서 향후 계약서 공증 기능을 넣을 생각을 하고 과도한 설계를 하는 우가 만들어 진다면 그건 분명 문제일 겁니다. 특히나 항상 인력이 부족하고 촌각을 다투는 서비스 업계라면 더욱 그럴 것입니다. 이런 딜레마를 고객에게 케익을 제공하는 것에 비유한 글이 있어서 관련한 제 의견과 원문, 번역문 링크를 공유 드립니다. 첨부 링크를 읽어봐 주세요~ (좋아요와 구독은 사랑입니다 ♡) 상황에 맞는 팀 운영이 필요하겠지만, 대부분은 작지만 '눈에 보이는' 스토리를 구현해 나가면서 우리의 product를 뚱뚱하게 만들어가는 전략이 유효합니다. 첨부 글의 대표 이미지가 많은 것을 함의하고 있습니다. 자동차를 만들기 위해서 바퀴 만들고, 그 다음에 껍데기 만들고, 그 다음에 핸들 만들고 하면... 개발 입장에서는 논리적이겠지만 그런 방식으로는 VUCA의 시대에 대응이 어렵습니다. 일단 스케이트 보드부터 만들어서 앞으로 이동 가능하게 하고, 그 다음으로 옆으로도 움직이는 스케이트 보드를 만든 후, 스케이트 보드에 엔진을 달아서 빨리 달리게 해보는... 이런 접근방식이 필요합니다. 이런 역할은 우수한 팀 리더십의 강한 추진이 필요합니다. 왜냐면 거세게 저항이 있을 수 있거든요. 그래도, 오랜 시간이 걸리더라도 잘 설득해 보시길 바랍니다. 첫단추는 그만큼 중요하니까요.