상세 컨텐츠

본문 제목

스토리 중심으로 개발하기

Product - Service - Engineering

by 무병장수권력자 2021. 1. 8. 14:42

본문

개발 입장에서는... 아마도 대부분...
무언가를 만들겠다라고 맘을 먹으면 가장 먼저 SW아키텍쳐(깍두기)를 그리고, 깍두기 하나하나를 세부 설계하고 그 단위로 개발하려고 합니다. 이게 편하고 익숙합니다. 예를 들면.. 네트워크 통신 모듈, 동시 세션 관리 모듈, 캐쉬 데이터 관리 모듈... 이런 식이다. 왜냐면.. SW 설계가 class를 단위로 이루어지기 때문이지요. (실제로 이렇게 설계를 해야 확장성이 높은 소프트웨어가 되긴 합니다.)

그런데.. 실제 사용자 사용 사례에 맞추지 않고 설계와 개발을 하게되면... 소위 over specification을 가지는 소프트웨어가 될 공산이 큽니다. 유연한 확장성을 가진 다는 측면에서는 바람직하겠습니다만.. 간단한 메모장 앱을 개발하면서 향후 계약서 공증 기능을 넣을 생각을 하고 과도한 설계를 하는 우가 만들어 진다면 그건 분명 문제일 겁니다. 특히나 항상 인력이 부족하고 촌각을 다투는 서비스 업계라면 더욱 그럴 것입니다.

첨부링크에서는 이를 고객에게 케익을 제공하는 것에 비유하고 있는데요.

https://www.thoughtworks.com/insights/blog/slicing-your-development-work-multi-layer-cake

 

고객에게 케익을 한번에 주기 어렵다면 조각으로 잘라서 제공하자고 하면서, 케익을 수평 분할을 하지 말라고 합니다. 위에 말씀드린 기술적인 레이어 단위 개발을 지양하라는 말입니다. 즉, 케익을 수직 분할하는 것이 바람직한데. 그래야 하는 이유를 다음과 같습니다.

  • 그렇게 잘라야 어려 층의 맛이 어우려져서 진짜 케익 맛을 알 수 있습니다.
  • 먼저 찍먹해본 조각 케익 맛이 별로이면.. 빨리 버리고 다른 레시피로 바꾸기도 쉽기 때문입니다.

 

한걸음 더 나아가서 조각을 어떻게 자를 건지도 설명하고 있는데요. 어떤 포괄적인 기능을 구현할 때 다음 항목들이 구분의 단위가 될 수 있다는 내용입니다.
- 업무흐름 단계
- 비즈니스 규칙
- 성공 / 실패 경로
- 매개 변수의 데이터 유형
- 입력 옵션 / 플랫폼
- 모호한 용어와 접속사

 

예를 들면 입력 옵션, 플랫폼 기준으로 로그인 기능을 분리한다고 하면 다음처럼 나눌 수 있게 되는 거고,

- 나는 사용자로써 멤버십 인증을 위하여 안드로이드 모바일 폰을 사용해서 로그인을 한다. 

- 나는 사용자로써 멤버십 인증을 위하여 iOS 모바일 폰을 사용해서 로그인을 한다. 

- 나는 사용자로써 멤버십 인증을 위하여 PC를 사용해서 로그인을 한다. 

 

성공 / 실패 경로를 기준으로 분리한다면,

- 나는 사용자로써 멤버십 인증을 위하여 올바른 id/password로 정상 로그인을 한다.

- 나는 사용자로써 멤버십 인증을 하고자하나 잘못된 id/password를 입력하여 로그인에 실패한다.

 

업무흐름 단계는 조금 더 복잡한데요... 아래 그림이 도움이 됩니다. MVP를 개발하고 부가적인 주요 기능을 더해 나가면서 확장된 새로운 스토리를 만들어 나가는 것입니다.

(나머지는 내용이 길어서 원문을 읽어 보시길 꼭 바랍니다. 글 아래에 번역된 포스트도 함께 링크합니다.)

뭐를 해야할 지 모든 팀이 아주 잘 이해하고 있는 상황이 아니라면 무조건 수직으로 잘려진 케익을 정하고, 그 조각 케익이 어떤 모양인지를 함께 만들어 나가는 것이 아주아주 중요합니다. 완벽한 계획, 완벽한 설계는 존재할 수 없습니다. 예전에도 말씀 드렸지만... 그러기에는 요즘 세상은 너무 불확실하고 복잡합니다. 명확한 가치를 담고 있는 작은 기능 단위, 스토리를 기반으로 incremental development를 해야 과제의 실패 확률이 낮아지고 고객과 시장의 요구사항에 지속적으로 근접하는 '살아있는 소프트웨어, 서비스'가 될 수 있을 겁니다.


[원문] https://www.thoughtworks.com/insights/blog/slicing-your-development-work-multi-layer-cake
[번역] https://www.popit.kr/%EA%B0%9C%EB%B0%9C%EC%9D%84-%EC%97%AC%EB%9F%AC-%EC%B8%B5%EC%9D%98-%EC%BC%80%EC%9D%B5%EC%9C%BC%EB%A1%9C-%EB%82%98%EB%88%84%EA%B8%B0/
참고자료 softwaredevelopmenttoday.com/2015/09/how-to-explain-agile-and-incremental-delivery-to-anyone/

 

Slicing your development work as a multi-layer cake

In Agile projects, the goal is usually broken down into discrete units of work that describes a feature or ability to perform an action from an end-user perspective. These blocks of work are usually referred to as ‘user stories’. That leads us to an ob

www.thoughtworks.com

 

개발을 여러 층의 케익으로 나누기 | Popit

* 이 글은 제품 설계와 관리 전문가 Luis Mizutani 가 ThoughtWorks 블로그에 올린 Slicing your development work as a multi-layer cake 을 번역한 글입니다. 애자일 프로젝트에서는, 흔히 목적을 쪼개어 개별 작업 단

www.popit.kr

 

Agile incremental delivery visualized – how to explain Agile and Incremental delivery to anyone | Software Development Today

If you are interested in Agile and if you want to read up on it (reading books, blogs or following discussions on twitter) you soon stumble upon the following picture to visualize incremental value. I believe it’s from Henrik Kniberg: I do understand whe

softwaredevelopmenttoday.com

 

 

 

 

반응형

관련글 더보기