소프트웨어 생명 주기 [소프트웨어 설계] // 스크럼 (Scrum) 이해하기

 

소프트웨어 생명 주기 [소프트웨어 설계] // 스크럼 (Scrum) 이해하기

 

 

 

 

소프트웨어 생명 주기란? ::

소프트웨어를 체계적으로 개발하고 관리하기 위해서 개발을 위한 정의, 운용, 유지보수 등의 과정을 단계별로 나눈 것

소프트웨어 생명 주기는 소프트웨어를 요리하는 다양한 요리법이라고 볼 수 있다.

여기서 요리법을 모형, 모델이라고 볼 수 있다.

 

 

 

 

대표적인 생명 주기 모형 ::

1. 폭포수 모델 (Waterfall Model)

각 단계가 마무리 되어야 다음 단계로 넘어가는 방식 위에서 아래로 떨어지기만 하는 폭포수처럼 이전으로 되돌릴 수 없다. 가장 고전적인 방법이다.

 

- 되돌릴 수 없기 때문에 초반에 계획된 대로 진행 해야 되어야 하며 각 단계를 마치면 확실한 결과물이 나와야한다.

- 하나를 확실히 마무리해야 다음으로 넘어갈 수 있기 때문에 2개 이상의 과정을 병행할 수 없다.

- 매뉴얼 작성이 필요하다. (만약에 문제가 생길 경우 돌아갈 수 없기 때문에 다시 개발하거나 문제점들을 잘 적어놔야 한다.)

 

 

 

 

 

2. 프로토타입 모형(Prototype Model)

폭포수 모델은 개발 완료 후에 오류를 발견하면 수정이 불가능하다는 문제점이 있다. (폭포수 모형의 단점 보완)

이 부분을 해결하기 위해서 시제품(prototype)을 미리 만들어보고 완성될 결과물을 예측한 뒤에 개선해서 다시 만드는 모델이다. 원형 모델이라고도 한다.

인터페이스 중심으로 개발 (빠르게 처리하기 위해 디자인이나 마감 등을 무시하고 최대한 기능적인 부분만 구현한다.)

 

 

 

 

 

3. 나선형 모형 (Spiral Model)

그렇다면 한 번의 프로토타입으로는 보완이 불가능할 정도의 많은 기능이 있는 대규모 소프트웨어의 경우는?

이런 점을 보완하는 것이 나선형 모델이다.

- 나선을 따라 돌듯이 계획 - 분석-개발-평가를 반복하여 소프트웨어의 완성도를 점진적으로 향상시킨다. 

- 추가되거나 누락된 요구사항을 첨가하여 진행 가능하며, 점진적 개발을 통해 정밀하며, 유지보수가 불필요할 정도로 개발하는 것이 목표이다.

- 대규모 소프트웨어 개발에 용이하다.

 

 

 

 

 

 

4. 애자일 모형(Agile Model)

 

지금까지 살펴본 폭포수, 프로토타입, 나선형처럼 발전해온 이유는 고객의 요구 사항을 만족시키기 위해서이다.

하지만 기본적으로 계획과 문서 중심으로 진행되기 때문에 고객과의 요구사항 변경에 지속적으로 대응하기가 어렵다 이런 부분을 보완해서 나온 모델들을 통칭해서 애자일 모형이라고 한다. (민첩한, 기민한)

 

- 고객과의 상호 작용에 초점을 맞춤 방법을 통칭하는 것이다.

- 고객의 요구와 변화에 빠르게 반응할 수 있다.

- 고객 우선

 

애자일 기반 소프트웨어 개발 모형 ::

스크럼(Scrum), XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM, DAD등이 있다.

 

 

 

 

스크럼 기법 (Scrum) ::

애자일 소프트웨어 개발 방법론 중에 하나로 이름처럼 팀을 중심으로 이루어진다.

제품 책임자, 스크럼 마스터, 개발팀  3가지 역할이 있고 이것을 합쳐서 스크럼 팀이라고 부른다.

 

제품 책임자(PO) : 의사 결정권자로 제품 요구사항을 백로그에 반영 각 스프린트마다 우선순위 관리, 조정

스크럼 마스트(SM) : 일일회의를 주관하고 개발팀을 코칭하고 지원하는 역할을 한다.

개발팀(DT) : 고객으로 부터 받은 요구사항을 가지고 제품을 개발하고 테스트하는 디자이너 및 테스터 등등

 

 

스크럼 기법의 프로세스 ::

소통을 통해서 개발에 필요한 사항들을 백로그(Backlog)에 기록한다.

이때 기록된 내용들은 개발자와 고객들이 모두 형식 없이 편안하게 이야기 형식으로 적기 때문에 스토리라고 부른다.

 

사용자 스토리 : 사용자나 개발자가 모두 이해할 수 있도록 사용자가 작성

카드, 대화, 테스트라는 3가지 측면을 이용하여 작성한다.

- 카드(Card) : 고객의 요구사항을 표현하기 위한 것으로 대화의 매개체 역할을 한다. who, why, what 정보가 모두 포함되어야 한다.

- 대화(Conversation) : 카드 내용의 세부사항을 구체화함

- 테스트(Test) : 대화를 통해 나온 기준을 통해 스토리 완료 여부 판단한다.

 

 

백로그 우선순위는 제품 책임자에 의해서 정해지게 되며 

백로그는 이해 관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항을 우선순위에 따라 모아놓은 목록을 말한다.

백로그가 준비되면 스크럼 마스터는 계획 회의를 진행한다.

회의를 통해 각 개발자별로 스프린트 백로그를 작성한다

스프린트 백로그는 각각의 스프린트에 대한 개별 백로그를 말하며

스프린트는 계획회의를 통해서 세부 개발 목표와 할당받은 작업시간 등을 말한다.

 

팀원들은 스크럼 마스터와 매일 회의를 해서 개발에 방해가 되는 요소들을 스크럼 마스터에게 알리고 스크럼 마스터는 이런 에러 사항들을 해결하기 위해 노력한다. (스크럼 마스터가 주도하는 일일 회의) 

그리고 소멸 차트를 통해서 예상기간 대비 실제 작업 진행량을 비교해서 문제점을 파악한다.

 

제품 책임자(PO)는 매주 검토회의를 통해서 필요한 내용을 백로그에 업데이트한다.

회고를 통해서 지난 일정을 되돌아보며 개선점을 찾는다.