Please enable JavaScript.
Coggle requires JavaScript to display documents.
Os 12 princípios do Manifesto Ágil, Manifesto Ágil, XP Extreme Programing…
-
Manifesto Ágil
Com a evolução da engenharia de software e os constantes fracassos dos projetos de desenvolvimento que utilizavam abordagens tradicionais, em 2001, 17 profissionais da área compilaram as melhores maneiras de desenvolver software..
Essa foi a origem do manifesto ágil, que foi uma grande mudança na forma de concepção de software
Esses tais de Métodos Leves eram os que hoje conhecemos como SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming entre outros.
Muitas pessoas foram contatadas porém apenas 17 estavam presente em fevereiro de 2001 em um resort de ski nas montanhas nevadas de Utah.
-
Robert Cecil Martin, conhecido como Tio Bob, criou um encontro para as pessoas interessadas em Métodos Leves.
Nomes Importantes
Kent Beck, criador do XP; Mike Beedle, CEO, Enterprise Scrum Inc.; Arie van Bennekum; Alistair Cockburn; Ward Cunningham, desenvolveu o primeiro Wiki; Martin Fowler, Chief Scienist da ThoughtWorks; James Grenning; Jim Highsmith;
Andrew Hunt; Ron Jeffries, um dos criadores do XP; Jon Kern; Brian Marick; Robert C. Martin; Steve Mellor; Ken Schwaber, co-criador do Scrum e Head da Scrum.org; Jeff Sutherland, co-criador do Scrum e CEO da Scrum Inc; Dave Thomas
-
-
XP Extreme Programing
“Metodologia ágil para equipes pequenas a médias desenvolvendo software com requisitos vagos ou que mudam frequentemente!"
Kent Beck, criador do XP
Contexto
Criado em 1996, o eXtreme Programming (XP) é um método que facilita o trabalho das equipes e aprimora a qualidade dos projetos.
-
-
Esta metodologia foi criada para produzir o software que o cliente precisa seguindo as especificações à risca.
Valores
Comunicação: A comunicação eficaz é fundamental. Os membros da equipe devem se comunicar abertamente e com frequência, compartilhando informações, ideias e preocupações para garantir uma compreensão clara dos requisitos e do progresso do projeto.
Simplicidade: Valoriza-se a simplicidade na XP. A equipe busca soluções simples para os problemas, evitando a adição de complexidade desnecessária ao software. Manter o código e o design simples facilita a manutenção e o entendimento.
Feedback: A obtenção de feedback é crucial. A XP promove a coleta constante de feedback dos clientes, dos testes e de outros membros da equipe para identificar áreas de melhoria e direcionar o desenvolvimento.
Coragem: Coragem é necessária para tomar decisões difíceis. Isso inclui a disposição de aceitar mudanças nos requisitos, refatorar o código quando necessário e enfrentar desafios sem medo. A coragem é um valor importante na busca da qualidade.
Principios
Feedback Rápido: Isso enfatiza a importância de obter feedback o mais rápido possível durante o desenvolvimento, seja por meio de testes, revisões ou interações com os clientes. Quanto mais cedo o feedback for obtido, mais fácil será identificar problemas e fazer correções.
Assumir Simplicidade: Este princípio sugere que a equipe deve sempre buscar as soluções mais simples e diretas para os problemas em vez de adicionar complexidade desnecessária. A simplicidade é valorizada na XP.
Mudança Incremental: A XP defende a introdução de mudanças incrementalmente, em pequenos passos. Isso permite que a equipe avalie continuamente o impacto das mudanças e as ajuste conforme necessário.
Abraçando Mudanças: A XP reconhece que os requisitos mudam e incentiva a adaptação às mudanças. Em vez de resistir às mudanças, a metodologia abraça-as e se ajusta conforme necessário.
Trabalho de Qualidade: A XP enfatiza a importância de produzir trabalho de alta qualidade desde o início. Isso inclui práticas como desenvolvimento orientado a testes (TDD) e a busca constante pela excelência técnica.
“Baseia-se na revisão permanente do código, testes freqüentes, participação do usuário final, refatoramento contínuo, integração contínua, planejamento, design e redesign a qualquer hora.”
Práticas do
XP
Jogo de planejamento: é a prática que define o escopo a ser desenvolvido na próxima iteração. Para esta definição de escopo é necessário priorizar as necessidades de negócio (ponto de vista do cliente) em conjunto com as estimativas técnicas (ponto de vista dos programadores). Se o planejamento for falho, atualize-o;
Entregas frequentes: Durante a iteração de uma ou duas semanas, o que estiver com status de pronto deve ser entregue ao cliente, assim, a equipe recebe o feedback mais rapidamente. Não espere todo o projeto estar concluído, entregue frequentemente;
Uso de metáforas: as metáforas devem guiar o desenvolvimento, através das histórias de usuário simplificada e compartilhada com todos;
Projeto simplificado: Quanto mais simples for o projeto, mais rápido é seu desenvolvimento. Complexidades desnecessárias devem ser removidas sempre que forem descobertas, isso mantém o ritmo e a qualidade do produto;
Testes: Tudo deve ser testado: programadores devem utilizar as práticas de TDD para melhorar a qualidade do produto;
Refatoração: Outra prática necessária para melhorar o design e a qualidade do produto. Reestruturar o sistema, sem alterar o seu comportamento, removendo sempre que possível a duplicidade, melhorando e simplificando o que já existe e tornando-o mais flexível;
Programação em pares: o desenvolvimento é guiado pela programação em par, ou seja, todo o sistema é implementado por dois programadores em uma única máquina;
Propriedade coletiva: os códigos não têm um dono, ou seja, viu que precisa melhorar (refatorar)? Faça você mesmo e não espere pelos outros, pois todos podem modificar qualquer parte do código a qualquer momento;
Integração contínua: se temos que entregar constantemente, é através da integração contínua que atingiremos este objetivo. Integre e atualize as versões do sistema várias vezes ao dia, cada vez que uma nova tarefa for concluída;
Ritmo sustentável: A semana deve ser de 40 horas no máximo, ou seja, trabalhe no máximo oito horas por dia durante quatro dias, evite fazer hora extras, pois a produtividade é reduzida;
Cliente presente: Precisamos de comunicação constante, desta forma, inclua sempre um cliente real no time;
Padrões de codificação: Utilize padrões, assim os programadores escreverão seus códigos respeitando as regras e isso cria uma comunicação através do código.
Processos do
XP
Uma prática de cada vez (enfatize o problema mais importante); Dificuldades culturais (deixar alguém mexer no seu código, trabalhar em pares); Dificuldades devido à mudança de hábitos (manter as coisas simples, escrever testes antes de codificar, vencer o medo de refatorar);
Equipes grandes e espalhadas geograficamente (falta de comunicação); Situações onde o feedback é demorado (testes muito difíceis, arriscados e que levam tempo, programadores em ambientes físicos distantes e sem comunicação eficiente)