Agile, Waterfall, Scrum ... 팀을 반복 개발로 전환하는 것이 얼마나 어려운가요?

Question

기업 분위기에서 팀을 전통적인 비 반복적 사양 목록, 간트 차트, 단계별 팀에서보다 반복적 인 방법으로 전환하는 데 필요한 과제는 무엇입니까?

또한 새로운 개발 전략을 사용하면서 다른 그룹과 합격하는 성공적인 방법은 무엇 이었습니까?

Answer 1

우리가 무슨 짓을 :

1. 은 (미래를 예측하고자) 계획은 단순히 보풀, 증기, 사실적 근거가없는 가정의 목록입니다 관리에 설명했다.

2. 스프린트 목록이 계획되어 있습니다. burndown 차트를 썼습니다. 요약 추정을하는 것을 잊어 버렸습니다.

3. 스프린트 목록에서 실행되기 시작했습니다.

처음 두 개 또는 세, 관리는 "계획"단 번 다운 목록이 전통적인 폭포 프로젝트 계획처럼, "위험", "가정"또는 아무것도 아니오 "날짜"로, 이었다는 것을 깨닫기 시작 후 .

물론이 시점에서 너무 늦었습니다. 우리는 이미 한 번의 스프린트를 완료했으며 두 번째 스프린트의 대부분을 통과했다. 말은 헛간에서 나옵니다. 종소리가 이미 들렸다.

그래서 경영진은 약간의 물건을 요구합니다.

1. 총 예산입니다. 우리는 "당신에게 중요한 스프린트를 더하고, 당신이 행복하다면 무작위로 선을 그어야합니다. 그건 당신의 예산입니다." 너무 많은 통제 때문에 아무도 좋아하지 않습니다. "어떻게 그걸 정당화 할 수 있니?" 그들이 물었다. "쉽습니다. 프로젝트를 취소 할 때까지 우선 순위에 따라 빌드합니다."

   우리가 추가해야했던 것은 각 스프린트의 잠정적 인 지속 시간이었습니다. 우리의 크기는 다양합니다 (2 ~ 4 주). 10 번의 스프린트 목록은 약 26 주에서 6 개월이었다. 그 후 우리는 숫자를 줄이기를 멈췄다.

2. "가정"목록. 우리는 방금 이것을 거절했습니다. "너 자신을 써라." 그들은 스스로 생각할 수 없었습니다. 그게 그랬어.

3. "위험"목록. 다시, 우리는 무엇이 을 두려워하는지 물었다. 그들이 무언가에 괴롭힘을 당하면, 아마도 번드에서 우선 순위를 변경해야합니다.

4. 기한. 우리는이 문제를 해결하고 날짜와 예산 주변의 번 다운과 그들에게 중요한 위험에 우선 순위를 매길 것을 요청했습니다. 우리는 어떤 명령을별로 신경 쓰지 않았습니다. 그것은 관리자로서의 그들의 요구입니다.

은 두 개 더 달리기 후에, 그들은 "폭포"요청을 중단하고 우선 순위와 번 다운을 관리하기 시작했다.

흥미롭게도 그들은 스코프 크리프에 대해 결코 묻지 않았습니다. 관리자는 "범위를 어떻게 관리합니까?" 점진적 개발을 적극적으로 거부하고 있습니다. 그들은 그것을 얻지 않으려 고 노력하고 있습니다.

관리자가 애자일 방법이 범위 크립을 "방지"하는 방법을 알고 싶을 때, 그들은 (a) 학습 과정을 "크립 (creep)"으로 분류하고 (b) 학습이 범위 변경으로 이어진다는 생각에 저항해야합니다 . 범위 "크리프 (creep)"가있는 유일한 방법은 발생할 수있는 학습에 관계없이 특정 범위를 확약 할 때입니다. 민첩한 방법은 포괄적 인 범위가 아닌 다음 스프린트에만 커밋됩니다. 범위에 커밋하지 않으면 존재하지 않기 때문에 오싹 할 수 없습니다.

Answer 2

Lynn Manns와 Linda Rising이 책 Fearless Change: Patterns for Introducing New Ideas에 관심을 가질 수 있습니다. 조직에 민첩한 방법을 도입 한 경험을 요약 한 것입니다.

Answer 3

지금 당장이 작업을 수행하려고합니다. 현장에서 고객 개발 부서를 운영하고 있습니다. 반복 개발 프로세스를 위해 바이 인을 얻으려고 할 때 핵심 요소라고 말할 수 있습니다.

이 중 하나에 대한 좋은 대답은 here입니다.

크고 관리 할 수없는 덩어리로 인해 프로젝트가 늦고 예산이 초과 된 프로젝트에 대한 실적을 이미 확보 한 경우 프로젝트의 이해 관계자가 변화를 이끌어 내도록 유도하는 좋은 출발점입니다.

프로세스는 자체를 증명할 수 있지만이를 지원하는 올바른 당사자와 만 처리 할 수 ​​있습니다. 당신의 핵심은 다른 팀 선수들이 당신이하고자하는 것에 가치를 보이도록하는 것입니다.

우리에게는 고객의 관점에서 접근하는 것입니다. 우리가 만들고있는 것이 그들이 구상 한 것임을 확실히하기 위해 끊임없이 고객에게 다시 와야합니다. 낭비를 막을 수있는 프로세스를 간소화하고 싶습니다. 모두 시간.

물론 각기 다른 조직의 애자일 작업의 다른 부분과 실제로 애자일 프로세스를 사용하는 소수의 기업은 순수한 의미에서 그렇게합니다.

시행 착오를 통해 귀사의 비즈니스, 문화 및 팀에 적합한 것을 파악하십시오. 점차 전반적인 프로세스를 채택 할 수 없다는 것과 체리가 비즈니스 모델에 가장 적합한 부분을 선택한다는 것은 없습니다.

Answer 4

여기 주위에는 스크럼을 사용하여 더욱 민첩 해지기를 원했던 한 팀에서 시작되었습니다. 이 팀은 "조종사 팀"이었고 몇 차례의 스프린트 (3 개월)를 보냈습니다. 그들은 스크럼에 대해 이미 읽고 배우고있는 내부의 누군가에 의해 코치되었습니다. 완전한 전환 대신 "파일럿"을 수행하는 것은 경영진과 굴절 팀 구성원의 수락을 얻는 데 도움이되었습니다.

"시도해보십시오"태도는 실제로 고객을 프로세스에 참여시키는 데 도움이됩니다 (내부 고객은 있지만 고객은 그다지 적지 않습니다).

막대기를 만들려면 진행 상황과 그것이 팀과 고객에게주는 이점 (성능/팀 구성원/고객과의 원활한 의사 소통, 더 나은 결과, 행복한 고객, 등)

Answer 5

제 경험으로 팀 전환은 문제가 아닙니다. 그것은 전환하는 경영입니다.

Answer 6

필자의 경험에 비추어 볼 때, 모든 프로그래머가 Agile/Scrum/whatever로 전환 할 의사가 있는지, 그리고 모든 사람들이 그것에 호의적인지, 아니면 적어도 적극적으로 가지 않을지 확인하십시오 그것을 반대하십시오. 애자 일/스크럼이 동의/입력없이 위에서 위임 받았다고 인식되면 팀원들의 저항을 보았습니다. 끊임없이 팀을 설득하지 않고도 관리자를 훈련시키는 것은 어렵습니다.