Issue: Colaboradores deverão mostrar entendimento do assunto que lhes foram atribuídos.
Repositório: 2024-2-Squad14
Data: 16/11/2024
Status: Aberto

Open
Tracked by
 #1
Colaboradores deverão mostrar entendimento do assunto que lhes foram atribuídos.
#2
ArturDCR opened this issue 3 weeks ago · 5 comments
Comments
@ArturDCR
Collaborator
ArturDCR commented 3 weeks ago
No description provided.

@ArturDCR ArturDCR mentioned this issue 3 weeks ago
Estudo: estudo de conceitos básicos #1
Open
1 task
@ArturDCR
Collaborator
Author
ArturDCR commented 3 weeks ago
Segue o resumo sobre o assunto definido:

Os critérios de aceitação de software são condições que precisam ser atendidas para que o produto seja considerado adequado e pronto para entrega. Eles ajudam a garantir que o software está alinhado com o que foi solicitado pelo cliente e que atende às expectativas definidas no início do projeto. Esses critérios devem ser claros, objetivos e testáveis para evitar mal-entendidos e problemas durante o processo de validação.

Principais aspectos dos critérios de aceitação:

Clareza e objetividade: As condições devem ser bem definidas, sem espaço para ambiguidades, para que todos os envolvidos compreendam facilmente.

Alinhamento com os requisitos: Os critérios precisam refletir os requisitos iniciais acordados entre o cliente e a equipe de desenvolvimento.

Mensurabilidade: Devem ser testáveis, ou seja, é necessário que haja uma maneira objetiva de verificar se o software atende às condições estabelecidas.

Abrangência:

Funcionalidade: Certificar-se de que o sistema realiza as funções planejadas corretamente.
Usabilidade: Garantir que o software é fácil de usar e intuitivo.
Desempenho: Avaliar a velocidade, eficiência e consumo de recursos.
Confiabilidade: Verificar se o sistema funciona sem falhas críticas.
Compatibilidade: Garantir que opera nos ambientes especificados.
Cenários de teste: É importante criar cenários reais para verificar se o software cumpre os critérios em situações práticas.

Por que os critérios de aceitação são importantes?

Alinhamento de expectativas: Eles ajudam a garantir que todos os envolvidos (clientes, usuários e equipe) estão na mesma página.
Qualidade do produto: Servem como referência para avaliar se o software está pronto para uso.
Base para testes: Facilitam a definição de testes de aceitação, permitindo identificar problemas antes da entrega final.
Os critérios de aceitação são fundamentais para assegurar que o software atende às necessidades e proporciona confiança no momento da entrega.

Fontes:

Pressman, Roger S. Engenharia de Software: Uma Abordagem Profissional*. McGraw-Hill.
Sommerville, Ian. Software Engineering. Pearson Education.
Boehm, Barry. "Verifying and Validating Software Requirements and Design Specifications".
Artigos e materiais da comunidade de desenvolvimento de software.
@lfelipebessa
Collaborator
lfelipebessa commented 2 weeks ago
Resumo sobre o Gráfico de Burndown no Desenvolvimento de Software

O gráfico de burndown é uma ferramenta visual que representa o trabalho restante em relação ao tempo estimado para concluí-lo. É amplamente utilizado por equipes ágeis para monitorar o progresso e ajustar o planejamento conforme necessário.

Componentes Principais:

•	Eixo X (Horizontal): Indica o tempo restante para a conclusão do projeto, geralmente medido em dias.
•	Eixo Y (Vertical): Representa o esforço remanescente necessário para finalizar o trabalho.
Linhas do Gráfico:

•	Linha Ideal (Trabalho Estimado):
•	Mostra a redução uniforme do trabalho em um cenário perfeito.
•	É geralmente uma linha reta que desce até zero no final do período.
•	Linha Real (Trabalho Remanescente):
•	Reflete o progresso real da equipe.
•	Pode apresentar variações devido a imprevistos ou mudanças no projeto.
Benefícios do Uso:

•	Monitoramento do Progresso: Permite verificar se a equipe está no ritmo certo para cumprir os prazos.
•	Planejamento Eficiente: Ajuda a ajustar recursos e cronogramas com base no progresso real.
•	Insights sobre a Equipe: Oferece visibilidade sobre a eficiência e possíveis obstáculos enfrentados.
Utilizar o gráfico de burndown facilita a comunicação dentro da equipe e com stakeholders, garantindo que todos estejam alinhados quanto ao status do projeto e possibilitando a tomada de decisões informadas.

Fontes:
https://www.atlassian.com/br/agile/tutorials/burndown-charts
https://asana.com/pt/resources/burndown-chart

@marcomarquesdc
Collaborator
marcomarquesdc commented 2 weeks ago
Planning Poker é uma técnica utilizada em metodologias ágeis, como o Scrum, para estimar o esforço necessário para realizar tarefas ou histórias de usuário. A ideia principal é promover discussões colaborativas entre os membros da equipe para chegar a um consenso sobre o tamanho relativo de cada item no backlog do produto.

Como funciona o Planning Poker
Preparação:

Cada membro da equipe recebe um conjunto de cartas com números (frequentemente na sequência de Fibonacci: 0, 1, 2, 3, 5, 8, 13, etc.).
Os números representam o esforço relativo ou complexidade de uma tarefa (não necessariamente o tempo em horas, mas a dificuldade comparada a outras tarefas).
Seleção da história:

O Product Owner apresenta uma história de usuário ou tarefa e explica o que é necessário fazer.
Discussão inicial:

Os membros podem fazer perguntas ao Product Owner ou ao time técnico para esclarecer dúvidas sobre os requisitos.
Votação:

Cada membro da equipe escolhe uma carta de sua mão que representa sua estimativa e a coloca virada para baixo.
Revelação:

Após todos escolherem suas cartas, elas são reveladas simultaneamente.
Discussão e consenso:

Se houver divergências significativas entre as estimativas, o time discute as razões.
Quem estimou valores muito baixos ou altos explica seu raciocínio.
Após a discussão, uma nova rodada de votação ocorre até que a equipe chegue a um consenso.
Registro da estimativa:

O valor final estimado é registrado no backlog.

@AndreMeyerr
Collaborator
AndreMeyerr commented 2 weeks ago
Dívida técnica é o termo usado em desenvolvimento de software para descrever as concessões feitas na qualidade do código ou design do sistema para entregar uma solução mais rapidamente. Essas escolhas podem economizar tempo no curto prazo, mas resultam em trabalho adicional no futuro, como correções, refatorações ou maior dificuldade de manutenção.

É frequentemente usado quando:
Pressão por prazos: Entregas rápidas levam a soluções temporárias.
Falta de planejamento: Decisões mal pensadas impactam o design e a arquitetura.
Código legado: Sistemas antigos que não seguem padrões modernos.
Falta de testes: Código entregue sem testes adequados.

Pode acarretar nas seguintes consequências:
Aumento dos custos de manutenção.
Maior dificuldade para adicionar novas funcionalidades.
Maior risco de bugs e falhas

@EduardoWaski
Collaborator
EduardoWaski commented 2 weeks ago
Do que se trata que se trata a história de usuário:
História de usuário é em suma, uma descrição breve de uma funcionalidade do ponto de vista de um usuário em questão.

Ela é muito utilizada pois comunica de forma simples as funcionalidades que um usuário final expera de sua aplicação.

Uma História de usuário geralmente segue o seguinte formato:

Como [quem?]
Eu quero [o quê?]
Para [por quê]
Segue um exemplo:

Como cliente do e-commerce, eu quero a funcionalidade de poder parcelar a minha compra para que eu possa ter mais tranquilidade nas contas do mês.

@EduardoWaski EduardoWaski closed this as completed 2 weeks ago
@EduardoWaski EduardoWaski reopened this 2 weeks ago

Contexto de uso: Inconclusivo
Categoria: Inconclusivo