|
|
|
|
+++
|
|
|
|
|
title = "Direto ao Ponto - criando produtos de forma enxuta - Paulo Caroli"
|
|
|
|
|
date = 2016-03-26
|
|
|
|
|
updated = 2021-02-12
|
|
|
|
|
|
|
|
|
|
[taxonomies]
|
|
|
|
|
tags = ["books", "paulo caroli", "ágil", "reviews", "stars:3", "published:2014"]
|
|
|
|
|
+++
|
|
|
|
|
|
|
|
|
|
[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.
|
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
vim:spelllang=pt:
|
|
|
|
|
-->
|
