Gerente de Projeto:

• Responsável por coordenar todas as atividades do projeto.

• Define objetivos, planeja o cronograma e alocar recursos.

• Gerencia riscos, comunicação e relatórios de progresso.

Arquiteto de Software:

• Responsável por definir a arquitetura técnica do sistema.

• Define padrões, diretrizes de design e componentes principais.

• Colabora com a equipe para garantir que a implementação esteja alinhada com a arquitetura.

Analista de Negócios:

• Responsável por entender as necessidades do cliente e traduzi-las em requisitos claros e mensuráveis.

• Elicita, analisa, documenta e valida os requisitos do sistema.

• Colabora com as partes interessadas para garantir que os requisitos do cliente sejam atendidos.

Desenvolvedor:

• Responsável por escrever código fonte de alta qualidade de acordo com os requisitos do sistema e as diretrizes de design.

• Realiza testes unitários para garantir a qualidade do código.

• Colabora com outros membros da equipe para integrar e testar componentes do sistema.

Testador:

• Responsável por planejar, projetar e executar testes para garantir a qualidade do software.

• Identifica e relata bugs encontrados durante os testes.

• Colabora com desenvolvedores para corrigir e retestar os defeitos.

Administrador de Configuração:

• Responsável por gerenciar a configuração do software, incluindo versionamento, controle de mudanças e integração de código.

• Garante que todos os artefatos e componentes do sistema sejam mantidos em um estado controlado e rastreável.

Especialista em Implantação:

• Responsável por planejar e executar a implantação do software no ambiente de produção.

• Coordena a migração de dados, instalação do software e treinamento de usuários.

• Fornece suporte técnico inicial após a implantação do sistema.

Programação em Pares (Pair Programming):

• Nesta prática, dois programadores trabalham em conjunto em um mesmo computador para escrever código, onde um fica responsável por fazer o código e o outro por revisar, promovendo assim a melhoria do código.

Teste de Software (Test-Driven Development - TDD):

• No TDD, os testes automatizados são escritos antes mesmo de escrever o código de produção.

• Os testes são elaborados para falhar inicialmente, representando o comportamento do software, é feito para garantir que o software atenda aos requisitos

Integração Contínua (Continuous Integration):

• A prática de integração contínua envolve a integração frequente do código produzido por diferentes membros da equipe.

• Cada vez que o código é integrado, testes de integração são executados para garantir que o sistema continue funcionando corretamente.

Desenvolvimento Incremental (Incremental Development):

• O desenvolvimento incremental envolve a entrega de funcionalidades em pequenos incrementos ao longo do tempo.

• Cada incremento adiciona valor tangível ao software e pode ser entregue ao cliente para feedback.

• Isso permite uma resposta mais rápida às mudanças de requisitos e uma maior flexibilidade durante o desenvolvimento.

Refatoração (Refactoring):

• Refatoração envolve a melhoria do código existente sem alterar seu comportamento externo.

• Os desenvolvedores fazem pequenas alterações no código para torná-lo mais claro, eficiente e fácil de manter.

Cliente no Local (On-site Customer):

• Essa prática envolve ter um representante do cliente disponível no local para colaborar com a equipe de desenvolvimento.

• O cliente fornece feedback contínuo sobre as funcionalidades desenvolvidas, esclarece requisitos e prioriza o trabalho.

Ênfase em Funcionalidades (Features):

• No FDD, o desenvolvimento é orientado pela identificação e entrega de funcionalidades específicas que agregam valor ao software.

• Cada funcionalidade é identificada, planejada, projetada, implementada e testada de forma independente.

• O FDD se concentra em construir um conjunto de funcionalidades completas e integradas, em vez de apenas focar em atividades de baixo nível, como escrever código.

• Logo, erros menores acabam se tornando mais difíceis.

Modelagem de Domínio:

• Usado para identificar o problema e as funcionalidades necessárias.

• O modelo de domínio é modificado ao longo do tempo à medida que novas funcionalidades são identificadas e implementadas.

Iterações Curtas e Sucessivas:

• O FDD adota iterações curtas e sucessivas, geralmente com duração de uma ou duas semanas.

• Cada iteração é focada na entrega de uma ou mais funcionalidades específicas, desde a concepção até a implementação e teste.

• As iterações ajudam a manter o desenvolvimento progressivo e fornecem feedback rápido sobre o progresso do projeto.

Inspeção Regular de Progresso:

• Mede-se o progresso com base nas funcionalidades entregues e de forma regular para garantir o avanço na direção certa.

Equipe Multifuncional:

• O FDD promove o trabalho em equipe de uma maneira multidisciplinar, onde os membros da equipe têm habilidades variadas e complementares.

• Isso permite que a equipe colabore de forma eficaz na identificação, planejamento, projeto e implementação das funcionalidades.

Liderança Ativa e Orientada por Resultados:

• O FDD enfatiza a importância de uma liderança ativa e orientada por resultados para garantir que o projeto avance de maneira eficiente e atenda aos objetivos definidos.

• Os líderes são responsáveis por facilitar o progresso, remover obstáculos e manter a equipe focada na entrega de funcionalidades de alto valor.

Gerente de Projeto:

• Responsável por coordenar e liderar o projeto como um todo.

Arquiteto-Chefe:

• Responsável por definir a arquitetura técnica do sistema.

Dono da Lista de Funcionalidades (Feature Owner):

• Responsável por gerenciar a lista de funcionalidades do projeto.

Líder Técnico (Technical Lead):

• Responsável por liderar a equipe de desenvolvimento no aspecto técnico do projeto.

Membros da Equipe de Desenvolvimento:

• São os desenvolvedores responsáveis por implementar as funcionalidades do sistema.

Planejamento de Sprint (Sprint Planning):

• O Planejamento de Sprint é realizado no início de cada Sprint.

• A equipe de Scrum, composta pelo Product Owner, Scrum Master e Equipe de Desenvolvimento, participa desta reunião.

• Durante o Planejamento de Sprint, a equipe seleciona itens do Product Backlog e define as metas para a Sprint.

• O Product Owner descreve os itens do Product Backlog mais importantes, esclarece dúvidas e prioriza os itens.

• A Equipe de Desenvolvimento discute como eles vão implementar as funcionalidades selecionadas e se compromete com a entrega de um incremento potencialmente entregável até o final da Sprint.

• O resultado desta reunião é um Sprint Backlog, que contém as tarefas necessárias para atingir os objetivos da Sprint.

Reuniões Diárias (Daily Scrum ou Daily Stand-up):

• A Reunião Diária é realizada todos os dias durante a Sprint, de preferência no mesmo horário e local.

• É uma reunião curta, com duração máxima de 15 minutos, onde a equipe de Scrum se encontra para sincronizar atividades e discutir o progresso do trabalho.

• Cada membro da equipe responde a três perguntas: O que foi feito desde a última reunião? O que será feito até a próxima reunião? Existem quaisquer impedimentos?

• O objetivo é manter todos os membros da equipe informados sobre o progresso do trabalho, identificar impedimentos e garantir que a equipe permaneça focada nos objetivos da Sprint.

Revisão de Sprint (Sprint Review):

• A Revisão de Sprint ocorre no final de cada Sprint, antes da Reunião de Retrospectiva.

• Durante esta reunião, a equipe de Scrum apresenta o incremento desenvolvido durante a Sprint.

• O Product Owner descreve as funcionalidades completadas e as que não foram completadas, conforme o planejado.

• A equipe de Scrum e os stakeholders discutem o incremento, fornecem feedback e identificam possíveis ajustes no Product Backlog.

• O objetivo é revisar o trabalho realizado durante a Sprint, obter feedback dos stakeholders e ajustar o Product Backlog conforme necessário.

Retrospectiva de Sprint (Sprint Retrospective):

• A Retrospectiva de Sprint é realizada após a Revisão de Sprint, também no final de cada Sprint.

• Durante esta reunião, a equipe de Scrum reflete sobre a Sprint que acabou de ser concluída.

• A equipe discute o que funcionou bem durante a Sprint, o que não funcionou tão bem e identifica oportunidades de melhoria.

• São discutidas ações específicas que podem ser tomadas para melhorar o processo de desenvolvimento e aumentar a eficácia da equipe na próxima Sprint.

• O objetivo é promover a aprendizagem contínua e a melhoria do processo de desenvolvimento ao longo do tempo.

Product Backlog (Lista de Backlog do Produto):

• O Product Backlog é uma lista priorizada de todas as funcionalidades, requisitos, melhorias e correções de bugs necessárias para o produto.

• É de responsabilidade do Product Owner gerenciar e manter o Product Backlog, garantindo que esteja sempre atualizado e refletindo as necessidades e prioridades do cliente e do negócio.

• Os itens do Product Backlog são geralmente descritos em termos de valor para o cliente, riscos, esforço estimado e dependências.

Sprint Backlog (Backlog do Sprint):

• O Sprint Backlog é uma lista de itens selecionados do Product Backlog que a equipe de Scrum concordou em completar durante uma Sprint específica.

• É criado durante o Planejamento de Sprint, onde a equipe de Scrum decide quais itens do Product Backlog serão incluídos na Sprint.

• O Sprint Backlog é uma visão detalhada do trabalho que será realizado durante a Sprint e geralmente inclui tarefas específicas, estimativas de esforço e responsáveis pela execução.

Incremento:

• O Incremento é o resultado do trabalho realizado pela equipe de Scrum durante uma Sprint.

• É uma versão potencialmente entregável do produto que inclui todas as funcionalidades completadas até o final da Sprint, bem como quaisquer outras melhorias ou correções de bugs.

• O objetivo de cada Sprint é produzir um incremento de trabalho funcional e valioso que possa ser entregue ao cliente ou colocado em produção.

Gráfico de Burndown:

• O Gráfico de Burndown é uma ferramenta visual que mostra o trabalho restante ao longo do tempo durante uma Sprint.

• Ele acompanha o progresso da equipe de Scrum em relação ao Sprint Backlog, mostrando o trabalho restante em relação ao tempo.

• O eixo horizontal representa o tempo (dias da Sprint), enquanto o eixo vertical representa o trabalho restante (geralmente em unidades de horas ou pontos de história).

• O Gráfico de Burndown ajuda a equipe a monitorar seu progresso, identificar tendências e tomar medidas corretivas, se necessário, para garantir que todos os itens do Sprint Backlog sejam concluídos até o final da Sprint.