1 ~ 2 명의 개발자가 Agile / Scrum을 사용할 수 있습니까?

내가 지금까지 읽고 연구 한 모든 내용은 Agile / Scrum이 약 4-6 명의 팀과 어떻게 잘 작동하는지 설명합니다.

현재 상점에는 약 8 명의 개발자가 있지만 프로젝트의 규모와 지원하는 부서의 수를 고려할 때 주어진 프로젝트에 1 명 또는 2 명 이상의 직원이 할당되지 않습니다.

1 ~ 2 명의 개발자 팀과 함께 Agile / Scrum을 계속 사용할 수 있습니까? 관리자에게이 방법론을 시작하기 위해 노력하고 있지만 소규모 개발자 승무원을 위해 일을 확장하는 방법을 설명하거나 더 많은 회원을 확보하도록 설득 할 수 있어야합니다 계획.

프로젝트에서 특정 민첩한 원칙을 사용할 수 있으며 스크럼을 사용할 필요가 없으며 가장 적합한 것을 사용 하십시오 . 일부 XP 방법과 일부 스크럼 관행에서 이점을 얻을 수 있습니다. 그러나 아마도 "책으로", 1-2 명의 사람 팀은 작은 오버 헤드 스크럼이 가져 오기에는 너무 작을 것입니다. 회고를 포기하지 말고, 문제에 대해 토론하고 그에 대한 해결책을 찾는 데 시간을 투자 할 가치가 있습니다.

네, 한 사람이 스크럼 / 애자일 원칙을 사용할 수 있습니다. 개인 생산성을 원한다면 Pomodoro 기술 또는 GTD를보십시오 .

민첩한 기술은 소규모 팀에 적합합니다. 대규모 팀 일수록 커뮤니케이션을 관리하기가 더 어려워집니다. 1 명 또는 2 명이 프로젝트 (및 고객)를 개발하면 매우 민첩하게 작업 할 수 있어야합니다. 민첩한 시작을 민첩한 시작으로 읽는 것이 좋습니다 . 스크럼의 경우 트렌치 에서 스크럼 을 살펴 보는 것이 좋습니다 . 칸반 은 지금 유행에있는 것처럼 보이고 개인 칸반 도 있습니다!

내가 당신이라면 Kanban을 사용하여 내 작업과 우선 순위를 관리하고 시각화 할 것이며 XP 중심 관행 중 일부를 채택 할 것입니다. 나중에 회고하는 동안 필요하다고 느끼는 더 많은 관행을 식별 할 수 있습니다.

칸반은 매우 규범 적입니다. 이 모든 정말로 필요는있다 :

1. 워크 플로우를 시각화합니다
2. 진행중인 작업을 제한합니다 (특히 귀하의 경우에 유용합니다)

아이디어는 유용하다고 생각되는 다른 방법을 사용하고 XP는 이러한 방법의 훌륭한 소스입니다.

면책 조항 : 나는 이것을 시도한 적이 없지만 같은 위치에 있다면 시도해야 할 일 목록의 최상위에있을 것입니다.

물론 의심의 여지가 없습니다. 개별 개발자가 민첩하게 작업하는 방법에 대한 자세한 내용은 Pragmatic Programmer 책을 확인하십시오. 개별 작업에 대한 스크럼 리소스는 사용하기 어렵지만 반복 개발의 기본 개념은 모든 규모의 작업 그룹에 적용될 수 있습니다.

http://www.pragprog.com/the-pragmatic-programmer

다양한 민첩한 방법의 기술을 사용할 수 있지만 Scrum Guide에 설명 된대로 역할을 채울 수 없으므로 Scrum을 사용해서는 안됩니다 . 스크럼은 4 ~ 11 명으로 구성된 팀을 위해 설계되었습니다. 그러나 스크럼을 포함한 많은 민첩한 방법론이 시작점을 제공 할 수 있습니다.

나는 최근에 스크럼에 관한이 책을 읽었습니다 : Scrum을 이용한 애자일 프로젝트 관리

저에게는 스크럼에 관한 저의 첫 번째 책이었고 저에게도 도움이되었으며, 근본적인 원리가 무엇인지에 초점을 맞췄습니다. 이러한 원칙 중 일부는 1-2 명 팀에 적용되고 도움이 될 수 있다고 생각합니다.

예, 두 명의 개발자 만 민첩한 방법을 사용할 수 있지만 항상 전담 고객 / 제품 관리자가 필요합니다. 개발자 한 명만 있으면 개인적으로 팀에서 일하기를 원하지만 실제로 프로그램을 쌍으로 묶을 수 없으므로 모든 코드 공유 기회를 놓치게되므로 말을하지 않습니다. 4-6 명의 개발자와 1 명의 제품 관리자는 민첩한 프로젝트를위한 완벽한 크기입니다. 그것보다 더, 그리고 하위 팀은 어떤 종류의 목적을이기는 경향이 있습니다.

나는 당신의 정확한 상황을 알지 못하지만 동시에 많은 프로젝트를 실행 하고있는 것 같습니다 . 제 제안은 동시 프로젝트의 양을 줄이려는 아이디어를 제시하고 대신 두 팀이 각각 하나의 프로젝트를 수행해야한다는 것입니다. 이것이 상황을 개선하고 민첩한 프로세스를 쉽게 적용 할 수있는 첫 번째 단계입니다.

작업 전환 및 프로젝트 휴지통의 나쁜 점에 대해 많은 이야기가 있지만 실제로는 좋은 점이 없습니다. 이제까지.

나는 2 명의 개발자가 명시 적으로 수행하지 않더라도 본능적으로 애자일과 같은 시스템을 기본값으로 생각합니다. 그들은 자연스럽게 서로 대화하고 자신의 PO와 반복됩니다.

다른 방법으로 살펴보십시오.

같은 Scrum 팀 의 개발자 8 명을 모두 고려해 보 시겠습니까? 그렇게하면 프로젝트간에 크로스 토크 효과를 얻을 수 있습니다. 어쩌면 특정 프로젝트에 사람들을 투입하지 않아도 될까요?

더 많은 사람들이 상점에 추가되면 팀을 두 개의 작은 팀으로 나눌 수 있습니다.