Extreme Programming in Agile – Um guia prático para gerentes de projeto e nTaskers

Publicados: 2020-07-08

Recebemos muitos pedidos sobre programação extrema em cascata – e como alguém poderia se beneficiar disso como gerente de projeto. Caso você não saiba o que é programação extrema, é uma forma de framework ágil onde os PMs obtêm o melhor dos recursos disponíveis em um ambiente de desenvolvimento de software.

Extreme Programming (XP) em ambiente ágil SDLC

Fonte: Udacity.com

Extreme Programming (XP), uma estrutura de desenvolvimento de software Agile, foi especificamente projetada para melhorar a qualidade do software, o processo de trabalho da equipe de desenvolvimento e aumentar a satisfação do cliente.

É um método desenvolvido para um ciclo de vida de desenvolvimento de software (SDLC) mais suave e eficiente para seus projetos, e foi implementado pela primeira vez em um projeto em 6 de março de 1996.

Por que Extreme Programming (XP)?

A Extreme Programming trabalha para fornecer versões de software iterativas e recorrentes ao longo do projeto; em vez de tudo junto após um único e longo ciclo de vida de desenvolvimento de projeto.

Esses ciclos iterativos curtos ajudam os membros da equipe e os clientes a avaliar e revisar o progresso do projeto ao longo de seu desenvolvimento.

Do que é feito o Extreme Programming (XP)?

Os valores

XP incorpora os seguintes 5 valores:

Comunicação : Projetos de desenvolvimento de software ou projetos em qualquer setor dependem muito da comunicação. XP se concentra na comunicação eficaz entre a equipe e o cliente.
Simplicidade : XP procura as maneiras mais simples de fazer as coisas. Isso significa fazer o que é essencial, reduzindo o desperdício, abordando apenas os problemas conhecidos e mantendo o design simples para criação e manutenção eficazes.
Feedback : O feedback desempenha um papel importante na melhoria do projeto. XP encoraja feedback instantâneo. Isso ajuda a equipe a identificar espaço para melhorias e revisar as práticas.
Respeito : A equipe deve respeitar uns aos outros tanto pessoal quanto profissionalmente, para atingir os objetivos.
Coragem : XP endossa coragem em todos os níveis. Isso pode incluir falar contra o que não funciona e qualquer coisa que afete a eficácia do projeto, ou aceitar feedback e melhorar as metodologias.

As Práticas

O núcleo do XP é um conjunto interconectado de práticas de desenvolvimento de software. Embora seja possível implementar essas práticas isoladamente, muitas equipes descobriram que algumas práticas reforçam as outras e devem ser feitas em conjunto. Isso pode permitir a eliminação total dos riscos que você costuma enfrentar no desenvolvimento de software.

As doze práticas originais para XP compreendem:

O jogo do planejamento
Pequenos lançamentos
Metáfora
Design simples
Teste
Reestruturação
Programação em pares
Propriedade Coletiva
Integração contínua
semana de 40 horas
Cliente no local, e
Padrão de codificação.

Ao longo dos anos, as equipes descobriram que algumas práticas reforçam as outras. Para eliminar riscos, eles devem ser unificados. As descrições a seguir incluem alguns dos refinamentos com base nas experiências de várias equipes:

Equipe inteira : As equipes devem incluir grupos multifuncionais de pessoas com habilidades diferentes. Dessa forma, eles podem se complementar para alcançar um resultado específico.

Sente-se Juntos: A maioria das pessoas concorda que as conversas cara a cara são a melhor forma de comunicação. As equipes devem sentar-se juntas sem barreiras à comunicação, por exemplo, paredes de cubículos.

Espaço de trabalho informativo : As equipes devem ser organizadas para se sentar de forma a tornar o trabalho da equipe transparente entre si e com as pessoas afiliadas fora da equipe.

Trabalho Energizado : Isso significa garantir que uma pessoa esteja mental e fisicamente saudável para se concentrar no trabalho. Isso também implica que não deve haver excesso de trabalho e equipes de respeito para apoiar sua saúde mental e física também.

Leia também:

Como gerenciar um projeto como um profissional no ambiente de trabalho de hoje?

Programação em Pares : A ideia por trás dessa prática é que 2 cérebros pensam melhor do que um. A programação em pares refere-se à produção de software por meio de 2 pessoas sentadas na mesma máquina. Com isso, há uma revisão contínua do trabalho e os problemas recebem uma resposta mais rápida. Este método demonstrou melhorar a qualidade e manter o foco.

Histórias : as histórias definem os recursos que o produto deve ter que sejam significativos para clientes e usuários. Essas histórias são usadas para planejamento e também servem como lembretes para futuras conversas.

Ciclo Semanal : No primeiro dia de cada semana, a equipe se reúne para refletir sobre o progresso até o momento. As histórias que devem ser entregues na semana são selecionadas pelo cliente. A equipe determina como abordar essas histórias. O objetivo por trás disso é alcançar um recurso verificável e em execução até o final da semana. O período fixo permite a produção de um recurso que pode ser mostrado ao cliente para feedback.

Ciclo trimestral: O objetivo do ciclo trimestral é verificar o trabalho detalhado de cada ciclo semanal no contexto do projeto geral. O cliente fornece o plano geral para a equipe em um determinado trimestre. Isso não apenas dá à equipe uma visão do projeto, mas também ajuda o cliente a trabalhar com outras partes interessadas envolvidas.

Slack : Isso implica adicionar algumas tarefas ou histórias de baixa prioridade nos ciclos semanais e trimestrais. Se a equipe estiver atrasada em tarefas mais importantes, elas podem ser descartadas. Caso contrário, estes também serão concluídos, aumentando as chances de cumprimento dos cronogramas estimados.

Construção de dez minutos : Todo o sistema e todos os testes devem ser executados em 10 minutos. Se o tempo exceder esse limite, várias reexecuções custarão períodos maiores entre os erros. Essa prática incentiva a automação do processo de compilação, tornando viável regularmente a execução de todos os seus testes.

Integração Contínua: Essa prática incentiva o teste imediato de novo código para a base de código maior existente. Isso ajuda a detectar e corrigir problemas de integração mais cedo. Essa prática requer disciplina e depende das práticas de Desenvolvimento em Dez Minutos e Desenvolvimento de Teste Primeiro.

Programação Test-First : Em vez de seguir o caminho regular, ou seja,

Desenvolver código -> Escrever testes -> Executar testes

A prática da Programação Test-First segue o caminho de:

Teste automatizado com falha de gravação -> Executar teste com falha -> Desenvolver código para fazer o teste passar -> Executar teste -> Repetir

Essa prática também reduz o ciclo de feedback para identificação e resolução de problemas. Isso resulta em uma redução no número de bugs que são introduzidos na produção.

Design Incremental : Esta prática retrata a realização de uma certa quantidade de trabalho inicial para entender a perspectiva abrangente do design do sistema. Depois disso, trabalhe mais nos detalhes de um aspecto específico do projeto quando recursos específicos forem entregues. Essa abordagem reduz o custo das alterações e permite que você tome decisões de projeto quando necessário com base nas informações mais atuais disponíveis.

Funções

O XP incorporou práticas específicas para sua equipe seguir e não estabelece funções específicas para os membros da equipe. No entanto, de acordo com o requisito, as 4 funções mais comuns são:

O Cliente: Espera-se que o Cliente XP participe ativamente do projeto. O Cliente toma todas as decisões de negócios relacionadas ao projeto, tais como:

O que o sistema deve fazer? Isso se refere aos recursos incluídos e ao que eles realizam
Quando o sistema é feito? Isso implica os critérios de aceitação
Quanto deve ser gasto? O que significa que o orçamento para o projeto e
O que deveria ser feito em seguida? A ordem em que os recursos são entregues.

O Desenvolvedor : Desenvolvedores percebem as histórias identificadas pelo Cliente, o que significa entregar um projeto com características decididas.

O Rastreador : O rastreador é uma função opcional e depende se a equipe precisar de um. Isso é realizado por um dos desenvolvedores para acompanhar as métricas ágeis relevantes e é essencial para a avaliação do progresso e identificação das principais áreas de melhoria. Isso é importante para acompanhar o progresso e identificar as principais áreas de melhoria. Algumas dessas métricas podem incluir a quantidade de tempo trabalhado, a quantidade de horas extras, os testes de aprovação e reprovação, velocidade e razões para variações na velocidade.

O Coach : Este papel é útil principalmente se a equipe está apenas começando. O Coach pode ser um consultor externo que já usou XP antes e pode ajudar a orientar a equipe nas Práticas XP, bem como na autodisciplina. Empregar o Coach ajuda a evitar possíveis erros que novas equipes podem cometer, agilizando o projeto.

Vantagens da programação extrema

A programação extrema permite que os desenvolvedores de software se concentrem na codificação e não se preocupem com as atividades improdutivas relacionadas ao projeto
O benefício mais importante da programação extrema é que ela permite que as empresas de software reduzam o gasto de recursos como dinheiro e tempo em atividades inúteis quando podem ser gastos em atividades como realização de projetos e outras sessões de brainstorming.
A programação extrema também reduz os riscos de falha do projeto ou mau funcionamento da codificação, garantindo que o cliente obterá o produto desejado no final
A programação extrema é uma metodologia incrível que não exige que o código seja complexo e difícil de ser entendido por todos e que aparece no código dos desenvolvedores que usam essa metodologia porque sempre que alguém assume sua posição, eles podem entender o código muito facilmente
Uma das melhores coisas do XP é que tudo é transparente e na frente de todos, o que ajuda a manter todos e tudo responsáveis
O feedback constante também é um recurso incrível da programação extrema que permite aos desenvolvedores codificar sem medo e sem medo de julgamento, porque eles sempre podem corrigir os pequenos erros que cometem com a ajuda do feedback que recebem
Testes regulares de todos os elementos do software, detecção de bugs para todo o código e o uso de testes de validação do cliente garantem que o cliente obtenha um protótipo funcional ou o software em funcionamento real em menos tempo do que o normal
Extreme Programming também ajuda as empresas a satisfazer seus clientes e manter seus negócios por mais tempo
Na metodologia de programação extrema, todos são membros iguais do rebanho e todos devem compartilhar o fardo como seus pares, o que significa que, desde a exigência até o código, os desenvolvedores trabalharão lado a lado para que ninguém se sinta desvalorizado ou esquecido

O Ciclo de Vida de Programação Extrema (XP)

O ciclo de vida do XP pode ser explicado em relação ao Ciclo Semanal e Ciclo Trimestral.

Para começar, o cliente define o conjunto de histórias. A equipe estima o tamanho de cada história, que juntamente com o benefício relativo estimado pelo cliente, indica o valor relativo usado para priorizar as histórias.

Caso algumas histórias não possam ser estimadas pela equipe devido a considerações técnicas pouco claras envolvidas, eles podem introduzir um Spike. Os picos são chamados de prazos curtos para pesquisa e podem ocorrer antes do início das iterações regulares ou junto com as iterações em andamento.

Em seguida vem o plano de lançamento: O plano de lançamento abrange as histórias que serão entregues em um determinado trimestre ou lançamento.

Neste ponto, os ciclos semanais começam. O início de cada ciclo semanal envolve a reunião da equipe e do cliente para decidir o conjunto de histórias a serem realizadas naquela semana. Essas histórias são então divididas em tarefas a serem concluídas naquela semana.

Os fins de semana com uma revisão do progresso até o momento entre a equipe e o cliente. Isso leva à decisão se o projeto deve continuar ou se valor suficiente foi entregue.

Estudos de caso para práticas de programação extremas (XP)

XP para o sistema Krizp

O problema

A Krizp Solution era uma empresa de desenvolvimento baseada na web na Índia. Seu plano de negócios previa a criação de portais na web para outras pequenas empresas ou instituições de ensino. A empresa começou como um negócio de meio período, empregando pessoas que já trabalhavam para outras grandes organizações de TI. O plano era continuar em tempo integral apenas se a startup se aventurasse em um sucesso. Não havia estrutura para seus processos de desenvolvimento de software, pois era apenas uma empresa iniciante com poucos projetos e poucos funcionários.

A empresa não tinha uma abordagem estruturada para o desenvolvimento de software. Com os requisitos iniciais anotados em papel, mais informações e esclarecimentos foram recebidos do cliente por meio de ligações telefônicas. Normalmente, as principais mudanças nos requisitos não aconteciam até a revisão do cliente, que era após o desenvolvimento da solução.

Além da correção de bugs, os desenvolvedores tiveram pouca ou nenhuma comunicação entre si. Eles trabalharam separadamente em diferentes recursos. Isso fez com que se tornasse uma barreira para as discussões sobre a melhoria dos métodos de trabalho.

Além disso, os projetos não foram documentados. Não havia gerente de projeto para acompanhar os projetos ou para garantir que os requisitos estabelecidos pelo cliente fossem atendidos. Os desenvolvedores trabalharam apenas no que foi pedido para ser feito.

A jornada

certificação pert de programação extrema

A equipe da Krizp System foi apresentada aos conceitos por trás dos diferentes frameworks ágeis. O método XP foi empregado durante um período de um mês e os resultados foram avaliados.

O CEO da empresa assumiu 2 funções: o representante do cliente e o rastreador. Para sua primeira função, ele priorizou as histórias de usuários, delegando-as à equipe de desenvolvimento e mantendo uma comunicação regular com o cliente. Como rastreador, ele mantinha o controle do tempo para concluir tarefas específicas. O CEO também iniciou o jogo de planejamento toda semana (ou pelo menos uma vez em quatro dias), pois o projeto era pequeno e os desenvolvedores podiam concluir tarefas em uma história de usuário mais rapidamente. No entanto, o cliente estava disponível para comunicação direta apenas duas vezes por mês e o restante do tempo ele estava em contato por telefone e e-mail.

A técnica de programação em pares foi adotada em que ambos os desenvolvedores trabalharam juntos. Após a conclusão da tarefa, ambos os desenvolvedores revisaram o código com o CEO.

Testes de clientes foram introduzidos e a equipe trabalhou em melhorias contínuas de design, que eram cerca de 12 a 15 por mês.

Resumo

A abordagem XP pareceu ter um bom impacto no ciclo de desenvolvimento de software da empresa. Algumas das mudanças positivas incluíram:

Melhor colaboração, comunicação e feedback da equipe
Melhor gerenciamento de tarefas e tempo, e
Maior envolvimento do CEO sem contribuição técnica.

Práticas de programação extremas para IBM e Sabre Airlines

O problema

Para avaliar as aplicações práticas do Waterfall vs. Extreme Programming, foi realizado um estudo de pesquisa por meio de 2 estudos de caso: um na IBM e outro na Sabre Airlines. Cada estudo de caso comparou a abordagem em cascata com a abordagem XP.

A jornada

No primeiro estudo de caso, na IBM, os pesquisadores queriam estudar o impacto da adoção da abordagem XP na produtividade, qualidade e satisfação do cliente. Um estudo de um ano foi realizado em uma equipe de 7 a 11 membros sobre a adoção de práticas XP. A equipe foi responsável pelo desenvolvimento de aplicativos Servlet/XML para um kit de ferramentas utilizado por outras equipes da IBM para criar produtos para clientes externos. O estudo de caso analisou 2 abordagens em lançamentos consecutivos de um mesmo produto. A primeira foi a abordagem tradicional em cascata e a segunda foi a XP.

No segundo estudo de caso, na Sabre Airline Solutions, o mesmo método foi usado, ou seja, comparando 2 abordagens através de diferentes versões do mesmo produto. A equipe trabalhou no desenvolvimento de um ambiente GUI programável para clientes externos para desenvolver aplicativos de negócios e usuários finais personalizados. A equipe era composta por 6-10 membros. A versão antiga foi concluída 3 anos antes (abrangendo 18 meses) usando o método em cascata, enquanto a nova versão foi concluída recentemente (abrangendo 3,5 meses), usando XP.

O primeiro passo foi estabelecer um Extreme Programming Evaluation Framework (XP-EF), que compreendia três partes: XP Context Factors (XP-cf), XP Adherence Metrics (XP-am) e XP Outcome Measures (XP-om):

Fatores de Contexto XP (XP-cf) : XP-cf foi usado para registrar informações importantes relacionadas ao projeto. Esses fatores incluíam tamanho da equipe, tamanho do projeto, criticidade e experiência da equipe.
Métricas de Adesão do XP (XP-am) : Através do XP-am, foi expressa a extensão em que a equipe utiliza as práticas do XP. O XP-am também ajudou a investigar as interações e dependências entre as práticas XP, bem como o grau em que as práticas podem ser desvinculadas ou removidas.
XP Outcome Measures (XP-om) : Avaliação habilitada para XP-cm de resultados relacionados ao negócio, ou seja, produtividade, qualidade, etc.

Além do framework, foram realizadas entrevistas com membros da equipe e clientes para auxiliar no entendimento da incorporação do XP pela equipe para a satisfação do cliente.

Resumo

Na IBM, o método XP pareceu mais produtivo comparado ao método cascata pelas seguintes medidas:

Defeitos de teste : para pré-lançamento, os defeitos foram 50% menores e para pós-lançamento, os defeitos foram cerca de 40% menores no lançamento através da abordagem XP.
Produtividade : Houve um aumento significativo na produtividade da equipe usando a abordagem XP do que no método cascata.
Satisfação do cliente: a satisfação do cliente foi considerada alta no XP e documentada como N/A para a cascata.
Moral : O moral das partes interessadas foi registrado como alto no XP e documentado como N/A para a cascata.

Na Sabre Airlines, resultados semelhantes foram observados:

Período de coleta de defeitos : como a primeira versão foi criada em mais de 18 meses, o período de coleta de defeitos também foi mais longo na abordagem baseada em cascata. Foi significativamente mais curto na versão baseada em XP.
Defeitos de teste : para pré-lançamento, os defeitos foram 65% menores e para pós-lançamento, os defeitos foram cerca de 46% menores no release através da abordagem XP.
Produtividade : A produtividade da equipe usando a abordagem XP foi cerca de 46% maior do que no método em cascata.
Satisfação do cliente: a satisfação do cliente foi considerada alta no XP e documentada como N/A para a cascata.
Moral : O moral das partes interessadas era de cerca de 68% XP e documentado como N/A para a cascata.

Casos de uso e aplicação

Caso de Uso 1: Desenvolvimento Web

Declaração do problema: O site da empresa precisa ser redesenhado.

Atores: Cliente, Desenvolvedores, Rastreador

Fluxo Regular de Eventos:
O cliente informa sobre os requisitos iniciais.
A equipe de desenvolvimento inicia a programação.
A equipe de controle de qualidade testa bugs e informa a equipe de programação
O cliente tem mais exigências
O ciclo se repete.

Usando XP:

A reunião presencial é chamada envolvendo o cliente e os desenvolvedores.
O cliente define os requisitos, o orçamento e o cronograma na forma de uma história.
O Gerente de Projeto se torna o Rastreador e acompanha o progresso do projeto.
A equipe de desenvolvimento começa a trabalhar em pares. O código é escrito e depurado ao mesmo tempo.
A cada semana, uma reunião é realizada para discutir o progresso. O cliente pode definir novos requisitos.
A cada trimestre é realizada uma reunião para discutir o status das histórias.
Depois que as histórias antigas são concluídas, um novo conjunto de histórias é formado (requisitos para o próximo trimestre)

Caso de uso 2: desenvolvimento de jogos

Declaração do problema: Um cliente exige que um jogo seja desenvolvido do zero.

Atores: Cliente, Desenvolvedores, Rastreador

Fluxo Regular de Eventos:

O cliente fornece requisitos, tempo e orçamento.
Os desenvolvedores começam a programar.
A equipe de controle de qualidade testa os módulos do jogo.
O cliente tem mais exigências.
O ciclo se repete.

Usando XP :

A reunião presencial é chamada envolvendo o cliente e os desenvolvedores.
O cliente define os requisitos, o orçamento e o cronograma na forma de uma história (módulos de jogo).
O Gerente de Projeto se torna o Rastreador e acompanha o progresso do desenvolvimento do jogo.
A equipe de desenvolvimento começa a trabalhar em pares. O código para diferentes módulos é escrito e depurado ao mesmo tempo.
A cada semana, uma reunião é realizada para discutir o progresso. O cliente pode definir novos requisitos.
A cada trimestre é realizada uma reunião para discutir o status das histórias.
Depois que as histórias antigas são concluídas, ou seja, os módulos de alta prioridade são concluídos, um novo conjunto de histórias é formado (requisitos para o próximo trimestre)

nTask for Extreme Programming Practices (XP)

nTask é um sistema de gerenciamento de tarefas que suporta o método Agile do framework Extreme Programming. É um aplicativo de gerenciamento de tarefas online projetado especificamente para trabalho em equipe e entrega de projetos. Independentemente do setor, o nTask facilita a metodologia XP e contribui para um planejamento de projeto eficaz e alinhamento de processos.

A seguir estão algumas das maneiras pelas quais o nTask pode ajudá-lo a planejar e atingir melhor os objetivos do seu projeto, tudo dentro da estrutura XP.

Agendamento de reuniões

Você pode agendar seus sit-ins, reuniões semanais e trimestrais com antecedência. A agenda e os horários das reuniões podem ser especificados. Você pode definir um horário fixo para a reunião ou enviar uma sugestão de horário para a equipe, para ser finalizada após a resposta da equipe.

Este aplicativo também permite que você anote todos os pontos importantes discutidos em uma reunião. As atas podem ser revisadas e publicadas para o resto da equipe.

Alocação da equipe

Você pode organizar sua equipe e as funções que eles assumirão na seção de alocação de equipe. Você pode definir facilmente funções para os desenvolvedores, os rastreadores e o cliente.

Criação do projeto

O cliente pode criar o projeto e especificar os requisitos. O cliente também pode definir o orçamento e o cronograma.

Criação e atribuição de tarefas

O cliente pode criar histórias criando tarefas dentro do projeto. As tarefas incluirão uma lista de atividades a serem concluídas em uma história. Essas histórias podem então ser atribuídas aos programadores.

Se as histórias forem concluídas antes do tempo por alguns membros da equipe, o cliente pode atribuir a eles as tarefas de “folga”, ou seja, tarefas de menor prioridade dentro do cronograma restante. Isso economiza tempo trabalhando mais rápido para a conclusão do projeto.

Veja também:

Apresentando o nTask 2.0 – Nossa atualização mais esperada até agora

Fluxo do projeto

O Gerente de Projeto ou Rastreador pode ajudar a acompanhar o fluxo do projeto através do módulo Quadro de Horários. Este módulo permite o monitoramento e avaliação eficazes do progresso do projeto. Também ajuda a avaliar individualmente o cronograma para diferentes tarefas e os marcos alcançados ou pendentes.

Colaboração fácil

Às vezes não é possível realizar reuniões presenciais, por exemplo, quando uma determinada equipe está trabalhando em outro site. Nesses casos, as atualizações automatizadas de projetos, tarefas e reuniões podem garantir a colaboração e a discussão da equipe em tempo hábil e eficaz. Isso evita o desperdício de tempo na organização manual do projeto e acompanhamento de tarefas, comunicação de reunião de atas ou atualização do projeto.

Comentários em tempo real fornecem uma maneira fácil de se comunicar com a equipe. Seja a troca de informações ou novas ideias, isso torna mais fácil para a equipe permanecer na mesma página.

As tarefas interdependentes são destacadas e cada membro da equipe pode verificar as atualizações instantaneamente conforme atualizadas pelos outros membros da equipe. Isso mantém a equipe atualizada sobre as situações de mudança e no planejamento da próxima tarefa, de acordo.

Além disso, o cliente pode colaborar diretamente com a equipe e atualizar qualquer alteração nos requisitos.

Transparência

O nTask oferece uma visão transparente de todos os projetos e tarefas e subtarefas correspondentes através do seu Painel de Tarefas. Qualquer projeto criado ou modificado é comunicado à equipe, imediatamente. Não há necessidade de verificar novamente as atualizações de progresso, convites para reuniões ou relatórios de projetos.

As tarefas atualizadas, modificadas ou excluídas abrem caminho para que toda a equipe tenha plena consciência e saiba exatamente o que está sendo realizado e quando.

Com a opção Filtro, você pode optar por ver as atualizações de projetos selecionados com base na prioridade ou na tarefa em questão. Com a opção Status, o status da tarefa selecionada pode ser visto se ela foi iniciada ou não, concluída ou em andamento.

Conclusão

Este artigo detalha como você pode se beneficiar do XP como um trabalhador ágil. Além disso, o nTask foi criado para realizar tais requisitos dentro do domínio de programação extrema e técnicas de cascata. Portanto, dê uma lida e não se esqueça de compartilhar seus pensamentos através da seção de comentários abaixo. Alternativamente, você pode nos enviar um e-mail para [email protected] .