[공개SW 활용 및 참여] Agile과 방법론 (Scrum, Kanban)

[공개SW 활용 및 참여] Agile과 방법론 (Scrum, Kanban)

2020. 7. 25. 19:49ㆍ오픈소스 아카데미

Agile 이란?

신속한 반복 작업을 통해 실제 작동 가능한 소프트웨어를 개발하여 지속적으로 제공하기 위한 소프트웨어 개발 방법에 대한 원칙.

소프트웨어 개발 탄생 초기에 제조 산업에서 차용해온 Waterfall 방법론의 한계를 극복하기 위해 고안되었고 2001년 애자일 선언문을 통해 Agile이라 명명되었다. ~~고객을 만족시키자!~~

애자일 선언문 : http://agilemanifesto.org/principles.html

애자일 선언문의 주요 4항

프로세스나 도구보다는 개인과 상호 작용을
포괄적인 문서보다는 작동하는 소프트웨어를
계약에 대한 협상보다는 고객과의 협력을
계획을 고수하기보다는 변화에 대응을 가치 있게 여긴다. 이 말은 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

Agile의 장점

변경이 포용됨 : 계획 주기가 짧으면 프로젝트 중 언제든지 변경 사항을 수용하고 수락하는 것이 쉽다. 수주 잔고를 수정하고 우선순위를 다시 정할 수 있는 기회가 항상 있기 때문에 팀이 수 주 내에 프로젝트 변경 사항을 도입할 수 있다.
최종 목표가 명확하게 정의되지 않은 프로젝트에 대해서 민첩하다. 프로젝트가 진행됨에 따라 목표가 밝혀지고 개발은 이런 진화하는 요구 사항에 쉽게 적응할 수 있다.
더 빠른 고품질 제공 : 프로젝트를 반복 단위 (관리 가능한 단위)로 분해하면 팀이 고품질 개발, 테스트 및 공동 작업에 집중할 수 있다. 반복할 때마다 테스트를 수행하면 버그를 확인하고 더 빨리 해결할 수 있다. 또한 고품질의 이 소프트웨어는 일관되고 연속적인 반복으로 더 빨리 전달될 수 있다.
강력한 팀 간 상호 작용 : Agile은 빈번한 의사소통과 대병 인터랙션의 중요성을 강조한다. 팀은 함께 일하고 사람들은 프로젝트의 책임을 맡을 수 있다.
고객은 전달되는 작업을 보고 입력을 공유하고 최종 제품에 실제 영향을 미칠 수 있는 많은 기회를 얻는다. 그들은 프로젝트 팀과 긴밀히 협력하여 소유권을 얻을 수 있다.
지속적인 개선 : 민첩한 프로젝트는 전체 프로젝트에서 사용자 및 팀원으로부터 피드백을 유도하므로 학습 한 교훈은 향후 반복을 개선하는 데 사용된다.

Agile의 단점

납기일을 고정하기 어려울 수 있다. 애자일 프로젝트 관리자는 종종 작업 우선순위를 재 지정하기 때문에 원래 배포 예정이었던 일부 항목이 완료되지 않을 수도 있다.
팀은 지식이 있어야 한다. 애자일 팀은 일반적으로 작기 때문에 팀 구성원은 다양한 영역에서 고도로 숙련되어야 하고 애자일 방법론을 이해하고 있어야 한다.
초기 적응기간 : Agile은 개발 팀이 완전히 프로젝트에 전념할 때 가장 성공적입니다. 애자일 프로세스 전반에 걸쳐 적극적인 참여와 협업이 필요하며 이는 전통적인 접근 방법보다 시간이 오래 걸립니다. 또한 개발자가 프로젝트의 전체 기간을 확약해야 한다는 것을 의미한다.
문서는 무시될 수 있다. 포괄적인 문서보다 작업 소프트웨어를 선호하므로 일부 팀원은 무서 작업에만 집중하는 것이 덜 중요하다고 느낄 수 있습니다. 애자일 팀은 문서와 토론 사이에서 적절한 균형을 찾아야 한다.
최종 제품은 매우 다를 수 있다. 초기 애자일 프로젝트는 최종 계획이 없을 수 있으므로 최종 제품은 원래 의도했던 것과 많이 다르게 보일 수 있다. 애자일은 매우 유연하기 때문에 진화하는 고객 피드백을 기반으로 새로운 반복(스프린트)이 추가될 수 있다. 이로 인해 최종 산출물이 매우 달라질 수 있다.

Agile 개발 사이클

계획 : 아이디어가 실행 가능하고 실현 가능한 것으로 간주되면 프로젝트 팀이 모여 기능을 식별한다.
요구 사항 분석 : 이 단계에서는 비즈니스 요구 사항을 파악하기 위해 관리자, 이해 관계자 및 사용자와의 많은 회의가 필요하다.
설계 : 시스템 및 소프트웨어 설계는 이전 단계에서 식별 한 요구 사항을 토대로 작성된다.
구현, 코딩 또는 개발 : 이 단계는 기능을 만들고 테스트하고 배포를 위한 반복 일정을 계획한다.
테스트 : 코드가 개발되면 요구 사항에 대해 테스트를 거쳐 제품이 실제로 고객의 요구 사항을 충족시키고 사용자 이야기와 일치하는지 확인한다.
배포 및 리뷰 : 테스트가 끝나면 제품을 고객에게 제공하여 제품을 사용할 수 있도록 한다. 그러나 배포는 프로젝트의 끝이 아니다. 고객이 제품 사용을 시작하면 프로젝트 팀이 해결해야 할 새로운 문제가 발생할 수 있다.

Methodologies to Implement Agile

이러한 애자일 개발방식을 구현하기 위한 방법론들이 있다.

익스트림 프로그래밍 (Extreme Programming, XP) : 익스트림 프로그래밍은 진화하는 고객 요구 사항에 대한 품질과 응답 성을 개선하기 위한 소프트웨어 개발 유형이다. XP의 원칙은 피드백을 포함하고, 단순성을 가정하고, 변화를 수용한다.
Lean Software Development (LSD) : LSD는 7가지 원칙 : 낭비를 제거하고, 학습을 확대하고, 가능한 한 늦게 결정하고, 가능한 한 빨리 전달하고, 팀에 권한을 부여하고, 무결성을 구축하고, 전체를 볼 수 있는 특징이 있다.
Kanban : 일본에서 '시각적 기호' 또는 '시각적 카드'를 의미하며 Agile을 구현하는 시각적 프레임 워크이다. 현재 시스템에 대한 작고 지속적인 변경을 촉진한다. 그 원칙은 다음과 같다 : 워크 플로우를 시각화하고, 진행 중인 작업을 제한하고, 플로우를 관리 및 강화하고, 정책을 명시적으로 만들고 지속적으로 향상한다.
Scrum : Agile을 구현하는 가장 보편적인 방법 중 하나이다. 변하지 않는 일련의 역할, 책임 및 회의를 따르는 반복적인 소프트웨어 모델이다. 스프린트는 대개 1~2주간 지속되므로 팀이 소프트웨어를 정기적으로 제공할 수 있다.
기타 : Feature-driven development (FDD), Adaptive system development (ASD), Dynamic Systems Development Method (DSDM), Crystal Clear

Scrum 방법론

Scrum은 Agile의 하위 집합이며 Agile을 구현하기 위한 가장 널리 사용되는 프로세스 프레임워크 중 하나이다. 복잡한 소프트웨어 및 제품 개발을 관리하는 데 사용되는 반복적인 소프트웨어 개발 모델이다.
1 ~ 2주간 지속되는 스프린트 (sprint)라는 고정된 길이의 반복을 통해 팀은 정기적으로 소프트웨어를 제공할 수 있다. 각 스프린트가 끝나면 이해 관계자와 팀 구성원이 만나 다음 단계를 계획한다.
Scrum은 변하지 않는 역할, 책임 및 모임을 따른다. 예를 들어 스프린트 계획, 데일리 스탠드 업, 스프린트 데모 및 스프린트 회고와 같은 각 스프린트에 구조를 제공하는 4가지 의식을 요구한다. 각 스프린트 동안 팀은 작업 게시판이나 번 다운 차트와 같은 시각적 게시물을 사용하여 진행 상황을 보여주고 점진적 피드백을 받는다.

Scrum의 장점

투명성과 프로젝트 가시성 향상 : 매일 회의를 통해 팀 전체의 역할 분담과 진행 사항을 확인할 수 있어, 오해와 혼란을 피할 수 있다.
팀 책임성 증대 : 스크럼 팀에게 무엇을 언제 어떻게 해야 하는지 알려주는 프로젝트 관리자(PM)는 없다. 대신 팀은 각 스프린트에서 수행할 수 있는 작업을 집합 적으로 결정한다. 팀원들은 모두 협력하고 서로를 도우며 협업을 개선하고 각 팀 구성원이 독립적으로 활동할 수 있도록 한다. 변화를 수용하기 쉬운 짧은 스프린트와 지속적인 피드백으로 변화에 쉽게 대처하고 적응할 수 있다.
비용 절감 효과 증대 : 지속적인 의사소통을 통해 팀은 모든 문제와 변화가 발생하자마자 이를 인식하여 비용을 절감하고 품질을 향상한다. 작은 덩어리로 기능을 코딩하고 테스트함으로써 지속적인 피드백이 있으며 실수를 고칠 때까지 일찍 수정될 수 있다.

Scrum에서의 역할들

제품 소유자 : 스크럼 제품 소유자는 자신이 무엇을 만들고 싶은지에 대한 비전을 가지고 있으며 팀에 그 비전을 전달한다. 제품 소유자는 비즈니스 시장 및 요구사항에 중점을 두어 모든 작업을 우선시해야 한다.
스크럼 마스터 (애자일 코치) : 미팅을 조직하고 로드 블록 및 문제를 처리하며 제품 소유자와 협력하여 제품 백 로그가 다음 스프린트에 대비할 수 있도록 보장해야 한다. 또한 스크럼 마스터는 팀이 스크럼 프로세스를 따르는지 확인한다. 팀 구성원에 대한 권한이 없지만 프로세스에 대한 권한이 있다.
스크럼 팀 : 스크럼 팀은 5명에서 7명으로 구성되는데, 전통적인 개발 팀과 다리 프로그래머, 디자이너 또는 테스터와 같은 별개의 역할 없이 모두가 함께 일련의 작업을 완료한다. 스크럼 팀은 각 스프린트에 대한 계획을 소유하고 있고 각 반복에서 얼마나 많은 작업을 완료할 수 있을지 예상한다.
고객

Steps in the Scrum process

개괄적인 Scrum 절차. Agile에서는 절차보다는 고객에게 만족스러운 결과를 우선시 함을 잊지말자.

Product Backlog : 고객이 요청한 제품의 요구사항 들을 명세한다.
Sprint Planning : Product Backlog를 우선순위에 따라 그룹 짓는다. Product Backlog를 수행하기 위한 자세한 사항들을 구체화시키고 향후 수행할 스프린트들에 분배를 한다.
Sprint Backlog : 특정 스프린트를 시작할 때 무엇을 해야할 지 결정하고 진행상황들을 표시한다.
Sprint : 정해진 주기에 따라 개발을 진행하고 리뷰하는 하나의 개발 Cycle 단위. Scrum은 이러한 Sprint들을 수 없이 반복한다. Scrum Methodology를 적용하기 위한 환경 구축 등 개발환경에 대한 것들은 Sprint'0'에서 완료하고 이후의 Sprint들 에서 Scrum을 적용한다.
Sprint들을 반복하고 고객이 만족할 만 한 결과가 이루어졌을 때 배포한다.

Tools and Methods in Scrum

스크럼 보드 : 스크럼 작업 보드로 스프린트 백 로그를 시각화할 수 있는 보드. 전통적으로는 화이트보드, Post-it를 이용한 방법이 있고 소프트웨어로도 존재한다. 스크럼 보드는 일반적으로 수행할 작업 / 진행 중인 작업 / 완료의 세 가지 범주로 나뉜다. 스크럼 팀은 전체 sprint 동안 보드를 업데이트해야 한다.
사용자 스토리 : 고객의 관점에서 소프트웨어의 기능을 설명하는 문서. 사용자의 유형, 원하는 내용 및 원하는 이유 등이 포함된다.
번 다운 차트 : 모든 수행된 작업을 나타낸다. 남은 작업, 이상적인 진행률 등의 차트로 계획에 따라 일이 진행되지 않는 경우 팀에 경고하고 의사 결정에 영향을 준다.

(좌)Scrum board (중)Burndown chart (우)User story

Kanban 방법론

Kanban은 '시각적 표시' 또는 '시각적 카드'의 일본어이다. Agile을 구현하는 데 사용되는 시각적 프레임워크로서 시점 및 수행을 보여준다. 현재 시스템에 대한 작고 점진적인 변경을 권장하며 특정 설정이나 절차가 필요하지 않다.

Kanban은 Toyota Prododuction System 및 Lean Manufacturing에서 영감을 얻었다. 1940년대 도요타는 슈퍼마켓의 재고가 얼마나 많은지를 모델화하여 엔지니어링 프로세스를 개선했는데. 소프트웨어 팀에서는 재고의 개념 대신 개발 중인 작업(WIP)의 수량을 한정 지어 놓아 팀의 Board에 '빈 공간'이 있을 때만 새 작업을 추가할 수 있다. Kanban은 WIP의 양과 팀의 역량을 조화시켜 유연성, 투명성 및 산출물을 향상한다. 주로 제품 개발 이후 사후 처리에 사용된다.

Kanban의 장점

유연성 향상 : 칸반은 진화하는 유동적인 모델이다. 설정된 기간이 없으며 새로운 정보가 들어올 때 우선순위가 재평가된다.
낭비 감소 : 칸반은 낭비를 줄이고 팀이 불필요한 작업을 하거나 시간을 낭비하지 않도록 한다.
이해하기 쉽다 : 칸반의 시각적 특성은 매우 직관적이고 배우기 쉽다. 팀은 완전히 새로운 방법론을 배울 필요가 없으며 칸반을 다른 시스템 위에 쉽게 구현할 수 있다.
전달 흐름 개선 : 칸반 팀은 고객에게 작업 흐름을 최적화한다.
사이클 시간 최소화 : 사이클 시간은 팀 작업 흐름을 통해 작업을 이동하는 데 걸리는 시간이다. 칸반 프로젝트에서 전체 팀은 작업이 프로세스를 통해 신속하고 성곡적으로 진행되도록 보장한다.

Kanban의 단점

일정 예상 어려움 : 칸반 보드의 열은 단계별로 표시되며 각 단계와 관련된 시간대가 없으므로 단계가 얼마나 오래 지속될 수 있는지 실제로 알 수 없다.

Kanban의 원칙

워크플로우 시각화 : 모든 작업을 표시함으로써 초기 문제를 식별하고 협업을 돕는다.
진행 중인 작업 제한(WIP) : 작업 진행 제한은 워크 플로우에 대한 최소 및 최대 작업량을 결정한다. WIP에 제한을 두면 속도와 유연성을 높이고 작업 우선순위를 낮출 수 있다.
흐름을 관리하고 향상함 : 칸반 보드 전반에 걸친 작업 흐름을 모니터링하고 개선해야 한다.
명시적 프로세스 정책 : 모든 사람들은 어떻게 작동하는지, 실제로 행해진 것이 무엇인지를 이해해야 한다.
지속적으로 개선됨 : 칸반은 작고 지속적인 변경을 권장한다. 칸반 시스템이 갖추어지면 팀은 문제를 식별하고 이해하고 개선을 제안할 수 있다. 팀은 흐름 추적, 주기 시간 측정 및 작업 품질 향상을 통해 효율성을 측정한다.

Scrum에 Kanban의 작업 제한 원칙을 추가하여 ScrumBan의 형태로 사용하기도 한다.

Agile을 사용해야 할 때

최종 제품이 명확하게 정의되어 있지 않을 때
클라이언트 / 이해 관계자가 범위를 변경할 수 있을 때
변경 사항이 전체 프로세스 중에 구현되어야 할 때
개발자가 적응 가능하고 독립적으로 사고할 수 있을 때
빠른 배포를 위해 최적화 해야 하는 경우

Scrum을 사용해야 할 때

프로젝트 요구 사항이 바뀌고 진화하는 경우
지속적인 피드백이 필요한 경우
작업의 대부분을 수행하는 방법을 파악해야 하는 경우
고정 된 날짜에 커밋할 필요가 없는 경우
프로젝트 팀이 자율성을 원하는 경우
정기적으로 소프트웨어를 제공해야 하는 경우

Kanban을 사용해야 할 때

반복을 요구하지 않는 프로젝트
언제든지 배포할 수 있는 것을 원하는 경우
팀이 변화를 선호할 때
팀이 가시성과 잘 어울릴 때
팀의 배포 흐름을 개선하고 싶을 때
이해하기 쉬운 시스템을 찾고 있을 때

Agile은 자유로운 개발 환경이 수용되고 그룹의 유연함이 있는 조직에서 적용하기 좋은 원칙이다.

오픈소스 아카데미 카테고리의 글들은 모두 국방오픈소스아카데미 : osam.kr 에서 비롯됨을 밝힙니다.

'오픈소스 아카데미' 카테고리의 다른 글

[개방형 OS] 다양한 개방형 OS (0)	2020.07.31
[개방형 OS] GPL과 리눅스의 탄생 (0)	2020.07.30
[공개SW 활용 및 참여] Open Source Community (0)	2020.07.26
[공개SW 활용 및 참여] Waterfall 방법론 (0)	2020.07.25

Looma Note