L07L08-Agile Software Development (Ch03)

신속한 소프트웨어 개발 (Rapid software development)

• 신속한 개발과 배포는 이제 소프트웨어 시스템에서 가장 중요한 요구 사항 중 하나이다.
  • 기업은 빠르게 변화하는 환경에서 운영되며, 안정적인 소프트웨어 요구 사항을 설정하는 것이 사실상 불가능하다.
  • 소프트웨어는 변화하는 비즈니스 요구 사항을 반영하기 위해 빠르게 발전해야 한다.
• 일부 시스템에서는 계획 기반 개발이 필수적이지만, 이러한 비즈니스 요구 사항을 충족하지 못한다.
• 1990년대 후반, 작동하는 소프트웨어 시스템의 제공 시간을 급격히 단축하기 위해 애자일 개발 방법이 등장하였다.

애자일 개발 (Agile development)

프로그램 명세, 설계 및 구현이 서로 얽혀 진행된다.

• 시스템은 여러 버전 또는 증분 형태로 개발되며, 이해관계자가 버전 명세 및 평가에 참여한다.
• 새로운 버전을 자주 제공하여 평가한다.
• 개발을 지원하기 위해 자동화된 테스트 도구 등의 광범위한 도구를 활용한다.
• 최소한의 문서화 – 작동하는 코드에 초점을 맞춘다.

계획 기반 개발과 애자일 개발 (Plan-driven and agile development)

• 계획 기반 개발
  • 계획 기반 소프트웨어 엔지니어링 접근 방식은 개발 단계가 분리되어 있으며, 각 단계에서 생성될 산출물이 사전에 계획된다.
  • 꼭 폭포수 모델을 의미하는 것은 아니며, 계획 기반이면서 점진적인 개발도 가능하다.
  • 반복은 각 활동 내에서 발생한다.
• 애자일 개발
  • 명세, 설계, 구현, 테스트가 서로 얽혀 진행된다.
  • 반복이 전체 활동에 걸쳐 발생한다.

 

 

 

[2] 애자일 방법

애자일 방법 (Agile methods)

• 1980~1990년대 소프트웨어 설계 방법의 높은 비용과 비효율성에 대한 불만이 애자일 방법의 탄생으로 이어졌다.
  • 코드에 집중하고 설계보다는 실제 작동하는 소프트웨어 개발을 우선시한다.
  • 반복적인 개발 접근 방식을 기반으로 한다.
  • 빠르게 작동하는 소프트웨어를 제공하고, 변화하는 요구 사항에 빠르게 적응하는 것이 목표이다.
• 애자일 방법은 소프트웨어 개발 과정에서 문서화를 최소화하고 불필요한 작업을 줄여, 변경 사항에 신속하게 대응하는 것을 목표로 한다.

애자일 선언문 (Agile manifesto)

"우리는 소프트웨어 개발의 더 나은 방법을 발견하고 있으며, 이를 통해 다른 사람들도 도울 수 있다. 이 과정에서 우리는 다음 가치를 중요하게 여긴다."

• 프로세스와 도구보다 개인과 상호작용
• 포괄적인 문서보다 작동하는 소프트웨어
• 계약 협상보다 고객과의 협력
• 계획을 따르는 것보다 변화에 대한 대응
• 즉, 오른쪽의 가치도 중요하지만, 왼쪽의 가치를 더 우선한다.

애자일 방법의 원칙 (The principles of agile methods)

원칙	설명
고객 참여	고객은 개발 과정에 적극적으로 참여해야 하며, 요구 사항을 제공하고 우선순위를 설정하며, 반복된 시스템을 평가해야 한다.
점진적 제공	소프트웨어는 고객과 협력하여 점진적으로 개발되며, 각 단계에서 포함될 요구 사항을 지정한다.
사람 우선	개발자의 역량을 인식하고 존중해야 하며, 고정된 프로세스보다 개별적인 작업 방식을 존중해야 한다.
변화 수용	시스템 요구 사항이 변경될 가능성이 크므로, 이를 수용할 수 있도록 시스템을 설계해야 한다.
단순성 유지	개발 과정과 소프트웨어 자체를 최대한 단순하게 유지하며, 불필요한 복잡성을 제거해야 한다.

애자일 방법의 적용 가능성 (Agile method applicability)

• 제품 개발: 소프트웨어 회사가 소규모 또는 중규모 제품을 개발하는 경우에 적합하다.
  • 현재 거의 모든 소프트웨어 제품과 앱은 애자일 방식을 사용하여 개발된다.
• 맞춤형 시스템 개발: 고객이 개발 과정에 적극적으로 참여할 수 있고, 외부 규칙과 규제가 적은 조직 내에서 유용하다.

 

 

 

[4] 애자일 개발 기법

극단적 프로그래밍 (Extreme programming, XP)

• 1990년대 후반 등장한 매우 영향력 있는 애자일 방법으로, 다양한 애자일 개발 기법을 도입했다.
• 극단적 프로그래밍(XP)은 반복적 개발 방식을 극한으로 적용한다.
  • 하루에도 여러 번 새로운 버전이 빌드될 수 있다.
  • 2주마다 고객에게 증분된 기능을 제공한다.
  • 모든 빌드는 모든 테스트를 통과해야 하며, 테스트가 실패하면 빌드는 허용되지 않는다.

극단적인 프로그래밍 릴리스 주기

극단적 프로그래밍 관행 (Extreme programming practices)

원칙/관행	설명
점진적 계획	요구 사항은 스토리 카드에 기록되며, 릴리스 포함 여부는 가용 시간과 우선순위를 고려해 결정된다. 개발자는 이를 개발 작업 단위로 나눈다.
소규모 릴리스	최소한의 유용한 기능 세트를 먼저 개발하며, 이후 반복적인 기능 추가를 통해 시스템을 발전시킨다.
단순한 설계	현재 요구 사항을 충족하는 데 필요한 최소한의 설계만 수행한다.
테스트 우선 개발	기능을 구현하기 전에 자동화된 단위 테스트를 먼저 작성하고, 테스트를 통과해야 기능을 완성하는 방식으로 개발한다.
리팩토링	개발자는 코드 개선이 필요하다고 판단되면 즉시 리팩토링하여 코드를 단순하고 유지보수하기 쉽게 만든다.
페어 프로그래밍	두 명의 개발자가 짝을 이루어 작업하며, 서로의 코드를 검토하고 품질을 개선한다.
집단적 소유권	모든 개발자가 시스템의 모든 영역을 담당할 수 있으며, 누구나 코드를 변경할 수 있다.
지속적 통합	개발이 완료된 코드는 즉시 전체 시스템에 통합되며, 모든 단위 테스트를 통과해야 한다.
지속 가능한 페이스	장기적인 초과 근무를 지양하며, 코드 품질과 생산성을 유지하는 속도로 작업한다.
현장 고객	최종 사용자(고객) 대표가 개발 팀에 상주하며, 요구 사항을 즉시 제공하고 개발 과정에 직접 참여한다.

XP와 애자일 원칙 (XP and agile principles)

• 작은 규모의 빈번한 시스템 릴리스를 통해 점진적 개발을 지원한다.
• 고객 참여를 보장하기 위해 개발 팀 내에 고객을 포함한다.
• 긴 작업 시간을 피하고 페어 프로그래밍, 집단적 코드 소유 등을 통해 개발자가 주도적으로 작업할 수 있도록 한다.
• 정기적인 시스템 릴리스를 통해 변화에 대응한다.
• 지속적인 코드 리팩토링을 통해 단순성을 유지한다.

XP의 실제 적용 (XP in practice)

• XP는 기술적인 요소에 집중하며, 많은 조직의 관리 관행과 통합하기 어려운 경우가 많다.
• 따라서 애자일 개발에서는 XP의 일부 기법을 채택하지만, 원래 정의된 XP 방식이 널리 사용되지는 않는다.
• 핵심 기법
  • 사용자 스토리를 활용한 명세 작성
  • 코드 리팩토링
  • 테스트 우선 개발
  • 페어 프로그래밍

요구 사항을 위한 사용자 스토리

• XP에서는 고객 또는 사용자가 XP 팀의 일부로 참여하여 요구 사항에 대한 결정을 내린다.
• 사용자 요구 사항은 사용자 스토리 또는 시나리오로 표현된다.
• 이러한 요구 사항은 카드에 작성되며, 개발 팀은 이를 구현 가능한 작업 단위로 나눈다. 이러한 작업은 일정 및 비용 추정의 기초가 된다.
• 고객은 우선순위와 일정 추정을 기반으로 다음 릴리스에 포함될 스토리를 선택한다.

‘약물 처방’ 스토리

케이트는 클리닉에 방문한 환자에게 약물을 처방하고자 하는 의사입니다. 환자 기록이 이미 그녀의 컴퓨터에 표시되어 있어서 그녀는 약물 필드를 클릭하여 '현재 약물', '새로운 약물' 또는 '처방집'을 선택할 수 있습니다.
만약 그녀가 '현재 약물'을 선택하면, 시스템은 그녀에게 용량을 확인하도록 요청합니다; 만약 그녀가 용량을 변경하고 싶다면, 새 용량을 입력한 다음 처방을 확인합니다.
만약 그녀가 '새로운 약물'을 선택하면, 시스템은 그녀가 어떤 약물을 처방할지 알고 있다고 가정합니다. 그녀는 약물 이름의 첫 몇 글자를 입력합니다. 시스템은 이 글자들로 시작하는 가능한 약물 목록을 표시합니다. 그녀는 필요한 약물을 선택하고 시스템은 선택한 약물이 올바른지 확인하도록 요청하며 응답합니다. 그녀는 용량을 입력한 다음 처방을 확인합니다.
만약 그녀가 '처방집'을 선택하면, 시스템은 승인된 처방집을 위한 검색창을 표시합니다. 그녀는 필요한 약물을 검색할 수 있습니다. 그녀는 약물을 선택하고 약물이 올바른지 확인하도록 요청받습니다. 그녀는 용량을 입력한 다음 처방을 확인합니다.
시스템은 항상 용량이 승인된 범위 내에 있는지 확인합니다. 범위를 벗어나는 경우, 케이트는 용량을 변경하도록 요청받습니다.
케이트가 처방을 확인한 후, 처방은 확인을 위해 표시됩니다. 그녀는 '확인' 또는 '변경'을 클릭합니다. 만약 그녀가 '확인'을 클릭하면, 처방은 감사 데이터베이스에 기록됩니다. 만약 그녀가 '변경'을 클릭하면, 그녀는 '약물 처방' 과정을 다시 시작합니다.

약물 처방을 위한 작업 카드 예시

이 이미지는 "약물 처방을 위한 태스크 카드 예시"를 보여주고 있습니다. 슬라이드에는 약물 처방 프로세스와 관련된 세 가지 태스크가 계단식으로 표시되어 있습니다:
태스크 1: 처방 약물의 용량 변경 - 이 태스크는 파란색 헤더로 표시되어 있지만 세부 내용은 보이지 않습니다.태스크 2: 처방집 선택 - 이 태스크도 파란색 헤더로 표시되어 있지만 마찬가지로 세부 내용은 보이지 않습니다.태스크 3: 용량 확인 - 이 태스크는 상세 설명이 포함되어 있습니다:용량 확인은 의사가 위험하게 적거나 많은 용량을 처방하지 않았는지 확인하는 안전 예방 조치입니다.일반 약물명에 대한 처방집 ID를 사용하여 처방집을 조회하고 권장 최대 및 최소 용량을 검색합니다.처방된 용량을 최소값과 최대값과 비교합니다. 범위를 벗어나면 용량이 너무 높거나 낮다는 오류 메시지를 발행합니다.범위 내에 있으면 '확인' 버튼을 활성화합니다.
이미지 하단에는 "Copyright ©2016 Pearson Education, All Rights Reserved"라는 저작권 표시가 있습니다.

 

리팩토링 (Refactoring)

• 소프트웨어 공학의 일반적인 원칙은 변화에 대비하여 설계하는 것이다. 변화에 대한 사전 대비는 장기적으로 비용을 절감할 수 있다.
• 하지만 XP에서는 변화를 정확히 예측하는 것이 불가능하므로 사전 대비가 비효율적이라고 본다.
• 대신 지속적인 코드 개선(리팩토링)을 통해 변화가 필요할 때 쉽게 적용할 수 있도록 한다.
• 프로그래밍 팀은 지속적으로 소프트웨어 개선 가능성을 찾고, 즉각적인 필요가 없더라도 개선을 수행한다.
• 이를 통해 소프트웨어의 가독성이 향상되어 문서화 필요성이 줄어든다.
• 코드가 잘 구조화되어 있어 변경이 용이해진다.
• 하지만 일부 변경은 아키텍처 수준의 리팩토링을 필요로 하며, 이는 비용이 많이 든다.

리팩토링 예시

• 중복 코드를 제거하기 위해 클래스 계층을 재구성
• 속성과 메서드를 정리하고 명확한 이름으로 변경하여 이해도를 높임
• 인라인 코드를 제거하고, 라이브러리에 포함된 메서드 호출로 대체

테스트 우선 개발 (Test-first development)

• XP에서는 테스트를 중심으로 개발이 이루어지며, 변경이 이루어질 때마다 프로그램을 테스트하는 방식을 사용한다.
• XP의 테스트 특징:
  • 테스트 우선 개발
  • 시나리오 기반의 점진적 테스트 개발
  • 사용자 테스트 개발 및 검증 참여
  • 자동화된 테스트 프레임워크를 사용하여 새 릴리스가 빌드될 때마다 모든 컴포넌트 테스트 실행

테스트 주도 개발 (TDD)

• 코드를 작성하기 전에 테스트를 먼저 작성하면 구현해야 할 요구 사항이 명확해진다.
• 테스트는 데이터가 아닌 프로그램 형태로 작성되어 자동 실행이 가능하다. 테스트는 실행 결과가 올바른지 확인하는 기능을 포함한다.
  • 일반적으로 JUnit과 같은 테스트 프레임워크를 활용한다.

새로운 기능이 추가될 때마다 기존 및 신규 테스트를 자동으로 실행하여 새로운 기능이 오류를 유발하지 않았는지 확인한다.

고객 참여 (Customer involvement)

• 고객의 역할은 다음 릴리스에서 구현될 사용자 스토리에 대한 승인 테스트를 개발하는 것이다.
• 개발이 진행되는 동안 고객이 팀의 일원으로 테스트를 작성하며, 새로운 코드가 고객의 요구 사항을 충족하는지 검증한다.
• 하지만 고객 역할을 수행하는 사람들은 시간적 제약이 있어 개발 팀과 풀타임으로 협업하기 어렵다.
• 또한, 일부 고객은 요구 사항을 제공하는 것만으로도 충분한 기여를 했다고 느껴 테스트 과정에 적극적으로 참여하지 않을 수도 있다.

복용량 확인을 위한 테스트 케이스 설명

테스트 4: 용량 확인
- 입력:
: 약물의 단일 용량을 나타내는 mg 단위의 숫자
: 하루당 단일 용량의 횟수를 나타내는 숫자
- 테스트:
1. 단일 용량은 올바르지만 빈도가 너무 높은 입력 테스트
2. 단일 용량이 너무 높거나 너무 낮은 입력 테스트
3. 단일 용량 * 빈도가 너무 높거나 너무 낮은 입력 테스트
4. 단일 용량 * 빈도가 허용 범위 내에 있는 입력 테스트
- 출력: OK 또는 용량이 안전 범위를 벗어났음을 나타내는 오류 메시지

 

테스트 자동화 (Test automation)

• 테스트 자동화는 특정 작업을 구현하기 전에 실행 가능한 테스트를 작성하는 것을 의미한다.
  • 이 테스트는 독립적으로 실행 가능해야 하며, 입력을 시뮬레이션하고 출력이 기대값과 일치하는지 확인해야 한다.
  • JUnit과 같은 자동화 테스트 프레임워크를 활용하면 실행 가능한 테스트를 쉽게 작성하고 실행할 수 있다.
• 테스트가 자동화되어 있으면 언제든지 빠르고 쉽게 테스트를 실행할 수 있다.
  • 새로운 기능이 추가될 때마다 모든 테스트를 실행하여 새로운 코드가 문제를 일으키지 않았는지 즉시 확인할 수 있다.

테스트 우선 개발의 문제점

• 프로그래머는 코딩을 선호하며, 테스트 작성 시 단순화하려는 경향이 있다. 예를 들어, 발생 가능한 모든 예외를 검증하지 않는 불완전한 테스트를 작성할 수 있다.
• 일부 테스트는 점진적으로 작성하기 어렵다. 예를 들어, 복잡한 사용자 인터페이스(UI)의 경우 화면 간의 워크플로우를 테스트하는 것이 어려울 수 있다.
• 테스트가 충분한지 판단하기 어렵다. 많은 시스템 테스트를 보유하고 있더라도 전체적인 테스트 커버리지가 부족할 수 있다.

페어 프로그래밍 (Pair programming)

• 페어 프로그래밍은 두 명의 프로그래머가 한 팀을 이루어 코드를 함께 개발하는 방식이다.
• 코드에 대한 공동 소유권을 형성하며, 팀 전체에 지식을 공유하는 데 도움이 된다.
• 한 사람이 작성한 코드가 즉시 다른 사람에 의해 검토되므로 비공식적인 코드 리뷰가 자연스럽게 이루어진다.
• 리팩토링을 촉진하며, 팀 전체가 코드 개선의 이점을 공유할 수 있다.
• 개발자들은 같은 컴퓨터에서 협력하여 소프트웨어를 개발한다.
• 페어는 동적으로 변경되며, 개발 과정에서 팀원들이 서로 협력할 기회를 갖는다.
• 페어 프로그래밍을 통해 팀원이 프로젝트를 떠날 경우 발생할 수 있는 리스크를 줄일 수 있다.
• 비효율적이라고 생각될 수 있지만, 연구에 따르면 두 명이 협력하면 개별적으로 작업하는 것보다 더 높은 생산성을 보일 수 있다.

 

 

 

[3] 애자일 프로젝트 관리

애자일 프로젝트 관리 (Agile project management)

• 소프트웨어 프로젝트 관리자의 주요 책임은 프로젝트를 일정 내에 완료하고, 예산 내에서 소프트웨어를 제공하는 것이다.
• 전통적인 프로젝트 관리는 계획 중심 접근 방식을 따른다.
  • 프로젝트 계획을 수립하여 무엇을 언제 전달할 것인지, 누가 프로젝트 산출물을 개발할 것인지 결정한다.
• 애자일 프로젝트 관리는 점진적 개발과 애자일 방식에 맞게 조정된 접근 방식을 필요로 한다.

스크럼 (Scrum)

스크럼은 특정한 애자일 실천법보다는 반복적인 개발 관리에 초점을 맞춘 애자일 방법론이다.

• 스크럼의 세 가지 주요 단계:
  1. 초기 계획 단계: 프로젝트의 전반적인 목표를 설정하고 소프트웨어 아키텍처를 설계한다.
  2. 스프린트 주기: 각 주기에서 시스템의 새로운 증분을 개발한다.
  3. 프로젝트 종료 단계: 프로젝트를 마무리하고, 시스템 도움말, 사용자 매뉴얼 등 필요한 문서를 완성하며, 프로젝트에서 얻은 교훈을 평가한다.

Scrum 용어

 

스크럼 용어	정의
개발 팀	최대 7명으로 구성된 자기 조직화된 소프트웨어 개발자 그룹으로, 소프트웨어 개발 및 프로젝트 문서 작성의 책임을 가짐.
잠재적 출시 가능한 제품 증분	스프린트에서 제공되는 소프트웨어 증분으로, 추가 작업 없이 최종 제품에 바로 통합될 수 있는 상태여야 함.
제품 백로그	스크럼 팀이 수행해야 할 작업 목록으로, 기능 정의, 요구사항, 사용자 스토리 및 관련 문서 작업 등이 포함될 수 있음.
제품 소유자	제품의 기능 및 요구사항을 정의하고, 개발 우선순위를 정하며, 제품 백로그를 지속적으로 관리하는 개인 또는 그룹.
스크럼	스크럼 팀이 진행 상황을 점검하고 그날의 작업 우선순위를 정하는 일일 회의. 일반적으로 짧은 대면 회의로 진행됨.
스크럼마스터	스크럼 프로세스가 올바르게 수행되도록 돕고, 팀이 외부 간섭 없이 작업할 수 있도록 보호하는 역할을 하는 사람. 프로젝트 관리자와는 다름.
스프린트	개발 반복 주기로, 일반적으로 2~4주 단위로 진행됨.
속도	단일 스프린트에서 팀이 처리할 수 있는 제품 백로그의 작업량을 추정한 값으로, 작업 계획 및 성과 측정 기준이 됨.

스크럼 스프린트 주기 (2~4주)

Scrum 스프린트 주기

• 스프린트는 보통 2~4주 동안 고정된 기간으로 진행됨.
• 계획의 출발점은 제품 백로그이며, 이는 프로젝트에서 수행해야 할 작업 목록임.
• 선택 단계에서는 프로젝트 팀과 고객이 함께 스프린트에서 개발할 기능과 작업을 선택함.

스프린트 주기

• 선택된 작업이 확정되면 팀은 자체적으로 소프트웨어 개발을 진행함.
• 이 단계에서 팀은 고객 및 조직과 격리되며, 모든 의사소통은 '스크럼마스터'를 통해 이루어짐.
• 스크럼마스터는 개발 팀을 외부 방해 요소로부터 보호하는 역할을 수행함.
• 스프린트가 끝나면 개발 결과물이 검토되고 이해관계자에게 시연됨. 이후 새로운 스프린트가 시작됨.

Scrum의 팀워크

• '스크럼마스터'는 일일 회의 주최, 백로그 관리, 결정 사항 기록, 진행 상황 추적 및 외부와의 커뮤니케이션을 담당함.
• 팀 전체가 매일 짧은 회의(스크럼)에 참석하여 진행 상황, 문제점, 계획 등을 공유함.
  • 이를 통해 팀원들은 전체 진행 상황을 파악하고, 문제 발생 시 신속하게 대응할 수 있음.

Scrum의 이점

• 제품이 관리하기 쉬운 단위로 나뉘어짐.
• 요구사항이 불안정하더라도 진행이 지연되지 않음.
• 팀 전체가 모든 사항을 공유하여 커뮤니케이션이 향상됨.
• 고객이 정기적으로 결과물을 확인하고 피드백을 제공할 수 있음.
• 고객과 개발자 간 신뢰가 형성되며, 프로젝트 성공을 기대하는 긍정적인 문화가 조성됨.

분산된 Scrum

 

 

 

[5] 애자일 방법 확장

애자일 방법 확장

• 애자일 방법은 소규모 프로젝트나 같은 장소에서 협업하는 팀에 적합하다는 점에서 성공적이었음.
• 모든 팀원이 같은 공간에서 근무할 때 커뮤니케이션이 원활해진다는 점이 주요 성공 요인으로 작용함.
• 대규모, 장기 프로젝트에 적용하기 위해 애자일 방법을 확장하는 것이 필요함.

확장 방법

• '확장 업(Scaling up)': 소규모 팀이 감당할 수 없는 대형 소프트웨어 개발 프로젝트에 애자일 방법을 적용하는 것.
• '확장 아웃(Scaling out)': 애자일 방법을 다년간의 소프트웨어 개발 경험이 있는 대규모 조직에 도입하는 것.
• 애자일 방법을 확장할 때도 기본 원칙(유연한 계획, 잦은 릴리스, 지속적 통합, 테스트 주도 개발, 원활한 팀 커뮤니케이션)을 유지해야 함.

애자일 방법의 실용적 문제

• 애자일 개발의 비형식적인 특성은 대기업에서 사용하는 계약 방식과 충돌할 수 있음.
• 애자일은 새로운 소프트웨어 개발에 적합하지만, 소프트웨어 유지보수에는 적합하지 않을 수 있음.
• 대부분의 소프트웨어 비용은 기존 시스템 유지보수에서 발생함.
• 애자일은 소규모 팀을 전제로 하지만, 현재 소프트웨어 개발은 전 세계에 분산된 팀들이 협업하는 경우가 많음.

계약 관련 문제

• 대부분의 맞춤형 소프트웨어 계약은 명확한 사양을 기준으로 작성됨.
• 하지만 애자일 개발에서는 명세와 개발이 동시 진행되므로, 전통적인 계약 방식과 맞지 않음.
• 기능이 아닌 개발자의 시간에 따라 비용을 지불하는 계약 방식이 필요하지만, 이는 법무팀에서 리스크가 크다고 판단할 수 있음.

애자일과 소프트웨어 유지보수

• 많은 조직이 새로운 소프트웨어 개발보다 기존 시스템 유지보수에 더 많은 비용을 지출함.
• 애자일 방법이 유지보수까지 지원하려면 다음과 같은 문제가 해결되어야 함.
  • 문서 부족으로 인한 유지보수의 어려움
  • 고객과의 지속적인 협업 유지
  • 원래 개발 팀이 유지보수를 계속할 수 있도록 팀 연속성 유지

애자일 유지보수

• 주요 문제:
  • 제품 문서 부족
  • 고객과의 협업 지속
  • 개발 팀의 연속성 유지
• 애자일 개발은 팀원들이 시스템을 잘 이해하고 있어야 함.
• 장기 운영 시스템에서는 원래 개발 팀이 항상 유지되지 않기 때문에 문제 발생 가능성이 있음.

애자일과 계획 기반 방법

• 대부분의 프로젝트는 계획 기반과 애자일 방법을 혼합하여 사용함. 적절한 균형을 찾는 것이 중요함.
  • 세부 명세와 설계가 선행되어야 하는가? 그렇다면 계획 기반 접근 방식이 필요함.
  • 점진적 제공 방식이 가능한가? 그렇다면 애자일 방법이 적절함.
  • 개발 규모가 큰가? 애자일은 소규모 팀에서 효과적이므로 대규모 프로젝트라면 계획 기반 접근이 필요할 수 있음.

애자일 원칙 vs. 조직 내 현실

원칙	실천
고객 참여	이는 개발팀과 시간을 보낼 의향과 능력이 있고 모든 시스템 이해관계자를 대표할 수 있는 고객에게 달려 있습니다. 종종 고객 대표자들은 시간에 대한 다른 요구사항이 있어 소프트웨어 개발에 충분히 참여할 수 없습니다. 규제 기관과 같은 외부 이해관계자가 있는 경우, 그들의 견해를 애자일 팀에 전달하기 어렵습니다.
변화 수용	많은 이해관계자가 있는 시스템에서는 변경 우선순위를 정하는 것이 매우 어려울 수 있습니다. 일반적으로 각 이해관계자는 다른 변경사항에 대해 다른 우선순위를 부여합니다.
점진적 배포	개발을 위한 빠른 반복과 단기 계획은 비즈니스 계획과 마케팅의 장기 계획 주기와 항상 맞지 않습니다. 마케팅 관리자는 효과적인 마케팅 캠페인을 준비하기 위해 몇 개월 전에 제품 기능을 알아야 할 수도 있습니다.
단순성 유지	배포 일정의 압박 하에서 팀원들은 바람직한 시스템 단순화를 수행할 시간이 없을 수 있습니다.
사람, 프로세스가 아닌	개별 팀원들이 애자일 방법에서 전형적인 집중적인 참여에 적합한 성격을 가지고 있지 않을 수 있으며, 따라서 다른 팀원들과 잘 상호작용하지 못할 수 있습니다.

 

애자일과 계획 기반 접근? 고려해야 할 요소

 

시스템 이슈

• 개발 중인 시스템의 크기는 얼마나 되는가?
  • 애자일 방법론은 비교적 소규모의 공동 작업 팀에서 비공식적으로 소통할 수 있을 때 가장 효과적이다.
• 개발 중인 시스템의 유형은 무엇인가?
  • 구현 전에 많은 분석이 필요한 시스템은 이를 수행하기 위해 비교적 상세한 설계가 필요하다. >> 계획 주도 방식(Plan-driven)
• 예상되는 시스템 수명은 얼마인가?
  • 장기간 운영될 시스템은 개발자의 의도를 지원 팀에 전달할 수 있도록 문서화가 필요하다.
• 시스템이 외부 규제를 받는가?
  • 규제를 받는 시스템이라면 시스템 안전성을 입증하는 과정에서 상세한 문서를 작성해야 할 가능성이 높다.

사람과 팀

• 개발 팀 내 설계자와 프로그래머의 실력은 어느 정도인가?
  • 애자일 방법론은 단순히 상세 설계를 코드로 변환하는 계획 주도 방식보다 더 높은 기술 수준을 요구할 수도 있다.
• 개발 팀은 어떻게 조직되어 있는가?
  • 팀이 분산되어 있다면 설계 문서가 필요할 수도 있다.
• 어떤 지원 기술이 사용 가능한가?
  • 설계 문서가 제공되지 않는 경우, 시각화 및 프로그램 분석을 지원하는 IDE가 필수적이다.

조직적 이슈

• 전통적인 엔지니어링 조직은 계획 주도 개발 문화가 자리 잡고 있으며, 이는 엔지니어링의 일반적인 방식이다.
• 조직 내에서 상세한 시스템 명세서를 작성하는 것이 표준 관행인가?
• 고객 대표가 시스템 증분에 대한 피드백을 제공할 수 있는가?
• 비공식적인 애자일 개발 방식이 상세한 문서를 요구하는 조직 문화에 적합한가?

대형 시스템을 위한 애자일 방법론

• 대형 시스템은 일반적으로 개별적으로 개발된 여러 시스템의 집합이며, 각 시스템은 별도의 팀이 개발한다. 이러한 팀들은 종종 서로 다른 장소에서, 때로는 서로 다른 시간대에서 작업한다.
• 대형 시스템은 기존 시스템과 상호 작용하는 브라운필드 시스템(Brownfield System) 이다. 시스템 요구사항 중 상당 부분이 기존 시스템과의 연동과 관련되어 있기 때문에 유연한 증분 개발 방식을 적용하기 어렵다.
• 여러 시스템을 통합하여 하나의 시스템을 만들 경우, 개발 과정에서 코드 작성보다는 시스템 구성(System Configuration)이 주요 작업이 될 가능성이 크다.

대형 시스템 개발

• 대형 시스템과 그 개발 프로세스는 외부 규제 및 규칙에 의해 개발 방식이 제한되는 경우가 많다.
• 대형 시스템은 조달 및 개발 기간이 길다. 그 기간 동안 시스템을 깊이 이해하는 일관된 팀을 유지하기 어려우며, 결국 팀원들이 다른 업무나 프로젝트로 이동하게 된다.
• 대형 시스템은 다양한 이해관계자를 포함한다. 모든 이해관계자를 개발 과정에 참여시키는 것은 현실적으로 어렵다.

대형 시스템에서 고려해야 할 요소

IBM의 확장된 애자일 모델

대형 시스템으로의 확장

• 요구사항 엔지니어링을 완전히 증분 방식으로 진행하는 것은 불가능하다.
• 단일 제품 소유자(Product Owner)나 고객 대표를 두는 것이 어렵다.
• 대형 시스템 개발에서는 코드만 집중적으로 다룰 수 없다.
• 팀 간의 커뮤니케이션 메커니즘을 설계하고 활용해야 한다.
• 지속적인 통합(Continuous Integration)은 현실적으로 어렵지만, 자주 시스템을 빌드하고 정기적으로 출시하는 것은 필수적이다.

다중 팀 스크럼 (Multi-team Scrum)

• 역할 복제(Role replication)
  • 각 팀은 자신이 담당하는 작업 영역에 대해 제품 소유자와 스크럼마스터를 둔다.
• 제품 아키텍트(Product architects)
  • 각 팀은 제품 아키텍트를 선정하며, 이 아키텍트들은 협력하여 전체 시스템 아키텍처를 설계하고 발전시킨다.
• 출시 일정 정렬(Release alignment)
  • 각 팀의 제품 출시 일정을 조정하여 기능이 완전한 데모 가능한 시스템을 만든다.
• 스크럼 간 회의(Scrum of Scrums)
  • 각 팀의 대표들이 매일 모여 진행 상황을 공유하고 다음 작업을 계획한다.

조직 전반의 애자일 적용

(대기업이 애자일 방법론을 적용하기 어려운 이유)

• 애자일 방법론을 경험해보지 않은 프로젝트 관리자는 새로운 접근 방식을 도입하는 것을 부담스러워할 수 있다.
• 대형 조직은 모든 프로젝트가 따라야 하는 품질 절차 및 표준이 존재하며, 이러한 관료적 요소가 애자일 방법론과 충돌할 수 있다.
• 애자일 방법론은 팀원들의 기술 수준이 상대적으로 높을 때 효과적인데, 대형 조직에서는 다양한 기술 수준을 가진 인력이 존재할 가능성이 높다.
• 기존 시스템 엔지니어링 프로세스를 오랫동안 사용해 온 조직에서는 애자일 방법론에 대한 문화적 저항이 발생할 수 있다.

핵심 포인트

• 애자일 방법론은 증분 개발 방식으로, 빠른 소프트웨어 개발, 잦은 릴리스, 문서화 최소화, 고품질 코드 생성을 목표로 한다.
• 애자일 개발 방식에는 다음과 같은 요소가 포함된다.
  • 사용자 스토리를 활용한 시스템 명세
  • 소프트웨어의 잦은 릴리스
  • 지속적인 소프트웨어 개선
  • 테스트 우선 개발(Test-first development)
  • 개발 팀 내 고객 참여
• 스크럼(Scrum) 은 애자일 프로젝트 관리 프레임워크로,
  • 일정 기간(스프린트) 동안 시스템 증분을 개발하는 방식으로 운영된다.
• 실무에서는 계획 주도 방식과 애자일 방식이 혼합된 개발 방식이 많다.
• 대형 시스템에서 애자일 방법론을 확장하는 것은 어려우며,
  • 대형 시스템은 사전 설계 및 문서화가 필요하고, 조직의 표준 관행이 애자일 방식과 충돌할 수 있다.