스크럼

스크럼 팀

스크럼 팀에는 제품 소유자, 스크럼 마스터 및 개발 팀이라는 세 가지 구체적인 역할이 필요합니다. 스크럼 팀은 다양한 기능을 갖추고 있기 때문에 개발팀에는 개발자뿐 아니라 테스터, 디자이너, UX 전문가 및 운영 엔지니어가 포함됩니다.

스크럼 제품 소유자

제품 소유자는 해당 제품의 챔피언으로, 비즈니스, 고객 및 시장 요구 사항을 이해하고 그에 따라 엔지니어링 팀이 해야 할 작업의 우선 순위를 정하는 데 중점을 둡니다. 효과적인 제품 소유자는 다음과 같습니다.

• 제품 백로그를 만들고 관리합니다.
• 모두가 제품 백로그의 작업 항목을 이해할 수 있도록 비즈니스 및 팀과 긴밀하게 협력합니다.
• 다음에 제공할 기능에 대한 명확한 지침을 팀에 제공합니다.

• 더 자주 제공하는 방향으로 나아가도록, 제품을 출시할 시기를 결정합니다.

제품 소유자가 항상 제품 관리자인 것은 아닙니다. 제품 소유자는 개발 팀이 비즈니스에 가장 큰 가치를 제공하도록 보장하는 데 중점을 둡니다. 또한 여러 제품 소유자로부터 엇갈린 지침을 받고 싶어 하는 개발 팀은 없으므로, 제품 소유자는 한 개인이어야 합니다.

스크럼 마스터

스크럼 마스터는 팀 내에 스크럼의 챔피언으로, 스크럼 프로세스에 대해 팀, 제품 소유자 및 비즈니스에게 코칭하고 그 프로세스의 실행을 미세 조정하는 방법을 모색합니다.

효과적인 스크럼 마스터는 팀이 수행하는 작업을 깊이 있게 이해하며 팀이 투명성과 전달 흐름을 최적화하는 데 도움을 줄 수 있습니다. 스크럼 마스터는 진행 책임자로서 스프린트 계획, 스탠드업, 스프린트 검토 및 스프린트 회고에 필요한 리소스(인력 및 물류 모두)를 예약합니다.

스크럼 개발 팀

스크럼 팀은 작업을 완료하며 지속 가능한 개발 관행의 챔피언입니다. 가장 효과적인 스크럼 팀은 아주 긴밀하고 같은 곳에 배치되며 보통 5~7명의 팀원으로 이루어져 있습니다. 팀의 규모를 정하는 한 가지 방법은 Amazon의 CEO인 Jeff Bezos가 만든 유명한 '피자 두 판 규칙'(팀은 피자 두 판을 나눠 먹을 수 있을 정도로 작아야 함)을 사용하는 것입니다.

팀원들은 서로 다른 기술 집합을 가지고 있으며, 아무도 작업 전달에 병목 현상을 일으키지 않도록 서로를 교육합니다. 강력한 스크럼 팀은 자체적으로 구성되며 분명한 '팀 중심의' 태도를 가지고 프로젝트에 접근합니다. 모든 팀원이 스프린트를 성공적으로 완료하기 위해 서로를 돕습니다.

스크럼 팀은 각 스프린트에 대한 계획을 추진하며, 과거의 속도를 가이드로 삼아 반복을 통해 작업을 얼마나 완료할 수 있을지 예측합니다. 반복의 길이를 고정하면 개발 팀에 추정 및 전달 프로세스에 대한 중요한 피드백을 제공하게 되므로 시간이 지남에 따라 추정의 정확도가 높아집니다.

스크럼 아티팩트

스크럼에서 세 가지 아티팩트를 식별하는 것부터 시작해 보겠습니다. 아티팩트는 문제를 해결하는 도구처럼 우리가 만드는 것입니다. 스크럼에서 이러한 세 가지 아티팩트는 제품 백로그, 스프린트 백로그 및 '완료'라는 정의에 대한 증분입니다. 이는 시간이 지남에 따라 계속해서 다시 방문하고 투자하게 될 스크럼 팀의 세 가지 상수입니다.

스크럼 세레모니 또는 이벤트

스크럼 프레임워크의 더 잘 알려진 구성 요소 중 몇 가지는 스크럼 팀이 정기적으로 수행하는 순차적 이벤트, 세레모니 또는 회의입니다. 세레모니에서 팀의 가장 많은 변형을 볼 수 있습니다. 예를 들어, 어떤 팀에서는 이러한 모든 세레모니를 번거롭고 반복적인 방법으로 수행하는 반면, 다른 팀에서는 세레모니를 꼭 필요한 체크인으로서 사용합니다. 저희의 조언은 두 스프린트에 대해 모든 세레모니를 사용하고 어떻게 생각되는지 확인하세요. 그런 다음 빠른 회고를 수행하고 어떤 부분을 조정할지 확인할 수 있습니다.

스크럼, 칸반, 애자일

스크럼은 아주 인기 있는 애자일 프레임워크여서 스크럼과 애자일은 종종 같은 것으로 오해받기도 합니다. 그러나 인기 있는 대안인 칸반 등의 다른 프레임워크도 있습니다. 어떤 회사에서는 '스크럼반'이라는 이름이 붙여진 스크럼과 칸반의 하이브리드 모델 또는 백로그가 있는 칸반인 '칸플랜'을 선택합니다.

스크럼과 칸반 모두 스크럼 보드 또는 칸반 보드와 같은 시각적 방법을 사용하여 작업 진행 상황을 추적합니다. 둘 다 효율성을 강조하고 복잡한 작업을 관리 가능한 작은 작업으로 나누지만 그 목표에 대한 접근 방식은 다릅니다.

스크럼은 시간이 고정된 더 작은 반복에 중점을 둡니다. 스프린트의 기간이 마무리되면 이 스프린트 주기 동안 구현할 수 있는 스토리 또는 제품 백로그 항목이 결정됩니다. 그러나 칸반에서는 현재 주기에서 구현할 작업 또는 진행 중인 작업(WIP 제한)의 수가 처음에 고정됩니다. 그런 다음, 이러한 기능을 구현하는 데 걸리는 시간을 역으로 계산합니다.

칸반은 스크럼만큼 구조화되어 있지 않습니다. WIP 제한 외에는 상당히 개방적인 해석이 가능합니다. 하지만 스크럼은 스프린트 검토, 회고, 일일 스크럼과 같이 구현의 일부로 시행되는 몇 가지 범주형 개념을 가지고 있으며 스크럼 팀이 목표를 달성하기 위해 외부 구성원에 의존하지 않는 교차 기능성을 내세웁니다. 교차 기능 팀을 모으기란 간단한 일이 아닙니다. 이러한 면에서 칸반은 적응하기 더 쉽지만 스크럼은 개발 팀의 사고 과정과 기능의 근본적인 변화로 간주될 수 있습니다.

Commitment

Because scrum teams are small and agile, each team member plays a significant role in the team’s success. Therefore, each team member should agree to commit to performing tasks they can complete and not overcommit. There should be frequent communication regarding work progress, often in stand-ups.

Courage

Courage for a scrum team is simply the bravery to question the status quo or anything that hampers its ability to succeed. Scrum team members should have the courage, and feel safe enough, to try new things. A scrum team should have the courage and feel safe to be transparent about roadblocks, project progress, delays, and so on.

Focus

At the heart of the workflow for scrum teams is the sprint, a focused and specified period of time where the team completes a set amount of work. The sprint provides structure but also focus to complete the planned amount of work.

Openness

The daily stand-up fosters an openness that allows teams to talk openly about work in progress and blockers. At Atlassian we often have our scrum teams address these questions:

• What did I work on yesterday?
• What am I working on today?
• What issues are blocking me?

This helps to highlight progress and identify blockers. It also helps to strengthen the team when everyone shares progress.

Respect

The strength of an agile team lies in its collaboration and recognizing that each team member contributes to work in a sprint. They celebrate each other’s accomplishments and are respectful to one another, the product owner, stakeholders, and the scrum master.

Scrum, kanban, and agile

Scrum is such a popular agile framework that scrum and agile are often misunderstood to be the same thing. But there are other frameworks, like kanban, which is a popular alternative. Some companies even choose to follow a hybrid model of scrum and kanban, which has acquired the name of "Scrumban" or "Kanplan," which is Kanban with a backlog.  

Both scrum and kanban use visual methods such as the scrum board or kanban board to track the progress of work. Both emphasize efficiency and splitting complex tasks into smaller chunks of manageable work, but their approaches towards that goal are different.

Scrum focuses on smaller, fixed-length iterations. Once the time period for a sprint is finalized, the stories or product backlog entries that can be implemented during this sprint cycle are then determined. In kanban, however, the number of tasks or the work in progress (WIP limit) to be implemented in the current cycle is fixed at first. The time taken to implement these features is then calculated backward.

Kanban is not as structured as scrum. Other than the WIP limit, it is fairly open to interpretation. Scrum, however, has several categorical concepts enforced as part of its implementation such as sprint review, retrospective, daily scrum, etc. It also insists on cross-functionality, which is the ability of a scrum team to not depend on external members to achieve their goals. Putting together a cross-functional team is not straightforward. In that sense, kanban is easier to adapt whereas scrum can be considered as a fundamental shift in the thought process and functioning of a development team.

왜 스크럼을 사용합니까?

스크럼 프레임워크 자체는 간단합니다. 규칙, 아티팩트, 이벤트 및 역할은 이해하기 쉽습니다. 스크럼 프레임워크의 반쯤 규범적인 접근 방식은 실제로 개발 프로세스의 모호성을 없애는 데 도움이 되며 회사가 개별적인 특성을 적용할 수 있는 충분한 여력을 제공합니다.

어려운 프로젝트에서 복잡한 작업을 관리 가능한 사용자 스토리로 구성하는 것은 이상적인 일입니다. 또한 역할과 계획된 이벤트의 명확한 구분은 개발 주기 전반에 걸쳐 투명성과 집단적 소유권을 보장해줍니다. 빠른 릴리스를 통해 짧은 시간 내에 진전을 확인할 수 있으므로 팀에 동기가 부여되고 사용자가 만족합니다.

그러나 특히 개발 팀이 전형적인 워터폴 모델에 익숙한 경우, 스크럼을 완전히 이해하는 데 시간이 걸릴 수 있습니다. 더 작은 반복, 일일 스크럼 회의, 스프린트 검토 및 스크럼 마스터 식별이라는 개념은 새로운 팀에게는 어려운 문화적 변화일 수 있습니다.

그러나 장기적인 이점은 초기 학습 곡선보다 훨씬 큽니다. 다양한 업계 및 업종에 걸쳐 복잡한 하드웨어 및 소프트웨어 제품을 개발하는 데 성공한 스크럼은 조직에서 채택할 만한 매력적인 프레임워크입니다.

Jira Software로 스크럼을 배우려면 이 자습서를 확인하세요.