[IT] 애자일 행동원칙 12가지

우리나라는 잘 알지도 못하면서 유명하다 싶으면 무조건 적용하려는 경향이 강합니다. 애자일 또한 마찬가지입니다. 애자일에 대해서 잘 알지도 못하면서 무조건 애자일을 적용하라고 지시가 내려옵니다. 지시가 내려오면 팀장들은 애자일이 무엇인지도 잘 모르면서 일단 데일리미팅, 칸반보드 등을 적용합니다. 불편하고 어색해도 지시가 내려와서 어쩔 수 없다면서 일단 시행합니다. 팀원들은 불평을 놓게 되고 결국 애자일은 흐지부지 사라지게 됩니다.

 

그래서 사람들에게 애자일이 무엇이냐고 물어보면 애자일 선언문과 원칙을 이야기하는 것이 아니라 데일리미팅, 칸반보드 같은 방법도구들을 이야기합니다.

 

우리는 최소한 애자일 선언문과 행동원칙에 대해서는 조금이라도 이해해야 합니다.

애자일 선언문에 대해서 못 보신 분들은 아래 링크를 통해서 한번 읽어보시기 바랍니다.

  

[IT] 애자일 선언문

 

 

애자일 행동원칙 12가지

1. 우리의 최고 우선순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달함으로써 고객을 만족시키는 것이다.

스프린트 단위로 작업을 진행하고 완료될 때마다 고객에게 공유해야 합니다.

하지만 실제 프로젝트를 진행하면 개발자들은 개발할 생각만 하기 때문에 통합테스트할 시점이 되어서야 고객에게 전달되기 일쑤입니다.

 

2. 비록 개발 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

요구사항도 주기적으로 점검하지 않으면 자칫 실제 고객의 생각과는 동떨어진 엉뚱한 제품이 만들어진다는 것을 반드시 기억해야 합니다. 

대부분은 프로젝트 개발자들은 요구사항을 고객의 문제로만 취급하며, 일거리가 늘어난 것으로 생각합니다. 그래서 요구사항이 변경되면 고객 탓만 하면서 안된다는 소리만 하거나 잔뜩 불만을 가지고 개발을 합니다.

 

3. 작동하는 소프트웨어를 자주 전달하라. 약 2주에서 2개월 정도의 간격으로 전달하되 간격은 짧을수록 좋다.

고객에게 직접 보여주는 것만큼 확실한 방법은 없습니다. 개발자는 피드백으로 기능을 완성하고 고객은 피드백 과정을 거치면서 제품에 신뢰를 갖게 됩니다.

중간중간 데모를 시연해 주는 것도 좋은 방법입니다. 결국은 소프트웨어의 개발의 기본은 작동하는 소프트웨어입니다. 아무리 멋지고 뛰어난 엔진은 탑재한 스포츠카라고 해도 시동이 안 걸리고 주행이 안되면 무슨 소용일까요?

개발자들은 기능이 동작하면 이상이 없다고 생각하지만 절대 그렇지 않습니다. 정상적으로 작동이 되어야 합니다. 절대 잊어서는 안 됩니다.

 

4. 비즈니스 영역 사람들과 개발자들은 프로젝트 전체에 걸쳐 매일 함께 일해야 한다.

개발자들의 가장 취약한 부분이 바로 커뮤니케이션일 것입니다. 비즈니스 영역 사람들과는 아예 커뮤니케이션을 할 생각을 안 합니다. 커뮤니케이션은 오로지 PM만 하면 된다고 생각하는데요. 절대 그렇지 않습니다. 개발자들이 정확한 요구사항을 이해하고 구현하기 위해서는 비즈니스 영역 사람들과 가까워야 합니다.

 

 

 

5. 동기가 부여된 개인들로 프로젝트를 구성하라. 그들에게 그들이 필요로 하는 환경과 지원을 제공하라. 그리고 그들이 일을 끝낼 수 있으리라 신뢰하라.

그들이 필요로 하는 환경을 반드시 지원해야 합니다. 사무실, 컴퓨터 등의 환경적 요인도 포함된 이야기이지만, 프로젝트의 목적과 그에 따른 역할이 무엇인지를 이야기하는 것도 매우 중요합니다. 

많은 개발자들이 지금 만들고 있는 소프트웨어가 어디에 어떻게 쓰이는지도 모르는 채로 코딩만 하는 경우가 많습니다. 그것은 개발자가 아니라 코더입니다. 

 

6. 어떤 다른 개발팀을 상대로, 혹은 개발팀 내에서, 서로 간의 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 보고 하는 대화이다.

코로나를 겪으면서 재택근무가 일상화되었습니다. 회사에서 사무실 출근을 추진하려 하니 상당한 반감이 생기고 있습니다. 하지만 서로 간의 정보를 전달하는 가장 효율적이고 효과적인 방법은 바로 얼굴을 보고 대화입니다. 전화와 화상회의만으로는 한계가 있습니다. 

악기를 다루는 밴드들이 개인연주는 개별적으로 연습하고 주기적으로 함께 모여서 합주를 같이 하는 것처럼 소프트웨어 프로젝트 또한 개인적으로 개발을 하고 주기적으로 모여서 개발현황 공유, 요구사항  확인, 테스트 등등을 할 수 있다면 상당히 좋을 것 같습니다.

 

7. 작동하는 소프트웨어가 진척 측정의 주된 척도이다.

대기업이나 공공기관의 경우 진척현황을 확인하기 위해서 문서를 요구하는 경우가 많습니다. 이미 꼭 작성해야 하는 문서양식이 존재하고 반드시 작성해 달라고 합니다. 얼핏 보면 체계가 작성된 것 같지만 절대 그렇지 않습니다. 작성된 문서를 보면 억지로 채운 흔적들이 낭자합니다. 불필요한 문서는 작성하지 않아야 합니다.

그렇다고 문서가 필요 없다는 것은 아닙니다. 작동하는 소프트웨어에 맞게 일치하는 문서가 있어야 합니다. 프로그램 분석서라고 작성되어 있는데, 그 프로그램을 추적하기 어렵거나 단순이 입력합니다. 삭제합니다. 같이 뻔한 이야기만 작성하는 경우가 즐비합니다.

 

8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자들은 일정한 속도를 계속 유지할 수 있어야 한다.

개발자들이 과도한 업무에 시달리다보면 아무리 좋아하는 일이라도 열정이나 흥미를 잃기 쉬우며 집중력 또한 멀어지게 됩니다. 또한 일과 생활을 균형있게 유지할 수 있도록 워라밸을 지킬 수 있는 환경을 만들어줘야 합니다.

현실적으로 참 어려운 일인 것을 사실입니다. 프로젝트를 하면서 야근이 없는 것을 본 적이 없습니다.

절대 개발팀과 고객 모두 야근이 당연하다고 생각하면 안됩니다. 

 

9. 기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민함을 향상시킨다.

개발자가 최신 기술에 관심을 갖고 실험할 수 있도록 시간적 여유를 제공해야 합니다. 

사실 개발자들은 프로젝트 중에 왜 이렇게 동작하지? 신기한데? 혹은 궁금한데? 하는 부분들이 있습니다. 하지만 분석할 시간이 절대 없습니다. 그래서 프로젝트 완료 후에 리뷰할 수 있는 시간을 가지는 것을 꼭 추천합니다. 중간중간 분석하고 싶은 부분을 기록만 하고 프로젝트 후에 같이 스터디하면서 리뷰를 할 수 있다면 좋을 것 같습니다.

 

10. 간결함(하지 않아도 되는 일의 양을 최대화 하는 기술)은 필수적이다.

전통적 개발 방식은 초기에 업무를 완벽하게 분석 설계하도록 되어 있습니다. 하지만 이러한 방식은 요구사항의 불명확성을 고려하지 않은 방식으로 개발자들은 분석 설계가 완료될 때까지 대기하면서 시간을 버리게 되며, 개발이 시작되면 변경되는 요구사항에 의해서 초기에 소요되었던 분석 설계가 무의미해지기도 합니다.

해당 요구사항이 분명하고 명확할 때 개발에 착수 하되, 과도한 분석 설계를 하지 않도록 주의해야 합니다.

 

11. 최상의 아키텍처, 요구사항, 설계는 자기 조직화 (self-organizing) 되어 있는 팀에서 나온다.

자기 조직화 되어 있는 팀이란 누군가의 지시가 없어도 자기 주도적으로 업무를 수행하고 유기적으로 협력하는 팀을 말합니다. 

아무리 뛰어난 PM이라고 해도 모든 디테일한 부분까지 알 수는 없습니다. 결국 디테일한 부분까지 분석하고 개발하는 것은 각각의 개발자들입니다.

수동적으로 시키는 업무만 하는 개발자가 있다면 능력 및 지위고하를 막론하고 반드시 조치가 필요합니다.

 

12. 정기적으로, 팀 차원에서 어떻게 하면 더 효과적일 수 있을지에 대해 되돌아보며 자신들의 행동을 이에 따르도록 조율하고 조정한다

위에서도 살짝 프로젝트 후에 스터디하는 것에 대해서 언급했었는데요. 프로젝트 끝나고 또는 중간중간에 주기적으로 잘한 점이나 못한 점 등을 토론하고 점검하는 과정이 매우 중요합니다. 이러한 과정을 통해서 교훈을 얻을 수 있다면 향후 개인적으로도 프로젝트나 팀 차원에서도 상당한 도움이 될 것입니다.

프로젝트 중에는 업무에 치이는 경우가 많기  때문에 개인적으로는 프로젝트 끝나고 개발 스터디와 함께 잘한 점이나 부족한 점 등을 이야기하는 것을 추천합니다. 개발회사에서는 프로젝트 끝나면 바로 다른 프로젝트에 투입하는 것만을 고려하지만 장기적인 관점에서는 이러한 활동이 상당히 중요하다는 것일 인식하고 있어야 합니다.