blog/content/reviews/books/direto-ao-ponto-criando-produtos-de-forma-enxuta.pt.md

+++
title = "Direto ao Ponto - criando produtos de forma enxuta - Paulo Caroli"
date = 2016-03-26

[taxonomies]
tags = ["books", "paulo caroli", "ágil", "reviews"]
+++

[Resumo GoodReads](https://www.goodreads.com/book/show/23834245-direto-ao-ponto---criando-produtos-de-forma-enxuta):
Um projeto ágil é conduzido através de entregas rápidas e frequentes. Um
projeto bem executado coloca ênfase em entregas de valor de acordo com
objetivos de negócios e os usuários de destaque. Projetos ágeis promovem a
liberação incremental de software: o MVP, o produto viável mínimo, em Inglês
Minimum Viable Product (MVP), a versão mais simples de um produto que pode ser
disponibilizada para o negócio. Mas como realizar o entendimento do MVP e a
iniciação do projeto ágil o mais rápido possível? Como garantir que o time
comece o projeto com entendimento compartilhado, direção, prioridade e um
plano bem definido?

<!-- more -->

{{ stars(stars=3) }}

Quando comecei a ler o livro, me lembrei imediatamente de um vídeo do _Robert
C. Martin_ explicando regras de progressão de código conforme os testes
unitários avançam: antes de explicar as regras, ele passa por todo o processo
de "escrever os testes antes do código", mostrando a evolução do código e
nesse ponto TDD faz o maior sentido do mundo. Mas quando ele chega nas regras,
você fica pensando se a regra *realmente* faz sentido.

A mesma coisa aconteceu com o livro: Paulo Caroli começa explicando os vários
conceitos e método das metologias enxutas e tudo faz sentido e parece ser a
melhor coisa do mundo. Mas depois começa a se aprofundar na inception e você
começa a pensar que talvez não faça sentido coletar todas as features e
definições e examinar tudo com os stakeholders se métodos ágeis funcionam
justamente sabendo que as coisas vão mudar no futuro. Do que adianta planejar,
discutir, desenhar e tudo mais quando se sabe que, no produto final, nem todas
as features desejadas inicialmente serão usadas ou se durante o
desenvolvimento não será detectada a mudança no curso e o resultado final será
completamente diferente do planejado inicialmente.

E esse ponto em específico nunca é discutido; você fica com um "waterfall" nas
mãos sabendo que nem tudo vai ser usado no final -- afinal de contas, essa é a
idéia dos métodos ágeis.

Então embora o livro descreva como fazer uma inception completa, com o maior
número de acertos possíveis, o fato que uma inception não parece se encaixar
na metodologia ágil nunca é discutido.