애자일 4대 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만,우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
애자일 소프트웨어 개발 선언문은 2001년 소프트웨어 엔지니어 업계의 리더들이 모여 공표한 내용입니다. 내용을 하나씩 뜯어봅시다.
공정과 도구보다 개인과의 상호작용을
말인 즉슨, 어떤 도구를 쓰는지, 어떤 공정과정을 갖는지 보다도 개인과의 상호작용이 중요하다는 뜻입니다. 개발자와 고객, 개발자와 개발자간의 대화와 협력을 통해 상황과 소프트웨어에 맞는 공정과 도구를 사용하는 것이 더 우선에 있음을 뜻합니다.
포괄적인 문서보다 작동하는 소프트웨어를
문서로만 보이는 소프트웨어가 아니라, 실제로 동작하는 소프트웨어를 만들고 보여야한다는 뜻입니다. 이는 문서로 보여지는 소프트웨어를 고객과 개발자가 서로 다르게 이해하고 있을 수 있기 때문입니다. 따라서 적은 기능이 달려있을지라도, 진짜 움직이는 소프트웨어를 보여 고객과 개발자의 이해를 일치하는게 더 중점에 있다고 해석할 수 있겠습니다.
실제로 XP(익스트림 프로그래밍) 실천 방법 중 하나가 매일 배치 인데, 개발되고 있는 코드와 실제 동작하는 소프트웨어 사이의 간극을 좁히기 위해 사용하는 방식입니다.
계약 협상보다 고객과의 협력을
개발엔 고객도 참여한다는 뜻입니다. 고객은 계약만 마치면 소프트웨어를 받을때까지 기다리기만 하는 것이 아니라, 개발 과정에 고객이 참여해 주기적으로 피드백을 주어야 개발자도 만족하고 고객도 만족하는 소프트웨어가 나온다는 뜻입니다.
실제로 애자일에선 매 스프린트가 끝날때 결과물을 고객과 함께 보고 평가하는 시간을 갖게 됩니다.
계획을 따르기보다 변화에 대응하기를
“계획은 언제든 바뀔 수 있다” 라고 받아들이면 될 것 같습니다. 1달치 백로그를 미리 쌓아놓고 이 백로그가 끝날때까지 눈도 깜빡 안한다! 해버리면 1달 뒤 모든 백로그가 완료되어도 고객이 원하는 제품과 전혀 다른 제품이 되어 있을 수 있습니다. 애자일에서는 한 스프린트를 짧게 가져가며 이 스프린트를 반복하는 것으로 주기적으로 시장의 반응을 확인하고 피드백을 바로바로 제품에 적용할 수 있습니다.
왼쪽에 있는 것들도 가치가 있지만, 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다
애자일에서 중요시하는 것은 개인과의 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대응 이지만, 그렇다고 공정과 도구, 포괄적인 문서 등이 의미가 없다는 것이 아닙니다. 애자일을 따른다고 문서 작성을 안하지는 않죠. 다만 2순위라는데 의미가 있습니다.
애자일 선언 이면의 12가지 원칙
- 우리의 최우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
- 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
- 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
- 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
- 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라 신뢰하라.
- 개발팀으로 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
- 작동하는 소프트웨어가 진척의 주된 척도이다.
- 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야한다.
- 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
- 단순성이 - 안 하는 일의 양을 최대화하는 기술이 - 필수적이다.
- 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
- 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
애자일 방법론을 따른다면 위의 12가지 원칙을 따른다는 뜻입니다. 마찬가지로 하나씩 뜯어보겠습니다.
우리의 최우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
최대한 매 스프린트마다 완성되는 소프트웨어가 고객에게 가치를 줄 수 있어야한다는 뜻입니다.
예를 들어, 음악을 감상할 수 있는 웹페이지를 만든다고 합시다. 음악 감상 기능은 구현되지도 않았는데, 로그인 기능을 먼저 달아버린다면, 이 웹페이지는 아무 가치도 없는 웹페이지겠죠. 따라서 고객에게 가치가 있는 음악 감상 기능을 먼저 달아야한다는 뜻입니다.
비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
계획을 따르기보다 변화에 대응하기를 에 부합하는 원칙입니다. 개발 막바지에 다다랐을 지언정, 고객의 요구사항을 적극적으로 반영해야 고객이 진정으로 원하는 소프트웨어를 만들 수 있다는 뜻입니다. 예를 들어, 오프라인에서 쉽게 서로의 번호를 교환할 수 있는 앱을 만든다고 칩시다. 그런데 개발 막바지에 코로나가 터져버린 상황입니다. 오프라인에서 유용한 이 앱은 더 이상 가치를 주지 못하겠죠? 그럼 과감하게 코로나에 대응하여 계획을 변경해야 합니다. 개발 막바지라고 만들던걸 붙들고 있다면 결과물은 경쟁력 없는 제품이 될 것입니다.
작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
스프린트를 최대한 짧게 가져가서, 작동하는 소프트웨어와 코드 사이의 간격을 줄이라는 뜻입니다. 그렇게 되어야 고객도 소프트웨어 개발이 어디까지 어떤 방향으로 이루어지는지 빠르게 확인하고 적극적인 피드백을 줄 수 있겠죠?
비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
개발은 개발자만 하는 것이 아니라는 뜻입니다. 다양한 사람들이 참여할수록 다양한 시점에서 제품을 볼 수 있고, 생길 수 있는 문제점에 선제적으로 대응할 수 있습니다. 막상 개발 끝내고 나니까 사업부에서 필요한 예산을 내어줄 수 없다고하면 안되겠죠? 시장은 어떤 상황인지, 사업적인 면에선 어떠한지 지속적으로 의견을 줄 수 있는 비즈니스쪽 사람들의 역할도 중요합니다.
동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라 신뢰하라.
쉽게 말하면 개발자에겐 개발하는 동기가 있어야하고, 위에서 쪼지 말라는 뜻입니다. 잘 정돈되고 효율적인 업무 환경이 마련되고 동료간의 신뢰가 확보되어야 더 좋은 소프트웨어를 만들 수 있습니다.
개발팀으로 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
비대면보다 대면을 선호한다! 라는 건데, 말이나 글로만 정보를 전달하다보면 서로 이해하는게 달라질 수 있어서, 면대면을 선호하는 겁니다. 근데 뭐 요즘엔 코시국이라 어쩔 수 없는 것도 있고, 협업툴이 워낙 잘 만들어져 있어서 비대면에서도 충분히 정보전달이 잘 된다고 보긴합니다. 어쨌든 정보전달만 잘 된다면 아무래도 좋습니다
작동하는 소프트웨어가 진척의 주된 척도이다.
작동하는 소프트웨어 = 마일스톤
마찬가지로 문서로 어디까지 개발이 완료되었다고 전달하는 것보다 직접 작동하는 제품을 보여주는게 개발이 어디까지 이루어졌는지 이해하에 더 좋다는 뜻입니다.
애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야한다.
대충 “무리하지 말자” 라고 이해하면 좋을 것 같습니다. 한 스프린트를 마치기 위해 하루에 14시간씩 일을 하다보면 번아웃이 와서 일을 지속하지 못하겠죠? 따라서 지속가능한 속도(sustainable pace)를 찾아서 그 속도에 맞춰 일을 하라는 뜻입니다.
기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
agile의 뜻이 “민첩한”이죠. “민첩하게 개발하는 건 좋은데, 속도 때문에 더 좋은 기술을 도입하거나 좋은 설계를 가져가는걸 포기하진 말아라” 라고 받아들이면 될 것 같습니다. 좋은 기술의 도입과 좋은 설계가 결국은 개발 속도를 더 빠르게 해줄 것이라고 보는거죠.
단순성이 - 안 하는 일의 양을 최대화하는 기술이 - 필수적이다.
원문은 아래와 같습니다
Simplicity--the art of maximizing the amount of work not done--is essential.
최대한 자동화해서 일하는 과정을 단순하게 만들어야한다는 뜻입니다. 자동화에 시간을 들일 지언정 결국은 시간을 아끼는 일이 될 것입니다.
최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
자기 조직화(self organizing)는 “모든 팀원이 공동의 목표를 이해하고 각자의 일에 최선을 다한다” 라고 이해하면 되겠습니다. 사실 좀 이상적인 이야기긴합니다. 우리 팀에 들어온 누군가는 우리가 뭘 개발하는지엔 관심이 없고 월급이 얼마인지에 더 관심이 있을 수도 있죠. 하지만 모든 팀원이 공동된 목표를 이해하고 그 목표를 위해 적극적으로 대화에 참여하고 다양한 피드백을 줄때에 비로소 최고의 설계와 최고의 요구사항이 나온다는 뜻입니다.
팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
제품에만 집중하지말고, 팀으로서도 더 나아질 방향을 탐색하라는 뜻입니다. 애자일 주기에 “회고” 시간이 들어가는 이유이죠. 좋은 팀이 좋은 제품을 만들 가능성이 높은 것은 자명합니다. 그러니 팀에 제동을 거는 요인들도 함께 고민하고 해결책을 찾아야겠죠.
마치며
필자에게 원래 마음에 잘 안와닿던 애자일 선언문이었지만, 오랜만에 애자일 선언문을 읽다가 문뜩, 이제는 이해 되는 원칙들이 보이더라구요. 그래서 막 생각을 글로 옮겨보았습니다.
