스크럼과 칸반: 두 가지 강력한 애자일 방법론 설명

복잡한 프로젝트를 관리하려고 하십니까? 해야 할 일이 많지만 당황하지 마세요! 프로젝트 관리자로서 귀하는 계획, 모니터링, 예산 관리, 실행, 품질 검증 및 최종 프로젝트를 정시에 출시하는 책임을 지게 됩니다. 고맙게도, 귀하(그리고 귀하의 팀도)의 작업을 더 쉽고 훨씬 더 효율적으로 만들 수 있는 많은 프로젝트 관리 방법이 있습니다!

이 기사에서는 최근 몇 년 동안 소프트웨어 개발 세계를 강타한 가장 인기 있는 두 가지 애자일 방법론 인 스크럼과 칸반 에 집중하고 싶습니다. 요즘에는 프로젝트 관리를 위해 이 두 프레임워크를 채택하지 않는 소프트웨어 하우스를 거의 찾을 수 없습니다. 그들은 무엇에 관한 것입니까? 계속 읽고 스크럼과 칸반에 대해 알아야 할 모든 것을 배우십시오!

프로젝트 관리에서 애자일 방법론이란 정확히 무엇입니까?

오늘날 기업들은 더 이상 개발 프로세스의 모든 단계에서 테스트하지 않고 단일 프로젝트에 대해 작업하지 않습니다. 그것은 단지 지불하지 않습니다! 왜 안 돼?

상상해 보세요. 예를 들어 전체 팀이 모바일 앱을 개발하는 데 몇 달 동안 작업하고 백엔드 및 프론트엔드 개발자, 디자이너 및 카피라이터의 전체 작업이 이미 완료된 후에만 테스트하고 평가하는 모바일 앱을 개발합니다. 당신의 제품이 더 이상 시장 요구 사항과 사용자 요구 사항에 응답하지 않는다는 것을 알게 된다면 어떻게 하시겠습니까? 그런 다음 많은 시간, 돈 및 에너지를 소모하는 전체 프로젝트의 후속 반복을 도입해야 합니다.

따라서 애자일 방법론은 워크플로를 크게 개선하고 모든 단계에서 변경 사항을 쉽게 구현하는 훌륭한 솔루션입니다. 애자일의 핵심 원칙은 하나의 "크고" 복잡한 프로젝트를 여러 개의 작은 항목(또는 기능)으로 나누고 차례로 릴리스하는 것입니다. 여기에서 개발과 테스트는 두 가지 동시 활동이므로 프로젝트를 지속적으로 검증하고 필요한 모든 개선 사항을 도입하는 것이 더 쉽습니다.

흥미로운 점은 Agile이 수년 동안 IT 및 소프트웨어 개발 회사에서 널리 사용되었지만 이 방법론이 매우 효과적이어서 오늘날에는 마케팅, 영업, HR 또는 운영과 같은 다른 많은 분야에서도 사용되고 있다는 것입니다. Verison One이 작성한 State of Agile Report에 따르면 2020년에 기술 회사와 소프트웨어 하우스의 95%가 다양한 Agile 방법을 실행하고 있습니다.

스크럼 프레임워크: 왜 그렇게 멋진가요?

많은 사람들은 매우 유사해 보이지만 동의어가 아닌 두 가지 개념을 혼동하는 경향이 있습니다. 바로 Agile과 Scrum입니다. 간단히 말해서, Agile은 Agile Manifesto에 지정된 모든 방법과 접근 방식을 나타내는 포괄적인 용어 인 반면 Scrum은 실제로 이러한 방법 중 하나입니다. 그것만큼 간단합니다!

스크럼이란 무엇이며 언제 사용할 수 있습니까?

스크럼은 개발 프로세스가 최소 몇 개월이 걸리는 복잡한 제품을 구축하는 데 주로 적용되는 프로젝트 관리 프레임워크입니다. 무엇보다도 투명성, 모든 팀 구성원 간의 지속적인 의사 소통 및 집단적 책임에 의존합니다. 이 전략은 대상 청중의 요구를 충족하고 현재 시장 요구에 응답하는 프로젝트의 최종 버전을 제공하는 것을 용이하게 합니다.

스크럼이 특히 최근 몇 년 동안 선도적인 프레임워크가 되었지만 실제로 새로운 것은 아닙니다. Harvard Business Review가 The New Product Development Game 이라는 기사를 발표한 1986년으로 돌아가 보겠습니다. 거기에서 저자들은 Honda나 Canon과 같은 회사가 성공으로 이끈 경영 방식에 대해 설명했습니다. 그런 다음 1993년 이러한 개념은 Jeff Sutherland와 Easel Corporation 팀이 Scrum이라는 팀 기반 프로세스를 구축하도록 영감을 주었습니다.

스크럼 팀의 역할 및 책임

스크럼 팀에서 모든 역할은 처음부터 명확하게 정의되며 일반적으로 전체 프로젝트에서 변경되지 않습니다. 일반적으로 이 프레임워크에는 제품 소유자, 스크럼 마스터 및 개발 팀의 3가지 기본 역할이 있습니다.

스크럼 마스터

스크럼 마스터는 모든 것이 올바른 방식으로 진행되고 개발 프로세스가 원활하게 진행되는지 확인하는 일종의(전부는 아니지만) 팀 리더입니다. 스크럼 마스터의 주요 책임은 다음과 같습니다.

• 팀원 모두가 디지털 제품의 새로운 기능을 제공하기 위해 보다 효율적으로 작업할 수 있도록 코칭
• 다음 스프린트를 위한 모든 작업 계획(아래에서 스크럼의 스프린트에 대해 자세히 설명하겠습니다) 및 제품 백로그 유지
• 프로젝트 관리를 위한 스크럼 원칙의 중요성에 대해 이해 관계자와 모든 팀 구성원 교육
• 모든 작업이 계획에 따라 수행되는지 평가
• 주어진 스프린트에서 작업의 실현을 방해하는 모든 장애물을 제거하려고 합니다.

스크럼 마스터가 항상 제품 소유자와 긴밀하게 협력 하는 것이 매우 중요합니다. 그들은 함께 후속 스프린트를 계획하고, 완료된 작업의 품질을 평가하고, 팀을 위한 방향을 설정하고, 프로젝트에 변경 도입이 필요한지 여부를 결정합니다. 간단히 말해서 스크럼 마스터는 개발 팀이 성공하고 모든 기능을 제시간에 제공할 수 있도록 최선을 다합니다.

제품 소유자

제품 소유자는 실제 비즈니스 이익을 창출할 수 있는 제품의 최종 버전을 제공할 책임이 있습니다. 따라서 전체 스크럼 팀 에서 우선 순위를 설정하고 가장 결정적인 역할을 하는 것은 제품 소유자입니다. 여기서 중요한 것은 제품 백로그가 제품 소유자가 관리한다는 것입니다. 제품 소유자는 어떤 제품 기능이 가장 큰 비즈니스 가치를 가지므로 우선적으로 개발해야 하는지를 결정합니다.

제품 소유자의 주요 책임은 다음과 같습니다.

• 제품 백로그 관리
• 이해 관계자에게 연락
• 각 스프린트의 주요 목표 정의
• 새로운 기능 출시 계획
• 개발팀의 작업을 평가하고 필요한 경우 스프린트를 취소

개발팀

개발 팀이 없었다면 스크럼은 실제 작업을 수행하고 특정 스프린트에 예정된 모든 작업을 완료하기 때문에 불가능했을 것입니다.

일반적으로 개발 팀은 iOS, 머신 러닝, 백엔드 또는 프론트엔드 개발과 같은 특정 분야의 전문 지식을 가진 사람들로 구성됩니다 . 그들은 모두 힘을 합쳐 디지털 제품의 고품질 기능을 제공합니다. 그러나 "개발 팀"이라는 용어는 일반적으로 엔지니어를 나타내지만 항상 정확한 것은 아닙니다. 마케터, 디자이너, 분석가, 테스터, 카피라이터 또는 영업 전문가도 스크럼 팀의 일원이 될 수 있습니다.

개발 팀을 구성할 때 고려해야 할 사항 중 하나는 구성원 수입니다. 여기에서도 Scrum은 몇 가지 기본 규칙을 지정합니다! 이러한 팀 은 3~9명으로 구성 되어야 하며 모든 기능을 제공하는 데 필요한 기술이 있어야 한다고 합니다. 물론, 그것은 모두 프로젝트의 복잡성과 클라이언트의 요구에 달려 있습니다. 때로는 4~5명의 개발자가 디지털 제품을 구축하기에 충분합니다.

그러나 스크럼에서 개발 팀의 역할은 정확히 무엇입니까? 기본적으로 다음을 수행해야 합니다.

• 제품 소유자의 지침에 따라 모든 제품 기능을 구축합니다.
• 주어진 스프린트에서 빌드할 항목 수 결정
• 스프린트가 끝날 때까지 모든 작업이 완료되도록 워크로드를 효율적으로 관리합니다.
• 모든 관련 결정을 공동으로
• '우리' 태도를 갖습니다. 팀이 모든 결정을 내리고 함께 문제를 해결하며 각자가 다른 동료에 대해 책임감을 느낍니다.

간단히 말해서 스크럼 개발 프로세스

스크럼이 무엇이며 누가 스크럼 팀을 구성하는지 이미 알고 있으므로 이제 이 방법론의 개발 프로세스가 어떻게 보이고 올바르게 수행하는 방법을 이해할 때입니다.

스크럼 프로세스에서는 모든 단계가 중요하며 팀에 실질적인 가치를 제공합니다. 다음은 건너뛰지 말아야 할 주요 단계입니다.

1. 제품 백로그 : 다음 스프린트에서 구축해야 하는 모든 항목의 목록입니다. 각 기능이나 항목이 언제 출시되어야 하는지 정확히 알고 있는 스크럼 마스터와 함께 제품 소유자가 관리합니다.
2. 스프린트 계획 회의 : 이 회의의 주요 목적은 개발 팀의 각 구성원이 다음 스프린트에서 무엇을 할 것인지 정의하는 것입니다. 모든 사람이 마감일 전에 모든 작업을 완료할 수 있는지 여부를 평가할 수 있도록 항상 스프린트가 시작되기 전에 구성됩니다. 모든 팀원이 스프린트의 주요 목표를 완전히 파악했는지 확인하십시오.
3. 스프린트 백로그 : 팀이 주어진 스프린트에서 수행하기로 선택한 제품 백로그에서 선택한 작업입니다.
4. 스프린트 : 모든 마법이 일어나는 곳입니다. 스프린트는 개발팀이 봄 기획 회의에서 할당된 모든 작업을 완료하는 데 일반적으로 1-4주가 소요되는 짧은 기간입니다.
5. 일일 스크럼 (Standup이라고도 함): 매일 같은 시간에 열리는 매우 짧은 회의에서 모든 사람이 1-2 문장으로 작업 진행 상황을 보고합니다. 완료한 내용과 아직 수행해야 할 작업에 대해 이야기합니다.
6. 스프린트 리뷰 : 스프린트가 끝나면 모두가 스프린트 리뷰에 자주 참석하는 다른 팀원과 이해 관계자에게 자신이 완료한 것을 발표할 기회가 있습니다.
7. 스프린트 회고 : 이제 전체 스프린트 주기를 끝내는 마지막 회의를 할 시간입니다. 팀 구성원이 다음 스프린트를 위해 개선할 수 있는 사항에 대한 제안이나 아이디어가 있는 경우 스프린트 회고 회의에서 이를 수행할 수 있습니다.

스크럼 프로세스 의 경우 각 스크럼 주기가 동일한 구조인지 확인하는 것이 중요합니다 . 스프린트 계획 회의로 시작하여 모든 사람이 작업에 착수하여 스프린트에 설정된 작업을 완료하고 맨 마지막에 모든 팀 구성원이 보여줍니다. 그들이 성취한 것.

한 가지 더 기억하고 싶은 것이 있습니다. 스크럼에는 매우 엄격한 변경 철학이 있습니다. 이것은 실제로 무엇을 의미합니까? 스크럼 팀 구성원은 스프린트 동안 작업이나 주요 목표를 변경해서는 안 됩니다. 그들이 계획한 결과를 제공하지 못한다면, 그것은 미래를 위한 교훈이 되어 항목을 완료하는 데 필요한 시간을 더 잘 추정해야 합니다.

칸반에 대한 몇 마디

이제 Scrum이 무엇인지, Scrum을 사용하여 디지털 제품을 구축하는 방법을 배웠으므로 두 번째 Agile 방법론에 조금 더 집중할 때입니다. 나는 당신이 이미 그것에 대해 잘 알고 있다고 확신합니다 – 비록 당신이 아직 깨닫지 못하더라도!

Kanban이란 무엇이며 언제 적용할 수 있습니까?

Kanban이라는 용어는 일본어에서 유래했으며 단순히 "시각적 신호"로 번역할 수 있습니다. 이것이 기본적으로 이 방법론의 전부입니다. Kanban에서 각 요소에는 팀 구성원이 화이트보드에 올려 놓고 상태를 변경하는 카드인 시각적 표현이 있습니다(예: '할 일', '하는 중' 또는 '완료').

이 접근 방식은 모든 산업 분야에서 쉽게 적용할 수 있지만 복잡하고 시간이 많이 소요되는 프로젝트와 관련된 소프트웨어 개발 팀에서 가장 자주 선택합니다. 그리고 그럴만한 이유가 있습니다. Kanban은 실시간 커뮤니케이션을 촉진하고 모든 팀원의 작업을 완전히 투명하게 만듭니다.

흥미롭게도 Kanban은 실제로 Scrum보다 훨씬 오래된 방법론입니다. 1940년대 도요타가 공장의 화이트보드에 별도의 카드를 배치하여 작업자가 언제든지 교체할 수 있는 시스템을 도입하면서 시작되었습니다. 결과적으로 이 전략은 작업을 훨씬 원활하게 하고 팀 간의 커뮤니케이션을 가속화했습니다.

칸반 팀에서 누가 누구입니까?

스크럼에 대해 논의할 때 각 팀 구성원(스크럼 마스터, 제품 소유자 및 개발자)의 정확한 역할, 책임 및 역량을 설명했습니다. 여기에서는 상황이 많이 다릅니다. Kanban은 실질적으로 모든 팀 구성원이 평등하고 집단적으로 힘과 기술을 결합하기 때문에 누가 더 많은 권한이나 책임이 있는지 정의하지 않습니다 .

또한 Kanban은 프로젝트에서 함께 작업할 수 있는 사람의 수를 지정하지 않으므로 모든 팀 구조가 허용됩니다. 그러나 워크플로를 개선하려면 교차 개발 팀 구축을 고려할 수 있습니다. 이 솔루션 덕분에 다양한 전문 분야를 가진 팀원들이 제품 개발의 각 단계에서 지식을 공유하고 피드백을 제공할 수 있습니다. 이렇게 하면 다른 팀과 전혀 상의할 필요가 없습니다!

Kanban 보드란 무엇이며 어떻게 작성합니까?

Kanban 보드는 이 방법론의 핵심이자 영혼입니다. 각 작업의 진행 상황을 실시간으로 시각화하기 위해 만든 프로젝트 관리 도구입니다. 팀원들이 이미 중요한 기능에 대한 작업을 시작했는지, 아니면 이미 완료했는지 궁금하다면 게시판을 확인하면 됩니다.

이 예는 Kanban이 무엇이며 어떻게 시각화하는지 보여줍니다.

따라서 Kanban 보드의 일반적인 개념은 매우 간단합니다. 레이블이 지정된 여러 열이 있고 각 열에 시각적 카드를 배치합니다. 스티커나 티켓이 될 수 있습니다. 이 카드 각각에 현재 참여하고 있는 프로젝트의 이름이나 구축 중인 특정 작업 항목을 기록합니다. 그런 다음 나머지 팀이 업데이트되고 현재 작업 중인 작업을 정확히 알 수 있도록 특정 카드를 특정 열에 할당하기만 하면 됩니다.

위에서 볼 수 있는 예는 다음과 같은 일반적인 열 범주를 보여줍니다.

• '할 것'
• '진행 중'
• '테스트'
• '완료'

그러나 워크플로를 보다 광범위하게 설명하고 열을 추가할 수 있습니다 . 선택은 관리 중인 프로젝트에 따라 다릅니다.

팀이 성공하기를 원한다면 한 가지 더 알아야 할 것이 있습니다. 팀이 동시에 작업할 수 있는 항목에 대한 제한을 정의해야 합니다. 이것이 Kanban이 WIT(Work In Progress) 제한 설정을 추가로 권장하는 이유입니다. 어떻게 실천할 것인가? 열에 동시에 몇 장의 카드를 유지할 수 있는지 지정해야 합니다(예: '진행 중'). 팀이 이 한도에 도달하면 단순히 카드를 더 추가할 수 없습니다. 이러한 경계를 설정하는 것은 항상 작업 과부하를 처리하는 훌륭한 솔루션입니다.

스크럼 대 칸반: 이 전투에서 어떤 프레임워크가 승리합니까?

글쎄요, 그 질문에 대한 답은 사실 그렇게 간단하지 않습니다. 이 두 애자일 전략은 몇 가지 유사한 원칙을 공유하지만 그들이 사용하는 관행은 완전히 다른 두 가지입니다. Kanban은 더 유동적이며 지속적인 변경과 정기적인 피드백을 선호하지만 Scrum은 훨씬 더 엄격하고 조직적입니다.

다음 소프트웨어 프로젝트에 대한 준비가 되셨습니까?

같이 일하자

다음은 이 두 프로젝트 관리 프레임워크 간의 주요 차이점입니다.

그렇다면 다음 중 어떤 애자일 프레임워크를 프로젝트 관리로 선택하시겠습니까? 아니면 전문가가 대신 해주기를 원하십니까? 부담 없이 문의하십시오. 다양한 Agile 방법론을 도입하여 150개 이상의 즉시 사용할 수 있는 성공적인 제품을 제공했습니다!