나는 다른 사람들이 이미 좋은 대답을했다고 생각하지만 팀이 방금 Scrum으로 전환했다고 생각하기 때문에 내 것을 추가 할 것입니다.
먼저 애자일과 스크럼에 대한 소개는 그다지 부드럽 지 않았습니다. 기본적으로 경영진이 내려 와서 오늘부터 당신은 스크럼을 할 것이며 이것은 당신이 따라야 할 과정입니다. 프로세스를 능가 하는 사람들에게 많은 것들 .
우리가 처음에했던 과정 (맹목적으로, 나는 덧붙일 수도있다)은 당신이 묘사 한 것과 매우 비슷했다. 사람들은 할당 된 작업을 받고, 모든 사람들이 예약을 받고, 우리 모두 책상으로 돌아가 플러그를 꽂습니다. 그런 다음 매일 지루한 회의가 있습니다.
중요한 것은 Agile과 Scrum이 실제로 사람들에 관한 것입니다. 팀이 반복 계획을 세울 때 Scrum 마스터 (아마도 관리자 인)가 시간, 스토리 및 작업을 할당하지 못하게하십시오. 완전히 팀에 달려 있습니다. 나는 많은 사람들에게 이것이 달성하기가 매우 어려운 개념이라고 생각합니다. 왜냐하면 그들은 몇 년 전에 일하러 왔고 단순히 업무를 배정 할 보스 (관리자, 기술 책임자)가 있었기 때문입니다. 그들은 스크럼으로 뛰어 들지만 모든 사람 (스크럼 마스터 자신을 포함하여)은 동일한 모드로 계속 작동합니다.
언젠가는 이것에 질려서 책, 블로그를 읽고 스택 교환에서 이와 같은 질문을 계속합니다. 얻을 수있는 사실은 개발자와 팀원으로서 이야기를하고 과제를 할당하는 원동력이되어야한다는 것입니다. 여러분이 페어 프로그래밍의 혜택을 누리게 될 것 같으면 반드시 각 엔지니어에 대해 2 개의 작업을 생성하고 두 시간을 모두 할당하십시오. 스크럼 마스터가 수행해야 할 유일한 것은 이전 반복에서 TEAM으로 제공 한 완료된 스토리에 대한 속도를 측정하는 것입니다.
또한 나에게 쓰레기를 버리는 또 다른 것은 사람들이 자신의 능력이 항상 총 시간의 75 %라는 것을 말하는 방법입니다. 나에게 도움을 준다. 또는 b) 너무 많은 시간이 할당되어 올바른 일을 할 수 없다. 스크럼 마스터가 이런 식으로 무언가를 가져 오려고 할 때 사람들은 얼마나 많은 시간을 할애해야하는지 이야기해서는 안됩니다. 모든 사람들은 자신이 편안하게 느끼는 것에 전념해야합니다. 예를 들어, 나는 팀 리더이며 계획되지 않은 임의의 디자인 토론이나 코드를 사용하거나 누군가를 도와 문제를 해결하는 경우가 종종 있으므로 내 용량은 절대 50 %를 넘지 않습니다.
방금 언급 한 작업을 수행하지 않는 방법을 배우기 위해 팀 4 릴리스주기가 걸렸습니다. 전문가에게 문의하면 반 민첩하지 않습니다. 그래도 여전히 많은 학습이 필요합니다.
업데이트 1 : Cliff의 의견에 대한 답변
글쎄 당신은 여기에 귀를 제공했습니다 ...
문화적 변화가 핵심이지만이 변화가 경영진 수준에서 일어날 필요는 없습니다. 자신의 그룹 관리자는 팀 내 문화를 바꾸고 그가 다루어야 할 회사 BS와 분리시킬 수 있습니다. 2007 년부터 2010 년까지 정확히 우리에 대해 설명했습니다. 우리 팀 (및 다른 팀도)은 릴리스 후 릴리스를 중단했습니다. 경영진의 "민첩성 프로세스"를 사용하는 릴리스 중 하나에서 우리는 한 사람이 일반적으로 수행 할 작업을 9 명으로 만들도록했으며 두 배의 시간이 걸렸습니다. 나는 자유 시간이 너무 많아서 이력서를 업데이트하기까지했다.
그런 다음 상사와 대화를 나누고 사람들에 대해 민첩한 것이 무엇인지 설명하고 제품에 대해 관심을 가지려면 제품 작업 및 배송 방법에 영향을 미치는 결정을 내릴 수 있다고 설명했습니다. 나는 그가 그것을 실험으로하기로 결정했다고 생각합니다. 그는 모든 단일 변화를 만들었습니다 ... 대부분은 저 자신이지만, 나머지 팀과 많이 이야기하므로 50 % 용량 :) ... 제안되었습니다. 그가 우리가 요구하는 모든 변경을하고도 여전히 실패한다면, 그는 "나는 당신에게 그렇게 말한 것"으로 승리 할 것이라고 생각할 수도 있습니다.
지난 12 개월 동안, 우리는 "멍청한"것을 많이 제거했습니다. 우리의 독립 회의는 우리가 고립 된 것이 아니라 함께 일하기 때문에 실제로 의미가 있습니다. 우리는 여전히 제품의 특정 부분에 대한 소유권을 보유하고 있지만 서로의 코드를 자주 공유합니다. 우리는 지속적으로 코드 검토를 수행하여 팀 구성원이 다른 코드를 배울뿐만 아니라 더 나은 코딩 및 디자인 기술을 배울 수 있습니다. 우리는 모 놀리 식의 거대한 "민첩한"팀을 3 개의 서로 다른 팀으로 나누었으므로 계획 및 기타 회의는 훨씬 짧으며 사람들은 주위에 앉아 관심이없는 것에 대해 들지 않기 때문에 실제로 관심을 갖습니다. 나는' 우리 밤에 5 명 중 4 명 (팀 중 하나)이 밤 11시에 온라인에있을 때 아무도 보지 못했고 실제로 아무도 우리가 열심히 일하거나 40 시간 이상 일하라고 압력을가했다고 말하지 않았습니다. 반년 전에 관심이 없었던 사람들은 갑자기 그들이하고있는 일에 열광하고 흥분합니다. "관리자가해야 할 일은 옳은 일을 결정하고 필요한 조치를 취하면 회사 BS를 가능한 한 많이 팀에서 제외시킬 것입니다."라고 말했습니다.
그것은 실험으로 시작되었습니다 (내 의심, 그는 저에게 말하지 않았습니다). 그러나 이제 우리 그룹은 부서의 다른 개발 그룹과 비교하여 엉덩이를 차고 있습니다.
이러한 변화가 일어 났을 때 (그리고 오늘날에도 여전히 문제가 됨) 우리에게 가장 큰 장애물은 정상적인 회사 환경의 엔지니어들이 우리 안의 실험용 쥐와 같다는 사실이었습니다. 관리자가 진정으로 "민첩한"상태로 가고 새장을 제거하기로 결정하더라도 모든 사람이 그 새장에 오랫동안 존재 해 왔으며 심지어 자신들이 자유 롭다는 사실조차 알지 못합니다. 따라서 모든 자유에도 불구하고 그들은 여전히 구속 된 것처럼 행동합니다. 팀의 경계를 벗어나서 더 나은 방법을 찾는 팀 구성원 (예 : 자신과 같은 사람)이 최소한 몇 명은 도움이 될 것이라고 생각합니다. 그 그룹으로 돌아와서 조금 저어주세요.
귀하의 경우, 팀에 내려 와서 작업 방법을 알려주는 다른 외부 세력을 찾고 있다면 페어링 된 프로그래밍이 해결책이 아닐 수도 있습니다. 대신, 규칙을 버리고 관리하지 않고 규칙을 세우고 그들이 원하는 것을 물어보십시오. 무엇이 그들을 행복하게 할 것입니까? 생산적인? 가장 큰 문제를 파악한 다음 팀에게 그들이 어떻게 생각해야하는지 물어보십시오.