개발 방법론은 어떻게 활용해야 하는가?
방법론에서 제시하는 산출물을 어떻게 활용할지 따져야 한다.
낭비를 최소화하는 관점에 따라 개발 조직이나 고객에게 큰 가치를 제공하지 못 하는 프로세스는 줄이거나 없애는 것이 바람직하다.
같은 방법론을 개발 기간 내내 동일하게 가져가선 안 된다.
프로젝트 진행에 따라 환경도 계속 변화하기 때문에 주기적으로 프로세스를 평가, 개선할 필요가 있다.
애자일
스프린트
애자일 방법론은 스프린트 단위로 요구사항의 변화를 받아들이며 개발한다.
스프린트를 계획하며 이전 요구사항과 새 요구사항을 보고 우선순위를 따져 작업하기 때문에 작업 중간에 요구사항이 바뀐다고 해도 다음 스프린트에 포함하면 그만이다.
이런 식으로 업무를 진행하면 결과적으로 우선순위가 떨어지는 요구사항은 프로젝트에 포함되지 않게 된다.
폭포수 방식이 아님
스프린트에도 물론 분석, 설계, 구현, 테스트의 공정이 발생한다.
하지만 폭포수 모델과의 차이점은 공정에 정해진 순서가 없다는 것이다.
고객에게 중요한 것은 중간 산출물이 아닌 결과물이라고 보기 때문에 모든 공정은 동시적으로 발생하여 중간 산출물을 최소화하고 제품의 품질을 높이는 것에 초점을 맞춘다.
주기가 규칙적 (타임 박싱)
스프린트는 빌드 기준으로 돌아가는 것이 아닌 2~4주 정도의 시간을 기준으로 돌아간다.
빌드 기준으로 개발 주기를 돌리면, 빌드의 규모에 따라 개발 주기가 들쭉날쭉하게 된다.
이런 규칙적인 개발 주기를 애자일에서는 타임 박싱이라고 표현하며, 이로 인해 업무 예측에 도움이 될 수 있다.
요구사항 도출
린 스타트업
요구사항 도출을 프로젝트 초기에만 국한하지 않고 주기적은 피드백을 통해 진행한다.
또한 언제든 요구사항이 바뀔 수 있다는 것을 전제로 둔다.
추후 변경되는 사항이 발생할 때를 대비해 프로젝트 초기에 상세한 요구사항을 모두 도출하지 않는다. 초기에 설정한 요구사항이 항상 정답은 아니기 때문이다.
고객은 제품을 원하지만, 정확하게 무엇을 원하는지는 알 수 없다. 전문가 또한 본인의 분야에 매몰되어 있을 가능성이 있다. 이를 해결하기 위해 요구사항 도출 과정에서 고객과 다양한 팀원들이 함께 참여한다. 고객이 인지하지 못 하는 문제를 도출할 수 있으며, 고객의 니즈를 다양한 측면에서 바라보기 때문에 창의적인 아이디어가 나올 수 있다.
디자인 씽킹
디자인 씽킹은 본질적인 문제를 파악하는 데에 중점을 둔다.
린 스타트업과 비슷하지만 '공감'이라는 과정이 추가된다.
공감은 관찰, 체험, 인터뷰 등으로 진행되나, 고객의 상황을 이해하고 유대감을 가지는 데에 중점을 두어 진행한다. 고객의 입장을 이해해야 본질적인 문제를 찾기 쉽기 때문이다.
내 자랑 😋✌️
창업을 하고 MVP를 개발하던 당시, 예상되는 사용자 표본들을 섭외해 인터뷰를 진행했다. 그들은 불편한 점은 있지만, 무엇이 어떻게 불편한지에 대해서는 정확하게 인지하지 못 한 상태였다. 인터뷰 이후 알게 된 고객 입장을 고려해 요구사항을 도출했고, 서비스는 사용자들에게 긍정적인 평가를 받았다.
요구사항 정의와 백로그
애자일에서 요구사항은 백로그에 작성한다.
백로그는 개발에 필요한 모든 업무를 우선순위화한 목록이며 백로그에 포함되는 요소들은 다음과 같다.
- 요구 기능, 비기능 요구사항
- 기술적, 관리적 업무
- 문제 해결 (리팩토링)
- 버그 수정
애자일은 변화를 주기적으로 수용해야 하기 때문에 요구 기능을 중심으로 백로그를 작성하고 선행 작업은 기술하되, 세부 작업은 백로그에 포함하지 않는다. 세부 작업은 스프린트에서 도출되며, 이런 방법은 추후 요구사항 변경에 대해 용이하게 대처할 수 있도록 한다.
요구사항을 정의하면 시장 가치가 높은 것을 우선으로 스프린트를 거쳐 MVP를 개발하고, 시장의 피드백을 받으며 지속적으로 개선해 프로젝트를 완수한다.
