Agile한 조직일수록 조직의 퍼포먼스를 이해하는 능력이 높음(퍼포먼스가 얼마나 걸릴지 예상의 정확도가 높음)
Manifesto : 선언문
워터폴 : 한번 지나가면 되돌아가기 어렵다
워터폴은 처음부터 완벽해야한다
워터폴을 사용하는 조직 예시 : 건축
워터폴의 단점을 보완한게 Agile
조직의 상황에 따라 워터폴이나 Agile을 적용
Agile은 주요 메인 기능을 최대한 빨리 만들고(고객에게 피드백을 받을 수 있는 수준) release, 그 후 고객의 요구사항에 맞춰 빠르게 적용
고객의 신뢰(소프트웨어 신뢰도)를 얻을 수 있음
초기 단계에 주요 기능을 정의
- 릴리즈 범위를 설정한다
작은 단위의 작업으로 나누어 계획에 할당(하루를 넘지 않음)
- 개개인이 무엇을 했는지 파악하기 위해서
예시) 로그인 기능을 처음 만들어보는 개발자
스프린트 1 : 로그인 기능 공부하기, 기능 써보기, 얼마나 걸릴지에 대한 스프린트
너무 타이트하게도, 너무 루즈하게도 task 단위 일정을 정하지 않기 위해 agile 사용
데일리 스크럼 시 이점
팀의 폭표에 대한 리스크를 줄임(시간 절약, 놓친 점 파악 등)
처음 데일리 스크럼 시 시간이 오히려 늘어날 수 있음, 스톱워치 켜놓고 시간이 되면 끝내버리고 회의 시간을 따로 갖기
전 스프린트에 대한 회고를 하고 다음 스프린트에는 똑같은 실수를 하지 않기 위한 장치를 마련(방어 로직)
예시) 스프린트 1에 팀원 중에 한명이 감기에 걸려서 3일 일을 못함
스프린트 2 회의를 할 때 위 상황을 대처할 수 있게 하는 방법?
버퍼를 넣어놓고, 시간이 남으면 추가로 할 작업도 생각
버퍼란?
예를 들어 8시간 일 한다고 가정했을 때 task 분배를 6시간~6시간 반 정도로 설정
스프린트는 주로 2~4주로 설정
Product Owner : 고객의 대표(데모 프로젝트 시에는 강사님)
Scrum Master : 스크럼을 주도적으로 이끄는 역할(데모 프로젝트 시에는 팀장)
Development Team(팀장과 팀원)
sprint(단거리 경주)(=Iteration planning)
Complement Product = 데모데이
스크럼끼리의 공유
팀 간 스크럼 공유도 해보자
어떻게 진행되고 있는지 알 수 있음
맨 마지막의 숫자 : story points
팀원들끼리 완료의 기준을 정함
ground rule에 코딩적인 룰도 정할 수 있음
하나의 task를 잡고 서로가 추정하는 걸리는 시간이 맞을 때 참조 story task의 기준점을 정함
참조 story task를 기준으로 스토리 포인트 추정
생각이 다를 시에는 논의 후 스토리 포인트 설정
참조 story task는 1로 잡지 않고 8 정도로 잡음
