데이터 과학 팀에 권장하는 프레임 워크 또는 방법론은 무엇입니까?
저는 대부분 데이터 과학자와 일부 소프트웨어 엔지니어 및 제품 소유자로 구성된 팀의 스크럼 마스터입니다.
우리 조직은 모든 팀이 Scrum을 사용하여 2 주 스프린트로 작업하기로 결정했습니다. 나는 개인적으로 그것이 효과가 있다고 믿지 않는다. 스크럼 프레임 워크는 다음과 같은 이유로 우리에게 실제로 작동하지 않습니다.
- 미지의 수준이 크기 때문에 추정하기가 매우 어렵습니다. 예를 들어, 실험을 실행하기위한 백 로그 항목이있을 수 있으며 출력은 일반적으로 매우 다양 할 수 있습니다. 실험의 결과는 말 그대로 앞으로 며칠 동안 작업을 주도합니다.
- 팀을 스토리로 나눌 수 있다고하더라도 스토리 간에는 많은 종속성이 있습니다. 그것은 순서도 또는 의사 결정 트리와 비슷하며 스토리 맵과 비슷합니다.
- PO와 SM은 데이터 과학자가 아니며 스토리의 내용을 실제로 도울 수 없습니다.
- 위의 이유 때문에 스프린트 약속은 거의 끝나지 않습니다.
- 팀은 엔지니어와 같은 방식으로 커뮤니케이션하지 않습니다. 그들은 토론하고 가설을 세우는 데 많은 시간이 필요합니다 (즉, 스크럼이 의도 한 바가 아닙니다). 적어도 이것은 제 경험입니다.
- 작업의 알 수없는 특성으로 인해 계획 회의가 다루기 어려워집니다.
데이터 과학 팀에 권장하는 프레임 워크 또는 방법론은 무엇입니까?
답변
Scrum이 무엇인지 ( Scrum Guide에 정의 된대로 )와 Scrum 과 널리 연관되어있는 것을 구별 할 가치가 있습니다.
예를 들어, 스토리 포인트, 스토리, 추정, 속도 등은 스크럼 가이드의 일부가 아닙니다.
팀은 엔지니어와 같은 방식으로 커뮤니케이션하지 않습니다. 그들은 토론하고 가설을 세우는 데 많은 시간이 필요합니다 (즉, 스크럼이 의도 한 바가 아닙니다). 적어도 이것은 제 경험입니다.
다시 말하지만, 스크럼 가이드에는 토론하고 가설을 세우는 데 많은 시간을 소비하지 않는다는 내용이 없습니다. 프레임 워크가 실제로 말하는 것보다 스크럼 규칙에 대해 이야기하고 있습니다.
저는 스크럼 프레임 워크를 사용하는 데이터 과학 팀과 함께 일했고 그들은 그들의 작업에 대해 논의하는 데 엄청난 시간을 보냈습니다.
작업의 알 수없는 특성으로 인해 계획 회의가 다루기 어려워집니다.
그렇다면 동기화에 더 많은 시간을 투자하고 계획에는 더 적은 시간을 할애하는 것이 좋습니다. 스크럼과 같은 프레임 워크의 가치는 팀이보다 협력적인 방식으로 협력하여 필요한 경우 서로를 지원하도록 돕는 것입니다.
질문에 답하기 위해 Scrum과 Kanban 모두 데이터 과학 팀과 협력하도록 만들 수 있습니다. 프레임 워크의 선택은 일반적으로 팀 구성원의 성격 유형, 조직의 특성 및 작업중인 도메인 유형에 따라 결정됩니다.
나는 추측하고 있지만 여기서 문제는 팀이 작업 방식을 제어하기보다는 그들에게 접근 방식을 적용하고 있다는 것입니다. Scrum의 회고 및 검사 및 적응주기는 팀이 적절한 접근 방식을 찾을 때까지 작업 방식을 조정할 수 있도록하기위한 것입니다.
칸반, 즉 타임 박스 스프린트보다는 관리 흐름은 당신이 언급 한 정확한 이유 때문에 연구와 발견 작업에 많은 의미가 있습니다. 팀의 관리 책임을 유지하기 위해 메트릭 및 상태보고를 계속 생성 할 수 있지만 예상 및 반복보다는 우선 순위 지정 및 지속 가능한 제공에 초점을 맞추는 것이 아이디어입니다. 언급 한 문제의 종류를 입증 할 수 있다면 이에 대한 좋은 사례를 만들 수 있습니다.
또한 효율적인 지속적 통합 파이프 라인을 갖추고 있는지 확인하십시오. 필요한만큼 자주 릴리스 할 수 있다면 모든 기대치를 1 주 또는 2 주 단위로 설정할 필요가 없으면 모든 사람이 이깁니다.
정해진 시간이없는 '가설'과 만남이 많다면 아직 작업의 범위가 명확하지 않다는 점이다. 범위가 확고 해지고 일정이 준비되었지만 새로운 요구 사항이 다가 오거나 변경되거나 회의가 지연되는 경우-우선 순위를 낮추고 자하는 경우 고객이 트레이드 오프 옵션으로 지연을 강조하면서 이미 합의 된 범위에 대해서만 작업을 진행합니다. 한 기능이 다른 기능에 유리합니다.
SAFe 프레임 워크 (https://www.scaledagileframework.com/# 과 https://www.guru99.com/scaled-agile-framework.html)-다른 응답자들이 이전에 언급 한 것 위에 강조 표시 할 수 있습니다. 러시아에서 진행된 전문 컨퍼런스의 많은 연사들로부터이 프레임 워크는 '실험실'에서 사용되는 것처럼 여러 번 강조되었습니다 (이 용어는 아직 잘 알려지지 않은 영역의 제품 개발에 초점을 맞춘 중대형 팀의 이름을 지정하는 데 사용됨) 우리로). 에픽-> 기능-> 사용자 스토리 흐름. '당신의 PO는 주제 분야의 전문가가 아닙니다'라고 언급했듯이 '스토리 사이에는 엄청난 수의 의존 관계가 있습니다. 그것은 순서도 또는 의사 결정 트리, 그 다음 스토리 맵과 비슷합니다. 'SAFe는 E2E 값에 대해 개인적으로 책임을지는 기능 및 기능 소유자를 가지고 있기 때문에 잠재적으로 사용하기에 적합하다는 것을 알았습니다. 비즈니스 가치 + 코드를 제공 할 수 있습니다.
SAFe의 분해는 다음과 같습니다 : Epic-> Architectural sub-epic (그런 다음 Feature (s)로 분류되며, Stories로 분할되고, 차례대로 Task로 분할 됨) + Business sub-epic (그런 다음 Feature ( s), 스토리로 분할되고 차례대로 태스크로 분할 됨).
내 개인적인 경험 (대기업 프로젝트의 비즈니스 분석가, 단계 중 하나에서 SAFe와 유사한 기능 기반 접근 방식을 사용하여 몇 가지 시나리오가로드 된 주제에 대한 비즈니스 가치 제공에 집중했습니다). Feature 는 제품의 구성 요소가 가장 영향을 많이받는 비즈니스 분석가 (일명 '비즈니스 소유자'-E2E 및 특히 비즈니스 가치에 대한 책임)와 개발 책임자 (일명 '기술 소유자')가 모든 스토리, 즉 E2E의 개발을 조율합니다. 기능 내). 한편 '사업주'는 '기술자'가 소유 한 구현 결과에 의존하며, '사업자'는 어쨌든 주된 것이며,최종적으로 고객 (귀하의 경우와 같이 외부 또는 내부 전체 제품 소유자)에게이를 시연하고 피드백을 수집합니다.기능 아래의 비즈니스 스토리는 각각 비즈니스 분석가가 소유합니다 (특정 시나리오, 즉 기능 분해에 따른 기능에 대한 책임). 비즈니스 스토리가 설명되고 눈에 띄는 E2E 또는 그 일부가 있으면 기술 스토리 소유자 / 팀을위한 시작이 준비됩니다. 기능의 기술 이야기, 각각은 개발 책임자가 소유합니다 (특정 시나리오, 즉 기능 분해에 따른 기능 담당).보고를 단순화하기 위해 DEV 팀은 기술 기능-> 기술 이야기를 미러링하고 비즈니스 스토리의 ID에 대한 링크를 유지합니다. JIRA). 기술 스토리가 구현되고 가시적 인 E2E 또는 그 일부가 있으면 비즈니스 스토리 소유자 / 팀을위한 데모가 준비됩니다. 이 접근 방식에서 '기능'이 더 관련성이 높은 용어이므로 에픽을 강조하지 않았습니다. 요약 : 장점 : 개인적 참여와 개인적 책임. 단점 : 비 기술적 '사업주'의 기술 작업을 주시하기위한 오버 헤드.