반응형

오랜만에 포스팅입니다.

얼마전 소프트웨어 기업을 대상으로 강의요청이 있어서 교육을 진행했습니다. 5시간 정도 교육을 마치고 교육 수강하신 분들을 대상으로 회고를 해보니 의미있었던 내용이었다는 이야기를 듣고 한번 정리해야 겠다는 마음이 들었습니다.

오늘 주제는 Waterfall, Agile, Scrum, Kanban 이라는 용어에 대해서 알아보고, 어떤 경우에 어떤 방법을 사용하는 것이 좋은지 이야기 하려고 합니다. 상세한 내용은 별도로 공유하는 자료를 참고하시기 바랍니다.

저는 소프트웨어 개발방법론 맹신자는 아니지만 개발방법론의 효용가치에 대해 인정하는 편입니다. 중요한 것은 방법론이 아니라 적절한 방법론을 적절한 곳에 사용하지 않는 사람이 문제 아닐까요. 

학교에서 배우는 소프트웨어 공학에 요즘 스크럼, 칸반이 들어있는지 모르겠지만 최근의 소프트웨어 개발방법론은 애자일 방식을 채택하는 경우가 많습니다. 

주변에서 요즘은 애자일 개발방법론을 사용하고 있다는 회사들을 종종 접하게 됩니다. 아래의 애자일 개발방식을 사용하고 있다는 사람들에게 물어본 조사결과를 보면 58%는 Scrum을 사용하고 10%는 Scrum과 XP의 하이브리드 형태를 사용하고 있습니다. 그리고 8%는 multiple methodologies를 사용하고 있죠. 7%는 Scrumban 5%는 Kanban을 사용하고 있습니다.



이 이야기는 애자일 개발방식을 사용하는 사람들이 저마다의 환경에서 적합한 방법을 채택하고 있다는 의미입니다. 하지만 아직 국내에서는 실제 현업에서 다양한 적용사례를 만나기 어려운 현실입니다. 현업에서 이야기를 하다보면 애자일과 스크럼을 동일시 하는 경우도 자주 보게 되는데 스크럼은 애자일의 서브셋 입니다.


애자일이란?

소프트웨어 개발의 기초 원칙과 정신을 선언한 철학입니다. 소프트웨어를 개발하는 더 나은 방법들에 대한 이야기를 담은 문서가 2001년 Agile Alliance 라는 그룹에서 만들어지는데 12가지의 원칙을 담고 있습니다.


애자일 철학을 반영하는 개발방법론들

Scrum?

Scrum은 Agile을 구현하는 가장 보편적 인 방법 중 하나입니다. 스크럼은 변하지 않는 일련의 역할, 책임 및 회의를 따르는 반복적인 소프트웨어 모델입니다. 


Kanban?

일본에서 '시각적 기호'또는 '카드'를 의미하는 Kanban은 Agile을 구현하는 시각적 프레임 워크입니다. 현재 시스템에 대한 작고 지속적인 변경을 촉진합니다. 그 원칙은 다음과 같습니다 : 워크 플로우를 시각화하고, 진행중인 작업을 제한하고, 플로우를 관리 및 강화하고, 정책을 명시적으로 만들고 지속적으로 향상시킵니다. 


XP(Extreme Programming)?

익스트림 프로그래밍 (Extreme Programming)은 진화하는 고객 요구 사항에 대한 품질과 응답성을 개선하기 위한 소프트웨어 개발 유형입니다. XP의 원칙은 피드백을 포함하고, 단순성을 가정하고, 변화를 수용합니다.


기타 Feature-driven development (FDD), Adaptive system development (ASD), Dynamic Systems Development Method (DSDM), Crystal Clear 등의 방법론도 애자일 개발 방법으로 사용됩니다.


그럼 모든 소프트웨어 프로젝트에 지금까지 우리가 잘 알고 있는 Waterfall을 버리고 애자일 철학을 반영한 방법론을 사용하는 것이 필요할까요? 언제 이런 애자일 개발 방법을 선택하면 좋을까요?


Waterfall 이 필요한 경우

- 범위의 변경은 기대하지 않고 고정된 가격 계약으로 작업하고 있는 경우 

- 프로젝트는 매우 간단하거나 여러 번 해본 적이 있는 경우

- 요구 사항은 잘 알려져 있고 고정되어 있을 때

- 고객이 원하는 것을 정확하게 미리 알고 있는 경우

- 질서 정연하고 예측 가능한 프로젝트로 작업하고 있는 경우


Scrume 이 필요한 경우

- 프로젝트 요구사항이 바뀌고 진화하는 경우

- 지속적인 피드백이 필요한 경우

- 프로젝트 팀이 자율성을 원하는 경우

- 정기적으로 소프트웨어를 제공해야 하는 경우


Kanban 이 필요한 경우

- 반복을 요구하지 않는 프로젝트

- 언제든지 배포 할 수 있는 것을 원하는 경우

- 팀이 변화를 선호할 때

- 팀의 배포 흐름을 개선하고 싶을 때

- 이해하기 쉬운 시스템을 찾고 있을 때


No silver bullet.

모든 프로젝트를 해결할 수 있는 유일한 소프트웨어 개발방법론은 없습니다. Waterfall, Scrum, Kanban, XP 등 다양한 소프트웨어 개발방법을 알고 우리팀에 좋은 방법을 찾아보고 서로 피드백하며 실행해가는 과정을 통해 조금씩 나아지는 것이 좋은 소프트웨어를 만들기 위해 필요한 것이며 저는 이것을 애자일이라고 부릅니다.


20180318_언제 애자일을 써야 좋을까.pdf


반응형

+ Recent posts