(1)
Chapéus indicam papéis. Uma pessoa pode assumir mais de uma função, ou Papéis diferentes em momentos diferentes.
(Abu): Em Scrum as equipes são generalistas, todos os integrantes da equipe devem e podem executar vários papeis, conforme a necessidade do projeto
(2)
Um testador, desenvolvedor e perito em domínio se reúnem com o dono do produto (Product Owner) para entendimento das histórias. Gradualmente as historias são decompostas e quebradas em um conjunto de especificações mais simples.
(Abu): Quase sempre as historias possuem mais de uma responsabilidade, esta sobrecarga de responsabilidade é o que nos chamamos de “Temas de Historia”. Uma historia com características de “Temas” devem ser quebradas em historias menores. O ideal é que uma historia possua apenas uma responsabilidade. Uma historia com apenas uma responsabilidade pode ser decomposta em “Tarefas” e executadas pela equipe.
(3)
O dono do produto (Product Owner) decide quais as historias vão ser trabalhadas e detalhadas na iteração. O escopo fechado da iteração não pode ser modificado.
(Abu): Em Scrum nos falamos que no planejamento da Sprint o Product Owner escolhe os Itens de Backlog que devem ser executados na Sprint. Os itens escolhidos pelo product Owner e comprometidos de serem entregues pela equipe não podem ser modificados.
(4)
Todos os comportamentos esquecidos pela equipe na iteração atual de trabalho, deve ser deixado para a próxima iteração. Estes comportamentos devem ser priorizados com o Product Owner para a definição da iteração correta de sua execução.
(Abu):Dentro da execução da Sprint vão ser encontrados novos comportamentos que a equipe não conseguiu identificar na reunião de planejamento da Sprint. Neste caso, estes comportamentos devem ser colocados como novos Itens de Backlog e no momento correto (Planejamento da Sprint) priorizado pelo Product Owner, para ser executado. Não devemos colocar mais Itens de Backlog numa Sprint que já esta negociada, pois corre o risco de não poder ser entregue o que já foi comprometido.
(5)
Desenvolvimento dos instrumentos de especificações, criação de erros e implementação das funcionalidades.
(Abu): Neste item a equipe desenvolve os artefatos necessários para o sistema, cria os testes (TDD) para que eles falhem e desenvolvem as funcionalidades esperadas pelo software. Esta é uma técnica de desenvolvimento, onde após os testes terem falhados, nos criamos as funcionalidades que permitam com que os testes cheguem ao resultado esperado. Um desenvolvimento focado a teste faz com que nosso código fique mais simples e principalmente coeso. Eu gosto muito dos testes, eles permitem a identificação e implementação de classes e métodos mais simples.
(6)
Depois que todos os testes forem passando, a história pode ser demonstrada ao dono do produto (Product Owner). Deve ser realizado testes manuais também.
(Abu): Em Scrum nos falamos que o Product Owner sempre esta presente e por estar presente ele sabe o que esta sendo entregue ou não. Mas mesmo com a sua presença nos temos uma reunião de Sprint Review, onde nesta reunião é oficializado o que esta sendo entregue e o que não foi possível de ser entregue, bem como a justificativa dos problemas encontrados. Mas o termo “Done” é definido junto com o Product Owner e deve fazer parte do conceito de “pronto” a execução e aprovação de todas as funcionalidades pelos testes. Também deve ser realizado testes manuais, que permitem a avaliação do produto como um “todo”. Fica a minha dica de utilização do software “Selenium” junto com o teste manual, para que este teste manual se torne um teste automatizado.
Abraços a todos,
Abu
Postagens
