개발 방법론

최승아·2021년 9월 3일
0

폭포수

1. 설립 전 - Build & Fix 방식

정의

  • 요구사항에 대해 일단 코드로 만든 후 계속 수정해 나가며 프로그램을 완성하는 방식

2. 설립 후 - 폭포수 방식

구조

  • Build & Fix 와는 달리 좀 더 구체화되고 순차적으로 진행

  1. 분석 : 고객의 요구조건, 시스템 환경 등 타당성 검토 후 요구사항에 대한 명세를 작성
  2. 설계 : 요구사항의 명세를 바탕으로 SW의 전체 구조간의 관계, 상세 알고리즘 등을 세부적으로 설계
  3. 개발 / 구현 : 요구사항 명세를 준수하는 설계에 따라 직접 코딩하여 SW를 개발하는 단계
  4. 테스트 : 완성된 프로그램을 테스트하는 단계
  5. 유지보수 : 변화에 대비하는 과정

특징

  1. 절차적 : 순차적으로 진행
  2. 단계검증 : 각 단계별로 검증이 완료 후 다음 단계로 이동
  3. 하향식 접근 : 전 단계의 작업이 모두 완료 되어야 다음 진행이 가능한 방식
  4. 피드백 : 결함 발견시 전 단계로 돌아가는 피드백 단계 존재

장/단점

  1. 장점
  • 전체 과정이 SW 생명주기와 일치하여 이해하기 쉬움
  • 각 진행 단계 별 산출물(문서)이 확실하여, 진행중 및 진행 이후에도 관리가 용이
  1. 단점
  • 각 단계가 종결 되어야 다음 단계 진행 가능
  • 고객의 요구사항을 반영하기 어렵다
  • 테스트 단계에서 발견된 중요 결함은 치명적인 문제가 될 수 있음

에자일 - 폭포수 문제점 해결!

정의

  • 문서를 통한 개발 방법 보다 일정 주기를 가지고 실질적인 코딩을 통해 개발을 진행하여 그때 그때 필요한 고객의 요구사항을 더하고 수정하며 진행하는 방법론

장/단점

  1. 장점
  • 제품에 대한 피드백을 많이 받아 제품의 질을 향상시키고, 고객 요구사항의 지속적인 변화에 맞춤
  • 지속적인 테스트를 하기 때문에 버그들을 고치기 쉽다
  1. 단점
  • 고객의 요구사항을 추가하고, 수정하는 작업이 반복되기 때문에 데드라인을 맞추기가 쉽지않음
  • 만약 뒤늦게 제품을 다시 수정해야 하는 상황이 생긴다면 수정하고 시험하기를 다시 번복해야 함 ==> 많은 비용이 들어감

애자일 선언문

  • 프로세스 도구 < 사람과 상호작용
  • 광범위한 문서 < 실제 작동하는 제품
  • 계약 협상 < 고객 협력
  • 계획 따름 < 변화 대응

스크럼 방식

  • [스크럼 용어 탄생] 럭비에서 나온 용어 ==> 사소한 반칙이 일어나면 그 주변으로 7~8명이 뭉쳐서 서로간의 힘겨루기를 하는 모양새를 보이는 모습이 방법론과 닮아있어서 이름을 붙임

출처 : https://needjarvis.tistory.com/317

  1. 주요 개념
  • 5-9명으로 구성되는 소규모의 다기능팀이 제품 개발을 완성하기 위해 스프린트라고 불리우는 업무 주기를 반복
  • 해야 할 일들의 목록에서 스프린트 동안 해야 하는 일들을 스스로 결정하고 완수하여 매 스프린트마다 결과물을 산출해냄
  • 팀이 성과를 낼 수 있도록 조력하는 역할 => 스크럼 마스터
  • 스크럼 마스터는 팀이 과제를 완수할 수 있도록 필요한 자원을 지원하거나 장애 요소를 제거하여 프로세스 인도
  1. 스프린트
  • 과제가 진행되는 주기를 지칭하는 것
  • 보통 1~4주로 구성
  • 하나의 스프린트가 끝나면 곧바로 다음 스프린트가 시작됨
  1. 스크럼 실행 방식
  • 팀, 제품 책임자, 스크럼 마스터가 참여하는 계획 회의로 부터 출발
  • 1파트 : 무엇을 하는지 => 2파트 : 결정된 무엇을 어떻게 할지 다룸
  • 매일 15분~30분 동안 스크럼 회의 진행
  • 스프린트 회고를 통해 무엇이 효과가 있고, 무엇이 문제인지 자유롭게 논의하여 프로세스와 환경을 점검하고 조정
  • 1~4주 주기로 반복되며 피드백과 학습을 통해 고객 요구 및 환경 변화에 대응 가능 ==> 고객 만족도 개선하고 , 더 빨리 제품 또는 기능을 출시 할 수 있게 만듬

참조 : https://hrbulletin.net/organizational-culture/%EC%95%A0%EC%9E%90%EC%9D%BC-%EB%B0%A9%EB%B2%95%EB%A1%A0%E2%91%A0-%EC%8A%A4%ED%81%AC%EB%9F%BCscrum/


데비옵스

  • 애자일은 고객과의 상호작용 => 데브옵스는 개발팀과 운영팀간의 긴밀한 협력 관계 구축에 집중
  • 개발자 + 운영자 역할을 합쳐지면서 => 더욱 민첩한 개발 및 배포 사이클을 가질 수 있음

참조 : https://engineering-skcc.github.io/devops/DevOps1-%EC%95%A0%EC%9E%90%EC%9D%BC%EA%B3%BC%EB%8D%B0%EB%B8%8C%EC%98%B5%EC%8A%A4/

폭포수(위) vs 에자일(아래) 비교 사진


(출처 : https://www.safaribooksonline.com/library/view/user-story-mapping/9781491904893/ch04.html)

profile
⭐ 개발 정리 공간 ⭐

0개의 댓글