애자일 큰 흐름 - tool4Free/okjob GitHub Wiki

애자일의 필요성

개인

일을 나눠서 하고 작은 단위의 일에만 집중하기 위해서 관리방법론이 필요하다.

시장 적합한 제품 개발을 위한 고객의 피드백 수렴

시간도 자원도 한정적인 상황에서 '시장 적합한' 제품을 개발하기 위해서는 고객의 피드백이 필요하다. 한 사람의 애씀 관점에서도 고객의 피드백을 통해 불필요한 곳에 쓰이는 에너지를 줄여 헛된 애씀을 방지할 수 있다. 즉, 피드백을 기반으로 개발을 진행해가며, 피드백이 없다면 제품을 재빨리 버려서 감정이 진창으로 빠지는 것을 예방할 수 있다.

제품 개발시 개고생을 하지 않기 위한 고객의 요구사항 변경 처리

"말로 표현하는 욕구는 5%에 불과하다", "고객은 보여주기 전까지 자신이 원하는 것을 잘모른다" 이런 말들은 직장 상사에게 통과하는 기획서를 가져가는 절차와 비슷하다. 내 생각으로만 심혈을 기울여 완성하고 가져가면 빡구 당하고 허탈해하는 경우가 발생한다. 하지만 초안 작성부터 작게 작게 상사에게 물어가며 방향을 잡는다면 빡구당해 멘탈이 붕괴되는 상황을 피할 수 있다.

즉, 얼개 잡고-피드백-피드백으로 세부작성-피드백-반영-피드백... 이런 식으로 (무한)루프를 돌면서 고객의 욕구가 반영된 시장 적합한 제품을 개발하는 방법론이 애자일이다.

애자일 흐름

출처: http://www.itlab.co.kr/v7/?m=bbs&bid=lec&cat=%EA%B0%9C%EB%B0%9C&uid=5964

스프린트

제품 백로그 작성

모든 이해관계자가 모여서 필요한 기능을 사용자 스토리 형식으로 '제품 백로그'에 기록한다.

사용자 스토리

전문 용어 없이 고객의 요구사항을 대화를 통해 정리. 요구사항 문서나 유즈케이스를 대신한다.
인터뷰, 설문, 관찰, 요구사항 공청회 같은 워크햡 형태로 취합
실사용자인지 확인 (남편이 부인이 쓸 칼을 사러 왔을 경우, 주방용 칼 제작사는 엉뚱한 피드백을 취합하게 됨)
고객에게 가치가 있고 서로 의존성이 없고 측정하능한 '기능' 단위로 적절하게 작은 단위로 작엇되어야 한다.
테스트를 통해서 스토리 완료 여부 판단
상세

예시

[사용자 역할]은 [행위/목표]를 수행하여 [이유]를 한다.

사용자는 새로운 하이브리드앱 어플리케이션이 필요하다
운영팀은 조건에 맞는 여러명의 사용자에게 같은 쿠폰을 발급할 수 있는 시스템이 필요하다.
개발자는 개발 프로세스 효율화의 필요성을 강하게 느낀다.
사용자는 안드로이드 어플리케이션 사용하다보면 자꾸 튕긴다

기술 스토리의 오묘함

빌드 서버 구축, 시스템 설계 개요 작성, 테이터베이스 튜닝, 버그 시스템 구축 등은 사용자에게 직접적인 가치를 제공하지 않는다. 다른 스토리에 영향을 미치지도 않지만.. 어쨌든 완료는 해야한다.

이 경우 기술 스토리를 비스니스 가치가 있는 스토리로 바꿔 적으려 하거나, 다른 스토리의 하위 작업으로 처리하거나, 기술스토리만 별도로 모아서 목록을 관리한다.

백로그에 모인 사용자 스토리의 중요성을 정한다.
백로그를 기초로 로드맵과 요구사항을 정한다.

로드맵을 에픽으로 분류하고 각 에픽별로 사용자 스토리를 넣고 우선순위를 부여한다.

단일 에픽과 멀티 에픽 예시

이슈 체계

방향 : 로드맵 -> 에픽 -> 스토리,버그,핫픽스 -> 하위작업

2레벨 작업은 반드시 1레벨이나 3레벨 작업이 필요하지 않는다.

1단계 큰틀 에픽
- 단기간 해결 불가, 거대한 작업
- 예) 사용자는 새로운 하이브리드앱 어플리케이션이 필요하다
2단계 스토리, 버그, 핫픽스
- 스토리 : 기능추가, 개선(리팩토링)
- 예) 운영팀은 조건에 맞는 여러명의 사용자에게 같은 쿠폰을 발급할 수 있는 시스템이 필요하다.
- 버그 : 현재 버전 사용에 문제가 되는 점
- 예) 사용자는 안드로이드 어플리케이션 사용하다보면 자꾸 튕긴다
- 긴급 : 현재 스프린트 계획에 없었거나 긴급 발생
- 예) 마케팅팀은 까먹은 급한 쿠폰 발급 생각, 내일까지 필요
- 현재 스프린트(주기)에 넣고 다음 회고 때 이야기해서 이런 일들까지 스프린트 정할 때 고려할 수 있도록 한다.
3단계 하위 작업
- 스토리, 버그, 긴급이 가질 수 있는 하위작업, 구체적이다.
- 예) 운영팀은 조건에 맞는 여러명의 사용자에게 같은 쿠폰을 발급할 수 있는 시스템이 필요하다.
  - 서버사이드 구조 설계, 명세
  - 쿠폰 컨트롤러 작성
  - 메인 페이지 프론트 작업
- 하위작업 필요없으면 생성하지 않아도 된다.

우선 순위

최상
- 시스템 사용 불능
- 해결 안하면 프로젝트 진행 불가
  - 사용자는 안드로이드 어플에서 주문 불가하다
- 담당 즉시 지정 및 전사 공유
상
- 시스템 주요 기능 동작 불능
- 프로젝트 진행은 가능하나 정상적인 개발 불가
  - 사용자는 안드로이드 어플에서 재고가 있는데 없다고 나온다.
- 지금 당장 개발하는 긴급 비즈니스 상황
  - 사용자는 재난발생 구호물품 전송 현황 파악 필요
중
- 시스템 일부 기능의 제약
  - 안드로이드 어플 설명 안 나옴
- 조만간 반드시 개발 필요
  - 계약 업체와의 API 개발 필요
저
- 동작하나 일부 기능 불편
  - 안드로이드 어플에서 점심 탭 갔다가 저녁 오면 튕긴다.
- 개발해야하나 업어도 상관 없는 경우
  - 플레이팅 2.0
최저
- 시스템 동작에 영향 없음
- 있으나 없으나 크게 상관 없음
  - 텔레그램 플레이팅 봇에 기능 추가하고 싶다