해당 게시글은 topcit 학습 자료실에서 제공하는 에센스에서 발췌 및 요약한 내용입니다.
소프트웨어 공학의 배경과 목적
소프트웨어 공학 소개
성공적인 다기능 및 대규모 소프트웨어 개발을 위해 소프트웨어 공학 기술의 적용이 중요하다. 이를 위해서는 세 가지 핵심 요소가 필수적이다.
•
프로세스(Process)
◦
체계적인 업무 방식과 흐름을 정의하여 이를 적용할 수 있는 효율적인 프로세스를 개발하고 유지해야 한다.
•
인력(People)
◦
전문적인 지식을 갖춘 조직 및 인력을 구성하여, 정의된 업무 방식을 효과적으로 수행할 수 있게 해야 한다.
•
기술(Technology)
◦
업무 방식과 인력이 효율적으로 운영될 수 있도록 지원하는 기반 인프라 기술을 갖추어야 한다.
소프트웨어 공학 배경
소프트웨어 공학의 변천사는 다음과 같이 발전해 왔다.
•
1950년대
◦
하드웨어 공학과 유사한 개념을 소프트웨어 개발에 도입하기 시작했다.
•
1960년대
◦
소프트웨어 수요 증가와 인력 부족으로 인해 "소프트웨어의 위기"가 발생하며 소프트웨어 공학이 본격적으로 도입되었다.
•
1970년대
◦
소프트웨어 개발 인력 부족 문제를 해결하기 위해 비전공자들이 대거 투입되었고, 선코딩 후수정 방식이 널리 사용되었지만 많은 결함이 발생했다. 이를 해결하기 위해 구조적 및 정형적 기법과 폭포수 모델이 도입되었다.
•
1980년대
◦
폭포수 모델의 비용과 진행 속도 문제를 인식하고 소프트웨어 재사용성과 생산성을 높이기 위한 연구가 활성화되었다.
•
1990년대
◦
제품의 시장 출시 시간을 단축시키기 위해 소프트웨어 개발 생산성에 대한 연구가 강화되었고, 요구사항과 설계, 구현을 동시에 진행할 수 있는 동시공학 모델이 활용되었다.
•
2000년대
◦
시장 환경의 급속한 변화에 효과적으로 대응하기 위해 애자일 방법론이 본격적으로 도입되었다.
소프트웨어 공학의 4가지 중요요소
방법 (Methods)
•
프로젝트 계획 수립, 추정, 시스템 및 소프트웨어 분석, 자료구조, 프로그램 구조, 알고리즘, 코딩, 테스팅, 유지 관리 등을 포함하는 다양한 작업을 체계적으로 다룸.
•
특수한 언어 중심 또는 그래프 표기법을 도입하며, 소프트웨어 품질에 대한 평가 기준을 설정.
도구 (Tools)
•
생산성 또는 일관성 향상을 위해 방법들을 자동화하거나 반자동화하는 도구들.
•
요구 관리 도구, 모델링 도구, 형상 관리 도구, 변경 관리 도구 등이 소프트웨어 개발 생명주기에서 활용됨.
•
도구들이 통합되어 서로 정보를 공유하며, 효과적인 소프트웨어 개발을 지원.
절차 (Procedures)
•
방법과 도구를 결합하여 소프트웨어 개발을 합리적이고 적시에 할 수 있도록 지원.
•
적용된 방법들, 요구되는 결과물(문서, 보고서 등), 품질 보증 및 변경 조정을 돕는 제어들, 그리고 소프트웨어 관리자가 진행을 평가할 수 있는 마일스톤을 정의.
사람 (People)
•
소프트웨어 공학은 사람과 조직에 크게 의존하며, 소프트웨어 개발 과정에서 다양한 이슈가 발생.
•
다른 공학 분야보다 더 복잡하고 다양한 문제들이 존재하므로, 소프트웨어 개발을 공학적으로 정리하는 것이 현실적으로 어려움.
소프트웨어 개발 생명주기
정의
•
사용자 환경과 문제점을 이해하는 것에서 시작하여 운용 및 유지보수에 이르기까지의 모든 과정을 포함.
•
일반적인 활동으로는 타당성 검토, 개발 계획, 요구사항 분석, 설계, 구현, 테스트, 운용, 유지보수가 있음.
목적
•
프로젝트 비용 산정 및 개발 계획 수립.
•
용어의 표준화와 프로젝트 관리.
소프트웨어 생명주기 선정
•
기업에서는 프로젝트의 개발 프로세스를 맞춤화하는 것이 중요.
•
시스템 개발의 리스크와 불확실성을 이해하고 기반으로 모델을 선택.
•
선택한 모델은 프로젝트의 리스크와 불확실성을 최소화할 수 있어야 함.
•
대표적인 모델로는 폭포수 모델, 프로토타입 모델, 진화적 모델, 점증적 모델 등이 있음.
소프트웨어 생명주기 모델 종류
•
여러 소프트웨어 생명주기 모델이 존재하며, 프로젝트의 특성에 따라 모델을 변경하여 사용 가능.
•
생명주기 모델은 프로젝트에 적용 가능한 예들 중 일부일 뿐이며, 가장 많이 사용되는 모델들을 포함.
V 모델
V 모델은 소프트웨어 개발 생명주기 모델 중 하나로, 프로젝트의 요구사항이 명확할 때 이상적으로 적용되며 다음과 같은 특징을 갖고 있다.
V 모델은 표준 통신 프로토콜을 구현하는 프로젝트 같은, 요구사항이 미리 잘 정의되고 표준화된 경우에 특히 적합하다.
•
명확성 제공
◦
프로젝트 관리자와 개발자에게 수행해야 할 활동을 명확하게 보여줌.
◦
소프트웨어 개발에 대해 잘 알지 못하는 고객도 이해하기 용이.
•
요구사항 식별 중요성
◦
요구사항이 모두 식별되고 명확해야 최종적인 상세 계획이 완성됨.
◦
요구사항이 명확하지 않은 경우, 프로젝트의 초기 계획은 시작/종료일, 주요 리스크, 가정과 의존 관계 등을 포함하여 기술해야 함.
•
검증 및 확인 강조
◦
프로젝트의 검증(Verification)과 확인(Validation)에 중점을 둠.
◦
개발 활동과 해당하는 테스트 활동이 전체 개발 주기 동안 병행됨.
◦
결함 발견 시 어느 개발 단계를 재수행해야 하는지 파악 가능.
•
적용 및 관리 용이성
◦
프로젝트에 적용하고 관리하기가 용이함.
◦
개발 활동의 시작과 종료 조건 및 프로젝트를 효과적으로 관리할 수 있는 척도가 명확하게 정의됨.
VP 모델
VP 모델은 V 모델에 프로토타이핑 기법을 통합한 소프트웨어 개발 생명주기 모델로, 프로젝트의 불확실성과 리스크를 줄이는 데 도움을 준다. 프로토타이핑은 빠르게 시스템이나 그 일부를 개발하여 개발자와 고객 간의 공통 이해를 증진시키는 방법이다. 이 모델은 다음 두 가지 주요 접근 방법을 포함한다
VP 모델은 V 모델의 구조를 유지하면서 프로토타이핑을 통해 추가적인 유연성과 이해도를 제공하여, 프로젝트의 리스크와 불확실성을 관리하는 데 유리하다. 이 모델은 특히 요구사항의 실현 가능성, 시스템 성능 검증, 새로운 도구 도입, 외주 개발 시스템의 위험 요소와 같은 리스크가 존재하는 프로젝트에 적합하다.
•
접근 방법 1
◦
문제가 명확하지 않을 때 적용 가능한 접근 방법으로, 해결책을 조사하고 적용해본다.
◦
수행 절차는 불확실성 요소를 정의, 해결책을 찾아 적용 방법을 정의, 해결책을 반복 적용하며 불확실성 요소의 원인을 찾는다.
•
접근 방법 2
◦
해결책에 리스크나 불확실성 요소가 존재할 때 적당한 접근 방법으로, 여러 해결책을 열거하고 평가한다.
◦
수행 절차는 불확실성 요소를 정의, 선택 가능한 해결책을 열거하고 선택 기준을 정의, 선택 기준에 따라 해결책을 평가하고 가장 적합한 해결책을 선택한다.
점증적 모델
점증적 모델은 소프트웨어 개발 생명주기 중 하나로, 시스템 개발 시간을 단축해야 할 때 특히 유용한 모델입니다. 이 모델의 주요 특징은 다음과 같다.
점증적 모델은 기능을 점진적으로 추가해 나가면서 전체 시스템을 개발하므로, 시간 제약이 있는 프로젝트나, 초기에 전체 기능을 구현하기 어려운 복잡한 프로젝트에 특히 적합하다.
이 모델은 개발 과정 중에 유연성을 제공하고, 시간에 따른 시장 요구 사항의 변화에도 잘 적응할 수 있다.
•
핵심 기능 우선 개발
◦
가장 중요한 기능을 먼저 개발하여 시스템을 동작 가능한 상태로 만들고, 이후 나머지 기능을 단계적으로 추가하는 방식이다.
•
단계별 기능 확장
◦
시스템은 여러 단계에 걸쳐 개발되며, 각 단계에서는 제한된 기능만을 가진 시스템 버전이 구현됩니다. 이후 단계에서는 이전 버전의 기능을 유지하면서 새로운 기능이 추가된다.
•
요구사항의 진화
◦
대부분의 요구사항이 초기에 정의되지만, 개발 과정에서 개선의 여지가 있어 점진적으로 개선이 가능하다.
•
외부 인터페이스 리스크 감소
◦
개발 초기 단계에서 외부 인터페이스(H/W and S/W)에 대한 리스크를 줄이는 데 효과적이다.
•
명확한 요구사항
◦
각 기능 확장 개발 단계에서 요구사항이 대체로 명확하기 때문에, V 모델이나 VP 모델과 같은 다른 개발 모델과 결합하여 사용이 가능하다.
진화 모델
진화 모델은 소프트웨어 개발 생명주기에서 시스템 개발 시간을 줄이는 데 유용한 모델로, 전체 시스템에 대한 개발 단계가 반복되어 각 시스템 버전이 사용자에게 모든 기능을 제공하며 진행됩니다. 이 모델의 주요 특징은 다음과 같다.
•
지속적인 개선과 반영
◦
개발된 시스템이 사용되면서 도출된 변경사항을 다음 시스템 개발에 반영합니다. 이러한 변경사항은 기능 변경, 사용자 인터페이스 변경, 신뢰성 및 성능 향상 등 비기능적 사항을 포함할 수 있다.
•
불분명한 시스템 명세에 적합
◦
시스템 명세가 전체적으로 불분명하거나 제품의 지속적 개선이 필요한 경우에 특히 적합하다.
•
점증적 모델과의 조합
◦
실무에서는 점증적 모델과 조합하여 사용되는 경우가 많으며, 이를 통해 새로운 시스템 버전에서 기존 기능이 향상되고 새로운 기능이 추가된다.
•
초기 교육 및 실무 적응
◦
시스템이 완전한 기능을 갖추고 있지 않더라도 초기 교육을 통해 사용자가 시스템에 익숙해지고, 필요한 개선사항을 도출할 수 있다.
•
경쟁력 강화 및 문제 조기 발견
◦
개발 기간 단축과 시스템의 조기 사용으로 경쟁력을 강화할 수 있으며, 시스템이 여러 번에 걸쳐 개발되기 때문에 예상치 못한 문제의 도출 및 조기 수정이 가능하다.
•
전문 분야별 개발 가능
◦
특정 기능의 향상을 위한 전문 분야별 개발이 가능합니다. 예를 들어, 사용자 인터페이스 개선 프로젝트에서 텍스트 기반에서 그래픽 기반으로의 전환과 같은 작업을 전문 분야를 가진 개발팀이 수행할 수 있다.
소프트웨어 개발 방법론
소프트웨어 개발 방법론의 필요성
•
개발 경험의 축적 및 재활용을 통한 개발 생산성을 향상
•
효과적인 프로젝트 관리
•
공식 절차와 산출물을 제시하고 표준용어를 통일하여 의사소통 수단 제공
•
각 단계별 검증과 승인된 종료를 통해 일정 수준의 품질 보증
소프트웨어 개발 방법론 종류
구분 | 구조적 방법론 | 정보공학 방법론 | 객체 지향 방법론 | CBD 방법론 |
개요 | 업무활동 중심의 방법론 | 데이터 중심의 방법론 | 객체, 클래스 간의 관계를 식별하여 설계모델로 변환하는 방법론 | 재사용이 가능한
컴포넌트의 개발/상용 컴포넌트들을 조합하는 방법론 |
기본 원리 | - 추상화
- 구조화
- 단계적 상세화
- 모듈화 | - 정보전략계획
- 업무영역분석
- 업무시스템설계
- 시스템구축 | - 요건정의
- 객체 지향 분석 (객체모델링, 동적모델링, 기능모델링）
- 객체 지향 설계
- 테스트/배포 | - 요구분석
- 분석 (아키텍처 정의, 유스케이스모델링)
- 설계
- 개발
- 구현 (릴리스, 교육) |
특징 | - 분할과 정복의 원칙
- 프로그램 로직중심
- 컨트롤가능한 모듈로 구조화 | - 기업업무 지원시스템 지원방법론
- 데이터모델 중시
- 프로그램 로직은 데이터구조에 종속 (CRUD)
- 전사적 통합데이터모델 | - 프로그램 단위는 객체
- 데이터와 로직 통합
- 고도의 모듈화
- 상속에 의한 재사용 분석
- 설계간 갭(gap) 없음 | - 객체방법론의 진화
- 인터페이스 중시
- 인터페이스의 구현은 컴포넌트
- 블랙박스 재사용 지향 |
주요 산출물 | - 도메인 분석서
- 데이터 흐름도
- 구조도
- 프로그램사양서 | - 도메인분석서
- ERD
- 기능차트
- 어플리케이션구조도
-프로그램사양서
- 테이블정의서/목록 | - 비즈프로세스/개념도
- 다이어그램
(유스케이스, 시원스, 클라스, 컴포넌트 등) | - 비즈프로세스/개념도
- 다이어그램
(유스케이스, 시원스, 클라스, 컴포넌트 등)
- 재사용계획서
- .NET EJB |
지원 도구 | - Teamwork
- SA | - Cool Gen
- SA | - Rose
- SA
- Palstic | - Cool Joe
- Together |
주요 지원 언어 | - COBOL
- C
- VB
- PASCAL | - COBOL
- C
- VB
- PASCAL | - C++
- JAVA
- VB | 원칙적으로 개발언어 무관 |
소프트웨어 개발 4단계
1.
요구사항 분석
•
개념적 단계로써 무엇을 개발할 것인가를 정확히 결정하는 것
•
사용자의 요구에 대하여 이해하는 단계
•
전체 개발 과정에서 개발 비용을 감소시킬 수 있는 결정적인 단계
•
초기에 요구사항을 잘 분석하여 정의하고 관리하기 위해 투자한다면 전체 소프트웨어 개발 기간과 비용의 초과, 품질 저하를 미연에 방지할 수 있음
2.
설계
•
물리적 실현의 첫 단계
•
서브 시스템들로 이루어지는 시스템 구조를 결정, 서브 시스템들은 하드웨어나 소프트웨어 등의 구성요소에게 할당
•
설계는 품질에 직접적인 영향을 줌
•
설계가 제대로 되지 않으면 시스템의 안정감 저하
•
안정감 없는 시스템은 유지보수도 어려움
3.
구현
•
설계 명세를 기반으로 요구사항을 만족할 수 있도록 프로그래밍 하는 것
•
프로그램은 상세 설계나 사용자 지침서에 기술된 것과 일치하도록 코딩해야 함
•
구현 단계에서 가장 중요한 작업 중 하나는 코딩 표준을 정하고, 이를 기반으로 명확하게 코드를 작성하는 것
4.
테스팅
•
시스템이 정해진 요구를 만족하는자 예상과 실제 결과가 어떤 차이를 보이는지에 대해 수동 또는 자동화된 방법을 동원하여 검사하고, 평가하는 일련의 과정을 의미함
•
소프트웨어 품질 보증을 위한 마지막 단계로 소프트웨어의 품질을 확보하기 위해 결함을 찾아내는 일련의 작업
•
품질에 대한 평가와 품질 향상을 위한 수정 작업 등이 포함
애자일 개발 방법론
애자일 방법론 종류
•
스크럼(Scrum), 켄 슈와버/제프 서덜랜드
•
익스트림 프로그래밍(extreme Programing, XP), 켄트 백/에릭 감마
•
린(Lean) 소프트웨어 개발방법론，메리 포펜딕/톰 포펜딕
•
애자일 UP(Agile Unified Process, AUP), 스콧 앰블러
익스트림 프로그래밍 - XP
XP 개요
XP(eXtreme Programming)는 1990년대 후반에 켄트 벡을 중심으로 개발된 경량화된 개발 방법론이다. 주로 중소규모 개발 조직에 적합하며, 테스트 주도 개발(TDD), 일일 빌드, 지속적인 통합 등을 강조한다. XP는 종종 개발 테크닉과 방법론 사이에서 논란의 대상이 되기도 한다.
주요 특징 및 적용 사례
•
국내에서는 작은 규모의 개발 팀을 중심으로 일부 기법이 적용되는 것이 일반적이다.
•
XP만을 고집하기보다는 스크럼과 같은 다른 애자일 방법론과 함께 적용하는 사례가 증가하고 있다.
가치와 실천
•
XP는 그 가치와 실천법으로 구성되며, 이를 통해 프로젝트를 반복적으로 수행하는 방식이다.
•
프로젝트 수행 과정에 여러 번의 반복이 있으며, 테스트 결과에 따라 반복적으로 업무를 수행한다.
XP 개발절차 및 용어
•
유저 스토리
◦
요구사항 수집 의사소통의 도구를 말하고 기능단위의 필요한 내용을 간단하게 기재한다.
•
스파이크
◦
어려운 요구사항 혹은 잠재 솔루션을 고려한 간단한 프로그램으로서, 사용자 스토리의 신뢰성을 증대, 기술문제의 위험을 감소하는 목적이 있다.
•
릴리즈 계획
◦
전체 프로젝트에 대한 배포 계획을 수립하여 하나의 반복을 1~3주로 나누고 반복들을 균일하게 유지한다.
•
승인 테스트
◦
릴리즈 전 인수 테스트로서 고객이 직접 수행한다.
•
작은 릴리즈
◦
XP 주기의 마지막 단계이고 소규모로 빈번하게 배포하면 고객에게 여러 이득을 조기에 제공할 수 있다.
XP 가치 - 5가지
•
의사소통
◦
팀 단위 소프트웨어 개발에서 가장 중요한 것은 의사소통이며, 실패한 프로젝트에서 볼 수 있는 전형적인 현상은 커뮤니케이션 오류이다. 고객, 개발자 관리자들 간의 의사소통을 통해 문제를 해결하고 팀 빌딩을 강화해야 한다.
•
단순성
◦
"가능한 한 가장 단순한 것은 무엇인가?”는 물음을 늘 갖는다. 불필요한 복잡성을 제거하여 설계를 단순하고 명확하도록 유지한다.
•
피드백
◦
어제의 산출물이나 가치가 오늘 무용지물이 되는 변화의 흐름 속에서 완전성을 추구하는 것보다 점진적인 개선
이 효과적이다. 팀이 다룰 수 있는 한도 내에서 최대한 빨리, 최대한 많은 피드백을 만들어 개선에 활용한다.
•
용기
◦
가능한 한 빨리 변경된 사항을 반영하여 고객에게 인도한다는 정신 아래 요구사항 및 기술 변경에 용감하게 대처해야 한다.
◦
문제를 적극적으로 해결하려는 용기는 단순함을 추구
◦
구체적으로 제시하려는 용기는 피드백을 강화
•
존중
◦
앞의 4가지 뒤에 숨어있는 가치로 팀에 속한 다른 사람들을 중요하게 여기지 않고 프로젝트를 제대로 할 수는 없다.
XP 실천 방법
•
개발
◦
단순한 설계 (Simple design)
▪
현재의 요구사항을 만족시키도록 가능한 한 단순하게 설계함
◦
테스트 기반 개발 (Test-Driven Development)
▪
코드를 작성하기 전에 테스트부터 작성하고 테스트 도구를 사용하여 자동화하라
◦
리팩토링 (Refactoring)
▪
코드의 중복과 복잡성을 제거하여 기존코드의 디자인을 향상시켜라
◦
코딩 표준 (Coding Standard)
▪
효과적인 의사소통을 위해 코딩 표준을 만들어라
◦
짝 프로그래밍 (Pair Programming)
▪
두 명의 개발자가 한 컴퓨터 앞에 앉아서 같이 개발 작업을 진행하라
◦
코드 공유 (Collective Code Ownership)
▪
팀의 모든 개발자가 소스코드에 대해 공동책암을 져서 언제든, 누구라도 코드를 수정해서 더 좋게 만들 수 있게 하라.
◦
지속적인 통합 (Continuous Integration)
▪
작업이 끝날 통합 작업을 수행하라.
•
관리
◦
계획 게임 (Planning Game)
▪
프로젝트 전체 계획과 주기 계획을 비즈니스와 기술적인 측면을
고려하여 세우고 실행과 피드백을 통해 업데이트를 유지하라.
◦
작은 릴리스 (Small Release)
▪
실행 가능한 모듈을 가능한 한 빨리 배포하여 고객이 수시로
소프트웨어가 어떻게 돌아가는지 볼 수 있게 하라.
◦
메타포 (Metaphor)
▪
시스템에 대한 전체 모습을 이해하기 쉬운 그림과 스토리로 표현하라.
•
환경
◦
주당 40시간 작업 (40 Hours/week)
▪
품질의 유지를 위해 일주일에 40시간 이상 일하지 마라.
◦
현장 고객 (On-site Customer)
▪
실제 시스템을 사용한 고객이 개발 현장에 상주하게 하라.
스크럼 (SCRUM)
스크럼 역할자 유형
•
제품 책임자 (Product Owner)
◦
제품 기능목록에 해당하는 제품 백로그(Product Backlog)를 만들고 우선순위를 조정하거나 새로운 항목을 추가하는 일을 관리한다.
◦
스프린트 계획 수립 시점에는 핵심 역할을 담당하지만 스프린트 시작 후에는 가능한 팀의 운영에 관여하지 않는 것을 권장한다.
•
스크럼 마스터 (Scrum Master)
◦
팀의 업무를 방해하는 요소 제거에 노력한다.
◦
원칙과 가치를 지키면서 팀이 개발을 진행할 수 있도록 지원한다.
•
스크럼 팀 (Scrum Team)
◦
일반적으로 스크럼 팀은 최소 5명에서 최대 9명으로 구성된다.
◦
사용자 스토리를 사용하여 한 스프린트 동안에 개발할 기능을 도출한다.
스크럼 프로세스
•
스프린트(Sprint)
◦
달력기준 1~4주 단위의 반복개발기간을 가리킨다.
•
3가지 미팅
◦
스프린트 계획
▪
각 스프린트에 대한 목표를 세우고 제품 백로그로부터 스프린트에서 진행할 항목을 선택한다.
▪
각 항목에 대한 담당자를 배정하고 태스크 단위로 계획을 수립한다.
◦
일일 스크럼
▪
매일 진행하는 15분 간의 프로젝트 진행상황을 공유하는 회의이다.
▪
모든 팀원이 참석하며 매일매일 각자가 한 일, 할 일, 문제점 등을 이야기한다.
◦
스프린트 리뷰
▪
스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하는 회의이다. 스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백을 받는다.
▪
가능하면 해당 스프린트 동안 진행된 모든 작업에 대한 데모를 진행하고 고객이 참여하는 것이 좋다.
▪
스크럼 마스터는 스프린트 동안 잘된 잠 아쉬웠던 점, 개선할 사항 등을 찾기 위한 회고를 진행할 수 있다.
•
3가지 산출물
◦
제품 백로그
▪
제품에 담고자 하는 기능의 우선순위를 정리한 목록, 고객을 대표하여 제품 책임자가 주로 우선순위를 결정한다.
▪
제품 백로그에 정의된 기능을 사용자 스토리라고 한다. 사용자 업무량에 대한 추정은 주로 스토리 포인트라는 기준을 이용한다.
◦
스프린트 백로그
▪
하나의 스프린트 동안 개발할 목록으로 사용자 스토리와 이를 완료하기 위한 작업을 과업(task)으로 정의한다. 각각의 과업의 크가는 시간 단위로 추정한다.
◦
소멸 차트
▪
개발을 완료하기까지 남은 작업량을 보여주는 그래프, 각 이터레이션 별로 남아있는 작업량을 스토리 포인트라는 것으로 나타낸 것이다.
스크럼 특성
•
투명성
◦
프로젝트가 현재 어떤 상태인지 확히 파악하는 건 어려움
◦
스크럼은 스크럼 회의, 소멸차트, 스프린트 리뷰와 같은 기법을 이용해서 프로젝트의 상태나 문제점을 효과적으로 파악할 수 있다.
•
타임박싱
◦
스크럼을 진행하는데 들어가는 시간을 제한하여 프로젝트 진행에만 집중하는 것이 가능
◦
일일 스크럼은 매일 15분의 제한된 시간에 진행되며, 스프린트 리뷰는 매 이터레이션 마다 주기적으로 진행된다.
•
커뮤니케이션
◦
스크럼에서는 팀원 간 커뮤니케이션을 원활하게 하기 위해서 많은 노력을 기울인다.
◦
일일 스크럼에서 개발자들이 갖고 있는 문제점을 공유하고, 플래닝 포커를 사용하여 사용자 스토리의 구현 난이도, 시간을 토론하는 절차는 팀원 간의 커뮤니케이션을 원활하게 해주는 스크럼의 특징 중 하나이다.
•
경험주의 모델
◦
스크럼은 고유의 프로세스 모델을 가지고 있지만 많은 기법들이 프로젝트에 참여하고 있는 개개인의 경험을 중요시한다.
◦
프로젝트별로 고유한 상황과 특징을 가지고 있기 때문에 기존의 정형화된 프로세스로는 이런 프로젝트 상황을 따라가기 어렵다. 스크럼은 기본적인 구조만 동일할 뿐 실제로 팀마다 달라지는 것을 인정한다.
