Bugs, alteração de requisitos e o dilema do PO

IMG_2395
No meu último post, não tive oportunidade de explorar alguns problemas que se observam na gestao de um backlog, e que se tornam mais importantes, depois de iniciada a fase de implementação: bugs (ou defeitos) e alteração de requisitos  (ou change requirements – CR).
Bugs e CRs tem que ser incluídos no backlog, bugs têm mesmo que ser resolvido e ignora-los custar-nos- á a insatisfação do utilizador/ usuário. Neste post vamos tocar diferentes questões: que tipo de bugs e CRs poderemos enfrentar, e em que contextos, quem normalmente os reportará em backlog e como resolverá o Product Owner, o dilema entre ocupar capacidade com uma nova funcionalidade ou a corrigir bugs ou a melhorar/ adaptar os detalhes do produto (CR).

Tipo de bugs e alteracao de requisitos (CRs) que podemos enfrentar

Dentro de um backlog observamos requisitos com diferentes níveis de detalhe, uns de alto nível (mais próximos da estratégia) e outros mais detalhados (mais próximos da implementação). No que se refere a bugs e alteracao de requisitos (CRs) quem os deve escrever no backlog? Sim porque é fundamental que toda esta informacao seja lá documentada e que o Product Owner e toda a equipa tenha nocao do trabalho e do estado do produto. A transparencia é uma vantagem do backlog.
Um bug é um defeito do software, um comportamento que não corresponde ao que foi inicialmente especificado, uma função que não é realizada ou é realizada com um desvio relativamente à especificação inicial(por exemplo, o output é parcialmente entregue, é entregue com defeitos, ou não é de todo entregue).
Uma alteração de requisito é uma adaptação ou alteração no comportamento do software, considerando uma especificação inicial.
Um bug é normalmente descrito e consideram-se na descricao dois critérios: gravidade e frequência. Gravidade significa o quanto ele bloqueia o usuário/ utilizador final na utilizacao do produto como especificado inicialmente. Muitas vezes, também se toma em consideracao a importância da funcionalidade afectada (por exemplo, é uma funcionalidade core do produto? ou apenas uma funcionalidade secundária, não usada tão frequentemente?). Frequência significa exactamente o número de vezes isso acontece, num determinado período de tempo.
Um bug pode ser funcional se a função não for executada ou não-funcional se a funçãofor executada, mas alguns atributos do produto não funcionais são afetados, como a segurança ou o desempenho, por exemplo. Muitas vezes, bugs funcionais são acionados com testes de utilizador/ usuário (por exemplo, testes manuais, smoke tests ou sanity tests), ou testes automáticos (por exemplo, testes de regressão). Bugs não funcionais exigem métodos de teste mais complexos (por exemplo, testes de segurança, testes de penetração).
Uma alteração de requisitos também pode ser funcional ou não funcional e isso define normalmente quem o identifica e o regista no backlog.  Uma alteração de requisitos funcional é normalmente identificada pelo Product Owner ou pelo Arquitecto. Uma  alteração de requisitos nao funcional é normalmente registada pelo Arquitecto, test manager ou outro colega da equipe de desenvolvimento.
Tenha em mente que uma alteração de requisitos faz parte do ciclo de vida do produto natural. O que pode ser visto como ineficiência é se a  alteração de requisitos é introduzida no meio da release ou do sprint, sendo algo completamente fora do plano acordado com a equipa Agile. Também nao é sinal de eficiencia se esta alteracao diz respeito a um novo requisito que está ainda em implementação pela primeira vez, o que significa que se está a fazer uma correcao relativamente ao inicialmente planeado/ desenhado.


(adsbygoogle = window.adsbygoogle || []).push({});

O dilema do Product Owner entre ocupar capacidade com uma nova funcionalidade, corrigir bugs ou melhorar/adaptar detalhes do produto (CR)

Bugs e CRs que geralmente entram no backlog após a capacidade para o Sprint ou para a release estar ocupada e acordada correspondem a um grande erro de planeamento e ao desrespeito pelo acordo com a equipe. Antes de concordar com o ambito/escopo da release, o Product Owner deve ter claro o quanto quere investir na qualidade do produto e melhoria versus novas funcionalidade. Já tive a experiencia no passado em que era muito mais a equipa de desenvolvimento a zelar pela qualidade do produto que o próprio Product Owner. Mas seja como for esta competicao pela capacidade e foco da equipe deve ser resolvida entre a equipe e o Product Owner.


(adsbygoogle = window.adsbygoogle || []).push({});

Uncategorized

Leave a Reply