Week 3 - Agile Software Development

1. 애자일 메소드의 배경

• 신속한 소프트웨어 개발과 전달이 소프트웨어 시스템에서 가장 중요한 요구 사항.
• 빠르게 변화하는 요구 사항에 맞춰 신속한 개발과 전달 필요.

• 계획 기반 개발은 이러한 비즈니스 요구에 대응하기 어려움. 더 나쁘다는 건 아님.

• 애자일 개발 방법론은 1990년대 후반에 등장하여 소프트웨어 시스템의 인도 시간을 크게 단축하려는 목표로 개발됨.

1-1. 애자일 개발

• 프로그램 명세, 설계, 구현이 교차되어 연속적으로 진행됨.

• 시스템은 여러 버전이나 단계적 증분으로 개발되며, 이해 관계자가 참여하여 명세 및 평가.

• 자주 새 버전을 인도하고 평가받음.

• 포괄적인 도구 지원을 통해 개발을 지원.

• 문서화 최소화, 코드 작동에 집중.

1-2. 계획 기반 개발과 애자일 개발

• 계획 기반 개발은 각 개발 단계를 미리 계획하고 그에 따른 산출물을 생산하는 방식.
• 워터폴 모델일 필요는 없으며, 단계적 개발도 가능.
• 활동 내에서 반복이 발생할 수 있음.

• 애자일 개발은 명세, 설계, 구현, 테스트가 유기적으로 교차하여 진행.

• 개발 과정에서 산출물은 협상 과정을 통해 결정됨.

2. 애자일 메소드

• 애자일 방법론의 탄생 배경: 1980년대와 1990년대의 소프트웨어 설계 방법에 포함된 많은 오버헤드에 대한 불만으로 인해 탄생.

• 애자일 방법론의 특징
1. 코드에 집중: 설계보다 코드 작성에 초점을 맞춘다.
2. 반복적 접근법: 소프트웨어 개발이 반복적 접근을 기반으로 이루어진다.
3. 빠른 제공과 진화: 빠르게 동작하는 소프트웨어를 제공하고, 변화하는 요구사항에 맞춰 빠르게 진화시킨다.

• 애자일 방법론의 목표
1. 오버헤드 감소: 문서화를 줄임으로써 소프트웨어 프로세스에서의 오버헤드를 감소.
2. 빠른 대응: 변화하는 요구사항에 과도한 재작업 없이 신속하게 대응할 수 있다.

2-1. 애자일 방법론의 원칙

• 고객의 참여 (Customer involvement): 고객은 개발 과정 전반에 걸쳐 참여해야 하며, 시스템 요구 사항을 제공하고 우선순위를 정해 각 반복 단계에서 시스템을 평가해야 한다.

• 점증적 인도 (Incremental delivery): 소프트웨어는 작은 증분으로 개발되며, 각 증분에서 고객이 포함할 요구 사항을 명시하고 반영해야 한다.

• 변화의 수용 (Embrace change): 시스템 요구 사항의 변화를 예상하고, 변화에 유연하게 대응할 수 있도록 시스템을 설계해야 한다.

• 단순성 유지 (Maintain simplicity): 소프트웨어 개발과정에서 단순성을 중시하며, 복잡성을 줄이기 위해 지속적으로 노력해야 한다.

• 사람이 중심 (People not process): 팀원의 능력을 최대한 발휘할 수 있도록 하고, 정해진 절차나 프로세스에 얽매이지 않도록 해야 한다.

📌 애자일 적용가능 분야

• 제품 개발 (Product development): 소규모 또는 중간 규모의 제품을 개발할 때 애자일 접근 방식이 적합하다. 현재 대부분의 소프트웨어 제품은 애자일 방식을 사용한다.

• 조직 내 맞춤형 시스템 개발 (Custom system development): 고객이 개발 과정에 적극적으로 참여하고, 외부 규제나 규칙이 거의 없는 환경에서 애자일 방식을 적용할 수 있다.

3. Agile development techniques : XP programming

• XP 프로그래밍 (Extreme Programming): 1990년대 후반에 개발된 중요한 애자일 방법론 중 하나로, 여러 애자일 개발 기법을 소개한다.

• XP의 극단적 접근: 반복적인 개발에 극단적으로 접근하여 하루에도 여러 번 새로운 버전을 빌드하고, 2주마다 기능 증분을 고객에게 인도. 모든 빌드는 성공적인 테스트를 거쳐야만 수용됨.

• 2주마다 진행되는 사이클로, 사용자 스토리 선정 -> 스토리 작업 분할 -> 릴리스 계획 -> 개발, 통합, 테스트 -> 릴리스 -> 시스템 평가의 과정을 거침.

2-1. Extreme Programming

• Incremental Planning (점진적 계획): 요구사항은 스토리 카드에 기록되며, 개발 팀은 이를 작업으로 분할.

• Small Release (소규모 릴리즈): 비즈니스 가치를 제공하는 최소 기능 세트를 먼저 개발하고, 이후 릴리즈를 통해 점진적으로 기능을 추가함.

• Simple Desing (단순 설계): 현재 요구 사항을 충족할 수 있을 정도로만 설계.

• Test-first development (테스트 우선 개발): 기능 구현 전에 자동화된 테스트 케이스를 먼저 작성.
Story → Test-case → Develop

• Refactoring (리팩토링): 코드 개선이 필요한 부분이 발견되면 지속적으로 리팩토링을 수행하여 코드를 유지보수 가능하게 만듦.

• Pair Programming (짝 프로그래밍): 개발자는 짝을 이루어 서로의 작업을 검토하고 지원.

• Collective ownership (공동 소유권): 개발자는 시스템 전체를 다루며, 누구나 코드를 수정할 수 있음.

• Continuous intergration (연속적 통합): 작업이 완료되면 즉시 시스템에 통합되며, 모든 유닛 테스트가 성공해야 함. 계속 증분하므로.

• Substainable pace (지속 가능한 속도): 지나친 초과 근무는 코드 품질을 떨어뜨리고 생산성을 저하시킴.

• On-site customer (고객의 참여): 고객은 개발 팀의 일원으로 요구 사항을 제시하는 역할을 담당함.

💡 에자일과 XP 원칙

• Incremental development (점진적 개발): 작은 릴리즈를 통해 자주 시스템을 인도.

• 고객의 참여: 고객은 개발 팀의 일원으로 상시 참여.

• 사람 중심: 짝 프로그래밍, 공동 소유권 등을 통해 장시간 근무를 피함.

• 변화의 수용: 정기적인 릴리즈를 통해 변화에 대응.

• 단순성 유지: 지속적인 리팩토링을 통해 단순성을 유지.

📌 XP의 주요 관행

• XP는 기술적 관점에서 주로 사용되며, 조직의 관리 관행과 통합하기 어려운 면이 있다. 주요 관행으로는 사용자 스토리 작성, 리팩토링, 테스트 우선 개발, 짝 프로그래밍이 있다.

• 요구 사항을 위한 사용자 스토리
• XP에서는 고객이 요구 사항 결정에 참여하며, 요구 사항은 사용자 스토리나 시나리오로 표현된다. 개발 팀은 이를 작업 단위로 분할하고, 이를 토대로 일정과 비용을 추정한다.

2-2. XP의 Refactoring

• 소프트웨어 공학의 전통적인 지혜는 변화를 위한 설계를 강조하지만, XP에서는 이러한 변화 예측이 신뢰할 수 없다고 본다.

• 대신, 코드의 지속적인 개선(리팩토링)을 통해 변화가 필요할 때 쉽게 구현할 수 있도록 한다.

• 프로그래밍 팀은 즉각적인 필요가 없더라도 가능한 소프트웨어 개선점을 찾고 이를 구현한다.

• 이는 소프트웨어의 이해도를 높이고 문서화 필요성을 줄인다.

• 코드가 잘 구조화되어 있어야 변경이 용이하며, 경우에 따라 아키텍처 리팩토링이 필요할 수 있다.

• Refactoring 예시
• 중복 코드를 제거하기 위한 클래스 계층 구조 재조정.
• 속성과 메서드의 정리 및 이름 변경.
• 인라인 코드를 라이브러리 메서드 호출로 대체.

2-3. Test Development

• XP에서 테스트는 모든 변경 후에 실행되며, 자동화된 테스트 하네스를 사용해 모든 컴포넌트 테스트를 수행한다.

• 코드를 작성하기 전에 테스트를 작성하여 구현해야 할 요구 사항을 명확하게 한다.

• 모든 새로운 기능이 추가될 때마다 이전 및 새로운 테스트가 자동으로 실행되어 오류를 즉시 감지할 수 있다.

• 고객은 수용 테스트 개발에 참여하며, 새로운 코드가 요구 사항을 충족하는지 확인한다.

• 그러나 고객의 시간이 제한되어 있어 팀과 풀타임으로 일하기 어려울 수 있다.

• 테스트는 실행 가능한 컴포넌트로 작성되며, 테스트 자동화는 새로운 코드가 도입될 때마다 즉시 실행되고 오류를 감지할 수 있다.
번역
테스트 자동화는 테스트가 실행 가능한 구성 요소로 작성된다는 의미입니다. 실행 가능한 구성 요소로 작성하는 것을 의미합니다.
• 이러한 테스트 구성 요소는 독립형이어야 하며, 테스트할 입력의 제출을 시뮬레이션하고 결과가 출력 사양을 충족하는지 확인해야 합니다.
• 자동화된 테스트 프레임워크(예: JUnit)는 실행 가능한 테스트를 쉽게 작성하고 실행을 위해 테스트 세트를 제출할 수 있는 시스템입니다. 테스트가 자동화되면 항상 빠르고 쉽게 실행할 수 있는 테스트 세트가 있습니다.
• 시스템에 기능이 추가될 때마다 테스트를 실행하여 새로운 코드로 인해 발생한 문제를 즉시 파악할 수 있습니다.

📌 테스트 우선 개발의 문제점

• 일부 프로그래머는 테스트를 작성할 때 지름길을 택하며, 일부 테스트는 점진적으로 작성하기 어렵다.

• 테스트 집합의 완전성을 판단하기 어렵다.

2-4. Pair Programming

• 이는 코드의 공동 소유권을 발달시키고, 팀 내 지식을 확산하는 데 도움이 된다.

• 또한, 비공식적인 리뷰 과정 역할을 하여 코드의 품질을 높인다.

• 짝 프로그래밍은 리팩토링을 장려하며, 팀 전체가 코드 개선의 혜택을 볼 수 있다.

• 짝 프로그래밍에서는 두 사람이 같은 컴퓨터에서 함께 소프트웨어를 개발한다.

• 팀원들이 서로 작업할 수 있도록 짝이 동적으로 만들어지며, 지식 공유는 프로젝트 리스크를 줄인다.

• 일부 연구에 따르면 짝으로 일하는 것이 더 효율적일 수 있지만, 고급 프로그래머끼리 짝을 이루면 비효율적일 수 있다.

3. Agile 프로젝트 관리 : Scrum

• 소프트웨어 프로젝트 관리자의 주요 책임:
→ 소프트웨어가 정해진 시간 안에, 계획된 예산 내에서 인도되도록 프로젝트를 관리하는 것.

• 표준적인 프로젝트 관리 접근 방식은 Plan-Driven.

• 관리자는 프로젝트의 인도 일정과 누가 작업할지를 포함한 계획을 수립.

• 애자일 프로젝트 관리는 증분 개발 및 애자일 방법에 맞춘 접근 방식을 요구.

• Scrum은 구체적인 애자일 실천보다 반복적 개발 관리에 초점을 맞춘 애자일 방법론.

• Scrum에는 세 가지 단계가 있음:
• 초기 단계: 프로젝트의 목표를 설정하고 소프트웨어 아키텍처를 설계하는 개요 계획 단계.
• 이후에는 스프린트 주기가 이어지며, 각 주기는 시스템의 증분 개발을 포함.
• 프로젝트 종료 단계: 프로젝트 문서화 완료, 교훈 평가 등.

🔍 Scrum의 용어 종류:

• Development team (개발팀): 7명 이하로 구성된 자율 조직 팀으로, 소프트웨어 개발과 관련된 주요 문서를 담당.

• Sprint (스프린트): 2~4주 동안 진행되는 개발 반복 주기.

• Scrum (스크럼): 매일 진행되는 짧은 데일리 미팅으로, 팀의 작업 우선순위와 진행 상황을 검토.

• Scrum master (스크럼 마스터): 스크럼 프로세스가 올바르게 진행되도록 팀을 지도하고 외부 간섭을 방지하는 역할.
• 스크럼 마스터는 프로젝트 관리자와는 다른 역할로, 팀이 효과적으로 스크럼을 사용할 수 있도록 돕는 데 중점을 둠.

• Potentially shippable product increment (잠재적 전달 가능한 제품 증가분): 스프린트에서 전달되는 소프트웨어 증가분. 완성된 상태로 더 이상의 작업이 필요하지 않도록 설계.

• Product backlog (제품 백로그): 스크럼 팀이 처리해야 할 해야 할 일 목록으로, 소프트웨어 기능, 요구사항 등을 정의.

• Product owner (제품 소유자): 제품 기능과 요구 사항을 식별하고, 이를 우선순위화하여 제품 백로그를 지속적으로 검토하는 역할. 고객이나 제품 관리자일 수 있음.

• Velocity (속도): 팀이 하나의 스프린트에서 처리할 수 있는 백로그 작업의 양을 추정하는 지표.

🔍 스크럼 스프린트 사이클의 단계:

• 작업 검토: 수행해야 할 작업을 검토한다.

• 항목 선택: 진행할 항목을 선택한다.

• 스프린트 계획: 스프린트를 계획한다.

• 스프린트: 개발 작업이 진행된다.

• 스프린트 검토: 작업 결과를 검토한다.

• 제품 백로그와 스프린트 백로그: 작업 항목과 완료된 소프트웨어를 관리한다.

• 스프린트는 일반적으로 2-4주로 고정된 길이이다.

• 계획의 시작점은 제품 백로그로, 수행할 작업 목록이다.

• 선택 단계에서는 프로젝트 팀이 고객과 협력하여 개발할 기능을 선택한다.

• 이들이 합의되면, 팀은 소프트웨어 개발을 위해 스스로 조직한다.

• 팀은 고객과 조직으로부터 격리되어 있으며, 모든 커뮤니케이션은 스크럼 마스터를 통해 이루어진다.

• 스크럼 마스터의 역할은 개발 팀을 외부 방해로부터 보호하는 것이다.

• 스프린트가 끝나면 작업 결과가 이해관계자에게 검토되고, 다음 스프린트 사이클이 시작된다.

🔍 스크럼에서의 팀워크

• 스크럼 마스터는 다음을 수행하는 촉진자 역할을 한다:
• 매일 회의 주선
• 수행할 작업의 백로그 추적
• 결정 사항 기록
• 백로그에 대한 진행 상황 측정 및 외부와의 커뮤니케이션

• 팀 전체는 짧은 데일리 미팅(Scrums)에 참석하여 정보를 공유하고 진행 상황 및 발생한 문제를 설명한다.

💡 스크럼의 이점

• 제품은 관리 가능하고 이해할 수 있는 청크로 분해된다. (쪼개서 개발하므로 가시적으로 보인다.)

• 불안정한 요구 사항은 진행에 지장을 주지 않는다.

• 팀 전체는 모든 사항에 대한 가시성을 가지며, 커뮤니케이션이 개선된다.

• 고객은 정시 납품을 보고 피드백을 받는다.

• 고객과 개발자 간의 신뢰가 구축되며 긍정적인 문화가 형성된다. (이는 XP와 같은 단점을 가진다.)

• 스크럼 마스터는 개발 팀과 함께 위치하여 일상적인 문제를 인식해야 한다.

• 제품 소유자는 개발자와 좋은 관계를 구축해야 하며, 서로를 신뢰하는 것이 필수적이다.

• 모든 팀을 위한 공통 개발 환경과 실시간 커뮤니케이션이 필요하다.

4. 애자일 프로그램의 규모 조정

• 애자일 방법은 소규모 및 중간 규모의 프로젝트에 성공적으로 적용되었으며, 이는 작은 공동 작업 팀에 의해 개발될 수 있다.

• 이러한 방법의 성공은 커뮤니케이션 개선에 기인한다고 주장되며, 이는 모두가 함께 작업할 때 가능하다.

• 애자일 방법을 확대하는 것은 여러 개발 팀이 있는 장기 프로젝트에 대응하기 위해 변경하는 것을 포함한다.

• 스케일링 업: 작은 팀이 개발할 수 없는 대규모 소프트웨어 시스템 개발에 애자일 방법을 사용하는 것과 관련이 있다.

• 스케일링 아웃: 오랜 소프트웨어 개발 경험이 있는 대규모 조직에 애자일 방법을 도입하는 것과 관련이 있다.

• 애자일 방법을 스케일링할 때 애자일 기본 원칙을 유지하는 것이 중요하다:
• 유연한 계획, 빈번한 시스템 출시, 지속적인 통합, 테스트 주도 개발, 팀 간의 원활한 커뮤니케이션.

4-1. 애자일 방법론의 실질적 문제

• 애자일 개발의 비공식성은 대기업에서 일반적으로 사용되는 계약 정의에 대한 법적 접근과 호환되지 않는다.

• 애자일 방법은 소프트웨어 유지보수보다 새로운 소프트웨어 개발에 가장 적합하다.

• 그러나 대기업의 소프트웨어 비용의 대부분은 기존 소프트웨어 시스템의 유지 관리에서 발생한다.

• 애자일 방법은 소규모 공동 작업 팀을 위해 설계되었으나, 현재는 전세계 분산 팀이 소프트웨어 개발에 관여하고 있다.

• 대부분의 소프트웨어 계약은 사양을 기반으로 하며, 시스템 고객을 위한 시스템 개발자가 구현해야 할 내용을 명시한다.

• 그러나 이는 애자일 개발의 표준인 사양과 개발을 교차 수행하는 것을 배제한다.

• 기능성보다 개발자 시간에 대해 지불하는 계약이 필요하지만, 이는 많은 법무 부서에서 높은 리스크로 간주된다.

4-2. 애자일 유지보수

• 대부분의 조직은 새로운 소프트웨어 개발보다 기존 소프트웨어 유지 관리에 더 많은 비용을 지출한다.

• 애자일 방법이 성공하기 위해서는 원래 개발뿐만 아니라 유지 관리도 지원해야 한다.

• 두 가지 주요 이슈:
• 애자일 접근 방식으로 개발된 시스템이 유지 가능한가?
• 고객의 변경 요청에 대응하여 시스템을 효과적으로 발전시키기 위해 애자일 방법을 사용할 수 있는가?

• 원래 개발 팀이 유지되지 않으면 문제가 발생할 수 있다.

📌 애자일 유지보수의 문제점

• 주요 문제는 다음과 같다:
• 문서화 부족
• 고객 참여 유지
• 개발 팀의 연속성 유지

• 애자일 개발은 개발 팀이 무엇을 해야 하는지 아는 것에 의존한다.

• 장기간 시스템의 경우, 원래 개발자가 시스템에서 항상 작업하지 않을 수 있기 때문에 실제 문제가 된다.

• 대부분의 프로젝트는 계획 중심 및 애자일 프로세스의 요소를 포함한다. 균형을 결정하는 것은 다음에 따라 다르다:
• 구현 이전에 상세한 사양과 설계가 중요하다면, 계획 중심 접근 방식을 사용해야 한다.
• 고객에게 소프트웨어를 전달하고 신속한 피드백을 받는 것이 현실적이라면 애자일 방법을 고려해야 한다.

• 애자일과 Plan-driven 방법은 시스템이 얼마나 큰가에 따라 갈린다.
• 애자일 방법은 소규모 공동 작업 팀으로 개발할 수 있는 경우 가장 효과적이다.
• 큰 시스템에는 더 큰 개발 팀이 필요하므로 계획 중심 접근 방식을 사용해야 할 수도 있다.

📌 애자일 원칙과 조직 연습

• Customer involvement (고객 참여): 고객이 개발팀과 시간을 함께 보내고 시스템의 모든 이해 관계자를 대표할 수 있어야 함.
• 하지만 고객 대리인은 종종 시간 제약 때문에 완전한 역할을 수행하기 어려움.
• 외부 이해 관계자, 예를 들어 규제 당국이 있을 경우, 그들의 의견을 개발팀에 반영하는 것이 어려움.

• Embrace change (변화 수용): 시스템에 많은 이해 관계자가 있을 경우 변화 우선순위를 정하는 것이 매우 어려움.
• 각 이해 관계자는 다른 변화를 우선시할 수 있음.

• Incremental delivery (점증적 인도):
• 신속한 반복 및 단기 계획이 비즈니스 계획 및 마케팅과 같은 장기 계획 주기와 맞지 않을 수 있음.
• 마케팅 관리자들은 몇 달 전부터 제품 기능을 미리 알아야 효과적인 마케팅 캠페인을 준비할 수 있음.

• Maintain simplicity (단순성 유지): 배포 일정의 압박으로 팀원들이 시스템 단순화 작업을 수행할 시간이 없을 수 있음.

• People not process (사람 우선): 팀 구성원 간 상호작용이 원활하지 않을 경우 문제가 될 수 있음.

4-2. 문제 사항

1️⃣ 시스템 개발 시 고려 사항

• 시스템의 크기: 애자일 방법론은 소규모, 동일 장소에 있는 팀에 가장 효과적임.

• 시스템 유형: 사전에 많은 분석이 필요한 시스템은 상세 설계를 통해 진행되어야 함.

• 시스템의 수명: 장기간 사용되는 시스템은 개발자와 지원팀 간의 의사소통이 필요함.

• 외부 규제 여부: 규제가 있는 시스템은 상세한 문서가 필요할 수 있음.

2️⃣ 팀 문제

• 디자이너와 개발자의 능력: 애자일 방법론은 계획 기반 접근 방식보다 더 높은 기술 수준을 요구함.

• 개발팀의 조직 방식: 팀이 분산되어 있을 경우 설계 문서가 필요할 수 있음.

• 지원 기술: 디자인 문서가 없을 때, 시각화 및 프로그램 분석을 위한 IDE 지원이 필수적임.

3️⃣ 조직 문제

• 계획 기반 문화: 전통적인 엔지니어링 조직은 계획 기반 개발을 표준으로 삼음.

• 시스템 사양 개발: 조직 차원에서 상세한 시스템 사양을 개발하는 것이 표준인지 확인 필요.

• 고객 피드백: 고객 대리인이 시스템 증분에 대한 피드백을 제공할 수 있을지 여부가 중요함.

• 문서화 부족: 애자일 개발 방식이 세부 문서화 문화와 잘 맞는지 확인 필요.

4-3. 대규모 시스템 개발

• 규제 제약: 대규모 시스템은 외부 규제 및 규칙에 의해 개발 방식이 제한됨.

• 오랜 개발 시간: 대규모 시스템은 긴 조달 및 개발 시간이 소요되며, 그 기간 동안 팀의 일관성을 유지하기 어려움.

• 다양한 이해 관계자: 다양한 이해 관계자가 모두 개발 과정에 참여하는 것이 현실적으로 불가능함.

📌 다중 팀 스크럼

• 역할 복제: 각 팀에 제품 소유자와 스크럼 마스터가 있음.

• 제품 아키텍트: 각 팀이 아키텍트를 선택하고 이들이 시스템 아키텍처를 공동 설계함.

• 릴리즈 정렬: 각 팀의 제품 릴리즈 일정을 맞춰 완전한 시스템이 제공되도록 함.

• 스크럼 오브 스크럼: 각 팀 대표가 모여 진행 상황을 논의하고 작업 계획을 수립함.