답변:
가장 큰 문제는 오해입니다. 일반적인 실패는 다음과 같습니다.
오직 한 팀만이 스크럼을하고 있지만 나머지 회사 (영업, 관리, HR 포함)는 여전히 오래된 방식으로 생각합니다. 예 :
고객 및 고객의 참여와 지속적인 상호 작용이 매우 중요합니다.
HR은 팀 성과가 개인의 성과보다 더 중요하다는 것을 이해해야합니다. KPI는 그로 변경해야합니다.
기능 정의는 지속적인 프로세스입니다. 프로젝트 정의는 고객 피드백에 의해 개발 중에 발전 할 것입니다. 해당 프로젝트 마감일로 인해 필요한 예산 또는 결과 기능 세트가 변경 될 수 있습니다 (이해 관계자의 승인 후).
변화는 과정의 일부입니다.
추정은 프로젝트가 시작될 때 5 개월 이내에 모든 기능 (처음에는 알려지지 않은 기능)으로 수행 될 것이라고 말할 수없는 지속적인 프로세스입니다.
팀은 결정을 내릴 수 있습니다. 팀은 다음 스프린트 동안 제공되는 기능의 양을 약속합니다. 이것은 요구하거나 명령 할 수 없습니다.
스프린트는 팀에게 안전한 구역입니다. 팀이 정의 된 사용자 스토리를 커밋 한 후에는 커밋을 팀 외부에서 수정할 수 없습니다.
오래된 조직 구조의 일부는 스크럼으로 이동할 때 의미가 없습니다. 스크럼은 세 가지 역할을 정의합니다 : 스크럼 마스터, 제품 소유자, 팀. 다른 역할이 있지만이 세 가지만으로도 응용 프로그램을 제공하기에 충분합니다. 일반적인 의미는 Scrum 마스터, 팀 리더, 제품 소유자 및 하나 이상의 프로젝트 관리자가 있습니다. 프로젝트 관리자와 팀 리더는 Scrum에서 중복 역할입니다.
할당 된 스크럼 마스터 역할이 스크럼 마스터를 수행하지 않습니다. 스크럼 마스터는 장애를 해결합니다. 팀을 방해하는 것은 최대한 빨리 해결해야하는 장애입니다. 가장 일반적인 실패는 Scrum에 대한 이전 경험이없는 개발자에게이 역할을 할당하는 것입니다. 이 역할은 일반적인 프로젝트 관리자를 부분적으로 대체하지만 Scrum 마스터는 파워 오버 팀이 없으며 Scrum 마스터는 구현할 기능을 요구하지 않습니다. 스크럼 마스터는 실현할 수없는 요구 사항으로 제품 소유자로부터 팀을 보호합니다.
편집하다:
중요한 메모를 추가하고 있습니다. 민첩한 접근 방식을 사용할 때 가장 큰 요점은 고객에게 최대한 많은 비즈니스 가치를 제공하는 것입니다. 그러나 고객 (제품 소유자가 나타내는)은 비즈니스 가치가 무엇인지 설명합니다. 따라서 Scrum을 사용할 때 분석이나 문서가 없다는 것이 일반적으로 사실이 아닙니다. 고객이 분석 또는 문서를 요청하고이를 비즈니스 가치로 표시하는 경우 (예 : 향후 몇 년간 개선해야 할 대규모 또는 장기 프로젝트로 인해)이를 생성 할 수도 있습니다. 가장 기본적인 접근 방식은 사용자 사례에 대한 승인 기준에 분석 및 문서를 포함시키는 것입니다. 이러한 경우 분석은 표준화 된 방식으로 제품 소유자와의 통신으로 문서화됩니다.
The most basic approach is including analysis and documentation in acceptance criteria for user stories.저의 첫 반응이기도합니다. 스토리에 합격 기준이 있다면, 이것이 가장 좋은 문서입니다. 그러나 팀이 추가 문서를 작성하기로 결정한 경우 (트렁크에있는 README 또는 유용한 정보가있는 Wiki에 대한 생각) 문제가 발생하지 않습니다. 나는 사람들이 SCRUM = 아무것도 기록되어 있지 않다고 두려워한다고 생각합니다.
제가 10 년 이상 xp와 스크럼에서 발견 한 가장 큰 문제는 아직 민첩하지 않은 팀이 "민첩에 유연하게 대응"하고 사용자 정의를 시작하고 특정 부품을 떨어 뜨리는 등의 결정을 내릴 때입니다. 각 부분의 역할과 그 이유를 명확하게 이해합니다.
나는 팀이 처음에 책을 통해 일을 할 때 아직 "얻지 않은"것을 바꾸는 팀보다 스크럼에서 더 성공적인 것을 보았습니다.
"첫 스프린트, 모든 스프린트, 두 번째 스프린트 모든 디자인 등 마지막 스프린트 모든 테스트"와 같은 것을 얻을 때입니다. 폭포라고도합니다. 또는 "어쨌든 앉아 보자.이 스탠드 업 사업은 어떻습니까?"
Shuhari와 관련이 있습니다 ( http://c2.com/cgi/wiki?ShuHaRi ).
가장 큰 문제는 항상 바이 인입니다. 팀 또는 주요 개인이 프로젝트 관리, QA, 개발 등에서 구매하지 않은 경우 거의 실패 할 수 있습니다.
또 다른 관련 문제는 실제로 관련된 모든 사람들이 실제 스크럼이 무엇인지 아닌지 인식하게 만드는 것입니다.
프로젝트 관리가 실제로 이것을 변경 사항으로 개발자에게 직접 제공하고 내일이 될 것으로 기대하는 티켓으로 사용하는 환경을 보았습니다. 새로운 프로세스를 사용하고 있기 때문입니다. 이 상황에 있거나 스크럼을 구현하려는 다른 시도에 실패하고 입안에서 쓴 맛이 나는 사람. 이 사람들은 때때로 프로젝트를 탈선하려고 할 것입니다.
내가 본 또 다른 문제는 회의를 세우는 것입니다. 당신은 항상 스탠드 미팅 중에 앉고 싶은 사람을 얻을 것입니다 ... "나쁘게 돌아왔다"또는 무엇이든. 그것은 목표가 무엇을지지하는지에 대해 전혀 모르는 같은 사람인 것 같습니다. 그리고 정치 나 그 주말에 무엇을했는지는 말하지 않을 것입니다. 내가 찾은 회의를 세우는 것이 효과적인 의사 소통의 열쇠입니다. 다른 사람이 이러한 회의를 독에 빠뜨리지 않도록하는 것이 중요합니다.
management has actually taken this as a ticket to come directly to developers이것이 SCRUM 프로세스가 이해되지 않는 상황의 좋은 예입니다. 스프린트 도중에 팀은 새로운 이야기를 받아 들일 수 없습니다.
우리는 얼마 전에 스크럼으로 옮겼으며 솔직히이 시스템을 운영하는 경영진은 각 스크럼을 2 주 폭포 프로세스로 취급했습니다. 스크럼 규칙에 대한 준수는 그 자체가 프로세스가되었습니다!
이것이 내가 찾은 문제입니다. 모든 민첩한 방법론은 여러분에게 맞는 방식으로 효과적으로 작업 할 수있는 유연성에 관한 것이어야합니다. 프로세스에서 규정 한 방식이 아닙니다. 예를 들어, 우리는 2 주간의 스크럼을 가지고 있었고, 한 팀은 2 주가 좋은 일을하기에 충분하지 않다고 느꼈다고 말했습니다 (스크럼 데모의 종료로 인한 가동 중지 시간과 초기 요구 사항 검토가 아님). 주. 충격 공포! 스크럼 당 2 주가 이상적이며 품질 관리 절차에 문서화되어 있기 때문에 경영진이 거부했습니다.
스크럼은 민첩한 방법 중 가장 민첩하지 않은 방법 일 것입니다. 그 이유는 아마도 그렇게 유명했던 이유입니다. 당신은 당신이 좋아하지 않는 것들을 제거하기로되어 있지만, 나는 그렇게 생각하지 않습니다. 내 조언은 더 유연하고 적은 규칙 기반 규칙을 사용하고 대신 필요한 규칙을 추가하는 것입니다. 이 때문에 Crystal을 선호 합니다.
가장 큰 문제는 고객이 SCRUM 프로세스를 수락하고 민첩해야한다는 것입니다. 대부분의 고객은 프로젝트가 시작될 때 이것을 듣고 싶어합니다.
합리적으로 들리지만 애자일과는 절대적으로 호환되지 않습니다. 폭포 대신 애자일이 좋은 이유를 고객에게 설명해야합니다.
how much will it cost?하고 자세한 답변을 기대합니다. 이 문제에 대한 나의 대답은 항상 "결국 원하는 것을 정확히 알고 있다면 민첩성이 필요하지 않다는 것입니다. 코드 만 작성하면됩니다." 그러나 우리는 그것이 일어나지 않을 것이라는 것을 알고 있습니다. ;-)
SCRUM에 처음 갈 때 두 가지 큰 문제가있었습니다.
1) 실제로 제품 소유자가 없었습니다. 제품 소유자였던 사람은 그렇게하지 않기 때문에 우리의 상사는 역할을 수행해야했습니다. 그는 항상 실제로 답을 알지 못했기 때문에 이런 종류의 물건에 압착을 넣었습니다.
2) 우리는 외부 구성 요소를 설명하는 데 좋지 않았습니다. 처음 몇 번의 스프린트는 완전 자동화 된 테스트를 시작하고 실행하는 것과 관련이 있었으며, 사용중인 시뮬레이터를 자동화하는 데 반복적으로 어려움을 겪었습니다. 어쨌든 우리는 이것이 일어날 것이라는 것을 깨닫는 데 결코 능숙하지 않았습니다.
프로젝트에서 직면 한 주요 문제는 다음 스프린트에 대해 예상 한 후에 요구 사항 수집이 발생한다는 것입니다. 수락 기준에 따라 추정합니다. 요구 사항을 수집하는 동안 미세 조정 된 AC가 훨씬 더 커져 8 시간 동안 계획된 작업이 실제로 24 시간이라는 것을 알게되었습니다! 스프린트 백 로그를 변경하고 추정치를 수정하여 스토리를 줄일 수 있습니까? 아닙니다! 민첩한 스프린트 백 로그를 변경할 수 없습니다! 그것이 내 TL이 말하는 것입니다. 따라서 시간을 8 시간으로 추정 한 원래의 허용 기준에 따라 코딩하지 않아야합니다! 하나님! 아니! 당신은 그렇게 할 수 없습니다! 그것은 민첩하지 않을 것입니다!