실패한 스프린트 및 마감일 처리

많은 스크럼 서적과 기사에 따르면 스프린트 실패 (스프린트 백 로그에서 일부 기능을 완료하지 못한 경우)는 나쁘지 않으며 때때로 발생하며 팀이 실수를 통해 배우면 실제로 유용 할 수 있다고합니다. 다음 스프린트에서 무언가를 향상시킵니다. 그리고 팀은 그들이 저지른 작업을 완료하지 않은 것에 대해 처벌을 받아서는 안됩니다.

이것은 개발자의 관점에서 훌륭해 보이지만 소프트웨어 클라이언트 " Scrum-Addicts LLC "가 심각한 고객을 위해 무언가를 개발하고 있다고 가정 해 봅시다 ( " Money-Bags Corporation ") :

1. Scrum-Addicts 관리자는 Money-Bags 용 소프트웨어를 만들 것을 제안합니다
2. 그들은 기능 목록에 동의하고 Money-Bags는 배송 날짜를 제공하도록 요청합니다
3. Scrum-Addicts 관리자는 Scrum 팀과상의하며, 모든 기능을 완료하려면 3 주간 소요됩니다.
4. Scrum-Addicts 관리자는 안전을 위해 1 주일을 추가하고 1 개월 안에 소프트웨어를 배송하겠다고 약속하고 Money-Bags와 계약을 체결합니다
5. 4 번의 스프린트 (배송 마감일) 후에 Scrum 팀은 80 %의 기능 만 제공 할 수 있습니다 (새로운 시스템에 대한 경험 부족, 프로덕션 환경의 이전 기능에서 중요한 버그 수정 등).
6. Scrum이 제안한 것처럼이 시점에서 제품은 잠재적으로 선적 가능하지만 Money-Bags는 계약서에 언급 된대로 100 % 기능이 필요합니다. 그래서 그들은 계약을 어 기고 아무것도 지불하지 않습니다.
7. Scrum-Addicts는 Money-Bags로부터 돈을 얻지 못했기 때문에 파산 직전에 있습니다. 투자자들은 결과에 실망하여 더 이상 회사를 돕고 싶지 않습니다.

분명히 어떤 소프트웨어 회사도 Scrum-Addicts의 입장에 서기를 원하지 않습니다. 애자일과 스크럼에 대해 내가 이해하지 못하는 것은 팀이 위에서 설명한 상황을 피하기 위해 계획과 마감일을 처리하도록 제안하는 방법입니다. 요약하자면 두 가지 질문이 있습니다.

누구를 비난해야합니까?

1. 적절한 계획을 세우는 것이 그들의 일이기 때문에 관리자
2. 팀은 그들이 할 수있는 것보다 더 많은 일을하기로 결심했기 때문에
3. 다른 사람

무엇을해야합니까?

1. 관리자는 마감일을 원래 팀의 예상보다 2 배 또는 3 배 늦게 이동해야합니다.
2. 팀원들은 무엇이든 상관없이 자신이 저지른 모든 일을하도록 장려해야합니다 (스프린트 실패에 대한 처벌을함으로써)
3. 팀은 회사 기한 정책에 맞지 않기 때문에 Scrum을 삭제해야합니다.
4. 우리는 모두 소프트웨어 개발을 포기하고 수도원에 합류해야합니다
5. ???

귀하의 예에서 몇 가지 근본적인 관리 문제가 있습니다.

• Scrum-Addicts 관리자가 "하드 데드 라인"계약에 서명했지만 "새로운 시스템이 관련된"상황에서 안전 마진이 33 %에 불과할 경우 이는 무모합니다.

• 한 달 후에 기능의 x % 이상을 제공 할 수 있다는 것은 고객이 마감 시간에 기능의 80 % 만받을 때 적어도 부분적으로 돈을 지불하는 계약을 협상하는 데 사용될 수있었습니다. 전적으로 또는 전혀없는 계약은 소프트웨어 공급 업체 나 고객 모두에게 도움이되지 않는 것입니다. 이는 공급 업체에게 0 개의 돈이 아니라 고객을위한 0 개의 기능을 의미합니다. 그리고 "Waterfall"과 같은 전혀 또는 전혀없는 개발 방법론은 그러한 계약을 작성하게 할 뿐이며, 민첩한 접근 방식은 추가적인 가능성을 제공합니다.

• 첫 1 ~ 2 회 스프린트의 결과를 살펴보면 팀이 마감일을 맞출 수 없다는 점을 관리자에게 분명히 알 수있었습니다. 따라서 이전 조치를 취하고 나머지 태스크 및 기능의 우선 순위를 재 지정하거나 이전에 고객과 재협상을 시도해야합니다. 예를 들어, 관리자는 나머지 기능 중 일부의 범위를 축소하려고 시도했을 수 있으므로 팀은 계약에 언급 된 모든 기능을 제공 할 수 있었지만 각 기능은 축소 된 범위에있었습니다.

작업이 생각보다 오래 걸리는 것으로 밝혀지면 개발 방법론이 그로부터 당신을 구할 수 없습니다. 그러나 스크럼과 같은 민첩한 접근 방식은 경영진에게 해당 상황에서 발생하는 상황을 제어 할 수있는 더 많은 기회를 제공합니다. 만약 그들이 그러한 기회를 이용하지 않는다면, 그것은 팀의 문제가 아니라 "스크럼"의 문제가 아니라 "민첩성을 받아들이지 않기 때문에"고객의 실수가 아닌 그들의 잘못입니다.

" 민첩한 소프트웨어 개발 선언 "의 가치 진술 중 하나 는 다음과 같습니다.

계약 협상을 통한 고객 협업

Scrum-Addicts LLC 가 고객과의 협업을 설정하는 대신 계약을 협상 했다는 사실 때문에 민첩성에 의문을 갖게되었습니다.

한 가지는 분명합니다 : 모든 사람이 민첩성을 받아 들여야합니다. 민첩성은 개발자만을위한 것이 아닙니다. 관리자와 고객은 또한 Agile Manifesto의 가치를 수용해야합니다. 고객이 민첩성을 받아들이지 않고 엄격한 계약과 최소한의 협업이 필요한 경우 민첩성을 사용하지 않거나 더 나은 고객을 찾으십시오.

마감 기한 개발로 계약 버블에 고정되어있는 것은 고객의 잘못입니다.

누구를 비난해야합니까?

관리자, 법률 부서, 회계사-선택하십시오 ...

나는 그 예가 다소 고안되었다는 것을 알고 있지만, 100 % 만족하지 않으면 회사가 한푼도 지불하지 않고 걸어 갈 수 있다는 사실은 폭포와 민첩한 사고를 혼합 해야하는 것처럼 즉각적인 경보 벨을 울려 야합니다.

고객은 케이크를 먹고 먹기를 원합니다. Z 날짜까지 제품 X를 $ Y로받는 한 폭포, 미니 폭포, 민첩, 라라 랜드를 받아들입니다.

민첩한 개발을 위해서는 개발 팀과 고객이 방법 론적 관점에서 동일한 페이지에 있어야합니다. 문화의 차이가 씻겨 나올 것이라는 생각은 희망적이다.

IT 프로젝트는 미지의 문제를 처리합니다 . 이들 중 일부 알려지지 도 있습니다 알 수없는 미지수 . 그게 무슨 뜻이야?

모델 철도의 장난감 다리를 예로 들어 보겠습니다. 알려진 모든 매개 변수가 있습니다.

• 당신은 계곡이 얼마나 큰지 알고 있습니다

• 산의 재료, 높이, 안정성 등을 알고 있습니다.

• 필요한 재료의 양을 알고 있습니다

• 이전의 "프로젝트"에서 비슷한 것들을 만드는 데 얼마나 걸 렸는지 알고 있습니다

여가 시간과 돈 투자 계산에 영향을 미치는 많은 변수가 있습니다. 그러나 다음 주말에 끝날지 여부를 생각없이 말할 수 있습니다.

한 단계 더 나아가십시오.

• 자신의 모델 철도를 위해 다리를 만들지 말고 대신 완전한 낯선 사람을 위해 다리를 지으십시오. 당신의 임무는 두 산 사이에 철도 다리를 만드는 것입니다

• 모델 환경에 앞서 정보가 거의 없다고 가정하십시오.

• 풍경에 대한 정보는 두 산이 있는데 너무 크지 않은 것입니다.

• 산의 일관성은 바위와 젤리 사이입니다

• 총 비용은 최대 10 $입니다

• 작업장은 완전히 어둡고 빛의 가능성은 없습니다. 8 개의 상자 만 있습니다.

• 마감 시간은 3 시간입니다.

그것은 IT 프로젝트와 유사합니다. 교량 건설 경험이 있으며 알려진 지형에서 걷기 쉽습니다. 그것이 어려운 것은 어둠 이다. 당신이 거의 예측할 수없는 많은 것들이 있습니다 : 산의 측정은 어둠 속에서 어느 정도 시간을 파고 난 후에 만 ​​알려져 있습니다. 산의 일관성도 마찬가지입니다. 이를 통해 소요 시간과 비용 을 예측할 수 있습니다. 여기서 미지 의 것은 콘크리트 지형과 같이 프로젝트의 시작에서 알지 못하는 것들입니다. 그러나 가장 경험이 많고 보수적 인 추정치조차도 예측할 수없는 것들이 있습니다. 이것들 은 약간의 혼란을 일으키는 미지의 미지수 입니다.

모든 IT 회사는이를 알고 있어야합니다. 그들은 프로젝트 위험을 처리해야합니다.

1) (재무) 위험을 최소화하는 몇 가지 방법이 있습니다. 거래에는 모든 작업 증분에 대해 고객이 지불하는 비용이 포함될 수 있습니다. 따라서 증분 1이 전달 된 후 부분 요율을 지불해야합니다. 만큼 스크럼-중독자 LLC가 제공하는 최소한의 재무 위험이 있습니다. 보다 세분화 된 스프린트 목표 를 계획할수록 모든 스프린트의 총 위험이 줄어 듭니다. 즉, Money-Bags Corporation 이 계약의 80 %를 수령 한 경우 계약 금액의 80 % 이상을 지불해야합니다. 스프린트 실패 후 지불을 거부하면 100 % 지불 거부만큼 위험이 높지 않습니다.

2) Scrum-Addicts LLC 는 개발자들에게 문제가 있습니다

Scrum-Addicts 관리자는 Scrum 팀과상의하고, 팀은 Scrum-Addicts 관리자가 안전을 위해 1 주일 동안 추가 한 모든 기능을 완료하고 3 개월 동안 소프트웨어 배송을 약속하며 계약을 체결하는 데 3 주일이 소요될 것이라고 밝혔다. 돈 가방으로

즉, a) 개발자가 스크럼에 대해 경험이 없거나 b) 스크럼을 잘못 사용하고 있음을 나타냅니다. 팀이 추정하고 관리자가 "버퍼"를 "안전"으로 추가하면 관리자는 팀보다 더 잘 알고있는 것 같습니다 . 이는 나쁜 징조 입니다. 숙련 된 팀이있는 경우 "관리자 버퍼"가 필요하지 않으며 팀은 이미 추정에 포함했습니다. 아이디어는 팀이 함께 일한 스프린트가 많을수록 팀의 강점과 약점을 더 많이 알고 사실적인 추정을 할 수있는 몇 가지 메트릭이 있다는 것입니다. 물론 이미 언급했듯이 미지의 미지수는추정을 어렵게 만드는 경향이 있습니다. 또는 적어도 부정확하다. 그러나 장기적으로는 추정치가 더 좋아질 것입니다.

누구를 비난해야합니까?

1) 관리

위에서 말한 것처럼 : 위험 관리에는 분명히 실패가 있습니다. 회사가 파산 직전에 있다면 그 회사는 그럴 자격이 있습니다. 그런 회사에서 일한다면 떠나십시오!

2) 팀

관리가 완전히 어리석은 경우에도 팀은 그러한 프로젝트에 반대하여 연설해야합니다. 훌륭한 관리자는 위험을 알아야합니다. 그러나 훌륭한 개발자는 위험을 지적해야합니다. 그리고 무엇보다도 : 팀은 무언가 실패하면 조기에보고해야합니다.

무엇을해야합니까?

지금 : 법정에 돈 가방 을 가지고 가십시오

미래를 위해 : 그러한 계약을하지 마십시오

스크럼은 관리 실패에 대해 책임을지지 않습니다. 스크럼은 많은 IT 프로젝트가 실패한 경험을 바탕으로 개발되었습니다. 그것은 실패를 막을 수 없으며 팀이나 경영자의 무능력을 치료할 수 없습니다. 기본 아이디어는 다음과 같습니다.

• 의사 소통 방법을 구성하기 위해 (누가 언제 무엇에 대해 이야기하는지)

• 개발자보고 실패를 조기에 장려하기 위해

• 작업과 하위 작업에서 문제를 나누기

• 시간과 능력을 구조화하는 것

• 시간 슬롯을 통해 작업을 배포

• 예측 불가능을 좀 더 예측 가능하게 만들기 (계획 포커)

또는 전체 : 위험을 최소화합니다.

스크럼은 망치처럼 도구입니다. 좋은 도구인지 여부는 사용 방법에 대한 지식에 달려 있습니다. 그러나 때로는 드라이버가 더 적합합니다. 그것은 당신에게 달려 있습니다.

먼저, "누가 비난해야합니까?" 묻는 잘못된 질문입니다. 비난을 할당하는 것은 재미 있고 모든 일이며, 비난을받은 사람을 제외한 모든 사람을 안심시킬 것입니다 ( "이봐, 그건 내 잘못이 아니야, 사장님이 그렇게 말했어!"의미). 그러나 시간을 생산적으로 사용하는 것은 아닙니다. 실제로 비생산적 일 수 있으며 직원의 사기를 떨어 뜨릴 수 있습니다.

그것을 보는 더 좋은 방법은 "지연을 일으킨 이유"입니다. 기술 경험이 부족 했습니까? 테스트 / QA에서 감지되지 않은 치명적인 버그? 테스트 / QA 부족? 추정이 너무 낙관적입니까? 팀의 비 낙관적 평가를 고려하지 않습니까? 누군가 버스에 맞았나요? 원인이 무엇이든 다음 질문은 "이 문제가 다시 발생하지 않도록하려면 어떻게해야합니까?"입니다. 어떤 경우에는 (거의 드문 경우) 그에 대한 대답은 "무엇을 제거해야"하는 것일 수 있지만 "책임있는 사람을 처벌해야합니다"에서 시작하면 대부분의 경우를 볼 수 없을 것입니다 올바른 솔루션이 아닌 곳.

프로젝트 내에서 이미 침몰했습니다. 마감 기한이 지났을 때, 고객이 미끄러질 것이라는 점이 분명 해지 자마자 고객에게 경고했습니다. (그렇기 때문에, 그렇지 않은 경우 문제의 일부입니다) 이제는 처리되었지만 계약서 (실제로 계약서에서 철자가 맞습니까?). 일반적으로 말하자면 누락 된 내용을 전달할 방법을 고객과 협상해야합니다. 많은 사람들이 계약을 변경할 수없는 것으로 생각하고 싶어하지만 a) 계약을 철회하고 구매 한 물건이없는 경우 b) 계약 위반으로 회사를 고소하고 법원에서 많은 돈을 지출하는 경우 그리고 c) 가능한 한 최소한의 문제로 제품을 얻는 방법 협상, 대부분의 회사는 c를 선택합니다.

고객에게 가격 / 마감일을 인용하기 전에 마감 마감일 또는 비용 초과와 관련된 위험을 분석해야합니다 (이러한 사유의 원인은 무엇입니까? 약속해야 할 사항을 결정하는 데 도움이되도록 정보를 계획하고 사용해야합니다. 그것이 100 %이거나 아무것도 아닌 경우 위험이 높기 때문에 분명히 더 높은 가격과 더 긴 마감일을 인용 할 것입니다.

이 대답에서 Agile에 대해 이야기하지 않았다는 것을 알 수 있습니다. 이 시점에서 (고객이 Scrum에 참여한 것을 잊어 버리려고합니다. 매우 중요하지만 중요하지는 않습니다). Agile, Waterfall 또는 사용중인 개발 프로세스에서이 문제에 직면하게됩니다. 예, 애자일은 실제 문제가 조기에 발생했는지 확인하고 프로세스 자체에 고객을 참여시켜 항상 정보를 제공하지만 만병 통치약은 아닙니다.

첫째, 이것은 모든 개발 방법론의 문제입니다. 적어도 반복 개발 시스템을 사용하면 마감일이 끝날 때 고객에게 보여줄 것이 있습니다. 이는 고객이 더 이상 지불하지 않아도 제품을 완성하기 위해 연장을 얻는 데 충분할 수 있습니다.

마감일이 마감일 인 경우도 있지만, 게임을 작성 중이며 크리스마스 휴가 기간 동안 반드시 출시되어야한다고 상상해보십시오. 잘못하면 많은 회사가 파산했습니다!

특정 날짜까지 일정량의 기능을 완료해야하는 민첩한 방법의 경우 스크럼은 사용하기에 가장 좋은 방법이 아닐 수 있습니다. 필요합니다.

방법론에 관계없이 필요한 것은 진행 상황을 파악할 수 있도록 필요한 기능의 백 로그를 설정하는 것입니다. 스프린트 단위로 진행하는 것만으로는 충분하지 않으므로 궁극적 인 목표를 달성하고 있는지 알 수 없습니다. 따라서 칸반 스타일의 방법론이 더 나을 것입니다. 왼쪽에있는 모든 기능을 설정하고 시스템을 통해 작업하여 진행률을 표시합니다.

이는 스크럼이 처리하지 않는 방식으로 여전히 수행해야 할 일에 사람들의 마음을 집중시키고, 개발팀 이외의 사람들이 남아있는 내용과 목표를 달성 할 가능성이 있는지 여부를 확인할 수 있도록하여 (고객의 기대를 조기에 관리합니다) 초과 근무 수당 보너스가 필요하기 전에 준비하십시오.

스크럼 (Scrum)은 포터가 영원히 무언가를 정의하고 구체화하는 시스템입니다. 이러한 종류의 개발에는 적합하지 않습니다. 다른 사람들은이 sytle을 관리하고 반복 개발 개념을 유지할 수 있습니다. Kanban은 그중 하나입니다. 그러나 이해해야 할 것은 종교적으로 스크럼을 따르고 있다면 민첩하지 않다는 것입니다. 진정한 애자일 시스템은 이러한 특정 문제에 대처하기 위해 변형 할 수 있어야합니다. 이것이 애자일이라고 불리는 이유, 수행해야 할 작업에 대한 정보, 그리고 마감 시한이 그 일부인 경우에는 당신이 일하는 방식으로 그것을 고려하십시오.

개발 패러다임은 계약 패러다임과 맞지 않습니다. 이상적으로는 계약서 작성 방식이 변경되지만 실제로는 발생하지 않을 수 있습니다. 그러나 스크럼을 떨어 뜨려도 놀라움과 마감 기한을 놓쳤을 것입니다.

계약서 작성 방법을 변경하거나 변경하지 않고 작업 한 내용을 배송합니다 . 그런 다음 완료되지 않은 기능을 완료하기 위해 개발 시간주기를 사용하여 계약을 이행하십시오.

약속 한 날 약속 한 모든 것을 전달하지 못한 것이 좋습니까? 아니요, 그러나 제 시간에 작동하는 것을 제공 한 다음 단순히 늦게 달리거나 전혀 제공 할 것이없는 경우보다 빨리 나머지를 제공하면 고객이 훨씬 행복해집니다.

많은 스크럼 서적과 기사에 따르면 스프린트 실패 (스프린트 백 로그에서 일부 기능을 완료하지 못한 경우)는 나쁘지 않으며 때때로 발생하며 팀이 실수를 통해 배우면 실제로 유용 할 수 있다고합니다. 다음 스프린트에서 무언가를 향상시킵니다. 그리고 팀은 그들이 저지른 작업을 완료하지 않은 것에 대해 처벌을 받아서는 안됩니다.

이런 종류의 행동을 "처벌"하는 방법은 완료하지 않은 사람들이 다음 스프린트에서 수행 할 수있는 작업의 양을 제한하는 것입니다. 멋진 작업을 수행 할 가능성은 사라졌습니다. 좋은 일을하는 것에 대한 보상은 더 많은 일입니다.

이것은 개발자의 관점에서 훌륭해 보이지만 소프트웨어 클라이언트 "Scrum-Addicts LLC"가 심각한 고객을 위해 무언가를 개발하고 있다고 가정 해 봅시다 ( "Money-Bags Corporation").

Scrum-Addicts 관리자는 Money-Bag 용 소프트웨어를 만들 것을 제안합니다. 기능 목록에 동의하고 Money-Bags는 배송 날짜를 제공하도록 요청합니다. Scrum-Addicts 관리자는 Scrum 팀과 상담하고 팀은 3 주가 소요될 것이라고 말합니다. Scrum-Addicts 관리자가 안전을 위해 1 주일 동안 추가 한 모든 기능을 완료하기위한 긴 스프린트-한 달 안에 소프트웨어를 배송하겠다고 약속하고 4 개의 스프린트 (배송 마감일) 후 Scrum 팀과 계약을 체결 함 Scrum 팀은 80 % 만 제공 할 수 있음 Scrum이 제안한 것처럼이 시점에서 제품은 잠재적으로 배송 가능하지만 Money-Bags는 100 %가 필요합니다. (새로운 시스템에 대한 경험 부족, 생산 환경의 이전 기능에서 중요한 버그 수정 등) 계약서에 언급 된대로 그래서 그들은 계약을 어 기고 아무것도 지불하지 않습니다.

Scrum-Addicts는 Money-Bags로부터 돈을 얻지 못했기 때문에 파산 직전에 있습니다. 투자자들은 결과에 실망하여 더 이상 회사를 돕고 싶지 않습니다.

월요일에 목요일에 비가 올 것이라고 100 달러에 베팅하고 금요일까지 비가 내리지 않으면 내 돈을 가져가는 것이 옳습니다. 도박 기회가 아니라 원하는 날씨 예보 인 경우 화요일에 업데이트 된 예측을 제공 할 수있는 계약이 필요합니다.

분명히 어떤 소프트웨어 회사도 Scrum-Addicts의 입장에 서기를 원하지 않습니다. 애자일과 스크럼에 대해 내가 이해하지 못하는 것은 팀이 위에서 설명한 상황을 피하기 위해 계획과 마감일을 처리하도록 제안하는 방법입니다.

MB가 공을 가지고 집에 가고 싶어하는 이유를 생각해보십시오. MB는 처음부터 한 달 안에 작업을 수행 할 것을 요구하지 않았습니다. SA는 한 달 안에 100 % 중요한 기능을 약속했지만 제공하지 않았습니다. SA는 최종 기한을 MB가 아닌 것으로 설정했습니다. SA는 마감일에 1 주일을 임의로 추가했습니다. 그렇다면 왜 마감일입니까?

때로는 소프트웨어 회사가 업무를 위해 경쟁 할 때 달을 과시하고 약속하려는 유혹에 빠지기도합니다. 전문가들은 달이 필요한지 신중하게 결정합니다. MoneyBags에 가장 필요한 것은 무엇입니까? 한 달에 100 % 기능 또는 기능 제품? 그들은 정말로 중요한 것이 무엇인지 알고 있습니까? 예정된 마감일을 정하는 일정이 있습니까?

내가 Scrum-Addicts이 계약을 협상했다면 Money-Bags 비즈니스 요구에 대해 더 많이 알고 Money-Bags가 편안하게 사용할 수있는 유연성을 부여하기 위해 계약을 구성하고 싶습니다. 민첩한 프로세스가 어떻게 작동하는지 가르쳐서 우리에게 무엇을 기대해야하는지 알게되었습니다.

한 달 만에 모든 것이 갑자기 완벽하게 작동하기를 기대하는 대신 1 ~ 2 주 안에 첫 번째 제품을 평가할 것으로 기대됩니다.

요약하자면 두 가지 질문이 있습니다.

누구를 비난해야합니까? 관리자, 적절한 계획을 세우는 것이 그들의 일
이기 때문에 팀은
다른 사람 보다 더 많은 일을하기 위해 노력했기 때문에

우리가 한 달 전에 길을 잃기 전에 아무도이 비극을 막을 수있었습니다.

폭포 프로세스를 민첩하게 부당하게 대표하는 팀을 고용 한 것에 대해 Money-Bags Corp을 비난 할 수있었습니다. 계약 자체는 이것이 민첩하지 않다는 것을 분명히합니다. 한 달 안에 할 계획이 있어도 민첩하지는 않습니다.

민첩하다고 주장하면 한 달 동안 단 하나의 스프린트로 민첩합니다. 폭포와 같은 것이기 때문에 권장하지 않습니다.

무엇을해야합니까?

민첩은 어떻습니까? 스프린트마다 무엇인가를 제공 하시겠습니까? 마감일 전에 피드백을 받으시겠습니까? 일주일 동안의 스프린트? 마감일이 숨어 있고기도하기보다는 위험에 처한 것으로 의심되는 순간에 드라코 니아 계약을 재협상하는 것은 어떻습니까? 최소한 파멸 된 프로젝트에서 시간 낭비를 멈추고보다 합리적인 고객을 찾을 수 있습니다.

관리자는 마감일을 원래 팀의 예상보다 2 배 또는 3 배 늦게 이동해야합니다.

마감 시간 승수는 시계를 15 분 일찍 설정하는 것만 큼 유용하므로 늦지 않습니다. 자신이 무엇을하고 있는지 깨닫기 오래 전에 만 자신을 속일 수 있습니다.

초기 추정치가 잘못되었습니다. 얼마나 잘못되었는지 파악하십시오. 5 주, 몇 주 또는 몇 주가 걸리는 것은 완료 날짜가 얼마나 확실하지 않은지를 표현할 수있는 간단한 표현입니다. 정확하게 추측하기보다는 추측이 얼마나 야단한지 추측합니다. 실제 작업을 수행하고 실제 데이터를 얻으십시오. 그런 다음 더 좁은 범위로 추정을 시작할 수 있습니다. 1-2 주 정도면 충분합니다.

팀원들은 무엇이든 상관없이 자신이 저지른 모든 일을하도록 장려해야합니다 (스프린트 실패에 대한 처벌을함으로써)

팀원들을 격려해야합니다. 실패, 커밋 또는 기타. 처벌이나 보너스 (당근과 스틱) 연구와 같은 인공적인 결과를 만들어 내기보다는 프로그래밍과 같은 창조적 인 일을하는 사람들이 자율성, 숙 달성, 목적의 세 가지를 제공한다면 가장 잘 반응하는 것으로 나타났습니다.

Daniel Pink는 이에 대해 TED 강연 을했습니다. 이야기는 민첩하지 않은 동기에 관한 것이지만,이 점들을 민첩하게 매핑하는 방법을 쉽게 보았습니다.

자율성-나는 내 인생을 지시하고 싶다-백 로그에서 일을 골라 보자.
숙달-중요한 피드백-고객 피드백을 개선하고 싶습니다.
목적-나보다 더 큰 일원이되고 싶다-공동 작업 팀.

팀은 회사 기한 정책에 맞지 않기 때문에 Scrum을 삭제해야합니다. Scrum은 폭포보다 마감일을 더 정확하게 맞출 수 있습니다. 마감일 스크럼이 그것을 충족시킬 수 있습니다. 시간, 기능 및 기술에 따라 47 개 기능 중 1 개만 충족 할 수 있지만 충족 할 수 있습니다.

애자일 프로젝트는 매우 밤새 팀이 집에 돌아올 때마다 배송 준비가되도록 스타일을 지정할 수 있습니다. 고객에게 테스트를 요청하고 피드백을 제공하도록 요청하는 것이 아니라면 이는 어리석은 것처럼 보입니다. 더 빨리 일어날수록 더 빨리 조정할 수 있습니다. 이것은 가능한 모든 마감 시간을 맞 춥니 다. 모든 기능 만있는 것은 아닙니다. 그러나 중요한 기능으로 안내합니다.

우리는 모두 소프트웨어 개발을 포기하고 수도원에 합류해야합니다

그렇습니다. 실생활에서 멀리 떨어진 방에 나를 잠그는 것처럼 LESS 코드를 작성하게 될 것입니다.

이 답변을 크기에 맞게 편집했습니다. 궁금한 점이 있으면 편집 기록을 읽으십시오.

모든 사람은 민첩해야합니다. 당신이 무엇을 결정하든, 모든 당사자들이 무엇을, 어떻게, 언제, 어디서, 왜 그렇게하는지, 누가, 어떻게 보이는지. 민첩한 고객, 관리 및 개발자.

배송 날짜를 미래에 너무 많이 줄 수는 없습니다. 당신은 견적을 제공합니다.

누군가 고객의 기대를 관리해야했습니다. 스프린트 몇 개가 뒤쳐 질 염려가 너무 걱정되지 않는 이유는 전체 프로젝트가 뒤지지 않도록 조정하기 때문입니다. 스프린트가 끝난 후 "배송 날짜"를 마치지 않을 것이라는 결론에 도달하면 고객에게 알려야합니다.

이제 무엇을하고 싶습니까? 필요하지 않은 기능을 제거하거나 날짜를 이동하십시오. 정시에 인도 할 수 있다면 그렇게 할 것입니다. 나쁜 소식을 주저하지 마십시오.

누가 일부 프로젝트에서 더 빨리 배송 할 수 있는지 알고 있습니다.

클라이언트가 원하지 않으면 민첩 할 수 없습니다.

골

다음 두 가지 "메트릭"이 비즈니스 결정의 기초가되어야한다고 생각합니다.

• (고객에게 이익이되는 일)
• 우리는 가능한 효율적으로 일하고 있습니까

이것들은 매우 보편적입니다. 이러한 "많은 위해 - 물론이의 더 옳은 일을하고 제품, 제품을 사용할 수있는 사용자에 관한 작품은 수익성이되고, 예를 들어, 매우 빠르고 복잡, 제품은 등이 제대로 판매되고 스크럼-중독자 LLC "는 책임을지지 않습니다.

발행물

계약은 위에서 설명한 목표에 초점을 맞추지 않습니다. "전부 또는 전무"조항이 있습니다. 모든 것을 완료하고 지불하거나 아무것도하지 않고 지불하지 마십시오. 그러나 이것은 창출되는 가치와 직접 관련이 없습니다. 또 다른 단점은 다음과 같습니다. 이제 계약을 준수하는지 확인하고 시간과 비용을 투자해야합니다. 이 땅에서 왜이 돈을 쓰고 싶습니까? 그 동안 요구 사항이 변경되어 주문한 소프트웨어가 가치를 창출하지 못한다는 것을 알게되면 계약 이행이 어떻게 도움이됩니까? 배수구로 내려가는 돈이 더 많습니다! 물론 이런 행동에는 이유가 있습니다.

• 문화적으로 우리는 그런 것들을 쇼핑하는 데 익숙합니다. 우리는 자동차와 마찬가지로 소프트웨어를 구입할 것을 기대합니다. 구성을 선택하고, 가격과 마감일을 정하고,이 두 가지가 충족되지 않으면 매우 불행합니다.
• 우리는 위험과 책임을 덜어주고 싶다
• 우리는 안정성을 원하고 계획을 세우고 기분을 좋게 만듭니다 (그리고 중요한 부분 인 고객도)!

하루가 끝나면 가능한 한 좋은 목표를 달성 할 수 있도록 타협을 선택해야합니다.

이것이 작동하는 방법입니다

• 제품 대신 서비스 및 업무 계약
  • 상대적으로 짧은 통지에 용어를 사용해야 함
• 최적의 효율성을 보장하기 위해 긴밀히 협력
• " Scrum-Addits LLC "와 " Money-Bags Corporation " 에서 필요한 모든 당사자를 참여시킵니다 .- 모든 정보를 터널링하는 "단일 접점"터널은 여기에서 작동하지 않습니다

글쎄 난 기본적으로 "민첩 해"라고 말했다. 이제 이유는 다음과 같습니다.

• 프로세스 및 계약은 목표 에 최대한 많은 비용을 지출하도록 최적화되었습니다
• 계약 업체가 자신의 일을하도록 신뢰해야하며, 자신이 일을하고 있는지 확인하기 위해 많은 돈을 투자 할 필요가 없습니다.
• 기대 / 계약이 충족되지 않은 경우 계약자를 고소 할 수있는 능력은 도움이되지 않습니다. 그렇게하는 것은 단순히 계약을 철회하는 것보다 비용이 많이 들기 때문입니다. 여기에서 주요 관심사 중 일부는 출시 기간입니다. 귀하는 귀하가 얻는 것보다 법정에 가면 더 많은 돈 / 사업을 잃을 것입니다.
  • 하루가 끝나면 위험을 감수해야합니다.