애자일이란 무엇일까?
- 짧은 반복 주기와 고객과 개발자 사이의 원할한 커뮤니케이션으로 생산성을 높는 개발 방법론?
애자일 이전에 왜 프로젝트가 실패했는지에 대해서 생각해보고, 애자일이 무엇인지를 이해해 보자.
또 애자일을 실천하면서 우리가 얻을 수 있는 가치들도 생각해보자.
1. 애자일 소개
애자일의 역사
제조업과 산업 전반적으로 과학적 관리법이 성공적으로 자리 잡고 있었다.
→ 계획을 세우는 데 먼저 많은 노력을 들인 다음, 그 계획을 주의 깊고 세세하게 실천하는 것 (하향식, 지휘 및 통제 접근법)
→ 효율성과 생선성을 극적으로 향상시켰다.
선애자일 (pre agile)
→ 조금씩 걸어보고 측정을 한 후 그에 맞추어 개선하기를 반복하는 방법
Q. 소프트웨어 프로젝라는 것이 어떤 종류의 프로젝트인가?
변경 비용이 많이 들고 명확한 목표가 상세하게 정의된 것인가? → 과학적 관리법
변경 비용이 적게 들고 불명확한 목표를 분완전하게 정의된 것인가? → 애자일
폭포수 → 과학적 관리법의 이론적인 후예
스노버드
17명의 백인 남성
애자일 선언과 가치
- 공정과 도구보다 개인과 상호작용
- 포괄적인 문서보다 작동하는 소프트웨어
- 계약 협상보다 고객과의 협력
- 계획을 따르기보다 변화에 대응하기
http://agilemanifesto.org/iso/ko/manifesto.html
스노버드 이후
일하는 방식을 아무것도 바꾸지 않으면서 동의할 수 있다.
애자일 개요
애자일 이전에 대부분 실패
- 매일 야근을 하지만 일정을 맞추지 못하는 개발팀
- 만드는 제품의 품질이 낮아서 고객이 원하는 것 근처에 미치치 못하는 팀
철십자
좋음, 빠름, 저렴함, 완성 이 중 셋만 고를 수 있다.
좋은 관리자는 네 가지 속성의 가중치를 관리하지, 모든 속성이 100%가 되기를 요구하지 않는다.
벽에 걸린 차드
관리자가 좋은 결정을 내리는 데 필요한 딱 맞는 데이터를 생산한다.
스토리 포인트 + 번다운 차트
언제쯤 끝날지 예측 가능할 거 같지만 남아있는 포인트가 늘수도 있다.
→ 요구사항의 변화
팀의 속도(스토리 포인트 처리 속도), 번 다운 차트 (남은 스토리 포인트)
→ 애자일 선언에서 차트를 말하지 않는다 진짜 필요한건 데이터다
→ 팀이 어떤 속도로 움직이고, 목표 달성까지 얼마나 남았는지
가장 먼저 알게 되는 것 (폭포수 모델의 진행)
마감 기한
요구사항은 유동적
회의
폭포수 모델로 해결을 시도
분석 → 설계 →구현
분석 단계
프로젝트의 규모들 추산하고, 기본적인 실현 가능성 검증, 인력 계획
→ 하지만 분석의 종료는 일정이 그냥 다다르면 종료됨
설계단계
프로젝트를 모듈로 나누고, 인터페이스를 설계.
몇 개의 팀이 필요하고 팀 사이의 연결은 어떻게 할지 정의
→ 마찬가지로 시간이 다 되면 종료됨
구현 단계
코딩을 한다
요구 사항이 계속 변경된다.
마감이 되지 않는다.
죽음의 행진 단계
고객이 화가남
과장?
최악의 상황을 묘사하고 있는게 맞다.
더 나은 방법
애자일은 분석을 계속 한다.
프로젝트 일정을 일정한 크기 (스프린트) 로 더 작게 나누고
그 주기마다 분석, 설계, 구현을 한다.
반복 주기 0
기능 목록을 만든다. (스토리)
개발 환경을 준비하고, 스토리의 크기를 추산하고 최초의 계획을 세운다.
스토리를 쓰고, 크기를 추산하고, 계획을 세우고, 설계하는 과정은 끝없이 계속된다.
애자일은 데이터를 만든다
반복 주기 1이 끝나면 우리가 계획했던 스토리 중 일부만 완료했을 것이다.
이를 통해 종료 일자를 계산할 수 있다. 하지만 안됨
반복 주기가 진행될 수록 오차 범위가 줄어들 수 있다.
희망 대신 관리
희망을 없애는 것이 애자일의 목표
→ 애자일을 실천하면 희망이 프로젝트를 죽이기 전에 희망을 파괴할 수 있다.
우리가 얼마나 망했는지를 빨리 알아내는 것 →그래야 상황 관리가 됨
철십자 관리하기
- 일정 변경하기 → 가능성 희박
- 사람 추가하기 → 브룩스의 법칙
- 품질 떨어뜨리기 → 빠르게 가는 유일한 방법은 제대로 가는 것이다.
- 범위 변경하기 → 우선순위를 정하고 일정안에 해결해야 하는 범위를 조정한다.
비지니스 가치 순서
이해관계자가 원하는 순서대로 기능을 구현해야 한다.
개요가 끝났다.
애자일은 프로젝트를 더 작은 반복 주기로 나누는 프로세스다.
각 주기의 결과물을 측정하여 지속적으로 일정한 평가하는 데 사용한다.
그렇게 해서 범위를 조절한다.
삶의 순환
바깥 고리 : 비지니스와 관련된 XP 의 실천
-
계획 게임 : 프로젝트를 기능, 스토리, 작업으로 쪼개는 방법을 알려준다.
→ 크기추정, 우선순위 결정, 기능이나 스토리 작업의 일정을 정하는 데 필요한 지침
-
작은 릴리즈 : 조그만 크기로 나누어서 하도록 이끈다.
-
인수 테스트 : 기능이나 스토리 작업의 '완료'를 정의할 수 있게 해준다.
-
전체 팀 : 소프트웨어 개발팀이 여러가지 역할로 구성되어 있음을 나타낸는 개념
→ 프로그래머, 테스터, 관리자
가운데 고리 : 팀과 관련된 실천 방법
- 지속 가능한 속도 : 개발팀이 자원을 너무 빠르게 소진한 나머지 결승선에 도달하기도 전에 탈진해 버리는 것을 막기 위함
- 공동 소유 : 팀이 프로젝트의 정보 공유
- 지속적 통합 : 피드백 고리가 자주 돌개 만드는 데 집중하도록 만든다. 팀의 현재 위치를 알수 있게
- 메타포 : 팀과 사업 부서가 의사소통할 때 사용하는 어휘나 표현을 만들고 널리 공유하는 실천 방법
안쪽 고리 : 기술 실천 방법
- 짝 프로그래밍 : 지식을 공유하고, 서로 리뷰하고, 협력하도록 하여 혁신과 정확성을 끌어내는 실천 방법
- 단순한 설계 : 팀이 노력을 낭비하지 않도록 도와주는 실천 방법
- 리펙터링 : 모든 작업 산출물의 지속적인 개선과 향상을 장려한다.
- 테스트 주도 개발 : 기술팀이 최고의 품질을 유지하면서도 빠르게 움직이기 위해 사용하는 안정망.
애자일 선언의 목표와 연관 시켜보자.
-
공정과 도구보다 개인과 상호작용
→ 전체 팀, 메타포, 공동 소유, 짝 프로그래밍, 지속 가능한 속도
-
포괄적인 문서보다 작동하는 소프트웨어
→인수 테스트, 테스트 주도 개발, 단순한 설계, 리펙터링, 지속적 통합
-
계약 협상보다 고객과의 협력
→ 작은 릴리스, 계획 게임, 인수 테스트, 메타포
-
계획을 따르기보다 변화에 대응하기
→ 작은 릴리스, 계획 게임, 지속 가능한 속도, 테스트 주도 개발, 리펙터링, 인수 테스트
결론
애자일은 작은 소프트웨어팀이 작은 프로젝트를 관리할 수 있게 도와주는 작은 규칙이다.
