Imagine aquela sexta feira que você chegou em casa depois de uma semana cheia do trabalho e não quer fazer nada para comer, nem sair para comer. Você pede aquela pizza. Mesmo que coma em companhia de alguém, podem haver sobras.
Então você coloca as sobras na geladeira na esperança daqueles pedaços congelados virarem seu café da manhã, almoço ou jantar. No entanto, você lembra que fez alguns compromissos e que vai demorar um dia para voltar para casa.
Você volta sábado à noite e lembra que existe a pizza parada na geladeira, mas está cansado demais para fazer algo. Domingo você levanta e tem aquele almoço com a família. Você passa à tarde assistindo TV ou fazendo qualquer outra coisa. À noite você está em sua casa e lembra da sobra da pizza. Você olha para aqueles pedaços e fica pensando: "Será que não está estragado?".
Você se livra das sobras, jogando no lixo.
Imagine agora quando você faz aquela reforma na sua casa. Você compra tinta, azulejos, piso, cimenta, madeira, massa corrida, vidro, etc. Para que dê tudo certo, compra um pouco a mais da quantidade necessária, pois sabe que imprevistos podem ocorrer e guarda um pouco para futuros reparos.
Nesse caso, o material de construção só ocupará um pouco de espaço na sua casa em algum canto esquecido pelo tempo. De tempos em tempos você deve revisitar aquele material para garantir que nenhum passou da data de validade, se tiverem.
Agora você está em um projeto de software. Sua equipe está desenvolvendo um sistema, funcionalidade por funcionalidade. Independente da metodologia adotada, seu sistema é submetido à testes com o cliente e erros são registrados. Fácil, se o Product Owner achar melhor, ele transfere esses erros como backlog do sistema.
Mas vamos imaginar que o PO deixa esses erros para depois, para sprints posteriores. Ele decide "deixar na geladeira" ou naquele "canto esquecido pelo tempo". Os sprints passam e aqueles itens de backlog são revisitados sempre. Eles ficam com a promessa de sair da geladeira para o microondas ou de serem utilizados para serem utilizados para algum reparo.
É claro que na metodologia ágil, com algum processo de integração contínua, o código é sempre testado e a equipe de desenvolvimento sempre fica sabendo o que acontece. Mas às vezes o problema não é visível para os testes. Os problemas foram deixados para trás, pois não são testáveis unitariamente, são problemas de interface com o usuário que foram classificados como irrelevantes e ficaram congelados em um canto escuro para serem corrigidos depois.
E aí? Não dá para jogar fora e não dá para deixar em um canto esquecido. São sobras de software. Alguém vai ter que corrigir, alguém vai ter que ficar com as sobras. Ficar procurando por um culpado é inútil. Foi o Product Owner que deixou coisa sem corrigir para trás, pois não achava importante para o negócio, foi o Scrum Master que não teve iniciativa de brigar e puxar os problemas para o sprint atual e se comprometer em entregar menos, ou ainda a equipe que não alertou tecnicamente o PO.
Ou foi a empresa que determinou algo como prioritário ou não prioritário? O importante é que alguém vai ter que ficar com as sobras e isso não é bom. Sobras de software são duradouras e vão sempre incomodar, vir à tona e cheirar mal.
Não deixe que essas sobras venham incomodar.
No comments:
Post a Comment
Let me know your opinion