우리는 소프트웨어 개발 회사입니다. 우리는 스크럼을 도입했습니다.
문제는 개발자가 많은 회사와 같은 스크럼 스프린트에 풀 타임을 쓸 수 없다는 것입니다. 그들은 SCRUM 프로젝트 작업에서 많은 개발을해야합니다!
나는 그것을 읽었습니다 : 스크럼은 시간제 개발자를 허용하지 않습니다스크럼 : "전속력으로 풀 타임"을 가진 팀에만 좋은 방법입니까?
그럼, 이것에 대한 당신의 경험은 무엇입니까?
스크럼은 스크럼 스프린트에 중점을 둔 개발 작업에만 시간을 할애하는 개발자들에게만 좋은 방법입니까? 시간
초점 인수을 정의하십시오.이 비율은 각 개발자가 Sprint 콘텐츠에서만 작업 할 수있는 시간의 비율입니다. 이 초점 요인은 Sprint 항목 (전자 메일, 지원, 회의 ...)에서 작업 할 수없는 시간을 나타냅니다.
스프린트 계획에서는 해당 집중 요인에 따라 달성 할 수있는 계획 만 계획하십시오. 팀의 경우 80 시간에 600 시간이면 480 시간 만 계획하게됩니다.
초기 값은 임의로 또는 이전 스프린트 동안 달성 된 것을 토대로 결정할 수 있습니다. 계획된 60 일 및 완료일 45 일은 75 %의 초점 계수를 제공합니다.
그렇다면 스크럼이 아닌 작업이 중단이 아닌 경우, 동시에 시간을 관리하는 것이 좋습니다 (예 : 금요일에 팀의 모든 구성원이 다른 작업을 스프린트 작업).
이 초점 요인은 팀 구성원마다 동일 할 필요는 없습니다. 또한 팀에 파트 타임 멤버가있을 수 있습니다.
에 대한
덕분에 내가 스크럼 파트 타이머를 허용하지 않는 방법을 표시되지 않는 이유는 무엇입니까? 나는 많은 스크럼 팀에 있었고 거의 항상 풀 타임이 아닌 리소스를 가지고 있습니다. 또는 우리는 두 개의 프로젝트 사이에서 분리 된 리소스를 가지고 있습니다. 우리는 개발자가 프로젝트에 지정된 시간을 할애하여이를 관리하고 할당 된 시간을 계획합니다. 가장 민첩한 프로젝트 관리 솔루션은 이러한 스타일의 리소스 관리를 가능하게합니다.
스크럼은 풀 타임 포커스를 원하기 때문에 컨텍스트 스위칭이 손실되는 것을 방지합니다. – Hace
스크럼에 대한 많은 접근법이 있습니다. 솔직히 "순수한"스크럼을하는 한 회사를 보지 못했습니다. 스크럼을 잘 구성 할 수 있다면 이익을 얻을 수 있습니다. 하지만 왜 프로세스를 스크럼으로 바꾸고 싶은지 생각해야합니다. maby 그것은 무의미합니다.
나는 당신이 스크럼을 시험해보고 그것이 가치가 있는지를 알아야한다고 생각한다.
저는이 문제가있는 회사에서 일하고 있습니다. 우리는 다음과 같은 문제를 스크럼을 사용하지만,이하려고 :
이러한 모든 문제로 책에서 스크럼을 수행하는 것은 불가능합니다. 팀의 인원이 항상 바뀌면 각 스프린트의 속도는 기본적으로 쓸모가 없다.
아직도 나는 당신이 어떤 혜택을받을 것으로 나타났습니다 :내 제안은 스크럼을위한 것입니다. 우리 회사에서와 마찬가지로 경영진과 개발자가 짧은주기 등의 이점을보기 시작하면 변경 작업을 시작하여 스프린트 작업이 아닌 작업이 스프린트 작업으로 바뀌게됩니다 . 그래서 나는 여전히 스크럼을 시도하는 것의 이점을보고있다. 스크럼을 어쨌든 할 수있는 100 % 올바른 방법은 없습니다.
적어도 결과를 드러내고 모든 스프린트가 문제를 해결할 수 있도록 시간의 조건을 정의 할 수 있습니다 (팀 용량의 15 %를 가정 해 봅시다). 이 시간은 스프린트의 목표에 커밋되지 않으며 해결 불가능한 문제를 해결할 수 있도록 남겨 둘 것입니다. 경영진은 팀의 생산성이이 금액만큼 앞선 사실로 인해 훼손된다는 것을 알게 될 것입니다. 우연한 일에 매 1 시간의 추가 작업을 예약하고, 그것이 끝났을 때 제품 소유자는 스프린트의 가치와 팀 결심을 지불하면서 이슈를 결정할 필요가 있음을 분명히 밝힌다. 투명성이 핵심입니다! – ANdreaT
비록 내가 SCRUM과 가장 큰 마일리지를 가지고 있지는 않지만 일반적인 규칙은 스프린트가 너무 집중되어 있고 팀이 많은 일을해야하기 때문에 스크럼이 잘 작동하지 않을 때이다. 스프린트의 범위는 고려되지 않았다. 따라서 이러한 작업은 스크럼 내부의 팀에 의해 성가신 것으로 인식되고 스크럼은 외부에 남겨진 사람들이 불쾌하다고 인식합니다.
우리는 아직 SCRUM을 다 사용해 보지 못했지만 구현할 수있는 여러 가지 방법으로 여기 몇 가지 경험을했으며 최상의 결과는 팀이 여러 부서 (테스트, 품질 보증, 구현, 개발, 아키텍처 , 마케팅). 이것은 이들이 팀에서 전일제가 아니라는 것을 의미하지만 현재 프로젝트의 범위 내에서 그들에게 할당 된 임무를 지니고 있다는 사실은 일반적으로 그 팀에 시간을 할애 할 의사가 있음을 의미합니다.
다음으로 가장 큰 이점은 가짜이지만 중요한 지원 dev와 같은 알려지지 않은 부분에 대한 버퍼 시간을 별도로 설정할 수 있다는 것입니다. 이러한 문제가 발생하면 작은 팀이 구성되어 일시적으로 주 스크럼에서 벗어나 문제를 처리합니다.
마지막으로 설치, 구성 등의 것들은 스크럼의 일부이며 그와 같이 집계됩니다.
다음에 시도 할 또 다른 접근법은 아이디어를 확장하여 하나의 스크럼 - 투 - 룰 - 그것 - 모든 접근법 대신에 각 특정 요구에 맞는 작은 팀을 얻도록 노력할 것입니다. 이 문제의 주된 문제점은 많은 사람들이 스크럼 마스터의 역할을 맡을 수는 없으므로 닭고기와 계란이 더 많지 않다는 것입니다.
여기에 SCRUM을 사용했지만 결코 책에 적용되지 않습니다. 나는 이러한 기술과 접근법을 아이디어 버켓으로 생각하고 우리의 요구에 가장 잘 맞는 방법을 모색하고 실험 해 봅니다. 그러나이 실험이 효과가 있기 위해서는 때로는 파괴적으로해야합니다 (당신은 스크럼을하지만 결코 그것을 공식화하지 마십시오). 나는 새로운 접근법을 채택하고 항상 우리가 직면하고있는 고유 한 변화 저항을 통해 쉽게자를 수있는 최선의 방법을 찾는다.
지금까지 워크 플로우는 자연스럽게 scrum-XP-agile-TDD 유형으로 발전했으며 천천히 침입 한 두려운 폭포를 피할 수있게되었습니다. 희망에 따라 잔디가 울타리의 내 측면에서 훨씬 더 친환경적입니다. :-)
우리 팀에서는 스프린트에 지원 작업이 포함되어 있습니다. 각 스프린트에 대해 우리는 각 제품이 필요할 것으로 예상되는 지원 시간을 추정하고이를 스프린트의 작업으로 추가합니다. 지원 수요가 예상보다 훨씬 높지 않으면 (물론 앞으로의 스프린트에서 지원을 위해 예약 된 시간에 영향을 미칠 수있다) 스프린트가 고통을 겪지 않는다.
정말로 좋은 질문입니다. 나는 거의 모든 종이, 기사, 서적 등에서 "모든 구성원은 풀 타임이어야합니다"라는이 문장을 보았습니다. 저는 스크럼에서 붉은 색을 띄지 만, 왜 이것이 그렇게되어야하는지에 대한 어떤 주장도 보지 못했습니다. 대규모 조직에서는 아무 것도하지 않는 개발자가있을 것이라고 기대하지만 소규모 조직에서는 스프린트에 100 % 커밋 할 수없는 개발자가 있어야하며 스크럼은 소규모 팀을 위해 설계되었습니다! 초점 요인은 이것을 다른 것과 마찬가지로 처리 할 수 있어야합니다.
우리가 일하는 곳에서는 개발자가 지원 요청과 같은 프로젝트에 참여하지 못하게하거나 팀장이 다른 프로젝트에 대한 모임을 갖기 때문에 누군가가 "비 프로젝트"라고 말할 수있는 시대가 있습니다. 이 사람은 현재 스프린트에 기여하지 않습니다.
효율성은 스프린트에 포함 된 작업에 집중할 수있게함으로써 발생합니다. 그것은 다른 개발 모델이 해결할 수있는 것이 아닙니다. 그러나 '다른 업무'가 할당 된 개발자는 지원, 교육 또는 기술 사전 판매와 같은 실재입니다.
대부분의 경우 지원이 기본적으로 제공되지 않습니다. 교육 및 사전 판매는 "X 씨가 고객과 N 일을 보내는 데"와 같이 다소 시간이 걸리는 경향이 있습니다.
개발자를 두 개 이상의 팀으로 나눠보십시오. 팀 간의이 스프린트 사이클 동안 지원을 받는다. 그 팀은 만날 여유가있는 일만해야합니다. 다른 팀을 방해하지 않고 지원 문제를 해결하기 위해 최선을 다해야합니다.
우리는 이것으로 좋은 결과를 보았습니다.
관리와 같이 들리는 것은 실제로 스크럼이있는 보트에는없는 것처럼 들립니다. 나는 매우 짧은 스프린트, 1 주 정도를 제안한다. 따라서 영업 담당자 나 경영진이 방해를 받고 싶을 때마다 일주일도 채 안되는 다음 스프린트를 위해 일을 끝내고 기다릴 수 있다면 시도해보십시오. 스크럼은 개발자가 혼자서하는 일이 아니어야합니다. 고객에게 전체 체인에 있어야합니다.
내가 일하고있는 회사가 동일한 문제에 직면하고 있기 때문에 이에 대한 내 생각을 더했습니다. 좋은 질문입니다. 좋은 답변을 얻길 바랍니다. – Halvard