모든 요구 사항을 수집하기 전에 릴리스 날짜를 결정하는 것이 민첩하지 않습니까?


10

나는 Craig Larman이 쓴 Applying UML and Patterns 책을 읽기 시작했다. 나는 그것이 직장에서 들었던 많은 것들에 도전하기 때문에 매우 흥미 롭습니다. 요구 사항이 한 번에 완벽하게 수집되지 않고 요구 사항 수집을 완료하는 데 많은 반복이 필요하다는 것을 읽었습니다. 그렇다면 내일 새로운 획기적인 요구 사항 (또는 요구 사항을 가장하는 변경 요청)이 내일있을 수 있다는 점을 고려할 때, 강제로 정해진 기한을 정하고 있습니다.

답변:


19

"철 삼각형"의 다른 두 모서리 중 하나를 이동할 준비가되어있는 경우 릴리스 날짜가 고정되어 있어 "민첩한"문제는 전혀 없습니다 . 해당 릴리스에 필요한 요구 사항 또는 사용 가능한 리소스 . 세 가지를 모두 고칠 수는 없으며 실제로 삼각형의 "자원"쪽은 수정하기에 매우 유연하지 않거나 비효율적입니다.

내일 새로운 주요 요구 사항이있는 경우 비즈니스가 해당 요구 사항을 수락 할 준비가되어 있으면 릴리스 날짜가되지 않을 수 있습니다. 즉, 다음 릴리스로 넘어갑니다.


1
나는 항상 삼각형의 자원 측면이 실수라고 느꼈습니다. 품질을 위해 교환하면 더 잘 작동합니다. 그러나 당신은 자리에 있습니다 : 당신이해야하지만 릴리스 기능에 나를 묶으십시오 결과적으로 기능과 품질이 떨어질 것입니다.
David Arno

1
@DavidArno 저는 "품질"이 모든 정의의 일부인 Done의 정의의 일부라고 주장합니다. 그리고 "자원" 은 프로젝트에서 자원을 빼앗아 전달에 큰 영향을 줄 수 있습니다 .
Philip Kendall 19

1
@ChristianHackl : 품질을 원한다면 방법론, 소프트웨어 개발에 많은 시간과 돈이 필요하다고 생각합니다.
Bryan Oakley

2
@BryanOakley : 맞습니다. 민첩한 복음 주의자들이 그들의 방법론이 이와 관련하여 특별하지 않다는 것을 실제로 인식하기를 바랍니다. 애자일이 케이크를 가지고 먹을 수 있다는 잘못된 가정을 버리고 나면 실제로 "애자일"이 얼마나 많은지를 선택하여 프로젝트에 맞는 올바른 개발 프로세스를 설계 할 수 있습니다.
Christian Hackl

1
@ChristianHackl 은총 알 방법론은 없습니다. 그러나 "민첩한"(광범위한 용어)의 주요 요점은 성공적인 배송을 더 저렴하게 / 빠르게 만들어야하는 것이 아니라 (필연적 인) 실패 비용을 낮추는 것입니다.
Guran

3

많은 애자일 캠프의 문제는 마감일이라는 단어에 있다고 생각합니다. 마감일의 위험은 수행해야 할 작업을 알고 있다고 가정하는 것입니다. 당신이 지적했듯이, 당신은 알 수없는 마감일을 가질 수 없습니다.

필립의 답변에 설명 된 내용은 제약 조건보다 마감일이 훨씬 적습니다. 우리는 3 월까지 자금이 있다고 말할 수 있으므로 그 당시 최고의 제품을 가능하게해야합니다.

유추하기 위해 식료품 이야기에 가서 일주일 동안 모든 식료품을 사라고 요청하고 가격을 보거나 가격을보기 전에 당신이 지출 할 것을 정확하게 알려주기를 원한다고 가정 해 봅시다. 또한, 틀리면 벌을받습니다. 프로젝트 마감일로 사람들이하는 일을 정확하게 수행 할 것입니다. 범위가 벌칙을받을 확률이 가장 낮기 때문에 범위가 생각할 수있는 것의 최고 값에서 숫자를 선택합니다. 이제는 이것이 용납 할 수 없다고 말하고 계획 한 것과 동일한 것을 구입해야하지만 $ 50 저렴하게 또는 그 밖의 방법으로 구입해야한다고 말합시다. 이제 무엇을 할 수 있습니까? 쇼핑을 마칠 때까지 인수를 연기하거나 상황을 속이는 방법을 찾을 수 있습니다. 이것은 알려지지 않은 마감일이있는 많은 조직에서 발생합니다.

이제 애자일은이 전체 상황이 얼마나 건강에 좋지 않은지를보고 "예산이 있다면 그 예산에 합의 할 수 있으며 이번 주에 가능한 한 최고의 식사를 그 제약 조건에서 제공 할 것"이라고 말합니다. 어느 것이 훨씬 더 건강한 대화입니까?


당신은 실제로 사람들에게 약속 합니까? 당신이 틀렸고 다른 접근법이 더 나은 식사로 마감일을 맞출 수 있다면 어떨까요?
Christian Hackl

1
애자 및 마감일 유사 인수 여기
에릭 왕

@신자. 확실한. 적어도 그 제약 조건 내에서 제공 할 수있는 것이 가장 좋습니다. 어쩌면 다른 사람이 더 잘 할 수 있거나 상황이 다른 경우 더 나은 해결책을 생각해 냈을 것입니다. 그러나 이러한 추측은 가치가없는 것 같습니다. 특히 프로젝트 후반부에서 항상 더 많은 정보를 얻을 수 있다는 점을 고려할 때, 지금 제공하는 예상 마감일은 그 특성상 나중에 말한 것보다 정보가 부족합니다.
Daniel

물론 우리는 StackExchange 플랫폼에서 상당히 복잡한 주제에 대해 이야기하고 있습니다.이 주제는 광범위한 다방면 주제를 처리하도록 설계되지 않았습니다. 나는 대답을 간결하게 유지하고 플랫폼을 충족시키는 데 집중했습니다. 사실 이것은 매우 좁은 슬라이스이며 소프트웨어 개발의보다 강력한 특성과 개발 수명주기 구성에 대해 많이 말할 수 있습니다.
Daniel

@Daniel : 글쎄, 난 당신이 최선의 접근 방식을 사용한다고 생각하기 때문에 고객에게 이상적인 결과를 약속 한다는 개념에 반대합니다 . 현실적이지 않습니다.
Christian Hackl

2

민첩성은 기술이 아니라 결과입니다. 잔디를 깎는 것과 비교할 때 한 번의 반복은 잔디를 깎은 한 줄의 잔디와 같습니다. 누군가 "15 분 안에 잔디밭을 전체적으로 깎으십시오"라고 말하고 민첩성을 사용하고 있다면 아마도 30 %까지 완료 할 것입니다. 그런 다음 나중에 더 반복하고 완료합니다.


2

예정된 릴리스 날짜를 문제없이 가질 수 있습니다. 이 특정 날짜에 끝이 없는지 확인하십시오. 당신은 해야 모든 질주의 끝 부분에 제공 될 수있는 제품을 가지고 있지만, 일반적으로 그렇게하지 않으면 수행 아무런 해가 없다; 요구 사항 대신 작업에 초점을 맞추는 것이 더 목표입니다. 당신이 계획 출시 날짜가있는 경우에, 당신은 있어야합니다 해당 날짜에 분리 가능한 제품이있다.

일반적으로 계획된 출시 날짜 이전에 테스트를 거치지 않았지만 릴리스 할 수있는 제품을 출시하는 것을 목표로하고, 품질 표준을 충족 할 때까지 제품을 테스트하고 버그를 수정 한 다음 공황없이 제품을 출시합니다. 릴리스에는 당시 준비된 내용이 포함됩니다.

이제 더 많은 기능이 실제로 구현되어 두 번째 릴리스 날짜도 계획해야한다는 사실이 사장에게는 분명하지 않을 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.