day 4 : 애자일 방법론

natuure·2021년 9월 29일
1

어플리케이션 개발은 자주 변하는 고객의 요구사항을 제일 우선 처리하고, 다른 개발팀과 협업을 능동적으로 하고, 고객이 원하는 때에 실행 가능한 제품을 개발할 수 있어야 한다.

애자일(Agile) 방법론

애자일이란?

정해진 계획대로 주도해 나갔던 과거의 방법론과 다르게,
개발해 나가면서 고객의 피드백을 바탕으로 주도적으로 개발하는 방법론

절차보다는 사람, 즉 고객을 중심으로 신속한 변화민첩하게 적응하면서 효율적으로 개발하는 방법론이다.


계획 - 요구분석 - 설계 - 개발 - 테스트 - 검토 순으로 진행되며,
프로젝트를 시작한 후 끊임없이 개선하기 위해 노력한다.





애자일 방법론의 특징

  • 고객과 개발자의 지속적인 소통을 통하여 변화하는 요구사항을 신속하게 수용한다.
  • 개발자 개인의 가치보다는 팀의 목적을 우선시하며 고객의 의견을 가장 우선시한다.
  • 팀원들과의 주기적인 회의 및 제품 시현을 통한 방지를 점검한다.
  • 진행하면서 프로그램을 시행해보고 고객으로부터 피드백을 받는다.
  • 프로그램 품질 향상을 위해 노력한다.

애자일은 고객·협업 중심, 변화에 대해 유연하게 적응이 핵심





애자일 방법론의 장점

  • 소프트웨어 및 고객 중심 - 변화하는 요구사항 및 사용자 의견을 수용하기 쉬움
    계획 혹은 기능에 대한 수정과 변경에 유연하다.
    고객 요구사항에 대한 즉각적인 피드백에 유연하며, 프로토타입 모델을 빠르게 출시할 수 있다.

  • 보다 빠르고 고품질 제공
    점진적으로 테스트를 할 수 있어서 버그를 쉽고 빠르게 발견할 수 있다.
    프로젝트 계획에 걸리는 시간을 최소화할 수 있다.

  • 소규모 프로젝트 적합
    빠듯한 기한의 프로젝트를 빠르게 출시할 수 있다.





애자일 방법론의 단점

  • 계획의 불확실성
    확정되지 않은 계획 및 요구사항으로 인한 반복적인 유지보수 작업이 많다.

  • 요구사항과 다른 최종 제품
    고객의 요구사항 및 계획이 크게 변경될 경우 모델이 무너질 수 있다.
    확정되지 않은 계획으로 개발 진행 시 이해하지 못하고 진행하는 부분이 많을 수 있다.
    반복적인 업무로 속도는 빠를 수 있으나 미흡한 기능들에 대한 대처가 필요하다.

  • 어려운 팀구성
    개인이 아닌 팀이 중심이 되다 보니 공통으로 해야 할 작업들이 많을 수 있다. (회의, 로그 등)





스크럼(Scrum)

럭비에서 유래된 용어로,
공수가 불분명할 때 팀원들이 어깨 동무를 하고 상대편과 원을 이루고 어깨를 맞닿은 상태에서 중앙에 럭비공을 놓아서 경쟁하는 것을 말한다.

즉, 팀원들과 협업하여 소프트웨어를 개발하는 모습이 럭비의 스크럼과 비슷하여 붙여진 듯 하다.

애자일 방법론 중의 하나로, 팀 중심으로 소프트웨어를 개발하는 방법론이다.
30일 간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다.



구성원

  • 스크럼 마스터 (SM)
    개발팀을 지원, 조율하기 위해 존재

  • 제품 책임자 (PO)
    의사결정권이 있는 사람

  • 개발팀 (DT)
    디자이너 및 테스터 등을 전부 포함한 개념




스크럼 프로세스

1. 제품 백로그 작성

  • 제품 완성에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록
  • 고객 및 최종사용자들과의 소통을 통해서 개발에 필요한 사항을 백로그에 기록한다.
    이때 기록된 내용들은 개발자와 사용자들이 모두 형식 없이 편하게 이야기 형식으로 되어있기 때문에 스토리라고 부른다.
  • 백로그의 우선순위는 제품 책임자(PO)에 의해서만 변경된다.


스프린트 - 계획 회의부터 제품 리뷰까지 반복적인 개발 주기
아이디어를 단기간 내에 프로토타입으로 제작하고 테스트하여 중요한 문제들에 대한 답을 찾아가는 과정


2. 스프린트 계획 회의

  • 백로그가 준비되면 스크럼 마스터는 계획 회의를 준비한다.
  • 어떤 팀이 어떤 항목을 담당하게 될지를 공동으로 결정한다.
  • 각 개발자들은 세부 개발목표와 스프린트 백로그를 계획한다.


3. 스프린트 백로그 작성

  • 하나의 스프린트 동안 완료할 과제들의 목록을 작성한다.
  • 날짜가 지날 수록 왼쪽에서 오른쪽으로 변경된다.


4. 일일 스크럼 회의

  • 팀원들은 스크럼 마스터(SM)와 함께 매일 회의를 열어서 최대 15분 이내에 마친다.
  • 계획에 방해되는 요소들을 스크럼 마스터에게 알리고, 스크럼 마스터는 장애 요소 해결을 위해 노력한다.
  • 소멸 차트를 통해 일의 진행이 매끄러운지 판단할 수 있는데, 예상기간 대비 실제 작업 진행량을 비교하여 문제점을 파악한다.


5. 스프린트 검토 회의

  • 제품 책임자(PO)매주 검토회의를 통해서 필요한 내용을 백로그에 업데이트 한다.
  • 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인한다.


스프린트를 통해 1~4주 정도 반복적 수행으로 개발 품질을 향상 시킨다. ➰



6. 스프린트 회고

  • 지난 일정을 되돌아본다.

일일 스크럼 회의 : 스크럼 마스터 (SM)
스프린트 검토 회의 : 제품 책임자(PO)
회의의 주체가 다르다는 점 기억





폭포수 모델과 애자일 방법론의 차이점

폭포수 모델은 단계가 마무리 되어야 다음 단계로 넘어갈 수 있는 모델로,
폭포처럼 위에서 아래로 떨어지는 형태로 개발되기 때문에 다시 되돌아가기 어렵다.

따라서 새로운 요구사항을 받아들이기 어려울 뿐만 아니라 고객과의 의사소통이 어렵고,
테스트도 맨 마지막에 진행해야 한다.

profile
🌈 Mobile Application Developer

0개의 댓글