애자일

등장배경 

- 초기 소프트웨어 개발 방법은 계획 중심의 프로세스

ex) 도시 계획으로 건축에서 사용하는 방법과 유사하며, 이런 프로세스를 활용하는 프로젝트가 대부분 

 

- 90년대 이후, 소프트웨어 분야가 넓어지면서 사용자들이 '일반 대중들'로 바뀌기 시작했고, 이로 인해 트렌드가 급격하게 빨리 변화하는 시대로 점차 바뀌어 나감.

 

- 이로 인해 제품 수명이 짧아지고, SW 개발의 불확실성이 높아지면서, 새로운 개발 방법이 등장하기 시작했다. 

 

" 규칙을 적게 만들고, 가볍게 대응을 잘하는 방법을 적용하자 "

 

- 경량 방법론 주의자들은 일단 해보고, 고쳐나가는 방식으로 개발하자는 방법이 팽배하기 시작했다. 

 

" 애자일 방법론 "

---

애자일 방법론

1. 애자일에서는 협력과 피드백을 더 자주하고 잘하는 것을 강조한다. 

 

가. 협력: 스스로 느낀 좋은 통찰은 협력을 통해 다른 사람에게도 전해줄 수 있고, 예상치 못한 팀의 기대 효과를 가져온다. 

 ex) 어떤 사람이 효율적인 코드를 만드는 방법을 발견함 -> 다른 사람들과 공유해서 모두 같이 빠르게 개발하고 더 멀리 나아갈 수 있는데 용이함.

 

나. 피드백: 내가 어떻게 확인하면서 학습을 진행하는 것이야 말로, 소프트웨어의 불확실성이 높은 만큼 학습의 중요도는 올라가게 된다.

ex) 내부적으로 내가 만든 것이 어떻게 됐는지 확인하고, 외부적으로는 내가 만든 것을 동료들에게 보여주고 사용해보면서 받은 피드백으로 부족한 부분들을 보완해 나가는 활동을 통해 한 단계 성장할 수 있는 발판을 만들 수 있음.

 

2. 애자일에서는 소프트웨어 개발의 불확실성을 중요하게 여긴다. 

 

가. 불확실성이 높으면, 우리가 예상하지 못한 것 상황에 직면할 수 있는 가능성이 높아진다. 

 

 1) 전통적 방법론: 과거의 행동을 후회한다. -> "계획을 세울 때 잘 세워서 지금 이런 상황이 닥치지 않도록 할 걸 그랬어"

 2) 애자일 방법론: 현재의 행동에 빠르게 대응한다. -> "이런 상황은 생각을 못했네, 다시 빨리 수정해 보자" 

 

나. 애자일 방법론에서는 개발과정에 있어서 모든 상황을 유연하고 기민하게 대응할 수 있다. 

---

스크럼 

- 애자일 방법론 중 하나로써 회의를 통해 스프린트 개발 주기를 정한 뒤, 이 주기마다 회의 때 정했던 계획들을 구현해 나가는 방법. 하나의 스프린트가 끝날 때 마다 검토 회의를 통해, 생산되는 프로토타입으로 사용자들의 피드백을 받으며 더 나은 결과물을 구현해낼 수 있음. 

 

* 스프린트: 작은 단위의 개발 업무를 단기간 내에 전력질주하여 개발

 

1. 스크럼 실행 순서 

 

 

2. 스크럼 장점

 가. 스프린트마다 생산되는 실행 가능한 제품을 통해 사용자와 의견을 나눌 수 있음 

 나. 회의를 통해 팀원들간 신속한 협조와 조율이 가능

 다. 자신의 일정을 직접 발표함으로써 업무 집중 환경 조성 

 라. 프로젝트 진행 현황을 통해 신속하게 목표와 결과 추정이 가능하며 변화 시도가 용이함

 

3. 스크럼 단점

 가. 스크럼은 프로젝트 관리에 무게중심을 두기 때문에 프로세스 품질 평가에는 미약함 

 

---