XP(eXtreme Programming)

비즈니스 상의 요구 변동이 심한 경우 적합한 개발 방법이다

애자일 개발 프로세스의 대표적인 하나로 꼽힌다

짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것이 목적이다

비교적 작은 규모의 인원의 개발 프로젝트에 적용하기 좋으며 개발 문서보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기에 중점을 두는 경향이 있다

릴리즈의 기간을 짧게 반복아혀 고객의 요구사항 반영에 대한 가시성을 높인다

 

XP의 가치

의사소통, 단순성, 피드백, 용기, 존중

 

XP의 원칙

인간성, 경제성, 상호이익, 자기 유사성, 개선, 다양성, 반성, 흐름, 잉여, 실패, 품질

 

XP의 실천방법

Whole Team 모든 프로젝트에 참여하는 팀원들을 가리켜 개개인의 역할이 있고, 역할의 중요성을 이야기한다
Planning Game XP에서 계획을 세우는데에는 이번 반복(iteration) 어떤 개발과정을 끝낼것인가, 개발 반복무엇을 할 것인가가 있다
Customer Tests 사용자의 요구사항에 부함하는 소프트웨어 만들기
Small Releases 릴리즈 기간을 짧게 반복하여 주기적으로 프로토 타입을 의뢰인에게 보여준다
Simple Design 코딩을 가능한 간단하게 한다
Test-Driven Development 테스트를 기반으로 하여 개발한다
Pair Programming 두명 혹은 그 이상의 프로그래머가 함께 코딩을 한다

 

XP 개발 프로세스

 

유저스토리(사용자스토리)

- 고객의 요구사항을 적어논 것

- 사용자의 입장에서 적으며 개발자 입장에서 재해석 해서는 안된다

 

릴리즈 계획

- 개발 완료 시점에 대한 일정을 수립한다

 

스파이크

- 요구사항의 신뢰를 높이고 기술 문제 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램

- 핵심 기능 이외에는 모두 무시하고 최대한 간단하게 작성한다

 

이터레이션

- 하나의 릴리즈를 더 세분화 한 단위

- 이 기간 중에 새로운 스토리가 작성될 수 있으며, 작성된 스토리는 진행 중인 이터레이션 혹은 다음 이터레이션에 포함될 수있다

 

승인검사

- 부분 완료 제품이 구현되면 수행한다

- 사용자가 직접 작성한 시나리오를 바탕으로 테스트 코드를 작성한다

- 테스트를 반드시 통과해야 유저스토리 처리가 완료된다

- 테스트가 완료되면 다음 이터레이션을 진행한다

 

소규모 릴리즈

- 릴리즈를 소규모로 진행하며 고객의 반응을 기능별로 확인할 수 있다

반응형

스크럼 기법

- 팀이 중심이 되어 개발의 효율성을 높이는 기법이다

- 팀원은 스스로가 스크럼 팀을 구성하며 개발에 관련된 모든 것을 스스로 해결할 수 있어야 한다

- 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성된다

 

스크럼이 추구하는 가치

확약 : 약속한 것을 확실히 실현하는 것

전념 : 확약한 것의 실현에 전념하는 것

정직 : 어떤 것이 자신에게 불리해도 숨기지 않는 것

존중 : 자신과 다른 사람에게 경의를 표하는 것

용기 : 팀 구성원은 자신이 옳은 일을 할 수 있도록 팀원간 갈등과 도전을 통해 작업 할 수 있는 용기

 

스크럼의 진행 순서

스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 ->스프린트 회고

 

제품 백로그

- 제품 개발에 필요한 요구사항 목록

- 지속적으로 업데이트된다

 

스프린트 계획 회의

- 스프린트 목표와 스프린트 백로그를 계획하는 외의

- 요구사항을 개발자들이 나눠서 작업할 수 있도록 task라는 작업 단위로 분할한 후 백로그를 작성한다

 

스프린트

- 반복적인 개발 주기

- 보통 2 ~ 4주 정도의 기간 내에서 진행된다

- 개발자가 원하는 task를 직접 선별하여 담당할 수 있도록 하는 것이 좋다

 

일일 스크럼 회의

- 날마다 진행되는 미팅으로 어제 한 일, 오늘 할 일, 장애 현상 등을 공유한다

 

스프린트 검토 회의

- 제품이 요구사항에 잘 부합되는지 테사용자가 포함된 참석자 앞에서 테스팅을 수행한다

- 제품 책임자는 개선할 사항에 대한 피드백을 정리해 백로그를 업데이트 한다

 

스프린트 회고

- 정핻놓은 규칙을 잘 준수하고, 개선할 점은 없었는지 기록한다

제품 책임자(PO; Product Owner) - 제품 백 로그를 정의하여 우선순위를 정해준다
스크럼 마스터(SM; Scrum Master) - 팀원을 코칭하고 프로젝트의 문제 상황을 해결하는 역할이다
개발팀(DT; Development Team)  - 제품 책임자와 스크럼 마스터를 제외한 모든 팀원

 

 

반응형

소프트웨어 생명 주기

소프트웨어 생명 주기(Software Life Cycle)이란 소프트웨어의 계획, 개발, 시험, 채용하는 과정을 뜻하는 용어이다.

대개 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 유지보수 단계로 구성되어있다.

 

소프트웨어 생명주기 모델

일반적으로 사용되는 소프트웨어 생명 주기 모델에는 폭포수 모형, 프로토타임 모형, 나선형 모형, 애자일 모형이 있다

 

폭포수 모델

폭포수 모델

- 순차적인 소프트웨어 개발 프로세스로 마치 폭포수처럼 지속적으로 아래로 향하는 것 처럼 보이는 데서 이름이 붙여졌다.

- 가장 오래되고 폭넓게 사용되는 전통적인 소프트웨어 생명 주기 모형이다

- 전 단계가 수행되어 완료되어야 다음 단계로 진행할 수 있다

- 설계자들이 향후 구현 작업의 난이도를 예측하기 어려워 설계가 어렵다는 단점이 있다

- 수정 모델로는 생선회를 겹쳐 내놓는 모양처럼 간 단계들이 서로 겹쳐 있는 사시미 모델이 있다

 

프로토타입 모델

프로토타입 모델

- 사용자의 모든 요구사항이 정확하게 반영될 때 까지 계속해서 개선/보완하는 모델

- 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다

- 프로토타이핑 과정은 4단계로 구분된다.

    1. 기본적인 사용자 요구사항을 분석한다. 시스템 설계자는 기본적인 요구사항이 도출되기까지 사용자와 함께 작업한다.

    2. 시스템 설계자가 위에 단계에서 도출된 요구사항을 만족시키는 프로토타입을 4세대언어로 알려진 프로그래밍 언어 또는 CASE 도구를 이용하여 개발한다. 이때 프로토타입은 앞으로 개발될 시스템의 가장 핵심적인 기능  위주로 개발된다

    3. 사용자가 개발된 프로토타임을 실제 사용함으로써 요구사항이 이행되고 있는지를 확인하며 프로토타입의 보완을 위한 여러 가지 제안을 하게 된다.

    4. 프로토타입의 수정과 보완이 이루어진다. 시스템 설계자는 사용자가 요구한 모든 제안사항과 이에 따르는 보완작업을 하게 된다. 프로토타입이 수정된 후에는 3단계로 돌아간다. 사용자가 만족할 때 까지 3단계와 4단계는 계속 반복된다.

- 사용자 중심의 개발 방법으로 사용자 요구를 극대화 할 수 있다

- 폭포수 모델에 비해 개발시간을 줄일 수 있다

- 오류를 초기에 발견할 수 있다

- 변경성이 용이하다

- 최종적으로는 시간과 비용이 훨씬 많이 들 수 있다. 언제든지 변경이 용이하지만 이러한 시스템의 변경이 계속되면 오히려 시간과 비용이 많이 들게 된다

 

나선형모형

나선형 모델 - IT 위키https://itwiki.kr/w/%EB%82%98%EC%84%A0%ED%98%95_%EB%AA%A8%EB%8D%B8

- Boehm이 제안한 모델로 폭포수 모형과 원형 모형의 장점을 수용하고 위험 분석을 추가한 점증적 갭라 모델이다

- 프로젝트를 개발하면서 발생하는 위험을 관리하고 최소화하는 것이 목적이다

- 점진적으로 성과를 보면서 개발을 진행하므로 정밀도가 높고 유지보수 과정이 필요없다

- 대규모 프로젝트, 국책사업 및 위험 부담이 큰 시스템 개발에 적합하다

- 진행 순서는 목표설정 -> 위험분석 -> 구현 및 테스트 -> 고객평가 순이다

 

애자일 모델

애자일 모델

- 기민한, 날렵한 이란 뜻으로 좋은 것을 빠르게 취하고, 낭비없게 만드는 다양한 방법론을 통칭해 일컫는다.

- 일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구사항을 더하고 수정하여 개발을 진행한다

- 일직선 과정인 폭포수 모델과 반대의 개념이다

- 계획 -> 설계 -> 개발 -> 테스트 -> 피드백 순으로 반복적으로 진행된다

 

애자일 소프트웨어 개발 선언

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업ㅇ르 통해 우리는 다음으 가치 있게 여기게 되었다

공정과 도구보다 개인과 상호작용
포괄적인 문서보다 작동하는 소프트웨어
계약 협상보다 고객과의 협력
계획을 따르기보다 변화에 대응하기

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas

 

 

반응형

+ Recent posts