Uma equipe XP deve reunir o máximo possível de habilidades técnicas e de negócio possiveis para desenvolver o software. A hierarquia entre os desenvolvedores deve ser rasa e não é recomendável estabelecer uma divisão de tarefas. Inicialmente as responsabilidades são distribuidas de acordo com as especialidades de cada um mas gradualmente, espera-se que essas especialidades […]
Medição e Métricas de Software
O papel da medição de software é quantificar alguns atributos de um produto ou de um processo de software. Comparando essas informações é possível tirar conclusões sobre a qualidade do software. Possibilita ainda mensurar se mudanças organizacionais – adoção de novas ferramentas, metodologias dentre outros – estão sendo positivas ou não para os processos de […]
Qualidade de Software
Atingir um alto nível de qualidade de produto ou serviço é uma exigência inerente ao mercado. Quando se trata de qualidade de software não se foge a regra e não é aceitável entregar produtos com baixa qualidade e descobrir as deficiências e problemas após entregar o produto ao cliente. 1.1 A Importância da Qualidade de […]
Engenharia de Requisitos
Os problemas que os engenheiros de software precisam solucionar, muitas vezes, podem ser muito complexos. Compreender corretamente o problema se torna muito difícil, especialmente se o sistema for novo. E claro, fica difícil definir com clareza o que o sistema deve fazer. A descrição das funções e das restrições são os requisitos do sistema. O […]
A Equipe e os Papéis no Scrum
O framework Scrum é formado por times scrum e os papéis a estes associados, time boxes (eventos com duração fixa) artefatos e regras. Os times scrum são configurados de modo a otimizar a flexibilidade e a produtividade. Por esse motivo os membros de um Time Scrum são auto-organizáveis, interdisciplinares e trabalham em iterações. Cada grupo […]
O Ciclo de Vida do Framework Scrum
A figura acima representa o ciclo de vida do desenvolvimento de software utilizando o framework Scrum. Nela podemos observar que o Product Owner e a equipe, baseados na visão inicial do produto, definem as histórias a serem desenvolvidas, ou seja o Backlog de Produto. Posteriormente quebram-no em pequenas “histórias” menores, originando vários Backlogs de Sprint. […]