Owner가 관여하고 싶지 않은 소규모 프로젝트에서 Scrum 사용


9

최근에 나는 스크럼에 대해 많이 읽고 배우고 있으며 그것을 많이 좋아합니다. 그러나 솔루션을 모르는 두 가지 시나리오가 있습니다. 따라서 4 명의 웹 개발자 (예 : UI / UX 디자이너)로 구성된 민첩한 팀을 구성하고 싶다고 가정 해 보겠습니다. 이 팀은 스크럼 원칙에 따라 운영됩니다.

처음에는 아파트 임대, 쿠키 판매와 같은 일반인의 소기업을위한 방문 페이지와 같은 프로젝트를 진행하고있을 것입니다. 이러한 고객은 일반적으로 회사를 고용 할 것으로 예상되므로 제품 소유자 역할 (IMHO)로 설정할 수 없습니다. , 그들에게 전체적인 프로젝트 목표를 세부적으로 제시 한 다음, 가능한 한 적은 참여로 (많은 의사 결정을 포함하여) 업무가 완료 될 것으로 기대합니다 (의견으로는 더 중요한 일이 있습니다). 개발자 / 스크럼 마스터 역할에 참여하고 싶다고 가정 해 보겠습니다 (이는 논쟁의 여지가 있지만 팀 구성원이자 스크럼 마스터 인 경우에도 마찬가지입니다). 따라서 단순히 제품 소유자의 역할을 수행해서는 안됩니다. 잘.

내 질문에 대해 : 회사의 사업자 인 경우 단순히 제품 소유자 여야합니까 (이 역할들이 서로를 포함합니까)? 제품 소유자 역할이있는 영업 사원을 고용 할 수 있습니까? 영업 사원이 아닌 숙련 된 개발자라면 더 좋을까요? 똑똑한 움직임 일까? 마지막으로 내 입장에 더 적합한 다른 민첩한 접근 방법이 있습니까?


편집 : 좋은 의견을 보내 주셔서 감사합니다. 의견을 추가하면 모든 추가 정보가 크게 감사하겠습니다.


1
랜딩 페이지를 만들려면 몇 번의 스프린트를해야합니까?
JeffO

JeffO, 나는 당신의 요점을 알고 있지만, 이미 몇 번의 간단한 방문 페이지가 그와 비슷한 것으로 밝혀졌습니다. 준비가되지 않았다면 이전 계획없이 파멸 될 것입니다. 적어도 그것은 내 경험입니다.
Andrej Mohar

답변:


15

나는 당신의 상황이 실제로 매우 일반적이며 많은 고객들이 PO 역할에 필요한 헌신의 수준에 관여하지 않는다고 생각합니다.

"PO 프록시"의 접근 방식은 매우 일반적으로 클라이언트와 대화하고 클라이언트의 요구 사항을 스크럼 팀의 사용자 기록으로 변환하는 회사의 누군가입니다. 물론, 조금씩, 프로세스에 더 많은 실제 클라이언트를 참여시켜야하지만, 이것이 항상 가능한 것은 아니며 클라이언트 유형에 따라 크게 다르므로 "PO 프록시"는 대부분의 시나리오에서 합리적인 솔루션이 될 수 있습니다. .

이 입장에서는 개발자가 아닌 영업 사원이 아닌 고객에게 가장 적합하며 고객의 비즈니스 분야에서 도메인 전문가에게 가장 적합합니다 (동시에 개발자 또는 영업자가 될 수 있지만 그의 주요 기술은 도메인 전문가 여야합니다).

이 역할을 수행하는 사람이 정말로 필요하거나 다른 역할과이 역할을 공유 할 수있는 경우, 다시 특정 상황에 따라 달라 지므로 공유 또는 전임 역할로 시작할 수 있습니다. 귀하의 특정 요구에 "검사 및 적응"하십시오.


8

내 경험상 고객이 고객에게 '제품 소유자'라고 말하면 추가 책임을지는 경향이 있습니다. 그러나 팀을 이끌 수 있도록 몇 주마다 진행 상황을 보여 주겠다고 말하면 멋지다. 대부분의 경우, 그것이 제품 소유자가하는 일입니다.


나는 전혀 관여하고 싶지 않은 일부 고객과 이미 협력했지만 대부분의 경우에 해당됩니다. 따라서 때때로 이것은 예상대로 작동하지 않을 수 있습니다.
Andrej Mohar

3

외부 고객은 이해 관계자이며 제품 소유자는 자신의 조직 내에서 와야한다고 말합니다.

내 경험상 비즈니스 소유자와 제품 소유자는 거의 같은 역할을하지 않습니다. 제품 소유자에게 필요한 기술과 그 책임을 확인하려면 스크럼 안내서를 참조하십시오 .

주의해서 제품 소유자를 선택하십시오. 스크럼의 이점을 얼마나 잘 달성하는지에 큰 영향을 미칩니다.


어느 정도 동의하지만 소규모 팀만있는 경우 제품 소유자를 선택하는 것이 매우 제한됩니다.
Andrej Mohar

0

나는 비슷한 상황에 있었고 제품 소유자의 책임을 고객에게주지 않았다. 당신이 말했듯이 고객은이 책임을 맡기를 원하지 않을 것입니다. 그것은 그들의 측면에서 많은 노력을 필요로하며, 모범 사례로 간주되지 않습니다.

팀의 일부인 제품 소유자가 있어야하며 팀에서 고객이 요청한 내용을 전달하도록해야합니다. 더 중요한 것은 팀의 이익을 위해 행동하는 것입니다. 그녀는 고객을 이해하고 고객이 요청한 기능의 우선 순위와 중요성을 판단 할 수있는 충분한 전문 지식을 갖추어야합니다.


왜 다운 투표를 요청할 수 있습니까?
Ioannis Tzikas

데릭에게 대답 할 때 소규모 팀을 구성하고 우리가 직면 할 수있는 모든 분야에 대한 전문 지식을 갖기가 매우 어렵습니다. 또한, 나는 제품 소유자의 역할을 잘못 이해했을 수도 있지만 고객의 이익을 위해 일해서는 안됩니다 (AFAIK, Scrum Master는 팀을 위해 일하기 때문에 그들이 서로를 잘 보완하는 이유는 무엇입니까?) 그나저나, 난 당신을 투표하지 않았습니다.
Andrej Mohar

내가 당신의 팀에서 말할 때 나는 당신의 회사 / 조직에서 의미했습니다. 제품 관리자는 고객의 의견이며 이해 관계자를 대표하지만 여전히 조직 / 팀을 위해 행동합니다. 요청을 필터링하고 클라이언트의 압력을 흡수하는 사람이 있어야합니다.
Ioannis Tzikas
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.