이전의 직업에서, 각 스프린트의 첫날 (우리는이를 반복이라고 함)을 다음과 같이 취했습니다.

• 회고전. 우리는 마지막 날 오후에 이것을 시작했지만 종종 스프린트에 대해 회고 한 다음 스프린트 작업의 마지막 느슨한 끝을 묶는 작업으로 돌아가는 것을 자주 발견했습니다. 그것을 회고하기 전에 모든 것이 우리 뒤에 있었다. 또한 스크럼 프로세스의 모든 회의 오버 헤드를 통합하여 다른 날을보다 이상적인 용어로 계획하고 사용할 수 있도록하는 것이 논리적으로 보였습니다. 일반적으로 2 시간이 걸렸습니다.
• 스프린트 계획. 백로 그는 마일스톤 계획 회의 (개발자와 PO 모두 하루 종일 가능) 중에 평가되었으며 각 스프린트가 시작되기 전에 PO에 의해 우선 순위가 결정되었습니다. 우리는 얼마나 많은 개발자의 날 (휴일, 휴가 등을 고려한)을 파악하고, 우리가 할 수있는 일을 파악하고, 사용자 요구 사항 (이전에 BA가 심사 한 것)을 신속하게 검토했습니다. MPM 동안의 간단한 개요로 얻은 것보다 작업에 수반되는 내용에 대해 더 완벽하게 이해할 수 있습니다. 일반적으로 2 시간이 더 걸렸습니다.
• 작업 계획. 이야기와 수용 기준을 알면서, 우리는 각 이야기를 이상적인 시간으로 추정되는 한입 크기의 과제로 나 bro습니다. 우리의 포인트 스케일이 교정되는 방식은 5가 개발자 스프린트 였으므로 1은 최대 개발자 2 일을 포함하여 무엇이든 될 수 있습니다. 이러한 이유로 팀원들이 스크럼 보드에 진행 상황을 표시 할 수 있도록 거의 모든 것이 분리되어야했습니다. 이것은 또 다른 2 시간의 블록이었고, 이것과 다음 항목 사이에 약간의 공짜가있었습니다.
• AAT 개요. 우리의 PO와 BA는 프로그래머가 아니었고 코딩도하지 않았습니다. PO는 계약서 뒤에 숨어서 요구 사항을 Word 템플릿 형식으로 제공하고 BA와 협력하여 해당 형식으로 세분화 할 것이라고 규정했습니다. BA는 코드를 이해했지만 시간은 순전히 분석 및 최종 테스트였습니다 (시스템이 있어야하므로 매크로를 셀레늄에 기록 할 수 있음). 따라서 코드가 승인 기준을 충족하는지 확인하려면 “용지”합격 테스트의 동작을 모델링하는 자체 AAT를 작성해야했습니다. 우리는 일반적으로 단위 및 통합 테스트에 사용한 것과 동일한 NUnit 프레임 워크에서이 작업을 수행했습니다 (FitNesse를 사용해 보았지만 충분히 빨리 포기할 수 없었습니다). 이것은 각 스프린트의 첫날의 나머지 날이었고 두 번째 날까지 계속되었습니다.

현재 직장에서 우리는 여전히 Scrum 프로세스를 채택하고 있으며 팀 전체의 마일스톤 계획이 없었으며 현재 진행중인 많은 작업에는 엄격한 승인 기준이 없습니다. 따라서 스프린트 계획은 각 스토리에 수반되는 내용과 우리가해야 할 일에 대한 설명입니다. 이는 최고의 X 이상 근무 시간을 최고 수준으로 끌어 올리 겠다는 약속입니다. 우리는 사내 팀이기 때문에 지금 당장 그것을 피해 갈 수 있습니다. 우리 각자는 소프트웨어의 최종 사용자와 개인적으로 협력하여 요구 사항과 디자인 솔루션을 수집합니다. 그럼에도 불구하고 스프린트 계획은 매주 월요일마다 아침마다 일어나며 오후에는 화요일에 본격적으로 개발을 시작할 수 있도록 개인적인 장애물을 없애는 데 소비됩니다.

오래 걸리지 않아야한다는 다른 의견 / 응답을 대조하기보다는 실제로 OP의 질문에 대답하기 위해, 사용하는 것보다 조금 더 흥미로운 애자일 추정, 스프린트 계획 및 회고에 접근하는 방법이 있습니다.

귀하의 우려를 구체적으로 해결하십시오.

• 회의 시간 이 길다 . 회고, 스프린트 계획, 과제 분석 등 각 회의는 명확한 목적과 토론 주제를 가져야하며 가능한 한 정해진 시간으로 제한되어야합니다. 이러한 회의를 주제로 유지하고 시간 목표를 달성하기 위해 계속 진행하는 것이 Scrum Master의 임무입니다.

• 회의는 단조롭습니다 . 그 중 일부가있을 것입니다. 한 번에 한 입 크기의 덩어리로 작업하므로 동일한 작업을 반복해서 수행하게됩니다. 팀의 집중력을 유지하고 회의의 목적을 달성하기 위해 추진하는 것이 도움이 될 것입니다.

  내가들은 다른 것은 스프린트 계획 회의가 너무 많은 성과를 거두려고한다는 것입니다. 마지막 회사에서 스토리 평가는 “마일스톤 계획 회의”에서 이루어졌습니다.이 회의는 약 1/4 분기에 하루 종일 진행되었습니다. 이러한 회의에서 우리가 추정하지 않은 백 로그에 구축 된 모든 내용은 포인트 단위로 추정되었습니다. 포인트 단위로 스토리 추정을 수행 한 다음 시간 단위로 작업 추정을 수행하는 경우 동시에 같은 날짜에 수행하지 않을 수 있습니다.

• 포인트 단위로 스토리를 추정 한 다음 몇 시간 내에 작업을 수행하는 것은 불필요한 것처럼 보입니다 . 두 가지 목적이 있습니다. 스토리 추정의 목적은 과거의 속도와 예상 대역폭을 기반으로 스프린트 백 로그를 채우는 데 사용할 수있는 대략적인 복잡성을 추정하는 것입니다. 작업 추정의 목적은 이야기를 개발자의 하루 이하로 처리하는 것으로 분류하고 (따라서 한 번에 완료 할 것으로 예상되는 단일 사람에게 할당 할 수 있음) 스프린트에서 씹을 수있는 것보다 많은 이야기의 복잡성을 잘못 추정하거나 물린 것.

  스토리가 모두 하루 이하로 걸리면 중복되지만 모든 포인트 스케일이 동일하게 보정되는 것은 아닙니다. 마지막 직장에서 5는 개발자 주 2 회 (처음에는 많은 서사시가 있었기 때문에 추정치가 많았 기 때문에)는 선형 척도로 최대 2 일 개발자 포인트를 만들었습니다. 이런 종류의 규모가 주어지면 사실상 모든 것이 작업으로 분류되어야합니다. 나의 새로운 회사에서, 개발자의 하루 반이 가까워 지므로 1 또는 2는 확실히 자체 작업이며, 3-8은 팀이 작업으로 분할하도록 강요하는 것과 관련하여 성가시다.

• 사람들의 집중력을 떨어 뜨리는 데 시간 이 걸리는 악순환이 있습니다 . 코딩 할 때와 마찬가지로 휴식을 취하십시오. 30 분마다 5 분씩 다리를 늘리거나 재편성하십시오. 1 시간마다 10 분씩 만들 수는 있지만 회의 시간을 확실하게 초과하지 마십시오. 배가 고프거나 커피가 더 필요하거나 화장실이 필요합니다. 거부하지 마십시오. 당신이 그들을 빨리 게하면 당신은 그들의 마음이 방황을 찾을 수 있습니다. 그 외에도, 토론을 짧고, 달콤하고, 요점까지 유지하면 앞에서 언급 한 것처럼 도움이 될 것입니다.

답변