민첩한 방법론에서 늦게 의미가 있습니까?

이것은 다른 질문 ( 이 질문)에 대한 답변과 의견 중 일부에서 나왔습니다 .

저는 주로 폭포 프로젝트와 함께 일했으며 민첩한 행동을 취하고 민첩한 것에 대해 공정한 글을 읽은 임시 프로젝트에서 일하는 동안, "적절한"민첩한 프로젝트에서 일한 적이 없다고 말하고 싶습니다. .

내 질문은 "늦은"이라는 개념이 민첩한 의미가 있는가? 그렇다면 무엇인가?

나의 추론은 민첩하게 시작 계획이없고 처음부터 세부적인 요구 사항이 없다는 것입니다. 당신은 높은 수준의 목표를 염두에두고 명목 날짜를 첨부 할 수 있지만 둘 다 (잠재적으로) 변할 수 있으며 확실하지 않습니다.

당신이 그것을 전달하고 사용자가 그것을 받아 들일 때까지 당신이 기본적으로 무엇을 전달할 것인지 정확히 알지 못한다면, 그리고 다음 스프린트 이후 일정이 없다면 어떻게해야 늦을 수 있을까요? 실제로 의미가 있습니까?

(분명히 스프린트가 넘칠 수 있음을 이해하지만 그 이상으로 이야기하고 있습니다.)

나는 분명히 폭포 프로젝트 (상대적으로 큰 프로젝트)가 내가 본 적이 있고 관련되어 있다는 사실에 근거하여 시간이 지남에 따라 폭포 프로젝트가 가능하다는 가정에 만족합니다 (쉽거나 일반적이지 않습니다) 그러나 가능합니다.

이것은 민첩성을 두드리는 것이 아니라 그것을 이해하는 것입니다. 나는 기한이나 예산 (또는 간접적)과는 무관하게 애자일의 이점을 보았습니다. 범위와 관련이 있습니다. 애자일은 프로젝트 팀이 중요하다고 생각하는 것보다는 실제로 중요한 것에 더 가깝게 전달합니다. 봤어요.

Agile 프로젝트에 사전 계획이 없다는 데 동의합니다.

필자는 비즈니스 분석가가 고객 및 개발자와의 설계 회의에서 상당한 시간을 소비하여 사용자 사례로 제시된 달성 가능한 요구 사항에 대한 자세한 목록을 작성했다. 그런 다음 숙련 된 개발자가 첨부 한 적절한 추정치가있는 작업으로 분류됩니다.

스프린트 / 반복 시작시 가장 중요한 작업이 확인되면 코딩을 시작할 수 있습니다. 이 선택 프로세스는 전체 프로젝트에서 반복의 의미를 결정합니다 ( "로그인 프로세스를 빌드 중입니다"). 팀의 다양한 멤버는 해당 사용자 스토리를 실현하는 데 필요한 다양한 작업을 수행합니다.

반복이 끝나면 해당 반복에 대한 모든 사용자 스토리가 완료 되거나 늦습니다 . 마찬가지로 각 반복 및 제품 출시가 끝날 때마다 개발을 중지 할 수 있어야합니다. 모든 사용자 스토리 측면에서 완전하지는 않지만 반복에서 요청 된 사용자 스토리는 완전하며 제품이 해당 한계까지 작동 할 수 있습니다.

민첩한 방법론에서 "늦게"는 폭포수 방법론에서 의미하는 것과 동일한 것을 의미합니다. 추정치가 잘못되었거나 할당 된 시간 동안 범위가 너무 커서 예상치 못한 어려움이 나타 났으며 고객이 충분히 반응하지 않았으며 프로그래머가 게을러졌습니다. 기계가 추락하고 개가 내 바이트 코드 등을 먹었습니다.

당신은 그것으로부터 배우고 다음 반복에 적응

차이점은 2-4 주마다 발생할 수 있으므로 수업을 배우고 프로세스를 빠르게 조정할 수 있습니다.

예, 그러나 9 개월이 아닌 9 개월의 신화 최종 프로젝트 마감일을 맞추지 않으면 1 개월이 소요됩니다.

당신의 추론은 선행 계획과 대규모 프로젝트에 대한 상세한 요구 사항이 가능하다는 가정에 근거합니다. 그것을 뒷받침 할 많은 증거가 있는지 확실하지 않습니다. 어쩌면 모든 공포 이야기는 일화일까요? 모든 개발자는 클라이언트가 완전히 동의하고 이해하는 완전히 변경되지 않는 사양으로 작업하기를 원합니다.

어떤 종류의 약속을 할 때마다 늦을 위험이 있습니다. 그것은 민첩에도 적용됩니다.

그러나 우리는 당신이 미래를 예측할 수 없다는 것을 알고 있으며, 고객이 끊임없이 그의 마음을 바꿀 것이라는 것을 알고 있습니다. 우리가 그것을 받아 들인다면, 우리는 또한 모든 약속이 차례로에 대한 질문을하게하는, 항상 잘못 꽤 많은 것을 수용해야 지각에 대답하기 쉬운 : 우리는 항상 잘못 (초기 또는 후기에로). 아무리 잘 닦여 있든 그것은 모두 추측의 문제입니다. 동전을 던지세요.

이것은 개발자로서 우리가 단순히 받아 들여야하는 것이며, 그 관점에서 지연 문제가 훨씬 덜 중요한 방식으로 작동하는 다른 방법을 찾으려고 노력합니다. 관점의 변화. 그렇게하는 방법은 가능한 한 빨리 작동하는 소프트웨어를 제공하는 데 초점을 맞추고 있으며 고객이 만족할 때 종료하는 옵션이 있습니다.

이것이 민첩한 것입니다. 지체가 사실이라는이 불편한 개념을 관리하는 영리한 방법은 우리가 할 수있는 최선을 다해 다루어야합니다.

예를 들어, 현재 반복이 시작될 때 수행 한 약속을 이행하지 못하는 경우가 늦습니다. 이것은 예상되는 것이며 다음 반복에서 실패하지 않도록 프로세스를 조정하고 프로세스를 조정해야합니다. 이를 처리하는 가장 좋은 방법은 반복을 가능한 작게 유지하는 것입니다.

다중 반복 계획 (일명 릴리스 계획)의 경우 완료된 반복에서 계산 된 속도를 사용하고 향후 릴리스 날짜를 예측하기 위해 데이터를 추정합니다. 이에 대한 자세한 내용은 James Shores의 기사 또는 내 자신의 (짧은) 것을 권장 합니다. "우리는 그 날짜까지 다음 기능을 완성 할 것이라고 80 % 확신합니다"라는 확고한 약속은 아닙니다. 이것은 (일종의) 결과를 늦게 만들 수 있지만 약속은 사실이 아니라 가능성 일뿐입니다.

이제이 기능을 애자일의 기본 약속으로 해석하십시오. 항상 작동하는 소프트웨어를 출시 할 준비가 되었습니까? 이를 통해 고객은 시스템이 충분하다고 생각할 때 개발을 중단 할 수있는 자유를 얻게되며 이는 예상보다 훨씬 빨리 발생할 수 있습니다. 또한 최신 반복의 실제 피드백을 기반으로 프로젝트를 새로운 방향으로 이끌 것을 권장합니다.

위의 사항은 모든 고객이 개발을 완전히 제어 할 수있을 정도로 충분해야하며 민첩한 방법의 지연에 관한 질문에 답변하기를 바랍니다.

Agile SCRUM에는 "late"의 두 가지 유형이 있습니다.>

1. Carryover-스프린트가 끝날 때 "완료"되지 않은 이야기, 개발자는 PBI 완료를 "커밋"하므로 완료되지 않은 경우 캐리로 간주 할 수 있습니다.

2. 로드맵-조직에 로드맵이 있고 날짜가 있다고 가정하면 해당 날짜의 주요 결과물이 누락 된 경우 "늦은"것으로 간주 될 수 있습니다.