Agile Vs Waterfall : 프로젝트에 가장 적합한 방법은 무엇입니까?

agile vs waterfall which is best methodology

문자를 문자열 C ++로 변환

애자일 및 폭포수 방법론, 다양한 유형의 SDLC 모델, 폭포수 대 애자일 개발 모델 및 테스트의 차이점에 대해 모두 알아보십시오.

이 유익한 기사를 읽고 각각의 장단점을 기반으로 프로젝트에 가장 적합한 모델을 결정하십시오.

폭포 모델과 애자일 모델은 소프트웨어 개발 수명주기 (SDLC)의 유형입니다. 이는 소프트웨어 산업에서 소프트웨어를 설계, 개발 및 테스트하는 데 사용하는 프로세스입니다.

SDLC를 따르면 고객 기대치를 달성하고 주어진 시간 내에 프로젝트를 완료하고 비용을 추정 할 수 있습니다.

학습 내용 :

• 폭포수 및 민첩한 모델 워크 플로
  • 소프트웨어 개발 수명주기는 무엇입니까?
  • 소프트웨어 개발 수명주기의 유형
    • # 1) 폭포 모델
    • # 2) 애자일 모델
    • # 3) 나선형 모델
    • # 4) 프로토 타입 모델
    • # 5) V 및 V 모델
• 폭포 모델
• 애자일 워크 플로우
  • Agile에서 사용되는 주요 용어
  • 애자일 방법론을 채택하는 주요 요소
  • 애자일 방법론의 유형
• 애자일 대 폭포수 모델의 차이점
• 애자일 테스트와 폭포 테스트의 차이점
• 결론
  • 추천 도서

폭포수 및 민첩한 모델 워크 플로

간단한 영어에서 Agile은 '빠르고 쉽게 움직일 수 있음'을 의미합니다. 애자일 개발 방법론 .

Agile은 계획을 자주 검토하고 조정하여 작업을 짧은 작업 세그먼트로 분할하여 나타내는 프로젝트 관리 방법입니다.

마찬가지로 폭포라는 단어는 물의 수직 흐름 또는 일련의 가파른 방울을 통한 물의 흐름을 나타냅니다. 폭포수 모델은 요구 사항 수집, 분석, 설계, 개발, 테스트, 배포 및 유지 관리 단계를 통해 진행 상황이 주로 한 방향으로 아래쪽으로 흐르는 선형 순차 모델입니다.

이 동일한 그림이 프로젝트 관리의 개념에 적용됩니다. 폭포 모델 . 일련의 단계와 고정 된 작업 계획으로 표현되는 프로젝트 관리 방법입니다.

(영상 출처 )

Waterfall 워크 플로 및 Agile 워크 플로를 논의하기 전에 소프트웨어 개발 수명주기 정의 및 요구 사항을 살펴 보겠습니다.

소프트웨어 개발 수명주기는 무엇입니까?

소프트웨어를 체계적으로 개발하기위한 단계별 절차입니다. 이를 위해 우리는 서로 다른 회사의 서로 다른 유형의 소프트웨어 개발 수명주기 중에서 선택합니다. 요구 사항에 따라 적절한 라이프 사이클이 선택됩니다.

폭포 모델은 SDLC 유형 중 하나이며 소프트웨어를 개발하는 오래된 프로세스입니다. 애자일 모델은 최신의 고급 모델입니다. 애자일은 다른 소프트웨어 개발 수명주기에서 파생됩니다.

다른 SDLC에는 나선형 모델, V 및 V 모델, 프로토 타입 모델이 포함됩니다. 비즈니스 요구 사항의 필요성과 호환성을 기반으로 소프트웨어 애플리케이션 개발에 가장 적합한 모델을 선택합니다.

(영상 출처 )

소프트웨어 개발 수명주기가 필요한 이유는 무엇입니까?

프로젝트를 체계적으로 관리하려면 SDLC가 필요합니다. 특정 수준의 제어를 제공하고 팀 구성원의 역할과 책임을 정의합니다. SDLC의 각 단계에 대한 범위와 기한을 제공합니다.

품질의 제품을 개발하고 제공하기위한 모든 단계를 따르는 팀원을위한 사용자 가이드와 다소 비슷합니다. 팀 관리가 목표와 요구 사항을 정의하고 평가하는 데 도움이됩니다. 또한 작업을 예약하고 예측하는 데 도움이됩니다. 그것은 클라이언트와 개발 팀 사이의 커뮤니케이션 라인을 만들고 그들 각각의 역할과 책임을 생성합니다.

소프트웨어 개발 수명주기의 유형

소프트웨어 개발 프로세스에 사용되는 SDLC 유형에 대한 간략한 소개를 살펴 보겠습니다.

# 1) 폭포 모델

앞에서 설명한 것처럼 폭포수 모델은 처음으로 도입 된 소프트웨어 개발 수명주기입니다. 소프트웨어를 순차적으로 개발하는 방법입니다. 이 접근 방식을 따르는 회사는 거의 없습니다. 프로젝트가 매우 간단하고 추가 요구 사항 변경이없는 경우이 접근 방식을 따릅니다.

이 자습서에서는 폭포 모델에 대해 자세히 설명합니다.

# 2) 애자일 모델

애자일 워크 플로는 대부분의 회사에서 사용되는 소프트웨어 개발 프로세스에 대한 고급 접근 방식입니다. 애자일은 스프린트 기반 소프트웨어 개발 수명 주기로 정의됩니다.

다음 섹션에서는 Agile 워크 플로에 대해 자세히 설명 할 수 있습니다.

# 3) 나선형 모델

요구 사항을 점진적으로 분할하고 추가하여 소프트웨어를 빌드하고 테스트하는 방법입니다. 이 모델은 요구 사항이 계속 변경되는 프로젝트에 도움이됩니다. 이 나선형 모델은 반복 개발 프로세스와 순차적 선형 개발 프로세스의 조합입니다.

이 접근 방식을 통해 제품의 증분 릴리스가 가능합니다. 여기서는 릴리스를 위해 소프트웨어의 모든 모듈이 완료 될 때까지 기다릴 필요가 없습니다.

선형 순차 모델은 시스템 수준에서 시작하여 분석, 설계, 코딩, 테스트 및 지원을 통해 진행되는 소프트웨어 개발의 체계적인 순차 접근 방식을 의미합니다.

반복적 모델은 초기의 단순화 된 구현에 초점을 맞춘 소프트웨어 개발 수명주기의 특정 구현을 의미하며, 이후 점차적으로 복잡성이 증가하고 최종 시스템이 완성 될 때까지 더 광범위한 기능이 설정됩니다.

# 4) 프로토 타입 모델

이 모델에는 먼저 더미 모델을 개발하고 실현 가능하고 모든 비즈니스 요구 사항에 도달하면 실제 작업 모델을 구현하는 방식으로 소프트웨어를 빌드하고 테스트하는 프로세스가 포함됩니다.

여기서 먼저 프로토 타입을 제작하고 테스트 한 다음 정확한 시스템 사양으로 실제 모델을 제작했습니다. 소프트웨어 프로토 타이핑은 소프트웨어 응용 프로그램의 프로토 타입을 만드는 활동입니다.

# 5) V 및 V 모델

검증 및 검증 모델입니다. 여기에서 소프트웨어를 개발하는 동안 SDLC의 각 단계에서 모든 것을 확인하고 검증하는 데 사용했습니다. V 모델은 폭포 모델의 확장으로 간주됩니다.

따라서 모든 SDLC 유형에는 기능과 특성이 있습니다. 프로젝트 요구 사항, 요구 사항, 실행 가능성, 기간에 따라 소프트웨어 응용 프로그램을 개발하기위한 특정 소프트웨어 개발 수명주기를 선택할 수 있습니다.

이제 Waterfall 및 Agile 소프트웨어 개발 수명주기에 대해 자세히 설명하겠습니다.

폭포 모델

Waterfall 모델에서는 다른 단계를 시작하기 전에 각 단계를 완료해야합니다. 우리는 동시에 여러 단계를 운영 할 수 없습니다. 이것은 Winston Royce에 의해 1970 년에 소개되었습니다. Waterfall 모델은 여러 단계로 나뉩니다.

(영상 출처 )

폭포 모델에는 다음 단계가 포함됩니다.

1. 요구 사항 수집
2. 타당성 조사
3. 디자인
4. 코딩
5. 테스팅
6. 유지

# 1) 요구 사항 분석

여기에서 비즈니스 분석가는 요구 사항 사양을 얻습니다. 요구 사항은 CRS (Customer Requirement Specification) 형식입니다. CRS는 비즈니스 흐름이 어떻게 진행되어야하고 애플리케이션이 지정된 요구 사항에 따라 어떻게 작동해야하는지 설명합니다. 비즈니스 분석가는 CRS를 SRS (Software Requirement Specification)로 변환합니다.

그런 다음 비즈니스 분석가는 개발 및 테스트 팀과 요구 사항 사양을 자세히 논의하고 개발 및 테스트 관점에서 요구 사항을 이해합니다. 실제 요구 사항을 기반으로 응용 프로그램 소프트웨어를 구축하기위한 요구 사항을 논의하고 분석하는 단계입니다.

여기에서 모든 것은 소프트웨어 요구 사항 사양 문서에 문서화되어야합니다. 폭포수 모델에서 각 단계의 결과물 / 결과 / 출력은 다음 단계의 입력 소스입니다.

서비스 기반 산업에서 비즈니스 분석가는 요구 사항을 가져올 수 있습니다.
제품 기반 회사에서는 제품 분석가가 요구 사항을 제공합니다.

# 2) 타당성 조사

경영진이 타당성 조사를 수행합니다. 즉, 팀은이 요구 사항 / 애플리케이션이 우리 환경에서 개발 될 수 있는지 여부, 사용 가능한 리소스가 충분하거나 부족한지, 비용 및 기타 여러 요인이 실행 가능한지 여부와 같은 매개 변수를 분석하고 우리가 다룰 수 있는지 확인합니다. 모든 비즈니스 흐름이 있는지 여부.

이 회의 / 분석에서는 프로젝트 관리자, 비즈니스 분석가, 재무 관리자, HR, 프로젝트 리더가 토론의 ​​일부가됩니다.

# 3) 시스템 설계

여기에서 프로젝트 아키텍트는 시스템 설계를 준비합니다. 그는 하드웨어, 시스템 요구 사항을 지정하고 응용 프로그램 아키텍처를 설계합니다. 시스템 설계에는 고수준 설계와 저수준 설계의 두 부분이 있습니다. 높은 수준의 디자인에서 우리는 응용 프로그램의 다른 블록을 디자인합니다. 저수준 설계에서는 의사 코드를 작성합니다.

# 4) 코딩

여기에서 개발자는 다른 방법과 다른 논리를 사용하여 애플리케이션의 각 기능과 UI에 대한 정확한 코딩을 시작합니다. Java, Python 또는 기타 언어와 같은 프로그래밍 언어를 사용하여 애플리케이션을 빌드 할 수 있습니다.

애플리케이션의 특정 모듈의 각 기능에 대한 코딩이 완료되면 개발자는 단위 테스트를 수행합니다. 코드가 제대로 작동하면 개발자는 코드를 테스트 환경에 배포하고 테스트를 위해 테스트에 빌드를 제공합니다.

# 5) 테스트

여기에서 테스트 활동이 시작됩니다. 이 단계까지는 Waterfall 모델에서 작업이 없습니다. 이 단계에서는 모든 유형의 테스트를 수행합니다. 이러한 테스트 유형에는 연기 테스트, 기능 테스트, 통합 테스트, 시스템 테스트, 승인 테스트, 회귀 테스트, 임시 테스트, 탐색 테스트 및 브라우저 간 테스트가 포함됩니다.

빌드를 받으면 애플리케이션 테스트를 시작합니다. 먼저 연기 테스트부터 시작하겠습니다. 차단 문제가 관찰되지 않으면 세부 테스트를 계속할 것입니다.

기능 테스트에서는 애플리케이션의 각 구성 요소를 테스트하기 시작합니다. 여기에서는 텍스트 필드, 버튼, 링크, 라디오 버튼, 업로드 버튼, 드롭 다운 및 탐색 링크와 같은 다양한 구성 요소를 확인합니다.

다음으로 UI, 룩앤필, 긍정 및 부정 입력 테스트를 확인합니다.

그런 다음 통합 테스트를 시작합니다. 여기서는 데이터 통합을 확인합니다. 동일한 데이터가 다른 각 페이지에 반영되는지 여부를 확인하고 각 페이지에 대한 이메일 링크 탐색을 확인합니다. 타사 응용 프로그램과의 데이터 통합을 확인하고 응용 프로그램의 데이터베이스 변경 사항을 확인합니다.

다음으로 시스템 테스트를 수행합니다. 전체 애플리케이션을 단일 단위로 확인합니다. 기능, 페이지 통합, 필드 유효성 검사, 오류 메시지, 확인 메시지 등을 확인합니다.

애플리케이션을 테스트하는 동안 버그 추적 도구에 문제를 기록합니다. 문제에 따라 버그에 우선 순위를 부여합니다. 버그를 생성 한 후 각 개발자에게 버그를 할당하여 문제를 해결합니다. 개발자가 버그를 수정 한 후 테스터에게 할당하면 버그를 확인합니다. 제대로 작동하면 테스터가 버그를 닫고, 그렇지 않으면 테스터가 문제를 해결하기 위해 개발자에게 다시 할당합니다. 이것이 버그 라이프 사이클이 진행되는 방식입니다.

그런 다음 수락 테스트로 이동합니다. 여기서는 스테이징 및 UAT (User Acceptance Testing)와 같은 다양한 환경에서 애플리케이션을 테스트합니다. 이것은 코드를 프로덕션 환경으로 이동하기 전에 애플리케이션을 철저히 테스트하는 가장 중요한 단계입니다.

승인 테스트가 오류없이 완료되면 클라이언트는 코드를 프로덕션 서버에 배포하고 릴리스를 계획합니다.

# 6) 유지 보수

프로덕션 서버에 애플리케이션 코드를 배포 한 후에는 클라이언트 애플리케이션에 대한 지원 / 유지 관리를 제공해야합니다. 이 유지 관리 단계는 실시간 생산 문제를 관찰 및 수정하고, 메모리 문제를 확인하고, 응용 프로그램을 개선하고, 새로운 요구 사항 변경 사항을 개발하는 것입니다.

어떤 경우에 폭포 모델을 선택할 수 있습니까?

• 필요한 변경이 없을 때.
• 프로젝트가 작고 단순 할 때.
• 기술에 복잡성이 없을 때.
• 더 많은 리소스를 사용할 수있는 경우.

폭포 프로 :

• 앞으로 뒤로 계획 및 구현이 쉽습니다. .
• 폭포 모델은 사용하기 쉽고 이해하기 쉽습니다. 프로젝트 관리자 또는 직원을위한 특별한 교육이 필요하지 않습니다. 그것은 쉬운 학습 곡선 .
• 본질적으로 단단하기 때문에 관리하기 쉬움 폭포주기. 각 단계에는 고정 된 결과물과 검토 프로세스가 있습니다.
• 덜 복잡함 단계가 겹치지 않기 때문에. 단계는 차례로 이어집니다. 다른 소프트웨어 개발 방법론과 비교할 때 명확한 구조를 사용합니다. 이 프로젝트는 요구 사항 수집부터 시작하여 고정 된 순차적 단계를 거쳐 마지막으로 유지 보수에 도달합니다.
• 단계적 개발로 인해 징계가 시행되다 , 시간 척도를 쉽게 유지할 수 있습니다.
• 공장 소규모 프로젝트에 적합 우리는 고정되고 명확한 요구 사항이 있습니다.
• 프로세스와 결과는 잘 기록 된 .
• 작업 정리는 쉽습니다.
• 그것은 진행 상황을 쉽게 측정 각 단계의 시작 및 끝 점이 미리 결정되어 있습니다.
• 프로젝트 전체에 걸쳐 요구 사항에 거의 변화가 없으므로 작업은 안정적으로 유지됩니다. 개발자를 위해. 또한 누구나 쉽게 빨리 배울 새로운 개발자 작업을 시작하십시오.
• 있습니다 재정적 놀라움 없음 . 요구 사항이 수정되면 개발을 시작하기 전에 최종 비용을 계산할 수 있습니다.
• 에 대한 음식 순차적 자금 조달 모델 .
• 이것의 상세 설계 최종 예상 결과를 모든 사람에게 매우 명확하게합니다.
• 요구 사항 수집 단계에서 문서화 된 기능 요구 사항 사양은 테스터에게 테스트 시나리오 및 테스트 사례를 설계하기에 충분한 세부 정보를 제공합니다. 따라서 테스트 프로세스가 쉬워집니다 폭포 모델에서.

폭포 단점 :

• 개발을 시작하기 전에 모든 요구 사항을 명확하게 알고 있어야하므로 프로젝트 지연 .
• 광범위한 연구가 필요합니다 사용자 요구에.
• 프로젝트의 초기 단계에서 고객은 기능 사양의 형태로 요구 사항을 명확하게 정의하고 개념화하는 것이 어렵습니다. 따라서 최종 제품을보고 마음이 바뀔 가능성이 높습니다. 이러한 변화는 사업 계획이나 시장 영향으로 인해 발생할 수도 있습니다. 이 모델의 낮은 유연성으로 인해 그러한 변화를 수용하기 어렵다 , 특히 제품을 크게 재 설계해야하는 경우.
• 작동하는 모델 없음 까지 생산됩니다 나중 폭포 수명주기 동안 단계.
• 느린 배송 시간 . 고객은 제품이 완전히 완료 될 때까지 제품을 볼 수 없습니다.
• 고객은 시스템에 미리 익숙해 질 기회가 없습니다. 폭포 모델은 내부 프로세스 과 최종 사용자를 제외합니다. .
• 그만큼 클라이언트에게 알리지 않음 프로젝트의 건전성에 대해 잘 알고 있습니다.
• 마감일을 놓칠 수 있습니다. 엄격한 관리와 정기적 인 모니터링이 유지되지 않는 경우
• 있다 변화의 여지가 없다 제품이 시장 요구 사항을 충족시키지 못하기 때문에 개발 중에 눈에 띄더라도.
• 지연 테스트 완료 될 때까지. 또한 대규모 수정은이 시점에서 비용이 많이 듭니다.
• 높은 위험과 불확실성 프로젝트가 거의 완료 될 때까지 문제가 눈에 띄지 않게 남아있을 여지가 너무 많기 때문에 폭포 모델에 관여합니다.
• 적합하지 않은 모델 길고 복잡하며 지속적인 프로젝트를 위해.
• 어렵습니다 진행 상황을 측정하다 각 단계 내에서.
• 테스터는 프로젝트의 여러 단계에서 유휴 상태로 있습니다.

애자일 워크 플로우

이제 애자일 소프트웨어 개발 수명주기를 살펴 보겠습니다. Agile은보다 정확하게 작업을 빠르고 쉽게 수행하는 프로세스입니다.

이 모델은 특히 소프트웨어 개발에 사용되는 프로젝트 관리 방법과 관련이 있습니다. 작업을 짧은 작업 단계로 나누고 계획을 자주 재평가하고 조정하는 것이 특징입니다. 각 팀원은 기본 비즈니스 흐름에 대한 아이디어를 가지고 있어야합니다.

(영상 출처 )

Agile에서는 개발자와 테스터가 병렬로 작업하여 애플리케이션 소프트웨어를 개발하고 테스트합니다. 개발은 반복 모드에서 수행됩니다. 각 반복 사용자 스토리에는 분석, 디자인, 코딩 및 테스트가 필요합니다.

요구 사항에 오류가없고 구현 가능한지 여부를 확인하기 위해 세부적인 방식으로 요구 사항을 테스트합니다. 각 반복이 끝난 후 다음 반복으로 전환하고 새로운 / 기타 요구 사항에 대해 동일한 프로세스를 따릅니다.

따라서 소프트웨어 블록을 개발하고 테스트하는이 프로세스는 더 정확하고 유연하게 짧은 시간에 수행됩니다. 그래서 더 많은 산업이이 과정을 따르고 채택합니다.

먼저 제품 소유자는 모든 요구 사항을 제품 백 로그에 추가합니다. 제품 백 로그에는 모든 사용자 스토리가 포함됩니다. 100 ~ 150 개의 사용자 스토리가 전체 프로젝트와 관련이 있다고 가정 해 보겠습니다. 이제 우리가 구현해야하는 스프린트 백 로그에 특정 사용자 스토리를 추가합니다. 그런 다음 모든 개발자, QA, BA가 스프린트 항목에 대해 작업합니다. 이것이 애자일 흐름이 작동하는 방식입니다.

Agile에서 사용되는 주요 용어

스프린트 백로 그는 무엇입니까?

인도 최고의 웹 호스팅 회사

현재 반복 또는 스프린트에서 구현해야하는 사용자 스토리 목록입니다.

예를 들어 스프린트 백 로그에는 20 ~ 30 개의 사용자 스토리가 있습니다. 다음은 현재 스프린트에서 구현해야하는 사용자 스토리입니다.

(영상 출처 )

Sprint 란 무엇입니까?

Sprint는 특정 기간 내에 선택한 사용자 스토리를 구현해야하는 짧은 기간입니다. 스프린트 기간은 약 2 ~ 3 주입니다. 기간은 회사마다 다릅니다.

이 스프린트 기간 동안 팀은 요구 사항을 분석하고, 요구 사항을 설계하고, 코딩, 테스트, 문제 수정, 재 테스트, 회귀 테스트, 데모 및 더 많은 활동을 수행해야합니다.

일일 스탠드 업 스크럼 회의

비즈니스 분석가, 개발자, 테스터, 프로젝트 관리자는 매일 스탠드 업 스크럼 회의의 일부입니다. 매일 이루어집니다. 15 ~ 30 분 이상 연장되지 않아야합니다.

여기에서 모든 팀원은 일일 작업 상태를 공유합니다. 여기서 논의하는 주요 사항은 어제 완료된 작업, 오늘 작업 계획, 프로젝트에서 직면 한 문제 또는 종속성입니다.

팀원이 프로젝트 중에 어려움이나 장애물에 직면하면 관련 담당자가 작업을 수행하여 작업을 완료합니다.

번 다운 차트

시간과 작업을 그림으로 표현한 그래프입니다. x 축은 남은 작업량을 나타내고, y 축은 남은 스프린트 시간을 나타냅니다. 팀은 특정 스프린트에서 사용 가능한 시간과 관련된 작업 작업을 만들어야합니다. 팀은 작업하고 완료 한 작업을 기반으로 매일 작업 시간을 소각합니다.

(영상 출처 )

Kanban Chart

프로젝트 관리 차트 / 도구입니다. 이를 통해 전체 프로젝트의 작업을 관리 할 수 ​​있습니다. 프로젝트 진행 상황 및 개인 작업 현황을 확인할 수 있습니다. 진행 항목, 보류 항목, 완료 항목의 그림 디지털 표현을 보여줍니다.

(영상 출처 )

온라인에서 애니메이션을 어디에서 볼 수 있습니까?

포커 활동 계획

사용자 스토리를 추정하는 스프린트 팀원 간의 게임입니다. 여기에서 전체 팀이 포커 활동을 할 것입니다. 각 팀원은 사용자 스토리 포인트를 기반으로 추정치를 제공합니다. 과반수 추정 투표에 따라 팀은 시간 슬롯을 결정하고 할당합니다.

예를 들면 , 한 명의 사용자 스토리 팀원이 3, 5, 8, 3, 1, 3과 같은 추정치를 제공합니다. 그러면 팀은 추정치로 3을 선택합니다. 포커 활동 카드에는 0, 1, 3, 5, 8, 13, 20, 100, 휴식, 의심이 있습니까? 카드. 이 팀원을 바탕으로 견적 카드를 제안합니다. 이와 같이 특정 스프린트와 관련된 모든 사용자 스토리를 추정합니다.

(영상 출처 )

• 0 포커 번호는 다음을 나타냅니다. 해당 항목 / 사용자 스토리에 작업이 없습니다.
• 1, 3 숫자는 다음을 나타냅니다. 작업이 적다
• 5, 8 숫자는 다음을 나타냅니다. 중간 수준의 작업
• 13, 20 숫자는 다음을 나타냅니다. 대규모 작업
• 100 숫자는 다음을 나타냅니다. 매우 큰 작업
• Infinity는 다음을 나타냅니다. 작업이 너무 커서 여러 작업과 사용자 스토리로 분할해야 함
• 브레이크는 다음을 나타냅니다. 쉬고 싶어
• ? 나타냅니다 : 의심

스크럼 마스터

그는 팀이 애자일 프로세스를 따르고 프로젝트 요구 사항을 충족하도록 돕는 사람입니다. 그는 필요할 때마다 회의를 진행하고 프로젝트의 필요성을 논의하는 데 도움을줍니다.

스크럼 마스터는 프로젝트에서 발생하는 문제와 종속성을 해결하기 위해 모든 팀 구성원에게 다리 역할을합니다. 그는 각 스프린트와 관련된 프로젝트 진행 상황을 추적합니다.

그는 스탠드 업 회의, 회고 회의, 검사, 검토, 데모에 참여하고 있습니다. 그는 매일 스탠드 업 미팅을 진행하고 팀원 업데이트를받는 사람입니다.

제품 소유자

그는 비즈니스 관점에서 제품 / 프로젝트를 추진하고 모니터링하는 사람입니다. 그는 제품이 비즈니스 요구 사항에 따라 개발되었는지 여부를 계속 지켜보고 있습니다. 그는 사용자 스토리의 우선 순위를 정하고 요구 사항을 제품 백 로그에서 스프린트 백 로그로 옮긴 사람입니다. 그는 프로젝트 마감일을 추정 할 것입니다.

그는 항상 사용자의 관점에서 제품을 봅니다. 제품 소유자는 응용 프로그램의 작동 방식에 대한 완전한 지식을 가지고 있습니다.

사용자 스토리

그것은 요구 사항의 블록입니다. 동일한 모듈과 관련된 사용 사례 / 요구 사항 집합이 포함되어 있습니다. 여기서 우리는 애플리케이션의 각 구성 요소가 작동하는 방식과 UI의 모양을 정의합니다. 각 구성 요소의 범위는 사용자 스토리에서 정의됩니다.

과제

팀원은 자신에게 할당 된 사용자 스토리에 대한 작업을 생성합니다. 그들은 개발 작업, 테스트 작업, 사용자 스토리 분석 작업과 같은 다양한 작업을 기반으로 작업을 생성해야합니다. 작업 기간은 사용자 스토리 포인트에 따라 달라야합니다.

테스터로서 우리는 사용자 스토리 분석, 테스트 케이스 준비, 실행, 회귀 테스트 등을위한 작업을 생성합니다.

백 로그 그루밍

이 부분에는 백 로그 항목 관리가 포함됩니다. 여기서 수행하는 활동은 백 로그 항목의 우선 순위를 지정하고, 더 작은 항목으로 나누고, 작업을 만들고, 수락 기준을 업데이트하는 것입니다.

되풀이

반복은 소프트웨어 응용 프로그램의 일부 모듈 / 부분을 개발하고 테스트하는 것입니다. 각 반복은 제품 분석, 제품 설계, 제품 개발, 제품 테스트 및 제품 데모로 구성됩니다.

애자일 방법론을 채택하는 주요 요소

• 관측: 작업과 제품을 정기적으로 검토하고 그에 따라 활동을 계획하십시오. 따라서 제품 개발 프로세스와 제품 품질이 좋을 것입니다.
• 변경 사항 환영 : 변경 사항은 매우 쉽게 처리됩니다. 소프트웨어 모듈이 별도로 개발되어 추후 통합되므로 제품에 큰 영향을주지 않습니다. 따라서 향후 요구 사항이 변경되면 재 작업이 없습니다.
• 기간 : 신청서의 각 단위에 대한 시간 프레임이 제공됩니다. 따라서 추정은 프로젝트 시간 추정에 정확할 것입니다.
• 고객 만족: 프로젝트 전반에 걸쳐 고객 및 주주와 상호 작용하고 각 제품 개발 수준에 대한 데모를 제공하기 때문에 고객 만족도가 더 높습니다. 이를 통해 비즈니스 흐름과 작업 진행 상황에 대한 고객 / 클라이언트 피드백을 정기적으로받습니다. 따라서 응용 프로그램의 작업 및 개발이 그에 따라 수행됩니다.

애자일 방법론의 유형

• 애자일 스크럼 방법론
• 린 소프트웨어 개발
• Kanban
• 익스트림 프로그래밍 (XP)
• 결정
• 동적 시스템 개발 방법 (DSDM)
• 기능 중심 개발 (FDD)

애자일 전문가 :

• 애자일 모델의 가장 큰 장점 중 하나는 뛰어난 적응성 . 적응성은 '변화에 대한 대응'을 의미합니다. Agile은 고객의 요구 사항과 우선 순위의 변화를 처리하는 데 매우 유연합니다.
• 허용 전체 제품 백 로그를 지속적으로 개선하고 우선 순위를 다시 지정합니다. 팀이 MVP 제공에 집중하고있는 현재 반복에 영향을주지 않습니다. 변경 사항은 다음 반복을 위해 계획 할 수 있으므로 몇 주 내에 변경 사항을 가져올 수있는 기회를 제공합니다.
• 애자일 방법론은 이해 관계자 참여 . 클라이언트와 프로젝트 팀은 각 스프린트 전, 도중 및 후에 만납니다. 고객이 프로젝트 전체에 지속적으로 참여하기 때문에 팀이 고객의 비전을 명확하게 이해할 수있는 기회가 더 많습니다.
• 작동하는 소프트웨어는 조기에 자주 제공됩니다. 이것은 이해 관계자의 신뢰 팀에서 팀이 매우 헌신적이다 프로젝트에.
• 이 모델은 투명도 . 이해 관계자와 팀 모두 무슨 일이 일어나고 있는지 잘 알고 있습니다. 클라이언트는 진행중인 작업을 볼 수 있습니다.
• 1 ~ 4주의 고정 일정 스프린트는 조기 및 예측 가능한 배송 . 새로운 기능은 타임 박스 방식으로 빠르고 자주 출시됩니다.
• 애자일은 고객 중심의 . 기능을 제공 할뿐만 아니라 사용자에게 가치있는 기능을 제공하는 데에도 초점을 맞 춥니 다. 각 사용자 스토리에는 비즈니스 중심의 수락 기준이 있습니다.
• 가치 있는 고객 피드백 얻는다 이른 프로젝트에서 필요에 따라 제품을 변경할 수 있습니다.
• 비즈니스 가치에 중점을 둡니다. . 먼저 고객에게 가장 중요한 것을 전달합니다.
• 결과물의 품질 향상 . 폭포수와 달리 테스트는 Agile 프로젝트에서 지속적으로 자주 수행되므로 문제를 조기에 발견하고 수정하는 데 도움이됩니다.
• 기민한 TDD (Test Driven Development) 접근 방식 지원 MVP를 통해 출시 될 기능에 대한 단위 테스트를 만들 수있는 충분한 시간을 제공합니다.
• 또한 빈번한 빌드 , 고객 요구 사항과의 불일치도 조기에 감지하고 수정할 수 있습니다.
• 우리가 얻는대로 즉각적인 사용자 피드백 각 MVP 출시 후 프로젝트 실패 위험이 낮고 애자일 방식으로 작업 할 때.
• 기민한 팀워크를 촉진 . 애자일 팀원들 사이에는 훌륭한 협업, 상호 작용, 조화 및 열정이 있습니다.
• 각 스프린트의 비용 및 일정 추정치는 스프린트 시작 전에 클라이언트에게 전달됩니다. 이 의사 결정 향상 사용자는 각 기능의 비용을 이해하고 그에 따라 우선 순위를 지정할 수 있습니다.
• 애자일 프로젝트에는 지속적인 개선 . 과거 스프린트에서 배운 교훈을 다음 스프린트에 적용 할 수 있습니다.
• 프로젝트의 모든 단계에서 특정 작업에 중점을 둡니다.

애자일 단점 :

• 애자일 팀은 문서를 무시하는 경향 . 이는 Agile 선언문이 포괄적 인 문서보다 작업 소프트웨어에 더 초점을 맞추기 때문입니다. 그러나 팀은 코드와 문서간에 적절한 균형을 유지해야합니다.
• 높은 수준의 고객 참여가 필요하므로 때때로 고객에게 문제가 됨 프로젝트에 참여할 시간과 관심이별로없는 분
• 팀에 헌신과 헌신이 부족하면 잘 작동하지 않습니다. Waterfall은 참여가 필요하지만 Agile은 헌신이 필요합니다.
• 초기 아키텍처와 디자인이 약하면 빈번한 리팩토링 필수입니다.
• 폭포와 비교할 때 Agile은 연습하기 어렵다 . 팀원은 Agile 개념에 정통해야합니다. 애자일을 연습하려면 많은 규율과 헌신이 필요합니다.
• 우선 순위 재 지정으로 인해 덜 예측 가능 스프린트가 끝날 때 전달되는 것보다
• 타임 박스 전달 및 빈번한 우선 순위 재 지정으로 인해 일부 기능이 할당 된 타임 라인에 전달되지 않을 가능성이 있습니다. 이것은 추가 스프린트 및 추가 비용 . 이것은 또한 문제로 이어질 수 있습니다 모호한 타임 라인 .
• 폭포와 비교할 때 구조가 부족합니다. 자제력이 있고 능숙하며 숙련 된 팀이 필요합니다. . 이것이 없으면 프로젝트는 정말 어려운 일이 될 수 있습니다.
• 가용성은 최종 결과물의 청사진 감소 .
• 때때로 외부 이해 관계자는 애자일 접근 방식을 따르지 않을 수 없습니다. . 이러한 경우 광범위한 청중에게 Agile에 대한 교육 및 교육이 필요합니다.
• 모든 팀원은 프로젝트 관리에 참여해야합니다.
• 문서가 덜 상세합니다.

애자일 대 폭포수 모델의 차이점

Waterfall과 Agile Software Development Life Cycles의 차이점은 다음과 같습니다.

폭포	기민한
프로세스는 하나의 단일 프로젝트로 처리되며 다른 단계로 더 나뉩니다.	프로세스는 여러 프로젝트로 나뉘며 각 프로젝트에는 서로 다른 단계의 반복이 있습니다.
폭포수 방법론은 제품 수명주기의 각 단계가 순서대로 발생하는 모델입니다. 프로젝트의 진행은 폭포를 닮은 이러한 단계를 통해 점차적으로 아래로 흐릅니다.	애자일 방법론은 반복적 인 접근 방식을 따르는 모델입니다.
이 모델은 일회성 대규모 전체 배송을 믿습니다. 제품은 SDLC가 끝날 때 배송됩니다.	이 모델은 정의 된 시간 간격으로 여러 개의 작은 배달 청크를 믿습니다. MVP (최소 실행 가능한 제품)는 각 스프린트가 끝날 때 제공됩니다.
전통적이고 구식 접근 방식입니다.	새롭고 현대적인 접근 방식입니다.
단일주기 및 단일 릴리스.	반복되는 반복 횟수 및 여러 릴리스.
소프트웨어 개발 라이프 사이클을 여러 단계로 나눕니다.	소프트웨어 개발 라이프 사이클을 스프린트로 나눕니다.
구조화되고 견고한 모델. 프로젝트의 설명, 사양 및 디자인을 변경하는 것은 어렵습니다.	이 모델은 유연성으로 유명합니다. 프로젝트 단계에서 언제든지 변경할 수 있습니다.
장기 계획 규모.	단기 계획 규모.
고객과 개발자 사이에는 먼 거리가 존재합니다.	고객과 개발자 사이에 짧은 거리가 있습니다.
사양과 구현 사이에 오랜 시간이 걸립니다. 비즈니스 분석가는 프로젝트 시작 전에 요구 사항을 수집하고 준비합니다.	사양과 구현 사이의 짧은 시간. 제품 소유자는 각 스프린트에서 팀에 대한 요구 사항 및 업데이트를 준비합니다.
문제를 발견하는 데 오랜 시간이 걸립니다.	문제는 빠르게 발견됩니다.
프로젝트 일정 위험이 높습니다.	낮은 프로젝트 일정 위험.
변화에 신속하게 대응하는 능력이 떨어집니다.	변화에 빠르게 대응하는 높은 능력.
테스트 단계는 개발 단계가 완료된 후에 만 ​​발생합니다.	테스트는 일반적으로 품질을 지속적으로 보장하기 위해 개발과 병행하여 수행됩니다.
고객은 요구 사항 수집 단계에서만 관여하며 그 이후에는 고객이 관여하지 않습니다. 그는 제품 배송 당시에 만 그림에 등장합니다.	고객은 프로젝트 전체에 참여하고 고객 만족을 보장하기 위해 수시로 고객으로부터 피드백을받습니다.
명확하게 정의 된 요구 사항이있는 프로젝트와 변경이 예상되지 않는 프로젝트에 적합합니다.	진화해야하는 프로젝트와 변화하는 요구 사항을 수반하는 프로젝트에 적합합니다.
엄격하게 순차적 인 프로세스.	고도로 협력적인 소프트웨어 개발 프로세스는 더 나은 팀 노력과 신속한 문제 해결로 이어집니다.
프로젝트 사고 방식을 보여줍니다.	제품 마인드를 도입하여보다 고객 중심적입니다. 요구와 변화는 과정의 일부입니다
공식 및 계층. 프로젝트 관리자는 의사 결정자입니다.	비공식적입니다. 전체 팀이 의사 결정을 담당합니다.
이 모델은 프로젝트 전체에 걸쳐 요구 사항에 변화가 없을 것으로 예상합니다.	이 모델은 적응을 기반으로하며 변화를 수용합니다.
개인의 작업 및 프로젝트 진행 상태를 확인하기 위해 수동 문서를 만들어야합니다.	Kanban 차트 및 Burn Down 차트를 따라 프로젝트 진행 상황과 개인의 작업 상태를 확인합니다.

우리는 Agile & Waterfall 방법론의 차이점과 각각의 이점 및 과제에 대해 충분히 논의했습니다. 이제 애자일 테스트와 폭포 테스트의 차이점을 살펴 보겠습니다.

애자일 테스트와 폭포 테스트의 차이점

소프트웨어 테스트의 관점에서 애자일 테스트가 Waterfall 테스트와 어떻게 다른지에 대한 공정한 아이디어를 갖는 것이 중요합니다.

결론

이 기사에서는 각 모델의 장단점을 포함하는 비교표를 사용하여 최신 Agile 접근 방식과 소프트웨어 개발 및 테스트의 기존 Waterfall 방법 간의 정확한 차이점을 배웠습니다.

이 기사에 나열된 모든 요소를 ​​고려하여 소프트웨어 애플리케이션을 개발하기위한 올바른 소프트웨어 개발 라이프 사이클 모델을 선택할 수 있습니다. 애자일 방법론이 Waterfall 모델보다 선호된다는 것은 의심 할 여지가 없습니다. 90 %의 기업이 소프트웨어 애플리케이션을 개발하기 위해 Agile 워크 플로우를 선호하고 따릅니다.

애자일 방법론은 모든 종류의 프로젝트에 적합합니다. 폭포수 방법론을 따르는 회사는 거의 없습니다. 이 방법론은 응용 프로그램이 작고 단순하며 요구 사항에 변화가없는 경우에만 적합합니다.

어떤 경우에는 필요에 따라 Spiral, V 및 V, Prototype이라는 다른 접근 방식을 선택하기도합니다.

이 정보가 프로젝트에 가장 적합한 모델을 결정하는 데 도움이되기를 바랍니다. 당신은 또한 갈 수 있습니다 각 방법의 단점을 제거하는 하이브리드 모델 – 여기서 설명합니다.

추천 도서

• 사례 연구 : 하이브리드 모델을 사용하여 폭포수 및 애자일 개발 프로세스의 결함을 제거하는 방법
• SDLC 폭포 모델이란 무엇입니까?
• Zephyr 엔터프라이즈 테스트 관리 도구 검토-Agile 도구에서 폭포 모델 자산을 사용하는 방법
• VersionOne 자습서 : 올인원 민첩한 프로젝트 관리 도구 가이드
• Jira 포트폴리오 자습서 : JIRA 용 애자일 프로젝트 포트폴리오 관리 플러그인 (검토)
• 2021 년 최고의 애자일 프로젝트 관리 도구 TOP 10
• 애자일 추정 기법 : 애자일 프로젝트의 진정한 추정
• 애자일 프로세스로의 성공적인 전환을위한 애자일 테스트 마인드를 개발하기위한 4 단계