4. 크게보기
프로젝트가 달성하고자 하는 목표가 무엇인지, 왜 이 소프트웨어를 개발하려고 하는 지 명확히 이해할 수 있다.
4.1 우리는 왜 여기 모였나요 ?
- 프로젝트가 성공하기 위해서는 왜 그것을 개발하는 지 이해해야 한다.
4.2 엘리베이터 피치 만들기
- 엘리베이터 피치 ⇒ 마치 엘리베이터를 타는 시간인 20초 ~ 3분 사이에 핵심을 전달하는 것을 말한다. ( 짧은 시간 안에 핵심을 피력하는 방식 )
4.3 제품광고를 직접 디자인해보자
- 제품의 광고를 제작해봄으로써, 제품이 고객에게 끌릴만한 점이 무엇인지, 이 제품만이 가진 남다른 기능은 무엇인지 생각하게 해 줄 것이다.
4.4 NOT 리스트를 작성하라.
- 어떤 것이 프로젝트 범위에 포함되는 지, 포함되지 않는 지 알 수 있다.
- NOT 리스트가 가져다주는 이점
- 단시간에 프로젝트에 관해 많은 것을 파악할 수 있으며, 프로젝트의 범위가 무엇인지 분명히 알 수 있다.
4.5 프로젝트와 관련된 다양한 사람들과 만나라
- 브레인스토밍 → 프로젝트 커뮤니티에 어떤 관계자들이 있는지 정확하게 파악하기
- 연락책을 마련하여 주요 팀원이 아닌 사람들과도 관계 유지하기 → 신뢰 쌓기 (성공하는 프로젝트의 기반)
5. 실현 방안
5.1 해결책을 보여주라.
- 기술적인 아키텍쳐 청사진을 보여주고 확인받기
5.2 야근 거리(리스크 발견하기)
- 프로젝트 리스크란?
- 시간과 비용이 허락하는 것보다 턱 없이 할 일이 많은 것.
- 리스크를 예방하기 위해서는
- 프로젝트 초기에 리스크 논의하기
- 해결할만한 가치가 있는 리스크와 그렇지 않은 리스크 나누기
5.3 규모 정하기
- 프로젝트 초기에 규모를 정하는 것은 추측이라 정확하지 않지만, 프로젝트의 출시날짜를 예측해서 고객에게 알려주어야 한다.
- 즉, 규모가 큰 프로젝트를 출시할 때 → 작고 다룰 수 있을 만한 크기의 프로젝트 여러 개로 나눠야 한다는 것이다.
5.4 우선순위 정하기
- 시간, 비용, 품질, 범위 → 프로젝트에서 지켜야하는 규정
- 하나를 충실히 지키면 그만큼 다른 것에 충실하지 못하게 된다. → 따라서 우선순위를 두는 것이 필요하다.
5.5 우선순위 보여주기(기회비용 파악)
- 팀 구성, 계획, 비용을 스폰서에게 보여주는 과정
- 최고의 팀을 구성하라
- 최종결정을 내리는 인물이 누구인지 파악하라
- 비용이 얼마나 들지 추측해보기
6. 사용자 스토리 수집하기
6.1 문서 작성의 문제점
- 두꺼운 요구사항 문서의 작성은 소통의 어려움 + 여러 의미로 해석될 수 있음
6.2 사용자 스토리
- 사용자 스토리란, 고객이 자신의 소프트웨어에 원하는 기능을 짧게 표현해놓은 것.
6.3 좋은 사용자 스토리의 요소
- 고객에게 가치가 있어야 한다.
- 고객이 쉽게 이해할 수 있도록 어려운 기술용어를 피하고 간단명료하게 써야한다.
- 필요한 모든 분야를 아우르는 정보를 포함해야 한다.
6.4 스토리 수집 워크숍 진행방법
- 스토리 수집 워크숍이란 ?
- 개발팀과 고객이 함께 모여 시스템에 필요한 사용자 스토리(고객이 원하는 기능)를 수집하는 과정.
7. 추정치 정하기 : 예측하는 기술
처음 정한 추정치는 정말 대략적인 추측으로 이루어진다.
7.1 개괄적으로 추정할 때의 문제점
- “추정치는 그저 추측일 뿐이다” → 완벽한 추정은 없다. 그럼에도 불구하고 현실적인 추정은 해야된다
7.2 확실한 추정치를 얻기 위한 방법
- 상대적인 크기로 추정하기
- 점수 기반 시스템
- 추정치가 추측인 것을 상기시켜준다.
- 오직 크기만 측정한다.
- 빠르고, 쉽고, 간단하다.
7.3 스토리에 적합한 크기 측정 기법
- 삼각층량
- : 기준 스토리를 몇 개 정하고 → 다른 스토리들의 상대적 크기를 추정하는 방법
- 플래닝 포커
- : 팀원들이 각각 스토리 추정치를 정한 후 → 그 결과를 모두와 비교하는 게임
8. 애자일로 계획 짜기
8.1 정적인 계획의 문제점
정적인 계획으로 프로젝트가 진행된다면,
- 팀원이 바뀌거나
- 팀의 작업속도가 생각보다 빠르지 않다는 걸 중간에 깨닫거나
- 중간에 고객이 정말 원하는 것이 무엇인지 깨닫거나
- 더 이상 남은 시간이 없거나
할 때, 결국 출시 날짜도 못 맞추고, 비용도 초과하고, 품질도 떨어지는 실패한 프로젝트가 되버릴 것이다.
8.2 애자일(로) 계획 세우기
8.3 범위에 유연하라!
- 애자일 프로젝트에서 본래 계획의 취지를 유지할 수 있는 이유 → 범위에 유연하기 때문이다.
- 애자일 팀은 고객이 엄청난 비용을 지불하지 않고도 언제든지 마음을 바꿀 수 있는 기회를 제공한다.
8.4 처음 세운 애자일 계획 (첫 계획)
- 애자일 계획을 세우는 단계 (5단계)
- STEP1. 마스터 스토리 리스트(사용자 스토리 모음) 작성하기
- STEP2. 크기 정하기
- STEP3. 우선순위 정하기
- STEP4. 팀의 업무 속도 측정하기
- STEP5. 날짜 예상하기
8.5 번다운 차트
- 번다운 차트: 대략 언제쯤 프로젝트가 완성되는지 알려줄 수 있다.
8.6 프로젝트를 애자일로 변화시키기
- 빨리 출시해야 한다면 → 지금 가지고 있는 계획은 버리고 새로운 계획을 세우도록 하자
- 해야 할 일의 목록을 만들고, 스토리의 크기와 우선순위를 정한다면, 최소한의 기능을 빠른 시일내에 출시할 수 있을 것이다.
- 예정된 일정 내에 작업을 마쳐야 한다면 → 매주 가치있는 기능 한두 개 선택해서 개발해보도록 하자
8.7 실행에 옮기기
'책 공부' 카테고리의 다른 글
개발자 원칙 (1) (0) | 2023.08.08 |
---|---|
함께 자라기 : 애자일로 가는 길 (2) (0) | 2022.11.02 |
읽기 좋은 코드가 좋은 코드다 (2) (0) | 2022.10.31 |
함께 자라기 : 애자일로 가는 길 (1) (0) | 2022.10.24 |
애자일 마스터 (1) (0) | 2022.10.23 |
댓글