민첩한 MVP (가장 귀중한 플레이어 / 프로그래머)

최근 저는 경영진이 각 스프린트가 끝날 때마다 팀이 개발자 'MVP'와 QA 'MVP'를 지명한다는 아이디어를 도출 한 민첩한 프로젝트 (스크럼 사용)에 참여했습니다. 팀. MVP는 작은 금전적 보상과 무료 점심을 제공받으며 트로피를 책상에 전시 할 수 있습니다. 우리는 지금까지이 보상 시스템을 갖춘 두 가지 스프린트를 가졌습니다.

이것에서 내가 보는 장점은 다음과 같습니다.

• 더 많은 버그가 수정되었습니다 (상위 경영진이보고 싶어하는 것, 원하는 방향으로 숫자가 변경됨).
• 각 '팀'의 MVP는 인정을 받고 자부심을 얻습니다 (또는 자아 부스트입니까?).

나는 그런 일을하는 데있어 나쁜 측면을 생각할 수있는 몇 가지를 발견했습니다 (적어도 개발자 관점에서).

• 버그 수정의 품질이 떨어질 수에 관심이있는 몇몇 개발자가 있습니다. 한 영역에서 수정하면 다른 영역에서 회귀가 발생합니다.
• 버그 수를 늘리기 위해 '쉽고 빠른'버그를 선택하는 개발자가 몇 명 있습니다. 내가 여기에 나쁜 것 같아요.
• 높은 우선 순위 (많은 시간이 '고정 / 고정하기'와 연관 됨) 결함은 실제로 우선 순위가 낮아집니다.
• 차단 결함은 일반적으로 시간이 더 걸리고 QA와 더 많은 조정이 필요하기 때문에 적시에 해결되지 않습니다.
• 개발자 팀 내의 팀 측면이 손실되었습니다. Dev와 QA의 팀 측면은 함께 개선되지 않았지만 이전과는 크게 달라지지 않았습니다.
• 버그 수정을 넘어서거나 THAT 번호를 향해 작업하는 것은 쉽게 인식 / 추적되지 않습니다.

팀이 각각을 처리하는 방식에 따라 위의 '나쁜'각각을 어느 정도 해결할 수 있다고 생각합니다.

내 질문은 그렇다면 스프린트 당 MVP를 인식하는 사람이 이와 같은 것을 성공적으로 철수 했습니까? 그렇다면 그 성공에 어떤 기여를했다고 생각하십니까?

애자일 은 개인의 노력이 아닌 팀의 노력을 강조 합니다. 따라서,이 접근법은 분명 민첩하지 않습니다.

이는 팀 협업을 장려하기보다는 각 팀 구성원이 자신의 결과에 집중하도록 독려합니다. 회원들이 서로를 피하는 것을 피할 수도 있고 (혹은 더 나빠질 수도 있음) 장기적으로는 팀의 발전을 방해 할 수 있습니다.

나는 그들이 좋은 일을했다면 팀 전체에 보상을 제안합니다.

나는 그것이 나쁜 게임 화가 적용되는 좋은 예라고 생각합니다 . 문제는 프로그래머가 잠재적으로 문제를 해결하고 도전 과제 (하드 버그 찾기 및 수정)를이기는 데 본질적인 동기가 있었으며, Scrum을 구현 한 이후 TEAM으로 작업 한 것이기 때문입니다. 다시 말해서, 그들은 잠재적으로 좋은 일을하고 싶었습니다.

이제 이들 중 일부의 경우,이 본질적 동기 또는 그 일부가 게임 메커니즘의 일부인 타이틀 ( "금주의 MVP")과 보상 (금전 금액 및 무료 점심)으로 구성된 외부 동기로 대체되었습니다. 게임 화 된 과정.

직장에서 게임 화를 성공적으로 적용 할 수 있지만 내재적 / 외적 동기를 활용하는 데 매우 신중해야합니다. 외적인 동기는 동기가 내재적으로되기 위해 자기 결정 을 강화하는 힘을 가져야한다. 그러나 여기서 일어난 일은 그 반대입니다. 프로그래머들은 승리하기 위해 "게임을하고 있습니다" .

이 문제를 해결하기 위해 할 수있는 일은 관리자에게 규칙을 약간 변경하도록 요청하는 것입니다.

• 티켓의 난이도와 우선 순위에 맞는 포인트를 제공합니다. 찾기 어려운 버그를 수정하는 것이 훨씬 흥미롭고 포인트 단위로 작성되도록하십시오.
• 협력 적으로 문제를 해결하기위한 포인트를 제공합니다 (다시 TEAM). 더 많은 프로그래머가 QA와 상호 작용할 수있는 곳입니다. 프로그래머와 QA에 의해 협력 적으로 해결되는 문제를 지적하십시오.
• 가장 많은 포인트와 가장 많은 티켓을 각각 다른 타이틀을 제공합니다. 이것은 프로그래머의 경쟁 본능을 만족시켜야합니다.
• 팀의 모든 구성원의 포인트를 합산하여 개발자와 QA 간의 우호적 인 경쟁을 설정하십시오.

그러나 회귀 버그의 가능성을 줄이는 것은 또 다른 문제입니다. 예를 들어 부정적인 점을 적용 할 수는 있지만 처벌의 형태이기 때문에 좋은 생각이 아니라고 확신합니다. 지난주에 회귀 버그가 발견되지 않은 경우 몇 점으로 스프린트를 자동으로 시작하는 것이 더 나을 것입니다. 회귀 버그가 발견되면 프로그래머는 0으로 시작합니다.

또한 "게임 화"에는 "게임"이 있습니다. 게임의 기본 측면은 자발적으로 게임 / 참여하는 것입니다. 작업의 맥락에서, 여기에 해당하는 경영진에 의해 부과 될 수 있지만, 일반적으로 아무도이 일을 강요해서는 안된다.

결론적으로,이 MVP는 반드시 나쁜 생각은 아니지만 비즈니스 (중요한 버그 해결)를 최우선으로하고 개인보다는 팀워크를 강조하기 위해 접근 방식이 약간 변경 될 수 있습니다.

팀 구성원의 노력에 대한 일종의 그룹 인식은 귀중한 동기 부여자가 될 수 있지만이 경우 잘못 적용되는 것처럼 들립니다. MVP는 투표에 의해 선정되었다고 말하지만 스프린트 당 수정 된 버그의 수는 많이 언급되어 있습니다. 그것은 당신의 시간이 MVP에 대한 재미있는 정의를 가지고있는 것처럼 들립니다. "가장 가치있는"칭호를받을 자격이있는 사람은 그 스프린트에서 소프트웨어에 가장 가치를 더한 사람이라고 가정합니다. 팀원이 신속하게 고칠 수있는 버그를 찾아 내고 가능한 빨리 버그를 폭파하고 결과적으로 회귀 버그와 기타 문제를 일으킨다면 가치를 더하지 못하고있는 사람은 문제를 파악하고 해결하는 데 도움이됩니다.

다음에 귀하의 팀이 이러한 투표 중 하나를 가질 때 적절한 토론을 시작하려고 제안합니다. 손을 보여주지 마십시오. 먼저 말해봐 누군가가 자신이 만든 "수정"의 수에 따라 투표권을 얻는 것 같으면 해당 수정으로 인해 회귀를 일으킨 위치를 지적하고 (그리하여)이 회귀를 수정 한 사람이 다른 사람을 정리하도록 지명해야한다고 제안합니다. 음식물. 누군가가 전체 스프린트를 하나의 불쾌한 문제로 쫓아 버렸다면 팀에 지적하십시오.이 사람의 수정 횟수는 하나이지만 소프트웨어의 주요 문제-한 손으로 해결했다는 사실을 강조합니다. 너무나 불쾌해서 그 누구도 만지고 싶어하지 않았습니다.

쉬운 수정 프로그램을 골라 서두르거나 우연한 방식으로 수행하는 것은 가치가 없으므로 그렇게하는 개발자는 아마도 MVP 후보로 적합하지 않아야합니다. 새로운 MVP를 선택할 때는 팀과 팀원을 모두 잊고 소프트웨어를 살펴보십시오. 마지막 이후로 해당 소프트웨어에서 가장 중요한 단일 변경 사항을 선택하십시오. 나는 여기서 싱글을 의미 한다. "많은 작은 버그가 아니라"는 큰 변화가 아닙니다. 특히 눈부신 버그가 수정 되었습니까? 새로운 기능이 추가 되었습니까? 이 큰 변화가 무엇인지 확인한 후에는 누가 그 책임을 맡았는지 물어보십시오. 그 사람들 중 하나가 아마 당신의 MVP 일 것입니다. 경우 "하지 많은 작은 버그 그대로"입니다 만 다음과, 차이 만그렇다면 버그 수는 MVP의 올바른 척도입니다. 심지어 회귀 버그로 수정 된 버그의 비율을 살펴 보겠습니다. 누군가가 발생하는 모든 버그는 카운트에서 최소 1을 공제합니다. 사실, 잘못된 수정으로 인해 알려지지 않은 버그를 발견 할 수 있기 때문에 이미 발견 된 알려진 버그 보다 더 나쁩니다 . 알려진 버그는 해결하기 위해 개발자의 노력이 필요합니다. 알 수없는 버그로 인해 품질 보증팀에서 찾아야 하고 개발자가 해결해야 할 경우 QA가이를 놓칠 위험이 있습니다.

이론적으로, 개발자가 상을받는 방법이 더 적고 더 큰 문제를 해결하는 것임을 깨달으면 어려운 문제, 복잡한 문제, 블로킹 결함을 목표로합니다. 주위를 둘러싼 고기 문제가 충분하지 않거나 더 많은 눈 을 필요로 하기에 까다로워서 때때로 함께 묶어야합니다 . 아마도 이와 같은 경우 버그를 수정하기 위해 더 많은 작업을 한 사람들이 누구인지 명확하지 않으면 상을 공유 할 수 있다고 제안합니다. 개발자는 아마도 그 사실을 알고있을 것입니다. 그러나 경영진이 관여한다고 말하고 경영진이 그 점을 항상 이해하지는 않습니다.

그리고 다른 모든 것이 실패하면 MVP 프로그램을 잊어 버려라. 스크럼 외부의 동료 개발자와 대화하고 MVP 상이 소프트웨어에 미치는 부정적인 영향을 지적하십시오. 당신이 그들을 무시하도록 만들거나 그렇게 큰 일을하지 않을 수 있는지 확인하십시오. 트로피를 서랍에두고 퇴근 후 팀을 위해 음료 한 잔에 현금 상을 보내고, 무료 점심 식사를 사용하여 컵 케이크처럼 공유 할 수있는 것을 얻으십시오. 애자일은 팀 시스템입니다. 팀을 서로 상대하는 개인의 성과 위험을 강조합니다. 유나이티드는 기한이 지난 후 예산이 부족한 버그로 가득 찬 소프트웨어를 출하했습니다.

이것은 특정 연습 (PVM으로서의 대중 인정)이 어떻게 팀의 행동에 중대한 영향을 미칠 수 있는지에 대한 전형적인 예입니다. 이는 인센티브, 동기 부여 및 보상을 넘어 환경 / 행동 심리학 및 의사 결정 아키텍처의 아이디어에 실제로 영향을 미칩니다. 멋진 것.

문제는 팀이 엄격한 정책을 세우거나 사람들이 무언가를하도록 강요하지 않고 자연스럽게 모든 일을 자연스럽게 처리 할 수 ​​있도록 프로세스를 어떻게 설계 할 수 있는가하는 것입니다.

팀에 적합한 프로세스를 설계하기위한 메커니즘으로 프로세스 에 대한 여유도 ( 도널드 노먼의 일상적인 사물 디자인 )를 사용하는 것에 대해 썼습니다 . 기본 아이디어는 프로세스의 관행이 사람의 행동에 직접 영향을 미친다는 것입니다. 따라서 프로세스의 여유가 팀의 가치와 완전히 일치하지 않으면 문제가 발생합니다.

이 주제에 대해 몇 가지 워크샵을 진행했으며이 특정 문제는 때때로 그룹으로 예를 들어 나타납니다. 질문에 공유 한 사건에 공제 이론을 적용하면 다음과 같이 보일 수 있습니다.

팀 가치 일관성, 예측 가능성 및 고품질 코드를 가정합니다.

관찰 한 부정적인 행동에 대한 세탁 목록이 있으며 모두 결함 메트릭을 사용하여 팀 MVP를 선택하는 것으로 보입니다. 예를 들어, 팀원들은 자연스럽게 버그를 선택하고 수정하여 세 가지 가치 모두에 부정적인 영향을 미치는 것으로 보입니다. (전에도 문제가 있다고 가정하고 이것이 MVP 아이디어로 이어졌습니다).

결함 메트릭을 기반으로 단일 MVP를 사용하는 대신 작지만 크게 변경하여 팀 동작을 변경하려고합니다.

• 누구나 팀의 가치를 입증 할 수있는 모든 개인에게 "팀 쿠도"를 제공하십시오. 이것은 예를 통해 팀 가치 시스템을 민주화하는 예측 성을 촉진 할 것입니다. (실제로 우리 팀에서이 작업을 수행합니다 ..)
• 모든 버그 수정에 대해 페어 프로그래밍을 시작하거나 "버그 버디"를 지정하십시오. 이는 급한 또는 반에 도움이되는 프로그래밍 결정을 권장하지 않고 품질을 향상시키고 친구가 불규칙한 행동을 유발할 수 있기 때문에 일관성을 권장합니다. (이 아이디어는 작업장에서 일반적으로 제안되며 직관적으로 보입니다 ..)

그리고 이것들은 접근 방식을 보여주고 시작하기위한 몇 가지 예입니다 ...

이 접근 방식의 가장 큰 장점은 프로세스 변경을 적극적으로 설계하고 있으며 프로세스 변경에 대한 정당한 이유가 있다는 것입니다. 객체 또는 UI 디자인과 마찬가지로 결과를 측정하여 작동하는지 여부를 이해할 수도 있습니다.

MVP 프로그램과 같은 기능을 보장하기 위해 가장 쉽게 조정하는 방법 중 하나는 팀 구성원이 가장 어려운 직원이 아니라 팀의 성공에 가장 가치있는 것으로 보상하는 것입니다.

우리는 버그 나 기능을 다루지 않았지만 팀의 모든 사람이 더 나은 성공을 거두는 멋진 사람들을 인식함으로써이를 성공적으로 수행했습니다. 예를 들어, 한 명의 개발자가 팀에 새로운 멤버를 멘토링하는 작업을 맡아 아키텍처와 작업 방식을 배울 수있었습니다. 한 명의 개발자가 팀의 나머지 부분을 돕는 데 더 많은 시간을 소비했기 때문에 개별 개발자의 속도가 줄어든 결과에도 신속하고 효율적으로 결과를 제공 할 수 있었기 때문에 속도가 향상되었습니다.

팀워크에게 보상하면 팀은 자신의 개인적인 성공이 아니라 중요한 팀임을 알 수 있습니다.