Visão Geral do eXtreme Programming (XP)

O XP foi criado considerando que mudanças são inevitáveis e que devem ser incorporadas constantemente. Este processo ágil resultou da experiência no projeto C3 Payroll na empresa Chrysler, e após seu sucesso, começou a despontar no meio acadêmico e empresarial e se tornou alvo de inúmeras pesquisas e discussões, além de ser adotado em diversas empresas de software do mundo inteiro.

Este método se baseia em alguns valores (comunicação, simplicidade, feedback e coragem) que servem como critérios que norteiam as pessoas envolvidas no desenvolvimento de software e princípios (feedback rápido, assumir simplicidade, mudança incremental, abraçando mudanças e trabalho de qualidade) que devem ser seguidos por equipes que forem usar XP em projetos.

Existem alguns fatores que são fortes indicadores para não usar XP como, cultura organizacional, equipes grandes, clientes desconfiados e tecnologia que não dá suporte facilitado para mudanças. Segue uma breve descrição destes indicadores:

• Cultura: A organização pode estar inserida dentro de uma cultura tradicional de desenvolvimento de software, produzindo muita documentação, gastando muito tempo com análise e projeto antecipado, entre outras coisas. Fazer com que a equipe passe a adotar as práticas de XP e esqueça as antigas pode ser muito difícil;

• Tamanho da equipe: Um projeto XP deve possuir uma equipe pequena – geralmente até 12 programadores. É difícil imaginar como ficariam alguns conceitos de XP como comunicação, programação em par e outras em uma equipe grande (Ex. 100 pessoas);

• Tecnologia: Não se deve usar XP quando uma tecnologia é complicada para escrever casos de teste, quando retorna feedback em um tempo longo ou quando não incorpora facilmente as mudanças. • Espaço físico: A organização do espaço físico onde a equipe de XP trabalha deve facilitar a comunicação e deixar todos próximos uns dos outros; 

• Cliente: XP exige que o cliente participe da equipe do projeto e trabalhe no mesmo local dos demais, estando a disposição, de preferência, o tempo todo para esclarecer dúvidas. Caso não possa ser alguém da organização do cliente alguém deve ser alguém que entenda do negócio do cliente e que seja capacitado para exercer este papel. O cliente também não precisa estar disponível todo o tempo embora seja preferível.

Gostou ? Ao decorrer dos posts irei trazer mais informações sobre este método ágil tão atual e presente no dia-a-dia da maioria das organizações desenvolvedoras de software.

Referências

http://www.cin.ufpe.br/~gamr/FAFICA/Desenvolvimento%20de%20sistemas/XP.pdf

. 

E-Kanban

Os sistemas eletrônicos automatizam os processos físicos do Kanban podem ser utilizados por organizações que desejam eliminar a maioria das dificuldades relacionadas a este processo. Estas dificuldades estão relacionadas a(o): 

• O uso de planilhas ->  embora dê flexibilidade, está muito sujeita à logica de seu criador e, aliada a falta de integração com os sistemas corporativos, acaba gerando uma dificuldade em sua administração e manutenção;

• O processo de criação e preenchimento manual de cartões -> está sujeito a falhas humanas bem como risco de perdas, extravios ou avaria dos cartões ao longo do processo;

• A adoção de um número cada vez mais crescente de itens administrados -> assim como as constantes e incômodas variações na demanda, exigem uma maior frequência no cálculo e revisão de kanbans, com a consequente sobrecarga do programador;

• A falta de visibilidade no chão de fábrica -> sabe-se o que é preciso fazer em função de kanbans vazios nos painéis, porém o que está em andamento bem como as quantidades nos supermercados e pontos de uso dependerá de levantamento físico nas áreas para saber onde estão cada um dos kanbans;

• Dificuldade de priorização -> principalmente quando há um grande número de kanbans vazios nas regiões vermelhas dos painéis e existência de processos concorrentes;

• Dificuldade de sinalizar processos -> fornecedores distantes em função dos deslocamentos físicos dos cartões.

Com a implantação de um sistema e-Kanban (ee a empresa já possui os conceitos em operação, o tempo médio para implantação será extremamente baixo, ficando na faixa de 1 a 3 meses) a organização pode usufruir dos seguintes benefícios:

• Maior integração com o sistema ERP corporativo e uniformização da base de conhecimento;
• Geração eletrônica de kanbans com a possibilidade de impressão ou simplesmente mantendo seus registros eletrônicos, minimizando a possibilidade de falhas humanas e perdas de cartões;
• Agilidade na revisão dos kanbans, independente do número de itens sendo administrados. A integração com o sistema ERP irá garantir os dados de demanda bem como as estruturas de produto, necessários para o cálculo de demandas em todos os níveis da estrutura;
• Visibilidade total do status da planta, com indicação nos painéis eletrônicos do que está vazio, a quantidade em processo e quantidades em supermercados;
• Priorizações claras e precisas através de quadros Heijunka e/ou listas de prioridades por percentual de invasão dos quadros Kanban;
• Sinalização imediata nos processos fornecedores distantes em função da disponibilidade dos kanbans eletrônicos em monitores ou painéis LCD.

Gostou ? O portal Kanbanize disponibiliza (gratuitamente) a utilização de um e-Kanban para você poder testar e visualizar como funciona o sistema, ou até utilizá-lo em um pequeno projeto.

Referência: 

http://www.linter.com.br/quando-considerar-a-adocao-de-um-kanban-eletronico/

Como montar um quadro Kanban

Modelo que pode ser montado em qualquer negócio para acompanhar diariamente a realização das atividades:

Instruções para montar do Quadro Kanban

• Faça da divisória/Parede o plano de fundo;
• Monte as caixas com fita azul;
• A medida das caixas de identificação é de 20cm x 10cm;
• A medida das caixas de ocorrências é de 50cm x 20cm;
• Os dizeres serão fornecidos de forma impressa.

Cada quadro deve ter um responsável por sua administração e manipulação diária, garantindo o bom andamento da rotina diária que é fundamental para seu bom funcionamento, porém cada usuário do quadro é responsável por manipular suas atividades.

Atividades

As atividades são descritas em um post-i, onde deve-se descrever sucintamente qual é a atividade, seu responsável e em qual Status a mesma se encontra no quadro.

  

COMO USAR:

Cada atividade deverá ser descrita em seu respectivo Post-It com o nome de seu responsável, pode-se adicionar também dados adicionais como prazo limite para resolução do problema, data de entrada da atividade, dados do responsável e etc.

Conforme o status da atividade for sendo alterado o post-it deve ser mudado entre as linhas que definem os estados das mesmas no quadro KanBan.

A FAZER:

Todas atividades que precisam ser realizadas pelo departamento e não exigem um planejamento prévio para execução.

FAZENDO:

Todas as atividades em Andamento.

FEITO:

Todas as atividades que estão acabadas e estão prontas para serem checadas antes de serem devidamente finalizadas.

PROBLEMAS:

Problemas que merecem atenção imediata ou tem de ser discutidas.

NÃO PLANEJADO:

Itens que precisam ser realizados porém precisam de um planejamento prévio para sua realização.

CHECADO:

Todas atividades que já foram realizadas e devidamente checadas e portanto estão totalmente prontas, recomenda-se que as atividades para serem colocadas neste Status devem ser checadas por outra pessoa que não o executor da tarefa, para certificar-se de que esta realmente pronta.

Recomenda-se que toda vez que houver uma checagem das atividades, o responsável pela checagem faça um relatório do andamento geral das atividades, bem como quais são as atividades e qual o andamento em % de cada uma delas.

Referências

FreeBits. KANBAN ADM. E VISUAL. Disponível em: <http://freebitstecnologia.blogspot.com.br/p/kanban-adm-visual.html> Acessado em 27 de janeiro de 2016.

Vídeo animado para introduzir o Kanban

O Kanban é um conceito de aplicação visual dos processos em suas fases. Tem como principal objetivo mostrar visualmente onde encontrar gargalos de tarefas complexas e priorizar a data da entrega do pedido do cliente, reduzindo assim a margem de erro, preparar processos para serem ativados de acordo com a demanda, possibilitando a flexibilização no planejamento dos processos.  

A implantação do Kanban é baseada em três aspectos:

• Visualizar os processos;
• Limitar o trabalho em processo (WIP – Work in progress);
• Gerenciamento de atividade para passar por todas as fases até a sua entrega.

Em que situação o tema é útil?

Nos últimos anos o conceito de metodologia ágil vem movimentando o mundo de desenvolvimento de software. Metodologias mais populares como Scrum e XP, criadas nas fabricas de software, vem ganhando cada dia mais espaço nas empresas de tecnologia. Essas ferramentas surgiram com a proposta de melhorar e agilizar os processos envolvidos no desenvolvimento de software, porém no mundo real fica claro que os processos ainda não estão “perfeitos”. Mas o que fazer então, sendo que essas ferramentas estão, teoricamente, maduras e eficientes no que se propõe? Como identificar onde estão os “gargalos” que fazem as equipes falharem nos seus sprints? Podemos dizer com que o Kanban pode ajudar a identificar essas falhas e solucioná-las.

(MARIOTTI ,Flavio S., p. 06)

Referências

DARUIX, Jamil. Desenvolvimento Ágil com Kaban. Disponível em:

<http://www.infonaveia.com.br/desenvolvimento/desenvolvimento-agil-kanban/> Acessado em Janeiro 2016.

MARIOTTI, Flávio. Kanban: o ágil adaptativo - Revista Engenharia de Software Magazine 45. Disponível em:

<http://www.devmedia.com.br/kanban-o-agil-adaptativo-revista-engenharia-de-software-magazine-45/23560>Acessado em Janeiro de 2016

Metodologia Ágil

Introdução

As definições modernas de desenvolvimento de software ágil evoluíram a partir da metade de 1990 como parte de uma reação contra métodos mais robustos, caracterizados por uma pesada regulamentação, regimentação e micro gerenciamento usado no modelo em cascata para desenvolvimento. O processo originou-se da visão de que o modelo em cascata era burocrático, lento e contraditório a forma usual com que os engenheiros de software sempre realizaram trabalho com eficiência.

A maior parte dos métodos ágeis tentam minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais levam por volta de uma a quatro semanas para entregar parte do sistema. Apesar das metodologias existirem, foi em 2001 que um grupo formado por Kent Beck e mais dezesseis renomados desenvolvedores assinaram o Manisfesto para o Desenvolvimento Ágil de Software e o grupo foi batizado de aliança dos ágeis. 

O manifesto ágil possui a seguinte base:

• Os indivíduos e as interações são mais importantes do que os processos e as ferramentas;
• O software funcionando é mais importante do que uma documentação completa;
• A colaboração com e dos clientes acima de apenas negociações de contratos;
• Respostas a mudanças acima de seguir um plano.

Isso não significa que a documentação não é importante ou que os processos e ferramentas sejam inúteis, significa que o item a esquerda é mais valorizado.

“A engenharia de software ágil combina filosofia com um conjunto de princípios de desenvolvimento. A filosofia defende a satisfação do cliente e a entrega de incremental prévio; equipes de projetos pequenas e altamente motivadas; métodos informais; artefatos de engenharia de software mínimos e, acima de tudo, simplicidade no desenvolvimento geral. Os princípios de desenvolvimento priorizam a entrega mais que a análise e projeto (embora essas atividades não sejam desencorajadas); também priorizam a comunicação ativa e contínua entre desenvolvedores e clientes”. (Pressman, 2011)

Um Pouco sobre a Metodologia

As metodologias ágeis tem foco na comunicação contínua com o cliente, na entrega constante e na equipe de desenvolvimento. É perceptível que muda um pouco o conceito tradicional, em que primeiro é planejado todo o produto, com uma análise completa, requisitos funcionais, não funcionais e requisitos inversos de todo o produto, para depois iniciar o desenvolvimento, o que pode acarretar problemas, pois um requisito mal interpretado só será identificado quando o produto for entregue meses depois. Na metodologia ágil, planeja-se apenas o que será feito naquele incremento, com detalhes, de forma que possamos desenvolver e entregar ao cliente. Caso o requisito tenha sido mal entendido, ele é rapidamente corrigido, pois o tempo do incremento é curto e a correção é rápida, diferente de quando o produto foi entregue completo, e que aparece muitos erros de requisitos, muitas coisas a serem corrigidas e melhoradas, levando tempo da equipe e a desmotivação.

Princípios

Os princípios do desenvolvimento ágil valorizam:

• Garantir a satisfação do consumidor entregando rapidamente e continuamente software funcionais;
• Até mesmo mudanças tardias de escopo no projecto são bem-vindas para garantir a vantagem competitiva do cliente;
• Software funcionais são entregues frequentemente (semanas, ao invés de meses);
• Cooperação diária entre pessoas que entendem do 'negócio' e desenvolvedores;
• Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança;
• A maneira mais eficiente e efetiva de transmitir informações é conversas cara a cara;
• Software funcionais são a principal medida de progresso do projeto;
• Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes para manter um ritmo constante indefinidamente;
• Design do software deve prezar pela excelência técnica;
• Simplicidade é essencial;
• As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas;
• Em intervalos regulares, a equipe reflete sobre como para tornar-se mais eficaz, então sintoniza e ajusta seu comportamento apropriadamente.

Referências

• Pressman, Roger S. Engenharia de Software: Uma abordagem profissional, Bookman, Porto Alegre, 2011;
• Sommerville, Ian. Engenharia de Software, Person, São Paulo, 2010.
• <http://manifestoagil.com.br/> Acessado em Janeiro de 2016
• <http://www.devmedia.com.br/uma-visao-geral-sobre-metodologia-agil/27944> Acessado em Janeiro de 2016

Olá !

Olá, nós somos a EquipeScrum ! Ao decorrer deste período (2015.2) nós iremos realizar diversas postagens sobre Métodos Ágeis, o que são, quais os métodos que existem, os mais e menos utilizados, suas vantagens e desvantagens. Enfim, acompanhando este portal você estará suficientemente informado sobre este assunto tão atual. 

Métodos como Extreme Programming (XP), Scrum, Lean Development, Feature-Driven Development (FDD), Kanban, RUP e OpenUP surgiram devido a necessidade de melhorarmos a forma como estamos desenvolvendo software e  das crescentes pressões do mercado por inovação, produtividade (prazos casa vez mais cursos), flexibilidade e melhoria no desempenho e qualidade dos projetos de desenvolvimento de SW.