왜 그리고 어떤 이유로 개발자가 "일일 스크럼"을 좋아하지 않을 수 있습니까? [닫은]

매일 스크럼을 유지하면 다음과 같은 장점이 있습니다.

1. 팀이 서로 협력
2. 모든 작업이 수행 된 양을 알고 있습니다.
3. 번 다운 차트가 점점 완성됩니다
4. 작업 보드가 업데이트되었습니다
5. 그렇게 오래 지속되지 않습니다. 15 분은 아무도 죽이지 않습니다.

그러나 최근 6 개월 동안 스크럼을 구현하고 사용한 후에는 개발자가 더 이상 매일 스크럼을 좋아하지 않는다고 생각합니다. 사람들은 충분히 설명하지 않고 작업 보드를 업데이트하기 때문에 지루한 것 같습니다. 어떤 이유로 든 우리는 그것을 잡지 못하고 행복해집니다.

나는 이것이 무엇이 잘못 될 수 있는지 모른다. "일일 스크럼"이 팀에 미칠 수있는 단점에 대해 언급 된 이유가 있습니까? 개발자가 일일 스크럼에 지친 이유는 무엇입니까?

여러 고용주와 함께 "SCRUM"팀에 참여한 경험이있었습니다. 관리자들은 "매일 스크럼 회의"를 SCRUM의 주요 요점으로 삼아 보다 효과적인 개발주기를 달성하기위한 수단 인 목표로 설정하는 대신 목표로 설정 한 것으로 보입니다 .

매우 빠르게 15 분 회의가 45 분 회의가되었습니다. 사람들이 다른 사람들의 말을 듣는 대신에 하품을하고 "우리가 언제 갈 수 있을까요?" 올빼미 같은 사람이 매일 오전 9시에이 멍청한 모임에 출근하는 것이 그 일을 그만두기에 충분한 이유입니다.)

관리자가 올바르게 적용하면 좋은 아이디어를 취하고 극단적으로 생각하면 예상 한 결과와 정확히 반대가됩니다. 나는 개인적으로 내가 더 많은 회의에 참여한다고 생각합니다. 나는 일주일에 2 번의 정기 모임을 가지고 있으며 보통 그 중 하나를 건너 뜁니다. 회의는 관리자를위한 것이며 개발자가 업무를 수행하도록합니다.

나는 "그러나 너무 훌륭하다"라고 말할 수있는 SCRUM 애호가들이 많이있을 것이라고 확신합니다.

나는 가치가 거의 없거나 전혀 없다고 생각하면 매일 지루하고 쓸모가 없다는 것을 알게 될 것입니다. 일일 스탠드 업의 유용성을 줄일 수있는 몇 가지 사항이 있습니다.

• 공유되는 정보는 어떤 식 으로든 나와 관련되거나 영향을 미치지 않습니다.
• 팀 소유권 부재 및 항상 자신의 프로젝트를 수행하는 모든 사람.
• 스탠드 업 외부의 팀 커뮤니케이션 부재.
• 가시적이거나 의사 소통되는 진행 부족.
• 공유 할 정보가 없습니다.

이것들은 내 머리 꼭대기에 있지만, 항상 더 많은 이유가 있습니다.

아마도 개발자에게 왜 관심이없는 것처럼 보이는지 물어보아야합니까? 더 많은 / 더 나은 의사 소통을 원한다면 시작해야합니다.

매일 스크럼 회의에서 발생하는 몇 가지 문제 :

• 너무 오래 지속되는 것들. 그들은 이런 종류의 문제의 근본 원인이기 때문에 매일 그 관리자를 원하지 않습니다. 그들이 일반적으로 의자를 사용하는 사람이되는 방법을보십시오 (예, 그 사람들을 위해 서 있어야 사람들이 빠르도록 유혹합니다)
• 나중에 또 다른 실제 회의를 예약하기로 결정하는 대신 자신이 오랫동안 가지고있는 고립 된 문제를 설명하는 사람 (또는 2 명 또는 3 명)에 대해 들어야합니다.
• 바보 같은 시간. 그 회의는 아침에있을 필요는 없습니다. 당신은 당신이 어제했던 것에 대해 말하지 않고 오늘 무엇을할지 결정하지 않습니다. 당신은 당신이 지난 매일과이 일 사이에 한 일에 대해 말하고 다음 일까지 할 일을 결정합니다.
• 개발자를위한 앱 소유권 부족. 개발자가 코드 원숭이로 취급되지 않으면 SCRUM이 작동합니다. 프로세스가 잘못되는 첫 징후는 개발자가 무언가를 수행하는 데 걸리는 시간을 평가하는 사람이 아닌 경우입니다.
• 또 바보 같은 시간. 팀의 일부가 어떤 일을 시작하고 매일 일어날 때 "지역에"있다면, 그것은 귀찮게됩니다. 매일 그 (것)들을 위해 좋은 시간은 아무도 일하지 않아야 할 때입니다 (예를 들어 점심 후에, 또는 점심 동안 토론을 시작하기 직전에).

타이밍 은 많은 사람들의 살인자입니다. 프로그래머는 늦게 코딩하고 늦잠을 자고 아침이 지나간 후에 들어옵니다. 정해진 시간에 사무실에 있어야하는데 너무 빠릅니다. 일찍 와서 이미 일을 시작한 다른 사람들에게는 너무 늦었습니다.

흐름 은 또 다른 문제입니다. 일부 기능을 갖춘 프로그래머는 밤 늦게까지 작동하고 집으로 돌아와서 재충전하고 계속 사용할 수 있습니다. 대부분 관련이없는 문제가있는 회의에 앉아야한다면주의가 산만해질 수 있습니다.

내 관찰은 너무나 자주이 회의는 관리자가 팀과 프로젝트에 유용하지 않고 실제로 무언가를하고있는 것처럼 보이고 느끼는 것입니다.

예를 들어, 팀은 다른 프로젝트에서 일련의 짧은 버그 수정을 수행하도록 지정됩니다. 그들은 실제로 팀으로 일하지 않고 개인으로 일하고 있습니다. 그러나 회사 / 부서 정책에 따라이 팀의 관리자 / 관리자는 매일 스크럼 회의를 개최합니다. 무용 한 회의를 위해 15 분 이상 걸리고 회의 전후에 15-30 분의 산만 함과 생산성 부족을 달성했습니다.

이제 마감 시간이 촉박하고 다양한 작업을하는 사람들 사이에 많은 조정이 필요한 프로젝트에서 스크럼이 잘 수행되는 것을 보았습니다. 그런 맥락에서 그것은 훌륭한 시스템이었습니다. 그러나 "스크럼 / 애자일 상점이기 때문에 회의를하고 있는데 그것이 바로 우리가해야 할 일"이라는 맥락에서 볼 때 정말 짜증납니다.

아무도 회의를 독점하지 않도록하십시오.

개발자의 4 5 분, 다음 10 분 안에 길에서 자신의 과장되게 떠벌 리다를 얻을 경우 모든 선발 팀 리더를 듣고 소요되는 놀라운 , 멋진 놀라운이나 멋진만큼 어느 쪽도없는 대부분의 그가 만든 새로운 개발, 그가 생각하는대로 사람들은 매우 빨리 지루해질 것입니다.

잠시 뒤에 서서 팀에 대해 생각해보십시오.

• 그들은 효과적으로 일하고 있습니까?
• 작업이 정시에 완료 되었습니까?
• 코드가 강력하고 잘 작성 되었습니까?
• 팀은 균열을 통해 아무것도 떨어지지 않도록 보장합니까?
• 팀은 작업을 복제하거나 서로의 발가락을 밟지 않도록 자체 조정합니까?

이 모든 것에 대한 대답이 "예"라면 팀의 일일 회의, 번 다운 차트 및 작업 보드와 같은 바쁜 업무를 강제해야하는 이유를 고려해야합니다. 어떤 가치를 더합니까? 자신의 즐거움을 위해서만 관료적 데이터를 생성하고 싶거나 팀의 생산성을 높이고 자하십니까?

일일 스크럼이 중단 된 후 생산성이 저하 되었습니까, 아니면 모든 것이 이전과 동일하게 똑딱 거리고 있습니까? 아무것도 변경되지 않으면 왜 회의를 계속합니까?

15 분. 이 15 분 (및 준비 시간)이 팀 구성원간에 충분한 새롭고 유용한 정보를 전달하여 다음 날 팀 생산성을 15 분 이상 향상시킬 수 있습니까? 매일 유용한 양의 스크럼 컨텐츠가 없다면, 팀원들은이 회의에서 최대한 빨리 나가서 다시 일을 시작하면 목표를 향해 훨씬 더 진전 할 것이라고 생각하고있을 것입니다.

게시판과 차트를 자주 업데이트하려면 위키에 초안을 넣으십시오.

회고 회의를 열어 "잘 된 일"과 "잘못 된 일"을보고 개발자가 일일 스탠드 업 회의 자체를 시간 낭비로 표시하는지 확인하십시오. 그런 다음 약간 재구성해야합니다.

내 개인적인 경험 :

• 목표는 우리가 오늘하고있는 일과 어제 어디에 있었는지 아는 것입니다. 의제를 고수하는 대신, 두 사람 사이의 차단제에 대한 기술적 논의에 빠져들고 다른 15 명은 지루합니다. 문제를 식별하지만 외부에서 논의
• 사람들은 정시에 회의실에 들어 가지 않으며, 이것은 일부 사람들이 의도적으로 수행하는주기가됩니다. 따라서 스크럼 마스터는 회의 시작 시간과 종료 시간을 보장하기 위해 회의 밖에서 그들과 조용히 토론해야합니다.
• 우리는 이미 스크럼 회의 외부의 번 다운 차트를 업데이트하여 일일 스탠드 업의 주요 목적이 아닙니다.

저항은 다음과 같은 경우에 온다 : 1) 사람들이 오전 9시에 서두르도록 강요한다. 기차가 늦을 때 추가 스트레스입니다. 2) 불충분 한 스크럼 리더십. 리더는 사람들에게 영향을 미치지 않는 것을 듣고 주위에 서 있지 말고 사람들이 오프라인으로 물건을 가져 가도록 지시해야합니다. 3) 가치없는 콘텐츠. 이것은 다시 스크럼 리더십 문제입니다. 병목 현상, 궤적 문제 및 잠재적 협업을 해결하기위한 포럼이어야합니다. 실제로 일어나는 일은 모두가 그날 다른 사람에게 무의미하거나 관심이없는 그날에 일할 것으로 예상되는 것을 말합니다. 4) 서. 나는 서 있지 않습니다. 서있는 논리는 사람들이 간략하게 격려한다는 것입니다. 사람들은 실제로 상관없이 딸랑 딸랑합니다.

나는 여러 번 스크럼 팀을 관리하고 일해 왔습니다. 개발자가 스크럼을 좋아하지 않는 주요 이유는 다음과 같습니다.

• 그것들은 매우 불량한 스크럼 마스터에 의해 실행되기 때문에 45 분으로 바뀌면 스크럼 마스터는 스크럼 제어를 개선해야합니다.
• 그들이 가장 싫어하는 가장 큰 정직한 이유는 나쁜 직장 윤리에 숨어 있기가 매우 어렵 기 때문입니다. 내가 함께 일한 일부 개발자는 충격적이며 30 분 일 해야하는 작업을 수행하는 데 며칠이 걸립니다. 좋은 PM은 개발자의 장벽을 제거해야합니다. 즉, 스프린트에서 작업을 수행 할 수 있어야합니다. 개발자들은 매일 일어나서 진전을 보여주기 때문에 좋아하지 않습니다. 어떤 이유에서든 진전을 보여줄 수 없을 때 불안감을 유발합니다. 유효한 문제로 인해 좋은 스크럼 마스터가 해당 문제를 최대한 빨리 해결해야합니다.

스크럼 마스터가 차단 문제를 해결할 권한, 기술 또는 기능이없는 경우 문제가 발생합니다. 사실 나는 그들이 사라지기를 희망하는 일부 매장 문제를 보았습니다. 이것은 재앙입니다.

솔직히 내가 방문한 일일 스크럼 회의의 99 %에서 거의 모든 토론 / 질문 / 응답이 몇 개의 이메일로 해결 될 수있었습니다.

나는 솔직히 회의를 갖지 않기 위해 더 유효한 이유를 제시해야한다고 생각합니다. 모든 사람을 직접 회의실에 모을 때가 좋은 이유가되었고 시간 효율성을 극대화하도록 조직 된 환경을 구축하십시오.

나는 일반적으로 회의를 싫어하고 화상 회의, 전화, 이메일, 업무 흐름에 방해가되지 않고 업무에 참여하거나 머무를 수있는 모든 것을 선호합니다.

개인적으로 8 시간 동안 회의가 4 회 이상이면 프로젝트가 제대로 관리되지 않고 있다고 생각합니다.

회의 긴장에 기여하는 많은 요소가 있습니다. 회의가 가치가있는 것보다 더 많은 비용을 지불해야하는 중요한 이유 중 하나로이를 고려하십시오.

• 초점-소프트웨어 대 회의
• 관리-관리자는 측정이 필요합니다
• 성격-내향적인 사람과 외향적 인 사람
• 시간-인터럽트, 메이커 및 관리자 시간
• 목표, 우선 순위

이러한 각 요소는 아래에 설명되어 있습니다.

포커스 -나는 소프트웨어 개발을 즐깁니다. 여기에는 문제 (문제)에 대한 생각, 솔루션 만들기, 소프트웨어 구축 및 회의가 소프트웨어 구축 작업에 집중하는 데 방해가됩니다. " 흐름 "이라는 상태가 있습니다. 개발자가 문제에 몰입하고 (문제) 솔루션의 정신 모델을 구축했으며 솔루션 구축에 전적으로 집중했습니다. 개발자는 자정까지 일하고 먹고 자러 떠난 다음 떠난 곳과 가까운 상태로 돌아갈 수 있습니다.

개발자는주의가 산만 해지지 않아야하며 많은 사람들이 심야에 코드를 작성하면 소음, 전화 통화, 바쁜 사무실 및 개발자가 아닌 동료가 작업을 방해하지 않는 것이 좋습니다. 그리고 10시, 11시 또는 12 시까 지 일한 후에는 나중에 (10, 11, 정오?) 근무하는 것은 무리가 없습니다. 개발자가 오전 9 시부 터 자정까지 작업하는 것이 합리적입니까?

스크럼 (및 기타) 회의는 개발자가 소프트웨어를 구축하는 기본 목적에서 벗어나게합니다.

관리 -관리자는 성공하기 위해 측정해야하므로 일정, 결과물, 타임 라인, 우선 순위 및 회의가 진행 상황을 측정 및보고하고 종속성, 지연 및 위험 영역을 노출해야합니다. Scrum의 과제는 관리자가 이러한 것들을 필요로하지만 개발자가 집중해야한다는 것입니다. 회의는 관리자에게 서비스를 제공하고 관리자가 상태 및 진행 상황을 확인, 측정 및 추적 할 수있는 방법을 제공하지만 회의는 개발자에게 유용하지 않습니다. 관리자는 방해 요소를 처리하고 장벽을 제거하며 개발자가 소프트웨어 구축에 집중할 수 있도록하면 더 많은 가치를 제공 할 수 있습니다.

회의 필요성에 대한 솔루션이 있습니다. 관리자는 개발자를 방문하거나 상태 보고서를 요청하거나 방해가 덜 방해되는시기에 대한 프로토콜을 채택하거나 개발자가 인터럽트 가능할 때 진행 상황을 알리는 정책을 채택 할 수 있습니다. 이것이 중요한 이유에 대한 시간 토론을 참조하십시오.

성격 -어떤 사람들은 내향적인 사람이고 다른 사람들은 외향적 인 사람이라는 것을 고려하십시오. 외향적 인 사람들은 사회적 상호 작용을 즐기고 재충전합니다. 내향적인 사람들은 관리자로서 성공할 수 있지만 일반적으로 외향적 인 사람들은 외향적 인 사람들입니다 (외향적 인 사람들은 일반적으로 사회적 상호 작용에 더 유리하기 때문에). 내 향적 인 사람들은 사회적 상호 작용을 즐기고 능가 할 수 있지만 고독으로 재충전됩니다. 개발자는 종종 내 향적이며 사회적 상호 작용이 "필요하지"않기 때문에 혼자 또는 소규모 팀에서 성공적으로 일하고 있습니다. 그들은 문제에 대해 혼자 일하는 것이 행복 할 수 있습니다 (외향적 인 사람들도 개발자가 될 수 있음). 일일 스크럼 회의는 사교 모임이 될 수 있지만 외향적 인 사람에게는 좋지만 내향적인 사람에게는 좋지 않습니다.

시간 -개발자는 회의 중에 코드를 작성할 수 없습니다. 또한 회의에 방해가되는 동안 어려운 문제에 대해 생각할 수 없습니다 (브레인 스토밍을하지 않는 한). 개발자는 소프트웨어 구축에 집중하기 위해 중단없는 큰 시간 블록이 필요합니다. 회의는 그들의 노력을 방해하는 방해입니다. 몇 시간 동안 문제 해결에 몰두하고 거의 끝났으며 누군가가 "스크럼 시간"이라고 말하면 중단되고 "기어 변속"중에 작업 시간이 손실 될 수 있습니다. 또는 오후 11 시까 지 직장에 머물 렀거나, 직장을 떠나거나, 집을 여행하고, 문제를 잤거나, 일어 났고, 문제를 해결하기 위해 일하기 위해 다시 여행 한 다음, 한 시간 동안 문제를 해결 한 후에 중단되었습니다. "스크럼을위한 시간"입니다.

Paul Graham 은 Maker Time vs. Manager Time에 대한 훌륭한 기사를 썼습니다. 계획된 또는 계획되지 않은 회의 중단으로 인해 흐름이 중단 될 수 있으며 개발자가 제작자 시간에서 관리자 시간으로 강제 전환 될 수 있습니다. 날 믿어, 당신은 메이커 타임에 개발자를 원한다.

목표, 우선 순위 -개발자와 관리자는 목표와 우선 순위가 다릅니다. 관리자는 일정을 추적하고, 비용을 최소화하며, 보고서에 책임이 있고 수행되도록해야합니다. 개발자는 과제 / 문제를 해결하는 소프트웨어를 구축 할 목표를 가지고 있습니다. 이러한 목표는 상충되지 않지만 긴장을 유발하는 커뮤니케이션 메커니즘입니다. 회의는 관리자의 요구를 충족시키고 관리자의 시간을 최적화하지만 개발자의 요구와 충돌합니다. 스크럼 회의는 회의의 첫 번째 규칙을 버리고 "의제를 가지고"더 방황하는 경향이 있습니다. 회의는 커뮤니케이션을 최적화하는 데 사용되지만 (관리자에게는) 개발자 시간 (중단, 흐름 손실 등)이 발생합니다.

목표는 무엇입니까? 품질, 시간, 비용, 프로세스 등 제약 조건을 신속하고 품질로 충족시키는 소프트웨어를 구축합니다. 스크럼 및 기타 민첩한 방법론은 프로세스 제약 조건을 인식하고 해당 요소를 최소화하려고 시도하며 해당 제약 조건을 최소화하여 성공했습니다. 그러나 회의를 추가하면 시간이 걸리고 중단으로 인해 개발자는 회의 시간보다 훨씬 많은 시간이 소요됩니다.

혜택을 제공하도록 회의를 수정하십시오.

1. 편의를 제공 할 수 있도록 한 번에 예약하십시오. 업무 시작 후 30 분이 지나서 모든 사람이 이메일을 검토하고 회의에 대한 생각을 정리할 수없는 이유는 무엇입니까? 간결한 계획이 필요합니다. 준비되지 않은 사람들은 영원히 흔들릴 수 있습니다.
2. 회의 중에 문제가 전달 된 경우 피할 수있는 문제를 식별하십시오. 누구나 요점이 무엇인지 이해해야합니다.
3. 모든 사람의 의견을 최소화하기 위해 필요한 모든 조치를 취하십시오. 토론의 장소가 아닙니다. 토론이 필요한 주제에 중점을 둔 사람들이 매일 모임 이외의 모임을 개인적으로 예약하도록합니다. 규칙 : 한 번에 한 사람 만 이야기합니다.

모든 불만 제기자는 문제에 기여하지 않는지 확인해야합니다. 덜 고통스러운 방식으로 일일 스크럼에 대한 목표를 달성 할 수 있다면 듣고 싶습니다.