안녕하세요! 이번 포스팅 주제는 현대 소프트웨어 개발 방법론의 실세라고도 할 수 있는 Agile 방법론에 대해 알아보고자 합니다. 더불어, DevOps를 위해 태어난 플랫폼인 GitLab이 지원하는 Agile 프로세스에 대해서도 알려드리고자 합니다.

Agile 방법론이란?

Agile 은 ‘기민한, 날렵한’ 이란 뜻으로 좋은 것을 빠르고 낭비 없는 개발을 가능하게 해 주는 다양한 방법론 전체를 통칭해 일컫는 말입니다. 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구사항을 더하고 수정하여 커다랗게 살을 붙이면서 개발해 나가는 프로세스 모델 방식입니다. 계획에 너무 의존하여 형식적인 절차를 따르는데 불필요한 시간과 비용이 따르며 전체적인 개발의 흐름 자체를 느리게 하는 단점을 가지고 있는, 단계에 따라 엄격한 순서대로 이루어지는 일직선의 과정의 고전적인 방법론 Waterfall 모델 프로세스와는 반대의 개념입니다.

GitLab을 사용한 Agile Planning

GitLab 개발 팀은 스크럼(Scrum), 칸반(Kanban), 익스트림 프로그래밍(XP)과 같은 린(lean) 프로젝트 방법론을 반복적이고 점진적으로 끊임 없이 제공하고 있습니다. 대기업 들은 SAFe(Scaled Agile Framework), Spotify 및 LeSS(Large Scale Scrum)를 비롯한 다양한 프레임워크를 통해 엔터프라이즈 규모에서 Agile을 채택하고 있습니다. GitLab을 사용하면 선택한 방법론에 관계없이 Agile 방식과 원칙을 적용하여 작업을 구성하고 관리할 수 있습니다.

GitLab Agile 툴의 특징

  • Issues : 기능마다 캡처하는 issue와 함께 사용자에게 비즈니스 가치를 제공하세요.
  • Tasks : 보통, 사용자 스토리는 개별 작업으로 특히 더 분리됩니다. GitLab의 issue 디스크립션 내에 task lists를 만들어 이러한 개별 작업을 추가로 식별할 수 있습니다.
  • Issue boards : 모든 진행 내용 들을 한 작업 공간 안에서 관리할 수 있습니다. 이슈들을 트래킹 할 수 있고 다른 상품과의 연동 필요없이 프로젝트 진행 경과에 대해 커뮤니케이션 할 수 있습니다. 백로그 부터 작업 완료까지 이슈를 해결할 수 있는 단일 인터페이스 역할을 합니다.
  • Epics : epics 와 함께 프로젝트와 마일스톤 전반에 걸쳐 더 효율적으로 프로젝트 포트폴리오를 관리하세요. 그리고 프로젝트 주제에 공유된 그룹의 이슈들의 트래킹에 대한 노력을 줄이면서 관리할 수 있습니다.
  • Milestones : 특정 기간 내에 GitLab milestones 을 통해 보다 넓은 목표를 달성하기 위해 생성된 이슈를 트래킹하고 merge request 할 수 있습니다.
  • Roadmaps : Start Date 및 Due Date를 타임라인의 형태로 시각화할 수 있습니다. epics roadmap 페이지에는 그룹 및 하위 그룹 아래에 있는 모든 epics에 대한 이러한 시각화 맵을 보여줍니다.
  • Lables : 개별 이슈를 만들어 할당하면 single label 또는 multi label 로 이슈 목록을 필터링할 수 있습니다.
  • Burndown Chart : 실시간으로 작업을 추적하고 리스크 발생 시 이를 완화합니다. burndown charts를 사용하면 작업이 완료되는 동안 현재 스프린트에서 범위가 지정된 작업을 시각화할 수 있습니다.
  • Points and Estimation : 가중치 속성을 할당하여 이슈에 대한 예상 노동량을 보여줍니다.
  • Collaboration : GitLab 의 issues, epics, merge requests, commits 등은 대화형 기능을 제공합니다.
  • Traceability : issue 생성 부터 연결된 파이프라인이 통과하고 종료 될 때까지 완벽한 추적 기능을 제공하는 이후의 merge request 로 팀의 issue들을 조정하세요.
  • Wikis : 여러분의 코드가 저장되어 있는 같은 프로젝트 내에 문서를 남기고 싶다면 wiki 라는 문서 시스템이 있습니다.
  • Enterprise Agile Frameworks : 대기업들은 다양한 프레임워크를 사용하여 엔터프라이즈급 규모에 Agile을 채택하고 있습니다. GitLab은 SAFe, Spotify, Orgulated Agile Delivery 등을 지원합니다.

GitLab이 지원하는 Agile iteration

User stories → GitLab issues

Agile 에서는 보통 사용자 스토리로 시작해서 기능을 캡처하여 사용자에게 비즈니스 가치를 제공하는 경우가 많습니다. GitLab에서는 프로젝트 내의 single issue가 사용자 스토리와 같은 역할을 합니다.

photo | 인포그랩 GitLab | 인포그랩 GitLab

Task → GitLab task lists

보통, 사용자 스토리는 더 세부적으로 분리될 수 있습니다. GitLab의 issue 디스트립션 내에 작업 목록을 만들어 개별 작업을 더 자세히 식별할 수 있습니다.

photo | 인포그랩 GitLab | 인포그랩 GitLab

Epics → GitLab epics

일부 Agile 실무자는 에픽이라는 여러 하위 issue로 구성된 상위의 사용자 스토리에 추상적인 주제를 지정합니다. 여러 GitLab에서의 epic에는 issue와 마찬가지로 제목과 설명도 포함되어 있지만 여러 하위 issue를 첨부하여 해당 계층을 표시할 수 있습니다.

photo | 인포그랩 GitLab | 인포그랩 GitLab

Product backlog → GitLab issue lists and prioritized labels

제품 또는 비즈니스 오너는 일반적으로 비즈니스 및 고객의 요구사항을 반영하기 위해 이러한 사용자 스토리를 만듭니다. 신속한 개발과 원하는 개발 순서를 파악하기 위해 제품 백로그에서 우선 순위를 지정합니다. 제품 오너는 이해 관계자와 의사 소통하여 우선 순위를 결정하고 백로그를 지속적으로 수정합니다. GitLab에는 사용자가 백로그를 추적하기 위해 볼 수 있는 동적으로 생성된 issue lists가 있습니다. 레이블을 만들고 개별 이슈에 할당할 수 있으며, 이를 통해 단일 레이블 또는 여러 레이블로 이슈 목록을 필터링할 수 있습니다. 이것은 더 많은 유연성을 허용합니다. 우선 순위 레이블을 사용하여 해당 목록의 문제를 정렬할 수도 있습니다.

photo | 인포그랩 GitLab | 인포그랩 GitLab

Sprints → GitLab milestones

스프린트는 작업이 완료되어야 하는 유한한 기간을 나타내며, 일주일, 몇 주 또는 한 달 이상이 될 수 있습니다. 제품 오너와 개발 팀은 스프린트에 대한 작업을 위해 미팅합니다. GitLab의 milestones가 이를 지원합니다. milestones에 시작 날짜와 기한을 지정하여 스프린트 기간을 캡처합니다. 그런 다음 특정 milestone에 issue를 할당하여 해당 스프린트에 issue를 할당합니다.

photo | 인포그랩 GitLab | 인포그랩 GitLab

Points and estimation → GitLab issue weights

미팅에서 사용자 스토리에 대해 논의하고 각 범위 내 사용자 스토리에 대한 기술적 노력의 수준을 추정하는 경우가 있습니다. GitLab의 issue에는 예상 노력을 나타내는 데 사용할 가중치 속성이 있습니다.

photo | 인포그랩 GitLab | 인포그랩 GitLab

Agile board → GitLab Issue Boards

스프린트 전반에 걸쳐 issue는 ‘개발 준비 완료, 개발 중, QA 중, 검토 중, 완료’와 같은 다양한 단계를 거칩니다. 일반적으로 이것들은 Agile 보드의 라인입니다. GitLab에서 issue board를 사용하면 단계를 정의하고 단계를 통해 issue를 이동할 수 있습니다. 또한 milestone 및 기타 관련 속성과 관련하여 보드를 구성할 수 있습니다. 팀에서는 워크플로 관점에서 스프린트 상태를 확인하기 위해 보드를 참고할 수 있습니다.

photo | 인포그랩 GitLab | 인포그랩 GitLab

Burndown charts → GitLab Burndown Charts

개발 팀은 실시간으로 제대로 진행되고 있는지 확인하고 위험이 발생할 때 이를 완화하기를 원합니다. GitLab은 burndown chart를 제공하여 팀이 현재 스프린트에서 범위가 지정된 작업이 완료되는 동안 "소멸"하는 것을 시각화할 수 있습니다.

photo | 인포그랩 GitLab | 인포그랩 GitLab

맺음말

Agile 쪽에서는 DevOps가 Agile로 대체되는 개발 생태계에서 파생된 하나의 새로운 실천 방법 중 하나로 보는 반면에, DevOps 쪽에서는 Agile이 DevOps 실천을 위한 구성 요소 중의 하나로 보는 시각이 있다고 합니다. 한 편으로는 Agile은 고객과의 상호작용에, DevOps는 개발팀과 운영팀 간의 협업 관계 구축에 집중한다는 차이점을 두어 Agile과 DevOps를 별개의 방법으로 보는 관점도 있다고 합니다. 즉, Agile과 DevOps는 어느 한쪽에서 파생되거나 출발한 개념이라고 단정 지을 수 없고 또는 다양한 관점으로 해석이 될 수 있다는 것이죠. InfoGrab은 이러한 Agile과 DevOps의 문화와 철학에 더욱더 가까이 다가가려 항상 노력하고 있습니다.

참고

https://about.gitlab.com/solutions/agile-delivery/