Aplicando métodos ágeis além do software (I) « Agile Way


18 de Novembro de 2009

Aplicando métodos ágeis além do software (I)

Há algum tempo eu vinha percebendo que certas questões dos métodos ágeis, em especial o SCRUM e XP, não ficavam claras pra mim. Isso me incomodava bastante.

Trabalho e estudo métodos ágeis desde final de 2007. Sempre busquei extrair a essência por trás dos processos. Mas de vez em quando, no momento em que questões de processo e engenharia cruzavam minha frente, novamente eu me enchia de dúvidas.

Nos últimos meses eu tenho pesquisado a respeito e percebi que, felizmente, esse desconhecimento é bastante comum. E mais: não há muito material disponível sobre isto. O que se encontra é baseado no “achismo” e no já conhecido “inspect & adapt”.

A realidade que eu falo é a aplicação dos métodos ágeis além do desenvolvimento do software. E no meu caso específico, agências digitais de criação de websites.Quando encontramos muitos “achismos” é sinal de que pouca gente de fato tentou desenvolver websites (seja em HTML, Web 2.0 ou Flash) utilizando SCRUM ou XP. E talvez exista um porquê nisto tudo.

O dia-a-dia numa agência digital

No período em que trabalhei numa grande agência digital em Porto Alegre, tive a oportunidade de estar à frente dos projetos de websites que foram desde institucionais, passando por e-commerces e até sites criativos e orgânicos em Flash.

Em todos os casos, o processo era basicamente o mesmo: linha de produção, ou waterfall.

Pegando todo o ciclo de vida do projeto: fazia-se a prospecção (seja recebendo contato do cliente ou indo até ele), designava-se um executivo de contas para representar o cliente dentro da empresa – fazendo toda a interface de comunicação, que era centralizada basicamente nos executivos, fazia-se uma primeira reunião com o cliente onde eram passados todo o briefing, requisitos, desejos, etc., com base nisso alocava-se a equipe.

Então iniciava-se o processo de produção. Normalmente o gerente desenvolvia um documento do projeto, mapeando as seções previstas, requisitos funcionais ou não e demais informações.

Os planejadores criativos, se o projeto demandasse, criavam toda a campanha criativa para ativação, marketing ou simplesmente linha de criatividade que o website deverá seguir. O documento de projeto era atualizado, ou deveria.

O arquiteto de informação recebia este documento e criava o esqueleto (wireframe, boneco, como quiserem) navegável da proposta ao cliente. Esse processo já era um pouco iterativo: fazia-se uma ou duas telas, aprovava-se com o cliente (ou não) e desenvolvia-se as demais com base no feedback.

Em seguida, aprovado o wireframe pelo cliente, o designer tratava de dar “vida” ao esqueleto. Cores, imagens, tipografia, destaques, animações e textos com base no que o arquiteto orientou. Seguia-se o mesmo princípio: duas ou três telas, aprovação, finalização das demais. Aprovação final.

E então os programadores entravam em ação. Desenvolviam a programação front-end (html, flash) e a back-end (php, asp, rails). Ao contrário das demais etapas, nessa o cliente não via “iterações”, mas apenas o website pronto. Finalizada a programação, o cliente aprovava. Com base no feedback, ajustes eram feitos e nova aprovação. Até a aprovação final e entrega do website.

Este tipo de processo de desenvolvimento é bastante comum e usado em quase todas agências digitais.

Problemas dessa abordagem

Pude identificar na prática alguns problemas dessa abordagem. Vou citar cinco:

1) Documento de projeto. Infelizmente o documento era tido como um artefato de muito valor, mas ninguém usava (notaram a discrepância?). Se muito, o arquiteto de informação era o que mais utilizada. Além disso, a documentação era raramente atualizada durante o projeto.

2) Definição preliminar das seções do site. Era cobrado do cliente, logo nas primeiras reuniões, uma definição das seções que o site deveria abordar. Por diversas vezes no decorrer do projeto ocorreram modificações (inclusões, exclusões, alterações) e tudo, de quebra, era feito com muita negociação com o cliente.

3) Wireframes/esqueletos. Os arquitetos de informação desenvolvem os wireframes com base no que imaginam ser necessário para organizar as informações no website que o cliente deseja, sempre com base nas referências que o cliente havia passado. Pude perceber a grande falta de capacidade de abstração dos clientes ao visualizarem as wireframes. Um website, para um cliente, é imagem e cor. Ver apenas molduras, textos e linhas de marcação não dizem nada – o que faz com que o cliente mude de idéia depois. E também não encantam.

4) Falta de comunicação entre a equipe. Arquitetos, designers e programadores raramente discutem o projeto desde o início. Eles são alocados conforme necessário. A idéia que um arquiteto teve pode não ser a mesma que um designer imaginava.

5) Atrasos e falta de testes. Como todo waterfall, a “fase de testes” é a primeira a sucumbir em caso de atrasos. Aliás, eu confesso que por muito tempo eu usei essa fase mais como “pulmão ou buffer” do que como uma fase dedicada a testar. Do início ao fim do projeto, pouco se discute sobre quem irá usar o site, quais testes devem ser pensados desde já… e como todo waterfall, qualquer atraso no início e meio do projeto, afeta diretamente o final. E o cliente normalmente não enxerga isso.

Porque o SCRUM e o XP confundem as pessoas dessa área

Poderia ficar discutindo diversos aspectos que contribuem para a confusão que é feita com SCRUM/XP nessa realidade. Vou citar apenas três:

1) Equipes multidisciplinares. As chamadas “cross-function teams” nessa realidade se tornam um caso a parte. Em desenvolvimento de software, pensamos na equipe como sendo composta por: analistas, testadores, DBA, programadores. Em agências temos: arquitetos de informação, designers, executivos de conta, planejadores, programadores.

Notou a diferença? As equipes das agências não são essencialmente técnicas. Um designer sabe pouco de programação e provavelmente nunca saberá o suficiente. Um programador dificilmente saberá diferenciar a influência de um tom de verde no fundo de um site. Realizar “pair programming” se torna algo completamente maluco! Realizar daily meetingdesandar a motivação (“do que diabos ele tá falando?”). Exigir uma visão analítica e sistêmica é de difícil compreensão e aplicação para alguém que vive de idéias e criatividade. Como mensurar “erro/defeitos/bugs” em um processo criativo?

2) Entregas iterativas de valor. Uma campanha via internet (hotsite, por exemplo) de uma grande empresa só terá valor ao cliente quando estiver PRONTA. Ajudaria ao cliente oferecer na primeira iteração a seção principal, na segunda a seção de cadastro dos usuários e na terceira o contato e a ativação da campanha? Qual a diferença de geração de valor entre essa abordagem e uma waterfall, já que ambas só trarão valor real no fim?

3) Criatividade. Vale ir mais a fundo nisso. Um software ERP, um sistema de gerência de estoques ou qualquer outro software coorporativo é visto sob a ótica FUNCIONAL. Um cliente jamais vai complicar uma equipe que entrega as transações com segurança, um cadastro bem efetivado, uma integração com o sistema legado… e uma interface pobre. O valor está associado à funcionalidade.

Já um website ou uma campanha digital tem um foco quase que exclusivamente em CRIATIVIDADE e DESIGN. Empresas que investem nisso, querem um site atrativo, de fácil navegação, simples, objetivo… bonito e criativo. Chegue na apresentação de uma grande empresa com o seu site institucional todo desenvolvido no MS FrontPage após um curso rápido de HTML. Você sabe que não sairá vivo de uma reunião assim.

Criatividade e design são de difícil mensuração. E pior: tendem a levar ao cliente a impressão de que uma mudança de “um boãozinho da parte de baixo, para a parte de cima” é super simples. E nem sempre é.

E aí? Tem saída? Podemos usar SCRUM/XP ou qualquer método ágil numa agência?

A resposta é não… não se deixe desmotivar :) Com certeza é possível.

A grande diferença é a abordagem.

Métodos ágeis tem como característica principal o “inspect & adapt”, ou seja, aplique, verifique, corrija e adapte conforme necessário. Tive a oportunidade, durante a minha pesquisa, de ler casos de aplicação de métodos ágeis em projetos espaciais da NASA (que segundo o Jeff Sutherland – “… ao final do projeto as pessoas choravam e se abraçavam comemorando. Aquele havia sido um dos projetos mais bem sucedidos da NASA…”) até empresas de advocacia!

No próximo artigo eu pretendo trazer algumas sugestões e idéias para que sejam combatidos alguns problemas aparentes. Alguns até que eu citei acima.

Até breve!



5 Comentários para “Aplicando métodos ágeis além do software (I)”

  1. Alex diz:

    Olá Flávio,

    muito interessante o seu post. Pelo que entendi, ainda são poucas as empresas de comunicação e publicidade que entendem que é melhor um processo cíclico para desenvolver um projeto grande, ao invés da cascata.

    Porém, acho que passo a passo vamos conseguir envolver todo mundo desde a produção do wireframe até o desenvolvimento final, com a evolução dos profissionais e das ferramentas.

    Não conhecia o seu blog, encontrei através de um tracker sobre wireframes. Vou passar a frequentar mais vezes.

  2. [...] Aplicando métodos ágeis além do software (I) – Flavio Steffens (Agileway); [...]

  3. Rafael diz:

    Parabéns pelo post, Flávio!!

    A empresa em que trabalho está passando por vários questionamentos que você citou acima, e infelizmente ainda não chegamos ao processo ideal.

    Aguardo seu próximo post… quem sabe vem uma luz

  4. [...] artigo anterior eu trouxe uma visão crítica sobre os processos ágeis em um ambiente de uma agência digital, [...]

  5. Raíne Santana diz:

    Achava que somente eu tinha me deparado com tal dúvida. Foi reconfortante saber que não. Estou redigindo a documentação do meu trabalho de conclusão de curso, que é sobre um site, e eu estou tendo muita dificuldade por se tratar de um site, não de software e ainda por cima não temos um empresa, e sim uma dupla, e ainda por cima não iremos desenvolver para um cliente em questao. Obrigada pela iniciativa.

Comentar