애자일 개발 방법론 - 애자일

애자일 모델

Flexible(Agile) 방법론은 워크플로를 여러 개의 작은 주기로 이동하여 소프트웨어 개발의 위험을 줄이는 데 도움이 됩니다. 이러한 주기를 반복이라고 하며 일반적으로 2~3주 동안 지속됩니다.

반복은 각각의 기능을 향상시키는 작업으로 구성된 작은 소프트웨어 프로젝트와 같습니다. 여기에는 계획 작성, 요구 사항 평가, 프로젝트 동의, 코드 작성, 테스트 및 기술 문서 작성이 포함됩니다.

완전한 소프트웨어 릴리스에는 일반적으로 한 번의 반복만으로는 충분하지 않습니다. 그러나 애자일의 좋은 점은 프로젝트의 작은 부분이 각 반복이 끝날 때마다 평가할 준비가 되어 있다는 것입니다. 이를 통해 팀 구성원은 최종 릴리스를 기다리지 않고 추가 작업의 우선 순위를 변경할 수 있습니다.

"민첩한" 개발 방법론을 적용하면 각 반복 후에 구체적인 결과를 볼 수 있습니다. 즉, 개발자는 작업 결과가 요구 사항을 충족하는지 여부를 이해할 수 있습니다. 이것은 유연한 모델의 중요한 장점 중 하나입니다.

단점은 Agile을 사용할 때 인건비와 프로젝트 예산을 추정하기 어려운 경우가 있습니다. 유연한 모델의 실제 적용을 위한 옵션을 선택하면 그 중 가장 유명한 것이 XP(Extreme Programming)입니다.

XP는 매일 진행되는 팀원들의 간단한 회의와 정기 회의(주 1회 이하)를 기준으로 합니다. 데일리 랠리(데일리 스탠드업)에서 일반적으로 논의되는 내용은 다음과 같습니다.

• 현재 작업 결과;
• 각 팀원이 완료해야 할 작업 목록
• 발생하는 어려움과 해결 방법.

선언서

Agile은 개발의 전체 방향이므로 이에 대한 작업 규칙은 Agile Manifesto라는 특별 문서에 선언되어 있습니다. 여기에는 팀이 작업해야 하는 관행과 원칙이 모두 포함됩니다.

Agile Manifesto는 4가지 기본 아이디어와 12가지 원칙으로 구성되어 있습니다.

핵심 아이디어:

• 개발자 간의 협업이 도구보다 더 중요합니다.
• 제품의 작업 버전이 설명서보다 우선합니다.
• 팀과 고객 간의 상호 이해가 계약 조건보다 더 중요합니다.
• 원래 계획은 필요한 경우 언제든지 변경할 수 있습니다.

Agile의 12가지 원칙은 다음과 같습니다.

• 주요 우선 순위는 완성된 프로그램이 고객의 기대에 부합하는 것입니다.
• 조건 변경은 개발의 최종 단계에서도 모든 단계에서 허용됩니다(소프트웨어의 품질과 경쟁력을 향상시킬 수 있는 경우).
• 소프트웨어 제품의 작업 버전 정기 배송(매 14일, 월 또는 분기별)
• 성공의 열쇠는 고객과 개발자 간의 정기적인 상호 작용입니다(가급적 매일).
• 프로젝트는 관심있는 사람들 사이에서 구축되어야 하며, 그러한 사람들에게는 작업에 필요한 조건과 모든 종류의 지원이 제공되어야 합니다.
• 팀에서 정보를 공유하는 가장 좋은 방법은 개인 회의입니다.
• 소프트웨어의 작동 버전은 진행 상태를 가장 잘 나타내는 지표입니다.
• 모든 이해 관계자는 소프트웨어 개발 프로세스 전반에 걸쳐 원하는 작업 속도를 유지할 수 있어야 합니다.
• 기술 개선 및 좋은 디자인은 유연성을 향상시킵니다.
• 단순하게 유지하고 과도하게 만들지 않는 것이 중요합니다.
• 스스로 조직할 수 있는 팀에서 최상의 결과를 얻을 수 있습니다.
• 팀 구성원은 작업 흐름을 변경하여 효율성을 개선하는 방법에 대해 정기적으로 생각해야 합니다.

애자일 선언문에 따르면 좋은 소프트웨어 개발 프로세스는 이 프로세스에 참여하는 사람들에게 직접적으로 달려 있습니다. 이렇게 하려면 가능한 한 효율적으로 상호 작용을 구성하고 가장 조직적인 팀을 만들어야 합니다.

방법론

Agile Manifesto에는 가치와 원칙을 설명하는 몇 가지 방법론도 있습니다.

• 애자일 모델링;
• 민첩한 통합 프로세스;
• 민첩한 데이터 방법
• 신속한 애플리케이션 개발(DSDM)
• 필수 통합 프로세스;
• 익스트림 프로그래밍;
• 기능 중심 개발;
• 현실화;
• 오픈업;
• 스크럼.

애자일 모델링은 소프트웨어 모델 및 문서의 개발 속도를 높이고 단순화하는 원칙, 용어 및 관행의 모음입니다.

Agile Modeling의 목표는 모델링 및 문서화를 개선하는 것입니다. 여기에는 코딩, 테스트 또는 프로젝트 제어, 배포 및 지원과 관련된 문제가 포함되지 않는다는 점에 유의해야 합니다. 그러나 이 방법론에는 코드 검토가 포함됩니다.

Agile Unified Process는 사용자가 쉽게 근사(모형)할 수 있도록 하는 방법론입니다. 일반적으로 상용 소프트웨어를 개발하는 데 사용됩니다.

민첩한 데이터 방법 - 여러 팀의 협력을 통해 고객 조건을 달성하는 몇 가지 유사한 방법론.

DSDM - 이 접근 방식은 개발자와 함께 미래 제품 사용자가 적극적으로 참여한다는 점에서 다른 접근 방식과 다릅니다.

기능 중심 개발은 시간 제한이 있는 개발 방법론입니다. "각 기능은 2주 이상 구현되지 않아야 합니다."

사용 사례가 작으면 기능으로 간주할 수 있다는 점을 고려해 볼 가치가 있습니다. 중요한 경우 여러 기능으로 나누어야 합니다.

Getting Real은 프로그램 인터페이스를 먼저 개발한 다음 기능을 개발하는 반복적인 방법론입니다.

OpenUP은 프로젝트 주기를 Inception, Refinement, Construction, Handover의 4단계로 나누는 개발 방식입니다.

Agile의 원칙에 따르면 작업 기간에 관계없이 모든 이해 관계자와 팀 구성원이 서로를 알아가고 의사 결정을 내릴 수 있는 방법을 제공해야 합니다. 덕분에 상황을 효과적으로 제어하고 중간 결과를 적시에 평가할 수 있습니다. 프로젝트 계획은 수명 주기를 정의하며 최종 결과는 애플리케이션의 안정적인 릴리스로 간주되어야 합니다.

Scrum의 경우 개발 프로세스 관리 규칙을 규제하고 조건을 조정하거나 변경할 가능성이 있는 기존 코딩 관행을 적용할 수 있습니다. 이 방법론을 사용하면 개발 초기 단계에서 예상 결과의 편차를 확인하고 제거할 수 있습니다.

이를 조금 더 자세히 살펴보자면...