효과적인 프로젝트 관리가 없으면 팀원들이 최대한 많은 절차를 처리해야 하며 이러한 접근 방식은 성공으로 이어지지 않습니다. Scrum 및 Kanban과 같은 몇 가지 잘 알려진 프로젝트 관리 방법론이 있습니다. 그러나 모범 사례를 결합한 한 가지 방법론이 있습니다. 스크럼과 칸반의 장점은 스크럼반으로 알려진 하이브리드 접근 방식에서 결합됩니다. 빠르고 지속적으로 움직이고 스크럼과 칸반의 제약을 받는 프로젝트에 적합합니다. 이 접근 방식은 충분히 적응할 수 있기 때문에 단기 및 장기 프로젝트 관리 모두에 적용될 수도 있습니다.
스크럼반 방법론이란 무엇입니까?
한마디로 Scrum은 간단하고 반복적이며 프로젝트를 더 작고 관리하기 쉬운 작업으로 분할하는 Agile 접근 방식입니다. 스크럼은 팀 구성원이 당면한 현재 작업에만 집중할 때 따로 시간을 두는 스프린트 아이디어를 소개합니다. 1~4주 범위 내에서 스프린트 기간을 선택할 수 있습니다. 그럼에도 불구하고 2주의 스프린트가 표준입니다. Kanban과 Scrum은 모두 호환성과 단순성으로 유명합니다. 현재 시스템을 업데이트하는 Scrum과 달리 Kanban은 효율성을 높이는 데 집중합니다. Kanban 설정의 일부는 한 눈에 프로젝트 상태를 표시할 수 있는 최소 3개의 기본 열이 있는 Kanban 보드입니다. Kanban은 제한 요소가 시간(스프린트)인 스크럼과 달리 한 번에 너무 많은 것을 수행하여 팀이 과중해지는 것을 방지하기 위해 진행 중인 작업을 제한합니다.
Scrumban은 팀 구성원이 보다 효과적인 프로젝트 관리를 할 수 있도록 지원하는 애자일 방법론 입니다. 처음에는 과도기적인 Scrumban 방법론으로 사용되었습니다. 그러나 Scrumban은 결국 팀원들에게 관심을 얻었고 독립형 기술로 부상했습니다.
Scrumban의 주요 측면
스크럼반에는 구현 및 적응에 관련된 다섯 가지 측면이 있습니다.
- 계획 및 계획 트리거
팀은 과거 성과와 추정치를 바탕으로 스크럼반에서 다가오는 스프린트를 계획합니다. Scrumban 팀은 계획 트리거를 활용하여 다음 반복에 대한 계획을 시작할 시기를 결정합니다. 이 수치는 팀의 계획 회의 후 백로그에 남아 있어야 하는 작업의 수를 나타냅니다.
- 칸반 보드
Scrumban 팀은 Kanban 보드를 사용하여 완료되는 작업을 추적합니다. 그들은 계획, 수행 및 완료된 모든 작업을 추적할 수 있습니다. Kanban 보드는 팀마다 다를 수 있지만 종종 백로그, 프로세스 섹션(프로세스에 따라 열로 분할됨) 및 완료 열로 구성됩니다.
팀 구성원이 백로그에서 자신의 할당을 선택한다는 것을 기억하는 것이 중요합니다. 작업이 끝나면 팀원은 백로그를 살펴보고 자신의 기술 세트에 따라 우선 순위가 가장 높은 작업을 선택합니다. 이것이 바로 보드를 매일 확인하고 필요에 따라 우선순위를 조정하는 것이 중요한 이유입니다.
- 재공품 한도
스크럼반 팀은 일관된 가치 전달을 보장하기 위해 한 번에 작업할 수 있는 작업 항목의 수를 제한합니다. 이를 설명하기 위해 WIP(Work In Progress) 한도가 사용됩니다. 모든 작업 항목의 배달 날짜를 보다 쉽게 예측할 수 있고 각 개별 작업 항목의 배달 속도를 높일 수 있습니다. 이 한도는 종종 팀의 명단 규모에 따라 설정됩니다. 예를 들어, 5명의 팀 구성원이 있는 경우 WIP 최대값은 5입니다. 결과적으로 각 팀 구성원은 한 번에 하나의 작업에 집중할 수 있습니다.
- 계획 버킷
Scrumban 팀에서 사용하는 장기 계획 방법을 계획 버킷이라고 합니다. 팀은 로드맵을 3개의 버킷으로 구성하며, 이는 Kanban 보드의 목록 또는 추가 열일 수 있습니다. 1년 안에 달성하고자 하는 팀의 가장 큰 아이디어와 목표는 첫 번째 버킷에 보관됩니다. 두 번째 버킷에는 팀이 6개월 이내에 실행하고자 하는 보다 명확한 계획이 포함되어 있습니다. 앞으로 3개월 동안의 세부 계획은 세 번째 버킷에 보관됩니다. 계획은 백로그에 추가되고 팀이 계획을 진행하기로 결정할 때 후속 반복에서 수행됩니다.
Scrumban 구현에 대한 궁극적인 가이드
Scrum과 마찬가지로 Scrumban은 전체 프로젝트를 Kanban 보드와 유사하지만 더 많은 정보와 자유를 제공하는 Scrumban 보드에 시각화합니다. Scrumban 보드는 또한 2주의 작은 반복으로 작동합니다. 이 기술은 Kanban 방법론에서 작업 당기기, WIP 제한 및 연속 작업 아이디어를 차용합니다. 일반적으로 스크럼반 주기는 프로젝트 전체에서 각 스프린트에 대해 반복되는 이러한 6단계로 구성됩니다. 단계는 다음과 같이 설명할 수 있습니다.
작업 항목 세분화
모든 스프린트 시간은 다음 반복을 위해 고려해야 할 작업 항목을 결정하는 것을 목표로 하는 작업 항목 구체화로 시작됩니다. 프로젝트 관리자와 기타 이해 관계자가 이 회의에 참여하여 팀의 다음 행동 방침을 결정하는 데 도움이 됩니다. 제안된 작업 항목 중 가장 중요한 항목과 그 이유에 대해 생각하는 것이 중요합니다. 목록에 우선 순위가 지정되면 목록의 각 항목에 대해 수행해야 할 작업을 지정해야 합니다. 따라서 팀이 계획 세션을 위해 함께 모일 때마다 작업 항목을 쉽게 선택하고 작업을 시작하는 데 도움이 됩니다.
계획
Scrumban 팀은 프로젝트가 시작된 후 그리고 주기적으로 예정된 스프린트 시간에 대한 작업을 구성하기 위해 모입니다. 팀은 정제된 제품의 백로그에서 최상위 작업 항목을 선택하고 각 항목의 요구 사항을 자세히 설명하고 각 항목을 완료하는 데 필요한 시간을 계산합니다. 팀이 스프린트 시간에 완료할 수 있는 작업의 수는 제한되어 있습니다.
일일 스탠드업
그룹은 할당된 작업에 착수합니다. 우선 순위에 따라 각 팀 구성원은 백로그에서 작업을 선택합니다. 팀 구성원은 작업을 신속하게 완료하기 위해 한 번에 둘 이상의 작업을 수행할 수 없습니다. 팀은 진행 상황을 측정하고 문제를 식별하기 위해 간단한 스탠드업 회의에서 매일 만나 작업을 평가합니다.
작업 동결, 분류 및 안정화
팀이 시간 제한 스프린트로 작업하거나 프로젝트가 거의 완료되면 프로젝트 관리자는 작업 동결을 구현할 수 있습니다. 결과적으로 팀은 백로그에 새 작업을 추가할 수 없습니다. 그런 다음 프로젝트 관리자는 현재 스프린트 시간 또는 프로젝트 동안 팀이 완료할 프로젝트 관리 항목과 완료되지 않은 상태로 남을 항목을 결정하기 위해 분류를 수행합니다. 작업 동결 및 분류는 확장을 중단하고 수행 중인 작업의 양을 안정화하기로 한 팀의 결정을 나타냅니다.
풀어 주다
팀이 마감 시간을 지키거나 할당된 모든 작업을 완료하면 스프린트 시간이 종료됩니다. 팀은 스프린트 동안 최종 제품을 점진적으로 개선한 다음 릴리스에서 이해 관계자에게 선보이기를 원합니다.
회고
회고는 스크럼반 프로세스의 마지막 단계입니다. 모든 릴리스에서 팀은 작업 절차에 대해 논의하고 잘 진행되었던 사항을 평가하고 다음 주기에 대해 개선해야 할 사항을 결정하기 위해 모입니다. 지금은 프로세스 수정을 도입하고 다가오는 스프린트를 위해 한두 가지 가시적 개선을 약속하기에 좋은 시간입니다.
왜 스크럼반인가?
Scrumban을 사용하는 세 가지 주요 이유는 다음과 같습니다.
- Scrum보다 채택하기 쉽습니다 . Scrumban의 프로세스는 Kanban의 프로세스와 더 느슨하고 유사합니다. 결과적으로 팀은 더 빨리 배우고 적응할 수 있습니다.
- 제품 개발 및 R&D 팀에 탁월합니다 . 빠르게 진행되는 절차는 빠르고 비교적 위험이 없는 개념 테스트를 가능하게 합니다.
- 지속적인 개선 . Scrum 덕분에 팀은 워크플로를 발전시키면서 더 나은 개선 사항을 만들 수 있습니다.
Scrum, Kanban 및 Scrumban의 차이점은 무엇입니까?
- 스크럼 은 구현하기 가장 어렵고 세 가지 옵션 중 가장 엄격한 프로세스입니다. 목표와 기한을 명확하게 정의하고 프로젝트 관리자에게 완전한 권한을 부여하고 빠르게 움직이는 크고 복잡한 프로젝트에 대해 효과적으로 기능하는 스프린트 타임으로 구성됩니다. 너무 많은 회의를 개최하면 시간 제한이 초과될 수 있으며, 이는 다른 효과적인 프로세스에서 불필요하게 시간이 많이 소요되는 부분으로 이어집니다. 또한 숙련되지 않은 팀이 더 많은 결함을 생성하거나 아키텍처를 부적절하게 설계하는 경우가 있습니다.
- Kanban 은 아마도 가장 간단하고 적용 가능한 기술일 것입니다. 프로세스는 Kanban에 초점을 맞추고 작업을 시각화합니다. 이렇게 하면 프로세스를 유연하게 유지하면서 팀의 모든 사람이 같은 페이지에 있는지 확인하고 워크플로 병목 현상을 노출할 수 있습니다. 점수를 공유해야 할 때 Kanban은 덜 유용합니다. 팀의 개별 기여를 추적하려고 할 때 팀 구성원의 삶을 훨씬 더 어렵게 만듭니다.
- Scrumban 은 Scrum에서 제공하는 체계화와 Kanban에서 제공하는 시각화를 활용하여 두 방법론의 장점을 결합합니다. 이것은 자연스럽게 발생하며 불필요한 복잡성을 추가하지 않고 쉽게 조정할 수 있습니다. 따라서 Scrumban은 프로덕션에 충분히 적응할 수 있으며 크고 작은 프로젝트 모두에서 성공합니다.
결론
당신의 노력이 완전히 효과가 없다는 것을 발견하기 위해 무언가를 시도한 적이 있습니까? 우리는 문제에 너무 집중하여 해결하지 못할 수 있습니다. 근본적인 문제를 결정하기 위해서는 측면적 사고와 계획이 필요합니다. 애자일 기법은 완전히 새로운 전략을 채택하여 프로젝트 관리의 근본적인 약점을 해결하려고 했습니다. 스크럼반 기술의 핵심에는 스크럼과 칸반의 모범 사례가 포함됩니다. Scrabman은 프로젝트 관리를 혁신했습니다. 코드가 없는 소프트웨어 개발과 같은 방식으로 변형되었습니다. 코드가 없는 플랫폼을 사용하면 창의적인 사고를 가진 사람이라면 누구나 소프트웨어를 개발할 수 있습니다. 노코드 플랫폼 AppMaster를 사용하면 웹 및 모바일 애플리케이션을 생성할 수 있을 뿐만 아니라 플랫폼에 바인딩되지 않고 가져갈 수 있는 소스 코드를 생성할 수 있습니다.
