애자일 팀에서 수석 개발자의 역할은 무엇입니까?

민첩하지 않은 개발 팀에서 수석 개발자는 일반적으로 다음과 같습니다.

• 표준 설정 (코딩 등)
• 팀을위한 새로운 기술 연구
• 팀의 기술 방향을 설정합니다
• 문제에 대한 최종 발언
• 시스템의 아키텍처를 설계

그러나 민첩한 팀은 다르게 작동합니다.

• 애자일 팀은 선구적인 것이 아니라 새로운 디자인에 의존합니다
• 한 사람이 디자인 한 것이 아니라 애자일 팀이 함께 디자인
• 민첩한 팀이 프로젝트를 전달하는 데 가장 적합한 자체 기술 방향을 결정합니다.

이것이 애자일 팀의 수석 개발자를 어디로 남겨 줍니까? 애자일 팀에 수석 개발자가있을 수 있습니까? 민첩한 팀은 리더와 다른 책임을 요구합니까?

애자일에는 리드 개발자의 기능이 바뀌지 않습니다. 어떤 개발 모델을 따르 든 시스템 아키텍처 결정 및 기술적 인 방향으로 팀의 나머지 부분을 참여시켜야합니다.

칙령으로 의사 결정을 전달하는 것은 모든 개발 팀이 운영하는 끔찍한 방법입니다. 애자일은 팀의 나머지 부분에서보다 명확한 프로세스를 구매하기 만한다면, 선임 개발자는 어쨌든 그렇게해야했습니다.

스크럼 방법론에 정해진 개발자 역할이 없다고해서 더 숙련 된 프로그래머의 의견이 가장 존중받지 못한다는 의미는 아닙니다. 애자일은 모든 사람이 자신의 일에 열중하지 못하게 한 다음 모든 것을 고수하려고하지만 여전히 통일 된 비전과 방향을 설정해야합니다.

민첩한 팀에서는 모든 사람이 자아를 제쳐 놓아야합니다.

애자일 팀의 한 구성원이 다른 팀보다 더 많은 경험을 가지고 있다면 경험이 풍부한 구성원이 대부분의 코드 검토에 참여하고 사람들은 팀 결정을 내릴 때 종종 해당 사람의 경험을 연기하게됩니다.

따라서 "리드 (lead)"개발자는 "리딩 (lead)"을 계속할 것이나 경험의 자연스러운 결과이며 의무적 인 기능이 아닙니다.

사람들이 자아를 버릴 수있는 이상적인 세상에 있습니다. 행운을 빕니다!

Ryathal의 답변 외에도 :

마치 팀에서 나오는 것처럼 완벽한 디자인과 팀 방향에 대해 완벽하게 조화를 이룹니다. 사람 그룹, 프로그래머 그룹은 특히 충돌 합니다. 팀장이 이끌면 민첩한 팀에서의 업무는 폭포보다 심판이나 촉매제에 가깝습니다. 예를 들어 팀이 어떤 디자인을 사용해야하는지에 대해 갈등을 겪게되면 사람들이 동등한 가치를 지니고 장점에 대해 논쟁해야합니다. 그리고 당신은 경로가 명확하지 않을 때 팀이 제안 할 솔루션을 중재 할 중재자가됩니다.

이것은 리드의 가장 중요한 책임 중 하나이지만 많은 사람들을 팀으로 만들려면 많은 다른 것들이 필요합니다. 좋은 코딩이 진행되는 한 예제를 설정해야하며 종종 직접 또는 문화를 만들어서이를 시행해야합니다. 하루에 한 번 일 어설 때도 모든 팀원들 사이의 의사 소통을 촉진해야합니다.

간과 한 또 다른 중요한 것은 회의입니다. 팀이 비즈니스맨, 다른 기술 팀 등과 상호 작용해야하는 모든 회의에 전체 팀을 배치하는 것은 비현실적입니다. 팀장이되면 귀하는 팀의 대표입니다. 회의에 참석하여 책상에 머무르고 업무를 수행 할 수 있습니다. 사람들이 직접 들러서 방해받지 않도록 연락하는 지점입니다. 그리고 외부 세계 (다른 팀이 진행중인 작업, 민첩한 팀이 다음 스프린트로 보이는 모습, 공개 요구 사항의 상태 등)에서 정보를 가져 와서 비등하고 의사 소통하기 위해 노력합니다.

요컨대, 윤활유가 매끄럽게 작동 할 수 있도록합니다.

민첩하지 않은 설명은 민첩한 설명을 무효화하지 않습니다.

민첩한 팀은 선구적인 것이 아니라 새로운 디자인에 의존합니다.

리드 개발자에 대한 귀하의 정의에 대해서는 디자인이 선행되어야한다고 말하는 것은 없습니다. 그는 방향을 정해도 여전히 초기 디자인을 배치 할 수 있습니다. 그 디자인은 분명히 등장합니다.

한 사람이 디자인 한 것이 아니라 애자일 팀이 함께 디자인

리드 개발자에 대한 당신의 정의에 대해서는 그가 디자인 을 지시 한다고 아무 것도 말하지 않습니다 . 비록 최종 결정을 내릴 수도 있지만 , 열악한 팀장 만이 그의 대다수 팀원들의 생각을 완전히 무시할 것입니다. 반면에, 가난한 팀만이 수석 개발자의 생각을 완전히 무시할 것입니다.

민첩한 팀이 프로젝트를 전달하는 데 가장 적합한 자체 기술 방향을 결정합니다.

다시 말하지만 리드가 처음 에이 방향을 설정 하지 않았다는 의미는 아닙니다 . 리드는이 민첩한 팀의 일부입니다. 민첩하지 않은 환경에서도, 팀이 의도적으로 실현 불가능하거나이 정보를 무효화하기 위해 새로운 정보가 제시된 경우에는 팀의 지시에 따라 계속 진행할 것입니다.

이 질문은 몇 가지 다른 질문을 제기합니다. 동료 소프트웨어 엔지니어 팀에게 무엇을해야 할 자격이 있다고 생각하십니까? 당신의 경험입니까? 상사가 당신에게 건네주는 재미있는 작은 제목입니까? 당신의 자아입니까? 회사에서 재임 했습니까? 당신의 "파 나치"입니까? 당신의 "스타일?" "리더십 기술?"

애자일 팀은 "축하합니다. 당신은 우리의 슈퍼 천재입니다. 당신은 비밀의 이중 천재 작업을 할 수있는 유일한 사람입니다." 오히려, 초점은 '작업 중'입니다. 실제로 더 많은 경험이 있다면, 그 경험이 당신의 디자인이 작업을 완성을 향해 얼마나 잘 추진하는지 보여 주어야합니다. 자신이 선택한 과제 (카드)는 가장 전문적인 분야를 반영해야합니다. 반면에, 대학을 졸업 한 어린이가 더 좋은 아이디어를 가지고 있고 40 년의 베테랑이 등장하는 것보다 상황에 더 잘 맞다면 왜 지구상에서 더 나쁜 디자인으로 갈까요? 우리의 직장은 치료실이 아닙니다. 그들은 우리가 위대한 일을 할 곳입니다.

또 다른 질문이 생겼습니다. 누가 "더 나은"의미를 결정하게 될까요? 답은 이해 관계자 팀입니다. 즉, 문제의 빌더 및 사용자 인 개발자, 요구 사항 사람, 테스터, 비즈니스 사람 등을 의미합니다. 좋은 아이디어가 있다면 왜 더 나은지 잘 설명 할 수 있습니다. 그렇게 할 수 없다면, 팀이 당신의 아이디어가 더 낫다고 믿을 이유가 없습니다. 민첩성은 자비주의를 장려합니다.

"개발 팀장"은 어떻게 되나요? 민첩하게? 그 이름에 더 잘 부합하는 것은 아무것도 없습니다. 팀원들보다 더 나은 소프트웨어를 실제로 생산할 수있는 것이 더 좋습니다. 그렇지 않으면, 그것들을 "리드 (lead)"라고 부를 이유가 없습니다. 단지 작은 배지나 재미있는 모자 일 뿐이며 의미가 없습니다. 많은 사람들이이 위협을 느낍니다. 그들은 배지 또는 재미있는 모자를 "작업"한 것처럼 느낍니다. 좋은 개발자는 재미있는 모자를 쓰지 않습니다. 그들은 훌륭한 소프트웨어를 개발하기 위해 노력하고 있으며, 궁지에 빠질 때까지 계획을 세웁니다. 그들의 목표는 매일 소프트웨어를 더 잘 구축하는 것입니다. 그렇지 않은 경우 프로젝트 관리를 살펴볼 수 있습니다. 아마도 더 행복 할 것입니다.

애자일에 대한 저의 경험에서 개발 팀 전체가 귀하의 사례보다 더 적은 책임을지게되므로, 수석 개발자와 건축가는 최상위 디자인 선택을 조정하지만, 하위 레벨 디자인은 애자일 팀 전체에 넘겨줍니다.

따라서 수석 개발자는 시스템 아키텍처 및 기술 선택에 대한 책임이 있습니다. 이것은 매우 중요합니다. 민첩한 디자인은 창발적인 디자인을 권장하고 리팩토링은 코드 객체 수준에서 일어나야합니다. 시스템 은 전체적으로 더 높은 수준의 사전 설계와 강성을 가져야하며 그렇지 않으면 프로젝트가 조정되지 않은 혼란에 빠질 위험이 있습니다.

프로젝트에서 수석 개발자는 기술 선택을 지시하고 시스템 구성 요소가 서로 상호 작용하는 방식을 설계했습니다. 민첩한 계획 회의는 상위 과제 내에서 이러한 구성 요소를 설계하는 방법에 중점을 두었습니다. 유쾌한 일로, 이는 다른 계획 회의에서 범위 제한을 유지합니다.

그는 또한 최후의 수단으로 기능했습니다. 개별 프로그래머들이 고칠 수없는 문제에 부딪쳤을 때, 그들은 리드로 가서 문제를 해결하는 최종 책임은 그의 책임이었습니다.