분류 전체보기47 어느 기획자의 공부, INVEST user-story 좋은 유저 스토리란 아래 6가지 특성을 만족한다라고 한다. INVEST in Good Stories, and SMART Tasks - XP123 (French) XP teams have to manage stories and tasks. The INVEST and SMART acronyms can remind teams of the good characteristics of each. Are you a Product Owner or a writer of user stories? I’d love to hear about your challenges and successes at william.w xp123.com 좋은 유저 스토리를 위한 6가지 특성 좋은 유저 스토리를 작성하기 위해서는 좋은 유저 스토리의.. 어느 기획자의 유저 스토리 기획자가 Agile 을 공부한다는 건 유저 스토리에 대한 접근이 아닐까라고 생각해본다. 도서를 보더라고 Agile 의 한 부분으로 유저 스토리만을 다룬 책들이 많이 있다. 프로젝트의 단추인 만큼 중요하지만 다루는 것은 그다지 쉽지 않은 부분이다. 유저 스토리를 이해하기 위해 사전 지식으로 Agile 원칙에 대한 이해가 필요하다. 서론의 시작 대충... 빠르게 개발해서 고객에게 전달하는 개발 방식이다. 그럼 어떻게 빠르게 개발을 할 수 있는가? 1. 개발할 내용을 작고 작은 조각으로 쪼갤 수 있어야 하고. 2. 작게 쪼갠 조각은 독립적으로 동작할 수 있어야 한다. 여기서 포인트! - 두 개의 문장을 작성했을 뿐인데... 막연하다. 어떻게 작성하라고?? - 유저 스토리를 작성하는 방법들이 나온 이유일 것이다.. 어느 기획자의 SRS (Software Requirements Specification) 요구사항 문서에 대한 템플릿은 IEEE 표준 문서가 있지만 실무에서 사용하기는 번거롭고 가독성이 떨어진다. 그래서 회사별, 사람별로 다양한 요구사항 정의서를 가지고 있다. 우리가 흔히 보는 비즈니스 측면이 강조된 요구사항 문서는 대부분 PM 이나 기획자들이 작성을 할 것이다. 실제 개발에서 사용하는 요구사항 정의서는 선임 개발자나 아키텍트가 작성하여 BDD 에 유용하게 사용한다. 기획자도 SRS 쓸 수 있다. 1. 표지 작성 [OOO] 요구사항 명세서, 작성(배포)일, 작성자 소속 2. 문서 확인 고객사와 개발사, 이해관계자들의 협의를 위한 공간 3. 문서 이력 문서의 변경 이력을 작성한다. 4. 서비스 개요 목적, 범위, 용어, 사양(성능), 설계, 참고 문헌 정의 5. 상위 수준 요구 사항 6. 기능.. 어느 기획자의 디자인 가이드 훔쳐보기 기획자도 각 플랫폼별 디자인 가이드를 알고는 있어야 합니다. (옵션 사항) 디자인 가이드는 각 플랫폼의 아이덴티티와 특색을 잘 표현하고 있어서 개발자 사이트를 통해 얻는 것보다 빠르고 쉽게 정보를 습득할 수 있습니다. Microsoft Design 사이트에서는 각 플랫폼의 디자인 가이드로 링크가 연결되어 있어 편하다. www.microsoft.com/design/fluent/#/ Web, Windows, 모바일 등 주요 플랫폼에 대한 디자인 가이드를 확인할 수 있다. 아래 이미지를 보면 좌측에 각 플랫폼을 선택하여 동일 컴포넌트에 대하여 확인할 수 있다. developer.microsoft.com/en-us/fluentui#/controls/mac/date-picker Microsoft 의 Fluent .. 어느 기획자의 PM 업무 SW 공학, 품질 관리 등 책을 보면 프로젝트 시작을 위해 가장 먼저 해야 될 업무에 대해 정의가 되어 있다. 물론 책마다, 글쓴이마다, 도메인 특성에 따라 다를 것이다. 나는 내부 SW 개발 프로젝트를 참여하면서 그 누구도 그것을 하는 사람을 보지 못했다. 다들 운영을 하고 있던 프로젝트라 신경을 쓰지 않았던 부분이 컸을 것이라 생각한다. "프로젝트 헌장" 이것에 대해 말하고자 한다. 프로젝트 헌장은 어떠한 프로젝트를 진행할 것이며 그에 따른 책임과 권한 등 모든 내용이 수록되어 있고 고객과 스폰서로부터 승인받아야 프로젝트를 시작할 수 있는 거창한 문서이다. (PMBOK 통합관리 부분에 언급되었을 것이다.) 하지만 필자는 이론 기반의 이상적인 프로젝트나 한국형 SI 프로젝트를 말하고 싶지 않다. ( 기.. 어느 기획자의 PM 이야기 SW 관리자를 우리는 보통 PM 이라 부른다. 필자는 명확하게 PM 이 지칭하는 역할이 Project Manager 인지 Proudct Manager 인지를 확인해보고 싶다. 두 직무는 명확히 다른 목적을 가진 업무로 헷갈리지 않기를 바란다. 설명은 애자일 환경에서의 직무에 대해 설명한다. Product Manager (Owner) 제품 관리자는 개발파트가 아닌 비즈니스, 사업과 관련된 영역에 치중한다. "개발은 모르겠고.. 이렇게 만들어줘야 상품 가치가 있고 고객이 사용할 수 있다." 라고 말할 수 있는 사람이다. 애자일 개발 프로세스가 널리 퍼지면서 PO (Product Owner) 라는 명칭으로 더 통용된다고 생각한다. 애자일에서 조직은 점점 더 작은 단위로 쪼개지고 애자일팀에서 스쿼드라는 팀 단위.. 어느 기획자의 UX 전략 UX 전략 기반의 모듈화를 실천해라. 보통 UX = UI + Interaction 이라는 공식에 공감한다. 사용자에게, 우리가 제공하는 가치에 대하여 UI로 낚시를 하여 서비스 들어오도록 하고 사용자에게, 우리가 자신을 목적 달성을 위해 일을 하고 있음을 알려주고 사용자에게, 우리가 제공하는 가치가 사용자에게 만족이라는 피드백을 주어야 한다. 화면설계서 작성 단계에 도달했다는 것은 이미 UX전략을 세웠을 것이다. 화면설계서는 말 그대로 화면(UI)을 포함하고 있다. 규모가 큰 제품이나 서비스의 경우는 여러 명이 같이 작업할 수도 있다. 이미 UX 전략 또는 아이데이션에서 대략적인 화면이나 UI컴포넌트가 정의되었을 것이다. 어디선가 주워들은 내용, 어떤 UX에이전시에서는 UI컴포넌트만 작업해서 배포하는 사.. 어느 기획자의 문서 작성 모든 문서를 작성하기 전에 형식을 갖추는 작업을 먼저 할 것이다. 화면 설계서 문서도 예외는 아니다. 하지만 후배들 작업하는 것을 보면, 자신만 알아볼 수 있게 작업하는 경우가 종종 발견된다. 주어진 템플릿을 그대로 이용하는 케이스 우선 내용부터 채우는 케이스 명확한 기준을 세우지 않고 작업하는 경우, 중구난방으로 문서 작성이 시작되어 헤매기 십상이다. 또한 완성된 결과물은 자신을 위한 문서가 될 뿐, 리뷰자들이 보기 어려워진다. 모든 문서는 문서를 보는 사람에 맞게 작성해야 되는 원칙을 지켜야 한다. 그래서, 틀을 갖추는 이야기를 하고자 한다. 첫 번째, 표지에 "제목"과 "부 제목", "작성자"를 기입해라. 내가 다니던 회사의 공식 형태는 아래와 같다. 주 제목과 부 제목의 가중치를 고려해보면, - .. 어느 기획자의 순서도 어떤 일을 하던지 익숙해지면 문제가 발생하기 쉽다. 고로, 기획자가 업무나 맡은 제품에 대해 익숙해지면서 문제가 발생할 확률이 높아진다. 내가 본 기획자들이 가장 많이 놓치는 부분이 기획(작업) 하는 부분에 대한 순서도 작성을 하지 않는다였다. 이유는 "다 아는 거 아니야?" 잘 안다고 생각할 때 사람의 뇌는 망각이라는 것을 실행하여 중간에 빼먹을 것을 당연히 했다고 여길 수 있다. 그래서 순서도 작성을 강하게 강조한다. Biseuness flowchart : 서비스나 상위 수준(시나리오) 업무 플로우 Function flowchart : 기능 및 사용자 액션 대한 플로우 비즈니스 플로우 최초의 시작은 요구 사항 기반으로 상세 기능이 정의 된 이후 시작할 수 있다. 사용자 요구 사항, 시스템 요구 사항,.. 어느 기획자의 개발 이해하기 기획하는데 개발을 왜 알아야 하죠?? 라고 생각하는 사람이 아직도 있는지 모르겠지만, 혹시 모르는 마음에 기획자도 알아두면 좋은 지식에 대해 다루어 본다. 개발은 SW가 만들어지는 모든 과정을 통칭하는 용어로, 기획자는 개발을 알아야 한다. 단, 코딩을 알 필요는 없다. 이런 것들이 기획자가 범하는 가장 많은 오류이다. 이런 것들 => 용어의 잘 못된 이해 1. 개발 (Software Development) SW개발 회사에서 개발은 하나의 SW 제품이 나오기까지의 시작과 운영까지의 모든 단계를 일컫는다. 즉, 요구사항 > 설계 > 구현 > 검증 > 운영 의 모든 프로세스를 포함하고 있다. 그럼 기획자는 각 단계별 어떤 업무를 수행하는지 확인하고 왜 개발을 알아야 하는가를 이해하면 된다. 첫 번째로 기획자.. 어느 기획자의 체크리스트 업무에 있어 익숙함이 가장 큰 리스크이자 문제라고 생각을 한다. 그래서 본인 직무(업무)에 대한 체크리스트를 작성하고 확인하는 습관이 중요하다. 아직 필자도 바쁘다는 업무를 핑계로 중구난방으로 작성했던 문서를 보고 반성을 해본다. 작성된 내용 일부는 사이트의 방문과 교육, 가이드 문서 기반으로 출처가 명시되어 있습니다. 1. 한 페이지(Screen)에서는 하나의 기능에만 충실해라 특히, 모바일을 중심 서비스가 증가하는 만큼 모바일에서 서비스를 이용하는 경우가 많다. 작은 화면에서 여러가지 기능을 수행하면, - 사용자가 사용하기 힘들뿐더러 컨트롤(사용)도 힘들기 마련이다. - 코치형 가이드가 마구마구 추가되어 복잡하게 될 수도 있다. - 복합한 UI이나 기능은 사이드 오류를 양산하기도 한다. 특히 우리는 .. 이전 1 2 3 4 다음
