Questões de Concurso
Comentadas sobre processos de software - desenvolvimento ágil em engenharia de software
Foram encontradas 613 questões
( I ) Time-boxe de 8h, de acordo com o tamanho da Sprint. Nesta reunião é onde o Product Owner é ouvido em relação às prioridades e os objetivos. É nela também onde o time irá deliberar sobre o que conseguem fazer em relação às necessidades, formalizando o Sprint Backlog. ( II ) Time-box de 4h, onde o incremento do produto que está pronto para uso, é apresentado ao Product Owner para apreciação. Também é nesta reunião, que deve ser facilitada pelo Scrum Master, que o Product Owner apresentará os números, gráficos e tudo o mais que for importante à equipe saber sobre o produto. Novas prioridades e movimentos do mercado, tudo focado em manter os objetivos coerentes ao longo das sprints. Esse é o evento que melhor representa o pilar de inspeção do Scrum. ( III ) Time-box de 3h onde o time de desenvolvedores e o Scrum Master, que atua apenas como facilitador, falam sobre os resultados obtidos na Sprint que passou e as lições tiradas, para a partir daí melhorar o processo, fortemente arraigado ao pilar de adaptação. ( IV ) Time-boxe de 15 min, sempre no mesmo local e horário para gerar consistência e evitar perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e que popularmente é feita em pé, para evitar prolongamentos e distrações, cada membro do time deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem algo me impedindo.
Os tipos (I), (II), (III) e (IV) são denominados respectivamente:
Entre os vários papéis do SCRUM, o product owner é a única pessoa responsável por gerenciar o backlog do produto, possuindo, ainda, a responsabilidade de maximizar o valor do produto e do trabalho da equipe de desenvolvimento.
O objetivo do RAD é separar os modelos da visualização e do controle. Ele fornece o controlador e facilita a escrita de moldes padronizados para a camada de visualização.
Em um desenvolvimento ágil que segue o manifesto ágil, não se deve aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis não se adequam a mudanças não planejadas.
Situação hipotética: Uma empresa possui um grande sistema com todas as suas funcionalidades em uma aplicação que acessa um banco de dados. A aplicação foi desmembrada em várias outras, em formatos de contêineres que podem ser provisionados, iniciados e parados sob demanda em ambientes de homologação e desenvolvimento, porém, em produção, o deploy é feito manualmente. Assertiva: Nessa situação, configura-se um ambiente que possui práticas de entrega contínua.
No Scrum, as funcionalidades contidas em um sprint são definidas pelo ProductOwner no ProductBacklog.