스크럼 평가에 대한 협상 및 격퇴 시도가 프로세스의 합법적 인 부분입니까?

나는 스크럼 회의에서 개발자들이 종종 이야기에 대해 현실적인 평가를한다는 것을 알아 차렸다. 그러나 다소 단순한 이야기조차도 구성, 타사 구성 요소 설정, 테스트 및 최종 빌드에 많은 노력이 필요하며 시스템에는 상당한 기술적 부채가 축적되어 제품 소유자 또는 관리 자에게는 추정치가 너무 높습니다.

PO는 종종 다음과 같은 추정치를 극복하려고 시도합니다. "이 스토리에 대해 13 개의 스토리 포인트 [4 일]를 원합니다. 이것은 불가능합니다! 이것을 관리자에게 설명 할 수 없습니다. 누군가가 이것을 코딩 할 수 있어야합니다. 3 시간 내내 [4 시간 내! " 결과적으로 개발자는 팔을 꼬아 5 ~ 8 스토리 포인트 (1.5 ~ 2 일) 추정치에 전념합니다 (Scrum 추정치는 예측뿐만 아니라 여전히 확약으로 간주 됨).

물론 (주로 테스트 및 품질에 대한) 기대치를 제거 할 계획이 없으면 이러한 스프린트는 종종 실패합니다. 개발자의 추정치는 정직하고 현실적인 것으로 추정치를 내리는 것이 실제 수행 할 작업을이기는 것은 아닙니다.

"누군가가 당신을 강요한다고해서 불가능한 약속을해서는 안됩니다!" 그러나 제 생각에 개발자의 임무는 소프트웨어 디자인과 코딩이며, 협상이나 압력에 맞서는 것이 아닙니다! 일반적으로 외부 고객과 직접 거래하는 모든 거래의 잭이있을 수 있지만 대부분의 사무실 개발자는 아닙니다!

나 에게이 연습은 프로그래머를 저크처럼 보이게하고 지속적인 스프린트 실패를 유발하며 현실적인 추정을 방지하고 실제 개선점을 찾습니다.

스크럼 지침서에서이 주제에 대해 무엇을 말하고 있습니까?

편집 : 시간을 스토리 포인트로 대체했습니다. 작업 세부 계획이 아닌 Planning Poker 및 스토리 포인트를 사용하여 초기 추정 단계를 언급했습니다. 나는 종종 요일 / 시간을 거기에 넣었습니다. 왜냐하면 그것이 때로는 대신 시간이있는 전형적인 대화이기 때문입니다. 혼란을 드려 죄송합니다! 스토리 포인트 예제는 시간 예제보다 더 긴 기간을 나타냅니다.

편집 2 현재 전용 스크럼 마스터가 없으며 평가 회의에서 PO가 그 역할을 수행합니다. 따라서이 중립적이거나 개발자 스크럼 마스터가 아닌 권위자로 보이므로이 부적절한 협상을 악화시키는 역할 충돌 일 수 있습니다. 아마도 이것은 가능한 한 "마스터"가 아닌 편견이있는 참가자로 그를 고치면 해결 될 수 있습니다.

당신이 묘사하는 상황은 유독합니다. 이런 종류의 협상은 팀의 현실과 전문성을 무시하고, 팀과 조직의 정보를 의도적으로 숨기고, 시간이 지남에 따라 팀이 개선되는 것을 방해합니다.

http://www.scrumguides.org/scrum-guide.html 을 권한 으로 도시하려면 다음 을 강조 표시하십시오.

다가오는 스프린트를 통해 개발팀 만이 달성 할 수있는 것을 평가할 수 있습니다.

과

스크럼은 투명도에 의존합니다. 가치 및 통제 위험을 최적화하기위한 결정은 아티팩트의 인식 된 상태에 따라 이루어집니다. 투명성이 완성되는 한, 이러한 결정은 건전한 근거를 가지고 있습니다. 인공물이 불완전하게 투명 할 경우 이러한 결정에 결함이있을 수 있으며 가치가 떨어지고 위험이 증가 할 수 있습니다.

제품 소유자는 4 시간 만에 작업을 수행 할 수 있습니다. 그것은 합리적인 목표 일 수도 있습니다. 건전한 반응은 팀의 추정을 받아들이고 정확한지 측정하고 "이러한 종류의 작업을 더 빨리 완료하기 위해 무엇을 변경해야합니까?"라고 묻는 것일 수 있습니다. 작업과 관련된 작업의 범위를 협상하는 것도 합리적 일 수 있으며 개발자와 제품 소유자가 해당 작업을 이해하는 방법에 중요한 차이를 강조합니다. 새로운 정보없이 팀이 추정치를 변경하도록 요구하면 부정확 한 추정치 만 보장됩니다.

개발 팀이이 패턴을 변경하기 위해 사용할 수있는 많은 전략이 있지만 "관리자에게이를 설명 할 수 없습니다"라는 응답을 예를 들면 매우 긴장됩니다. 제품 소유자가 관리에 대한 신뢰를 얻지 못하고있는 것 같습니다 (정확하지 않은 추정치가 도움이되지 않을 수도 있음). 현재 프로세스 실패에 대해 투명하지 않을 수도 있습니다.

제 생각에는 SCRUM의 가장 큰 성과 중 하나는 스토리 포인트를 개발하는 것이며 여기에 언급 된 교섭 문제를 피하려는 명백한 의도가 있습니다. 스토리 포인트의 요점은 작업과 며칠이 걸리는 지 직접 연결을 피하는 것입니다. 대신,이 두 가지 개념은 속도라는 개념으로 연결됩니다.

내가 개발자 였고 13 점 이야기를 8 점 이야기라고 부르기 위해 팔을 꼬고 있다면 행복하게 순종 할 것입니다. 그들의 추정 능력은 그들이 영향을 미치고 있습니다. 모든 난이도를 맞추기 위해 단순히 확장 할 것입니다. 결국 팀의 속도는 주당 스토리 포인트 측면에서 감소하여 경영진이 스토리 포인트를 "돌릴"것입니다. 경영진에게 전달되는 숫자는 다음과 같아야합니다. "우리는 이정표를 달성하는 데 필요한 스토리 포인트 수를 50 % 줄였습니다. 그러나 속도가 50 % 감소한 결과 순 효과는 우리입니다. "우리가하고자하는 시간을 정확히 달성 할 수있을 것입니다." 속도의 개념은 경영진의 희망적인 사고와 싸우기 위해 존재합니다.

이제 볼 가치가있는 두 가지 극단이 있습니다. 하나는 완전한 관리 실패이며 다른 하나는 실제로 관리가 관심을 갖는 매우 중요한 관심사입니다. 첫 번째 사례는 개발자들에게 "생산성이 충분하지 않다는 것입니다. 더 많은 스토리 포인트 가치의 작업을해야합니다"라고 말하는 SCRUM의 사형 선고입니다. 그렇게되면 실제로 스크럼을 사용하지 않는 것입니다. 쿠쿠 (Cookoo)는 둥지에서 스크럼을 걷어차 고 다음으로 돌아 오는 어미 새에게 먹이를 주려고합니다.

이제 경영진 이 생각 해야 할 경우 가 있습니다이런 식으로 팔을 비틀 수 있습니다. "속도가 주당 20 포인트 인 경우이 작업을 완료하는 데 50 스토리 포인트를 감당할 수 없습니다. 고객이 원하는 경우 30 스토리 포인트로 달성해야합니다"라고 말하는 것이 합리적이어야합니다. 스토리의 내용을 재협상하여 범위를 40 % 줄입니다. SCRUM은 개발자가 원하는대로 무엇이든 할 수있는 무료 식사권이 아니며,이를 수행하기위한 커뮤니케이션 도구와 경영진이해야 할 일에 대해 공개적으로 대화합니다. 또한 고객이 작업을 제 시간에 완료하지 못할 본질적인 위험을 기꺼이 받아들이려는 경우 개발자에게 압박을 가하고 "30 점 만에 작업 수행"이라고 말하는 것도 유효합니다. 마감일을 놓치면 개발자가 " 그리고 실제로 수행 한 모든 것을 받아들입니다. 팀의 생산성을 측정하는 더 좋은 방법이 있다고 생각하지만 그것이 작동하는 과정이라는 것을 인정해야합니다. 그리고 실제로 수행 한 모든 것을 받아들입니다. 팀의 생산성을 측정하는 더 좋은 방법이 있다고 생각하지만 그것이 작동하는 과정이라는 것을 인정해야합니다.

우선, PO는 경영진에게 작업 정보를 제공해서는 안됩니다. 작업 평가는 팀의 이익을위한 것입니다. 팀 외부의 모든 사람이 알아야 할 것은 작업중인 스토리, 포인트 값 및 팀의 평균 속도입니다. 티

둘째, PO가 소프트웨어에 대한 깊은 지식을 갖춘 선임 개발자가 아닌 한, 작업 평가에 대한 의견은 그다지 중요하지 않습니다. 개발자는 시스템에 대한 지식이있는 사람과 작업을 수행하는 사람입니다. 평가 기술이 전혀없는 학교 밖에서 모두 신입생을 제외하고는 추정을 제외해야합니다.

그것은 때때로 견적에 의문을 제기 할 수 없다는 것은 아닙니다. 그렇다면 긍정적 인 방식으로 발생해야합니다. 예를 들어 "우리가 이미"x "에 대한 작업의 절반을 완료했다고 생각했거나"Y를 수행 할 시간을 포함해야합니까? "

결론 : 개발자는 선의의 정확성을 유지하려는 한 원하는대로 추정 할 수 있어야합니다. 그들이 4 시간이 걸린다고 말하면 받아 들여야합니다.

스크럼 지침서에서이 주제에 대해 무엇을 말하고 있습니까?

그들은 아무 말도하지 않습니다. 작업 추정은 스크럼의 일부가 아닙니다. 스크럼을 사용하면 스토리 포인트에서 추정이 중지됩니다. 작업 평가는 팀이 스토리를 완료하는 데 필요한 모든 작업을 통해 생각하도록함으로써 스토리 포인트를 더 잘 평가할 수 있도록 돕는 도구 일뿐입니다.

스크럼 프로세스를 준수하는 것이 Scum Master의 임무입니다. 여기에는 스프린트에서 수행 할 수있는 작업량에 대해 팀이 일관되게 초과 커밋하지 않도록하는 것이 포함됩니다.
한편으로는 지나치게 열성적인 팀을 통치하지만 다른 한편으로는 팀에 압력을 가하는 경우 제품 소유자에게 다시 밀리는 것을 의미합니다.

약속 / 예측을 현실적으로 유지하는 한 가지 좋은 방법은 마지막 몇 가지 스프린트에서 실제로 실현 된 이야기를 보는 것입니다. 그것이 팀이 달성 할 수있는 것으로 증명 한 것이므로 완료되지 않기 때문에 스프린트로 훨씬 더 많은 작업을 수행 할 필요가 없습니다.

다른 답변에서도 알 수 있듯이 팀이 제공 한 견적에 대한 협상 은 Scrum 프로세스의 일부 가 아닙니다 . 이 팀은 소프트웨어에 가장 익숙하므로 작업량이 얼마나 많은지 가장 잘 알고 있어야합니다.

어떤 수 에 대해 흥정 할 것이있다 범위 이야기의. 제품 소유자가 스토리가 합리적으로 예상되는 것보다 크거나 작은 것으로 추정되는 경우, 팀에 설명을 요청하여 수행해야하는 작업에 대한 관점이 당사자간에 일치하는지 확인할 수 있습니다.
스토리가 실제로 그렇게 많은 경우, 제품 소유자는 스토리를 몇 개의 작은 스토리로 분할하고 해당 작은 스토리에 기능을 분배하도록 결정할 수 있습니다.

팀은 품질을 제공 할 책임이 있으며 협상을 위해 개방해서는 안됩니다.

예, 아니오

예, 스프린트 팀은 스프린트에 들어가는 것에 대해 제품 소유자와 협상해야합니다 .

아니요, 제품 소유자는 시간이 얼마나 걸리는지 말하지 않습니다 . 당신은 전문가가 아니라 전문가입니다.

보세요, 당신은 그런 종류의 쓰레기를 다룰 필요가 없습니다. 당신의 매니저 나 팀장이 당신을 성공으로 이끌 것입니다. 그것은 당신이 성공하기 위해 PM (또는 그들의 상사)을 다루는 것을 의미합니다. 그것은 그렇게 어렵지는 않습니다.

"아니."

그들이 뭘하려는 건가요? 코드 자체를 작성 하시겠습니까?

이 동작을 허용하는 것은 Scrum Master의 실패입니다. 그녀의 임무는 무엇보다도 팀을 보호하는 것입니다. 위에서 설명한 이유로 PO는 근시안적입니다. 스크럼 마스터는 토론의 맥락을 강화하고 긍정적 인 방식으로 재구성해야합니다.

물론 이러한 압력은 OP에 대해 이미 언급 한 속도의 압력을 낮추는 원인이됩니다. 팀이 지속적으로 스프린트를 끝내지 못하면 스크럼 마스터는 다시 한 번 들어서 왜 그런지 물어봐야합니다. 유독 한 환경에서 팀원들은 회고에 정직하게 느끼지 않을 수 있습니다. 그러나 그러한 상황에서 스크럼 마스터는 나쁜 행동을 불러 내고 팀을 보호 할 책임이 있습니다.

Scrum Master가 이러한 작업을 수행 할 수 없거나 수행 할 수없는 상황에 처한 경우 다른 Scrum Master가 필요할 수 있습니다. PO는 전형적인 압력에 반응하고 있습니다. 동굴 탐험에서 팀은 또한 사람들이 자주하는 것처럼 반응하고 있습니다. 스크럼 마스터의 임무는 그것이 무엇인지 확인하고 멈추는 것입니다. 여기서 OP의 책임은 이것을 회고에서, 그리고 필요한 경우, 리드 및 관리자에게 제기하는 것입니다. 그래도 문제가 해결되지 않으면 LinkedIn 프로필을 업데이트하고 더 나은 직원을 찾으십시오.

제품 개발 팀 (제품 소유자, 개발자, 테스터에 이르는 모든 사람)은 민첩한 프로세스를 따르고 합리적으로 유능한 사람과 현실적인 기대를 바탕으로 좋은 결과를 얻을 수 있습니다.

또는 애자일 프로세스와 표면적으로 유사한 프로세스를 따를 수 있습니다.

그 PO는 아마도 작업에 대한 더 낮은 시간 추정치를 얻으려고하면 더 나은 결과를 얻을 것이라고 생각합니다. 물론 작동하지 않습니다. 3 일이 걸리면 현금을 많이 주면 한 시간 안에 할 수있을 것으로 예상합니다. 여전히 3 일이 걸립니다. 약속 한대로 1 시간 안에 끝나지 않아서 내게 소리 치면 5 일이 걸립니다.

그가 달성 한 것은 민첩한 프로세스를 깨뜨리고 얻을 수있는 모든 긍정적 인 결과를 포기하는 것입니다. 스크럼 마스터는이를 방지 할 수있는 경험, 힘 및 용기를 가져야합니다. 경영진이 경험이없는 누군가를 스크럼 마스터로 만들거나, 스크럼 마스터에게이를 막을 수있는 권한을 부여하지 않으면 민첩성이 깨지는 것은 잘못입니다. 스크럼 마스터에게 용기가 없으면 PM과 책임을 나눕니다.

나는 그것이 동기 부여에 많이 달려 있다고 말하고 싶습니다. 추정의 가장 중요한 목표는 주어진 스프린트 동안 팀이 얼마나 많은 양을 달성 할 수 있는지에 대한 아이디어를 얻는 것입니다. 그런 다음 해당 속도를 기반으로 미래의 작업을 예측할 수 있습니다. 예를 들어, 팀이 스프린트 당 30 스토리 포인트를 완료하고 백 로그에서 아이템 X보다 약 60 스토리 포인트가 앞당겨지면 제품 소유자는 6 주와 같은 방식으로 아이템 X가 완료된다고 합리적으로 말할 수 있습니다 ( 표준 2 주 스프린트).

이 추정을 최대한 정확하게하기 위해 특정 항목의 스토리 포인트 수에 대해 의견이 일치하지 않는 것은 아닙니다. 스크럼은 실제로 그것을 장려합니다. 그 불일치는 때때로 가열 될 수도 있습니다. 그러나 궁극적 인 최종 목표는 PBI의 복잡성을 정확하게 추정하고 인위적으로 노력을 축소시키지 않으면 서 더 많은 PBI를 지정된 속도로 밀어 넣을 수 있습니다.

이것이 원칙적으로 포커 계획의 원리입니다. 모든 사람들은 그들의 추정을 제시합니다. 그런 다음 스크럼 마스터는 최고 및 최저 추정치를 가져 와서 팀원이 왜 그렇게 높거나 낮을 것이라고 생각하는지 묻습니다. 이를 통해 팀은 관련된 작업의 다른 관점을 듣고 작업이 실제로 얼마나 복잡한 지 더 잘 알 수 있습니다. 토론 후 모든 사람은 다시 견적을 던집니다. 이 과정은 복잡성에 대한 일반적인 합의가 이루어질 때까지 헹구어지고 반복됩니다.

다시 말해, 도전자는 그들이 왜 자신이 동의하지 않는 이유에 대한 근거를 가지고 있기 때문에, 당신의 추정에 도전하는 것은 잘못이 아닙니다. 그러므로 귀하의 평가가 여전히 옳다고 생각 될 경우, 귀하의 추정이 정확하다고 팀에 확신시키는 것은 귀하의 책임입니다.