애자일, 스크럼, 칸반: 도대체 이 단어들이 의미하는 바는 무엇일까요?

소프트웨어 개발자가 "새로운 JavaScript 프레임워크" 또는 "새로운 IDE"에 대한 뉴스를 듣게 되면 그 내용을 명확히 하기 위해 더 많은 질문을 할 필요가 없습니다. 그러나 그가 "새로운 애자일 프레임워크"에 대해 듣는다면 그는 호머-심슨의 고개를 끄덕이며 그것이 무엇인지 아는 척 할 것입니다. 그러나 그는 단 하나의 질문을 할 것입니다. "애자일 프레임워크"가 도대체 ​​무엇 을 하는 걸까요 평균?

현대 소프트웨어 개발 환경에서 '애자일(agile)', '스크럼(scrum)', '칸반(kanban)'과 같은 단어를 점점 더 많이 듣게 되며 부적절하게 사용되는 경우가 많습니다. 이 기사에서는 이러한 용어 중 일부를 설명하고 명확히 하려고 합니다.

기민한

군중의 똑똑한 사람이 되고 싶다면 작업 프로세스에 대해 이야기할 때 다른 모든 문장에서 "애자일"이라는 단어를 사용해야 합니다. 그것은 꽤 넓은 범위를 가지고 있고, 당신이 말하는 주제에 대해 많이 알 필요가 없으며, 정말 좋은 형용사 또는 부사입니다. 그러나 "애자일"은 실제로 무엇을 의미합니까?

애자일(Agile)은 애자일 원칙을 따르는 개발 접근 방식인 "애자일 소프트웨어 개발"을 의미합니다. 그러나 "애자일 원칙"이란 무엇입니까? 애자일 선언문과 애자일 개발의 기초가 되는 애자일의 12가지 원칙을 살펴보세요. 선언문에서:

애자일 원칙은 작동하는 소프트웨어의 지속적인 제공, 팀 간의 긴밀한 의사 소통 및 변화하는 요구 사항에 대한 높은 적응성을 장려합니다. 업무에서 이러한 가치와 원칙을 따른다면 애자일 환경에서 일하고 있다고 말할 수 있습니다. 따라서 애자일 소프트웨어 개발은 ​​방법론이 아니라 동일한 원칙을 따르는 다양한 방법론, 프레임워크 및 기술의 집합일 뿐입니다. "애자일"은 생각하고 결정하기 위한 프레임워크라고 말할 수 있습니다.

그러나 우리의 일에서 원리를 따르는 것이 왜 그렇게 중요한가?

선언문과 원칙은 소프트웨어 개발의 도전에 대응하여 수십 년에 걸쳐 진화한 최고의 솔루션을 모색한 결과입니다. 70년대, 80년대, 90년대 전반에 걸쳐 전 세계의 다양한 개발자와 팀은 작업 방법과 문제 해결 접근 방식을 실험하고 다양한 프레임워크와 기술(예: 스크럼 및 익스트림 프로그래밍)을 발명했으며 심지어 같은 수준에 도달했습니다. 병행하는 아이디어. 마침내 2001년 2월에 17명의 개발자가 모여 이러한 다양한 아이디어와 경험의 공통 분모를 찾았습니다. 선언문은 그렇게 만들어졌습니다.

스크럼

의미를 모른 채 "애자일" 방법에 대해 이야기하는 경우 주제를 알고 있는 대화 상대 앞에서 "스크럼 및 기타 애자일 방법론"을 발견할 수 있는 말을 할 수 있습니다.

스크럼은 방법론이 아니지만 Game of Thrones 의 살인 횟수보다 더 자주 스크럼이 호출된다고 들었습니다. 스크럼은 모든 질문에 대한 답변을 제공하지 않으며 직면한 모든 상황에 응답하기 위한 정확한 절차를 제공하지 않습니다. 그리고 아마도 이 잘못된 해석의 결과로 대부분의 스크럼 구현도 잘못되었습니다. 팀은 가치를 얻지 못합니다. 이것은 아마도 스크럼에 대한 가장 어리석은 진술로 귀결됩니다. "스크럼이 작동하지 않습니다."

스크럼이란 무엇입니까? 스크럼 가이드는 스크럼을 다음과 같이 정의합니다.

따라서 이것은 프레임워크 이며 다른 프레임워크와 마찬가지로 잘못된 방식으로 사용될 수 있고 정기적으로 사용됩니다. 스크럼을 효과적으로 사용하려면 스크럼이 설정한 구조를 채택하는 것뿐만 아니라 팀 전체에 걸쳐 애자일 원칙에 대한 깊은 이해와 인식이 필요합니다.

스크럼은 제품 소유자, 스크럼 마스터, 개발 팀의 역할로 구성됩니다.

또한 4가지 스크럼 행사가 있습니다: 계획 회의, 일일 스크럼, 스프린트 검토, 스프린트 회고

그리고 세 가지 아티팩트: 제품 백로그, 스프린트 백로그, 제품 증분.

스크럼 프로젝트는 스프린트라고 하는 규칙적인 시간 프레임으로 구성됩니다. 일반적으로 2주 동안 지속됩니다.

제품 소유자 는 프로젝트의 방향을 안내할 책임이 있습니다. 새로운 작업과 기능이 결정되면 제품 소유자는 이를 제품 백로그에 추가합니다. 스프린트는 개발 팀이 백로그에서 작업할 작업을 선택하고 구현 방법을 계획하는 계획 회의에서 시작됩니다. 그 다음에는 개발 팀이 백로그를 사용하여 진행 상황을 추적하고 활동을 동기화하고 필요한 경우 계획을 조정하기 위해 일일 회의를 만나는 동안 개발이 이어집니다. 개발 결과는 제품에 적용되고 즉시 출시될 수 있는 제품 증분이어야 합니다. 스프린트가 끝나면 제품 증분이 스프린트 검토에서 제품 소유자에게 제공되며 추가 변경이 필요한 경우 제품 백로그가 추가됩니다. 그 후 팀 전체가 스프린트 회고전에 참석하여 작업 프로세스와 개선 방법에 대해 이야기합니다.

스크럼을 배우고 이해하기는 쉽지만 채택하기는 어렵습니다. 이 프레임워크가 프로젝트에 적합하거나 적합하지 않을 수 있는 많은 이유가 있습니다. 일상적인 발전뿐 아니라 문화적으로도 많은 변화가 필요한 경우가 많습니다. 스크럼은 오래 지속되고 다양한 전문가가 포함된 복잡한 제품 개발에 가장 적합합니다.

스크럼이 인기 있는 이유는 무엇이며 전통적인 폭포수 모델보다 이점이 있는 이유는 무엇입니까? 간단히 말해서 제품과 고객에게 더 많은 가치를 제공하기 때문입니다. 폭포수와 같은 "무거운" 방법을 사용하면 몇 달 동안 아무도 프로젝트를 볼 수 없는 공포 이야기가 많이 나옵니다. 스크럼에서는 불가능합니다.

스크럼은 최종 사용자에게 전달되는 가치 에 관한 것입니다. 스크럼을 실제로 활용한다면 매 스프린트마다 가치 있는 것을 제공해야 합니다. 가치를 측정할 수 있으며 팀은 다음 반복에서 더 많은 가치를 제공하기 위해 장애물을 검사하고 적응해야 합니다.

대부분의 소프트웨어 개발에서 우리는 마천루를 구축하지 않습니다. 시작하기 전에 전체 계획을 준비하고 끝날 때까지 그 계획을 고수할 필요는 없습니다. 우리는 소프트웨어를 개발 중이며 다양한 상황에 적응하고 개발 중에 제품 요구 사항을 변경할 수 있는 능력이 있습니다. 오랫동안 많은 개발자들이 이것을 여덟 번째 대죄로 여겼지만, 제품 관점에서는 예측 가능성을 최적화하고 위험을 제어하는 ​​데 큰 이점입니다. Scrum은 이 기능을 중심으로 개발되었으며 구현을 통해 필요한 변경 사항을 처리하는 안정적이고 효율적인 방법을 제공합니다.

계획 포커, 페어 프로그래밍, 테스트 주도 개발(TDD), 행동 주도 개발(BDD) 등 많은 기술이 스크럼과 함께 사용됩니다. 그것들은 실제로 스크럼의 일부가 아니라 오히려 호환 가능한 기술입니다. 스크럼과 동시에 자주 언급되는 방법 중 하나는 칸반인데, 이 두 가지가 서로의 관계에서 무엇을 의미하는지에 대해 많은 혼란이 있습니다.

칸반

스크럼과 칸반에 대해 이야기할 때 군중으로부터 자주 묻는 질문 중 하나는 "스크럼과 칸반 중 어느 것이 더 낫습니까?"입니다. 사과와 오렌지를 비교하거나 "팬케이크와 맥주 중 어느 것이 더 낫습니까?" 둘 다 더 좋습니다.

칸반은 팀원들에게 과부하를 주지 않으면서 적시 배송을 목표로 하는 간단한 방법입니다. 궁극적으로 최대 가치를 제공하는 것이 목표라는 점에서 스크럼과 유사하지만 스크럼보다 훨씬 유연합니다.

Kanban은 소프트웨어 개발 커뮤니티에서 발명한 것이 아닙니다. 사실, 그것은 Toyota의 제조 공정에 기원을 두고 있으며 다른 영역에서도 널리 사용됩니다. 따라야 하는 엄격한 절차도 없고 칸반을 구현하고 사용해야 하는 엄격한 방법도 없습니다. 그것은 오히려 원칙과 관행의 집합이며 이러한 관행에서 필요에 맞게 선택할 수 있습니다. 그러나 kanban 보드 사용을 포함하여 소프트웨어 개발에서 가장 자주 사용되는 kanban 구현이 있습니다. 작업 단계와 작업을 나타내는 열로 구성됩니다.

열은 개발 프로세스의 작업 상태를 나타냅니다. 가장 간단한 예는 "할 일", "진행 중" 및 "완료"라는 세 개의 열로 구성됩니다. 따라서 작업은 "To Do"에 추가되고 개발이 시작되면 "In Progress"로 이동하고 마지막 열로 이동하면 "Done"으로 간주됩니다. 그러나 물론 더 복잡할 수 있습니다.

백로그 → 사양 정의 → 개발 준비 → 개발 → 코드 검토 → 테스트 → 배포됨(→ 아무도 실제로 사용하지 않음 → 완전히 제거됨).

모든 열에는 하위 열이 있을 수 있습니다. 예를 들어 "개발"은 "계획"과 "코딩"으로 나눌 수 있습니다. "테스팅"은 "단위 테스팅"과 "통합 테스팅" 등으로 나눌 수 있습니다. 해당하는 경우 열이 전문가 전용일 수 있습니다. 팀은 필요에 따라 열과 단계를 정의합니다. "풀(pull)" 철학에 따라 작업은 즉각적인 요구가 있을 때만 워크플로에 들어가야 합니다.

이 보드의 목적은 칸반의 첫 번째 핵심 사례인 워크플로를 시각화하는 것입니다. 사실 칸반은 보드 없이도 할 수 있습니다! 작업 상태를 나타내는 다양한 배경색이 있는 Google 시트의 간단한 작업 목록일 수도 있고 Gantt 차트, 다이어그램, 테이블일 수도 있습니다. 사무실에 있는 버킷 세트일 수도 있습니다. 작업의 상태 및 공이 작업으로 사용되는 위치. 워크플로를 시각화하고 전체 프로세스에 투명성을 제공하기만 하면 됩니다.

또 다른 중요한 원칙은 노력의 배치 크기를 줄이는 것 입니다. 단순화하면 멀티태스킹을 피할 수 있습니다. 이는 동시에 작업하는 작업의 양을 줄이는 것을 의미할 수 있습니다. 팀에 3명의 디자이너가 있는 경우 팀은 "디자인" 열의 최대 작업 수를 3개로 설정할 수 있습니다.

스크럼과 마찬가지로 칸반도 팀을 프로세스에서 가장 중요한 인물로 봅니다. 그러나 스크럼처럼 역할을 제안하지 않으며 기존 프로세스를 변경하지 않도록 기존 역할을 유지할 수 있습니다. 지속적인 개선도 마찬가지입니다. Kanban은 일반적으로 지속적으로 배우고 개선할 것을 권장하지만 스크럼의 Sprint Retrospective처럼 해당 프로세스만을 위한 특정 이벤트를 처방하지는 않습니다.

어떤 것을 사용해야 합니까?

스크럼과 칸반은 상호 배타적이지 않으며 실제로 비교할 수도 없습니다. 스크럼에는 정의된 역할이 있는 반면 칸반은 "도대체 현재 역할과 책임을 유지하십시오."라고 말합니다. 스크럼은 일하는 방식을 바꾸도록 강요할 것입니다. kanban을 사용하면 기존 프로세스로 시작할 수 있습니다. 스크럼에서 이벤트에 대한 명확한 일정은 프레임워크에 의해 규정됩니다. 칸반에는 이벤트가 없습니다. 그러나 둘 다 가치 중심적이며 팀 구성원을 시스템의 "보스"로 존중하며 본질적으로 동일한 임무를 가지고 있습니다. 지속적으로 낭비를 제거하고 장애물을 제거하는 것입니다.

그러나 "특정 프로젝트와 특정 팀에서 무엇을 사용해야 합니까?"라는 질문이 있습니다. 훨씬 더 의미가 있습니다. Kanban은 많은 프로세스와 문화적 변화를 필요로 하지 않으며 대부분의 경우 스크럼보다 채택하기가 더 쉽습니다. 반면 스크럼은 프로세스를 안내하는 훨씬 더 많은 구조를 제공하므로 모든 사람이 같은 페이지에 있는 한 많은 오버헤드를 제거할 수 있습니다.

그러나 둘 모두의 장점은 둘 다 엄격한 규칙이 아니라는 것입니다. 일일 회의 또는 검토와 같이 가장 적합한 스크럼 요소를 선택하고 선택하는 데 방해가 되는 것은 없습니다. 그리고 칸반 보드를 스크럼에 통합하지 못할 이유가 없습니다.

스크럼은 전체 팀이 잘 이해할 때 매우 효과적인 프레임워크임이 입증되었습니다. 그러나 내 경험상 일부 클라이언트와 스크럼에서 작업하는 것이 어렵다는 것을 알았습니다. 적절한 스크럼 구현에 필요한 프로세스와 문화적 변화는 너무 많을 수 있습니다(특히 자신이 새로운 Google을 만들고 있다고 믿는 사람을 대할 때). 반면에 칸반은 더 유연하고 사람들을 바꾸도록 강요하지 않습니다. 일부 저자는 칸반이 민첩성을 위한 좋은 방법이며 스크럼을 더 쉽게 구현할 수 있다고 말합니다. 다른 사람들은 스크럼을 사용하면 결국 칸반으로 이어져야 한다고 말합니다.

진실은 모든 프로젝트가 다르고 모든 상황에 맞는 솔루션이 없다는 것입니다. 프로젝트 관리자는 팀에 가장 적합한 것이 무엇인지 결정해야 합니다.