애자일 소프트웨어 개발 선언 4가지 가치와 그 이면의 12가지 원칙

 

출처 : YES24.com

애자일에 대해 공부를 하게 되다보면, 애자일 소프트웨어 개발 선언 4가지 가치와 12가지 원칙을 책 첫장에서 많이 접하게 된다. 처음 읽을 때는 이게 도대체 무슨말인가? 알송달송하고 애매모호하며 뿌연 안개 같은 느낌이었다. 지나치게 추상화된 느낌이랄까?

 

요약하자면, 고객이 만족하는 잘 돌아가는 서비스를 제 때 잘 제공하기 위한 가이드라인이라 해야 할 듯 하다.

 

애자일 소프트트웨어 개발 선언 4가지 (4대 가치)이라 함은

공정과 도구보다 개인과 상호 작용을 

포괄적인 문서보다 작동하는 소프트웨어를 

계약 협상보다 고객과 협력을

계획을 따르기보다 변화에 대응하기를 가치있게 여긴다. 

여기서 앞에 나온 것들을 무시한다기 보다 둘 다 가치가 있지만 무게 중심을 뒤쪽에 더 둔다는 것으로 보는 것이 타당할 듯 하다.

 

스노버드에 모인 그룹이 위 네가지 가치는 매우 빨리 생각해냈지만, 애자일 선언문 이면의 12가지 원칙에 동의하기 위해 꽤 오래동안 토론을 벌였다고 한다. 처음 출시 버전은 현재 알려진 것과는 조금 다르며 최종 버전은 http://www.agilemanifesto.org 에서 확인할 수 있다. 

 

 

애자일 선언 이면의 12가지 원칙

1. 우리의 최우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
3. 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라 신뢰하라.
6. 개발팀으로 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
7. 작동하는 소프트웨어가 진척의 주된 척도이다.
8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야한다.
9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
10. 단순성이 - 안 하는 일의 양을 최대화하는 기술이 - 필수적이다.
11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

위 12가지 원칙 중 위 세가지는 소프트웨어를 일찍 그리고 지속적으로 전달하며, 요구사항 변경을 적극적으로 받아들이고, 짧은 주기마다 작동하는 소프트웨어를 제공하는 것이다. 이렇게 하기 위해서 반복(iteration)과 백로그(backlog)와 같은 방법을 사용하여 관리한다.

 

반복 주기: 모든 프로젝트 활동을 반복적으로 수행하여 작동하는 소프트웨어를 지속적으로 제공한다. 반복주기는 정해진 시간(Timedboxed)이 있기에 이 시기에 수행할 수 있은 일을  매 반복 주기에 우선순위를 두어 할당하고 조율하게 된다. 이를 통해 가장 중요한 요청사항에 집중해서 작업할 수 있는 환경을 만들 수 있다.

 

백로그: 변하는 요구사항을 관리하는 아주 좋은 방법으로 반복주기에 포함되어 있지 않지만 개발예정된 피처목록이다.

 

핵심정리를 하자면,

소프트웨어는 사용자, 고객, 또는 이해관계자가 원하는 일을 할 때 가치가 있다.

소프트웨어를 가치 있게 만들려면 팀은 사용자에게 초기 버전을 배포한 후 지속적으로 배포해야 한다.

애자일 팀은 변화하는 요구사항을 환영하고 변경사항을 일찍 알면 재작업을 방지할 수 있다.

일찍 변경 사항을 찾는 최고의 방법은 사용자에게 작동하는 소프트웨어를 자주 배포하는 것이다.

문서는 도움이 되지만 정보를 전달하는 가장 효과적인 방법은 면대면 대화이다.

애자일 팀의 개발자들은 사용자와 이해관계자를 포함한 비즈니스 쪽 사람들과 매일 함께 일한다.

반복은 소프트웨어를 정해진 시간마다 지속적인 산출물로 만들어내는 프랙티스이다.

백로그는 팀이 향후 반복해서 개발할 피처의 목록을 유지하기 위핸 프랙티스이다.

 

 

개발하기도 바쁜데,,, 이런 것을 고려해야 하나?

성가지고 집중할 수 없는 상태가 되는 것 아닌가?

이미 만든 코드를 변경해야 하는 상황은 끔찍하지 않는가?

 

그러나, 고객이 그 소프트웨어가 무언가를 제공하고 있지만 우리가 필요로 하는 것은 아니다. 라 한다면

이런 성가심은 사용자의 장기적인 요구사항을 받아들여 가치 있는 서비스를 제공한다는데 가치를 둘 수 있다 보여진다. 

 

우린 실제로 이런 경우를 많이 만나고 있다.

훌륭한 아키텍처 구성에 수 많은 반짝이는 아이디어로 멋들어지게 소프트웨어를 제공해도

원하는 것이 아닐 수 있다. 이런저런 기능을 넣다보니 사이즈는 커지고, 납기일은 늦어진다. 고객의 요구사항을 명확하게 이해하지 못하여 재작업하게 되는 경우가 많다.

 

패션쇼에 내세울 예술작품을 만드는 것이 아니라면, 소비자들이 많이 찾는 옷을 만들어야 하는 것과 같지 않을까? 그들이 원하는 바를 정확히 알려면 시제품을 만들어 피드백을 받아 수정보완하여 점점 개선되어 나가는 것이 바람직하지 않을까?  하고 생각해보게 된다.

 

출처 : Head First Agile