저는 스크럼의 이점과 과정에 대해 꽤 잘 읽었습니다. 백 로그, 번 다운 차트, 반복, 사용자 스토리 사용 및 스크럼 "프레임 워크"의 기타 다양한 개념에 대한 아이디어를 얻습니다.
즉, 저는 한 번에 여러 프로젝트를 관리하는 웹 개발 회사에서 일하고 있으며 "프로덕션 팀"을 구성하는 6 명의 팀원이 있습니다.
스크럼은 여러 프로젝트에서 어떻게 작동합니까? 여전히 특정 시간 동안 단일 프로젝트에 대한 반복을 예약하고 전체 팀이 작업을 수행 한 다음 해당 반복이 완료되면 새 반복으로 다음 프로젝트로 이동합니까? 아니면 동시에 단 하나의 팀으로 자체 반복으로 여러 프로젝트를 관리하는 "민첩한"방법이 있습니까?
답변:
스크럼은 당신이 하나의 독립된 제품에 대해 작업해야한다고 지시하지 않습니다. 완료해야 할 작업이 많고 (제품 백 로그), 다음 반복에서 사용할 수있는 개발 시간이 일정하며 (프로젝트 속도에서 작업) 클라이언트가 선택한 항목이 있음을 나타냅니다. / business는 다음 반복 (스프린트 백 로그)에서 수행 될이 문제 / 작업 풀에서 가장 우선 순위를 갖습니다.
제품 백 로그 및 스프린트 백 로그가 하나의 프로젝트에 있어야 할 이유가 없습니다. 단일 프로젝트에서도 별도의 프로젝트 (UI, 비즈니스 계층, 데이터베이스 스키마 등)와 같은 개별 작업 단위가있을 것입니다. 특히 엔터프라이즈 소프트웨어 개발은 모두 진행되어야하는 많은 코드 기반이있는 이와 같습니다. 스크럼 프로세스 (회의, 질문, 번 다운 차트 등)는 모두 하나의 프로젝트이든 여러 프로젝트이든 상관없이 작동합니다.
실제로 각 반복에 "보고 모듈 수행"또는 "XYZ 시스템의 API와의 인터페이스"라는 주요 주제를 갖는 것이 좋습니다. 따라서 많은 문제가 하나의 프로젝트 또는 영역에서 발생합니다. 반복이 끝나면 작업의 큰 부분을 가리키고 그것에 대해 눈금을 둘 수 있습니다.
대답은 " 백 로그 항목의 우선 순위를 지정할 사람 "(즉, 먼저 수행해야 할 작업을 결정) 에 달려 있다고 생각합니다 . 이 사람이 한 사람인 경우이 사람은 프로젝트의 제품 소유자이며, 모든 프로젝트에 대한 모든 항목 또는 프로젝트 당 백 로그를 단일 백 로그로 만들 수 있으며 계획 할 때 모든 프로젝트에서 백 로그 항목을 선택할 수 있습니다. 스프린트. 이 경우 스크럼은 "작동"합니다.
모든 프로젝트에 책임이 있다면, 각 책임이 의식적으로 프로젝트를 선호하는 문제에 직면하게 될 것입니다. IMHO, 중재를 통해 우선 순위를 정할 권한이있는 제품 소유자 한 명만 있으면됩니다.
이러한 맥락에서 따라야 할 한 가지 규칙 은 Sprint 동안 Sprint 콘텐츠를 변경하지 않는 것 입니다. 필요한 경우 반복을 2 ~ 3 주로 단축하여 현재 Sprint에 긴급 항목을 추가해야하는 위험을 낮출 수 있습니다.
동의하지 않습니다. 스프린트 중에 팀이 단일 프로젝트에 집중하는 것이 프로세스의 핵심이라고 생각합니다. 전체 개발 프로세스에 기여할 수없는 전문가 (컨텐츠 작성자, 그래픽 담당자, 비즈니스 프로세스 분석가 등)가 있다면 더 이상 기여할 수 없을 때 팀에서 섞어 버릴 것입니다. 또는 더 좋은 방법은 테스트와 같은 일에 기여할 수 있도록 몇 가지 다른 작업에 대한 교육을받는 것입니다.
염두에 두어야 할 또 다른 사항은 프로젝트를 병렬로 실행하면 일정이 죽는다는 것입니다. 이것을 고려하십시오 : 단순화를 위해 동일한 팀을 사용하고 같은 날짜에 시작하는 5 개의 프로젝트가 있다고 가정 해 봅시다. 각 프로젝트에는 3 개월의 노력이 필요합니다. 병렬로 실행되는 최상의 시나리오에서는 한 번에 모두 완료하고 15 개월이 걸립니다. 단 한 번의 스프린트에서 한 달의 노력의 1/5 만 맞출 수 있기 때문에 속도가 정해집니다. 또한 동시에 5 개의 데모 회의를 진행하게됩니다. 따라서 최상의 시나리오는 15 개월 안에 5 개의 프로젝트를 제공하고 경쟁 업체는 3 번에도 동일한 작업을 수행 할 수 있다고 주장 할 것입니다. 성숙도를 추정하는 팀은 사용 가능한 노동의 20 % 만 고려할 수 있기 때문에 어려움을 겪을 것입니다. 실제로 단일 스프린트에서 일부 작업을 수행 할 수 없음을 알 수 있습니다. 작업중인 프로젝트의 수를 5 개에서 변경해야하는 경우 팀은 팀의 효율성을 손상시킬 추정 습관을 조정해야합니다. 또한 간단한 작업 재 할당으로 인해 작업을 시작하기 전에 새로운 개발 환경을 가동해야하는 경우 팀이 자체 구성하기가 어려울 것입니다.
동일한 5 개의 프로젝트를 연속적으로 실행한다면 동일한 15 개월에 5 번째 프로젝트를 제공 할 것이지만, 고객에게 12 개월의 백 로그가 있고 사용할 수있는 요구 사항이 있다는 것을 고객에게 교육했을 것입니다. 그 시간에 프로젝트 목표를 구체화하십시오. 또는 지속적인 백 로그가있는 경우 다른 팀을 고용해야 할 때라는 것을 알고 있습니다. 그러나 최고의 프로젝트는 활성 기간 동안 빠른 개선을 보인 고객과 함께 3 개월 만에 완료됩니다. 그 프로젝트를 1 년 전에 끝내고 이력서에 올릴 수 있습니다. 당신의 스프린트 속도는 그 기간 동안 안정 될 것이며, 프로젝트가 한두 번 후에 보폭에 도달하고 주어진 스프린트에서 더 많은 것을 성취 할 수 있다는 것을 알게 될 것입니다.
프로젝트를 연속적으로 실행하는 것은 스크럼 페이스를 채택하려는 조직에서 가장 큰 장애물 중 하나라고 생각합니다. 프로젝트 관리자 역할을 해체하는 것과 관련된 주요 문화적 변화이지만 스크럼 프로세스의 이점은 엄청납니다.
EVERYBODY는 전체 팀원이 될 필요는 없습니다. 그들은 개발 프로세스를 준비하면서 대기실에서 고객을 참여시킬 수 있습니다. 비즈니스 분석가, 네트워크 설계자 및 그래픽 디자인 인력을 도메인 전문가로 유지하고 필요한 경우에만 팀에 연결합니다. 스프린트 0으로 실행하게하십시오. 룩앤필 및 워크 플로우 작업이 얼마나 매력적인 지 놀랄 것입니다. 개발이 본격적으로 시작되면 실제로 참여 수준이 올라갈 수 있으며 사용 가능한 것이 중요하다는 점을 이해하고 고객을 준비시키는 것도 좋습니다. 휴가 나 휴가 등을 미리 처리 할 수있는 충분한 시간을 가질 수 있도록 일정을 알려주십시오.
나는이 정확한 상황에 있었다.
프로젝트 전체에 한 명의 제품 소유자가있는 경우 Phillipe는 절대적으로 정확합니다. 한 팀으로 한 스프린트는 잘 작동합니다.
둘 이상의 제품 소유자가있는 경우 이상적으로 비즈니스 측은 작업 일정을 세울 책임이있는 단일 '우선 순위 지정자'를 선택해야합니다. 이것은 확실히 최고의 솔루션입니다.
(아마도 그렇듯이) 비즈니스가 우선 순위를 지정하는 방법을 변경하지 않으려는 경우 (너무 편리 할 수 있음) 팀을 분할하고 두 개의 동시 스프린트를 실행할 수 있습니다. 그러나 6 명의 팀이 있다면 3 개 이상의 팀으로 나누지 않을 것입니다 (전혀 나누고 싶지는 않지만 2-3 개 팀이 가능할 것 같습니다). Kenny가 제안한 것처럼 더 이상 분할하고 한 사람으로 구성된 팀을 갖는 것은 나에게 다소 무의미한 것 같습니다. 그러면 더 이상 팀이없고 개별 프로그래머 만 있습니다.
팀을 분할하는 경우, 동일한 코드베이스에서 작업하는 별도의 스프린트가없는 한 스탠드 업을 통합하는 데 큰 가치를 찾지 못했지만 다음 목적을 위해 해당 팀을 통합하려는 논쟁이 될 수 있습니다. 스프린트.
최근에 제가 읽은 또 다른 의견이 있습니다. 즉, 애자일 환경에서 Project 의 개념 이 비생산적 일 수 있고 제거 될 수 있다는 것입니다. 이러한 사고 방식에 따르면 조직은 대신 릴리스에 집중해야합니다 . 이는 프로젝트 가 완료 될 때까지 가치를 생성하지 않는 인위적인 작업 상자 이기 때문 입니다. 배송 가능한 가치를 자주 제공하려는 Agile의 목표에 위배됩니다. 릴리스 가 가치를 제공으로 그 범위가 감소 또는 팀이 다음하기 전에 제공 할 수 있는지에 따라 확장 할 수 있기 때문에 방향이 있기 때문에 애자일에 맞춰 더 릴리스 .
회사에서 이전에 프로젝트 라고 불렸던 것이 이제는 공통 애자일 테마 또는 기능 으로 다시 패키징 되는 잠재적 중간 지점 이 있습니다 . 이 접근 방식의 이점은 제품 소유자가 적합하다고 생각하는대로 이제 테마 또는 기능 을 가치있는 부분으로 구현할 수 있다는 것입니다.
하나의 팀이 여러 제품을 작업하는 문제가 여전히 남아 있으며 도메인 지식과 가능한 기술 기술에 대한 합법적 인 우려 때문에 문제가됩니다. 그러나 제품 애자와 내장, 심지어 여러 제품 단일 팀에 의해 구축은 지속적으로 축적되어 출시 -able 값입니다. 대조적으로, 프로젝트 는 끝날 때까지 가치가 없습니다.
생각할 것 ...
나는 anopres가 옳았다 고 생각합니다. 가장 좋은 방법은 스크럼으로 동시에 여러 프로젝트를 피하는 것입니다. 병렬로 너무 많이 실행하는 것은 효율적이지 않다는 것을 확신하기 위해 모든 것을하십시오.
5 명으로 구성된 팀에 대해 약 3 개월에 대해 각각 5 개의 프로젝트를 가정 해 보겠습니다.
접근 방식 1 : 각 사람이 팀의 단일 프로젝트에서 작업
접근 방식 2 : 프로젝트 당 스프린트 1 회, 프로젝트 전환
접근 방식 3 : 단일 스프린트에서 5 개의 프로젝트
접근법 4 : 권장-직렬화 된 작업
보시다시피, 솔루션 4는 일반적으로 프로젝트가 훨씬 빠르게 전달되고 팀이 함께 효율적으로 작업하기 때문에 일반적으로 더 좋습니다. 다른 접근 방식으로는 컨텍스트 전환으로 인한 낭비 시간, 완전한 팀 협업 없음, 모든 프로젝트의 매우 긴 총 제공 시간 등이 있습니다.
백 로그 그루밍은 어떻습니까? 팀이 한 번에 하나의 프로젝트를 수행하는 것은 간단합니다. 모두가 참여할 것입니다. 여러 프로젝트가있는 경우 개별 그루밍 세션에 단일 사람을 위임해야 할 수 있습니다 (전체 팀이 포함되지 않음).
3 개월 후에 2 차 프로젝트를 시작하면 다른 모든 프로젝트와 함께 즉시 시작하는 것보다 훨씬 빠른 배송 (6 개월 이후)을 얻을 수 있다는 점을 고객에게 확신시키는 것이 중요합니다. 관리자가 보는 것은 착각입니다. 한 번에 5 개의 프로젝트를 시작하고 열심히 일하며 조금씩 제공합니다. 그러나 결국 이것은 효율적이지 않습니다.
그렇기 때문에 스크럼이 여러 프로젝트에 대해 병렬로 효율적이라는 것을 믿지 않습니다. 스크럼을 프레임 워크에 맞추고 스크럼 규칙에 따라 작업하는 것은 매우 까다 롭습니다. 때로는 모든 사람을 유지하기 위해 2 개의 프로젝트를 갖는 것이 좋을 수도 있지만, 더 많은 프로젝트를 추가할수록 스크럼의 효율성이 떨어집니다. 아마도 칸반은 진행 상황과 팀 작업을 볼 수있는 대안일까요?
감사합니다, Adam
@Chris가 말했듯이 일반 프로젝트에는 하위 프로젝트가 있습니다. 하지만 백로 그는 하나뿐입니다.
모든 프로젝트의 백 로그에서 생각하십시오. 첫 번째 문제 : 작업이나 프로젝트에 우선 순위를 할당하고 있습니까? 저는 프로젝트 당 백 로그를 선호합니다. 최소한 제품 소유자의 우선 순위를 명확히해야합니다.
제품 소유자가 다르고 해당 제품 소유자가 각 프로젝트에 얼마나 많은 시간을 주어야하는지 동의하지 않기 때문입니다. "누군가"는 프로젝트 간 우선 순위를 관리하는 방법에 대한 결정을 거부해야합니다. 참고 : 개발자는 그렇게해서는 안됩니다.
여기에 우리의 프로젝트 "S"관리자가 제품 소유자에게 필요한 자원과 팀 구성원이 줄 수있는 시간의 균형을 맞출 것입니다. 제품 소유자 A는 한 달의 작업 비용을 지불했지만 제품 소유자 B는 항상 자신의 프로젝트를 업데이트하고 있습니다 (그리고 당신에게도 좋은 비용을 지불합니다). A가 한 달 (개발자 시간)을 가질 수 있도록 팀의 균형을 맞추고 B가 주머니를 채우는 것을 막지 마십시오.
내부 소프트웨어의 경우 (회사 1 개, 프로젝트 1,000 개) 다른 제품 소유자는 그들에게 주어진 시간에 동의해야합니다. 그들은 고립되어 사는 것이 아니라 당신과 같은 배에 있습니다 (프로젝트 "S"매니저). 그들은 당신의 삶이 어떤 일을 연기 할 수있게 해줄 것이지만, 동시에 당신은 그들의 필요를 잊지 말아야합니다.
글쎄, 나는 이것을하기위한 최선의 방법을 알아 내려고 여전히 노력하고있다. 그러나 이것이 우리가 지금 추진하고있는 것입니다. 도움이되기를 바랍니다.
팀 구성원은 스크럼 프로젝트간에 시간을 나눌 수 있지만 팀 구성원이 전적으로 헌신하는 것이 훨씬 더 생산적입니다. 팀 구성원은 한 스프린트에서 다음 스프린트로 변경할 수도 있지만 이는 팀의 생산성을 저하시킵니다. 더 큰 팀이있는 프로젝트는 여러 스크럼으로 구성되며 각 스크럼은 제품 개발의 다른 측면에 중점을두고 노력을 긴밀하게 조정합니다.
각 프로젝트에 대해 하나의 Sprint를 실행하고 모든 활성 스프링 / 프로젝트를 처리하기 위해 매일 1 회의 스탠드 업 회의를 갖는 것이 좋습니다.
기여하고 싶습니다. 이것이 내가하는 방법입니다.
그리고 그게 다야. 나는 이것이 꽤 잘 작동한다고 말할 수 있습니다. 이를 위해 Google 스프레드 시트 (제품 백 로그 및 스프린트 백 로그, 차트 및 항목 포함)를 사용하고, 온라인 조직을위한 redmine (특정 의미 체계 포함)을 매일 사용합니다 : 시간, 작업 진행 등
이 접근 방식의 문제점은 스프린트 백 로그 스프레드 시트와 레드 마인에서 작업을 복제했다는 것입니다. 하지만이 작업을 완전히 온라인으로 수행 할 수있는 온라인 도구는 없습니다. 나는 redmine의 제품 백 로그를 놓치고 (다른 의미가 없습니다) jira의 단일 보드, 타이가의 더 많은 이야기 등