정의 된 역할을 가진 팀에서 Scrum을 작동시키는 방법은 무엇입니까?

일부 배경 정보

사내 소프트웨어 개발 팀의 일원입니다. 그것은 구성

• 5 명의 개발자 (2 년에서 5 년 사이의 경험을 가진 저는 그 중 하나입니다)
• 구현 담당자 3 명 (소프트웨어 배포 및 교육 수행)
• 그리고 1 명의 프로젝트 관리자.

우리는 중소 규모의 프로젝트를 많이 개발하며, 그 일정은 보통 겹칩니다. 개발은 다음과 같습니다.

1. "클라이언트"는 초기 요구 사항을 제공합니다.
2. 상기 사양에 따라 시스템을 개발
3. 상기 시스템을 "클라이언트"에게 제시
4. "클라이언트"는 상기 프리젠 테이션에 기초하여 추가 요구 사항을 제공
5. "클라이언트"에 새로운 요구 사항이 없거나 배포 대상 날짜가 끝날 때까지 2-4 반복
6. 시스템 설정 및 배포

이것은 마감일을 대부분 처리하는 "클라이언트"이고 (프로그래머 및 PM.SE에서 여기에서 볼 수있는 붉은 깃발) 사실과 함께 우리는 명확한 개발 방법론을 따르지 않습니다. 카우보이 코딩, 유지 관리 할 수없는 코드 및 생산 과정에서 발생하는 버그 등이 있습니다. 우리가 스크럼과 같은 애자일 기반 방법론을 채택하기로 선택한 이유입니다.

왜 스크럼인가?

관리자의 주도권이었으며 현재 상황에서 모든 사람들이 동의 한 것으로 보입니다.

스크럼의 문제

Scrum의 일부 요소는 현재 Agile 개발자의 "전역"이라는 문제를 쉽게 해결할 수없는 현재 설정과 충돌합니다. 배포 팀은 프로그래밍 방법을 모르며 개발자는 평균 이하의 커뮤니케이션 및 교육 기술을 보유하고 있습니다. 이 라인업은 곧 변경되지 않을 것입니다.

질문

방법론으로서 Scrum의 효과에 영향을 미치나요? 보상하기 위해 다른 변경이 필요합니까? 아니면 생각을 완전히 버리고 다른 방법론에 대해 생각하는 것이 더 좋을까요?

실제로 현재 작업 방식이 생각보다 스크럼에서 멀어지지 않았습니다.

Scrum에서는 초기 요구 사항 세트를 가져 와서이를 구현하고 결과를 시연하며, 데모를 기반으로 새로운 요구 사항을 제공 할 수 있거나 이해 관계자는 더 이상 개발할 필요가없는 제품이 충분하다고 판단 할 수 있습니다.
당신이 말한 "클라이언트"는 스크럼에서 제품 소유자의 역할을 맡을 수 있습니다 (이미 프로젝트 내 우선 순위를 설정하고 롤아웃 준비시기를 결정함으로써 이미 그 역할을 수행하는 것으로 보입니다).
큰 변화 중 하나는 반복의 길이 일 수 있습니다. 스크럼에서 반복은 1 주에서 4 주 사이 지속됩니다.

팀 구성 및 전담자 오류에 대해 스크럼은 모든 사람 이 전담 자라고 요구 하지는 않습니다 . 스크럼은 팀 전체가 제품을 요구 사항 목록에서 배포 가능한 제품으로 가져 오는 데 필요한 모든 역량을 갖추도록 요구합니다.
귀하의 상황에서 하나 이상의 개발자 (주로 구현 및 테스트 작업을 수행)로 구성된 프로젝트 당 팀과 쉽게 구현할 기능에 대한 매뉴얼 및 교육 자료 작성에 중점을 둔 "구현 직원"의 구성원을 쉽게 확인할 수 있습니다. 개발자들이 지금 구현하고 있습니다.

클라이언트 / 제품 소유자가 배포에 대한 승인을 얻은 후에는 스크럼 팀의 작업이 대부분 완료되므로 개발자는 다른 프로젝트로 이동하고 (배포 후 문제를 해결하기 위해 필요할 때만 사용 가능) 구현 직원은 교육 수행 및 롤아웃 지원으로 전환 할 수 있습니다.

해당 릴리스에 필요한 기능에 충분한 유연성이있는 한 최종 기한이 있다는 사실은 실제 문제가 아닙니다.

대안을 요청하므로 eXtreme Programming (XP)을 말씀 드리겠습니다. 특히 쌍 프로그래밍이 도움이 될 것이라고 생각합니다.

서로 다른 기술을 가진 사람들을한데 모으면 커피 만들기, 테스트, 교육 등 어떤 기술에 상관없이 팀에 기술을 전파 할 수 있습니다.

그러나 솔직히 말하면 SCRUM이 그렇게 멀리 들리는 것처럼 들리지 않습니다. SCRUM의 일부는 유연하고 팀에 가장 적합한 것을 찾고 있습니다. XP의 일부는 팀을 존중하고 적응하는 것입니다. 어쩌면 100 년 안에 우리는 단단하고 빠른 규칙을 가지고보다 완전하게 발전된 직업을 가질 수도 있지만 (지금은 의심 스럽지만) 현재로서는 여러분에게 맞는 일을하는 것이 전부입니다. 중요한 것은 피드백 루프를 갖는 것입니다. 무언가가 효과가 없다면, 팀은 그것에 대해 논의하고 그들이 효과가있는 것을 찾을 때까지 새로운 것을 시도해야합니다.

정의 된 역할을 가진 팀에서 Scrum을 작동시키는 방법은 무엇입니까?

그냥 해. 스크럼 가이드 에 따르면 모든 사람이 개발자이지만 지구상에서는 다시 다른 사람들이 다른 것들을 테이블에 가져올 것입니다. 나는 어떤 사람들은 실제로 테스터이고 다른 사람들은 소프트웨어를 작성하라고 제안했을 때 거의 무모 해졌다 .

해결하고 싶은 것들 :

스프린트

초기 개발 단계에 이어 표면적으로 스프린트 (sprint)하는 일련의 단계가있는 것 같습니다. 이것을 깨는 것을 고려하십시오. 클라이언트는 무언가를 일찍 보게 될뿐만 아니라 개발 이정표가 발생할 때 더 나은 느낌을받을 수 있습니다.

고정 마감일

이것은 몇 번이고 자라며 실제로 내가 현재 일하는 개발자의 측면에서 지속적인 가시입니다. 스크럼은 스프린트에 대한 추정치를 설정합니다. 예, 일련의 스프린트 후 대상을 공격 할 수 있지만 일단 클라이언트가 초기 버전을 주시하면 범위가 크게 늘어날 수 있습니다. 이것은 그 자체로는 문제가되지 않지만, 클라이언트는 추후 스프린트에서 추가 작업이 진행될 것이며 알려진 요구 사항을 초과한다는 것을 인식해야합니다.

당신은 당신이 시작하고 거기서부터 반복 할 수 있기 때문에 당신의 상황은 칸반과 더 잘 어울릴 것입니다. 즉, 현재 프로젝트에 방해가되는 빅뱅 소개가 없을 것입니다. 이사회에서 작업을 시각화하고 회고 및 일일 회의와 같은 일부 관행을 채택하는 것만으로 시작하십시오.

규범이 아니기 때문에 스크럼보다 약간 더 조심해야합니다. 따라서 적절한 민첩한 사고 방식을 익히는 대신 이전에하던 일로 되돌아가는 경향이 있습니다.

완전한 스프린트를 위해 프로젝트를 진행하는 안정적인 사람들이 없기 때문에 스크럼은 겹치는 별도의 프로젝트에서 잘 작동하지 않습니다. 따라서 자세한 정보와 같은 개념은 당신을 우울하게 할 것입니다.

그러나 고객에게 최고의 비용 / 이익을 가져다주는 이야기를 먼저 읽고 완전 자동화 된 테스트를 포함하여이를 구현하기에 충분한 품질로 구현하는 것은 다음 이야기를 진행하기 전에 유용한 개념입니다. 마찬가지로 스토리가 "완료"된 것으로 간주되기 전에 스토리를 위해 작성된 모든 코드를 다른 개발자가 검토해야합니다.

구현 담당자가 교육 및 참조 문서를 작성해야한다고 가정하고 코드를 작성하기 전에 각 스토리에 대해 첫 번째 초안을 작성할 수 있으므로 합격 테스트가됩니다.

구현 스태프의 입력이 개발자에게 가장 도움이되는 각 프로젝트가 시작될 때 이전 프로젝트의 배포에 100 % 헌신한다는 것을 알게 될 것입니다. 따라서 개발자가 현재 프로젝트의 코드를 작성하는 동안 구현 담당자가 다음 프로젝트에 대한 기사 및 사용자 문서를 작성하는 작업을 수행 할 수 있는지 고려하십시오.

테스트에 사용 된 예제를 작성하는 구현 직원과의 "행동 주도 개발"이 효과가있을 수 있습니다.

따라서 도움이되는 약간의 Scrum이 있지만 Scrum을 사용하는 대신 Scrum에 기대어보십시오.