스크럼 마스터는 어떻게 제어 불능 제품 소유자를“관리”합니까? [닫은

Question

나는 스크럼을 처음 접했고 스프린트 뒤의 팀 개념을 이해하는 동안 소프트웨어 개발에 참여하지 않은 제품 소유자의 간섭을 최소화하는 팀의 수호자가 여전히 필요하다고 생각합니다. 당신의 성공은 무엇이며 어떤 공포 이야기를 살았습니까?

업데이트:

비즈니스 프로세스를 구현하기 위해 코딩과 클라이언트를위한 적절한 아키텍처를 만드는 것 사이의 균형을 찾고 있습니다. 제품 소유자가 사업부에서 온 경우 데이터 모델 등에 어떤 시간을 소비 해야하는지에 대한 지침이 있어야합니다.

정의:

"제어 불능"제품 소유자는 일반적으로 해당 추정치를 만들 수있는 실제 기술적 능력이 없지만 적극적으로 시간 프레임을 설정하는 비즈니스 부서의 일부를 의미합니다. 일반적 으로이 사람은 다음과 같이 말할 것입니다. "다음 주에 운영위원회와의 다음 회의 전에 해당 화면이 필요하므로 먼저 해당 작업 제품을 우선 순위를 정합니다. 운영과 대화 한 후에 데이터베이스를 다루겠습니다."

모두에게 큰 대답. 좋은 입력에 감사드립니다.

Answer 1

"데이터 모델 등에 어떤 시간을 소비 해야하는지에 대한 지침이 있어야합니다."

오른쪽. 그것이 우선 순위가 전부입니다. 작업을 정의하고 우선 순위를 정합니다. 당신은 우선 순위에 따라 일합니다.

무엇이 통제 할 수 없습니까?

1. 작업이 완료되기 전에 작업을 재정의 하시겠습니까?

2. 작업이 완료되기 전에 우선 순위를 재정의 하시겠습니까?

솔루션은 동일합니다. 작업을 작은 조각으로 나누면 변화를 일으킬 기회가 있기 전에 무언가가 끝나십시오.

짧은 (2 주) 스프린트가있는 경우 통제 할 수 없습니다. 약간 더 실용적인 4 주간의 스프린트를 가면 문제가 될 가능성이 적습니다.

Answer 2

책임은 스크럼에서 매우 명확하게 정의됩니다. 제품 소유자는 백 로그 항목을 정의하고 우선 순위를 정합니다. 개발자는 스프린트에서 할 수있는 일을 약속합니다.

따라서 제품 소유자는 추정치를 설정할 권한이 전혀 없습니다. 물론 그는 여전히 특정 시점에 무언가가 필요하다고 말할 수 있습니다. 하지만 여전히 개발자가 ~할 수 있다 완료됩니다. 그리고 그것이 할 수 없다면, 그들은 PO의 요구를 최대한 최대한 성취하기 위해 범위를 바꾸는 방법이나 다른 일을 할 수있는 모든 일에 대해 함께 운동해야합니다.

이제, 이것이 원활하게 작동하지 않는 상황에서 SM이 정확히 어떻게 행동 해야하는지는 특정 상황에 크게 의존합니다. 차라리 그가 PO와 팀 사이의 좋은 관계와 의사 소통 문화를 촉진하는 것을보고 싶습니다. 방패 그러나 PO의 팀.

Answer 3

제품 소유자는 모호하거나 다양한 고객 요구 사항에서 벗어나는 사람이어야합니다.

제품 소유자는 추정치를 제공해서는 안됩니다.

Answer 4

나는 그것이 "통제 불능"의 문제라고 생각하지 않습니다.

"다음 주에 운영위원회와의 다음 회의 전에 해당 화면이 필요하므로 먼저 해당 작업 제품을 우선 순위로 바꾸어야합니다. 운영과 대화 한 후에 데이터베이스를 다루겠습니다."

그 진술에는 본질적으로 잘못된 것이 없습니다 그 자체로. 앱이 올바르게 추상화되면 DB는 어쨌든 별도입니다. UI의 첫 번째 주요 문제는 더 심리적입니다. 비 DEV는 대부분의 작업이 화면을보고 "속도가 느려질 때"라면 Bonkers가 수행된다고 가정합니다. 그러나 여기에 당신의 실제 문제가 다음과 같습니다.

제품 소유자로 표시된 사람은 제품을 소유하고 있지 않으므로 충분한 책임을지지 않습니다.

제품은 전부의 "기능적 요구 사항"(용어를 빌리기 위해)뿐만 아니라 사물. SM은 앉아 있어야하며 PO가 달성해야 할 장면의 범위를 이해하지 않아도 될 필요가 없다고 단호해야합니다. PO가 전체 범위를보기 시작하면 실제로 더 넓은 이해 관계자 커뮤니티의 대표자가 될 수 있습니다.

궁극적으로 SM은 시행 프로세스를 담당하는 사람입니다. 그들은 그렇게 행동해야합니다.

Answer 5

나는 두 개의 다른 상점에서 Agile을 사용했습니다. 두 번 모두 잘 작동합니다. 통제 불능이 어떤 것이 시스템을 망칠 수 있는지 알 수 없습니다. 스프린트 전에, 당신은 당신이 할 모든 작업을 계획하고 그들이 얼마나 오래 걸릴지 추측합니다 (항상 반올림). 그런 다음 스프린트 중에 얼마나 많은 작업을 수행 할 수 있는지 알 수 있습니다.

대부분의 상점은 4 주간의 스프린트와 하루에 6.5 시간의 실행 가능한 시간을 사용합니다. 스프린트가 설정되면 새로운 작업을 도입하지 않으며 스프린트에 들어가는 계획되지 않은 작업 만 추가하는 기능에서 버그를 수정하는 것입니다. 물론 추측 시간에 포함될 것이라고 가정합니다.

보다 구체적인 답변을 원한다면 "제어 불능"제품 소유자가 의미하는 바를 정의해야합니다.

Answer 6

할 말이 두 가지 있습니다.

아마도 당신은 아마도 일종의 R & D 관리자가있을 것입니다 (반드시 스크럼 마스터는 아닙니다). 제품 소유자가 아닙니다).

이 사람은 개발자를 "보호해야한다"고 생각합니다. 우리는 그런 남자가 있었을 때 상황에 있었고, 그것은 꽤 잘 작동했습니다. 그는 예를 들어 백 로그에서 비 기능적 물건을 얻는 데 도움을주었습니다.

이제 우리는이 사람이 없습니다. 우리의 관리자는 Scrum Master입니다. 그리고 그는 우리를 보호하는 것도 꽤 잘합니다. 그러나 ... 여기서 문제는 일반적인 스크럼 마스터가 공식적인 힘이 없다는 것입니다. 그래서 그는 "당신은 이것을 많이 압박하지 않을 것입니다"라고 말할 수는 없지만, 물론 그는 Teem이 도움이 필요하다는 것을 알면 이야기해야합니다.

팀 자체와 제품 소유자는 시간이 지남에 따라 진화하여 서로를 더 많이 돌보기 시작합니다. 제품 소유자는 팀이 더 많은 노력을 기울이지 않거나 "지금은 기능하지 않는 물건을 위해 시간이 필요하다"고 말합니다.

그러나 다시 - 다시 - 주된 책임이 개발자를 돌보는 별도의 R & D 관리자가 있다면 좋다. 그러면 더 균형을 잡을 것이다.

또한 지원 업무를 위해 개발자를 빌리는 지원 부서가 있습니다. 때로는이 고객이나 그 고객을 위해 무슨 일이 일어나지 않을지 동의하기가 어렵습니다 (지원이 모든 것을 원하기 때문에). 이 경우 R & D 관리자 - 아주 좋은 아이디어도 ..

이상적으로, 나는 개발자가 관리자 나 방패가 필요하지 않도록 아이디어가 완전히 몸을 기울이는 것을 좋아하지만 ... 나는 그것이 어떻게 작동하는지, 어떻게 작동하는지 모르겠습니다 ... :)

Answer 7

나는 S. Lott에 동의합니다. 짧은 스프린트가 더 좋습니다. 짧은 사용자 이야기가 도움이 될 수 있습니다. 우리는 사용자 스토리를 최대 2-4 일로 제한하려고합니다.

1. 모든 사용자 스토리가 잘 정의되어 있고 소유자가 동의하는지 확인하십시오.

2. 스프린트가 시작되면 새로운 작업을 현재 스프린트에 추가 할 수는 없지만 다음 스프린트에서는 우선 순위가 높을 수 있다고 주장합니다. 짧은 스프린트가 훨씬 쉬워집니다.

3. 또한 인공 마감일의 부과를 제거하기 위해 가능한 경우 다음 스프린트가 시작될 때까지 현재 스프린트에서 품목을 전달해서는 안됩니다.

민첩한 발전에있어 가장 어려운 부분은 징계입니다. 훈련 된 팀과 스크럼 마스터가 있으면 사용자는 익숙해지고 일이 훨씬 매끄럽게 움직입니다. 프로젝트 관리에 소프트웨어를 사용하는지 확실하지 않지만 랠리를 살펴보십시오. 그들은 지난 1 년 동안 큰 개선을 해왔습니다.

Answer 8

반복 중에 반복 (Sprint in Scrum) 범위는 반복 중에 변경되어서는 안됩니다. 그렇기 때문에 한 번에 하나의 반복이 계획된 이유입니다. S. Lott가 지적했듯이 반복이 짧을수록 제품 소유자는 새로운 것을 계획 할 수 있습니다.

스크럼 마스터 역할은 팀을 그러한 압력에서 분리하는 것이며, 새로운 요청이 다음 반복을 기다려야한다고 제품 소유자에게 말해야합니다.

이제 제품 소유자의 역할은 팀이 생산하는 작업의 가치를 최대화하는 것입니다. 따라서 현재 반복의 끝을 기다릴 수없는 새로운 최상위 항목이 있으면 품목을 교체 할 수 있습니다. 비슷한 견적으로 그리고 시작되지 않았습니다. 이것은 규칙이 아니라 예외 여야합니다.

Answer 9

명확하게 정의 된 참여 규칙을 고수하면 (SM)는 팀을 이끄는 시간을 보낼 수 있습니다.

Answer 10

애자일 팀은 개발자, 비즈니스 분석가, 테스터, DBA, 스크럼 마스터 및 제품 소유자로 구성됩니다.모두 하나의 기능 기반 팀으로 일하고 있습니다.

민첩한 방법론은 비즈니스가 더 빠른 제품 개발을 가속화하는 데 도움이됩니다. 제품 소유자는 우선 순위를 정의하고 우선 순위를 변경할 수 있습니다. 실제로 (SME, 개발자, 디자이너, 테스터… 그리고 작은 사용자 이야기. Scrum Team이 Sprint 내에서 수행 할 수 없다고 생각되면 사용자 스토리의 작은 덩어리로 나뉘어져야하며 개발과 관련된 스택 추적을 기반으로 추정해야합니다.

즉, 제품 소유자 (PO)가 특정 사용자 스토리를 먼저 완료해야하지만 해당 스토리가 여러 변경 사항 (예 : 데이터베이스를 포함한 백엔드 및 백엔드)이 포함되어 있으면 한 스프린트에서 완료 할 수없는 경우 SCRUM 팀은 다음과 같은 주요 규칙을 따를 수 있습니다.

중요 요소들 :

• 스택 트랙을 기반으로 하위 사용자 스토리로 나눕니다
• 이와 관련된 각 사용자 스토리를 추정하십시오
• Scrum Master는 팀 현재 팀 Velocity를 기반 으로이 사용자 스토리를 마치기위한 타임 라인에 대해 제품 소유자에게 알려야합니다.
• 제품 소유자는 스프린트 내에서 완료 할 수 없으므로 타임 라인을 이해할 수있을 정도로 성숙해야합니다.

• 여전히 PO가 우선 순위에 문제가있는 경우 스크럼 마스터/코치와 상담 할 수 있습니다.

  한눈에, Agile은 비즈니스를 돕기위한 것이지만 스크럼 팀을 과부하시키지 않도록주의해야합니다. 반복 개발을위한 정기적 인 프로세스이므로.