Agile 원칙 및 값(Jeff Sutherland)
Jeff Sutherland는 1993년에 Scrum을 발명했으며 Ken Schwaber와 함께 작업하여 OOPSLA'95에서 Scrum을 공식화했습니다. 두 사람은 많은 소프트웨어 회사에서 Scrum을 확장하고 개선했으며 Agile Manifesto를 작성하는 작업을 도왔습니다. http://scrum.jeffsutherland.com에 있는 Jeff의 블로그에는 Scrum의 기원과 최선의 구현 방법에 대해 수록되어 있습니다. |
Agile 개발은 Scrum, XP(Extreme Programming), DSDM(Dynamic Systems Development Method) 및 Crystal을 만든 사람들, 기능 중심의 개발 지지자, 그리고 소프트웨어 업계의 여러 사고 리더들로 구성된 그룹이 2001년에 작성한 Agile Manifesto에서 유래한 용어입니다. Agile Manifesto는 당대의 모든 개별 Agile 방법론에 대한 공통적인 최우선 가치 및 원칙을 설정했습니다. 또한 팀이 높은 성과를 얻을 수 있도록 해주는 다음과 같은 네 가지 핵심 가치에 대해 자세히 설명합니다.
개인 그리고 개인의 상호 작용
작동하는 소프트웨어 제공
고객 공동 작업
변화에 대응
이러한 핵심 가치는 Manifesto for Agile Software Development 웹 사이트에서 찾아볼 수 있는 12가지 원칙을 통해 지원됩니다.
이러한 가치는 Agile Manifesto를 만든 사람들이 별 의미 없이 단순히 립 서비스용으로 제시한 것이 아니라, 현실에서도 실질적인 효력이 있는 가치입니다. 각각의 Agile 방법론이 이러한 가치를 구현하는 방법은 조금씩 다르지만, 모두 이러한 가치를 하나 이상 실현하는 구체적인 프로세스와 방법을 갖고 있습니다.
개인 및 상호 작용
팀이 높은 성과를 얻기 위해서는 개인 및 상호 작용이 필수적입니다. 한 프로젝트를 대상으로 실시한 "커뮤니케이션 포화" 연구 결과, 커뮤니케이션 문제가 없을 경우에는 팀이 업계 평균보다 50배나 높은 성과를 얻을 수 있는 것으로 나타났습니다. 커뮤니케이션을 촉진하기 위해 Agile 방법은 빈번한 조사 및 적용 주기를 사용합니다. 이러한 주기는 몇 분(페어 프로그래밍의 경우), 몇 시간(연속 통합의 경우), 매일(일일 스탠드업 미팅의 경우) 또는 일정한 반복 기간(조사 및 검토의 경우)이 될 수 있습니다.
하지만 피드백 및 커뮤니케이션의 빈도를 높이는 것만으로는 커뮤니케이션 문제를 없애기에는 역부족입니다. 이와 같은 조사 및 적용 주기는 팀 멤버가 다음과 같은 핵심적인 태도를 실천할 때만 효과를 발휘합니다.
각자의 가치에 대한 존중
모든 커뮤니케이션에 있어서의 정직
모든 데이터, 작업 및 결정의 투명성
개개인이 모두 팀을 지원한다는 믿음
팀과 팀의 목표에 대한 헌신
이러한 태도를 촉진하기 위해 Agile 관리자는 협력적인 환경을 제공하고, 팀 코치는 보다 적극적인 참여를 유도하고, 팀 멤버는 이러한 행동을 명확하게 실천해야 합니다. 그럴 경우에만 팀이 모든 잠재력을 발휘할 수 있습니다.
이러한 태도로 전환하는 것은 생각보다 어렵습니다. 대부분의 팀은 문화적 규범이나 정직한 커뮤니케이션으로 인해 충돌을 겪은 과거의 부정적인 경험 때문에 정직함, 투명성 및 신뢰를 배제하고 있습니다. 이러한 경향을 바로잡기 위해 리더와 팀 멤버는 긍정적인 의견 충돌을 장려해야 합니다. 이렇게 하면 생산적인 환경을 구축하는 데 도움이 될 뿐만 아니라 여러 가지 이점이 있습니다.
프로세스를 향상시키기 위해서는 팀이 조직 내의 장애물이나 문제를 목록으로 작성하고, 이에 정면으로 대응하고, 우선 순위에 따라 이를 체계적으로 제거해야 합니다.
혁신은 서로 충돌하는 아이디어가 자유롭게 교환될 때만 이루어집니다. Scrum의 대부라 할 수 있는 Takeuchi와 Nonaka는 이러한 현상에 대해 연구하고 저술했습니다.
팀이 공통의 목표를 갖기 위해서는 충돌하는 의제를 찾아내서 해결해야 합니다.
헌신적인 협력은 사람들이 공동의 목표에 동의하고 각자 개인으로서 또한 팀의 일원으로서 성장하려고 노력할 때 비로소 이루어집니다.
마지막 내용인 헌신이 특히 중요합니다. 개인과 팀은 헌신적으로 작업할 때만 높은 가치를 제공하는 데 한 축을 담당하고 있다는 책임감을 느끼게 됩니다. 이것은 소프트웨어 개발 팀이 가져야 하는 기본적인 자세입니다. Agile 방법론은 팀이 우선 순위가 높은 작업을 먼저 선택하고, 팀 내부 작업을 관리하고, 작업 방법을 개선하는 데 집중하도록 장려함으로써 헌신적인 자세를 이끌어냅니다. 이러한 방법은 자기 조직화의 기본이자, Agile 팀이 결과를 달성할 수 있게 해주는 동력입니다.
팀이 높은 성과를 얻을 수 있도록 Agile 방법론은 프로세스와 도구보다 개인 및 상호 작용을 중요하게 여깁니다. 모든 Agile 방법론은 사실상 빈번한 조사 및 적용 주기를 통해 커뮤니케이션과 공동 작업을 향상시키고자 합니다. 하지만 이러한 주기는 Agile 리더가 Agile 팀에서 정직, 투명성, 신뢰, 존중 및 헌신의 튼튼한 기반을 구축하는 데 필요한 긍정적인 충돌을 장려할 때만 효과를 발휘합니다.
포괄적인 문서화보다 작동하는 소프트웨어를 중시
Agile 개발이 가져다 주는 큰 차이점 중 하나가 바로 작동하는 소프트웨어입니다. Agile Manifesto에서 설명하는 모든 Agile 방법론은 실제로 작동하는 소프트웨어의 일부분을 일정한 간격으로 고객에게 제공하는 데 중점을 두고 있습니다.
모든 Agile 팀은 "작동하는 소프트웨어"에 대한 정의를 확립해야 합니다. 이를 가리켜 완성의 정의(Definition of Done)라고 합니다. 궁극적으로 기능은 모든 테스트를 통과하고 최종 사용자가 작동할 수 있는 상태가 되어야만 완성된 것으로 간주됩니다. 팀에서는 최소한 단위 테스트 수준을 넘어서 시스템 수준의 테스트를 실시해야 합니다. 가장 우수한 팀은 통합 테스트, 성능 테스트, 고객 수용 테스트까지 마쳐야 기능이 완성된 것으로 간주합니다.
한 CMMI 수준 5 회사는 여러 프로젝트의 포괄적인 데이터를 통해 기능에 수용 테스트를 포함하고, 기능을 우선 순서대로 일렬로 구현하고, 각 기능에 대한 수용 테스트를 즉시 실행하고, 발견된 버그를 최우선적으로 수정함으로써 시스템에서 생산 속도를 두 배 높이고 결함을 40% 줄이는 데 성공했습니다. 이미 세계에서 가장 낮은 결함률을 기록 중인 회사에서도 이 정도의 성과를 얻은 것입니다.
Agile Manifesto는 팀에서 작동하는 소프트웨어를 일정한 간격으로 제공할 것을 권장합니다. 완성의 정의에 동의하는 것은 Agile 팀이 이러한 목표를 달성하는 데 필요한 고성능 및 고품질을 실현하는 유용한 방법 중 하나입니다.
계약 협상보다 고객 공동 작업을 중시
지난 20년간 프로젝트 성공률은 전 세계적으로 두 배 이상 높아졌습니다. 이는 소규모 프로젝트가 늘어나고 결과물이 자주 제공되었기 때문입니다. 덕분에 고객이 작동하는 소프트웨어에 대한 피드백을 정기적으로 제공할 수 있게 되었습니다. Manifesto 작성자들이 소프트웨어 개발 프로세스에 고객을 참여시키는 것이 성공에 있어 필수적이라고 강조한 것은 확실한 근거가 있었기 때문입니다.
Agile 방법론은 고객 대표자가 개발 팀과 긴밀히 협력하도록 함으로써 이 가치를 더욱 강화합니다. 예를 들어 첫 번째 Scrum 팀은 수천 명의 고객을 보유하고 있었습니다. 이 모든 고객이 제품 개발에 참여하는 것은 현실적으로 불가능했기 때문에 제품 소유자라고 하는 고객 대리자를 선택하여 현장의 모든 고객뿐만 아니라 관리, 영업, 지원, 클라이언트 서비스 및 기타 관련자까지 대표하도록 했습니다. 제품 소유자는 팀이 작동하는 소프트웨어를 릴리스하는 4주마다 고객 및 관련자의 현실과 실제 피드백을 고려하여 요구 사항 목록을 업데이트해야 할 책임이 있었습니다. 이를 통해 고객은 제작 중인 소프트웨어의 개발에 도움을 줄 수 있었습니다.
첫 번째 XP 팀은 내부 IT 프로젝트부터 시작했습니다. 이들은 팀에 있는 회사의 최종 사용자와 매일 공동 작업을 할 수 있었습니다. 자문 팀 및 내부 팀에서는 약 10%의 시간을 하루 단위로 팀과 함께 공동 작업을 하는 최종 사용자에 할애합니다. 나머지 90%의 시간에는 대리자를 지정해야 합니다. XP 팀에서 고객이라고 부르는 이 고객 대리자는 최종 사용자와 협력하여 개발자가 구현해야 하는 기능의 명확한 우선 순위 목록을 제공합니다.
Agile 프로젝트가 전 세계에서 평균적으로 일반 프로젝트보다 두 배가 넘는 성공률을 보이는 주요 원인 중 하나는 고객 또는 고객 대리자와 매일 공동 작업하기 때문입니다. Agile 방법론에서는 이러한 점을 인식하여 개발 팀 내에 특별히 고객 대표자를 위한 자리를 마련했습니다.
계획 준수보다 변화에 대한 대응을 중시
변화에 대응하는 것은 고객을 만족시키고 비즈니스 가치를 제공하는 제품을 만드는 데 필수적입니다. 업계 데이터에 따르면 60%가 넘는 제품 또는 프로젝트 요구 사항이 소프트웨어 개발 도중에 변경되고 있습니다. 전통적인 방식의 일반 프로젝트의 경우 제때에, 예산에 맞춰, 계획된 그대로 완료되어도 고객이 정확히 원하는 것이 아니기 때문에 고객을 만족시키지 못하는 경우가 종종 있습니다. 이때 "험프리의 법칙"에 의하면 고객은 작동하는 소프트웨어를 보기 전에는 실제로 자신이 무엇을 원하는지 모릅니다. 고객이 프로젝트가 끝날 때까지 작동하는 소프트웨어를 보지 못하면 피드백을 적용하기에 너무 늦습니다. Agile 방법론은 프로젝트 전반에 걸쳐 고객의 피드백을 받으므로 제품 개발 중에 피드백과 새로운 정보를 통합할 수 있습니다.
모든 Agile 방법론은 고객 또는 고객 대리자의 피드백에 맞춰 계획을 정기적으로 변경할 수 있는 프로세스를 기본적으로 갖추고 있습니다. Agile 방법론의 계획은 항상 최고의 비즈니스 가치를 가장 우선적으로 제공하도록 설계되었습니다. 일반적인 방식의 프로젝트는 대부분 예정보다 늦게 완료되는 반면, 20%의 기능에 80%의 가치가 있기 때문에 제대로 실행된 Agile 프로젝트는 조기에 완료됩니다. 따라서 고객의 만족도는 높아지고, 개발자는 보다 즐겁게 일할 수 있습니다. Agile 방법론은 성공하기 위해서는 변화를 위한 계획을 세워야 한다는 인식을 바탕으로 합니다. 그래서 검토, 소급 등 고객 피드백과 비즈니스 가치에 맞춰 우선 순위를 정기적으로 바꿀 수 있도록 특별히 설계된 프로세스를 구축한 것입니다.
Agile은 방법론 실현을 내포하는 포괄적인 개념
Agile 개발 자체는 방법론이 아닙니다. 이는 여러 개의 Agile 방법론을 지칭하는 포괄적 용어입니다. 2001년에 Agile Manifesto가 서명될 당시에는 Agile 방법론에 Scrum, XP, Crystal, FDD 및 DSDM이 포함되어 있었습니다. 이후에 Lean 방법론이 중요한 Agile 방법론으로 등장하여 이 항목의 뒷부분에 나오는 그림과 같이 Agile 개발의 범주에 포함되었습니다.
여러 컴퓨터 언어가 개체 지향 프로그래밍의 핵심 기능을 다양한 방식으로 매니페스트하듯이 각 Agile 방법론마다 서로 조금씩 다른 방법으로 Agile Manifesto의 핵심 가치를 구현합니다. 최근의 조사 결과에 따르면 Agile 방법론을 실행하는 팀 중 약 50%가 Scrum을 사용하고, 20%가 Scrum을 XP 구성 요소와 함께 사용하고, 12%가 XP만을 사용한다고 합니다. 전 세계적으로 80%가 넘는 Agile이 Scrum 또는 XP로 구현되어 있기 때문에 MSF for Agile Software Development v5.0은 Scrum 및 XP의 핵심 프로세스와 방법에 초점을 맞춥니다.
.png "Agile 우산")
Scrum은 Agile 개발 프로세스를 위한 프레임워크로, 특정한 엔지니어링 방법을 포함하고 있지 않습니다. 반대로, XP는 엔지니어링 방법에 초점을 맞추지만 개발 프로세스의 핵심 프레임워크는 포함하고 있지 않습니다. 그렇다고 해서 Scrum이 특정 엔지니어링 방법을 권장하지 않거나, XP에 프로세스가 없는 것은 아닙니다. 예를 들어, 최초의 Scrum은 현재 XP로 알려져 있는 모든 엔지니어링 방법을 구현했습니다. 하지만 소프트웨어 개발을 위한 Scrum 프레임워크는 팀이 2-3일 안에 시작하도록 설계된 반면, 엔지니어링 방법은 종종 구현되는 데 수 개월이 걸립니다. 따라서 각 팀에 대해 특정 방법을 구현해야 하는지 여부 그리고 구현한다면 언제 해야 하는지의 문제가 남습니다. Scrum 공동 제작자인 Jeff Sutherland와 Ken Schwaber는 Scrum 팀이 즉시 시작하고 장애 요소 목록과 프로세스 향상 계획을 작성할 것을 권장합니다. 엔지니어링 방법이 장애 요소로 식별되는 경우 팀은 XP 방식을 개선책으로 고려해야 합니다. 우수한 팀들은 Scrum을 XP 방식으로 보완하여 실행합니다. Scrum은 XP를 확장해 주고, XP는 Scrum이 제대로 작동하도록 해줍니다.
다음 표에서는 Scrum과 XP의 주요 용어를 어떻게 서로 대응하는지를 보여 줍니다.
Scrum |
XP |
|---|---|
제품 소유자 |
고객(Customer) |
Scrum 마스터 |
XP 코치 |
팀 |
팀 |
스프린트 |
반복(Iteration) |
스프린트 계획 회의 |
계획 게임 |