저는 세 명의 개발자와 한 명의 디자이너로 구성된 팀에서 일하는 웹 개발자입니다. 이제 민첩한 스크럼 소프트웨어 개발 방법론을 구현 한 지 약 5 개월이되었습니다. 하지만이 사이트에서 공유하고 싶었던 이상한 느낌이 듭니다.
인간의 삶에서 중요한 요소 중 하나는 의사 결정 과정입니다. 그러나 의사 결정에는 큰 차이가 있습니다. 일부 결정은 내부 또는 외부 힘의 결과 일 뿐이며, 다른 결정은 자유 의지에 전적으로 근거하며 일부 결정은 단순히 그 사이에있는 것입니다. 결정을 내릴 자유가 많을수록 자신의 일을 더 많이 주도하게됩니다. 이것은 규칙 인 것 같습니다. 우리는 스스로 삶을 형성하는 경향이 있기 때문입니다.
해야 할 일 을 결정하는 것과해야 할 일 을 듣는 것 사이에는 큰 차이가 있습니다 .
스크럼 전에, 나는 같은 좀 더 느낌을했다 등, 구현의 우선 순위, 개발, 분석에 관련 된 의사 결정에 더 많은 자유를 가지고 같은 느낌이 내가 뭘하는지 결정하고 있습니다 .
그러나 스크럼 방법론으로 인해 이제 많은 결정이 단순히 제품 소유자로부터 온 것입니다. 그는 PBI의 우선 순위를 정하고 소프트웨어 작동 방식, 때로는 UI 및 기능 구현 방식을 분석합니다. 나는 이것이 스크럼 방법론의 일부라는 것을 알고 있으며, 이것이 향후 제품 판매를 향상시킬 수 있음을 알고 있습니다. 그러나 이제 나는 무언가를하기로 결정하는 대신 항상 무언가를하라는 말을 듣는 것처럼 느낍니다 . 이 증후군은 이제 작업에 대해 더 수동적이었습니다.
- 더 나은 솔루션, 접근 방식 또는 기술을 찾기 위해 검색을 적게하는 경향이 있습니다.
- 나는 즐거운 일을 기대하고 아침에 일어나지 않습니다. 오히려 저는 살기 위해 일해야한다는 느낌이 듭니다
- 퇴근 후 자신의 취미 프로젝트에 더 많은 기아가 있습니다
- 더 이상 기술 수준에 도달하기 위해 팀을 강요하지 않습니다
- 나는 저녁이나 차 시간에 더 많은 시간을 보내고 일을 다시하는 것에 대한 열의가 적다
- 나는 이제 더 빨리 일을 끝내고 싶어서 집에 돌아갈 수있게하려고한다
가장 큰 문제는 동료들도이 행동을보고 진단한다는 것입니다. 스크럼의 결과인가? 스크럼은 실제로 개발 팀이 전체 소프트웨어를 구성하는 데 참여하지 않은 것처럼 느끼도록하여 프로젝트를 수동적으로 만드는가? 이 느낌을 어떻게 극복 할 수 있습니까?
답변
그러나 이제는 무언가를하기로 결정하는 대신 항상 무언가를하라는 말을 듣는 것 같습니다.
이것은 레일에서 무언가가 나왔다는 심각한 표시입니다. 민첩한 프로젝트는 이런 느낌이 없어야합니다. “공정을 지나친 사람들”의 수사에는 “우리는 사람들이 빨라 먹는 일을하도록 강요하지 않습니다.” 몇 가지 아이디어가 있습니다.
당신은 “스크럼하지만”하고 있습니까? 즉, 일부 스크럼, 다른 일부입니다. (즉, “우리는 스크럼을 수행하고 있지만 모든 이야기는 제품 소유자가 아닌 PMO에서 가져와야합니다.”) 요즘 많은 미친 쓰레기가 스크럼이라고합니다.
개인적으로 당신이 있어야 할 과정에 관여하지 않습니까? 나는 많은 사람들이 이야기의 내용에 화를내는 것을 알고 있었고, 이야기가 스프린트 백 로그에 들어간 후에 만 참여하는 것으로 나타났습니다. 스토리 개발 초기에 제품 소유자와 이야기하고 피드백을 얻으십시오.
Scrum에서 팀은 프로세스를 소유해야하며 프로세스는 팀의 요구에 맞게 시간이 지남에 따라 변경 될 것으로 예상됩니다. 회고에서 우려를 제기하십시오. 제안하는 프로세스를 조정할 수 있다면 일부 팀에서 판매하기가 더 쉬워집니다.
답변
당신의 문제는 스크럼이 아닙니다 (그리고 Jarrod Roberson이 코멘트에서 언급했듯이, 당신이 묘사하고있는 스크럼이 아닙니다)-제품 소유자의 미세 관리 및 (그리고 팀의) 주장 력 부족 .
“하지만 스크럼 방법론으로 인해 이제는 많은 결정이 제품 소유자로부터 온 것입니다. 그는 PBI의 우선 순위를 정하고 소프트웨어 작동 방식, 때로는 UI 및 기능 구현 방법을 분석합니다. 이것이 스크럼 방법론의 일부라는 것을 알고 있습니다.”
당신은 착각입니다. 스크럼에 대한 위키 백과 페이지를 간단히 살펴보면 “실제 분석, 디자인, 구현, 테스트 등을 수행하는 교차 기능 그룹 인 팀”이라는 것을 알 수 있습니다 . 보다? 제품 소유자가해야 할 일 을 알려 주지만이 를 수행하는 방법 은 팀이 결정 합니다 .
구현 책임은 귀하에게 있으므로 응용 프로그램 구현 방법을 결정해야합니다. 제품 소유자의 의견을 경청하십시오. 그러나 최종 결정은 귀하 (또는 팀)에게 달려 있습니다.
BTW 미세 관리 는 활성 개발자를 수동 개발자로 전환합니다.
답변
당신이 묘사하는 것은 스크럼이 아닙니다.
기술적으로 업무를 수행하는 방법을 말하면 제품 소유자가 한계를 넘어 섰습니다. SCRUM이 전혀 아닙니다.
SCRUM은 개발자가 개발 문제에 집중할 수 있도록 하고 시간이 얼마나 걸리고 어떻게해야하는지 결정하도록합니다.
SCRUM은 모든 이해 관계자 간의 협업을 촉진하기 위해 협업, 즉 스프린트 계획 회의를위한 것입니다. 제품 소유자, 개발자 및 테스트.
예, 제품 소유자는 고객의 요구에 따라 먼저 제공해야하는 기능, 기능을 우선시해야하지만 개발자는 제품 소유자가 아닌 엔지니어링 및 디자인을 수행해야합니다.
개발자와 고객이 함께 작업하고 고객과 직접 기능을 해시하도록 특별히 작업하고 교육하지 않는 한 개발자가 GUI와 워크 플로를 디자인해야한다는 데 동의하지 않습니다. 진공 상태에서 수행되는 프로그래머 내장 GUI는 고객의 요구를 거의 충족시키지 못합니다.
스크럼은 애자일 매니페스트에 대해 예측 가능하고 반복 가능한 경량 프로세스를 구현하는 것입니다.
아주 좋은 것들이 이렇게 왜곡되고 있다는 이야기를 들으면 슬프게됩니다.
답변
나는 스크럼 전에 추측하고 있습니다. 모두가 원하는 것을했습니다 : yippee ki-yay mf’er . 사용자는 후원자이며 스토리를 주도하고 청구서를 지불합니다. 제품 소유자는 스토리가 완료되도록합니다. 어떻게 당신의 그룹은 제품 소유자가 당신에게 프로그램하는 방법을 말해야한다는 결론에 도달했습니다.
멋지다고 생각되는 코드를 작성하거나 깔끔한 작은 앱을 만들고 싶습니까? “B가 아닌 기능 A를 먼저하고 싶기 때문에 선택의 자유를 유지할 수 있습니다.” 새로운 개발 방법론이 아닌 다른 후원자를 찾으십시오.
프로젝트 소유자 제목이나 다른 것에 빠졌습니다. 당신이 이야기에 동의하지 않는 정당한 이유가 있다면, 무언가 말하고, 주장하십시오. 항상이기는 것은 아닙니다. 사용자에게 돌아와서 요청에 유효한 문제가 있음을 알리는 것이 그들의 임무입니다. 이야기가 하루 종일 데이터베이스를 무작위로 삭제하거나 백업, 데이터 손실 또는 가동 중지 시간을 요구하지 않는 경우 이야기를 바로 잡아야 할 문제와 의무가 있습니다.
답변
애자일에 대한 모험이 스크럼에 의해 타락한 것 같습니다. 모든 민첩한 방법론 중에서 Scrum이 가장 민첩하지 않다는 것을 알았습니다. 미니어처 폭포 및 추가 프로젝트 관리와 비슷합니다. 물론 이것은 성가신 개발자로부터 통제를 받고 있다고 생각하는 경영진이 가장 좋아하는 것이지만 물론 상황의 현실을 알 수 있습니다.
민첩성은 정해진 경로를 따르는 것이 아니라 생산성과 동기를 부여하도록 설계되었습니다. 프로세스를 사용하지 않는 사람들 은 선언문 (모자이크)을 사용하며 사용중인 시스템에서 손실됩니다.
따라서 변경하십시오. 경영진에게 맡겨서 역행 단계라고 말하면 생산성이 예전보다 떨어지고 작업 방식에 만족하지 못한다고 말할 수 있습니다. 쇼 애자일 선언문 (및 악 트윈 만이 실험에서 교훈을 배웠지 만, 더 나은 시스템으로 당신이 잘 작동하도록 나타나는 가지고하는 데 사용처럼 (하나 그것에서 좋은 비트를 진화하지으므로) 및 증명 당신을 위해).
답변
저는 단순히 여러분이 더 많은 소유권을 갖는 데 익숙하다고 생각합니다. 내가 생각하는 모든 사람은 인간 본성을 선호합니다.
불행히도 많은 부분이 소프트웨어보다 작다고 생각합니다. 종종 일부는 클라이언트가 아닌 개발자를 위해 작성 되었기 때문입니다. 새로운 접근 방식은이를 줄이지 만 소유 느낌을 희생해야합니다.
나는 당신이 일을 더 좋거나 더 재미있게 만들 것을 제안하는 방법을 모른다. 그러나 그것은 훌륭한 질문이자 매우 좋은 통찰력이다.
답변
“역할-으로, 목표 / 목표 —- 이렇게-편익”을 원하는 형태로 사용자 스토리를 받고 있습니까? 귀하의 제품 소유자가 디자인 작업을하고 싶어하는 것처럼 들리며, 그렇게하는 것이 가장 좋은 사람이 아닐 수도 있습니다. 사용자 스토리 패턴을 사용하면 제품 소유자가 비즈니스 관심사를 고수하고 소프트웨어 개발자가 소프트웨어 개발을 수행 할 수 있습니다.