Em posts anteriores falei de como se sabe se um processo é tradicional ou não e como se define o processo clássico. Hoje falarei do processo ágil.
O processo ágil é muito semelhante ao processo clásico, mas se apoia em algumas permissas diferentes que injetam muita simplicidade no processo e os desburocratizam.
O primeiro passo é não confundir o “Processo ágil” com o “Movimento Ágil”. O movimento ágil é um conjunto de pessoas que partilham de um conjunto de conceitos e valores que querem ver ser usados na prática. O Manifesto Ágil é o simbolo deste movimento. Contudo o movimento ágil não foi inicado com o manifesto ágil. No final dos anos 90 algumas pessoas começaram a adotar metaforas diferentes para o processo de software. Até aqui a metáfora favorita é a da construção de uma casa, ou um avião. A metáfora passou então a ser a de uma linha de montagem, e não uma linha qualquer, uma linha japonesa de montagem que podemos identificar como a guerra ao desperdicio. Desperdicio de tempo, dinheiro, planejamento, documentação, preocupações, etc.. Com isto nasceu o processo Lean. Mais tarde o processo Scrum.
O processo ágil é então o resultado de uma mudança de paradigma em que as pessoas queriam ver mais produto e menos “planejamento”. Isto não significa que não ha planejamento, mas ha o minimo necessário. Esta diretiva de “o minimo necessário” é o amago do processo ágil. Ao contrario nem o processo clássico ou o tradiiconal parte de um conjunto de diretivas/axiomas e essa é a principal diferença para o processo ágil.
As leis do desenvolvimento de software são levadas em consideração para criar um processo que não lute contra o inevitável, mas se aproveite do inevitável. Ou seja, use a correte, não reme contra ela.
O primeiro destes inevitáveis é a mudança. A mudança é inevitável. O que significa que a mudança de escopo é inevitável. Devido a isto o processo ágil pega o processo clássico e define que todos os projeto serão plan-driven e que não existem projeto time-driven ou feature-drive. Ou, dito de outra forma, as mecanênicas de um plan-drive permitem controlar qualquer tipo de projeto, inclusive o time-drive e o feature-drive. Isto significa que num processo ágil sempre consideramos que o cliente quer algumas features em algum tempo. Isto força o cliente a priorizar muito bem o que quer e quando quer. Por isso as verificações que no processo clássico são feitas em certos gates, no processo ágil são feitos continuamente.
O processo ágil começa da mesma forma que o tradicional ou o clássico: transformar prospects (clientes em potencial) em clientes. Para isso o departamento comercial faz o seguinte. Começa por se aproximar do cliente para saber o que ele quer. Normalmente a resposta é vaga. Algo como “precisamos de um sistema de XPTO porque o nosso tem alguns problemas”. O departamento comercial vê isto como uma oportunidade e propõe que o cliente aceite conversar com alguém da área de projetos. A area de projeto envia 2 ou mais pessoas com capacidades de Levantamento. Normalmente um analista e um domain expert. Não envia apenas uma pessoa. Isso seria um erro. E não envia mais que 3 pessoas, porque isso seria desperdicio. A equipe é focada em levantar os requisitos macro. Até seguimos o processo clássico. A diferença está em que todos os requisitos são gravados como historias. As historias têm uma forma padrão de serem escritas. Isto faz com que os requisitos sejam mais padronizados na sua forma o que permitirá depois indentificar requisitos iguais ou que estão contidos em outros requisitos. Historias não se comparam apenas acasos de uso podendo conter informações não funcionais. A estas historias pode ser atribuido um risco como no processo clássico e um tramanho. A diferença é que o tamanho não é atribuido pela equipe de levantamento ou de projeto.
Em um processo ágil a equipe de execução não é escolhida à posteriori. A equipe é envolvida desde um principio. Aqui ha uma diferença grande para o processo clássico e o tradicional.
O processo de levantamento leva de 5 a 10 dias de entrevistas com vários stakeholders. O objetivo não é criar codigo, mas saber o que o cliente precisa e não precisa.Tudo é escrito em forma de historias para posterior análise.
Não é relevante neste ponto saber o que o cliente quer antes do quê e para quando. Esse aspeto será tratado depois.
De posse das historias, elas foram uma lista. Esta lista é reorganizada. Vários stakeholders podem ter dito a mesma coisa com palavras diferentes. Alguns detalharam mais, outros menos. O objetivo é ter uma lista de historias limpa de repetições e ambiguidadas. Questionamentos são enderaçados ao cliente.
Depois da lista limpa, ela é repassada com a equipe de execução. Neste ponto o erro ainda é grande e o cone de incerteza é levado em consideração. A equipe usa um processo interativo de pontuação do tamanho das historias. Este é um processo semelhante ao Wideban Delphi do processo clássico, mas mais simples e rápido. Este processo é conhecido como Planning Poker. Nesta fase cada pessoa da equipe de execução atribui uma pontuação minima e máxima à historia. Esta margem, junto com o cone de inserteza irá nos dar um tamanho máximo e minimo para a lista de historias. Estes pontos são chamados pontos de historia e obdecem a um conjunto de regras.
O processo de Planning Poker junto com a escala de pontos provê uma forma mais imparcial de contabilizar o tamanho da lista de historias.
A grande diferença para o processo tradicional é que a estimativa é em tamanho não em tempo. Para o processo clássico a diferença é que se escolhe uma unidade nova para estimar o tamanho. Estamos aqui efetivamente dimencionando os requisitos e não a implementação. Esta mudança de paradigma é obvia para alguns e alienigena para outros, mas é necessária no processo ágil.
Sabemos então que a lista de historias do cliente tem um tamanho entre A e B, já com os devidos erros e desvios. A posta feita ao cliente é a seguinte : Você terá direito a gastar B pontos de historia. O nosso preço é P por ponto de historia o que significa que o preço do projeto é BxP.
Este mecanismo é extremamente transparente e muito semelhante à proposta tradicional de “Você tem direito a gastar H horas de projeto. O nosso preço é P por hora o que significa que o preço do projeto é H*P”. Isto diz ao cliente porque o preço é aquele e diz como o preço irá variar se ele decidir modificar alguma coisa. Como a mudança é inevitável é importante que o cliente saiba as regras do jogo. Isto , ao contrario do processo classico de gerenciamento de mudanças, deixa o cliente mais livre e mais à vontade.
Contudo para evitar desperdicios, a proposta não termina ai. A proposta inclui dividir o projeto em pelo menos 3 partes. A prática de repartir o projeto em releases (publicações) já é padrão no processo clássico. Aqui estamos apenas forçando que o projeto seja dividido em 3 releases. Desta forma o cliente é obrigado a priorizar para o primeiro release o que realmente é o coração do sistema, o resto são upgrades ou extensões. As historias são então destribuidas pelos releases, não pelo tamanho, mas pela prioridade que o cliente lhe dá. A Prioridade, assim como o Risco e o Tamanho é uma propriedade das Historias. Veja que no modelo clássico já era assim, já falavamos em prioridades. A diferença é que não atribuimaos um numero para isso. Era sempre subjetivo. Em um processo ágil a prioridade é um numero que pode identificar em qualquer momento qual a historia que é para realizar primeiro.
O processo ágil funciona bem perto do cliente. Nem todos os clientes aguentam esta forma de trabalho, mas o modelo é o mais simples possivel. Uma lista de historias subdividida em 3 ou mais releases. Um conjunto máximo de pontos que têm um preço e a possibilidade de remover, adicionar ou reoganizar as historias a qualquer momento. Qualquer alterção que tenha que ser feita no software para corriger, reverter ou emendar é considerada uma historia e vai consumir pontos. Mas o cliente é livre de comprar mais pontos quando quiser.
O andamento do projeto será medido com comparando as balizas que sãos os releases. O release em si mesmo é dividido em sprints e as tarefas são realidas e aprovadas em um sprint. Isto permite saber claramente o que está pronto para entrega e o que não. A razão entre o numero de pontos realizados por sprint é a velocidade. Estrapolando a velocidade é possivel saber o quanto vai ficar de fora do sprint e já ir replanejando continuamente sem ter que esperar que todas as features estejam implementadas para poder testar ou redirecionar o projeto.
O processo ágil é, portanto, marcado pelos seguintes aspetos:
O processo ágil ainda é estricto em certo aspetos como o processo clássico e demanda, como o clássico um certo grau de comprometimento e não sair mudando as regras sem as conhecer. Não é um processo Stage-Gate com o clássico. Avaliações e mudanças de planos são feitas constantemente. Contudo, como no processo clássico, tudo isto e feito com base em numeros e dados e não em chutes ou promessas.
Dentro do processo ágil existem várias variantes cada um delas dando mais importância a um aspecto ou outro. Algumas como o XP (Extreme Programming) aliam as práticas do processo ágil com boas práticas de engenharia de software para tentar obter o melhor de dois mundos. Outras, como Lean, ainda focam no fluxo do processo e ainda tem um resticio do processo Stage-Gate ( afinal o modelo Lean é baseado em linhas de produção que são stage-gates por definição), outras adotam Stage-Gates conceptuais como Kanban ao mesmo tempo que permitem um controle ágil.
Ágil não representa o abandono dos valores clássicos, nem de suas práticas. Bem pelo contrário. O processo ágil é genéticamente artilhado para cumprir com uma série de leis e permissas resultado da analise classica e ainda sendo simples de usar. Muita gente acha que ágil é o abandono da documentação e do levantamento de requisitos. Nada mais longe da verdade. O ponto é que ágil se preocupa em não desperdiçar, e isso significa que não podemos documentar tudo a toda a hora nem ficar levantando requisitos o resto da vida. Ha um conceito de “bom o suficiente” ou “minimo suficiente” que basta para o trabalho em mãos.
Com o fim da triologia de processo, espero que fique mais claro para todos as diferenças, para que da proxima vez que ouvir falar em processo tradicional ou ágil saiba do que está falando.
Se você entendeu o que escrevi, você deve ter entendido que dizer que você usa um processo tradicional é na realidade uma forma de insulto profissional pois, a realidade não é nada bom usar um processo tradicional. É que as pessoas que usam tradicional e acreditam nele ouvem “tradicional” mas entendem “clássico” e é não exergar a diferença, que os torna tradicionalistas.