소요 시간과 절약 시간을 모두 예상해야하는 프로젝트에 유연하고 민첩하게 접근 할 수 있습니까?

이전에 Agile과 효과적으로 협력 한 사람으로서 현재 고용주에게 혜택을 확신 시키려고합니다. 그러나 경영진은 프로젝트의 비즈니스 가치를 평가하기 위해 사전에 예측할 수있는 능력을 유지해야합니다.

내 고객의 대부분은 내부에 있으며 최근에는 팀을 둘러보고 비즈니스 프로세스에 대한 아이디어를 자동화하도록 요청했습니다. 그런 다음 시간이 얼마나 걸리는지 확인하고 솔루션이 총 개발 시간을 절약하는 데 걸리는 시간을 계산했습니다. 이렇게하면 관리자는 솔루션이 시간 절약 측면에서 얼마나 효과적인지 측정 할 수 있습니다.

그러나이 요구 사항에 "민첩한"방식으로 접근 할 수있는 방법이없는 것 같습니다. 유연한 요구 사항은 소요 시간 추정이 잘못 될뿐만 아니라 잠재적 인 시간 절약도 예상됨을 의미합니다. 나는 왜 그것이 문제가 될 수 있는지 설명했지만 협상 할 수 없다고 들었다.

질문 (폭포) 클라이언트에 애자일 개발을 판매하는 방법은 외부 고객 방법 "판매"애자에 대한 몇 가지 유용한 조언이있다. 나는 그것을 외부 고객에게 판매하려고하지 않습니다. 나는 잘 작동하는 방법론을 유지하면서 내부 관리의 요구를 가장 잘 조정할 수있는 방법을 연구하려고합니다.

유연한 방식으로이 작업에 접근 할 수있는 방법이 있습니까?

다른 답변에서 알 수 있듯이 경영진은 프로젝트에 대한 높은 수준의 견적을받을 권리가 있습니다. ROI를 결정하는 데 무리가 없습니다.

그러나 Agile에 대해 좋아하는 접근법 중 하나는 프로젝트의 범위가 고정되어 있지 않다는 것입니다. 처음에는 기능 및 에픽 수준에서 크기를 조정할 수 있으며 비즈니스는 가장 중요한 기능을 기반으로 ROI를 결정할 수 있습니다. 종소리와 휘파람이있는 멋진 UI는 비즈니스 가치는 낮지 만 클레임을 처리하기위한 워크 플로 엔진은 ROI가 높습니다.

전체 프로젝트를 통합하면 원하는 중요한 비즈니스 기능에 집중하는 것보다 ROI를 충족시키기가 더 어렵습니다.

다음은 내가 한 방법입니다.

WBS 이정표를 작성하고 각각을 제공 가능한 기능으로 전환

이를 통해 프로젝트를 다양한 비즈니스 가치를 가진 미니 하위 프로젝트로 분류 할 수 있습니다. 이들 각각은 비즈니스 가치 측면에서 독자적으로 세워 져야합니다.

특징에 노력하는 t- 셔츠 크기

이는 특정 기능의 규모 또는 규모에 대한 대략적인 아이디어를 얻는 매우 쉬운 방법입니다. 가치가 낮은 기능은 쉽게 승리하는 것처럼 보이면 여전히 ROI가 높습니다.

지형지 물을 스토리로 분류

연습을 통해 이해하기 쉬운 작은 기능을 찾아서 처음에는 이야기로 나눕니다. 이 이야기를 포인트별로 추정하십시오. 이제 당신은 근거가 있습니다

작은-> 40 점

이것은 다른 기능과 비교하는 기초가 될 것입니다

스토리 포인트 노력을 모든 기능에 연결

작은 기능을 다른 기능과 비교하십시오. 예를 들어

중형 특징 Y는 40 스토리 포인트의 소형 특징 X의 두 배 크기와 노력 인 것 같습니다.

보통 기능 Y는 아마도 80 스토리 포인트입니다. 모든 기능에 대해 스토리 포인트가 높은 수준으로 추정 될 때까지이 작업을 계속하십시오.

팀 속도 추정

개발 팀을 살펴보면서이 팀이 주어진 스프린트에서 효과적으로 제공 할 수있는 스토리 포인트 수를 결정하십시오. 이 팀과 함께 예전 애자일 프로젝트를 가지고 있다면 시작하기에 좋은 곳입니다. 팀 뒤에 이러한 기록이없는 경우 팀과 함께 모의 스프린트 계획을 진행하여 세부적인 세부 기능을 살펴보십시오. 사람들이이 이야기에 대한 작업을 위해 어떤 종류의 시간별 견적을 제공합니까?

팀이 2 주 안에 제공 할 수있는 작업량에 따라 총 스토리 포인트 수를 팀의 평균 잠재적 속도로 사용하십시오!

예상 완료 날짜 찾기

모의 스프린트 계획에있는 팀이 스프린트에 25 스토리 포인트를 제공하는 것이 편안하다고 느끼고 총 백 로그가 프로젝트의 골드 캐딜락 버전에 대해 300 스토리 포인트처럼 보이는 경우 팀이 12 스프린트 또는 24 주에 이상적으로 걸리는 것처럼 보입니다. 모든 것을 완료하십시오.

이제 ROI 대 비즈니스 가치에 도달하기 위해 팀의 리소스 비용을 주당 달러로 바꾸는 것은 쉽지 않습니다. 협상은 가장 중요한 기능에 대해 계속 진행할 수 있으며 프로젝트 관리는 기본적으로 배낭 문제가됩니다.

"관리"에는 문제가 없습니다. 시작하기 전에 잠재적 인 프로젝트의 비용과 이점을 추정 할 수 있어야합니다. 그렇지 않으면, 누군가가 가치있는 일 (또는 시도하는 것)을 어떻게 알 수 있습니까?

그렇다면 왜 애자일입니까?

민첩한 방법을 사용하는 것은 불확실성을 선택 하는 것이 아니라고 주장합니다 . 오히려 애자일은 불확실성이 불가피하다는 주장이며, 전통적인 방법의 세부적인 사양과 추정은 잘못된 확신을 초래합니다.

시간 추정 측면에서 몇 가지 핵심 사항 :

• 프로젝트 전체의 요구 사항 변경은 불가피합니다. 애자일은 변화가없는 척하기보다는 이것을 고려합니다.
• 세부 사양에는 종종 프로젝트에 적용되기 전까지 밝혀지지 않은 설계 결함이 포함됩니다. 이는 기존 프로젝트에서 애자일 프로젝트보다 더 큰 변화 를 의미 할 수 있습니다 .
• "이 프로젝트 전체가 얼마나 큰 것 같아?"에 기초한 시간 추정치 많은 세부 요구 사항에 대한 예상 시간을 합산하는 것만큼이나 정확할 것입니다.
• 올바른 추정으로 이끄는 주요 사항은 추정, 측정 및 검토주기이며, 이는 일관된 프로세스에 적용 할 수 있습니다.
• "저장된 작업량"추정치는 세부 사항이 아닌 프로젝트의 주요 요구 사항에 의해 결정될 것이기 때문에 Agile이이를 추정하는 능력에 큰 해를 끼치 지 않을 것입니다.

최신 정보:

분명히 말하면, 상사에 대한 귀하의 답변은 "유연한 시간이기 때문에 Agile을 사용하여 시간을 절약하거나 전체 개발 노력을 잘 평가할 수는 없습니다." 나는 이것이 잘못이라고 생각합니다. 어쨌든 불확실성이 있기 때문에 애자일 프로세스를 사용할 때 이러한 추정을 수행 할 수 있다고 생각합니다. 물론 Agile은 프로젝트가 전개됨에 따라보다 유연하고 반응이 빠른 프로세스를 허용합니다.

이것은 애자일 도입의 가장 어려운 부분 중 하나입니다.

"관리는 여전히 시간 추정이 필요합니다"

내 접근 방식은 다음과 같습니다

• 패드 300 %. 300 %의 오래된 말은 관리 수준에서 실제로 민첩한 상황이 발생하지 않을 때 유용합니다. 이것은 "민첩한 접근 방식"이 아니지만 이 상황에 대한 타협 입니다. 당신은 몇 번 앞서 올 수있을 것입니다-하지만 그것을 의지하지 마십시오!

• 프로젝트의 '반쪽'지점에서 달성 한 작업을 바탕으로 검토를 요청하십시오. 수행 한 작업을 기반으로 완료 될 때 프로젝트하십시오. 그런 다음 경영진과 대화하고 프로젝트 시작시 추측에 따라 시간이 고정되는 경우 기능 또는 품질을 희생 할 대상을 선택하십시오.

• 경영진과 수행 한 기능 및 품질에 대해 협업하고 있는지 확인하십시오.

• 이 프로젝트의 흐름에 따라 마감일 누락, 품질 저하, 퇴근 및 퇴근 직원 등의 일상적인 일이 발생하도록하십시오. 다음 단계의 프로젝트가 시작되면 이러한 '부작용'에 대해 논의하십시오.

• "진정한"민첩한 접근 방식 의 장점 에 초점을 맞추고 설명하십시오 . 품질 향상에 대해 이야기하십시오. 하루 중 늦게까지 변경하여 생산에 들어가는 능력에 대해 이야기하십시오. 재 작업의 필요성이 줄어든 것에 대해 이야기했습니다. 기술 부채가 줄어들면서 결국 개발이 크롤링 될 것이라고 이야기하십시오. 예를 들어, 우리는 하루 종일 오일 교환을 할 수 있지만 엔진을 손상시키고 성능이 저하되며 결국 막대를 날려 버릴 수 있습니다.

• 이력서와 링크 된 프로필을 최신 상태로 유지하십시오. 사례를 몇 번 작성한 후에 관리 지원을받을 수없는 경우 계속 진행하십시오. 일부 조직은 귀하의 주장에 등재되지 않으므로 해당 조직으로 이동하십시오. 그것을 다윈주의 고용이라고 부름;)

애자일 개발에 대해 잘못된 가정을하고 있다고 생각합니다. 유연성과 변화하는 요구 사항은 말 그대로 민첩한 선언문에 포함 됩니다.

개발 후반에도 변화하는 요구 사항을 환영합니다. 민첩한 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.

유연한 (읽기 : 변경) 요구 사항은 Agile에서 환영합니다. 대부분의 개발자에게 요청하면 변경 사항이 합리적이어야한다는 경고를 추가합니다. 팀에게 3D 게임을 구축하도록 요구 한 다음 요구 사항을 "원자 원자로 제어 시스템"으로 변경하는 것은 다소 중요합니다. 그러나 프로젝트 범위에서 요구 사항을 추가, 제거 또는 수정하는 것은 완벽합니다.

문제는 변화하는 요구 사항에 어떻게 대처 하는가입니다. 일반적인 대답은 짧은 반복을 사용하여 너무 많은 시간을 낭비하기 전에 조기에 코스를 조정할 수 있다는 것입니다. 또한 팀이 요구 사항을 더 작은 조각으로 분해하여 모든 사람이 요구 사항을 더 잘 이해하고 합리적인 시간과 노력으로 요구 사항을 구현할 수 있도록합니다.

완료되지 않은 작업량을 최대화하는 기술인 단순성은 필수적입니다.

나는 또한이 민첩한 원칙을 좋아합니다. 일반적으로 팀은 무자비한 효율성을 통해 필요한 것만 제공하기 위해 노력해야합니다. 예를 들어, 고객 이 무언가가 필요 하다고 생각 하지만 비린 것처럼 보이면 파헤쳐보십시오. 최종 사용자는 실제로 사용하지 않을 수 있으므로 작업을 수행하지 않아야합니다.

그러나 귀하의 질문 이이 원칙의 다른 측면에 부딪쳤다 고 생각합니다. 소프트웨어는 일반적으로 수동 프로세스를 자동화하는 목적으로 사용됩니다. 소프트웨어 자체는 최종 사용자가 수행하지 않은 작업량을 최대화하기 위해 존재합니다.

소프트웨어가 최종 사용자를 구하는 노동량을 측정하는 것은 확실히 가치있는 척도입니다. 나는 내 경력에서 이것을 직접 측정했습니다. 실제로 비용 / 혜택 분석의 중요한 구성 요소입니다. 최종 제품이 최종 사용자를 얼마나 많이 절약 할 수 있을지에 비해 소프트웨어 프로젝트가 얼마나 많은 노력을 기울일 것인지입니다.

이는 애자일 (또는 다른) 개발 철학과 절대적으로 호환되며 경영진은이를 반드시 고려해야합니다.

예, 민첩성은 몇 가지 장점이 있습니다.

• 그것은 비즈니스 사람들이 비행 중에 마음을 바꿀 수있게합니다.
• 그것은 일종의 엔지니어의 영원한 나쁜 추정으로부터 비즈니스를 보호합니다.
• 최종 비전을 달성하기 전에 조기에 그리고 종종 가치를 제공합니다.
• 그것은 당신이 여분 일부 종종 나쁜 계획을 생성 할 수있는 선행 계획 비용의 어쨌든 .
• 정말 멋지다. 권리?

그러나 여전히 정확한 사전 예측을 제공해야합니다.

그렇지 않다면, 제품에 초기 투자 가치가 있다는 증거도없고 어떤 경우에는 전혀 가치가 없다는 증거없이 제품에 투자하라고 효과적으로 요청하는 것입니다.

그리고 지금들을 수 있습니다.

전에 들었습니다. 나는 전에 그것을 말한 것이 확실 합니다.

아-하지만 Haow !? HAOW는 저와 같은 단순한 인간이 그러한 것들의 운명에 내 눈을 응시합니다! 신들 자신 만이 신성하고 지시 할 수있는 것들. 필사자들이 가장 깊은 잠에서 꿈을 꾸고 하루 종일 잊을 수있는 것들! 압제적인 관리 유형, 그런 요구를 충족시킬 수 있는가!?

과거의 공연을 가이드로 사용하고 정직하십시오 .

• 이해 관계자 및 / 또는 최종 사용자와 충분히 대화하여 제품 및 / 또는 주요 구성 요소가 작업 한 다른 주요 구성 요소와 비교하여 얼마나 복잡한 지 결정하십시오 . 초기 상대 점 추정을합니다.
• 역사적으로 보았던 범위 변경 및 버그 감소의 양으로 해당 숫자를 부풀립니다 .
• 대략적인 타임 라인에 도달하려면 포인트 추정치에 과거 속도를 적용하십시오. 그리고 불확실성 의 합리적인 원뿔을 적용하십시오 .
• 프로젝트에 대한 평가 및 이해를 다시 검토하십시오. 확신 할 당신은 당신의 평가를 기반으로 프로젝트를 태클에 대한 결정을 기꺼이 것입니다.

마지막으로, 불확실성의 원뿔을 이해 당사자들에게 제시하고, 가정과 우려 사항을 말하고, 그대로 두십시오.

제쳐두고, 나는 또한 당신 및 / 또는 팀의 정상적인 추정을 온전히 확인하기 위해 객관적인 포인트 추정 휴리스틱을 제안하는 것이 좋습니다.

포커를 계획하는 동안 또는 혼자가는 경우 개인 견적을 확인 하는 데이 견적을 N 번째 투표 로 사용할 수 있습니다 . 예를 들어, 우리 팀 은 이야기에 대한 느슨하게 기술적 인 발견 토론을 분당 약 1 포인트 정도 추정 하는 경향이 있습니다. 이것은 장이 이야기가 5 점이라고 말하면 특히 유용하지만, 수행해야 할 일을 이해하는 데 20 분이 걸렸습니다. 보통 복잡성과 오해가 숨어 있다는 좋은 지표입니다.

나는 지속적으로 좋은 시간 추정을 할 수 있었던 회사에서 일한 적이 없으며, 그렇게 주장하는 사람과도 일한 적이 없습니다. 검색하면 업계 전체에서 추정이 해결되지 않은 문제임을 알 수 있습니다.

추상적 인 스토리 포인트를 기반으로 속도를 측정하는 방법에 대해 자세히 알아 보려고 노력할 수 없다면, 추정치에 더 많은 관심을 기울여야합니다.

애자일은 모든 범위의 문제에 대한 훌륭한 해결책이지만 일부 복음 주의자들이 제안한 내용에도 불구하고 유일한 해결책은 아니며 항상 올바른 해결책은 아닙니다.

언급 된 사례는 단순히 민첩한 문제가 아닙니다.

나는 최근에 팀을 둘러보고 자동화 할 비즈니스 프로세스에 대한 아이디어를 요청하는 일을 맡았습니다. 그런 다음 시간이 얼마나 걸리는지 확인하고 솔루션이 총 개발 시간을 절약하는 데 걸리는 시간을 계산했습니다. 이렇게하면 관리자는 솔루션이 시간 절약 측면에서 얼마나 효과적인지 측정 할 수 있습니다.

변화하는 민첩한 작업이 아닌 일부 비즈니스 프로세스 자동화의 비용과 이점을 결정해야하는 작업은 특정 솔루션의 특정 문제입니다. 임의의 수의 비즈니스 프로세스가 포함 된 목록을 작성하고 각각에 대해 예상 자동화 비용, 자동화되지 않은 예상 비용 및 자동화의 예상 이점이 있습니다. 경영진은이를 예산, 자원, 요구 사항 및 전략적 목표와 비교하고 이러한 프로세스 중 자동화 할 프로세스를 결정합니다 (있는 경우). 양심적이라면 ROI를 낮출 수는 있지만 다른 단계의 비용을 줄여 총 ROI를 향상시키는 선택된 작업을 강조 표시하게됩니다. 사내 및 아웃소싱 된 맞춤형 개발 (애자일 및 / 또는 워터 폴 기법 사용), 선반 솔루션 구매, 타사 서비스 제공 업체 등을 포함하여 자동화를 달성하는 다양한 방법을 식별했을 수도 있습니다. 이 전체 프로세스는 비즈니스 프로세스 리엔지니어링으로 알려진 90 년대에 매우 유행했습니다.