소프트웨어 공학 (5), Agile software development

소프트웨어 공학 (5), Agile software development

2022. 4. 14. 17:39ㆍ강의 내용 정리/소프트웨어 공학

728x90

Agile software development

웹 기반, 비즈니스에서 많이 사용하는 개발 기법

1. 소프트웨어 비즈니스의 발전

Past: Software 중심

한글, 어도비 포토샵, 마이크로 소프트 윈도우 OS, Office, CD/DVD 등 과거에는 소프트웨어 자체가 비즈니스로 활용되는 경우가 많았다. 한마디로 소프트웨어를 직접 판매하여 수익을 창출하는 경우가 대부분이었다. 따라서 패키지형태로 소프트웨어를 제공하는 경우에는 소프트웨어를 개발과 관련된 사람이 많이 필요하고 문서를 만들 필요가 있었다.

Windows 9x, Office 2xxxx와 같이 소프트웨어 개발 주기는 연단위일 정도로 개발 기간이 매우 길었고, 많은 사람들이 투입되기에 비용도 많이 소모됐다. 이 당시에는 목표로 가지고 있는 데드라인을 명확하게 지켜야하기에 정해진 날짜에 맞춰 결과물을 도출하는 것이 중요했다. 최근에 소프트웨어를 판매할 때는 구독형 서비스로 제공하는 경우가 많다.

Today: Service 중심

최근에는 서비스를 제공하기 위한 도구로서 소프트웨어가 사용되는 경우가 더 많다. 한마디로 소프트웨어를 돈을 받고 파는 것이 아닌 이를 도구로서 활용해 이루고자한 비즈니스나 서비스 등을 이뤄내는 것이 목표이다. 즉, 소프트웨어는 비즈니스를 위한 수단으로서 사용한다. 예를 들어 구글이나 네이버의 검색 서비스는 돈을 받고 제공하는 것이아니라 광고라는 주요 수익원을 얻기 위한 수단이 된다. 무료 게임 또한 아이템을 판매하기 위한 수단이되고, 카카오나 라인과 같은 메세지도 플랫폼 비즈니스를 위한 활용 수단이 된다.

최근 오픈소스 및 웹 기반 환경이 많이 발전하면서 자바스크립트, html, css 등이 많이 발전했다. 개발 관점에서는 굉장히 긴밀하고 빠르게 개발하고 있다. 날마다, 주단위로 혹은 월단위로 출시가 될 정도로 빠르게 개발을 진행한다. 이는 비즈니스 환경의 경쟁관계가 심하기 때문에 발생하는 현상이다. 기업은 사용자들의 요구사항이나 반응에 즉각 움직여야한다. 과거와는 달리 한정된 사람과 돈을 들여가면서 개발을 하기에 서비스의 단위별로 그리 많은 인원과 돈이 투입되지 않는다. 이러한 환경 속에서 Agile이 각광받기 시작했다.

2. Class

Past: Waterfall

세부적으로 봤을 때는 조금 더 다양한 단계로 나눌 수 있지만 Waterfall의 특징을 가지고 있는 것을 확인할 수 있다. 따라서 앞쪽에서 문제가 발생하면 뒤에 단계에 치명적인 문제가 발생할 수 있기에 차근차근 문제가 없도록 해야한다.

1) 장점

- 소프트웨어를 개발하는 단계 이전에 요구사항 분석 및 설계하는데에 많은 투입이 되는데 개발자가 아닌 사람들도 많이 투입되기에 상당량의 문서를 만들어내기에 뒤에 단계에 진입했을 때에 상당량의 고민을 끝낼 수 있음

- 새로운 멤버가 들어왔을 때 쉽게 프로젝트에 대해 이해하며 진행할 수 있음

- 단계마다 해야할 일과 산출물이 정해져있기에 의사소통에 따른 문제 발생이 적을 수 있음

- 날짜와 결과물에 대한 규정이 가능

- 체계적인 개발을 할 수 있음

2) 비판

- 소프트웨어를 개발해야하는데 이를 뒷전으로 하고 문서화의 과정에 얽매임

- 요구사항 분석이 100% 신뢰성있게 잘되었는지, 현재 출시 전의 요구사항의 분석이 유효한가? 비즈니스 환경이 변화했는데도 아직 유효한가? 등에 대한 문제점이 발생할 수 있음

- 무한경쟁 시장 속에서 이를 고려할 때 앞단계에서 뒷단계에 대한 고민을 끝내는 것은 불가능하다고 판단될 수 있음

- 시장의 반응을 보며 시장 니즈에 맞는 소프트웨어를 출시해야하는 경우에는 적용하기 어려움

- 사용자의 니즈나 요구사항이 변하는 경우 소프트웨어는 바뀔수밖에 없지만 waterfall를 적용하기 어려움

최근에는 소프트웨어 자체보단 서비스로서의 역할이 더 중요해지는 관점으로 바뀌면서 Waterfall 방식의 장점보단 비판점이 더욱 부각되고 있는 상황이다.

Today: Agile

1) Agile Manifesto

waterfall 개발 방식의 문제점을 고찰하여 더 나은 개발을 위해 선언한 소프트웨어 개발을 위한 대헌장

- 의미있는 소프트웨어를 만드는 것을 강조함

- 네줄 이상의 규칙을 정하면 더 복잡해지기에 간단하게 이를 표현하고자함

- 소프트웨어 개발 뿐 아니라 Agile은 다른 분야에서도 많이 퍼지기 시작함

(1) 개인과 상호작용(Individuals and interactions)

- waterfall의 경우 공정과 도구가 집중되었음

- 개인의 역량과 마인드가 중요해지기에 개개인의 개발자가 self-motivated, self-learning 해야하는 것을 강조함

(2) 작동하는 소프트웨어(Working software)

- waterfall의 경우 문서가 너무 많았음

- 언제든 소프트웨어를 통해 진척사항등에 대해 보여줘야함

(3) 고객과의 협력(customer collaborative)

- waterfall의 경우 계약과 협상에 너무 초점을 맞춤

- 고객이 요구하는 것을 충분히 고민하여 최대한 니즈에 맞게 개발하기 위해 고객과의 대화를 나눠야함

- 소프트웨어관련 지식이 없는 사람과 의사소통을 할 수 있을 정도로 의사소통 방법이 더 중요해짐

(4) 변화에 대응(responding to change)

- waterfall의 경우 계획을 따르는 것이 매우 중요했음

- 개발자가 스스로 러닝한 것을 기준으로 제안도 할 수 있고 변화에 대응할 수 있어야함

2) 12 Principles of Agile development

Agile Manifesto의 구체적인 실천 및 강론에 대한 내용

Agile 기법에 대한 구체적인 예시가 있기에 레퍼런스로 활용 가능하고 1, 2, 3 원칙이 제일 우선시 된다.

(1) 고객을 만족시켜야한다.

- 상사를 만족시키는 것이 아닌 소프트웨어를 사용할 실질적인 고객을 맞춰주는 것이 중요함

(2) 요구사항의 변화를 환영해야함

- waterfall에서는 요구사항의 변화를 반영하기 어려움

- 요구사항이 변할 때 이를 긍정적으로 받아들이고 대응해 소프트웨어의 변화를 받아들이는 자세가 중요함

(3) 소프트웨어를 주기적으로 내보내는 것(Deliver)

- 개발 중간의 결과물은 소프트웨어이어야함

- 심한 경우에는 아침, 저녁마다 소프트웨어를 찍어내는 경우가 매우 많음

(4) 대화하는 것을 서슴치말아라

- 비즈니스가 목표라면 비즈니스하는 사람과 개발자는 생각을 수시로 주고받아서 같은 상황에 대해 의견을 나눠야함

- 수많은 대화를 통해 이해하는 것이 중요함

(5) 동기부여되고 신뢰가 있는 사람들을 모아서 프로젝트를 수행하고 믿어라

- 회사에서 사람을 뽑을 때는 motivated 되어있는 사람을 뽑음

- 좋은 팀을 만들기 위해 어떻게 해야하는지를 묻기도 함

(6) 면대면으로 만나 팀플을 하는 것이 매우 효과적이고 효율적인 의사전달 방법이다.

- 눈을 보며 의견을 나누는 것이 매우 중요함

(7) 작동하는 소프트웨어가 진척정도에 대한 주요한 지표가 된다.

- 개발자는 개발 결과물을 가지고 보여주는 집단임

- 본인이 할 수 있는 최선의 결과물을 보이는 것이 중요함

(8) sustainable한 개발 과정을 장려한다.

- 사용자들이 유기적으로 연결되어있을 필요가 있음

(9) 자가발전을 끊임없이 해야함

- 스스로 공부해가며 소프트웨어를 개발해야함

(10) simplicity가 핵심적이다.

- 중요한 것을 중심으로 단순화하는 것이 중요함

(11) 아키텍쳐, 요구사항, 디자인을 잘 하기 위해서는 self-organizing team을 꾸리는 것이 매우 중요하다.

(12) 주기적으로 하고 있는 작업에 대해 논의해서 개선하는 과정이 필요하다.

3. Scrum

Agile FrameWork 중 하나로 스프린트를 통해 빠르게 소프트웨어를 출시하는 방법론

1) Scrum 프로세스

- 스스로의 경험을 공유하고 체계화된 형태로 제시하기 시작하면서 등장한 방법론 중 하나

- 세명에서 아홉명 정도의 소규모 팀을 꾸려서 2-4주에 소프트웨어를 출시하는 것(sprints)을 권장하고, 서서 15분 정도 매일매일 미팅을 하며 진행하는 것에 대해 논의와 토론을 함

- 대학생의 입장에서 하기 좋은 agile 방법론임

Product owner

- 소프트웨어 제품이 갖춰야할 것을 명시하는 사람으로 팀장 혹은 고객이 될 수 있음

- 소프트웨어의 전반적인 요구사항이나 기능을 정함

Sprint planning

- 소프트웨어의 기능을 우선 순위를 중심으로 쪼개어 제일 중요한 것을 첫번째 sprint로 놔둠

- 한번의 sprint마다 2-4주에 걸쳐 기능을 구현함

cf) waterfall을 쪼개는 경우 spiral이 있었음

- daily scrum을 통해 진행 사항에 대한 내용을 모임을 통해 의견을 나누고 sprint 이후에는 리뷰를 진행하여 sprint 사이클을 끝낸다.

2) Scrum 구성요소

3) Scrum 간단한 규칙

- 현실에 맞춰가며 scrum은 점점 고도화됨

4) 8 steps to Scrum과 DevOps

- 각 그림별로 스텝이 나타나고 있음

- DevOps때문에 5번 단계에서 길어졌는데, 개발 과정이 운영까지 포함되어 액티브하게 바뀐 것을 확인할 수 있음

5) Agile 도구

- scrum은 포스트잇을 많이 사용하기에 여러 도구를 많이 사용함

- 오픈 프로젝트

4. DevOps(development and operations)

개발과 운영을 함께 진행하는 개발 철학과 문화

1) 데브옵스란?

- 전통적인 방식은 개발과 운영의 목적이 다르기에 개발팀이 만든 것을 운영팀이 운영을 하는 식으로 이루어졌다.

- 개발은 좋은 기술로 원하는 소프트웨어를 개발하는 것이 목적

- 고객이 만족할 수 있게 안정적으로 제공하는 것이 운영팀의 목적

- 데브옵스는 개발팀은 우리 회사에 목표에 부합하는 소프트웨어를 만드는데 안정적인 것 이상으로 고객 니즈를 더욱 충족시킬 수 있도록 피드백을 주고받을 수 있는 개발체계에 맞춰 운영도 바뀌어야하는 것을 강조함

- 개발/운영 팀들의 사이클은 톱니바퀴처럼 굴러가야한다는 것을 강조함

- 체계화하여 개발 이후에 테스트, 검증, 통합, 전달되는 과정을 자동화하는 것이 중요하다.

* QA: 소프트웨어가 가져야할 기능을 검증하는 단계

2) 데브옵스 프로세스

3) 데브옵스 개발을 위한 툴

- 데브옵스와 관련된 툴이 실제로 많이 존재한다.

- 데브옵스 개발자에 대한 연봉이 높게 책정이 되어있기에 개발과 운영의 조화에 대한 고려가 비즈니스 환경에서 필요하다는 것을 알 수 있다.