애자일

피드백이 계속되는 상황에서 

 

어떻게 하면 효율적으로 프로덕트를 만들고 개선해 나아갈 것인가?

 

이러한 질문에 대해 프로세스 최적화를 한 전략이 Agile이라는 개발 방법론인 것 같다.

 

결국 모든 일이라는게 

 

1. 목표를 정한다.

2. 달성한다. 

 

이렇게 단순화 할 수 있는데,

 

여기에 "시시각각 변화하는 환경과 피드백"에 대응하기 위해서

 

 

1. 조직의 관점에선

 

1) 팀의 단위가 작아서 의사결정이 빨라야 한다.

(한 팀을 스쿼드, 스크럼이라 부른다.)

2) 일반적으로 프로덕트 오너(프로덕트 매니저)와 개발자로 나뉜다.

(경우에 따라선 몇몇 직무들이 추가될 수도 있다.)

3) 하나의 기능을 위해 한 번의 스프린트를 진행한다.(1~2주)

4) 스프린트를 진행하고 매일 증가분을 축적한 후 체크한다.(이를 데일리 스크럼이라 한다.)

5) 스프린트 막바지에 스프린트 리뷰를 한다.

6)  중간중간에 스프린트 회고를 한다. 이때, 회고라고 하여 막바지에 하는게 아닌 중간중간에 한다. 목표는 팀의 화합을 위해 팀워크적 문제점들을 살피는데에 있다.

 

기본적으로 "계획 -> 실행 -> 평가 -> 피드백" 및 중간 "팀워크 체크" 이렇게 나눠볼 수 있겠다.

 

 

2. 목표 달성의 관점에선

 

1) 큰 목표를 정한다.

2) 큰 목표를 달성하기 위해 필요한 중간 목표들을 정한다.

3) 중간 목표들을 달성하기 위한 작은 목표들을 정한다.

4) 각 목표들을 달성해 나갈 때, 실험을 통해서 피드백을 받고 반영한다.

 

이렇게 가지치기 형식으로 쪼갠 뒤,

 

기능에 따라 카테고리화 하고

 

현재 상황과 환경에서 중요한 순서대로 분류하고 하나씩 처리해 나가는 방식이라고 할 수 있다.

 

(여기서 각각의 목표들을 모은 집합을 "프로덕트 백로그"라 한다.

그리고 각 스프린트의 목표가 되는 집합을 "스프린트 백로그"라 한다.)

 

다만, 기술적으로는 빠른 주기로 업데이트가 필요하다는 인식을 갖고

 

그에 맞춰 개발을 해 나아가야 할 것이다.

 

특히, 여러 기능들을 개발할 때, 나중에는 그 기능들을 하나의 모듈로서 본체에 합쳐야할 텐데,

 

이 부분도 고려해야 할 것이다.

 

(모듈화를 통한 유연성 확보라는 표현도 알맞겠다.)

 

 

만약 실제로 실행한다면, 최소한의 기능을 만들어 놓고 배포한 뒤, 실제로 효과가 있는지(실험)에 대한 부분은 내가 맡아서 하면 될 것 같다. 어차피 데이터 분석 및 ML 모델링, 실험계획은 도맡아서 해야한다.