O que faço quando meu líder de equipe está quebrando meu esquema de banco de dados com uma liberação chegando?

Meu líder de equipe tem esse péssimo hábito de mexer no esquema do banco de dados e fazer alterações que causariam graves falhas na base de código (sem realmente me consultar sobre como as alterações afetariam a base de código).

Normalmente, eu viveria com isso, mas temos um prazo em duas semanas e isso acontece desde que comecei, há 1 mês e meio. Fui criado para acelerar o desenvolvimento do projeto.

Devido ao prazo, já estou gastando mais de 60 horas por semana e não tenho mais energia para lidar com isso (tentei de algumas maneiras). Somos apenas uma equipe de dois homens e, além de alterar o banco de dados diariamente, ele não contribuiu muito no sentido de desenvolvimento real (codificação).

Atualmente, sinto que estou fazendo todo o trabalho, além de ter que "consertar" o que ele quebra com suas alterações.

Como alguém lida com isso? Já falei com nosso gerente sobre sua falta de esforço no departamento de desenvolvimento. Ele está lá há seis meses mais do que eu, mas escrevi 95% do código quando você exclui a 5ª monstruosidade normal do banco de dados de formulário que ele 'contribuiu'.

Alguma sugestão?

Post-mortem:

Na sexta-feira, tivemos uma discussão com o gerente, e eu fiz minhas preocupações serem conhecidas. Isso levou a um pouco de confronto, mas no geral eu senti que o gerente estava do meu lado. Então, pelo menos, temos nossos dados congelados agora, vamos ver como eles vão daqui.

"O prazo é daqui a duas semanas; precisamos congelar o esquema se quisermos atingi-lo".

Falando com o gerente E o desenvolvedor na mesma reunião:

"As alterações no banco de dados e no código precisam aparecer simultaneamente. Se você alterar o banco de dados, também deverá alterar e testar a base de código. Caso contrário, você estará enviando confirmações quebradas, o que é inaceitável se cumprirmos o prazo. Não corrigirei mais o código quebrado por seus commits, simplesmente restaurarei as alterações e deixarei uma nota por e-mail, porque não posso investigar e corrigir problemas fora do trabalho que me foi atribuído e ainda espero cumprir o prazo ".

Muito mais difícil se você não tiver um plano de teste ...

Você precisará ser mais vigoroso e garantir que, em breve (como ontem, anteontem ou no mês passado), decida um esquema e avance. Não há uma maneira sensata de continuar desenvolvendo um aplicativo com um banco de dados que é um alvo em movimento.

Você precisa confrontá-lo e explicar como suas alterações estão afetando a base de código e, portanto, as linhas de tempo do projeto. Convença-o de que ele precisa considerar o impacto de suas alterações antes de efetuá-las. Também faça com que ele concorde na presença de seu gerente com o fato de que ele será responsável por quaisquer atrasos que induzir por esse comportamento

Se o líder da equipe não for uma pessoa razoável (e não parecer razoável com a descrição do comportamento dele), converse com seu gerente e explique-lhe que você não cumprirá o prazo com o andamento das coisas. Peça a ele que se posicione e verifique se o líder da equipe está ciente disso, realizando uma reunião em que o gerente define as expectativas.

Você também deve argumentar sobre a falta de contribuição do líder da equipe para o desenvolvimento. Ambos os problemas devem ser resolvidos para tornar o projeto um sucesso.

Você terá que impor alguma restrição ao seu time, mas isso pode ser complicado para jogar na sua posição nele.

Uma maneira útil de resolver isso pode ser adotar um controle de alterações documentado mais rigoroso. Você pode fazer isso insistindo que, no momento, alterações ad-hoc estão colocando em risco sua capacidade de gerenciar as atualizações do sistema de uma maneira que não tenha consequências imprevistas e ameaçadoras de prazo (o que é verdade). Portanto, insista para que todas as alterações venham com documentação mostrando a alteração proposta e seus efeitos em todos os outros códigos e estruturas. Você ficará surpreso com o quanto isso reduzirá o volume de alterações que ocorrem :-)

Você realizou uma retrospectiva com a equipe? Caso contrário, segure um. Ao fazê-lo, identifique as alterações não planejadas (sujando com) no banco de dados como um problema. Especifique o custo para você e outras pessoas em relação ao risco e à qualidade de vida no trabalho. Trabalhar continuamente 60 horas por semana não é sustentável. Se você não é capaz de sustentar seu ritmo de desenvolvimento, não está fazendo agilidade.

Além disso, você está fazendo TDD (desenvolvimento orientado a teste) ou teste funcional / de regressão automatizado? Nesse caso, as alterações no banco de dados devem resultar em testes quebrados. Isso deve ajudar a lidar com o impacto e identificar o código que precisa ser atualizado.

Nesse caso, o líder da equipe não é " muito ágil ", o líder da equipe é um " cowboy ágil ". Faça uma retrospectiva, identifique o que deu errado. Priorize-o alto e, em seguida, resolva-o durante a próxima iteração. Isso deve dar corda no seu cowboy ágil !!!

Não houve o mesmo problema com você cerca de um ano atrás? 'O líder da minha equipe diz A.Property = A.Property; está bem '. Parece que a pergunta foi banida porque eu não a vejo no meu histórico de comentários. Enfim, o ponto é:

Se você acha que todos os líderes de sua equipe estão atrapalhando você com apenas metade da sua experiência, provavelmente encontrará um emprego sem ele . Eu sugeriria tentar e se tornar um líder como outra opção, ainda que você seja capaz, você já foi oferecido a fazê-lo.