[Object Tracking Robot]0장 애자일(Agile) 기법 (feat. waterfall 기법)
2021.5.10 22:16
안녕하세요
프로그래밍을 배우는 빛나는 샤트입니다.
인공지능 프로젝트 팀장 역할을 몇 번 하다보니 기존의 프로젝트 운영 방식과 조금 다른 유연한 방식이 필요하다고 생각했다.
그 때 알게된 애자일 기법!
Agile이란 '민첩한'이라는 뜻을 가지고 있는데, 첫 느낌은 굉장히 유연성이 있는 프로젝트 진행 기법이라고 느꼈다.
실제로 기존의 방식인 Waterfall 방식과 어떤 차이가 있는지 비교해보자.
*참고*
이 글에서 쓰인 내용이 100% 모두 맞는 내용이 아닐 수 있음을 밝힙니다. 기법의 소개정도로만 읽어주세요.
또한 blog.rightbrain.co.kr/?p=5832, blog.rightbrain.co.kr/?p=5810
2개의 글을 읽고 작성했음을 밝힙니다.
1. Waterfall 방식
우리가 흔히 생각하는 진행 방식이라고 보면 된다.
문제 발견 -> 정의 -> design -> develop -> test -> 마무리
Final Goal을 달성하기 위해 한 단계씩 차근차근 밟아나가는 형식은 너무나 익숙하다.
학창시절을 생각하면 시험 기간이 있고 시험 범위가 있었다. 결국 우리가 해야할 건 너무나 분명했었다.
하지만 시험의 경우 정해진 틀이 있기에 가능하다고 생각한다.
회사의 프로젝트의 경우 언제든지 요구사항이 바뀔 수도 있고 변수가 생겨 프로젝트 진행의 방향이 조금 틀어질 수 있다.
즉, 변수에 유연하게 대처할 수 있어야 한다. (Final Goal이 변경될 수도 있기에 더 까다로울 수 있다.)
그럼에도 Waterfall 방식이 좋은 이유는 각 단계별 업무 분장이 분명하고 완료된 단계에 대해선 크게 문제가 없다는 점이다. (문제가 있다면 다음 단계로 진행할 수 없으니.)
단점은 분명하다. 변수에 의해 흔들리게되면 시간이 지체되고 유연한 대처가 어려워지게 되고 전체 계획을 다시 수립해야 한다.
2. Agile 방식
그렇다면 이러한 단점을 개선하기 위한 방법은 무엇이 있을까?
그 대답으로 Agile방식이 등장했다.
사실 전체 진행 방식은 Waterfall과 비슷할지도 모르겠다.
다른 점은 빠르게 작은 단위의 task를 완료하는 것이다.
아래 그림을 보자.
위 그림과 같이 Agile방식은 전체 프로젝트에 대한 일정이 아닌 개발자의 입장에서 볼 때 필요한 모듈 위주로 문제를 정의하고 빠른 일정으로 소규모 단위의 업무를 달성해낸다는 것이다. 이러한 방식은 변수에 유연하게 대처할 수 있다.
예를 들어 현재 세 번째 모듈을 개발하고 있는 상황에서 첫 번째로 완성한 모듈에 변동사항이 생겼다고 하자. 그렇다면 첫 번째 모듈만 수정하면 된다.
Agile방식은 스크럼 프로세스를 따른다.
스크럼 프로세스는 아래와 같은 특성이 있다. (출처: 스크럼, 위키백과)
- 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
- 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
- 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
- 날마다 15분 정도 회의를 가져라.
- 항상 팀 단위로 생각하라.
- 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.
백로그에 해야할 업무를 명시하고 스프린트를 정해진 기간(1~2주)에 끝내고 리뷰 후 피드백하는 과정을 반복하는 것이다.
이렇게 되면 업무 단위로 일을 빠르게 진행할 수 있게 된다.
이러한 방식을 잘 할 수 있는 소프트웨어 'jira'
https://www.atlassian.com/ko/software/jira
위 그림처럼 백로그에서 생성한 업무를 스프린터 단위로 진행하는 모습이다.
To-Do, In Progress, Code-Review, Done 등 진행 단계에 따라 이슈들을 한 눈에 볼 수 있다.
(물론 각 담당자가 일을 얼마나 잘하고 있는지 안하고 있는지도 알 수 있다.)
3. Waterfall VS Agile
두 가지 프로젝트 진행 기법에 대해 소개했는데, 어떤 기법이 더 좋다는 것이 아닙니다.
장,단점이 존재하기에 적절히 섞어서 사용해도 괜찮을 것입니다.
Agile의 경우 수정이 가능하다는 점에서 전체 프로젝트 방향성을 잃을 수도 있다는 점이 있을 수 있습니다.
(무한 수정 루프에 빠질수도...)
아직 어색한 기법이지만 새로운 개념을 시도하는 것만으로도 의미가 있을 것이라 생각합니다.
4. Agile 기법 적용
이번 프로젝트를 진행하면서 Agile기법을 적용하려고 했고 1주차가 마무리되는 시점(5월 13일 목요일)에 대략적인 방법을 정립했다.
1) 기존의 방식
- 자율주행 로봇의 구동 기능별로 하나씩 구현: 예시) 추적 알고리즘 -> 전진 -> 정지 -> 회전 -> 장애물 회피 -> 돌발상황 시나리오 대응
위와 같이 추적 알고리즘을 열심히 공부해서 공부한 것을 바탕으로 로봇을 잘 구동되게 하자 라고 생각했다.
2) 애자일 방식
- 로봇의 구동 방식을 먼저 정립: 정지 조건, 회전 조건, 장애물 회피 조건 등을 먼저 정립
- 프로젝트를 진행하면서 계속 추적 알고리즘을 탐색하고 공부하며 개선해나가는 방법.
이 방법을 선택한 이유는 우리가 결국 최종 목표는 '특정 인물을 잘 추적하는 자율주행 로봇'을 만드는 것이기 때문.
그리고 1~2주 내에 추적 알고리즘을 많이 학습하기 어렵고 공부가 끝나고 이해하자마자 바로 적용해 어떤 결과가 나오는 지 눈으로 보는 것이 더욱 효과적이기 때문.
그래서 아래와 같이 주차별 Task를 간략히 정리했다. (추후 업데이트 예정)
1주차: 추적 알고리즘 탐색, 로봇 기동 방식 정립
2주차: 추적 알고리즘 적용(2개: DeepSORT), 평가 기준 정립, 적용 결과 정리, 로봇 기동 방식 개선(필요 시)
3주차: 추적 알고리즘 적용(2개), 적용 결과 정리, 로봇 기동 방식 개선(필요 시)
4주차: 추적 알고리즘 적용(2개), 적용 결과 정리, 로봇 기동 방식 개선(필요 시)
5주차: 로봇 연동 및 기동 디버깅
6주차: 최종 개선 및 보고서 작성, GitHub 정리