데이터 과학 팀에 권장하는 프레임 워크 또는 방법론은 무엇입니까?

Nov 25 2020

저는 대부분 데이터 과학자와 일부 소프트웨어 엔지니어 및 제품 소유자로 구성된 팀의 스크럼 마스터입니다.

우리 조직은 모든 ​​팀이 Scrum을 사용하여 2 주 스프린트로 작업하기로 결정했습니다. 나는 개인적으로 그것이 효과가 있다고 믿지 않는다. 스크럼 프레임 워크는 다음과 같은 이유로 우리에게 실제로 작동하지 않습니다.

  • 미지의 수준이 크기 때문에 추정하기가 매우 어렵습니다. 예를 들어, 실험을 실행하기위한 백 로그 항목이있을 수 있으며 출력은 일반적으로 매우 다양 할 수 있습니다. 실험의 결과는 말 그대로 앞으로 며칠 동안 작업을 주도합니다.
  • 팀을 스토리로 나눌 수 있다고하더라도 스토리 간에는 많은 종속성이 있습니다. 그것은 순서도 또는 의사 결정 트리와 비슷하며 스토리 맵과 비슷합니다.
  • PO와 SM은 데이터 과학자가 아니며 스토리의 내용을 실제로 도울 수 없습니다.
  • 위의 이유 때문에 스프린트 약속은 거의 끝나지 않습니다.
  • 팀은 엔지니어와 같은 방식으로 커뮤니케이션하지 않습니다. 그들은 토론하고 가설을 세우는 데 많은 시간이 필요합니다 (즉, 스크럼이 의도 한 바가 아닙니다). 적어도 이것은 제 경험입니다.
  • 작업의 알 수없는 특성으로 인해 계획 회의가 다루기 어려워집니다.

데이터 과학 팀에 권장하는 프레임 워크 또는 방법론은 무엇입니까?

답변

4 BarnabyGolden Nov 25 2020 at 18:03

Scrum이 무엇인지 ( Scrum Guide에 정의 된대로 )와 Scrum 과 널리 연관되어있는 것을 구별 할 가치가 있습니다.

예를 들어, 스토리 포인트, 스토리, 추정, 속도 등은 스크럼 가이드의 일부가 아닙니다.

팀은 엔지니어와 같은 방식으로 커뮤니케이션하지 않습니다. 그들은 토론하고 가설을 세우는 데 많은 시간이 필요합니다 (즉, 스크럼이 의도 한 바가 아닙니다). 적어도 이것은 제 경험입니다.

다시 말하지만, 스크럼 가이드에는 토론하고 가설을 세우는 데 많은 시간을 소비하지 않는다는 내용이 없습니다. 프레임 워크가 실제로 말하는 것보다 스크럼 규칙에 대해 이야기하고 있습니다.

저는 스크럼 프레임 워크를 사용하는 데이터 과학 팀과 함께 일했고 그들은 그들의 작업에 대해 논의하는 데 엄청난 시간을 보냈습니다.

작업의 알 수없는 특성으로 인해 계획 회의가 다루기 어려워집니다.

그렇다면 동기화에 더 많은 시간을 투자하고 계획에는 더 적은 시간을 할애하는 것이 좋습니다. 스크럼과 같은 프레임 워크의 가치는 팀이보다 협력적인 방식으로 협력하여 필요한 경우 서로를 지원하도록 돕는 것입니다.

질문에 답하기 위해 Scrum과 Kanban 모두 데이터 과학 팀과 협력하도록 만들 수 있습니다. 프레임 워크의 선택은 일반적으로 팀 구성원의 성격 유형, 조직의 특성 및 작업중인 도메인 유형에 따라 결정됩니다.

나는 추측하고 있지만 여기서 문제는 팀이 작업 방식을 제어하기보다는 그들에게 접근 방식을 적용하고 있다는 것입니다. Scrum의 회고 및 검사 및 적응주기는 팀이 적절한 접근 방식을 찾을 때까지 작업 방식을 조정할 수 있도록하기위한 것입니다.

7 nvogel Nov 25 2020 at 03:00

칸반, 즉 타임 박스 스프린트보다는 관리 흐름은 당신이 언급 한 정확한 이유 때문에 연구와 발견 작업에 많은 의미가 있습니다. 팀의 관리 책임을 유지하기 위해 메트릭 및 상태보고를 계속 생성 할 수 있지만 예상 및 반복보다는 우선 순위 지정 및 지속 가능한 제공에 초점을 맞추는 것이 아이디어입니다. 언급 한 문제의 종류를 입증 할 수 있다면 이에 대한 좋은 사례를 만들 수 있습니다.

또한 효율적인 지속적 통합 파이프 라인을 갖추고 있는지 확인하십시오. 필요한만큼 자주 릴리스 할 수 있다면 모든 기대치를 1 주 또는 2 주 단위로 설정할 필요가 없으면 모든 사람이 이깁니다.

1 elisarea Dec 01 2020 at 21:41

정해진 시간이없는 '가설'과 만남이 많다면 아직 작업의 범위가 명확하지 않다는 점이다. 범위가 확고 해지고 일정이 준비되었지만 새로운 요구 사항이 다가 오거나 변경되거나 회의가 지연되는 경우-우선 순위를 낮추고 자하는 경우 고객이 트레이드 오프 옵션으로 지연을 강조하면서 이미 합의 된 범위에 대해서만 작업을 진행합니다. 한 기능이 다른 기능에 유리합니다.

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 또는 그 일부가 있으면 비즈니스 스토리 소유자 / 팀을위한 데모가 준비됩니다. 이 접근 방식에서 '기능'이 더 관련성이 높은 용어이므로 에픽을 강조하지 않았습니다. 요약 : 장점 : 개인적 참여와 개인적 책임. 단점 : 비 기술적 '사업주'의 기술 작업을 주시하기위한 오버 헤드.