Processo de Software √Āgil 

Feb/12
7

 

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:

  • Aceitar que a mudan√ßa do escopo √© inevit√°vel
  • Aceiter que o custo adv√©m do desperd√≠cio
  • N√£o se¬† faz nada sem estimar antes e as estimativas n√£o s√£o viciadas. Para n√£o viciar as estimativas processos que colocam a equipe de execu√ß√£o √† cabe√ßa como o Planning Poker, s√£o usados.
  • N√£o existe fases de projeto. Existem releases. Com datas e listas de features a serem realizadas.
  • N√£o s√£o feitas promessas. √Č estabelecido um contrato, com regras, prazos, coisas a esperar e principalmente coisas a n√£o esperar. Tudo √© feito de comum acordo e sem mecanismos de submiss√£o.
  • O cliente √© respeitado. √Č informado de todos os problemas e todos os riscos. O cliente tem controle absoluto sob o rumo do projeto. Ele decido o que realizar e quando. A prioriza√ß√£o constante leva √† diminui√ß√£o de desperdicios e a alcan√ßar os objetivos do cliente mais cedo.
  • Conhecimento das capacidades e fun√ß√Ķes dos membros da equipe n√£o s√£o necess√°rios porque a equipe, ela mesma, vai acabar provendo a estimativa original os dados de andamento atrav√©s da velocidade. O que ha a fazer √© simplesmente guiar o cliente e permitir que ele fa√ßa corre√ß√Ķes.
  • Sempre que ha um problema qualquer pessoa pode levant√°-lo e alertar.

 

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.

 

 

 

Comente

Artigos