스크럼 팀에서 여러 역할을 가진 사람들을 갖는 것이 괜찮습니까?


9

팀에 소개 할 수있는 애자일 스타일 방법론을 평가하고 있습니다. 스크럼을 사용하면 같은 사람이 여러 역할을 수행 할 수 있습니까? 우리는 4 명의 개발자로 구성된 소규모 팀과 웹 디자이너가 있습니다. 우리는 실제로 리더 (이 역할을 수행함), QA 테스터 또는 비즈니스 분석가가 없으며 모든 개발 작업은 CIO에서 제공합니다. 자동화 된 테스트는 총 시간 낭비로 간주되며 모든 것이 품질이 아닌 속도에 중점을 둡니다.

CIO는 개발 작업 (기능 또는 버그 여부에 관계없이)을 수행하여 개발자 (팀 전체, 개인, 종종 개인 또는 외부)에게 제공합니다. 완료 될 것으로 예상됩니다. CIO는 초기 아이디어 이상의 요구 사항을 수집하지 않습니다 (이는 우리가 최종 사용자 중 누구도이 기능을 참조하거나 정보를 제공받지 않았기 때문에이 기능을 사용할 수 없음을 알기위한 목적으로 구현 한 적이 있기 때문에 이전에 우리를 물리 쳤습니다) 우리가 그것을 개발하기 전에, 그리고 공황 상태에서 우리는 변화를 되돌 리라고 지시받을 것입니다.

우선 스크럼 스타일이 몇 가지 표준과 관행을 도입하기 위해 고려해야 할 사항입니까? 읽기에서 스크럼은 약간 더 많은 신뢰와 의사 소통에 의존하고 개발보다는 프로젝트 관리에 더 중점을 둔 것으로 보인다. 이는 현재 프로젝트 관리와 유사하지 않기 때문에 우리가 완전히 결여하고있는 것이다.

둘째, 그것이 가능하다면 누군가가 ScrumMaster와 개발자로 활동하는 것이 비합리적이라고 생각합니까? 또는 개발자가 제품 소유자가 될 수도 있습니다 (개발자가 아닌 CIO가 될 가능성은 있지만)? 나는 Scrum Master와 Product Owner가 서로 다른 사람이어야한다는 것을 알고 있지만 동시에 우리는 Product Owner의 자질을 가진 사람이 없다고 생각합니다 ( '모든 이야기가 필요합니다. 어떻게해야할지 신경 쓰지 마십시오. "거래 유형 및 / 또는 동결은 변덕스럽지 않습니다.)

사고 방식이 바뀔 가능성이 거의 없기 때문에 현재 진행중인 작업을 보상하기 위해 Scrum / XP / Lean을 선택하고 선택해야 할 수도 있습니다. 예를 들어, 페어 프로그래밍은 절대로 날지 않을 것입니다 (폐기물로 보이면 모든 사람에게 두 사람이 필요한 경우 절반의 작업을 수행 할 수 있음).


2
CIO와의 모든 비공개 세션을 논의하여 같은 페이지에 머 무르려면 팀을 세워 회의를 시작하십시오. 스프린트가 방해받지 않도록하세요.
JeffO

답변:


13

Scrum, Kanban 또는 기타 민첩한 방법론은 주로 소프트웨어 개발 프로젝트 에 중점을 둔 방법론 입니다. 다시 말해, 그것은 본질적으로 프로젝트 관리 관행입니다.

귀하와 귀하의 팀이 프로젝트 작업을 수행하기를 간절히 원한다면, "프로젝트"작업을 수행하지 않거나 팀으로 헌신하지 않기 때문에 애자일은 단순히 조직에서 작동하지 않을 것입니다. "프로젝트 약속".

복잡한 기능을 중심으로 미니 프로젝트를 구성 할 수도 있지만 실제로는 비즈니스 분석가 또는 최종 사용자와 연결되어 있지 않으므로 사용자가 무엇인지 실제로 알 수있는 방법이 없을 때 사용자 스토리를 제공하는지 어떻게 확인할 수 있습니까? 원하는가?

귀하의 유일한 이해 관계자는 귀하의 상사이며, 그는 기본적으로 귀하의 팀이 프로젝트의 다른 이해 관계자에게 서비스를 제공하기 위해 존재하지 않으며, 귀하는 이것이 다른 이해 관계자에게 어떤 영향을 미치는지에 관계없이 그와 그의 필요를 서비스하는 팀으로 존재합니다.

무엇보다도 그는 개인에게 개별 작업을 제공하고 그들이 가기로 결정한 즉시 일을 우선 순위를 매길 것입니다. 개별 프로젝트 리소스가 즉시 통지 될 때 또는 스프린트가 보류되는 경우 민첩한 프로젝트 방법론에서 기능 할 수 없습니다.

그런 식으로 작동하지 않아야합니다

스프린트는 것입니다 약속 바이 팀 전체가 지정된 날짜에 의해 사용자 스토리의 부분 집합을 제공 할 수. 일단 시작되면 우선 순위 변경이나 변경이 발생하기 전에 스프린트를 완료해야합니다. 이러한 혼란스러운 임시 환경에서 프로젝트를 관리 할 때는 어떻게해야합니까?

애자일 프로젝트 관리 방법론에 도움이되는 환경에서는 일하지 않습니다. Waterfall 방법론에 도움이되는 환경에서는 작업하지 않습니다. 당신은 군주제에서 일하고 있으며 단지 그의 왕이 그의 입찰을하고 불을 끄는 왕들입니다.

이것은 소프트웨어 개발 프로젝트 팀이 만든 것이 아닙니다.

따라서 매우 모호한 방식으로 귀하의 상황에서 개인이 여러 역할을 수행하는 것이 중요하지 않다고 말하는 귀하의 질문에 대답하고 있습니다. 당신은 당신의 손에 훨씬 더 큰 문제가 있습니다. 지붕이없는 집의 카펫에서 물 얼룩을 제거하는 방법을 묻습니다.


슬프게도 귀하의 답변이 올바른 것 같습니다.. 우리는 기본적으로 CIO에게 무엇이든 연기 할 필요가 있습니다. SVN을 언제 어떻게 분기해야하는지 등 관심이없는 것들도 있습니다. CIO는 개발자가 아닌 경우 어떻게 분기해야하는지 결정합니다.
Wayne Molina

1
@WayneM 왕이 소소한 바보 일 때 모든 왕의 말과 모든 왕의 사람들이 다시 겸손한 덤프를 다시 넣을 수 있습니까? 나의 일반적인 경험은 나에게 그렇지 않다고 말합니다. 이 환경은 프로젝트에서 소프트웨어를 작성하는 데 도움이되지 않습니다. 프로젝트 팀에서 일하는 좋은 경험을 원한다면 거기에서 찾을 수 없기 때문에 둘러보기 시작하십시오.
maple_shaft

2
@WayneM 또한 CIO는 우선 순위를 정해야합니다. 고객이 실제로 어떻게해야하는지 알려주는 귀중한 시간을 낭비하지 않고 고객 및 사용자 요구를 충족하도록 제품 라인을 지시하는 데 실제로 집중하려고한다면 회사가 훨씬 더 잘할 것입니다. 완전한 기능 장애의 cesspool.
maple_shaft

최악의 부분은 멍청한 운 때문에 적당히 성공한 것이므로 문제조차 보지 못합니다.
웨인 몰리나

1
@WayneM 바보 같은 틈새 시장에서 정치적 연결? 아마 후자 일 것입니다. 기업은 오랫동안 멍청한 행운을 유지하지 않습니다. 보다 효율적인 경쟁 업체가 회사를 떠나는 것을 막을 수있는 유일한 방법은 진입 장벽입니다.
maple_shaft

6

여기서 언급했듯이 Scrum Master 또는 Product Owner 중 하나에 실행 가능한 작업이있는 경우 팀 구성원이기도합니다.

즉, CIO와 고객 모두로부터 실질적인 인수를하지 않으면 Agile에 심각한 문제가 발생하게됩니다. CIO는 스프린트 중간에 작업 항목을 추가 할 수 없지만 다음 항목까지 기다려야한다는 사실을 기꺼이 준수합니까? 그는 개발 될 아이템의 우선 순위를 기꺼이 하시겠습니까? 당신이 쓴 것에서, 그가 당신이하는 일을 소유 한 것처럼 들리므로 제품 소유자가되어야합니다. 그가 원치 않는다면, 당신은 현재보다 더 이상 성공하지 못할 것입니다.


3
이. 제품 소유자는 항상 공통의 목표를 향해 나아가는 팀의 중요성을 약속하고 이해해야합니다. 이 사람은 그것에 관한 것이 아니며 솔직히 그가 이해하지 못하는 세계에서 어른 게임을하려고하는 거대한 도구처럼 들립니다. 또한 OP의 과거 질문 중 일부로 그를 판단하고 있음을 명심하십시오.
maple_shaft

1

Scrum은 CIO가 프로세스에 구매하는 경우에만 CIO가 개발자 임시 작업을 할당하는 문제에 대한 좋은 솔루션이 될 수 있습니다. 귀하의 CIO가 직접 할당을받는 것을 좋아하지 않는 것 같습니다. 그러나 CIO가 사용자 스토리를 작성하고 우선 순위를 정하는 아이디어를 구매할 수 있다면이를 관리하는 데 매우 효과적인 방법을 찾을 수 있습니다. 그러나 CIO가 프로세스에 충실하도록 설득하는 것부터 시작합니다.


1

스크럼은 고려해야 할 사항입니다. 그러나 동일한 페이지에 관련된 모든 사람들을 확보 하고이 방법론을 사용하는 데있어 초기 문제를 해결하기 위해 최소한 몇 가지 스프린트를 얻는 것과 함께 구조에 대한 몇 가지 변경 사항을 수락한다는 말이 있습니다.

제품 소유자는 여기에 제시된 이해 상충이있을 수 있으므로 개발 팀 외부에 있어야합니다. 이 경우 충돌이 나쁘지 않지만 Scrum Master는 개발자 일 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.