글 제이미 마이어
ISIS 커뮤니케이션 전문가
일반인에게 소프트웨어 개발 방법을 설명하기란 결코 쉽지 않습니다. 소프트웨어 개발에는 소위 “코드”라 불리는 개발자들만의 비밀 언어가 사용되기 때문입니다. 그래도 이번에는 이러한 비밀 언어에 대해서 잠시 설명해보겠습니다.
소프트웨어 개발에 있어 폭포수 모델은 오래된 접근 법이라 할 수 있습니다. 일반적으로 폭포수 개발은 순서에 따라 모든 작업을 순차적으로 계획해 놓고 전체 어플리케이션을 개발하는 방식입니다. 따라서 일단 작업 시작되면 마치 폭포수가 떨어지는 것처럼 쉬거나 변경되는 일 없이 전체 어플리케이션 개발이 진행됩니다. 그래서 폭포수 모델은 일반적으로 상의하달식 경영 방식과 비교할 수 있습니다.
하지만 폭포수 모델은 난해한 문제, 즉 처음 계획 단계에는 예상하지 못했던 내부 모순적 문제로 인해 프로젝트 전체가 좌초될 수 있습니다. 소프트웨어 개발 과정에서 난해한 문제들이 발생할 가능성은 매우 높고 폭포수 방법에서 고객은 프로젝트가 최종 완료되고 나서야 소프트웨어가 작동하는 모습을 확인할 수 있습니다. 게다가 이 시점에는 이미 난해한 문제들이 치명적인 문제로 성장해서 되돌리기가 힘듭니다. (위 내용은 tucows.com에서 일부 발췌했습니다.)
ZIMS는 이러한 폭포수 방법의 문제점을 보완하고자 약 10년 전에 개발된 애자일 방법을 사용합니다. 폭포수 방법에서는 심도 깊은 사전 계획을 통해 난해한 문제점을 해결하려고 한다면 애자일 방법론에서는 아무리 철저하게 사전에 준비하더라도 작업 중에는 어쩔 수 없이 난해한 문제가 발생한다고 가정합니다. 따라서 애자일 방법에서는 개발자와 고객이 긴밀하게 공조하여 계획을 변경하고 우선 순위를 다시 정하는 등 유연하게 대처합니다.
ISIS는 애자일 방법론 중에서도 스크럼 방식을 사용하고 있습니다. 스크럼은 선수들이 얼굴을 맞대고 전술을 대형을 짜는 럭비 경기에서 유래된 말입니다. 럭비 경기에서 스크럼은 몇몇의 선수들이 공을 중심으로 서로 어깨를 맞대고 밀고 당기면서 뭉친 진영을 가리키는 말입니다. 스크럼 방식에서는 단기간 집중적으로 작업해 눈으로 확인 가능한 성과물을 만들어냅니다. 그래서 마치 폭포수가 떨어지는 것처럼 전체 소프트웨어를 한 번에 릴리스하기 보다는 여러 단계로 나눠서 조금씩 릴리스하고 별도의 기능이 필요하면 이후 릴리스에 추가합니다. 전체 소프트웨어는 각 스크럼으로 나눠서 개발되고 매우 구체적인 고객의 요구 사항까지 반영하기 때문에 완전한 고객 승인을 얻을 수 있습니다. 이런 연유로 ZIMS도 여러 단계에 걸쳐 릴리스됩니다. (위 내용은 클레이그 머피의 “스크럼을 이용한 적응적 프로젝트 관리”에서 일부 발췌했습니다.)
스크럼 방식의 기본 요소 중 하나는 매일 수행하는 일일 스크럼 회의입니다. 우리는 중부 표준시 8:00 AM(뉴델리 시간 6:30 PM)에 일일 스크럼 회의를 갖습니다. 그리고 스크럼 방식의 다른 요소들과 마찬가지로 회의도 정확히 정해진 시간 안에서 이뤄집니다. 일일 스크럼 회의는 아래 세 가지 질문에 대해 모든 참석자가 가능한 간단하게 답하는 방식으로 진행되며 회의 시간은 15분을 넘지 않습니다.
어제 어떤 작업을 진행했나?
오늘은 어떤 작업을 진행할 예정인가?
오늘 작업 가운데 예상되는 문제점은 무엇인가?
스크럼 회의의 목표는 팀원들이 긴밀하게 공조하여 빠르게 작업을 진행하며 공동의 목표에 집중하도록 하는 것입니다. 스크럼 회의는 ISIS가 현재 진행하고 있는 집중 프로세스의 상징이라 할 수 있습니다. 이 프로세스가 제대로 작동하려면 스크럼 마스터라 불리는 강력한 지도자와 감독관이 필요한데 이번 프로젝트에서는 새로운 ZIMS 프로젝트 매니저, 앨빈 스미스가 이 역할을 담당하고 있습니다. 미네소타의 ISIS 사무실에서 근무하는 앨빈은 진행 속도가 빠르고 변경이 가능하며 유연하고 긴밀한 공조가 필요한 애자일 환경에서 공동 목표에 따라 모든 작업이 안정적으로 진행되도록 또한 팀원 중 누구 하나 길을 잃고 헤매지 않도록 관리 감독합니다.
ISIS 커뮤니케이션 전문가
일반인에게 소프트웨어 개발 방법을 설명하기란 결코 쉽지 않습니다. 소프트웨어 개발에는 소위 “코드”라 불리는 개발자들만의 비밀 언어가 사용되기 때문입니다. 그래도 이번에는 이러한 비밀 언어에 대해서 잠시 설명해보겠습니다.소프트웨어 개발에 있어 폭포수 모델은 오래된 접근 법이라 할 수 있습니다. 일반적으로 폭포수 개발은 순서에 따라 모든 작업을 순차적으로 계획해 놓고 전체 어플리케이션을 개발하는 방식입니다. 따라서 일단 작업 시작되면 마치 폭포수가 떨어지는 것처럼 쉬거나 변경되는 일 없이 전체 어플리케이션 개발이 진행됩니다. 그래서 폭포수 모델은 일반적으로 상의하달식 경영 방식과 비교할 수 있습니다.
하지만 폭포수 모델은 난해한 문제, 즉 처음 계획 단계에는 예상하지 못했던 내부 모순적 문제로 인해 프로젝트 전체가 좌초될 수 있습니다. 소프트웨어 개발 과정에서 난해한 문제들이 발생할 가능성은 매우 높고 폭포수 방법에서 고객은 프로젝트가 최종 완료되고 나서야 소프트웨어가 작동하는 모습을 확인할 수 있습니다. 게다가 이 시점에는 이미 난해한 문제들이 치명적인 문제로 성장해서 되돌리기가 힘듭니다. (위 내용은 tucows.com에서 일부 발췌했습니다.)ZIMS는 이러한 폭포수 방법의 문제점을 보완하고자 약 10년 전에 개발된 애자일 방법을 사용합니다. 폭포수 방법에서는 심도 깊은 사전 계획을 통해 난해한 문제점을 해결하려고 한다면 애자일 방법론에서는 아무리 철저하게 사전에 준비하더라도 작업 중에는 어쩔 수 없이 난해한 문제가 발생한다고 가정합니다. 따라서 애자일 방법에서는 개발자와 고객이 긴밀하게 공조하여 계획을 변경하고 우선 순위를 다시 정하는 등 유연하게 대처합니다.
ISIS는 애자일 방법론 중에서도 스크럼 방식을 사용하고 있습니다. 스크럼은 선수들이 얼굴을 맞대고 전술을 대형을 짜는 럭비 경기에서 유래된 말입니다. 럭비 경기에서 스크럼은 몇몇의 선수들이 공을 중심으로 서로 어깨를 맞대고 밀고 당기면서 뭉친 진영을 가리키는 말입니다. 스크럼 방식에서는 단기간 집중적으로 작업해 눈으로 확인 가능한 성과물을 만들어냅니다. 그래서 마치 폭포수가 떨어지는 것처럼 전체 소프트웨어를 한 번에 릴리스하기 보다는 여러 단계로 나눠서 조금씩 릴리스하고 별도의 기능이 필요하면 이후 릴리스에 추가합니다. 전체 소프트웨어는 각 스크럼으로 나눠서 개발되고 매우 구체적인 고객의 요구 사항까지 반영하기 때문에 완전한 고객 승인을 얻을 수 있습니다. 이런 연유로 ZIMS도 여러 단계에 걸쳐 릴리스됩니다. (위 내용은 클레이그 머피의 “스크럼을 이용한 적응적 프로젝트 관리”에서 일부 발췌했습니다.)
스크럼 방식의 기본 요소 중 하나는 매일 수행하는 일일 스크럼 회의입니다. 우리는 중부 표준시 8:00 AM(뉴델리 시간 6:30 PM)에 일일 스크럼 회의를 갖습니다. 그리고 스크럼 방식의 다른 요소들과 마찬가지로 회의도 정확히 정해진 시간 안에서 이뤄집니다. 일일 스크럼 회의는 아래 세 가지 질문에 대해 모든 참석자가 가능한 간단하게 답하는 방식으로 진행되며 회의 시간은 15분을 넘지 않습니다.
어제 어떤 작업을 진행했나?
오늘은 어떤 작업을 진행할 예정인가?
오늘 작업 가운데 예상되는 문제점은 무엇인가?
스크럼 회의의 목표는 팀원들이 긴밀하게 공조하여 빠르게 작업을 진행하며 공동의 목표에 집중하도록 하는 것입니다. 스크럼 회의는 ISIS가 현재 진행하고 있는 집중 프로세스의 상징이라 할 수 있습니다. 이 프로세스가 제대로 작동하려면 스크럼 마스터라 불리는 강력한 지도자와 감독관이 필요한데 이번 프로젝트에서는 새로운 ZIMS 프로젝트 매니저, 앨빈 스미스가 이 역할을 담당하고 있습니다. 미네소타의 ISIS 사무실에서 근무하는 앨빈은 진행 속도가 빠르고 변경이 가능하며 유연하고 긴밀한 공조가 필요한 애자일 환경에서 공동 목표에 따라 모든 작업이 안정적으로 진행되도록 또한 팀원 중 누구 하나 길을 잃고 헤매지 않도록 관리 감독합니다.
No comments:
Post a Comment