스크럼이 민첩하지 않다고 생각하는 사람이 있습니까?

저는 민첩한 개발을 좋아하는 팬이며 몇 년 전에 매우 성공적인 프로젝트에서 XP를 사용했습니다. 나는 그것에 관한 모든 것, 반복적 인 개발 접근법, 테스트 주위에 코드 작성, 페어 프로그래밍, 현장에서 고객이 일하는 것을 좋아했습니다. 생산성이 높은 작업 환경이었고 압박감을 느끼지 않았습니다.

그러나 내가 일한 마지막 몇 곳은 스크럼을 사용 / 사용했습니다. 요즘 애자일 개발의 포스터 아이라는 것을 알고 있지만 그것이 민첩하다고 100 % 확신하지는 않습니다. 다음은 그것이 민첩하지 않은 두 가지 주요 이유입니다.

프로젝트 관리자는 그것을 좋아합니다

본질적으로 타임 라인에 집착하는 프로젝트 관리자는 모두 스크럼을 좋아하는 것 같습니다. 내 경험상 그들은 시간 요구 사항을 추적하고 주어진 작업에 소요 된 시간을 기록하는 수단으로 Sprint 백 로그를 사용하는 것 같습니다. 그들은 화이트 보드를 사용하는 대신 엑셀 시트를 사용합니다. 엑셀 시트는 각 개발자가 종교적으로 작성해야합니다.

내 생각에 이것은 민첩한 프로세스를 위해 너무 많은 문서 / 시간 추적입니다. 작업 자체를 수행 할 수있을 때 작업 시간이 얼마나 걸리는지 추정하는 데 시간을 낭비하는 이유는 무엇입니까? 또는 마찬가지로 다음 작업으로 넘어갈 때 작업이 얼마나 오래 걸 렸는지 문서화하는 데 시간을 낭비하는 이유는 무엇입니까?

스탠드 업 회의

내가 일했던 이전 장소에서의 스탠드 업 회의는 악몽이었다. 우리는 매일 어제 무엇을했는지, 그날 무엇을할지 설명해야했습니다. 우리가 작업에 대해 "추정"한 시간을 넘어 서면 프로젝트 관리자는 악취를 would 고 무능력자를 보여주는 수단으로 Sprint 백 로그를 참조하십시오.

이제는 의사 소통의 필요성을 이해하지만 반드시 매일 회의의 분위기가 밝고 지식 공유에 중점을 두어야합니다. 숙제 스타일이 어디로 바뀌어야한다고 생각하지 않습니다. 또한 민첩성의 결점은 타임 라인이 바뀌므로 돌로 설정해서는 안된다는 것입니다.

결론

민첩성의 개념은 개발자의 삶을 편하게 만들어 소프트웨어를 개선하는 것입니다. 따라서 팀이 사용하는 민첩한 프로세스는 개발자가 주도해야한다고 생각합니다. 프로젝트 관리자가 애자일 개발과 관련이있는 프로젝트를 추적하기 위해 "민첩한"이라는 프로세스를 사용한다고 생각하지 않습니다.

누구 생각?

Scrum에는 변태하기 쉬운 특정 요소가 있지만, 솔직히 말하면, 모든 이해 관계자에게 교육 내용이 무엇인지, 작동 방식에 대해 교육하지 않고 조직이 Scrum을 채택하도록 시도한 결과입니다. 왜 작동합니까? 결과를 얻으려면 회사 전체에 바이 인이 필요합니다.

민첩한 변화는 마이크로 매니저, 자신의 의제를 가진 힘이있는 사람들, 부족한 교육을받은 개발자, 커뮤니케이션 사일로 등 조직에서 발생하는 모든 문제를 노출시킬 것입니다. 이러한 문제를 해결하기위한 집단적 의지가 없다면 "스탠드 업"과 "스프린트에서 작동"만하면 Scrum 구현은 얼굴이 평평해질 것입니다.

나는 이것을 충분히 강조 할 수 없다. 만약 당신이 스크럼을하고 싶다면 길을 보여줄 수있는 유능한 코치가 필요하다. Essential Scrum을 읽고 그것이 어디로 가는지를 보는 것만으로는 충분하지 않습니다 ...

예. 애자일의 "아버지"중 하나라도 스크럼이 실제로 민첩하다는 데 동의하지 않습니다. youtube.com/watch?v=hG4LH6P8Syk – 행복감

위의 의견 중 하나 에서이 링크가 실제로 모든 것을 말합니다. 볼 가치가있는 것은, Uncle Bob은 Scrum에 대한 간략한 역사를 제공하며, 기본적으로 Scrum은 관리 프로세스 가되기 위해 시간이 지남에 따라 발전했기 때문에 민첩한 개발 프로세스 가 아니라고 말합니다 . 그 이유는 Scrum 과정을 수강 한 개발자가 아닌 프로젝트 관리자이기 때문입니다.

당신이 설명하는 것은 우리의 전문 스크럼 트레이너들이 "구현 된 스크럼"을 가진 조직에서 많이 본 것입니다. 종종 "개발 팀에서 XP를 수행"하기도합니다. 이는 빌드 서버에서 몇 개의 단위 테스트가 실행되고 있음을 의미합니다. 이것은 스크럼이 아닙니다 .

예, 프로젝트 관리자는 제품 백 로그, 특히 디지털화 된 제품 백 로그를 사용하여 해당 시스템이 수집하는 측정 항목을 악용 할 수 있습니다. 그러나 개발팀과 스크럼 마스터는 그를 보내서는 안됩니다. 어쨌든 프로젝트 관리자는 무엇입니까? 제품 소유자 가 아니어야합니까 ?!

XP가 잘못 수행 될 수 있고보다 엄격한 프로세스가 지속적으로 통합, 배포되지만 계획에 따라 매우 유동적 일 수있는 것처럼 Scrum은 프레임 워크 일뿐입니다. 가치와 프로세스를 잘 이해하려면 이해하는 사람이 필요합니다. 그것은 걸리는 개선을 학습 연속 거기까지.

아마도 하나를 예상했을 수도 있지만 일부 (많은?) 사람들이 스크럼을 민첩하지 않은 방식으로 오용한다고해서 스크럼이 민첩하지 않다는 것을 의미하지는 않습니다.

프로젝트 관리자 : Scrum 팀에는 그러한 역할이 없습니다. 스크럼 마스터는 예산 또는 마감일을 책임지지 않습니다. 그는 팀을 돕고 그들이 저지른 목표를 향한 장애물을 제거 할 책임이 있습니다. 당신이 묘사 한 바에 따르면, PM은 일반적으로 팀과 제품 소유자에게가는 특권을 취하여 이전의 명령 및 통제 습관을 영속하는 것으로 보입니다.

시간 추적 : 스크럼은 남은 시간 을 추적 하고이를 합산 하여 개별 팀 구성원이 보낸 시간이 아닌 스프린트 상태를 결정 하도록 권장합니다 . 이것은 세부적인 것처럼 보일지 모르지만 비난 지향적 문화와 목표 지향적 접근 방식의 모든 차이를 만듭니다.

보내는 사람 스크럼 가이드 :

스프린트 진행 상황 모니터링

스프린트의 어느 시점에서나 스프린트 백 로그에 남아있는 총 작업량을 합산 할 수 있습니다. 개발팀 은 스프린트 목표 달성 가능성을 계획하기 위해 모든 일일 스크럼 에 대해 남은 총 작업량을 추적합니다 . Sprint 전체에서 남은 작업을 추적함으로써 개발 팀은 진행 상황을 관리 할 수 ​​있습니다.

스크럼은 프로젝트 관리 방법론입니다

애자일은 소프트웨어 개발 방법론입니다 (-ish)

스크럼 + 민첩성

민첩하지 않은 스크럼.