민첩한 방법으로 우수한 소프트웨어를 개발하는 방법은 무엇입니까?

고객 만족도 의 카노 모델 은 다양한 종류의 제품 기능을 정의합니다. 그들 중에는

1. 필수품 : 구현되지 않은 고객은 제품을 수락하지 않습니다.

2. 매력적인 품질 (운임 자) : 고객이 처음에는 기대하지 않지만 발견 될 때 흥분과 즐거움을 유발하는 기능.

매력적인 자질은 분명히 많은 비즈니스 가치를 가지고 있습니다. 5.000 미만의 중고 피아트가 모든 필수 요건을 충족 할 때 사람들은 페라리를 500.000에 구매하게합니다.

그러나 필자가 알고있는 모든 민첩한 프로세스는 필수 요구 사항을 강력하게 선호합니다. 이들은 항상 가장 높은 우선 순위를 갖습니다. 민첩한 매력적인 자질을위한 장소도없는 것 같습니다.

민첩한 프로세스가 소프트웨어 개발에 매우 ​​유용하다고 생각합니다. 그러나 필수 요구 사항을 거의 충족시키지 못하는 최소한의 수준이 아니라 유쾌한 고품질 소프트웨어 제품을 만드는 데 어떻게 적용 할 수 있습니까?

부록 : 처음 두 가지 답변이 지적했듯이 필수 요건을 최우선으로하는 것이 합리적입니다. 그러나 우리 (및 고객)는 항상 필수 요구 사항이 무엇인지 미리 알고 있습니까? 처음에 우선 순위가 높은 요구 사항이 나중에 쓸모 없지는 않지만 훨씬 덜 중요하다는 사실을 몇 번이나 경험했습니다. 그러므로 필자는 필수 요건에 노예로 집중해서는 안된다고 생각합니다.

공식적인 답변은 민첩성을 오해하고 민첩성이 요구 사항을 지시하지 않으며 이해 관계자가 이해한다는 것입니다. 애자일의 핵심은 돌로 요구 사항을 개척하는 것이 아니라 고객과 밀접한 관계를 유지하면서 점진적인 통찰력의 혜택을 누리면서 요구 사항을 드러내는 것입니다.

그러나 그것은 모두 이론입니다. 당신이 목격 한 것은 실제로 민첩한 작업 방식을 채택한 많은 소프트웨어 생산 라인의 공통된 특징입니다.

문제는 고객의 말을 듣고 고객의 요구에 신속하게 대응하는 것이 곧 제품에 대해 전혀 생각하지 않거나 디자인을 전혀하지 않는 결과입니다. 비전과 전문 지식으로 공급 된 사전 예방 적 프로세스였던 것은 종종 고객의 요구에 따라 수동적이고 완전히 반응적인 프로세스로 악화 될 수 있습니다. 이것은 "일을 할 것"이라는 필수품 만 만들게 될 것입니다.

당시 고객이 요구하는 모든 고객이 더 빠른 말 이었기 때문에 당시 제조업체가 "민첩한"상태라면 자동차는 결코 발명되지 않았을 것입니다.

그럼에도 불구하고 민첩성이 나빠지지는 않습니다. 공산주의와 비슷합니다. 사람들은 단지 사람들이고 사람들이 일을하기 때문에 잘 작동하지 않는 좋은 아이디어입니다. 그리고 방법 / 이념 / 종교는 그들이 움직임을 겪고 있거나 규칙을 따르는 한 그들이 잘하고 있다는 생각에 빠져들게됩니다.

[편집하다]

Slebetman :

자동화 산업 (즉, Toyota)에서 민첩성이 진화 한 것은 아이러니 한 일입니다.

자동화의 황금률을 기억하십니까? "먼저 조직하고 자동화하십시오". 손상된 프로세스를 자동화하는 경우 발생할 수있는 최선의 방법은 잘못된 모든 것을 가속화하는 것입니다. Toyota의 사람들은 바보가 아니 었습니다.

새로운 방법론을 채택하는 일반적인 이유는 상황이 좋지 않기 때문입니다. 경영진은이를 인정하지만 핵심 문제를 이해하지 못할 수도 있습니다. 그래서 그들은이 전문가를 고용하여 애자일과 스크럼에 대한 탄력적 인 연설을합니다. 그리고 모두가 그것을 좋아합니다. 그들 자신의 이유로.

개발자들은 "이것이 효과가있을 수 있습니다. 우리는 비즈니스 문제에 더 관여하고이 백 로그를 작성하기위한 정보를 제공 할 수 있습니다. 이는 영업 및 고객 서비스가 우리가하는 일, 왜 필요한지를 이해할 수있는 기회가 될 수 있습니다. 우리가 동의 한 것을 투명하게 불 태우는 동안 우리는 그것들을 머리카락에서 빼낼 것입니다. " 더 이상 "당신이하고있는 일을 그만두십시오. 지금이 일을해야합니다."

반면에 판매, 고객 서비스 또는 소유자는 아마도 필요한 작업을 수행하는 부서의이 블랙 박스에 대한 제어 권한을 얻는 방법으로 볼 수 있습니다. 그들은 거기에서 무슨 일이 일어나고 있는지 알지 못하지만 문제의 핵심이 어딘가에 묻혀 있다고 확신합니다. 그래서 그들은 스크럼을 소개하고, 선택한 제품 소유자를 설치하고 갑자기 모든 제어권을 갖습니다. 이제 뭐? ... 어 ...

실제 문제는 종종 상점이 처음에 잘 조직되지 않아서 변경되지 않았다는 것입니다. 사람들은 자신이 감당할 수없는 책임을 맡았을 수도 있고 어쩌면 할 수도 있지만, 보스 씨는 자신이 한 일이나 (가장 경험상 가장 자주)하는 일을 끊임없이 방해하고 망치고 있습니다.

때때로 시간이 지남에 따라 비공식 조직이 공식 노선 사이에 출현 할 수 있습니다. 이것은 공식적인 구조의 부족을 부분적으로 보상 할 수있다. 어떤 사람들은 명함을 가지고 있는지 여부에 관계없이 자신이 잘하는 일을 끝내게됩니다. 애자일 / 스크럼 (Agile / Scrum)의 무뚝뚝한 도입은이를 즉시 망칠 수 있습니다. 사람들은 이제 규칙에 따라 연주해야합니다. 그들은 그들이하는 일에 감사하지 않는다고 느낀다. 대신에 작은 이야기가 적힌 노란 작은 종이를 얻는다. 말할 것도없이, 그러한 개인들에게는 특별히 동기 부여가되지 않을 것입니다. 그들은 주문을 기다리는 것이 좋으며 더 이상 주도권을 갖지 않을 것입니다.

따라서 상황이 악화되고 애자일이 짜증나게 될 것입니다.

애자일은 빨라지지 않으며 유지 관리 프로젝트에 적합하며 신중하게 적용하면 새로운 개발에도 유용 할 수 있지만 잘못된 사람들이 이해하지 못하거나 잘못된 이유로 채택하면 가장 파괴적 일 수 있습니다.

민첩한 매력적인 자질을위한 장소도없는 것 같습니다.

사과와 오렌지를 비교하고 있습니다. 전통적인 폭포에서 요구 사항에 필수 아이템이 필요하다고 말하는 경우 피아트가 제공됩니다. 요구 사항이 최고 수준이어야한다고 말하면 페라리를 얻습니다.

애자일에서도 마찬가지입니다. 필수 요건을 충족하지 않으면 법정 화폐를받습니다. 우수성에 대한 이야기가 있다면 페라리를 얻게됩니다. 민첩 그 모든 정말 강제 당신이해야에있는 거랑을 할 것입니다 첫째 . 2 년 동안 슈퍼 쿨 스포일러를 제작하지 않고 엔진 마감일을 놓치십시오.

너무 긴 이야기는 짧습니다. 필요한 것을 얻습니다. 스포츠카를 계획하면 스포츠카를받습니다. 애자일은 전혀 바꾸지 않습니다. 애자일 프로세스가 피아트 요구 사항을 충족시키는 경우 민첩성을 비난하지 말고 피아트 만 필요한 사람들을 비난하십시오.

그러나 필자가 알고있는 모든 민첩한 프로세스는 필수 요구 사항을 강력하게 선호합니다. 이들은 항상 가장 높은 우선 순위를 갖습니다.

그들이해야 할대로-Kano 모델을 다시 살펴보십시오. 필수 요구 사항이 충족되지 않으면 고객은 제품을 수락하지 않습니다. 그리고 당신의 기쁨은 중요하지 않습니다.

민첩한 매력적인 자질을위한 장소도없는 것 같습니다.

더 이상 진실에서 멀어 질 수는 없습니다.

민첩한 프로세스는 일반적으로 다음 사항을 강조합니다.

• 피드백을받을 수있는 작동중인 제품을 자주 제공합니다.
• 짧은 시간에 완료 할 수있는 기능을 작은 부분으로 나눕니다.
• 우선 순위에 따라 해당 부분을 구현하십시오.

"기쁨"기능을 우선시하는 것을 막을 수있는 것은 없습니다. 우선 순위를 결정하는 담당자에게 전적으로 달려 있습니다.

많은 사람들이 위험을 감수하지 않기를 원하므로 "운임 자"에게 높은 우선 순위를 부여하지 않을 수도 있습니다. 그러나 민첩하지 않은 프로젝트에서는 여전히 그렇습니다.

애자일에 대해 아무것도 말한다 무엇 해당 코드가 점진적으로 작성해야합니다 먼저 수행 및 유지 해제 가능한 상태로 가능한 한 자주, 대신에 계획해야 다음 해제 상태까지 달 동안 사용할 수 없습니다.

저는 Agile과 BDUF (Big Design Up Front) 프로세스를 모두 수행했으며, BDUF의 두 프로세스에서 혁신적이고 매력적인 기능을 확실히 얻을 수 있지만 당연히 미리 계획해야합니다. 즉, 혁신은 일반적으로 설계 프로세스에 영향력이있는 사람들이 제안하거나 최소한 후원해야합니다.

그 이유는 다음 릴리스까지 6 개월 (또는 무엇이든)이 있고 프로젝트 관리자는 해당 릴리스에 포함될 사항에 대해 스트레스를 받기 때문입니다. 기능이 적용되지 않으면 다음 릴리스까지 6 개월이 더 걸리기 때문입니다. . 따라서 잼으로 채워진 스케줄에는 잼으로 채워진 기능 목록이 있으며, 낮은 순위 및 파일이 시원한 것으로 2 ~ 3 일 동안 작동하는 경우 고객이 좋아할 것이라고 생각하며 그렇지 않습니다. 그들은 전체 일정을 위험에 빠뜨릴 것이고 지불해야 할 지옥이있을 것입니다.

애자일 프로세스에서는 소프트웨어를 릴리스 가능한 상태로 유지하기 위해 노력하고 있으며 프로젝트 관리자는 기능이 저하되면 2 주 안에 소프트웨어를 얻을 수 있기 때문에 스트레스를 덜받습니다. 따라서 개발자가 멋진 아이디어가 담긴 회의에서 돌아와서 며칠을 보낸다면 6 개월의 혈액 내 일정을 위험에 빠뜨리지 않습니다.

기본적으로 뿌린 것을 거둔다. 혁신을 장려하고 팀에게 충분한 자율성을 제공하면 혁신을 얻을 수 있습니다. 마감일을 맞추기 위해 지속적으로 절단 코너를 요구하는 경우, 방법론에 관계없이 소프트웨어를 일치시킬 수 있습니다.

우수한 소프트웨어는 다음 두 가지에서 비롯됩니다.

• 고객에게 필요한 것을 제공

• 전문가되기

소프트웨어를 개발할 때 따라야 할 모든 종류의 원칙이 있습니다. 고객 요구 사항과 관련이없는 건조, 읽기, SOLID 등 고객이 스포츠카를 요청했습니다. 고객이 스포츠카를 멋지게 만드는 데 필요한 것을 이해했다면 필요하지 않을 것입니다. 무엇이 더 중요한지 알아내는 것은 당신에게 달려 있습니다.

우리의 임무 중 하나는 문제가 심각하게 잘못되지 않는 한 고객이 경험하지 않는 표준을 유지하는 것입니다.

당신이 그것을 올바르게하고 있다면 민첩성은 고객이 실제로 원하는 것만 피아트로 향하는 경향이 있습니다. 그것이 그들이 해결해야 할 것이 아닐 때는 아닙니다.

폭포는 다릅니다. 일단 하이 엔드 스포츠카 요구 사항에 대한 오해가 정착하기 시작했기 때문에 다릅니다. 애자일은 새로운 정보를 처리하고 실제로 필요한 것이 총알 자전거 인 경우 적응할 수 있습니다.

폭포는 오늘날까지 많은 상점에서 여전히 사용되고 있습니다. 이 상점은 요구 사항이 1 년에 2 % 미만으로 바뀌기 때문에 성공합니다.

고객이 원하는 것을 고객에게 제공하는 것이 아닙니다. 또한 크레딧을 전혀 얻지 못한다는 것을 잘 알고 있어야합니다. 당신이 끔찍하게 잘못하지 않으면 고객이 결코 자라지 않을 것입니다. 이러한 것들이 더 잘 선택되었거나 시간 낭비로 많은 쓰레기가 필요합니다.

모든 바보는 무제한 예산으로 다리를 만들 수 있습니다. 전문가는 간신히 넘어지지 않는 다리를 만듭니다.

그러므로 필자는 필수 요건에 노예로 집중해서는 안된다고 생각합니다.

물론 이죠 당신의 시간을 추정 할 때를 제외하고. 이러한 필수 요건이 유일한 고려 사항이 아니기 때문입니다.

승인,

Agile에서 프로그래머는 소프트웨어를 만들 수 있지만 결국 제품을 만드는 것은 제품 소유자입니다. (소프트웨어 개발자를 사용하여)

"매력적인 특성"은 제품 소유자에게 달려 있습니다.

제품 소유자가 "섹시한 디자인"을 요구하는 경우 요구 사항이 될 수 있습니다. 개발자는 이러한 선택에 대해 걱정할 필요가 없습니다.

또한 소프트웨어는 실제 물리적 제품과 매우 다르므로 많은 카노 모델이 적용되지 않는다고 생각합니다. 예를 들어 왜 페이스 북을해야합니까? 유일한 이유는 : 친구들이하기 때문입니다. 다음 스프린트에 넣는 방법 ........ 또한 소프트웨어에서 가장 매력적인 특성 중 하나는 실제로해야 할 일을 수행한다는 것입니다. (그리고 그것이 애자일이 많은 것을 돕는 곳입니다 : P)

저의 경험은 위의 의견에 동의합니다. 우수한 소프트웨어 개발을 방해하는 Agile 고유의 것은 없습니다. 그러나 Agile이 (실용적으로) 실행되는 방식에는 몇 가지 측면이 있습니다. "

• 애자일은 점점에 역점을두고 뭔가 빨리 작업을; 그러나 이는 특히 사용자가 볼 수없는 인프라에서 가정을 단순화하고 모퉁이를 줄이는 것을 의미합니다. 단순화 가정을 수정하는 비용이 낮 다면 본질적으로 잘못된 것은 없습니다 . 그러나 종종이 "기술 부채"는 제품이 생산되기 전에 제거되지 않습니다.
• 애자일은 스프린트가 끝날 때 항상 배송 할 수있는 것에 가까운 물건을 가져야하므로 이해 관계자와 프로젝트 관리자는 "가지고있는 것"이 ​​충분하다고 결정할 수 있습니다. 생산. 다시 말하지만, 이것에 본질적으로 아무런 문제가 없다면당신은 모든 "기술 부채"를 소거했습니다. (또는 당신이 가진 곳과 장소를 평화롭게 만들었습니다.) 그러나 내 경험상 너무 많은 기술 부채가 관리자의 약속으로 생산에 들어갑니다. "출하 압력이 사라지면 청소할 것"으로 빠르게 "생산 중이며, 우리가 지금 무엇을 바꾸어야하는지 매우 조심해야합니다", 결국 "노출이 있다고 말한 적이 없습니다! 다음에 더 나은 일을해야 해요! " "저가의 단맛을 잊은 후에도 품질이 좋지 않은 쓴 맛이 오래 남아있다"는 Ben Frankin의 교훈은 결코 배우지 못한 것 같습니다.
• 그러나 신뢰할 수있는 관리자 및 잘 훈련 된 개발자의 경우에도 구현이 시작되고 완료 될 스프린트가 시작 되기 전에 적절한 분석, 설계 및 설계 검토 가 너무 적다는 일반적인 문제가 있습니다. 신중하게 대안을 고려하지 않은UI 은유와 디자인은 크다-프로젝트가 시작된 후에는 이것을 상당히 많이 수정한다. 주니어 팀이 경쟁 제품을 신중하게 연구하지 못하거나 I18N, 알림 프레임 워크, 로깅, 보안 및 API 버전 관리 전략 (예 :)과 같은 인프라 기술의 정의 및 구현의 우선 순위를 지정하지 않으면 궁극적으로 버그가 더 높아집니다. 필요한 교육, 분석, 디자인 및 프로토 타이핑을 수행하는 데 처음 2-5 스프린트를 미리 사용한 경우보다 생산성이 떨어지고 기술 부채가 더 많이 발생합니다. 요컨대 애자일 팀은 해킹 할 라이센스에 저항해야합니다.
• 필자는 개발자에게 계획 수준의 설계를 가장 기본적인 수준으로 작성하는 데 시간을내는 것을 권장하지 않은 2 차 수준의 관리자 (100 명 이상의 개발자)를 보유하고 있습니다. 그의 추론은 "사람들이 서로 대화하기를 원한다"는 것입니다. 그들은 5 개의 다른 시간대와 3 개의 국가에 있었기 때문에 아이러니했습니다. 말할 필요도없이, 모든 팀이 다른 사람 이 어떤 기능을 구현할 책임이 있다고 생각하면 프로젝트 후반에 많은 밤과 주말을 일해야 할 지에 대한 많은 지적이있었습니다. 공급 업체 및 소비자의 디자인이 메시되지 않았기 때문에 다시 구현)

프로젝트 관리자와 이해 관계자 가 고품질의 제품을 제공하기를 원하는지 여부는 매우 중요합니다 . 그들이 그렇게하겠다고 약속하면 애자일은 그것을 가능하게 할 것입니다. OTOH는 Agile이 일정 결정을 이해 관계자 및 프로젝트 관리자에게만 제공하기 때문에 개발 팀이 지원없이 우수한 프로젝트를 제공하기가 어렵습니다. 한마디로 : 제품 품질에 대한 책임은 전적으로 프로젝트 관리자의 발자취에 있습니다.

TL; DR

실제로 민첩한 개발을 통해 소프트웨어 품질을 높이고 고객 만족을 유지하며 가치있는 제품을 제공 할 수 있습니다.

몇몇 똑똑한 사람들이 전통적인 프로세스에서 많은 소프트웨어 프로젝트가 직면하는 문제를 해결하기 위해 민첩한 개발을 도입했습니다.

애자일 선언문 (1) 에서 정의한 애자일 개발의 핵심 가치는 다음과 같습니다.

• 프로세스 및 도구에 대한 개인 및 상호 작용
• 포괄적 인 문서에 대한 작업 소프트웨어
• 계약 협상을 통한 고객 협업
• 계획에 따라 변경에 응답

따라서 민첩한 개발로 고품질 소프트웨어를 만들 수 없습니다. 민첩한 개발을 통해 고품질 소프트웨어를 제공 할 수 있습니다.

그러나 우리 (및 고객)는 항상 필수 요구 사항이 무엇인지 미리 알고 있습니까?

그게 요점입니다. 개인, 고객, 작업 소프트웨어 및 요구 사항 변경에 집중함으로써 민첩한 개발을 통해 최종 제품이 제공되기 전에 고객이 원하는 것을 파악할 수 있습니다.

이것이 스크럼과 같은 민첩한 프레임 워크가 짧은 반복주기를 가져서 결과가 제품으로 작용하는 이유입니다. 고객의 기대에 대비하여 초기 단계에서 작업을 이미 검증하고 요구에 따라 목표 / 요구 사항을 조정할 수 있습니다. 민첩한 개발을 통해 제품 의 필수 품질 을 실현할 수 있습니다 .

과거에는 여전히 그렇습니다. 오늘날에도 마찬가지입니다. 전통적인 접근 방식으로 개발 된 많은 소프트웨어 프로젝트가 실패했거나 성공하지 못했거나 고객이 불쾌감을 주어야합니다 .

또한 민첩한 개발을 통해 매력적인 품질 에 도달 할 수 있습니다 . 각 반복 후에 제품을 반영하면 프로젝트를 시작할 때 고객이 관심을 갖지 않은 새로운 요구 사항이 매력적으로 나타납니다 (매력적인 품질). 이를 통해 고객은 만족합니다.

또한 카노 모델 의 역 품질 -불만족스러운 속성-에 대해서도 언급하고 싶습니다 .

모든 프로젝트에는 프로젝트 시작시 좋은 아이디어 인 요구 사항이 있습니다. 잠시 후 그들은 반대로 바뀌고 실망을 일으켰다.

전통적인 소프트웨어 개발 프로세스에서는 장기 프로젝트 실행 후 최종 제품에서 이러한 요구 사항을 인식하게됩니다. 고객 실망을 피하고 후속 프로젝트를 변경하려면 너무 늦습니다.

민첩한 개발을 통해 작동하지 않거나 불만족스러운 요구 사항을 조기에 식별하고 프로젝트 중에 요구 사항을 변경할 수 있습니다.

앞서 언급했듯이 민첩한 개발은 소프트웨어 품질을 높이고 고객 만족을 유지하며 가치있는 제품을 제공하는 데 도움이됩니다.

나는이 파티에 늦었지만이 주제에 대해 다른 견해를 나누고 싶습니다.

그러나 필수 요구 사항을 거의 충족시키지 못하는 최소한의 수준이 아니라 유쾌한 고품질 소프트웨어 제품을 만드는 데 어떻게 적용 할 수 있습니까?

민첩한 소프트웨어 개발 에는 민첩한 방법론의 두 가지 중요한 요소 인 반복적 인 접근 방식 과 고객 피드백을 고려한 일시적인 측면 이 있습니다 . 예 : 반복 t에서 매력적인 품질 로 식별되는 기능 은 다음 반복 t + 1에서 필수 품질이 될 수 있습니다 .

민첩한 방법을 적용하면 기능의 품질 범주를 동적으로 변경할 수 있습니다. 반복의 계획된 기능 t와 이후의 반복 t + n의 완성 된 기능을 비교하면 정확히 언급 한 내용을 경험하게됩니다.

처음에 우선 순위가 높은 요구 사항이 나중에 쓸모 없지는 않지만 훨씬 덜 중요하다는 사실을 몇 번이나 경험했습니다.

이러한 일시적인 측면을 염두에두고 민첩한 방법 으로 최소한의 품질 에만 집중 하면서도 고품질의 고품질 소프트웨어 제품 을 생산할 수 있다는 것은 타당합니다 . 반복적 인 접근 방식 과 짝 고객의 피드백은 시간이 지남에 따라 게임의 규칙을 변경합니다.

결론

민첩한 방법으로 우수한 소프트웨어를 개발하는 방법은 무엇입니까?

반복적 인 접근 방식을 적용하고 고객 의견을 경청 하십시오 . 이러한 요소 중 하나를 버리고 덜 성공적인 형태의 민첩한 소프트웨어 개발을 얻게됩니다.

   > How to develop excellent software with agile methods?

• 고객 별 개별 소프트웨어 제작시 :
  • "유쾌한"기능은 추가 비용이 들기 때문에 비용이 중요하지 않은 고객을 찾고 고객은 이에 대한 지불 여부를 결정해야합니다.
• 소프트웨어 제품을 생산할 때 :
  • "유쾌한"기능은 신규 고객을 유치하기에 좋고 제품을 1000 회 이상 판매 하는 경우 "유쾌한"기능을 구현하는 비용은 그다지 중요하지 않습니다 .
• "충분히 좋은 (최고) 좋은"환경에서는 "유쾌한"기능을 구현할 돈이 없습니다.

Scrum 팀에서 제품 소유자는 구현할 기능을 선택해야합니다. 따라서 "충분한"또는 "우수한"소프트웨어를 정의하는 것은 그에게 달려 있습니다.

당신은 좋은 점수를 올립니다. 그러나 이러한 문제가 민첩한 프로세스 / 방법론으로 제한되어 있다고는 생각하지 않습니다.

필수 기능과 비 필수 기능에 대한 의견이 다릅니다. 귀하의 예를 사용하기 위해 자동차를 구매하는 사람은주의를 끌기위한 필수 기능으로 간주하여 피아트가이 필수 요건을 충족하지 않는 것으로 간주 할 수 있습니다.
보다 현실적으로 소프트웨어 제품에는 실제 최종 사용자의 요구를 충족시키기 위해 특정 기능이 필요할 수 있지만 판매를 위해서는 특정 기능이 필요할 수도 있습니다. 구매를 승인 한 사람은 종종 최종 사용자가 아니기 때문입니다.
따라서 최종 사용자에게 "필수적이지 않은"기능은 제품을 판매하는 데 필수적 일 수 있으며 따라서 제품을 만드는 회사에도 필수적입니다.

요구 사항과 우선 순위를 적절하게 설정하려면 우수한 제품 개발 팀을 보유하는 것이 중요하다는 사실로 요약됩니다. 그러나 민첩한 상점에만 해당되는 것은 아닙니다.

또한 결정을 내릴 권한이있는 제품 소유자 (들) / 이해 관계자가 있어야합니다. 귀하의 제품 소유자의 결정이 다른 사람에 의해 지속적으로 무효화되는 경우, 이것이 문제라는 점에 가장 먼저 동의하지만, 민첩한 문제는 아닙니다.

당신이 당신의 제품 소유자 (들)에게 원하는 다른 것들이 있습니다 ... 제가 들었던 한가지 설명은 "CRACK"(협업, 대표, 승인, 헌신, 지식)입니다. 이러한 영역이없는 제품 소유자는 프로젝트에 문제를 일으킬 수 있습니다. 그러나 처음에는 폭포 환경 에서이 약어를 들었으므로 나쁜 고객 / 제품 소유자의 고통은 민첩한 상점에만 국한되지 않습니다.

민첩하게 할 수있는 일은 이러한 문제 중 일부를 표면에 가져 오는 것입니다.

예를 들어, XP 문헌은 "고객"이 지식이 있고 팀이 액세스 할 수 있으며 의사 결정 권한이있는 것에 대해 IIRC에 상당히 명시되어 있습니다. "제품 소유자"라는 용어는 어느 정도의 지식, 약속 및 권한을 의미합니다.

제공되는 기능의 대부분이 필수 기능이 아닌 즐거움으로 구성되는 상황에 처한 경우, 작업 소프트웨어 또는 거의 작동하는 소프트웨어를 제공 할 때마다 해당 문제를 제기하는 것이 훨씬 쉽습니다 (원인을 쉽게 파악할 수 있음) 수개월 또는 수년 간격으로 배달하는 것보다 2-3 주가 소요됩니다.

소규모 반복 작업을하고 백 로그를 자주 검토하는 경우 (우선 순위 재검토 포함) 팀이 이전 실수로부터 배울 수있는 기회를 제공합니다. "이것은 지금 정말 중요하다고 생각하지만, 우리가 결국에는 사용하지 않았어야한다고 확신했던 동적 탐색을 기억하십니까?" 다른 사람들이 지적했듯이 모든 것이 미리 계획되어 있다면 그러한 토론은 훨씬 적습니다.

대조적으로, 선행 설계 방법론은 기본적으로 제품 및 기능에 대한 이해가 정적 인 것으로 가정합니다. 그것은 내 경험이 아니었다 : 거의 항상 함께 일할 수있는 무언가를 갖는 것은 사업 사람들의 문제에 대한 이해를 변화시킨다. 따라서 빠른 피드백에 중점을 둡니다. (개발자의 이해도 변경되지만 우선 순위에는 영향을 미치지 않습니다.)

계획 중 일부를 연기하면 비즈니스 요구 사항의 변화에 ​​대응할 수도 있습니다. "당신은 당신이 구축하고있는 웹 사이트를 알고 있습니까? 우리는 운영을 끊을 수있는 모바일 앱이어야합니다." 이것은 특별히 묻지 않은 것이 아니지만 프로세스가 비즈니스 환경의 변화 (적어도 이론적으로)에 대응할 수 있기를 원하지 않습니까?

애자일은 "필수 기능을 구축하지 마십시오"라고 말하지 않습니다. "비즈니스가 어떤 기능 (구체적으로)을 구축할지 결정할 수 있도록 허용"이라고 말합니다.
... 그리고 (똑같이 중요한) "기술자들이 원하는 기능을 구축하는 데 걸리는 시간을 알려줄 수 있습니다".

1. Must-be qualities종종 결정하기가 어렵습니다. 사람들은 그들을 양심에 두었습니다. 민첩한 반복 및 클라이언트 참여는 대부분의 필수 항목을 찾는 데 도움이됩니다. 그것이 민첩의 힘이며 그것을 무시하는 것은 어리석은 일 입니다.
2. One-dimensional qualities즉, 이행해야 할 약속은 변경되지 않을 때까지 폭포 OK로 지원됩니다. 민첩한 것이 도움이되지만 강력하지는 않습니다.
3. Attractive qualities좋은 기능입니다. 그들은 다음 세대의 필수 아이템이 될 수 있습니다. 그러나 현재 세대에서 그들은 심지어 계약에 있지도 않습니다. 고객 대표 참여가 이러한 특성을 매우 잘 지원한다고 가정하는 민첩한 방법입니다. 작업 중에 스코프를 가볍게 변경할 수 있습니다. 한 곳에서는 다른 곳에서는 약간의 보상으로 개선에 대해 협상 할 수 있습니다. 폭포에서는 실제로 불가능합니다. 큰 조직 지연 없이는 기능 만 무료로 추가 할 수있었습니다. 여분의 시간이 이미 예산에 들어간 경우 가능합니다.

따라서 민첩한 프로세스는 카노 모델을 지원할 수 있으며, 일부 모델은 최고의 폭포 프로젝트보다 훨씬 뛰어납니다.

이해를 크게하려면 책임있는 고객 담당자와 민첩한 프로세스를 설정해야합니다.