애자일 vs 폭포수

1. 폭포수 개발방식

폭포수 개발방식은 다시 되돌아 갈수 없는 구조

요구사항 분석 > 설계 > 개발 > 테스트 > 배포형태로 단계적 프로젝트가 수행

     폭포수 모델 개발방식은 마치 6개월만에 책을 만들어내는 것과 같은 방식

폭포수 모델의 단점은 완성되기 전까지 문제점을 발견하기 어려움

2. 애자일 개발방식

     

애자일은 방법론이라 얘기한다. 유연하게 일하는 방식.

짧은 주기로 고객의 소프트웨어를 만들어가면서 이슈 사항들을 바로바로 제거하는 개발

방식이 바로 애자일 소프트웨어 개발 방식이다

폭포수 모델방식에 비해 작업의 단위는 훨씬 작아지고, 처음에 생각했던 방향성에서 크게 틀어

질 가능성을 최소화 할수 있다. 수정할 필요가 있으면 바로바로 수정하기 때문에, 비용도 크게 들

지 않고 쉽게 수정 할수 가 있다.

추상적이고 모호한 수준의 end -image를 점점 구체적인 소프트웨어로 만들어가면서 고객도 만

족하고 팀원도 만족

3. 프로젝트 실패의 원인

원인은 바로 고객의 요구사항 변경

소프트웨어 개발에 있어 요구사항은 구체적이지 않고, 모호한 경우가 많음

4. 갖춰야할 능력

소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기술도 

변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에, 문제가 되는 것은 변

화가 아니다. 그보다는 변화를 극복하지 못하는 우리의 무능력이 문제다

5. 스크럼

팀원들과 협업하여 소프트웨어를 개발하는 모습을 말한다.

스크럼은 애자일의 여러가지 실천 도구 중 하나이다.

- PO는 제품에 대한 오너쉽을 가지는 사람이다.

PO는 일정이나 리스크,이슈 등에도 관심이 있어야 하겠지만

가장 중요한 것은 지금 만들어지는 제품이 어떤 순서로 개발이 되어야 하는지

결정을 내리는 가장 중요한 역할을 해야 한다.

- SM은 항상 팀원들의 목소리에 귀를 기울여야 하는사람이다.

- 백로그는 요구사항 리스트, 제품의 개발 대상 목록이다.

- 애자일에서는 요구사항을 user story (사용자 스토리) 라 한다.

- PO는 해당 제품에 대해 관련 있는 여러 사람들을 통해 요구사항 즉 사용자 스토리를 수집한다. 

- 이 여러 사람 안에는 해당 제품을 사용한 End User는 당연히 포함이 되어야 하며, 제품과 연계되어 있는 임원들이나 관련 깊은 부서의 실무 담당자들, 그리고 스크럼 팀을 이루는 팀원들도 포함된다

- 여기서 중요한것은 사용자 스토리는 사용자의 관점에서 작성이 되어야 한다는것이다 소프트웨어 개발자들이 사용하는 용어들이 들어가서는 안된다

- 사용자 스토리를 작성하는 방법에 대해서 기술한 책

 

- 참고할 좋은책들 (인사이트 :  사용자 스토리,o reilly : user story mapping, 애자일회고 인사이트)