고객의 개입 없이도 민첩성을 달성 할 수 있습니까?

Agile에 관한 책을 쓸 수 없었습니다. 나는 그들의 프로세스를 애자일이라고 부르는 여러 상점에서 일했습니다. 애자일 개발의 주요 포인트 중 하나는 정기적 인 고객 참여입니다. 스프린트 후, 작업을 클라이언트에게 데모하여 피드백을 얻을 수 있습니다. 헹구고 반복하십시오.

내가 겪는 문제는 많은 고객들이 관여하고 싶지 않다는 것입니다. 그들은 폭포 접근 방식을 훨씬 선호합니다. 요구 사항을 미리 수집 한 다음 완료되면 다시 돌아옵니다. 내 경험상 폭포가 작동하지 않습니다. 고객은 그들이 볼 때까지 원하는 것을 모릅니다. 워터 폴 딜레마는 모든 요구 사항을 미리 알고 싶어하는 대규모 개발자 커뮤니티에 의해 더욱 전파됩니다. 이런 식으로 그들은 무엇을 구축하고 있는지 알 수 있고, 그에 따라 설계 할 수 있으며, 고객은 해당 요구 사항에 "사인"했기 때문에 비난을받습니다.

내가 틀렸어? 고객의 개입 없이도 민첩하게 작업 할 수 있습니까? 그렇다면 내가 논의한 문제를 어떻게 그리고 어떻게 극복 할 수 있습니까?

어떻게 할 수 있습니까? 이 기술의 본질은 고객과 개발자 사이의 일종의 피드백 루프를 나타냅니다.

그러나 팀의 일부는 "프록시"고객 ( "자신의 개밥을 먹는"과 유사한 프로세스)으로 작동하여 실제 고객을 얻는 것만 큼 만족 스럽지는 않지만 "민첩한 척"할 수 있습니다. 피드백.

좋든 싫든 고객은 디자인 프로세스에 참여하게됩니다. 재 작업 비용이 얼마나 드는지에 대한 문제 일뿐입니다 (지연이 길수록 비용이 많이 듭니다).

고객이 "Big Design Up Front"를 원하기 때문에 처음으로 디자인을 얻는 데 더 많은 시간과 노력이 필요하다는 것을 이해하도록 도와주십시오.

귀하의 질문에 대한 짧은 대답은 '아니요'입니다. 다음은 질문의 일부에 대한 의견입니다. 대부분의 답변은 제 개인적인 경험과 관찰에 근거합니다.

내 경험상 폭포가 작동하지 않습니다.

Waterfall은 다양한 복잡성의 시스템을 제공하기위한 올바른 방법입니다. 불행히도 잘 제시되거나 이해되지 않습니다. 그 이유 중 하나는 계속해서 나타나는 오늘날의 방법론과 경쟁하여 충분한 돈을 벌지 못하기 때문입니다. 많은 은행, 보험 및 제조 시스템이 워터 폴 방식으로 만 제작되었으며 오늘날에도 여전히 생산되고 있다는 사실에 놀랄 것입니다. 소프트웨어 산업이 과학 이상의 과대 광고에 기반을 둔 것은 슬픈 일입니다.

고객은 그들이 볼 때까지 원하는 것을 모릅니다.

이것은 신화입니다. 큰 것도. 이것은 웹 페이지 디자인 / 레이아웃의 경우 일 수 있지만 비즈니스 데이터 처리의 경우 대부분의 사용자는 작동하는 것을 원합니다. 이러한 사용자 중 일부는 여전히 AS / 400 화면과 3270 CICS 모니터를 RGB와 함께 사용하며 해당 도구를 사용하여 비즈니스를 수행 할 수 있습니다. 또한 동일한 사용자는 인터페이스 디자인 (및 일부 기능성)에 대한 언급없이 SAP 및 ORACLE ERP 시스템을 수용합니다. 대부분의 비즈니스 사용자는 시스템이 올바른 기능을 생성하는 경우 작업 습관과 흐름을 조정합니다. 여기서 스트레스는 보이지 않는 기능입니다. 비즈니스 사람들은 업무 시간의 90 %를 어떻게 잘 수행하는지 이해합니다.

워터 폴 딜레마는 모든 요구 사항을 미리 알고 싶어하는 대규모 개발자 커뮤니티에 의해 더욱 전파됩니다. 이런 식으로 그들은 무엇을 구축하고 있는지 알 수 있고, 그에 따라 설계 할 수 있으며, 고객은 해당 요구 사항에 "사인"했기 때문에 비난을받습니다.

개발자가 집에서 저녁 식사를하고 3 시간 정도를 보낸 후 다음 기술을 배우고 나서 다른 훈련을 위해 셔츠를 누르기를 원하기 때문에 개발자가 무엇을 만들고 있는지 알고 싶어한다고 개발자를 비난 할 수 없습니다. 현재 스킬 세트를 대체합니다! 비난 게임은 아무도 승자가 아닙니다. 각 당사자의 역할과 책임의 관점에서 생각하면 사진이 매우 명확합니다.

결론적으로, 프로젝트 관리자, 프로그래머 및 웹 디자이너는 방법론에 관계없이 최종 사용자로부터 요구 사항을 수집하는 방법을 알아야하는 비즈니스 분석가를 대체하지 않습니다.

그들은 시간을 내고 싶지 않으며, 선택권이 주어지면 오히려 무료로 소프트웨어를 얻는 것이지만 여전히 청구 할 것입니다. 회사 내부에서 소프트웨어를 개발하는 경우에는 문제가 해결되지 않습니다. 그들은 IT 부서가 (임직원) 구매 및 지불되었다고 생각하므로 가능한 한 많은 작업을 수행 할 수 있습니다.

잠재적으로 민첩 할 수 있습니다. 모든 사양을 확인하고 코딩을 시작하십시오. 클라이언트가 진정 무언가를 생각하고 작업을 중단하고 변경하고 재 작업해야하는 경우 조금 더 민첩 해집니다. 팀 내에서 승인을 수행 할 수도 있습니다. 팀원 중 한 명이 양복을 입고 넥타이를 씌우고 고객 인 척하십시오.

많은 시간을 앞두고 노력하면 두려워 할 수 있습니다. 스프린트를 시도해보십시오. 그런 다음 거부 할 수있는 기회를 제공하십시오. 프로젝트의 나머지 부분에서는 언제든지 폭포수로 이동할 수 있습니다. 또한 수표를 작성하는 사람에게 시간이 제약이되면 팀의 다른 사람들이 검토를 수행하고 승인 할 수 있다고 제안합니다.

어떤 시점에서는 폭포가 작동하지 않는다고 생각해야합니다. 그들이이 접근 방식에 만족했는지 물어보고, 그렇다면이 프로젝트를하는 마지막 사람이없는 이유는 무엇입니까?

클라이언트 개입 없이는 방법론을 사용할 수 없습니다. 내가 참여한 프로젝트에서 목격 한 것처럼 요구 사항에 대한 승인은 의미가 없습니다. 당신의 문제는 애자일을 할 수있는 것 이상으로 고객을 교육하고 그들이 참여하는 것이 얼마나 중요한지 이해해야합니다.

Agile의 주요 이점 중 하나는 각 기능에 대해보다 자세한 요구 사항을 얻는 기능이라고 생각합니다. 클라이언트가 모든 요구 사항을 사전에 제시 할 때 각 기능은 약간의 기능이 정의 된 모호한 아이디어 인 경향이 있습니다. 애자일은 클라이언트가 각 기능을 다시 방문하여 원하는 기능과 기능이 더 큰 그림에 어떻게 적용되는지 정확하게 집중 하도록합니다. 이 같은 양의 디테일 (기능을 구현하기에 충분한 디테일)을 스펙에 가져 오려면 Waterfall은 실제로 다음 두 가지 중 하나를 수행해야합니다.

1. 추측. 모호한 무언가가 나올 때까지 구현 한 다음 해당 기능이 가장 잘 구현 될 것이라고 생각하는 방법을 판단하십시오. "잠깐만 요, 그건 내가 요청한 것이 아니에요!" 대본.

2. 디자인을 우선적으로 강조합니다. 기본적으로 고객이 첫날에 반 베이크 스펙을 던질 때, 구현하기 전에 모든 세부 사항을 살펴볼 계획입니다. 명확히하기 위해 클라이언트를 물어 모든 것을 당신이 전체 프로젝트에 대한 모든 구현 세부 사항을 알고있는 지점에 광고 nauseum를. 완벽하지는 않지만 옵션 1보다 낫습니다. 예상치 못한 세부 정보가 계속 표시 될 수 있으며 고객이 언덕을 향해 달리는 경우도 있지만 실제로 개발 및 커뮤니케이션 중에 의사 소통을 원하지 않으면 심령 적이 지 않습니다. 이것은 필수입니다. 이것은 기본적으로 폭포이며 제대로 실행하기가 매우 어렵다는 것을 포함하여 관련된 모든 단점이 있습니다.

3. 반 구운 사양을 사용하되 어쨌든 설명을 요청하십시오. 사양의 모호한 부분에 도달 할 때까지 작업 한 다음 고객에게 설명을 요청하십시오. 물론, 이것은 클라이언트가 요구 한 것이 아니지만, 사양처럼 어두운 애플리케이션을 원치 않고 사양을 미리 정의하지 않으려는 경우 남아있는 옵션 중 하나입니다. 애자일의 모든 이점을 누릴 수는 없지만 (예 : 모든 사람이 같은 페이지에 있도록 정기적 인 고객 승인) 개발에 필요한 정보를 얻을 수 있습니다. 옵션 1은 아마도 하위 제품을 남길 수 있기 때문에 옵션 2는 낭비 적이며 고객에게 실망 스러울 것입니다. 이것은 실제로 그렇게 나쁜 옵션은 아닙니다. 여기서 핵심은 각 변경 사항에 따라 타임 라인과 가격을 수정하는 데 부지런해야합니다. 올바르게 수행하면 클라이언트가 알지 못하더라도 대부분의 애자일 프랙티스가이 배열과 호환되는 것을 알 수 있습니다. IMHO, 이것은 실제로 애자일의 정신에 부합합니다. 즉, 방법론을 특정 배열에 맞게 조정해야합니다.

고객이이 세 가지 옵션 중 하나 또는 완전한 애자일의 결과로 실제로 살 수 없다면, 나는이 고객이 어떻게 당신의 가치를 실제로 누릴 수 있는지 상상하기가 어렵습니다.

나는 어렵지만 여전히 가능하다고 생각합니다. Robert의 대리 아이디어가 효과가 있다고 생각하지만 대리자가 '실제'클라이언트와 최대한 많은 시간을 보내야 관점에서 사물을 볼 수 있어야합니다. 이런 식으로 프록시는 어떤 기능이 실제로 중요한지 확인하고 고객이 기대 / 바람하는 사용자 경험을 느낄 수 있습니다.

그러나 어느 시점에서 소프트웨어를 '실제'클라이언트에게 보여줘야합니다.

실제 고객을 피하는 것이 가능하며, 때로는 규제에 필요합니다. 일반적으로 의료 소프트웨어 고객은 관여하지 않습니다. 이러한 경우 다른 엔티티가 고객 역할을 대체 할 수 있습니다. 예를 들어 마케팅 팀은 고객으로 간주 될 수 있습니다.

애자일은 단단하고 큰 전면 디자인을 대체하기 위해 단단한 루프가 필요합니다. 아주 단단하지만 실제로는 가능합니다. 애자일 만이 유일한 방법은 아닙니다.

Agile의 수정 사항 중 하나를 찾고 싶을 수도 있습니다.이 특정 문제를 해결하는 방법이 많을 수 있지만 가능하다고 생각되면 스스로 구성하지 않는 경우가 있습니다.

이러한 모든 프로세스는 똑똑한 사람들이 구성했으며 똑똑한 사람들은 모든 프로세스를 수행 할 수 있습니다. 폭포는 아무도 당신을 위해 일한 적이 없기 때문에 발명되었다고 생각하지 않습니까? 일부 사람들은 그것이 효과를 발휘할 수있게 되었기 때문에 진화했고 다른 사람들은 "그것을 개선하고 효과적으로 생산할 수없는 팀에게 공급해야한다"고 말했다. 모든 프로그래머가 모든 문제를 해결할 수있는 것은 아니라는 점을 인식하지 못하면 동일한 프로세스를 사용하는 두 팀이 서로 다른 결과를 얻을 수있는 이유가 무엇일까요?

문제는 많은 프로세스가이를 구현하기 위해 인재를 필요로한다는 것입니다. 우리는 스포츠를 해 본 모든 사람의 풀에서 프로 스포츠 선수처럼 드문 재능을 이야기하고 있습니다. 폭포수 작업과 같은 엉터리 프로세스는 많은 사람들이 성공할 수 없다고 생각하는 이유입니다.

애자일을 작동시키는 데 훨씬 적은 재능이 필요하지만, 고객이 지속적으로하고있는 일을 살펴보고 오류가 전파되지 않도록하기 위해, 그리고 무자비한 리팩토링과 같은 매우 구체적인 투자가 필요합니다. 몇 달 동안 팀이 풀 수없는 기술적 부채.

고객을 정의하십시오.

다른 회사입니까? 다른 개인?

회사 내의 다른 팀입니까?

회사 내 제품 챔피언입니까?

당신인가요?

위의 모든 것이 가능하며 상황에 따라 상당히 합리적입니다. 애자일 (Agile)이 무엇인지에 대해 터널을 한눈에보고 싶지 않기 때문에 결정적인 NO 가 부정확 하다고 말할 수 있습니다. 반면에 그렇습니다 .

애자일 이라는 단어 를 잠시 생각해보십시오 . 이 용어를 만든 매우 영리한 사람들은 설명하려는 개념에 대해 더 나은 은유를 고를 수 없었습니다. 민첩성 이라고 말하면 무엇이 떠오 릅 니까? 발의 함대? 아마 빠른 반응? 적응이 빠르신가요?

이제 일반적으로 받아 들여지는 Agile 사례를 모두 생각해보고 Agile 로 간주되는 소프트웨어 개발 방법에 실제로 어떤 것들이 있는지 물어보십시오 .

나는 솔로 프로젝트를위한 모든 의도와 목적을 가진 고객입니다. 고객 역할을 뚜렷하게 바꾸고 싶을 때 가끔 모자를 쓰고 싶기도합니다 . 이것은 내가 일할 때보 다 민첩하게 만듭니다. 내가 돌보는 모든 것에 대해 내 고양이는 관리자 가 될 수 있습니다. 그는 내가 가끔 휴식을 취하도록하고, 어떤 일에도 너무 집착하지 않도록 상기시킨다. 당신은 당신의 멋진 "Pomadoro Technique"을 선호하지만, 나는 "Rascal"Timer를 선호합니다 !! 문제는 내가 직접 코드를 작성할 때마다 엄격하게 민첩한 프로세스로 작업한다는 것입니다. 나는 끝없는 개발 스파이크의 삶을 살고 아무것도 달성하지 못하는 해커 온 카우보이 유형이 아닙니다. 저는 소프트웨어를 제작하고, 직장과 개인 생활을 중심으로 개발 일정을 정하고, 실제 고객을 위해 일할 때 기대할 수있는 방식으로 소프트웨어를 완성하고 싶습니다. 일이 스케줄을 방해 할 때 프로젝트 작업을 적절히 조정하고 우선 순위를 정합니다. 솔로를 적용 할 수있는 모든 표준 민첩한 관행과 기술을 사용하며 "제공" 가능한 한 자주 나 자신 (또는 테스트 할 친구 또는 동료)에게 코드를 작성하십시오. 이 모든 것이 민첩하지 않다면 나는 무엇인지 묻습니다.

제 대답은 예입니다 . 애자일 소프트웨어 개발자가 될 수 있으며 애자일 방법론을 적용 할 수 있으며 고객이나 관리자가 반드시 필요한 것은 아닙니다. 혼자서 프로젝트를 수행하고 여러 모자를 쓸 수 있습니다. 그러나 목표를 달성하기 위해 다른 사람들과 협력하는 것이 매우 도움이되기 때문에 다른 역할을 없애는 것이 이상적 이지 않을 수도 있습니다 . 그것들은 당신의 아이디어를위한 건전한 보드 역할을하며, 스스로 스스로 현명하게 생성하기 어려운 요구 사항을 제공합니다. 고객과 관리자가 만족시키는 또 하나의 중요한 역할은 끝없이 기능을 추가하고 엄격하게 필요한 것 이상으로 코드를 수정하지 않고 목표에 계속 집중하는 것입니다.

그럼에도 불구하고, 훈련 된 방식으로 일하고, 선택한 방법론을 엄격하게 고수하고 민첩한 관행을 적용하고, 부주의하게 추적하거나 마음이 바뀌는 경우 (고객 모자 착용시)와 제품 디자인 또는 방향 일정을 조정하고 고객이 기대하는대로 우선 순위를 조정할 수 있다면 민첩하게 행동합니다.