https://hanminwoo.com/33 ## 애자일 소프트웨어 개발
- 애자일 소프트웨어 개발 선언
https://agilemanifesto.org/iso/ko/manifesto.html
* 공정과 도구보다 개인과 상호작용을
* 포괄적인 문서보다 작동하는 소프트웨어를
* 계약 협상보다 고객과의 협력을
* 계획을 따르기보다 변화에 대응하기를
- 애자일 선언 이면의 원칙
http://agilemanifesto.org/iso/ko/principles.html
애자일 소프트웨어 개발은 소프트웨어 개발방법중 하나로
프로젝트의 생명주기동안 반복적인 개발을 촉진함
개획이 없는 방법과 계획이 지나치게많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이며
폭포수 모델 이나 나선형 모델과 구별되는 가장 큰 차이점은 문서를 통한 개발(less document-oriented,)
방법이 아니라 실질적인 코딩을 통한 방법론(code-oriented) 임
일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그떄 그때 필요한 요구를 더 하고 수정하여
하나의 커다란 소프트웨어를 개발해 나가는 adaptive style 이라고 할수 있음
https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C
https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C
- 익스트림 프로그래밍(Extreme Programming, XP)
애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 했음.
이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트우선 개발(TDD)을 특징으로 하는 명시적인 기술과 방법을 가지고 있음
- 스크럼
30일마다 동작 가능한 제품을 제공하는 스프린트(Sprint)를 중심으로 하고 있음.
매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론임
프로젝트 관리를 위한 상호, 점진적 개발방법론, 소프트웨어 개발 프로젝트를 위하여 고안되었지만
소프트웨어 유지보수팀이나 일반적인 프로젝트 관리에서도 적용 할 수 있음
- 크리스털 패밀리
이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공함.
그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론암
- Feature-Driven Development
feature마다 2주정도의 반복 개발을 실시함.
Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가짐.
- Adaptive Software Development, ASD
소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론임.
내용적으로는 다른 방법론들과 유사하지만, 합동 애플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는 것이 조금 다름
- 익스트림 모델링
익스트림 모델링은 UML을 이용한 모델링 중심 방법론임.
다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 함
- 스프린트 (Sprint):
반복적인 개발 주기.
계획 회의부터 제품 리뷰가 진행되는 날짜까지의 기간이 1 스프린트.
예) 회사에서 정하는 이터레이션이 개발 주기가 될 수도 있음.
- 이슈(Issue):
- 에픽 (Epic):
에픽은 많은 사용자 스토리, 많은 작은 단위 업무로 나눌 수 있는 업무의 큰 틀.
하나의 Sprint에 걸쳐서 끝나지 않고, 여러 Sprint에 걸쳐서 종료되며, 여러 Story들의 집합. 주로 Major Feature들을 중심으로 정의함.
- 스토리 (Story):
서비스 고객에게 가치를 줄 수 있는 기능을 서술한 것.
각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성하는 것이 좋음.
예) [(역할을 가진) 사용자]는 [행위 / 목표]를 수행하여 [이유]를 한다.
- 태스크 (Task):
에픽 or (사용자) 스토리의 하위 작업으로 에픽 / (사용자) 스토리를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업
예) 유사 기능 조사, 테스트 시나리오 작성 , 기능 개발
- 서브태스크 (Sub-Task):
(사용자) 스토리의 하위 작업으로 에픽 / (사용자) 스토리를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업
- 백로그 (Backlog)
- 제품 백로그 (Product Backlog):
제품에 대한 요구사항을 모아둔 곳
- 스프린트 백로그 (Sprint Backlog):
(제품에 대한 요구사항 중에) 해당 스프린트에 진행할(한) 요구사항을 모아둔 곳
- 스프린트 운영
- 그루밍 (Grooming):
"다음 스프린트에 들어가기 전에 PO(PM)가 다음 스프린트에 개발할 기능에 대해서 대략적으로 리뷰 하는 행위" (스프린트 진행 중에 일어남)
[WHY]
- 다음 스프린트에 대한 가시성 확보 (미리 생각할 시간을 줍니다.)
- 개발 개시 전 리뷰를 통해서 개발 가능성, 기획상 구멍을 찾아서 수정할 시간을 갖음
[HOW]
- 1시간 정도로 사용자 스토리나 UX 프로토타입을 리뷰
- 가급적 실제로 돌아가는 UX 목업이 좋음 (애니메이션 복잡도 등을 미리 예측 가능)
- 스토리포인트 미팅 (Story point meeting):
등록된 사용자 스토리의 개발 추정 기간을 산정, 많이 활용하는 개발 추정 도구는 "플래닝 포커"이며 보통은 제품 백로그(Product Backlog)에 스토리포인트를 추정함
경우에 따라 스프린트 백로그(Sprint Backlog)의 스토리를 다시 추정하기도 합니다.
애자일 스크럼과 JIRA https://www.slideshare.net/Byungwook/jira-61442816
- 플래닝 포커 (Planning poker):
다른 말로 스크럼 포커 라고도 불리는데, 이는 추정을 위한 합의 기반 기술(consensus-based technique)로써 대부분 소프트웨어 개발에 있어서 개발 목표를 위한 공수 산정이나 상대적 규모산정에 사용함
숫자를 숨기는 이런 방식은 구성원들의 편향적인 고정관념을 피할수 있게 해줌.
플래닝 포커는 광대역 델파이(Wideband delphi)의 한 형태라고 함.
플래닝 포커 https://ko.wikipedia.org/wiki/%ED%94%8C%EB%9E%98%EB%8B%9D_%ED%8F%AC%EC%BB%A4
- 계획 미팅 (Planning meeting)T
he What
PO(PM)가 스프린트의 목표와 어떤 백로그(backlog)가 그 목표에 기여하는지 설명함.
스크럼팀은 다음 스프린트 동안에 종료(Done)할 백로그를 결정함
The How
개발팀은 스프린트 목표를 달성하기 위한 필요한 작업 계획을 세움.
궁극적으로 스프린트 계획의 목표는 개발팀과 PO(PM) 간의 노력과 가치 기반 협상
(일정 수준의 노력으로 가장 가치가 높은 작업을 선정하고 실행 계획을 세우는 것)
The Who
개발팀과 PO(PM)없이 스프린트 계획 미팅을 할 수 없음.
PO(PM)은 그가 원하는 가치 기반 목표를 정의함.
개발팀은 그 목표를 어떻게 달성할 수 있는지 혹은 달성할 수 없는지 이해할 필요가 있음.
만약에 둘 중 하나라도 이 이벤트로부터 놓친 것이 있으면 계획 미팅은 거의 불가능함
The Inputs
스프린트 계획에서 가장 중요한 시작점은 제품 백로그임.
제품 백로그는 잠재적으로 현재 스프린트의 일부가 될 수 있는 '스터프(stuff)' 리스트를 제공함.
스크럼팀은 또한 점진적으로 수행된 기존 작업을 살펴보아야 하고 팀이 수행할 수 있는 양(Capacity)에 대해서 고려해야 함.
The Outputs
스프린트 계획 미팅에서 가장 중요한
산출물은 팀이 스프린트의 목표를 설명할 수 있다는 것과 그들이 목표를 향하고 있는 업무를 어떻게 시작할 수 있는 설명하는 것임.
이것이 스프린트 백로그로 보여집니다.
Sprint planning https://www.atlassian.com/agile/scrum/sprint-planning
- 스프린트 리뷰 (Sprint review)
Step 1: 종료기준을 정의합니다. (Define 'done')- 받아들일 수 있는 기준 (Aceeptance criteria)- 테스트 방법 기록 (Testing notes)
Step 2: 서로 축하합니다. (Celebrate the team)
Step 3: 공유합니다. (Reach across geographies)(필요하다면) 데모
Agile Sprint Reviews https://www.atlassian.com/agile/scrum/sprint-reviews
- 회고 미팅 (Retrospective meeting):
잘한 것, 반성할 것, 개선할 것에 대한 이야기를 나누는 시간“팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다."
스프린트 회고하기 https://agileit.tistory.com/23Agile
Retrospectives https://www.atlassian.com/agile/scrum/retrospectives
- 소멸 차트 (Burn down chart):
시간 대비 남아 있는 일의 양을 표현.
작업물 or 백로그(bakclog)를 수직축에 표현하고 수평축에는 시간을 표현함.
즉 작업물의 진행 차트. 모든 작업들이 완료되는 시점을 예측하는데 유용