SCRUM을 한 사람 만 작업하는 프로젝트에 사용해야합니까?

우리 회사에는 3 개의 서로 다른 프로젝트를 동시에 진행하는 팀이 있으며 일반적으로 각 프로젝트에는 한 두 사람 만 참여합니다. 프로젝트 작업에는 종종 새로운 기술을 익히거나 버그를 해결하는 것이 포함되며,이 두 가지 모두 예측하기 어려운 작업으로 이어집니다. 이 상황에서 경영진은 여전히 ​​SCRUM 사용을 고집하고 예상치 못한 상황에 대해 스프린트 종료시 안전 버퍼 할당을 허용하지 않습니다. 거의 모든 사람이 관련없는 소프트웨어 구성 요소 또는 다른 소프트웨어 프로젝트를 함께 수행하지만, 전체 팀을 대상으로하는 회의가 진행됩니다.

• 누군가가 단일 개발자 및 퍼지 작업으로 프로젝트에서 SCRUM이 잘 작동하는지, 어떻게 프로세스가 잘 작동했는지 궁금합니다.

• 새로운 기술 연구 / 마스터 링과 관련된 작업을 추정하는 방법 (새로운 프로그래밍 언어, 플랫폼 및 개발 도구 학습 포함)?

• 누군가가 특정 프로젝트에 SCRUM을 사용하지 않도록 설득하는 데 성공했으며, 그렇다면 어떤 주장이 가장 성공적 이었습니까?

감사!

"Personal Scrum"을 찾아보십시오 ...이 작업을 수행하는 사람들의 블로그 게시물이 두세 개 있습니다. Full Scrum에는 단일 팀으로 완벽하게 번역되지 않는 몇 가지 개념이 있습니다. (제 경험은 약 4 명 정도의 특정 "핵심 집단"이 팀 작업을 잘 수행하는 것으로 보입니다.)

예를 들어 http://blog.jgpruitt.com/tag/personal-scrum/ .

그러나 작업 목록이 "보호"되는 동안 작업 추정, 속도 및 시간 제한 스프린트와 같은 것은 1에서도 잘 작동합니다.

당연히 아니지. 일일 스크럼은 매우 짧고 매우 지루할 것입니다!

그래도 도움이 될만한 비트를 선택할 수 있습니다. 카드를 완전히 채울 필요는 없지만 카드는 의미가 있습니다. 진행 시간을 확인하기 위해 일정 시간이 지나면 중지하는 것도 의미가 있습니다. 그러나 그렇게하고 있다면 Kanban, Crystal 및 기타 모든 Agile 방법도 도움이되는 비트를 확인하십시오.

팀 없이는 스크럼을 수행 할 수 없습니다. SCRUM이 정의한 팀은 SCRUM에서 중요한 역할을하는 "제품 개발을 위해 자체 관리를 담당하는 부서 간 기능 그룹"입니다.

http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdf 에 따르면

개발 팀 규모 최적의 개발 팀 규모는 민첩성을 유지하기에 충분히 작고 상당한 작업을 완료 할 수있을만큼 큽니다. 3 명 미만의 개발 팀원은 상호 작용을 줄이고 생산성을 향상시킵니다. 소규모 개발 팀은 스프린트 중에 기술 제약이 발생하여 개발 팀이 잠재적으로 릴리스 가능한 증분을 제공하지 못할 수 있습니다. 멤버가 9 명을 초과하면 너무 많은 조정이 필요합니다. 대규모 개발 팀은 경험적 프로세스가 관리하기에는 너무 많은 복잡성을 생성합니다. 제품 소유자 및 스크럼 마스터 역할은 스프린트 백 로그 작업을 실행하지 않는 한이 수에 포함되지 않습니다.

그러나 여전히 민첩 할 수 있으며 제품 / 스프린트 백 로그 유지 관리 및 스프린트 / 반복 계획 및 작업, 모든 이해 관계자의 검토 및 피드백 및 재 계획 등과 같은 SCRUM의 다른 특성을 사용할 수 있습니다. 여기에 설명 된대로 스크럼에 대한 자세한 내용을 읽으십시오.

비슷한 가게에서 일하고 있습니다. 다른 사람들이 언급했듯이, 당신이 묘사하는 것은 민첩하지만 스크럼은 아닙니다. 또한 백 로그 및 스프린트의 이해 여부는 새로운 작업인지 아니면 유지 관리 및 지속적인 지원인지에 따라 달라집니다. 전자의 경우 폭포 접근 방식은 한 사람의 팀에 더 적합합니다. 그렇지 않다면, PM 관점에서, 그들이하고있는 일은 포트폴리오에 여러 프로젝트가있는 경우 좋은 접근 방법처럼 보입니다.

애자일 애호가에게는 폭포 사용에 대한 언급은 희생적입니다. 그러나 사람들은 상식을 사용해야합니다.

최근 프로젝트에서 예를 들어 보겠습니다. 저는 5 개월의 공격적인 타임 라인에서 3 개의 개발자로 구성된 팀을 이끌고 2 개의 주요 웹 사이트를 재 설계했습니다. 우리는 매일 일 어설 모임을 가졌습니다. 그러나 소규모 팀이었고 제한된 수명주기이기 때문에 폭포 프로젝트였습니다. 개발자는 모두 프로젝트가 시작될 때까지만 계약 한 단기 계약자였습니다. 이 프로젝트는 매우 전통적인 폭포 수명주기를 따랐습니다. 물론 아무 문제가 없습니다. "민첩한"방식으로 작업 한 것을 제외하고는 정상 회의를 유지하고 민첩한 개발 모범 사례를 유지했습니다. 소규모 팀은 대규모 팀의 주별 스프린트 계획 회의에서 면제되었습니다. 왜? 매주 배포가 없었기 때문입니다. 그리고 우리 팀은 다른 팀의 작업에 의존하거나 영향을 미치지 않았습니다. 사실, 우리는 거의 자율적으로 일했습니다. 웹 사이트가 시작된 후 지속적인 유지 관리 및 지원을 위해 민첩한 프로세스로 전환했습니다. 다른 개발자들은 현재 다른 곳에서 일하고 있습니다. 모든 개선 사항은 주기적 배포에 따라 계획됩니다.

요점은 각 프로젝트의 규모, 복잡성 및 성숙도에 가장 적합한 프로세스를 사용하는 것이 좋습니다. 많은 연구를하고 있다면 향후 5 개월 동안 예측하기가 어려우므로 민첩성이 폭포보다 더 나은 방법 일 것입니다.

문제의 일부는 일부 사람들이 다음 5 개의 스프린트를 미리 계획 할 수 있다고 생각하는 것입니다. 그것은 전에 나와 함께 한 사건이었습니다. 스프린트를 두 개 이상 계획해서는 안됩니다. 스프린트를하는 데있어 전체 목적을 무너 뜨리기 때문입니다. 스프린트는 정해진 시간 내에 현실적인 양의 향상을 제공하겠다는 약속입니다. 확실하지 않은 것에 헌신해서는 안됩니다. 스프린트 계획은 본질적으로 단기 계획이지만, 그 점이 중요합니다. 장기 일정이 있다면 물건을 더 작은 결과물로 나누는 것에 대해 생각하십시오. 또는 SDLC의 위치에 따라 검사 점 회의를 설정합니다.

스프린트 계획은 특정 시간 내에 완료되도록 보장되는 것에 대한 현실적인 약속으로 간주됩니다. 계획이 알 수없는 변수를 설명하지 않는 경우 범위 또는 비관적 추정치를 제공해야합니다. 또는 다른 제안처럼 스토리 포인트를 사용하십시오. 미끄러짐 및 기타 중요한 작업을 수행 할 수 있도록 스프린트를 완전히 예약해서는 안됩니다.

팀에 한 사람 만 있으면 안되며 실제로 존재하는 것 같습니다. SCRUM의 "팀"은 개발자 만이 아닙니다. 고객 담당자, 스크럼 마스터, 개발자 등입니까? 당신은이 제품과 관련된 일을하거나, 결정을 내리거나, 판매하려고하는 유일한 사람입니까?

연구 추정에 관해서는 이야기로합니다. "Research XXX"에 대한 이야기를 구체적으로 만들고 이야기를 들려주십시오 (여기서 시간을 추정하는 것이 아니라 어려움을 기억하십시오). 또한 어려움 을 상당히 적절하게 추정 할 수 있어야합니다 기술을 연구해야하는 경우에도 일부 기능을 구현 . 때때로이 후자의 사실은 단순히 이야기를 "최대 난이도"로 바꿉니다.

아니요, 모든 개발자와 스탠드 업으로 만나면 안됩니다. 당신은 당신의 팀 과 회의해야개발자가 아닌 .

행운을 빕니다. 당신이 알아낼 수 있기를 바랍니다.

제품 소유자와 스크럼 마스터 (스크럼이 아닌 경우)가 있다고 가정하면 스크럼은 한 사람의 팀을 위해 일할 수 있습니다. 스크럼 아티팩트 (백 로그, burddown 차트)는 다인종 팀에서 사용되는 것처럼 사용됩니다. 이제 회의에 대해 :

일일 스탠드 업 : 일일 스탠드 업을 사용하여 제품 소유자, 스크럼 마스터 또는 진행 상황에 관심있는 사람을 모두 업데이트 할 수 있습니다. 스크럼 마스터는이 회의를 통해 귀하가 가진 장애에 대해 배울 것입니다. 필요한 경우 제품 소유자가 스코프 재 방문을 도와 줄 수 있습니다.

스프린트 검토 : 각 스프린트가 끝날 때마다 소프트웨어의 작업 증분을 제품 소유자 나 클라이언트에게 인계합니다. 스프린트의 목표가 "무언가"를 배우는 것이 목표라면 경영진이 사용할 수있는 PoC (즉, 일반적으로 PoC의 고객)를 보여줄 것입니다.