스크럼 : 동기 부여 처리

에 따르면 이 , "스크럼은 매우 높은 동기 부여, 밀접하게 협력, 간 기능과 자기 조직 팀에 의존합니다." 그렇다면 코드의 소유권을 가지려는 동기가없는 동료를 어떻게 처리합니까? 누군가 소유권을 얻는 데 어떻게 관심이 있습니까?

이것이 귀하의 팀의 문제인지는 모르겠지만 처음 스크럼을 도입했을 때의 문제였습니다. 우리 경영진은 언젠가 우리에게 와서 지금부터 당신은 개별 사일로에서 일하지 않을 것이라고 말했습니다. 대신 스크럼으로 작업하게됩니다. 여기에 당신이 따라야 할 많은 새로운 과정이 있습니다.

열쇠는 그들이 개발자, 우리에게 오지 않았고, 어떻게 일하고 싶어하는지 묻는 것입니다. 무엇을 더 행복하게 해줄까요? 더 효율적인?. 그래서 내가 들었던 것은 "더 이상 코드를 소유하지 않습니다. 작성한 모든 것이 짓밟 히게 될 것입니다 (팀 소유). 이제 우리는 시간별로 시간을 관리하기 때문에 손가락을 움직이거나 들지 않을 것입니다." 아 그리고 이제는 지루한 15 분마다 매일 사람들이 관심을 가지지 않는 것에 대해 토론하고 보통 30 분이 걸리고 2 주마다 우버 지루한 4 시간의 계획 회의를 가질 것입니다. 당신의 모든 삶.

실제로 이것은 애자일 또는 스크럼이 아니며, 이것은 하나의 관리 스타일에서 다른 스타일로 옮겨가는 것입니다. 여기서 모든 것이 여전히 중앙에서 제어되며, 모든 생명을 나에게서 빠뜨릴뿐만 아니라 많은 자유를 얻었습니다. 이력서를 업데이트 할 시간입니다.

지난 12 개월 동안 팀 관리자가 무언가 다른 것을 시도하기 위해 여러 번 로비를 한 후에 그는 실제로 제 제안을 받아 들였고, 우리는 매우 성공적인 한 해를 보냈다고 생각합니다.

우리에게있어 중요한 변화는 개발자들이 우리가 원하는 방식으로 작업 할 때 훨씬 더 많은 목소리와 자유를주는 것이 었습니다. 우리가 한 일 :

1. 큰 "민첩한"개발 팀을 3 개의 작은 팀으로 나누면 각 팀에는 3-4 명의 개발자 만 있습니다. 이것은 모든 사람이 참여하게하고 개인은 익사하지 않습니다.
2. 동일한 팀의 모든 사람이 동일한 기능 영역에서 작업하여 다른 사람들이 스탠드 업 및 반복 계획에서 이야기하는 내용에 관심을 갖도록하십시오.
3. 경영진이 단순히 누가 무엇을 다루는 지 이야기하고 과제 / 과제를 할당하는 대신 백 로그를 만들었고 팀 자체는 업무 분담 방식에 대해 많은 의견을 제시했습니다.
4. 우리는 새로운 회원이 많았 기 때문에 각자의 주요 책임 영역을 소유 한 사일로 시스템으로 시작했습니다. 이를 통해 새로운 사람들은 알 수없는 제품의 작은 영역에 집중할 수있게되었으며 다른 사람의 샌드 박스에서 놀고 있지 않다는 더 빠른 감각을 갖게되었습니다. 그러나 6 개월에서 8 개월이 지나면 그 지역은 점점 더 회색으로 변해 가기 시작했습니다. 이제 내가 속한 팀의 사람들은 다른 사람의 코드를 밟거나 다른 개발자가 자신의 작업을 수행하는 것이 상당히 편안합니다.
5. 모든 제출물에 대한 코드 검토가 핵심이었습니다 (그리고 이것이 처음 스크럼을했을 때 처음으로 넘어간 것입니다).
   • 프로그래밍 기술 / 방법 측면에서 지식 이전
   • 다른 사람들이 그렇지 않은 코드를 배우는 데 좋았습니다.
   • 팀은 의사 소통하고 사교를 할 수있는 기회를 얻습니다.
   • 그리고 코드 검토는 하나 또는 두 개의 버그를 잡을 것이라고 생각하지만, 위의 측면에서 대부분 그 가치를 봅니다.
6. 경영진은 팀의 의견을 경청해야합니다. 팀이 무언가가 효과가 없거나 변경이 필요하다고 말하면 단순히 팀원이 단순히 체크 아웃하여 경영진이 프로젝트를 처리하도록하는 것보다 무시합니다. 당신이 사람들에게 동기를 부여하고 싶다면, 그들은 조끼를 입어야하고, 그들이 옳은 것으로 행동하는 것이지, 맨 위에서부터하지 말아야 할 것이 아니라는 것만으로 조끼를 입을 것입니다.

동기 부여가없는 데에는 여러 가지 이유가 있지만 가장 일반적인 것은 당신이 말하는 것처럼 느끼지 않는 것입니다. 우리 팀이 스크럼을 시작했을 때 나는 회고전의 제안이 이행 된 후 스크럼에 대한 동기가 가장 적은 사람들이 돌아 섰다는 것을 알았습니다.

사소한 문제가 많이 발생하여 시범 적으로 진행될 수 있습니다. 예를 들어, 지난 주에 올라온 한 가지는 4시 회의를 좋아하지 않는 팀원이었습니다. 그것은 쉽게 고쳐집니다.

다시 말해, 팀에게 동기를 부여하는 것이 무엇인지 알아내는 가장 좋은 방법은 팀에 문의하는 것입니다.

그들에게 코드에 대한 개별 소유권을 부여함으로써.

많은 상점들이 "팀 소유권"모델로 작업합니다. 이는 상호 협업 및 위험 감소에는 좋지만 개인이 개인적으로 책임을 지도록 동기를 부여하는 데는 좋지 않습니다. 개인 소유 인센티브가 없기 때문에 팀 소유는 평균 코드를 초래할 수 있습니다.

해결 방법 : 코드의 각 부분에 개인을 할당하여 코드의 해당 부분을 관리 할 수는 있지만 팀 전체가 코드 전체에 액세스 할 수 있도록하십시오.

참조 : https://softwareengineering.stackexchange.com/a/33464/1204