Desenvolvimento

Ξ 1 comentário

Aplicando métodos ágeis além do software

publicado por Flávio Steffens

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.

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

Flávio Steffens de Castro é empreendedor na Woompa (www.woompa.com.br), criador do crowdfunding Bicharia (www.bicharia.com.br) e gerente de projetos desde 2006. Trabalha com métodos ágeis de gerenciamento de projetos desde 2007, sendo CSM e autor do blog Agileway (www.agileway.com.br).

Flávio Steffens

Comentários

1 Comment

  • Um bom contributo para ajudar a desmistificar a ideia errada de que os métodos ágeis só se aplicam aos projetos de desenvolvimento de software

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes