개떡같은 블로그

스프린트 계획회의의 목표

스프린트에서 구현될 기능 목록 결정, 

방법

명확한 스프린트 목표 설정

테스트 주도 계획 설정

목표 달성을 위한 계획 실천 약속함

제품백로그 : 언제든 수정가능함

그러나 스프린트 백로그는 수정 불가 

스프린트 계획

팀의 초기 역량 결정함

팀 이력ㅇ네 ㅊ기초하여 구현속도를 구함

실제 커밋(commit)할수 있는 시간

일일 실제 업무시간이 8시간이라고 했을 때 실제 업무에만 집중할 수 있는시간 4~5시간을 계획에 넣는다.

스프린트 규칙

제품 백로그로 부터 항목 선정 및 논의 

항목을 작업 간으한 테스크로 분할

각 테스크에 대한 작업량 추정

팀역량이 남아있는 동안 다음 항목에 대해 반복

팀 역량이 모두 할당되면 스프린트 계획 종료

3주짜리 스프린트

스프린트 계획 종료

스프린트 목표에 기초한 종료 상태 정의 

할당받은 테스크가 어떤 상태로 완료되는지 확인해야함

리뷰를 위한 목업과 스키마 .- 실행가능한 일부를 데모하고 리뷰해야함

스프린트 계획의 핵심가치

1.능동/개방적인참여

2. 자발적인 권한 위임

3. 종료 상태의 정의

4. 작업 할당 전에 개별 역량의 공유와 이해

5. 팀의 구성 및 이력

6. 팀 내 균형 및 지원

7. 팀의 헌신과 집중

작업 추적 프로세스 -번다운 차트

스프린트 기간에는 추가 요구사항이 없어야 합니다.

그러나 작업시간에 못맞출 경우를 대비하여 여분의 시간을 할당할수 있다.  Risk Buffer 리스크 버퍼라고 함

스크럼의 역할과 책임

역할 1: 제품책임자 

       2: 스크럼팀

       3: 스크럼 마스터

제품책임자 : 제품의 특성과 기능을 정의하고 출시 일자와 내용을 결정 , 수익성에 대한책임, 그리고 우선순위 부여 , 제품

백로그에서 특성 및 기능, 우선순위 변경가능하고 작업 결과에 대한 승인또는 거부 결정

스크럼팀

프로젝트의 결과를 위해 각자의 역할을 수행, 교차 기능적 자율적 조직화 , 적그적인 협동을 통하여 최선의 결과를 도출

일반적으로 5~9명으로 구성

상근, 동일 장소 배치 권장

 기획-분석-설계-코딩-테스팅-QA

스크럼마스터

팀이 완전히 생산적이고 기능적이 되도록 보장

모든역할고 ㅏ기능에 걸쳐 밀접하게 협력하고 장애제거

외부의 간섭과 방해로부터 팀을 보호

스ㅏ크럼 프로세스가 준수되도록 보장

일일스크럼 스프린트 계획을 세움

이해관계자

이해관계는 있지만 제품 제공에 대한 책임은 없음

우선순위 부여, 팀과 협력 리뷰등에 참여

피그

프로젝트 진행에 실제적인 헌신이 요구되는 사람 

제품책임자, 스크럼팀, 스크럼 마스터 등, 

치킨

직접적인 참여를 하지않는 이해관계자

제품책임자는 피그와 치킨들과 백로그를 작성

피그들은 스프린트 미팅을 통해 백로그를 만듬

피그들은 스프린트 기간동안 기능 구현함

피그들은 스크럼마스터의 주간으로 데일리업 미팅을 통해 진행상황을 공유함

스프린트 완료 되면 치킨과 함께 리뷰를 함 

제품 백로그 작성방법

요굿사항에 대한 명세와함께 요구순위  예상시간, 그리고 담당자를 기록함

제품 백로그 추정단위

ideal time

간섭이나 방해가 없다고 가정할때 한사람이 사용가능한 시간의 양

시간또는 일수를 표현

ex 1/2day 

폭포수 프로세스 : 계획중심 방법론 계획, 정ㄴ량적인 평가 , 문서화 , 주요마일스톤에 따른 중앙집중관리, 순차적 절차가 따름

                       프로세스에 따라 굉장히 많은 문서가 존재함 

중간에 경경진 리뷰가 들어감

실제 런칭까지 많은 시간이 들어감

애자일 :             프로젝트 초기부터 고객참여 

시장출시주기가 짧음 

출시 사이사이 데모가 가능한 조각이 들어감

고객과 내부 경영진 피드백 반영

스크럼 프로세스

제품책임자가 중심이 되어 고객과 팀으로 부터 의견을 받아 다양한 요구서를 받아 제품  백로그 제작  1~4주 

팀에서 스프린트 계획회를 통해 백로그로 부터 선정하여 업무를 테스크화 함

스크럼마스터가 일일 스텐드 미팅을 통해 간략히 공유함 

스프린트를 거듭할 수록 시스템이 완성됨

스프린트 리뷰회를 통해 개선점을 찾아 회고 회의를 진행

1. 제품백로그 작성

중요사항 - 우선순위 및 요구사항에 대한 명세 

2. 스프린트 계획

필요한사항 : 제품 백로그, 팀역량 비지니스 상황, 기술현황, 현재제품 

스프린트 계획 회의에는  - 제품 책임자, 스크럼팀, 고객, 이해관계자가 참여

하며 이 회의를 통해 스프린트 목표와 스프린트 작업내용이 담긴 백로그가 작성됨

  팀능력 추정

  *휴일외근 업무외 시간은 제외하고 가용 가능한 시간을 추정함

  팀 사용가능한 시간이 확인되면 스프린트 백로그를 작성함

    * 반드시 들어가야할 내용은 테스크 , 담당자, 작업예상시간이 반드시 들어가야함

스프린트 회의를 통해 스프린트 백 로그가 완성되면 투명하게 프로젝트를 진행하기 위해 스프린트 일일 업데이트를하고

이를 바탕으로 일일 스탠드업 미팅을 진행하여 어제 한일 오늘할일 이슈상황을 간단히 공유하고 발생가능한 장애를 

발견하고 대응하기 위함

진행현황 확인 방법 day1~항목을 y축에 넣고 total 값을 x축에 넣으면 차트로 진행현황을 쉽게 확인 할 수 있습니다.

적극적인 테스크 추적을 위해 보드 활용

벽을 3구분으로 나눠 1. 해야할일 2. 하고있는일 3.완료한일로 나누고 스탠드업 회의때 추가하거나 제거 함 

1.애자일 소프트웨어 개발 프로세스

모든 태스크가 명확히 이해되는가?

정확히 동일한 입력값을 사용하는가?

언제나 동일한 출력값이 생성되는가?

  그러나 요구사항이 변동이 심하고 예측불가능하기 때문에 출력을 예측하기 힘들고 동일하지 않다.

그ㅏ래서 나온 프로세스가 적응적 프로세스 입니다.

적응적 프로세스란?

  -프로세스 반복이 불가 합니다.

  -변화르ㅏㄹ 수요ㅕㅇ하고 

  -점검과 조정을 통해 위험을 낮춤

그래서 모델이 복잡하여 

비용이  많이들고 복잡하다는 단점이 있습니다.

반복점증적 프로세스란?

목표 시스템을 여러번 나누어 출시

폭포수 모델의 경직성을 보완 

중요한 기능을 먼저 출시하고 고객과 시장의 피드백을 받아 다음번 출시 주기에 반영합니다.

스크럼 xp등을 포함하는 애자일 방법론의 근간이 됩니다.

애자일방법론이란?

적응적이고 반복점증적 모델을 기본으로 합니다.

단 차이점은  1) 출시주기를 더 짧게 한다  이를 통해 다양한 변화에 대응하게 합니다. 2~4주 의 출시 주기를 권장 

2) 고객과 팀 팀원 간의 소통, 협력을 극대화 하는 실천법을 제공함으로써 고객 가치를 생성에 중점

애자일 프로세스 

자기조직화팀 :팀이 주체가 되어 각자 할일을 능동 적으로 진해하는 자기조직화팀이 주체가 됨

반복점증개발하여 유연 하게 함  -->인간중심적임

애자일 방법론의 기원

소프트웨어가 대형 복잡화 되감에 따라 1995년이후 경량 방법론이 발표됨 -->가볍고 실용적인 소프트웨어 개발방법 추구 --->2000년대 애자일이라는 이름오

통합됨 

스크럼이란?

프로젝트 관리를 위한 애자일 방법론으로 추정및 조정기반의 대표 기법

1986년 시작됨 1995년에 소프트웨어 개발에 적용시켜 탄생

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

SW개발 방식을 애자일화 하는데 초첨화 

1999년 켄트백과 엔지니어들이 효과적 기법들을 모아 방법론으로 

FDD , DSDM,CRYSTLCLEAN,린등 존재함

애자일선언문 발표

2001년 2월 17명의 경량방법론 지지자들이 모여 공동으로 추구하는 가치 발표

애자일 연합은 실천법보다는 < 원칙에 중심을 주다는 것

개인과 상호작용을  > 프로세스와 도구 보다 중시한다.

동작하는 소프트웨어를 > 포괄적인 문서보다 중시한다.

고객과의 협력을 > 계약협상 보다 중시한다.

변화에 대응을  > 계획의 수행 보다 중시한다

애자일방법론 중시 가치는?

1. 소통하라 - 크고잘 보이는 차트 , 정보 공유시스템 회의, 정기적인 계획 세션

2. 협력하라 - 전체팀은 고객과 함께 생각하고 문제 해결

3. 적응하라 - 변화를 수용 , 변화에 대한 제어를 포기

4. 지속적으로 - 짧게 시간이 정해진 반복점증개발

5. 가치를 전달하라 - 가치와 위험도가 가장 높은 일부터 먼저 시작 , 자주 출시하고 낭비를 줄임

6. 피드백을 구하라 - 일찍 자주 일을 보여줌

애자일 방법론이 아닌것은?

1. 스케줄 쥐어짜기 ->지속가능한 시간 속도를 파악해서 안정적 성과 내도록 강조

2. 문서작성 안하기 

3. 막장 코딩

4. 설계나 계획 안하기 ->? 엔지니어링 실천법을 이용해서 챙겨야함 ( TDD 등)

애자일 방법론 사용의 장점

1. 요구사항 변경관리

2. 팀생산성 증가

3. 프로젝트 가시성 개선

등등

애자일 사용 현황

애자일 실천법 사용현황

1.일일 스탠드업, 

2. 제품 백로그

3. 짧은 출시주기

4. 회고