[06일차] 애자일 방법론 / 협업 - 현업 요청자, 디자이너

 

02. 프로젝트와 산출물 (애자일)

 

폭포수와 비교했을 때 무엇이 다른지 

 

애자일 방법론 

폭포수 방법론은 단계별로, 선형적인 프로세스가 IT 시장에 적합하지 않다고 등장한 방법론 

오픈 했을때랑은 산출물이 옛날것으로 되어 버리는 경우가 나타난다. (IT 시장은 빠르게 변화하기 때문에)

 

단위를 쪼개서 중간 중간에 기획을 넣자! 

쪼개서 몇번에 걸쳐서 진행을 한다. 

 

한번의 스프린트로 묶어서 진행한다. 

 

기획 > 디자인 > 개발> 테스트 

를 스프린트 3주 단위로 여러번 진행을 한다. 

중간에 검토하는 과정도 포함해서 빠르게 변화하는 IT 시장에 대응할 수 있다. 

 

4 가지 핵심 사상 

1) 절차와 도구를 넘어선 개성과 화합 

폭포수는 산출물이 많았다. 기획 뿐만 아니라 개발자도 문서 작업이 많았다. 

- 개성과 화합 

 개발자가 기회기자의 확정된 기획에 맞게 맞춰서 만드는게 아니라 러프하게 잡힌 기획에 맞추어서 

여러가지 시도를 통해 개발을 진행하자 

 

2) 종합적인 문서화를 넘어선 동작하는 소프트웨서 

문서가 아니라 코딩을 하자! 

코딩 산출물 그자체가 중요하자 

 

3) 계약과 협상을 넘어선 고객과의 협력 

개발자 만든 방법론 

고객은 갑, 회사가 된다. (외주일 경우)

=> 대화를 충분히 하면서 협력하자 

 

4) 계획 준수를 넘어선 변화에의 대응 

중간에 다른게 들어오면 다음 스프린트에 넣어주겠다는 내용 

 

사상적인 관점에서 애자일에 대한 관점이 넓어야한다. 

시키는 대로 할거야! 는 애자일 프로젝트에 적합하지 않는다. 

 

 

장점 

- 문서화 단축 / 산출물을 빠르게 만들 수 있다.

폭포수의 경우 스토리보드 문서 양이 많다. 

그것보단 문서보단 코딩에 집중하자 

애자일은 정해진 상황을 중요시 하긴 보단 기획적 가치를 더 중시해서 협력하고 해서 만드는 것이 중요하다. 

 

- 중간 단계에서 변화하는 기획을 수용하여 빠르게 변화될 수 있다. 

시스템적으로 스프린트로 단위로 쪼개져 있기 때문에 중간에 변경을 할 수 있다. 

 

- 개발자와 디자이너의 자유도가 높아서 창의적인 결과를 가져올 수 있다. 

기획자가 두루뭉술 하게 말했을 때, 여기서 디자인과 개발자가 능력을 동원해서 훨씬 더 좋은 결과물을 만들어 낼 수 있다는 내용 

시간적인 부분이랑은 상관없이 

 

- 과정 내내 팀원들과 많은 협의를 진행. 개발자와 디자이너가 끈끈한 협업 관계가 이루어진다

데일리 스크럼 미팅 진행, 같은 코딩을 상의하는 페어 프로그램 등

팀원들이 이상적인 부분을 많이 대화하기 때문에 책임떠넘기는게 아니라 모두의 프로젝트가 된다. 

 

단점

- 복잡한 프로젝트의 경우 참여자 수준이 제각각일 경우 관리가 어렵다. 

전체적인 진척률이나 수준율 차기 때문에 관리가 어렵다. 

언제 결과물이 나올지 가늠하기 어렵다. 

 

- 애자일 사상에 대한 공감이 없으면 아레나 문제가 발생하게 된다. 

창의적인 것을 하고 싶지 않고 정해진 것만 하고 싶은 참여자가 있다면 아레나 문제가 발생한다. 

서로 상호협의도 어렵고 

기본적으로 많은 참여가 필요한 방법론이다. 

 

- 팀과 밀접하게 움직어야하기 때문에 애자일 전문가가 필요하다. 

전문적으로 스크럼마스터, 애자일 코칭 과 같은 전문가가 관리를 해주어야한다. 

 

 

기획자의 산출물 

출처: 강의자료 03-11

 

 

• 기획안 작성 (폭포수와 유사하지만 문서를 최소화 하기 위해)

- User Story 

: 이용자가 어떤 순서로, 어떤 감정을 가지고 무엇 때문에 이용하는지 설명을 하는 시나리오 

기능보단 고객이 왜 무엇때문에 어떤 고객이 사용하는지에 대한 내용이기 때문에 UX, 컨테스츠 

 

- Backlog

유저 스토리를 통해  화면, 일부 기능을 쪼개놓은 것

백로그를 개발자에게 나누어 주며 분담을 하는 툴을 이용하게 된다. 

 

• 프로토타입핑 

- 페이퍼 

- 프로토타입 툴 이용 

개발자와 디자이너가 이해할 수 있을 정도로 

 

스프린트를 몇개를 나누어서 쪼개게 되고 

스프린트 안에는 개발 디자인 테스트가 계속 이루어진다. 

단위로 운영서버에 반영을 할 수도 있다.

 

스프린트 중간에 기획자 참여를 제한적으로 두고 있다. 

개발자와 디자이너의 역량을 최대화 하기 위해서 

 

• 오픈 

그랜드 오픈이면 폭포수랑 비슷하게 오픈 

그때그때 오픈이면 다시 스프린트가 돌 수 있다. 

 

산출물 수 

=> User story, Backlog, 목업, 운영가이드 

확실히 줄었다. 

 

애자일 방법론에 대한 질문 

Q) 세련된 것이다? 

A) 폭포수와 애자일의 관계를 연결해서 공부하는 것이 좋다. 

애자일을 위해 만들어진 Jira, Trello 등이 있는데, 이것을 사용해보면서 애자일자체를 이해하는 것이랑은 차이가 있다. 

사상이나 마음가짐, 팀원 등 이랑 또 다르기 때문에 사상을 잘 이해하고 

프로젝트의 성격과 기획의 양 등을 잘 반영하여서 방법을 선택하는 것이 좋다. 

 

Q) 빠르다?

A) 국내에서는 애자일이 펴질때 빠르다 라는 개념이 확산이 됬다. 

빠르다기 보다는 산출물을 빠르게 볼 수 있다는 장점이 있는 것이다. 

MVP (최소 프로덕트)는 Lean UX 인데, 여기서는 나오면 시장에 내놓아도돼! 인데 

애자일이랑은 다르다. 두가지 부분이 다르다. 

프로젝트에 따라서 폭포수가 오히려 더 빠를 수 있다. 

스프린트가 늘어나면 애자일이 더 느리게 될 수 있다. 

 

 

포인트! 

팀 내 애자일 사상에 대한 공감이 가장 중요하다! 

 

 

03. 협업과 커뮤니케시연 - 현업 요청자 

 

주요 협업자에 대한 이해를 강의 진행할 것이다. 

 

현업 요청자 

현업(現業)? (IT 쪽에서의 )

이 프로젝트를 발주한 사람, 요청한 사람, 프로젝트가 시스템, 오픈 했을 때 운영을 할 사람을 말한다.  

: 프로덕트 개발 진행 후 서비스를 운영하면서 직접 사용하거나 활용해야하는 업무자를 이르는 업계의 슬랭 

 

실제 프로젝트를 떠나서 쓸 사람

스타트업의 경우 현업과 기획자의 구분이 없는 경우도 있다. 

 

IT 팁과 아닌 팀이 구분되어 있으면 존재한다. 

 

큰 Stakeholder가 현업일 가능성이 높다. 

 

> Stakeholder

 : 이해관계자

회사에 대하여 개인 또는 그룹

주주, 채권자, 직원, 소비자, 협력 업테 등 회사의 활동과 관련된 모든 관계자 

 

주로 마케팅 담당자, 영업 담당ㅈ, CS 처리자 등 

고객 서비스 외에 Admin 을 이용하는 내부 사용자 라고 볼 수 있다. 

 

(인하우스 기반 개념) 

 

요청 유형 

1) 업무적 목표를 위한 시스템적 변경 의견 요청 

어드민 써봤는데 업무하는 데에 불편해요~ 

이런 기능이 있었으면 좋겠어요~ 

 

2) 업무 중 시스템 불편 사항 접수 

배너 등록하는데 글씨 복붙 할 수 있게 해주세요~

 

3) 타사 서비스 업체 그림까지 있는 형태 

캡쳐나 그림그려서 이거 만들어주세요~ 

 

4) 와이어프레임 수준의 UI와 설명까지 있는 형태 

 

※ 외주의 경우 RFP 를 통해 받을 수도 있다.  

 

웹 기획 오퍼레이터 VS 서비스 기획자 

웹 기획 오퍼레이터 

- 그대로 구현해 주는 사람 

- 요청에 따라 똑같이 만들어준다. 

(수행만 하는 사람인가? 라고 생각이 들 수가 있다. )

 

VS 

 

서비스 기획자 

- 현업 요청에 대해서 본질을 살펴본다.

- 무엇을 만들 것인지 보단 누가 무엇을 하고 싶은지가 중요하다.  

 

현업과 협의를 위한 Tip 

1) 요청된 UI 는 수단일 뿐! 근본족인 목적을 파악하여 대안을 제시하자 

EX 

빅사이즈 의류 판매하는 전시 매장을 만들고 싶어요~ 요청 

그런데 비지니스에서 사이즈가 개발 리소스를 주게 확정이 안되면, 기존의 시스템을 활용해서 

평가해서 이후에 개발을 진행하자고 제안해볼 수 있다. 

=> 대안을 제시해줌으로서 전체적인 시스템으로 ... 

 

2) 개발을 꼭 해야하는 것은 아니다! 기존 시스템을 최대한 활용해서 안내해주는 것도 좋은 방법이다. 

 

3) 요청 사항이 전체 프로덕트 비지니스 관점에서 충돌이 되거나 불편할 수 있거나 한지 판달할 수 있어야 한다. 

제로베이서 관점에서, 프로덕트만 바라보고 검토해봐야 한다. 

 

 

인하우스 환경에서 

갑과 을로 보면 오퍼레이터가 될 수 밖에 없다. 

협업 관계로 인식하여 기획을 진행해야한다. 

 

 

04. 협업과 커뮤니케이션 - 비쥬얼 디자이너 -1 

 

디자이너 

(UX 디자이너, UI 디자이너,)

 

: 그래픽을 디자인 할수 있는 디자이너를 다룬다. (강의에서는 ) 

 

현재는 기획자가 스토리보드나 와이어프레임에 UI에 구성요소나 UX적인 행태만 다룬다. 

영역을 네모로 표시를 했는데 디자이너가 원으로 하면 그정도의 영역은 수용을 하게 된다. 

 

프로토타이퍼? 

: 회사에 따라 기획자가 하는 경우도 있고 디자이너가 하는 경우도 있다. 

인터렉션 영역이 중요한 것ㄴ데 UX로, 기획 어디로 보는지 회사마다 다르다. 

 

비주얼 디자이너가의 핵심 키워드 

- 레이아웃

 배치를 어떻게? 

- 그리드 

 윗줄과 아랫줄이 같은가 

- 여백 

- 자리수

 가변적인 데이터가 들어올 수 있는 템플릿이기 때문에 

- 레벨 

- 톤앤매너 / 룩앤필 

 전체적으로 컬러와 분위기 

- 포인트 컬러 

 

업무 

기획자가 스토리보드를 전달하면 

1) 드래프트 

시안 작업 

2) 기본 시안과 Variation 

모든 변화 케이스에 대한 디자인 정리 

3) 프로토타이핑 

4) 스타일 가이드 작성 

프론트 엔드 개발자가 화면을 구성하는 데에 용이하도록 

 

드래프트 작업 

: 스토리보드에서 전달된 전체적인 디자인 컨셉과 시안을 만들어보는 작업 

A안 B안 등 기획자와 함께 결정을 하게 된다. 

ex. 검색창 하나만 다루더라도 여러가지 시안을 놓고 결정을 하게 된다. 

 

기본 시안 

표준이 되느 시안으로 이를 기준으로 Variation 작업을 진행하게 된다. 

 

기획자 검토 

- 기획의 의도가 잘 반영이 되어있는지 

- 개발이 불가능한 디자인인지 검토해야한다. 

 

디자인 디렉터 

- 디자인 산출물 관점 뿐만 아니라 전체 운영적인, 리소스에 대한 검토 진행 

- 배열이 잘 되어 있는지

- 운영요소 가이드화가 가능한다. 

 > 디바이스가 다양한데 사이즈에 따라 다양한 버전을 만드는 것이 아니라 

   하나를 가지고 여러곳에 쓸 수 있도록 가이드를 만든다. 

 

하나의 시안 채택 

 

Variaiton 작업 

기본 케이스를 중심으로 여러가지 케이스에 필요한 여러가지 요소를 개발 디자인 한다. 

EX 

버튼이 눌렸을 떄, 커서에 있을 떄, 체크가 되었을 때 등 

 

동작에 대한 케이스, 회원 등급에 대한 케이스 

 

 

04. 협업과 커뮤니케이션 - 비쥬얼 디자이너 -2 

(원래는 7일차에 강의가 배정되어 있는데 ㅇㅁㅇ) 

 

프로토타이핑 

시안과 프로토타이핑이 가장 다른점은 무엇일까?

인터렉션! 이다. 

 

모바일 폰에 넣어보고 움직여 보고 작업해보면서 

인터렉션에 대한 부분을 파악해본다. 

 

인터렉션에 대한 디자인을 세부 디자인 작업을 해본다. 

 

스타일 가이드 (최종적인 개발을 위한 디자인 작업)

포토샵이나 일러스트를 생각해보면 

박스 하나도 코딩으로 바꾸기 위해서 어떤 기준으로 사이즈를 만들었는지 숫자로 표기를 해주어야 한다. 

- 가로, 세로, 정렬 등 

 

스타일 가이즈 엄청 복잡하다 ㄷㄷㄷ 

포토샵으로 작업하는 경우는 가이드를 하는 시간이 더 오래 걸린다. 실제 디자인 보다도 

 

컬러값, 텍스트, 폰트 사이즈 정의 

 

디자인 업무 툴   

Sketch 스케치

포토샵과 일러스트레이션 중간 

그래픽 이미지를 화면단위로 구성하면 제플린 같은 부분이랑 연동하면 사이즈를 바로 분영해준다. 

Variation 작업 단축 

기획자가 하는 것이 나은 경우도 있다. 

 > 기획자 하면서 비주얼 적인 부분도 관심이 있으면 스케치를 경험해보는 것도 좋다. 

 

Jeplin 제플린 

스타일 가이드 자동 생성 

 - 레벨링에 대한 검증이 필요하다.

 

Invision 인비전 

프로토타이핑에 스케치 작업파일 연동 

 

디자이너와 커뮤니케이션 Tip! 

1) 디자인은 디자이너가 전문가다! => 취향으로 접근하지 말아라

기획자 중 가끔 디자인을 컴펌 하려는 경우도 있다.  

 

2) 기획자는 컴펌자가 아니다. 

 

3) 모바일의 가변적인 환경을 이해해야 한다. 

다른 협업자의 입장을 함께 대변해주면서 진행을 해야한다. 

 

 

 

 

 

-----

패스트 캠퍼스 

'서비스 기획서 완성 온라인 완주반 '

강의 스터디