3. Agile Development

즈아 지금까지 Process Model에 대해서 알아보았쥬? 근데 Agile한 방식의 개발 방법이 나오게 된 이유가 있을거라고 생각합니다.

그래서! 이번 파트는 좀 간단하게 애자일 개발방법의 등장 배경, 특성에 대해서 자세히 알아보고, 애자일 개발론을 아주 잘 보여주는 XP 에 대해서 알아보겠습니당.

 

I. Agile Development의 배경과 특성

Agile 개발론을 간략히 배우면서 그 전에 Plan - driven 모델에 대해서 알아보았습니다. 이 plan - driven 의 장점중 하나로 매 단계가 끝날 때 마다 Documentation 즉 문서화를 통해 문서가 나온다는 것이었습니다.

이러한 plan - driven 모델을 사용하더라도 개발 중간중간 요구사항의 변화를 적용하기 위해 "다시" 처음부터 Specification 하고 매 단계 끝날 때마다 문서 쓰고 이게 너무 개발과정에서 부담이 되었던거죠. 

 

지금까지의 이야기를 통해 정리해보자면 : 

 

• 등장 배경 : 요구사항 분석 -> 설계 / 구현 사이의 documentation 작성의 overhead(부담)이 너무 크다 
• 목표 : 그래서 documentation 작성을 줄이고, 요구사항 변화에 민첩하게 반응해서 빠르게 배포해보자.

 

이러한 agile development는 크게 3가지의 특성을 가집니다 : 

 

• Incremental Development 
  • Increment 단위로 쪼개어 개발이 이루어지므로 빈번하게 배포가 이루어지며 여러 단계가 반복된다
• 24/7 Customer Involvement
  • XP에서 후술하겠지만, 개발 팀 내부에 고객이 full - time 으로 관여한다
• 문서 작성의 최소화

앞에서 알아보았듯 이러한 agile development는 다음과 같을 때 가장 잘 적용할 수 있습니다 : 

 

• 중소규모 이거나 상호작용이 많은 경우
• 고객이 24/7 관여 할 수 있고, 팀원끼리 서로 근접(co-located)한 경우
• Customized Software Development일때 적절하다 

 

 

II. XP - Extreme Programming

 

이 XP기법은 애자일 개발론을 극한까지 활용하는 기법입니다.

이 기법을 정의하자면 :

• Increment 의 크기를 Extreme하게 즉 극단적으로 작게 쪼개어 기능들의 개발을 매우 빈번하게(하루에 많으면 여러번 개발됨) 하고, 배포는 격주로 하는 개발론

이 XP 개발론은 크게 4가지의 특징을 가집니다.

 

1. 유저의 요구사항이 스토리나 시나리오 형식으로 전달된다.

 

일반적으로 유저들이 요구사항을 제공하는 경우 이를 개발자들의 언어, 즉 테크니컬하게 제공해 주지 않습니다.

게임의 예시를 들어봐도 "무슨무슨 스킬 너프좀요", "사일러스하고 니코 버그 픽스좀요" "이즈q가 무한이에요" 라이엇 너네가 사람이냐" "스킨좀 그만내고 롤 클라이언트 버그좀 픽스해라 걍 하꼬 게임사임 ㄹㅇ"

와 같은 요구사항 또는 

"스크린 UI가 눈에 안들어오는데요?", "아니 다음 눌렀는데 왜 안넘어가요" 와 같이 주로 시나리오나 스토리 형태로 요구사항이 전달되게 됩니다. 따라서 다음과 같은 단계를 거쳐서 고객의 요구사항이 구현되게 됩니다.

 

1. 먼저 팀 내의 유저(고객)가 스토리나 시나리오 형태로 들어오는 요구사항 중 하나를 선택합니다.
2. 선택된 요구사항은 개발팀에서 task 단위로 쪼개져서 개발을 진행합니다.
3. 그 다음에 선택된 요구사항 또한 유저(고객)이 개발 스케쥴에 맞춰서 선택합니다.

 

2. 리팩토링 

 

먼저 리팩토링의 정의에 대해서 알아봅시다 : 

• 리팩토링이란, 코드의 interface는 수정하지 않으면서 클래스의 계층구조를 바꾸어 재사용성을 높이거나, 변수나 클래스명을 알아보기 쉽게 바꾸는 것과 같이 이미 존재하는 코드 블럭을  수정하는 것입니다.

이러한 리팩토링은 즉각적인 필요가 없을 때에도, 즉 상시로 함으로써 팀내 인원들의 코드에 대한 이해도를 높일 수 있습니다. 이를 통해 documentation 을 줄일 수 있게 되죠.

 

 

3. Test First Development

 

단어만 봐도 알 수 있듯이 코드 먼저 쓰지말고 항상 테스트를 먼저 계획하고 개발한 후에 코드를 작성하라는 것입니다.

테스트를 먼저 계획함으로써 내가 개발하려는 코드의 이해도를 높일 수 있고

(acceptance test를 계획함으로써 요구사항에 대해서 명확히 알 수 있다거나, component test를 계획함으로써 내가 지금 당장 개발하려는 코드블럭에 대한 이해도를 높일 수 있음)

또한 테스트를 자동화 함으로써 코드에 대한 신뢰도를 높일 수 있습니다. 

 

 

4. Pair - Programming

 

이 기법은 두명 이상의 개발자가 하나의 컴퓨터 앞에 앉아 개발하는 방법입니다. 

"아니 그럼 키보드 하나 두고 두명이서 개발하나요?ㅋㅋㅋㅋㅋ" 이 아니구요, 한명은 개발을 하고(코드 작성하기) 한명 이상의 개발자는 뒤에서 작성되는 코드를 보면서 리뷰하는 것입니다. 

이러한 과정을 통해 비공식적인 코드리뷰를 매 코드작성마다 할 수 있게 되고 하나의 코드를 여러명의 개발자가 보게 됨으로써 결국 전체 코드에 대한 팀의 이해도가 높아지게 됩니다. 이는 결국 documentation 을 줄일수 있게 되는 결과로 이어지게 됩니다.

 

 

III. Agile Development의 단점 

그렇다면 애자일 개발론은 문서화도 줄이고, 이해도도 높이고, 요구사항 변화도 민첩하게 하고 현실적인 문제는 없는 걸까요?

애자일 개발의 단점을 알아보기 전 장점은 바로 문서 작성을 줄일 수 있다는 것이었고 이를 보완하기 위해, 

리팩토링, Test first Development, Pair - Programming 을 통해 코드에 대한 팀의 이해도를 높이는 기법들을 사용했습니다.

 

하지만, 만약 초기 개발진이 대규모로 나가게 되거나, 동시에 여러명의 개발자가 나가게 된다면 어떻게 될까요?
사람에 의존해서 documentation을 줄였던 애자일 개발론이 이때 문제가 됩니다.

 

즉 다음과 같은 현실적인 문제가 발생하게 되는거죠 : 

 

• 소프트웨어의 문서가 부족하여 요구사항의 변화와 같은 것이 기록되지 못한다.
• 장기적 관점에서 볼때 기존 개발팀의 계속 유지될 수 없고, 기존 개발팀이 동시에 이탈하는 경우 치명적일 수 있다.

 

 

IV. Agile Development VS Plan-driven Development

 

그럼 언제 애자일 개발을 하고 언제 plan-driven 개발을 할까요? 다음 질문들에 답을 함으로써 판단해 볼 수 있습니다.

(PD : Plan-Driven, Development, AD : Agile Development)

 

• 초기 명세가 매우 상세해야 하는가?
  
  • YES : PD  / NO : PD , AD
• 개발의 규모가 큰가?
  • YES : PD / NO : PD , AD
• 개발의 단위를 increment단위로 나누고, 유저들의 요구사항 반영을 빠르게 하는 방식이 현실적으로 가능한가?
  • YES : PD, AD / NO : PD
• 팀내 인원들이 서로 근거리에 있는가(co - located) ?
  • YES : PD, AD / NO : PD

 

 

끝!!!!!!!