Campus Party – Slides sobre Agile Development

Esta semana estive no Campus Party e fiz uma apresentação sobre conceitos básicos em Desenvolvimento Ágil com Scrum, abaixo seguem os slides.

Agile UX: como integrar UX e desenvolvimento

Agilidade envolvendo Experiencia do Usuário, ou simplesmente UX, é um dos assuntos mais quentes no “mundo ágil” nos últimos tempos, como fazer para integrar o desenvolvimento de software com a Experiência do Usuário e Design. O Jakob Nielsen fez um ótimo post a respeito (com um viés um pouco “nós contra eles”) com direito a um post resposta bem legal do Alistair Cockburn. E alguns dias atrás o Guilherme Chapiewski fez um excelente post sobre como tem sido a experiência na Globo.com até o momento. Eu passei por este problema lá e quando vim para o Yahoo! resolvi tentar um novo “approach”, que na verdade era o que eu sempre quis fazer na Globo.com.

A primeira diferença que notei é que no Yahoo! não existem as diversas camadas de responsabilidades na parte de Interface/UX/Design. Na Globo.com existem três camadas que são responsáveis pelo visual e UX de um projeto: Os designers, os Arquitetos da Informação e os desenvolvedores Client Side. Claro que os problemas são muito amenizados quando estes três profissionais são alocados no mesmo time ágil. Mas agora olhando de fora, eu sinceramente acho que isso não resolve o problema.

No final o problema principal é a comunicação, como todos sabemos e já foi mencionado por Jack Welch (veja o quote abaixo) quanto mais camadas vc tiver pior será a comunicação, maior será a burocracia e principalmente o comprometimento com o produto final, podendo gerar os mini-waterfalls.

The more layers in a business, the more spin, meddling, and worst of all, delays

Quando estava formando meu time no Y! uma das principais premissas era não criar silos de especialização, ou seja, ter desenvolvedores que queiram mexer com todo o ciclo de desenvolvimento desde BackEnd, Banco de dados até Frameworks Javascript e TDD; um Product Owner que queira entender a importância dos desenvolvimentos de infra-estrutura e processos de qualidade e, neste mesmo contexto, eu tb estava procurando um Designer que não tivesse medo que meter a mão em código e desenvolver a parte Client Side quando fosse necessário. A primeira parte não foi tão difícil, existem muitos desenvolvedores multifuncionais e que tem a cabeça aberta para assimilar que eles devem entender de todo o ciclo e não apenas de uma ou outra parte. Mas achar um Designer/UX que também entenda de implementação não é nada fácil. Apesar de que todos os Designers que conheço (ou quase todos) fazem “freelas” que envolvem escrever código e muitas vezes desenvolvimento usando PHP ou Ruby, quando estão trabalhando na empresa muitos deles se limitam a gerar um PSD, muitas vezes não porque queiram, mas devido a forma como o processo foi estruturado.

No meu time atual tive a sorte (e bota sorte nisso) de encontrar um Designer que gosta de desenvolver toda a experiência, e tem a função de garantir que a visão de funcionamento e design do produto esta sendo bem executada do início ao fim. Neste caso o Designer ou UED (User Experience Designer) tem a responsabilidade de criar a experiência usando sua ferramenta favorita (Fireworks no caso) e depois implementar este design em código garantindo que tanto o visual quanto a experiência será a mesma em todos os browsers que suportamos e de que as boas práticas de implementação estão sendo seguidas.

O que sempre ouvi dizer é que não é possível fazer a interface/design sem pensar no produto todo, na experiência que estou tendo nesse momento posso dizer que isso é meia verdade. A visão do produto precisa estar clara: o que é o produto, quais as funcionalidades chave, qual o público que ele se destina, etc. Mas estou podendo constatar que não é preciso ter todos os detalhes para desenhar a experiência, e que sim podemos fazer a implementação da experiência aos poucos junto com a evolução do produto. No nosso caso estamos apenas no segundo Sprint e o desenvolvimento da interface/design e UX estão seguindo as histórias priorizadas no Backlog, e é muito legal ver a interface ganhando forma de uma maneira iterativa, posso dizer que a interface do nosso protótipo mudou umas 10 vezes (totalmente) e isso em nada impactou os desenvolvedores.

Isso acontece porque decidimos separar totalmente a “camada de apresentação” da “camada de negócios”, o UED é responsável pela camada de apresentação codificando e comitando os templates Django diretamente no SVN. Com isso o UED tem total controle da interface e pode alterar totalmente a usabilidade sem necessitar de outras pessoas (camadas) para isso.

Na última semana, foi até engraçado, pois estavamos todos trabalhando com uma interface na cabeça e de um dia para o outro o UED do time mudou totalmente o funcionamento da interface – para melhor claro. Neste momento me lembrei de como seria se tivessemos as três camadas envolvidas (designer, arquiteto, clientside) … acho que levaria alguns dias/semanas para discutir tudo e no final provavelmente a interface seria vetada por se tratar de uma mudança muito radical. Neste ponto vale lembrar que não adianta ter pessoas de qualidade se vc não deixar que elas tomem decisões, neste caso quem possui a última palavra em termos de UX é o nosso UED.

Voltando aos principios ágeis, onde pensamos iterativamente, sempre entregando software funcionando a cada sprint, posso dizer que se fossemos utilizar a forma antiga onde o UED investe 20 dias (no mínimo) pensando em todos os fluxos possíveis do produto, mais a identidade visual, mais toda a teoria. Com certeza hoje estariamos jogando grande parte deste trabalho fora, pois a idéia do funcionamento do produto evoluiu muito nos últimos 15 dias, e ao incluirmos evoluções iterativas do design/UX conseguimos fazer os ajustes necessários e o impacto foi mínimo. Claro que estou contando com possíveis grandes alterações no futuro, mas pelo menos estas alterações serão fruto da visualização do design aplicado na prática e não de um monte de PSDs e Fluxos de arquitetura.

Ainda não sei o quanto esta forma de trabalhar vai escalar no futuro, mas o ganho que tivemos na agilidade e na qualidade neste início estão valendo a pena.

Video: Palestra do Danilo na Falando em Agile 2008

A Caelum publicou hoje o video da palestra do Danilo Bardusco no Falando em Agile 2008. Para os que nao tiveram a oportunidade de ir ao evento vale a pena assistir.

Falando em Agile 2008

Esta semana vou fazer uma palestra no Falando em Agile 2008, evento organizado pela Caelum do Paulo Silveira e do Alexandre Magno. Esta é a primeira edição deste evento com foco em agilidade e processos de desenvolvimento de software, um assunto cada vez mais recorrente no nosso dia a dia e tema constante em todos os eventos relacionados a tecnologia que participo e leio a respeito.

Apesar de ser a primeira edição do evento, a Caelum trás na bagagem a experiência de realizar o Falando em Java, evento já bem conhecido dos desenvolvedores e muitos anos de participação na comunidade de desenvolvedores no Brasil.

Como não poderia deixar de ser, a agenda esta excelente. Vou poder reencontrar alguns velhos amigos e trocar idéias com pessoas que estão buscando se aprimorar e conhecer mais sobre processos ágeis de desenvolvimento, entre os palestrantes estão Phillip Calçado, Guilherme Chapiewski, Danilo Bardusco e o David Anderson, um dos criadores do FDD (Feature Driven Development). Aqui esta a agenda completa.

Eu vou falar sobre o Product Owner e seu papel dentro de um time ágil, e discutir alguns pontos que sempre surgem quando se fala sobre a sua atuação: o Product Owner pode ser técnico? O PO é parte do Time ou deve ficar de fora do Time? Como se planejar para entregar um release em uma data específica?

Vejo vcs lá!

Distância ainda é importante

Eu não sou muito a favor do uso de ferramentas eletrônicas no gerenciamento de projetos tocados por equipes ágeis, no entanto, até o momento não tivemos que lidar com grandes distância entre membros de um mesmo time ou entre times na Globo.com. Existem diversas ferramentas digitais que se propõem a ajudar os times que estão distantes, a estruturar melhor a informação, gerar relatórios gerenciais e por ai vai. Algumas destas ferramentas são por exemplo o Mingle da Thoughtworks, o VersionOne, o Jira com Greenhopper entre outros, vc pode ver uma lista mais extensa dessas ferramentas no blog do Wayne Allen.

Ainda acho que tudo se resolve com um bom e velho whiteboard, lembrando um dos princípios do Agile Manifesto “Individuals and interactions over processes and tools“. Se for necessário gerar um report do andamento do projeto (ou do sprint) tire uma foto do whiteboard todos os dias e envie para quem precisa deste report. Não tem nada mais claro para verificar problemas e andamento de um time do que o whiteboard.

Hoje em dia a Globo.com esta recoberta de Whiteboards e os burndown charts podem ser vistos por toda a empresa, o que mostra como as coisas estão mudando por aqui. Mas isso não tira mérito das pessoas que tentam encontrar formas de melhorar o trabalho quando times precisam atuar em um mesmo projeto e estão separados geograficamente.

Nas minhas leituras esporádicas de RSS encontrei um post sobre um projeto interessante do Henrik Kniberg chamado Whiteboard Wiki (http://www.whiteboardwiki.org), que se propõe a recriar online, de uma forma simples e direta, o ambiente de um whiteboard.

De qq forma ainda acho que se vc tiver uma opção de manter o time co-locado, nem pense em outra alternativa, “Take It“. Em linha com isso esta um paper do Gary e Judith Olson chamado Distance Matters, onde eles apresentam um estudo sobre o uso de tecnologia como forma de diminuir os problemas da distância. Abaixo segue a conclusão deste Paper:

Collaborative work at a distance will be difficult to do for a long time, if not forever.There will likely always be certain kinds of advantages to being together. However, as a wide range of collaborative tools emerges, we will find useful ways to use them to accomplish our goals. If at some point in the past we had written a similar article about telegraphy, the telephone, radio, television, or fax machines, we would have had tables that catalog their shortcomings. However, in their own ways, all of them have turned out to have been useful for a variety of purposes, and they worked their ways into social and organizational life in enduring fashion. Indeed, some of the most profound changes in social and organizational behavior in this century can be traced to these tools. The rich repertoire of present and future collaborative technologies will have a similar fate. We will find uses for them, and descriptions of collaborative work in the future will enumerate the emergent social practices that have put these technologies to useful ends. But it is our belief that in these future descriptions distance will continue to matter.