Mudanças entre as edições de "Sprint 61"
| Linha 9: | Linha 9: | ||
'''[André 16/05]''' Ao corrigir um bug, lembrar de colocar um comentário com o que foi realizado para a correção. Durante a análise e correção do bug, muitas vezes o desenvolvedor implementa correção diferente do que foi sugerido pelo tester ou outra correção alinhada com os responsáveis pelo projeto. É importante para o tester saber o que foi realizado, se teve alguma mudança de definição, para que possa direcionar o reteste corretamente. | '''[André 16/05]''' Ao corrigir um bug, lembrar de colocar um comentário com o que foi realizado para a correção. Durante a análise e correção do bug, muitas vezes o desenvolvedor implementa correção diferente do que foi sugerido pelo tester ou outra correção alinhada com os responsáveis pelo projeto. É importante para o tester saber o que foi realizado, se teve alguma mudança de definição, para que possa direcionar o reteste corretamente. | ||
| + | |||
| + | '''[André 16/05]''' Desenvolvedores: questionar mais os POs na hora de desenvolver um requisito, para entender todos os pontos que estão implícitos nos documentos. | ||
Edição das 18h35min de 16 de maio de 2016
Página criada para anotar os pontos negativos e positivos da sprint, durante seu andamento. Durante a retrospectiva, vamos consultar essa página e registrar aqui as sugestões de melhoria.
[André 11/05] Houve impedimento para testar a tarefa de Compensação de ausências. Precisei de auxílio do Juliano, porém ele estava com outras demandas e não conseguiu me atender prontamente. Não havia outras tarefas para serem testadas naquele momento. Tive sorte de ter a reunião da brigada de incêndio no período da tarde, pois no período que estive fora a Márcia conseguiu resolver meu impedimento. Caso contrário, eu ficaria sem atividades.
[André 13/05] Conforme comentado na reunião diária, o apontamento das horas no Youtrack está sendo mais satisfatório. Provavelmente se deve ao fato de não usarmos mais o TFS, o que facilita o apontamento.
[André 16/05] Ao corrigir um bug, lembrar de colocar um comentário com o que foi realizado para a correção. Durante a análise e correção do bug, muitas vezes o desenvolvedor implementa correção diferente do que foi sugerido pelo tester ou outra correção alinhada com os responsáveis pelo projeto. É importante para o tester saber o que foi realizado, se teve alguma mudança de definição, para que possa direcionar o reteste corretamente.
[André 16/05] Desenvolvedores: questionar mais os POs na hora de desenvolver um requisito, para entender todos os pontos que estão implícitos nos documentos.
