애자일은 새로운 미세 관리입니까?

이 질문은 잠시 동안 머릿속에서 요리되어 왔기 때문에 개발 환경에서 민첩 / 스크럼 관행을 따르는 사람들에게 물어보고 싶었습니다.

우리 회사는 마침내 애자일 방식을 도입하기 위해 애자일 그룹에 4 명의 개발자 팀을 시험 적으로 시작했습니다. 3 개월의 반복으로 4 개월이 지났으며 우리의 나머지 부분에 대해 완전히 민첩하게 가지 않고 계속하고 있습니다. 이는 경영진의 신뢰가 비즈니스 요구 사항을 충족시키기 위해 위와 같은 약간의 특별 요청을 처리하기 때문입니다.

최근에 저는이 이니셔티브에 참여한 개발자들과 이야기를 나누었습니다. 그들은 재미 없다고 말합니다. 그들은 스크럼 마스터가 다른 개발자와 대화 할 수 없으며 작업 영역에서 전화를 걸 수 없습니다 (어쩌면 어느 정도 괜찮을 수도 있음). 예를 들어, 민첩한 팀에 속한 킥을 친구에게 말하고 싶다면 Scrum 마스터의 승인 없이는 허용되지 않습니다. 애자일 팀 바로 옆에 앉아 있습니다.

이 모든 또는 민첩성의 아이디어는 민첩한 개발자에게 중단없이 완벽한 진공을 제공하고 6 시간 이상의 생산 시간을 확보하는 것입니다. 글쎄, 나는 애자일 전문가가 아니지만 Yahoo 애자일 롤아웃 문서를 읽고 다른 조직과 비슷한 것을 사용하면 애자일이 싸지 않다는 느낌을받습니다. 팀에 민첩성을 심어주고 문제를 해결하기 위해 자원과 예산이 필요합니다.

초보자를 위해서는 개발자를위한 교육과 관리자 등을위한 코칭이 필요합니다. 현재 Scrum 마스터는 경영진이 지불 한 민첩한 훈련 수업을 며칠 동안 진행 한 관리자였으며 현재이 민첩한 팀을 이끌고 있습니다. 또한 회의에서 애자일 선언문이 애자일이 결석으로 설정되지 않고 각 회사마다 다르게 사용자 정의된다고 지시하지 않는다고 들었습니다. 글쎄, 그것은 모두 좋은 소리와 이유 소리.

결론적으로, 항상 애자일이 개발 팀과 조화를 이루어 행복한 개발자가 될 것이라고 생각했습니다. 그러나 애자일 팀의 개발자와 대화 할 때 매우 반대되는 느낌이 들었습니다. 그들은 하루 종일 조용히 앉아 일하는 것 외에는 아무 말도 할 수 없다는 것이 불행하며, 경영진이 더 많은 일을 할 수있는 또 다른 방법이라고 생각합니다.

이것이 더 많은 달러에 대한 이기적인 이점을 위해 사용 된 좋은 관행의 예 중 하나라면 알려주십시오. 아니면 어쩌면 우리와 같은 개발자 일뿐입니다.이 민첩한 팀은 일을하고 있기 때문에 숨을 쉬는 환경에서 일하는 것을 좋아하지 않는다고 생각합니다.

미국 전역에 지사가있는 의료 분야의 회사입니다. 카우보이 스타일의 민첩한 느낌이 들기 때문에 현재 회사에서는 애자일을 원하지 않습니다.

모든 것은 관리가 완전히 싸다는 것과 관련이 있습니다. 더 저렴한 버전을 위해 고가의 커피를 자르고, 절약에 중점을두고 가능한 한 마른 상태로 생산성을 유지하십시오.

제 생각에는 문 뒤에있는 경영진이이 아이디어를 내 놓았고, 민첩한 기술로 인해 더 많은 생산물을 만들어 내므로 우리는 동일한 직원 수로 더 많은 생산자에게 상사를 보여줄 수 있습니다. 또는 그럴 경우 직원 수를 줄일 수 있습니다.

그들은 매일 5 분씩 회의를하고 있습니다. 그러나 팀 외부의 사람과 대화하거나 대화 할 수 없습니다. 모든 작업에 중점을 둡니다.

당신은 민첩한 것이 아니라 관리적 독재를 묘사하고 있습니다. 애자일 (Agile)은 변화하는 요구 사항 분야에서의 점진적인 개발에 관한 것이며, 사람들이 각자의 업무 수행 방식을 지시하는 것이 아닙니다.

Scrum 마스터가 다른 개발자와 대화 할 수 없으며 작업 영역에서 전화를 걸 수 없습니다.

이것은 실제로 애자일 관행의 일부가 아니며 별도의 문제입니다.

애자일 방법론의 큰 동기는 개발자 간의 커뮤니케이션 이 증가한다는 것 입니다. 개발자 통신 개발자 제한은 애자일 사례와는 별개의 문제입니다. 나는 이것이 일어나지 않는다고 말하는 것이 아닙니다. 분명히 그것은 조직에서 "민첩한"롤아웃의 일부로 표시되고 있지만 이것은 실제로 민첩성과는 별개의 문제입니다 (애자일 개발의 정신과는 다소 반대), IMO).

그것은 민첩하게 구현 된 것 같습니다. 애자일 경우에는 소액 관리를 줄이지 말고 늘리지 않아야합니다. 팀은 약속을하고 프로세스의 일부는 경영진이 팀이 달성 할 것이라고 신뢰한다는 것입니다. 일일 스크럼은 개발자가 서로 의사 소통하는 방법이며 시간을 어떻게 보냈는지가 아니라 수행 한 내용을 알려주는 방법입니다 (몇 곳에서 본 실수입니다). 스토리가 얼마나 오래 걸리는지 (다른 일반적인 실수)가 아니라 상대적 복잡성을 추정해야하기 때문에 추정 프로세스조차도 추정에서 명시적인 시간을 제거해야합니다. 개발자가 소비하는 시간을 제어하는 ​​것은 소액 관리의 특징이며 프로세스에서 시간을 제거하는 것은 민첩성의 핵심 원칙 중 하나입니다.

당신이 묘사하는 환경은 정원의 다양한 의사 민첩한 헛소리 처럼 들립니다 .

애자일 이전에 애자일에 관여했습니다. 2000 년경 나는 코딩에 불을 지르고 익스트림 프로그래밍에 대해 들었고 그것을 시도하고 좋아했습니다. 그것은 개발자로서 견고한 소프트웨어를 만드는 것이 가장 중요한 상황이었고, 나를 미치게 만드는 많은 헛소리를 최소화하는 도구를주었습니다. 나는 그것을 좋아했다.

오늘 다른 곳에서 자세히 설명 하는 문제는 요즘 "애자일을 채택"하는 대부분의 사람들이 불편하게 만들면 아무것도 개선하는 데 관심이 없다는 것입니다. 따라서 "Agile"은 개발자에게 이전과 같은 방식으로 이길 수있는 새로운 도구 일뿐입니다. 예를 들어, 개발 속도를 늦추는 모든 헛소리를 제거하면서 생산성을 근본적으로 향상시키는 방법과 달리.

지금. 저는 회사를 시작하고 많은 XP와 애자일 세계에서 배웠던 여러 가지 트릭을 사용할 것입니다. 그러나 정확하게 당신과 같은 이야기 때문에 요즘 애자일 채택에 대해 들었을 때마다 fl니다.

따라서 귀하의 질문에 직접 답하십시오 : 민첩한 것이 새로운 미세 관리가되어서는 안됩니다. 실제 일을하는 사람들에게 힘을 실어주는 것이 중요합니다. 그러나 귀하의 경우, 애자일은 그들이 자신의 나쁜 본능에 빠지면서 그들이 당신에게 말하는 최신 거짓말처럼 들립니다. 정말 죄송합니다.

민첩하지 않습니다.

첫째, 스크럼은 민첩하지 않습니다 . 솔직히 스크럼은 헛소리입니다. 나는 극한 프로그래밍 하우스에서 자랐습니다. 스크럼은 프로젝트 관리 도구-개발 프로젝트를위한 정의 된 리듬입니다. 그러나 개발 자체에 대해서는 말할 것도없고 요구 사항, 계획 및 고객과의 관계에 대해서는 말할 것도 없습니다. XP는이 모든 것에 대해 할 말이 많습니다. 민첩하다고 부르는 다른 방법론에는 대화에 추가 할 무언가가 있어야합니다. 스크럼 지지자들은이를 프로세스가 아니라 프로세스의 래퍼로 설명했습니다. 현명한 사람은 래퍼가 좋은 물건을 얻기 위해 제거하고 버리는 것이라고 지적했습니다.

좋아, 스크럼이 울렸다!

둘째, 민첩한 프로세스의 기본이라고 생각하는 XP의 설립 원칙은 개발자 중심입니다 . 개발자가 자신이 필요로하는 일을 할 수있는 능력을 갖게되므로 자주 중단되는 방법입니다. 애자일 팀은 민주주의 또는 민주주의로 구성 될 수 있지만 리더는 개발자입니다. 프로젝트 관리자 등 중요한 역할이 있지만 팀 리더가 아닙니다. 관리자들을 유감스럽게도, '스크럼 마스터'-사람들을 보좌하는 것은 팀이 민첩하지 않다는 확실한 신호입니다.

나는 세 번째가 있어야한다고 생각합니다. 없습니다.

스크럼은 애자일의 나쁜 자식입니다. 모든 민첩한 방법론 중 가장 폭포 형 스타일이며, 이것이 관리자들 사이에서 가장 인기있는 이유입니다.

모든 민첩한 방법은 문제가 발생하지 않고 작업 코드를 생성하는 것입니다. 다시 읽어보세요. 다시 한번.

"민첩한 규칙"에 관계없이 그 목표를 방해하는 것은 나쁘다. 규칙이 잘못되면 f * * 규칙을 변경하십시오 ! 그것이 민첩한 방법입니다. 그것이 적절하고 효과적입니다.

좋은 예 이것은 테어 코크 (민첩 선언문의 발신자 중 하나)에 의해 주어진다 :

“워크 스테이션과 화이트 보드가있는 방에 4-6 명을두고 사용자에게 접근합니다. 1 ~ 2 개월마다 실행되고 테스트 된 소프트웨어를 사용자에게 제공하고 그렇지 않은 경우에는 그대로 두십시오.”

그것이 당신이 가진 사람들의 품질에 효과가 있다면, 그것이 당신이 필요한 전부입니다. 스크럼 마스터 나 "민첩한"방법론이 필요하지 않습니다. 매일 스크럼에 앉아 있으면 효과가 있다면, f * * *하십시오. 당신이 일 어설 수 있다는 것은 스스로 생각할 수있는 능력에 대한 한심한 폐지입니다.

있다 응답 당신이하고있는 민첩의 종류는. 이것입니다. 다른 사람이 없을 때 인쇄하여 어딘가에 고정 시켜서 스스로 발견하도록하십시오.

현재 스크럼 마스터는 경영진이 지불 한 며칠간의 민첩한 훈련 과정을 이수한 관리자로 현재이 민첩한 팀을 이끌고 있습니다.

그게 네 문제 야 경영진은 애자일을 원하고 실제로 그것이 무엇인지 알지 못하고 팀에 부과합니다. 개발자의 생산성을 크게 줄이고 싶을 때해야 할 일이 많습니다.)

새로운 프로세스 제안은 개발자가 제공해야합니다. 또는 경영진의 아이디어라면 적어도 검토 및 승인을 받아야합니다 .

어쨌든 개발자가 거부하면 구현하지 마십시오 ! 아니면 당신이 묘사 한 재앙이 될 것입니다.

"민첩한"및 다른 모든 "관리 방법론"은 사람들에 대한 소액 관리를 강요하기 위해 자주 남용됩니다. OTOH 때때로 가난한 솜씨를 방어하기 위해 학대됩니다.

"우리는 민첩하다"는 계획 부족, 디자인, 기능, 품질, 출시주기에 대한 생각 부족으로 가장 자주 핑계입니다. 이것은 일반적으로 개발자와 경영진이 제공합니다. 미들 매니지먼트를 위해 중간 관리자, 건축가, 영업 사원 등으로부터 들리는 가장 빈번한 변명이기도합니다. .

물론이 두 가지는 종종 모순되며 동일한 프로젝트에서 발생할 수 있습니다.

귀하의 원래 질문에 대답하기 위해 Agile은 새로운 마이크로 관리입니다.

먼저 이것을 읽으십시오 (Agile manifesto). 공동 개발자와 이야기하지 않는 것이 나열되어 있지 않습니다.

실제로 "개인 및 상호 작용"은 공동 개발자와 이야기하지 않는 것과 정반대입니다.

민첩한 새로운 자기 관리해야합니다. 애자일이 올바르게 실행되면, 고객과 개발자가 작업을 식별 할 때 백 로그에 추가되는 합리적인 범위의 사용자 스토리를 작업하여 많은 결정을 내립니다.

일일 스크럼은 관리가 아니라 커뮤니케이션에 관한 것입니다. 우선 순위 및로드 밸런싱에 대한 논의가 있지만 스크럼에서 관리하는 사람은 스크럼 마스터가되기를 바랍니다. 개발자로서 참석하여 내가 한 일, 내가 할 일 및 필요한 도움에 대해 이야기합니다. 그런 다음 스크럼 마스터는 내 진행에 방해가되는 행동을 취해야합니다.

민첩한 팀은 일상적인 작업이 계층 적으로 관리되는 것처럼 느껴져서는 안됩니다. 계층 적 조직의 최상위에있는 누군가가 멀리서 결정을 내린다면 이제는 의사 결정의 탈 중앙화시기입니다! 일부 사람들과 일부 조직의 경우 이것은 너무 멀리 다리 일 수 있습니다. 조직에 다음 사항이 해당되지 않는 경우 :

라이브 애자일 선언문을

"우리는 소프트웨어를 개발하고 다른 사람들이 소프트웨어를 개발하도록 도와주는 더 나은 방법을 발견하고 있습니다."

"이전 상사와 같은 새로운 상사를 만나십시오." 가능한 한 팀 내에서 민첩성을 시작하십시오. 때때로 이것은 Agile을 사용하여 시험 프로젝트에 참여하고자하는 의지를 연합함으로써 발생합니다. 훌륭한 팀워크에 대한 실적이있는 자원 봉사자 또는 초청 된 회원으로부터 애자일 팀을 구성 할 수 있다면, 팀원들이이를 해결할 수 있습니다. 사내 또는 접근성이 높은 고객을 위해 짧은 프로젝트에 소규모 팀을 사용하십시오.

변화를 받아들이십시오. 아마도 당신은 약간의 훈련을받을 수 있지만 예산이 빡빡하고 돈이 없을 수도 있습니다. 다른 기회도 개선 될 수 있습니다. 독서를하고, 팀원들이 애자일에 대해 할 수있는 것을 배우고 서로 가르칩니다. 애자일 채택을 모델링하고 이끌 자격이있는 신규 또는 기존 직원을 찾을 수 있습니다.

애자일 팀은 일반적으로 이해되는 목표를 향해 노력하는 축구 팀과 같습니다. 저는 몇 년간 민첩한 팀의 일원이었으며 모든 이해 관계자들에게 효과적이고 효율적인 의사 소통이 핵심입니다. 관리자 / 스크럼 마스터는 단순한 팀의 촉진자이며 전통적인 관리 / 마이크로 관리는 팀의 정신을 죽일 것입니다.

내가 일한 팀에서는 근무 시간 이후에 팀 게임을 플레이하여 회원들의 동지애를 향상시키는 것이 좋습니다. 나는 그 생각을 여기에 모았 습니다 .

귀하의 질문에 대답하기 위해 : 아니요. 민첩한 형태는 소액 관리의 형태가 아닙니다. 그러나 다른 도구와 마찬가지로 사람들은 도구를 잘못 사용할 수 있습니다. 애자일은 제대로 구현 될 때와 사람들이 일관 될 때 훌륭합니다.

"Devs는 다른 사람과 대화하지 말고 스크럼 마스터"에 대한 나의 생각 :

나는 그것이 규칙이었던 곳에서 일했다. 그러나이 규칙은 사람들에게 작업을 완료하도록 요청하는 것과 관련이 있습니다. 예를 들어, 나는 무작위로 개발자 테스터에게 가서 몇 시간 안에 나를 위해 몇 가지 테스트를 해달라고 요청할 수 없습니다. 스크럼 마스터와 대화를해야 긴급 상황 인 경우 (또는 향후 스프린트를 위해 백 로그로 푸시해야하는 경우) 팀 구성원과 해당 작업이 스프린트에 어떻게 적용되는지 논의 할 수 있습니다.

이 경우, "서로 대화하지 않는 개발자"라는 개념은 하나의 체크 포인트를 통해 퍼널 작업으로 변환되어 특정 개발자가 과로하지 않거나 긴급한 작업을 수행하여 계획을 세우지 못할 정도로 바쁘기 때문에 이해했습니다. 작업 완료.

그렇지 않으면 개발자는 서로 대화해야합니다. 항상. 문제를보다 빨리 해결하고, 팀과 더 가까워지고, 더 빨리 제공 할 수 있습니다.

또 다른 관점을 제시하기 위해 : 저는 사람들이 개발자들이 "너무 많이 이야기했다"고 생각하는 환경에있었습니다. 앉은 후, 우리는 실제로 "개발자들은 자신의 작업을 수행하기에 충분히 독립적이지 않다. 모든 것이 너무 세분화 되었기 때문에, 작은 작업을 마치려면 다른 세 사람에게 가야한다"는 것을 알았다.

따라서 관리자가 민첩하게 전환하기로 결정했을 때 올바른 장소로 정보를 가져오고 조직 내에서 많은 조각화를 막을 것으로 기대했습니다. 어떤 사람들은 애자일이 구현 된 후에도 개발자들이 여전히 서로에게 달려가는 것에 실망했습니다. 그러나 그들이 깨닫지 못한 것은 점점 줄어들고 있다는 것입니다. 그래도 시간이 걸렸습니다. 따라서 그것이 조직에서 진행되고있는 일이라면 사람들은 밤새 민첩하게 문제를 해결하기를 기대했을 수 있습니다. 그것은 그것이 작동하는 방식이 아닙니다.

원작자 Smith Janes는 경험을했을 수도 있습니다. 그러나 이것이 Agile 프로젝트에서 발견 된 전형적인 문제입니다.

1. 대부분의 조직, 개발자는 애자일 / 스크럼에서 여러 프로젝트로 작업해야합니다. 스프린트는이 사실로 간주되지 않습니다. Scrum Master는 스프린트가 끝날 무렵에 이야기를 끝내야한다고 가정합니다. Scrum 마스터는 개발자가 아닌 하나의 프로젝트에만 전념 할 수 있습니다. 또는 전화를 허용합니다.
2. 나는 스프린트가 계획된 곳에서 민첩한 프로젝트를 보았습니다. 스프린트의 중간 쯤이나 중간에 스프린트에 포함 된 이야기가 있습니다. 가장 민첩한 프로젝트에서 남용 중 하나입니다.
3. 테스트 : TTD .. 예, 매우 좋습니다 ..하지만 TTD에 전적으로 의존하는 대부분의 애자일 프로젝트를 보았습니다. 기능 또는 인간 테스트에 허용되는 범위 나 시간이 없습니다. 기능 테스트의 중요성을 모르거나 이해하지 마십시오. 비즈니스 요구를 충족시키지 못하면 코드가 완벽하게 작동 할 수 있습니다. 쓸모가 없습니다. 이는 비즈니스가 미리 참여하지 않거나 참여가 있지만 비즈니스 의사 결정을 반영하지 않는 경우에 발생합니다. .. 결국 개발자가 비난을 받거나, 기능을 제공하지 않았거나, 마지막 순간 변경으로 끝날 것입니다. 스크럼 마스터가 스토리가 완료되지 않은 것에 대해 비난을 받고 싶지 않기 때문에 시간이 더 오래 걸립니다.

학대 ... 사업에 대한 낮은 참여율이나 지식이 부족하거나 참가자가 스프린트 중간에 빠지는 경우.

1. 모든 프로젝트가 애자일에 적합한 것은 아닙니다 ... 대부분의 관리자 나 스크럼 마스터는이 사실을 알지 못합니다. 유지 보수 프로젝트 .. 스프린트에서 허용되는 결함은 처음 8 시간 안에 완료 될 수 있습니다. 4 시간을 보낸 후 이것이 Java / 또 다른 제품이라는 것을 발견했습니다 ... 자금 조달, 새 버전 또는 업그레이드는 내부 엔지니어링 등의 승인을 받아야합니다. 5.Retrospection : 소수의 애자일 프로젝트 만이 단계를 수행합니다. 완료된 경우. 관리 스크럼 마스터는 실패한 스토리에 대해 책임을지지 않습니다.
2. 페어링 .. 많은 개발자들이 동료를 남용하기위한 장소로 페어링을 취급합니다. 다른 디자인, 코딩 관행을 비판합니다. 팀워크로 취급하는 평가자, 서로 배우기 ... 민첩 / 스크럼을 남용하는 또 다른 방법

애자일은 확실히 좋은 방법론입니다. 조직이 완전히 또는 훈련되지 않은 경우를 제외하고는 ... 학대입니다 .. 주당 60 시간 이상의 근무 시간, 비난 게임, 낮은 도덕성.

애자일은 가장 작은 관리입니다. 애자일에는 이니셔티브 나 창의성을위한 장소가 없으며, 무능한 관리자가 기술적 관점에서 단서 없이도 통제력을 유지할 수 있도록 프로그래밍에서 즐거움을 제거했습니다.