Agile Devops & Culture

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

애자일의 4대 가치와 12대 원칙을 통해 애자일의 주요 원리를 이해해보자.
출처 : http://agilemanifesto.org/iso/ko/principles.html

* 애자일 12대 원칙

1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. (Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.)

프로젝트 중 일부 기능만 먼저 오픈을 희망하는 등 고객 입장에서는 좋은 아이디어를 최대한 빨리 출시하여 경쟁력을 갖추고 싶어할 것이다. 하지만 기존 폭포수 방식의 경우 고객의 요구사항을 한꺼번에 모아서 개발하여 후반부에 가서야 고객이 결과물을 확인할 수 있어 고객의 만족을 높이기 힘들 것이다.

그렇기 때문에 점진적이고 반복적인 개발을 통해 고객에게 지속적으로 가치 있는 소프트웨어를 전달함으로써 고객의 만족을 훨씬 더 높이는 것이다.

2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다. (Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.)

전통적 프로젝트의 경우 초기 분석 단계에서 최대한 요구사항을 모두 도출한 뒤 개발을 진행하고 이후 요구사항 변경은 최소화하려고 노력한다. 초기에 아무리 상세하게 요구사항들을 도출했다 할지라도 개발이 시작되기 전이기 때문에 프로젝트 중반이나 후반까지도 고객의 요구사항이 계속 변경될 수 있는 것이다. 솔직히 개발팀 입장에서는 요구사항 변경이 달갑지 않은 건 사실이나 개발팀이 일정이나 기타 여러 이유로 요구사항 변경 요청을 거부한다면 고객 입장에서는 원하는 결과물을 얻지 못해 사용자에게 환영받지 못하거나 경쟁력을 잃을 수 있을 것이다.

그렇기 때문에 개발팀은 변경을 유연하게 수용할 수 있는 프로세스를 가지고 일을 함으로써 고객의 경쟁력에 도움을 주는 것이다.

3. 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라. (Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.)

스토리보드, UI 정의서 등 다양한 문서 작성을 통해 고객과 소통하려고 하지만 사실 고객에게 직접 결과물을 보여주는 것만큼 확실한 방법은 없을 것이다. 실제 동작하는 결과물을 보여 주고 직접 체험하게 해봄으로써 기능에 대한 고객의 피드백을 받을 수 있기 때문이다.

애자일에서는 제품 개발을 작은 구성 요소로 나누고 이런 구성 요소들을 자주 전달하는 것을 선호한다. 기능 단위로 짧은 기간을 주기로 개발부터 테스트, 배포까지 진행함으로써 고객에게 동작하는 결과물을 전달하고 피드백 과정을 거쳐 제품의 가치를 높일 수 있는 것이다. (이 부분은 향후 ‘스프린트’ 를 소개하면서 다시 다룰 예정이다.)

4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다. (Business people and developers must work together daily throughout the project.)

커뮤니케이션은 프로젝트 성공을 위한 구성 요소 중의 하나이다. 프로젝트 진행에 있어서 고객과 개발팀이 자주 소통하고 함께 일해야 고객이 원하는 시스템을 만들 수 있다는 의미다.

5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라. (Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.)

사실 개인의 의지와는 상관없이 리더의 판단에 의해 프로젝트에 참여하게 되는 경우도 많을 것이며, 이 경우 자신의 의사와는 상관없이 참여가 결정되었기 때문에 동기부여가 쉽지 않을 수 있을 것이다.

그렇기 때문에 프로젝트 시 상위 관리자의 일방적인 결정이 아닌 개인의 의사를 최대한 존중하여 동기 부여된 사람들로 구성함으로써 성과를 높이는데 도움을 주어야 하며, 고객도 업무에 세부적으로 간섭하지 않는 등 개발팀이 자신들의 방식으로 일할 수 있도록 자율성을 줘야한다. 개발팀은 고객에게 성과로 판단될 뿐 결과물을 만들기위해 ‘어떻게’ 할지에 대한 방식을 설명할 의무는 없는 것이다. 즉, 애자일에서는 신뢰와 자율성을 통해 개인과 팀에 힘을 실어주어야 한다.

6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다. (The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.)

위에서 고객과 개발팀 간의 커뮤니케이션이 중요하다고 언급했지만 개발팀 내부적인 커뮤니케이션 또한 중요하다. 전통적인 개발 방식은 대부분 문서를 통해 정보를 전달하고 공유하는데 문서에는 의도한 내용을 모두 담기 힘들다.

개발자들이 고객이 의도한 바를 올바르게 이해하는 것도 매우 중요한 요소이다. 프로젝트 구성원 간의 의사소통을 문서에 의존하기보다 면대면(face to face) 대화를 통해 정보를 효과적으로 전달하고 오해를 줄임으로써 시간을 절약할 수 있을 것이다.

7. 작동하는 소프트웨어가 진척의 주된 척도이다. (Working software is the primary measure of progress.)

프로젝트 개발을 진행하면서 다양한 산출물을 만들어내지만 이는 고객에게 직접적인 가치를 주지 않으며, 고객에게 진정으로 가치는 주는 것은 작동하는 시스템이다.

고객 입장에서는 ‘OOO 기능 설계, 연동규격서 등 작성 완료 및 70% 코딩 완료’ 와 같은 내용이 아닌 ‘OOO 기능의 작동 여부와 시스템 완성도’ 가 실질적인 진행 척도가 될 수 있을 것이다.

8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다. (Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.)

지속 가능한 개발은 말 그대로 오랜 기간동안 지속적으로 개발하는 것을 의미한다. 마라톤 선수에게 단거리 선수처럼 계속 빨리 달리라고 하면 지쳐 완주하기 힘든 거처럼 상습적인 야근이나 과도한 업무로 인해 열정이나 흥미, 집중력을 잃게 되면 프로젝트가 잘 진행되지 않을 것이다.

그렇기 때문에 고객과 프로젝트 관리자는 개발자들이 업무에 지속적으로 집중할 수 있도록 일과 인생의 균형을 유지할 수 있는 환경을 만들어 주어야 한다. 상습적인 야근은 지속 가능한 개발을 방해하여 성과를 오히려 떨어뜨릴 것이다.

9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다. (Continuous attention to technical excellence
and good design enhances agility.)

좋은 설계나 탁월한 기술은 비즈니스 변화에 따른 요구사항 변경에 빠르게 대응하는데 도움을 줄 수 있다.

가령 올바른 프레임 워크와 지원 도구를 사용하여 이전보다 훨씬 빠르게 고객에게 결과물을 제공할 수도 있으며, 반복적인 업무의 자동화를 통해 시간과 비용도 절감시킬 수 있을 것이다.

10. 단순성이 — 안 하는 일의 양을 최대화하는 기술이 — 필수적이다. (Simplicity–the art of maximizing the amount of work not done–is essential.)

솔직히 이 말이 의미하는 바가 잘 이해 되지 않아 여기저기 검색을 해봐도 서로 이해하고 해석하는 게 달라 뭐라고 딱 정의를 못할 거 같지만 이 원칙에서 하고싶은 말은 가능한 불필요한 노력을 줄이고 일을 단순화시키라는 거 같다.

실제로 필요한 일인지 다시 생각해보고 작은 단위로 일을 단순화 시킴으로써 덜 복잡하게 개발하고 테스트가 가능하며, 혹시 문제가 생기더라도 원복이 용이할 것이다.

11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다. (The best architectures, requirements, and designs
emerge from self-organizing teams.)

자기 조직적인 팀은 관리자가 개발자에게 작업을 할당하거나 지시하지 않아도 구성원들이 자기 주도적으로 업무를 수행하고 유기적으로 협력하는 팀을 의미한다.

구성원이 자유롭게 소통하고 협력할 때 창의성이 나타나는 팀이 될 것이다.

12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다. (At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.)

프로젝트가 종료되고 난 이후에 진행하는 Lesson & Learned 은 향후 유사한 프로젝트 수행할 때는 많은 도움이 될 수 있지만 정작 지금 진행하고 있는 프로젝트에는 도움이 되지 못한다.

그렇기 때문에 프로젝트 종료 시점이 아닌 프로젝트를 진행하면서 주기적인 Lesson & Learned 을 통해 효과적인 수행방법을 찾아 지속적으로 개선해나가야한다.

마무리

애자일의 4대 가치와 12대 원칙을 통해 애자일 개발 선언문이 담고있는 내용에 대해서 알아보았다. 솔직히 필자가 관리자가 아닌 개발자여서 그런지 이 글을 쓰면서도 일부 이해가 안 가는 부분도 있었다. 이런 부분들은 애자일을 기반으로 각 업무 특성에 맞춰 응용하고 적용함으로써 이전보다 업무가 효율적으로 진행될 수 있게 노력해야할 거 같다는 생각이 든다.

이후에는 애자일 관련 기법들에 대한 내용을 하나씩 나눠서 다뤄보려고 한다.

참고

댓글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중

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