에자일(소프트웨어개발프로세스)
– 성공하는 소프트웨어 기업이 되기 위해서는 경쟁사보다 빠른 시장 진입, 고객의 실제 요구사항에
부합하는 솔루션, 그에 근거한 확고한 방법론, 품질과 기능 면에서 필요한 조건을 만족시키는 솔루션,
경쟁사보다 빠른 변화에 대한 대처 등이 필요하다. 이 모든 것을 애자일 기법이 제공할 수 있다.
– 애자일 선언문의 핵심
① 상호작용과 개인(Individual and interactions)
② 동작하는 소프트웨어(Working software)
③ 고객과의 협력(Customer collaboration)
④ 변화에 대한 대응(Responding to change)
– 애자일 선언문이 추구하는 핵심 원리
① 지속적으로 가치 있는 소프트웨어를 조속하게 릴리스.
② 요구사항의 변화를 환영(처리 가능한 프로세스여야 함.)
③ 짧은 주기로 자주 릴리스.
④ 개발자와 관련된 사람들은 프로젝트 진행시 함께 작업.
⑤ 문서보다는 동작을 생각하는 단순성.
⑥ 자체적으로 조직된 팀
→ 요구사항의 변화를 수용하고 실제로 동작하는 소프트웨어를 끊임없이 출하해야함.
– 애자일 방법론들의 목표 : 신뢰성이 높은 소프트웨어를 좀 더 빨리 제작하는 것
Ceremony ↓ / 반복적(Not 선형적)
※ RUP : ceremony 조율 가능
– 애자일 방법론의 특징
○ 90년대 중반 기존의 무겁고 규범적인 방법론에서 가벼운 방법론을 지향.
○ 적기 시장 진입이나 고객 요구 사항의 변화에 민첩하게 대응하는 동시에 높은 품질을 제공
(역사가 짧기 때문에 많은 보완과 발전이 필요한 방법론)
○ 고객과 직접 상호작용이 가능한 소규모 팀일 경우, 대규모 소프트웨어 개발에서 엔터프라이즈급
방법론의 적용 실험을 통해 방법론 자체는 변하더라도 핵심 활동은 일치함.
○ 애자일 소프트웨어의 장점으로 생산성 향상, 품질 향상, 팀의 사기와 업무 만족도 향상 등의
전반적으로 좋은 결과가 나타남.
– 애자일 방법론의 종류
① XP(eXetrem Programming)
○ 널리 사용되고 있는 애자일 소프트웨어 개발 방법론 중 하나
○ 프로그래머 팀(5~10명)이 현장에서 고객의 팀과 함께 머물며 일함.
○ 요구사항의 형태인 사용자 스토리 형태로 구체화되어야 함
○ 짝을 이뤄(Pair Program)일을 하고 스스로 단위 테스트를 수행한다.
○ 요구사항, 아키텍처, 설계는 프로젝트 방향과 함께 나아간다.
② Scrum(스크럼)
○ 애자일 프로젝트 관리 방법론.
○ 스프린트(sprint, 특정 기간을 의미)라는 30일 주기를 기반으로 진행.
○ 스프린트 시 행하는 작업은 고정.
○ 릴리스당 약 세 번의 스프린트를 수행한다.(30×3=90일)
③ RUP(Rational Unified Process)
○ 소프트웨어 개발 방법론, 소프트웨어 공학 활동, 프로세스 프레임 워크.
○ UP를 구체화한 UML기반의 프로세스.
○ 반복, 점진적인 특성은 애자일 방식에 충분히 적용 가능.
○ RUP가 애자일 방법론에 완벽히 부합하지는 않지만 일부를 적절히 응용하면 애자일 방법론에
매우 가까워질 수 있다.
– 폭포수 모델의 특징
○ 비효율성과 비유연성으로 과소평가되고 있으나 이러한 모델을 통해 과거 수많은 성공적인
애플리케이션이 개발되었음.
○ 전통적인 폭포수 모델은 현재에도 널리 사용 중.
○ 논리적인 접근법을 조금 더 추상화된 방법으로 나타냄.
– 폭포수 모델 오용 방지를 위한 네 가지 가정의 문제점.
○ 요구사항의 이해와 정의를 위해 제대로 시간을 투자해야함
→ 소프트웨어가 완성되고 최종 사용자에게 전달되는 시간 간격이 클수록 고객으로부터 피드백을
받아 새로운 요구사항을 구현하는 것도 오래걸리게 됨.
→ 변화에 대한 발견이 늦어질수록 변경해야 하는 부분은 커지고 더 많은 재 작업이 따른다.
○ 개발 도중 발생하는 요구사항 변경이 적은 편이기에 계획 재고나 수정의 빈도가 적음.
→ 요구사항 결정 시점과 시스템 개발 완료 시점 간의 차이가 클수록 더 많은 변경사항이 발생함.
○ 시스템 통합은 아키텍처와 계획에 따라 예측이 가능
→ 독립적으로 활동하는 팀들이 만든 대규모의 코드가 잘 동작 할 것이라는 가정은 잘못됨.
○ 일정은 예측 가능한 스케줄 안에서 완료할 수 있다.
→ 일정은 최소 두 배정도 늘어나는 것을 예상해야 한다.
– 폭포수 모델에서 일정이 지연되는 경우
○ 데드라인이 임박했음에도 최종적으로 시스템이 원활이 동작하는 지 검사하는 통합 작업은
수행하지도 못한 상태가 됨.
○ 고객 평가를 검사할 수 있는 기능이 없어서 만든 결과물이 고객의 요구에 부합하는지조차
알 수 없게 됨.
→ 이로 인해 예상했던 시간 안에 의도한 결과물을 고객에게 제대로 배포하지 못하고,
솔루션은 재고할 가치가 없었음을 알고, 고객이 만족할 만한 기능이 없을 수도 있고,
새로 다시 작업 시 이미 만들어 놓은 기능은 무용지물이 될 수도 있고, 작업이 끝난 것이
아니므로 프로젝트의 위험을 제거했다고 볼 수 없게 된다.
[출처] http://blog.naver.com/tanatounot/220961140720