다음글은
https://www.youtube.com/watch?v=3y5rCRys4t0
를 보고 작성하였으며, 개인적인 생각이 들어있을 수 있습니다!
흔히 팀원들과 프로젝트를 하다보면,
서로 언제까지 어떤 내용을 완료하겠다! 라는 약속(?)을 한다.
이게 바로 스프린트 이다.
애자일 방법론에서, 그러한 스프린트를
Iteration 이라고 하고, 해당 Iteration을 각각의 스프린트라고 생각하면 된다.
셋중에, 어떤 문항이 Iteration의 이득이라고 할 수 있을까?
정답은, 3번 "변화하는 조건에 대해 바로 적응 가능" 이다.
1번은, 애자일 프로세스를 사용하면 측정과 검증을 더 많이 하기 때문에, 코드 작성이 느리다. 하지만 점차 빨라지긴 한다.
2번은, 테스트를 빈번하게 돌림으로, 버그를 더 빨리 찾을 수 있다. 어차피 있던 버그는 찾을 수 있기 때문에, 많이 찾을 수 있다는건 어불성설이다.
이렇게, 애자일에서 가장 중요한 것은, 적응이다
애자일 방법론은
계획을 통해 주도했던 과거의 방법과는 다르게,
앞을 예측하며 개발하지 않고 일정한 주기(Iteration)를 가지고 끊임없이 프로토타입을 개발해 나가며 그때그때의 수정사항을 반영하며 개발하는 적응형 스타일이다.
바로 위에서 적은 그때그때의 수정사항에는
요구사항 또는 기능들에 대한 리스트,
예산,
데드라인이 있다.
위의 그림처럼 애자일 없이, 그때그때 필요한 적응 없이
가장 처음 계획했던대로 개발한다면
개발한 SW와 목표가 동떨어져있고,
소비자가 원하는 SW를 개발하는 와중에,
소비자의 비즈니스에 변화가 생겨 계속해서 원하는 SW가 변경될 수 있다.
그렇다면 어떻게 해결할 수 있을까?
바로 애자일 방법론이다.
요구사항 수집, 빠른 데모, 수정사항 반영, 잘못된 선택 바로잡기와 같은 Iteration을 진행하며,
위의 그림처럼 각각의 Iteration에 목표를 수정하고 반영하여
계속해서 다른 방향으로 나아가게 되고,
결국은 소비자의 니즈에 맞춘 SW를 개발하게 되는것이다.
계획을 통해 주도했던 과거의 방법과 애자일 방법의 차이를 그림을 통해 확인해보자.
Requirememts : 요구사항 분석
Design : 설계
Code : 소스코드 작성
Test : 테스트라고 하면,
기존의 워터풀 방식은 단 한번의 R, D, C, T 사이클이 돌고
최후에 한번 기능 검증을 한다 (Measurememt)
하지만 애자일 방식은, 여러번의 사이클을 돌며, 계속해서 변경사항을 반영하며 여러번의 검증을 한다
RDCTM -> RDCTM -> RDCTM -> ....... -> RDCT 마지막 M
소비자가 가장 중요하다.
소비자가 마음을 바꾸거나,
소비자가 원하는 방향으로 개발되지 않는다거나
소비자의 사업이 바뀐다거나와 같은 이슈를
자주자주 확인받고 적응하는 일을 통해
지금 우리의 개발방향이 맞는지, 완성중인 SW가 소비자가 진정 원하는건지
그때그때 Adaptive 하게 적응해야 한다.
이게 애자일 방법론 이다.
많은 도움이 되었습니다, 감사합니다.