[SE] L07/L08 - 요약

신속한 소프트웨어 개발

1. 특징

1. 신속한 개발과 배포는 소프트웨어 시스템에서 가장 중요한 '요구 사항' 중 하나이다.

• 기업은 빠르게 변화하는 환경에서 운영된다.
  • 따라서, 안정적인 소프트웨어 요구 사항을 설정하는 것이 사실상 불가능하다
• 소프트웨어는 변화하는 비즈니스 요구 사항을 반영하기 위해 빠르게 발전해야 한다.

1. 일부 시스템에서는 계획 기반 개발이 '필수'적이지만, 이러한 비즈니스 요구사항을 충족하지 못한다.
2. 1990년대 후반, 애자일 개발 방법이 등장했다.

애자일 개발

1. 특징

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

1. 계획 기반 개발과 애자일 개발의 차이

1. 계획 기반 개발

• 개발 단계가 분리되어 있으며, 각 단계에서 생성될 산출물이 사전에 계획된다.
• 꼭 폭포수 모델을 의미하는 것은 아니며, 계획 기반이면서 점진적인 개발도 가능하다.
• 반복은 '각 활동 내에서 발생'한다.

1. 애자일 개발

• 명세, 설계, 구현, 테스트가 서로 얽혀 진행된다.
• 반복이 '전체 활동에 걸쳐 발생'한다

1. 세 가지 주요 사항

• 코드에 집중하고, 설계 보다는 '실제 작동하는 소프트웨어 개발'을 우선시한다.
• 반복적인 개발 접근 방식을 기반으로 한다.
• 빠르게 작동하는 소프트웨어를 제공하며, 변화하는 요구 사항에 빠르게 적응하는 것이 목표이다.

1. 애자일 선언문

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

• 프로세스와 도구보다 개인과 상호작용 → 효과적인 개발은 프로세스보다 팀원 간의 원활한 협업에서 나온다.
• 포괄적인 문서보다 작동하는 소프트웨어 → 문서보다 실제 동작하는 소프트웨어를 만드는 것이 더 중요하다.
• 계약 협상보다 고객과의 협력 → 고객과 긴밀히 협력하며 요구사항을 유연하게 반영해야 한다.
• 계획을 따르는 것보다 변화에 대한 대응 → 초기 계획에 얽매이지 않고 변화에 빠르게 대응하는 것이 중요하다.
• 오른쪽도 중요하지만 왼쪽을 더 우선한다 → 기존 방식도 의미 있지만, 더 나은 소프트웨어 개발을 위해 유연한 접근이 필요하다.

1. 애자일 방법의 원칙

원칙설명

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

1. 애자일 방법이 효과적인 경우

: 변화에 유연하게 대응할 수 있는 개발 방식으로, 다음과 같은 경우에 특히 효과적이다.

• 제품 개발: 규모가 작은 소프트웨어나 중간 크기의 제품을 만들 때 적합하다.
• 소프트웨어 제품과 앱: 요즘 대부분의 소프트웨어와 앱은 애자일 방식으로 개발된다.
• 맞춤형 시스템 개발: 고객이 개발 과정에 적극적으로 참여할 수 있고, 외부의 복잡한 규칙이 적은 조직에서 효과적이다.

애자일 기법 - 극단적 프로그래밍

1. 극단적 프로그래밍이란?

: 1990년대 후반에 등장한 애자일 방법으로, 다양한 애자일 개발 기법을 도입했다.

1. 특징

1. XP는 '반복적 개발 방식'을 극한으로 적용한다.

• 하루에도 여러 번 '새로운 버전'이 빌드될 수 있다.
• 2주마다 고객에게 '증분된 기능'을 제공한다.
• 모든 빌드는 '모든 테스트'를 통과해야 한다
• 만약 테스트가 실패하면, 빌드는 허용되지 않는다.

1. XP의 관행 (주요 기법)

원칙/관행설명

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

1. XP와 애자일 원칙의 연관성

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

1. XP의 실제 적용

• XP는 기술적 요소에 집중하기 때문에 조직의 관리 방식과 통합하기 어려운 경우가 많다.
• 따라서, 애자일 개발에서는 XP의 일부 기법을 채택하여 사용한다.
• 핵심 기법
  • 사용자 스토리를 활용한 요구 사항 관리
  • 코드 리팩토링
  • 테스트 우선 개발 (TDD)
  • 페어 프로그래밍

요구 사항 관리: 사용자 스토리 (User Story)

• 고객이 직접 팀에 참여하여 요구 사항을 스토리 카드로 작성한다.
• 스토리는 개발 작업 단위로 나뉘며, 일정과 비용을 고려하여 릴리스에 포함될 항목을 결정한다.

리팩토링

1. 개념

• 코드의 기능은 유지하면서 내부 구조를 개선하는 과정
• 지속적인 개선을 통해 가독성을 높이고 유지보수를 쉽게 만듦

1. 기존 개발 방식과 XP의 차이점

• 일반적인 소프트웨어 공학 원칙
  • 변화에 대비하여 미리 설계하면 장기적으로 비용 절감 가능
• XP(익스트림 프로그래밍)에서의 관점
  • 미래의 변화를 정확히 예측하는 것은 불가능하므로, 사전 대비보다는 필요할 때 개선하는 것이 효율적

1. 리팩토링의 필요성

• 변화에 유연하게 대응할 수 있도록 코드 품질을 지속적으로 개선
• 가독성 향상 → 문서화 필요성 감소
• 코드 구조가 개선되어 유지보수가 쉬워짐
• 일부 경우, 아키텍처 수준의 리팩토링이 필요할 수 있으며, 이는 높은 비용이 발생

1. 리팩토링의 예시
2. 중복 코드 제거 → 클래스 계층을 재구성하여 코드 재사용성 증가
3. 명확한 이름 사용 → 속성과 메서드 이름을 직관적으로 변경하여 코드 이해도 향상
4. 코드 간소화 → 인라인 코드 제거 후, 라이브러리 메서드를 활용하여 유지보수 용이

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

1. 개념

• XP(익스트림 프로그래밍)에서는 '테스트'를 중심으로 개발하며, '코드 변경이 발생할 때마다' 반복적으로 테스트를 수행
• 자동화된 테스트를 활용하여 코드 품질을 지속적으로 유지 및 개선

1. XP에서의 테스트 특징

• 테스트 우선 개발 → 코드를 작성하기 전에 '테스트를 먼저 설계'
• 시나리오 기반 테스트 → 요구 사항을 반영한 '점진적 테스트 개발'
• 사용자 테스트 포함 → 고객이 테스트 과정에 참여하여 검증
• 자동화된 테스트 프레임워크 사용 → 새 릴리스가 빌드될 때 모든 컴포넌트 테스트 자동 실행

1. 테스트 주도 개발 (TDD, Test-Driven Development)

• 코드를 작성하기 전에 '테스트를 먼저 작성'하여 구현할 요구 사항을 명확히 함
• 테스트는 '코드 형태로 작성'되어 자동 실행 가능
• 테스트 코드가 실행 결과를 검증하여 '정확한 동작을 보장'
• 일반적으로 JUnit과 같은 테스트 프레임워크 활용
• 새로운 기능 추가 시, '기존 및 신규 테스트를 자동 실행'하여 기존 코드에 미치는 영향을 검증

1. 문제점

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

고객 참여

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

테스트 자동화 (Test Automation)

1. 개요

• 특정 기능을 구현하기 전에
• 실행 가능한 테스트를 작성하는 과정
• 테스트는 해야 하며, 해야 함입력과 출력을 검증
• 독립적으로 실행 가능

1. 테스트 자동화의 특징

특징설명

독립 실행 가능	개별 테스트가 다른 테스트에 의존하지 않고 단독으로 실행될 수 있어야 함
입력 시뮬레이션	실제 사용자 입력을 흉내 내어 테스트 진행
출력 검증	실행 결과가 기대값과 일치하는지 자동으로 확인

1. 테스트 자동화의 이점

이점설명

빠른 테스트 실행	자동화된 테스트를 활용하면 수동 테스트보다 훨씬 빠르게 검증 가능
지속적 검증	새로운 기능 추가 시 기존 테스트를 실행하여 코드 변경이 문제를 일으키지 않았는지 즉시 확인 가능
프레임워크 활용	JUnit과 같은 자동화 테스트 프레임워크를 사용하여 테스트 작성 및 실행이 용이함

페어 프로그래밍 (Pair Programming)

1. 개요

• 두 명의 프로그래머가 한 팀을 이루어 함께 코드를 개발하는 방식
• 코드 공동 소유권을 형성하여 팀 전체에 지식을 공유

1. 페어 프로그래밍의 특징

특징설명

실시간 코드 검토	한 사람이 작성한 코드가 즉시 검토되므로 비공식적인 코드 리뷰가 자연스럽게 이루어짐
리팩토링 촉진	코드 개선을 함께 논의하며 유지보수성을 높임
협력 개발	같은 컴퓨터에서 협력하여 소프트웨어를 개발
유동적인 페어 구성	개발 과정에서 팀원들이 다양한 사람과 협업할 기회를 가짐

1. 페어 프로그래밍의 장점

장점설명

지식 공유	팀원 간 기술과 도메인 지식을 효과적으로 공유 가능
리스크 감소	특정 개발자가 프로젝트를 떠나도 남은 팀원이 업무를 이해하고 이어받을 수 있음
생산성 향상	연구에 따르면 협력 개발이 개별 작업보다 높은 생산성을 보일 수 있음

애자일 프로젝트 관리 (Agile Project Management)

1. 개요

• 소프트웨어 프로젝트 관리자의 주요 목표는
• 일정 내 프로젝트 완료 및 예산 내 소프트웨어 제공
• 전통적인 프로젝트 관리:
  • 프로젝트 계획을 수립하고, 일정과 책임을 명확히 정의
• 계획 중심 접근 방식
• 애자일 프로젝트 관리:
• 점진적 개발과 유연한 조정 방식 적용

1. 스크럼 (Scrum)

• 특정 애자일 실천법이 아닌
• 반복적인 개발 관리에 초점을 맞춘 애자일 방법론

1. 스크럼의 3단계

단계설명

초기 계획 단계	프로젝트 목표 설정 및 소프트웨어 아키텍처 설계
스프린트 주기	각 주기(2~4주)마다 새로운 기능 개발
프로젝트 종료 단계	프로젝트 마무리, 문서화, 피드백 반영

1. Scrum 용어 및 정의

용어정의

개발 팀	최대 7명으로 구성된 자기 조직화된 개발 그룹
잠재적 출시 가능한 제품 증분	추가 작업 없이 최종 제품에 바로 적용될 수 있는 소프트웨어 증분
제품 백로그	수행해야 할 작업 목록 (기능 정의, 요구사항, 사용자 스토리 포함)
제품 소유자	제품의 기능 및 요구사항을 정의하고 우선순위 관리
스크럼	진행 상황을 점검하고 우선순위를 정하는 일일 회의
스크럼마스터	스크럼 프로세스를 조율하며 팀이 외부 방해 없이 작업할 수 있도록 지원
스프린트	개발 반복 주기 (일반적으로 2~4주 단위 진행)
속도 (Velocity)	한 스프린트에서 팀이 처리할 수 있는 작업량을 측정한 값

1. Scrum 스프린트 주기 (2~4주)

1. 스프린트 주기 흐름

단계설명

백로그 선정	제품 백로그에서 이번 스프린트에서 수행할 작업 선정
개발 진행	선정된 작업을 개발하며, 팀은 외부 간섭 없이 작업
일일 스크럼	진행 상황 공유, 문제 해결, 목표 조정
스프린트 종료 및 검토	개발된 기능을 이해관계자에게 시연하고 피드백 반영
새로운 스프린트 시작	이전 결과를 반영하여 새로운 스프린트 시작

1. Scrum의 팀워크

역할책임

스크럼마스터	일일 회의 주최, 백로그 관리, 진행 상황 추적, 외부 방해 요소 차단
개발 팀	코드 작성, 기능 구현, 문서화
제품 소유자	요구사항 정의 및 우선순위 조정
이해관계자	스프린트 결과 검토 및 피드백 제공

1. Scrum의 이점

이점설명

작업 관리 용이	제품이 작은 단위로 나뉘어 관리가 쉬움
유연한 대응	요구사항 변경이 발생해도 진행 가능
효율적인 커뮤니케이션	팀원 간 투명한 정보 공유
고객 피드백 반영	고객이 정기적으로 결과물을 확인하고 의견 제공
팀워크 강화	고객과 개발자 간 신뢰 및 협력 문화 조성

1. 분산된 Scrum (Distributed Scrum)

• 다양한 지역에 분산된 팀이 함께 협업하는 스크럼 방식
• 원격 환경에서도 일정한 프로세스 유지 필요
• 온라인 협업 도구 활용 (예: Jira, Trello, Slack, Zoom 등)

애자일 방법 확장 (Scaling Agile Methods)

1. 애자일 방법의 한계

• 애자일 방법은 함.
• 소규모 프로젝트나 같은 장소에서 협업하는 팀에 적합
• 팀원이 같은 공간에서 근무할 때 커뮤니케이션이 원활해짐.
• 대규모·장기 프로젝트에서는 애자일 방법을 확장할 필요가 있음.

1. 애자일 방법 확장 방식

확장 방식설명

확장 업 (Scaling up)	소규모 팀이 감당할 수 없는 대형 소프트웨어 개발 프로젝트에 애자일 방법 적용
확장 아웃 (Scaling out)	애자일 방법을 다년간의 소프트웨어 개발 경험이 있는 대규모 조직에 도입

• 확장하더라도 애자일의 기본 원칙(유연한 계획, 잦은 릴리스, 지속적 통합, 테스트 주도 개발, 원활한 팀 커뮤니케이션)을 유지해야 함.

3-1. 여러 가지 문제

1. 애자일 방법의 실용적 문제 (Practical Issues in Agile Development)

문제설명

비형식적인 개발 방식	애자일 개발의 비형식적 특성은 대기업에서 사용하는 계약 방식과 충돌 가능
적합성	애자일은 새로운 소프트웨어 개발에 적합하나, 소프트웨어 유지보수에는 적합하지 않을 수 있음
비용 지급 방식 문제	개발자의 시간 기준으로 비용을 지불하는 방식이 필요하지만, 법무팀에서 리스크가 크다고 판단할 가능성이 있음
활동 방식	애자일은 소규모 팀을 전제로 하지만, 현재 소프트웨어 개발은 전 세계에 분산된 팀들이 협업하는 경우가 많음

1. 계약 관련 문제

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

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

• 많은 조직이 새로운 소프트웨어 개발보다 기존 시스템 유지보수에 더 많은 비용을 지출함.
• 애자일이 유지보수까지 지원하려면 다음 문제 해결 필요:
  • 제품 문서 부족 → 유지보수 어려움
  • 고객과의 지속적인 협업 필요
  • 개발 팀의 연속성 유지 어려움
• 애자일 개발은 팀원들이 시스템을 잘 알고 있어야 한다.
  • 장기 운영 시스템에서는 원래 개발팀이 항상 유지 되지 않기 때문에, 문제 발생 가능성이 있다.

애자일 vs. 계획 기반 접근 (Agile vs. Plan-driven Approaches)

1. 혼합적 접근 방식

• 대부분의 프로젝트는 애자일과 계획 기반 접근을 혼합하여 사용함.
• 적절한 균형을 찾는 것이 중요함.

1. 애자일과 계획 기반 방법 비교

고려 요소애자일이 적합한 경우획 기반 접근이 필요한 경우

요구사항 정의	점진적 제공 방식이 가능할 때	세부 명세와 설계가 선행되어야 할 때
프로젝트 규모	소규모 프로젝트	대규모 프로젝트
예상 시스템 수명	단기 운영	장기 운영 → 유지보수 문서 필요
규제 준수 여부	비규제 시스템	규제를 받는 시스템 (상세 문서 요구됨)

애자일 원칙 vs. 조직 내 현실 (Agile Principles vs. Organizational Reality)

원칙현실적 문제

고객 참여	고객 대표자의 시간 부족, 외부 이해관계자(규제 기관 등)와의 소통 어려움
변화 수용	이해관계자마다 변경 요청의 우선순위가 달라 조정이 어려움
점진적 배포	비즈니스·마케팅 계획과 맞지 않을 가능성
단순성 유지	일정 압박으로 인해 코드 최적화 및 단순화에 시간 부족
사람 중심 접근	애자일 방식이 모든 개발자의 성향에 맞지 않을 수 있음

애자일과 계획 기반 접근법: 선택을 위한 고려 요소

1. 시스템 (System)

1. 유형 (Type)

• 애자일 적합: 요구사항이 자주 변경되는 시스템, 사용자 인터페이스 중심 애플리케이션
• 계획 기반 적합: 구현 전 많은 분석이 필요한 시스템, 복잡한 시스템 통합이 요구되는 경우

1. 수명 (Lifetime)

• 애자일 적합: 짧은 수명 또는 지속적 발전이 필요한 제품
• 계획 기반 적합: 장기간 운영될 시스템 (개발자 의도를 지원 팀에 전달할 문서화 필요)

1. 규모 (Scale)

• 애자일 적합: 비교적 소규모 시스템, 공동 작업 팀에서 비공식적 소통이 가능한 프로젝트
• 계획 기반 적합: 대규모 복잡한 시스템, 다수의 팀이 참여하는 프로젝트

1. 규제 (Regulation)

• 애자일 적합: 규제가 적은 분야의 시스템
• 계획 기반 적합: 외부 규제를 받는 시스템 (시스템 안전성 입증을 위한 상세 문서 필요)

1. 팀 (Team)

1. 기술 역량 (Competence)

• 애자일 적합: 높은 기술 수준을 갖춘 설계자와 프로그래머
• 계획 기반 적합: 다양한 기술 수준의 개발자가 혼합된 팀, 상세 설계를 코드로 변환하는 업무

1. 분산도 (Distribution)

• 애자일 적합: 동일 위치에서 작업하는 팀, 긴밀한 협업이 가능한 환경
• 계획 기반 적합: 지리적으로 분산된 팀 (원활한 소통을 위한 상세 설계 문서 필요)

1. 기술 (Technology)

• 애자일 적합: 시각화 및 프로그램 분석을 지원하는 현대적 IDE 사용 가능
• 계획 기반 적합: 특수 도메인의 개발 도구, 레거시 시스템 지원 도구

1. 조직 (Organization)

1. 문화 (Culture)

• 애자일 적합: 변화 수용적이고 유연한 문화, 실험과 학습을 장려하는 환경
• 계획 기반 적합: 전통적 엔지니어링 문화, 공식적 프로세스 중심 환경

1. 계약 (Contracts)

• 애자일 적합: 유연한 계약 구조, 지속적 고객 참여가 가능한 프로젝트
• 계획 기반 적합: 상세한 시스템 명세서가 요구되는 계약, 고정 가격 계약

1. 납품 (Delivery)

• 애자일 적합: 고객 대표가 시스템 증분에 대한 지속적 피드백 제공 가능
• 계획 기반 적합: 명확한 마일스톤 기반 납품, 사전 정의된 요구사항에 따른 검수

대형 시스템을 위한 애자일 방법론 (Agile Methods for Large-Scale Systems)

1. 구조

• 일반적으로 개별적으로 개발된 여러 시스템의 집합
• 각 시스템은 별도의 팀이 개발한다.
• 이러한 팀은 종종 서로 달느 장소에서, 때로는 서로 다른 시간대에서 작업한다.

1. 브라운필스 시스템

: 대형 시스템은 기존 시스템과 상호작용하는 브라운필드 시스템이다.

• 시스템 요구 사항 중 상당 부분이 기존 시스템과의 연동과 관련이 있기에, 유연한 증분 개발 방식이 어렵다.
• 따라서, 여러 시스템을 통합하여 하나의 시스템을 만들 경우, 개발 과정에서 코드 작성 보다는 시스템 구성이 주요 작업이 될 가능성이 크다.

대형 시스템 개발

1. 상황

: 대형 시스템과 그 개발 프로세스는 외부 규제 및 규칙에 의해 개발 방식이 제한되는 경우가 많다.

1. 기간

: 대형 시스템은 조달 및 개발 기간이 길다.

• 그 기간 동안 시스템을 깊이 이해하는 일관된 팀을 유지하기 어렵다.
• 결국 팀원들이 다른 업무나 프로젝트로 이동하게 된다.

1. 다양한 이해 관계자

: 대형 시스템은 다양한 이해 관계자를 포함한다.

• 모든 이해 관계자를 개발 과정에 참여시키는 것은 현실적으로 어렵다.

1. 고려해야 할 요소

• System of Systems : 여러 독립 시스템이 연결되어 협력하는 구조를 의미하며, 각 시스템의 통합 및 상호작용을 이해해야 한다.
• Brownfield Development : 기존 시스템을 기반으로 개선하는 개발 방식으로, 기존 시스템의 구조와 데이터를 충분히 고려해야 한다.
• Diverse Stakeholders : 다양한 이해 관계자가 포함되어 있으며, 이들의 요구를 충족시키는 것이 어렵기 때문에 효과적인 소통이 필요하다.
• Regulatory Constraints : 외부 법규 및 규제를 준수해야 하며, 이를 이해하고 충족하는 설계와 개발이 필요하다.
• System Configuration : 시스템 구성 요소 간의 조정 방법으로, 효율성과 안정성을 확보해야 한다.
• Prolonged Procurement : 대형 시스템 조달에 필요한 긴 시간으로, 팀의 일관성을 유지하기 어려워지므로 전문성과 지식을 지속적으로 유지해야 한다.

1. 대형 시스템으로의 확장

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

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

: 다중 팀 스크럼은 여러 팀이 함께 협력하여 효과적으로 작업할 수 있도록 지원한다.

1. 역할 복제 (Role Replication)

• 각 팀은 제품 소유자와 스크럼마스터를 두어, 자신이 맡은 작업을 관리한다.
• 제품 소유자는 제품의 방향을 정하고, 스크럼마스터는 팀이 스크럼 프로세스를 잘 따르도록 돕는다.

2. 제품 아키텍트 (Product Architects)

• 각 팀은 제품 아키텍트를 선택한다.
• 이 아키텍트들은 함께 협력하여 전체 시스템의 구조를 설계하고 발전시킨다.

3. 출시 일정 정렬 (Release Alignment)

• 모든 팀의 제품 출시 일정을 맞춘다.
• 이를 통해 모든 기능이 포함된 완전한 시스템을 만들어, 시연할 수 있도록 준비한다.

4. 스크럼 간 회의 (Scrum of Scrums)

• 각 팀의 대표들이 매일 모여 진행 상황을 공유하고, 다음 작업을 계획한다.
• 이 회의는 팀 간의 협력과 소통을 강화하는 데 도움을 준다.

조직 전반의 애자일 적용 (Enterprise-wide Agile Adoption)

: 대기업에서 애자일 적용이 어려운 이유

문제설명

기존 관리 방식과 충돌	애자일을 경험해보지 않은 관리자들이 새로운 접근 방식 도입을 부담스러워함
관료적 절차와 충돌	대형 조직에서는 표준화된 품질 절차 및 표준이 존재
팀원의 기술 편차	애자일이 높은 기술 수준을 요구하는데, 대형 조직에서는 다양한 실력의 개발자가 존재함
문화적 저항	기존 시스템 엔지니어링 프로세스를 오랫동안 사용해 온 조직에서는 애자일 도입에 대한 저항 발생