Em uma equipe de desenvolvimento não-ágil, um desenvolvedor líder geralmente :
- Define o padrão (codificação e outros)
- Pesquisa novas tecnologias para a equipe
- Define a direção técnica da equipe
- Tem a palavra final sobre assuntos
- Projeta a arquitetura de um sistema
No entanto, uma equipe ágil trabalha de maneira diferente:
- Uma equipe ágil confiará no design emergente, e não na frente
- Uma equipe ágil projeta em conjunto, em vez de o design ser ditado por uma pessoa
- Uma equipe ágil decide por sua própria direção técnica, o melhor para entregar um projeto
Onde isso deixa um desenvolvedor líder em uma equipe ágil? É possível ter um desenvolvedor líder em uma equipe ágil? Uma equipe ágil exige responsabilidades diferentes de um líder?
design
architecture
agile
scrum
team-leader
Peter Bridger
fonte
fonte
Respostas:
Nada no ágil muda a forma como o desenvolvedor líder deve funcionar. Eles devem envolver o restante da equipe com as decisões de arquitetura do sistema e a direção técnica, independentemente do modelo de desenvolvimento que está sendo seguido.
Distribuir decisões por decreto é uma maneira terrível de qualquer equipe de desenvolvimento executar. O Agile apenas torna a compra do restante da equipe um processo mais explícito, e um desenvolvedor líder deveria estar fazendo isso de qualquer maneira.
Só porque não há um papel de desenvolvedor líder definido em uma metodologia scrum, não significa que as opiniões dos programadores mais experientes não sejam as mais respeitadas. O Agile não está deixando todo mundo enlouquecer por conta própria e, em seguida, tentando juntar tudo, ainda há uma visão e direção unificadas que precisam ser definidas.
fonte
Em uma equipe ágil, todos devem colocar seus egos de lado.
Se um membro de uma equipe ágil tem mais experiência do que os outros, o que provavelmente acontecerá é que o membro experiente estará envolvido na maioria das revisões de código e as pessoas frequentemente se depararão com a experiência dessa pessoa ao tomar decisões de equipe.
Portanto, um desenvolvedor "líder" continuará "liderando", mas como uma consequência natural de sua experiência e não como uma função obrigatória de seu título.
É em um mundo ideal onde as pessoas podem colocar seus egos de lado. Boa sorte!
fonte
Além da resposta de Ryathal :
Você fala sobre design emergente e direção da equipe como se eles fluíssem da equipe em perfeita harmonia e harmonia. Grupos de pessoas, grupos de programadores, especialmente, têm conflitos . Como líder da equipe, seu trabalho em uma equipe ágil é mais um árbitro ou catalisador do que em cascata. Quando a equipe entrar em conflito sobre qual design usar, por exemplo, você garantirá que as pessoas tenham a mesma opinião e continuem discutindo por méritos. E você acaba sendo o árbitro para qual solução proposta a equipe seguirá quando o caminho não estiver claro.
Essa é uma das responsabilidades mais importantes do líder, mas muitas outras coisas são necessárias para transformar um monte de gente em uma equipe. Você ainda precisa dar um exemplo no que diz respeito à boa codificação e, muitas vezes, impor isso (diretamente ou criando uma cultura para isso). Você precisa facilitar a comunicação entre todos os membros da sua equipe, porque uma vez por dia em stand-up não será suficiente.
A outra coisa importante que você ignorou são as reuniões. É impraticável levar a equipe inteira a todas as reuniões em que a equipe precisa interagir com pessoas de negócios, outras equipes técnicas, etc. Como líder da equipe, você é o representante da equipe. Você vai às reuniões para que eles possam ficar em suas mesas e fazer as coisas. Você é o ponto de contato para que não sejam interrompidos por pessoas que param diretamente. E você trabalha para obter informações do mundo exterior (em que outras equipes estão trabalhando, como são as equipes ágeis no próximo sprint, qual é o status desse requisito aberto, etc.), reduzi-las e comunicá-las.
Em resumo, você é o lubrificante para garantir que eles funcionem sem problemas.
fonte
Sua descrição não-ágil não invalida sua descrição.
Nada na sua definição de desenvolvedor líder diz que o design deve ser antecipado. Ele pode definir a direção e ainda pode traçar um desenho inicial. Esse design é definitivamente emergente.
Nada na sua definição de desenvolvedor líder diz que ele determina o design. Embora ele possa ter a palavra final, apenas uma liderança ruim desconsideraria completamente os pensamentos de seus companheiros de equipe majoritários. Por outro lado, apenas uma equipe ruim desconsideraria completamente os pensamentos do desenvolvedor líder.
Novamente, isso não significa que o lead não defina inicialmente essa direção. A liderança faz parte dessa equipe ágil. Mesmo em um ambiente não-ágil, apenas uma liderança ruim continuaria a liderar uma equipe nessa direção quando ela se tornasse conscientemente inviável ou quando novas informações fossem apresentadas para invalidar essa direção.
fonte
A pergunta sugere algumas outras perguntas. O que você acha que o qualifica a dizer a uma equipe de colegas engenheiros de software o que fazer? É a sua experiência? É o título engraçado que seu chefe lhe deu? Esse é o seu ego? Seu mandato na empresa? É o seu "panache?" Seu estilo?" Suas "habilidades de liderança?"
As equipes ágeis não entregam crachás ou chapéus uns aos outros que dizem: "Parabéns, você é nosso super gênio - você é o único autorizado a fazer um trabalho super secreto de gênio duplo". Em vez disso, o foco é o trabalho em mãos. Se você é realmente mais experiente, essa experiência deve mostrar como seus projetos levam o trabalho adiante para a conclusão. Suas tarefas (cartões) escolhidas por você devem refletir as áreas nas quais você é mais especialista. Por outro lado, se algum garoto recém-formado tiver uma idéia melhor e se encaixar melhor no contexto do que algo que um veterano de 40 anos venha à tona com, por que diabos iríamos com o design mais pobre? Nossos locais de trabalho não são escritórios de terapia - eles são onde construímos grandes coisas.
Isso levanta outra questão: quem decide o que significa "melhor"? A resposta: a equipe de partes interessadas. Isso significa que os desenvolvedores, pessoas de requisitos, testadores, pessoas de negócios etc., que são os construtores e usuários da coisa em questão. Se você tem uma ótima ideia, é melhor demonstrar por que é melhor. Se você não pode fazer isso, não há razão para a equipe acreditar que sua ideia é melhor. O Agile incentiva a meritocracia.
Então, o que acontece com o "líder da equipe de desenvolvimento?" em ágil? Nada - eles apenas cumprem esse nome - é melhor que REALMENTE sejam capazes de produzir software melhor do que as outras pessoas da equipe. Caso contrário, não há razão para chamá-los de "lead" - é apenas um pequeno crachá ou chapéu engraçado e não faz sentido. Muitas pessoas acham isso ameaçador. Eles sentem que estão "trabalhando para" um distintivo ou chapéu engraçado. Bons desenvolvedores não trabalham com chapéus engraçados. Eles trabalham para criar um ótimo software e planejam fazê-lo até coaxar - seu objetivo é melhorar a construção de software todos os dias. Se não é você, talvez você queira investigar o gerenciamento de projetos. Você provavelmente ficará mais feliz.
fonte
Na minha experiência com o Agile, a equipe de desenvolvimento como um todo tem menos responsabilidade do que os seus exemplos sugerem, deixando o desenvolvedor e o arquiteto coordenarem as opções de design de nível superior, mas entregando o design de nível inferior para a equipe ágil como um todo.
Portanto, o desenvolvedor líder permanece responsável pela arquitetura do sistema e pelas opções de tecnologia. Isso é muito importante: embora o ágil incentive o design e a refatoração emergentes, isso deve estar acontecendo no nível dos objetos de código. O sistema como um todo precisa ter um nível maior de pré-design e rigidez, caso contrário o projeto corre o risco de se tornar uma bagunça descoordenada.
Em nosso projeto, o desenvolvedor líder determinou as opções de tecnologia e projetou como os componentes do sistema interagem entre si. As reuniões de planejamento ágil focavam em como projetar esses componentes dentro de seus mandatos de nível superior. Como um aspecto agradável, isso mantém um limite para as reuniões de planejamento cansativas.
Ele também funcionou como o ponto de último recurso. Quando programadores individuais encontravam problemas que não conseguiam resolver, eles assumiam a liderança e a responsabilidade final por consertar as coisas era dele.
fonte