domingo, 11 de novembro de 2018

Get the job done, parte 1: O que significa “DONE”?


Done, ready, pronto! O que significa isso? A coisa mas idiota que eu vi em métodos ágeis foi tentar manipular a definição de “pronto”. Por que? Para saber isso e outras coisas, leia esta nova série de artigos que estou postando, e vamos repensar juntos o sentido da “agilidade” em desenvolvimento de software.



Pronto é pronto!

O que seu professor queria dizer quando dizia: “O trabalho deve ficar pronto na terça-feira"? E o que você entende, quando seu mecânico lhe fala: “Seu carro ficará pronto na Quinta-feira"? Será que o professor aceitaria apenas algumas folhas? E depois você entregaria o resto? Será que você aceitaria as rodas, depois os bancos, depois o motor do seu carro, e daí por diante? Claro que não.

Veja só a definição que a Agile Alliance oferece:


Um blá-blá-blá que não deixa claro o que significa “pronto” (ou “done”). Pronto pode ser o estado do software após o desenvolvimento de uma ou mais “histórias” de usuário, não necessariamente entregues em ambiente produtivo. Alguns preferem a definição mais “em cima do muro” de PSPI: Potentially Shippable Product Increment ou Incremento de Produto Potencialmente Entregável. O que isto significa? Você pode colocar aquilo em ambiente produtivo, fazendo um “release"? Não necessariamente. O artigo sobre PSPI justifica isso desta forma: 

you may not have enough value completed to release at that time, but what you have is high quality, or “releasable”.” 
(Você pode não dispor de valor suficiente para entregar naquele momento, mas o que você tem é de alta qualidade ou “entregável”).

WTF?! Como algo pode ser considerado “entregável” se não pode ser entregue? 

Pronto

Se você “googar” o termo: “definição de pronto”, a primeira resposta diz tudo: 

“inteiramente feito ou construído; terminado.”

Restou alguma dúvida? Claro que não. Pronto é “done” é “ready” e não “potencialmente entregável”.

Por que os agilistas pensam diferente? Por que agem desta forma? Porque o método mais utilizado, o Scrum, divide artificialmente o trabalho em vários pedacinhos, feitos em períodos de tempo de tamanho fixo, portanto, nem sempre o que entregam ao final de cada período é útil para o Cliente. 

Imagine uma casa feita de acordo com o Scrum. Como seria? A ordenação das histórias não segue um padrão. Alguns defendem que as histórias de maior valor para o usuário devem ser concluídas antes. E se o “usuário” valoriza mais a cozinha? Então vamos entregando os itens de cozinha em primeiro lugar, certo? E lá vai o “usuário” homologar o fogão, os armários e a geladeira, mesmo que não tenha uma cozinha onde utilizá-los. Ah, mas eles são “potencialmente entregáveis”.

Problemas do fracionamento

Esse fracionamento excessivo é oriundo de um “mantra” do início dos métodos ágeis: “Entregue rápido, entregue frequentemente”. Alguns podem considerar isso bom, mas eu, do alto dos meus 40 anos de experiência, tenho minhas dúvidas.

Para começar, o Cliente (quem tem “usuário” é traficante) tem que deslocar alguém para acompanhar o desenvolvimento. O Cliente tem que se envolver, sendo esse um dos “dogmas” do agilismo.

Por mais “bacana” que seja essa entrega fracionada, o que acontece ao longo do tempo? Sim, vamos supor que já estamos no décimo terceiro “sprint” (tinha que ser o 13, não?) será que a “entrega” dele será totalmente compatível com tudo aquilo que já foi entregue? Lembre-se que os métodos ágeis “encorajam” a mudança constante das “histórias”, portanto, é comum haver mudanças nos “sprints” mais ao final, impactando “entregas” mais antigas, causando retrabalho e jogando seu orçamento no lixo.

O dogma do fracionamento diminuir o risco é uma falácia!

Seria melhor receber algo realmente pronto, mesmo que incompleto, mas pronto para usar! Voltemos ao exemplo da casa... Para mitigar o risco de entregas demoradas, você poderia dividir o projeto em: 
  1. Estrutura: Piso de concreto, fundações, colunas, vigas, lage, canos, conduítes e paredes;
  2. Elétrica e hidráulica: Encanamento, esgoto, fiação e quadro de luz;
  3. Acabamento: Piso definitivo, revestimento de banheiro e cozinha, emboço, reboco e pintura das paredes;
  4. Armários: Cozinha, banheiro e quartos.
Não parece muito melhor? A cada “entrega” você realmente tem algo funcional, mesmo que não totalmente satisfatório, ajudando a reduzir o risco. 

Voltando ao “pronto”

Por isso que “Get the job done” prescinde de “definição de pronto”. Pronto é pronto! 

Para mitigar o risco do projeto, as entregas podem ser fracionadas, desde que você entregue algo realmente útil. Alguns questionarão: “De que adianta uma casa sem piso, sem pintura? Bom, se você tem a Estrutura, qualquer um pode concluir a obra e, em caso de necessidade, pode ser vendida. Agora, o que fazer com uma porta, duas janelas, um armário semi-pronto e um vaso sanitário?

Se você tem algo “pronto” o risco de mudanças interferirem com o que já foi entregue é minimizado, pois o Cliente tem algo “pronto” na mão e pode avaliar o que é derrubar paredes e reconstruir apenas por capricho de alguns.

Tudo fica mais visível e mais claro e o risco de ficar sem algo útil é mitigado. 

Por exemplo, em engenharia de software, o que significaria “pronto”? Vamos supor que você esteja encomendando um software de e-commerce, como seriam essas entregas parciais? Podemos pensar em algo assim: 

  1. Cadastro de clientes e produtos;
  2. Carrinho de compras;
  3. Processamento de pagamentos;
  4. Vitrine;
  5. Processo de entrega;
  6. Analíticos (estatítica, “quem comprou comprou também etc”); 
Certamente, você não constrói cadastro de clientes e produtos em duas semanas, certo? Este seria um prazo padrão de “sprints”. Claro que não! Essa história de fracionar arbitrariamente o projeto é uma grande roubada!

Pronto PRONTO mesmo?

Um incremento do software está pronto quando temos: 
  • Código-fonte funcionando;
  • Testes automatizados implementados;
  • Testes de aceitação realizados;
  • Software implantado.
Isso é software pronto. Nada dessa bobagem nonsense de “potencialmente entregável”.

Mas, como dividir o projeto, sem usar “sprints” de tamanho fixo? Como estimar as “histórias”, sem usar aquela fábula de unicórnios de jogar cartinhas? Bem, isso é papo para outro post.

Por enquanto, ficamos com a “definição de pronto”: PRONTO É PRONTO, CARACA! PRESCINDE DE DEFINIÇÃO!

Nenhum comentário:

Postar um comentário