칸반이란?

칸반은 연속적 흐름 처리 방식입니다. 이슈는 큐에 입력되고, 개발 프로세스의 단계에 따라 “당겨”집니다. 칸반은 칸반 보드로 시각화되고 각각 단계는 열로 표시됩니다. 이슈들은 “수영 레인(Swimlane)”으로 불리는 행으로 나눌 수 있습니다. 이슈들의 우선순위를 나타내기 위해 수영 레인을 이용하기로 결정하고  우선순위가 낮은 이슈들을 아래에 배치합니다. 칸반의 핵심은 Work-In-Process(WIP)가 동시에 개발이 진행 될 수 있는 아이템의 수를 제한하는 것입니다. 작업자는 WIP에 여유가 있을때만 작업을 왼쪽에서 오른쪽으로 당길 수 있습니다. 스크럼이 스프린트에 이용할 수 있는 작업 시간을 제한함으로써 생산성을 제어하는 반면, 칸반은 동시에 처리할 수 있는 이슈의 수를 제한함으로써 생산성과 벨로시티를 제어합니다. 추정은 더이상 프로세스의 일부가 아닙니다.

벨로시티는 여전히 중요 목표지만 지금 우리는 이슈 레벨에 따라 최적화 시켰고, 사이클 타임이라고 부르고 있습니다. 보드의 오른쪽에 있는 아이템은 그 뒤의 아이템들보다 더 높은 우선순위를 가집니다. 이것은 팀의 중요한 핵심 가치를 만들어 냅니다. 더 많은 작업을 하기 전에, 지금 하고 있는 작업부터 끝내야합니다. 또한 멀티 테스킹을 그만두고 이 일 저 일을 번갈아가면서 하는 것을 지양합니다.

칸반을 사용하면 사업적 요구에 따른 우선순위의 변동이 사라집니다. 사업팀은 “To Do” 열을 소유하고, 기술팀은 나머지 모든 열을 소유합니다. 사업팀은 작업들이 To Do에 있는 동안 야생 동물처럼 날뛰게 할 수 있지만, 다른 열로 이동된 이후에는 큰 노력 없이 그것들을 바꿀 수 없습니다. 결과적으로, 개발자들은 작업을 선택하는 순간 사업적인 영역과 단절됩니다.

칸반 간략 설명

칸반 장점

스크럼은 개발자에게 규범적이고 유연하지 못한 규칙을 부과하여 관리되는 것 처럼 느껴지게 만들었지만, 칸반은 탄력적이고 절차 지향적이고 기술 조직에 의해 관리됩니다. 게다가, 연속적인 흐름 모델은 “데드라인”이 없다는 것을 의미합니다. 그러나 “속도”에 대한 압박은 늘 존재합니다. 개발속도에 대한 압박은 존재하지만 데드라인이 없어 전체적인 생산성은 더 향상될 수 있습니다. 스크럼과 대비하여 전체 팀 플래닝 스프린트로 격주에 한번씩 반나절을 허비하지 않았을 수 있고 스프린트와 일치시키기 위해 개발 범위를 속이지 않을 수 있습니다. 칸반은 생산성과 코드 품질 모두를 향상시킬 수 있는 방법론이고, 한번에 여러 업무를 진행하는데서 오는 혼란을 감소 시킵니다. 거기다, 모두가 칸반 보드만 보면 무엇이 누구에 의해, 얼마정도 진행되고 있는지, 다음 작업을 위해서 무엇이 필요한지, 병목이 어디인지 알 수 있기 때문에, 프로젝트 관리 오버헤드를 감소시킬 수 있습니다.

품질에 대한 조직적 목표

계획적이지 않은 칸반의 주요 이점은 소프트웨어 품질에 초점을 맞출수 있게 해주는 것입니다. 스크럼에서는, 스프린트 내에 있는 것을 하기 위하여 코드리뷰를 건너뛰고, 코드 커버리지 표준인 95%에 못미치는 70%를 승인하는 등 기술적 부채를 늘려가는 경우가 많았습니다. 칸반에서는, 코드 품질 보증 단계는 프로세스에 포함됩니다. 거의 데드라인이 없기 때문에, 이런 단계를 건너 뛰어야 할 만한 압박이 없어집니다.

개선 VS 회고

스크럼 회고는 칸반에서 개선 회의로 대체됩니다. 개발자와 PO는 오버헤드를 감소시키면서, 속도와 품질을 향상시키기 위해 프로세스가 어떻게 수정되어야 하는지 논의합니다. 한 것을 뒤돌아보고 비판하는 대신, 진취적으로 프로세스를 개선하는데 모든 에너지를 쏟습니다. 방어적인 태도는 줄어들고, 협동력은 향상됩니다. 프로세스 안의 모든 것은 좋은 목표이고 새로운 아이디어들은 테스트 하기 위한 실험들로 간주됩니다. 대부분의 아이디어들은 시도해볼 수 있고, 매우 일부만 탈락합니다. 그 결과, 개선 회의에서는 긍정적이고, 창조적인 느낌을 받을 수 있고, 프로세스는 아주 부드럽게 수행됩니다.

칸반을 위한 소프트웨어 도구들의 미흡

Atlassian Jira와 Greenhopper가 칸반을 위한 좋은 기능들을 가지고 있지만, 이것들의 칸반 보드는 상대적으로 새롭고, 기대하는 것에 비해 유연스럽지 못합니다.(예를 들면, 수영 레인에서 WIP 한계를 가질 수 있도록).그 결과, 프로세스 일부를 Jira와 Greenhopper에서 가능하도록 맞춰야합니다. 칸반 보드를 팀의 특별한 요구에 따라 모델링 할 수 있다면, 칸반을 통해서 더 많은 이점을 얻을 수 있지만 이러한 도구가 미흡합니다.

신속함에 대한 조직의 동기부여 상실

스크럼에서는, 스프린트 시계가 큰소리로 똑딱거립니다. 모두가 스프린트 안에서 일을 완료하기 위해 압박을 느끼고 마음을 급박하게 만듭니다. 칸반에서는, 신속성은 더 추상적이고 그러한 감정적인 압박이 없기 때문에 문화부터 관리에 걸쳐 계속 열심히 해야 조직이 건강하게 유지될 수 있다는 긴장감을 부여해야만 합니다.


칸반이 완벽한 개발방법론은 아니지만 도입해보기엔 충분히 매력적입니다.

'공부' 카테고리의 다른 글

이진법, 16진법, 비트와바이트, 인코딩  (1) 2018.07.12
마이크로소프트 REST API 가이드라인  (0) 2017.03.14
칸반  (0) 2017.03.13
XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13
REPL 이란?  (0) 2017.03.08

XP - 익스트림 프로그래밍이란?

비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법입니다. 이 방법은 애자일 개발 프로세스라 불리는 개발 방법 중의 대표적인 하나로 꼽히며, 약칭인 ‘XP’로 잘 알려져 있습니다. 이 방법은 10~12개 정도의 구체적인 실천 방법(Practice)을 정의하고 있어, 비교적 적은 규모의 인원의 개발 프로젝트에 적용하기 좋습니다. 개발 문서 보다는 소스코드를, 조직적인 개발의 움직임 보다는 개개인의 책임과 용기에 중점을 두는 경향이 큽니다. 켄트 백은 XP를 이끄는 가치와 원칙에 대해서도 강조했습니다. XP에서 실천 방법에만 집중하고 가치와 원칙을 무시하면 제대로 XP를 실천하고 있다 하기 힘들 것입니다. 원칙은 가치와 실천 방법을 잇는 다리 같은 것입니다. XP의 목적은 '고객이 원하는 양질의 소프트웨어를 빠른 시간안에 전달하는 것'입니다. 수시로 발생하는 고객의 요구사항에 대처하고, 고객이 원하는 SW를 고객이 원하는 시간에 인도하기 위해서는 고객과 팀원간의 대화를 통해 해결합니다. 다른 애자일 방법론과 구분되는 XP만의 특징에는 테스팅이 있습니다. XP는 프로그래머들이 코딩을 할 때에 테스트 코드를 작성하도록 함과 동시에 테스트를 기반으로 프로젝트를 완성시켜 나가도록 합니다. 또한 이러한 테스트에 기반을 둔 프로젝트 발전 과정은 애자일 방법론의 기본 개념인 "반복적으로 프로토 타입을 고객에 전달함으로써 고객의 요구사항 변화에 민첩하게 대응한다"를 실천하는 데에 큰 도움을 줄 수 있습니다. 왜냐하면 매번 프로토 타입을 고객에 전달함에 있어서 프로토 타입 자체로써 버그가 상대적으로 적은 완벽에 가까운 데모를 경험하게 해줄 수 있기 때문입니다.

기본 원칙

기본 원칙은 다음과 같습니다.

  1. 조금씩, 하지만 자주 발표
  2. 사이클을 반복해서 돌리면서 개발
  3. 스펙에 없는 것은 절대 집어넣지 않음
  4. 테스트 코드를 먼저 만듬
  5. 야근금지. 항상 정규 일과 시간에만 작업
  6. 기회가 생기는 족족 언제 어디서든 코드를 개선
  7. 모든 테스트를 통과하기 전에는 어떤 것도 발표하지 않음
  8. 조금씩 발표하는 것을 기반으로 하여 현실적인 작업 계획을 만듬
  9. 모든 일을 단순하게 처리
  10. 두 명씩 팀을 편성하고 모든 사람이 대부분의 코드를 알 수 있도록 돌아가면서 작업

실천 방법

 Whole Team

애자일 방법론과 XP 방법론이 많이 사용되기 이전에는 팀을 기반으로 한 소프트웨어 개발이 흔치 않았습니다. 그렇기 때문에 개발자들과 프로젝트에 참여하는 관리자 모두 이러한 방법론에 대해서 진지하게 생각을 하지 않고 있었습니다. 그래서 고전적인 소프트웨어 개발 방법론인 폭포수 모델과 나선 모형에서는 수많은 소프트웨어 개발의 실패를 불러오기도 했습니다. 하지만 애자일 방법론 및 XP 방법론이 유명세를 타기 시작하면서 팀을 기반으로한 협동적인 개발 방법론이 강조되기 시작했습니다. 그러므로, 첫 번째 실천 방법인 Whole Team은 모든 프로젝트에 참여하는 팀원들을 가리키며 개개인이 각자의 역할이 있고 그들의 역할의 중요성을 이야기합니다. XP에서 말하는 Whole Team은 일반적으로 tester, interaction designers, architects, project managers, product managers, executives, technical writers, programmers and users로 구성이 됩니다. 이들 중에서 가장 중요한 팀원은 사용자(user)입니다. 왜냐하면 그들이 프로젝트의 키를 가지고 있는(stakeholder)일 뿐만 아니라 그들을 통해 요구사항(requirement)을 파악 할 수 있기 때문입니다.

Planning Game

XP에서 계획을 세우는데에는 중요한 2가지가 있습니다. 첫 번째로 '이번 반복(iteration)에는 어떤 개발 과정을 끝마칠 것인가' 와 두 번째로 '그 이후 개발 반복(iteration)에서는 무엇을 할것인가' 입니다. XP는 일반적으로 2주를 주기로 계획을 세우고 프로토 타입을 만들어서 최종 사용자 혹은 프로젝트를 의뢰한 의뢰인과 함께 무엇이 얼만큼 개발이 되었는지 혹은 알맞은 방향으로 개발이 진행이 되어가고 있는지 검사 혹은 회의를 합니다. 그렇기 때문에 그 기한 안에 프로젝트 혹은 프로토 타입은 반드시 개발이 완료가 되어야 하며, 그렇지 못해서 기한을 연장하게 되면, 그에 따른 추가 비용 및 시간적 손실이 발생하게 됩니다. 또한, 이를 통해서 소프트웨어 개발의 투명성을 확보 할 수가 있습니다. 기업의 입장에서 좋은 점은 그들의 실력 및 가능성을 보여줄 수 있는 기회로 사용될 수 있으며, 사용자 혹은 의뢰인 입장에서는 더욱 큰 금전적 손실이 발생하기 전에 프로젝트를 취소하고 다른 개발팀을 찾아 볼 수 있는 기회로 사용 될 수도 있습니다.

Customer Tests

가장 흔히 발생하는 소프트웨어 개발 실패 중 하나는 개발이 끝난 제품 혹은 소프트웨어가 처음 사용자 혹은 의뢰인이 원했던 것과 다르다는 것입니다. 그렇기 때문에 XP에서는 반복적으로 customer tests를 거칩니다. 그리고 이를 통해서 그들이 잘못 이해하고 있었던 부분에 대해서 수정을 거치기도 하며 더욱 더 의뢰인 혹은 최종 사용자의 요구에 부합하는 소프트웨어를 만들어 내게 됩니다.

Small Releases

이 실천 방안을 통해서 개발자는 주기적으로 프로토 타입을 의뢰인에게 보여줍니다. 그리고 이를 통해서 의뢰인은 제한된 기능을 가지고 있지만 실제로 작동이 되는 데모 모델을 볼 수가 있으며 추가 사항을 요구 할 수도 있습니다. 기존의 혹은 과거의 소프트웨어 개발 과정에서 개발이 끝나기 이전에 어떤 소프트웨어가 만들어질지 알 수 없었던 것과 비교해서 가장 차이점을 만들어내는 실천 방안입니다. 또한 개발자에게 있어서는 현재까지의 개발 상황이 올바른 길로 가고 있음을 알 수 있습니다.

Simple Design

보통의 프로젝트 개발 혹은 코딩의 경우 기능이 더해지면 더해질수록 복잡해 지기 마련입니다. 그렇게 되면, 새롭게 충원되는 개발자의 경우에 현재까지의 개발 상황을 이해하는데 오랜 시간이 걸리게 됩니다. 또한 버그가 발생할 경우에도 쉽게 처리를 하지 못하고 오랜 시간이 걸리게 됩니다. 그렇기 때문에 XP에서 모든 코딩을 가능한 간단하게 할 것을 강조합니다. 이러한 추세 혹은 트렌드는 KISS 원칙원리와도 함께 한다고 할 수 있습니다. (KISS 원칙이란 디자인에서 간단하고 알기 쉽게 만드는 편이 좋다는 원리를 말합니다.)

Test-Driven Development

테스트를 기반으로한 개발은 XP에서 가장 중요한 실천 방안중 하나입니다. 테스트를 거치고 코딩을 하며 프로젝트를 개발해 나갑니다.

Pair Programming

두명 혹은 그 이상의 프로그래머가 함께 코딩을 하는 것을 말합니다. 두명의 프로그래머가 함께 코딩을 하고 테스트를 통해서 개발을 할 수도 있고, 한명은 코딩을 하고 한명은 Quality Assurance 역할 통해서 테스트에만 집중을 할 수도 있습니다.

'공부' 카테고리의 다른 글

마이크로소프트 REST API 가이드라인  (0) 2017.03.14
칸반  (0) 2017.03.13
XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13
REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08

스크럼이란?

스크럼(Scrum)은 프로젝트관리를 위한 상호,점진적 개발방법론이며, 애자일 소프트웨어 공학 중의 하나입니다. 스크럼(Scrum)은 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있습니다.

스크럼 특성

스크럼은 특정 언어나 방법론에 의존적이지 않으며, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용 범위의 개발 기법입니다. 스크럼은 애자일 소프트웨어 개발 과정의 하나로 다음과 같은 특성을 가지고 있습니다.

  • 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여.
  • 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공.
  • 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공.
  • 날마다 15분 정도 회의.
  • 항상 팀 단위로 생각.
  • 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지.

스크럼이 추구하는 가치

스크럼은 다음의 5가지 가치에 중점을 두어 진행됩니다.

확약

  • 약속한 것을 확실히 실현하는 것

전념

  • 확약한 것의 실현에 전념하는 것

정직

  • 어떤 것이 자신에게 불리해도 숨기지 않는 것

존중

  • 자신과 다른 사람에게 경의를 표하는 것

용기

  • 팀 구성원은 자신이 옳은 일을 할 수 있도록 팀원 간 갈등과 도전을 통해 작업 할 수 있는 용기

스크럼의 진행

스크럼에서는, 30일간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킵니다. 아래는 스크럼 진행시 나타나는 중요 요소입니다.

  1. 일반적인 권장기간은 30일 이지만, 스크럼 적응도 및 진행 상황에 따라 1주~4주의 유연성을 가짐.

제품 백로그(Product Backlog)

  • 개발할 제품에 대한 요구 사항 목록

스프린트(Sprint)

  • 반복적인 개발 주기 (회사에서 정하는 이터레이션이 개발 주기가 됨. 계획 회의 부터 제품 리뷰가 진행 되는 날짜 까지의 기간이 1스프린트임)

스프린트 계획 회의(Sprint Planning Meeting)

  • 스프린트 목표와 스프린트 백로그를 계획하는 회의

스프린트 백로그(Sprint Backlog)

  • 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

일일 스크럼 회의(Daily Scrum Meeting)

  • 날마다 진행되는 미팅 (어제 한일, 오늘 할일, 장애 현상 등을 공유)

실행 가능한 제품(shippable product)

  • 개발 스프린트의 결과로써 나오는 실행 가능한 제품

상기 요소들을 아래와 같은 순서에 따라 사용하여 스크럼을 진행시킵니다.

  1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정함.
  2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율. 조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 됨.
  3. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당.
  4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가짐.
  5. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해.
  6. 제품의 학습과 이해가 끝나면, 스프린트 회고를 통해 팀의 개발 프로세스에 대한 개선의 시간을 갖음.
  7. 스프린트 기간 중 다음 스프린트를 준비 하기 위해 PO와 필요 인원이 모여 백로그를 준비하는 시간을 갖음.


이러한 진행 방식과 더불어, 개발 팀원 이외에 아래와 같은 직책(역할)이 정의되어 있습니다.

제품 책임자(Product Owner)

  • 제품 백 로그를 정의하여 우선순위를 정해 줌.

스크럼 마스터(ScrumMaster)

  • 프로젝트 관리자(코치)

스크럼 마스터는, 일반적인 관리를 수행하는 프로젝트 관리자들과는 달리 팀원을 코칭하고 프로젝트의 문제 상황을 해결하는 역할을 하며, 제품 책임자는 스프린트 목표와 백로그등의 결정에 있어 중심이 되는 상위 관리자로, 제품 책임자가 독단적으로 목표를 결정하지 않고, 고객과 관리자 및 팀원들이 모여서 목표를 정합니다.

이런 과정을 거친 뒤, 개발 팀원들이 주도적으로 스프린트 목표를 달성하기 위한 작업을 정해 나가게 됩니다. 보통, 각 작업들은 4시간에서 16시간 정도 걸리도록 정합니다. 물론, 작업을 정하고 할당하는데는 고객이나 제품 책임자와는 상관 없이 팀원 자율로 진행됩니다. 이와 같은 자율적인 행위를 통해서 팀원들은 의사를 활발하게 주고 받게 되고, 끈끈한 협업체계를 가지게 됩니다.


애자일 프로세스는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기 조직화를 중요하게 여기고 있습니다. 하지만, 이러한 부분과 더불어 애자일 프로세스는 무질서해 보이기 때문에 전통적인 프로세스 개선과 마찰이 생기게 됩니다.

'공부' 카테고리의 다른 글

칸반  (0) 2017.03.13
XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13
REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08
소프트웨어 개발 방법론  (0) 2017.03.08

read–eval–print loop의 약자로 파이썬 대화형 환경 같은 걸 말합니다. 컴파일 과정없이 즉석에서 코드를 입력하고 결과를 바로 알 수 있기 때문에 아주 편리합니다.


'공부' 카테고리의 다른 글

XP - 익스트림 프로그래밍  (0) 2017.03.13
스크럼  (0) 2017.03.13
REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08
소프트웨어 개발 방법론  (0) 2017.03.08
문자열 인코딩 (unicode/UTF8, UTF16, ASCII)  (0) 2016.11.09

애자일 소프트웨어 개발이란?

애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론입니다. 계획이 없는 방법론의 경우, 앞으로의 일을 예측하기 힘들고 효율적이지 못하다는 점에서 취약점을 가지고 있으며, 계획에 너무 의존하는 경우는 그 형식적인 절차를 따르는데 필요한 시간과 비용을 무시할 수 없으며, 전체적인 개발의 흐름 자체를 느리게 하는 단점을 가지고 있습니다.

그렇기 때문에 애자일 방법론에서 택한, 그리고 다른 고전적인 방법론, 예를 들면 폭포수 모델 또는 나선 모형과 구별되는 가장 큰 차이점은 less document-oriented, 즉 문서를 통한 개발 방법이 아니라, code-oriented, 실질적인 코딩을 통한 방법론이라는 점입니다. 그러므로 애자일 개발 방법론은 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 adaptive style이라고 할 수 있습니다.

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말입니다. 예전에는 애자일 개발 프로세스는 "경량(Lightweight)" 프로세스로 불렸습니다. 익스트림 프로그래밍(XP:eXtreme Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있습니다.

폭포수 모델이란?

폭포수 모델(waterfall model)은 순차적인 소프트웨어 개발 프로세스(소프트웨어를 만들기 위한 프로세스)로, 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 이름이 붙여졌습니다. 이 폭포수 모델의 흐름은 소프트웨어 요구사항 분석 단계에서 시작하여, 소프트웨어 설계소프트웨어 구현소프트웨어 시험소프트웨어 통합 단계 등을 거쳐, 소프트웨어 유지보수 단계에까지 이릅니다.

한계점 

주로 실제 실행에 있어 불가능한 모델이라는 점이 그 주요 논지인데, 의미있는 규모의 프로젝트에서는 다음 단계에 대한 이해나 경험 없이, 각 단계를 완벽히 마무리한 후 다음 단계를 진행하는 것이 불가능하다는 것입니다. 예를 들어 고객들은 동작하는 프로토타입을 보지 않고는 정확히 자신들이 무엇을 원하는지를 요구사항으로 정하지 못할 수 있습니다. 또 고객들은 정해진 요구사항을 빈번하게 수정해달라고 요구하는 경우도 많으며, 그럴 경우 설계자나 구현자가 이를 통제할 수 있는 방법은 많지 않습니다. 만약 고객이 설계가 완료된 이후에 요구사항 변경을 요구했다면, 설계는 새로운 요구사항을 위해 변경되어야 하고 그때까지 투입된 많은 노력은 무위로 돌아가게 됩니다. 또한 설계자들은 설계 시에 향후 구현 작업의 난이도를 예측하기 어렵습니다. 즉, 구현 단계에 이르러서야 특정 부분의 설계를 구현하는 것이 불가능하거나 매우 어려움이 명백해지는 경우가 있을 수 있습니다. 그럴 경우, 기존 설계를 유지하여 어려운 구현을 진행하는 것보다 재설계를 택하는 것이 향후 발생할 수 있는 더 큰 문제 상황을 방지하는 데 나은 선택입니다.

기존 개발 프로세스와 차이점

전통적인 개발 프로세스들은 폭포수 모델과 계획 기반 개발을 따르는 반면, 애자일 개발 프로세스는 그에 반한다는 점에서 가장 큰 차이를 가집니다. 폭포수 모델과 계획 기반 개발 기법들은, 일련의 차례와 탄탄한 계획을 기반으로 하여 개발을 진행시킵니다. 이것은, 이해하기도 쉽고 사용하기도 쉬운 바람직한 기법이기도 하지만, 이로 인해서 많은 부작용이 생길 수 있습니다. 가장 큰 부작용이 발생할 때는, 계획대로 진행되지 않을 경우입니다. 이럴 경우에는 다음과 같은 부작용이 발생하게 됩니다.

  • 납기일 전 철야
  • 철야에도 불구하고 납기일 지연
  • 지연에 따른 비난과 스트레스로 개발자 에너지 소진
  • 결국 납품된 솔루션은 고객의 요구를 충족하지 못함

이런 부작용은 근본적인 개발 프로세스 접근법의 차이에서 나타납니다. 전통적인 개발 프로세스들은 공업에서 사용하는 정형적 프로세스 제어 모델을 따르고 있습니다. 정형적 프로세스 제어모델은, 동일한 입력에 대해서 동일한 결과가 기대 될 경우에 적합합니다. 하지만, 소프트웨어를 포함한 IT의 개발은 경험적 프로세스 제어 모델로 접근할 필요가 있습니다. 경험적 프로세스 제어 모델은 항상 불확실성을 수반하고 포용하고 있습니다. 애자일 개발 프로세스는 경험적 프로세스 제어모델로 개발을 관리합니다.

종류

애자일 개발 프로세스로 불리는 개발 방법론에는 다음과 같은 것들이 있습니다.

  • 익스트림 프로그래밍(Extreme Programming, XP) - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 함. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트우선 개발(TDD)을 특징으로 하는 명시적인 기술과 방법을 가지고 있음.
  • 스크럼 - 30일마다 동작 가능한 제품을 제공하는 스프린트(Sprint)를 중심으로 하고 있음. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론.
  • 크리스털 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론.
  • Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가짐.
  • Adaptive Software Development, ASD - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론. 내용적으로는 다른 방법론들과 유사하지만, 합동 애플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는 것이 조금 다름.
  • 익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론. 다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 함.

상기 소개된 애자일 개발 프로세스들은 각자 다른 특징과 적용 범위가 있으며, 서로 조합도 가능합니다. 애자일 개발 프로세스를 채용하고 있는 프로젝트에서는 특정 방법론만을 채택해서 매뉴얼대로 흉내만 내는 것이 아니라, 여러 방법 중에서 자신의 프로젝트에 맞는 부분을 취사 선택하여 조합하고, 또 독자적인 방법을 만들어 냄으로써 큰 효과를 올리고 있습니다. 이러한 애자일 개발 프로세스의 제창자들은 애자일 연합이라는 자유로운 조직을 만들고, 애자일 개발 프로세스의 보급에 힘쓰고 있습니다.

적용대상

애자일 개발 프로세스를 필요로 하는 조직은 크게 두 가지로 나뉩니다.

  1. 하나는 목표 달성을 위한 프로세스를 가지지 않고, 임기응변적인 소프트웨어 개발로 인해 혼란에 빠져있는 조직. 이러한 프로젝트 팀에게 있어 애자일 개발 프로세스는, 개선을 위한 좋은 힌트가 될 것입니다. 애자일 개발 프로세스는 작고 쉽게 도입할 수 있으며, 그것에 들어가는 비용과 위험도 낮습니다.
  2. 두 번째는 이미 전통적인 소프트웨어 프로세스를 도입하고 있지만, 제대로 동작하지 않는(또는 프로세스 실시를 위한 오버헤드가 너무 커서 오히려 업무에 부담을 주고 있는) 조직. 프로세스의 도입은 조직의 문화를 바꿉니다. 효과가 크면 클수록 조직문화에 대한 영향은 커지고, 도가 지나치게 되면 고유의 문화를 파괴해 버리기도 합니다. 그러나 조직에 있어서 애자일 개발 프로세스는 좋은 결과를 가져다 줄 것입니다. 또한 CMMI나 SPICE등의 인증을 얻으려고 하는 조직에서는 그들의 요구를 충족시킬 아이디어를 제공해 줄 수 있을 것입니다.


'공부' 카테고리의 다른 글

스크럼  (0) 2017.03.13
REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08
소프트웨어 개발 방법론  (0) 2017.03.08
문자열 인코딩 (unicode/UTF8, UTF16, ASCII)  (0) 2016.11.09
데이터 검증 유의사항  (0) 2016.10.17

소프트웨어 개발방법론의 정의

  • 소프트웨어 개발 방법론은 소프트웨어를 생산하는 데에 필요한 반복적인 과정들을 정리한 것
  • 소프트웨어 공학 원리를 소프트웨어 개발 생명주기에 적용

소프트웨어 개발 방법론의 필요성

  • 개발 경험 축적 및 재활용을 통한 개발 생산성 향상(작업의 표준화/모듈화)
  • 효과적인 프로젝트 관리(수행공정의 가시화)
  • 정형화된 절차와 표준 용어의 제공으로 의사 소통 수단 제공

연도별 흐름

1970198019902000
구조적 프로그래밍구조적 시스템 분석과 설계 방법론

객체지향 프로그래밍

고속개발 방법론

스크럼

익스트림 프로그래밍

래셔널 통합 프로세스

애자일 통합 프로세스


'공부' 카테고리의 다른 글

REPL 이란?  (0) 2017.03.08
애자일 소프트웨어 개발  (0) 2017.03.08
소프트웨어 개발 방법론  (0) 2017.03.08
문자열 인코딩 (unicode/UTF8, UTF16, ASCII)  (0) 2016.11.09
데이터 검증 유의사항  (0) 2016.10.17
유니코드 BOM(Byte Order Mark)  (0) 2016.10.12

+ Random Posts