스크럼 소개

스크럼의 개념은 스포츠, 더 정확하게는 럭비에서 IT 세계로 들어왔습니다. 현재 이는 소프트웨어 개발 및 지원에 있어 보다 유연하고 효과적인 방법론 중 하나입니다. 시간 관리 원칙을 바탕으로 구축된 스크럼 방법론은 개발 프로세스의 품질 관리를 강조합니다. 스크럼 방법론의 핵심은 하나의 큰 작업이 여러 개의 작은 작업으로 나뉘어 짧은 시간 내에 하나씩 완료된다는 것입니다.

스크럼의 역할 분배

방법론의 구조를 좀 더 자세히 살펴보겠습니다. 따라서 여기서 주요 구성 요소는 스크럼 팀(보통 7~9명으로 구성)입니다. 자바 프로그래머, 테스터, 분석가 등 다양한 분야의 전문가들로 구성된 그룹입니다. 팀은 제품 개발에 전적으로 참여하며 결과에 대해 전체적으로 책임을 집니다. 고품질 최종 제품에 관심이 있는 고객 또는 그의 대리인인 제품 소유자(제품 소유자)가 있습니다. 이 사람은 제품의 모양과 작동 방식을 알고 있으므로 팀의 작업 우선 순위를 지정합니다. 제품 소유자의 주요 차이점은 팀에서 일하지 않고 팀과 함께 일한다는 것입니다. 스크럼 마스터는 경험이 풍부한 직원이자 팀의 일종의 팀 리더입니다. 그는 다른 팀원을 조직하고, 불분명한 문제를 이해하도록 돕고, 회의를 개최하고, 스크럼 원칙을 준수하도록 보장합니다. 여기서 중요한 점은 마스터가 보스의 동의어가 아니라는 것입니다. 아니요, 스크럼 마스터는 작업을 전달하지 않으며 최종 결정도 내리지 않습니다. 이 모든 작업은 팀원이 수행하며 마스터는 팀원만을 지원합니다.

스크럼 작동 방식

전체 소프트웨어 개발 프로세스는 짧은 기간(스프린트)으로 나뉩니다. 스프린트 기간은 일주일에서 한 달까지 가능합니다. 각 스프린트가 시작될 때 제품 소유자가 주최하는 회의에서 작업이 설정됩니다. 다음은 계획입니다. 팀은 가장 시급한 작업을 선택하고, 참가자가 주어진 시간 내에 무엇을 달성할 수 있는지 평가하고, 참가자에게 작업을 분배합니다. 모든 근무일은 스크럼(회의)으로 시작됩니다. 각 팀원은 "내가 이미 무엇을 했는가?", "오늘 무엇을 할 것인가?", "작업 완료를 방해할 수 있는 것은 무엇인가?"라는 3가지 질문에 답합니다. 이러한 회의를 통해 참가자들은 진행 상황을 평가하고 적시에 발생하는 어려움을 해결합니다. 스프린트가 끝나면 각 참가자가 자신의 진행 상황이나 특정 작업을 완료하지 못하게 된 요인에 대해 보고하는 종료 회의도 있습니다. 기본적으로 그들은 2가지 질문에 답합니다: "지난 스프린트에서 잘한 것은 무엇입니까?", "다음 스프린트에서 개선해야 할 점은 무엇입니까?"

스크럼 방법론의 장점과 단점

이 방법론의 장점은 유연성과 적응성입니다. 언제든지 제품의 내용을 변경하거나 다른 기능을 추가할 수 있습니다. 스크럼은 고객 자신이 원하는 것이 무엇인지 완전히 알지 못할 때 매우 편리합니다. 또한 이 방법은 최소한의 기능으로 빠른 시작이 필요한 대규모 프로젝트에 적합합니다. 따라서 주요 기능이 포함된 프로그램을 출시하고 이후 스프린트마다 새 기능을 추가하는 것으로 나타났습니다. 스크럼의 또 다른 장점은 각 프로젝트 참가자의 독립성과 자체 조직화입니다. 관리자 비용을 절약하고 팀원 간에 돈을 나눌 수 있습니다. 하지만 이 경우 인사 선발에 상당히 많은 관심을 기울인다. 그리고 이 방법론의 가장 불쾌한 단점은 불확실성입니다. 스프린트 횟수는 무제한이므로 프로젝트 종료 날짜를 설정하기가 어렵습니다. 따라서 스크럼은 정부 명령이나 지원팀의 업무 등 중간 가치 없이 최종 결과만 중요한 프로젝트에는 적합하지 않습니다. 물론 스크럼에서 Java 프로그래머의 자기 조직화와 유연성은 좋지만 지식과 실무 기술이 없다면 우리가 어디에 있겠습니까? 놓치고 있는 것 같은 느낌이 드시나요? 그렇다면 javarush.ru 에서 더 빠르게 문제를 해결해 보세요 !