Agile Devops & Culture

[Agile] 애자일 ‘4대 가치’와 ’12대 원칙’

애자일의 4대 가치와 12대 원칙을 통해 애자일의 주요 원리를 이해해보자.

“필자가 쓰는 글들은 책이나 교육, 기타 여러 매체를 통해서 접하고 공부한 내용들을 정리하여 누군가에게 정보를 전달하기 위한 목적도 있지만, 필자가 애자일(agile)을 공부하면서 느꼈던 점이나 이렇게 적용했었으면 어땠을까하는 점 혹은 프로젝트는 아니지만 SM업무에 이런식으로 적용해보고 있다와 같은 ‘주관적인 생각’도 많이 들어있는 글임을 밝힙니다.”

  • DSDM(Dynamic Systems Development Methods)
  • 스크럼(Scrum)
  • 크리스털 방법론(Crystal Clear)
  • XP(Extreme Programming)
  • 린(Lean SW Development), 칸반(SW Kanban) 등..

기존 전통적인 방법론의 한계를 극복하기 위해 1990년대 중반부터 위와 같은 여러개의 경량 방법론들이 발표되어 관심을 받다가 2001년 어느날 17명의 전문가들이 한 곳에 모여 공통적인 개발 철학을 정리하게 되는데 그것이 바로 ‘애자일 소프트웨어 개발 선언문(Manifesto for Agile Software Development)’ 이다.

팀 또는 프로젝트 마다 각기 다른 형태의 프로세스를 수행할 수 있고 상황에 따라 얼마든지 변경할 수 있는데 ‘애자일 소프트웨어 개발 선언문’ 이 수행과 변경에 있어 그 기준이 되는 것이다.

출처 : https://agilemanifesto.org/iso/ko/manifesto.html

애자일을 어딘가에 적용해보기 위해 또는 애자일을 적용해볼만한 곳이 있는지 찾아보기 위해 인터넷에서 애자일에 대해서 조금이라도 검색을 해본 분들 이라면 위 이미지와 앞으로 설명할 내용에 대해서 한번쯤은 접해보셨을 거라고 생각한다. 하지만 그 중에는 애자일 소프트웨어 개발 프로세스를 제대로 이해하지 못하여 나는 애자일 개발을 하고있다고 생각하지만 실제로는 애자일이 아니거나 그 효과가 떨어지고 계신 분들도 있을 거라고 생각한다. 그래서 애자일의 의미에 대해서 조금이라도 이해를 돕고자 애자일 ‘4대 가치’와 ’12대 원칙’에 대해서 써보려고 한다.

* 애자일 4대 가치

1. 공정과 도구보다 “개인과 상호작용”을 (Individuals and interactions over processes and tools)

“요즘에 새로 나온 무슨 툴이 있는데 그걸 사용하면 설계가 이쁘게 잘 된대요!” “스프링부트를 사용하면 xml 설정도 편하고 스프링 기반으로 쉽게 개발할 수 있대요!” “다른 프로젝트에서 이런 프로세스를 도입했더니 결과가 좋았다는데요!” “그럼 우리도 이번에 그런 것들을 적용해볼까요??”

물론 프로젝트나 업무 진행에 있어서 도움이 되는 좋은 도구와 프로세스가 있으면 좋을 것이다. 하지만 아무리 좋은 도구와 프로세스가 있어도 고객과 프로젝트팀이나 팀내 구성원들 간 또는 개발팀과 운영팀과 같이 이해관계자 간의 상호작용이나 소통이 원만하지 않다면 프로젝트가 성공하기 어렵다고 생각한다.

즉, 훌륭한 제품은 도구나 프로세스에서 나오는 것이 아닌 사람에게서 나온다는 것이다.

2. 포괄적인 문서보다 “작동하는 소프트웨어”를 (Working software over comprehensive documentation)

“OOO 대리님 보고자료 작성 때문에 오늘 몇시까지 ㅁㅁㅁ 좀 만들어주세요.” “ㅁㅁㅁ요?? 그거 꼭 필요한건가요?? 지금 일정 내 개발하기도 촉박한대…”

프로젝트를 진행하면서 중간 산출물은 어느 정도 필요한 건 사실이다. 가령 Front-End 와 Back-End 를 개발하는 팀이 서로 다른 경우 API 연동규격서 문서가 없으면 협업을 효율적으로 하기 힘들고 나중에 큰 문제가 발생할 수도 있다. 보고 자료 또한 진행상황이나 이슈 보고를 위해 필요한 건 사실이다. 하지만 프로젝트 일정과 상황에 따라 적절하게 조율되지 않는다면 목적 없는 문서를 양산하기 쉽고, 부수적인 업무에 시간을 허비할 수도 있다.

즉, 프로젝트 산출물과 같은 문서들이 프로젝트를 진행하는데 필요한 건 사실이지만 그 자체가 목적이 되어서는 안되며 최종 시스템을 더 잘 만드는 것에 더 큰 가치를 둬야 한다.

3. 계약 협상보다 “고객과의 협력”을 (Customer collaboration over contract negotiation)

개발팀 입장에서는 개발 진행 중에 특히나 프로젝트 막판에 요구사항이 변경되는 것을 반기지 않을 것이다. 처음부터 명확하지 않았던 요구사항으로 인해 변경되는 부분도 있겠지만 프로젝트 후반부에 어느정도 완성된 결과물을 직접 보면서 요구사항 변경이 발생하게 된다. 이 경우 변경 범위와 영향도에 따라 일정 변경이 불가피하나 프로젝트 일정과 비용을 늘리는 것은 쉽지 않기 때문에 고객과 개발팀 간의 갈등이 발생할 수 밖에 없다.

그렇기 때문에 프로젝트 후반부에 고객과 개발팀이 요구사항 수용을 위해 일정과 비용을 두고 협상을 하는게 아니라 처음부터 꾸준한 협력을 통해 요구사항을 명확히 하고 일정 내 개발 범위에 대한 절충을 통해 완료 조건을 명확하게 해야한다.

4. 계획을 따르기보다 “변화에 대응하기”를 (Responding to change over following a plan)

정해진 비용과 일정 내에 프로젝트 초기 계획했던 대로 척척 진행된다면 아주 이상적 이겠지만 프로젝트 초기 상세하게 도출하기 힘든 요구사항들과 그로 인해 발생하는 생각지 못했던 이슈들, 그리고 프로젝트 중간 심지어 막판에 이르기까지 계속 변경되는 요구사항들로 인해 계획을 따르는 건 쉽지 않을 것이다.

그렇기 때문에 무작정 계획을 따르기 보다는 변화에 적절히 대응하면서 제약 조건을 조정해 나가야 프로젝트의 실질적인 가치를 높일 수 있을 것이다.

여기까지 ‘애자일 4대 가치’에 대해서 살펴보았다. 아직 의미가 잘 이해되지 않거나 이게 과연 효과가 있을까하는 의구심이 드는 등 저마다 다양한 반응을 가지셨을 거라고 생각한다. 아마 이 부분은 자신의 상황에 맞게 응용해보고 경험이 쌓일수록 이해가 깊어질 거라고 생각하기에 이어서 ‘애자일 12대 원칙’을 통해 실무 적용에 도움이 될 수 있는 좀 더 구체적인 지침에 대해서 알아보자.

댓글 남기기

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.

%d 블로거가 이것을 좋아합니다: