기한은 민첩합니까?

명확성을 기하기 위해 마감일은 다음과 같습니다.

시간 제한 또는 마감 시간은 목표 또는 작업을 수행해야하는 좁은 시간 영역 또는 특정 시점입니다.

^{에서 위키 피 디아}

내 소프트웨어 개발 경력 전체에서 "애자일 (Agile)"을 해왔는데, 이는 어느 곳에서나 최소한 다음과 같은 관행을 준수하는 것으로 보였습니다.

• 주간 또는 격주 스프린트
• 회고전 스프린트 계획
• 제품 소유자
• 스크럼
• 사용자 스토리

그러나 내가 본 모든 프로젝트는 마감일을 설정해야한다고 주장했습니다. 애자일은 적응 형 계획, 유연성 및 변화에 초점을 맞추려고 시도합니다. 기한은 민첩합니까?

제 생각에는 마감 시간이 유연성 부족과 품질 부족으로 이어 지므로 그렇지 않습니다. 대신 스프린트와 조기 배송에 집중하는 것이 더 가치가 있다고 생각합니다. 그러나 내가 있었던 모든 서클에서 이것은 사실이 아니며 기한은 애자일 개발과 밀접한 관련이 있습니다.

마감일은 현실입니다. 대부분의 경우 특정 날짜까지 무언가 를 가져야 합니다. 피할 수 없습니다. 기한이 없으면 민첩한 프로젝트조차도 파킨슨의 법칙에 굴복 할 수 있습니다 .

작업 완료 시간을 채우기 위해 작업이 확장됩니다.

다시 말해, 프로젝트 가 영원히 계속 될 수 있다면 그렇게 될 것입니다.

기한과 관련하여 애자일은 몇 가지 일을 시도합니다.

• 마감일까지 얼마나 많은 작업을 수행 할 수 있는지 항상 모든 사람이 볼 수 있도록 보장
• 가장 중요한 기능이 먼저 완료되었는지 확인
• 아직 완료되지 않은 기능에 의존하지 않는다는 점에서 완성 된 기능을 사용할 수 있는지 확인하십시오.
• 개발이 지속 가능한 속도로 지속되도록 보장

이런 방식으로 피할 수없는 날이 오면 쓸모없는 코드가 아니라 완성되지 않은 가장 중요한 것만 가지고 테스트되고 테스트 된 제품이 필요합니다. 그리고 완성 된 제품에 아무도 놀라지 않습니다.

네 "민첩한"및 "마감일"은 완벽하게 호환 될 수 있습니다.

마감일은 인생의 사실입니다. 아주 확실한 날짜가 있습니다.

Comdex의 소프트웨어가 필요합니다

또는

게임은 Black Friday까지 매장 진열대에 있어야합니다

등. Comdex 또는 Black Friday를 연기 할 수는 없습니다. 나머지 세계는 그렇게 작동하지 않습니다.

애자일의 목표는 마감 시한을 맞추지 못하는 것들이 더 빨리 실패하거나 좋은 일입니다. 또는 범위를 더 빨리 재검토하여 리소스가 올바른 ROI에 집중 될 수 있도록 더 적시에.

마감일은 확정 된 어려운 날짜입니다. 애자일 (Agile)은 소프트웨어가 원래 기대했던 것보다 두 배나 오래 걸릴 것이라는 사실을주기 초기에 알 수있게 해주는 도구입니다. 프로젝트 관리자는 더 많은 리소스를 추가하거나 범위를 변경하거나 마감일을 조정 (확실한 마감일이 아닌 확고한 상황 일 경우) 또는 프로젝트를 수행 할 수 있도록 나중에이 문제를 일찍 인식 할 수 있어야합니다 취소 된.

애자일이 추구하는 투명성은 사이클 초기에 문제와 진행 상황을 보여주는 것입니다. 고전적인 폭포 배달 실패는 문을 닫은 후 몇 달을 보냈고 마감일 1 주일 전에 제품을 배달 한 것으로 잘못되었다는 말을 듣고 몇 달을 낭비했다는 말을 들었습니다 (이제 마감 시한을 완전히)습니다). . 또 다른 고전적인 폭포 실패는 마감일 1 주일 전까지도 여전히 발견 할 수 있습니다. 애자일은 이러한 문제를 프로세스 초기에 알리려고합니다.

기한과 관련하여 애자일이 시도하는 다른 부분은 합의 된 기능의 일부만 (어떤 이유로 든) 완료 되더라도 현재 버전의 소프트웨어가 유용하고 배포 가능하다는 것입니다.

우리는 4 월 15 일에 세금 소프트웨어를 배포하기 위해 원하는 모든 것을 놓치는 것을 놓쳤지만, 지난 11 월에 시작한 이래로 75 %, 우리가하는 일과 효과가있었습니다. 우리는 12 월 중순부터 전체 기능 세트를 배포 할 수 없으며 고객 기반의 80 %에 초점을 맞췄습니다.

일부 마감일을 준수해야합니다. 계약상의 의무, 협약, 규제 요건. 일부는 스프레드 시트에서 제조와 동일한 차트에 소프트웨어 개발을하려는 관리자에 의해 부과됩니다. 원인이 무엇이든, 대부분의 사람들은 그들로부터 벗어날 수 없습니다.

제대로 작동하는 팀에서 일하는 경우 개발자와 경영진 / 이해 관계자 간의 의사 소통은 결정을 내릴 필요가있는 사람들에게 마감 기한이 없거나 개발을 계속하는 것이 더 중요하다는 결정을 내릴 수 있음을 의미합니다.

일주일에 한 번 또는 한 달에 두 번 완성 된 사용자 사례를 제공하더라도 마감일이있을 수 있습니다. 사람이 올 때, 이해 관계자가 마감일까지 어떤 내용이 적합한 지 알도록하고 기대치를 설정하십시오.

현재 모든 단계에서 요구하는 요구 사항으로 최고의 소프트웨어를 지속적으로 구축하는 경우 스프린트 종료 시한은 이론적으로 문제가되지 않습니다. 실제로, 이것은 일반적으로 그렇지는 않지만 얇은 공기에서 나오는 마감일도 아닙니다. 제가받은 가장 중요한 마감일은 오래 전에 저에게 전달되었습니다. 품질과 기능에 대한 기대였습니다.

누락 된 경우 아무런 결과가없는 임의의 마감일은 그리 민첩하지 않지만 개발팀의 통제 마감일 이외의 이유로 마감해야하는 상황이 있습니다. 다행히 기한이 합리적이라면 방정식을 뒤집고 기한을 기민한 방식으로 처리 할 수있는 방법이 많이 있습니다.

마감일이 항상 틀린 것은 아닙니다. 우리 모두 오비완으로부터 배운 것처럼 :

"Sith만이 절대 거래를한다"

대부분의 경우 마감일이 어리 석고 불필요하며 확실히 민첩하지 않다고 말하는 것은 공정하지만, 항상 그런 경우라고 말하는 것은 어리석은 일입니다. Architypal 케이스는 선거 추적 소프트웨어와 같이 시간에 민감한 사용에 필요한 소프트웨어입니다. 소프트웨어가 선거에 제 시간에 준비되지 않았다면, 선거를 연기하는 것이 현명하지도 실용적이지 않을 것이며, '죄송합니다. 너무 오래 걸린 것 같습니다. 비용을 지불하는이 소프트웨어가 완전히 가치가 없다는 것을 알고 있습니다. 마감일이 애자일이 아니기 때문에이를 만나지 않기 위해 어떻게 우리를 대항 할 수 있습니까? '

고객에게 시간에 민감한 무언가를 원한다고해서 고객에게 말을 걸어주는 것은 그리 민첩하지 않으며 하루 가 지나면 누군가 가 이런 것들을 만들어야 할 것입니다. 그렇다면 어떻게 고객을 행복하게하고 시간에 민감한 것들에 대해 합리적인 솔루션을 제공 할 수 있을까요? 글쎄, 소프트웨어 개발에 불확실한 시간이 걸리고 마감일이 변하지 않는다면, 그 불확실성을 처리하기 위해 다른 것이 변해야 할 것입니다 ...

배달 날짜가 ​​일정하게 유지되면 다른 측면이 변수가됩니다.우리 모두 알고 있듯이 소프트웨어 프로젝트에는 많은 불확실성이 있습니다. 프로젝트에서 성공하기를 원한다면,이 불확실성에 대응하여 무엇인가 변수를 만들어야합니다. 어쨌든 자연스럽게 보입니다. 그러나 이것이 유일한 선택은 아닙니다. 마감 기한을 지키지 않으려면 처리 방법은 제공된 기능을 변수로 만드는 것입니다. 기능 목록의 우선 순위를 정하고 해당 날짜까지 제공 할 수있는 기능의 양에 불확실성이 있음을 명확하게 전달하십시오. 고객과 협력하여 이러한 기능의 우선 순위를 정하여 가장 중요한 기능이 배송 될 가능성이 높아지도록합니다. 그런 다음 마감일이 다가 오면 배송 준비가 된 모든 것을 배송해야합니다. 이 모델에서는

누군가 마감 기한을 설정하고 싶을 때는 마감일을 정할 수 있지만 마감 기한이 고정되면 범위가 유연하게 유지되어야합니다.

tl; dr

이상적인 세상에서는 마감일이없고 준비가되었을 때만 제공합니다. 하지만 실제로는 비용을 지불하는 사람들이 일반적으로 일을 알고 싶어한다는 것입니다. 민첩한 방법론은이를 인식하지만 모든 것을 묶을 수는 없다는 것을 인식합니다.

이를 통해 제품에 적합한 수준으로 배송 품질을 유지할 수 있습니다. 마감일과 범위 (및 예산)를 수정하면 상황이 급증하고 프로젝트가 끝날 때 미친 위기 시간으로 오래된 폭포 세계로 돌아갑니다. 더 많은 개발자와 테스터를 추가해도 문제가 더 빨리 해결되지 않으므로 예산을 늘리는 것이 일반적으로 답이 아닙니다. 더 많은 사람들이 (각각 자신의 foibles를 가지고) 더 많은 시간이 걸린다는 것은 잘 알려진 견해입니다 (그리고 나는 경험에 동의합니다).

일반적으로 소프트웨어 비용을 지불하는 사람이 말하는 것을 좋아하지 않는 경우 (애자일 방법을 실제로 이해하지 않는 한) 마감일을 맞출 수는 있지만 원하는 모든 것을 할 수는 없습니다. 소프트웨어를 구성하는 기능의 우선 순위를 지정하여 관리 할 수 ​​있습니다. 우선 순위 토론은 다음과 같습니다.

개발팀 (D) : "가장 중요한 기능을 먼저 제공하고 싶은 기능의 우선 순위를 정할 수 있습니까?"

고객 (C) : "모든 것이 우선 순위 1입니다. 다음 달 말까지 모두 완료하기를 원합니다."

D : "그렇지만 가능하지만 요구 사항이 변경되거나 개발 과정에서 예상하지 못한 문제를 발견하면 불가능할 수 있습니다."

C : "더 많은 돈을 주면 어떡하지?"

D : " 한숨을 쉰다 . 더 많은 자원이 있어도 실제로는 한 달이 걸리기 때문에 우선 순위를 정하는 방법을 잘 모를 경우 먼저 어떤 기능을 원하는지 알려주십시오."

C : "좋아요 큰 버튼을 원하지만 정말 크게 만들면 ... 등"

이제 우선 순위대로 기능을 살펴볼 수 있습니다. 또한 우선 순위가 낮은 항목을 팀과 함께 미리 살펴보고 더 많은 정보가있을 때 개발 단계에있을 때 변경 될 수 있음을 알고 조기에 예측할 수 있습니다. 로드맵이없는 경우이를 재정의하거나 작성하는 데 사용할 수 있습니다. 그러면 릴리스 계획의 기초가됩니다. 로드맵은 범위가 변경 될 수 있음을 인정하는 고객과 논의 할 수 있지만 전달할 주문이 있습니다.

애자일의 가장 큰 장점 중 하나는 개발 과정에서 변화가 일어나고 상황에 따라 변화한다는 것을 인정한다는 것입니다. 보다 전통적인 접근 방식과는 달리,이 원칙은 정기적 인 스프린트 결과물 및 고객과의 지속적인 커뮤니케이션과 함께 진행 상황에 대해 자연스럽게 더 투명 해져야한다는 것을 의미합니다. 이는 좋은 일입니다.

때로는 고객이 특정 날짜까지 원하는 것을 얻지 못하는 것을 좋아하지 않지만, 왜 그리고 무엇을 얻는지는 좋은 품질인지 이해할 것입니다. 고객이 기능을 제공 한 후 6 개월이 지나면 고객이 특정 날짜까지 제공 한 제품을 신경 쓰거나 기억하지 않을 것입니다. 고객은 여전히 ​​사용중인 제품의 품질을 기억합니다.

마감일은 전통적으로 비즈니스 라이프 사이클을 기반으로합니다. 세금 소프트웨어는 4 월 15 일까지 있어야합니다. 다음 회계 연도보고는 7 월까지 완료해야합니다.

애자일 선언의 상태 :

프로세스 및 도구에 대한 개인 및 상호 작용

포괄적 인 문서를 통한 작업 소프트웨어

계약 협상을 통한 고객 협업

계획 변경에 대한 대응

마감일은 계약입니다. 그들은 계획입니다. 그들은 당신의 팀의 속도에 응답하지 않습니다. 세 명의 최고의 개발자를 잃어버린 경우에는 변경되지 않습니다.

마감일은 민첩하지 않지만, 민첩은 마감일에 대한 피드백을 제공 할 수 있습니다. 애자일은 우리의 속도가 피처를 자르지 않고 마감일을 만들지 못할 지 알려줍니다. 마감일을 정하기 위해 고용해야하는지도 알려줍니다. 그리고 어떤 경우에는 잘라낼 기능이 없을 때 마감일이 불가능하다는 것을 알려줍니다.

애자일 팀이 할 수있는 최선의 방법은 속도와 우선 순위가 매겨진 백 로그로 마감일을 결정하는 것입니다. 예상 배송 날짜가 제공됩니다. 마감일을 벗어난 경우, 고객과의 진지한 대화 시간과 마감일이 가능한지 결정하십시오.

각 스프린트의 배송은 협상 할 수 없다고 말하고 싶습니다. 작업을 평가하고 카드 크기를 정한 다음 스프린트가 끝날 때까지 팀을 바쁘게 유지할 수있을 정도로 적재합니다 (1 주에서 한 달에 한 번씩 스프린트가 작아야 함). "배달 마감일"은 예상 작업에 대한 완료된 작업의 과거 추세를 기반으로해야합니다. 애자일은 기존의 "비용 / 시간 / 범위"제약 아이디어에서 아무 것도 추가 / 제거하지 않습니다. 범위에 대한 우선 순위를 높이는 것이 일반적으로 더 많은 돈이나 시간을 소비하는 것보다 선호한다는 점에서 스코프를 선호하는 방법으로 스코프를 사용합니다.

어떤 사람들은 "와일드 웨스트"에 민첩성을 혼동하는 것 같습니다. 애자일은 아무것도 없다는 것을 의미하지 않습니다. 민첩성은 합리적인 사람이 얼마나 잘 평가할 수 있는지에 대해 거짓말을 그만두는 것을 의미합니다. 기본적으로 우리는 약 2-4 주 후에 소프트웨어 개발을 추정 할 수 있습니다. 그 외에도, 그것은 모두 다양한 정도의 장식과 추측입니다. 더 나쁜 것은, 미래에 더 많은 것들에 대한 견적을 제공하는 비용은 단지 작업을 수행하는 비용에 접근한다는 것입니다. 어떤 이유로 든 프로젝트 관리자는 역사적으로 이러한 절대적 진실을 고객에게 인정하기를 꺼려했습니다. 애자일은 단순히 소프트웨어 엔지니어링의 미래를 얼마나 잘 예측할 수 있는지에 대한 제한이 있다고 주장함으로써 이러한 사고를 조정하고 장기 예측을 위해 "증거 기반 추정"으로 미묘하게 전환합니다.이다 추정 할 수있는, 우리는 우리가 지금까지 전달 된 한 내용을 기반으로 장기적인 미래 전달 상당히 합리적인 견적을 제공 할 수 있습니다.

TL; DR

마감일은 민첩합니까? ... [D] 마감일은 민첩한 발전과 함께 진행되는 것으로 보입니다.

여기서 많은 답변이 질문의 엔지니어링 측면에 초점을 맞출 것입니다. 대신 프로젝트 관리 관점에서이 문제를 해결하겠습니다.

마감 기한은 민첩한 원칙에 맞지 않는 사전 계획의 많은 것을 의미합니다. 대신, 반복 개발 모델은 시간 상자, 종지 및 출시주기에 의존 포함 적시 계획,하지만 "큰, 선행 계획"일반적으로 기존의 프로젝트 관리 마감일와 연결되어 있습니다.

민첩한 방법론으로 릴리스 계획을 수행하는 것은 여전히 ​​가능하지만 계획은 일반적으로 법정 화폐로 설정 한 관리 목표보다는 목표를 달성하는 데 필요한 반복 횟수의 추정치에 기반합니다. 즉 출시 날짜가 설정 될 수 없음을 말하는 것이 아니다, 또는 목표를 충족 할 수없는,하지만 방법 은 정의하고 충족되었는지는 기존의 프로젝트 관리 방법론에 비해 상당히 다르다.

마감 시간이 아닌 시간 상자를 생각하십시오

그러나 내가 본 모든 프로젝트는 마감일을 설정해야한다고 주장했습니다. 애자일은 적응 형 계획, 유연성 및 변화에 초점을 맞추려고 시도합니다. 기한은 민첩합니까?

이것은 민첩한 원칙에 대한 일반적인 오해입니다. Scrum 및 Kanban과 같은 민첩한 프레임 워크는 마감일이 아니라 타임-박싱 및 지속 가능한 전달 방식에 중점을 둡니다.

예를 들어 스크럼에서 스프린트는 "마감일"이 아닙니다. 시간 상자는 팀이 예상 시간을 초과하지 않고 시간 상자에 맞출 것으로 예상되는 작업량으로 채워진 다음 시간 상자가 만료되면 "완료"또는 "완료되지 않음"입니다. 일단 사라지면 타임 박스는 영원히 사라집니다. 완료되지 않은 모든 작업은 프로젝트의 과거 (역사적) 요구에 따라 새로운 임시 타임 박스 내에서 재 계획되고 재 추정되어야합니다.

타임 박스의 중요성은 이해 관계자가 진행 상황을 검토 할 수있는 예측 가능한 케이던스와 잠재적으로 배송 가능한 가치 를 제공 할 팀을위한 지속 가능한 속도를 창출한다는 것 입니다. 작업은 점진적이며 케이던스를 따릅니다. 따라서 큰 선행 마감일 개념은 민첩한 원칙과 일치하지 않습니다.

시간 상자를 기준으로 릴리스 계획

사람들이 민첩한 프로세스를 기존 프레임 워크에 매핑하기가 가장 어려운 영역은 아마도 릴리스 계획입니다. 릴리스 계획에는 종종 고정 범위 또는 고정 날짜 결과물이 포함됩니다. 애자일 프레임 워크에서 릴리스 계획은 일반적으로 범위 가 변경 가능한 변수로 명시 적으로 정의되고 릴리스 날짜는 반복적으로 추정되는 추정 프로세스를 통해 수행됩니다 .

예를 들어, 20 번의 반복이 끝날 때 프로젝트의 v1.0을 릴리스하기 위해 프로젝트가 수행 될 수 있습니다. 릴리스 된 내용의 범위는 프로젝트 수명 기간 동안 변경 될 수 있지만 (범위, 기능 및 우선 순위는 모든 스프린트 시작시 변경 될 수 있음) 각 릴리스의 대상 날짜는 프로젝트 계획에서 고정됩니다. 이 팀은 각 스프린트마다 배송 가능한 증분을 제공하기 위해 노력하고 있으며, 정의 정의에는 프로젝트가 각 스프린트의 끝에서 릴리스 가능한 상태에 있도록 지속적인 통합과 같은 품질 검사가 포함되어 있습니다.

때때로 범위가 고정 된 민첩한 프로젝트가 표시되지만, 민첩한 프로젝트에서는 범위가 변경 가능한 변수이기 때문에 각 반복의 범위가 프로젝트의 변화하는 요구에 따라 조정, 변경 또는 적응함에 따라 릴리스 날짜가 시간이 지남에 따라 변경 될 수 있습니다. . 민첩한 팀, 특히 경험이 부족한 팀에 대한 고정 범위 접근법을 권장하지는 않지만 올바른 접근법이 필요한 경우가 있습니다.

또한보십시오

• 애자일 릴리스 계획을 수행하는 방법

마감일을 약속으로 생각하십시오. 프로젝트가 민첩하다고해서 특정 날짜에 특정 기능을 제공한다고 약속해서는 안됩니다.

민첩성이 가져 오는 것은 그 사이에 일어나는 일입니다. 특정 날짜에 하위 기능 B, C, D 및 E로 구성된 기능 A를 제공해야한다고 정의하는 엄격한 소프트웨어 요구 사항 스펙 문서를 보유하는 대신 지정된 날짜에 기능 A를 제공하기로 약속합니다. 초기 단계에서는 고객이나 고객이 기능의 모양을 모르거나 B, C, D 및 E 하위 기능 또는 B 및 C 하위 기능 또는 12 가지 다른 하위 기능이있을 수 있습니다.

이전에 소기업에게만 상품을 제공하고 대기업과 계약을 체결 한 회사를 상상해보십시오. 이 대기업은 EDIFACT를 사용하며 회사에서 사용하는 현재 회계 소프트웨어가 EDIFACT를 처리하지 않는 것으로 보입니다. 당신은 계약, 기업 4 월 15 준비가되어 있어야 주어진, 그것을 수행하는 플러그인을 작성하도록 요청하고 있습니다 ^일 .

민첩성은 중간 단계가 점진적으로 전달되고 정기적 인 피드백을 기반으로한다는 것을 의미합니다. 기본적으로, 당신은 회계사에게 당신의 진행 상황을 보여줄 것입니다, 그들은 당신이 그것에 대해 어떻게 생각하는지, 가능한 문제는 무엇인지 등을 알려줄 것입니다. 이것은 또한 원래 회계사가 자신들이 생각하고 개선 할 수있는 훌륭한 아이디어를 가지고 있음을 의미합니다 실질적으로 사용자 경험. 3 주 후에는 크게 개선되지 않았을뿐만 아니라 한 달 동안 추가 개발이 이루어질 것으로 보입니다. 애자일 (Agile) 덕분에이 기능에서 다른 기능으로 노력을 재지 정하여 제 시간에 전달할 수 있습니다.

또한 고객의 관점을 이해해야합니다.

• 종종 비즈니스에는 특정 배송 날짜가 필요합니다. 예를 들어 올림픽 게임이 끝난 후에 는 올림픽 게임 온라인 스트리밍 서비스를 제공 할 수 없습니다 . 비즈니스 측면에서 이것은 단순히 실패이며 큰 부정적인 결과를 초래합니다.

• 약정이 없으면 개발자 나 하청 업체가 완벽 주의자이거나 프로젝트의 우선 순위를 낮추는 유혹을받습니다. 스프린트의 규칙 성이 도움이되지만이 위험을 완전히 막지는 못합니다.

  마감일이 매우 쉽게 발생하기 때문에 마감일을 좋아하지는 않지만 많은 회사가 왜 그렇게하는지 이해합니다. 스프린트 만보고 프로젝트가 일정보다 뒤쳐져 있음을 항상 쉽게 알 수있는 것은 아닙니다.이 맥락에서 마감 기한을 놓친 것은 무언가가 통제 할 수없고 당장 처리해야한다는 분명한 알림 일 수 있습니다.

릴리스 계획에 대한 eXtreme Programming 상태 :

릴리스 계획의 기본 철학은 프로젝트를 범위, 자원, 시간 및 품질의 네 가지 변수로 수량화 할 수 있다는 것입니다.

어느 것이 공정한 것 같습니다. 또한

아무도 4 개의 변수를 모두 제어 할 수 없습니다. 하나를 변경하면 실수로 다른 하나가 응답으로 변경됩니다. 품질을 우수보다 낮게 낮추면 다른 3 가지 변수에 예상치 못한 영향이 있음

br3w5 에서 이미 언급했듯이 리소스를 늘리는 것은 제한적인 솔루션입니다. 팀원 인 다른 사람을 파견 한 경우 이미 팀에 속한 커플을 추가 할 수 있습니다. 그러나 팀 재구성 없이는 시간이 많이 걸리지 않고 팀 규모를 빠르고 무기한으로 늘릴 수는 없습니다.

따라서 시간이 제한되는 마감 기한 인 돌이킬 수없는 품질과 고정 된 자원으로 범위를 조정해야합니다. 민첩성을 사용하면 가능한 가장 생산적인 범위로 마감 시간을 맞출 수 있습니다. 그러나 일반적으로 범위의 일부가 제 시간에 완료되도록 보장 할 수 있습니다. 마감 시간 아래로 제한 될 시간을 신뢰할 수있게 추정 할 수있는 부분입니다. 일반적으로 여러 번 수행 한 작업에 거의 근접하고 거의 알려지지 않은 것입니다.

소프트웨어 개발 방법의 목적은 올바르게 이해 될 때 우리의 생각에 집중함으로써 생산성을 높이고 일반적인 상황에 공통된 언어를 제공하는 것입니다. 그것은 마음 통제와 죄책감이 아니라 영감과 능력에 관한 것입니다.

말 그대로 타협없이 소프트웨어 개발 방법을 따르는 것은 다른 상황에서 급진주의 또는 근본주의라고 불리는 것에 해당합니다. 이 수차의 순수한 형태는 실제로 시장에서 급속히 실패하기 때문에 실제로는 거의 보이지 않습니다. 그러나 개발자가 특정 방법을 구현하는 어려운 작업에서 경쟁 할 때, 점수를 초과하는 것은 자연스러운 일입니다.

선교사와 전도자들은 주로이 방법을 전혀 사용하도록 설득력이 필요한 사람들을 목표로 삼고 있다는 사실로 인해 문제가 더욱 악화됩니다. 비록 그들이 설교를하더라도 인간의 본성은주의를 덜 받도록합니다.

마감일은 민첩하지 않으며 다음과 같습니다.

1) 폭포, 2) 잘못된.

소프트웨어와 마감일은 함께 잘 작동하지 않으며 가지고 있지 않습니다. 여러 가지면에서 애자일 방법은 예산 기한뿐만 아니라 마감 기한을 충족 할 수 없다는 것이 확실 해지자 포기 된 마감일 또는 소프트웨어의 대규모 문제에 대한 반응입니다.

애자일은 "마감일이나 기능이 미끄러지거나 변경 될 것이라는 것을 알고있다. 우리는 그것을 알고있다. 그래서 오른발로 내딛어 라.

핵심은 마감일이 단순히 소프트웨어의 첫 번째 버전에 대한 릴리스 날짜가된다는 것입니다. 그것은 여전히 ​​석재로 작성되었을 수도 있습니다. 예를 들어, 소프트웨어는 학업 용이며 학기 시작시 사용할 수 있어야합니다. 그러나 제공 할 내용은 그렇지 않습니다. 그때까지 모두가 확신 할 수있는 최소한의 실행 가능한 제품을 보유하고 있으며 "원하는 것"이 ​​있습니다. 전체 목록이 "마감일"에 의해 전달되지 않을 것으로 판명 될 때 모든 사람이 손을 내밀는 대신 MVP를 문 밖으로 내 보냅니다. 그 시점에서 나머지의 비용 / 혜택을 평가하십시오.

오랫동안 컴퓨터 게임을 한 사람이라면 이것이 어떻게 작동하는지 정확히 알고 있습니다! 첫 번째 릴리스가 베타 표준에 도달하면 많은 게이머들이 만족하기 때문에 "실제 마감일"이 실제로 무엇을 의미하는지에 대한 기대치가 낮습니다.

따라서 마감일은 민첩하지 않으며 사람들이 소프트웨어를 하드웨어 및 철강 공학처럼 취급 할 수 있다고 생각했던 시절부터 보류되었습니다. 우리는 이것이 소프트웨어보다 하드웨어가 갖는 가장 큰 장점을 제거하기 때문에 이것이 불가능하거나 바람직하지 않다는 것을 배웠습니다.

애자일은 교량 설계가 결코 불가능한 방식으로 프로젝트 과정에서 목표를 개발하고 변경할 수 있도록하여 이러한 부드러움을 활용하려고합니다.

"아마도 아니오"라고 대답

Project_management_triangle은 비용, 시간 및 범위 (및 품질)이 서로에 의존한다고. ( "2를 골라 3을 얻으십시오")

스크럼 스프린트는 고정 시간 (예 : 7 일 = 스프린트 길이)과 비용 (예 : 7 명의 팀원 예산)을 선택하고 범위 (스프린트에서 수행 할 스토리 수)를 추정합니다.

경영진이나 영업 부서가 세 가지 (비용, 시간 및 범위)를 모두 정의하려고하면 팀이 목표에 도달 할 것을 약속 할 수 없으므로 (품질 = 정의의 정의를 위반하지 않음) 스크럼의 의미에서 민첩하지 않습니다.

전문 경영진은 정해진 날짜가 정해져 있으면 비용과 시간을 정의하고 필요한 경우 범위를 줄입니다.

간단하고 직접적으로 대답 할 수 없습니까?

없음 마감일은 민첩하지 않습니다.

요점은 반복적 인 방식으로 학습하고 적응하면서 할 수있는 것을 구축하는 것입니다.

기한은 "당신이 x로 y를 제공해야한다"는 사전 결정된 시간 척도 (우리가 무엇을 전달하려고하는지 확실하지 않은 민첩하다고 말한다. 민첩한 학습은 우리가 시간 척도에 대해 확신하기가 매우 어렵다는 것을 알더라도 해결 된 문제이며 어쨌든 그렇게하지 말아야한다고 가르칩니다.

질문에 대한 대답이 "아니요, 기한이 민첩하지 않다"는 것을 확인한 후 "민첩한 상황에서 마감일을 어떻게 처리합니까?"라는 질문에 대한 흥미로운 대화를 나눌 수 있습니다. 다른 답변에서 그것에 대해 생각하십시오.

후자에 대한 합리적인 대답은 우리가 점점 더 많은 가치를 조기에 제공하고 우리가 적시에 어디에 있는지 알 수 있다는 것입니다.

작업에 필요한 민첩성의 정도는 조직도에서 자신의 위치가 얼마나 높은지에 반비례합니다.

"애자일 (Agile)"은 그것이 무엇인지에 대해 좋습니다. "민첩한"분류 란 "충분한 역량과 함께 열린 마음을 가진"을 의미합니다. 가장 민첩해야하는 것은 바닥에있는 그런 포입니다.

관리 수준에서 뾰족한 머리 보스가 일주일 뒤로 마감 시간을 밀면 더 나은 제품을 만들거나 회사가 또는 부서)는 향후 2 주를 절약 할 수 있으며 이는 기한이 기한입니다.

그러나 깨달은 자기 이익처럼, 그것은 실제로 존재하지 않습니다.