# data[].attributes.body
Desenvolvido em 2003 e comprado pela IBM, é um processo de desenvolvimento de software que fornece um framework para desenvolver a eficiência do desenvolvimento de software.

# data[].attributes.body
Essas são as quatro fases do ciclo de vida:

Concepção: Parte onde tem-se uma visão inicial e clara do projeto. Os artefatos que devem ser entregues são: visão de projeto, caso de negócio, plano de projeto e lista preliminar de requisitos.

Elaboração: Nessa fase faz-se a análise detalhada de riscos e requisitos, além da identificação de riscos. Os artefatos que devem ser entregues são: Especificação de Requisitos, Arquitetura do Sistema, Plano de Iteração e Protótipo.

Construção: Nessa fase se realiza a construção do código e testes. Os artefatos que devem ser entregues são: Código Fonte, Documentação do Código, Testes Unitários e Relatório de Progresso.

Transição: O foco é garantir entrega e treinamento referente ao sistema ao usuário. Os artefatos que devem ser entregues são: Software Entregável, Manual do Usuário, Relatório de Testes e Plano de Suporte.

Seguem suas nove disciplinas:

1. Modelagem de Negócios: Estabelece uma visão geral do projeto, a partir das necessidades do cliente, oportunidades e requisitos.

2. Requisitos: Vêm a partir da análise da documentação e avaliação das necessidades e requisitos do sistema.

3. Análise e Design: Envolve transformar os requisitos numa arquitetura detalhada e numa interface que esteja em concordância com o solicitado pelo cliente.

4. Implementação: Envolve tornar o projeto e design em um código executável.

5. Testes: Fazer a verificação para saber se o sistema está livre de defeitos.

6. Implantação: Trata-se da distribuição do sistema aos usuários finais.

7. Gestão de Configuração e Mudança: Tem haver com o controle de versões de software e gerenciamento de mudanças.

8. Gestão de Projeto: Coordenação, planejamento e monitoria de processos relacionados ao projeto.

9. Ambiente: Envolve infraestrutura, hardware e outros componentes físicos que afetam o software.

# data[].attributes.body
1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

# data[].attributes.body
Seguem exemplos de benefícios da metodologia:

Melhoria da Qualidade do Software, Maior Satisfação do Cliente, Flexibilidade e Adaptabilidade, Maior Produtividade da Equipe, Redução de Riscos, Cultura de Melhoria Contínua, Maior Envolvimento e Motivação da Equipe

# data[].attributes.body
Seguem os valorem fundamentais da metodologia:

Comunicação

Feedback

Coragem

Respeito

Simplicidade

# data[].attributes.body
1. 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.

2. 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

3. 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.

4. 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.

5. 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.

6. 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.

# data[].attributes.body
1. Ê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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

# data[].attributes.body
Seguem as cinco etapas do processo:

1. Desenvolvimento do Modelo de Domínio:

O modelo de domínio captura as entidades principais do sistema, seus relacionamentos e as responsabilidades de cada uma.

A equipe de desenvolvimento colabora para criar e refinar o modelo de domínio, garantindo uma compreensão comum do problema e uma base sólida para identificar funcionalidades.

2. Construção da Lista de Funcionalidades (Features):

Com base no modelo de domínio, a equipe de desenvolvimento identifica e lista todas as funcionalidades necessárias para o sistema.

Cada funcionalidade é descrita de forma concisa e inclui uma descrição detalhada de sua finalidade, critérios de aceitação e outras informações relevantes.

As funcionalidades são priorizadas com base no valor para o cliente e na complexidade de implementação.

3. Planejamento por Funcionalidade (Feature Planning):

Nesta etapa, a equipe de desenvolvimento seleciona um conjunto de funcionalidades prioritárias para serem desenvolvidas em uma iteração.

Cada funcionalidade é analisada mais detalhadamente para identificar tarefas específicas necessárias para sua implementação.

Com base na capacidade da equipe e na estimativa de esforço, são definidos prazos para a entrega de cada funcionalidade.

4. Projeto por Funcionalidade (Feature Design):

Uma vez que as funcionalidades foram planejadas, a equipe de desenvolvimento começa a projetar a arquitetura e o design técnico necessário para implementar cada funcionalidade.

O design é orientado pela lista de funcionalidades selecionadas para a iteração, garantindo que a equipe se concentre nas necessidades imediatas do projeto.

5. Construção por Funcionalidade (Feature Build):

Na última etapa do processo FDD, a equipe de desenvolvimento implementa e testa as funcionalidades selecionadas para a iteração.

Cada funcionalidade é desenvolvida de forma iterativa e incremental, com ciclos curtos de desenvolvimento, teste e revisão.

Uma vez concluídas, as funcionalidades são integradas ao sistema e testadas em conjunto para garantir que funcionem corretamente e atendam aos requisitos do cliente.

# data[].attributes.body
1. Gerente de Projeto:

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

2. Arquiteto-Chefe:

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

3. Dono da Lista de Funcionalidades (Feature Owner):

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

4. Líder Técnico (Technical Lead):

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

5. Membros da Equipe de Desenvolvimento:

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

# data[].attributes.body
Framework Scrum:

1. Papéis Principais:

Product Owner

Scrum Master

Equipe de Desenvolvimento

2. Eventos:

Sprint Planning

Daily Scrum

Sprint Review

Sprint Retrospective

3. Artefatos:

Product Backlog

Sprint Backlog

Incremento

Papéis Principais:

1. Product Owner:

Representa os interesses dos stakeholders e é responsável por maximizar o valor do produto.

Define e prioriza os itens do Product Backlog com base nas necessidades do cliente e nas oportunidades de mercado.

Trabalha em estreita colaboração com a equipe de desenvolvimento para garantir que os itens do Product Backlog sejam compreendidos e entregues de forma eficaz.

2. Scrum Master:

É um facilitador e servo-líder responsável por garantir que o Scrum seja compreendido e implementado corretamente pela equipe.

Remove obstáculos que impedem o progresso da equipe, facilita reuniões e eventos do Scrum e ajuda a equipe a resolver problemas.

Ajuda a garantir que a equipe siga os princípios e práticas ágeis, bem como a melhorar continuamente sua eficácia e desempenho.

3. Equipe de Desenvolvimento:

São os profissionais que transformam os itens do Product Backlog em incrementos potencialmente entregáveis de produto no final de cada Sprint.

Auto-organizam-se para realizar o trabalho de forma eficaz, sem necessidade de supervisão direta.

Colaboram intensamente, compartilham responsabilidades e trabalham em conjunto para alcançar os objetivos do Sprint e do produto.

# data[].attributes.body
1. 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.

2. 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.

3. 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.

4. 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.

# data[].attributes.body
1. 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.

2. 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.

3. 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.

4. 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.