서비스를 성공적으로 만드는 방법

서비스를 성공적으로 만드는 방법

제품을 올바르게 만드는 것과 올바른 제품을 만드는 것은 다른 문제다.성공을 위해서는 둘 다 필요하다.

고코 아지치영국 애자일 테스팅 사용자 그룹

“

좋은 제품은 모든 기초 중의 기초다. 제품의 품질이 1이라면,브랜드 마케팅은 그 뒤에 따라 붙는 0과 같다. 앞에 1이 없다면, 뒤에 아무리 많은 0이 붙어도 소용없다.

리완창

“샤오미 공동창립자

기능적, 비기능적 요구사항을 올바르게 구현한 동작하는 소프트웨어

기능적 요구사항(functional requirement)

사용자가 직접적으로 이용하는 개별적인 기능에 대한 요구사항

비기능적 요구사항(non-functional requirement)

성능, 신뢰성, 가용성 등과 관련된 요구사항

우리는 소프트웨어를 잘 만들고 운영하고 있을까?

대부분의 프로젝트에서

겪고 있는 문제

테스트 자동화, 자주 검증하는 시스템을 구축하기 힘들다.

QA에 많은 책임이 몰리고, 오류가 잦다.

커뮤니테이션 미스가 많고, 변경이 잦다.

누구도 원하지 않는 기능을 개발할 때가 있다.

문제의 진짜 원인을 짚어보자

눈에 보이는 기능이 완성을 의미하지 않는다.

당장 코드 한 줄을 더 빨리 작성하고 그게 무엇이 됐든 동작하는 기능을 빨리 보길 바란다.

역사상 가장 성공한 전투기 F-16 팰콘

1970년대 제트 전투기의 가장 중요한 요소는

속도

하지만 F-16을 성공을 이끈 것은

항속거리와 기동성

F-16의 초기 요구사항은 마하 2~2.5

F-16의 수석 설계자 해리 힐레이커는

그 기능이 왜 필요한지 물었다

미공군은 전투 회피 능력 때문이라 답했고

해리 힐레이커는 전투기의 민첩성을 높이는데 집중했다.

문제를 이해하는 과정

구현에만 신경 쓰지 않고 문제 자체를 더 정확히 이해하는 과정 필요

F-16 사례를 통해 알 수 있는 것

시스템이 어떤 일을 해야하는지 알기 위해서는어떤 문제를 해결해야 하는지 알아야 한다

“”

이것만 하면 될까?

문제와 기능을 이해하는 과정에서 얻은 지식을 정리하는 방법도 필요

변화가 자주 생기는 현대엔 부적합한 경우가 많다.

상세한 명세와 계획을 최신 상태로 유지하는데 비용이 큼

유스케이스하나 이상의 행위자(actor) 사이의 상호작용을 기술

분석된 시나리오는 구체적이고 범위가 넓다.

최소한의

유지 비용으로

문서를 적절하고

신뢰할 수 있게

유지할 수 있는

방법 필요

스토리와 함께하는 서비스 개발

문제 해결 아이디어

사용자의 관점에서 사용자에게 가치를 줄 수 있는 기능을 서술한 것“”

사용자 스토리란?

사용자가 내서재에서 삭제하고 싶은 작품을 선택한 후 숨기기 버튼을 클릭하면 시스템은 HTTP API를 통해 서버에 해당 작품을 삭제하도록 요청한다.

시스템 관점

HTTP API?

서버에 요청한다는 말은 또 뭐지?

사용자는 삭제하고 싶은 작품을 1개 이상 선택할 수 있다. 사용자는 확인을 선택해 삭제 작업을 완료할 수 있다.

사용자 관점

아하! 사용자는 삭제하고 싶은 작품을 선택해 삭제할 수 있구나!

“”

「시스템이 어떻게 동작 하느냐」가 아닌 「사용자가 어떤 목적으로 시스템을 사용하느냐」라는

관점에서 사용자 요구사항을 정리

내서재 개발 사례아이디어 실천법

내 서재의 작품을 삭제할 수 있게 해주세요!“”

코딩은 잠시 멈추고 스토리를 분석해 봅시다.해결해야 할 문제와 만들어야 할 기능을 이해하는 시간이 필요합니다.

분석 회의는 누가 주도하나요?

누구나 가능합니다~!

분석 회의는 누가 주도하나요?

만약 모두가 리더인 조직이라면

스스로 하나의 조직 처럼 사고하고 행동해야 함

자기조직화(Self Organization)

누가 언제 리딩해주지, 왜 아무말이 없을까?

보스없는 조직에서 적응 못할 사람은 떠나라!

모두가 자기의 주장을 내세울 수 있고 누구든지 리더가 될 수 있으며

스스로가 일할 명분을 선택해야 한다.

http://news.mk.co.kr/newsRead.php?year=2015&no=342351

기사에서 발췌

스스로 일정을 결정하고 이해관계자를 찾고 사용자 스토리 분석을 주도한다.

프로젝트 구성원은 한 배를 탄 루피 해적단 같은 팀, 누가 주도하든 적극적인 참여!

또 질문! 누가 참석하나요?

또 질문! 누가 참석하나요?

관계자라면 누구나 가능합니다~!

아무리 검토 과정이 있더라도 혼자 명세를 작성하는 책임을 지는 것은 바람직하지 않다.“

”성격에 따라 CR, 비즈니스 담당자 등도 참석

이상적인 구성원은 4명 이상(기획자, 디자이너, 개발자 그리고 QA)

어쩌고저쩌고 이렇고저렇고


나랑 상관 없는 이야기인데... 어쩌지?

노노노~! 잠깐만요!


나랑 상관 없는 이야기인데... 어쩌지?

버블헤드 인형을 조심하라!http://blog.naver.com/neok3323/220550454744

문제를 창의적이고 효율적으로 해결하기 위해 함께 분석하고 평가해야 한다.

이제 내서재 삭제 기능을 분석해봅시다.

내서재에서 작품을 삭제할 수 있게 해주세요!

그 기능이 왜 필요한 거에요?


사람들이 서재에서 보고 싶지 않은 작품을 삭제하고 싶어 합니다.






그렇군요, 문제를 해결할 또 다른 방법이 떠오르진 않네요. 알겠습니다.

문제를 공유하면








문제를 해결할 더 좋은 방법을 함께 고민해 볼 수 있어요.


스토리는 「주체 / 목적 / 행위」로 정리할께요.

「사용자는 / 보고 싶지 않은 작품을 제거하기 위해 / 내서재를 삭제할 수 있다」


잠깐만요. 내서재를 삭제한다는 말은 오해할 수 있겠어요. 내서재의 작품을 삭제할 수 있다가 어때요?



「사용자는 / 보고 싶지 않은 작품을 제거하기 위해 / 내서재의 작품을 삭제할 수 있다」




「사용자는 / 보고 싶지 않은 작품을 제거하기 위해 / 내서재의 작품을 삭제할 수 있다」




목적은 어떤 기능을 왜 제공해야하는지 행위의 목적성을 나타내요.

오우! 정확히 짚어주셨네요! 음... 현재 내서재 페이지에서 삭제를 바로 제공하긴 힘들 것 같고 편집 모드로 전환해야 할 거 같아요. 어떤가요?


크게 상관없어요. 추후 다양한 편집 기능이 추가될 수도 있으니 그편이 좋은 거 같습니다.

「사용자는 / 작품을 제거하기 위해 / 내서재에서 편집 버튼을 선택해 편집 모드로 전환할 수 있다」

크게 상관없어요. 추후 다양한 편집 기능이 추가될 수도 있으니 그편이 좋은 거 같습니다.


아직 단순한 버튼으로 할지, 라디오 버튼으로 할지 결정하지 않았어요. 지금 UI에 관한 요소가 결정 돼야 하나요?

앗! 제가 너무 구체적인 내용까지 서술했네요. UI에 관한 부분은 추후 다시 논의하는 게 맞는 거 같네요.


「사용자는 / 작품을 제거하기 위해 / 내서재에서 편집 모드로 전환할 수 있다」




「사용자는 / 작품을 제거하기 위해 / 내서재에서 편집 모드로 전환할 수 있다」

전문 용어(예: 개발 용어)나 구체적인 UI 구현 고민 없이 짧고 간결하게 스토리 작성


혹시 삭제 시 작품을 여러 개 선택하여 일괄 삭제 할 필요가 있을까요?


많은 작품을 가지고 있는 기존 사용자는 여러 작품을 한 번에 삭제하고싶어 할 거 같네요!

「사용자는 / 1개 이상의 작품을 제거하기 위해 / 삭제하고 싶은 작품을 여러 개 선택할 수 있다」

많은 작품을 가지고 있는 기존 사용자는 여러 작품을 한 번에 삭제하고싶어 할 거 같네요!


자, 사용자가 내서재의 작품을 삭제하기 위해 편집 모드로 전환하고, 삭제하고 싶은 작품을 여러 개 선택했습니다. 그다음은 어떻게 이뤄지는 게 좋을까요?


음... 확인 버튼을 두고 그 버튼을 선택하면 최종적으로 삭제할 수 있도록 하죠?

「사용자는 / 선택한 작품을 제거하기 위해 / 확인 버튼을 선택해 삭제 작업을 완료할 수 있다」





이 말 속에는 어떠한 기술 용어도, 구체적인 UI 상태도 담고 있지 않아요.




관례적, 패턴적으로 나타나는 UI 요소는 스토리에 담아도 큰 문제 없어요.


음, 사용자가 실수로 삭제할 수도 있지 않을까요?


아! 그렇네요. 삭제 전에 확인받는 절차를 둬야 할 거 같습니다.

「사용자는 / 잘못된 삭제를 피하기 위해 / 작품이 삭제 되기 전 확인 받을 수 있다」



「사용자는 / 잘못된 삭제를 피하기 위해 / 작품이 삭제 되기 전 확인 받을 수 있다」



시스템 관점이 아닌 사용자 관점에서 요구사항을 분석하면 누락할 수 있는 중요한

행위를 쉽게 발견할 수 있어요.

오늘은 여기까지 하시죠? 수고하셨습니다.

감사합니다.

사용자는 / 보고 싶지 않은 작품을 제거하기 위해 / 내서재의 작품을 삭제할 수 있다.

• 사용자는 / 작품을 제거하기 위해 / 내서재에서 편집 모드로 전환할 수 있다.

• 사용자는 / 1개 이상의 작품을 제거하기 위해 /삭제하고 싶은 작품을 여러개 선택할 수 있다.

• 사용자는 / 선택한 작품을 제거하기 위해 /확인 버튼을 선택해 삭제 작업을 완료할 수 있다.

• 사용자는 / 잘못된 삭제를 피하기 위해 /작품이 삭제 되기 전 확인 받을 수 있다.

개발자는 여기에서 많은 정보를 얻을 수 있습니다.

사용자는 / 보고 싶지 않은 작품을 삭제하기 위해 / 내서재의 작품을 삭제할 수 있다.

• 사용자는 / 작품을 삭제하기 위해 / 내서재에서 편집 모드로 전환할 수 있다.

• 사용자는 / 1개 이상의 작품을 삭제하기 위해 /삭제하고 싶은 작품을 여러개 선택할 수 있다.

• 사용자는 / 선택한 작품을 삭제하기 위해 /확인 버튼을 선택해 삭제 작업을 완료할 수 있다.

• 사용자는 / 잘못된 삭제를 피하기 위해 /작품이 삭제 되기 전 확인 받을 수 있다.내서재의 작품 삭제를 요청하기 위한

API가 필요하네요.

사용자는 / 보고 싶지 않은 작품을 삭제하기 위해 / 내서재의 작품을 삭제할 수 있다.

• 사용자는 / 작품을 삭제하기 위해 / 내서재에서 편집 모드로 전환할 수 있다.

• 사용자는 / 1개 이상의 작품을 삭제하기 위해 /삭제하고 싶은 작품을 여러개 선택할 수 있다.

• 사용자는 / 선택한 작품을 삭제하기 위해 /확인 버튼을 선택해 삭제 작업을 완료할 수 있다.

• 사용자는 / 잘못된 삭제를 피하기 위해 /작품이 삭제 되기 전 확인 받을 수 있다.

그 API는 복수의 작품을 삭제할 수 있도록 디자인돼야 하는군요.

디자인이나 마크업이 나오기 전에 API를 디자인하고 비즈니스 로직을 구현할 수 있습니다.

스토리 분석

스토리 분석

스토리 분석

스토리 분석

스토리 분석

기획자

디자이너

백엔드

프론트엔드

마크업

API 디자인

API 디자인 모델 구현

디자인

마크업 개발

UI 개발

API 및 비즈니스 로직 구현

개발 시작 지점

스토리를 기반으로 병렬로 구현을 진행하여 개발 기간을 단축 시킬 수 있어요.

스토리가 있으면 테스트와 TDD가 가능하며 결과적으로 테스트 자동화도 가능합니다.

기능, “내서재의 작품 삭제 기능”스토리, “사용자는 / 1개 이상의 작품을 제거하기 위해 / 삭제하고 싶은 작품을 여러개 선택할 수 있다.”• Given : 사용자가 내서재 페이지에 방문한다. • And : 사용자가 내서재 페이지에서 편집 모드로 전환한다. • When : 사용자가 삭제하고 싶은 작품을 선택한다. • Then : 삭제 대상이 되는 작품이 선택된다.

스토리, ...

감사합니다.

Engineering

서비스를 성공적으로 만드는 방법