본문 바로가기
728x90

개발 안하는 공대생

요구사항_INVEST in Good 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가지 특성 좋은 유저 스토리를 작성하기 위해서는 좋은 유저 스토리의.. 더보기
Essential XP : Card, Conversation, Confirmation 애자일 소프트웨어 개발 선언 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다 : 공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hun.. 더보기
요구 사항_수집?분석?정의?명세? 우선 펼쳐보자 소프트웨어 공학의 입구에 서서 문을 열면 가장 먼저 반기는 것이 요구사항이다. 그리고 이렇게 시작한다. "고객은 자신이 무엇을 원하는지 모른다." 실제 모르는 것이 아니라 머릿속에 있는 것을 표현을 못한다는 말이다. 이것을 구체화하는 작업이 요구사항 정의이다. 웹 에이전시나 SI 프로젝트를 경험하신 분들은 친근하게 느껴질 수 있을 것이다. 하지만 인하우스나 자체 솔루션을 오래부터 가져온 회사 직원은 필요성을 못 느낄 수 있을 것이다. 요구사항의 중요성은 구글에서 검색하면 나무에 그네를 만드는 이미지로 확인할 수 있다. 서론을 시작으로, 요구사항 수집 > 분석 > 정의 > 관리 4단계를 확인한다. (원문 보기) [SW Requirements] 요구사항 수집, 분석, 정의 기본편 소프트웨어 공학의 입구에 서.. 더보기
요구사항_Given When Then 이 어쨌다고?? 기획자가 Agile 을 공부한다는 건 유저 스토리에 대한 접근이 아닐까라고 생각해본다. 도서를 보더라고 Agile 의 한 부분으로 유저 스토리만을 다룬 책들이 많이 있다. 프로젝트의 단추인 만큼 중요하지만 다루는 것은 그다지 쉽지 않은 부분이다. 사전 지식으로 Agile 에 대한 이해가 필요하다. 서론의 시작 대충... 빠르게 개발해서 고객에게 전달하는 개발 방식이다. 그럼 어떻게 빠르게 개발을 할 수 있는가? 1. 개발할 내용을 작고 작은 조각으로 쪼갤 수 있어야 하고. 2. 작게 쪼갠 조각은 독립적으로 동작할 수 있어야 한다. 여기서 포인트! - 두 개의 문장을 작성했을 뿐인데... 막연하다. 어떻게 작성하라고?? - 유저 스토리를 작성하는 방법들이 나온 이유일 것이다. - As a, I want, .. 더보기
요구사항_기획자 몸에 맞는 SRS 사전학습 ->> [SW요구사항] 요구 사항 작성이 어려울때 하나씩 파헤치기 (경험기반) 기획자도 작성할 수 있는 수준의 SRS 를 제안해 본다. >> 템플릿 확인하러 가기 1. 표지 작성 [OOO] 요구사항 명세서, 작성(배포)일, 작성자 소속 2. 문서 확인 고객사와 개발사, 이해관계자들의 협의를 위한 공간 3. 문서 이력 문서의 변경 이력을 작성한다. 4. 서비스 개요 목적, 범위, 용어, 사양(성능), 설계, 참고 문헌 정의 5. 상위 수준 요구 사항 6. 기능 요구 사항 7. 비 기능 요구 사항 8. 이슈 리스트 (optional) 아래 링크에서 위 목차의 템플릿을 확인할 수 있다. >> 템플릿 확인하러 가기 SRS 작성 템플릿 SRS (Software Requirements Specificati.. 더보기
기획도 모듈화다! UX 전략 수립 UX 전략 기반의 모듈화를 실천해라. 화면설계서 작성 단계에 도달했다는 것은 이미 UX전략을 세웠을 것이다. 더보기 "욘나빠른피셜" UX란? 보통 UX = UI + Interaction 이라는 공식에 공감한다. 사용자에게, 우리가 제공하는 가치에 대하여 UI로 낚시를 하여 서비스 들어오도록 하고 사용자에게, 우리가 자신을 목적 달성을 위해 일을 하고 있음을 알려주고 사용자에게, 우리가 제공하는 가치가 사용자에게 만족이라는 피드백을 주어야 한다. 화면설계서는 말 그대로 화면(UI)을 포함하고 있다. 규모가 큰 제품이나 서비스의 경우는 여러 명이 같이 작업할 수도 있다. 이미 UX 전략 또는 아이데이션에서 대략적인 화면이나 UI컴포넌트가 정의되었을 것이다. 어디선가 주워들은 내용, 어떤 UX에이전시에서는 U.. 더보기
문서의 시작, 틀을 갖추자 (Document layout) 문서의 틀을 먼저 갖추자. 화면설계서 기반으로 기획서를 작성, 욘나빠른 Tip 모든 문서를 작성하기 전에 형식을 갖추는 작업을 먼저 할 것이다. 화면 설계서 문서도 예외는 아니다. 하지만 후배들 작업하는 것을 보면, 자신만 알아볼 수 있게 작업하는 경우가 종종 발견된다. 주어진 템플릿을 그대로 이용하는 케이스 우선 내용부터 채우는 케이스 명확한 기준을 세우지 않고 작업하는 경우, 중구난방으로 문서 작성이 시작되어 헤매기 십상이다. 또한 완성된 결과물은 자신을 위한 문서가 될 뿐, 리뷰자들이 보기 어려워진다. 모든 문서는 문서를 보는 사람에 맞게 작성해야 되는 원칙을 지켜야 한다. 그래서, 틀을 갖추는 이야기를 하고자 한다. 첫 번째, 표지에 "제목"과 "부 제목", "작성자"를 기입해라. 내가 다니고 있.. 더보기
지극히 개인적인 기획자의 체크리스트 (6~8) 업무에 있어 익숙함이 가장 큰 리스크이자 문제라고 생각을 한다. 그래서 본인 직무(업무)에 대한 체크리스트를 작성하고 확인하는 습관이 중요하다. 아직 필자도 바쁘다는 업무를 핑계로 중구난방으로 작성했던 문서를 보고 반성을 해본다. 작성된 내용 일부는 사이트의 방문과 교육, 가이드 문서 기반으로 출처가 명시되어 있습니다. 6. 화면 설계시 기준 해상도를 설정해라. 화면을 설계할 때 기준 크기와 반응형에 대한 고민을 해야한다. 최소한 Min/Max 의 크기 기준으라도 정의해야 실제 개발된 산출물이 사용자 환경에 따라 원치 않는 모습으로 보여지는 것을 피할 수 있다. - Windows OS는 괜찮지만, Mac OS의 해상도는 작게, 보통, 크게 등..변태 해상도가 많으니 유의해야 한다. - SPA(Single.. 더보기
Scrum 에 맞춰본 테스팅 V-Model 테스트 분야 공부를 하게 되면 반드시 만나는 V-Model 에 대한 생각이다. ISTQB 공부를 하면서 실라버스에 나온 내용과 테스트 실무 등.. 프로세스 및 정책은 언제나 웅장한 느낌을 받는다. 그럼 실무에서는 어떻게 적용해야 할 것인가? 여태 다녀본 회사에 품질, 테스트 조직이 있다한들 테스트 정책을 명문화하여 지키는 것을 본 적이 없었다. 그리고 앞으로도 없을 것 같다. 그만큼 실무와 거리가 생기는 내용이라 생각한다. 개발 프로세스를 개선하면서 늘 품질 파트를 어떻게 접목해야 하는가라는 고민이 생겼다. 일전에 스크럼을 공유하면서 고민했던 내용을 끄적여 본다. Scrum 프레임워크를 통해 개발자들은 어떻게 개발을 해야되는지 알게 된다. 하지만 품질 담당자에 대한 언급은 없었던 것 같다. 개발을 잘하면.. 더보기
지극히 개인적인 기획자의 체크리스트 (4~5) 업무에 있어 익숙함이 가장 큰 리스크이자 문제라고 생각을 한다. 그래서 본인 직무(업무)에 대한 체크리스트를 작성하고 확인하는 습관이 중요하다. 아직 필자도 바쁘다는 업무를 핑계로 중구난방으로 작성했던 문서를 보고 반성을 해본다. 작성된 내용 일부는 사이트의 방문과 교육, 가이드 문서 기반으로 출처가 명시되어 있습니다. 4. Backoffice (Admin) 사이트 구성 시, CRUD 를 지켜라 Backoffice 와 같이 관리자 웹 사이트나 서비스의 경우 Database를 기준으로 화면을 구성하게 된다. 이 경우, 비지니스 로직보다는 단순 조회, 수정, 삭제 기능이 메인이다. 기본 기능은 CRUD C (create) : 신규 생성 (new) R (read) : 조회 (search) U (update) .. 더보기
지극히 개인적인 기획자의 체크리스트 (1~3) 업무에 있어 익숙함이 가장 큰 리스크이자 문제라고 생각을 한다. 그래서 본인 직무(업무)에 대한 체크리스트를 작성하고 확인하는 습관이 중요하다. 아직 필자도 바쁘다는 업무를 핑계로 중구난방으로 작성했던 문서를 보고 반성을 해본다. 작성된 내용 일부는 사이트의 방문과 교육, 가이드 문서 기반으로 출처가 명시되어 있습니다. 1. 한 페이지(Screen)에서는 하나의 기능에만 충실해라 특히, 모바일을 중심 서비스가 증가하는 만큼 모바일에서 서비스를 이용하는 경우가 많다. 작은 화면에서 여러가지 기능을 수행하면, - 사용자가 사용하기 힘들뿐더러 컨트롤(사용)도 힘들기 마련이다. - 코치형 가이드가 마구마구 추가되어 복잡하게 될 수도 있다. - 복합한 UI이나 기능은 사이드 오류를 양산하기도 한다. 특히 우리는 .. 더보기
플랫폼 별 Design Guide 한 눈에 보기 (Fluent Design System) 기획자도 각 플랫폼별 디자인 가이드를 알고는 있어야 합니다. (옵션 사항) 디자인 가이드는 각 플랫폼의 아이덴티티와 특색을 잘 표현하고 있어서 개발자 사이트를 통해 얻는 것보다 빠르고 쉽게 정보를 습득할 수 있습니다. Microsoft Design 사이트에서는 각 플랫폼의 디자인 가이드로 링크가 연결되어 있어 편하다. www.microsoft.com/design/fluent/#/ Web, Windows, 모바일 등 주요 플랫폼에 대한 디자인 가이드를 확인할 수 있다. 아래 이미지를 보면 좌측에 각 플랫폼을 선택하여 동일 컴포넌트에 대하여 확인할 수 있다. developer.microsoft.com/en-us/fluentui#/controls/mac/date-picker Microsoft 의 Fluent .. 더보기
프로젝트의 시작, PM 으로써 무엇을 먼저하는가? 본 글은 필자의 경험과 교육, 세미나를 통해 얻은 지식을 바탕으로 공유하는 내용입니다. Project Manager VS Product Manager SW 관리자를 우리는 보통 PM 이라 부른다. 명확하게 PM 이 지칭하는 역할이 Project Manager 인지 Proudct Manager 인지를 확인해보고 싶다. 두 직무는 명확히 다른 목적을 가진 업무로 헷갈리지 않기를 PM vs PM SW 공학, 품질 관리 등 책을 보면 프로젝트 시작을 위해 가장 먼저 해야 될 업무에 대해 정의가 되어 있다. 물론 책마다, 글쓴이마다, 도메인 특성에 따라 다를 것이다. 나는 내부 SW 개발 프로젝트를 참여하면서 그 누구도 그것을 하는 사람을 보지 못했다. 다들 운영을 하고 있던 프로젝트라 신경을 쓰지 않았던 부분이.. 더보기
스크럼마스터는 누가하나요?? (묻는 사람이 하세요) Scrum 을 도입하고자 할 때 또는 셋업 하려고 할 때 가장 먼저 무엇을 신경 쓸 것인가? 나는 당연히 업무 분장이라고 생각한다. (Role and Responsibilities) 스크럼의 구성원은 보통 3가지로 구분된다. PO (Product Owner) SM (Scrum Master) SD (Scrum Developer / Scrum Team) 그럼 조직에서는 현재 구성원을 어떻게 배치할지에 대해 고민을 해야 한다. 보통의 조직은 이렇지 않을까.. - PO : 기획자 or PM - SM : PM - SD : 개발, 디자인, 기획, 테스터 이제부터 개인적인 배치에 들어갑니다. PO : 기획자가 적합. - 기술 기반의 지식이 중요하지 않음. (사용자, 유저 친화적이어야 함) - 이해관계자와 커뮤니케이션.. 더보기
기획자가 알아야할 잡학다식 (기획자도 개발팀원이다.) 기획하는데 개발을 왜 알아야 하죠?? 라고 생각하는 사람이 아직도 있는지 모르겠지만, 혹시 모르는 마음에 기획자도 알아두면 좋은 지식에 대해 다루어 본다. 개발은 SW가 만들어지는 모든 과정을 통칭하는 용어로, 기획자는 개발을 알아야 한다. 단, 코딩을 알 필요는 없다. 이런 것들이 기획자가 범하는 가장 많은 오류이다. 이런 것들 => 용어의 잘 못된 이해 기획자의 개발 용어 알아가기 SW개발 회사에서 개발은 하나의 SW 제품이 나오기까지의 시작과 운영까지의 모든 단계를 일컫는다.즉, 요구사항 > 설계 > 구현 > 검증 > 운영 의 모든 프로세스를 포함하고 있다. 나 때는 말이야, 기획? 1. 개발 (Software Development) SW개발 회사에서 개발은 하나의 SW 제품이 나오기까지의 시작과 .. 더보기
SW 관리자 되어보기 (PM 의 이중인격) 본 글은 필자의 경험과 교육, 세미나를 통해 얻은 지식을 바탕으로 공유하는 내용입니다. SW 관리자를 우리는 보통 PM 이라 부른다. 필자는 명확하게 PM 이 지칭하는 역할이 Project Manager 인지 Proudct Manager 인지를 확인해보고 싶다. 두 직무는 명확히 다른 목적을 가진 업무로 헷갈리지 않기를 바란다. 설명은 애자일 환경에서의 직무에 대해 설명한다. Product Manager (Owner) 제품 관리자는 개발파트가 아닌 비즈니스, 사업과 관련된 영역에 치중한다. "개발은 모르겠고.. 이렇게 만들어줘야 상품 가치가 있고 고객이 사용할 수 있다." 라고 말할 수 있는 사람이다. 애자일 개발 프로세스가 널리 퍼지면서 PO (Product Owner) 라는 명칭으로 더 통용된다고 생.. 더보기