Questionamentos...

Caramba, suas dúvidas estão muito legais e estou ficando com vontade de participar da thread, só para ver as respostas das outras pessoas.

Acho que você tem razão, a variável do tempo vai ser definida de acordo com o que precisa ser feito... Uma coisa que acho bem legal da metodologia ágil é abrir a porta para que o produto entre no ar sem que esteja realmente "pronto". O tempo inteiro a gente acessa sites, apps que não estão com todas funcionalidades liberadas mas que já ta gerando valor para o cliente.

Flavio vi seu questionamento sobre a atividade e sobre o que escreveu do usuário ter que realmente ver algo concreto. É importante que o processo de entrega de software seja de maneira iterativa e incremental, para que o que esteja sendo entregue para o cliente seja, inicialmente, validado e principalmente já gere valor de imediato para o cliente. As vezes uma solução simples irá entregar o mesmo valor, ou até entregará valor mais rápido, que uma solução mais robusta que custará mais para o cliente e também demorará mais para gerar valor para ele. E melhor ainda, as vezes o problema do cliente se resolve já com uma solução mais simples.

A ideia de ter o sistema validado pelo cliente é tanto do lado de negócio, processo, quanto ao técnico. Código em estoque, ou seja, código fora de produção/homologação, é código com bug e futuro retrabalho.

Espero ter ajudado.

Como o Alberto disse, é muito comum temos sites e softwares que não estão com todas as funcionalidades desenvolvidas mas estão no ar. Engraçado como faz sentido o que o Flávio disse, mas ainda sim, tem algo que você possa mensurar antes do produto estar pronto é melhor ainda.

É por isso que existe um PO. Esse cara tem que ter conhecimento de negócio e de TI para conseguir falar a língua dos dois. O cliente nem sempre consegue explicar com detalhes o que quer. E nós temos que ir ilustrando isso aos poucos. Concordo com você em relação a prototipação e qualquer outro método que consiga abrir a cabeça dele aos poucos e afunilando isso a cada entrega.

"The shorter the cycle, the faster the learning". Você vai ter feedbacks durante todo o caminho de produção. Quantas vezes você já viu equipes chegarem ao final de um projeto e o cliente rejeitar? Isso ocorre justamente por falta de mostrar algo aos poucos ao cliente, assim como era no modelo waterfall. O problema do waterfall era levantar tudo muito cedo e entregar algo errado no final. Essa é a verdadeira vantagem desse método frente aos antigos: Você entrega algo de valor o tempo todo e o cliente fica mais satisfeito. Você reduz o custo de tomada de risco, melhora o desempenho da equipe, ajusta a questão de taxação fiscais do projeto.

Sobre a entrega... A cada duas semanas você precisa entregar algo de útil e de valor. E isso é bem possível em projetos grandes, como por exemplo em SAFe (Scaled Agile Framework). Por isso ele diz que em um ou dois meses você já tem algo... comparando sempre ao método antigo de desenvolvimento waterfall.

Francisco Flávio,

Quando vc compara o software a um bem físico (casa, carro, computador), fica estranho mesmo. Mas imagine um bem intelectual (um livro ou um disco), neste caso, dificilmente o cliente (editora, gravadora), vai esperar tudo está pronto para "ver o que deu", seu cliente vai querer trabalhar com você.

As metodologias ágeis não trouxeram nada de "novo", apenas mostram os melhores caminhos para termos mais efetividade. É sempre bom para o cliente ter acesso ao produto, mesmo que ele não "consiga colocar em produção".

Att.,

Alysson Bruno

Ótimos pontos por aqui. :-)

Indo um pouco para a filosofia de botequim: eu gosto muito de como as metodologias ágeis tentam, mais do que ser ágeis em si, resgatar a troca de experiências com o usuário final. Por mais que digam (ou tentem vender) o contrário, nas últimas décadas TI foi ficando cada vez mais distante do negócio e de cuidar do cliente. Ficamos atolados em um monte de burocracias, documentações e processos engessados que sequer permitem que o usuário e inclusive o profissional de TI aprenda e mude de ideia ao longo do caminho. Scrum, Kanban, XP trazem de volta aquele desenvolvimento moleque, de raiz, onde você entrega continuamente pequenas e rápidas soluções, de acordo com as expectativas de quem vai utiliza-la. Puro amor. ;-)

Marcos, eu não sei de qual metodologia vc está falando... Por exemplo, eu conheço o RUP também, e posso-lhe assegurar que ela prevê um contato direto e frequente com todo o tipo de interessados em um projeto de informática,; inclusive, caso seja detectada a necessidade, ela prevê remodelar o processo de negócio antes de automatizá-lo. Além disso, por ser iterativa e incremental, ela prevê entregas de versões inacabadas do produto ao longo de cada fase de seu desenvolvimento.

Olá Flavio.

Trabalho com RUP há pouco mais de 12 anos, sempre em grandes empresas (o que pode ser uma benção ou uma maldição). Concordo contigo quando diz que a metodologia prevê o contato direto com usuário e possibilidade de adequar/alterar necessidade ao longo do caminho. No entanto, se comparada a outras metodologias ágeis, acredito que mesmo o RUP é um pouco menos dinâmico neste sentido, inclusive pela quantidade de artefatos envolvidos.

Mas é aquilo. Depende da implementação da metodologia em cada empresa e cada caso sempre é um caso específico. :-)

Grande abraço!

Alysson, no meu texto, eu falo sobre prototipação... Nele também, eu NÃO disse que o cliente NÃO deveria ter acesso ao produto incompleto, muito pelo contrário; eu disse que o discurso Scrum é fantasioso e marketeiro ao dizer que ao final de cada sprint "algo de valor" será entregue ao cliente... Qualquer metodologia incremental e iterativa disponibiliza algo ao seu cliente. Então, se esse "algo" é de valor, não é me´rito de metodologia ágil alguma. O valor quem diz é o cliente... É ele quem decide se o que está pronto já pode ser colocado em produção ou não... Não há garantia de que , entre 2 e 4 semanas (time box do scrum), seja produzido algo que já possua "valor" para o cliente ... Metodologias ágeis são muito eficientes para projetos de pouco risco, que seja verdadeira a premissa de que o P. O. sabe "tudo" do negócio... Quando os problemas a serem sanados por um projeto são complexos ou de grande porte, muitas vezes, ninguém sabe como resolvê-lo, ou seja, não existe P.O. do jeito que o scrum define. Resumindo, quem só conhece metodologias ágeis não têm parâmetros suficientes para comparar as outras metodologias... Independentemente disso, na minha opinião, o mais prudente é seguir a máxima que diz: "não existe bala de prata".

Flávio, sugiro que você procure conhecer o caso do sistema Sentinel, do FBI. O Scrum foi criado para lidar com cenários de alta complexidade. Outra coisa, se o P.O. não sabe o que trará mais valor, provavelmente ele não deveria ser o P.O., que não se restringe a uma pessoa necessariamente, pode ser um time a depender do tamanho do projeto.

na minha visão o negocio foi se desenvolvendo, e com as experiencias adquiridas as empresas optam por implementar a metodologia ágil no dia dia do negocio de desenvolvimento de software, ainda tem muito a ser melhorado e discutido, com isso pensar, criar novas ferramentas poderosas ao nosso favor.

Sugiro que a galera que está enxergando Ágil como algo para pequenas empresas deem uma olhada para as grandes que estão usando ágil em grande escala e com situações muito mais críticas. Indico estudarem um pouco do SAFe - Scaled Agile Framework e ampliem mais o seu horizonte para ágil. Abraço

Renato, o próprio Santander tem usado Scrum com sucesso. ;-)

Abraços Marcos

Flávio, o MVP, praticamente em paralelo, o ROI, são conquistas que precisam de aprimoramento contínuo e, mais que isso, todo o time aplicado e acreditando no resultado, e isso inclui o cliente. O "atraso" se dá caso exista uma expectativa de tempo que não seja atendida. Coisa que não precisa acontecer, caso seja negociado com o seu usuário/cliente. Esse é o meu ponto de vista... Já entreguei uma primeira versão do relatório em excel, por e-mail, e o resultado foi ótimo pois o usuário já conseguia responder ao seu gestor, e eu consegui validar a query que havíamos montado. O MVP pra ele era a informação, que ele não possuía e passou a ter num formato que ele conseguia entender e manipular...

Pra priorizar features para um bom ROI você precisa saber duas coisas primeiro: Qual o custo de atraso (CoD) em entregar valor e Qual o custo para implementar algo de valor. Ou seja, avalie a quantidade de trabalho, o tempo para fazer e quanto você vai gerar de valor com aquilo pronto. De maneira geral tente avaliar cada feature dando preferência a trabalhos com menores durações e alto CoD. Você pode usar a técnica de WSJF = CoD/Duration.

Lembrando que às vezes você tem parte de desenvolvimento que agrega valor a algo maior. (Enable new bussiness opportunities?)

Complementando sobre a questão de testes e protótipos é bem comum usar UX designs (User Experience designs). Isso ajuda muito o feedback de PO ou PM (ou até SM) com relação ao desenvolvido assegurando que a solução bate com as expectativas do cliente. Inclusive você pode estabelecer um critério de User Interface (UI) para DoD. Os critérios de aceitação deles passam também pelo PO.

Alberto, não consigo excluir minha resposta.

Achei mais simples entender da seguinte forma:

"O usuário final precisa ver algo concreto para realmente entender o que quer."

Quanto menos abstrato for o escopo, mais perto o cliente estará da solução desejada.

"Além disso, ao levarmos X meses para entregar o projeto, estamos atrasando o ROI do cliente em X meses. "

Como patrocinador da demanda, o cliente ficará mais satisfeito quanto mais rápido transformarmos seu capital investido em ativo utilizável.