스크럼 프로세스 관리 - 팁, 함정, 아이디어

Question

나는 한동안 팀과 함께 스크럼을 해왔지만 몇 가지 이유로 지저분 해 보인다. 나는 그들이 변화 될 수있는 방법에 대해 생각해 왔으며 여기에서 제기하고자하는 몇 가지 질문을 가지고있다.

먼저 스크럼 프로세스에서 테스터, 디자이너 및 비 개발자의 역할은 무엇이되어야합니까? 다른 팀원과 동등하다면 몇 가지 문제가 발생합니다. 디자이너와 테스터는 일반적으로 개발이 완료된 후 작업을 수행하므로 이러한 종속성으로 인해 스프린트를 적절하게 계획 할 수 없습니다.

두 번째로 마감일이 있습니다. 이는 엄격하고 우선 순위에 많은 영향을 미칩니다. 최종 결과는 최종 변경이나 스프린트가 끝날 때의 나쁜 결과로 인해 스프린트 중간에 백 로그가 변경된다. 우리는 또한 고객 지원과 같은 비 기술적 인 작업이 많습니다. 그 동안에는 많은 작업이 계획되어 있기 때문에 계획을 세울 수 없습니다. 그래서 팀 구조, 문화 및 관행이 Scrum과 호환되지 않는 것으로 생각하고 있습니다. Scrum for me는 단일 소프트웨어 제품을 개발하는 팀을위한 프로세스 관리 도구입니다.

더 구체적이고 복잡한 시나리오에서 어떻게 적용 할 생각이십니까? 공유 할 경험이 있습니까?

Answer 1

일반적으로 테스터 및 문서 작성자 (및 기타 비 개발 업체)는 모두 스크럼 팀의 동등한 회원입니다. 배후의 아이디어는 위험을 최소화하는 것입니다.

완전히 테스트되고 문서화 된 잠재적으로 선적 가능한 제품을 포함하는 done 정의를 요구하면 각 스프린트가 끝날 때 프로젝트가 함께 강제 실행됩니다.

dev가 AFTER 될 때까지 테스트가 시작되지 않으면. 작업이 완료되면 개발자가 많은 버그를 발견하게됩니다. 이제는 버그를 수정해야합니다. 버그가 상호 작용하고 일반적 규칙은 "버그 수정 비용은 시간이 지남에 따라 기하 급수적으로 증가하기 때문에 매우 느리고 비쌉니다." 일찍 잡은 버그는 저렴하고 쉽게 고칠 수 있으며, 늦은 버그는 악몽입니다.

개발을위한 단계에서 테스트 (및 문서)를 이동하려는 이유가 여기에 있습니다. 그리고 지금 당장 당신은 묻고 있어야합니다, 어떻게! 테스트가 느리며 dev와 함께 단계별로 어떻게 움직일 수 있습니까?

대답은 자동화입니다. SCRUM은 항상 XP 또는 Agile 위에 위치하며, 둘 다 우수한 단위 테스트 적용 범위와 TDD를 요구합니다. 조심해야 할 또 다른 문제가 있습니다. 기능 개발자는 단위 테스트와 시스템 테스트를 모두 작성해야합니다. 모든 테스트 자동화는 기능 개발자가 수행해야합니다. 팀. 일부 장소는 기능을 dev에 분할. 자동화 개발자. 그리고 그것은 나쁘다.

이제 자동 테스트를 수행하고 하루에 한 번만 실행하십시오. 그리고 분명히 지속적인 통합을 올바르게 실천하고 있습니까? 이것은 테스터의 작업 부담을 엄청나게 줄여줍니다. 그리고 이것이 테스팅이 dev와 함께 유지되는 방법입니다. 한 가지 더, 테스터는 현재 자동화하기가 불가능하거나 매우 어려운 정말로 어렵고 창의적인 작업을 수행합니다. 버그를 발견 할 때마다 버그를 노출시키는 데 걸리는 시간은 자동화되어 있으며 일일 회귀 테스트의 일부가됩니다 . 휴, 긴 대답이야!

이제 질문의 두 번째 부분을보십시오. 스크럼은 규율에 관한 것입니다. 스프린트는 짧고 스프린트 중에는 백 로그가 변경되지 않아야합니다. 기술적이지 않은 작업은 고객 지원 팀에 맡겨 져야하며 스크럼을 할 수 있습니다. 당신의 문화와 관행이 스크럼과 양립 할 수 없다는 소리가 나면 당신 말이 맞습니다.

경험상 Scrum/Agile으로 전환하는 것은 매우 고통스럽고 스트레스가 많은 프로세스이며 대부분 전환 시도가 실패합니다. 성공의 열쇠 중 하나는 경영 팀에서 스크럼/애자일의 챔피언입니다. 당신의 설명에서 그것은 당신이 하나도 가지고 있지 않은 것처럼 들립니다.

스크럼에는 비용과 이점이 있지만, 그렇게하는 것은 거의 효과가 없거나 비용이 들지 않는다는 것을 의미합니다. 스크럼을 잘못하고 나쁘게 만들고 있다면 스크럼을 전혀하지 않는 것이 나을 것입니다.

Answer 2

변경 사항을 바탕으로 스프린트 백 로그에 변경 내용을 추가하면 안됩니다. 스프린트가 끝날 때까지 제품 백 로그로 이동하고 무시해야합니다.

귀하는 마감일을 스프린트와 조정해야합니다. 스프린트 중반에 은퇴하는 것이 허용되지만 새로운 것을 소개하지는 않는다고 생각합니다.

스프린트 중간 작업을 많이 추가하는 경우 스프린트가 너무 길어질 수 있습니다. 각 스프린트에서 약 20 일간의 작업을 목표로하고 있다는 것을 기억하십시오. 더 이상 설명하는 문제가 발생하기 시작합니다.

테스터는 모든 민첩한 프로세스에 중요하지만 실제 작업이없는 사람이 다음 작업을 선택하는 경우 스크럼에 적합하지 않습니다. 작업과 사람 간의 연관성을 선택하려고 시도하는 것은 일정에 빠지기 시작합니다. 모든 일은 피하려고했습니다!

테스터가 개발자와 가까운 거리에서 작업하는 경우 작업 항목이 실제로 완료되었는지 여부를 판단하는 데 도움이 될 수 있습니다.

Answer 3

먼저 스크럼 프로세스에서 테스터, 디자이너 및 비 개발자의 역할은 무엇이되어야합니까? 다른 팀 구성원과 동등한 경우 몇 가지 문제가 발생합니다. 디자이너와 테스터는 일반적으로 개발이 완료된 후 작업을 수행하므로 이러한 종속성으로 인해 스프린트를 적절하게 계획 할 수 없습니다.

개발 의존성으로 인해 디자이너와 테스터가 스프린트를 계획 할 수 없다면 개발 계획이 올바르게 계획되지 않았 음을 의미합니다. 그 문제를 해결해야합니다.

팀은 "작업 B는 작업 A가 먼저 수행되어야합니다. 작업 A는 8 시간이 소요되고 작업 B는 4 시간이 걸릴 것입니다"라고 말할 수 있어야합니다. 작업 견적이 정확하다면 종속성은 전혀 문제가되지 않습니다.

두 번째로 마감일이 있습니다. 이는 엄격하고 우선 순위에 많은 영향을 미칩니다. 최종 결과는 최종 변경이나 스프린트가 끝날 때의 나쁜 결과로 인해 스프린트 중간에 백 로그가 변경된다.우리는 또한 고객 지원과 같은 많은 비 기술적 인 작업을 수행해야합니다.이 작업은 그 동안 많이 이루어져야하므로 계획대로 진행될 수 없습니다.

이 경우 문제는 사용자가 스크럼을 사용하고 있지 않다는 것입니다. Scrum이 작동하는 유일한 방법은 경영진이 프로세스를 완전히 구매하는 경우입니다. 즉, 개발자가 계획 한 스프린트 작업을하고 스크럼이 수행하는 방법을 통해 새로운 작업을 추가하는 동안 개발자를 30 일 동안 혼자있게 만드는 것을 의미합니다. 제품 목록에 소원 목록 항목을 추가 한 다음 스프린트 계획 중에 개발자와 이해 관계자는 다음 스프린트에서 수행 할 작업에 동의합니다.

일반적인 개발을 방해하는 고객 지원 문제가있는 경우 팀을 나눠주고 스크럼에서 개발 작업을 전담하는 그룹을 하나 만들어야하며 고객 지원 문제를 처리하는 다른 그룹이 있어야합니다. 그런 다음 각 스프린트의 끝에서 사람들을 앞뒤로 돌려 보낼 수 있습니다.

Answer 4

먼저 Scrum을 전혀 사용하지 않고 있지만 일부 프로세스는 사용하지 않을 수도 있습니다.

디자이너와 테스터는 일반적으로 개발이 완료된 후 작업을 수행하므로이 종속성으로 인해 스프린트를 적절하게 계획 할 수 없습니다.

작업 종속성에는 관계가 없으므로 마녀가 거의 발생하지 않으며 적절한 계획을 세울 수 있습니다. 스프린트 계획에서 팀은 완료 정의와 관련된 이야기를 추정해야합니다. 스토리를 디자인하고 테스트하는 것을 포함하고 실제로해야한다면 스토리 허용 기준을 달성하는 데 필요한 노력의 추정에는 설계 및 테스트 작업이 포함되어야합니다.

최종 결과는 최종 변경으로 인해 스프린트 중간에 백 로그가 변경되거나 스프린트가 끝날 때 잘못된 결과가 발생합니다.

스프린트 길이가 더 넓어 보이는 것 같습니다. 왜 더 짧게하려고하지 않니? 좋은 스프린트 길이는 스프린트에서 변경을 유지할 수있는 길이입니다. 나는 1 주일이 걸릴 것이라고 생각한다.

그리고이 동작은 장애물을 제거하지 않으므로 스크럼 마스터가 제대로 작업하지 못한다는 것을 보여줍니다.