본문 바로가기
책 공부

애자일 마스터 (2)

by ppirae 2022. 11. 1.

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 확실한 추정치를 얻기 위한 방법

  1. 상대적인 크기로 추정하기
  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

댓글