스크럼의 프로젝트 관리

어떻게 작동하나요?

실제로 이는 전체 프로세스가 지속적으로 최적화되고 고객의 요구에 맞게 조정된다는 것을 의미합니다. 팀 및 제품 의 전체 작업 기간 동안 프로젝트. 관리 책임 제품 개발 는 제품 소유자(PO)와 디자인 팀 사이에 분산되어 있습니다. PO는 제품 개발 방향과 관련된 의사 결정을 내리는 사람으로, 제품이 어떤 제품이 될 것인지에 대한 전체적인 '비전'을 가지고 있습니다. 작업 관리는 칸반 보드를 기반으로 이루어집니다( 스프린트 스크럼 보드라고 하는 기능). 프로세스의 각 참가자는 백로그에 작업을 추가할 수 있지만 우선순위를 설정하는 것은 운영 책임자가 담당합니다. 프로젝트 팀은 PO의 아이디어를 구체적인 작업으로 '변환'하고 구현을 계획할 책임이 있습니다.

주기 과정

이 프로세스는 반복(스프린트)으로 나뉩니다. 약 2주 동안 진행되는 한 번의 스프린트에서 프로젝트 팀은 이전에 계획한 기능의 일부를 구현하고 테스트합니다.

스프린트는 백로그의 맨 위에 있는 PO가 이전에 정리하고 설정한 작업을 팀이 논의하고 준비하는 '계획'으로 시작됩니다. 그 후 이러한 작업의 난이도를 추정하고 난이도에 따라 점수를 부여합니다. 팀 구성과 작업 조건이 비교적 일정하기 때문에 각 스프린트에서 수행한 포인트를 반복해서 확인할 수 있고 향후 작업을 계획할 수 있습니다. 기획 회의가 끝나면 한 스프린트 내에 완료해야 할 총 포인트 수가 있는 과제가 선정되고 새로운 스프린트가 시작됩니다.

스프린트 중간에 그루밍이 진행됩니다. 이 회의에서는 운영자가 팀에 추가 기대치와 아이디어를 제시하고, 프로젝트 팀은 이를 분석하여 더 작은 작업으로 세분화하여 운영자에게 가능한 제안을 제시합니다. 향후 작업을 계획할 때 OP는 분석가, 사용자, UX 및 그래픽 디자이너와 상의합니다. 추가 분석(시장 연구 및 데이터 과학)가 이 단계에서 필요한 경우가 많습니다. 이른바 사용자 스토리를 분석하고 공식화한 후에야 PO는 백로그에 해당 스토리를 게시합니다. 사용자 스토리에는 운영자가 특정 작업 또는 작업 그룹에서 기대하는 바가 무엇이며 작업 완료 여부를 인식하는 데 어떤 기준을 사용해야 하는지에 대한 정보가 포함되어야 합니다.

스프린트 기간 동안 소위 "일일 스탠드업 미팅"이라는 회의가 매일 열립니다. 이 회의에서 각 개발자는 나머지 팀원들에게 지난 하루 동안 자신이 수행한 작업을 공유하고 향후 작업을 방해하는 문제나 봉쇄에 대해 알립니다. 이러한 현황 교환 덕분에 다양한 작업 간의 잠재적인 충돌을 훨씬 빠르게 파악할 수 있고 개발자가 문제에 부딪혀 진전을 이루지 못하는 상황을 피할 수 있습니다. 일일 스탠딩 회의는 가능한 한 짧게 진행하되, 동시에 각자의 역할을 충실히 수행하는 것을 전제로 합니다. 스탠딩 회의의 공식은 팀이 회의 시간을 짧게 유지하도록 장려합니다.

스프린트 동안 작업은 현재 상태에 따라 스크럼 보드에서 이동됩니다. 열의 선택은 일반적으로 회사 또는 팀의 업무 시스템에 해당하며 버전 관리 시스템 및 릴리스 빈도와 관련이 있습니다. 저희의 경우 다음과 같습니다:

• 할 일 - 완료 대기 중인 작업
• 진행 중 - 진행 중인 작업
• 코드 검토 - 다른 개발자의 확인을 기다리는 작업
• 준비됨 - 개발자가 확인하고 수락한 작업
• 스테이징 - 스테이징 인스턴스에 있는 작업으로 PO 승인을 대기 중입니다.
• 수락됨 - PO가 수락한 작업
• 완료 - 프로덕션 인스턴스에 있는 준비된 작업

스프린트가 끝나면 회고회가 열립니다. 이 회의는 업무 최적화를 위한 회의입니다. 팀 전체가 지난 스프린트에서 잘된 점과 개선이 필요한 부분에 대해 논의합니다. 또한 이전 회고를 참고하여 업무 개선을 위한 모든 아이디어를 구현할 수 있었는지 점검하기도 합니다. 회고에서 논의되는 문제는 개발 도구, 압박감, 작업 난이도, 커뮤니케이션 문제(개발자와 팀, PO 간)에 이르기까지 다양합니다.

스크럼 마스터의 책임

스크럼 프로세스의 적절한 수행을 책임지는 사람은 스크럼 마스터입니다. 이 역할은 종종 팀에서 가장 이해하기 어려운 역할입니다. 스크럼 마스터는 의사 결정권이 없습니다. 의사 결정은 팀과 PO가 공동으로 내리는 반면, SCRUM 마스터의 역할은 프로세스의 적절한 진행 과정에서 장애물을 제거하는 것입니다.

스크럼 마스터의 임무는 다음과 같습니다:

• 계획, 그루밍, 일일 스탠드업 회의, 회고 등 SCRUM 회의 진행
• 스크럼 보드의 작업이 팀에 의해 정기적으로 정리되고 PO에 의해 우선순위가 지정되도록 합니다.
• 팀과 PO 사이의 연결고리 역할을 하므로 프로그래머의 언어를 비즈니스 언어로 또는 그 반대로 번역하는 어려운 역할을 하는 것은 종종 SCRUM 마스터입니다. 이는 우리 회사에서 스크럼 마스터가 개발자, 즉 기술자라는 사실 때문입니다. 스크럼 마스터의 작업의 일반적인 프레임워크는 이를 요구하지 않습니다.
• 팀이 회의에서 주제에서 벗어나지 않도록 하고 의제를 지키기
• 주로 회의에서 팀 분위기를 관리합니다.
• 충돌이 발생하면 해결합니다.

또한 읽어보세요:

• 소프트웨어 구축을 위한 코데스트의 모범 사례. 고객 여정에 대한 접근 방식
• 소프트웨어 빌드를 위한 Codest의 모범 사례: GitFlow
• 소프트웨어 구축을 위한 Codest의 모범 사례. 요구 사항 분석은 어떻게 구현하나요?