Agile case study, Scrum, DevOps 란 무엇일까?

Agile, Scrum, DevOps 기법에 대해 다시한번 내용 정리를 할 필요성을 느껴 전반적인 내용을 정리해보았다.

본 글의 구성은 다음과 같다.

-      Agile Development Background

-      What is Agile?

-      What is Scrum?

-      Scrum Overview

-      Scrum Tools

-      Agile / Scrum case study <Fail>

-      Agile shortcomings [ In business ]

-      Agile shortcomings [ In Team project ]

-      Agile / Scrum case study <Success>

-      Supporting open source software.

-      What is DevOps?

-      DevOps tools

Agile Development Background

Agile 등장 이전, 기존의 Waterfall 방식은 1~2년에 걸쳐 각 팀에 요구사항이 나뉘어져 있고 폭포처럼 위-> 아래로 흐르며 진행되는 개발론인데, 이는 시작전 많은 고민을 통해 뒷 단계를 수월히 하고 문서 작성을 통해 일을 명확하게 규정하여 문제를 최소화 하는 것을 목표로 했다. 그러나 앞선 과정에서 후에 발생할 모든 일을 고민하는 것은 사실상 불가능하며, 소프트웨어 개발보다도 문서를 작성해두는 것에 집중하여 정작 소프트웨어를 놓치는 경우가 있었다. 또, 앞선 시기에 발생된 요구사항이 개발이 완료된 단계에서도 요구가 되는지에 대한 문제, 즉 사용자의 니즈에 따라 유동적으로 변화할 수 없는 문제가 있었다. Service 중심 세상에는 waterfall 방식이 부적합하다고 판단되었고, 이에 무한 경쟁과 함께 빠르게 변화하는 세상에 맞는 방법론이 필요하게 되었다.

 

What is Agile?

Agile의 사전적 정의는 ‘날렵한’, ‘민첩한’ 등 이며, 2001년 ‘애자일 소프트웨어 개발 선언’에 의해공식적으로 명명되었다. 이는 스크럼, 칸반 등을 포함하는 소프트웨어 개발 방법론으로, 소프트웨어 개발에 대한 진지한 토론이 담긴 대 헌장이라고 할 수 있다. 미래에도 의미있는 SW를 만들자는 의미를 가진 선언은 크게 4 가지로 말할 수 있다.

-      공정과 도구보다 “개인의 상호작용을”

-      포괄적인 문서보다 “작동하는 소프트웨어를”

-      계약 협상보다 “고객과의 협력을”

-      계획을 따르기보다 “변화에 대응하기를”

 

즉, 고객만족을 위해 더 짧은 개발 주기를 요구하며 이를 위해 현업과 개발자 등, 업무 담당자간의 실용적인 의사소통이 필수적이라는 것. ‘형식’보다는 ‘실용’을 추구한다고 볼 수 있다.

 

Agile 방법론에 조금 더 구체적인 원리는 다음과 같이 제시될 수 있다.

1.     상사의 만족이 아닌, 실 사용자와 고객을 만족시키자.

2.     요구의 변화를 환영하자

3.     SW를 주기적으로 내보내자.

4.     비즈니스 사람들과 대화를 서슴지 말자. Model을 이해해야한다.

5.     믿을 수 있고 자기동기적인 팀원과 팀을 이루며 그들을 믿어라

6.     원격으로라도 face to face 대화(음성&화상)를 하자.

7.     문서가 아닌 실제 결과물을 보여줘라

8.     지금과 미래에 지속가능한 SW를 만들자

9.     자가발전, 대등한 파트너쉽, 새로운 학습을 위해 주기적으로 행하는 습관을 기르자

10.  가장 중요한 것을 중심으로 단순화하자

11.  팀을 짤 때 필요한 사람을 고민하자

12.  주기적으로 과정을 재검토하자.

 

Agile이 생각하는 이상적인 개발자는

-      Self motivated, Self learning, Self devotion

한 사람이라고 할 수 있다. 자가발전, 자가학습을 통해 공동 목표에 기여할 수 있는 사람..

그리고 혼자 하는 것이 아니라 팀원과의 토론을 통해 파트너로 함께 협력하는 사람이다.

 

What is Scrum?

Scrum 의 사전적 의미는 ‘럭비에서 반칙이 있을 때, 양편 선수가 밀집하여 서로 팔을 꼭 끼고뭉치는 일, 그 사이로 굴려넣은 공을 자기편 쪽으로 빼냄’이다.  이렇게 럭비팀에서 쓰던 용어를 소프트웨어 개발 프로세스에 사용한다는 것은, ‘팀’이라는 단어가 주는 의미를 개발 팀에 적용해 효율적인 성과를 위함이다. Scrum은 Agile 방법론 중 하나로, 소프트웨어 개발 ㅍ로젝트를 위해 고안되었지만 팀의 개선과 프로젝트 관리를 위해서도 사용되는 경험 관리 기법이다. 간단히 말하면 3~9명의 팀을 구성하여 커뮤니케이션 하며 일어서서 하루에 15분 정도 매일매일 토론하고 2~4주단위마다 sw 보고를 하는 과정을 통해 30일간 제품 릴리즈(Sprint)를 점진적으로 수행하자는 것.

Scrum의 구성원은 다음과 같다.

-      Product Owner

제품 책임자는 제품의 가치와 팀의 결과물을 최상으로 만들 책임을 가지며, 제품 백로그 관리를 담당하는 유일한 사람이다. 주요 업무로는 명확한 요구사항에 대한 이해를 바탕으로 테스트 대상, 범위 및 테스트 목표설정, 리스크를 고려한 테스트 우선순위 및 아젠다 설정, 매 스프린트마다 테스트 우선순위 수정 결정, 작업 결과의 승인여부 결정

-      Scrum Master

리더이자 조력자이며 사람들이 스크럼을 제대로 이행하고 수행하고 있는지에 대한 책임을 가진 사람이다. 주요 업무로는 목표 달성 방법에 대한 조언, 여러 사람과 조직이 서로 잘 협력하도록 도우며 장애를 제거, 스프린트 목표와 관계없는 추가적인 작업 과 같은 외부 간간섭으부터 팀 보호, 일일 스크럼 미팅/스프린트 계획 미팅/리뷰 등의 프로세스 준수 관리, 생산성 함양 책임

-      Scrum Team

매 스프린트에서 완료된 기능을 지속적으로 추가하여 잠재적으로 출시 가능한 제품을 배포할 수 있는 전문가들로 5~9명으로 구성된 팀. 주요 업무로는 정의된 테스트 목표를 달성하기 위한 업무 결정, 스프린트 작업 결과를 제품 책임자와리뷰, 기술적/사업적 테스트 역량 확보, 매 스프린트마다 의미있는 결함을 발견하고 제거되도록 관리

 

Scrum Overview

1.     Product backlog : 프로그램이 가져야하는 전략적 기능/모든 요구사항정리(목록) 완료 기준 명확해야함.(내용, 가용성, 우선순위화) <Product owner>

2.     Sprint Planning Meeting : 서비스, 기능 우선순위 중심으로 항목을 나눔. 제일 중요한 항목을 첫 Sprint로 지정. *1개월

3.     스프린트를 기준으로 평균 2~4시간, 최대 8시간의타임 박스 운영.. version 하나씩.. <Team>

4.     Sprint backlog : 스프린트를 위해 선택된 제품 백로그 항목들의 집합. 목표를 실현하기 위한 계획서. 해당 Sprint에서 해야할 작업만 정리, 매일 남은 작업량을 스크럼 미팅을 통해 업데이트. 우선순위별로 정리

5.     Sprint 1~4 Weaks : 짧은 시간동안 제품/서비스 개발을 지속적으로 개선하며 피드백을 받아 고쳐나감. <Scrum Master>

6.     Daily Scrum : 어제의 과업이 완수됐는지 확인, 다음 업무 재분담, 장애물 있는지 확인. 보통 15분 이내로 진행.

l  번다운 차트

스프린트 기간 동안 개발된 스프린트 백로그 비율을 표시하는 차트. 개발 진행 속도와 추진 상황을 한눈에 간단히 알아볼 수 있다. 지속적 관리와 업데이트 필요.

7.     Sprint Review : 스크럼 팀과 제품 이해관계자들이 해당 스프린트에서 무엇이 완료되었는지 함께 확인하는 리뷰. 1개월 스프린트를 기준으로 4시간 타임 박스 미팅

8.     Sprint Retrospective : 1개월 스프린트 기준 3시간 타임박스. 해야할 작업이 잘 정의되었는지, 완료의 정의가 잘 되어있는지, 업무에 대한 합의가 업데이트 되었는지 회고. 생산적이었는가/2개의 액션 집중 회고

Scrum Tools

DPM 홈페이지에 가면 팀플을 할 때 쓸만한 Scrum 툴들을 확인할 수 있다.

Ex) Clarizen, Monday.com, ProjectManager.com, Zoho Sprints, Kanbanize, MeisterTask, airfocus, Pivotal Tracker, Nostromo, Ravetree 등

또한 Opensource.com 페이지에 가면 오픈소스 관련 기사를 모아서 볼 수 있으니 project management tools for agile teams 에 관심이 있다면 들어가서 한번 봐보자.

 

Agile / Scrum case study <Fail>

Agile의 실제 적용사례는 태생이 IT 기업인 카카오, 네이버 같은 기업보단 은행, 증권사와 같은 비즈니스 중심의 기업 상황에 더 적합하다고 생각한다. 이런 형태의 비즈니스를 운영하는 기업들은 현업이 정의한 요구사항을 개발자가 구현하는 전통적인 개발방식에 익숙하며, 신규 서비스의 개발보다는 레거시 시스템의 유지보수가 차지하는 비중이 압도적인 특징이 있기 때문이다.

 최근 이러한 기업들은 ‘디지털 트랜스포메이션’ 전략을 강조해 IT부분에서 많은 변화를 시도중이며, 그 중에서도 agile과 같은 개발 문화를 도입하려는 시도는 지속적으로 이루어지고 있다. 그러나 agile 방법론을 성공적으로 도입했다는 기업은 좀 처럼 찾아보기 힘들다. 그 이유가 뭘까?

 

Agile shortcomings [ In business ]

대개의 기업에서 agile 방법론을 적용하려는 주체는 기업의 임원들이며, 이들은 이론적인 설명에 매료되어 막연한 기대감으로 전략을 추진한다. 예를 들어,

임원 : 한번해봐!

기획 및 개발팀

-      스크럼, 칸반 등 개념 검토 및 현황 조사

-      개발팀 교육용 자료 제작 및 교육 실시

-      화이트보드/포스트잇 활용 등 문화 정착을 위한 노력

-      애자일 툴 제작 업체 섭외 및 도입 회의 진행

-      개발자 대상 툴 테스트 요청

-      커스터마이징을 위한 개발자 의견 수렴 등

이러한 과정으로 진행되는 프로젝트는 어설프지만 기획팀의 의도에 맞춰 개발 방식의 변화를 시도하기도 하나, 마음처럼 조직 전체로 활성화되지 못하고 팀마다 적용하는 방식이 제각각이 되기 일쑤이다. 위의 절차에는 기존 방식 및 문제점을 정확히 인지하고, 이를 바탕으로 구성원이 명확한 목표 의식을 공유할 필요가 있으나.. 기업에서 기존의 방식을 명확히 정의하고 있는 경우는 거의 없다. 기업의 많은 리더들은 자신들의 기존 개발 방법론이 ‘Waterfall’ 방법론이라 이야기 하지만, 실제로 일하는 개발자들은 이 얘기를 공감하지 못하는 경우도 많다. 개발 도중 요구사항이 변경, 추가되는 경우가 비일비재하고, 테스트 단계에서 설계가 변경되는 경우도 많기 때문이다. 이처럼 사실상 기업에서 명확한 개발 방법론이 존재하는 경우는 드물다. 그렇기 때문에 더욱 기업의 임직원들은 덜 체계적인 상태에서 일하고 있다는 불편한 사실과 마주할 용기를 내어야 한다. Agile을 실현하기에 앞서 반드시 기존의 프로세스를 단계별로 정의하고 문제점을 도출하는 노력을 해야하며, 단순히 임원 보고용으로 조사해서는 안된다. 방법론을 정의내리려 하지 말고 기존의 프로세스를 분석하고 실용적으로 변화시키기 위한 고민을 해야 할 것이다. 그리하여 보완점을 이렇게 정리할 수 있겠다.

1.     Agile에 끼워 맞춰 모든 프로세스를 재정의하는 ‘변화를 위한 변화’를 지양하고, 그저 조직 구성원들이 자연스럽게 받아들일 수 있을만한 단계적 프로세스 개선을 목표에 둬야 한다. –

2.     IT뿐만 아니라 임직원 모두의 인식 변화를 목표로 해야한다. 수직적인 명령에 의한 변화가 아니라, 충분한 공감대 형성을 통한 기업 문화 변화를 인내심있게 추진해야 한다.

3.     대부분의 개발이 유지보수 성격의 업무라면, 정말 새로운 방법론의 적용이 필요한지 고민해보아야 한다. 이를 성역없이 논의해볼 필요가 있다.

4.     기업의 IT리더들이 수평적 문화를 확산시키지 않은 상태에서 애자일을 시도하는 것은 근본적인 문제 해결없이 겉치장만 하는 꼴이 될 수 있다.

 

Agile shortcomings [ In Team project ]

기업이 아닌 Team project 에서도 Agile 기법 적용에 문제가 발생할 수 있다. 발생 가능한 문제와 그 보안점에 대해 간략히 살펴보자.

1.     Sprint point 과대평가 : 팀 내에서 소화 가능한 작업의 양을 과대평가 하는 것은 흔히 발생하는 문제이다. 스스로의 처리/생산 능력을 잘 파악하고 log를 적당히 묶어 배정해야 할 것이다. (이전 프로젝트에서 팀이 완료한 포인트 수를 보자)

2.     잦은 팀원 교체 : 적절한 시간동안 팀 구성원을 일정하게 유지하는 것, 적절한 팀 규모를 유지하는 것이 중요하다. 안정적인 팀은 스스로의 생산 능력을 파악할 수 있고, 이는 예측 가능성을 높여 궁극적으로 생산성 향상으로 이어진다.

3.     버그 방치 : 팀은 매일 일과를 끝내는 시점에 정상적인 코드를 얻는 것을 목표로 해야한다. 수정되지 않은 버그는 후에 더 많은 시간을 소요해야 한다.

4.     비상 상황 선언 전 너무 긴 기다림 : Sprint 가 계획을 이탈할 것이 확실시되면 사전에 정해진 비상 절차에 착수해야한다. 일부 작업 분담부터 Sprint 중간에 이르기까지, 강력한 조치를 취해야할 시점을 신속하게 결정해야 한다.

 

Agile / Scrum case study <Success>

Case1. KB금융 – 애자일 스쿼드 팀

: KB 국민은행이 고객의 요구에 빠르게 대응하기 위해 마련한 총 인원 5명의 소규모 조직으로, KB 국민은행의 모바일 뱅킹 어플리케이션 ‘KB 스타뱅킹’ 개선 업무를 맡고 있다. 애자일 스쿼드의 특징은 위계 질서를 없애고 수평적으로 조직이 운영된다는 점이다. 또한 팀에 속한 직원들은 각자의 직책이 있지만, 별명이나 호칭을 사용하며 회의를 위한 서류나 보고서 등을 모두 없앴다. 이러한 방식을 통해 애자일 기법, 넓게는 소프트웨어개발 과정에 있어 각자의 의견 소통이 활발하게 이루어지도록 자연스럽게 분위기를 형성할 수 있었던 것 같다.

 

애자일 기법을 활용한 프로젝트 진행(기존의 방식과 비교)

- ­하나의 프로젝트를 기존의 방식으로 처리할 경우, 보통 6-7개월의 시간이 소요됨. 그러나 그룹 대표와 직접적으로 소통하는 방식으로 의사결정이 빨라졌고, 필요한 업데이트부터 순차적으로 진행할 수 있게 되어 빠른 시간 내에 프로젝트 완성 가능.

- 기존에는 기본 틀에서 고객들의 민원을 정리해 이를 해결하는데 집중했지만, 이들은 고객입장에서 최대한 편하게 앱을 이용할 수 있는 환경 구축을 위해 기본 틀마저 새롭게 고쳐가며 업무를 수행함.

 

애자일을 통해 개발한 서비스: KB스타뱅킹 업데이트(2016년 기준)

- 시작화면의 전체적인 화면 구성을 완전히 바꿨으며, 고객의 계좌를 한눈에 보여주는 ‘계좌뷰’ 기능 등이 추가됨.

Case 2. Principal Financial Group

: 기업고객을 대상으로 보험, 은퇴 설계, 기타 자산 관리 서비스를 제공하는 기업으로 자사의 보험, 퇴직연금, 자산관리 고객들을 위해 좀더 많은 소프트웨어를 신속하게 구축하기 위해 애자일(Agile)을 도입.

 

애자일 도입 후 기업 내부의 긍정적 변화

2013년부터 내부 해커톤을 개최하였고, 이를 통해 광범위한 애자일 도입의 기틀을 다지며 디지털 제품 개발에 집중.

애자일에 대한 급작스러운 접근방식은 문화적 파괴를 유발할 수 있으므로 천천히 시작하는 방식을 택함.

2개월에 한 번씩 회의를 진행하는 것이 아닌, 2주 단위의 스프린트 [1]과정에서 프로젝트를 위해 만나 적절한 이해 당사자들이 의사결정을 내릴 수 있도록 함. 이 결과로, 해당 기업은 개념 증명 및 최소 실행 가능 제품을 구축하는 소프트웨어 신생벤처처럼 운영하게 됨.

데이터를 이용해 프로세스를 지속적으로 개선할 수 있도록 하며, 2주 동안 데이터와 당시 상태를 계속 고려해가며 계획을 변경할 수도 있음.

 

Supporting open source software.

ProjectLibre

마이크로소프트 프로젝트의 오픈소스 데스크톱을 대체가능한 프로젝트 관리 도구이며, 제품 기능에는 마이크로소프트 프로젝트와의 호환성 외에도 간트 차트, 네트워크 다이어그램, WBS/RBS차트, 획득된 값 계산 및 리소스 히스토그램이 포함됨. JAVA가 설치되어 있다면 Linux, Mac OS, Windows OS에서 사용 가능. 무료 소프트웨어로 누구나 사용 가능.

 

Redmine

웹 기반 오픈 소스 프로젝트 관리 도구로, 오픈 소스 ALM 솔루션에서 프로젝트 관리, 요구사항 관리(문서 및 위키 기능 통한 요구사항 작성가능, 해당 요구사항 기반 Epic & Story 생성하여 애자일 프로젝트 관리 가능, 차트와 캘린더를 통한 직관적 프로젝트 관리 수행 가능), 이슈 관리(이슈, 버그와 같은 다양한 타입의 업무 생성가능, 또한 그 현황을 가시화할 수 있는 도구 제공), 변경 관리(변경관리를 위한 변경요청 생성, 해당 소스코드의 추적 및 비교 지원), 테스트 관리(체계적으로 테스트를 관리하며, 실행 결과로부터 결함 관리 가능) 등의 역할 수행하는 핵심 솔루션.

 

Freedcamp

2010년에 출시된 이후 꾸준히 개선되는 애자일 방식의 프로젝트 관리 소프트웨어. 프로젝트와 사용자수, 스토리지에 대한 제한이 없고 모든 사용자가 대시보드를 맞춤화 할 수 있음. 주요 작업, 하위 작업, 토론, 프로젝트 일정(마일스톤), 시간, 파일 및 캘린더 등의 기능을 지원. 프로젝트 관리 소프트웨어를 확장하는 것이 바람직한 기업에 가장 적합함.

 

What is DevOps?

Scrum 기법과 함께 Develop + Operation의 합성어인 DevOps 도 뜨고있다. DevOps는 개발과 운영을 긴밀하게 연결하여 필요한 SW를 고객에게 안정적으로 제공하며, 높은 퀄리티를 유지하며 시스템을 바꾸는데 드는 시간을 줄인다. DevOps의 목적은 개발 사이클을 줄이고 배치하는 빈도를 증가시키는 것이며, 소프트웨어를 구축하고 통합하고 테스트하는 모든 과정의 자동화, 모니터링에 기여하는 것이다. DevOps programming의 자동화 툴을 통해 개발 – 검증 – 운영의 과정을 자동으로 돌아가게 할 수 있다.

DevOps process

Plan > Create > verify(QA) > Package >> release > configure > monitor > plan “공생관계”

DevOps tools

Tool 중 각 단계별 하나씩은 경험해보는 것이 좋다

.이러한 Agile Manifesto , 12 Principles of Agile, Developments , Scrum 과정은 팀 프로젝트를 할 때 한번쯤 경험해보는 것을 추천한다

 

2021. 04. 

김다예