Qual é o papel do desenvolvedor líder em um time ágil?

40

Em uma equipe de desenvolvimento não-ágil, um desenvolvedor líder geralmente :

  • Define o padrão (codificando e de outra forma)
  • 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 dependerá de um design emergente, em vez de antecipar
  • Uma equipe ágil cria projetos juntos, em vez de design sendo ditado por uma pessoa
  • Uma equipe ágil decide sua própria direção técnica, o que é 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 lead?

    
por Peter Bridger 23.04.2014 / 13:46
fonte

6 respostas

44

Nada em alterações ágeis como o desenvolvedor líder deve funcionar. Eles devem envolver o restante da equipe com decisões de arquitetura do sistema e orientação técnica, independentemente do modelo de desenvolvimento que está sendo seguido.

Distribuir decisões por edital é uma maneira terrível de qualquer equipe de desenvolvimento executar. Agile apenas faz com que a compra do resto da equipe seja mais explícita, e um desenvolvedor líder deveria ter feito isso de qualquer maneira.

Só porque não há um papel de desenvolvedor principal em uma metodologia scrum, não significa que as opiniões de programadores mais experientes não sejam as mais respeitadas. Ágil não é deixar todos enlouquecerem e, em seguida, tentar juntar tudo, ainda há uma visão unificada e uma direção que precisa ser definida.

    
por 23.04.2014 / 14:27
fonte
30

Em uma equipe ágil, todos devem deixar seus egos de lado.

Se um membro de uma equipe ágil tiver 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 adiarão a experiência dessa pessoa ao tomar decisões da equipe.

Assim, 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.

Isso é em um mundo ideal onde as pessoas podem deixar seus egos de lado. Boa sorte!

    
por 23.04.2014 / 14:18
fonte
20

Além da resposta do Ryathal :

Você fala sobre o design emergente e a direção da equipe como se fluissem da equipe em perfeita harmonia e harmonia. Grupos de pessoas, grupos de programadores, especialmente, têm conflito . Como a equipe lidera, seu trabalho em um time ágil é mais um árbitro ou um catalisador do que em cascata. Quando a equipe tiver conflitos sobre o design a ser usado, por exemplo, você se certificará de que as pessoas tenham o mesmo palavreado e concordem em discutir os méritos. E você acaba sendo o árbitro para qual solução proposta a equipe seguirá quando o caminho não estiver claro.

Esta é uma das responsabilidades mais importantes do líder, mas muitas outras coisas são necessárias para transformar um grupo de pessoas em uma equipe. Você ainda precisa dar um exemplo até onde vai a boa codificação e, muitas vezes, impor isso (seja diretamente ou criando uma cultura para isso). Você precisa facilitar a comunicação entre todos os membros de sua equipe, porque uma vez por dia em pé não vai cortá-lo.

A outra coisa importante que você esqueceu é de reuniões. É impraticável trazer toda a equipe para 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 elas possam ficar em suas mesas e fazer as coisas. Você é o ponto de contato para que eles não sejam interrompidos por pessoas parando diretamente. E você trabalha para obter informações do mundo exterior (em que outras equipes estão trabalhando, quais são as equipes ágeis no próximo sprint, qual é o status dessa requisição aberta, etc), reduzi-las e comunicá-las.

Em suma, você é o lubrificante para garantir que eles funcionem sem problemas.

    
por 23.04.2014 / 14:57
fonte
6

Sua descrição não-ágil não invalida sua descrição ágil.

An agile team will rely on emergent design, rather than up front.

Nada sobre a sua definição de desenvolvedor líder diz que o design deve ser feito antecipadamente. Ele pode definir a direção e ainda pode apresentar um projeto inicial. Esse design é definitivamente emergente.

An agile team designs together, rather than design being dictated by one person

Nada sobre sua definição de desenvolvedor líder diz que ele dita design. Embora ele possa ter a palavra final, apenas uma liderança fraca desconsideraria totalmente os pensamentos de seus companheiros de equipe majoritários. Por outro lado, apenas uma equipe ruim ignoraria totalmente os pensamentos do principal desenvolvedor.

An agile team decides on their own technical direction, which is best to deliver a project

Novamente, isso não significa que o lead não define inicialmente essa direção. O lead faz parte dessa equipe ágil. Mesmo em um ambiente não-ágil, apenas uma liderança fraca continuaria a marchar uma equipe nessa direção quando se tornasse conscientemente inviável, ou quando novas informações fossem apresentadas para invalidar essa direção.

    
por 23.04.2014 / 16:07
fonte
5

A pergunta levanta algumas outras questões. O que você acha que o qualifica para dizer a uma equipe de colegas engenheiros de software o que fazer? É a sua experiência? É o pequeno título engraçado que seu chefe lhe deu? É o seu ego? Seu mandato na empresa? É o seu "panache?" Seu estilo?" Suas "habilidades de liderança"?

As equipes ágeis não distribuem crachás ou bonés um para o outro dizendo "Parabéns, você é o 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 à mão. Se você é realmente mais experiente, então essa experiência deve mostrar o quão bem seus projetos levam o trabalho para a conclusão. Suas atribuições auto-escolhidas (cartões) devem refletir as áreas que você é mais especialista em. Por outro lado, se algum garoto fora da faculdade tem uma idéia melhor, e se encaixa no contexto melhor do que algo que surge um veterano de 40 anos com, por que diabos iríamos com o design mais pobre? Nossos locais de trabalho não são consultórios terapêuticos - eles são onde chegamos para construir grandes coisas.

Isso levanta outra questão: quem decide o que significa "melhor"? A resposta: a equipe de stakeholders. Isso significa que os desenvolvedores, pessoas de requisitos, testadores, pessoas de negócios, etc., são os criadores e usuários da coisa em questão. Se você tiver uma ótima ideia, é melhor demonstrar por que ela é melhor. Se você não pode fazer isso, então não há razão para a equipe acreditar que sua ideia é melhor. Ágil incentiva a meritocracia.

Então, o que acontece com o "líder da equipe de desenvolvimento?" em ágil? Nada - eles simplesmente são melhores para esse nome - eles são realmente capazes de produzir um software melhor do que as outras pessoas da equipe. Caso contrário, não há razão para chamá-los de "chumbo" - é apenas um pequeno distintivo ou chapéu engraçado, e não tem sentido. Muitas pessoas acham isso ameaçador. Eles se sentem como se estivessem "trabalhando para" um distintivo ou chapéu engraçado. Bons desenvolvedores não trabalham para chapéus engraçados. Eles trabalham para construir um ótimo software, e planejam fazê-lo até que se atrapalhem - seu objetivo é melhorar a produção de software todos os dias. Se não é você, talvez você queira investigar o gerenciamento de projetos. Você provavelmente será mais feliz.

    
por 23.04.2014 / 23:39
fonte
2

Na minha experiência do Agile, a equipe de desenvolvimento como um todo recebe menos responsabilidade do que os seus exemplos sugerem, deixando que o desenvolvedor principal e o arquiteto coordenem as escolhas de design de alto nível, mas distribuindo design de nível mais baixo para a equipe ágil. um todo.

Assim, o desenvolvedor líder permanece responsável pela arquitetura do sistema e pelas opções de tecnologia. Isso é muito importante: embora o agile incentive o design emergente e a refatoração, isso deve estar acontecendo no nível dos objetos de código. O sistema como um todo precisa ter maior nível de pré-projeto 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 escolhas tecnológicas e projetou como os componentes do sistema interagem entre si. Reuniões de planejamento ágeis focaram em como projetar esses componentes dentro de seus mandatos de nível superior. Como um aparte agradável, isso mantém um limite máximo em reuniões de planejamento de outra forma cansativas.

Ele também funcionava como o último recurso. Quando programadores individuais se deparavam com problemas que não conseguiam consertar, eles assumiam a liderança e a responsabilidade final de consertar as coisas era dele.

    
por 24.04.2014 / 10:52
fonte