Blogue

Explicação do retrabalho de software O retrabalho de software é o trabalho consequente que surge da alteração de requisitos, designs, código e testes após algum trabalho já ter sido iniciado. Na maioria dos empreendimentos de software, isso representa 30-50% de todas as atividades. Geralmente excluímos a correção de bugs da categoria de retrabalho de software. O retrabalho geralmente descreve o trabalho extra que é consequência da “mudança de requisitos”. Retrabalho de software – bom ou ruim Alguns retrabalhos podem ser vistos como um indicador positivo de que o feedback dos usuários está orientando a mudança em direção ao que é necessário. Isto é justo se as mudanças forem imprevisíveis. No entanto, os níveis típicos de retrabalho em software [...]

O Significado de "Dívida Técnica" A metáfora da Dívida Técnica (TD) no contexto do software foi cunhada por Ward Cunningham, que na época estava trabalhando na codificação de um sistema financeiro. Ele usou a metáfora para explicar aos seus colegas financeiros o raciocínio para refatorar e reescrever partes dos códigos à medida que o conhecimento dos requisitos evoluía. "Ao tomar atalhos e entregar código que não é adequado para a tarefa de programação do momento, uma equipe de desenvolvimento incorre em TD. Essa dívida diminui a produtividade. Essa perda de produtividade é do interesse do DT." A explicação original pretendida por Ward era bastante limitada [...]

Aqui estão alguns insights sobre o valor de encontrar defeitos de requisitos antes do design ou codificação. Para uma equipe de desenvolvimento de software, é muito valioso encontrar defeitos cedo. Melhor ainda, é prevenir defeitos completamente. Requisitos excelentes são uma forma eficaz de prevenção de defeitos e prevenção de retrabalho. Um requisito ambíguo pode levar a um esforço substancial desperdiçado. Ao prestar atenção à detecção de defeitos em requisitos de software, as equipes incorrerão em menos desperdício e, com mais frequência, entregarão certo na primeira vez. Defeitos surgem antes que a codificação comece Defeitos surgem em requisitos e arquitetura antes mesmo de a codificação começar. [...]

Divisão de histórias – refinamento para uma granularidade ideal Uma história aparentemente pequena pode acabar sendo muito maior do que o esperado. Somente através do refinamento ou da divisão da história você pode descobrir isso. A divisão da história pode ser feita no início ou logo antes do sprint anterior. Recomendamos fazê-lo o mais cedo possível para evitar surpresas tardias. Consideramos a “divisão da história” e o “refinamento da história” como atividades muito semelhantes. Trata-se de otimizar a granularidade da história de usuário escrita. O que são histórias de usuários Para as equipes que conseguem fazer colocation, a história de usuário pode ser apenas um lembrete de uma conversa. [...]

A Elicitação de Requisitos trata de descobrir os requisitos reais de negócios e os requisitos de sistema de qualquer empreendimento de software. Trata-se primeiro de descobrir o que é necessário e depois de articular as descobertas destiladas em artefactos que possam ser usados como base para descrever o que precisa de ser feito. É incomum que os requisitos reais do negócio (e os requisitos subsequentes do sistema) possam ser encontrados rapidamente. Embora a elicitação de requisitos seja algumas vezes chamada de coleta de requisitos, esta é uma frase enganosa. Os requisitos reais são mais como um tesouro enterrado em um campo, em vez de colheitas que podem ser colhidas. Às vezes, uma indicação de [...]

Vejamos como e por que podemos querer garantir a qualidade das histórias de usuários. Histórias de usuários ruins levam a reuniões desnecessárias, desperdício e retrabalho. Melhorar a história do usuário o mais cedo possível no ciclo de vida de desenvolvimento é uma forma eficaz de minimizar o desperdício e o retrabalho. A garantia de qualidade é uma abordagem sistemática para determinar se um “produto” atende a critérios aceitáveis. Para o controle de qualidade das histórias de usuários, precisamos primeiro definir o que é bom? Qual é a diferença entre boas histórias de usuários (e conjunto de histórias de usuários) e baixa qualidade. Para o desenvolvimento ágil de software tendemos a [...]