[소프트웨어공학] 3장 에이자일소프트웨어개발 (Agile Software Development)

웹을 기반으로 하는 서버베이스에 많이 사용된다.

변화를 빠르게 받아드린다.

에이자일을 다루는 개발자 입장에서 폭포수 기법의 문제점을 알아봄

 

Plan based 기법을 주로 사용하는 서비스 -> c, c++를 통한 컴파일 언어가 주가 됨, 기계언어는 자체적인 해석이 안 되기 때문에 개발자만이 변경이 가능함

-MS windows & Office

-한컴 한글 워드 프로세서

-패키지 게임

 

현대 에이자일을 다루는 서비스(유행이 민감한 서비스)

-구글, 네이버 검색 서비스(실질적으로 소프트웨어를 팔지 않음 네이버와 같은 경우는 주 비즈니스 모델이 광고임 -> 대부분의 소프트웨어는 무료이고 이를 통한 서비스로 광고를 내보냄)

-Free 게임(스마트폰 게임 -> 무료 다운이 가능하지만 속에서 아이템을 파는 것을 통해 수익을 만들어냄)

-다음 카카오, 라인 메신저

-Ad-based Free Servies

 

에이자일이 등장하게 된 연유를 설명하기 위해 폭포수 기법을 기반으로 설명하면서 비판부분을 삽입하여 에이자일이 필요하게 된 이유를 말해줌.

 

소프트웨어 분야가 어떻게 발전해 왔는가?

2가지 관점이 있음

-과거 소프트웨어 자체가 목적인 경우(소프트웨어 자체를 팔아서 이윤을 남김, 현재 사회에서 도 존재하기 함, 비중이 작아졌을 뿐)

-현대 사회에서 비중이 커진 서비스를 이루내기 위한 도구의 측면에서의 소프트웨어(서비스 중심)

ex. 오픈소스 역시 과거와 같은 관점에서는 수익을 창출할 수 없다. 따라서 현대에 오면서 그 소프트웨어 자체는 도구로만 작용하고 그로인한 서비스를 통해 수익을 만들어 내는 측면으로 변화되어 왔음

 

과거의 소프트웨어들은 굉장히 개발기간이 길다.(1~2년의 긴 기간을 가지고 개발이 됨)

개발기간을 명시해서 그것을 꼭 지켜야 함.

 

이에 비해 현재의 서비스 중심 소프트웨어 서비스 회사들은 개발기간이 상당히 짧다(주단위 월단위) -> 경쟁관계가 심하다.

ex. 최근 마켓컬리와 같은 곳에서 새벽배송이 많이 관심을 갖자 쿠팡 등 여러 동류의 회사들이 이를 모방하여 따라함 -> 누가 먼저 생각해서 그 서비스를 개발해 내느냐가 관건임.

-> 하나의 서비스에 제한적으로 개발이 되는 경우가 많음

서비스 예시로 구글 자체를 말하는 것이 아닌 구글 안에 있는 구글닥스, 구글 맵과 같은 요소들을 서비스라고 칭함

ex. 정부가 마스크 제고현황 정보를 제시하자마자 단시간에 네이버 카카오 등에서 지도에 띄어 주는 서비스를 단시간에 만들어 냄 -> 신속정확이 포인트!

>> 가장 중요한 것은 서비스 회사들이 사용자의 요구에 즉각적으로 반응을 해서 빠른 경과물을 만들어 낸다.

ex. 코로나 확진자의 이동경로를 파악하고 마스크 잔고를 알아보는 정보를 즉각적으로 알아보기 위해 반응을 해야 이러한 서비스가 인기를 끌고 많이 사용됨. -> 시장에 대한 즉각적인 반응이 포인트이다!!

 

정리

과거의 소프트웨어는 누군가 사줄 사람이 명확하게 존재하여 사용자들이 소프트웨어 개발을 기다리는 형태였지만 최근의 서비스라는 것은 시장의 반응을 보고 있다가 그에 맞게 빠르면 하루 만에 서비스를 개발하고 사용할 수 있게 해준다. -> 서비스에 대한 아이디어가 주된 수익 요소이다!(소프트웨어는 도구임)

 

폭포수 기법 – 개발과정을 체계적으로 하기 위한 방법론임

폭포수 기법 예제

>>제안서(요구사항)를 제출 -> 승인을 받음 -> 소프트웨어의 세부적인 요구사항을 기능적으로 작성 -> 이러한 요구사항을 설계함 -> 설계부서와 개발부서가 분리되어 있다면 서로 합의하는 단계를 거친다.(이 경우에는 설계자 또는 마케팅을 하는 사람들의 의견이 중시됨) -> 따라서 UI/UX의 요구를 개발자들이 제대로 이해를 했는가를 반영을 하여 보여지는 것이 맞는지 제대로 작동을 하는 알고리즘이 제대로 적용된 것인지를 확인함 -> 디자인을 경험을 기반으로 심도 있게 보고 개선하는 작업을 함 -> 개선된 디자인을 서로 합의함 -> 실제로 개발을 해봄 -> 시험을 진행해서 문제를 확인함 -> 최종적으로 결과물이 요구사항을 만족하였는지 확인하고 이 모두가 만족된다면 출시를 결정함

>> 큰 단점 – 굉장히 오랜 기간 위에서 아래로 흐르는 구조인데 설계가 잘못 된다면 개발이 잘못 될 수 있다. -> 따라서 앞쪽에 이러한 문제를 미리 잡아줌

 

폭포수 모델의 장점

-앞에서 미리 요구사항, 설계 등에 대한 심도있는 과정이 진행되기 때문에 문제 발생을 최소화 함

-많은 사람들이 투입됨 -> 단계별로 진행하는 사람들이 다르다는 가정 하에 진행을 원활하게 하기 위해 상당량의 문서들이 제작이 됨.

>> 따라서 뒤에 단계에 진입했을 때 상당량의 고민이 끝나있을 수 있다.

-새로운 사람이 투입되었을 때 문서를 통한 명확한 파악이 가능함.

-해야 할 일과 개발되어야 할 것이 명확하게 문서화 되어 있기 때문에 개인의 생각을 가지고 진행하다 발생하는 경험부족 등의 문제를 방지할 수 있음

-단계별로 해야 할 일이 명확하기 때문에 제한 날짜와 결과를 정확하게 측정할 수 있음

-일관적이고 절차적으로 개발이 가능함

 

폭포수 모델의 단점(비판)

-소프트웨어라는 것이 제한된 시간 속에서 정확하기 만들어 질 수 있는 것인가?

-문서화를 많이 함에 따라 최종 목표인 소프트웨어 개발에 있어 본질을 모호하게 만듦.

-급변하는 현시대에서 굉장히 긴 개발기간을 가지고 개발을 하는 폭포수 모델은 그 때 그 때 급변하는 변화들을 모두 수용하기에 어려움이 있음 (단계별 절차적으로 진행되는 개발 방법이 현실적인 이야기인가?)

-현시대에 동류 서비스업체가 많은 상황 속에서 복잡하고 긴 절차를 가지고 살아남기란 매우 어려움이 있음

-이상적인 방법이긴 하나 각 단계들이 시간에 맞게 진행될 수 있는지는 미지수이기 때문에 문제가 될 수 있음

-또한 현시대에 급변하는 사용자들의 니즈를 수요하는데 있어 신속함이 결여될 수 있음

>>경쟁이 심한 사회로의 이전과 급변하는 사용자의 니즈 수용에 취약하다

-많은 개선이 이루어졌지만 과거 소프트웨어 자체가 목적이었던 것에 맞춰져 있었기 때문에 현시대 소프트웨어가 도구로 변한 시대 속에서 많은 문제점들이 수반 될 수밖에 없다.

 

2001년 2월 위 문제에 대한 것들에 대한 많은 논의가 있었음.(17명의 논의)

-> 에이자일 기법의 등장!!!

>>소프트웨어를 어떻게 하면 잘 짤 수 있는가?

에이자일 소프트웨어 개발 선언(4가지)

-개인과 상호작용

-작동하는 소프트웨어

-고객과의 협력

-변화에 대응하기

>>과거에 있던 것들에 대한 고찰을 기반으로 만들어짐

>개발자가 나서서 제안을 할 수 도 있음 (유기적인 사람들 간의 관계를 중시함)

>>특징적인 것은 시간이 지날수록 변하는 개념이 아닌 시간이 지남에 따른 변화역시 복잡성을 야기한다는 의견에 의해 위에 선언은 변화지도 추가되지도 않고 유지되고 있음

>>소프트웨어 개발에서 변화는 복잡성을 야기하기 때문에(개개인의 마인드와 개발자들의 능력이 더 중요한 것을 바뀜)

 

앞쪽에서 말한 4가지 방법

-개발자들이 스스로 영감을 얻고 스스로 배워서 적극적으로 자신의 의사를 어필할 수 있는 방향을 추구함 -> 공동의 목표를 위해 헌신하는 자세가 필요하다.

더불어 이들이 서로 상호작용 하는 것이 매우 중요하다!

스스로 자가 발전을 하는 자세가 필요함

-그때 그때 결과를 물어보면 문서적인 것이 아닌 결과적인 소프트웨어 개발을 보여줘야 함

-본인이 만드는 소프트웨어에 대한 애정과 가치를 지속적으로 생각해줘야 함(허심탄회하게 고객님과 대화를 나눠야 함)

-개발자 스스로가 본인이 공부한 것을 기반으로 제안을 할 수 있어야한다.(변화에 대응하는 사람이 되어야함)

소프트웨어 교육의 트렌드는 방향성만을 교육하는 것이다.(세세한 것들은 스스로 학습하는 방향을 추구한다)

-> 하고 싶은 것을 가지고 스스로 학습을 지속적으로 하라!!

 

4가지에 더불어 12가지를 만듦(좀 더 체감할 수 있게 확장한 것)

-고객(이해하고 다가가야 한다)을 만족시켜야한다(실제로 회사에서도 고객이 아닌 부장을 만족시킨다...)

-변화는 필수 불가결하니 그러한 고객들의 변화하는 요구사항을 긍정적으로 받아들이고 수용해보아야 한다.

-소프트웨어를 주기적으로 내보내야 한다.(주기적으로 단시간으로 변화된 소프트웨어를 내보내기)

-대회를 함에 서슴지 않기(비즈니스를 하는 사람들과 개발자 간에 원활한 대화를 진행하여 서로 원하는 것을 이해해간다.)

-프로젝트를 수행할 때에는 스스로 영감을 얻고 스스로 학습하는 사람들을 모아두어라, 환경을 제공하고 믿기(좋은 팀을 만들기 위해 어떻게 해야 하는지를 물어본다.)

-직접 만나서 있지 않고 멀리 떨어진 사람들과도 원격(음성과 화상을 공유함!!)으로 진행한다.

>>위의 3개는 팀플의 최고 덕목

-동작하는 소프트웨어가 항상 중간 결과물이 되어야한다.

-유기적으로 사용자들이 연결이 되어 있어야한다.

-본인이 끝임 없이 자기개발을 해야만 한다.(스스로 자가 학습, 끊임없이 관심분야를 공부해라)

-단순함을 추구한다.(필수적인 요소들만 포함한다)

-팀 작업을 할 때 스스로 필요로 하는 사람들을 위주로 만들어간다.

-주기적으로 작업, 결과물, 과정들을 서로 논의해서 문제점들을 지속적으로 개선해간다.

 

에이자일 방법론 중하나 Scrum

>에이자일을 실천하기 위한 방법론

>3-9명 정도의 사람이 소규모의 팀이 하기를 권장함

>미팅을 간단하게 서서 15분정도의 미팅을 매일 진행한다.

>2-4주 단위로 만들어진 소프트웨어를 릴리즈 함.

>>권한이유 -> 우리가 만드는 팀이 이정도 이고 가정 접하기 편한 방법론이다.

 

전반적인 과정

만들려고 하는 소프트웨어의 전반적인 기능을 나열한다. -> 필요로 하는 기능들을 쪼게어 우선순위를 부여한다.(우리가 가장먼저 담아야하는 기능을 먼저 스프린트 한다.) -> 그러게 정해진 스프린트를 1-4주 단위로 스프린트를 뛴다(버전이 하나씩 생성됨, 스크럼 마스터 지위 하에 진행) -> 데일리 스크럼(매일 매일 가장 주요한 요소들을 확인하고 진행상황을 파악함, 15분 정도) - 모든 작업이 마무리 되면 팀 스스로가 자체 평가도 해보고 피드백 한다.

>>결국은 스크럼은 고도화된다. -> 좀 더 체계적으로 발전해 나감

 

소프트웨어 개발 (스크럼 + DevOps)

>>최초 미팅을 가짐 고객과 프로덕트 오너 ->프로덕트 오너와 프로그래머, 시스템 관리자가 만나 백로그를 작성한다. -> 스프린트의 주기, 맴버는 어떻게 구성할지 등을 계획함 -> 스프린트를 진행하며 개발을 함 -> 중간 중간 스프린트의 결과로 중간 소프트웨어가 나옴 -> 이렇게 만들어진 것들을 피드백하는 과정까지 거친다. -> 스프린트에 대한 피드백을 진행한다. -> 그러한 피드백을 반영 함 -> 다시 변경된 요구사항이 있다면 수용해서 스프린트를 계획하고 앞 과정을 반복함

>>DevOps가 추가되어 개발과 작동을 시험함(스프린트별 중간 소프트웨어에서 진행 됨)

개발자와 운영자가 유기적으로 상호작용을 해야 함.

포스트잇 별로 붙여져 있음 (스크럼)

 

DevOps(development(개발) + operations(운영, 안정적으로))

>더 좋은 서비스를 제공하는 것이 우선순위가 안정성보다 중요성이 높음

>개발 철학, 문화

>이걸 어떻게 할거냐? 앞에서부터 depoly(운영)까지의 전체과정이 자동화 됨(도구들이 많이 등장함)

>경쟁x -> “우리 회사가 사용하는 좋은 소프트웨어를 잘 만들자!”

>DevOps = 개발 + 질문(검증) +　작동(배포운영)

 

DevOps과정

개발 -> 계획을 세움 -> 소프트웨어를 만듦 -> 검증과정을 거침 -> 패키지가 됨 -> 운영을 통해서 릴리즈가 됨(소프트웨어 1개) -> 컴퓨터 위에 올라가서 환경을 설정함 -> 고객님들이 사용하는 것을 모니터함 -> 개선사항, 문제점이 나타나면 다시 계획을 세우고 위의 과정을 반복함

>>서로 물고 물리는 과정이 반복됨.

 

 

3장 요약

Agile Manifesto(선언문)

12 Principles of Agile Developments

Scrum

DevOps