애자일에 대해 알아보자 Agile

애자일에 대해 알아보자 Agile

---

2022.11.29 - [슬기로운 자바 개발자 생활/etc] - 엿 같은 소프트웨어 공학- 소프트웨어 프로세스 모델의 이해

엿 같은 소프트웨어 공학- 소프트웨어 프로세스 모델의 이해

지난 포스팅과도 연관이 된다.
개발자가 되어 SI 프로젝트든 솔루션 업체에서 일을 하든 나름 그곳에는 개발 프로세스가 존재하게 된다.

"애자일" 이란 단어를 심심찮게 들어본다. 그리고 개발자라면 소프트웨어 공학의 폭포수 모델 정도는 알아야 한다.
이유는 거의 80% 이상의 프로젝트들이 그렇게 일하고 있으니까... 물론 개발방법론과 개발을 잘하는 것과는 약간 거리가 있지만... 어쨌든 모르는 것보다는 도움이 될 거다.

소프트웨어 공학에서 사용하는 전통적인 폭포수 모델은 전 포스팅에서 봤으니 이제 애자일에 대해 알아보자

---

애자일

아래를 읽으면 된다.

애자일 소프트웨어 개발

애자일 소프트웨어 개발 - 위키백과, 우리 모두의 백과사전

로버트 C. 마틴

Robert C. Martin - Wikipedia

로버트 C. 마틴 (엉클 밥) 이라는 별명을 가진 개발자이자 소프트웨어 공학자와 그의 친구들이 이름 붙인 아이디어다.
그들은 "경량 프로세스 회담"이라는 회의를 통해 아래와 같은 선언문 비슷한 것을 만들어 냈다.

애자일은 아이디어다. 이 아이디어를 알리기 위해 "애자일"이라는 이름을 붙였다.

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

잘 와닿지 않는다. 직역하면 원래 그렇다.

의외로 쉽다. 개념만 알면 된다. 이거 안다고 개발 잘하는 거 아니다.
이런 아이디어를 이용해 프로젝트를 잘하고 개발을 잘하면 그것이 목적을 이루는 완성일뿐이다.
열심히 공부할 필요도 없다. 신문기사 읽듯이 알아보자.

저들이 애자일을 만들어낸 이유는 이렇다. 이것은 애자일 개요라고 말해도 될듯하다.
어떻게 SW 프로젝트를 관리할까? 폭포수 모델 기반에서는 실패가 많다.

애자일을 만들어 낸 이들도 한국의 SI개발 프로젝트의 개발자와 별반 차이가 없던 경험을 한 것이다.
매일같이 야근을 하지만 언제나 일정을 맞추지 못하는 개발팀.
만들어낸 제품의 품질이 낮아 고객과는 불화가 계속 이어진다. 지금도 일어나고 있다.

애자일은 방법론이고 뜻 그대로 "유연하게 일하는 방식" 정도로 이해하면 된다.

<마틴 파울러, 켄트 백> 유명한 사람들 이름이 보인다.

스노버드에 모인 사람들과 애자일 선언문

---

결론 그래서 애자일 하게 일하는 게 모냐?

아주 추상적으로 그냥 폭포수 모델을 여러 번 반복하는 개발 프로세스라고 이해하시라.
스크럼이나 XP, TDD 애자일과 따라다니는 용어들이 있지만 이번 포스팅에서는 뺀다.

소프트웨어의 모든 것은 변한다. 요구사항도 변하고, 설계도 변한다. 심지어 스타트업의 경우 비즈니스도 수시로 변한다. 거기다가 팀원도 바뀐다. 변화는 문제가 아니다. 극복할 문제인 거다.

전통적인 폭포수 모델을 예로 들어보자. 프로젝트가 망하는 원인은 간단하다.
꼭 마지막 단계 쯤 가서 특수한 요구사항이나 기능 추가가가 일어난다.
거기서부터가 망하는 시발점이 된다.
개발자들은 요구사항 변경이 일어나면 돌아버린다. 거의 만들었는데 이제 와서 바꿔달라고? 미친 거 아냐?

이럴 경우 폭포수 모델에서는 대응이 안된다. 있을 수 없는 일이 벌어지는 게 세상 아닌가?

자주 이런 일이 일어나니 야근이 늘어나고 일정을 못맞추고 프로젝트는 실패가 된다.

언제까지 누구의 잘못도 아닌 변화라는 괴물에게 당하고만 있어야 하는가? 새로운 아이디어가 필요하다.
프로세스 모델에 변화가 필요하다. 어쩌면 변화는 당연한거 아닐까?

변화는 당연하다. 문제가 아니다. 우리가 극복해야 될 사안이다.

조금씩 개발하면서 피드백을 받으며 점진적으로 소프트웨어를 개발해나가는 방식이라고 생각하면 된다.

---

그래서 애자일로 하면 프로젝트가 성공하는가?

세상살이 정답이 어디 있겠는가?
왜 많은 프로젝트들이 애자일을 도입하지 않겠는가? 다 이유가 나름 있다.
요것이 시간이 많이 걸린다.
때로는 폭포수 모델이 좋을 때도 분명 있다. 요구사항 변경이 크지 않다면...
예) 명확한 요구사항, 경험 많고 업무 잘 아는 고객. 이미 문제없는 업무 프로세스 등.

요즘 SI 프로젝트들을 보면 기간이 1년 이상인 것은 보기 힘들다. 3개월, 6개월, 2개월도 있다.
애자일을 하기 위해서는 협력이 중요한데 피드백을 줄 고객의 협력이 그리 적극적이지 않다.
아주 소소한 예시를 들자면 고객은 "요구사항 내고 너네가 알아서 다해" 이딴 식이다.
그리고 테스트해달라고 하면 제대로 해주지도 않는다. 결국 피드백 따위는 없다. 협력이 중요한데...

국내 많은 대기업은 SI업체에 의뢰해 IT 개발 프로젝트를 90% 이상 진행한다.
정해진 개발 기간이 있다는 뜻이다. 프로젝트에 관련된 사람들이 긴밀하게 변화에 대응하는 노력이 필요한데, SI업체도 나름의 개발 프로세스가 있을 것이고, 충돌이 일어나지 않겠는가? 개발이 끝나면 또 SM으로 하도급을 줄테고...

애자일도 하나의 옷이지 않을까 싶다. 옷도 사람에 따라 어울리는 사람이 있고 아닌 경우도 있잖은가?

http://www.yes24.com/Product/Goods/95728889

클린 애자일 - YES24