변화하는 요구 사항을 어떻게 처리합니까? [닫은]

현재 직장에서는 요구 사항이 많이 변경된 것 같습니다. 우리는 "애자일 (Agile)"샵이므로, 우리가 조정해야하는 것과 그렇지 않은 것을 얻지 만 언젠가는 변화가 크고 사소한 것이 아닙니다.

제 질문은 변경 비용을 어떻게 효과적으로 전달합니까? 민첩하기 때문에 변경이 충분히 크면 현재 스프린트에서 무언가가 떨어질 것이지만 일반적으로 다음 번에 추가됩니다. 우리의 모델은 SaaS이기 때문에 최종 고객은 사실상 비즈니스 자체이며 n 주 후에 컷 기능을 제공 할 것임을 알고 있습니다.

내가 얻으려고하는 것은 n 주 만 지연되어 통신에 사용할 기능이 실제로 제거되지 않는다는 것 입니다. 변경 비용에 대해 비즈니스가 이해하도록하는 다른 방법은 무엇입니까?

@Joe "우리는"애자일 (Agile) "샵이므로, 우리가 조정해야하는 것과 그렇지 않은 것을 얻을 수 있지만 언젠가는 변화가 크고 사소한 것이 아닙니다."

프로세스에서 요구 사항의 변경 속도를 제어 할 수없는 경우 프로세스가 민첩하지 않고 우연한 것입니다. 애자일은 "내 길을 오는 것을 취하는 것"을 의미하지 않습니다.

요구 사항 변경 / 크립을 제어하려면 프로세스에서 요구 사항이 변경되지 않는다는 개념 (스크럼의 핵심 개념)을 채택 할 수 있습니다. 요구 사항 변경은 기존 요구 사항을 새로운 요구 사항으로 대체하는 것으로 간주합니다. 요구 사항에 대한 백 로그가 있어야하며 사용자가 구현하려는 요구 사항을 선택해야합니다.

당신은 2 주 안에 X와 Y를 원했지만 갑자기 Z를 원했습니다. 그럼, 4 주 안에 3 분을 모두 보내드릴 수 있습니다. 또는 2 주 안에 한 쌍 (X와 Z) 또는 (X와 Y) 또는 (Y와 Z)를주고 나머지는 나중에 배송 할 수 있습니다. 고르다.

이것이 고객과 협상하는 방법입니다. 요구 사항 변경 비용을 전달하는 방법입니다. 당신의 그룹이 그 힘을 가지고 있지 않다면, 당신은 민첩한 가게에 있지 않으며, 당신이 그것에 대해 할 수있는 일은 없습니다. 짜증나지만 사실입니다.

협상 할 수있는 경우 요구 사항 및 요구 사항 변경을 구현하는 데 걸리는 시간을 정밀하게 추적해야합니다. 즉, 과거 및 현재 프로젝트에서이 데이터를 수집해야합니다.

요청 (또는 N 요청의 영향을받는 모듈) 당 원래 시간 추정치 및 실제 완료 시간 (개발자 수와 같은 자원 외에)을 수집합니다. 더 나은 방법은 요청 / 요청 변경의 크기를 추정하는 것입니다 (과거 프로젝트 및 요청의 코드 라인 또는 기능 포인트 측면에서).

사용자와 대화 할 수있는 측정 항목이 있다고 가정합니다. 새로운 요청에는 1K 코드 라인 또는 각각 평균 ​​5 개의 입력 필드 (50 개의 기능 포인트)가있는 10 개의 웹 페이지가 필요하다는 것을 알고 있습니다.

그런 다음 과거 프로젝트에 특정한 과거 데이터 (일부 코드 라인, 일부 웹 페이지, 일부 실제 기능 포인트)를 살펴보고 각각의 비용이 절대 완료 시간으로 어떻게 추정되는지를 추정 할 수 있습니다. 충분한 데이터가있는 경우 실제 개발자 인원 수를 추적하는 요구 사항을 식별 할 수도 있습니다.

그런 다음이를 사용하여 고객에게 내역 데이터를 기반으로 알립니다. 프로젝트 실패는 지수 분포 추종을 따르는 경향이 있다고 주장합니다. 그리고 당신은 당신의 고객을 위해 다음과 같은 주장으로 무장합니다.

과거 및 현재 프로젝트의 데이터와 사용 가능한 리소스를 기반으로 요구 사항을 충족시킵니다.

1. 25 %의 실패 확률 (또는 성공의 75 %)로 완료하는 X 시간

2. 1.5 * X 실패 시간 5 % (또는 성공률 95 %)

3. 실패의 95 % (또는 성공의 5 %)로 완료하는 0.5 * X 시간

시간 자원의 함수로서의 실패 확률은 일반적으로 95 %, 25 % 및 5 %가됩니다 (지수 분포를 나타냄). 특정 기준선 금액이 다소 적절한 성공 기회를 제공한다는 메시지를 전달하지만 실제 위험은 ). 그 중 1.5는 위험을 최소화하면서 거의 일정한 성공 확률을 제공하지만 그보다 훨씬 적습니다 (원래의 0.5는 거의 특정 실패를 보장합니다).

당신은 그것들을 소화하게했습니다. 그들이 여전히 위험한 제안을한다면 ( 어제 끝났습니다! ) 적어도 당신은 그들에게 그렇게 말했다고 서면으로 가지고 있습니다. 민첩한 것이 아니라 엔지니어링과 같은 그룹에 대한 희망이 있다면 고객은 귀하의 숫자를 진지하게 고려하고 이에 따라이 요청과 향후 요청을 예약 할 수 있습니다.

엔지니어는 변경 요청이 무료 식사가 아니라고 검증 가능하고 명확한 용어로 엔지니어에게 설명해야합니다.

당신이 묘사 한 것에서, 당신은 문제가 없습니다. 변경을 요청하고 완료 될 때까지 기다리거나 다른 기능을 연기 할 의사가 있습니다. 시간, 자원 및 요구 사항 사이의 균형처럼 보입니다.

새로운 추가 / 변경 연령을 최소로 설정해보십시오 (버그 수정에는 적용되지 않음). 예를 들어, 3 주가 지나기 전에는 새로운 변경 작업을 수행 할 수 없습니다.

처음에는 모든 작업이 매우 중요해 보이는 것처럼 보이기 때문에 작업의 최소 수명을 갖는 것이 좋습니다. 그러나 시간을 기다리면 중요도가 크게 떨어질 수 있습니다. 시간 간격에 따라 작업중인 작업에서 최소한 그 정도의 안정성 시간이 제공됩니다.

연령을 추적하려면 작업을 일부 목록에 추가 할 수 있지만 해당 기간이 만료 될 때까지 작업으로 간주되지는 않습니다.

고객이 프로젝트를 훨씬 느리게 진행하는 것으로 인식하고 개발자가 어쨌든 많이하지 않아야한다고 생각하기 때문에 요구 사항을 자유롭게 변경할 수 있다고 생각하는 기술 용어로 프로젝트가 얼마나 빨리 진행되는지에 관계없이 이것은 매우 일반적인 문제입니다.

이러한 결함 인식은 시간이 걸리고 클라이언트가 제대로 설명하지 못하는 세 가지 주요 개발 작업에서 비롯됩니다.

1. 코드 검토 / 정리 : 이전 코드는 부풀려지고 엉망이되어 정기적 인 검토와 정리가 필요합니다. 시간이 많이 걸리며 고객은 절대 믿지 않습니다.
2. 보안 감사 및 수정 : 특히 주니어 팀 구성원이있는 경우 많은 코드 관련 보안 문제가 발생하며 작성된 새 코드를 정기적으로 검토하고 보안에서보기에 좋지 않은 것을 다시 작성하려고합니다. 고객은이 시간을 알거나 설명하지 않습니다.
3. 아키텍처 관련 변경 사항 : 코드 포인트가 커지면 여러 지점에서 구조적 재고와 리팩토링이 필요할 수 있습니다. A-성능 관련 변경 / 최적화 (알고리즘 변경, 라이브러리 교체, 캐시 엔진 등) 또는 : B-생산성 관련 변경 / 최적화 (가독성, 코드 재사용 성, 이해의 용이성, 새로운 코딩 규칙, 새로운 프레임 워크 등).

위의 어느 것도 최종 고객에 의해 이해되고 올바르게 설명되지 않습니다.

기본적으로 "뷰"(GUI 요소)가없는 것은 수행되지 않았습니다.

이것을 projenix 정리라고 부르겠습니다.