Chatpter 02 소프트웨어 개발 프로세스 01 소프트웨어 개발 프로세스의 이해 02 소프트웨어 프로세스 모델의 이해 03 주먹구구식 모델 04 선형 순차적 모델 05 V 모델 06 진화적 프로세스 모델 요약 연습문제 07 나선형 모델 08 단계적 개발 모델 09 통합 프로세스 모델 10 애자일 프로세스 모델

소프트웨어 개발 프로세스의 개념을 이해한다. 소프트웨어 프로세스 모델의 종류를 알아본다. 주요 프로세스 모델에 대해 자세히 살펴본다.

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

1. 일상에서의 프로세스 의미 프로세스 일을 처리하는 과정 또는 순서 (예 1) 공장에서 자동차, 세탁기 등이 조립되어 완제품이 되는 과정 (예 2) TV요리 프로에서 요리사가 맛있는 요리를 만드는 과정

2. 프로세스의 정의 프로세스 프로세스를 따랐을 때의 효과의 예 일이 처리되는 과정이나 공정 즉, 주어진 일을 해결하기 위한 목적으로 그 순서가 정해져 수행되는 일련의 절차 프로세스를 따랐을 때의 효과의 예 요리 레시피 활용하면? 세탁기 사용설명서 활용하면? 화면 지시에 따라 OS 설치하면? → 목적 달성

3. 소프트웨어 개발 프로세스(1) 소프트웨어 개발에서의 프로세스 (좁은 의미)소프트웨어 개발 프로세스 작업(task)순서의 집합 + 제약 조건(일정, 예산, 자원)을 포함하는 일련의 활동(activity) 작업(task): SW를 개발할 때 일을 수행하는 작은 단위 (좁은 의미)소프트웨어 개발 프로세스 SW제품을 개발할 때 필요한 절차, 과정, 구조 사용자의 요구사항을 SW시스템으로 구현하기 위한 일련의 활동 (넓은 의미)소프트웨어 개발 프로세스 절차, 구조, 방법, 도구, 참여자까지 모두 포함 SW개발 목적을 이루는데 필요한 통합적 수단

3. 소프트웨어 개발 프로세스(2) 프로세스의 목적 guide 역할 이전에 얻은 노하우를 전달 -> 시행착오 감소 -> 빠르게 적응 guide 역할

Section 02 소프트웨어 프로세스 모델의 이해

1. 소프트웨어 개발 과정 작은 규모의 소프트웨어 개발 과정 대규모의 소프트웨어 개발 과정 개집 짓는 일에 비유 빌딩 짓는 일에 비유

2. 소프트웨어 프로세스 모델(1) 소프트웨어 프로세스 모델의 정의 소프트웨어 프로세스 모델의 목적 소프트웨어 개발 생명주기(SDLC Software Development Life Cycle) SW를 어떻게 개발할 것인가에 대한 전체적인 흐름을 체계화한 개념 개발 계획 수립부터 최종 폐기 때까지의 전 과정을 다룸 순차적인 단계로 이루어 짐 소프트웨어 프로세스 모델의 목적 공장에서 제품을 생산하듯이 소프트웨어 개발의 전 과정을 하나의 프로세스로 정의 주어진 예산과 자원으로 개발하고 관리하는 방법을 구체적으로 정의 고품질의 소프트웨어 제품 생산을 목적으로 함

2. 소프트웨어 프로세스 모델(2) 소프트웨어 프로세스 모델의 역할 프로젝트에 대한 전체적인 기본 골격을 세워줌 일정 계획을 수립할 수 있음 개발 비용 산정뿐 아니라 여러 자원을 산정하고 분배할 수 있음 참여자 간에 의사소통의 기준을 정할 수 있음 용어의 표준화를 가능케 할 수 있음 개발 진행 상황을 명확히 파악할 수 있음 각 단계별로 생성되는 문서를 포함한 산출물을 활용하여 검토할 수 있게 해줌

Section 03 주먹구구식 모델

1. 주먹구구식 모델 Build and fix 모델, code and fix 모델, 즉흥적 소프트웨어 개발 모델 주먹구구식 주먹으로 구구셈을 따지던 방법에서 유래한 말 정확한 앞뒤 계산 없이 일을 대충 처리할 때 쓰는 말 소프트웨어 개발에서의 주먹구구식 모델 공식적인 가이드라인이나 프로세스가 없는 개발 방식 요구 분석 명세서나 설계 단계 없이 간단한 기능만을 정리하여 개발하는 형태 일단 코드를 작성하여 제품을 만들어본 후에 요구 분석, 설계, 유지보수에 대해 생각

2. 주먹구구식 모델의 개발 단계 ① 첫 번째 버전의 코드를 작성하여 제품을 완성한다. ② 작성된 코드에 문제점이 있으면 수정하여 해결한다. ③ 문제가 없으면 사용한다.

3. 주먹구구식 모델의 사용 및 단점 주먹구구식 모델의 사용 주먹구구식 모델의 단점 개발자 한 명이 단시간에 마칠 수 있는 경우에 적합 대학 수업의 한 학기용 프로젝트 정도 주먹구구식 모델의 단점 정해진 개발 순서나 각 단계별로 문서화된 산출물이 없어 관리 및 유지보수가 어렵다. 프로젝트 전체 범위를 알 수 없을 뿐더러 좋은 아키텍처를 만들 수도 없다. 일을 효과적으로 나눠 개발할 수도 없으며, 프로젝트 진척 상황을 파악할 수 없다. 계속적 수정으로 인해 프로그램의 구조가 나빠져 수정이 매우 어려워진다.

Section 04 선형 순차적 모델

1. 선형 순차적 모델 Linear sequential 모델, waterfall 모델, Classic life cycle

2. 폭포수 모델의 개발 절차 계획단계(3장에서 자세히 다룸) 요구분석 단계(4장에서 자세히 다룸) 설계 단계(5-6장에서 자세히 다룸) 구현 단계(7장에서 자세히 다룸) 테스트 단계(8장에서 자세히 다룸) 유지보수 단계(10장에서 자세히 다룸)

3. 폭포수 모델의 장점 관리의 용이 체계적인 문서화 요구사항의 변화가 적은 프로젝트에 적합

4. 폭포수 모델의 단점 각 단계는 앞 단계가 완료되어야 수행할 수 있다. 각 단계의 결과물이 완벽한 수준으로 작성되어야 다음 단계에 오류를 넘겨주지 않는다. 사용자가 중간에 가시적인 결과를 볼 수 없어 답답해할 수 있다.

Section 05 V 모델

1. V 모델 폭포수 모델 + 테스트 단계 추가 확장 산출물 중심(폭포수 모델) vs 각 개발 단계를 검증하는 데 초점(V 모델) ※ 자세한 내용은 8장(테스트)에서 다룸

Section 06 진화적 프로세스 모델

1. 진화적 프로세스 모델의 등장 배경 선형순차적 모델의 대표: 폭포수 모델 진화적 프로세스 모델의 대표: 프로토타입 모델

1-1 프로토타입 프로토타입 소프트웨어 개발에서의 프로토타입 대량 생산에 앞서 미리 제작해보는 원형 또는 시제품으로, 제작물의 모형 소프트웨어 개발에서의 프로토타입 정식 절차에 따라 완전한 소프트웨어를 만들기 전에 사용자의 요구를 받아 일단 모형을 만들고 이 모형을 사용자와 의사소통 하는 도구로 활용

1-2 프로토타입 모델의 개발 생명주기

2. 실험적 프로토타입 모델

3. 진화적 프로토타입 모델

4. 프로토타입 모델의 개발절차(1) ① 요구사항 정의 및 분석 ② 프로토타입 설계 ③ 프로토타입 개발 1차 개략적인 요구 사항 정의 후 2차, 3차, … n차를 반복하면서 최종 프로토타입 개발 ② 프로토타입 설계 완전한 설계 대신, 사용자와 대화할 수 있는 수준의 설계 입출력 화면을 통한 사용자 인터페이스 중심 설계 ③ 프로토타입 개발 완전히 동작하는 완제품을 개발하는 것이 아님 입력 화면을 통한 사용자의 요구 항목 확인 출력 결과를 통해 사용자가 원하는 것인지 확인

4. 프로토타입 모델의 개발절차(2) ④ 사용자에 의한 프로토타입 평가 ⑤ 구현 추가 및 수정 요구 프로토타입 평가 최종 프로토타입 개발 추가 및 수정 요구 프로토타입 평가 프로토타입 개발

5. 프로토타입 장/단점 장점 단점 프로토타입이 의사소통 도구로 활용 반복된 요구사항 정의를 통해 사용자 요구가 충분히 반영된 요구 분석 명세서 작성 초기 프로토타입 사용을 통한 새로운 요구사항 발견 프로토타입 사용을 통한 완성품의 예측 가능 단점 반복적 개발을 통한 투입 인력 및 비용 산정의 어려움 프로토타이핑 과정에 대한 통제 및 관리의 어려움 중간 산출물 생성의 어려움 불명확한 개발 범위로 인한 개발 종료 및 목표의 불확실성

Section 07 나선형 모델

1. 나선형 모델의 특성(1) 진화적 프로토타입 모델 + 위험 분석

1. 나선형 모델의 특성(2) 위험 분석 단계의 위험 요소의 예 빈번히 변경되는 요구사항 팀원들의 경험 부족 결속력이 떨어지는 팀워크 프로젝트 관리 부족

2. 나선형 모델의 개발 절차(1) ① 계획 및 요구 분석 단계 ② 위험 분석 단계 사용자의 개발 의도 파악 프로젝트의 명확한 목표 제약 조건의 대안을 고려한 계획 수립 기능/비기능 요구사항 정의 및 분석 ② 위험 분석 단계

2. 나선형 모델의 개발 절차(2) ③ 개발 단계 ④ 사용자 평가 단계 추가 및 수정 요구 프로토타입 평가 프로토타입 개발

3. 나선형 모형의 장/단점 장점 단점 사전 위험 분석을 통한 돌출 위험 요소 감소 프로젝트 중단 확률 감소 사전 위험 분석을 통한 돌출 위험 요소 감소 프로젝트 중단 확률 감소 사용자 평가에 의한 개발 방식 요구가 충분히 반영된 제품 사용자의 불만 감소 단점 반복적 개발에 의한 프로젝트 기간 연장의 가능성 반복 회수의 증가에 따른 프로젝트 관리의 어려움 위험 관리의 중요 위험 전문가 필요에 따른 부담

Section 08 단계적 개발 모델

1. 단계적 개발 모델 릴리즈 구성 방법에 따른 분류 점증적 개발 방법 반복적 개발 방법

2. 점증적 개발 방법 개발 범위 증가 ‘하나가 끝나면 그 다음, 또 하나가 끝나면 그 다음…’과 같이 하나씩 늘려 감

2-1 점증적 개발 방법의 예 (예 1) 도서 집필 (예 2) 3층 건물 건축 (예 3) 대학 종합정보시스템 개발 1장을 완벽히 쓰고, 2장, 3장, …, 10장까지 완성해나가는 방식으로 책을 집필 (예 2) 3층 건물 건축 (예 3) 대학 종합정보시스템 개발 2층 증축 후 사용 1층 완성 후 사용 3층 증축 후 사용 교무/학사 개발 후 사용 회계/기타 개발 후 사용

3. 반복적 개발 방법 품질 증가 ‘하나가 끝나면 그 다음, 또 하나가 끝나면 그 다음…’과 같이 하나씩 늘려 감

3-1 반복적 개발 방법의 예 (예 1) 도서 집필 (예 2) 소프트웨어 개발 1~10장 원고 1차 작성 (n차 반복) 시스템 전체 개발 후 인도 기능/성능 변경 및 보강

Section 09 통합 프로세스 모델

1. 통합 프로세스 모델 해결방안 폭포수 모델 문제점 반복적 개발 방법

2. 통합 프로세스(UP) 모델

기본 개념 전체 생명주기를 지원하는 절차 중심의 프레임워크 - 도입, 구체화, 구축, 전이 단계의 과정 안에서 세부 개발 활동이 반복적으로 이루어짐 요구사항에 적합하도록 프로세스의 조정 및 수정 가능 - 각 단계에 종합적으로 수행되는 활동이 있지만 어느 시점에서 종료되기 보다는 지속적인 반복과 개선이 수행됨

특징 반복적이고 점진적임 아키텍처의 정의를 중요하게 생각하며 견고한 개념 가능 - 쓰임새와 물질을 토대로 아키텍처를 먼저 구축 후 구현 아키텍처와 객체지향이 중요해짐에 따라 활용도 증가 상품관리 행위자 (actor) 쓰임새 (usecase) 고객관리

3. 통합 프로세스(UP) 방법

4. 통합 프로세스UP 모델의 절차 ① 도입 단계inception phase ② 구체화 단계elaboration phase ③ 구축 단계construction phase ④ 전이 단계transition phase ⑤ 도입/구체화/구축전이 단계의 공통 작업

도입단계 이해관계자가 협동으로 개발을 준비하는 단계 프로젝트의 목표와 실현가능성에 대해 파악 대략적인 비용 평가 중요한 요구사항을 쓰임새, 행위자 수준으로 분석 핵심 요구사항에 대한 프로토타입 구현 요구사항 : 상 분석 : 중 설계 : 중 구현 : 하 평가 : 하

① 도입 단계inception phase

구체화 단계 대부분의 요구사항과 아키텍처를 정립하는 단계 요구사항의 대부분을 쓰임새로 작성하고 설명 설계단계에서 실행 가능한 아키텍처의 설계 구축단계에 대한 상세한 프로젝트 계획 수립 구현은 시스템의 중요한 기능에 국한 - 요구사항 : 상 분석 : 상 설계 : 상 구현 : 중 평가 : 중

② 구체화 단계elaboration phase

구축단계 아키텍처 설계를 토대로 소프트웨어를 구현 사용자에게 인도가 가능한 시스템을 구현 시스템의 모든 컴포넌트 개발, 평가 구현, 평가에 치중 요구사항 : 하 분석 : 하 설계 : 중 구현 : 상 평가 : 상

③ 구축 단계construction phase

전이(이행)단계 제품의 완성 단계 개발을 완료하고, 품질을 보장하여 사용자에게 인도 사용자 환경에서의 인수 시험, 교육훈련 설계, 구현, 평가에 치중 요구사항 : 하 분석 : 하 설계 : 중 구현 : 중 평가 : 중

④ 전이 단계transition phase

쇼핑몰 구축에 적용한 사례

⑤ 도입/구체화/구축전이 단계의 공통 작업

장점 기술적 또는 요구사항 변경 등에 관한 위험요소를 초기에 완화 시킬 수 있음 - 반복과 점증적 개발 장점 - 반복과 점증적 개발 장점 진척 사항을 가시화할 수 있음(UML 활용 사용자, 개발자간 이행 용이) 발주자의 실제 요구사항에 근접한 시스템을 만들 수 있음 - 품질좋은 SW 개발 확률이 높음 이전 반복을 통해 얻은 교훈은 다음 반복의 피드백으로 작용하여 반복이 거듭될수록 개선된 스포트웨어 개발이 가능(개발자 skill 숙달) - 조직내의 개발 노하우, Best practices 확보 가능

Section 10 애자일 프로세스 모델

1. 애자일 프로세스 모델 애자일(agile) 애자일 프로세스 모델 애자일의 기본 가치(애자일 선언문) ‘날렵한’, ‘민첩한’ 고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론 애자일의 기본 가치(애자일 선언문) • 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통 중시 • 문서 중심이 아닌, 실행 가능한 소프트웨어 중시 • 계약과 협상 중심이 아닌, 고객과의 협력 중시 • 계획 중심이 아닌, 변화에 대한 민첩한 대응 중시

1-1 애자일 프로세스 모델의 이해 애자일의 개발 방법 사용자 확인 프로토타입 개발 일부 기능 사용 반복적인 개발을 통한 잦은 출시를 목표로 함 사용자 확인 프로토타입 개발 일부 기능 사용

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

XP(Extreme Programming) 기본개념 고객이 원하는 양질의 소프트웨어를 짧은 시간에 구축, 전달 Agile 기법: 즉시 변경, 경량화 기법 - 고객의 요구사항은 변경된다는 가정 4개의 가치(Value), 13개의 실천사항(Practice) 제시

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

XP(Extreme Programming) 4가지 가치(Value) 의사소통(Communications) - 고객, 개발자, 관리자간의 원활한 의사소통 - On-site 고객, Whole-팀, Stand-up 미팅 피드백(Feedback) - 신속한 개발 -> 고객과 시험 -> 신규 요구 반영 - 지속적으로 시험결과를 통합 -> 도출 결과 반영

XP(Extreme Programming) 4가지 가치(Value) 단순성(Simplicity) - 설계의 단순함 -> 군더더기 제거, 100% 정상코드 추구 - 문서화 축소 용기(Courage) - 요구사항 및 기술변경에 대해 용기있게 대처

XP(Extreme Programming) 13가지 실천(Practice)

XP(Extreme Programming) 개발활동

XP(Extreme Programming) 역할 분담

XP(Extreme Programming) 쇼핑몰 시스템 적용 예

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

4. 스크럼 방식의 진행 과정

5. 스크럼 방식에서 사용되는 용어(1) 제품 기능 목록product backlog 작성 우선순위가 매겨진 사용자의 요구 사항 목록

5. 스크럼 방식에서 사용되는 용어(2) 사용자 스토리user story작성 및 스토리 포인트story point 산정 사용자 스토리: 메모지 한 장에 구현할 기능을 사용자 관점에서 사용자 언어로 작성한 사 용자 요구 사항 스토리 포인트: 사용자 스토리를 수행하는데 걸리는 상대적인 개발 기간(시간)

5. 스크럼 방식에서 사용되는 용어(3) 사용자 스토리user story • 제품 기능 목록에 정의된 사용자 관점에서의 기능 • 사용자에게 가치를 평가 받을 수 있도록 기능을 표현한 것 • 보통 작은 인덱스 카드를 사용해 필요한 것만 짧게 표현 • 고객의 요구 사항을 문서화한 것이라기보다는 표현했다고 보는 것이 적합 • 유스케이스보다 작은 규모 • 사용자 스토리는 반복을 마치면 사라지지만 유스케이스는 개발 기간 동안 지속 • 사용자와 충분히 대화하여 세부 사항을 구체적으로 서술 • 테스트를 통해 스토리가 완료된 것을 확인 • 다른 스토리에 종속되지 않고 독립적이며, 협상 가능해야 함 • 추정 및 측정 가능해야 함 • 사용자 스토리는 스토리가 큰 것보다는 많은 것이 좋음 • 테스트가 가능해야 좋은 사용자 스토리

5. 스크럼 방식에서 사용되는 용어(4) 스프린트sprint ‘전력 질주’ 작업량으로 볼 때 그렇게 많지 않고, 개발 기간도 짧다. 작은 단위의 개발 업무를 단기간 내에 전력 질주하여 개발한다는 뜻

5. 스크럼 방식에서 사용되는 용어(5) 스프린트의 예 계획: 소프트웨어 공학 원고 작성, 총기간(1년), 1장/(10일~40일) • 스프린트 = 반복 주기 = 10일~40일

5. 스크럼 방식에서 사용되는 용어(6) 스프린트 구현 목록sprint backlog 각각의 스프린트 주기에서 개발할 작업 목록 세부 작업 항목과 작업자, 예상 작업 시간 등에 관한 정보를 작성

5. 스크럼 방식에서 사용되는 용어(7) 소멸 차트burndown chart 시간이 지남에 따라 소멸되고 남은 것을 표현 계획 대비 작업이 어떻게 진행되고 있는지를 날짜별로 남은 작업량으로 표현

6. 스크럼 방식에서의 회의(1) 스프린트 계획 회의sprint planning meeting 전체적인 스프린트 계획 회의 가장 높은 순위의 항목에 관심 그 배경과 목표에 대해 팀원들과 토의 제품 책임자의 의도 파악 세부적인 스프린트 계획 회의 우선순위가 높은 항목의 구현 방법에 대한 구체적인 작업 계획을 세움 결정된 개발 항목에 대한 스프린트 구현 목록 작성 정해진 작업 수행 소요 시간 추정

6. 스크럼 방식에서의 회의(2) 일일 스크럼 회의daily scrum meeting • 매일, 서서, 짧게(15분 정도) 함 • 진행 상황만 점검하고, 스프린트 작업 목록을 잘 개발하고 있는지 확인 • 모든 팀원이 참석하고, 한 사람씩 어제 한 일을 얘기 • 한 사람씩 오늘 할 일과 문제점 및 어려운 점 정도만 얘기 • 매일 완료된 세부 작업 항목을 완료 상태로 옮겨 스프린트 현황판 업데이트 • 개별 팀원에 대한 진척 상태를 확인 • 그날의 남은 작업량을 소멸 차트에 표시

6. 스크럼 방식에서의 회의(3) 스프린트 현황판task board 최종 제품finished work 개발 팀의 개발 현황(진척도, 남은 작업, 진행 속도)을 나타냄 최종 제품finished work 모든 스프린트 주기가 끝나면 제품 기능 목록에서 개발하려고 했던 제품이 완성

6. 스크럼 방식에서의 회의(4) 스프린트 검토회의sprint review 스프린트 회고sprint retrospective 하나의 스프린트 반복 주기(2~4주)가 끝났을 때 생성되는 실행 가능한 제품에 대해 검토 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인 전체 흐름을 확인하여 비즈니스 가치를 점검 스프린트 회고sprint retrospective 스프린트에서 수행한 활동과 개발한 것을 되돌아 봄 개선점은 없는지, 팀이 정한 규칙이나 표준을 잘 준수했는지 등을 검토 문제점을 확인하고 기록하는 정도로만 진행 추정 속도와 실제 속도를 비교해보고, 차이가 크면 그 이유를 분석 프로세스 품질은 측정하지 않음

6. 스크럼 방식에서의 회의(5) 배포 목록release backlog

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

8. 제품 책임자, 스크럼 마스터, 스크럼 팀의 역할

9. 스크럼 방식의 장점 • 실행 가능한 제품을 통해 사용자와의 충분한 의견 조율 가능 • 일일 회의를 통한 팀원들 간의 신속한 협조와 조율 가능 • 일일 회의 시 직접 자신의 일정 발표를 통한 업무 집중 환경 조성 • 다른 개발 방법론들에 비해 단순하고 실천 지향적 • 팀의 문제를 해결할 수 있는 스크럼 마스터의 능력(역할) • 프로젝트 진행 현황을 통한 신속하게 목표와 결과 추정 가능, 목표에 맞는 변화 시도 가능

10. 스크럼 방식의 단점 추가 작업 시간 필요 일일 스크럼 회의를 15분 안에 마쳐야 함 반복 주기가 끝날 때마다 실행 가능하거나 테스트할 수 있는 제품을 만들어야 하기 때문 일일 스크럼 회의를 15분 안에 마쳐야 함 길어지는 회의 시간으로 인한 작업의 방해 투입 공수 불측정에 따른 효율성 평가 불가 투입 공수 불측정으로 인해 얼마나 효율적으로 수행되었는지 모름 프로세스 품질 평가 불가 프로세스 품질 미평가로 인한 품질 관련 활동이 미약하고 품질의 정도를 알 수 없음 :