클린 소프트웨어 - 애자일 실천방법

애자일 실천방법

개발자들은 실용적인 방법 없이 프로젝트를 진행해 왔다. 그 결과 고객은 낮은 품질에 실망하고, 개발자는 반복되는 에러와 비효율적인 작업에 지치게 되었다.

그래서 개발자들은 과거 실패의 경험으로부터 제대로 동작했던 것을 선택하여 어떠한 프로세스를 만들게 된다. 하지만 이 또한 에러를 충분히 방지해 주지 못했다.

이를 해결하기 위해 프로세스가 계속해서 더 커지지만 이는 불필요한 것이다. 까다롭고 많은 프로세스는 오히려 방지하고자 했던 문제를 발생시킬 수 있으며, 일정의 지연과 예산의 급증을 불러온다. 팀의 사기가 저하되는 것 또한 문제다.

이는 2000년경 많은 소프트웨어 회사에서 발생한 문제이며, 이를 해결하고자 2001년 초 애자일 연합이 등장한다.

애자일 연합

애자일 소프트웨어 개발 선언문

프로세스 및 툴 < 개인 및 상호작용

사람은 성공의 가장 중요한 요소다. 뛰어난 팀원이 없다면 좋은 프로세스를 가지고 있어도 프로젝트의 실패에서 구원해낼 수 없다. 하지만 뛰어난 팀원만이 모인 팀이라 해도 그들이 팀으로서 함께 일하지 않으면 실패할 수 있다.

평범한 개발자가 모여 서로 잘 대화하는 팀이, 뛰어난 개발자가 모여 서로 상호작용하지 못하는 팀보다 성공할 가능성이 높다.

어떠한 툴을 사용하기 전에, 자신이 이 툴을 사용하여 생산성을 증가시켜야만 하는 정도까지 성장했는지 먼저 판단해 보아야 한다.

팀을 구성하는 일은 환경을 구축하는 일보다 더 중요하다. 팀이 구성된 후 팀의 필요를 기반으로 환경을 구축해야 한다.

포괄적 문서 < 동작하는 소프트웨어

소프트웨어의 문서화는 필요하지만 지나친 문서화는 피해야 한다. 특히 문서와 코드가 동기화되어있지 않을 때 개발자를 잘못된 방향으로 이끌게 된다.

설계 원리와 구조에 대한 문서를 쓰는 것도 짧고 요약적이게 작성되어야 한다.

작은 문서에도 새로운 팀원이 시스템에 빠르게 적응하려면, 그와 친밀하게 일하는 것이 중요하다.

새로운 팀원에게 정보를 전할 수 있는 가장 좋은 기록은 코드와 팀이다. 코드는 그것이 하는 일에 대해 거짓말을 하지 않으며, 유일하게 모호하지 않은 정보의 원천이다.

팀원은 계속 변화하는 시스템의 지도를 머릿속에 담고 있다.

문서의 필요가 급박하고 중요하지 않다면 아무 문서도 만들지 마라.

계약 협상 < 고객 협력

성공적인 프로젝트를 위해서는 규칙적으로, 자주 고객의 피드백을 받아야 한다. 고객은 계약서나 작업 기술서에 의존하기보다는, 개발 팀의 노력의 결과에 자주 피드백을 주면서 가까이서 일해야 한다.

기본적으로 계약서만으로는 프로젝트의 진행에 부족한 부분이 많으며, 계약서가 명시한 기한은 늘어나는 경우가 부지기수다. 그러므로 개발 팀과 고객이 함께 작업하면서 이러한 사항을 결정하는 것이 좋다.

계획 준수 < 변화에 대한 반응

업무 환경은 변하기 쉽고, 이는 고객의 요구사항을 변하게 만든다. 개발자는 요구사항에 변동이 없을 거라고 확신할지라도 이를 구현하는 데 얼마나 많은 시간이 소요될지는 잘 예상하지 못한다.

다음 2주간의 세부적인 계획, 다음 3개월간의 개략적인 계획, 그 이후로는 아주 대강의 계획을 세우는 것이 좋다. 다시 말해서 가까운 시일 내에 수행할 태스크에 대해서만 세부적인 계획을 세우는 것이 좋다.

원칙

앞에서 설명한 가치는 다음의 열두 가지 원칙을 이끌어낸다. 이는 애자일 실천방법이 무거운 프로세스와 차별화되는 점들이다.

유용한 소프트웨어의 빠르고 지속적인 공개를 통해 고객을 만족시키는 것이 최고 가치

공개본에서 기능하는 부분이 적을수록 최종 공개본의 품질이 높아진다. 고객에게 자주 공개할수록 최종 품질이 좋다.

고객에게 제품을 빨리, 자주 공개한다. 기본적인 시스템을 프로젝트 시작 후 처음 몇 주 안에 공개하고, 2주마다 기능성을 증가시킨 시스템을 계속 공개하려고 노력한다.

고객은 제품을 검증하여 원하는 기능을 충분히 갖추었다고 생각하면 그 선에서 그 시스템을 생산하기로 결정할 수 있을 것이고, 그렇지 않다면 변경하기 원하는 사항을 전달할 수 있을 것이다.

개발 후반부에서도 요구사항 변경을 환영하기

변화를 걱정하지 않는다.

요구 사항 변경은 긍정적인 것이다. 팀이 시장의 요구를 충족시키기 위해 무엇을 해야 하는지 좀 더 배웠음을 의미하기 때문이다.

그러므로 애자일 팀은 소프트웨어의 구조를 탄력적으로 유지하기 위해 노력하여 요구사항이 변경되었을 때 시스템에 미치는 영향을 최소화시켜야 한다.

개발 중인 소프트웨어를 짧은 시간 간격으로 자주 공개하기

소프트웨어를 개발 중에 공개하고, 빨리 공개하고, 자주 공개한다.

고객의 요구를 만족시키는 소프트웨어를 공개하는 것이 우리의 목표이기 때문이다.

업무를 하는 사람과 개발자는 항상 함께 일해아 한다

고객과 개발자, 이해당사자 사이에 상당한 양의 빈번한 상호작용이 있어야 프로젝트를 빠르게 진행할 수 있다.

소프트웨어 프로젝트는 지속적으로 관리되어야 한다.

의욕적인 개인들을 중심으로 프로젝트 구성하고 환경과 필요로 하는 자원을 제공하기

사람이 성공의 가장 중요한 요소이므로 사람을 먼저 구성한 후 이에 따라 프로세스, 환경, 관리 등 부차적인 것을 제공한다.

직접 일대일로 대화하는 것이 개발 팀 내에서 정보를 전달하고 공유하는 가장 효율적이고 효과적인 방법

애자일 프로젝트 팀은 문서로 작성된 명세, 계획, 설계를 필요로 하지 않는다.

꼭 필요한 것은 대화이다.

개발 중인 소프트웨어가 진척 상황의 일차적 척도

진행하고 있는 단계나 작성한 문서의 양, 작성한 기반 구조 코드의 양은 중요하지 않다.

필수적인 기능을 구현한 척도가 소프트웨어 개발 진척 상황의 척도가 된다.

지속 가능한 개발

팀의 개발 속도를 조절하여 너무 지치지 않게 하고, 내일의 에너지를 빌려 오늘 일하지 않아야 한다.

프로젝트 기간 동안 가장 높은 질의 기준을 유지할 수 있을 정도로 일한다.

우수 기술과 좋은 설계에 대한 지속적인 관심은 속도를 향상시킨다

애자일 팀원은 철저하게 자신이 작성할 수 있는 가장 높은 품질의 코드만 작성한다.

문제가 생긴다면 그날 업무를 끝내기 전에 그것을 해결한다.

단순성은 필수적이다

목표와 일치하는 가장 단순한 길을 선택한다.

내일의 문제를 예상하는 것에 지나친 관심을 두지 않으며, 오늘 그 모든 문제에 대한 방지책을 세우려 하지 않는다.

현재 가장 간단하고 가장 고품질의 작업을 오늘 행하고, 내일 문제가 생긴다면 그때 변경 작업을 하는 것이 쉬울 것이라 확신한다.

자기 조직적인 팀에서 최고의 아키텍처, 요구사항, 설계가 나온다

책임감은 온전한 팀에게 전달되고, 팀은 그것을 충족시키기 위한 가장 좋은 방법을 결정한다.

팀원은 프로젝트의 모든 분야에서 함께 일한다. 팀원 한 명이 특정 업무를 담당하는 것이 아니라, 팀 전체가 이 책임을 공유한다.

팀은 규칙적으로 좀 더 효과적인 방법을 반영하고 그 행위를 종류하고 조정해야 한다

애자일 팀은 자신들을 둘러싼 환경이 계속 변하고 있다는 사실을 인지하므로, 빠른 속도를 유지하기 위해 그 환경과 함께 자신들의 조직, 규칙, 대화, 관계 등을 계속 조정한다.

결론

모든 소프트웨어 개발자와 모든 개발 팀의 직업적 목표는, 그들의 고용인과 고객에게 가능한 한 가장 높은 가치를 전달하는 것이다.

애자일 소프트웨어 개발의 원칙과 가치는 개발 팀이 프로세스의 증가 악순환을 깨고 그들의 목표에 다다르기 위해 간단한 테크닉에 초점을 맞추는 것을 돕기 위한 방법으로 만들어졌다.