PMP 20 요구 사항 상세화

사용자 스토리 ; 

- 1-3일, 40시간 내에 구현이 가능한 work 

- 인덱스 카드/ 스티키노트 등 사용 

- PO 작성 > 프로덕트 백로그에 들어감 

- 작성하는 법

  - candidate story ; 사용자 또는 고객의 관점으로 선택 

  -  As a roll, I want functionality so that biz benefits .. 형식으로 작성

  - 누가 원하는가? / 우리가 왜하는가? 두 가지 답이 나와야 함

- Format 

  - Given ; 시나리오 / When 액션 / Then 결과 

- 3C 사용자 스토리 

  - Card ; 심플하고 식별가능 수준  

  - Conversation ; 세부사항은 고객이나 개발팀과 의논 

  - Confirmation ; 고객이 직접 확인 > 리뷰 과정에서 데모 시현을 통해 확인하게 됨 

- INVEST 원칙 ; Independant , Negotiable , Valuable , Estimate, Small, Testable

 

워크숍 개최 ; 요구사항을 모으는 방법

- 고객 제품책임자 비즈니스관계자 등 전부 모이는 행사

- 회고 / 계획 회의 / esimaiting 세션 

- 좋은 워크샵의 조건들

  - 다양한 사람들 / 퍼실리테이팅 / 사람들을 인볼브시켜야

- 스토리 워크숍 

  - 후보 유저 스토리 중 선호되는 접근법 / 스토리 라이팅 워크숍 / 사용자 니즈를 이해하는 좋은 워크 플로우 

  - 이해관계자도 디자인 프로세스에 참여시키는 것도 좋음

- 브레인스토밍

  - 3가지 방법 / Quiet Wiriting/ 라운드 로빈 / Free for all 

-  콜래보레이션 게임

  - 이노베이션 게임이라고도 함 

  - Rememeber Future / 완성상태를 떠올림 / 뭐가 되어있는지를 상상하면서 DoD를 만드는 법

  - Prune the Product Tree ; Trunk-이미 완료함 / Branch-New / 중요한 것일 수록 Trunk 쪽으로 움직임

  - Speed Boat Game ; Wind=Why / Anchor =Cost/Resource/Time / Moving Toward=KPI,Solution 등

 

애자일 모델 활용하기

- 가볍고 미흡해야함

- Analysis > Design > Implemenatation > (Testing > Analysis) > Review > Design 을 반복

- 고려사항

  - Supplmeent XP/스크럼

  - 문서 작업 적정하게 / 큰 팀에서는 힘듦 / 페이스 투 페이스 대화 

- XP ; Extreme Programming 

  - 커뮤니케이션 중요 / 단순성 -코드 대신 다이어그램 / 피드백 / 용기 - 삭제와 리팩터링을 할 용기 / 겸손 - 잘 모른다는 

 

유즈 케이스 다이어그램 ; 사용자와 유즈케이스를 통해서 기능을 모델링할 수 

- 유즈 케이스; 액션 서비스 기능의 집합체 

- 시스템 ; 사각형 - 유즈 케이스를 담음 / 사용자는 사각형 바깥에 존재 

- 유즈 케이스 ; 타원형 ; 동사로 레이블링 

- 행위자 ; 시스템도 액터가 될 수 있다

- 관계 ; 선 ; 사용자와 유즈케이스 사이의 관계 

 

데이터 모델 정하기

- 스크린 디자인 ; 사용자 인터랙션 / 사용자 스토리가 포커싱됨 / 팀과 PO의 협업 / 범위 변동이나 블랙홀 방지

- 와이어 프레임 ; UI 요소 인터페이스 사용자 인터랙션 정의 등 / 저 수준 프로토타이핑

- 페르소나 ; 핵심 이해관계자의 페르소나 / 가상의 인물 / 실제 목표 오리엔티드 / 

- 페르소나 만들기 ;

  - 정확성이 긴 것보 낫다

  - 목표와 사용자를 알아야 한다 

  - 가장 중요한 페르소나를 정의해야 

  - 주 용도에 집중해서 작성 / 

 

계약과 애자일 접근방법

- RFP ; 구매자가 판매자에게 전달 / 

- 판매자가 애자일을 원하면 > RFP에 정의해야 ; 구매자를 교육해야할 수도 

- 애자일은 변경을 수용하기 때문에 계약과 충돌함

- 애자일은 유연하고 / 계약은 not flexible, 제안과 고려사항에 대한 제한요건의 형식들

- 애자일은 계약을 넘어서는 협동을 바람 / 시간과 비용에만 제약을 두고 업무 범위 변경 

- 고려사항 ; 범위 변경 / 우선도 / 타임과 시간 제약 

- DSDM 계약 / Dynamic System Development Mehod / 워터폴은 너무 크고 느림 / RAD는 품질 낮음

  - 워터폴과 RAD의 장점만 가져오려 함

  - RAD ; 의사소통, 참여 투명성을 / 워터폴은 예측성과 품질을

  - 고정된 일정 비용 품질 / 애자일 프레임워크를 따름 

- Graduated Fixed Price Contract 

  - 온 타임이면, 적정 그래프 / 빨리 끝낼 수록 맨아워 머니를 많이 쳐줌 / 늦으면 시급이 깎임

  - 샌드배깅 X / 조깅 납품하려고 소요시간 부풀리는 것

  - 신뢰가 있어야 함 / 효율적으로 일해야 함 / 결과물에 집중 / 시간이 아니라

- FIxed Price Work Package 

  - 작업의 가격은 고정으로 남아있는다

  - 개별 작업 패키지는 비용 측정되야 해서 > 시간이 좀 초기에 걸림

  - 범위에 대한 변경은, 작업 패키지에 대한 새로운 측정을 해야 함 

- 계약은 언제든 수정 가능

- Gulf of Evaluation ; 이해한 내용이 다른 경우 발생 

 

가치 베이스 분석 ; 비즈니스 편익 - 비용 

- 비즈니스 가치 창출이 얼마나 자주인지 / 월간 주간인지

- 높은 비즈 가치가 낮은 비즈 가치 제품에 의존적일 수 있다

  - 데이터베이스나 아키텍츠 등을 먼저 구축해야 할 수도 

- 가치 기반 분해

  - 요구사항 유도 / 유사 특성끼리 묶음 / 특성 브레이크 다운 / 요구사항 랭킹 / 개발의 우선순위 조정

- 프로덕트 박스 / 주요 세가지 기능을 집어넣고 상상하는 것

- 개략적 요구사항 ; 전체적 균형 설계를 도와줌 / 세세한 내용을 마지막 순간에 결정할 수 있게 함