애자일 방법론의 종류

• Scrum
• Kanban
• Lean
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Dynamic Software Development Method (DSDM)

Scrum

• 스크럼은 애자일 소프트웨어 개발 과정의 하나로 다음과 같은 특성을 지니고 있음

  • 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여.
  • 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공.
  • 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공.
  • 날마다 15분 정도 회의.
  • 항상 팀 단위로 생각.
  • 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지.

중요 요소

• 제품 백로그(Product Backlog)

  • 개발할 제품에 대한 요구 사항 목록

• 스프린트(Sprint)

  • 반복적인 개발 주기 (회사에서 정하는 이터레이션이 개발 주기가 됨. 계획 회의 부터 제품 리뷰가 진행 되는 날짜 까지의 기간이 1스프린트임)

• 스프린트 계획 회의(Sprint Planning Meeting)

  • 스프린트 목표와 스프린트 백로그를 계획하는 회의

• 스프린트 백로그(Sprint Backlog)

  • 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

• 일일 스크럼 회의(Daily Scrum Meeting)

  • 날마다 진행되는 미팅 (어제 한일, 오늘 할일, 장애 현상 등을 공유)

• 실행 가능한 제품(shippable product)

  • 개발 스프린트의 결과로써 나오는 실행 가능한 제품

진행

• 스크럼에서는, 30일간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행하며, 권장기간은 30일 이지만, 스크럼 적응도 및 진행 상황에 따라 1주~4주의 유연성을 가짐.

• 상기 요소들을 아래와 같은 순서에 따라 사용하여 스크럼을 진행

  1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정함

  2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율. 조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 됨

  3. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당

  4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가짐

  5. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해

  6. 제품의 학습과 이해가 끝나면, 스프린트 회고를 통해 팀의 개발 프로세스에 대한 개선의 시간을 가짐

  7. 스프린트 기간 중 다음 스프린트를 준비 하기 위해 PO와 필요 인원이 모여 백로그를 준비하는 시간을 가짐

• 이러한 과정 뒤, 개발 팀원들은 주도적으로 스트린트 달성을 위한 작업을 자율적으로 정하며, 각 작업은 4~16시간 정도 소요가 되도록 정함

• 이를 통해 팀원들은 의사소통을 활발하게 주고 받게 되고 끈끈한 협업 체계를 가지게 됨

익스트림 프로그래밍(XP)

• 애자일 방법론 중 하나로, 비즈니스 상의 요구가 시시각각 변동이 심한 소규모 프로젝트에 적합한 개발 방법론

  • 10~12개 정도의 구체적인 실천 방법(Practice)을 정의

  • 짧은 주기로 여러번 고객에게 납품 반복

  • 개발 문서 보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기를 중시

절차

User Stories, Architectural Spike ▶ Release Planning ▶ Iteration
▶ Acceptance Test ▶ Small Release

사용자 스토리(User Stories)

• 사용자 요구사항 / UML의 유스케이스와 같은 목적(요구사항 수집, 의사소통 도구)
• 릴리즈 계획을 작성하기 위한 단위
• 기능단위로 필요한 내용을 간단하게 기재, 필요시 간단한 테스트 사항도 표기 가능
• 시스템을 사용하는 고객이 필요한 것이 무엇인지를 기술 → Acceptance Test시 사용

구조적 스파이크(Architectural Spike)

• 어려운 요구사항 혹은 잠재적인 솔루션들을 고려하기 위해 작성하는 간단한 프로그램
• 사용자 스토리의 신뢰성을 증대시키거나 기술적인 문제의 위험을 줄이고자 하는데 목적

릴리즈 계획(Release Planning)

• 전체 프로젝트에 대한 배포 계획을 생성

반복(Iteration)

• 하나의 반복을 1에서 3주 정도로 나누고 반복들을 프로젝트 전반에 균일하게 유지

• XP의 반복은 프로세스의 평가와 계획을 단순하고 신뢰성 있게 만드는 핵심 항목 → 반복 계획 미팅

• 사용자 요구사항 변경, 기술적인 문제 등 상황에 따라 릴리즈 및 반복 계획 수정 가능

인수 테스트(Acceptance Test)

• 릴리즈 전의 인수 테스트. 고객이 수행

소규모 릴리즈(Small Release)

• 소규모로 빈번하게 배포하면 고객에게 여러 가지 이득을 조기 제공

• 프로그램은 빠른 피드백을 제공 받음

실천사항

Fine scale feedback

• Pair Programming

  • 하나의 컴퓨터에 2명의 프로그래머가 모든 코드를 코딩과 리뷰 역할을 바꿔가며 공동작업 진행

• Planning Game

  • 사용자 스토리를 이용해 다음 릴리즈의 범위를 빠르게 결정

• Test Driven Development

  • 실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하여 무엇을 해야하는 지 깨우치며, 이를 기반으로 코드 작성

• Whole Team

  • 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴
  • 고객은 스토리를 명확하게 해주고, 중요 결정사항에 대해 명확하게 답을 제공

Continuous process

• Continuous Integration

  • 모듈 단위로 개발된 소스코드들을 하나의 작업이 끝날 때 마다 지속적으로 통합하고 동시에 테스트

• Design Improvement

  • 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성 수행

• Small Releases

  • 짧은 주기(2주 정도)로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 함

Shared understanding

• Coding Standards

  • 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성

• Collective Code Ownership

  • 시스템에 있는 소스코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정 가능함

• Simple Design

  • 가능한 가장 간결한 디자인 상태 유지

• System Metaphor

  • 최종적으로 개발 되어야 할 시스템의 구조를 기술

Programmer welfare

• Sustainable Pace

  • 일주일에 40 시간 이상 작업 금지, 2주 연속 오버타임 금지

Scrum vs XP

• Scrum의 스프린트는 2~4주 간 지속되지만, XP는 더 짧음

• Scrum은 스프린트 변경을 허용하지 않지만 XP는 반복 내 변경에 더 유연

• Scrum은 엔지니어링 관행을 제시하지 않음

  • XP는 TDD, 페어프로그래밍, 리팩토링과 같은 관행에 의해 주도

• Scrum은 팀이 개발 우선순위를 결정하지만, XP는 고객이 우선순위를 결정