Sintoma: durante o processo de desenvolvimento de uma funcionalidade, a equipe se direciona ao Product Owner ou cliente para tirar dúvidas, mas o mesmo se encontra frequentemente ocupado e não pode responder. Quando o PO está livre, a equipe está concentrada em outra tarefa.

Ação: crie uma lista de discussão envolvendo todos os interessados no projeto (Product Owner, desenvolvedores, User Experience, clientes envolvidos com aceitação etc) e envie um email para a lista.

Deixamos de lado a antiga “pastelaria” que exigia disponibilidade dos desenvolvedores no exato instante do aparecimento de uma necessidade, tudo era “para agora”. O mesmo vale para o Product Owner e qualquer outro ser humano em seu trabalho.

Apesar de muito desejado, é impossível exigir que no exato instante que surge uma dúvida da equipe de desenvolvimento, o Product Owner esteja disponível para conversar.

Vale lembrar que o email é uma comunicação assíncrona que leva mais tempo para obter resultados, além de ter chances de ser mal compreendido, portanto a primeira maneira a ser abordada para resolver um problema deve ser sempre a cara a cara com o PO.

Lista de discussão de um projeto/produto. Criar uma lista de discussão leva 2 minutos e permite receber feedback da primeira pessoa disponível, além de facilitar a busca por conversas quando novos membros entrarem.

Como o problema é a escassez de tempo de um indíviduo específico do qual esperamos uma resposta, o envio para uma lista que envolve PO, UX e clientes diminui o tempo no escuro, sem feedback. Para evitar uma discussão, faça perguntas diretas que esperam respostas fechadas, por exemplo:

Bom dia,

Estamos com uma dúvida em relação a listagem de contas atrasadas.
As com mais de um mês de atraso devem aparecer com outra cor,
conforme o padrão da tela de faturas?

Nesse caso um mês é considerado 30 dias, correto? Ou precisamos ter precisão de dias de acordo com o mês?

Caso a pergunta enviada seja um pedido de aprovação de história, inicie a próxima história até receber o feedback da mesma:

Bom dia,

As histórias A e B foram finalizadas e estão aguardando aprovação.

Caso a pergunta permanença em aberto sem resposta mesmo após o envio de um email, procure a conversa pessoal novamente: também é nosso papel como desenvolvedor conseguir a resposta, removendo impedimentos.

Veja também: prefira terminar a começar outra história.

Sintoma: Próximo ao término do ciclo de desenvolvimento (um sprint ou similar) todas as histórias estão marcadas como terminadas, resultando em uma sensação de sucesso. Mas durante a revisão das histórias pelo Product Owner, o número de recusas por detalhes pequenos é muito grande, e o número de aprovações é muito pequeno.

Ação: Mesmo que o ciclo de desenvolvimento seja curto – por exemplo 2 semanas – esperar o último momento para pedir aprovação é adiar as recusas e impedir as correções a tempo, algo potencializado em métodos waterfall.

O momento de pedir o feedback do cliente é assim que a equipe de desenvolvimento colocou a mesma em homologação (veja deploy contínuo e one click homologa).

Para quem utiliza um quadro físico, adicione nesse instante uma coluna de aprovação pelo cliente, para que o critério de pronto dependa da aprovação, que será recebida durante o ciclo de desenvolvimento.

Quadro físico com coluna de "aguardando aprovação"

Quando utilizar um sistema de tickets, crie um estado equivalente “a aprovar”, que mostre a pendência de aprovação:

Quadros digitais com estado de aprovação

Quando parar: Após criado esse estado ou coluna, com o passar do tempo, é natural que o processo de pedir aprovação durante o ciclo se transforme em algo cotidiano.

Nesse momento é possível remover tal coluna novamente pois o mesmo já passou a fazer parte do dia a dia da equipe.

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.

Ao término do primeiro sprint, sua aplicação está andando muito bem e tem todas as histórias aprovadas enquanto no ambiente de testes. Passaremos então para a primeira tentativa de colocá-lo em produção/homologação, e logo descobre-se que o sistema não funciona corretamente nesse novo ambiente, e é gasto muita energia para adaptar diversos detalhes que já eram considerados “prontos”.

Após esse esforço, com a aplicação rodando em outra máquina diferente da de desenvolvimento, os clientes começam a utilizá-la e a quantidade de bugs específicos desse novo ambiente que aparecem sobrecarregam os desenvolvedores. O estranho de tudo isso é que o código original rodava na máquina do desenvolvedor sem problemas, inclusive com testes unitários e de aceite.

Em sistemas que não implementam testes end to end, mesmo que smoke tests e que não se planejam para deploys desde o começo do projeto, é comum encontrar um grande número de bugs no primeiro deploy de homologação, além de uma extrema dificuldade para realizar essa implantação inicial.

A equipe passa então a trabalhar para corrigir essas onda de bugs, fica incapaz de adicionar novas funcionalidades em um ritmo adequado e desanima rapidamente.

Enquanto o processo de deploy não for automatizado, cada nova tentativa de implantação é seguida por uma enchurrada de bugs novos, sempre com as mesmas consequências negativas.

A solução aqui é automatizar todo o processo de deploy desde o primeiro sprint, e para isso você precisa estruturar muito bem seu ambiente, de forma que ele seja perfeitamente replicável entre as máquinas de desenvolvimento, homologação e produção. Isso é bastante planfletado pelo movimento Devops.

Graças aos ciclos mais curtos de deploy, o cliente testa o seu software mais cedo e recebemos feedback mais rápido quanto a bugs existentes, portanto o número de bugs novos sai do zero muito mais cedo, diminuindo um possível susto.

Martin Fowler comentou recentemente sobre a estratégia de manter dois sistemas muito parecidos em paralelo e virar a chave de roteamento de um para o outro para efetuar a transição, processo que pode e deve ser automatizado por completo em aplicações de alta disponibilidade. Fábio Akita da Locaweb explica uma estratégia simples para deploy contínuo através do uso do git.

Tudo isso minimiza o acúmulo de bugs, resultando em um ritmo constante, mas menor, de aparição de problemas, inerentes a qualquer processo.

Com o deploy contínuo através de técnicas como a citada pelo Akita, cada commit terá não só suas baterias de testes rodados, mas entra em homologação. Os bugs aparecem mais cedo durante o desenvolvimento do projeto e o processo de deploy pode ser efetuado mais frequentemente.

Indo além, com um sistema blue-green, seu processo de deploy atinge um nível maior ainda de maturidade, com a possibilidade de um rollback robusto a qualquer instante.

Como você está tratando o seu deploy?

Mais uma palestra do Falando em Agile 2008. Desta vez com Danilo Sato e Francisco Trindade, ambos da ThoughtWorks de Londres, falando sobre os problemas encontrados no dia a dia quando se adota uma metodologia ágil. A ThoughtWorks é umas das empresas mais conceituadas quando se fala em agilidade, e tem como seu cientista chefe Martin Fowler.

Veja também outras palestras do Falando em Agile 2008:

• Scrum na Globo.com: Derrubando mitos, com Danilo Bardusco
• Agilidade de Tartaruga, com Danilo Sato e Francisco Trindade
• Contratação de projetos de Software, manutenção de sistemas e portfólio de projetos com Agilidade, por José Papo