June 21st, 2007XP 2007 – Dia 4

Conforme eu havia previsto, hoje teria menos coisas para escrever. Como houve manifestações a favor dos meus relatos, vou tentar compensar esse post mais “magro” com mais fotos. Mas isso não significa que pouca coisa aconteceu. Pelo contrário, muita coisa interessante aconteceu: 2 tutorias excelentes, almoço com a Mary e Agile Café. Pena que está acabando…

Thinking, Refining, and Communicating the Business Perspective with Executable Documents – Rick Mugridge e David Hussman

Pela manhã, decidi participar do tutorial sobre Documentos Executáveis com o David Hussman (Agile Coach) e o Rick Mugridge, co-autor do famoso livro sobre FIT, apesar de ter participado de uma sessão sobre o framework na Agile 2006. O interessante foi que a ênfase da apresentação foi muito além da ferramenta FIT/FitNesse/FitLibrary. O conceito da documentação executável como elemento de comunicação com os clientes e como forma de definir os cenários de aceitação de uma história vai muito além da ferramenta. Documentos Executáveis são aqueles que não são escritos uma vez só; aqueles que não tendem a ser esquecidos ou a crescer infinitamente; aqueles que ajudam as pessoas a pensar e colaborar; aqueles que ajudam as pessoas a comunicar o que o produto realmente faz.

Algo que gostei muito, e que não tinha visto de forma formalizada antes, foi a prática conhecida como Story-Test Driven Development (STDD ou Desenvolvimento Dirigido por Testes de Histórias), onde antes de fazer TDD, a equipe de programadores, analistas, testers e clientes colabora para definir os critérios de aceitação da história antes mesmo de começar a desenvolver. Como a Mary disse no seu tutorial, por que uma equipe de desenvolvedores deve começar a trabalhar numa história sem saber o que deve fazer? Segunda ela, na empresa do Jeff Sutherland (criador do Scrum e CTO da PatientKeeper) os desenvolvedores não podem colocar a mão numa história se ela não é “testável”. Se o cliente não consegue (ou não se importa em) sentar com a equipe para definir exatamente o que espera do software desenvolvido, não tem sentido começar a programar. Qual o valor esperado?

David Hussman apresentando STDD

Segundo os palestrantes, o caminho para chegar a uma documentação executável passa por diversas etapas:

  • Personas: Para quem não conhece, é uma prática criada por Alan Cooper para descrever os usuários do sistema de forma mais humana. Ao invés de usar “homens-palito” (ou seja lá como chamam esses bonequinhos), uma persona tem nome, foto (ou caricatura), interesses pessoais e valores que espera extrair do produto. No artigo que vou apresentar semana que vem na WDRA (em Porto de Galinhas!), apresento de forma breve essa prática que é muito eficiente (e divertida).
  • Histórias: Partindo das personas, você consegue enxergar diversos objetivos e tarefas que um usuário irá realizar no seu sistema. Fica bem mais fácil escrever histórias a partir dessas tarefas.
  • Testes de Histórias (Story-Tests): Uma vez que temos histórias, é hora de colaborar com o cliente para entender o que eles realmente querem. Dessa conversa devem surgir os testes de histórias (ou testes de aceitação, como o Kent Beck definiu em XP).
  • Cenários, tabelas/fixtures (no caso do FIT), APIs, etc: No momento que a equipe entende a real necessidade do cliente (que pode mudar com o tempo, mas isso é normal), precisam garantir que aquilo seja armazenado de forma executável e que sirva como ferramenta para informar o desenvolvedor quando uma história está quase pronta (“quase” pois o seu conceito de “pronta” pode – e deve – ir mais além da codificação/teste).
  • Documentos Executáveis: Só depois de tudo isso você é capaz de construir uma documentação executável. Essa documentação serve como registro de como o sistema deve funcionar e, quando o cliente mudar de idéia ou quiser discutir algo em particular, ela pode ser alterada/testada em ciclos curtos de feedback para garantir que o sistema se adapta às novas necessidades.

Personas

No final, o grupo se dividiu e a discussão continuou entre os mais interessados no nível mais técnico (discutindo o FIT/FitNesse em particular) e os mais interessados no nível mais amplo. Fiquei um pouco em cada discussão.

From User Story to User Interface – Jeff Patton

Na parte da tarde participei de mais um excelente tutorial com o Jeff Patton, da Thoughtworks. Material impecável, slides e timing muito bons, didática excelente e exercícios práticos divertidos e instrutivos. E, claro, um assunto muito interessante: como o design de usabilidade (por aqui mais conhecidos como Interaction Design) e o design de interfaces gráficas se encaixam no mundo ágil?

Quem vive no mundo do design de interfaces e da usabilidade tem uma propensão a trabalhar com BDUF (Big Design Up-Front). O que geralmente se diz é que você precisa ter uma idéia de todas as possíveis formas de interação e atividades que um (ou vários) usuário(s) terão com o sistema antes de projetar a melhor interface e o melhor design gráfco. Nós do mundo ágil sabemos que BDUF não funciona muito bem. Num dos relatos de experiência apresentados anteriormente, Robert Beedle mostrou um estudo empírico qualitativo mostrando que, em geral, a maioria das atividades de definição de interface tendem a acontecer no início dos projetos mesmo. Ele mostrou quatro abordagens diferentes:

  • Fazer todas as atividades de design da interface antes de começar a desenvolver
  • Fazer ambas as atividades em paralelo, de forma iterativa
  • Fazer ambas as atividades em paralelo, porém trabalhando no design de interface uma iteração na frente (de forma que a equipe de desenvolvimento trabalha sempre em cima do que a equipe de interface desenvolveu na iteração anterior)
  • Começar somente com atividades de design da interface e, gradualmente, inserir atividades de desenvolvimento. Conforme as iterações vão passando, a quantidade de trabalho de desenvolvimento vai aumentando enquanto de design diminui, até o momento em que só é preciso desenvolver. Algo como aqueles gráficos de baleia do RUP.

No tutorial, Jeff apresentou o modelo em camadas proposto por James Garrett para descrever os diferentes elementos da Experiência do Usuário:

  • Superfície: interface gráfica, com cores e elementos gráficos do design.
  • Esqueleto: uma espécie de “wireframe” de como os elementos estão estruturados na interface.
  • Estrutura: como os elementos da interface estão conectados para formar um todo.
  • Escopo: uma lista de tarefas que um usuário tipicamente irá realizar através da interface.
  • Estratégia: os objetivos por trás das tarefas que serão realizadas na interface.

Apresentou também as diferentes formas de representar os usuários (Atores, Papel, Perfil ou Persona) e as diferentes formas de capturar e representar as interações do usuário com o sistema, como: Use cases, Histórias, Workflows, Cenários e Modelo de Tarefas. Durante o resto do tutorial, nos organizamos em grupos e realizamos diversas atividades para produzir e validar um protótipo em papel: partimos de uma história e definimos um simples cenário de uso, descrevendo as interações entre o usuário e o sistema (num formato de Use case essencial). A partir disso, definimos os diversos componentes que fariam parte da interface gráfica para que o cenário fosse atendido.

Componentes da interface gráfica em fase de incepção

Depois veio a parte divertida: começamos a desenhar e recortar os diversos componentes e “montar” a interface em papel, usando canetinhas, papel, transparências, cola pritt e liquid paper.

Criando nosso protótipo em papel

Por fim, vimos como funciona um teste de usabilidade num protótipo de papel e como, depois de poucas iterações, conseguimos diminuir o número de erros de usabilidade. Para isso, cada um tinha um papel (role, para não confundir): o “facilitador” apresentava nossa proposta e era o único que podia conversar com o usuário-final (num estilo narrador de esporte). Outra pessoa faz o papel de “computador” e fica trocando os papéis/botões/transparências conforme o usuário-final interage com o protótipo. Além do “usuário-final” (que eram duas pessoas vindas de uma outra equipe), alguém precisa fazer o papel de “observador” e ficar tomando nota dos problemas encontrados durante o teste.

Teste de usabilidade do protótipo com usuários de outra equipe

Foi uma experiência valiosíssima (o melhor tutorial até agora na conferência) e aprendi bastante sobre como integrar o mundo do design com o mundo de desenvolvimento. Nós sempre aprendemos bastante quando passamos por problemas parecidos. O Jeff está fazendo um trabalho excelente para juntar essas duas comunidades. Para quem se interessar, vale a pena conferir as suas idéias.

Discussões em Geral

Não bastassem os ótimos tutoriais, aind tive o privilégio de ser convidado para almoçar com a Mary e com o Tom para discutir várias coisas. Uma das discussões foi a respeito da velocidade, e expressei minha opinião (e a da Mary) na XP@Rio. Não vou me repetir por aqui. Se alguém se interessar, é só seguir o link. :-)

Como comentei, as pessoas que não estão participando de workshops ou tutoriais geralmente se reúnem nas mesas de fora do hotel para discutir assuntos ágeis, no que foi batizado como Agile Café. Dei uma passada no final do dia, mas já estava cansado e resolvi voltar pro hotel para descansar. Por hoje é só, pessoal. Amanhã é dia de mais um tutorial e um workshop. Arrivederci!

Post to Twitter

July 25th, 2006Agile 2006 – Dia 3

Resumo do terceiro dia de conferência: uma sessão pela manhã, quatro na parte da tarde e eu descobri que estou ficando míope :-)

Storytelling with FIT – Steve Freeman e Mike Hill

Depois da sessão de ontem
com o Ward Cunningham sobre a importância dos testes para a evolução de um sistema, decidi assistir uma palestra
sobre o framework que ele inventou para testes de aceitação: FIT. O ponto principal
da palestra foi mostrar a importância dos testes de aceitação como meio de comunicar requisitos. Eu já ouvi muitas
conversas por aqui sobre a utilização da palavra “teste”, pois muitos podem achar que o único objetivo de um teste
é encontrar erros (e sabemos que, apesar de eficientes, testes não provam a ausência de bugs). Ao invés de “teste”,
os apresentadores tentaram usar o termo “documento”, pois os testes de aceitação no FIT são páginas HTML contendo
texto e tabelas com exemplos que especificam o comportamento esperado do sistema. O mais interessante é que o
documento é algo executável. Com isso você tem como especificar os critérios de aceitação de uma história antes de
ter a implementação pronta (a idéia de escrever testes antes do código aplicada num contexto mais amplo).
Ao implementar a funcionalidade esperada, você utiliza ferramentas como os testes de unidade e
TDD para garantir
a qualidade do código. Porém o desenvolvedor é também responsável por fazer o teste de aceitação passar. Para isso,
você precisa escrever um Fixture, que na verdade é uma classe
que será chamada pelo framework e te dará acesso aos dados escritos no documento FIT. A partir daí, você faz as
chamadas necessárias ao código da sua aplicação e avalia os resultados de acordo com as expectativas descritas no
documento FIT. Abaixo são duas tabelas que fizemos para especificar uma parte de um sistema de venda online de
serviços de internet:

Storytelling with FIT

Agile Quality: A Canary in a Coal Mine – Ken Schwaber

A sessão que escolhi participar depois do almoço foi do outro inventor do Scrum:
Ken Schwaber. Ele falou sobre a importância da qualidade como
atributo essencial num sistema de software: devemos nos preocupar com a qualidade desde o início. O custo para
colocar a qualidade depois é muito alto, podendo até levar um projeto ao fracasso no longo prazo devido à perda
de vantagem competitiva. Quando mais tempo você gasta lidando com defeitos no seu sistema, menos tempo sobre para
pensar no valor que ele está trazendo para o negócio. E o principal objetivo de qualquer sistema de software
deve ser agregar valor ao negócio. Na sua palestra, Ken tentou mostrar a importância da qualidade para um projeto de software e defendeu a idéia de que cortar qualidade deve ser uma decisão de negócio.

Agile Stories – Research Papers

Na segunda metade da tarde, resolvi assistir à apresentação de 3 papers, numa trilha chamada “Agile Stories”.
Falarei um pouco sobre cada um dos papers nos tópicos abaixo:

The Deployment Production Line – Jez Humble, Chris Read e Dan North

Esse artigo foi bem interessante: eles mostraram uma forma efetiva de estruturar e automatizar a implantação da sua
aplicação em diferentes ambientes (teste, integração, aceitação, …). O artigo explica de forma mais detalhada a idéia
da linha de produção que eles desenvolveram num projeto da ThoughtWorks. O interessante
é que eles automatizaram o processo de tal forma que qualquer pessoa podia fazer o deploy de qualquer versão do sistema
em qualquer ambiente com poucos cliques. É interessante ressaltar também o modo em que eles quebraram as dependências
para acelerar a execução dos testes nos diferentes ambientes, paralelizando em várias instâncias separadas do
Cruise Control a execução dos testes de unidade, testes de aceitação nos
cenários de sucesso (smoke tests, que rodam mais rápido), testes de aceitação nos cenários mais complicados (demoram
mais), testes de performance, etc. Com isso, um determinado build vai ganhando “medalhas” conforme passa em
cada etapa de teste, ficando fácil de saber quando ele pode ou não ser implantado em ambiente de produção.

The Cost of Code Quality – Yuri Kharmov

Essa apresentação foi, por enquanto, a pior da conferência. Foi o oposto da palestra do Ken Schwaber
que eu tinha acabado de assistir. O autor defendeu a idéia de que nem sempre precisamos
nos preocupar com a qualidade quando escrevemos código. O principal argumento dele é: toda preocupação com
qualidade tem um custo associado e você deve considerá-lo na hora de usar técnicas como TDD ou Integração Contínua,
em outras palavras, não é um grande problema ter um sistema cheio de bugs se eles não te atrapalham.
Duas coisas me incomodaram: em primeiro lugar ele transpareceu não entender a verdadeira essência de
TDD como uma
ferramenta que possibilita o Design Incremental.
Segundo, quando perguntaram para ele ao final da palestra quantas vezes ele discutia sobre qualidade de código com
o cliente, ele respondeu “Quase nunca”. Como ele pode julgar pelo cliente o valor da ausência ou não de bugs se ele
nunca discute sobre isso?

Appropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value – Deborah Hartmann e Robin Dymond

A última palestra do dia foi sobre métricas ágeis. Eu achei bem interessante a distinção entre “Diagnósticos” e “Métricas”
proposta pelos autores:

  • “Diagnósticos”: são números que te ajudam a entender o andamento das coisas em relação ao processo. Por exemplo: medir a velocidade do time; interpretar o gráfico de “Burn-Down” para descobrir se o time irá terminar no prazo; ou saber a quantidade de defeitos. “Diagnósticos” dependem do contexto do time e devem ser temporários, ou seja, descarte-os assim que o processo estiver funcionando.
  • “Métricas”: são números que medem o valor de negócio que seu sistema está produzindo. Por exemplo: retorno de investimento; lucro; ou presença de mercado. “Métricas” são mais difíceis de medir, por isso é bom escolher apenas uma.

É preciso tomar cuidado com as métricas que você escolhe para avaliar o desempenho de uma equipe ágil, afinal
“You get what you measure”. Outra coisa que eles mostraram foi um template para ser utilizado na hora de
criar uma métrica ágil, com pontos que te fazem pensar sobre o verdadeiro valor que aquela métrica irá representar
quando estiver medindo o sucesso do seu software.

Post to Twitter


© 2007-2009 Danilo Sato | Powered by Wordpress

Page optimized by WP Minify WordPress Plugin