애자일 소프트웨어 개발(Agile software development) 혹은 애자일 개발 프로세스
소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다.
최근에는 애자일 게임 보급 등의 여파로 소프트웨어 엔지니어링 뿐 아니라 다양한 전문 분야에서 실용주의적 사고를 가진 사람들이 애자일 방법론을 적용하려는 시도를 하고 있다.
종류
애자일 개발 프로세스로 불리는 개발 방법론에는 다음과 같은 것들이 있다.
- 익스트림 프로그래밍(Extreme Programming, XP) - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트우선 개발(TDD)을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.
- 스크럼 - 30일마다 동작 가능한 제품을 제공하는 스프린트(Sprint)를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.
- 크리스털 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.
- Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.
- Adaptive Software Development - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. 내용적으로는 다른 방법론들과 유사하지만, 합동 애플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는 것이 조금 다르다.
- 익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다. 다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다.
---------------------------------------------------------------------------
Agile 의 업무방식
- 매일매일 업무 회의하기
서로 요즘 하고 있는 일의 진척 상황을 공유하고. 오늘 할 일을 팀원들에게 전달하거나, 도움이 필요한 일을 이야기합니다. 팀원 10명이 모여서 진행하지만 15~20분정도 소요됩니다.
회의 준비도 별것 없이 자기가 하는 업무를 간략하게 정리해서 이야기하면 되는 부분이다.
업무에 속도가 붙지 않거나 문제가 생기면 즉각 발견할 수 있고, 대처가 가능하다.
팀의 업무효율은 증가할 수 있으나, 사람이 피곤할거같다.
- 업무진행에 있어 문서 남기지 않거나 최소화하기
별도의 개발관련 문서를 남기지 않는 게 원칙인 시스템이다.
정말 필요한 것만 작성해서 문서작성의 시간을 줄이고, 그 시간에 개발을 더해 생산성을 늘리는 방식이다.
다만 업무의 인수인계에 대한 고려는 에자일 업무에 해당하지 않는 것으로 보인다.
- 별도의 아이스 브레이킹 시간을 갖는다.
업무의 하나로써 자기의 일상이나 최근에 관심가진 인사이트, 취미 등 5~10분정도 서로의 일상을 공유하기도 한다.다.
재택근무가 많아지고 자기 할일이 많아지다보니 대화할 시간이 없는 만큼,
팀의 분위기를 위해 별도로 신경을 쓰기도 한다.
이렇게 안하면 이야기할 여유를 가지기도 쉽지 않을 것이다.
- 스크럼을 짠다.
스크럼(Scrum)은 팀이 협업하고 영향력이 큰 업무를 수행하는 데 도움이 되는 애자일 프레임워크다.
왜 이걸 프레임워크라고 하는지는 알 수 없으나, 30일, 한달 내료 프로젝트를 완성하는 단위인 스프린트(전력질주) 단위로 업무를 나누어 진행한다.
스크럼 프레임워크는 스프린트(전력질주) 단위로 업무와 팀이 바뀌기도 하며, 지속적인 개선에 집중할 수 있도록 가치, 역할, 지침의 청사진을 제공한다
이를위한 스크럼 도구들이 있다.
--- Ex : Asana, Jira(Atlassian) 등
※ 스크럼에서 사용되는 역할
1.제품 책임자(Product Owner)
비즈니스 목표를 충족시키는 제품을 만들기 위해 제품 백 로그를 관리하고 제품을 검토한다.
※ 제품 백로그(요구사항) 관리/설명
※ 제품 백로그의 우선순위 관리
※ 만족스럽게 개발되었는지 확인
2. 스크럼 마스터(ScrumMaster)
Product Owner와 Development Team이 가치(Value)와 원칙(Principle)으로 성공적인 제품을 만들고, 조직 변화를 촉진하고 민첩한 작업 방식을 수립하여 유지할 수 있도록 책임을 가진다.
※ 팀을 보호하고 장애 요소를 해결
※ 일일 스크럼 회의를 진행
※ 모니터링 및 Tracking
- 백로그 관리
수행해야 하는 업무들을 리스트화 하여 단위별로 프로젝트 화 시키고 수행한다.
수행이 완료된 내용들과 이후 새로 진행할 업무를 갱신해가며 끊임 없는 개발을 진행함으로써
업무 성과의 효율이 좋은 방식이다.
-----------------------------------------------------------
애자일 개발방식의 원칙
- 약속: 팀 멤버들은 서로를 신뢰해야 한다. 팀 멤버들은 이 기간 동안 스프린트(전력질주)에 전념할 것을 약속하고, 최상의 솔루션을 찾기 위해 지속적으로 개선하는 데 전념한다.
- 용기: 팀은 정확한 해답이 없는 어려운 문제에 직면할 수 있다. 팀은 최선의 솔루션에 도달하기 위해 열린 마음을 가지고 어려운 질문을 던지고 솔직하게 답하는 용기를 가져야 한다.
- 집중: 스프린트(전력질주)를 수행할 때 끝날 때까지 결과물을 완료하기 위해 백로그에서 선택한 업무에 집중한다.
- 열린 마음: 개발을 진행하는데 있어 항상 완벽하게 진행되지는 않을 것이다. 팀 멤버들은 개인적으로 배울 수 있고 제품이나 프로세스를 개선하는 데 도움이 되는 새로운 아이디어와 기회에 열린 마음을 가져야 한다.
- 존중: 협업은 에자일의 핵심이다. 팀의 협업을 지원하기 위해 팀 멤버들은 다른 멤버, 팀장, 업무방식을 존중해야 한다.
------------------------------------------
애자일 개발 방법중 대표적인 스크럼의 진행 순서
1. PO는 제품의 요구기능(User Story)과 우선순위를 제품 백로그로 정한다.
2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다.
3. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.
(해설:PO는 기능과 우선순위에 대한 권한이 있고, 개발팀은 Sprint내에 해야 할 업무량을 결정할 권한이 있다. 특히 개발경험 있는 PO가 너무 적은 개발량을 문제제기 하기도 하지만, 실제 개발하는 개발팀원의 개발속도(Velocity)로 예측하며 조정이 중요하다.)
4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
5. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰(Review)를 통해 만들어진 제품을 검토하고 개선사항을 이해 한다.
6. 제품의 리뷰를 통해 제품의 지속적 개선사항 도출이 끝나면, 스프린트 회고(Retrospective)를 통해 팀의 개발 문화(프로세스)에 대한 개선의 시간을 갖는다.
(해설:스프린트 Review는 제품을 개선하는 활동이고, 회고는 우리(프로세스, 문화)를 성장시키는 활동이다.)
7. 다음 스프린트에서 수행할 백로그를 PO와 필요 인원이 모여 선정하고 계획하는 시간을 갖는다.
'IT기술 > CS(ComputerScience)' 카테고리의 다른 글
RTO와 RPO 뭐냐 이게? (0) | 2023.11.24 |
---|---|
Stateful | Stateless 서비스 (0) | 2023.11.24 |
소프트웨어 공학의 모든 것 - 유지보수 (0) | 2023.08.07 |
[CS] OOM의 원인과 아주 간단하게 OOM 발생 시키기 (0) | 2023.08.03 |
개발에서 빌드도구(Build tool) maven, gradle 살펴보기 (0) | 2023.04.18 |