Voltando ao assunto, o que fazemos é sensibilizar a P.O. que é necessário testar de várias formas (unitariamente, com testes de aceitação) e que precisamos sempre automatizar todos os testes. TODAS as histórias, sem exceção, são testadas da melhor forma que conseguimos e por várias pessoas diferentes (no mínimo duas – outro desenvolvedor e o homologador). Além da visão de negócio, que é dada pelo P.O., a visão técnica que eu dou para o meu time é sempre a seguinte: não importa quanto tempo leve ou o que vamos precisar fazer, nossas histórias não podem nunca ter bugs e precisamos fazer todo o possivel para impedir que eles aconteçam. Eventualmente acontece, porque não somos perfeitos, mas todos tem carta branca para testar da forma necessária e para recusar um trabalho que eles acreditem que não seja possível fazer com qualidade.

[ ]s, gc

Realmente, acho que não li o post com a atenção que deveria, acho que prestei mais atenção aos comentários da rapazeada.

Agora eu faço um questionamento. Que qualquer coisa, por mais banal que seja, é mais um item a ser testado, isso é fato. Agora como vc tem feito pra minimizar esse tipo de problema? Não no seu caso, mas na maioria dos projetos isso é uma constante, de coisas banais que tiram o sono da gente, pelo simples fato de não sabermos falar não na hora em que deveríamos. E de não fazer o cliente entender que o “é só mais um botãozinho” exige trabalho(ás vezes muito trabalho) e talvez retrabalho, e que no final pode implicar num sistema em produção que estava em ordem, virar um sistema bugado.

Calma, respire fundo. Você acaba de dar uma mancada em público por não ler direito o post:

“[...]Basicamente tratava-se de uma linha simples de código, só que a história não foi priorizada e por isso não entrou no Sprint.[...]“

Nós colocamos essa história no Sprint porque depois deu tempo. Quando chegamos na metade acabou faltando trabalho e faz parte das responsabilidades do time pedir mais histórias, e o P.O. escolheu essa história para ser implementada (dentre outras).

Além do mais, o ponto dessa história não é esse. O ponto é que, qualquer coisa, por menor e mais banal que seja, no mínimo e mais um item para ser testado e para dar problemas em produção.

[ ]s, gc

Tem uma boa discussão sobre isso aqui.

[ ]s, gc

>> http://gettingreal.37signals.com/ch05_Start_With_No.php

Agora se teu cliente nao aguenta isso, talvez ele nao seja um bom cliente pra ti

O problema é quando acontece o que houve no seu caso, qdo um desses detalhezinhos da algum erro… certamente eu teria escutado que eu deveria ter previsto que esse problema poderia ocorrer em producao.

[]s

No caso dessas tais coisinhas, ainda, acho que há uma grande diferença se o cliente está na mesma classe hierárquica dentro da mesma empresa, ou se o cliente é aquele que paga você para fazer algo e por estar pagando diz “Eu pago, você faz…”.

Não sei se fui bem claro…

Abraços

Acho que ser o chato é o ponto mesmo, mas pergunto: E o caso de voce ter um cliente mais chato que voce? :S

[]s

Quanto aos clientes, as vezes tenho vontade de ensina-los a programar ou no minimo modelar. Mas na verdade isso eh uma questao que o agile te dah certas vantagens dependendo de como tu aborda isso com o cliente. Se tu trabalha com algum contrato de escopo negociavel, tu geralmente recebe pelas “coisinhas a mais”, agora quando a coisinha a mais eh ignorada ou subestimada, e geralmente o eh, a coisa fica feia

Agora o pior eh quanto ao teu time.
Nao tem escolha, o ponto eh ser O CHATO MESMO…tens que bater o peh!!!
O mais dificil eh q as pessoas soh aprendem da pior forma.