Meio a tantos incentivos e pressões para gerarmos ciclos de entrega cada vez mais curtos, não passam despercebidas as oportunidades de entregar código de baixa qualidade para agradar um chefe, um gerente, um cliente, ou quem quer que esteja interessado na data da entrega, mas nenhum interesse no resultado da entrega. O tema de hoje é sobre como controlar e gerenciar as expectativas e como controlar e contornar a essa lambança.
Contexto
Vimos nas últimas décadas um movimento pautado pelo aumento da pressão em busca de ciclos de entrega cada vez mais eficientes, cada vez mais curtos, cada vez mais ágeis. Mas será que o que estamos fazendo é realmente ágil? Ou será que estamos nos escondendo no guarda-chuva do ágil para fazermos de qualquer maneira?
Acho que cabe a desambiguização: ÁGIL não é DE QUALQUER MANEIRA.
Enquanto:
Ágil pode ser encarado como de uma forma mais simples
De qualquer maneira pode ser encarado como de uma forma porca e sem zelo.
O manifesto ágil é dividido em 12 princípios e nenhum deles cita nem “de qualquer maneira” ou “de forma porca” ou “de forma desleixada“.
Na prática, vejo muitas coisas ruins de disfarçando de ágil, muita gestão criativa, se disfarçando de ágil para simplesmente aceitar e promover o caos e a desorganização. Em nome do ágil se tem cometido atrocidades e cada vez menos vejo qualidade nos projetos com essas características.
O baixo clero do projeto, nós, os técnicos, simplesmente vemos o reflexo dessa desorganização e desse caos. Aos poucos com voz, cabe alertar sobre o que ressalta aos olhos ou simplesmente abandonar o barco. E esse é o principal motivador para esse post. Ver gente boa, se perdendo e sendo empurrada a se jogar no precipício.
Mas o que falta?
Não é difícil entender o que falta à maioria desses projetos é estratégia. Estratégia técnica, estratégia para a gestão de features, clareza em sua interdependência. Em qualquer projeto com um roadmap flexível, é necessário compreender quais são os alicerces que fundamentam aquilo que iremos construir.
- Quais features precisam de novos elementos de infraestrutura?
- Quais features precisam de algum mecanismo arquitetural determinado?
É importante:
- Identificar quais novas infraestruturas são necessárias para as próximas features.
- Determinar com clareza quais features dependem de cada infraestrutura existente e não existente.
- É muito importante saber quanto custa (em tempo) um novo elemento de infraestrutura de aplicação, é extremamente relevante saber que esse custo precisa ser empenhado antes das features que dependem dele, e das features que dependem das features que dependem dele. Sim, há cenários em que você precisa adicionar um elemento de infraestrutura, para construir a feature A, que por sua vez, somente então permitirá a criação de uma feature B. A gestão de precedências e dependências é importantíssima para se criar um roadmap viável.
Posso estar ferindo, com esse pedido, algum dos elementos do manifesto? Talvez, mas minha experiência com uma infinidade de projetos nos últimos anos mostra que repetidamente, ao juntarmos os conceitos funcionais e não funcionais, mascaramos o custo real de cada coisa, abrindo brechas para o planejamento criativo, que prioriza uma feature em um sprint, no qual a feature predecessora, engordada pelo tal requisito não implementado, está fora exatamente por estar inchada.
Abstrato? Tenho uma história pra contar…
Imagine que você precise implementar um simples upload de arquivos de imagem.
Está combinado que você usará um lob storage, como o Amazon S3 ou Azure Blob Storage.
Você orça a implementação da abstração que ajudará o projeto, mas o faz adicionando esforço na feature de upload de imagem. Isso permite que uma outra feature, como upload de PDF, tenha um menor peso, e um menor esforço, já que, a infraestrutura entre as duas features foi orçada na feature anterior. Vamos supor que tenha orçado 2 dias para upload de imagens e 3 horas para upload de PDF.
É importante estar claro quanto custa cada um desses requisitos, isoladamente, para não haver o equívoco de reordenar uma feature em função do custo, no qual a feature priorizada “custa menos” exatamente porque sua predecessora está escondida em outra feature que vai ficando para final do backlog por “custar caro”.
Mas como isso pode acontecer?
Bom, há muito waterfall travestido de ágil e naturalmente nesses casos, o caos é seu maior vilão. Tudo muda o tempo todo, e ninguém de fato tem uma visão clara e de longa data sobre o mesmo projeto. Todos olham para uma visão míope do projeto e acabam por tomar decisões equivocadas, que quando reavaliadas, não fazem o menor sentido ou simplesmente são inviáveis com o prazo que se tem.
E você?
E você, me conta, já passou por situações assim? Escreva aqui nos comentários!
Gostei do artigo, mas vou pegar o exemplo que você deu para debater. No caso do Upload da imagem, ele ficou em 2 dias porque você esta planejando uma abstração para facilitar uma outra user story, mas e se eu focar e fizer sem abstração, qual seria o tempo? 1 dia para cada uma? E se criar uma nova user story, voltada para a abstração desses itens? E como o peso dela em negocio é menor, ela vai ficar para o final, qual seria o custo para o cliente?
Como gerente de inovação e produto, eu vejo a sua visão como a minha, com preocupação para a melhoria continua do produto, mas se estamos falando de um atelie de software, será que esta abstração vai trazer algum valor para o cliente, ou vai trazer apenas valor para o atelie? E quem vai pagar essa conta? O atelie assume o custo desta abstração? Divide o custo com o cliente, e na próxima vez que for realizar um desenvolvimento (talvez para outro cliente), ele usa essa abstração e barateia o custo? Existe uma infinidade de caminhos e cada caminho vai te levar a um custo, no final tudo vai depender do que você precisa entregar, e do que o seu cliente (seja interno ou externo) quer.
Eu dei a pista de que seriam necessários novos uploads, e a diferença entre eles seria o tipo de arquivo. Acabei, equivocadamente, omitindo que a necessidade não é somente de realizar um upload, mas junto com o upload oferecer um preview para aquele tipo. Esse é o ponto que faz mais diferença. A abstração permite fazer upload de qualquer coisa, e controlar quem é o handler de preview daquele upload. Isso visualmente facilita muito o trabalho do cliente ao visualizar, o que no meu caso são emails, geralmente com comprovantes, prints de tela, etc.
No caso do planejamento em si, se você não abstrair, é muito provável que a soma da construção dos uploads aumente. O foto é gestão e manutenção, então até aceito custar mais caro para desenvolver com a abstração, desde que haja algum ganho, imediato ou posterior. Mas é um tradoff que precisa ser analisado, caso-a-caso.
A pergunta sobre o que a abstração entrega de valor, é bem pertinente. E eu vou na contramão do que muita gente prega. Eu prego que qualidade técnica, quer dizer, não produzir código duplicado, ser de fácil manutenção, viabilizar a entrega de features semelhantes com menor esforço representa valor. Não somente para o cliente, mas para o negócio. Essa é uma visão que prioriza qualidade, principalmente pois quando as coisas não dão certo e quando algo ruim chega ao cliente, com uma série de reclamações e até abandono no uso do produto, inevitavelmente o custo do dano à imagem do produto é muito maior do que aquelas horas ou até dias a mais que gastamos fazendo, o que na minha visão, é fazer direito.
Eu particularmente não gosto da ideia de dividir o custo entre partes, o custo é do cliente. Se eu estou fazendo “certo” é para ele. O que eu geralmente coloco, é que “meu time trabalha assim”, e ponto final. Não deixo uma necessidade técnica para uma demanda de negócio parecer nem fútil nem supérflua, encaro como obrigatória, pois se eu estou colocando algo ali, há bons indícios de que é de fato necessário. Claro, já errei nisso, por culpa minha ou por culpa dos outros. Mas em via de regra, são exceções.