2015.06.24

기고 | 기업 내 애자일 활용법 ① 가치

Joe Mack | CIO
오늘날 많은 이들이 애자일(Agile) 방법론에 대해 잘 알라고 있다. 오늘은 애자일의 이점, 기업 규모에서 애자일과 관련된 일부 우려사항, 이런 우려를 최소화하면서 더욱 민첩해지기 위해 사용할 수 있는 일부 전략에 대해 논의한다..

먼저 오늘은 자주 논의되고 있는 애자일 방법론의 이점(자주 언급되지 않는 1~2가지 이점 포함)에 대해 간략히 논의한다.

Credit: Thinkstock


일찍 자주 제공
각 개발 스프린트(Sprint) 후, 제 기능을 하는 소프트웨어가 제공된다. 즉, 워터폴(Waterfall) 프로젝트와는 달리 애자일 프로젝트(약 4주 스프린트)는 목표 기간에서 1개월 이상 벗어나는 일이 없다. 이는 우리가 직접 체험해 본 워터폴 방식과 크게 달라진 부분이다.

워터폴 방식의 괴담 시나리오는 이렇다. 요건을 제시하고 합의한 후 계약을 체결한다. 그리고 나서 개발자들은 1년 동안 수백 만 줄의 코드를 작성한다. 제대로 했기를 바라며 시연을 지켜본다. 목표 기한에서 크게 벗어났기 때문에 어쩔 수 없이 즉각적으로 추가적인 자본을 투입해 상황을 해결하려 한다.

그러나 애자일 방식에서는 제대로 된 소프트웨어를 제공하고 각 스프린트 후 피드백을 얻는 능력에 스프린트 자체와 관련된 반복적인 계획과 우선순위 설정이 맞물리기에 개발 중 크고 작은 변화가 가능하다.

투명성
각 스프린트 후 제대로 된 소프트웨어를 제공하는 것 외에 개발자들은 애자일 지침에 따라 매일 진행상황을 보고해야 한다. 이로 인해 일간 최신 스프린트 수준 및 릴리즈(Release) 수준 상태 보고가 이뤄진다.

이 접근방식은 항상 모든 수준에서 완전한 투명성으로 이어진다. 개발자가 몇 시간 뒤쳐져 있는 경우 이런 이례적인 상황이 전반적인 과업, 기능, 스프린트, 릴리즈 제공에 영향을 끼칠지 즉각적으로 판단할 수 있다.

유연성
스프린트 수준(매 4주 등) 뿐만이 아니라 일일 수준에서 대응하는 능력 또한 애자일을 통해서만 가능하다. 일일 보고에 기초한 스프린트 수준의 대응이 필요한 이유는 일반적으로 과업 또는 기능 예측에 상당한 오류가 존재하기 때문이다.

이 부분은 후반부에서 다루겠지만 간단히 이야기하면 프로젝트의 파라미터가 릴리즈 중간 또는 심지어 스프린트 중간에 바뀌는 경우에 그 정도로 신속하게 대응할 수 있다는 것이다.

애자일의 민첩성은 현대 개발 프로젝트의 필수요건이 되었다. 특히 클라우드 개발에 적합하다. 모든 주요 클라우드 제공자들은 거의 매월 새로운 기능을 공개하는 이유이기도 하다. 최신 상태를 유지하고 이런 기능을 적극적으로 활용하는 유일한 방법은 애자일을 통해 자신의 코드를 신속하고 효율적으로 적용하는 유연성을 갖추는 것이다.

고도의 참여도
애자일의 또 다른 핵심 이점은 프로세스 전반에 걸쳐 유연하고 협업적인 의사소통이 가능하다는 점이다. 이를 통해 워터폴 접근방식으로는 불가능한 수준의 참여가 가능하다.

제품 소유자 그리고 다른 "고객" 자원은 처음부터 직접적으로 관련된다. 이런 높은 수준의 참여는 선택적인 것이 아니기 때문에 워터폴 프로젝트에서 발생하는 고객 참여 부재 문제 완화시킨다. 고객과 이해당사자들은 각 스프린트 후 제대로 된 소프트웨어를 보고 세부적인 피드백을 제공해야만 하며 이로 인해 높은 수준의 참여도를 보이게 된다.

품질
애자일 방식에서는 모든 개발자는 시험자이기도 하다. 때문에 처음부터 품질 확보가 애자일 프로세스에 포함된다. 이것은 각 스프린트 후 제대로 된 소프트웨어를 제공하는 개념에도 포함된다. "제대로 된"이라는 것은 소프트웨어가 적절히 엄격하게 개발 및 시험되고 이것이 각 스프린트의 각 특징에 적용된다는 의미다.

실제로 그 어떤 기능도 "스프린트 완료 후" 제공의 일환으로 완전한 시험을 거쳐 공개 준비가 완료될 때까지 "완전"하다고 할 수 없다. 이것은 많은 기업에서 필수요건으로 삼고 있는 UAT(User Acceptance Testing)와 전혀 다르다. 이 부분은 추후 자세히 소개할 예정이다.

비용 예측가능성
정의상, 애자일 프로젝트는 특정 시간에 시작되고 끝난다. 정의상 애자일 프로젝트는 "죽음의 행군(Death March)"라고도 알려져 있는 "푸시 투 릴리즈(Push To Release)"를 허용하지 않으며 이를 허용해서도 안 된다.

한 릴리즈에 몇 개의 스프린트가 있고 해당 프로젝트에 몇 개의 자원이 있으며 이런 각 자원의 비용이 얼마인지 안다면 상대적인 확신을 갖고 프로젝트 비용을 예측할 수 있다. 이런 현상은 "다음 릴리즈(Next Release)"의 개념을 통해 실현된다 (하단을 참조).

행복한 개발자
새로운 개발자를 고용해 교육하기란 쉽지 않다. 대부분의 사람들은 기존의 사람들을 유지하고 싶어한다. 개발자들과 함께 지내봤다면 최고의 코드를 작성하는 사람들은 최고의 코드를 작성하지 않는 사람들과 비교했을 때 다소 "높은 유지관리"가 필요하다는 점을 알고 있을 것이다. 이런 최고 수준의 개발자들을 영입할 만큼 운이 좋다면 이들이 항상 만족할 수 있도록 하는 것이 가장 큰 관심사여야 한다.

애자일은 개발자들이 좋아하는 여러 이점이 있지만 위에서 설명한 "죽음의 행군"의 가능성을 전혀 배제할 수 없다. 또 다른 개발자 친화적인 개념은 애자일을 통해 개발자들이 요건 수집 및 예측에 참여할 수 있어 일반적으로 워터폴 개발에서는 불가능한 투자와 소유의 수준이 가능하다는 점이다.

하지만 아마도 대부분의 개발자들이 선호하는 애자일의 가장 중요한 특징은 매일 느껴지는 자주성일 것이다. 그들은 매일 스크럼(Scrum)에 참여하고 그 누구의 감독도 없이 자유롭게 코드를 개발한다.

이것이 기본적인 조치이며 성인의 행동과 코드 품질을 가정하게 된다. 단, 개발자가 어려움에 처한 경우에는 예외적으로 항상 애자일 방법론에 따라 전체 팀, 스프린트, 릴리즈의 일정이나 품질에 부정적인 영향을 끼치지 않고 관리할 수 있다.

다음 릴리즈(Next Release)를 사용
"다음 릴리즈"는 고지식한 소프트웨어 기업들이 제공하는 소프트웨어와 관련되어 있지만 애자일 개발의 필수적인 부분이다. "다음 릴리즈"를 무시하고 모든 것을 최신 릴리즈로 가져오기로 결정한 경우 이 방법론의 핵심을 무시하는 것이다.

"다른 릴리즈"를 사용한다는 것은 애자일 개발 방법론을 통해 이유야 어찌되었든 우선순위가 (가능하다면) 가장 낮고 최신 릴리즈에 의해 극복한 하나 이상의 기능을 최신 릴리즈의 제품 백로그(Backlog)에서 제외하고 "다음 릴리즈"의 제품 백로그로 옮길 준비가 되었다는 뜻이다.

여러 대기업에서 "다음 릴리즈"의 개념은 조달, 입찰/제안, 예산 계획을 둘러 싼 복잡한 프로세스와 완전히 조화를 이루지 못하고 있다. 이 부분은 다음 기사에서 다루도록 하겠다. 이번 기사에는 "다음 릴리즈"를 이미 구매하고 대가를 지불한 것으로 가정한다.

-> 관련 영상 : The case for agile in the enterprise
ciokr@idg.co.kr 



2015.06.24

기고 | 기업 내 애자일 활용법 ① 가치

Joe Mack | CIO
오늘날 많은 이들이 애자일(Agile) 방법론에 대해 잘 알라고 있다. 오늘은 애자일의 이점, 기업 규모에서 애자일과 관련된 일부 우려사항, 이런 우려를 최소화하면서 더욱 민첩해지기 위해 사용할 수 있는 일부 전략에 대해 논의한다..

먼저 오늘은 자주 논의되고 있는 애자일 방법론의 이점(자주 언급되지 않는 1~2가지 이점 포함)에 대해 간략히 논의한다.

Credit: Thinkstock


일찍 자주 제공
각 개발 스프린트(Sprint) 후, 제 기능을 하는 소프트웨어가 제공된다. 즉, 워터폴(Waterfall) 프로젝트와는 달리 애자일 프로젝트(약 4주 스프린트)는 목표 기간에서 1개월 이상 벗어나는 일이 없다. 이는 우리가 직접 체험해 본 워터폴 방식과 크게 달라진 부분이다.

워터폴 방식의 괴담 시나리오는 이렇다. 요건을 제시하고 합의한 후 계약을 체결한다. 그리고 나서 개발자들은 1년 동안 수백 만 줄의 코드를 작성한다. 제대로 했기를 바라며 시연을 지켜본다. 목표 기한에서 크게 벗어났기 때문에 어쩔 수 없이 즉각적으로 추가적인 자본을 투입해 상황을 해결하려 한다.

그러나 애자일 방식에서는 제대로 된 소프트웨어를 제공하고 각 스프린트 후 피드백을 얻는 능력에 스프린트 자체와 관련된 반복적인 계획과 우선순위 설정이 맞물리기에 개발 중 크고 작은 변화가 가능하다.

투명성
각 스프린트 후 제대로 된 소프트웨어를 제공하는 것 외에 개발자들은 애자일 지침에 따라 매일 진행상황을 보고해야 한다. 이로 인해 일간 최신 스프린트 수준 및 릴리즈(Release) 수준 상태 보고가 이뤄진다.

이 접근방식은 항상 모든 수준에서 완전한 투명성으로 이어진다. 개발자가 몇 시간 뒤쳐져 있는 경우 이런 이례적인 상황이 전반적인 과업, 기능, 스프린트, 릴리즈 제공에 영향을 끼칠지 즉각적으로 판단할 수 있다.

유연성
스프린트 수준(매 4주 등) 뿐만이 아니라 일일 수준에서 대응하는 능력 또한 애자일을 통해서만 가능하다. 일일 보고에 기초한 스프린트 수준의 대응이 필요한 이유는 일반적으로 과업 또는 기능 예측에 상당한 오류가 존재하기 때문이다.

이 부분은 후반부에서 다루겠지만 간단히 이야기하면 프로젝트의 파라미터가 릴리즈 중간 또는 심지어 스프린트 중간에 바뀌는 경우에 그 정도로 신속하게 대응할 수 있다는 것이다.

애자일의 민첩성은 현대 개발 프로젝트의 필수요건이 되었다. 특히 클라우드 개발에 적합하다. 모든 주요 클라우드 제공자들은 거의 매월 새로운 기능을 공개하는 이유이기도 하다. 최신 상태를 유지하고 이런 기능을 적극적으로 활용하는 유일한 방법은 애자일을 통해 자신의 코드를 신속하고 효율적으로 적용하는 유연성을 갖추는 것이다.

고도의 참여도
애자일의 또 다른 핵심 이점은 프로세스 전반에 걸쳐 유연하고 협업적인 의사소통이 가능하다는 점이다. 이를 통해 워터폴 접근방식으로는 불가능한 수준의 참여가 가능하다.

제품 소유자 그리고 다른 "고객" 자원은 처음부터 직접적으로 관련된다. 이런 높은 수준의 참여는 선택적인 것이 아니기 때문에 워터폴 프로젝트에서 발생하는 고객 참여 부재 문제 완화시킨다. 고객과 이해당사자들은 각 스프린트 후 제대로 된 소프트웨어를 보고 세부적인 피드백을 제공해야만 하며 이로 인해 높은 수준의 참여도를 보이게 된다.

품질
애자일 방식에서는 모든 개발자는 시험자이기도 하다. 때문에 처음부터 품질 확보가 애자일 프로세스에 포함된다. 이것은 각 스프린트 후 제대로 된 소프트웨어를 제공하는 개념에도 포함된다. "제대로 된"이라는 것은 소프트웨어가 적절히 엄격하게 개발 및 시험되고 이것이 각 스프린트의 각 특징에 적용된다는 의미다.

실제로 그 어떤 기능도 "스프린트 완료 후" 제공의 일환으로 완전한 시험을 거쳐 공개 준비가 완료될 때까지 "완전"하다고 할 수 없다. 이것은 많은 기업에서 필수요건으로 삼고 있는 UAT(User Acceptance Testing)와 전혀 다르다. 이 부분은 추후 자세히 소개할 예정이다.

비용 예측가능성
정의상, 애자일 프로젝트는 특정 시간에 시작되고 끝난다. 정의상 애자일 프로젝트는 "죽음의 행군(Death March)"라고도 알려져 있는 "푸시 투 릴리즈(Push To Release)"를 허용하지 않으며 이를 허용해서도 안 된다.

한 릴리즈에 몇 개의 스프린트가 있고 해당 프로젝트에 몇 개의 자원이 있으며 이런 각 자원의 비용이 얼마인지 안다면 상대적인 확신을 갖고 프로젝트 비용을 예측할 수 있다. 이런 현상은 "다음 릴리즈(Next Release)"의 개념을 통해 실현된다 (하단을 참조).

행복한 개발자
새로운 개발자를 고용해 교육하기란 쉽지 않다. 대부분의 사람들은 기존의 사람들을 유지하고 싶어한다. 개발자들과 함께 지내봤다면 최고의 코드를 작성하는 사람들은 최고의 코드를 작성하지 않는 사람들과 비교했을 때 다소 "높은 유지관리"가 필요하다는 점을 알고 있을 것이다. 이런 최고 수준의 개발자들을 영입할 만큼 운이 좋다면 이들이 항상 만족할 수 있도록 하는 것이 가장 큰 관심사여야 한다.

애자일은 개발자들이 좋아하는 여러 이점이 있지만 위에서 설명한 "죽음의 행군"의 가능성을 전혀 배제할 수 없다. 또 다른 개발자 친화적인 개념은 애자일을 통해 개발자들이 요건 수집 및 예측에 참여할 수 있어 일반적으로 워터폴 개발에서는 불가능한 투자와 소유의 수준이 가능하다는 점이다.

하지만 아마도 대부분의 개발자들이 선호하는 애자일의 가장 중요한 특징은 매일 느껴지는 자주성일 것이다. 그들은 매일 스크럼(Scrum)에 참여하고 그 누구의 감독도 없이 자유롭게 코드를 개발한다.

이것이 기본적인 조치이며 성인의 행동과 코드 품질을 가정하게 된다. 단, 개발자가 어려움에 처한 경우에는 예외적으로 항상 애자일 방법론에 따라 전체 팀, 스프린트, 릴리즈의 일정이나 품질에 부정적인 영향을 끼치지 않고 관리할 수 있다.

다음 릴리즈(Next Release)를 사용
"다음 릴리즈"는 고지식한 소프트웨어 기업들이 제공하는 소프트웨어와 관련되어 있지만 애자일 개발의 필수적인 부분이다. "다음 릴리즈"를 무시하고 모든 것을 최신 릴리즈로 가져오기로 결정한 경우 이 방법론의 핵심을 무시하는 것이다.

"다른 릴리즈"를 사용한다는 것은 애자일 개발 방법론을 통해 이유야 어찌되었든 우선순위가 (가능하다면) 가장 낮고 최신 릴리즈에 의해 극복한 하나 이상의 기능을 최신 릴리즈의 제품 백로그(Backlog)에서 제외하고 "다음 릴리즈"의 제품 백로그로 옮길 준비가 되었다는 뜻이다.

여러 대기업에서 "다음 릴리즈"의 개념은 조달, 입찰/제안, 예산 계획을 둘러 싼 복잡한 프로세스와 완전히 조화를 이루지 못하고 있다. 이 부분은 다음 기사에서 다루도록 하겠다. 이번 기사에는 "다음 릴리즈"를 이미 구매하고 대가를 지불한 것으로 가정한다.

-> 관련 영상 : The case for agile in the enterprise
ciokr@idg.co.kr 

X