스프린트는 얼마나 편안해야합니까?

스프린트에 배정 된 이야기를하는 것에 대한 태도는 무엇인가? 분명히 스프린트에서 작업을 수행하도록 우선 순위를 정하고 싶지만, 민첩성의 전체 요점은 역동적입니다. 예상치 못한 일이 일어나고 그 이야기가 끝나지 않고 다음 스프린트로 밀려날 때, 당신은 당신이 잘못한 느낌을 원하지 않습니다. 그것은 무섭거나 부정적인 경험이 아니어야합니까?

스프린트 커밋을 놓치면 부정적인 / 무서운 경험이 허용됩니까? 처리해야 할 예기치 않은 작업 (예 : 생산 지원)이 발생할 때 누락 된 스프린트 약속에 대해 개발자가 책임을 져야합니까?

당신이해야 절대적으로 스프린트 내에서 수행 항목을 얻을 것을 목표로하고 있습니다.

SCRUM의 주요 이점 중 하나는 프로젝트에 '하트 비트'를 제공한다는 것입니다.

우선 순위를 정하고, 목록에서 항목을 선택하고, 전달하고, 데모하고, 진행 방식을 반영한 다음, 예측 가능한 주기로 다시 수행합니다.

모든 계획, 추정 및 우선 순위는이 개념을 기반으로합니다. 스프린트 내에서 X 포인트를 수행 할 수 있고 커밋 할 것이며, 시간이 지남에 따라 더 나은 계획을 위해 사용할 수있는 속도를 설정할 수 있습니다.

당신이 당신의 스프린트의 내용과 약속에 너무 캐주얼하면 스크럼은 내 의견으로 고장 나면 많은 이점을 잃습니다.

물론 현실 세계는 때때로 이것에 대해 말할 것이 있지만 그것은 규칙이 아닌 예외입니다 ....

핵심은 스토리를 완성하지 못하는 것에 대한 책임 이 필요하다는 것 입니다.

즉, 스토리가 완료되지 않은 확실한 이유가 있어야하며이 이유는 앞으로 진행될 프로젝트 계획에서 설명되므로 반복되지 않습니다.

이 이유는 모호한 "물건이 생겨난 것"이상이어야합니다.

예를 들어 팀 구성원이 프로덕션 문제에 대해 작업해야했기 때문에 스토리가 완료되지 않은 경우이 팀 구성원의 시간을 줄이거 나 다른 적용 범위를 마련하여 향후 반복에서이 가능성을 해결해야합니다.

더 많은 부지런함이나 선행 노력으로 그 이유를 피할 수 있었다면,이 책임은 다소 고통 스러울 수 있습니다. 다행스럽게도 "당신이 일을하지 않습니다"라는 다양성보다는 "이번에 우리가 다음에 더 잘해야 할 것"의 다양성에 고통이 있기를 바랍니다.

그것은 무섭거나 부정적인 경험이 아니어야합니까?

한두 번 발생하면 부정적인 경험이되어서는 안됩니다. 정기적으로 발생하면 문제가있는 것입니다. 팀은 항상 극복하고 있습니다. 스프린트를 위해 커밋 한 것에 대해 더 잘 생각하고 두 번 생각하지만 걱정하지 마십시오.

편안한 스프린트는 당신이 미달 된 것을 의미합니다.

비 완성 스프린트는 초과 커밋을 의미합니다.

나는 커밋 한 것을 전달하고 커밋을 더 잘하려고 노력합니다. 특별한 상황에서만 이야기를 다음 스프린트로 옮기겠습니다. 마감일 직전에 압력을 가하는 것보다 매일 약간의 압력을받는 것을 선호합니다.

내 경험을 바탕으로- 민첩한 다른 것들과 마찬가지로, 우리는 추정을 포함한 지속적인 피드백 시스템에 적응합니다.

첫 스프린트 (프로젝트의 시작)에 대한 마감 기한을 놓치는 것은 괜찮지 만, 팀의 강점 등을 모르고 잘못 판단한 것 (예상치 부족)을 배우게됩니다. 그런 다음 피드백을 가져 와서 다음 스프린트로 보내면 더 나은 추정치를 얻을 수 있습니다.

내 경험으로 볼 때, 새로운 민첩한 프로젝트에서 11 개월이 지났는데, 우리가 그것을 놓치 더라도 마감 기한을 거의 놓치지 않습니다 . 그러나 우리는 팀원의 속도와 힘을 알지 못했기 때문에 첫 스프린트의 마감일을 놓쳤습니다.

일부 사람들은 첫 스프린트가 첫 스프린트 문제를 극복하기 위해 더 많은 시간을 "할당"한다고 주장합니다.

여기에서 답변 / 의견을 보는 것이 흥미 롭습니다. 내가 작업 한 모든 민첩한 (유형) 프로젝트에서 가장 큰 장점은 프로젝트가 끝날 때 마감일 3 월이 아닌 많은 미니 마감일에 마감일 압력을 분산시키는 것이 었습니다. IMO는 스프린트를 심각하게 고려해야합니다. 마감 시한이나 기능이 부족하면 프로젝트 관리 또는 개발 과정에서 잠재적 인 문제로 간주해야합니다.

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

그것이 무섭거나 부정적인 경험이고 항상 발생한다면 문제가있는 것입니다. 소프트웨어 개발은 ​​재미 있어야합니다. 부정적이거나 무섭지 않습니다.

그러나 팀이 스프린트에서 일부 스토리를 끝내고 지속적으로 전달하지 않으면 문제가 있습니다. 이 문제는 팀에 더 많은 압력을 가하여 스토리를 완성함으로써 해결되지 않을 것입니다. 외부 요인으로 인해 문제가 발생하면이를 관리해야합니다. 팀이 과도하게 커밋하는 경우 ScrumMaster가 더 적은 스토리 포인트에 참여하도록 팀을 안내 할 수 있습니다. 여러 가지 이유가있을 수 있으며 각각 다른 방식으로 해결해야합니다. 활기차고 동기 부여 된 팀은 앞으로 나아갈 동기가 충분해야합니다.

문제가 무엇이든 이상적으로는 회고 중에 제기되어 수정됩니다.

팀이 비교적 짧은 스프린트 기간 동안 달성 할 수있는 것을 파악한 후 달성하는 것은 그렇게 복잡하지 않아야합니다 (때때로 다음 스프린트로 진행되는 이야기는 괜찮습니다. 속도가 변동될 수 있으며 상황이 변하는 등) ). 몇 번의 스프린트 후 합리적으로 원활하게 진행할 수 없다면 뭔가 잘못한 것입니다.

실제로 타임 라인에 따라 다릅니다.

때때로 당신은 모든 이야기를 끝내거나 대부분의 이야기를 끝내야 할 것입니다. 애자일은 약간의 유연성을 제공하지만, 프로젝트를 타이트한 일정으로 완료해야합니다. 따라서 대부분의 스토리를 완료하면 프로젝트를 제 시간에 완료 할 수 있습니다.

그럼에도 불구하고 모든 이야기와 스프린트를 끝내지 못하게하는 물건이 나올 것입니다.

제품이 타임 라인에 있고 주요 기사가 누락 된 경우 해당 coudl은 제품을 늦게 만듭니다. 경우에 따라 제품이 늦어지면 회사의 경쟁력이 떨어질 수 있습니다. 따라서이 경우 스토리가 누락되어 부정적인 경험이되고 싶을 수 있습니다.

올바르게 복용하면 스트레스가 좋습니다. 당신은 모든 스트레스를 없애고 싶지 않고, 시간에 더 고르게 퍼 뜨리고 싶을뿐입니다. 좋아하는 게임을 할 때도 스트레스와 부정적인 감정이 사라집니다. 실제로 더 많은 에너지를 얻습니다.

팀은 놓친 이야기에 대해 진정으로 기분이 나 빠져야합니다. 그것은 다음에 무언가를 바꿀 에너지를 줄 것입니다 (다른 방식으로 일하거나 적은 이야기를 계획하십시오, 둘 다 좋습니다). 물론 그들은 이야기를 할 때 자랑스러워해야합니다.

또한 예기치 않은 작업 (생산 지원)에 대해서도 언급합니다. 그것은 나와 함께 붉은 깃발을 올립니다. 이야기와 관련이없는 모든 문제에 대해 합의 된 시간 상자가 있어야합니다. 그렇지 않으면 게임이 불공평하고 팀이 무력감을 느끼고 부정적인 감정을 개선하는 데 사용하지 않습니다.

약속을 실패하게 만드는 요소를 살펴보고 해결하려고 노력해야합니다. 대량의 무작위 이벤트는 스프린트를 엉망으로 만들어 속도를 예측할 수 없게 만듭니다. 이 문제의 원인을 해결하거나 스프린트에 여유 를 줄이십시오. 나는 고정을 선호합니다.

어느 쪽이든, 외부 요인으로 인해 업무를 방해하는 팀은 책임을 질 수 없습니다. 이것을 회고하려면 회고를 사용하십시오.