Para participar da minha mentoria exclusiva, o primeiro passo é preencher a aplicação que está neste link aqui: https://form.respondi.app/bF2OsgO5 Texto do podcast: Durante uma de minhas mentorias sobre Gestão Ágil, uma cliente relatou o seguinte: "Na nossa Sprint Review todos os desenvolvedores mostram o seu trabalho, esteja ele pronto pra uso ou não, mesmo que ele não tenha sido testado." Segundo ela isso acontecia porque em algumas Sprints, muitos histórias de usuário eram finalizadas do ponto de vista do desenvolvimento, mas não eram testadas. Se os itens não testados não pudesse ser mostrados na Sprint Review, praticamente nada poderia ser mostrado. Isso geraria uma frustração muito grande nos desenvolvedores, que de certa forma passariam por "incompetentes". E eles não eram incompetentes, pois tinham feito o "seu trabalho". Essa abordagem tem muitos problemas. Uma Sprint Review serve para que o time mostre o trabalho que foi completado. A finalidade principal é obter feedback do cliente. Um trabalho completado, do ponto de vista do Scrum, é aquele que atendeu à Definição de Pronto. A definição de pronto é um acordo entre todo o time sobre tudo que deve ser feito sobre um item para que ele possa ser considerado pronto. E não dá pra imaginar que, em desenvolvimento de software um item esteja pronto sem ter sido testado. Parece uma convenção besta, burocrática, mas não é. Vamos ver alguns problemas que ocorrem quando apresentamos itens não testados em uma Sprint Review? - Esse comportamento passa uma falsa sensação de progresso. Esse não teste realizado pode estar escondendo uma quantidade gigantesca de trabalho ainda a ser realizado, pois bugs nem sempre são simples de corrigir. - Durante a apresentação para os clientes na Sprint Review, os bugs podem aparecer e isso pode afetar a confiança dos stakeholders no trabalho da equipe de desenvolvimento. - Uma parte importante da revisão de sprint é obter feedback dos stakeholders. Se a história não foi testada, o feedback pode não ser totalmente relevante ou preciso, pois baseia-se em funcionalidades que ainda podem sofrer alterações significativas. - O tempo do cliente é valioso. Ele não tá ali pra ouvir status report de desenvolvedor. Ele não tem o menor interesse (e não deve ter mesmo) em saber detalhes de como foi difícil fazer isso ou aquilo. Ele só quer ver o que está pronto pra ele. Se ele sacar que seu tempo está sendo desperdiçado, ele simplesmente não vai mais participar. - E o mais importante: a Sprint finalizou e praticamente nada poderá ser colocado em uso. Até um item estar de fato liberado para o mercado ele é apenas custo. Todo o valor do trabalho só pode ser materializado quando ele chega de fato às mãos do cliente. "Mas o que eu devo fazer então? ", perguntou a minha cliente. "Também acho muito errado gastarmos uma sprint inteira e não ter nada pra apresentar." A solução é simples. Foque em menos itens, de forma que haja tempo para se fazer todo o trabalho, inclusive o teste. Isso é basicamente o que prega o Kanban, dimunir o trabalho em progresso. Outra saída é quebrar mais os itens, de forma a torná-los menores. Assim, a chance de finalizá-los por completo também aumenta. Se você também tem problemas ao aplicar a gestão ágil ou a gestão de projetos, considere fazer parte da minha mentoria exclusiva. Para participar, o primeiro passo é preencher a aplicação que está na descrição desse vídeo. A mentoria é paga, mas vai ser o melhor investimento em formação que você já fez.

Ask this episode

“What did the council decide on item 42?” — answered with the speaker and the moment.

Transcript

Related