5 분 소요



애자일 기법



신속한 소프트웨어 개발

신속한 개발 및 제공은 이제 소프트웨어 시스템의 가장 중요한 요구 사항이다. 계획 기반 개발은 일부 유형의 시스템에 필수적이지만 빠르게 움직이는 비즈니스 환경에서는 이 방식이 문제가 될 수 있다.

계획 주도 개발과 애자일 개발



애자일 개발

  1. 프로그램 명세, 설계 및 구현은* 인터리브드 된다.*

  2. 평가를 위해 새 버전을 자주 제공한다(점증적 개발).

  3. 개발을 지원하는 데 사용되는 광범위한 툴을 지원한다.(ex. 자동화 테스트 툴)

  4. 최소한의 문서로 작업 코드에 중점을 둔다.

계획 기반과 애자일 개발


계획중심 개발

  • 소프트웨어 엔지니어링에 대한 계획 중심 접근 방식은 사전에 계획된 각 단계에서 생성될 출력과 함께 별도의 개발 단계를 기반으로 한다.
  • 반복은 활동 내에서 발생한다.

애자일 개발

  • 명세, 설계, 구현 및 테스트가 인터리브드되고 개발 프로세스의 출력은 소프트웨어 개발 프로세스에서 협상 프로세스를 통해 결정됩니다.


애자일 기법

애자일 기법

  1. 디자인보다 코드에 집중

  2. 소프트웨어 개발에 대한 반복적 접근 방식을 기반

  3. 작동하는 소프트웨어를 신속하게 제공하고 변화하는 요구 사항을 충족하기 위해 이를 신속하게 발전시키기 위한 것입니다.

애자일 기법의 목표

  • 애자일 기법의 목표는 소프트웨어 프로세스의 오버헤드를 줄이고(문서를 줄인다) 과도한 재작업 없이 변화하는 요구 사항에 신속하게 대응할 수 있도록 하는 것

애자일 선언

에자일 기법의 철학적 배경으로 이 방법을 리드했던 개발자가 작성한 선언 우리는 보다 나은 소프트웨어를 개발하고, 다른 사람들이 이렇게 할 수 있도록 도와줌으로써 더 나은 소프트웨어를 개발하는 방법을 찾고있다. 이러한 작업을 통해 다음과 같은 가치를 찾아냈다.

  1. 프로세스와 도구보다는 개인과 상호작용을

  2. 이해하기 좋은 문서보다는 작동하는 소프트웨어를

  3. 계약 협상보다는 고객과의 협업을

  4. 계약을 따르기보다는 변화에 대응하는 것을

즉, 왼편에 적힌 내용도 가치가 있지만, 우리는 오른쪽에 적힌 내용에 더 많은 가치를 둔다.

애자일 기법 적용


애자일 기법은 특히 다음의 두 가지 유형의 시스템 개발에 성공적으로 적용할 수 있다.

  1. 소프트웨어 회사가 중소 규모의 제품을 판매할 목적으로 개발하는 경우, 사실상 요즘 모든 소프트웨어 제품과 앱은 애자일 기법을 적용해서 개발한다.

  2. 고객이 개발 프로세스에 참여하겠다는 확실한 의사가 있고, 소프트웨어에 영향을 줄 수 있는 외부 이해당사자나 규제가 거의 없는 조직내에서 이루어지는 맞춤형 시스템 개발인 경우

Extreme programming

익스트림 프로그래밍(XP)은 반복 개발에 극단적 접근 방식이다.

  • 버전은 하루에 여러 번 빌드될 수 있으다.
  • 증분은 2주마다 고객에게 전달된다.
  • 모든 빌드에 대해 테스트를 실행해야 하고 실패시 다시 1단계 부터한다. 모든테스트가 성공해야 빌드가 승인된다.

XP 및 애자일 원칙

  1. 소규모의 잦은 시스템 릴리즈를 통해 점증적 개발이 지원된다.

  2. 고객 참여는 고객이 개발팀에 지속적으로 참여하는 것으로 지원이 이루어진다.

  3. 페어 프로그래밍, 지속가능한 개발 프로세스를 통해 프로세스가 아닌 사람을 지원한다.

  4. 리팩토링과 새로운 기능의 연속적 통합을 통해 변화를 허용한다.

  5. 코드 품질을 향상시키는 끊임없는 리팩토링을 통해 단순성을 유지한다.

Key practices in XP

XP는 기술적인 초점을 가지고 있으며 대부분의 사업 분위기에서 쉽게 통합할 수 없었다



사용자 스토리

소프트웨어 요구는 항상 바뀌기 마련이다. 애자일 기법에서는 이러한 요구 변경을 처리하기 위해 별도의 요구공학 활동을 두지 않는다. 따라서 요구사항 도출과 개발을 함께 진행한다. 이 아이디어를 보다 쉽게 적용하도록, “사용자스토리”라는 개념을 만들었는데 이 사용자 스토리는 시스템 사용자가 경험할 수 있는 일종의 시나리오를 뜻한다.

이들은 카드에 기록되며 개발 팀은 이를 구현 작업으로 세분화한다. 이러한 작업은 일정 및 비용 견적의 기초가 된다.

고객은 우선순위와 예상 일정에 따라 다음 릴리즈에 포함할 스토리를 선택한다.


리팩토링

리팩토링은 소프트웨어 엔지니어링의 일반적인 통념은 변화를 위한 설계다. 변화를 예상하는 데 시간과 노력을 들일 가치가 있으며, XP에서는 변경 사항을 구현해야 할 때 쉽게 변경할 수 있도록 지속적인 코드 개선(리팩토링)을 제안한다.

프로그래밍 팀은 가능한 소프트웨어 개선 사항을 찾고 즉각적인 필요가 없는 경우에도 이러한 개선 사항을 적용한다.

리팩토링의 예시

  • 중복 코드를 제거하기 위한 클래스 계층 재구성
  • 이해하기 쉽도록 속성과 메소드를 정리하고 이름을 바꿈.
  • 프로그램 라이브러리에 포함된 메소드에 대한 호출로 인라인 코드를 대체


테스트 우선 개발

테스트는 XP의 중심이며 XP는 모든 변경이 이루어진 후 프로그램을 테스트하는 접근 방식을 개발했다.

XP 테스팅의 주요 특징

  • 테스트 우선 개발
  • 시나리오에서 점증적 테스트 개발
  • 테스트 개발 및 검증에 사용자 참여
  • 테스트 자동화 프레임워크 사용

테스트 기반 개발(test-driven development)

코드를 작성하기 전에 테스트를 작성하면 구현해야 할 요구 사항이 명확해진다.

  • 테스트 자동화
  • 테스트는 프로그램으로 작성
  • 테스트에는 올바르게 실행되었는지 확인하는 내용이 포함
  • 새 기능이 추가되면 모든 이전 및 새 테스트가 자동으로 실행

고객 참여

  • 테스트 프로세스에서 고객의 역할은 스토리에 대한 승인 테스트 개발을 돕는 것
  • 따라서 모든 새 코드는 고객이 필요로 하는 코드인지 확인하기 위해 검증됨
  • 그러나 고객 역할을 채택하는 사람들은 사용할 수 있는 시간이 제한되어 있음

테스트 자동화

테스트 자동화는 작업이 구현되기 전에 테스트가 실행 가능한 구성 요소로 작성됨을 의미한다.

  • 이러한 테스트 구성 요소는 독립형이어야 하고 테스트할 입력 제출을 시뮬레이션해야 하며 결과가 출력 명세를 충족하는지 확인해야 합니다.
  • 자동화된 테스트 프레임워크(e.g.Junit)는 실행 가능한 테스트를 쉽게 작성하고 실행할 테스트 세트를 제출할 수 있게 해주는 시스템입니다.

테스트 우선 개발의 문제점


  • 프로그래머는 테스트보다 프로그래밍을 선호하며 때로는 테스트를 작성할 때 지름길을 택하기도 한다.
  • 일부 테스트는 점진적으로 작성하기가 매우 어려울 수 있습니다.


페어 프로그래밍

페어 프로그래밍은 프로그래머가 쌍으로 작업하고 함께 코드를 개발하는 것이다.

  • 코드의 공통 소유권을 개발하고 팀 전체에 지식을 전파하는 데 도움이 된다.
  • 전체 팀이 시스템 코드를 개선함으로써 이익을 얻을 수 있으므로 리팩토링을 권장한다.
  • 2명의 프로그래머가 별도로 작업하는 것보다 한 쌍이 함께 작업하는 것이 더 효율적이다.





애자일 프로젝트 관리

프로젝트 관리에 대한 표준 접근 방식은 계획 중심이다.

  • 애자일 프로젝트 관리에는 점진적 개발과 애자일 메소드에 사용되는 방식에 맞게 조정된 다른 접근 방식이 필요합니다.

스크럼

스크럼은 특정 애자일 방식보다는 반복적인 개발 관리에 중점을 둔 애자일 방식입니다.

스크럼 용어


개발팀

  • 7명을 넘지 않아야 하는 자체 조직 소프트웨어 개발자 그룹
  • 개발자 그룹은 소프트웨어 및 기타 필수 프로젝트 문서 개발을 담당한다.

잠재적으로 전달 가능한 제품 증분

  • 스프린트에서 제공되는 소프트웨어 증분.
  • 아이디어는 이것이 ‘잠재적으로 전달 가능’해야 한다는 것이다.

제품 백로그

  • 이는 스크럼 팀이 해결해야 하는 ‘할 일 ‘의 목록이다.
  • 여기에는 소프트웨어, 소프트웨어 요구 사항, 사용자 스토리 또는 추가 작업에 대한 설명이 포함된다.

스크럼의 팀워크


스크럼 마스터

  • 매일 회의를 주선하는 조력자
  • 수행할 작업의 백로그를 추적
  • 결정을 기록하고 백로그에 대한 진행 상황을 측정
  • 팀 외부의 고객 및 경영진과 소통

모든 팀원

  • 짧은 일일 회의 참석
  • 정보 공유, 지난 회의 이후의 진행 상황, 발생한 문제 및 다음 날 계획에 대해 설명

데일리 스크럼 동안 각 팀원은 일반적으로 세 가지 질문에 답한다.

  • 팀이 스프린트 목표를 달성하는 데 기여한 어제 내가 완료한 것은 무엇인가?
  • 팀이 스프린트 목표를 달성하는 데 기여하기 위해 오늘 무엇을 완료할 계획인가?
  • 나 혹은 팀이 스프린트 목표를 달성하는 데 방해가 되는 장애물이 있나?

스크럼의 이점


  • 백로그를 기준으로 어디까지 개발했는지 알기 쉽다.
  • 불안정한 요구 사항을 잡고있지 않는다.
  • 팀 전체가 모든 것을 볼 수 있으므로 결과적으로 팀 커뮤니케이션이 향상된다.
  • 고객은 증분의 정시 전달을 확인하고 제품 작동 방식에 대한 피드백을 얻는다.
  • 고객과 개발자 사이에 신뢰가 형성





애자일 기법의 규모 조정

애자일 방법은 소규모 공동 배치 팀에서 개발할 수 있는 중소 규모 프로젝트에 성공적인 것으로 입증됐다.

애자일 방법을 확장하려면 서로 다른 위치에서 작업하는 여러 개발 팀이 있는 더 크고 긴 프로젝트에 대처하기 위해 이러한 방법을 변경해야 한다.

Scaling out과 Scaling up

Scaling up

  • 소규모 팀이 개발하기에는 어려운 대규모 시스템 개발을 다루기 위한 애자일 기법의 스케일 업

Scaling out

  • 특화된 개발 팀을 소프트웨어 개발 경험을 가지고 있는 대규모 회사에서 더 광범위하게 사용하기 위한 애자일 기법의 스케일 아웃

애자일 방법의 실질적 문제

  • 애자일 방법은 소프트웨어 유지 관리보다는 새로운 소프트웨어 개발에 가장 적합하다.
  • 애자일 방식은 공동 배치된 소규모 팀을 위해 설계되었지만 현재 많은 소프트웨어 개발에는 전 세계에 분산된 팀이 참여하고 있다.

계약 문제

  • 맞춤형 시스템에 대한 대부분의 소프트웨어 계약은 명세를 기반으로 한다.
  • 따라서 특정 요구사항을 개발한 것에 대한 비용이 아닌 스템 개발에 필요한 시간에 대한 비용을 지급하는 것으로 계약을 해야 한다.

댓글남기기

참고