Scrum은 활동적인 개발자를 수동 개발자로 전환합니까?

저는 세 명의 개발자와 한 명의 디자이너로 구성된 팀에서 일하는 웹 개발자입니다. 이제 민첩한 스크럼 소프트웨어 개발 방법론을 구현 한 지 약 5 개월이되었습니다. 하지만이 사이트에서 공유하고 싶었던 이상한 느낌이 듭니다.

인간의 삶에서 중요한 요소 중 하나는 의사 결정 과정입니다. 그러나 의사 결정에는 큰 차이가 있습니다. 일부 결정은 내부 또는 외부 힘의 결과 일 뿐이며, 다른 결정은 자유 의지에 전적으로 근거하며 일부 결정은 단순히 그 사이에있는 것입니다. 결정을 내릴 자유가 많을수록 자신의 일을 더 많이 주도하게됩니다. 이것은 규칙 인 것 같습니다. 우리는 스스로 삶을 형성하는 경향이 있기 때문입니다.

해야 할 일 을 결정하는 것과해야 할 일 을 듣는 것 사이에는 큰 차이가 있습니다 .

스크럼 전에, 나는 같은 좀 더 느낌을했다 등, 구현의 우선 순위, 개발, 분석에 관련 된 의사 결정에 더 많은 자유를 가지고 같은 느낌이 내가 뭘하는지 결정하고 있습니다 .

그러나 스크럼 방법론으로 인해 이제 많은 결정이 단순히 제품 소유자로부터 온 것입니다. 그는 PBI의 우선 순위를 정하고 소프트웨어 작동 방식, 때로는 UI 및 기능 구현 방식을 분석합니다. 나는 이것이 스크럼 방법론의 일부라는 것을 알고 있으며, 이것이 향후 제품 판매를 향상시킬 수 있음을 알고 있습니다. 그러나 이제 나는 무언가를하기로 결정하는 대신 항상 무언가를하라는 말을 듣는 것처럼 느낍니다 . 이 증후군은 이제 작업에 대해 더 수동적이었습니다.

1. 더 나은 솔루션, 접근 방식 또는 기술을 찾기 위해 검색을 적게하는 경향이 있습니다.
2. 나는 즐거운 일을 기대하고 아침에 일어나지 않습니다. 오히려 저는 살기 위해 일해야한다는 느낌이 듭니다
3. 퇴근 후 자신의 취미 프로젝트에 더 많은 기아가 있습니다
4. 더 이상 기술 수준에 도달하기 위해 팀을 강요하지 않습니다
5. 나는 저녁이나 차 시간에 더 많은 시간을 보내고 일을 다시하는 것에 대한 열의가 적다
6. 나는 이제 더 빨리 일을 끝내고 싶어서 집에 돌아갈 수있게하려고한다

가장 큰 문제는 동료들도이 행동을보고 진단한다는 것입니다. 스크럼의 결과인가? 스크럼은 실제로 개발 팀이 전체 소프트웨어를 구성하는 데 참여하지 않은 것처럼 느끼도록하여 프로젝트를 수동적으로 만드는가? 이 느낌을 어떻게 극복 할 수 있습니까?

그러나 이제는 무언가를하기로 결정하는 대신 항상 무언가를하라는 말을 듣는 것 같습니다.

이것은 레일에서 무언가가 나왔다는 심각한 표시입니다. 민첩한 프로젝트는 이런 느낌이 없어야합니다. "공정을 지나친 사람들"의 수사에는 "우리는 사람들이 빨라 먹는 일을하도록 강요하지 않습니다." 몇 가지 아이디어가 있습니다.

당신은 "스크럼하지만"하고 있습니까? 즉, 일부 스크럼, 다른 일부입니다. (즉, "우리는 스크럼을 수행하고 있지만 모든 이야기는 제품 소유자가 아닌 PMO에서 가져와야합니다.") 요즘 많은 미친 쓰레기가 스크럼이라고합니다.

개인적으로 당신이 있어야 할 과정에 관여하지 않습니까? 나는 많은 사람들이 이야기의 내용에 화를내는 것을 알고 있었고, 이야기가 스프린트 백 로그에 들어간 후에 만 ​​참여하는 것으로 나타났습니다. 스토리 개발 초기에 제품 소유자와 이야기하고 피드백을 얻으십시오.

Scrum에서 팀은 프로세스를 소유해야하며 프로세스는 팀의 요구에 맞게 시간이 지남에 따라 변경 될 것으로 예상됩니다. 회고에서 우려를 제기하십시오. 제안하는 프로세스를 조정할 수 있다면 일부 팀에서 판매하기가 더 쉬워집니다.

당신의 문제는 스크럼이 아닙니다 (그리고 Jarrod Roberson이 코멘트에서 언급했듯이, 당신이 묘사하고있는 스크럼이 아닙니다)-제품 소유자의 미세 관리 및 (그리고 팀의) 주장 력 부족 .

"하지만 스크럼 방법론으로 인해 이제는 많은 결정이 제품 소유자로부터 온 것입니다. 그는 PBI의 우선 순위를 정하고 소프트웨어 작동 방식, 때로는 UI 및 기능 구현 방법을 분석합니다. 이것이 스크럼 방법론의 일부라는 것을 알고 있습니다."

당신은 착각입니다. 스크럼에 대한 위키 백과 페이지를 간단히 살펴보면 "실제 분석, 디자인, 구현, 테스트 등을 수행하는 교차 기능 그룹 인 팀"이라는 것을 알 수 있습니다 . 보다? 제품 소유자가해야 할 일 을 알려 주지만이 를 수행하는 방법 은 팀이 결정 합니다 .

구현 책임은 귀하에게 있으므로 응용 프로그램 구현 방법을 결정해야합니다. 제품 소유자의 의견을 경청하십시오. 그러나 최종 결정은 귀하 (또는 팀)에게 달려 있습니다.

BTW 미세 관리 는 활성 개발자를 수동 개발자로 전환합니다.

당신이 묘사하는 것은 스크럼이 아닙니다.

기술적으로 업무를 수행하는 방법을 말하면 제품 소유자가 한계를 넘어 섰습니다. SCRUM이 전혀 아닙니다.

SCRUM은 개발자가 개발 문제에 집중할 수 있도록 하고 시간이 얼마나 걸리고 어떻게해야하는지 결정하도록합니다.

SCRUM은 모든 이해 관계자 간의 협업을 촉진하기 위해 협업, 즉 스프린트 계획 회의를위한 것입니다. 제품 소유자, 개발자 및 테스트.

예, 제품 소유자는 고객의 요구에 따라 먼저 제공해야하는 기능, 기능을 우선시해야하지만 개발자는 제품 소유자가 아닌 엔지니어링 및 디자인을 수행해야합니다.

개발자와 고객이 함께 작업하고 고객과 직접 기능을 해시하도록 특별히 작업하고 교육하지 않는 한 개발자가 GUI와 워크 플로를 디자인해야한다는 데 동의하지 않습니다. 진공 상태에서 수행되는 프로그래머 내장 GUI는 고객의 요구를 거의 충족시키지 못합니다.

스크럼은 애자일 매니페스트에 대해 예측 가능하고 반복 가능한 경량 프로세스를 구현하는 것입니다.

아주 좋은 것들이 이렇게 왜곡되고 있다는 이야기를 들으면 슬프게됩니다.

나는 스크럼 전에 추측하고 있습니다. 모두가 원하는 것을했습니다 : yippee ki-yay mf'er . 사용자는 후원자이며 스토리를 주도하고 청구서를 지불합니다. 제품 소유자는 스토리가 완료되도록합니다. 어떻게 당신의 그룹은 제품 소유자가 당신에게 프로그램하는 방법을 말해야한다는 결론에 도달했습니다.

멋지다고 생각되는 코드를 작성하거나 깔끔한 작은 앱을 만들고 싶습니까? "B가 아닌 기능 A를 먼저하고 싶기 때문에 선택의 자유를 유지할 수 있습니다." 새로운 개발 방법론이 아닌 다른 후원자를 찾으십시오.

프로젝트 소유자 제목이나 다른 것에 빠졌습니다. 당신이 이야기에 동의하지 않는 정당한 이유가 있다면, 무언가 말하고, 주장하십시오. 항상이기는 ​​것은 아닙니다. 사용자에게 돌아와서 요청에 유효한 문제가 있음을 알리는 것이 그들의 임무입니다. 이야기가 하루 종일 데이터베이스를 무작위로 삭제하거나 백업, 데이터 손실 또는 가동 중지 시간을 요구하지 않는 경우 이야기를 바로 잡아야 할 문제와 의무가 있습니다.

애자일에 대한 모험이 스크럼에 의해 타락한 것 같습니다. 모든 민첩한 방법론 중에서 Scrum이 가장 민첩하지 않다는 것을 알았습니다. 미니어처 폭포 및 추가 프로젝트 관리와 비슷합니다. 물론 이것은 성가신 개발자로부터 통제를 받고 있다고 생각하는 경영진이 가장 좋아하는 것이지만 물론 상황의 현실을 알 수 있습니다.

민첩성은 정해진 경로를 따르는 것이 아니라 생산성과 동기를 부여하도록 설계되었습니다. 프로세스를 사용하지 않는 사람들 은 선언문 (모자이크)을 사용하며 사용중인 시스템에서 손실됩니다.

따라서 변경하십시오. 경영진에게 맡겨서 역행 단계라고 말하면 생산성이 예전보다 떨어지고 작업 방식에 만족하지 못한다고 말할 수 있습니다. 쇼 애자일 선언문 (및 악 트윈 만이 실험에서 교훈을 배웠지 만, 더 나은 시스템으로 당신이 잘 작동하도록 나타나는 가지고하는 데 사용처럼 (하나 그것에서 좋은 비트를 진화하지으므로) 및 증명 당신을 위해).

저는 단순히 여러분이 더 많은 소유권을 갖는 데 익숙하다고 생각합니다. 내가 생각하는 모든 사람은 인간 본성을 선호합니다.

불행히도 많은 부분이 소프트웨어보다 작다고 생각합니다. 종종 일부는 클라이언트가 아닌 개발자를 위해 작성 되었기 때문입니다. 새로운 접근 방식은이를 줄이지 만 소유 느낌을 희생해야합니다.

나는 당신이 일을 더 좋거나 더 재미있게 만들 것을 제안하는 방법을 모른다. 그러나 그것은 훌륭한 질문이자 매우 좋은 통찰력이다.

"역할-으로, 목표 / 목표 ---- 이렇게-편익"을 원하는 형태로 사용자 스토리를 받고 있습니까? 귀하의 제품 소유자가 디자인 작업을하고 싶어하는 것처럼 들리며, 그렇게하는 것이 가장 좋은 사람이 아닐 수도 있습니다. 사용자 스토리 패턴을 사용하면 제품 소유자가 비즈니스 관심사를 고수하고 소프트웨어 개발자가 소프트웨어 개발을 수행 할 수 있습니다.

Scrum에는 개발자들이 새로운 기능, UI, 유용성에 기여하고 조언을 제공 할 수있는 충분한 공간이 있습니다. Scrum에는 비즈니스 사용자와 개발자 간의 협업과 대화가 필요합니다. 그러나 결국 제품 소유자는 스프린트 후 스프린트 (즉, ROI) 후 생성 된 소프트웨어 증분의 비즈니스 가치를 최대화하는 책임이 있기 때문에 항상 최종 결정권을 갖습니다.

민첩한 선언에서 :

우리의 최우선 과제는 귀중한 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시키는 것입니다.

UI와 기능을 구현하는 방법을 알려주는 제품 소유자는 용납 할 수 없습니다. 이 경우 당신은 이후 최종 결정이 있어야 당신은 당신이 생산하는 소프트웨어의 내부 품질에 대한 책임을.

프로그래머가 원하는 기능을 자유롭게 구현할 수있는 개발자가 만든 회사에서 일할 수도 있습니다. 그러나 대부분의 애자일 방법론은 비즈니스 영역의 사람들과 대부분의 장소에서 가장 일반적인 작업 부서 인 소프트웨어 (개발자, 테스터 등)를 생성하는 팀을 명확하게 분리합니다. 내 가정이 옳다면, 나는 당신이 더 이상 "큰 그림에 영향을 줄 수는 없다"는 느낌을 이해할 수 있지만 회사가 성장함에 따라 어쨌든 Scrum인지 아닌지 생각합니다.

언급 한 분석, 디자인 및 기타 메타 개발 활동 (제품 소유자가 다시 수행하지 않아야 함)과 관련하여 애자일 팀은 교차 기능 및 사일로가 없어야합니다. 어느 한 특정 개발 활동에 대한 모든 지식을 갖고있는 사람은 아무도 없으므로 "코드 원숭이"와는 달리 다양화할 수있는 기회가있을 것입니다.

반대로, 제품 소유자가 기능에 대한 결정을 내릴 경우 품질 코드를 만드는 데 더 많은 시간을 할애 할 수 있다는 것을 알게되었습니다. 또한, 유효한 우려가있는 경우, 항상 제품 소유자의 결정에 의문을 제기 할 수 있으며 이는 일반적으로 유익한 토론으로 이어집니다.

우리는 여기서 스크럼을 연습합니다. 우리는 현재 비즈니스 우선 순위와 이전 스프린트의 성공 및 실패를 제공하는 격주 계획 회의를 가지고 있으며 팀으로서 다음 스프린트를 위해 무엇을 해결하고자 하는지를 결정 합니다.

이를 수행하는 방법 중 하나는 수직으로 복잡하고 비즈니스 우선 순위를 수평으로 보드에 백 로그를 정렬하는 것입니다. 그 후 제품 소유자가 자신의 의견을 얻었으므로 우리가 원하는 것을 선택하는 것은 팀의 책임입니다. 당연히 높은 복잡도의 우선 순위가 낮은 작업을 고르는 것이 어려워 지지만 우리는 이것을 팀으로 결정하고 있습니다. 계획 세션이 더 길어 지지만 가치가 있으며 애자일 프로세스의 핵심 부분입니다.

때로는 미세 관리가 있지만 다른 문제입니다.

당신이 묘사하는 실제 문제는 팀이 방법론을 채택 할 때 일반적인 병리입니다. 이것은 구식 헤비급 시스템과 마찬가지로 새로운 학교 민첩 시스템에서도 마찬가지입니다.

Q : 방법론은 x를 규정하지만 x는 제대로 작동하지 않습니다. 우리는 무엇을해야합니까?

A : x 구현을 개선하십시오. 아마 그만해 방법론은 당신의 보스가 아닙니다!

이 특정한 경우에는 제품 소유자가 너무 많이 수행 한 것처럼 들립니다. 그것에 대해 편안하게 이야기하고 있습니까? "스크럼"을하지 않았다면 대화를 편안하게 하시겠습니까? 제품 소유자가 건설적인 피드백에 민감하지 않은 경우 방법론 문제가 아니라 제품 소유자의 문제입니다.

나는 잠시 동안 더 많은 폭포가 있었던 것처럼 전체 스크럼과 잘 어울리지 않습니다.

그러나 솔직히 말하면 이것은 프로젝트 관리 기술 문제보다는 관리 인력 문제와 비슷합니다. 마찬가지로 기술 기반보다 더 많은 사람들이 기반합니다.

자체 조직 팀에서 리더의 역할은 게시물에서 누락 된 것으로 보이는 블로그 게시물입니다. 스프린트에서 수행 할 작업을 결정하는 팀은 어디입니까? 팀은 프로세스와 작업에 대한 소유권을 가지고 있습니까? 스크럼을 알고 있고 다른 버전의 왜곡되지 않은 스크럼을 알고있는 사람이 있습니까?

나는 Scrum과 같은 경험을했으며 그것을 "이야기의 폭정"이라고 부릅니다.

내 경험상 크리에이티브 / 디자인 / 프런트 엔드 측면에서 개발자는 백엔드 작업에 참여하는 사람들보다 더 많은 어려움을 겪는 것 같습니다.

내가 지금까지 찾은 유일한 방법은 스크럼을 버리는 것입니다. 종종 장점이 있기 때문에 가능하지 않거나 적절하지 않은 경우가 많거나 개발자에게 "귀하의" 실제로 로그인 페이지 를 구현하는 방법을 자유롭게 선택할 수 있습니다 . 실제로는 구현이 기존 코드 및 시스템 아키텍처에 의해 제약을받지 않기 때문에 'for and a while 루프'중에서 선택할 수있는 자유를 고려하지 않는 한 자유.

해야 할 일 을 결정하는 것과해야 할 일 을 듣는 것 사이에는 큰 차이가 있습니다 .

내 경험에 의하면, 단지 다소 긴 방법이 에서 무엇을 말되기 에 무엇을 결정.

이 방법의 끝에서 그것은 일반적으로 우리가 있기 때문에하지 지시를 받았다 밝혀 그 전력과 같은 때문이 아니라 그들이 할 수있는 더 나은 아무것도 없다. 이와는 반대로이 방식이 끝날 때 – 팀에 대한 충분한 신뢰를 얻었을 때 그들은 우리가 처리 할 수있는만큼 많은 통제력을 잃어 버리고 행복하게 우리를 넘겨주는 것처럼 보입니다. 그 이상)

그리고 내 경험상 이것은 기본적으로 Scrum / Agile과 관련이 없습니다. 스크럼, 반복, 폭포 등이 발생했습니다. 신뢰 의 문제는 공정에 무관 한 것으로 보인다

우리 팀에서는 제품 소유자가 해야 할 일 을 알려주고 어떻게해야하는지 결정 합니다 . 이 분리를하는 것이 정말 중요합니다. 그렇지 않으면 설명 된 상황에 처하게됩니다.

내 경험에 따르면, 스크럼은 당신이하는 일을 깊이 관찰하는 것입니다. 그것은 단지 당신의 어깨에 앉아서 당신이하는 것을 지켜보고 있습니다. 자체 장점이 있지만 스크럼 방법론이 싫습니다. 품질이 아니라 카운트를 기대합니다. 스크럼 방법론으로 인해 품질이 저하되고 있습니다.