Desenvolvimento: o dia que o meu projeto parou

Existem diversos tipos de débitos e o que todos eles tem em comum é que tornam a manutenção de um sistema muito custosa e delicada.

Por mais de dois anos, a Caelum tem feito um esforço sobre cortar diversos tipos de débitos técnicos, incluindo levar práticas ao extremo, como testes end-to-end em grid.

Uma forma de enxergar que devemos melhorar o processo de desenvolvimento é verificar que perdemos dinheiro ao tomar decisões ou muito cedo, ou tarde demais.

O descuido gera débitos que cortam a produtividade de sua equipe. Também o excesso de cuidado, gera muitas trocas de decisões, visando o preciosismo técnico, pode levar a um atraso muito grande.

Além disso, uma empresa que espera 4 meses para colocar algo em produção pode ser uma empresa 4 meses atrás de seus concorrentes. Entregar valor tardio é ficar para trás.

Mas o que causa empresas ágeis a não entregar tão frequentemente?

Muito produtos criados em ambientes ágeis só são colocados em produção depois de muito tempo. Durante todo esse tempo, os únicos a testarem e aprovarem as funcionalidades são a equipe de QA e o Product Owner. Ao colocar este produto em produção depois de um ciclo tão grande, o cliente final vai encontrar os problemas que costumavam aparecer em metodologias tradicionais.

No lado gerencial, o Product Owner apresenta dificuldades em priorizar seu backlog de maneira a entregar valor, acabando por entregar funcionalidades. Além disso, é dificil aceitarmos algo “incompleto para o uso mínimo” e, na visão de quem é dono de um produto, o “mínimo necessário” acaba sendo maior do que o real e nunca é atingido para ser colocado em produção. É aí que seu projeto para: ele ficara sem entregas durante muito tempo.

Existe uma prática bem simples para um PO executar e perceber se possui essas dificuldades. Olhe seu penúltimo sprint e veja as funcionalidades que já estão sendo utilizadas por seu cliente. Agora jogue na fórmula:

GPD = (salario da equipe * pontos_desnecessários) / pontos_do_sprint

GPD é o Gasto que você teve com Priorização Desnecessária durante o penúltimo sprint. Ser ágil é entregar valor, e seus pontos estão sendo utilizados em funcionalidades completas sem tanto valor. Se existiam outras tarefas que entregavam valor para os usuários, a priorização poderia ter sido melhor.

Outra possível melhora na parte gerencial está na execução de testes somente por QAs e POs: o feedback não vem do cliente final. Devemos entregar cedo e frequentemente para receber feedback real, e não apenas do PO. Mas como alcançar isso se o produto possui um conjunto mínimo de funcionalidades, que é razoavelmente grande, para entrar em produção?

Assim como diversos ramos de software, adote o conceito de usuários beta. Ele possuem acesso a suas funcionalidades mais cedo, em servidores suficientemente estáveis que acessam dados de produção, rodando a última versão de seu produto, mas com o risco de algo dar errado. O conceito de beta potencializa a propaganda do seu produto, podendo criar uma legião de fanboys.

Na parte técnica, desenvolvedores tem percebido cada vez mais a importância de todos tipos de testes automatizados, controle de versão, integração contínua e outras práticas com base em XP, mas outra causa ainda mais comum de problemas em diversas empresas é o truck factor. Se durante a reunião de planejamento alguém responde que determinada tarefa é dele – pois ele “conhece mais aquela parte do sistema” – ou se alguém é o único que vota os pontos de parte do sistema; ou ainda se é comum esperarem por alguém para executar qualquer tarefa, está na hora de compartilhar mais o conhecimento e acabar com esse impeditivo antes que o truck acabe com ele. Parear e ensinar mais o que conhecemos permite que, ao invés de produzirmos por nós mesmos, diversas pessoas produzam através do que compartilhamos. Essa é a mágica do ensino, levado ao pareamento. Não parear por causa daquela parte ser responsabilidade de uma única pessoa é um paradoxo! É justo esse tipo de caso que mais ganha vantagens do pareamento.

O outro fator para desenvolvedores e sysadmins se perguntarem é quanto tempo leva para fazer deploy? Alguns dias? Se sim, a metodologia ágil que foi alcançada perdeu grande parte do seu valor pois o feedback rápido virou feedback semanal ou ainda mensal.

Apesar de processos de build automatizados junto com integração contínua serem importantes, deploy contínuo é cada vez mais fundamental.

Essas e outras práticas, gerenciais ou técnicas, servem para encontrar o que está implicando na não-entrega de valor ao cliente. Depois de detectado esse gargalo, devemos agir para melhorar nosso processo de desenvolvimento.

10 Comentários

  1. Bruno 19/04/2010 at 23:52 #

    otimo artigo Guilherme,

    engraçado que recentemente vi no quadro de uma equipe scrum varios post’s com uma das siglas (FE,BE) FrontEnd e BackEnd, ou seja a equipe totalmente dividida em tarefas paralelas… então gostaria de saber tua opnião sobre o fato, como evitar isso já que o pessoal frontend teoricamente não sabe nada do servidor!!

    grande abraço

  2. Diego Carrion 20/04/2010 at 00:27 #

    Muito legal o artigo.

    Ficou uma dúvida somente, esse PO que não consegue priorizar corretamente nem reconhecer o mínimo produto viável é um PO de verdade ou é alguém interno da equipe que assumiu o cargo de PO?

    Pergunto isso porque com o segundo caso ja teve os mesmo problemas e com o primeiro não, o que faz tudo sentido.

  3. André Luiz Forchesatto 20/04/2010 at 14:12 #

    Muito bom o artigo, muito material também nos links do texto.

    Acho muito interessante os princípios dos métodos ágeis, procuro sempre ser guiado pelos mesmos, mas trabalho em uma equipe descentralizada com um desenvolvedor em cada cidade e sentimos dificuldade em aplicar alguns dos princípios como programação em par, reuniões diárias, controle de sprints, você conhece algum artigo que aborde o desenvolvimento ágil em equipes descentralizadas?

    Grande abraço

  4. Braulio Consani 21/04/2010 at 22:29 #

    Oi Guilherme!
    Parabéns pelo post! Muito pertinente a questão colocada pois um dos grandes desafios é trazer um P.O. adequado e que represente de maneira fiel o cliente final, o que é difícil realmente, de preferencia deve ser um profundo conhecedor do negócio e da empresa contratante, ou seja, que conheça a cultura, processos, profissionais e demais negócios e que possa realmente estabelecer reais prioridades e ligar o produto que está sendo desenvolvido com as áreas correspondentes.
    Como você bem colocou, integração contínua é fundamental, porém urge que os deploys assim também o sejam. O esquema dos usuários betas é uma saída interessante neste cenário de deploys mais frequentes. Outro ponto que pode ajudar também é na reunião de entrega de sprint estarem envolvidos também os usuários-chave do sistema (difusores) e os stakeholders.

  5. Guilherme Silveira 25/04/2010 at 09:48 #

    @bruno ótimo comentário. a equipe de front end e de back end pode ser a mesma e ter conhecimento de como um e outro funciona – o que precisam é de uma interface uniforme (uniform interface) de comunicação para evitar alto acoplamento entre as duas partes: mas nada impede as duas equipes serem uma só, desde que mantenham o baixo acoplamento.

    @diego pois é, é muito mais uma características de um PO iniciando do que de um PO experiente em processos ágeis. estou tentando abordar essas faltas comuns que exercemos quando adotamos algo ágil

    @andré nosso próximo curso de desenvolvimento ágil abordará esse assunto e tem um artigo legal do infoq, apesar de antigo, com diversos links sobre o assunto: http://www.infoq.com/news/2007/06/07

    @braulio obrigado! nada como complementar mais ainda o post com comentários.

  6. Wilson 05/05/2010 at 00:02 #

    Olá Guilherme,
    Em muitas empresas que rodam Scrum é fácil ver as entregas serem feitas somente para os PO’s e o sistema só entrando em produção depois que todas as funcionalidades estejam desenvolvidas e testadas pelo PO.
    Esse post acrescenta ainda mais nessa parte.

    Parabéns!
    Abraço.

  7. Guilherme Silveira 05/05/2010 at 14:02 #

    @wilson

    Obrigado Wilson! Realmente é sempre dificil. Aliás é justo por isso que enfrentamos esses problemas. Pelo que tenho visto o papel dos couchs de outras metodologias, o trabalho acaba sendo até mesmo eterno, afinal sempre há o que melhorar.

    Abraço!

Deixe uma resposta