스크럼 스프린트는 가능한 가장 빠른 속도로 작동한다는 의미입니까?


21

나는 최근에 Agile, Scrum을보다 정확하게 수행하는 회사와 인터뷰했으며 Agile처럼 보이지 않는 것들이 있습니다. 나는 특히 나에게 특히 관심이있는 한 가지 사례, 스크럼 스프린트의 사례를 취할 것이다.

내가 말한 특정 프로젝트 관리자 (예, 프로젝트 관리자에게 말했다)는 근무 시간이 끝났을 때 집에 가지 않는다는 것을 그녀 팀의 사람들이 이해했다 ( "알았다"는 것이 맥락에서 파악한 것임). , 일이 끝나면 아무리 많은 일이 있어도 집에 갈 수 있습니다. 내가 줄 사이에서 읽은 것은 가능한 한 많은 기능을 스프린트에 넣고 초과 근무가 발생한다는 것입니다.

이제는 지금까지 애자일을 수행하지 않았지만 (가장 폭포를 선호하는 금융 및 정부 기관과 협력) 내 이해는 다음과 같습니다.

  • 스크럼의 스프린트는 애자일의 일반 반복의 이름입니다.
  • 팀은 지속 가능한 속도로 작업하고 단시간에만 영향을 미치며 오랜 시간에 발생하는 문제로 인해 효과가 왜곡되므로 장기 초과 근무를 피해야합니다.

내 말이 맞습니까? 관리자의 프리젠 테이션을 적기로해야합니까?


애자일에 대한 실제 경험은 없지만, 내가 이해 한 바에 따르면, 스프린트 작업량은 스프린트 기간과 균형을 이루어야하므로 개발자가 작업량을 과소 평가하거나 관리자가 작업량에 대한 피드백을 요구하지 않고 작업을 제공하고 있습니다 . 이 경우 아마도 후자 일 것입니다. -그래도 틀렸다면 정정 해주세요
Andreas

4
@gnat 질문이 너무 다르다고 생각합니다
Andreas

27
"... 근로 시간이 끝나도 집에 가지 않고, 일이 끝났을 때 집에 돌아가도 아무리 걸리더라도 ..." 바람처럼 달려요. 그녀는 바보입니다.
JᴀʏMᴇᴇ

나는이 질문을 다시 열기로 투표했다. 제안 된 중복 is-agile-the-new-micro-micromanagement에 대한 질문은이 질문과 공통으로 관리자가 무언가를 "스크럼 (scrum)"이라고 부르며 이것이 실제로 스크럼인지 알고 싶어합니다. 이 질문은 "다른 개발자들과 대화 할 수 없다"는 제안 된 "시간외"에 관한 것입니다.
k3b

"... 근로 시간이 끝나도 집에 가지 않고, 일이 아무리 많아도 집에 가지 않으면"지속 가능한 페이스의 핵심 개념과 직접 충돌하는 것 같습니다. 식탁에 음식을 넣어야한다면 HST, 때때로 발생하는 경우 문제가 없습니다. 때로는 모든 노력에도 불구하고 위기가 발생하고 고객이 우선합니다. 그러나 그녀는 그것이 정기적으로 발생하는 것처럼 들리도록하고 훌륭한 것입니다. 그 이유는 그들이 발생 했는지 이해 하고 근본적인 문제를 해결 하기 위해 근본 원인을하지 않고 있다는 것 입니다.
돈 브랜슨

답변:


27

이러한 관행이 애자일의 원칙에 위배된다는 것을 알기 위해 멀리 검색하지 않아도됩니다. 애자일 선언문 의 기본 원칙 중 하나는 다음 과 같습니다.

민첩한 프로세스는 지속 가능한 개발을 촉진합니다. 스폰서, 개발자 및 사용자는 일정하게 일정한 속도를 유지할 수 있어야합니다.

몇 년 전, 스크럼은 미묘하지만 중요한 변화를 일으켰습니다 . 대신 팀의 투입 을 달성 할 수있는 일에 그들은 예상 그들이 끝낼 수 있습니다 생각.

그 변화는 학대 때문에옵니다. 그것은 당신이 묘사 할 때까지 집에 가지 않는 태도와 매우 흡사합니다. 개발 중에는 팀 외부에서 그들이 약속 할 수없는 많은 요소가 있습니다-날씨 비유를 사용하기 위해 내일 비가 올 것이라고 약속을 할 수는 없습니다.

질문에 직접 대답하려면 :

  • 예, 스프린트는 스크럼의 반복의 이름이 표시입니다 대답 의 차이를
  • 예, 팀은 지속 가능한 속도로 작업해야합니다. 초과 근무의 유일한 확실성은 팀의 생산성을 장기적으로 감소시킬 것이라는 것 입니다 .
  • 예, 그것은 붉은 깃발입니다!

23

그렇습니다, 당신 말이 맞습니다. 내가들은 말을 들었다면 최대한 빨리 도망 가겠습니다. 그들은 단지 민첩성을 변명으로 사용하고 있습니다. 고전적인 죽음의 행진처럼 들립니다.


3
죽음의 행진은 일반적으로 끝이 없습니까? 그것이 스프린트 후에 스프린트 작동하는 방법이라면 그 프로젝트는 영원한 지옥처럼 들립니다.
DXM

5
아니, 죽음의 행진에는 항상 "우리는 단지 다음 버전으로 넘어 가야한다. 그러면 우리는 버그를 리팩토링하고 고칠 수있다! 죄송합니다. 우리는 2 개월 후에 다음 버전을 고객에게 약속했습니다. 다음 다음으로 넘어 가야합니다." 번역!" 등등, 당신은 아이디어를 얻습니다.
Miki Watts

2
@DXM 모두가 종료되거나 해고되면 끝납니다. 죽음의 행진 프로젝트는 몇 년 동안 지속될 수 있습니다.
Dogweather

3
죽으면 @DXM 죽음 행진이 끝납니다.
Dave Hillier

흠, 나는 거기에 내 자신의 경험을 투영하고 있다고 생각합니다. 어쨌든 잘못 관리 된 프로젝트는 죽음의 행진과 다음에 어디로 갈지에 대한 수개월의 결정이 뒤섞인 조합입니다. 비어있는 백 로그로 엄지 손가락에 앉은 팀은 거의 8 개월이 걸렸습니다. 그런 다음 우리는 "우리는 매년 릴리스주기에있는"문을 릴리스 4-6 개월이 주어질 것
DXM

11

이를 수용 할 수있는 한 가지 중요한 사항이 있습니다. 팀은 스프린트 범위를 수락합니다.

스크럼에서 팀은 업무를 배정받지 않습니다. 제품 소유자는 팀과 협의하여 제품 작업 및 기술 (채무) 작업의 우선 순위를 정합니다. 그런 다음 프로젝트 관리자, 제품 소유자 및 팀 은 스프린트로 가져올 내용과 해당 작업의 범위에 대해 협상 합니다.

이 세계에서 팀은 본질적으로 "우리는 X 작업을 수행하고 테스트하고이 반복을 제공 할 수 있습니다"라고 말합니다. 따라서 팀이 때때로 이러한 약속을 충족시키기 위해 초과 근무를 할 것으로 기대합니다.

즉, 너무나 많은 곳에서 애자일을 좋아하지 않습니다. 따라서 팀 리더가 보통 상사 인 사람들과 효과적으로 협상 할 수있는 사람은 거의 없습니다.


8
"때때로 이러한 ( 잘못 추정 된 ) 약속 을 충족시키기 위해 초과 근무를한다 "=> 잘못된 추정치를 습관으로 만들기
gnat

1
@gnat-pssh. 추정치는 때때로 높습니다. 추정치는 때때로 낮습니다. 과소 평가가 추세가되면 문제 일 것입니다. 그러나 이것이 반복이 존재하는 이유입니다. 추정을 구체화하는 데 도움이됩니다.
Telastyn

8
프로그래밍 스웨트 샵은 일반적으로 근로자의 협상을 허용하지 않습니다.
maple_shaft

1
@ gnat : 팀으로서, 당신이 습관적으로 작업을 과소 평가하는 것을 발견한다면, 다음 스프린트에서 더 적은 일을하기로 결심해야합니다.
Bart van Ingen Schenau

관리 목표가 근무 시간 제한에 관계없이 가능한 한 많은 작업을 수행해야하고 (대부분의 경우 경험이이를 나타냄) 직원 목표는 유급 작업을 초과하지 않고 최대한 많은 작업을 수행하는 것입니다. 시간 (일부 관리자는 이것이 낙관적이라고 주장 할 수 있음을 인정합니다). 추정의 본질적인 오류에 관계없이 스케줄링은 항상 == 근무 시간으로 경향이 있습니다. 논리적 확장은 직원 목표를 과소 평가로 전환해야한다는 것입니다. @BartvanIngenSchenau 이것은 습관이 자연스럽게 발전하는 방법입니다.
Steven Evers

1

스크럼은 해당 스프린트 기간 동안 완료되는 일련의 작업을 추정하는 스프린트로 구성됩니다 (일반적으로 2 주이지만 1 일에서 4 주까지 어디에서나 보았습니다). 나는 이것이 잘못된 작업에 대한 동기를 부여한다고 생각합니다. PO (제품 소유자)는 스프린트 당 큰 커밋을 얻기 위해 낮은 견적을 원할 것입니다. 팀은 PM이 볼 수있는 멋진 번 다운 차트를 생성하기 위해 큰 견적을 작성합니다. 물론 이것은 엉터리 조직을 나타냅니다. 당신은 정말로 정확한 추정치를 얻고 싶거나 부족하여 다음 스프린트로 스토리를 넘기거나 일찍 마무리하고 추가 작업을 백 로그에서 가져 오는 것을 두려워하지 않습니다. "스프린트"라는 용어는 더 빨리 일하는 사람들의 이미지를 만들어 낸다고 생각합니다.


1
PO는 추정 과정에 참여하지 않아야합니다. 그들은 민첩했다, 팀은 무엇에 전적으로 추정 함께 올라오고에 대한 책임과 기반이 될 것입니다 팀이 PO는 백 로그의 우선 순위를 변경할 수 있습니다 추정하고있다.
DXM

2
"팀은 PM이 볼 수있는 멋진 번 다운 차트를 생성하기 위해 큰 견적을 내릴 것입니다.": 이것이 전체 메커니즘에 결함이 있다고 생각하는 한 가지 이유입니다. 팀이 차트에 공급할 견적을 제공하도록 강요하는 것보다 관리자가 신뢰하는 팀으로부터 훨씬 더 나은 성과를 얻을 수 있다고 생각합니다.
Giorgio

팀은 내가 말했듯이 예상치를 채우는 인센티브가 있어야합니다. PO가 비용을 지불하는 경우 PO는 더 적극적으로 추정하도록 압력을 가할 수 있습니다. 배경을 위해, 나는 스크럼 팀이 내 동료 인 컨설팅을 위해 일하는 반면, PO는 일반적으로 외부이고 우리의 비정상적인 청구 요금을 지불합니다 :)
jiggy

@Giorgio 신뢰할 수없는 팀은 항상 견적을 작성하고 상황을 악화시킬 수 있습니다. 그러나 신뢰할 수있는 팀, 심지어 전문가조차도 더 나은 평가를 배울 수 있습니다. 그렇기 때문에 추정 능력을 향상시키기 위해 추정 한 다음 실제 작업과 비교합니다. 이 메커니즘은 결함이 없으며 시스템을 활용하는 팀을 구성하는 것이 문제이며 관리 시스템에 관계없이 문제가됩니다.
Chris

1

아니요 : 스크럼 스프린트는 타임 박스 일뿐입니다. 스프린트 / 반복 시작시, 은 이전 성능, 가용성, 예정된 이벤트, 공개 장애 등을 기반으로 달성 할 수있는 스토리 포인트의 양을 추정합니다. 그런 다음 제품 소유자와 협상합니다. 스프린트에 넣을 사용자 스토리에 대해 그것이 팀이 제품 소유자에게 제공 하는 약속 입니다.

개발하는 동안 상황이 실제로 예측 된 것이 아니며 (결국 소프트웨어 개발 임) 팀이 약속을 이행하지 못할 위험이있는 경우, 제품 소유자에게 하나 이상의 스토리가 발생할 위험이 있음을 알립니다. 완료되지 않았습니다.

그리고 괜찮습니다. 물론, 스프린트가 끝났을 때 스프린트가 실패했다는 것을 인정해야하는 것은 기분이 나쁘지만,이기는 것은 아닙니다. 그것은 개선의 기회입니다. 스프린트가 끝나고 새로운 스프린트가 시작될 때 스프린트 회고전을하게되는데, 누군가 먼저 물어볼 것은 '이 스프린트에 실패한 이유와 다시 실패하지 않으려면 어떻게해야합니까? ? '. 한 가지 방법은 약한 노력을 줄이는 것입니다 (= 적은 스토리 포인트를 차지함).

tl; dr : 지속 가능한 페이스. 스크럼은 케이던스에 관한 것입니다. 팀은 스프린트마다 스프린트를 무한정 유지할 수 있습니다. 초과 근무는 그렇지 않습니다. 팀이 과로하게되고, 일이 엉성해지며, 회원이 병에 걸리거나 완전히 멈출 수 있으며, 실패한 스프린트보다 더 큰 문제가 있습니다.


0

민첩한 프로세스는 지속 가능한 개발을 촉진합니다. 스폰서, 개발자 및 사용자는 일정하게 일정한 속도를 유지할 수 있어야합니다.

민첩한 선언에서

항상 초과 근무를하는 것이 지속 가능한 것처럼 들리지 않습니다.

즉, 봄 약속이 강한 것으로 문제가 없으며 (팀이 원하는 방식으로), 초과 근무를 예상하거나 초과 계산 할 때 초과 근무를하는 것이 견적 또는 의사 소통에 더 나은 인센티브가됩니다. PO에 대한 기대.


0

내가 말한 특정 프로젝트 관리자 (예, 프로젝트 관리자에게 말했다)는 근무 시간이 끝났을 때 집에 가지 않는다는 것을 그녀 팀의 사람들이 이해했다 ( "알았다"는 것이 맥락에서 파악한 것임). , 일이 끝나면 아무리 많은 일이 있어도 집에 갈 수 있습니다. 내가 줄 사이에서 읽은 것은 가능한 한 많은 기능을 스프린트에 넣고 초과 근무가 발생한다는 것입니다.

스크럼이 아닙니다. 타임 박스에 제안 된 작업량 은 관리자의 희망 목록이 아닌 팀 속도를 기준으로 합니다. 그들은 단순히 끝없는 초과 근무가 "애자일"이라고 믿도록 속이려고합니다. 팀은 방해받지 않고 집중하면서 일하면서 더 효율적으로 작업 할 수 있지만 Scrum은 끝없는 효율성 향상을 위한 마술 지팡이가 아닙니다 .

관리자는 Agile에 대해 약간의 오해를 가지고 있거나 개발자가 어리석은 것이라고 생각합니다. 반면에, 팀이 스프린트를 계속해서받을 때, 그들은 초과 근무를해야한다는 것을 알고, 실제로 어리 석고 더 나을 자격이 없습니까?

나는 당신이 답을 알고 있다고 생각한다 ... ;-)

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.