팀이 안정적이지 않을 때 애자일 개발을 어떻게 관리하나요?[닫은]

Question

나는 몇 년 동안 내 프로젝트에 민첩한 접근 방식(XP 및 스크럼)을 사용해 왔으며 훌륭한 결과를 얻었습니다.그러나 모든 경우에 개발팀의 모든 구성원은 프로젝트에 100% 헌신했습니다.

이제는 팀이 불안정할 때 이런 일을 해야 하는 상황이 됐다.예를 들어, 한 번의 반복에서는 4명이 작업하고 다음 반복에서는 2~3명만 작업할 수 있습니다.

나는 이것이 많이 변동하고 안정적이지 않기 때문에 일반 속도 접근법을 사용하여 추정하는 것을 어렵게(또는 불가능하게) 만든다는 것을 알고 있습니다.다음은 각 반복이 끝날 때마다 릴리스할 수 있다고 실제로 기대할 수 없다는 것입니다.

어쩌면 여기에는 또 다른 접근 방식이 필요할 수도 있습니다.백로그에서 물건을 가져와서 뒤죽박죽하고 가능할 때마다 릴리스하세요.나 정말 그건 싫지만...

이견있는 사람?

Answer 1

질문에서 나는 당신이 일부 개발자 (아마도 2) 100%가 프로젝트에 헌신했으며 일부 (다른 2-3)는 한 번에만 참여한다고 가정합니다.

당신이 할 수있는 한 가지는 100% 커밋 된 핵심 개발자와 다른 모든 사람들을 위해 다른 프로세스를 설정하는 것입니다. 핵심 사람들에게 정상적인 애자일 프로세스를 사용하고 정상 반복주기에서 작업을 해제하십시오. 비 코어 사람들의 경우 계획을 거의 계획하지 않고 자신의 (및 귀하의) 추정치가 시간의 방법이라고 가정합니다. 이상적으로는 그들의 변경 사항을 핵심 구성원에 의해 안정적인 코드 브랜치로 분리하고 병합해야하지만 모든 프로젝트의 아키텍처와 팀 역할이이를 허용하는 것은 아닙니다.

요점은 혼돈의 원천을 분리하고 분리하고 프로젝트의 중심을 남겨두고 팀의 영향을받지 않는 것입니다.

Answer 2

어쩌면 민첩한 접근 대신 다른 사람과 속도를 늦출 수 있습니다. 반복적이고 증분 접근법. 몇 주 안에 반복을 측정하는 대신, 팀에서 사람들을 계속 추가하고 떨어 뜨리면 더 긴 반복 (몇 달 안에 측정)이 더 좋습니다.

그렇다고해서 여전히 민첩한 기술을 사용할 수 없다는 의미는 아닙니다. 나는 여전히 당신의 백 로그를 유지하고 차트를 태울 것입니다. 2 주마다 릴리스하는 대신 6 주마다 (~ 2 개월) 석방 될 것입니다. 새로운 개발자가 더 숙련 된 개발자와 합류하고, 쌍 프로그래밍을 사용하거나, 새로운 개발자에게 버그 수정을 할당하거나, 새로운 개발자에게 단위 테스트를 유지하여 코드 기반을 배우도록 할당하십시오.

Answer 3

속도는 추정 일뿐입니다.

순진하게, 당신이 주어진 속도가 있다면 v 4 명의 개발자로 구성된 팀과 함께, 속도로 반복을 예약하십시오. (v/4)*number_of_developers

잃어버린 회원이 평균보다 특히 강하거나 약한 경우이 가치를 퍼지 할 수 있습니다.

이것은 기본적으로 무엇입니다 PivotalTracker 팀 강도 메트릭으로 수행합니다.

Answer 4

따라서, 당신은 지속적으로 변화하는 팀 규모의 프로젝트를 가지고 있으며, 당신의 상사는 당신이 그에게 얼마나 오래 걸리는지에 대한 정확한 추정치를주기를 원합니까? 정확하고 정확한 차이점을 염두에 두는 한이 작업을 수행 할 수 있습니다. 귀하의 정밀도는 주로 항목의 수와 각 항목의 세분화 (분해)에 달려 있습니다. 항목이 많을수록 많은 수의 법칙이 더 많이 작동하여 평균적으로 과소 평가됩니다.

정확도는 자신감의 함수입니다. 추정치는 단일 포인트 값이 아니며 신뢰의 백분율을 가진 숫자가있는 범위입니다. 예를 들어, 적절한 추정치는 "2 주 (2 주)가되지 않을 것입니다."2 주 50% 신뢰, 4 주의 80% 신뢰도 "가 될 것입니다.

내가 원래 게시물에서와 같이 임의로 관리되는 프로젝트에 대한 견적에 대한 견적을 제공하는 불가능한 과제로 할당 된 사람이라면, 할당 된 최소 수의 사람들 (예 :,” 48 ~ 66 주 2 명의 개발자 (50% ~ 80% 자신감) ") 및 할당 된 평균 사람들과 관련된 범위 (예 : 5 명의 개발자와 함께 25 ~ 45 주 [50% ~ 80% 자신감]). 그리고 평균 수의 낮은 수치와 함께 최소 수의 높은 수치 (예를 들어, 2 ~ 5 개 개발자 [50% ~ 80% 자신감] ")의 높은 수치 (예 : 25 ~ 66 주), 심지어 I '를 사용하십시오. d 면책 조항을 입력했습니다 ( "컨텍스트 전환으로 인한 손실 시간에 대해 10% + 10%").

더 나은 방법으로, 나는 왜이 배열이 예의 바르고, 하위 최적 이었는지, 그리고 멀티 태스킹이 프로젝트 지옥으로가는 길의 기본 주요 표지판 인 이유를 정확하게 설명합니다.

다른 사람이 제안한 것처럼, 워크 플로를 반복 기반에서 흐름 기반 (Kanban)으로 변경하는 것은 좋은 전략 일 수 있습니다. Kanban을 사용하면 백 로그에서 항목의 우선 순위를 변경하여 프로젝트 우선 순위가 변경됩니다. 팀이 항목을 잡으면 일반적으로 완료됩니다 (워크 플로를 통해 모든 길을 흐르면 이해 관계자는 진행중인 작업으로 나사로 팀을 방해 할 수 없습니다). 나는 지속적인 엔지니어링 프로젝트에 Kanban을 사용했으며 매우 잘 작동했습니다. 추정치에 도움이되는 방법에 따라 연속 흐름의 열쇠는 각 작업 항목을 대략 같은 크기 (1x, 2x, 3x, 10x, 20x, 100x)가되도록하는 것입니다. 프로세스 상태 변경 날짜 (예 : 대기열 1/15, 디자인 1/22, DEV 1/24, 테스트 2/4, 2/7) 등을 추적하여 워크 플로를 통해 항목의 이동을 추적해야합니다. 시간이 지남에 따른 상태의 시간 기간을 평가하기 위해 정기적으로 누적 흐름도. 각 항목의 크기와 항목의 워크 플로우를 통한 시간을 알고 있다는 점을 감안할 때 프로젝트가 얼마나 오래 걸리는가는 독자에게 남겨진 사소한 계산 운동입니다. (가장 흥미로운 질문은 제약을 발견하는 방법입니다 ... 그리고 그와 그것들을 제거하는 방법입니다. 힌트 : 작업이 제약 앞에 쌓기 때문에 주에서 오랜 시간을 찾으십시오.)

Answer 5

스토리 작업을 수행 할 개별 개발자가 스토리를 완성하는 데 필요한 노력을 추정하게하십시오. 그 개발자의 추정에서 역사적 차이를 고려할 수 있지만, 아이디어는 추정치를 취한 다음 그 스프린트에서 몇 가지 이야기를 마칠 수있는 이야기를 파악할 수 있다는 것입니다.

Answer 6

평균 속도는 주로 룩 하이드 릴리스 계획에 주로 사용된다는 것을 잊지 마십시오. 그만큼 팀 선택을 담당합니다 각 반복에서 얼마나 많은 백 로그 품목을 취할 수 있는지 (역사적 속도를 아는 것은 도움이 될 수 있지만).

팀 규모 (및 속도)가 반복에서 반복으로 변동하는 경우 팀 변동이 계속 될 것이라고 가정 할 때 과거 N 스프린트에 대한 평균 속도를 사용하여 유용한 릴리스 계획을 수행 할 수 있습니다. 안정적인.

Answer 7

여기서 가장 큰 문제는 팀이 스프린트에서 스프린트로 바뀌기 때문에 팀이 예측 가능한 견적과 배송을 제공하기 어렵다는 것입니다.이는 또한 팀의 헌신과 지속적인 개선에 해를 끼칠 수 있습니다.

이 사례는 실제로 Kanban 접근 방식에 매우 적합할 수 있습니다.빠른 개요를 보려면 Henrik Kniberg의 Kanban 소개를 확인하세요.

행운을 빌어요!