Specification By Example: How successful teams deliver the right software

Este livro, escrito por Gojko Adzic é diferenciado, porque é um daqueles livros que quebram com paradigmas. O livro em si não possui nenhum código fonte e não explica sobre nenhuma ferramenta. É essencialmente sobre processo para a entrega de um produto certo, e não apenas de construir certo. Os livros do Gojko em geral são muito bons, todos eles não apenas valem a pena ser lidos como devem ser lidos por qualquer um interessado em entregar software de qualidade. Este livro foi listado como o segundo mais influente livro ágil de 2012, baseado nos reviews da Amazon e da Goodreads. Gojko é sérvio, sua carreira profissional começou em 1997 com artigos sobre programação publicados em revistas sérvias. Em 2005 ele se mudou para o Reino Unido e em 2009 fundou junto com outras pessoas a Yazino, uma startup de game social. Estarei neste post trazendo incrementalmente as principais ideias desse livro.

Muitos nomes, uma só ideia

Um esclarecimento muito importante são as inúmeras variações de nomes que as práticas que tratam com especificações e testes possuem. Todas elas compartilham dos mesmos conjuntos de princípios e ideias, dessa forma, tratam essencialmente da mesma coisa:

  • Agile acceptance testing
  • Acceptance Test-Driven Development
  • Example-Driven Development
  • Story testing
  • Behavior-Driven Development
  • Specification by Example

Gojko percebeu que as inúmeras variações de nomes não faziam com que as pessoas de negócio se tornassem mais envolvidas, os termos eram muito técnicos e mais confundiam do que ajudavam. Dessa forma decidiu nomear todo o conjunto de práticas descritas no livro como Specification by Example, pois não cria uma herança com nomes como agile, driven-development ou test, o que algumas vezes podem levar a uma compreensão viciada dos termos.

Você está construindo certo o produto certo?

Construir certo o produto versus construir o produto certo

Como pode ser visto na imagem, Specification by Example vai de encontro não apenas em construir certo o produto, mas também em construir o produto certo. Segundo o autor, o foco da comunidade nos últimos anos foi principalmente na eficiência e não na eficácia. Lembre-se de Peter Drucker, “a eficiência consiste em fazer certo as coisas, a eficácia em fazer as coisas certas”. Precisamos de ambos para o produto ter êxito. Dessa forma, para construir o produto certo é preciso:

  • Evitar o excesso de documentação.
  • Evitar a perda de tempo em detalhes que irão mudar antes mesmo de um trecho de código ser desenvolvido.
  • Ter documentação confiável que explique o que o sistema faz e que possa ser modificada facilmente.
  • Manter a documentação relevante e confiável com o mínimo de custo de manutenção.
  • Encaixar tudo isso em iterações curtas, para que as informações sobre o trabalho futuro possam ser produzidas just-in-time.

A figura a seguir mostra a documentação que times ágeis necessitam hoje. Elas precisam ser fáceis de manter, devem possibilitar serem escritas com pouca antecedência e devem ser testáveis. Isso faz todo o sentido quando passamos a pensar que toda a documentação gerada para o software passa a ser única. Isso é, não existe diferença da documentação que uma equipe de qualidade gera e da que o analista de negócios gera, pois todas elas tem o mesmo propósito. Todos estão escrevendo especificação para que o software funcione corretamente. Escrever comportamento de teste também é escrever especificação.

Intersecção para construir o produto certo

Quais são os benefícios em utilizar as práticas de Specification By Example?

O conjunto de práticas de Specification by Example pode ser usado tanto em times que usam processos baseados em iterações, como Scrum e Extreme Programming (XP), assim como processos baseados em fluxos, como Kanban. Os principais benefícios são os seguintes:

Implementação de mudanças mais eficiente

Isso ocorre por conta da existência de “documentação viva”, que é uma fonte confiável de informação das funcionalidades do sistema. É como dizer que agora a sua especificação é “compilável” (e como você verá mais adiante, de fato é).

Alta qualidade do produto

As expectativas estão claramente definidas o que torna a validação do processo eficiente. O desenvolvimento é baseado em comportamentos testáveis.

Menos retrabalho

Melhora da colaboração nas especificações, o que leva a um entendimento compartilhado das expectativas de todos os membros do time.

Melhor alinhamento de atividades dos diferentes papéis dentro do projeto

Melhora da colaboração entre os papéis, o que leva a um fluxo de entrega mais regular.

Quais são os passos para entregar um produto eficaz?

Specification by Example é um conjunto de processos que facilita a mudança no software. Foca na entrega de um produto eficaz, e não apenas eficiente. A figura a seguir é a “big picture” do Specification By Example, e de certa forma, mostra o como o software sempre deveria estar: alinhado com o negócio. Na primeira parte, deriva-se o escopo a partir dos objetivos de negócio. Nada mais justo, sem objetivos de negócio o software provavelmente não teria motivos para existir. O escopo é então especificado colaborativamente, definindo-se os principais exemplos que são representativos para as user stories. Esses exemplos são refinados para então poderem ser automatizados, o que dá origem a uma especificação executável, literalmente uma especificação “compilável”. Essa especificação é validada frequentemente, uma vez que esses exemplos estão automatizados. Isso tudo dá origem a uma especificação viva e totalmente sincronizada com o software. Ao final, se algum comportamento do software é alterado a ponto de não corresponder mais a um exemplo da especificação, a validação irá quebrar. Da mesma forma, se algum exemplo da especificação é alterado sem que haja alteração no código, o software irá quebrar.

Processo da especificação por exemplos

A seguir serão mostradas as principais ideias de cada uma das etapas desse processo que foram extraídas do livro.

Derivar o escopo dos objetivos

Implementar um escopo significa oferecer a solução para um problema de negócio ou atingir um objetivo de negócio. Confiar no cliente para criar uma lista de user stories é deixar para ele a responsabilidade de desenhar a solução, porém os usuários de negócio não são designer de software. Se o cliente é quem define o escopo, o projeto não irá se beneficiar do conhecimento das pessoas da equipe de entrega. Isso resulta em um software que faz o que o cliente pediu, mas não o que ele realmente precisa. Ao invés de aceitar cegamente os requisitos de software como uma solução para um problema desconhecido, deriva-se o escopo dos objetivos. Os usuários de negócio, dessa forma, focam em comunicar o valor que eles esperam receber das funcionalidades desejadas. Isso ajuda todo mundo a entender porque ela é necessária. O time então pode sugerir uma solução que seja mais econômica, rápida e fácil de entregar do que aquela que muitas vezes os usuários de negócio imaginavam.

Especificar colaborativamente

Se desenvolvedores e testadores não estão engajados em elaborar as especificações, essas terão que ser comunicadas separadamente para o time, o que acaba abrindo oportunidades para muitos desentendimento. Na prática, você está brincando de telefone sem fio. No lugar de simplesmente confiar em uma única pessoa toda a responsabilidade de criar as especificações, por que não fazer com que os times de entrega colaborarem com os usuários de negócio para especificar a solução? Pessoas com diferentes experiências tem diferentes ideias e usam essa experiência a favor para resolver os problemas. Especificar colaborativamente cria um senso de posse compartilhada da especificação, fazendo com que todos sintam-se mais envolvidos no processo de entrega.

Ilustrar usando exemplos

Em vez de esperar que as especificações sejam precisas desde o início, trabalhe junto com os usuários de negócio para identificar os principais exemplos que descrevem a funcionalidade esperada. Durante esse processo, desenvolvedores e testadores frequentemente sugerem exemplos adicionais que ilustram casos extremos ou que enderecem áreas do sistema que são particularmente problemáticas. Isso elimina gaps funcionais e inconsistências e garante que todos os envolvidos tenham um entendimento compartilhado do que necessita ser entregue. Se o sistema funciona corretamente para todos os principais exemplos, então ele atende a especificação em que todos acordaram. Os principais exemplos definem o que o software precisa fazer. Esses exemplos serão usados como base para o desenvolvimento e também serão um critério de avaliação objetivo para saber quando o desenvolvimento estará pronto.

Refinar a especificação

Criar uma especificação colaborativamente através de exemplos cria um entendimento compartilhado do domínio do negócio, porém resulta em exemplos mais detalhados do que o necessário. Usuários de negócio pensam muitas vezes sobre a perspectiva de interface, logo oferecem exemplos de como algo deve funcionar quando clicam em links e preenchem campos. Esse tipo de descrição restringe o sistema. Detalhar como algo deve ser feito ao invés do que deve ser feito é um total desperdício. Exemplos detalhados fazem com que eles sejam difíceis de comunicar e entender. Os exemplos refinados podem ser usados como critérios de aceitação para a entrega. O desenvolvimento não estará pronto até que o sistema funcione corretamente para todos os exemplos. Depois de prover informação para que todos os principais exemplos sejam fáceis de entender, o time então passa a criar especificações com exemplos, ao qual representa a especificação de trabalho, o teste de aceitação e também futuramente o próprio teste de regressão funcional.

Automatizar a validação sem alterar a especificação

Uma vez que o time concorda com as especificações com exemplos e as refina, elas podem ser utilizadas como base para o desenvolvimento e para validar o produto. O sistema será validado muitas vezes com esses testes durante o desenvolvimento para garantir que eles atendam aos objetivos. Como se automatiza a validação sem alterar a especificação, os principais exemplos serão próximos dos mesmos que foram feitos no quadro branco: compreensíveis e acessíveis para todos. Para que tudo isso ocorra, não seria possível automatizar as especificações com uma linguagem muito técnica, pois as tornariam inacessíveis para os usuários de negócio. Existem hoje muitos frameworks que quase não requerem tradução dos principais exemplos. Alguns deles são o Concordion, FitNesse, Cucumber e SpecFlow. Dessa forma, o mesmo documento pode ser usado para buscar esclarecimentos com os usuários de negócio. Se há necessidade de alterar a especificação, isso será feito em um único lugar.

Validar frequentemente

Na maioria das vezes, o código fonte é a única coisa em que se pode confiar. A maioria das documentações ficam desatualizadas antes mesmo do projeto ser entregue. Dessa forma, os programadores passam a ser o gargalo da informação. Especificações executáveis, por outro lado, são fáceis de serem validadas. Se a validação é frequente, então é possível haver tanta confiança na documentação quanto no código fonte de que eles estão fazendo a mesma coisa.

Evoluir a um sistema de documentação

Uma documentação viva, é uma fonte confiável e oficial de informação sobre as funcionalidades do sistema que qualquer pessoa pode acessar. É tão confiável quanto o código, só que muito mais fácil de ler e entender. A equipe de suporte pode usá-la para saber o que o sistema faz e por quê. Os desenvolvedores podem usá-la para desenvolvimento. Testadores podem usá-la para testes. Analistas de negócio podem utilizá-la como ponto de partida para se analisar o impacto de uma mudança em uma funcionalidade. Além de tudo isso, possibilita também o seu uso para teste de regressão.

Testes e especificações são a mesma coisa?

Quando uma especificação é utilizada com muitos exemplos concretos, ela pode ser usada também para testar o sistema. Depois que a especificação é automatizada, ela torna-se um teste de aceitação executável. Dessa forma, especificações e testes são a mesma coisa. Evidentemente que isso não significa que não há outros tipos de teste, como por exemplo, testes exploratórios e testes de usabilidades, porém esses tipos de testes não são especificações.

Quais os efeitos sobre os diferentes papéis na equipe?

Efeitos sobre os analistas de negócio:

  • O papel do analista de negócio está mudando de um transportador de informação para um facilitador que permite as pessoas compartilhar conhecimentos diretamente.
  • O analista de negócio é uma ótima opção para ser o facilitador do workshop de especificação.
  • Trabalhar com teste de aceitação torna o resto do trabalho do analista de negócio mais fácil e mais eficaz.
  • Você ainda pode manter seus documentos tradicionais, mas use os testes de aceitação como especificação oficial.
  • Você pode modificar a especificação (testes de aceitação) quando o desenvolvimento iniciar sem causar grandes problemas para ninguém.
  • Testes não tem que ser perfeitos desde o início.
  • Fazer tudo certo não é só sua responsabilidade. Desenvolvedores e testadores compartilham a responsabilidade pelas especificações.

Efeitos sobre os testadores:

  • O papel principal do teste é ajudar as pessoas a evitar problemas, não descobri-los.
  • O processo de QA não termina com o teste de aceitação ágil. Você pode usar ainda qualquer outra ferramenta ou técnica além dos testes de aceitação.
  • A automação dos testes de aceitação dá a você mais tempo para testar coisas que não podem ser facilmente automatizadas.
  • Testadores tem mais influência em projetos que usam teste de aceitação ágil.
  • Desenvolva sua carreira aprendendo tudo que você possa sobre o domínio durante os workshops de especificação, ou torne-se um especialista em automação.

Efeitos sobre os desenvolvedores:

  • Você não pode escrever testes de aceitação por conta própria.
  • Você precisa participar em discussões sobre o domínio.
  • Workshops de especificação dá a você uma boa chance para discutir casos extremos e inconsistências com especialistas no domínio antes do desenvolvimento.
  • Testes de aceitação não fornecem feedback instantâneo como os testes unitários. Isso é porque eles lidam com o panorama geral e com regras de negócio e não com unidades de código.
  • Você necessita ambos, testes de unidade e testes de aceitação.
  • Testes de aceitação existem para facilitar a comunicação entre as pessoas.
Anúncios

The Scrum Field Guide: Practical Advice for Your First Year

Este é um dos livros ao qual tomei conhecimento pela página dos top 100 agile books de 2012 do blog do Jurgen Appelo. É um livro que disparou para a sétima posição da lista e que me despertou a curiosidade de lê-lo. O livro for escrito por Mitch Lacey. Mitch é consultor ágil e tem sua própria empresa, chamada Mitch Lacey & Associates Inc. Ele ajuda empresas a obter ganhos através da adoção de princípios e práticas ágeis. Sua carreira profissional começou em 1991 em uma empresa de jogos de computadores. O livro relata as lições aprendidas mais significativas para equipes que estão em seu primeiro ano de projeto ágil. Neste post, vou relatar de forma incremental os pontos que mais me chamaram a atenção no livro.

O Scrum é simples, mas não é fácil

Este capítulo foi uma boa forma de começar a livro, pois afinal de contas o maior desafio no Scrum não está em seu processo, mas em sua cultura, na mudança de mentalidade. O Scrum vai contra tudo aquilo que se aprendeu em muitos anos de desenvolvimento waterfall. Dessa forma, nada mais lógico que tome um tempo para desaprender velhos hábitos e ajustá-los a uma nova realidade. Normalmente não é o Scrum que falha, mas as pessoas que falham em usar o Scrum, por isso da importância também da necessidade de coaching. Em uma história que Mitch conta neste capítulo, ele deixa claro que a primeira coisa a se fazer ao ensinar Scrum é fazer entender os valores, o framework, e a mudança de mentalidade que é necessário para ir adiante. Implementar Scrum requer que as pessoas estejam dispostas a fazer as seguintes mudanças:

  • Desenvolver um entendimento dos valores do Scrum;
  • Submeter-se a uma enorme e frequente mudança de mentalidade;
  • Planejar prevendo a mudança e adaptar quando ela ocorrer;
  • Tratar com questões que nascem repentinamente;
  • Incorporar práticas de engenharia ágil.

O Scrum é construído em cima de valores

Para que se entenda os valores, é necessário que se entenda o por que estamos fazendo o que estamos fazendo. Qualquer framework que vale a pena ser adotado é construído em cima de princípios e valores. Os valores por trás do Scrum são foco, respeito, comprometimento, coragem e “mente aberta”.

O Scrum requer uma mudança de mentalidade

Isso pode se resumir em uma única frase: “Você não pode resolver os problemas usando a mesma mentalidade de quando foram criados”, Albert Einstein.

O Scrum toma o caminho mais curto, não o caminho definido

Veja na imagem a seguir, se você percebe no meio do caminho que você pode pegar um atalho (do A pro B), por que não fazê-lo? Você não deveria ser punido por encurtar o caminho. Um caminho maior (do A pro B e do B pro C) indica, consequentemente, maiores custos. É como se você fosse obrigado a planejar sua viagem para a praia, mas não poder mudar o caminho caso encontre um trajeto mais curto ou menos congestionado. Mudanças acontecem e elas são fatos da vida.

Preste atenção agora na mudança de mentalidade entre o planejamento tradicional e o Scrum. No tradicional você é guiado por um plano, fixa as funcionalidades (seu trajeto até a praia) e estima seu custo e o prazo. No Scrum, você pode até fixar seu custo e seu prazo, mas o projeto é dirigido a valor e as funcionalidades são estimadas (isso é, se eu encontrar um caminho mais curto que me ajude no meu objetivo, ótimo).

Mas afinal, quando é adequado usar Scrum?

Projetos de software geralmente se encaixam em quatro diferentes áreas: simples, complicado, complexo e anárquico. Projetos simples são fáceis de entender e implementar, são construídos em cima de coisas conhecidas. Se você está em qualquer área diferente da simples você terá mudanças no projeto. Nesses cenários, a adoção do Scrum é mais recomendada, pois a mudança é certa que virá.

Mudar é difícil

Normalmente se mede a mudança pelas funcionalidades que foram esquecidas quando se estava desenvolvendo um produto, uma change request, nesses casos, indica que falhamos de alguma forma. O que normalmente não se entende é que a mudança é inevitável. Não temos bola de cristal e não podemos prever o futuro. Qualquer pessoa que almeje o sucesso, deveria aprender a abraçar a mudança. A figura a seguir mostra como ocorre a variação da produtividade ao longo do tempo até o novo status quo. Uma percepção importante é que a mudança é um investimento de longo prazo, inicialmente, talvez se pode experimentar uma produtividade ainda pior do que a atual, devido a ruptura do estado de conforto, o chaos se instaura, pois as pessoas ainda não sabem trabalhar perfeitamente dentro da nova realidade. Mas o investimento se paga ao longo do tempo, pois o novo status quo levará a uma melhor situação que o status quo atual.

De acordo com a experiência do autor, a maioria das equipes que implementaram Scrum necessitaram de pelo menos três meses para aprender o básico e começar a implementar. Na média, sugere que se planeje de três a seis meses a gestão da mudança, dependendo do grupo ao qual será feita a transição.


Lean Analytics: Use Data to Build a Better Startup Faster

A análise de hoje é sobre mais este livro da série de Eric Ries, escrito por Alistair Croll e Benjamin Yoskovitz. No preâmbulo, Eric Ries lembra que desde os tempos de Taylor, nós avaliamos os skills dos gerentes comparando seus resultados com o que foi prometido. Se seguiu conforme o planejado, está promovido. Agora, se você está ocupado construindo o produto errado, porque você deveria estar orgulhoso em fazê-lo dentro do prazo e do orçamento? Está é a razão porque precisamos de um novo entendimento de como mensurar progresso.

Pare de mentir a si mesmo

Essa parte do livro trata sobre dados qualitativos e quantitativos, métricas de vaidade, correlação, coorte, segmentação e indicadores de condução. Afinal, instintos são experimentos, dados são provas. Vou falar sobre cada um deles mais adiante.

Nós todos somos mentirosos

Os autores lembram que seguir o modelo de Lean Startup entrega uma alta dose de honestidade, o que o torna muito difícil de mentir, especialmente para si mesmo, isso porque trata fundamentalmente de métricas acionáveis. Peter Drucker já dizia, “se você não pode medir, não pode gerenciar”.

Como se faz uma boa métrica?

Uma boa métrica é comparativa

É possível compará-la com outros períodos, grupos de usuários ou concorrentes.

Uma boa métrica é compreensível

Se as pessoas não conseguem lembra-la e discuti-la, será difícil transformar a mudança no dado dessa métrica em uma mudança na cultura. Em outras palavras, ela não servirá para nada.

Uma boa métrica é uma relação ou uma taxa

Há algumas razões de por que trabalhar com relações é melhor do que as taxas.

  • São fáceis para tomada de decisão: fazendo uma analogia com dirigir um carro. A distância percorrida é meramente informativa, mas a velocidade – distância por hora – é algo em que você pode agir, porque isso nos informa sobre o estado atual, e se você necessita ir mais rápido ou mais devagar para chegar ao destino dentro do tempo.
  • São comparativas por natureza: Voltando ao carro, a velocidade é uma métrica, mas a velocidade sobre a média de velocidade da última hora mostra se você está acelerando ou reduzindo a velocidade.
  • São boas para comparar fatores que são de alguma forma opostos: No carro, isso talvez seja a distância percorrida dividida pelo número de multas. Quanto mais rápido você dirigir, mais distância você irá percorrer, porém mais multas você irá levar. Essa proporção sugere a você a não ultrapassar o limite de velocidade.

Uma boa métrica muda a forma como você se comporta

Isso é de longe o mais importante critério para uma métrica. Ela muda a forma com que você se comporta porque está alinhada com os seus objetivos. Algo a se perceber é que as métricas frequentemente veem em pares. Taxa de conversão (conversion rate) está ligada com o tempo para efetuar a compra (time-to-purchase), juntas elas dizem muito sobre o fluxo de caixa, por exemplo.