안녕하세요. 엔지엠소프트웨어입니다. 개발자와 일반인분들에게는 다소 생소한 내용일듯한데요. DevOps는 보통 매니저가 프로젝트 시작전에 어떻게하면 이 프로젝트를 효율적으로 관리하고, 개발의 품질과 속도를 개선해서 퍼포먼스를 올릴지에 대한 고민에서 출발한 개념이자 프레임워크입니다. 오래전부터 프로젝트 매니저들은 자기만의 철학과 관리 기법을 나름대로 적용시키면서 프로젝트를 성공시키고자 노력했습니다. 이런 여러가지 철학(?) 또는 기술들을 하나의 시스템화 한것이 DevOps입니다. 개발 초창기부터 IBM의 CC, CQ를 사용해봤던 저에게는 그렇게 생소한 개념이 아니긴하지만, 이 제품들이 워낙 고가이다보니 경험해본 분들이 그렇게 많지는 않았던거 같습니다. 저는 운이 좋은 케이스였던거죠^^;

 

DevOps 사례는 애플리케이션 개발팀(Dev)과 해당 IT 운영팀(Ops)간의 원활하고 지속적인 커뮤니케이션, 협업, 통합, 가시성 및 투명성을 목표로 합니다. Dev와 Ops간의 이러한 긴밀한 관계는 초기 소프트웨어 계획부터 코딩, 구축, 테스트 및 릴리즈 단계와 구축, 운영 및 지속적인 모니터링에 이르는 모든 활동(Life-cycle)들에 걸쳐서 관리해야 합니다. 이런 관계는 추가 개선, 개발, 테스트 및 구축에 대한 지속적인 피드백 루프를 추진하는 원동력이 됩니다.

 

 

DevOps에 대해서 간략하게 알아봤는데요. CQ, TFS, JIRA, Azure등등... 사용해본 경험을 기반으로 개인적인 내용에 대해 설명하도록 하겠습니다. 주로 아틀라시안社의 JIRA를 사용하고 있는데요. 저는 이번에 회사에서 Azure를 도입했기 때문에 Azure를 기반으로 이야기를 풀어 나가도록 하겠습니다.

 

애자일이란?

애자일은 신속한 반복 작업을 통해 실제 작동 가능한 애플리케이션을 개발하여 지속적으로 제공하기 위한 소프트웨어 개발 방법론입니다. 애자일 방법론의 정의는 애자일이 독특한 소프트웨어 개발 방식임을 나타내기 때문에 약간(?) 오해의 여지가 있는데요. 애자일은 정확하게 말하면 소프트웨어 개발에 필요한 작업을 알려주는 일련의 규정은 아닙니다. 그보다는 협업과 워크플로우를 바라보는 하나의 관점이며, 우리가 무엇을 어떻게 잘 만들지에 대한 선택을 안내하는 가이드라고 보시면 됩니다.

 

애자일 방법론의 목표는 소프트웨어의 작은 구성 요소를 신속하게 제공하여 고객의 만족도를 개선하는 것입니다. 이런 목표를 이루기 위해 적응형 접근 방식과 팀워크를 활용한 지속적인 개발에 중점을 두고 프로젝트를 관리하는 것입니다. 일반적으로 애자일 소프트웨어 개발은 소프트웨어 개발자와 비즈니스 담당자가 자체적으로 조직한 소규모 팀으로 이루어지며 이들은 소프트웨어 개발 라이프 사이클 전체에 걸쳐 정기적으로 직접 소통하며 협업을 유지해 나갑니다. 전통적인 개발 방법론에서 탈피하여 소프트웨어 도큐멘테이션에 대한 경량화 방식을 선호하며 라이프 사이클의 모든 단계에서 적극적으로 변화를 수용합니다.

 

위에서 잠시나마 알아본 내용을 보면 DevOps와 애자일은 개념적인 요소에 지나지 않습니다. 이런 개념적인 활동들을 쉽게 관리하기 위한 도구들이 존재하는데요. IBM의 CC/CQ와 TFS, JIRA, Azure DevOps가 있습니다. 대부분 JIRA는 사용해봤을테고... Azure DevOps는 저처럼 처음 접해보는 분들이 많을겁니다. Azure의 Source Control(Git)만 사용해오다가 DevOps는 처음 접하기는 하지만, JIRA와 유사하기 때문에 적응하는데 크게 어려움은 없을겁니다^^

 

관리자가 생성한 Azure의 프로젝트에 접속합니다.

 

 

좌측의 메뉴 목록에서 Boards를 클릭하세요.

 

 

아래 그림과 같이 워크 아이템(Work Items)을 추가할 수 있습니다.

 

 

1. Epic

개발을 완료하기까지 긴 시간이 필요하거나 몇번의 스프린트가 요구되는 큰 업무 덩어리를 등록합니다. 여러개의 스토리 또는 테스크를 하위로 가집니다.

 

2. Feature

Epic의 주요한 특징들을 기준으로 등록합니다. 예를 들어 Epic에 펌프 장비 데이타 수집을 등록했다고 해봅시다. 그러면, Feature는 FTP, SFTP 구현에 대해 등록할 수 있습니다.

 

3. User Story

서비스를 이용하는 고객에게 가치를 줄 수 있는 기능을 서술한 내용입니다. 각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성합니다. 펌프 장비의 특정 위치에 센서 데이타가 파일로 생성되고, 이곳에 접근해서 파일을 가져온다고 작성할 수 있습니다. 여기서, 사용자는 행위 또는 목표를 수행하여 어떤 결과가 나올지에 대한 이유를 기술합니다.

 

4. Task

타스크는 스토리를 완료하기 위해 개발자가 작업해야 하는 작업의 단위입니다. FTP 서버 구성, FTP 클라이언트 개발, SFTP 권한 및 인증서등등... 스프린트를 돌릴 수 있을만한 작은 단위로 쪼개서 등록합니다. 이 때 주의할점은 유저 스토리에서 나타나지 않는 비기능 요건들도 충분히 반영하여 작성해줍니다.

 

작업 항목 구조

 

 

백로그 계층 구조

 

 

각 작업 항목 양식 내에서 토론 섹션을 통해 수행할 작업을 설명하고, 프로젝트 참가자에게 작업을 할당하고 상태를 추적합니다. 다른 사용자와 공동 작업할 수 있습니다. 이와 같은 일련의 과정을 좀 더 이해하기 쉽게 서술하면 아래와 같이 설명할 수 있습니다.

 

Example

A라는 회사에서 로켓 발사를 추진할 계획이며, 발사 장면을 유튜브로 스트리밍 실시간 방송할 예정입니다. 그러나, 이 회사는 유튜브로 스트리밍할 수 있는 서비스가 없습니다. 그래서, 넷플릭스나 디즈니로 스트리밍하던것에 추가로 유튜브까지 스트리밍하기를 원합니다.

 

Epic

• 기존 스트리밍 기능에 유튜브 스트리밍 기능 추가 및 개선

 

User Story

• 기존 스트리밍 서버에 유튜브 서비스를 추가할 수 있는 기능 필요
• 기존 스트리밍 인터페이스에 유튜브 인터페이스를 추가할 수 있는 방법
• 유튜브 서비스이기 때문에 스마트폰을 비롯한 태블릿에서도 사용 가능하게 가로/세로 사이즈 조정 필요

 

개발에 필요한 세부 내용은 다루지 않도록 하겠습니다. 이 부분은 프로젝트 매니저 또는 프로젝트 리더가 기술 검토 및 Function List를 작성하고 이를 토대로 WBS를 만든 후 각각의 항목들을 Task로 등록해야 합니다. 이 때 기술적인 내용들과 함께 디자인도 같이 추가해야 합니다. 디자인은 화면 명세로 Function List의 번호와 매핑되어야 하고 추적할 수 있어야 합니다. 나중에 언급하겠지만, 타스크는 브랜치와도 연동되고 다른 개발에 영향을 주면 안됩니다. 지속적인 통합(CI: Continuous Integration)을 위해 유의해야 합니다.

 

Initiative

고객쪽 관점에서 관리되는 것을 말하며 Epic이 여러개의 Story로 구성되는 것과 비슷하게 이니셔티브는 여러개의 애픽으로 구성됩니다. Epic보다 더 광범위하고 여러 팀으로부터 진행된 Epic이 취합되어 이룰 수 있는 최종 단계의 Goal이라고 생각하시면 됩니다. Epic이 한달 또는 한 분기 내에 완료되는 반면에 이니셔티브는 일반적으로 1년 또는 수년이 걸리는 경우가 많습니다.

이니셔티브: 올해 로켓 발사 비용을 5프로 줄이길 원합니다.

 

Epic

• 발사 단계 연료 소비량을 1프로 감소시키겠습니다.
• 모든 발사체에 온도 조절기를 설치해서 온도를 낮춰 안정성을 높입니다.

 

여기까지 간략하게 프로젝트 매니저가 어떻게 프로젝트를 관리하고 이슈들을 등록하며 백로그를 생성하는지에 대해 알아보았습니다. 개념적인 내용으로 작성한지라 처음 프로젝트 매니저를 맡은 경우 어떻게 관리해야할지 머리속이 복잡하고 막막할 수 있는데요. 사용자 스토리 칸반 보드는 사용자 스토리 및 자식 작업을 빠르게 추가하는데 유용한 도구입니다. ①프로젝트팀을 선택하고, ②Boards를 클릭합니다. ③프로젝트를 선택하면 칸반 보드가 표시됩니다.

 

 

애자일 프로젝트 관리 방법을 사용하면 이정도로 정리할 수 있습니다. 스크럼 스프린트로 관리하는 경우 백로그로 제품에 대한 요구사항들을 모아놓고 이 항목들을 유저 스토리에 연결시킵니다. 그리고, 스프린트 백로그에는 타스크에 등록된 항목들을 유저 스토리에 연결해서 추가하여 관리할 수 있습니다. 스프린트를 운영하는 경우 그루밍전에 다음 스프린트에 개발할 기능에 대해서 대략적으로 리뷰합니다. 이 때 Why, How에 대해 설명할 수 있어야 합니다. 그리고 스토리 포인트를 산출합니다.

Why

• 개발자가 다음 스프린트에 대한 가시성을 확보하여, 스프린트가 끝나고 리뷰 및 테스트기간에 검토할 수 있도록 해줘야 합니다.
• 그리고, 코드 리뷰 후 다음 스프린트에 대해 관리자가 간략하게 개발 가능성, 개발 기간에 대해 파악해야 합니다.

 

How

• 1시간 정도로 사용자 스토리나 UX 프로토타입을 리뷰하고, 가급적 실제로 돌아가는 UX 목업을 갖추는게 좋습니다. (PM, PL 작업)
• 일반적으로는 PPT에 디자인 문서를 작성하여 개발자와 리뷰하는 시간을 가집니다. 이 때 개발자의 질문을 유도하여 개선점을 찾으면 좋습니다.

 

스토리포인트 산출

등록된 사용자 스토리의 개발 추정 기간을 산정합니다. 개발자마다 개발 퍼포먼스가 다르기 때문에 팀원들과 같이 산정하며, 이 때 플래닝 포커 방식을 많이 사용합니다. 보통은 제품 백로그에 스토리 포인트를 추정하여 등록하지만, 개발자가 다시 수정할 수 있습니다. 이 때 스토리포인트 수정에 대한 사유를 명확히 해야 합니다. 또한, 스프린트 백로그의 스토리를 다시 추정하기도 합니다.

 

플래닝 포커란? (스크럼 포커)

아래 그림처럼 FTP Upload & Download 타스크를 개발할 때 A라는 개발자가 얼마만큼의 스토리 포인트를 가질지 결정하는 과정을 말합니다. 이 때 팀원들간 가장 높은 스토리포인트와 가장 낮은 스토리포인트를 낸 팀원들의 주장을 각각 들어보고, 다시 한번 투표합니다. 2번째 투표에서 가장 많은 득표를 받은 스토리포인트가 개발 기간이 됩니다. 플래닝 포커 앱이 있으니 핸드폰으로 찍어서 보여주고 의견을 발표하면 됩니다. 의견 발표는 위에서도 말했듯이 가장 높은 스토리포인트와 가장 낮은 스토리포인트를 낸 2명입니다.

 

 

스프린트가 완료되면 코드 리뷰시 매니저는 해당 스프린트를 종료(State: Done)합니다. 또는 서브 타스크를 다시 등록하고 스프린트를 한번 더 진행합니다. 스프린트가 종료되면 이 스프린트와 연결된 백로그를 결정합니다. 이 글은 개발자 관점에서 작성하는건 아니고 프로젝트 매니저와 관리자가 어떻게 프로젝트를 관리하고 유지하는지에 대한 내용입니다. 따라서, 개발자가 타스크와 스프린트를 어떻게 처리하고 백로그와 칸반의 상태를 변경하는지는 설명하지 않습니다. 이 부분은 다음에 다시 자세하게 설명하도록 하겠습니다.

 

마지막으로 프로젝트 관리자가 스프린트 리뷰(코드 리뷰)를 어떻게 진행하는지에 대해 말씀드리고 마치도록 하겠습니다.

종료 기준을 정의합니다. Define Done이라고 합니다.

• 받아들일 수 있는 기준을 세우고, 다음 타스크를 진행할 수 있도록 해줍니다.
• 테스트 방법을 기록하고 검증합니다.

스프린트가 잘 끝났으면 서로 축하합니다. 

기술 스텍 및 노하우를 서로 공유합니다. 필요하다면 개발자는 데모를 보여주면서 설명합니다.

매니저는 회고의 시간을 가지고 잘한 것, 반성할 것, 개선할 것에 대해 이야기를 나누는 시간을 10분정도 가지고 미팅을 마칩니다.

 

개인적으로 하나의 완벽한 방법은 없다고 생각합니다. 더 많은 대화와 소통이 필요할뿐이고, 서로 도와가면서 한배를 탄 팀원이라는 강한 결속력이 수반되어야 합니다. 팀원들 모두는 "일이 되는 방향"으로 스크럼을 점진적으로 개선하는 활동이 중요합니다. 그리고, 무엇보다 스프린트를 정해진 기간안에 완수해야 한다는 책임감이 요구됩니다. 개발자 입장에서 빠르게 굴러가는 스프린트로 인해 스트레스를 받기 보다는 옆의 팀원과 소통하면서 빠르게 문제를 해결해 나갈 수 있는 문제 해결 능력을 키우는데 가치를 둔다면 좋을듯 합니다.

 

개발자에게 후원하기

 

추천, 구독, 홍보 꼭~ 부탁드립니다.

여러분의 후원이 빠른 귀농을 가능하게 해줍니다~ 답답한 도시를 벗어나 귀농하고 싶은 개발자~

감사합니다~

추천0 비추천0