애자일 방법론

기존 프로세스 = 폭포수 모델

• 폭포수 모델 (Waterfall) : 전체적인 계획과 마감 일이 정해져 있고 “기획 > 디자인 > 개발 > 테스트 > 배포 > 유지 보수” 순으로 한 단계 가 끝나면 다음 단계로 넘어감.

단점

• 한 단계에서 문제 or 요구 사항이 생기면 다시 처음 단계로 돌아가 차례차례 진행된다. ex) 기획, 디자인을 거쳐 개발 단계 까지 왔는데 정작 개발에서 안된다고 하면, 다시 기획부터 시작해서 단계가 반복 된다.
  
• 기존에 하던 일을 날릴 수 있고(시간 낭비), 수정 사항을 적용하는데 시간이 많이 걸린다.
• 실질적으로 거듭되는 수정사항으로 인해 마감일을 지키기 어렵다.

➡️ 프로세스의 유연성이 떨어짐.

애자일(Agile) 방법론

• 고객과 제품을 중심으로 일정한 주기를 가지고 끊임없이 프로토타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 방법. ➡️ 그때 그때 마다 유연하게 개발하자!
  

애자일 소프트웨어 개발 선언

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

애자일 원칙

1. 우리의 최우선 순위는 가치(value) 있는 소프트웨어를 초기부터 지속적으로 제공(배포)함으로써 고객을 만족시키는 것입니다.

2. 개발 후반부에 변화하는 요구 사항의 수용을 환영합니다. Agile 프로세스는 변화를 수용하며 고객의 경쟁력을 돕습니다.

3. 소프트웨어를 짧은 주기(2주에서 2달까지)로 동작하는 소프트웨어를 배포하되 더 짧은 주기를 선호합니다.

4. 비즈니스 담당자와 개발자는 프로젝트 전체 기간 동안 매일 함께 일해야 합니다.

5. 동기가 부여된 개인들 중심으로 프로젝트를 구축합니다. 그들에게 필요한 환경과 지원을 제공하고 업무를 완수 할 것을 믿습니다.

6. 개발 팀에 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.

7. 작동하는 소프트웨어가 진척의 주요 척도입니다.

8. Agile 프로세스는 지속 가능한 개발을 장려합니다. 스폰서, 개발자 및 사용자는 일정하게 속도를 유지할 수 있어야 합니다.

9. 우수한 기술과 우수한 디자인에 대한 지속적인 관심은 민첩성(agility)을 향상 시킵니다.

10. 단순성(수행되지 않은 작업량을 최대화하는 기술)은 필수적입니다.

11. 최고의 아키텍처, 요구 사항 및 디자인은 자기 조직화 팀(Self-Organization Team)에서 나옵니다.

12. 팀은 정기적으로 보다 효과적인 방법을 적용해보고, 그에 따라 행동을 조율하고 조정합니다.

스크럼(Scrum)

• 애자일 방법론을 적용한 대표적인 프로세스

출처 - https://insight-bgh.tistory.com/259

1. 제품 기능 목록 작성

   • 개발 제품에 대한 요구사항(backlog) 목록 작성
   • PO (Product Owner)가 어떤 요구사항(backlog)부터 개발 해야 할지 우선순위를 정함.
   • 일반적으로 한 주기가 끝날 때 까지는 제품 기능 목록을 수정하지 않음.

2. 스프린트(Sprint) 계획 회의

   아래의 항목들을 정함.

   • 세부적으로 구현 해야 될 것
   • 작업자
   • 예상 작업시간

3. 스프린트(Sprint) 수행

   ❓ 스프린트 Sprint) : 육상, 수영, 스피드 스케이트 등의 단거리 레이스, 또는 단거리를 전력으로 행하는 질주
   • Task를 너무 크게 잡지 아니하며, 단기간 동안(보통 2주) 전력 질주 하듯이 업무를 수행한다.
   • 스프린트 주기 동안 도중에 개발 내용이 바뀌지 않아야 하고, 팀원(7~8명 정도)들 동의 없이 바꾸지 않는다.
   • 스프린트 수행 하는 동안은 SM(Scrum Master)가 관리 함.

4. 일일 스크럼 회의

   • 모든 팀원들이 모여 짧게(약 15분) 상황 점검. 파악하는 사항
     • 어제 한일
     • 오늘 할 일
     • 문제점 및 어려운 점
   • 사항들을 고려하여 세부 작업 항목을 업데이트 한 뒤 전체 공유.

5. 제품 완성 및 스프린트 검토 회의

   • 고객 앞에서 최종 제품 시연
   • 고객의 요구사항을 얼마나 부합했는지 피드백 수용

6. 스프린트 회고

   • 스크럼 과정, 완성 제품을 되돌아보며 개선 할 점, 잘한 점을 검토 함.

참고 문헌

• https://evan-moon.github.io/2019/07/02/what-is-agile/
• https://ko.wikipedia.org/wiki/폭포수_모델
• https://ko.wikipedia.org/wiki/애자일소프트웨어개발
• http://agilemanifesto.org/iso/ko/manifesto.html
• https://medium.com/hgmin/agile-principles-애자일-12가지-원칙-d3f386bd9839
• https://insight-bgh.tistory.com/259
• https://velog.io/@phs880623/애자일-방법론과-CI-CD