Agile Way

No artigo anterior eu trouxe uma visão crítica sobre os processos ágeis em um ambiente de uma agência digital, cuja realidade costuma ser um tanto diferente de uma empresa de software.

Neste artigo irei tentar discorrer sobre algumas ideias para aplicar agilidade em um ambiente destes. Note: são ideias e sugestões baseadas na minha visão e experiência. Não veja isso como uma verdade absoluta.

Antes de entrar no assunto, queria apenas expôr um artigo bem interessante que encontrei em um blog, onde os autores falam de suas experiências com SCRUM em uma produção de um website.

Uma das coisas que eles comentam e que demonstra bem a diferença de uma produção de software e uma produção de um website é:

“When a project includes getting feedback from the end user, it take measurably longer to allow for subjective decisions based on visual elements, than on purely functional determinations.”

E foi o que eu já havia comentado no artigo anterior. É difícil ter feedbacks com clientes quando se trata de algo tão subjetivo como design.

Atacando os problemas com agile

Atenção, lembre-se que essas sugestões envolvem mudanças de processos e cultura. Tenha certeza que muitas pessoas farão cara feia, sem nem ao menos tentar. E outros preferirão manter as coisas como estão, pois dessa forma sempre poderão culpar o “sistema”, a “desorganização” e demais objetos esotéricos. De forma direta, vou atacar os problemas mencionados no artigo anterior.

1) Documento de projeto que ninguém usa. Que tal tornar o documento de projeto em apenas um documento de formalização do que será feito, de forma bem objetiva? Seria um documento orientado ao cliente, talvez até mesmo o próprio contrato. Nele constariam informações que só são relevantes ao pessoal de negócio (algumas datas, algumas orientações, restrições, etc). Tudo o que for de natureza mutável (seções, funcionalidades, usuários, etc) se torna algo informal, como os cartões de um Product Backlog. Esses cartões (também conhecidos como Index Cards) contem as informações relevantes para os desenvolvedores, numa linguagem simples e de fácil entendimento par todas as partes. É preenchido a lápis, o que possibilita a manutenção dele. E é FÍSICO, estando sempre disponível para a equipe. Aliás, está sempre junto ao Scrum Master, que o levará em todas reuniões. E só são atualizados na presença de todos (ou a maioria) dos componentes da equipe – sendo uma forma de estimular a colaboração e a comunicação.

2) Definição preliminar das seções do site quase sempre inexatas. A não ser que se trate de um hotsite simples, ou de um website mais simples ainda, o risco de tentar prescrever as seções que irão compor um website do cliente é o mesmo de tentar adivinhar as funcionalidades do sistema a ser desenvolvido. Lembre-se que os sites atuais possuem gerenciadores de conteúdo, e que tudo isso está associado ao website. Portanto, uma definição errada pode levar ao desenvolvimento de uma arquitetura de informação, layout, programação front-end e back-end errada. Vale a pena arriscar? Assim como no desenvolvimento de software, é relativamente tranquilo de identificar com o cliente quais seções tem mais valor para ele. Normalmente é a seção principal (home) que é a apresentação da sua proposta ou empresa. Vale a pena sentar com o cliente e navegar em algumas referências buscando identificar ideias. E avaliar se algumas das coisas que ele quer são de fato relevantes ou não agregam nada.

3) Wireframes/esqueletos não geram valor ao cliente. Os arquitetos de informação vão me matar! Mas calma, gente. A arquitetura de informação é muito importante para um website sério e bem produzido. Quem duvida, basta pedir para um designer criar um site direto sem pensar na AI. Pode ter certeza que vocês irão encontrar diversos furos de navegação e conteúdo. E até mesmo de programação. Porém, criar uma fase específica para produção da arquitetura da informação não seria perder um período de tempo focado em algo que só tem benefício interno? Que tal então transformar essa criação em algo interno de cada iteração? E mais importante ainda: que tal fazer com que o arquiteto e o designer trabalhem de fato juntos? Um pode completar o outro durante o desenvolvimento.

4) Falta de comunicação entre a equipe. Bom, aqui existem técnicas a serem aplicadas, mas vale ressaltar que se seu pessoal não estiver a fim de fazer acontecer, nada vai adiantar. De imediato, é importante que a cada início de projeto TODOS envolvidos (do executivo de contas ao programador) estejam presentes na reunião. Se o cliente estiver presente, melhor ainda! As pessoas só se sentem parte de alguma coisa quando participam. Ou você acha que alguém será comprometido com algum projeto, que ele pegou sem nem saber quem é o cliente ou mesmo quem fez as telas de layout? Depois encoraje as pessoas a se comunicarem diariamente sobre o projeto. Uma reunião diária (daily meetings) pode funcionar, caso sua equipe tenha apenas um projeto ou seja uma equipe com vários projetos. Agora, imagine reuniões diárias em um ambiente onde cada pessoa trabalha em um projeto diferente: não se trabalharia nessa empresa. Faça o possível para manter a mesma equipe sempre, isso já reforça a comunicação e cumplicidade.  Jamais esqueça de chamar todos para as reuniões de planejamento e retrospectiva da iteração. E, se possível, fuja ao máximo de conversas via MSN, email e afins.

4.1) Ainda sobre a comunicação, tente acabar com o “waterfall” da comunicação. Ou seja, para um programador tirar uma dúvida sobre um pedido do cliente, ele tem que falar com o gerente, que tem que falar com o executivo que fala com o cliente. E depois a mensagem volta por todo esse processo. Qual o problema de aproximar o cliente da sua equipe? Quanto tempo se economiza com isso? E o sentimento de responsabilidade, será que não cresce?

5) Atrasos e falta de testes. Ora, essa é fácil: tente criar a cultura em seus desenvolvedores (e até mesmo designers, arquitetos, executivos e planejadores) de que teste é algo importante. É constrangedor enviar ao cliente algum projeto e receber um feedback de que ele tentou clicar em determinada seção e deu um erro “#495 no stack of mySql and goddamn mothafucka found”. Mais constrangedor ainda é corrigir isso e gerar outros erros. Acredito que na maioria dos websites é inútil utilizar uma abordagem do tipo TDD (test driven development). Seria tentar utilizar uma prática excelente em algo que não necessita de tanto. Mas e se fizer parte do planejamento das seções, durante as iterações, a preocupação com os testes? Discutir quais são os usuários do site, quais são os caminhos a serem percorridos, que dados no manager normalmente dão mais erros e necessitam de uma atenção especial, enfim. Não deixar para testar apenas no fim, mas durante todo o processo. E discutir entre a equipe sempre, sobre isso.

Duas sugestões de aplicação de SCRUM

Antes de mais nada, faço coro ao que li em uma apresentação sobre SCRUM:

“Dentro da sua realidade, aplique o SCRUM como ele é por três iterações. Só então inspecione e adapte.”

Uau, é algo tão óbvio! Mas agora pergunte-se: quantas pessoas que você conhece que ao se deparem com o SCRUM, a primeira coisa que fizeram foi pensar em como adaptá-lo a realidade da empresa? Veja, a pessoa nem aplicou o SCRUM e já pensa em adaptá-lo! Com base no que? Quais feedbacks ele teve para identificar uma mudança?

Logo, minha primeira idéia é exatamente essa: aplique o SCRUM como ele é na sua empresa. Sofra bastante. Veja o que dá errado e o que dá certo. Discuta com sua equipe e só então, após três iterações, inicie a adaptação à sua realidade.

Eu sugeriria duas abordagens:

1) Utilizar iterações e entregar seções a cada sprint. Esta é a adaptação mais óbvia. Ao invés de releases, você entrega seções do website, já prontas. Wireframe, layout, programação front-end e back-end. Utilize a primeira sprint (sprint zero) para focar na parte conceitual do website. Crie o product backlog, priorize e tente chegar a uma linha de arquitetura e layout para ser aprovado ao cliente. A partir disso, no sprint 1, comece a trabalhar arquitetura, layout e programação em cada uma das seções selecionadas. Isso fará com que a equipe trabalhe de fato em conjunto.

E o valor para o cliente? De fato, como eu já havia discutido no outro artigo, é estranho fazer um website e entregar partes para o cliente. Sabemos que o site só irá para o ar quando tudo estiver pronto! Porém, essa abordagem facilita a aproximação com o cliente. Obtem-se feedbacks mais rápidos o que facilita a mudança de rumo, caso seja necessário. E creio que o tempo de desenvolvimento será muito menor, também.

2) Manter a proposta waterfall, mas aproximando o cliente. O que significa isso? Seguir usando a abordagem waterfall onde temos as fases de arquitetura, design, programação. Só que em cada uma dessas fases, criar iterações para entregar algo ao cliente e obter um feedback.  É uma abordagem que eu considero perigosa, pois pode facilitar as velhas práticas mencionadas anteriormente. Porém, pode ser uma forma de ser agile, sem criar uma mudança radical no ambiente.

Notem que em ambas abordagens o que realmente muda é a aproximação do cliente. É importante que a gente perceba que o cliente TEM responsabilidade no projeto. Não dá para deixá-lo acomodado no sentido de “ok, eu pago e vocês fazem e depois me mostram”. Forcem um feedback constante por parte dele.

Em ambas as situações, o gerente de projeto pode fazer o papel de Scrum Master. E o executivo de contas, de Product Owner. Eu diria até que nessa realidade de agências, os papéis do SCRUM são as coisas mais fáceis de identificar…

Concluindo

Criatividade e agilidade podem trabalhar juntos. Processos ágeis não funcionam só porque estão mais alinhados com a realidade moderna de gestão. Funcionam porque focam nos quatro pilares modernos de gestão Preciso lembrar? Pessoas e comunicação, produto entregue e funcional, reação à mudanças e colaboração do cliente.

Os processos ágeis se adaptam em várias empresas de diversos tipos de natureza de serviços. Exatamente por partirem dessa premissa de que precisamos inspecionar o que fazemos, adaptar e melhorar sempre. Esqueça um pouco os termos “processo” e “metodologia”. Pense mais em como satisfazer o seu cliente, garantir qualidade e um excelente ambiente de trabalho.