Existem diversos tipos de débitos e o que todos eles tem em comum é que tornam a manutenção de um sistema muito custosa e delicada.

Por mais de dois anos, a Caelum tem feito um esforço sobre cortar diversos tipos de débitos técnicos, incluindo levar práticas ao extremo, como testes end-to-end em grid.

Uma forma de enxergar que devemos melhorar o processo de desenvolvimento é verificar que perdemos dinheiro ao tomar decisões ou muito cedo, ou tarde demais.

O descuido gera débitos que cortam a produtividade de sua equipe. Também o excesso de cuidado, gera muitas trocas de decisões, visando o preciosismo técnico, pode levar a um atraso muito grande.

Além disso, uma empresa que espera 4 meses para colocar algo em produção pode ser uma empresa 4 meses atrás de seus concorrentes. Entregar valor tardio é ficar para trás.

Mas o que causa empresas ágeis a não entregar tão frequentemente?

Muito produtos criados em ambientes ágeis só são colocados em produção depois de muito tempo. Durante todo esse tempo, os únicos a testarem e aprovarem as funcionalidades são a equipe de QA e o Product Owner. Ao colocar este produto em produção depois de um ciclo tão grande, o cliente final vai encontrar os problemas que costumavam aparecer em metodologias tradicionais.

No lado gerencial, o Product Owner apresenta dificuldades em priorizar seu backlog de maneira a entregar valor, acabando por entregar funcionalidades. Além disso, é dificil aceitarmos algo “incompleto para o uso mínimo” e, na visão de quem é dono de um produto, o “mínimo necessário” acaba sendo maior do que o real e nunca é atingido para ser colocado em produção. É aí que seu projeto para: ele ficara sem entregas durante muito tempo.

Existe uma prática bem simples para um PO executar e perceber se possui essas dificuldades. Olhe seu penúltimo sprint e veja as funcionalidades que já estão sendo utilizadas por seu cliente. Agora jogue na fórmula:

GPD = (salario da equipe * pontos_desnecessários) / pontos_do_sprint

GPD é o Gasto que você teve com Priorização Desnecessária durante o penúltimo sprint. Ser ágil é entregar valor, e seus pontos estão sendo utilizados em funcionalidades completas sem tanto valor. Se existiam outras tarefas que entregavam valor para os usuários, a priorização poderia ter sido melhor.

Outra possível melhora na parte gerencial está na execução de testes somente por QAs e POs: o feedback não vem do cliente final. Devemos entregar cedo e frequentemente para receber feedback real, e não apenas do PO. Mas como alcançar isso se o produto possui um conjunto mínimo de funcionalidades, que é razoavelmente grande, para entrar em produção?

Assim como diversos ramos de software, adote o conceito de usuários beta. Ele possuem acesso a suas funcionalidades mais cedo, em servidores suficientemente estáveis que acessam dados de produção, rodando a última versão de seu produto, mas com o risco de algo dar errado. O conceito de beta potencializa a propaganda do seu produto, podendo criar uma legião de fanboys.

Na parte técnica, desenvolvedores tem percebido cada vez mais a importância de todos tipos de testes automatizados, controle de versão, integração contínua e outras práticas com base em XP, mas outra causa ainda mais comum de problemas em diversas empresas é o truck factor. Se durante a reunião de planejamento alguém responde que determinada tarefa é dele – pois ele “conhece mais aquela parte do sistema” – ou se alguém é o único que vota os pontos de parte do sistema; ou ainda se é comum esperarem por alguém para executar qualquer tarefa, está na hora de compartilhar mais o conhecimento e acabar com esse impeditivo antes que o truck acabe com ele. Parear e ensinar mais o que conhecemos permite que, ao invés de produzirmos por nós mesmos, diversas pessoas produzam através do que compartilhamos. Essa é a mágica do ensino, levado ao pareamento. Não parear por causa daquela parte ser responsabilidade de uma única pessoa é um paradoxo! É justo esse tipo de caso que mais ganha vantagens do pareamento.

O outro fator para desenvolvedores e sysadmins se perguntarem é quanto tempo leva para fazer deploy? Alguns dias? Se sim, a metodologia ágil que foi alcançada perdeu grande parte do seu valor pois o feedback rápido virou feedback semanal ou ainda mensal.

Apesar de processos de build automatizados junto com integração contínua serem importantes, deploy contínuo é cada vez mais fundamental.

Essas e outras práticas, gerenciais ou técnicas, servem para encontrar o que está implicando na não-entrega de valor ao cliente. Depois de detectado esse gargalo, devemos agir para melhorar nosso processo de desenvolvimento.

Você já desenvolveu software usando o modelo waterfall? Brigou com o cliente para discutir se aquele requisito fazia ou não parte do contrato? Se perdeu com tantas obrigações do processo unificado? Cansou de escrever todo UML antes de escrever uma única linha de código? E aí alterar todo o UML pois ele não representava aquilo que o cliente queria? Só faz uma release estável de ano em ano?

O mercado está mudando. O gerenciamento de software está mudando. Precisamos de releases  rápidos, código testado, responder rapidamente aos novos requisitos do cliente, não se perder em milhares de páginas de contratos e requisitos. Agilidade.

A Caelum acaba de anunciar a criação de um novo treinamento focado em desenvolvimento ágil: PM-51, Programação Extrema (XP) com Java. A elaboração do treinamento contou com a consultoria de Danilo Sato, mestre em Ciência da Computação pela USP em metodologias ágeis.

As metodologias “tradicionais” de desenvolvimento de software têm causado cada vez mais complicações para as empresas. A abordagem das metodologias ágeis (como Scrum e XP) procura resolver esses problemas focando no resultado final do produto, na rápida resposta às mudanças e na satisfação do cliente. Grandes nomes do desenvolvimento de software e grandes empresas pelo mundo todo (como Google, Yahoo e Microsoft) têm apostado nas metodologias ágeis e têm tido ótimos resultados. A Caelum também abraçou a causa, e utiliza metodologias ágeis em seus projetos e clientes.

Iniciamos o enfoque em metodologias ágeis com o treinamento de Scrum no início desse semestre, com Alexandre Magno. Agora completamos a grade com o treinamento de Extreme Programming (XP), metodologia que é inclusive muito utilizada em conjunto com Scrum.

Neste treinamento de XP abordaremos as práticas da metodologia e as práticas de programação que trazem agilidade ao desenvolvimento de software. Desde tópicos técnicos como testes automatizados, design patterns, refatoração e o processo de build até a integração contínua, programação pareada e o uso de controle de versão. Além disso, falaremos dos valores ágeis, das reuniões diárias, jogo do planejamento, métricas de qualidade de código e tracking para controle geral do processo de desenvolvimento. Diferentemente do treinamento de Scrum, a parte prática deste treinamento possui bastante código e desenvolvimento.

Entre em contato conosco para saber mais ou fazer sua reserva.