애자일 방법론 - 가치, 원칙, 의견

요즘의 거의 모든 회사가 따르고 있다는 애자일 방법론에 대해 알아봅니다. 

애자일 방법론은 유연성과 협력을 중시하는 방법론입니다. 

 

초기부터 정확한 계획을 세우는 대신, 변화를 수용하고 고객의 피드백을 적극 수용하는 것을 중요시하는 개발 방법론입니다. 

작은 단위의 반복적인 개발 주기를 통해 소프트웨어를 점진적으로 개발하고 변경에 유연하게 대처합니다. 

 

애자일 방법론을 말할 때 "4가지 가치"와 "12원칙"은 빠지지 않고 이야기됩니다.

조금 더 자세히 알아보겠습니다. 

 

[목차]

• 4가지 가치
• 12가지 개발 원칙
• 의견

4가지 가치

애자일 선언문에서 제시된 핵심 가치입니다. 

1. 개인과 상호작용을 과정과 도구보다 우선시합니다. 
   • 개인들의 상호작용과 소통이 더 중요하며, 프로젝트에 있어서 도구나 프로세스보다 사람 간의 상호작용이 우선시됩니다. 
2. 작동하는 소프트웨어를 완성하는 것을 문서보다 우선시합니다. 
   • 완벽한 문서보다는 실제로 작동하는 소프트웨어를 더 중요시합니다. 
   • 프로젝트의 목표는 실제 작동하는 소프트웨어를 개발하는 데에 있습니다. 
3. 고객의 협력을 계약 협상보다 우선시합니다. 
   • 고객과 지속적인 협력과 의사소통이 더 중요하며, 프로젝트의 성공을 위해 고객과의 상호작용을 우선시합니다. 
4. 계획을 따르기보다는 변화에 대응하는 것을 우선시합니다. 
   • 예상치 못한 변화에 유연하게 대응하고, 신속히 조정할 수 있는 능력이 중요합니다. 
   • 빠르게 변화하는 환경에 적용할 수 있는 유연성이 필요합니다. 

12가지 개발 원칙

애자일 소프트웨어 개발의 12가지 원칙은 소프트웨어 개발에서 애자일 방법론을 적용할 때 준수해야 할 원칙들을 설명합니다. 

1. 우리의 최우선 과제는 가치 있는 소프트웨어를 조기에 지속적으로 제공하여 고객을 만족시키는 것입니다.
2. 개발 후반에도 요구 사항 변경을 환영합니다.
   • 민첩한 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.
3. 더 짧은 기간을 선호하여 몇 주에서 몇 달까지 작동하는 소프트웨어를 자주 제공하십시오.
4. 비즈니스 담당자와 개발자는 프로젝트 전반에 걸쳐 매일 함께 작업해야 합니다.
5. 의욕이 넘치는 개인을 중심으로 프로젝트를 구축하세요.
   • 그들에게 필요한 환경과 지원을 제공하고 그들이 일을 완수할 것이라고 믿으십시오.
6. 개발팀 내에서 그리고 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.
7. 작동하는 소프트웨어는 발전의 주요 척도입니다.
8. 민첩한 프로세스는 지속 가능한 개발을 촉진합니다.
   • 스폰서, 개발자, 사용자는 무한정 일정한 속도를 유지할 수 있어야 합니다.
9. 기술적 우수성과 좋은 디자인에 대한 지속적인 관심은 민첩성을 향상합니다.
10. 단순성, 즉 완료되지 않은 작업의 양을 최대화하는 기술이 필수적입니다.
11. 최고의 아키텍처, 요구 사항 및 디자인은 자체 구성 팀에서 나옵니다.
12. 정기적으로 팀은 어떻게 하면 더 효과적으로 일할 수 있을지 생각해 본 다음 그에 따라 행동을 조정하고 조정합니다.

의견

애자일 선언문의 내용을 같이 보셨습니다. 

선언문의 내용만 보면 무언가 매우 긍정적이고 의욕 넘치는 정신이 보이는 것 같습니다. 

굉장히 빠르게 제대로 된 소프트웨어가 만들어질 것도 같습니다. 

 

아시겠지만, 생각보다 잘 되지 않습니다. 

개인적으로 생각하는 큰 원인은 아래와 같습니다. 

1. 모든 구성원이 대화를 좋아하진 않는다.
2. 모든 구성원이 개발을 빠르게 진행할 수는 없다.
3. 요구 사항에 대한 빈번한 변경을 모두 좋아하진 않는다.
4. 최고의 아키텍처, 설계를 본 적이 없고, 만들 팀도 없다. ( 만들 능력도 없으며, 필요성도 못 느낀다. ) 
5. 빠른 주기에 구성원들이 금방 지친다. 
6. 개발 주기가 반복될수록 쌓이는 버그를 수정하는데 시간이 점점 더 많이 소모되기 시작한다.

하나하나 말하고 싶은 것들이 많지만, 결론부터 말씀드려 보겠습니다. 

어떤 방법론이라도 장단점이 있습니다. 그리고 어떤 방법론이 정답일 수도 없습니다. 

현재의 조직의 개발 문화를 냉정히 평가하고, 더불어 개발 구성원들에 대한 지극히 냉정한 평가가 된 후에

조직에 맞는 방법론을 구성하기 바랍니다. 

 

이전에도 말씀드린 적이 있는데요. 문서를 만들지 말라는 부분은 없습니다. 

필수적인 문서는 꼭 만들어서 협의나 논의하실 때 활용하시기를 당부드립니다. 

대화가 우선시되는 방법론이지만, 너무 말로만 논의하다 보면 서로 다른 곳을 보며 이야기하기 쉽습니다. 

 

애자일 방법론은 하위 방법론들을 활용해서 진행됩니다. 익스트림, 칸반, 스크럼 등이 있습니다. 

하위 방법론은 별도 정리해 보겠습니다. 

 

참고) 어느 책에서 이런 문구를 본 적이 있습니다. "최고의 사람들로만 구성해야 한다."