Agile 개발이란?

Agile 개발은 반복적인 소프트웨어 개발을 설명하는 데 사용되는 용어입니다. 반복 소프트웨어 개발은 일반적으로 스프린트라고 하는 짧은 단위로 작업을 완료하여 DevOps 수명 주기를 단축합니다. 스프린트는 일반적으로 1~4주 길이입니다. 민첩한 개발은 대규모 프로젝트를 미리 계획하고 계획에 따라 완료하는 기존 또는 폭포 개발과 대조되는 경우가 많습니다.

모든 스프린트에서 프로덕션 품질 코드를 제공하려면 Agile 개발 팀이 가속화된 속도를 고려해야 합니다. 각 스프린트마다 모든 코딩, 테스트 및 품질 검증을 수행해야 합니다. 팀이 제대로 설정되지 않는 한 결과는 기대에 미치지 못할 수 있습니다. 이러한 실망은 훌륭한 학습 기회를 제공하지만 시작하기 전에 몇 가지 주요 교훈을 배우는 것이 유용합니다.

이 문서에서는 Agile 개발 팀의 몇 가지 주요 성공 요소를 설명합니다.

• 부지런한 백로그 구체화
• 초기 및 자주 통합
• 기술 부채 최소화

부지런한 백로그 구체화

Agile 개발 팀은 종종 사용자 스토리라고 하는 요구 사항의 백로그에서 작동합니다. 가장 중요한 사용자 스토리가 맨 위에 있는 백로그의 우선 순위가 지정됩니다. 제품 소유자는 백로그를 소유하며 고객의 요구에 따라 사용자 스토리를 추가 및 변경하고 우선 순위를 다시 지정합니다.

Agile 팀의 생산성에서 가장 큰 걸림돌 중 하나는 잘못 정의된 백로그입니다. 팀이 요구 사항을 명확하게 정의하지 않는 한 각 스프린트마다 고품질 소프트웨어를 일관되게 제공할 것으로 예상할 수 없습니다.

제품 소유자의 작업은 모든 스프린트, 엔지니어가 작업할 사용자 스토리를 명확하게 정의하도록 하는 것입니다. 백로그 맨 위에 있는 사용자 스토리는 항상 팀이 시작할 준비가 되어 있어야 합니다. 이 개념을 백로그 구체화라고 합니다. Agile 개발 팀을 위해 백로그를 준비하려면 노력과 훈련이 필요합니다. 다행히도 투자할 만한 가치가 있습니다.

백로그를 구체화할 때는 다음 주요 고려 사항을 기억하세요.

1. 사용자 스토리를 구체화하는 것은 종종 긴 잠재 고객 활동입니다. 우아한 사용자 인터페이스, 아름다운 화면 디자인 및 고객 만족 솔루션은 모두 만드는 데 시간과 에너지가 소요됩니다. 부지런한 제품 소유자는 2~3개의 스프린트를 미리 사용자 스토리를 구체화합니다. 디자인 반복 및 고객 검토를 고려합니다. 모든 사용자 스토리가 Agile 팀이 고객에게 제공하는 것을 자랑스럽게 생각합니다.

2. 사용자 스토리는 팀이 말하지 않는 한 구체화되지 않습니다. 팀은 사용자 스토리를 검토하고 작업할 준비가 됨에 동의해야 합니다. 팀이 스프린트 첫날까지 사용자 스토리를 볼 수 없는 경우 문제가 발생할 수 있습니다.

3. 백로그의 사용자 스토리는 모호하지 기본 수 있습니다. 우선 순위가 낮은 항목을 구체화하는 데 시간을 낭비하지 마세요. 백로그 맨 위에 집중합니다.

초기 및 자주 통합

CI/CD(지속적인 통합 및 지속적인 업데이트 )는 Agile 개발의 빠른 속도를 위해 팀을 설정합니다. 가능한 한 빨리 빌드, 테스트 및 배포 파이프라인을 자동화합니다. 새 프로젝트를 시작할 때 팀에서 수행하는 첫 번째 작업 중 하나로 해당 자동화를 설정합니다.

자동화를 통해 팀은 느리고 오류가 발생하기 쉽고 시간이 많이 걸리는 수동 배포 프로세스를 방지합니다. 팀은 모든 스프린트를 릴리스하므로 이러한 작업을 수동으로 수행할 시간이 없습니다.

CI/CD는 소프트웨어 아키텍처에도 영향을 줍니다. 이를 통해 빌드 가능하고 배포 가능한 소프트웨어를 제공할 수 있습니다. 팀은 배포하기 어려운 기능을 구현할 때 빌드 및 배포가 실패하면 즉시 알게 됩니다. CI/CD는 팀이 배포 문제가 발생할 때 이를 해결하도록 강제합니다. 그러면 제품이 항상 배송할 준비가 된 것입니다.

효과적인 Agile 개발에 매우 중요한 몇 가지 주요 CI/CD 활동이 있습니다.

1. 단위 테스트. 단위 테스트는 사람의 실수에 대한 첫 번째 방어입니다. 단위 테스트는 코딩의 일부로 고려합니다. 코드를 사용하여 테스트를 체크 인합니다. 단위 테스트를 모든 빌드의 일부로 만듭니다. 실패한 단위 테스트는 실패한 빌드를 의미합니다.

2. 빌드 자동화. 빌드 시스템은 빌드가 실행되면 소스 제어에서 직접 코드 및 테스트를 자동으로 끌어와야 합니다.

3. 분기 및 빌드 정책. 팀이 특정 분기에 코드를 검사 때 자동으로 빌드되도록 분기 및 빌드 정책을 구성합니다.

4. 환경에 배포합니다. 프로덕션을 모방하는 환경에 빌드된 프로젝트를 자동으로 배포하는 릴리스 파이프라인을 설정합니다.

기술 부채 최소화

개인 재정으로, 그 아래에서 발굴하는 것보다 부채에서 유지하는 것이 더 쉽습니다. 기술적인 문제로도 동일한 규칙이 적용됩니다. 기술적인 부채에는 이전에 수행된 바로 가기 때문에 팀에서 해결해야 하는 모든 것이 포함됩니다. 예를 들어 일정이 촉박한 경우 기한을 맞추기 위해 품질을 희생할 수 있습니다. 기술적인 문제는 품질 부족을 만회하기 위해 코드를 리팩터링해야 할 때 나중에 지불하는 가격입니다. 예를 들어 잘못된 디자인, 버그, 성능 문제, 운영 문제, 접근성 문제 및 기타 문제를 해결하기 위한 수정 사항이 있습니다.

기술적 부채를 계속 유지하려면 용기가 필요합니다. 코드 재작업을 지연해야 하는 많은 압박이 있습니다. 기능을 작업하고 부채를 무시하는 것이 좋습니다. 불행히도, 누군가는 조만간 기술적인 부채를 갚아야 합니다. 금융 부채와 마찬가지로 기술 부채는 더 오래 갚기 어려워집니다. 스마트 제품 소유자는 팀과 협력하여 스프린트마다 기술 부채를 갚을 시간이 있는지 확인합니다. 기술 부채 감소와 기능 개발의 균형을 맞추는 것은 어려운 작업입니다. 다행히도 생산적이고 고객 중심적인 팀을 만들기 위한 몇 가지 간단한 기술이 있습니다.

항상 Agile

Agile이 된다는 것은 경험에서 배우고 지속적으로 개선한다는 것을 의미합니다. 민첩한 개발은 더 엄격한 프로세스 루프로 인해 기존 프로젝트 계획보다 더 많은 학습 주기를 제공합니다. 각 스프린트는 팀이 배울 수 있는 새로운 기능을 제공합니다.

예시:

• 팀은 고객에게 가치를 제공하고 피드백을 가져온 다음 해당 피드백에 따라 백로그를 수정합니다.
• 자동화된 빌드에 주요 테스트가 누락된 것을 알아봅니다. 이 문제를 해결하기 위해 다음 스프린트에 작업을 포함합니다.
• 특정 기능은 프로덕션에서 성능이 저하되므로 성능 향상을 위한 계획을 수립합니다.
• 팀의 누군가가 새로운 연습을 듣습니다. 팀은 몇 가지 스프린트를 위해 그것을 시도하기로 결정합니다.

Agile 개발을 시작한 팀은 더 많은 학습 기회를 기대해야 합니다. 그들은 성장과 개선으로 이어지기 때문에 프로세스의 귀중한 부분입니다.

다음 단계

팀에 적합한 Agile 개발 프로세스에 정착하는 방법에는 여러 가지가 있습니다. Azure DevOps는 다양한 프로세스 템플릿을 제공합니다. 계획과 다른 기준 구조를 찾고 있는 팀은 이러한 템플릿을 시작점으로 사용할 수 있습니다. 팀의 문화권과 목표에 가장 적합한 프로세스 템플릿을 선택하는 방법에 대한 자세한 내용은 Azure Boards에서 작업할 프로세스 흐름 또는 프로세스 템플릿 선택을 참조 하세요.

조직이 성장함에 따라 징계를 유지하는 것이 어려울 수 있습니다. Agile을 대규모 팀으로 확장하는 방법에 대해 자세히 알아봅니다.