Desde que o mundo é mundo sempre tentam fazer com que nós programadores façamos mais do que nós achamos que é possível. Não importa quanto tempo você leve para fazer uma determinada tarefa, sempre alguém vem com aquela pergunta: mas não dá pra fazer só mais essa coisinha aqui???
O problema é que nem sempre se tem a percepção exata do que essa “coisinha” significa. A cada “coisinha” a mais que se faz é mais uma coisinha para programar, errar, testar, integrar, testar denovo e dar bug em produção.
No último Sprint da minha equipe aconteceu uma coisa muito engraçada. Uma das tarefas era colocar uma imagem de uma determinada forma em um site. 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. De fato parecia ser uma coisa bem simples. Como era só uma linha de código e todo mundo sabia disso, fizeram uma força danada pra empurrar essa história para dentro do Sprint, mas eu fui o chato e repetí umas vinte vezes: é mais uma coisa para testar e dar bug.
Isso foi no início do Sprint. Casualmente, nos dois dias seguintes o time deu um salto e o trabalho ficou muito adiantado. Com isso foi necessário colocar mais umas histórias para o time não ficar sem o que fazer e entre essas histórias estava a tal da linha para colocar uma imagem numa tal posição.
Fim do Sprint, tudo estava testado e o pacote com a aplicação fechado. Quando colocamos o site em produção, das 17 (dezessete) histórias que fizemos adivinha qual foi a única que deu problema??? A maldita “coisinha”, que por causa de uma configuração que só existia no mod_rewrite do Apache de produção não funcionava nem por um milagre! Até descobrir esse problema e resolvê-lo levamos algumas horas, sem contar que manchamos nosso histórico de alguns Sprints sem colocar bugs em produção…
Essas “coisinhas” de última hora nunca são tão simples quanto parecem. No mínimo é mais uma coisa para testar e dar bug em produção. 🙂
15 replies on “Não dá pra fazer só mais uma coisinha?”
O incrivel eh como muitas vezes NINGUEM percebe a importancia ou complexidade dessas coisinhas…
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.
Em rarissimos casos encontraremos clientes que entendam a importancia dessas pequenas coisas. As vezes, é dificil ate mesmo para a equipe entende-los e encara-los como risco. No fim, quem leva a culpa por mais um bug é o time. 🙁
Acho que ser o chato é o ponto mesmo, mas pergunto: E o caso de voce ter um cliente mais chato que voce? :S
[]s
Vitor, não consigo visualizar… Poderia exemplificar?
Acho que o ponto não é o rótulo de chato. O ideal seria encontrar uma forma de negar que a tarefa seja realizada imediatamente. Talvez negociar seja o ponto. Por exemplo: [Cliente] “Pode colocar a figurinha em tal posição?”; [Você] “Posso, porém precisarei de mais tempo. Pode ser na próxima versão (Sprint)?”; [Cliente] “Mas é só uma coisinha”; [Você] “Você assume o risco? Formalize a solicitação citando o risco e a imagem será colocada, por sua conta, claro”. Dividir a responsabilidade com o cliente já o fará recuar e entender que se você, que conhece os riscos de implementar a tal “coisinha”, está receioso é porque realmente tem alguma coisa de errado. Se mesmo assim ele resolver assumir o risco, você implementa ou, dependendo de sua autonomia no projeto, assume a responsabilidade por ter negado a tal “coisinha” ao cliente.
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
Um dos meus clientes sempre consegue encaixar pequenas coisas em todas as subidas que eu faco. Apesar de varias vezes eu negar, ele sobe ate a ultima instancia da empresa dizendo “que é só um detalhezinho”. E acaba sempre conseguindo! 🙂
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
O ponto aqui, eh +- o que os caras da 37 signals falam: Say NO!
>> 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 🙁
Eu não concordo 100% com essa história da 37s., mas acho que a filosofia por trás disso é legal 🙂
Tem uma boa discussão sobre isso aqui.
[ ]s, gc
O engraçado é quando o cliente pede uma coisinha simples e essa coisinha que deveria satisfazê-lo, não o satisfaz… 😀
Eu ficava feliz em ver tal situação pois só assim o cliente aprende que no desenvolvimento de um sistema, nós também aprendemos com o próprio sistema que está em desenvolvimento numa total sinergia… abs!
O Pior é ainda quando o cliente fala: Mas isso é só um botãozinho. Isso você faz rapidinho em alguns minutos. LOL 🙂
É por isse tipo de atitude de diversos clientes que eu aprendi a usar uma palavra tão simples, mas que quase ninguém usa perante o cliente, que é a palavra “NÃO”. Se um “NÃO” tivesse sido dito ao cliente na devida hora, e logicamente com os devidos argumentos como justificativa do mesmo, talvez o bug não tivesse ocorrido na produção. Talvez com o “NÂO”, vc´s teriam tido mais tempo e mais atenção com essa simples linha que deveria ser alterada. Acho que vc´s(sua equipe inteira) deveriam ser humilhados em praça pública(pelo tio Dijkstra :D) depois de uma mancada dessas hehehe.
@Luiz
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
……….depois de eu tomar uma invertida e ser humilhado em praça pública(me sentindo sendo castigado por Dijkstra na praça da Sé). Nossa, que vergonha, tomar uma dura às 00:03 do domingo é de lascar hehehehe. Desculpa a brincadeira de post anterior caso ela tenha soado sarcástica ou arrogante ou qualquer coisa de ruim que seja. O fato é que a intenção não era nenhuma dessas. Agora voltando ao assunto principal. 🙂
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.
Relaxa, eu sei que foi brincadeira 🙂
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
[…] http://gc.blog.br/2008/05/05/nao-da-pra-fazer-so-mais-uma-coisinha/ […]
[…] não? E o que é que estamos fazendo quando não permitimos, de jeito nenhum, mudanças no backlog ao longo de um sprint? Só permitimos que novas tarefas entrem no […]