나는 큰 백엔드 구성 요소가있는 Android 및 iOS 용 새로운 모바일 앱을 개발하는 개발자입니다. 우리는이 프로젝트를 세 번 밟았으며 모든 행사 (정제, 기획, 데일리, 회고 등)와 함께 스크럼을 사용합니다.

두 번의 스프린트에서, 팀은 초과 근무와 주말에 (지급받지 않은) 일을해야했습니다. 모두 열심히 일했지만 일부 외부 의존성과 낙관적 추정으로 인해 모든 스프린트 스토리를 달성하기가 어려워졌습니다.

내 경험상 일부 스프린트 동안 완료되지 않은 스토리 비율이 약간 정상적이며 다음 스토리에서 다루어 질 수 있습니다. 그러나 프로젝트 관리자는 우리가 스스로 판단을 내렸을 때 그것이 우리의 잘못이라고 말하며 스프린트의 모든 항목을 완료해야합니다.

1. 이것이 내가 알지 못하는 스크럼의 허용 / 공통 변형입니까?

2. 내가이 일을해야한다고 어떻게 제안합니까?

몇 가지 눈에 띄는 것입니다.

경영진이 팀이 일련의 작업을 수행한다는 아이디어는 최신 버전의 Scrum Guide와 일치하지 않습니다. "커밋"또는 "커밋"이라는 단어는 가장 최근 (2017 년 11 월) 버전의 스크럼 안내서에서 두 번만 사용됩니다. 한 번은 스크럼 값을 나열 할 때 한 번은 "사람이 스크럼 팀의 목표를 달성하기 위해 개인적으로 노력한다는 것을 나타냅니다" ".

목표에 대한 아이디어는 스크럼에게 중요합니다. 조직과 팀은 광범위한 목표를 가지고있을뿐만 아니라 스크럼에서 각 스프린트는 스프린트 계획에서 제품 소유자와 개발 팀 간의 협력으로 정의 된 스프린트 목표를 가지고 있습니다. 스프린트 목표는 제품 백 로그의 항목을 구현하여 달성 할 수 있지만 단순히 "이 작업 본문을 마치는"것은 아니며 종종 완전한 스프린트 백 로그를 나타내지 않습니다. 즉, 스프린트에 대해 선택된 모든 단일 제품 백 로그 항목 또는 스프린트 백 로그의 모든 단일 항목을 완료하지 않고도 스프린트 목표를 달성 할 수 있어야합니다. 나의 현재 생각은 스프린트 목표를 달성하는 데 필요한 작업이 팀 용량의 60-70 % 정도가되어야하지만 용량을 고려해야한다는 것입니다. 하지만 조직마다 다를 수 있지만

초과 근무 및 주말 근무는 민첩한 소프트웨어 개발 관행입니다. 기본 원칙 중 하나는 모든 이해 관계자가 지속 가능한 속도로 작업 할 수 있다는 것입니다. 긴 날과 주말은 돈을 지불하더라도 팀에게는 지속될 수 없습니다.

이 시점에서 몇 가지 다음 단계가 있습니다. 팀의 스크럼 마스터는 스크럼 및 애자일 소프트웨어 개발의 가치와 원칙 (예 : "약속"및 "지속 가능한 페이스")에 대한 관리를 교육해야합니다. 팀은 작업을 예측하고 제품 소유자와 범위를 협상하는 기능을 수행해야합니다. 또한 팀은 이러한 상황을 초래 한 장애를 해결하거나 예방하기 위해 노력해야합니다 (외부 종속성의 영향 제거 또는 감소).

팀이 계획된 모든 스토리를 완료하기 위해 초과 근무를해야하는 상황에서 설명하는 상황은 Scrum 문헌이 "커밋"이라는 용어 사용을 중단 한 이유 중 하나입니다. 제 3 자 종속성에 대한 불확실성, 각 항목의 작업량, 질병을 고려하여 모든 사람이 이용할 수있는 시간 등을 포함하여 모든 불확실성이 제거 될 때만 진정한 약속을 할 수 있습니다.

Scrum의 기본 아이디어 중 하나는 팀이 지속 가능한 속도로 작업한다는 것입니다. 이는 본질적으로 초과 근무없이 (유료 또는 무급) 정상적인 근무 시간을 의미합니다. 이는 직접 허용되는 스크럼 변형이 발생 하지 않았 음을 의미합니다 .

당신이 할 수있는 일은 당신의 역할에 달려 있습니다.

당신이 개발자라면, 당신이 할 수있는 최선의 방법은

• (통칭 개발팀)는 스프린트 내에서 제공 할 수있는 것보다 더 많은 작업에 "커밋"하기를 거부합니다. 이것은 아마도 경영진이 원하는 것보다 훨씬 적을 것입니다.
• 새로운 작업을 시작하기보다는 작업을 마무리하는 데 집중하십시오. 일부 작업을 완료 할 수없는 경우 계획을 조정할 수 있도록 가능한 빨리 표시하십시오.

스크럼 마스터라면 스크럼에 대한 경영진을 교육하여 가치를 입증 할 수 있습니다. 나에게 눈에 띄는 몇 가지 사항 :

• 첫 번째 단락에서 언급했듯이 팀은 스프린트 계획 중에 약속을하지는 않지만 완료 될 것으로 예상되는 작업을 예측합니다.
• 스프린트가 끝날 때 미완성 작업을 피해야하지만 프로젝트 시작시 (또는 팀 구성 변경 후)이 상황은 거의 피할 수 없습니다. 스프린트에서 팀이 실제로 수행 할 수있는 작업량은이 구성에서 팀의 마지막 몇 스프린트의 역사적 수치를 기반으로 결정될 수 있습니다. 프로젝트 초기에는 이러한 역사적 수치가 존재하지 않으므로 처음 3 개의 스프린트에서 달성 한 팀은 각 스프린트에 대해 계획된 것이 좋은 계획보다 더 우연한 것입니다. 지속 가능한 속도로 약 5 회의 스프린트 후 팀이 스프린트 내에서 실제로 얼마나 많은 작업을 완료 할 수 있는지에 대한 합리적인 아이디어를 얻기에 충분한 데이터가 있습니다.

PM은 사업과 관련이 없습니다.

PM은 무급 연장 근무를 요구하는 사업이 없습니다.

분명한 일은 모든 작업이 제 시간에 완료되도록 보장하는 방식으로 모든 작업을 추정하는 것입니다. 그런 다음 과업을 과소 평가한다고해서 무료로 끝내야한다면, 과도하게 평가하면 일없이 시간을 보낼 수 있기 때문에 두 번째 방법으로 술집에 갈 수 있어야합니다.

여기에는 여러 가지 측면이 있지만, 예를 들어 PM은 계획된 작업이 완료되지 않은 이유를 명확하게 이해하려고합니다. 그러나 이것은 회고에서 제기되고 해결되어야한다. 개발 측면에서 스프린트 실패에 기여할 수있는 많은 요소가 있습니다.

고려해야 할 사항 :

스프린트에 너무 많은

정기적으로 너무 많은 일을 저지르면 스프린트가 실패합니다. 스프린트 속도는 시간이 지남에 따라 추적되어 최적의 포인트 수 (또는 일)가 무엇인지 확인해야합니다.

자원 할당

스프린트 계획은 행사, 공휴일, 교육, 관리, 지원 및 기타 프로젝트와 같은 비 개발 활동을 적절하게 설명해야합니다. 모든 사람이 매 시간마다 매분마다 물리적으로 사무실에 있다고 가정하면 자동으로 실용적이지 않으며 즉시 출발에서 당신을 뒷발에 올려 놓으십시오.

변동 추정

구체화를하고 있지만 항상 오버런되는 특정 종류의 작업이 있습니까? 일반적으로 이들은 누락되거나 모호한 요구 사항에 해당합니다. 요구 사항이 모호한 경우 스토리를 적절히 조정하거나 스파이크가 계획되지 않은 경우 스프린트로 만들면 안됩니다.

속도

속도가 제대로 추적되면 실제 스토리 수가 분명해집니다. 그것은 그들이 항상 제 시간에 끝날 것이라고 말하지는 않지만 일을 훨씬 쉽게해야합니다.

좋은 의지

모든 프로젝트에서 선의는 제한적입니다. 당신이 지속적으로 시간을 제공하기 위해 노력하고 있다면 사기가 고생하고 개발자가 타 버릴 것 입니다. 이것은 프로젝트 관리 실패 입니다. 이미 설명했듯이 스프린트 계획은 속도와 스파이크를 사용하여 현실적인 이야기 수만 예약하여 길을 따라갈 수 있도록하십시오.

스파이크

아이템의 품질이 나쁘거나 평범한 양모 인 경우, 나중에 스프린트를 위해 더 나은 추정치를 제공하기 위해 스파이크를 넣는 것을 두려워하지 마십시오. 그렇습니다. 일부 사람들은 추정하기에 좋지 않지만 대부분의 경우 전체 사실은 당시에 알려지지 않았습니다. 이상적으로, 이것은 세련미에서 다뤄지거나 PO에 의해 일찍 포착되어야하지만 때로는 스프린트로 빠져들 수 있습니다. 개발자는 달리 잘 달리는 스프린트를 쉽게 어뢰 할 수 있으므로 이러한 문제를 해결해야합니다.

아니요, 이것은 매우 중요한 이유 중 하나 인 인식 된 형태의 애자일 이 아닙니다. 모든 것을 전달하겠다고 약속하면 애자일을하지 않고 폭포를하고 있습니다. 대신 애자일을하고 있다고 생각하면 , 아마도 폭포수를 제대로 못하고 있을 것 입니다. 낡은 톱이 "좋고 빠르며 싸고 두 개를 고르세요"라고 들었을 것입니다. 소프트웨어 개발에서는 "제 시간에 예산에 맞춰 제공되는 모든 기능 중 첫 번째 또는 다른 두 가지를 선택"하는 것과 비슷합니다. 폭포가 첫 번째를, 애자일이 두 번째를 선택합니다.

민첩 해지 려면 시간 내에 완료 할 수없는 스프린트에서 스토리를 제거 할 수 있는 유연성 이 필요 합니다. 이를 수행 할 수있는 한 가지 방법은 제품 소유자에게 MoSCoW 우선 순위를 사용하여 스토리를 평가하도록 요청하는 것입니다. 여기에는 완료해야 할 필수 스토리로 스토리의 총 60 % (총 스토리 포인트 기준), 프로젝트가 완료하고 최소 실행 가능한 제품이 출시 될 때 완료해야하는 20 %, 시간이 있으면 완료 될 수 있으며 현재 릴리스의 범위를 벗어나는 것이 있으면 안됩니다. 또한 머스트 해브는 결합 할 때 다른 카테고리의 아이템을 포함 할 필요없이 최소한의 가능한 제품을 만들기 위해 뼈에 충분한 고기를 가져야합니다.

Sprint 백 로그에서 품목을 폐기할지 여부를 결정하는 것은 팀이 요청한 후 제품 소유자의 책임이며 Sprint 백 로그에서 폐기 된 품목은 제품 소유자가 평가 한 후 다음 중 하나입니다. 프로젝트에서 완전히 삭제되거나 프로젝트 백 로그에 적절한 순위로 배치됩니다.

이 경우 제품 소유자가 프로젝트 관리자 인 것 같습니다. 어떤 작업을 제거할지 결정하는 것이 그의 일이 될 것이므로, 과다 커밋에 대해 당신을 비난해서는 안됩니다. 왜냐하면 그것을 보상하기 위해 작업을 포기하는 것이 그의 일이기 때문에 그가 그렇게하지 않는 것처럼 보입니다.

그는 스프린트 사이에 이월이 없어야한다는 것이 맞습니다. 스프린트 사이에 이월이있는 스크럼 팀은 반 패턴이며 표준 스크럼이 유효한 결과로 받아들이는 것이 아닙니다.

그러나 그의 접근 방식은 좋지 않습니다.

스프린트 동안 팀은 수행중인 작업과 선택한 스토리를 마무리하는 스프린트 계획에 대한 헌신을 유지할 수 있는지 지속적으로 모니터링해야합니다. 팀이 모든 스토리를 완료 할 수없는 것으로 확인되면 PO를 만나고 스프린트에서 제거 할 스토리를 선택해야합니다. 그렇게함으로써 모든 사람은 이야기 작업을 중단하고 나머지 이야기를 완수하는 데 집중합니다. 기억하십시오 : 2 층을 반으로 끝내는 것보다 1 층을 완전히 끝내는 것이 항상 좋습니다.

외부 의존성과 부정확 한 추정의 문제는 회고전이 존재하는 이유입니다. Retro 동안 팀은 이러한 문제를 반영하고 식별해야합니다. 그런 다음 팀은 이러한 문제에 대한 솔루션을 찾아 구현해야합니다. 시스템과 평범한 경험을 더 잘 알고 있으면 추정을보다 정확하게 할 수 있습니다. 외부 의존성은 어렵지만 고칠 수는 없습니다.

스크럼 마스터 는 PM ( 스크럼 팀에서 PM이하고있는 일이 무엇입니까? )도 모든 이야기를 마치도록 강요해서는 안됩니다. 대신에 불만이 있으면 회고를 위해 보관해야합니다. 더 좋은 점은 이야기가 제 시간에 끝나지 못하게하는 문제를 해결하는 것의 일부가되어야합니다.

이것이 내가 알지 못하는 스크럼의 허용 / 공통 변형입니까?

없음 . 완전히 잘못되었습니다. 내가 할 수 어쩌면 동정 지불 주문서는 스프린트가 끝나기 전에 사실로 추정을주는 실수를하는 경우, 초과 근무,하지만 무급 초과 근무가 완전히 말도 나를 최대한 빨리 다른 직장을 찾아 만들 것입니다.

이에 대해 내가 행동해야한다고 어떻게 제안합니까?

내 경험에 비추어 볼 때, 많은 사람들이 논리적 인 주장을 듣지 않을 것입니다. 그것이 얼마나 깨진 지 알 수있는 유일한 방법은 show 가 아니라 show 입니다. 따라서 다음에 예상하고 커밋 할 때는 가능한 한 적은 양을 커밋 하십시오 . 스프린트 끝에서 작은 티켓을 완성하기로 약속하십시오. 하루에 할 수있는 일. PM이 어떻게 반응하는지보십시오. 그런 다음 시스템이 어떤 시스템이 사용되며 무엇에 거기에서 토론을 시작 해야 사용할 수.

일반적으로 프로젝트 시작시 팀의 속도를 결정할 때 새로운 팀이라는 사실을 고려하여 보수적 인 (보통 평소보다 낮은) 숫자를 사용합니다. 팀이 정착하는 데 약간의 시간이 걸립니다. , 서로 이해하고, 기능 및 NFR 요구 사항 등을 이해합니다. 기본적으로 처음 몇 번의 스프린트 후 팀 속도를 최적화하면 분명히 그 시점부터 속도가 향상됩니다.

처음에는 더 높은 속도를 내고이를 달성하기 위해 팀을 늘릴 필요가 없습니다.

한 가지 더 중요한 것은 놓칠 수없는 전달 약속이있는 일회성 시나리오에서 프로젝트 관리자는 주말에 스트레칭, 늦게 작업 및 작업에 대한 팀에 압력을 가할 수 있다는 것입니다. 그러나 그것은 일의 규범이 아니라 예외로 간주되어야합니다. 그렇게하면 단기적으로 속도가 높아질 수 있지만 장기적으로는 코드 품질 문제, 팀 소진 문제, 동기 부여가 낮은 불행한 팀 등을 초래할 수 있으므로 비생산적입니다.

약속 FAQ

이 동작이 정상입니까?

잘 모르겠습니다.

놀랍습니까?

아닙니다. 어떤 사람들은 약속의 모든 것이 완료 되어야 한다는 것을 의미 하는 "약속" 을 항상 이해 합니다 .

좋은 생각입니까?

민첩한 개발은 핵심 주제로 지속 가능성 을 가지고 있습니다. 그것은 대부분 현명한 생각입니다. (경영진이이를 수락하지 않으면 조직을 민첩하게 부르지 않아야합니다.)

우리는 무엇을해야합니까?

• 스프린트 내용은 추정치에 근거한다고 설명한다 . "추정"은 때때로 정확하고 일반적으로 잘못됨을 의미합니다. 잘못되면 때로는 너무 낮고 때로는 너무 높습니다.
• 작업 속도보다 추정 동작을 변경하는 것이 훨씬 쉽다고 설명하십시오.
• 팀이 너무 높은 견적에 대해 처벌을 받으면, 단 한 번의 스프린트에서 다음 스프린트로 일부 컨텐츠를 푸시하는 것보다 그 정도가 낮아지고 경영진은 더 많은 진전을 잃을 것이라고 설명한다.

좋은 점은 : 프로젝트 관리자가이 모든 것을 이미 알고 올바른 것으로 인식 할 것입니다. 그것은 단지이다 단기적으로 하나가 그들을 무시하는 것이 좋습니다.

귀하의 관리 팀에 동의하지 않습니다. 스프린트를 끝내기 위해 초과 근무를해서는 안됩니다.

그러나 약속이 불가능하다는 생각은 소프트웨어 개발에 대한 오해에서 비롯됩니다. 많은 팀이 이전 스프린트에서 완료 한 스토리 포인트 수만큼 스프린트에서 완료 할 수있는 스토리를 예측하려고하는 것을 보았습니다. 가능하다면 소프트웨어 개발은 ​​선형 적이라고 할 수 있습니다. 즉, 두 시간을 일하면 한 시간보다 두 배나 더 많은 일을합니다.

소프트웨어 개발은 ​​창의적이므로 선형 적이 지 않습니다. 팀이 스프린트에서 수행 할 수있는 작업을 관리자에게 알리고 해당 스토리를 전달하는 것이 더 좋습니다. 지속적으로 약속을 잃어버린 경우 이야기의 범위를 전혀 알지 못했거나 제품 소유자가 더 많은 일을하도록 압력을 받고 있습니다.

전자의 경우 스토리를 적용하기로 동의하기 전에 스토리의 범위를 이해해야합니다. 후자 인 경우 문화 문제가 있으며 수행 할 수있는 작업이 거의 없습니다.