[알쓸신잡] Agile..? (애자일)

[Agile]

2001냔 2월, "애자일 연합"이라는 그룹에서 '애자일 선언문'이라는 공동 선언서를 만들어 낸다.

http://agilemanifesto.org/principles.html

애자일 선언문

- 소프트웨어 개발의 기초 원칙과 정신으로 이야기 되고 있는 선언서

- 소프트웨어를 개발할 때 상호작용을 우선으로 하자는 선언문

애자일 선언문 내용

- 프로세스나 도구 보다는 개인과 상호 작용을

- 포괄적인 문서보다는 작동하는 소프트웨어를

- 계약에 대한 협상보다는 고객과의 협력을

- 계획을 고수하기 보다는 변화에 대응을 

- 전자의 내용보단 후자의 내용쪽에 더 많은 가치를 넣자

애자일의 장점

- 변경이 포용 됨 

- 계획주기가 짧으면 프로젝트 중 언제든지 변경 사항을 수용하고 수락하는 것이 쉽다.

- 최종 목표가 정의되지 않은 프로젝트에 대해서는 민첩함

- 프로젝트가 진행됨에 따라 목표가 밝혀진다.

- 더 빠른 고품질 제공

- 프로젝트를 반복단위로 분해하여 고객과 계속 소통을 함 

- 강력한 팀 간 상호 작용   

- Agile은 빈번한 의사 소통과 대면 인터렉션의 중요성을 강조하기 때문

- 고객은 전달되는 작업을 보고 입력을 공유하고 최종 제품에 실제 영향을 미칠 수 있는 많은 기회를 얻는다.

- 프로젝트 팀과 긴밀히 협력하여 소유권을 얻을 수 있음

- 지속적인 개선

- 민첩한 프로젝트는 전체 프로젝트에서 사용자 및 팀원으로부터 피드백을 유도하므로 학습 한 교훈은 향후 반복을 개선하는데 사용

애자일의 단점

- 납기일을 고정하기 어렵다

- 애자일 프로젝트 관리자는 종종 작업 우선 순위를 재 지정하기 때문에 어렵다

- 계속 고객과 소통을 해야하기 때문에 개선사항을 수정하느라 힘들수 도 있다.

- 팀은 지식이 있어야 한다

- 애자일 팀은 일반적으로 작기 때문에 팀 구성원은 다양한 영역에서 고도로 숙련되어야 한다.

-  초기 적응기간

- Agile은 개발 팀이 완전히 프로젝트에 전념 할 때 가장 성공적

- 문서는 무시 될 수 도 있다.

- 포괄적인 문서보다 작업 소프트웨어를 선호하기 때문

- 최종 제품은 매우 다를 수 있다.

- 초기 애자일 프로젝트는 최종 계획이 없을 수 있으므로 최종 제품은 초기와 다를 수 있다.

- 애자일 프로젝트는 매우 유연하기 때문에 고객 피드백을 기반으로 새로운것이 추가 될 수 있다.

애자일 개발 사이클

- 계획

- 아이디어가 실행 가능하고 실현 가능한지

- 요구 사항 분석

- 비지니스 요구 사항을 파악, 관계자와 사용자의 많은 회의가 필요

- 설계

- 요구사항을 토대로 작성

- 구현, 코딩 및 개발

- 기능을 만들고 테스트하고 배포

- 테스트

- 코드가 개발되면 요구 사항에 대해 테스트를 거쳐 제품이 실제로 고객의 요구 사항을 충족시키는지 확인

- 배치

- 고객에게 제공하여 제품을 사용할 수 있도록 함

애자일을 구현하기 위한 방법들(애자일 방법론이란 단어는 잘못 된 것)

- 익스트림 프로그래밍

-  Lean Software Development(LSD)

- 소규모 프로그래밍에 적합함

- Kanban

- Scrum

- 가장 많이 알려진 방법

-  FDD, DSDM 등 여러가지 방법들이 있다.

Scrum 방법론

- Agile의 하위 집합이며 Agile을 구현하기 위한 가장 널리 사용되는 프로세스 프레임워크중 하나

- 1~2주간 지속되는 스프린트라는 고정길이 반복을 통해 팀은 정기적 인종지에 소프트웨어를 제공

- 전대 변하지 않는 역할, 책임 및 모임을 따른다

- 스프린트 계획, 데일리 스탠드 업, 스프린트 데모 및 스프린트 회고와 같은 각 스프린트에 구조를 제공하는 4가지를 따른다.

 Scrum에서의 역할

- 제품 소유자

- 스크럼 제품 소유자는 자신이 무엇을 만들고 싶은지에 대한 비전을 가지고 있음

- 스크럼 마스터

- 미팅을 조직하고 로드 블록 및 문제를 처리

- 애자일 관리자라고도 불림

- 스크럼 팀

- 5명 ~ 7명으로 구성되며 전통적인 개발 팀과 달리 프로그래머, 디자이너 또는 테스터와 같은 별개의 역할이 없음

- 모두가 함께 같은 일련의 작업을 완료한다.

Scrum 프로세스에서의 단계

- 백로그 수정 / 정리

-  한 스프린트가 끝나면 팀과 제품 소유자가 만나서 다음 스프린트에 대한 회의를 한다.

- 스프린트의 우선 순위를 재평가하거나 우선순위를 다시 설정한다.

-  Daily Scrum meetings

- 15분간의 스탠딩 미팅으로 각 팀 구성원이 자신의 목표와 쟁점에 관해 얘기를 진행한다.

- 스프린트 검토 모임

- 각 스프린트가 끝날때 팀은 스프린트 검토 회의에서 완료 한 작업을 제공한다.   

- 보고서나 PowerPoint  프레젠테이션이 아닌 실시간 데모가 있어야 한다.

- Sprint 회고

- 각 스프린트가 끝날 때 Scrum이 얼마나 잘 작동하고 있는지 파악하고 다음 스프린트에서 변경해야 할 사항에 대해서 이야기한다.

Scrum에서의 방법과 도구

- 스크럼 보드

- 스크럼 작업 보드로 스프린트 백 로그를 시각화 할 수 있다.

- 스크럼 팀은 전체 스프린트 동안 보드를 업데이트 해야한다.

- 사용자 스토리

- 고객의 관점에서 소프트웨어 기능을 설명

- [사용자의 유형]으로서 [목표를 달성 할 수 있도록][작업 수행]을 원한다의 구조로 작성

- 번 다운 차트

- 수치를 눈으로 볼 수 있는 차트

- 모든 수행된 작업들을 나타낸다.

- 일반적으로 가로축을 따라 시간과 함께 세로 축에 있다.

- 남은 작업은 스토리 포인트, 이상적인 날, 팀 일 또는 기타 매트릭으로 나타낼 수 있다.

- 계획에 따라 일이 진행되지 않는 경우 팀에 경고하고 의사 결정의 영향을 보여준다.

Waterfall?

- Waterfall 방법론은 순차적 인 선형 프로세스를 따르며 소프트웨어 엔지니어링 및 IT 프로젝트를 위한 개발 방법론

- [waterfall 단계, 장점, 단점]

Kanban

- 시각적 표시, 카드의 일본어

- Agile을 구현하는 데 사용되는 시각적 프레임 워크로서 시점 및 수행을 보여줌

- 현재 시스템에 대한 작고 점진적인 변경을 권장하며 특정 설정이나 절차가 필요하지 않음

- 제품을 출시할때에는 사용하지 않지만, 제품을 유지보수할 때에는 Kanban을 자주 사용함

- Agile의 한 가지 방법

Kanban의 원칙

- 워크플로우 시각화

- 진행중인 작업 제한

- 흐름을 관리하고 향상시킴

- 명시적 프로세스 정책

- 지속적으로 개선됨

Agile vs Waterfall

- 유연성에서는 Agile이 더 좋음

- 요구상항은 Waterfall에서 작성해야하지만, Agile에서는 작성하지 않음

Agile vs Scrum

- Scrum은 철학이지만 Agile은 철학이 아님

- Agile은 방법론이 아니지만 Scrum은 방법론임

Kanban vs Agile

- Kanban은 지속적인 흐름을 가지고 있지만 Agile은 아님

- Kanban은 방법론이지만 Agile은 방법론이 아님

Kanban vs Scrum

- Kanban은 유지보수측면에서 유용, Scrum은 개발에서 유용

- Scrum은 요구사항을 추정하면서 만들 수 있지만, Kanban은 아니다

- Kanban은 하나의 보드를 사용하지만 Scrum은 아니다

그럼 Waterfall은 언제 사용해?

- 범위의 변경은 기대하지 않고, 고정된 가격 계약으로 작업하는 경우

- Scrum의 경우 가격 계약이 계속 변경

- 프로젝트는 매우 간단하거나 여러 번 해본 적이 있는 경우

- 요구 사항은 잘 알려져 있고 고정되어 있을 때

- 고객이 원하는 것을 정확하게 미리 알고 있는 경우

- 질서 정연하고 예측 가능한 프로젝트로 작업하고 있는 경우

그럼 Agile은 언제 사용해?

- 최종 제품이 명확하게 정의되어 있지 않음

- 클라이언트 / 이해 관계자가 범위를 변경할 수 있어야 함

- 변경 사항이 전체 프로세스 중에 구현되어야 함

- 개발자가 적응 가능하고 독립적으로 사고 할 수 있음

- 빠른 배포를 위해 최적화해야 하는 경우

그럼 Scrum은 언제 사용해?

- 프로젝트 요구 사항이 바뀌고 진화하는 경우

- 지속적인 피드백이 필요한 경우

- 작업의 대부분을 수행하는 방법을 파악해야 하는 경우

- 고정 된 날짜에 커밋할 필요가 없는 경우

- 프로젝트 팀이 자율성을 원하는 경우

- 정기적으로 소프트웨어를 제공해야 하는 경우

- 좋은 소프트웨어를 개발하고 싶은 경우

그럼 Kanban은 언제 사용해?

- 반복을 요구하지 않는 프로젝트

- 언제든지 배포 할 수 있는 것을 원하는 경우

- 팀이 변화를 선호할 때

- 팀이 가시성과 잘 어울릴 때

- 팀의 배포 흐름을 개선하고 싶을 때

- 이해하기 쉬운 시스템을 찾고 있을 때