Tagview Tecnologia

Um amigo, bastante engajado na comunidade ágil, me recomendou um artigo muito interessante cujo título é  ”The marriage of Lean, Scrum e XP: How to align Agile Across an Organization“, escrito por Geoffrey Bourne. Abaixo segue um pequeno resumo.

Nos últimos anos vários “sabores” de métodos/metodologias ágeis surgiram: Scrum, Lean, FDD (Feature Driven Development), AUP (Agile Unified Process),  XP (Extreme Programming) e outros. Estes métodos possuem muitas features semelhantes e diferentes e as empresas começam a se perguntar qual método devem adotar.

Primeiramente, uma organização deve ser vista em três níveis: O Executivo/(PMO), o Gerenciamento de Projetos e os Desenvolvedores/Entregadores. Um executivo focado na estratégia da empresa irá ficar bastante confuso se você começar a evangelizar sobre as virtudes do Extreme Programming (XP) como integração contínua, refatoração, etc, Estes detalhes são “gregos” para um executivo assim como a discussão sobre orientação por objeto. Entretanto este mesmo executivo ficará bastante interessado se você apontar como aumentar o valor das ações através da eliminação de desperdícios e otimização dos processos na orgazinação (Lean).

Mas a medida que os processos ágeis amadurecem ainda permanece a questão. Qual método agíl devemos adotar para nossa empresa?  Na opiniao do autor, os diversos níveis de uma organização se alinham  com três métodos específicos: Lean, Scrum e Extreme Programming.

A organização deve ser compreendida como um todo, ao invés de “partes/divisões” separadas. Deve ser considerada um organismo vivo com suas áreas mutualmente dependentes.

Cada nível tem metas diferentes (onde querem chegar) e objetivos diferentes (como chegam lá). O Executivo foca no nível estratégico e acionário. O gerente de projetos foca no time e na entrega do produto. O desenvolvedor foca na engenharia e nas entregas das tarefas.  Cada grupo tem apenas uma compreensão superficial dos outros níveis. Quando um desenvolvedor recebe como meta a meta do nível executivo como “Cliente em primeiro lugar: Conquiste a confiança do cliente e aumente seu valor de negócio”, este pode até entender a meta, mas não saberá como agir para atingí-la. O mesmo ocorre quando um desenvolvedor tenta convencer um executivo que devem organizar os diretórios do controle de versão SVN da corporação. Com certeza este executivo vai olhar com cara de “blank” para este desenvolvedor pois a reestruturação do SVN não se aplica as metas e objetivos do executivo. Como Dale Carnegie apontou,  a estrada real para o coração de uma pessoa é falar sobre o que ela mais valoriza.

Ágil, como declarado no movimento do Manifesto Ágil, é um conjunto de princípios – uma filosofia, muito mais do que um processo passo a passo. Processos pesados como Waterfall (cascata) dominaram o mundo do desenvolvimento de software, mas aos poucos gerentes começaram a adotar a idéia de se fazer “mais”com “menos”. Assim foram surgindo processos mais leves focados na colaboração, comunicação e adaptação. Em 2001, o Manifesto Ágil, cristalizou os conceitos comuns dos processos ágeis – Scrum (1995) e XP (1996) e outros. Assim, conforme mencionado anteriormente os três se complementam:

Estes três tipos de processos ágeis possuem suas forças unicas mas complementarem entre si.

Lean – Originou-se na linha de produção da Toyota como uma maneira de eliminar o desperdício, otimizar os processos da organização e focar naquilo que realmente tinha valor para o cliente. O sucesso deste processo levou a inovadores a aplicarem Lean no desenvolvimento de software. Os 7 princípios são:

• Emilinar desperdício – (remover aquilo que não traz valor para o cliente)
• Aumentar o aprendizado – (melhorar o desenvolvimento do software através do aprendizado contínuo)
• Decidir o mais tarde possível – (postergue as decisões até que as “assumptions” se tornem fatos)
• Entreguar o mais rápido possivel – (resultados entregues mais rápidos, feedbacks mais rápidos)
• Dar poder de decisão para o time  - (permitir que os trabalhadores da linha de frente tomem a maior parte das decisões)
• Construir Integridade – (integridade, flexibilidade e eficiência)
• Ver o Todo – (veja o software como um todo e são como a somatória de várias partes)

Scrum – uma plataforme que facilita a organização da equipe e a geração de trabalho de alta-qualidade sem sacrificar a produtividade. O nome significa um movimento do jogo rugby cuja idéia é a equipe toda levar a bola até o gol. Como Lean, este processo também se originou no setor da manifatura e depois foi levado para o desenvolvimento de software.Scrum se baseia em:

• Oraganização do time (Scrum Master, Product Owner e Time de desenvolvimento)
• Rituais (Reuniões Diárias, Retrospectivas, Reviews)
• Entregas parciais
• Time-box (definição do tempo para as entregas e reuniões)
• Envolvimento do cliente durante todo o processo

Extreme Programming (XP) – metodologia voltada para programadores que enfatiza práticas técnicas para promover “skillful development” através de entregas frequentes de software funcionais.  As 4 práticas fundamentais de XP são:

• Comunicação – próximo ao cliente, programação em par e desenvolvimento nas instalações do cliente
• Simplicidade – Desenho simplificado e codificação do necessário
• Feedback – Releases pequenos para rápidos feedbacks e TDD (Test-Driven-Development)
• Coragem – Código coletivo e Refatoração (coragem para mexer naquilo que está funcionando)

Podemos notar que os três níveis (Executivo, Gerenciamento de Projetos e Desenvolvimento) se alinham muito bem com estes três métodos ágeis. Diferentes visões para diferentes audiências. Lean brilha quando aplicado para aqueles com foco nos valores estratégico, organizacional e acionário, enquanto Scrum brilha para os que tem foco na organização do time e no gerenciamento das entregas do projeto. Extreme Programming brilha quando aplicado aqueles com foco tático e no desenvolvimeto com entregas, conforme diagrama abaixo.

Adotando estes três processos  (System Thinking – aplicá-los por toda a organização e não em um único nível), aumentamos a chance de adoção, produtividade e sucesso em geral. Talvez em um futuro próximo um único processo ágil nasça para endereçar as necessidades de todos os níveis da empresa, enquanto isto não ocorre, estas idéias podem servir de guia para se adotar Agile em sua organização.

Recentemente nossa equipe trabalhou em um grande projeto web de um cliente líder da área editorial que se tornou um caso de sucesso devido a vários fatores, tais como; a expertise da equipe de desenvolvimento, um ótimo Scrum Master,  mas principalmente  devido a excelente atuação do Product Owner. Nestes nove anos de empresa, nunca havia me deparado com um P.O. tão comprometido e com tanto interesse em ver o projeto se concretizar de forma rápida. O histórico de nossa empresa sempre foi ter P.O.s interessados no início mas que com o passar do tempo deixavam de priorizar o projeto e raramente estavam disponíveis para validar e aceitar as estórias entregues. Muitas vezes ficávamos semanas sem obter feedback para podermos prosseguir com a implementação.

Neste projeto utilizamos Scrum como método ágil para facilitar o gerenciamento das equipes remotas e nossas dailies se transformaram em micro Reviews tamanho o interesse do P.O. em navegar e validar as estórias implementadas.  Diariamente no mesmo horário, ele entrava em contato com nossa equipe, via conferência, para escutar sobre o trabalho realizado, as dificuldades, os impedimentos, mas principalmente para acessar e experimentar as novas funcionalidades. Houve dias que confesso ter desejado que ele não tivesse entrado em contato devido a excessiva carga de trabalho, mas lá estava ele no telefone “E aí pessoal, podemos começar?” Era inacreditável, todos os dias a mesma frase com o mesmo entusiasmo. Esta proximidade diária foi essencial para o esclarecimento de cada pequena regra de negócio que surgia ao nos aprofundarmos nas estórias e muitas vezes, ao ser questionado sobre determinada regra ouvíamos “Nao havia pensado nisto, mas tarde darei um retorno” e no mais tardar no dia seguinte a dúvida estava esclarecida sem retrabalhos de implementação. Este processo se repetiu por quatro meses até a entrega oficial da aplicação. Saldo final – projeto entregue no prazo (curtíssimo), 0% de retrabalho, funcionalidades utilizadas pelos usuários e apenas alguns pequenos bugs.

Esta nossa experiência nos mostrou que para garantir o sucesso de um projeto devemos buscar e se for o caso “brigar” por um P.O. comprometido, interessado e que envolva as pessoas responsáveis pela utilização, para que o software entregue esteja plenamente de acordo com as necessidades reais dos usuários e que somente a proximidade do dia a dia pode garantir esta aderência. Apesar de acreditar e aplicar Scrum há vários anos em nossa empresa, às vezes devemos realizar pequenas alterações em seus rituais para fazer com que o P.O. não espere o final da sprint de duas ou três semanas para validar e experimentar as funcionalidades. A substituição de algumas dailies por  micro Reviews nos traz feedbacks mais rápidos, evita retrabalhos e nos antecipa mudanças de rumo.

Depois de vários anos atuando na área, acredito que não vale a pena seguir em frente com um projeto sem um bom P.O.