CH3.2 소프트웨어 개발 프로세스

CH 3.2 소프트웨어 개발 프로세스

3.2.1 Agile 개발 프로세스 개요

3.2.2 유저 스토리

3.2.3 대표적인 Agile 방법론

 

3.2.1 Agile 개발 프로세스 개요

등장배경

 Agile 프로세스는 그 이름처럼 신속한 소프트웨어 개발을 위해 나온 프로세스이다. 소프트웨어를 신속하게 개발하기 위해서는 '잦은 요구사항 변경을 어떻게 해결하는가?' 가 중요하다. 명세서와 코드로는 사용자와 의사소통이 힘들기 때문에 유저에게 반복적으로 프로토타입을 개발하여 보여주고 피드백을 받는 것이 빠른 소프트웨어 개발의 방법이라고 할 수 있다. 

 

 사용자에게 가시적인 소프트웨어를 보여주는 개발 접근 방법이 애자일 개발 방법론이다.

 

반복적으로 개발

반복된 테스트

유저 피드백 반복적으로 반영

 

 애자일 소프트웨어 개발 선언은 애자일 방법론에 대한 핵심 원칙을 정리한 문서이다. 이 선언은 개인과 상호작용을, 작동하는 소프트웨어를, 고객과의 협력을, 변화에 대응할 것을 강조하고있다.

 

전통적 방법론 VS 애자일 방법론

대상	애자일 방법론	전통적 방법론
계획 수립	유동적으로 범위 설정	확정적으로 범위 설정
업무 수행	팀 중심 업무	관리자 중심 업무
개발 및 검증	반복 주기 단위로 개발 및 검증	분석부터 테스트까지 순차적 수행
팀 관리	팀 평가	개별 평가
문서화	코드를 강조	상세한 문서화 강조
성공 요소	고객 가치 전달	계획/일정 준수
유형	XP, 스크럼, 린	폭포수, 프로토타입 등

 

Agile 개발 프로세스

 애자일 개발 방법론은 기민한, 좋은 것을 빠르고 낭비 없게 만드는 개발 방법론을 통틀어 이야기한다. 프로젝트 기간을 짧은 주기로 나누어 반복적인 개발을 하는 개념적 방법인 것이다.

 

 애자일 개발 방법론에는 XP, 스크럼, 린 등 다양한 프로세스가 있지만 공통적으로 가지고 있는 원리 12가지가 있다.

1. 고객 만족을 가능한 한 빨리 이끌어내고, 유연한 소프트웨어를 지속적으로 사용자에게 제공한다.
2. 개발 과정에서 늦은 시점일지라도 요구 사항 변경을 적극 수용한다.
3. 실행 가능한 소프트웨어를 1~2주에 한 번씩 사용자에게 배포한다.
4. 사용자와 개발자 간 친밀한 미팅을 거의 매일 수행한다.
5. 프로젝트는 신뢰할 수 있고 동기가 부여된 개인을 중심으로 진행한다.
6. 의사소통을 위해 가능하면 한 곳에 모여 대화한다.
7. 실행 가능한 소프트웨어를 기준으로 프로젝트 진척률을 결정한다.
8. 일정한 개발 속도를 유지하며, 지속 가능하도록 소프트웨어를 개발하나.
9. 우수한 기술의 도입과 좋은 설계에 지속적인 관심을 갖는다.
10. 단순화는 필수다. 작업을 가장 단순한 형태로 분리하여 고민하고 해결한다.
11. 최상의 아키텍처, 정제된 요구사항, 좋은 설계는 잘 구성된 팀을 통해 개발된다.
12. 팀은 더 효과적인 방법의 적용, 적절한 조정 과정을 정기적으로 수행한다.

 애자일 개발 방법론은 기존 프로세스의 장점을 최대한 취합하여 만들어졌다.

 

반복 별로 최소한의 가치를 빠르게 제공하자!

유연하게 기능의 우선순위를 조정하자!

반복하면서 점진적으로 작업하자!

 

위의 세 원리가 애자일 개발 방법론의 핵심 원리이다.

 

3.2.2 유저 스토리

 빠르고 기민하게 소프트웨어를 개발해야하는 애자일 방법론은 기존 소프트웨어에 개발에 쓰이던 요구사항 문서 대신 유저 스토리를 요구한다.

 

유저스토리란?

 고객이 자신의 소프트웨어에 원하는 기능을 짧게 표현한 것으로, 프로덕트 백로그 관리에 사용된다.

 

 유저들은 스토리, 즉 원하는 기능을 우선 순위대로 적는다. 유저 스토리는 [사용자]는 [목적]을 위해서 [활동/작업] 하기를 원한다, 의 방식으로 기술한다. 각 유저 스토리는 과제와 테스트 기준을 가지고 있다. 과제는 이 유저 스토리 구현하기 위해 개발자가 해야할 일이고, 테스트는 유저 스토리가 잘 작동하는지 검증하는 작업이다.

 

좋은 유저 스토리의 조건

 아무렇게나 필요한 기능을 마구 적는다고 모두 좋은 유저 스토리는 아니다. 좋은 유저 스토리의 요건으로 INVEST가 있다.

• Independert 독립적 : 유저 스토리는 독립적이어야한다. 다른 유저 스토리에 지나치게 의존하면 안된다.
• Negotiable 협상 가능 : 규모 측면에서 '협상 가능' 해야한다. 리소스를 고려해 규모를 유동적으로 설정할 수 있어야한다.
• Valuable 가치있는 : 유저 스토리는 가치가 있어야한다. 여기서의 가치는 고객의 관점에서 평가해야한다.
• Estimable 측정 가능한 : 유저 스토리 개발에 드는 리소스를 측정 가능 해야한다.
• Small : 유저 스토리의 리소스는 범위가 작아야한다. 그래야 측정가능하고 독립적일 수 있다.
• Testable : 유저 스토리가 잘 개발되었는지 알기 위해 '테스트 가능' 해야 한다.

3.2.3 대표적인 Agile 방법론

 Agile 방법론에는 다양한 프로세스가 있지만 이번 시간에는 XP, 스크럼, 테스트 주도 개발 프로세스를 위주로 알아볼 것이다.

 

XP 프로세스

 XP 프로세스는 반복 개발이라는 접근 방법을 기반으로 하고 있으며, 새로운 버전의 소프트웨어가 하루에도 몇 번씩 개발된다.

 

• 엔지니어링 사이클 : 코딩 → 테스트 → 사용자 피드백 → 설계 → 반복
• 배포 사이클 : 사용자 스토리 선정 → 스토리 분할 및 태스크 식별 → 배포 계획 수립 → 개발/통합/테스트 → 소프트웨어 배포 → 시스템 평가 및 피드백 →  반복

이러한 XP 프로세스는 요구사항이 시시각각 변동이 심한 경우 적합한 방법론이며, 적은 규모 인원의 개발 프로젝트에 적합하다.

 

• XP 프로세스의 10가지 실천사항
  • 증분 계획 : 사용자 요구 사항을 스토리 카드에 기록하며, 배포 시 들어갈 스토리는 사용 가능한 시간과 상대적 우선 순위에 따라 결정한다. 개발자는 이러한 스토리를 개발의 단위 태스크로 분리한다.
  • 작은 배포 : 비즈니스 가치를 제공할 수 있는 최소한의 유용한 기능을 먼저 개발하여 배포한다. 소프트웨어 시스템 배포의 경우, 첫 번째로 배포된 소프트웨어에 기능을 점진적으로 추가하면서 배포한다.
  • 단순 설게 : 추후 나올 가능성이 있는 요구사항이 아닌 현재의 요구사항을 충족 시키도록 설계를 수행한다.
  • 테스트 우선 개발 : 기능 자체가 구현되기 전에 새로운 기능에 대한 테스트를 수행하기 위해 자동화 된 단위 테스트 프레임 워크를 사용한다.
  • 재구조화 : 모든 개발자는 코드 개선이 가능한 부분을 발견하는 즉시 코드를 재구조화 해야한다. 이를 통해 코드를 간단하고 쉽게 유지보수 할 수 있다.
  • 짝 프로그래밍 : 개발자는 쌍으로 작업하여 서로의 작업을 확인하고, 항상 훌륭한 작업을 수행할 수 있도록 지원한다.
  • 공동 소유권 : 개발자들은 시스템의 전 영역에 개발 작업을 수행함으로써, 경험과 전문 지식이 상호 연관되어 적용될 수 있다. 이로 인하여 모든 개발자가 모든 코드를 책임을 지며, 누구나 아무거나 변경할 수 있도록 한다.
  • 지속적 통합 : 단위 태스크가 완료되자마자 이는 전체 시스템에 통합한다. 통합한 후, 시스템에 대한 모든 단위 테스트가 통과되어야한다.
  • 지속 가능한 개발 속도 : 초과 근무가 많아지면 종종 코드 품질이 저하되고 중간 생산성이 감소할 수 있으므로 허용되지 않는다.
  • 현장 고객 : 고객/사용자 대표는 XP 개발 팀이 항상 접촉할 수 있어야 한다. XP 프로세스에서 고객은 개발 팀의 구성원이며, 고객은 소프트웨어 구현을 위해 시스템 요구사항을 팀에 제공해야한다.

스크럼 프로세스

 스크럼 프로세스는 소프트웨어 개발에 대한 실천사항을 강조하기보다 팀 중심의 반복적인 개발의 관리 관점을 강조하였다. 

• 스크럼 프로세스 용어
  • 스프린트 : 반복적인 개발 주기, 계획 회의부터 제품 리뷰가 진행되는 날짜까지의 기간이 1 스프린트.
  • 백로그 : 완료되지 않은 작업 목록.
  • 제품 백로그 : 개발할 제품에 대한 요구사항 목록.
  • 스프린트 백로그 : 스프린트 목표에 도달하기 위해 필요한 작업 목록.
  • 번다운 차트 : 스프린트 백로그에 남아 있는 작업량을 보여주는 차트.
  • 번업 차트 : 배포에 필요한 진행 사항, 진척도를 보여주는 차트.
  • 제품 책임자: 제품 백로그를 정의하여 우선순위를 정하는 책임자.
  • 스크럼 마스터 : 프로젝트 관리자.
• 스크럼 프레임워크
  • 소프트웨어에 포함할 기능 및 개선점에 대한 우선순위를 부여
  • 개발 주기는 30일 정도로 하며, 개발 주기마다 실제 동작할 수 있는 결과를 제공
  • 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공
  • 날마다 15분 정도 회의
  • 항상 팀 단위로 생각
  • 원활한 의사소통을 할 수 있도록, 구분 없는 열린 공간을 유지
• 스크럼 프로세스

데일리 스크럼 : 매일 15분씩 회의

백로그 관리 : 완료되지 않은 작업 목록을 중요도에 따라 구분한다. 스크럼 반.

번다운 차트 : 스프린트 백로그에 남아 있는, 해야할 일 작업량 차트.

번업 차트 : 배포에 필요한 진행사항, 즉 진척도를 나타내는 차트. 

 

XP 프로세스와 스크럼 프로세스를 비교해보자.

대상	Scrum	XP
주기	1~4주	더 짧음
변경 허용	X	유연한 변경 허용
공학 관행	제시 안됨	TDD, Pair programming 등의 실천 사항
우선순위 결정자	팀	고객

 

테스트 주도 개발

 기능 구현 전, 기능 검증을 위한 테스트를 먼저 작성하고 테스트를 통과하는 코드를 작성하는 반복적인 과정.

•  RED-GREEN-REFACTORING 사이클
  • RED : 실패하는 테스트 작성
  • GREEN : 테스트를 통과하도록 기능 코드 작성
  • REFACTORING : 코드 정리