본문 바로가기

개발

Clean Agile - Chapter 3

반응형
 

클린 애자일

애자일의 기본으로 돌아가라!애자일 선언이 첫선을 보인 지 20년 가까이 지난 지금, 살아있는 전설 로버트 C. 마틴(“엉클 밥”)은 새로운 세대에게 애자일 가치와 실천 방법을 다시 소개한다. 애

www.yes24.com

위의 책 내용을 참고하여 정리한 글입니다.

자세한 내용은 책에서 확인하세요.

 

애자일 실천 방법 중 비즈니스와 연관된 것이 많고,

계획 세우기, 작은 릴리스, 인수 테스트, 전체 팀이 포함된다.

 

이 중 계획 세우기에 대한 내용이다.

계획 세우기

프로젝트의 크기를 추정하기 힘들다면, 더 작게 쪼개고 쪼개서 추정하면 된다.

하지만 추정이 매우 정밀하고 확실하면 의미가 없다.

 

추정은 추측이다.

작은 비용으로 대략 어느 정도 걸릴지 알고 싶은 것이다.

삼변량 분석

최선, 일반, 최악 의 경우를 사용하여 추정한다.

 

최선 : 1주에 끝날 확률 95프로

일반 : 2주에 끝날 확률 50프로

최악 : 3주에 끝날 확률 5프로

 

전체 프로젝트 추청에는 적당하다.


프로젝트의 일상적 관리 용도로는 정밀도가 낮다.

스토리 포인트

앞서 나온 반복 주기에서 실행할 수 있다.

스토리

애자일에서 스토리는 프로젝트에서 필요한 것에 대한 간략한 명세이다.

 

스토리는 매우 단순해야 하며 세부사항은 생략되어야 한다.

세부 사항은 쉽게 바뀌고, 스토리를 관리하거나 추정하기 어렵게 만든다.

메모 ( 스토리 )는 아직 요구 사항이 아니다. 카드 ( 스토리 )는 확정된 것이 아니다.
세부 사항을 남기지 않는 규율을 지켜야 한다.

 

스토리는 다음 조건을 만족해야 한다.
I = 독립적 => 의존성이 없어야 가치가 높은 것을 먼저 진행할 수 있다.

N = 협상 가능 => 세부 사항에 대한 협상이 진행될 수 있어야 한다.

V = 가치 => 비즈니스 가치가 존재해야 한다. 리팩터링, 코드 정리, 아키텍처 설계는 비즈니스 가치가 없다.

E = 추정 가능 => 작업량을 추정 못한다면 스토리가 아니다.

S = 작은 규모 => 반복 주기에 해결 가능한 사이즈여야 한다.

T = 테스트 가능 => 테스트 작성을 할 수 있어야 한다.

 

당연히 스토리끼리 합치거나, 더 작게 나눌 수 있다.

 

스토리의 추정이 힘든 경우 위한 추정을 위한 또 다른 스토리를 만들 수도 있다.

이것을 "스파이크"라 한다.

 

"바코드 인식 기능"의 스파이크는 "바코드 라이브러리 학습"가 될 수 있다.

반복 주기에서 연관된 스파이크가 다 끝나기 전에는 기능 구현 스토리는 진행할 수 없다.

반복 주기 0

회의를 통해 프로젝트에 필요한 스토리를 정한다.

ex) 로그인, 로그아웃, QA 인식 등등

 

이제 가장 먼저 기준 스토리를 정하고 포인트 ( 걸릴 시간의 수치 )를 정한다.

- 포인트는 추정을 나타내고 싶은 어떤 숫자든 상관없다.

ex) 1 ~ 6 , 1 ~ 100

 

기준 스토리를 기준으로 나머지 스토리의 포인트를 정한다.

ex) 로그인의 포인트보다 텍스트 수정이 더 포인트가 클 수는 없다.

반복 주기 1 ~ N

한 주기 동안 몇 개의 스토리 포인트를 처리할 수 있을지 짐작하고,

스토리 포인트에서 맞춰서 이번에 진행할 스토리들을 정한다.

- 중요도와 비용을 잘 비교해서 스토리를 정한다.

 

스토리를 다 처리 못해도 실패가 아니다.

다음 반복 주기에 전체 스토리 포인트를 조절할 수 있는 데이터가 나왔다면 성공이다.

- 데이터는 완료된 스토리들의 스토리 포인트를 통해 얻을 수 있다.

- 이전 반복 주기에 20 포인트를 완료했다면, 이번 반복 주기에는 20포인트만큼 스토리를 정하면 된다.

 

대신 데이터가 없으면 그것은 실패가 맞다.

스토리의 완료

스토리의 완료는 테스트를 기준으로 한다.

테스트가 끝나지 않은 스토리는 완료된 것이 아니며 반복 주기 동안 완료한 스토리 포인트 총합에 포함되면 안 된다.

 

테스트는 QA 가 만들어야 하고, 개발이 끝났다면 개발자도 이를 도와야 한다.

대신 스토리를 직접 구현한 개발자는 참여하지 않는 게 좋다.

( 개발자 본인만 아는 무언가가 들어갈 가능성 또는 주관적인 테스트 작성의 가능성? 때문인 거 같다. )

반응형

'개발' 카테고리의 다른 글

잘되던 쿼리 heroku 에서만 에러 날때  (0) 2021.02.18
Clean Agile - Chapter 5  (0) 2021.01.28
Clean Agile - Chapter 4  (0) 2021.01.21
Clean Agile - Chapter 2  (0) 2021.01.14
Clean Agile - Chapter 1  (0) 2021.01.14