민첩, 폭포 및 요구 사항 변경

10

요구 사항 변경으로 인해 '애자일'로 정의 된 프로젝트의이 문제가있는 사람이 있습니까? 나는 스프린트 4 주 안에 진행되는 개발 프로젝트를 진행하고 있지만이 스프린트 사이에는 항상 변화가 있습니다. 여전히 Agile로 정의되어 있습니까? 나는 그것이 일종의 하위 민첩한 프로세스라고 생각합니다. 민첩한 프로세스의 요구 사항은 스프린트의 시작 부분에서 정의되어 끝까지 검토되어야합니다. 내가 이것에 맞습니까? 이것에 대한 당신의 경험을 알려주십시오.

agile requirements

— 아 라빈 드 A
소스

"요구 사항 변경"은 느슨한 용어입니다. 고객이 승인 된 요구 사항에 대해 실제로 마음을 바꿨 기 때문에 변경이 있습니까? 무엇이 그 변화를 일으켰습니까? 이 문제가 계속 발생하면 요구 사항 수집 방법을 다시 검토해야합니다. 적절한 요구 사항 수집이 부족한 SE 방법론은 없습니다.

— NoChance

@Emmad 사용자가 특정 수단으로 유용성을 향상시킬 수 있다고 느끼면 UAT 중에 요구 사항이 변경됩니다. 이로 인해 사전 프로덕션 문제가 발생합니다. 이것은 확실히 민첩하지 않습니다.

— Aravind A

@Aravind A : UAT는 스프린트가 끝날 때 발생합니다. 그런 다음 UAT 중에 발생하는 새로운 아이디어 / 변경 사항은 일반적으로 다음 스프린트 (스프린트를 사용하는 경우)의 스토리가됩니다.

— sleske

@sleske가 제안하는 것은 효과가 있지만 사용자가 예외적 인 요구 사항을 가지고 있다면 사용 편의성을 미리 프로토 타입으로 만들 수 있습니다. 때로는 자원이 많은 프로젝트에서 사용자의 야망을 통제해야합니다.

— NoChance

9

민첩한 프로세스의 요구 사항은 스프린트 시작 부분에 정의되어 있으며이를 향해 검토해야합니다. 내가 이것에 맞습니까?

아니요, 이것은 프로젝트의 성격과 프로세스에 따라 다릅니다.

스프린트 중에 요구 사항을 수정해야하는 민첩한 개발 모델이 있으며 다음 스프린트에 대해서만 변경해야합니다 (예 : Scrum).

그러나 고객이 지연과 변경으로 인한 추가 작업을 수락하는 한 거의 언제든지 변경이 발생할 수있는 프로세스도 있습니다. Kanban은 종종 이러한 워크 플로를 관리하는 데 사용됩니다 (Kanban은 Scrum과 결합 할 수도 있음).

따르는 모델은 각 프로젝트의 세부 사항에 따라 다릅니다.

따라서 고객이 요구 사항을 지속적으로 변경할 가능성이 필요하다고 느낀다면 민첩한 프로세스가이를 수용 할 수 있습니다. 그러나 고객은 지속적인 변경의 결과에 대해 알고 있어야하며 프로젝트 속도가 느려질 것임을 이해해야합니다.

이는 애자일 선언문의 "프로세스와 도구에 대한 개인과 상호 작용"및 "계획에 따른 변경에 대한 응답" 의 원칙으로 요약됩니다 .

— 썰매
소스

프로세스를 지나치게 민첩하게 만들지 않습니까? 민첩성은 얼마나 멀리 갈 수 있습니까? 개발자가 처음으로 요구 사항을 충족하면 다음 번에 수요가있을 것입니다. 나는 이것이 코드 품질이 던져지는 많은 문제 중 하나라고 생각합니다.

— Aravind A

@AravindA 코드 품질은 별도의 관심사 여야하며 코드 변경 횟수에 관계없이 팀은 항상 동일한 코드 품질 표준에 중점을 두어야합니다. 실제로 요구 사항과 코드가 끊임없이 변하기 때문에 코드 품질이 더 중요합니다.

— maple_shaft

2

@maple_shaft는 옳습니다-품질은 (적어도 대부분) 요구 사항 변경에 직각입니다. 요구 사항 : 좋은 코드 작성을 시작합니다. 내가 완료하고 새로운 요구 사항을 얻거나 반 완료하고 변경을 받으면 좋은 코드를 작성하기 시작합니다. 현재 일정 / 약속 등에 대한 영향을 강조한 후

— sdg

시스템 설계 방식에 큰 영향을 미치는 요구 사항 변경으로 인해 지연이 발생하거나 품질이 저하 될 수 있습니다. 그렇기 때문에 "갑작스런"외관의 위험을 줄이려는 오래된 폭포수 분석을 반복해야합니다 (반복적 일 수도 있음).

— MaR

@sles 설명해 주셔서 감사합니다. 나는 지금 그것을 얻는 것 같아요. Agile에 대해 더 많이 알아야 할 것 같습니다.

— Aravind A

12

나는 당신이 물어봐야 할 질문은 : 왜 당신은 요구 사항 변화에 의해 오버런 되는가? 일반적인 원인은 다음과 같습니다.

개발자는 최종 사용자와 연락이 충분하지 않아서 사용자의 요구를 이해할 수 없습니다. 대신 그들은 추상 루빅스 큐브처럼 요구 사항을 처리합니다. 그들은 그들의 정신을 이해하려고 노력하지 않고도 요구 사항의 글자를 따릅니다.
누군가 (예 : 마케팅)는 최종 사용자에게 이해가되지 않는 요구 사항을 추가하고 있습니다 (예 : 브로셔에서는 양호 함). 따라서 "진정한"요구 사항과 "기타"요구 사항 사이에는 개발자의 요구에 맞서 싸우는 전투가 있습니다.
프로젝트의 범위는 정의되어 있지 않습니다 ( "어쨌든 워드 프로세서를 구현하는 경우 급여 회계를 수행하는 작은 모듈 만 추가 할 수 없습니까? 오, 다른 개발 팀의 Bill은 얼마나 어려운지 물었습니다." 워드 프로세서도 C ++ 코드를 컴파일하게 하시겠습니까? ")

근본적인 문제가 무엇이든간에이를 해결해야합니다. "Agile"(또는 다른 방법론) 계층에서 익사하면 작동하지 않습니다.

— 니키
소스

@nike 감사합니다. 이것이 바로 내가 생각한 것입니다. 세 번째 요점은 내 시나리오에 맞습니다. 일부 고객은 작업 속도를 높이기 위해 은총 알이라고 생각하는 작업 'Agile'을 활용합니다.

— Aravind A

9

요즘에는 관리 유형에 가장 인기있는 애자일 프로세스 인 스크럼에서는 스프린트의 범위가 고정되어 있습니다. 스프린트 동안 스프린트 백 로그가 바뀌면 스크럼이 아니라 혼란입니다. 스프린트 백로 그는 스프린트 시작시 생성되어야하며 스프린트가 끝날 때까지 고정되어 있어야합니다 (이 시점에서 다음 스프린트에 대한 새로운 스프린트 백 로그를 작성합니다).

스프린트 중에 제품 백 로그가 변경되면 큰 문제가되지 않습니다. 변경 사항은 다음 스프린트에 대한 다른 요구 사항과 같이 우선 순위가 매겨지고 추정되고 선택된 새로운 작업이되었습니다. 그러나 제품 소유자가 스프린트를 정기적으로 취소해야하기 때문에 요구 사항이 너무 많이 변하는 경우 대문자 'T'로 인해 문제가있는 것입니다.

더 짧은 스프린트가 필요할까요?

— 아담 자 스키 비츠
소스

더 짧은 스프린트가 필요한 경우 +1 2 주로 확장하여 도움이되는지 확인하십시오.

— John

1

스프린트, 특히 요구 사항이 불안정한 프로젝트의 경우 4 주가 실제로 아주 길게 들립니다.

— Carson63000

7

프로그래머의 건강을 위해 개정 / 스프린트 중에 요구 사항이 변경되지 않는 것이 가장 좋습니다.

상황에 따라 두 가지 확실한 옵션이 있습니다.

더 짧은 스프린트
전체 개정 / 스프린트가 취소되고 재 계획 되지 않는 한 고객이 개정 / 스프린트 동안 요구 사항을 변경하지 않을 것에 동의하게합니다.

나는 두 가지를 강력히 추천 합니다 .

— 스티븐 에이 로우
소스

3

가장 큰 문제는 스크럼을 사용하고 있다고 믿지만 그렇지 않은 것입니다. 특히 제품 소유자가 따르지 않습니다. 스크럼에서 스프린트는 안전한 영역이며 현재 스프린트가 취소되지 않으면 커밋 된 사용자 스토리를 변경할 수 없습니다. 이것을 시행하는 것은 Scrum master의 책임입니다. 이것이 환경에서 작동하지 않으면 프로세스 문제 = Scrum을 사용하지 않는 것입니다.

스크럼을 따르고 싶다면 가장 간단한 방법은 스프린트를 짧게 만드는 것입니다 (예 : 일주일). 4 주 스프린트는 스크럼 초기에 옵션으로 간주되었지만 현재는 1-2 주이며 3 주가 상위 경계로 간주됩니다. 환경 변화에 4 주가 걸렸습니다.

— 라디 슬라 프 므 른카
소스