[책리뷰] 애자일 마스터

Euro·2024년 11월 1일

애자일 소개

애자일 : ‘신속 개발 방법론’ 들을 통칭하는 단어, 대표적으로 스크럼, 칸반, XP 등 포함

마스터 스토리 리스트 : 프로젝트 기간 동안 '해야할 일'을 담은 목록
고객(PO)은 추가하고 싶은 기능(사용자 스토리)을 추가
이터레이션(스프린트) : 고객이 가장 중요시하는 스토리를 개발-검증 (1-2주)
팀의 속도, 프로젝트의 범위, 유연한 계획 세우기

애자일 프로젝트 관리 목표

지속적인 혁신
제품 적시 출시
확장성 있는 제품
사람과 프로세스의 적응력
신뢰성 있는 결과

애자일 프로세스 도입 단계
1. 애자일 프로젝트 인셉션 : '인셉션 덱'이란 도구를 통해 초기단계에 고객과 개발팀이 서로 알아가는 과정을 갖는 일정한 기간
2. 스크럼 계획 : 모든 요구사항을 리스트업한 백로그를 작성하고, 릴리즈와 스프린트 계획을 세우는 단계
3. 스크럼 실행 : 스프린트 관리, 일일 스크럼, 스프린트 리뷰, 스프린트 회고 미팅 등을 통한 구현 단계
4. 애자일 프로세스에서 최고의 성능 도출 : 단위테스트, 리팩터링, 지속적인 통합 등

(추가)전통적인 프로젝트 개발방식의 한계

초기에 설정된 업무 범위, 일정 비용은 반드시 지켜야할 목표로 여겨짐
초기에 구체적인 요구사항을 도출하기 어려움
중간에 발생하는 요구사항의 변경을 반영하기 어려움
프로젝트 관리자 중심의 명령과 통제 방식 때문에 구성원은 수동적으로 바뀌고, 커뮤니케이션이 매우 부족해짐

애자일 프로젝트 인셉션

인셉션 덱 : 프로젝트 초기 단계에 고객과 개발팀이 서로 알아가는 과정을 갖는 기간 중 사용하게 되는 일종의 도구

아래 10가지 항목에 대해 서로에게 질문

우리는 왜 여기 모였는지 : 프로젝트 동기 확인 및 목적 공유
엘리베이터 피치 : 30초간 두 문장으로 프로젝트를 설명
패키지 디자인 & 제품의 광고 디자인
- 1단계: 제품이 제공하는 혜택이 무엇인지 브레인스토밍하라.
- 2단계: 슬로건 만들기
- 3단계: 상자 디자인하기
NOT 리스트 - 하지 말아야 할 것들 작성
- 범위 내 : 꼭 해결해야 하는 중요한 문제들
- 범위 외 : 있으면 좋지만 무리할 필요 없는 사항들
- 미해결 : 조금 더 생각해 봐야 할 것들
프로젝트와 관계된 다양한 사람들과 알고 지내기 : 관련 업계 종사자들과 커뮤니케이션
해결책 제시 : 기술적인 아키텍처를 공유하고 서로의 생각 파악
- 어떤 도구나 기술을 사용할지 추측
- 프로젝트 제약사항이나 범위를 시각화
- 리스크에 대한 상의
미리 야근 거리가 될 만한 것들 찾기 : 발생할 문제 미리 파악
규모 정하기 : 프로젝트 개발 기간 산정
- 작은 단위로 생각
- 규모에 적당한 기대치 세우기
우선순위 파악 : 시간 | 비용 | 품질 | 범위 단위에서 중요한 요소 파악
기회 비용 파악 : 팀 구성, 시간/비용, 최종 결정자 등

애자일 프로젝트 계획

사용자 스토리 수집

사용자 스토리 : 고객이 자신의 소프트웨어에 원하는 기능을 짧게 표현해 놓은 것

고객에게 가치가 있어야 함
필요한 모든 분야를 아우르는 정보를 포함해야 함
독립적, 협상 가능, 테스트 가능, 작고 추정가능해야 함

좋은 사용자 스토리의 요건 : INVEST
Independent, Negotiable, Valuable, Estimatable, Small, Testable
→ 독립적인 스토리와 적절한 스프린트 계획이 선행되어야 스프린트 리뷰에서 원하는 목적을 달성

스토리 수집 워크숍 : 애자일로 계획을 세우기 전, 기능을 나열해보는 것
How to ?

포스트잇에 붙이거나 기록할 수 있는 커다란 곳에서 협의
페르소나, 플로차트 등 그림을 자주 그려볼 것
스토리(다이어그램) 많이 쓰기
그 외 모든 것에 대해 브레인스토밍

스토리 크기 추정

미래 계획을 짤 수 있는 정보를 제공하고,
추정치는 추측일 뿐이라는 것을 상기시켜 주며,
소프트웨어 개발에는 본래 복잡성이 있다는 걸 인지하게 해주는 추정치 필요

상대적인 크기로 측정
진행 상황을 추적하기 위한 점수 기반 시스템 필요

하지만, 스토리의 상대적인 크기가 정해지고 팀의 생산도가 측정되어야 현실적이고 실현 가능한 계획을 수립 가능함

계획 수립

마스터 스토리 리스트 작성 + 릴리스 정의
릴리스 : 함께 묶어 전달했을 때, 고객에게 가치가 있는 스토리들을 논리적으로 분류해놓은 그룹
크기 정하기 : 릴리스가 얼마나 큰지 알아보고 프로젝트가 얼마나 걸릴지 예상
우선순위 정하기 : 개발 아키텍쳐와 관련된 위험을 줄이기 위함
팀의 업무속도 측정 : 업무 속도 = 완성된 스토리 포인트 / 이터레이션
첫 예상치는 낮게 잡는 것이 좋음
날짜 예상

번다운 차트 : 업무를 완료하는 데 걸리는 시간 대비 남은 업무를 나타내는 그래프

시나리오1. 고객이 새로운 요구사항을 찾아낼 때

릴리스 날짜를 미루거나 (비용 증가)
조금 덜 중요하다고 생각하는 스토리를 빼버림
있으면 좋은 기능 리스트 작성 후 프로젝트 후반에 시간이 남는다면 개발

※ 감정적이지 않도록 주의

시나리오2. 프로젝트가 예상보다 느리게 진행될 때

프로젝트에 핵심 기능 한두 개만 선택, 뼈대가 되는 최소한의 버전으로 계발 일정 설계
작게 쪼개면서 고객과 투명한 대화를 통해 건설적인 목표를 잡아가는 것을 지향
인력추가, 날짜 연기 (추천 x)

※ 고객에게 사전에 계획 변경 가능성 고지하는 것 필요

시나리오3. 중요한 팀원을 잃게 되었을 때

고객에게 상황설명 후, 업무 속도에 어떤 영향을 끼치는지 측정하여 어느정도 였는지 말해야함

시나리오4. 시간이 다 되었을 때

범위조정 > 일정이 반밖에 안남으면 기능도 반으로 줄여야함
고객과 함께 해결방안 모색 > 뼈대만 개발 등..

애자일 프로젝트 실행

     출처 : https://inblog.ai/lomin/agile-project-management-with-scrum-33678#%EC%95%A0%EC%9E%90%EC%9D%BC_%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EB%A5%BC_%EC%86%8C%EA%B0%9C%ED%95%98%EA%B8%B0%EC%A0%84%EC%97%90_%EC%9D%BC%EB%9F%AC%EB%91%90%EA%B8%B0_0

이터레이션 관리

1단계 : 분석과 설계 : 작업 준비하기

사용자 스토리에 대한 깊이있는 분석을 스토리가 필요하기 직전(이터레이션 직전)에 실행
좋은 순서도, 페르소나, (팀원과 함께) 종이 프로토타입 활용
고객과 검토

2단계 : 개발 : 작업실행
작업환경 준비 후 실행

3단계 : 테스트 : 완료된 작업 확인하기

데모를 직접 경험하게 하며 그것을 관찰 + 피드백 얻기
인수 테스트가 필요 없다고 느껴질 때까지 진행

커뮤니케이션 계획

기대치 세우기 & 피드백 받기

이터레이션을 운영하기 위해 필요한 네가지 활동

다음 이터레이션에 할 작업 준비
지난 이터레이션에서 작업했던 스토리에 대한 피드백 받기
다음 이터레이션에서 스토리들을 어떻게 작업할지 계획 세우기
향상될 부분이 있는지 지속적으로 찾기 (미니 회고)
- 잘하고 있는 것, 더 향상시켜야 할 부분 토론

일일 스탠드업을 진행할 때 하면 안 되는 것

FROM

어제 무엇을 했는지
오늘 무엇을 할 것인지
내 작업 속도를 늦추거나 방해하는 요소가 있는지

세상을 바꾸기 위해 어제 무엇을 했는가
오늘 그 작업을 어떻게 끝낼 것인가
지금 앞을 가로막고 있는 이장애물을 어떻게 없앨것인가

시나리오1. 완성되지 않은 스토리

이터레이션 작업 속도에는 완성or미완성 스토리만 포함, 완성이 안 된 것들은 미뤄두고 완성되면 계산에 포함시킴

시나리오2. 일일 스탠드업이 도움이 안 될 때

일일 스탠드업의 목적 상기
하지만 일일 스탠드업이 최선책은 아니므로 취사선택하면 됨

시나리오3. 이터레이션 기간 동안 가치를 전달하지 못했을 때

직접 고객과 대면하여 상황을 사실적으로 전달해야 함

시각적인 환경조성

스토리보드
릴리스 상황판
속도와 번다운 차트
인셉션 덱 (공간여유가 있다면)

Euro

이전 포스트

UI 용어 정리

다음 포스트