고객의 요구 사항이 전혀 변하지 않을 때 Agile을 사용하는 것이 잘못 되었습니까?

12

최근에 Agile을 사용하는 주요 이유 중 하나가 클라이언트가 종종 요구 사항을 변경하기 때문에 많은 게시물을 보았습니다.

그러나 클라이언트 가 요구 사항을 자주 변경하지 않는다고 가정 해 봅시다 . 실제로, 고객은 약간 모호 할 수 있지만 (불합리하게 모호한 것은 아니지만) 확고한 요구 사항이 있지만 어쨌든 Agile을 사용합니다.

내가 애자일을 사용하는 이유는 소프트웨어가 세부 사항, 실제로 직면 할 때까지 인식 할 수없는 문제가있을 정도로 복잡하기 때문입니다. 폭포와 같은 대규모 대규모 계획 접근 방식을 수행 할 수는 있지만 모든 고급 디자인 및 저수준 코딩 서명을 마무리하는 데 몇 개월이 걸릴 것입니다. 그러나 시스템을 위해 매우 구체적이고 고정 된 건축 설계가 있습니다.

내 질문은 : 이것은 나쁜, 카우보이 코딩, 안티 패턴 등으로 간주됩니까? Agile에서 이러한 '렛트 잇 잇'사고 방식 대신 요구 사항이 안정적 일 때 코딩을 시작하기 전에 폭포를 사용하고 최대한 상세하게 계획해야 합니까?

편집 : 여기서 중요한 점은 다음과 같습니다. 요구 사항 변경에 대한 고객의 책임은 없습니다. 고객이 우리에게 매우 구체적인 문제를 지적하고, 우리에게 매우 합리적인 세부 사항으로 희망 목록을 제공하고, 우리를 내버려 두십시오 (즉, 고객이해야 할 생산적인 일이 더 이상 버그를 일으키지 않도록하십시오). 최소 작업 프로토 타입이있는 경우 종료). 이 시나리오에서 Agile을 사용하는 것이 잘못 되었습니까?

agile development-process

— 정보
소스

2

@randomA : 실제로 IMHO 는 일주일 이상의 노력이 필요한 작업 제품을 만들려는 경우에만 순수한 폭포를 시도 해서는 안됩니다 .

— Doc Brown

10

당신의 고객을주세요

— razethestray

7

@razethestray보다 고객에게 2 배 더 많은 비용을 드리겠습니다

— Euphoric

2

고객이 "매일 귀찮게"하고 싶지 않으면 효과적인 의사 소통 방법을 배우십시오. 예를 들어, 불명확 한 포인트에 대해 (아마도 잘못된) 가정을하는 대신 목록에서 질문을 수집하고 고객에게 정기적으로 목록을 보냅니다. 더 좋은 점 : 요점을 논의 할 회의를 마련하십시오. 요구 사항이 너무 명확하면 목록이 비어있는 상태입니다. 회의가 없습니다 (그러나 나는 그렇지 않을 것입니다). 소프트웨어에 잘못된 가정을 구현하기 시작하면 나중에이를 변경하기 위해 더 많은 노력을 기울일 것입니다.

— Doc Brown

3

@randomA : 당신은 아무것도 묻지 않고 잠시 동안 고객을 행복하게 유지할 수 있으며, 마지막으로 전달할 때 요구 사항을 너무 많이 놓아 프로그램을 버리고 시작할 수 있기 때문에 그를 불행하게 만듭니다. 처음부터 (고객이 기꺼이 지불하지 않을 것임). 또는 올바른 프로그램을 작성하기 위해 충분한 시간을 요구하여 조금만 불행하게 만들지 만, 프로그램이 실제로 원하는 것을 수행하고 그가 지불 한 것을 얻을 때 마지막에는 매우 행복합니다. 선택하십시오.

— Doc Brown

16

이것이 나쁜 카우보이 코딩, 반 패턴으로 간주됩니까?

짧은 대답 : 아닙니다. "민첩한"행동이 "계획 없음"을 의미하는 것은 아니며, 일을 과도하게 분석하지 않는 것을 의미합니다.

애자일이 사용되는 주요 이유 중 하나는 고객이 종종 요구 사항을 변경하기 때문입니다.

그것은 지나치게 단순화 된 진술입니다. "요구 사항 변경"은 또한 요구 사항에 대한 팀의 이해가 어떻게 변화하는지에 관한 것입니다. 고객이 소프트웨어의 몇 가지 릴리스를 실제로 볼 때 요구 사항에 대한 고객의 우선 순위가 어떻게 변하는 지에 관한 것입니다.

실제로 "민첩한"은 설명 된 상황에서 IMHO와 가장 잘 작동 합니다. 고객은 전반적인 요구 사항에 대해 잘 알고 있으며 일반적인 계획을 작성하고 많은 "사용자 사례"로 백 로그를 채울 수 있습니다. 올바른 시스템 아키텍처를 선택하기에 충분한 정보. 민첩한 개발 전략을 짧게 반복하면 "모호한 요구 사항"을보다 정확하게 만들고 올바른 방향으로 가고 있다면 많은 피드백을받을 수 있습니다. 또한 실제 노력과 비용에 대한 조기 피드백을 제공합니다 (모든 요구 사항을 자세히 알고 있어도 폭포 접근 방식에서는 실패 할 수 있음).

— 닥 브라운
소스

3

"폭포"를 올바르게 수행한다는 것이 "모든 것을 계획"한다는 의미는 아니며, 사물을 과소 분석하지 않는 것을 의미합니다.

— Giorgio

1

@Giorgio : "폭포"를 올바르게 수행한다는 것은 요구 사항이 "약간 모호"하고 "소프트웨어가 복잡하여 세부 사항, 실제로 직면 할 때까지 인식 할 수없는 문제가있을 정도로 복잡함"을 의미합니다. 원래 질문).

— Doc Brown

6

이 상황에서 민첩성을 사용하는 것은 여전히 좋은 생각입니다. 민첩하게되면 많은 이점이 있습니다. 그 중 하나만 고객의 정기적 피드백과 언급 한대로 변화하는 요구 사항에 대응할 수있는 기능입니다.

Waterfall 프로젝트가 실패로 악명 높은 주된 이유 중 하나는 '거의 완료된'문제입니다. 결국에는 생성 된 버그 더미를 테스트하여 릴리스 할 수없는 제품을 남겨두고 뛰어난 버그를 수정하기 위해 2, 2 년이 더 필요한지 전혀 모릅니다. 애자일은이 위험을 완전히 제거합니다. 애자일 프로젝트가 과도하게 실행되는 경우에도 다음과 같은 작업 버전을 제공 할 수 있습니다.

A) 데모를 통해 고객이 실제로 거의 근처에 있음을 입증합니다.

B) 어쨌든 그들이 행복하고 해방 될 수있을만큼 충분히 좋다.

나에게있어, 완전한 실패의 위험을 제거하는 것은 비즈니스가 민첩한 개발 프로세스로 전환하기에 충분한 이유 일뿐입니다. 처음에 계획된 것보다 더 나은 소프트웨어를 구축 할 수있는 능력은 케이크 위에 장식하는 것입니다. 다른 답변에서 언급했듯이 이러한 '콘크리트'요구 사항은 종종 놀랍게도 가단성입니다.

— SpoonerNZ
소스

나는 A)가 당신의 대답의 시작 부분에서 언급 한 문제를 어떤 방식으로 해결하는지 이해하지 못합니다 : 마지막 몇 개의 이야기가 며칠 또는 2 년이 걸릴지 어떻게 알 수 있습니까? 당신은 실제로 당신이 실제로 할 때만 알고 있습니까?

— Giorgio

1

맞습니다. 그러나 차이점은 90 % 완성 된 버그가있는 소프트웨어가 아니라 현재 상태로 출시 가능한 제품을 보유하고 있다는 것입니다. 또한 릴리스 할 수있는 기능을 제공하는 데 시간이 얼마나 걸 렸는지, 남은 작업에 대한 추정치는 실제로 수행 한 작업에 대한 증거가 없다는 확신을 더 많이 줄 수 있습니다.

— SpoonerNZ

계획된 기능이 모두 필요한 경우 90 % 기능이있는 제품은 사용할 수 없거나 릴리스 할 수 없습니다. 이미 존재하는 제품의 데모를 제공하는 데만 사용할 수 있습니다. 내 경험상 모든 상황에서 애자일이 바람직하지는 않습니다. 애자일이 더 적합한 프로젝트 (요구 사항 변경, 작고 독립적이며 독립적 인 기능 변경)와 그렇지 않은 프로젝트 (안정적인 요구 사항, 복잡하고 /하거나 미션 크리티컬) 풍모).

— Giorgio

동의합니다. 미달 게재는 어느 경우에도 좋지 않지만 이해 관계자는 모든 기능이 작동하지만 일부 기능이 누락 된 곳에서 사용할 수있는 모든 기능을 갖춘 소프트웨어 버전을 제작하는 팀 또는 귀하에게 이론적으로 모든 기능을 가지고 있지만 많은 충돌을 일으키고 예기치 않은 동작이 많은 소스 코드의 버그 수수께끼? 나는 어느 쪽을 더 신뢰할 것인지 안다.

— SpoonerNZ

물론 첫 번째 팀을 신뢰하지만, 민첩하지 않은 방법을 사용하면 항상 이론적으로 모든 기능을 갖추고 있지만 많은 충돌이 발생하고 예기치 않은 동작이 많이 발생하는 버그 수수께끼 소스 코드 더미로 끝나는 것에 동의하지 않습니다. . 적어도 이것은 지금까지 내 경험이 아닙니다.

— Giorgio

3

애자일은 클라이언트와의 빈번한 피드백 루프가 필요한 경우에 이상적입니다. 요구 사항이 자주 변경되기 때문일 수 있지만 다른 이유로 인해 발생할 수도 있습니다.

반면에 애자일은 요구 사항이 완전히 안정되어 있고 고객이 단일 빅뱅 배달 만 기대할 경우에도 동일하게 작동 할 수 있지만 계획. 즉, 조직 내에서 제품 소유자 역할 을 채워야하며 의사 결정을 내릴 충분한 권한이 고객에게 있어야합니다.

— 바트 반 인겐시나 우
소스

1

너무 많은 참여를 원하지 않는 고객에게 실질적인 비즈니스 요구가 있는지 궁금합니다. 기존 애플리케이션이 새로운 기술로 '번역'되는 프로젝트에서 종종 이런 일이 발생하는 것을 보았습니다. 질문이 있으면 코드를 확인할 수 있습니다. 아무도 리메이크를 기다리고 있지 않습니다.

— user99561

@ user99561 : 당신 말이 맞지만, 그러한 상황에서 요구 사항이 모호하지는 않습니다. 새로운 프로그램이 이전 프로그램 과 똑같이 동작하는 한 명확합니다 . 이러한 상황에서 "민첩한"접근 방식은 실제로 필요하지 않습니다. 많은 고객 상호 작용없이 반복적 인 마일스톤 기반 접근 방식만으로도 충분할 것입니다.

— Doc Brown

맑은? 정확한 행동과 예외가 무엇인지 파악하는 것이 좋습니다. 대부분의 사업가조차도 응용 프로그램에서 발생하는 일을 이해하지 못합니다. 내 충고 :이 프로젝트에서 최대한 빨리 도망 치십시오. 프로젝트가 시작되는시기는 알지만 애플리케이션이 다르게 동작하여 마지막으로 게시 된 버그는 알지 못하기 때문에 수정됩니다.

— user99561

0

언제든지 큰 릴리스를 작은 릴리스 (스프린트)로 분할하고 고객에게 피드백을 요청할 수 있습니다. 이렇게하면 올바른 일을하고 있고 고객이 진행 상황을 추적 할 수 있습니다.

문제가있는 경우 고객에게 더 빨리 정정 할 수있는 기회를 제공 할 수 있습니다. 마지막에 실수를 보여주고 어디서부터 시작 해야할지 모르는 경우 오류를 수정하는 것이 아니라 가능한 한 빨리 실수를 수정하는 것이 좋습니다.

— 실비 우 부르 세아
소스

명확히하기 위해 편집을 추가했습니다. 고객들은 충분한 세부 사항과 명확한 위시리스트를 가진 문제를 보여 주었고 더 이상 문제를 일으키고 싶지 않습니다. 따라서 프로토 타입을 시연 할 수있을 때까지 클라이언트 피드백이 거의 끝날 때까지 없다고 가정하십시오.

— 정보 : A