magaretjo

magaretjo

Make your life grateful~

Agile 프로젝트 퀵가이드(1) : Overview

Updated:

INTRO…

본 퀵가이드는 애자일 프로젝트를 시작하려는 SK주식회사의 구성원을 위해 만들어졌으며, SK주식회사 CNAPS 방법론 중 애자일 영역을 근간으로 하여 작성된 요약 지침서입니다.

※ 참고 : CNAPS Agile 방법론 ☞ https://cnaps.skcc.com/

당사의 애자일 방법론은 스크럼을 기본 레퍼런스로 참고하여 작성된 것으로, 앞으로 다루게 될 내용 또한 SW개발 프로젝트의 스크럼 적용을 위한 실무적 내용을 다룰 예정입니다.

스크럼 활동과 관련된 대부분의 내용은 “스크럼 가이드북”에서 언급하는 내용들이기 때문에, 애자일/스크럼 방법에 대해 처음 들어보거나 경험한 적이 없다면 먼저 애자일/스크럼 프로젝트 적용을 위한 관련 교육을 수강하거나 Scrum Alliance에서 발간한 스크럼 가이드북를 추천드립니다.

스크럼 가이드북은 스크럼 실천을 위해 가장 핵심적이며 필요한 내용을 다루고 있는 기본적인 안내서이므로, 스크럼을 올바르게 적용하고 싶다면 반드시 읽어보기를 권고드립니다.

전체 가이드는 overview로부터 시작해 다음과 같은 순서로 Posting됩니다.


애자일 개요

애자일 방법론들이 처음 등장하기 시작한 것은 1990년대 중반으로, 기존의 무겁고 규범적인 방법론에서 탈피하여 좀더 가벼운 방법론, 경량화 방법론(Lightweight methods)을 지향하며 Rapid개발방법, Scrum, XP 등이 나오기 시작하였습니다.

이러한 경량화 방법론 관련 종사자들이 “애자일 연합(Agile Alliance)” 그룹을 만들고 2001년 1월 ‘애자일 선언문(Agile Manifesto)’이라는 공동의 선언서를 만들어내면서 비로서 ‘애자일’이라는 명칭으로 통일되기 시작하였는데, 이후부터 “애자일”은 기존의 폭포수 방법론을 대체할 수 있는 하나의 소프트웨어 개발방식으로서 의미를 갖게 되었습니다.

애자일선언문(Agile Manifesto)

우리는, 소프트웨어를 개발하면서, 그리고 또한 다른 사람의 개발을 도와주면서 소프트웨어를 개발하는 더 나은 방법들을 찾아나가고 있다. 이 작업을 통해 다음과 같은 가치를 추구하게 되었다.
  • 프로세스나 도구 보다는 개인과 상호 작용을,
  • 포괄적인 문서 보다는 작동하는 소프트웨어를,
  • 계약에 대한 협상 보다는 고객과의 협력을,
  • 계획을 고수하기 보다는 변화에 대응을
더욱 가치 있게 여긴다.

애자일 선언에서 출발하여 애자일 연합에서는 구체적인 실천 원칙으로 다음을 제시하고 있습니다.

애자일 선언문의 바탕에 깔려있는 원칙들

  1. 우리의 최고 우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달함으로써 고객을 만족시키는 것이다.
  2. 비록 개발 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
  3. 작동하는 소프트웨어를 자주 전달하라. 약 2주에서 2개월의 정도의 간격으로 전달하되, 간격이 짧을수록 좋다.
  4. 비즈니스 영역 사람들과 개발자들은 프로젝트 전체에 걸쳐 매일 함께 일해야 한다.
  5. 동기가 갖추어져 있는 개인들로 프로젝트를 구성하라. 그들에게 그들이 필요로 하는 환경과 지원을 제공하라. 그리고 그들이 일을 끝낼 수 있도록 신뢰하라.
  6. 어떤 다른 개발팀을 상대로, 혹은 개발팀 내에서, (서로 간의) 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 보고 하는 대화이다.
  7. 작동하는 소프트웨어가 진척 측정의 주된 척도이다.
  8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 그리고 사용자들은 일정한 속도를 계속 유지할 수 있어야 한다.
  9. 기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민함을 향상시킨다.
  10. 간결함-하지 않아도 되는 일의 양을 최대화하는 기술-은 필수적이다.
  11. 최상의 아키텍처, 요구사항, 그리고 설계는 자기조직화(self-organizing)되어 있는 팀에서 나온다.
  12. 정기적으로, 팀 차원에서 어떻게 하면 더 효과적일 수 있을지에 대해 되돌아보며 자신들의 행동을 이에 따르도록 조율하고 조정한다.

위의 애자일 선언문과 구체적인 실천원칙에서 알 수 있듯이 애자일 방식을 적용하는 목적은 단순히 고객의 요구사항을 시시때때로 반영하고 최단기간에 빠른 결과물을 얻기 위함만이 아닙니다.

원하는 목적을 달성하기 위해서기 불필요한 부분을 덜어내어 간결함을 유지시키며 높은 성과를 내기 위해 필요한 환경을 조성하고, 지속적으로 돌아보고 발전시키는 노력이 필요합니다.

  • 애자일 가치
    • 위 선언문과 원칙이 바로 애자일 가치와 정신을 대변한다.
    • 따라서 애자일 프로젝트에 참여하는 구성원은 세부 시행 규칙과 방법보다는 선언문에 담겨 있는 애자일 가치 추구에 동참하려는 의지가 필요하다.
    • 프로젝트 오리엔테이션 또는 스크럼 미팅에서 프로젝트 구성원과 함께 애자일 선언문과 원칙에 대해서 낭독하고 공유할 것을 추천한다.


애자일 방법론과 스크럼

애자일 선언문이 나온 이후로 다양한 애자일 방법론이 등장하였는데, 그 기반에는 공통적으로 ‘신뢰성 높은 소프트웨어를 빨리 개발하자’는 가치를 공유하고 있습니다.

대표적인 방법론으로는 스크럼, 적응형 소프트웨어 개발 방법론(Adaptive Software Development, ASD), 기능 주도 개발방법론(Feature Driven Development, FDD), 동적 시스템 개발 방법론(Dynamic Systems Development Method, DSDM), 익스트림 프로그래밍(eXtreme Programing, XP), 린(Lean) 소프트웨어 개발방법론, 애자일 UP(Agile Unified Process, AUP) 등이 있으며 이 중에서 특히 세계적으로 널리 채택된 애자일 방법론은 스크럼과 익스트림 프로그래밍(XP)이 있습니다.

초기에는 XP를 주로 사용했지만 스크럼이 점점 많은 인기를 끌면서 현재는 스크럼과 XP를 같이 사용하는 게 일반적인 추세이다. 또한 경량화 방법론인만큼 과거에는 소규모 개발에 적합하다 여겨졌으나 최근에는 대규모 프로젝트에 SAFe, LESS와 같은 애자일 방법론을 적용하는 사례도 늘어나고 있습니다. 즉, 애자일 방법론은 소규모 프로젝트를 위한 경량화 방법론에서 출발하였지만 점차적으로 적용 가능한 프로젝트의 범위를 늘려가고 있으며, 다양한 애자일 방법론 중 하나를 프로젝트 특성에 맞게 커스터마이징하여 적용할 수 있습니다.

당사에서는 스크럼 프레임웍을 애자일 프로젝트 방법론으로 채택하였으며, CNAPS 2.0에서 관련 프로세스를 정규화하여 상세한 가이드를 마련해 놓았습니다.

따라서, 당사에서 애자일 방법론은 스크럼을 지칭하며 앞으로 나오는 퀵가이드 연재물에서도 애자일로 표현된 문구는 스크럼 방식의 애자일을 의미하고 있음을 기억하기 바랍니다.

스크럼은 1986년 타케우지 & 노나카 교수가 HBR에 기고한 “The New Product Development Game” 에서 그 실천법이 처음 소개되었는데 추정 및 조정 기반의 경험적 관리기법의 대표적인 형태로 여겨졌다. 이후 1995년에 켄 슈와버와 제프 서덜랜드가 이 방법을 소프트웨어 개발에 소개하면서 스크럼이라 명명하며 핵심적인 규칙을 정립하게 되었습니다.

스크럼 프레임워크의 규칙과 활동에 대한 세부적인 내용에 대해서는 위의 Intro에서 권고하였듯이 Scrum Alliance에서 정의한 “스크럼 가이드북”을 참고하십시오.

애자일 적용 고려사항 (애자일 적합도 검토)

프로젝트에 애자일 방법론을 어떻게 적용해야 성공적으로 적용이 가능할까 ? 이에 대한 황금룰은 정의된 바가 없습니다.

애자일(스크럼)을 적용 사례를 간접적으로 익히거나, 애자일 정신처럼 실제 프로젝트를 수행하면서 실패와 성공을 몸소 경험하고 Lessons Learned와 Know-how를 체득하는 것이 가장 좋은 접근법으로 여겨집니다.

다만 당사 방법론에서는 애자일(스크럼) 프로젝트를 처음 시작하는 구성원들을 위해 먼저 “애자일 적합도 checklist (Agile Project Fit Assessment Tool-Kit)”를 제공하며 사전 준비사항을 점검을 해보기를 가이드하고 있습니다.

즉, 해당 프로젝트를 애자일로 수행해도 될런지, 애자일 프로젝트를 수행하기 위한 준비가 되어 있는지에 대해 먼저 헤아려 봄으로써, 오히려 애자일을 올바로 수행하기 위한 예비 작업을 거칠 수 있게 됩니다.

사전점검 Checklist 중 일부 주요 사항에 대해 간략히 소개하면 다음과 같습니다.

  • 스크럼 방식에 대해 고객과 합의가 되었는가 ?
  • 역할에 필요한 권한과 책임을 위임받은 PO가 존재하며, 적극적 및 주기적으로 참여할 수 있는가 ?
  • 스크럼 팀이 Self-Organized* 및 Cross-Functional* 한가 ?
  • 기술적 부채가 많이 존재하는가 ? 즉, 해결/검증해야 할 기술요소가 많거나 적 기술장벽이 높아 아키텍처나 방향성, 설계에 대해 검증이 필요한가 ?
  • SW개발 기능에 대한 Feature 또는 업무 범위(Business Boundary)와 요구사항이 모호한가 ?

※ 위에서 Self-Organized 및 Cross-Functional한 조직의 의미는 스크럼팀 구성 편을 참고하십시오.

물론 위의 몇가지 사항만 가지고 애자일 적용 여부를 단적으로 판단하기 어려운 부분이 있습니다.

가장 크게 고려해 볼 사항은 고객사 및 PM 또는 PL이 기존에 스크럼 경험이 있는지, 애자일의 가치를 이해하고 팀웍을 이루어 함께 추구해가고자 하는 의지가 있는지입니다. 스크럼 팀이 제대로만 꾸려진다면 여러가지 어려움에도 불구하고 애자일 방식을 시도해 볼 수 있을 것입니다.

애자일 방법의 가장 큰 잇점 중 하나는 짧은 주기의 스프린트를 반복하면서 실패를 미리 경험해보고, 다음 스프린트에서 이를 개선할 수 있기 때문니까요.

다시 말하자면, 애자일을 적용하려는 프로젝트 팀(고객을 포함하여)에게는 초기 스프린트의 결과물이 기대에 못미치는 수준일지라도 일시적 실패에 대해 수용할 수 있는 포용력, 다음 스프린트에서는 이를 개선할 뿐 아니라 만회하고자 하는 모두의 노력과 헌신하려는 마음가짐이 필요합니다.

애자일을 적용하면서도 정해진 프로세스와 규칙을 워터폴 방식처럼 엄격히 적용하고 다음 스프린트에 개발팀의 회고를 반영하여 개선할 수 없다면, 또한 스프린트 실패에 대해서 질책과 책임추궁이 주로 거론된다면 차라리 단계별로 엄격히 이행 여부를 점검하는 워터폴 방법론이 더 적합할 것입니다.

또하나 프로젝트 기간이 너무 짧아서 3~5회 수준의 스프린트 밖에 돌릴 수 없다면 한번의 실패가 프로젝트의 성패를 좌우하게 될 가능성이 커지므로, 애자일 적용 여부를 재고해야 할 것입니다.

이제까지 간략하게 애자일 프로젝트 수행을 위한 기본적인 개념과 고려사항을 살펴보았습니다.

다음 장에서는 애자일 프로젝트의 착수를 위한 본격적인 준비사항을 다루겠습니다.

Related Posts :
QuickGuide 02 > 프로젝트 수행 준비


< EOF >

You May Also Enjoy