소프트웨어 공학과 개발 프로세스_3

1. 애자일 프로세스 모델

애자일(agile)의 사전적 의미는 '날렵한', '민첩한'입니다.

애자일 프로세스(aglie process) 모델은 고객의 요구에 민첩하게 대응하고 그때마다 주어진 문제를 풀어가는 방법론

 

애자일의 기본 가치

• 프로세스와 도구 중심 X, 개개인과의 상호 소통 중시
• 문서 중심 X, 실행 가능한 SW 중시
• 계약과 협상 중심 X, 고객과의 협력 중시
• 계획 중심 X, 변화에 대한 민첩한 대응 중시

💡애자일은 고객과의 협업, 빠른 시간 안에 고객이 작동해볼 수 있는 SW, 환경과 고객의 변화에 능동적으로 대처하는 것 강조!

 

---

 

애자일의 개발 방법

반복적인 개발을 통해 잦은 출시를 목표로 함

Ex. 애자일 개발 방법

 

---

 

2. 애자일 프로세스 모델 vs 폭포수 모델

애자일 프로세스 모델과 폭포수 모델의 비교

구분	애자일 프로세스 모델	폭포수 모델
추가 요구사항의 수용	추가 요구 사항을 수용 가능 방법의 설계	추가 요구 사항을 반영하기 어려운 구조
릴리스 시점	수시로 릴리즈	최종 완성된 제품을 릴리스
시작 상태	시작 단계는 미흡, 점차 완성도↑	시작 단계에서의 완성도가 매우 높음
고객과의 의사소통	처음부터 유저의 참여 유도, 대화를 통한 개발 진행	사용자와 산출물의 근거 중심,  대화 부족
진행 상황 점검	개발자와 사용자는 개발 초기부터  진행 상황 공유	단계별 산출물에 대한 결과로  개발의 진척 상황을 점검
분석/설계/구현 진행 과정	하나의 단계 또는 반복 안에 분석/설계/ 구현 과정이 모두 포함되어 동시에 진행	분석/설계/구현 과정이 명확
모듈(컴포넌트) 통합	개발 초기부터 빈번한 통합, 문제점을  빨리 발견하고 수정하는 방식	구현이 완료된 후에 모듈 간의 통합 작업을 수행

애자일은 변화에 민감하게 대처할 수 있는 개발 방법론이 많지만 여기선 스크럼(Scrum)과 익스트림 프로그램(eXtreme Programming, XP)를 중심으로 서술합니다.

 

---

3. XP(eXtreme Programming, XP)

XP에 대하여.. 이 부분은 참고 자료 2번째 이미지를 많이 참고하고 동봉하였습니다 ㅠ

Ex. XP 모듈 이미지

용어 정리

 

유저스토리(User Story) : 사용자의 요구 정리 명세서

스파이크 : 어려운 요구 사항 혹은 잠재적 문제점을 해결하기 위한 간단한 프로그램

XP(Extreme Programming) 기본 개념

• 고객이 원하는 양질의 SW를 짧은 시간에 구축 및 전달
• Agile 기법 : 즉시 변경, 경량화 기법
  - 고객의 요구사항은 변경된다는 가정
• 5개의 가치(Value), 13개의 실천사항(Practice) 제시

---

XP 특징

• 모바일이나 쇼핑몰처럼 즉각 요구가 반영되어야 하는 분야에 적합
• 신기술의 도입, 경험부족, 이해가 부족한 상황
• 나선형 모델을 좀 더 극단적으로 사용(위험분석)
  -시험을 강조
  
• 개발자가 소규모(10명 내외), 같은 공간 사용 시 적합

---

XP 5가지 가치

• 의사소통(Communications)
  • 고객, 개발자, 관리자간의 원활한 의사소통
  • On-site 고객, Whole-팀, Stand-up 미팅
• 피드백(Feedback)
  • 신속한 개발 → 고객과 시험 → 신규 요구 반영
  • 지속적으로 시험결과를 통합 → 도출 결과 반영
• 단순성(Simplicity)
  • 설계의 단순함
    - 군더더기 제거, 100% 정상 코드 추구
  • 문서화 축소
• 용기(Courage)
  • 요구사항 및 기술변경에 대해 용기있게 대처
• 존중 : 위에 4가지 뒤에 숨겨진 가치로 팀에 속한 사람들의 존중(단, 이 존중은 가치로 취급받지 않는 경우가 다반이다)

---

XP 개발활동

Ex. 개발활동 이미지

---

XP 역할분담

Ex. 역할 분담 이미지

Ex. XP 개발 활동 이미지(by. 쇼핑몰)

 

---

4. 스크림(Scrum)

스크림은 원래 럭비 경기에서 사용하는 용어입니다.

스크림은 소프트웨어 개발보다는 팀의 개선과 프로젝트 관리에 중점을 둔 애자일 방법론!
단, 구체적인 프로세스를 명확하게 제시 X

Ex. 스크럼 방식

위 그림은 스크럼 방식의 진행 과정을 정리한 모습이며 단계 번호의 과정은 아래 그림과 동일합니다.

Ex. 스크럼 방식의 진행 절차

스크럼 개발 프로세스

•  소프트웨어 개발보다는 팀의 개선과 프로젝트 관리를 위한 애자일 방법론
• 경험적 관리 기법 중 하나
• 구체적인 프로세스를 명확하게 제시하지 않음
• 개발 팀(조직)을 운영하는 효율적인 운영 방식(지침)

 

이젠 위 그림과 과정을 생각하며 용어 정리를 마무리로 끝마치겠습니다. 용어 설명 후 다시 한번

위 스크럼 방식 이미지를 보시고 정리하시면 됩니다.

---

스크럼 방식에서 사용되는 용어 설명

💡Keyword

---

제품 기능 목록(Product Backlog), 사용자 스토리(User Story), 스토리 포인트(Story Point), 스프린트(Sprint),

스프린트 구현 목록(Sprint Backlog), 소멸 차트(Burndown Chart),  일일 스크럼 회의(daily scrum meeting),

스프린트 현황판(Task Board), 스프린트 검토회의(Sprint Review),  스프린트 회고(Sprint Retrospective),

배포 목록(Release Backlog),  제품 책임자, 스크럼 마스터, 스크럼 팀

제품 기능 목록(Product Backlog) 작성

우선순위가 매겨진 사용자의 요구 사항 목록

Ex. 제품 기능 목록

---

사용자 스토리(User Story) 작성

 

제품 기능이 도출되면 각 기능을 서술하는데, 이때 사용되는 것이 사용자 스토리
즉, 메모지 한 장에 구현할 기능을 유저 관점에서 작성한 사용자 요구 사항

📋Tip : 개발에 필요한 구체적인 내용은 사용자 스토리에서 작성 X 뒤에 나오는 스프린트에 작성

​사용자 스토리지 Tip

• 카드(Card) : 기능을 서술하는 것으로 포스트잇을 많이 사용
• 대화(Conversation) : 사용자와 개발자가 충분한 대화를 통해 요구사항 도출
• 확인(Confirmation) : 스토리가 완료되는 조건을 서술

---

스토리 포인트(Story Point) 산정

요구사항의 규모를 측정하는 단위로 업무량을 이용해 산정
대체로 개발자가 주도적 역할이지만 사용자 스토리의 중요도를 판단하는 일은 주로 업무 분석가가 함

📋Tip - 스토리 포인트 : 사용자 스토리를 수행하는데 걸리는 상대적인 개발 기간(시간)
- 일반적인 SW 개발 방법론 : 개발에 소요되는 시간을 일/주/월과 같은 시간 단위로 예측
- 애자일 방법론 : 일/주/월의 시간 단위를 스토리 포인트라는 추상적인 개념으로 바꿔서 사용
- 스토리 포인트 예측 : 요구사항의 난이도, 걸리는 시간, 복잡도를 고려해 스토리 포인트 결정
Ex) 이번 프로젝트는 난이도, 복잡도를 고려해 1시간을 1포인트로 결정 

---

스프린트 계획 수립

스프린트(Sprint)의 사전적 의미는 "전력 질주"입니다.

작업량으로 볼 때 그렇게 많지 않고, 개발 기간도 짧다.
즉, 작은 단위의 개발 업무를 단기간 내에 전력 질주하여 개발한다는 뜻

Ex. 스프린트 이미지(스토리 보드)

하나의 스프린트엔 어떤 사용자 스토리를 몇 개 포함할 것인지 등을 스프린트 계획 회의에서 결정합니다.

그렇다면 스크럼에서 스프린트는 보통 1~4주 정도를 하나의 스프린트로 봅니다. 이 기간도 회의를 통해 결정돼요.

여러 가지를 하지만 이때 외부의 개발 방해 요소를 차단하는 것이 가장 큰 역할인 스크럼 마스터도 있지요

하나의 스프린트는 개발 완료 여부와 관계없이 정해진 일정이 지나면 끝

스프린트 계획을 세우기 위한 계획 회의는 크게 다음 두 가지로 나눌 수 있습니다.

• 전체적인 스프린트 계획 회의
  • 제품 책임자를 통해 사용자가 원하는 것이 무엇인지 파악하는데 중점
  • 스크럼 마스터는 제품 기능 목록 검토하면서 항목들 우선순위 지정 및 확인
• 세부적인 스프린트 계획 회의
  • 우선순위가 높은 항목을 어떻게 구현할 것인지 구체적인 작업 계획 

 

스프린트 구현 목록(Sprint Backlog)

- 각각의 스프린트 주기에서 개발할 작업 목록

- 세부 작업 항목과 작업자, 예상 작업 시간 등에 관한 정보를 작성

Ex. 스프린트 구현 목록 이미지

---

소멸 차트(Burndown Chart)

- 시간이 지남에 따라 소멸되고 남은 것을 표현
- 계획 대비 작업이 어떻게 진행되고 있는지를 날짜별로 남은 작업량으로 표현

Ex. 소멸 차트 이미지

---

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

일일 스크럼 회의는 스프린트 기간에 하는 회의로 다음과 같은 특징이 있음

• 매일 한다
• 짧게(15분 정도) 한다
• 진행 상황만 점검
• 한 사람씩 어제(오늘) 한(할) 일을 얘기함

---

스프린트 현황판(Task Board)

개발 팀의 개발 현황(진척도, 남은 작업, 진행 속도)을 나타냄

Ex. 스프린트 현황판 이미지

---

스프린트 검토 회의(Sprint Review)

하나의 스프린트 반복 주기(1~4주)가 끝났을 때 생성되는 실행 가능한 제품에 대해 검토

- 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인
- 전체 흐름을 확인하여 비즈니스 가치를 점검

---

스프린트 회고(Sprint Retrospective)

회고의 사전적 의미는 지나간 일을 돌이켜 생각해보는 것을 스프린트와 합쳐 사용

 

- 문제점을 확인하고 기록하는 정도로만 진행
- 스프린트에서 수행한 활동과 개발한 것을 되돌아 봄
- 개선점은 없는지, 팀이 정한 규칙이나 표준을 잘 준수했는지 등을 검토

---

배포 목록(Release Backlog)

여기서 배포는 사용자에게 시스템 일부를 제공하는 것으로 그것을 목록으로 나타내어 릴리스를 출시!

---

Ex. 스크럼 방식

• 장점
  • 반복 주기마다 생산되는 실행 가능한 제품을 통해 사용자와 충분한 의견 조율 가능
  • 일일 회의를 함으로써 팀원들 간에 신속한 협조와 조율이 가능
  • 다른 개발 방법론에 비해 단순하고 실천 지향적
• 단점
  • 추가 작업 시간 필요
    - 반복 주기가 끝날 때마다 실행 가능하거나 테스트할 수 있는 제품을 만들어야 함
  • 일일 스크럼 회의를 15분 안에 마쳐야 함
    - 매우 간략하게 이야기해야 하므로 때로는 회의 시간으로 인한 작업 방해
  • 투입 공수 불측정에 따른 효율성 저하
    - 투입 공수를 측정하기 어렵기에 작업이 얼마나 효율적으로 수행되는지 알기 어려움
    

---

참고 자료

쉽게 배우는 소프트웨어 공학 - 교보문고

 

Chatpter 02 소프트웨어 개발 프로세스 01 소프트웨어 개발 프로세스의 이해 02 소프트웨어 프로세스

 

01_소프트웨어_개발(1)

참고 이미지

Chatpter 02 소프트웨어 개발 프로세스 01 소프트웨어 개발 프로세스의 이해 02 소프트웨어 프로세스