스크럼 가이드 | 13. 스크럼 개발팀
게시 됨: 2022-04-25스크럼의 개발 팀은 제품을 만드는 데 관련된 모든 사람들로 구성된 학제 간 그룹입니다. 오늘 기사에서는 어떤 특성을 가져야 하는지 살펴보겠습니다. 또한 목표를 효과적으로 달성할 수 있는 개발팀의 구성과 책임도 고려할 것입니다.
스크럼의 개발 팀 – 목차:
- 개발팀 기능
- 개발팀
- 개발팀의 책임
- 요약
개발팀 기능
스크럼 원칙에 따라 작업하는 개발 팀 은 독립적인 전문가 그룹입니다. 외부 전문가 또는 하청업체의 지원을 사용하지 않습니다. 그러나 팀이 목표를 달성하기 위해 잘 일치한다는 것을 결정하는 것은 무엇입니까? 그리고 전문성에 관계없이 개발 팀의 작업에는 어떤 책임이 포함됩니까?
효과적인 개발 팀이 되기 위해서는 자기 조직화 능력, 성장 추진력, 학제 간 융합이라는 세 가지 특성이 있어야 합니다.
자기 조직화
개발팀이 속한 스크럼팀 을 이야기할 때 '자기관리'라는 용어를 사용합니다. 조직 차원의 자기 관리를 의미합니다. 스크럼 팀 전체는 누가 어떻게 일을 할 것인지 뿐만 아니라 무엇을 할 것인지도 결정합니다. 스크럼 팀에서 관리 작업의 상당 부분은 제품 소유자와 스크럼 마스터에 속합니다.
따라서 개발팀의 경우 자기관리보다 자기조직화가 더 중요하다. 계획 책임, 즉 누가 특정 작업을 언제, 어떻게 수행할지 스스로 결정하는 것을 말합니다.
발전의 추구
효과적인 팀의 핵심 기능은 성장을 위한 추진력입니다. 야심 차기 전에 설정된 작업을 완료하는 방법. 이는 개발팀 구성원 개개인의 성향과 태도 때문만은 아닙니다. 역량과 노력을 키우는 것은 팀 전체를 정의 하는 팀의 분위기 에서도 고무됩니다.
학제간
팀의 학제간 구성은 팀원들이 함께 각 스프린트에서 가치 있는 증분을 생성하는 데 필요한 모든 기술을 보유해야 함을 의미합니다. 이것은 또한 팀의 각 구성원이 해당 스프린트에 필요한 작업을 수행한다는 것을 의미합니다. 모두가 목표를 달성하기 위해 필요한 일을 합니다. 개발자의 전문 지식을 넘어 새로운 작업을 수행하는 것을 의미하더라도. 자신의 전문적 역량이나 역할에 집착하는 것은 실수입니다.
개발팀
스크럼 가이드에 따르면 최대 개발자 수는 8명입니다. 이러한 작은 구성은 팀원들이 서로를 알아갈 수 있는 기회를 갖기 때문에 의사소통과 개방성을 장려합니다 . 단, 팀은 3인 이상이어야 합니다. 각 스프린트에서 비즈니스 가시적인 진전을 이룰 수 있을 만큼 충분히 커야 합니다.
Scrum 내의 개발자 는 다양한 기술과 책임을 가진 사람들이라고 합니다. 어떤 경우에도 프로그래밍을 하는 사람들을 위해 예약된 이름이 아닙니다. 따라서 팀에는 프로그래머와 디자이너, 연구원과 분석가, 테스터와 과학자, 기타 전문가가 포함될 수 있습니다.
개발자들 사이에는 계층 구조가 없습니다. 그것이 그들이 전문적이거나 과학적인 제목을 사용하지 않는 이유입니다.
개발팀의 구성에 대한 중요한 가정은 그것이 하나라는 것입니다. 따라서 다른 목표에 대해 작업하는 소규모 팀이 분리되어서는 안 됩니다.
개발팀의 책임
개발팀의 책임은 세 가지 영역으로 나눌 수 있습니다. 이것들은:
- 계획 작업
- 제품 작업 중
- 팀 내 협업 개선
계획 작업
작업 스케줄링은 모든 스크럼 기반 개발 팀이 이행해야 하는 의무입니다. 그것은 스프린트 계획을 만들고 그것을 스프린트 백로그에 넣는 것으로 구성되며, 이는 별도의 기사에서 설명할 것입니다. 가장 중요한 것은 개발팀이 함께 작업한다는 것입니다. 이러한 방식으로 각 개발자는 주어진 스프린트에서 수행할 작업의 수를 현실적으로 결정할 수 있습니다. 장기적으로 이를 통해 팀은 일정한 속도를 유지하고 보다 정확하게 계획할 수 있습니다.
맥박을 주시하는 것, 즉 매일 계획을 현실에 맞게 조정하는 것도 마찬가지로 중요합니다. 문제가 발생하면 변경해야 할 수도 있습니다. 작업을 재구성하거나, 작업을 다르게 분배하거나, 새로운 어려움에 대해 스크럼 마스터와 이야기하십시오.
제품 작업 중
제품 작업의 형태는 주어진 개발 팀이 운영하는 영역에 따라 크게 다를 수 있습니다. 일반적으로 각 스프린트에서 달성해야 하는 목표는 증분, 즉 비즈니스 가치가 있는 제품 기능을 만드는 것입니다.
여기서 직접 말하고 다음 규칙을 적용하는 것이 유용합니다.
제품에 대한 작업을 수행할 때 이전 버전보다 개선되었을 뿐만 아니라 덜 완성된 상태로 남겨두어야 합니다.
이 원칙을 적용한다는 것은 팀 전체가 증분에 대한 책임을 진다는 것을 의미합니다. 개발자가 부주의하게 작업을 수행하여 제품의 품질이 저하되면 다른 사람이 작업을 수행해야 합니다. 반면에 개발자가 제품에서 버그를 발견하면 스스로 수정하거나 버그 정보를 할 수 있는 사람에게 전달해야 합니다. Sprint 내에서 Product Increment 작업에 대한 자세한 내용은 별도의 기사에서 작성하겠습니다.
팀의 협업 개선
팀이 운영되는 방식을 연구하는 것은 개별 개발자의 효율성과 효율성을 지속적으로 개선하는 것입니다.
그러나 그것은 또한 또는 무엇보다도 개발자 간의 의사 소통에 관한 작업입니다. 개선은 효율적이고 정확한 작업 분할을 가능하게 하는 솔루션을 찾는 것으로 구성됩니다. 또한 기술을 연습합니다.
- 사람이 아닌 솔루션을 비판 하십시오. 작업을 설명하는 데 사용하는 언어를 변경하면 태도가 바뀌고 협업이 향상됩니다.
- 당신의 아이디어로부터 거리를 두기 - 유머와 더 정직한 피드백을 가능하게 합니다.
- 신뢰 구축 - 신뢰 덕분에 환경의 부정적인 반응에 대한 두려움 없이 개발자가 제안하는 더 많은 혁신적인 아이디어가 있을 수 있습니다.
팀 협업 개선은 이 기사에서 설명하는 스크럼 이벤트 동안 팀이 작동하는 방식에 대한 지속적인 반성과 피드백 제공을 통해 달성됩니다.
요약
오늘 기사에서는 스크럼 개발 팀의 특성, 구성 및 책임에 대해 설명합니다. 학제 간, 자기 조직화 및 개발에 대한 열망 이 이 작은 팀의 특징입니다. 그리고 팀 작업의 지속적인 개선과 제품에 대한 효과적인 작업 – 이는 모든 개발 팀이 수행해야 하는 작업입니다.
콘텐츠가 마음에 들면 Facebook, Twitter, LinkedIn, Instagram, YouTube에서 바쁜 꿀벌 커뮤니티에 가입하십시오 .
스크럼 가이드:
- 기본 용어, 역할 및 개념의 용어집
- 스크럼이란?
- 스크럼 값
- 회사에서 스크럼을 구현하는 방법은 무엇입니까?
- 스크럼 팀 - 무엇이며 어떻게 작동합니까?
- 제품 소유자는 누구입니까?
- 제품 소유자의 가장 일반적인 실수
- 스크럼 마스터는 누구인가?
- 좋은 스크럼 마스터의 특징
- 스크럼 마스터의 가장 흔한 실수
- 스크럼 마스터가 추적해야 하는 통계 및 메트릭은 무엇입니까?
- 제품 소유자와 스크럼 마스터 간의 협력
- 스크럼 개발팀
- 개발자의 가장 흔한 실수
- 스크럼 아티팩트
- 스케일링 스크럼
- 스프린트 백로그
- 제품 백로그란 무엇입니까?
- 사용자 스토리란 무엇입니까?
- INVEST로 최고의 사용자 스토리 만들기
- 가장 흔한 사용자 스토리 실수
- 사용자 스토리 수락 기준
- 스크럼의 추정 및 스토리 포인트
- 계획 포커
- 팀 평가 게임
- 증분 정의
- 스크럼 이벤트
- 스크럼에서 스프린트란?
- 스크럼 팀 약속 - 제품 목표, 스프린트 목표 및 완료의 정의
- 번다운 차트란 무엇입니까?
- 번다운 차트를 만들고 해석하는 방법은 무엇입니까?
- 번다운 차트의 장점과 단점
- 스크럼과 스크럼반의 칸반 보드
- 스크럼의 속도 - 개발 팀의 속도
- 일일 스크럼
- 스프린트 계획
- 스프린트 리뷰
- 스프린트 회고란 무엇입니까?
- 스프린트 회고 중 일반적인 실수
- 제품 백로그 육성