저는 지난 4 년 동안 세 가지 프로젝트에서 SCRUM을 사용해 왔습니다. SCRUM의 장점 중 하나는 유연성과 적응성 (예 : 변화하는 고객 요구 사항에 대한 대응)입니다. 또 다른 장점은 경영진이 프로젝트 진행 상황을 쉽게 추적 할 수 있다는 것입니다.
SCRUM의 유연성은 장점이 될 수 있습니다. 예 웹 애플리케이션을 구현할 때 요구 사항이 매우 빠르게 변경되고 고객이 프로토 타입을 본 후 원하는 것을 실제로 이해합니다.
반면에 다른 종류의 소프트웨어 프로젝트 (예 : 항공 우주 분야)가 있습니다. 산업) 요구 사항이 상당히 고정되어있는 경우 : 요구 사항 사양 문서를 받고 6 개월 후에 작동하는 소프트웨어와 완전한 문서를 가지고 돌아와야합니다. 이런 종류의 프로젝트에서는 SCRUM이 제공하는 유연성이 필요하다고 생각합니다. 요구 사항에 대한 피드백을 얻기 위해 프로토 타입을 제작하고 고객에게 보여줄 필요가 없음) : 오히려 놀라 울 여지가 거의없는 각 프로젝트에 대해 반복해서 반복되는 매우 구조화되고 체계적인 접근 방식이 필요합니다.
SCRUM은 제안자들이 범용 소프트웨어 개발 방법론으로 간주합니까, 아니면 특정 범주의 프로젝트 또는 응용 분야에 특히 적합한 것으로 간주됩니까?
예 예를 들어, 저는 최근에 항공 우주 산업을위한 소프트웨어를 생산하는 회사의 웹 사이트를보고 그들이 V- 모델을 사용하고 있음을 알게되었습니다. SCRUM 제안자는 SCRUM이 이러한 종류의 프로젝트에 적합하지 않다고 말하거나이 회사가 SCRUM으로 전환을 시도해야한다고 제안할까요?
참고 이 포럼 독자의 의견을 묻지는 않지만 SCRUM 제안자 사이에서 확고한 의견이 무엇인지 알고 싶습니다. SCRUM이 범용으로 간주 되는가 아니면 특정 수업에 적합합니까? 프로젝트 만? 후자의 경우 어떤 종류의 프로젝트에 대해?
댓글
- stackoverflow.com 참조 / questions / 596916 / when-should-you-not-scrum 및 eweek.com/c/a/IT-Management/ …
- " 요구 사항 사양 문서를 받고 6 개월 후에 작동하는 소프트웨어를 가지고 돌아와야합니다. " 것은 신화입니다. 공식적으로 정의 된 언어 (기능적 요구 사항이 매우 명확하고 고정 된 것처럼 보이는 경우) 용 컴파일러와 같은 것을 빌드하더라도 구현할 항목을 결정하고 우선 순위를 지정해야합니다. 사용자와 논의 할 비 기능적 요구 사항이 있습니다. , 그리고 당신은 일을 해결하는 방법을 결정해야하는 여러 자유도를 가지고 있습니다. 따라서 민첩한 접근 방식은 이러한 종류의 프로젝트에도 적합합니다.
- " 따라서 민첩한 접근 방식은 그러한 종류의 프로젝트에도 적합합니다. " : 애자일이 더 유연 할 수 있지만 다른 방법도 유연합니다. 다른 방법이 충분히 유연하고 특정 프로젝트에 대해 애자일이 너무 유연 할 수 있습니다. 여기서 브레인 스토밍을 해보세요.
- " " 요구 사양 문서를 받고 6 개월 후에 다시 방문해야합니다. 작동하는 소프트웨어로 " 것은 신화입니다. " : 저는 ' 그렇게 생각하지 않습니다. . 고객이 버튼을보고 마음을 바꿨 기 때문에 웹 페이지의 버튼 레이블을 빠르게 변경할 수 있지만 비행기의 움직이는 부분을 제어하는 항공 전자 소프트웨어의 중요한 부분을 쉽게 변경할 수는 없습니다. 늦게 변경해야 할 수도 있지만 민첩한 방법이이를 관리하는 올바른 방법인지 또는 다른 방법 (예 : V- 모델)의 더 복잡한 반복이 필요한지 궁금합니다.
Answer
SCRUM은 대부분의 프로젝트와 팀 규모에 적합하지만 대규모 작업을 수행하는 대규모 팀에는 유용하지 않은 범용 방법론입니다. 프로젝트. 일부 프로젝트에 참여하는 사람의 수는 질서를 유지하기 위해 더 견고한 구조가 필요하기 때문에 애자일 방법론을 거의 불가능에 가깝게 만드는 것을 극도로 어렵게 만듭니다. 항공 우주 산업은 애자일 접근 방식이 항상 실행 가능하지 않은 대규모 프로젝트가있는 경향이있는 산업의 좋은 예입니다.
댓글
- 프로젝트가 SCRUM으로 수행하기에는 너무 크다고 간주되는 경우에 대한 정보 예를 들어 15 명으로 구성된 팀을위한 18 개월 프로젝트를 고려하십시오. 이러한 팀이 SCRUM에서 이익을 얻거나 V- 모델과 같은 다른 모델도 적합할까요? 내가 묻는 이유는 18 개월 이상 요구 사항과 구현이 완성되고 안정화 될 충분한 시간이 있고 SCRUM이 제공하는 유연성이 실제로 필요하지 않기 때문입니다.오히려 더 중장기적인 접근 방식이 여기에 적합합니다. 이에 대한 문헌이 있나요?
- @Giorgio 프로젝트 시간은 '별로 중요하지 않지만 15 명이면 충분하므로 여러 스크럼을 만들면 도움이됩니다. 그룹이지만 여전히 SCRUM의 관리 가능한 범위에 있습니다. 커뮤니케이션 관리가 팀의 정규직이되기 시작하면 V- 모델을 살펴볼 시간입니다.
- 진심인가요? 우리는 전에 V-model을 사용하고 있었고 SCRUM으로 전환했습니다. 사실 우리는 ' 정확히 이러한 이유로 인해 느려 졌다는 느낌이 있습니다. 부기가 너무 많습니다.
- @Giorgio는 모든 스위치에 해당되는 Pierre 303과 같은 새로운 제품은 몇 번의 스프린트 후에 더 나은 아이디어를 얻었다 고 말했기 때문에 처음에는 느려질 것입니다.
- @Giorgio-' 사실입니다. 많은 " 민첩한 " 방법론이 예상되는 무거운 프로세스보다 더 무겁습니다. ' 교체! 분명히 이것은 그들이 틀렸다는 것을 의미합니다. ' 애자일은 가볍고 자유롭고 외부인에게는 혼란스러워 보입니다. 팀이 매우 조직화되고 규율이 있어야하지만 일반적으로 ' 이점이 있습니다. 대신 Alistair Cockburn (Agile의 창립자 중 한 명)의 Crystal을 사용해보십시오.
Answer
모든 유형의 프로젝트 ! 대규모 프로젝트와 소규모 프로젝트 모두에서 잘 작동합니다.
사람들은 결혼식, 이사 등을 계획하는 데 사용했습니다. 따라서 소프트웨어 프로젝트뿐 아니라
저는 확고한 신념을 갖고 있습니다. 스크럼과 같은 접근 방식의 이점을 얻을 수있는 많은 비즈니스 운영이 있습니다.
댓글
- 자신의 의견이 공유됩니까? SCRUM 제안자, 즉 SCRUM을 성문화하고 홍보 한 저자에 의해?
- 예-최근 Cheryl Hammond가 언급했습니다 ( blog.bsktcase.com ), Northwest Cadence의 ALM 컨설턴트가 " A Scrum Masters Day In The Life : The New Visual Studio ". 여기에서 볼 수 있습니다. msevents.microsoft.com/CUI/ …
답변
Scrum은 방법론이 아니라 프레임 워크입니다.
Scrum이 가장 잘 작동합니다. c에서 5 ~ 9 명의 개발자 가 iv에서 작업하는 다기능 팀 id = “f0778fd50c”>
중대형 규모의 프로젝트 (4 개월에서 수년까지). 프로젝트가 더 큰 경우 Scrum of Scrums 로 확장 할 수 있습니다.
여기서는 교차 기능에 대해 논의하지 않겠습니다. 공식 스크럼 가이드 에서 팀 규모에 대해 설명하는 내용은 다음과 같습니다.
최적 개발 팀 규모는 민첩성을 유지할 수있을만큼 작으며 중요한 작업을 완료 할 수있을만큼 큽니다. 개발 팀 구성원이 3 명 미만이면 상호 작용이 줄어들고 결과적으로 생산성 향상이 줄어 듭니다. 소규모 개발 팀은 스프린트 중에 기술 제약에 직면 할 수 있으며, 이로 인해 개발 팀은 잠재적으로 해제 가능한 증분을 제공 할 수 없습니다. 9 명 이상의 회원을 보유하려면 너무 많은 조정이 필요합니다. 대규모 개발 팀은 경험적 프로세스를 관리하기에는 너무 많은 복잡성을 생성합니다. 제품 소유자 및 스크럼 마스터 역할은 스프린트 백 로그 작업도 함께 실행하지 않는 한이 수에 포함되지 않습니다.
스프린트는 약 1 개월입니다.
스프린트는 한 달로 제한됩니다. Sprint의 지평이 너무 길면 빌드중인 항목의 정의가 변경되고 복잡성이 증가하며 위험이 증가 할 수 있습니다. 스프린트는 적어도 매월 목표에 대한 진행 상황을 검사하고 조정하여 예측 가능성을 지원합니다. 스프린트는 또한 위험을 한 달의 비용으로 제한합니다.
소규모 프로젝트에서 반복적 인 프로세스를 기반으로하는 프레임 워크를 사용하는 것은 의미가 없다고 생각합니다. 4 개월 이상. 4 개월 = 4 회 스프린트. 또한 3 회 스프린트 후에 더 정확한 속도 를 얻는다는 점을 고려해야합니다.
그렇습니다. , 저는 개인적으로 소규모 프로젝트를 위해 제한된 버전의 Scrum을 사용합니다.하지만 그때는 그것을 Scrum이라고 부를 수는 없습니다. 이 특별한 경우에는 프레임 워크 구현에 Scrum의 핵심 원칙을 사용하고 있습니다.
Answer
, SCRUM을 애자일 관행을 구현하기위한 하나의 지침 세트라고 생각하십시오. 프로젝트를 수행하는 방법에 대한 “성스러운 책”이라고 생각하지 마십시오. 예를 들어 꾸준한 작업 흐름이 필요한 많은 프로젝트의 경우 Kanbam이 더 적합합니다.
애자일 프로젝트는 고정 된 종료 날짜 또는 고정 비용이 필요한 프로젝트를 수행하는 곳에서 떨어지는 경향이 있습니다. 이러한 프로젝트는 여전히 애자일 방법을 사용하여 수행 할 수 있지만 모든 것을 미리 계획해야합니다. 목표에 도달 할 가능성이 일반적인 애자일 방식이 아닌지 판단합니다. 애자일에서는 할 일이 부족하거나 할 시간이 없을 때까지 계속 일하는 경향이 있습니다. 대부분의 프로젝트에서 이것은 괜찮습니다. 프로젝트 중에 요구 사항이 변경 될 수 있습니다.
댓글
- 우리 팀에서 애자일을 수행하는 방법은 고객이 스토리에 우선 순위를 설정하도록하는 것입니다. (가장 중요한 것부터 가장 중요한 것까지) 포커 카드를 사용하여 사용자 스토리를 추정하고 마감일까지 구현할 수있는 많은 스토리를 계획합니다. 더 빠른 것으로 판명되면 우선 순위 목록의 다음 항목에 따라 더 많은 이야기를 예약합니다.
- 몇 달 후 다시 답변을 읽었는데 실제로 정말 깨달았습니다. +1