Questões de Governança de TI - Ciclo PDCA (Plan, Do, Check, Act) para Concurso

São de comprimento fixo, normalmente duas a quatro semanas. Eles correspondem ao desenvolvimento de um release do sistema em XP., O ponto de partida para o planejamento é o backlog do produto, que é a lista do trabalho a ser feito no projeto. Durante a fase de avaliação do sprint, este é revisto, e as prioridades e os riscos são identificados. O cliente está intimamente envolvido nesse processo e, no início de cada sprint, pode introduzir novos requisitos ou tarefas.

É o ponto central com poderes de liderança sobre o produto. Ele é o único responsável por decidir quais recursos e funcionalidades serão construídos e qual a ordem que devem ser feitos.

É simplesmente a junção de todas essas pessoas em uma equipe multidisciplinar, e que são responsáveis pela concepção, construção e testes do produto.

É o ponto central com poderes de liderança sobre o produto. Ele é o único responsável por decidir quais recursos e funcionalidades serão construídos e qual a ordem que devem ser feitos. É simplesmente a junção de todas essas pessoas em uma equipe multidisciplinar, e que são responsáveis pela concepção, construção e testes do produto.

É uma unidade de planejamento na qual o trabalho a ser feito é avaliado, os recursos para o desenvolvimento são selecionados e o software é implementado. No fim de um sprint, a funcionalidade completa é entregue ao CEO.

É uma atividade na qual se identifica um item no product Backlog, associa-se a um desenvolvedor e aplica-se técnicas de gestão para o aumento da produtividade.

É uma unidade de planejamento na qual o trabalho a ser feito é avaliado, os recursos para o desenvolvimento são selecionados e o software é implementado. No fim de um sprint, a funcionalidade completa é entregue aos stakeholders.

É uma atividade que busca planejar as fases seguintes considerando a característica da equipe.

Comunicação, planejamento, modelagem, construção, teste e implantação.

Engenharia de sistemas, análise, projeto, codificação, testes, implantação.

Concepção, planejamento, modelagem, construção.

Concepção, elaboração, construção e transição.

Test-driven Development (TDD) permite que seus testes modelem a forma do design do sistema

Domain-driven Design (DDD) é uma coleção de padrões e princípios que ajudam em seus esforços para construir aplicações que refletem uma compreensão e a satisfação das exigências do seu negócio

Behavior-driven Design (BDD) as especificações criadas quando utilizado BDD usam a mesma linguagem onipresente como visto no domínio real, o qual pode ser benéfico tanto para usuários técnicos como para usuários de negócio

Test-driven Development (TDD) visa uma automatização do processo de negócio, de modo que o foco é no domínio do software a fim de atender completamente um determinado negócio