Agile

애자일(Agile)

목적을 달성하고, 성과를 최대화하는 방법

• 관계자는 목적 달성을 위해 서로 협력한다.
• 이용자나 관계자의 피드백을 들어가며, 계획을 조정한다.
• 한번에 정리하는 것이 아니라, 조금씩 만든다.
• 실제로 만든 것이, 원래 요구와 맞는지 수시로 확인한다.

폭포수 VS 애자일

폭포수(Waterfall) 방법론은 그림에서 알 수 있듯이 소프트웨어 개발 단계가 위에서 부터 아래로 폭포에서 물이 떨어지듯이 순차적으로 진행된다. 폭포수 방법론은 한단계씩 진행함에 따라 다시 이전 단계로 가지 않고 계속 진행하기에 다음 단계로 가기전에 요구사항을 완벽하게 반영하여 개발했다는 것을 전제로 한다.

수직적으로 진행되기에 각 과정에 대한 이해가 용이하나 개발 도중에 요구사항이 변경되었을 경우, 추가적인 비용과 시간이 들게 된다.(수정사항을 반영하여 처음부터 진행해야 함)

애자일(Agile) 방법론은 폭포수 방법론과 다르게 소프트웨어 개발 단계를 명확하게 구분하지 않고 각 단계를 반복적으로 수행하면서 진행한다. 이때 요구사항을 추가하거나 제외하면서 소프트웨어를 개발하게 된다. 잦은 요구사항의 변경이나 큰 프로젝트를 맡게 되어 요구사항 분석 및 설계를 완벽하게 하기 어려운 경우, 애자일 방법론은 폭포수 방법론보다 적합한 개발 방법론이 될 수 있다.

개발 도중에 요구사항이 변경되었을 경우, 해당 요구 사항을 반영하기 용이하고 개발하면서 지속적으로 테스트 되기에 개발 초기에 버그를 발견할 수 있다.

애자일 개발

'사전에 모든것을 정확히 예측하고, 계획하는 것은 불가능하다' 는 전제를 의식하고 있어야 한다. 미리 대략적인 전체상을 명확히 한 후에 어느 정도의 기간과 인원으로 일을 하는가를 결정한다. 그 범위 안에서 중요한 순서로 '프로덕트'를 만든다. (프로덕트 = 실제로 만들 수 있는 것, 문서 포함)

❗️중요 : 리스크가 큰 것을 먼저 만들고, 우선순위가 낮은 것은 나중으로 미루어, 요구분석, 설계에 시간을 적게 쓸 것.

❓ 모든 것을 정확히 예측하고, 계획한다는 것?

• 얼마나 기간이 걸리는가
• 몇 명이 투입 되는가
• 얼마나 비용이 발생하는가

스크럼(Scrum)

애자일 방법론의 한 가지로 전원이 하나가 되어 작업, 회의, 성과물을 정하는 것이다.

• 요구를 미리 정리하여, 순서대로 프로덕트를 만들어 성과를 최대화한다.
• scrum에서는 실현되는 가치나 리스크, 필요성을 기준으로 한다. 고정된 짧은 단위 시간으로 나누어 작업을 진행한다.
• 현재 상황이나 문제점을 항상 명확히 한다. (투명성)
• 정기적인 진척상황이나 만들고 있는 프로덕트가 올바른가, 일의 진행 방법에 문제가 없는가를 확인하고 일의 방법에 문제가 있거나, 더 좋은 방법이 있다면 그 방법으로 변경한다. (적응)

요구를 정렬한다.
현실화 할 수 있는 것을 List화 하여 정렬한다. 항상 유지보수하여 최신으로 유지한다.

프로덕트 오너(P.O)

backlog의 관리자로, 프로젝트에 반드시 한 명이 필요하며 순서의 최종 결정권한을 가지고 결과를 책임진다. 개발팀을 활용해, 프로덕트 가치를 최대화한다. 그 과정에서 개발팀과 상담은 가능하나, 간섭은 할 수 없다.

P.O가 해야할 일

• 백로그 정리
• 프로덕트의 비전을 명확히 하고, 주변과 공유
• 대략적인 릴리즈 계획을 결정
• 예산 관리
• 고객, 유저, 경영자 등의 프로덕트 관계자와 프로덕트 백로그 항목의 내용을 확인하거나, 만들 순서나 구현시기를 상담
• 기존 프로젝트 백로그 항목의 내용을 최신 상태로 갱신
• 프로덕트 백로그 항목의 내용을 관계자가 이해할 수 있도록 설명
• 완성된 프로덕트가 요구에 맞는지 검사

프로그램 개발

• 릴리즈 판단 가능한 프로덕트를 만든다.
• 3~9명으로 구성
• 전원이 모이면 프로덕트를 만들 수 있다.
• 상하관계 없음

스프린트(Sprint)

최장 1개월까지의 고정된 기간으로 나누어, 반복하여 개발하는데, 이 고정된 기간을 스프린트라고 한다. 개발팀은 이 기간 중에 계획, 설계, 개발, 테스트 전부를 수행한다. 스프린트 기간은 고정이며 변동되어서는 안 된다.

1. 자주 계획한다.
   스프린트에서 무엇을 만들 것인가? 어떻게 만들 것인가? → 스프린트 계획 미팅

   • 스프린트에서 개발하기 위한 계획이 필요
   • P.O는 무엇을 원하는가
   • 개발팀은 얼마만에 가능하다고 예상되는가
   • 개발팀은 어떻게 그것을 실현할 것인가

2. Sprint Backlog
   선택한 Product Backlog 항목을 완료시키기 위해 필요한 작업을 개발팀에서 정리하는 작업들을 task라고 하고, task의 일람을 Sprint Backlog라고 한다.

   • 프로덕트 백로그를 구체적으로 task로 분리한다.
   • task는 나중에 추가하는 것이 가능하다.

3. 릴리즈 판단 가능한 프로덕트
   완료의 정의에 의해 무엇으로 릴리즈 판단 가능한지를 정한다. 도중에 축소는 피한다.

   완료의 정의 : 코드 리뷰, 유닛 테스트, 커버리지, 문서화, 보안, 성능 등

4. 매일 상황을 확인한다.
   데일리 스크럼(15분 정도)을 통해 개발팀의 상황을 매일 확인한다.

   • 스크럼 내용 : 이전 데일리 스크럼에서 한 일, 다음 데일리 스크럼까지 할 일, 곤란해하고 있는 것

5. 완성된 프로덕트를 확인한다.
   스프린트 리뷰(1시간 정도)를 통해 개발팀의 성과를 P.O가 확인한다.

   • 개발팀이 완료 못 한 backlog 항목에 대해 설명
   • P.O가 프로덕트 상황이나 개발 환경에 대해 설명
   • backlog에 추가해야 할 항목 유무에 대한 논의
   • 프로젝트를 진행하면서 문제가 되는 사항에 대해 논의
   • 현재의 진행을 토대로, 릴리즈 및 완료일을 예측

6. 스프린트 되돌아보기
   스프린트 종료 회의(1시간 정도)를 통해 프로세스나 tool 등의 관점에서 이번 스프린트를 검사한다. 잘 된 점, 개선해야 할 점 등을 관리하고 이후의 계획을 만든다.

스크럼 마스터

P.O나 개발팀을 지원하는 역할을 한다.

• 프로세스가 잘 돌아가도록 한다.
• 방해를 제거한다.
• 각종 지원을 한다.
• 교육, 코칭, 추진 역할

스크럼 마스터가 할 일

• 알기 쉬운 backlog 작성법을 P.O나 개발팀에게 가르친다.
• backlog의 좋은 관리 방법을 찾는다.
• P.O나 개발팀에게 애자일 개발이나 Scrum에 대해 설명하고 이해시킨다.
• 스프린트 계획 회의나 스프린트 종료 회의 등의 진행을 필요에 의해 행한다.
• P.O와 개발팀의 대화를 촉진한다.
• P.O나 개발팀의 생산성이 높아지도록 변화를 촉진한다.