카우보이에게 민첩한 접근 방식이 너무 편리한 변명인가?

민첩한 접근 방식이 요구 사항이 모호하고 최종 사용자의 아이디어를 형성하는 데 많은 상호 작용이 필요한 프로젝트에 가장 적합하다고 생각합니다.

그러나 ... 저의 전문적인 업무에서, "애자일 (agile)"접근 방식이 왜 선결제 디자인에 노력을 기울이지 않았는 지에 대한 변명으로 사용되는 회사에서 계속해서 끝납니다 . 요구 사항이 잘 이해 될 때

민첩한 접근 방식이 없다면 여기에 멋진 고급 사양으로 앉아 있고 다른 무언가가 자랄 때마다 두 번째 날마다 동일한 화면과 기능을 다시 방문하지 않아도 될 것이라고 생각합니다. 그렇게 생각하지 않았습니다.

민첩한 방법론의 이점이 카우보이 기술 책임자에게 불충분하다는 변명을 능가 할만큼 충분한가?

업데이트 : 아이러니하게도 저는 현재 인증 된 스크럼 마스터입니다. Scrum 과정에서 발표 된 논문 중 하나는 최고의 개발 프로세스가 설계 결정을 내리는 단일 전문가 또는 전문가가 있었지만 명백한 약점이 있다는 것이 었습니다. 스크럼은 품질 소프트웨어를 생산하는 책임을 "팀"으로 옮겼는데, 이는 하위 표준 팀이 다른 애자일 및 비 애자일 개발 프로세스와 다르지 않은 스파게티를 제거 할 수 있다는 것을 의미합니다.

카우보이 스타일 프로그래밍의 변명으로 애자일 개발을 사용하고 있다면 실제로 애자일 개발을 따르지 않는 것입니다. 카우보이는 당신이 어떤 프로세스를 주더라도 항상 카우보이가 될 것입니다.

애자일은 BDUF보다 열악한 개발 관행을 더 이상 비난하지 않습니다. 문제는 관행을 적용 할 때의 규율 또는 부족에 있습니다. BDUF 실무의 목적은 프로젝트의 방향을 파악하고 사전에 위험을 결정하는 것입니다. 민첩한 관행의 목적은 신속하게 방향을 바꿀 수 있도록 개발 상태를 유연하게 유지하는 것입니다. 민첩한 프로젝트는 세부적인 사용자 스토리를 준비 할 수 있으므로 팀은 미래의 방향을 알고 여전히 완전히 구현하기 위해 반복 당 2 또는 3 만 선택합니다. 문제는 어떤 방법론을 사용하든 동일하게 유지됩니다. 경영진은 카우보이가 멍청하게 행동하게합니다.

[BDUF : 빅 디자인 업 프론트]

애자는, 같은 어떤 나쁜 행동을 다루거나 팀들이의 책임을지지 않습니다 생각 문제를 해결하려고 할 수 있습니다.

그러나 스크럼 과 같은 일부 애자일 방법론 의 마법 은 조직 내 문제에 대한 많은 가시성을 제공한다는 것입니다. 팀 내에서 문제를 포함!

그러면 문제가 발생할 때이를 해결할 수있는 기회가 주어집니다.

카우보이에게 문제가 있다면, 이것은 첫 번째 반복 후에 매우 잘 보입니다. 문제가 다른 곳에 있으면 곧 나타날 것입니다.

이상하게도, 내가 참여한 "민첩한"프로젝트에서, 단순히 코딩을 시작하려는 카우보이의 요구보다 요구 사항 수집 단계를 건너 뛰는 것은 관리의 변명처럼 보입니다. 우리가하지 않기 때문에 나의 프로젝트는 매우 좌절되었습니다 가지고 와 상호 작용하는 모든 최종 사용자. 대신 영업 담당자와 상담하여 고객이 원하는 바를 파악한 다음 회의에 전화를 걸어 관리자에게 설명하여 관리자에게 작업을 할당하기 시작합니다. "좋은"프로젝트에서는 참조 할 PP 프레젠테이션이있을 수 있지만 일반적으로 일상적인 스크럼 회의에서 일부 기능이 어떻게 작동해야하는지 묻고 관리자는 질문을 작성하고 감독에게 묻습니다. 시간이 많이 걸리지 만 "민첩하다"!

필자는 여전히 실망스러운 스코프를 다루기 때문에 폭포의 팬이라고 말할 수는 없지만 애자일은 항상 문제를 해결하기위한 효과적인 방법이 아니라 문제에 대한 양보로 간주했습니다. 초기 반복 테스트와 많은 종이 프로토 타입을 갖춘 좋은 디자인이 훨씬 더 효과적인 것 같습니다.

나는 애자일 개발 (Agile Development)의 방어가 카우보이로 인한 실패에 대해 책임을지지 않는다고 말하는 것을보고있다. 애자일의 성공에는 부지런함과 지능이 필요합니다.

다른 방법론에 동일한 양보를 적용하는 한 이것은 합리적인 입장으로 보입니다. 카우보이로 인한 프로젝트 실패에 대해 민첩성을 비난 할 수없는 경우 카우보이로 인한 프로젝트 실패에 대해 민첩하지 않은 방법론을 비난 할 수 없습니다.

그런 다음 애자일과 카우보이 사이에 상관 관계가 있는지 (인과 관계 아님!) 논쟁 할 수 있습니다. 일화적인 증거 만 있으면 믿습니다. 경영진에 의해 감지되지 않고 카우보이 관행을 극복하는 좋은 방법으로 인식됩니까?

물론 카우보이가 방법론에 고르게 분산되지 않을 수 있고 카우보이가 프로세스의 성공적인 사용을 훼손한다는 사실을 인정하면 프로세스가 성공적인지 테스트하기가 매우 어려워졌습니다. 하나의 프로세스가 (컨텍스트 내에서) 더 낫다는 주장은 반박 할 수없는 수준에 가깝습니다. 이것은 내 직업에 대해 부끄러워하는 문제 중 하나입니다. 많은 주장에 대한 과학적 근거가 부족합니다.

(어쨌든 폭포 프로세스는 모든 사람이 공격하는 밀짚 꾼처럼 보이지만 실제로 반복없이 사용하는 사람은 거의 없기 때문에 대안을 민첩한 "폭포"라고 부르는 것을 싫어합니다.)

애자일은 팀에서 일하는 한 괜찮습니다.

너무나 많은 사람들이 나쁜 팀을 좋은 팀으로 만들 수있는 방법으로 판매하고 있으며, 그 방법으로는 효과가 없습니다. 나쁜 사람들을 데려 가서 갑자기 유용하게 만드는 과정을 적용 할 수는 없습니다.

나는 민첩성 뒤에 숨은 아이디어를 많이 좋아하지만, 시간과 시간이 또 다시 나타나는 실패는 관리자가 민첩성의 전체 개념에 직면하여 팀이 자제해야한다는 엄격한 "민첩한 프로세스"를 추진하고 있다는 것입니다. 조직.

"카우보이"에 이르기까지, 내가 가졌던 모든 민첩한 팀의 경우 프로세스가 야생화보다 더 느리게 진행되는 것으로 나타났습니다. 애자일 이 "카우보이 코더" 를 가능하게 하는 상황을 경험 한 적이 없습니다 .

좋은 팀의 경우 잘 작동하는 것 같습니다 (다시 말해, 좋은 팀이있을 때 대부분의 프로세스가 잘 작동하는 것 같습니다.

다른 팀의 경우 내 경험상 나쁜 사람들이 더 잘하는 데 도움이되지 않지만 때로는 생산적인 사람들을 망칠 수 있습니다.

전반적으로, 중요한 것은 좋은 팀을 구성하고 필요한 것을 말한 다음 벗어나는 것입니다. 나는 어떤 유행어를 적용해도 나쁜 팀이있는 문제를 해결할 것이라고 생각하지 않습니다.

(위에서 파악하지 못했다면, 나는 "Capitol-A Agile"의 팬이 아닙니다. 반면에, 나는 그것이 카우보이를 격려한다고 생각하지 않습니다.)

민첩하게 제대로 수행되면 "카우보이"기술 리드 및 "영웅"프로그래머의 강화 효과가 있어야합니다. 이 효과를 관찰하지 않으면 민첩한 구현에서 중요한 것이 누락되었다는 신호일 수 있습니다.

"Agile"은 실제로 인터페이스 (여기서는 객체 지향 은유를 사용하고 있음)이며 인스턴스화 할 수 없다고 덧붙이고 싶습니다. 그것의 구체적인 구현이 XP 라면, 많은 프로그래밍으로 많은 기술 관행을 따라야하므로 카우보이 프로그래밍을위한 공간이 거의 없습니다. 또 다른 가능성은 잘 조직 된 스크럼 팀의 팀워크가이를 확인하는 것입니다.

카우보이 코더는 또한 테스트가 쉽지 않은 코드를 작성하는 경향이 있으며 테스트 작성을 좋아하지 않는 경향이 있습니다. TDD를하는 모든 사람이 카우보이의 태도를 지배하는 데 도움이되고 개발자가 아키텍처에 대해 좀 더 생각하게 만들 수 있다고 생각합니다. 물론 완벽한 방법론은 없습니다.

저는 현재 특정 개별 카우보이보다 조직 문화와 관련이있는 것을 제외 하고는이 경우 상점에서 일하고 있습니다.

조직은 항상 상대적으로 느슨하고 "비공식적 인 민첩한"접근 방식으로 운영해 왔습니다. 나는 그것이 진정으로 민첩하다고 말하지 않고, 더 "이름이 민첩하다"지만 실제로는 존재하지 않는 단순한 방법론입니다. 팀마다 다르게 운영되지만 전체 조직 문화에는 "느슨한 이름 만"프로세스 이외의 다른 방법론이 없기 때문에 전체적으로 비교적 혼란스럽고 혼란 스럽습니다. ).

이야기의 교훈은-그렇습니다. 내가 지금 구직을하고 있다면 매우 조심해야합니다. 상점이 애자일이라고 주장하는 경우-인터뷰에서 애자일의 잘못된 이름 이상을 실제로 따르고 있는지 확인하기 위해 매우 어려운 질문을 할 것입니다.

사용자가 사용할 수있는 응용 프로그램, 데이터를 입력 할 수있는 화면이 있으면 사용자는 피드백을 줄 수 있다는 것을 알았습니다. 그래야만 요구 사항 문서에서 고객이 서명하려고하는 내용을 이해합니다 (고객이 서명하지만 모든 사람이 고유 한 의미를 가짐). 민첩한 개발이 아니라면 예산을 넘어서는 폭포 프로젝트가 될 것이지만 일단 제공하면 응용 프로그램이 변경 될 것입니다. 첫 번째 버전은 사용자가 요구 사항을 논의 할 수있는 프로토 타입에 지나지 않습니다. 예산보다는 예산보다 민첩하다고합니다.

어떤 환경에서는 애자일이 규율을위한 변명으로 사용된다고 생각합니다. 진짜 문제는 우리가 왜 방법론을 가지고 있는지를 잊어 버린 것입니다. 개인적으로, 방법론은 시스템 아키텍처가 기능적이지 않은 품질 속성을 다루어야한다는 의미에서 아키텍처 문제라고 생각합니다. 방법론은 동일한 속성 (유지 보수성, 개발 생산성, 지식 전달, 외)

방법론을 프로세스 속성에 대한 제어로 보는 것은 몇 가지 사항을 의미합니다. 1) 메트릭이 없으면 한 방법론의 효율성을 다른 방법론과 비교할 수 없습니다. 품질 대 지식 이전).

측정 항목과 실질적인 목표를 모두 갖지 않으면 서 우리는 단순히 "마술 깃털"로 방법론을 선택하여 소프트웨어를 제공 할 수있게됩니다.

이제 애자일, XP, 스크럼 등의 전문가들은 특정 범주의 방법론의 취약성에 대해 이야기합니다. 논쟁은 : 왜 모든 규칙을 따를 수있는 규칙이없는 한 개인에 의해 파괴 될 수있는 방법론을 사용 하는가? 질문은 유효한 질문입니다. 그러나 이는 증상이 아니라 원인입니다. 정확하고 의미있는 (매우 어려운 부분) 프로세스 메트릭 세트가 정의, 테스트 및시기 적절한 피드백을 제공 한 경우 특정 방법론이 성공과 거의 관련이 없음을 알게 될 것입니다. (비례 적으로 나는 수많은 방법론을 사용하여 성공적인 프로젝트를 보았고 동일한 방법론을 사용하여 두 배나 많은 실패를 보았습니다)

측정 항목은 무엇입니까? 프로젝트마다, 팀마다, 시간에 따라 다릅니다. 배달 일정이 중요한 경우에 유용합니다. 개인적으로 사용한 것은 예측 기술과 품질입니다. 대부분의 개발자는 일주일 이하의 작업을 정확하게 추정 할 수 있습니다. 따라서 한 가지 접근 방식은 프로젝트를 1 주일에 한 번의 작업으로 나누고 누가 견적을했는지 추적하는 것입니다. 프로젝트가 진행됨에 따라 견적이 변경 될 수 있습니다. 작업이 완료된 후, 10 % 이상 (하루에 1/2) 이상이 오류를 버그와 동일하게 처리하면 추정치가 해제 된 이유 (예 : 데이터베이스 테이블이 고려되지 않은)를 식별하고 수정 조치 (예 : 추정에 DBA 포함)를 수행하십시오. 이 정보를 사용하여 주당 예상 버그 수, 개발자 당 버그 수,

그래서 무엇? 프로세스 방법론을 충족시키지 못하는 예측 모델이있는 경우 방법론의 일부 측면을 추가 또는 제거하고 모델에 어떤 영향을 미치는지 확인할 수 있습니다. 물론, 실패에 대한 두려움으로 인해 개발 프로세스를 진행하고 싶은 사람은 없지만, 우리는 이미 지속적으로 높고 예측 가능한 속도로 실패하고 있습니다. 개별 변경을 수행하고 결과를 측정하면 Agile이 팀에 완벽한 방법론임을 알 수 있지만 RUP, 폭포 또는 최상의 모범 사례를 쉽게 찾을 수 있습니다.

제 제안은 우리가 프로세스라고 부르는 것에 대해 걱정하지 말고, 개발 프로세스 목표와 관련된 검사를 실시하고, 프로세스를 개선하기 위해 다른 기술을 실험 해 보도록하는 것입니다.

나는 멋진 고급 사양으로 여기에 앉아 있었고 다른 무언가가 자르거나 그렇게 생각하지 않았기 때문에 2 일마다 같은 화면과 기능을 다시 방문하지 않아도됩니다.

그것은 내 동료가 자신이 가지고있는 "민첩한"프로젝트에 대한 경험과 일치하지 않는 것 같습니다. (내가 한 번도 본 적이 없었습니다.) : 테스트를 마치고 코드를 작성하여 일부 사양에 코드를 작성하라는 요청을 받았습니다. 새로운 요구 사항으로 넘어갈 준비가되었으므로 요구 사항을 변경하고 다시 테스트해야합니다. 그는 좌절감을 느낀다.

나는 민첩성을 강타하지 않고 팀이 민첩하게 행동하고 있지 않다고 생각하지만 카우보이가 "민첩한"이라는 용어를 사용하여 뾰족한 헤드 매니지먼트에게 반 베이크 디자인이 부정적인 것이 아니라 긍정적이라는 확신을 주기도한다. .

아무도 자신을 카우보이 코더로 생각하지 않는 것이 재밌습니다. 많은 포스터에 베팅하는 것은 하나의 포스터이거나 하나였습니다.)

카우보이 코더는 물건을 빨리 처리하는 것을 좋아하기 때문에 좋습니다. 그들은 종종 큰 그림 문제 나 코드 품질에 대해 걱정하지 않기 때문에 "카우보이 코더"가 흔히 사용되는 이유입니다. 이들의 방법은 프로젝트 지연의 기회 비용 위험을 완화합니다.

카우보이가 아닌 코더는 안전하고 규칙적이고 질서 정연한 방식으로 작업을 수행하는 것을 좋아합니다. 그들은 그것을 올바르게 만들고 한 번 만드는 것을 좋아합니다. 그들은 정보를 영원히 수집하고, 가정을 고려하고, 아무도 읽을 수없는 큰 문서를 생성하며, 늦거나 매우 늦게 시스템을 제공하는 것으로 유명합니다. 그들의 방법은 품질이 떨어지는 소프트웨어의 위험을 완화 시키려고합니다.

민첩한 방법론의 장점은 짧은 고품질 작업 반복을 강제로 수행하여 두 가지 유형의 코더의 장점을 활용한다는 점입니다. 또한 각 반복은 지연된 배달의 기회 비용 위험과 품질이 낮은 소프트웨어의 위험을 모두 완화합니다.

애자일이 초기 설계 / 사양에 대해 거의 강조하지 않는 이유는 요구 사항이 변경 될 수 있기 때문이 아닙니다. 더 깊은 이유는 요구 사항이 안정적인 경우에도 사양이 다음과 같은 경향이 있기 때문입니다.

• 잘못-요구 사항을 캡처하지 못합니다.

• 일관성이 없음-작가 / 독자가이를 잡을 수없는 충분한 정보가 포함되어 있기 때문에 모순으로 가득 차 있습니다.

• 분리됨-실행 중 (축소되었지만) 시스템에서 귀중한 피드백을 통합하지 않습니다.