Especificação por exemplo

É um grande desafio fazer o produto certo da forma certa, pois fazer o produto certo da forma errada vai gerar valor com desperdícios ocultos, enquanto fazer da forma errada sem ser o produto certo não gera sequer valor. O segredo está no produto certo com a forma adequada às suas características e contexto, para isso é preciso distinguir entre domínio do problema e da solução:

  • O domínio do problema relaciona-se aos objetivos.
  • O domínio da solução esta relacionado ao escopo.

O que é o seu projeto? Qual é o problema, quais são os objetivos, a vida útil, estratégia, complexidade, time, tecnologia, custo, timing, … Fosse uma equação simples TODOS os projetos seriam ideais, tanto como produto quanto forma.

Desafio: Trabalhar de forma iterativo-incremental-articulada, usando de métodos ágeis para entregar valor e qualidade a cada sprint, senso de pertença, tanto no domínio do problema quanto da solução. É trabalho duro!

Especificação por exemplos: É a constituição de uma linguagem ubiqua e eficaz, com entendimento e construção de qualidade desde o início, praticada por todos. O maior benefício é uma documentação viva, acessível a todos.

Convergência: Iniciar pela compreensão do problema e objetivos pelos olhos do cliente, construir User Stories com critérios de aceitação usando BDD. Deixar o tecniquês e o laboratório é o cerne do Design Thinking, Agile, Lean Startup, …

Ponto de atenção: Cabe ao cliente demonstrar e explicar os problemas e objetivos, não a solução, pois cabe a equipe contribuir com seus conhecimentos, experiências e especialização, expôr alternativas e a melhor opção.

Imersão e colaboração: Colaboração desde a estratégia, planejamento tático e técnico, sempre iterativo-incremental, sempre com foco no valor e qualidade. É uma construção conjunta e dependente, na busca constante pelo equilíbrio.

Documentação: Um profundo e complexo detalhamento da especificação técnica pode ser um grande desperdício, não tanto pela confecção quanto pela sua utilidade futura. A especificação por exemplo detalha de forma, tão simples quanto possível, os testes de aceitação, funcionais. Linguagem ubiqua, critérios entendidos facilmente, tanto por clientes quanto por desenvolvedores.

Dicotomia: Em nenhum momento afirmei que não precisa documentação, a essência é que documentação boa é documentação útil, atualizada e confiável. Além das histórias do usuário, com seus critérios de aceitação, cada artefato adicional deve ser compatível a necessidades relativas a tecnologia utilizada, complexidade, exigências corporativas e bom senso.

US-BDD

Grooming: Assim como Schwaber explicou na técnica de grooming em equipes SCRUM, equipes que praticam especificação por exemplo podem dedicar até 10% de um sprint em reuniões dedicadas a refinar as histórias sendo detalhadas para o sprint seguinte. Uma especificação colaborativa, por exemplos, amplia o entendimento e protagonismo de todos, gerando senso de pertença.

Histórico: Entre os precursores estão Ward Cunningham e Martin Fowler, dois signatários do manifesto ágil para desenvolvimento de software de 2001. Fowler foi quem cunhou o nome “especificação por exemplos”.

Automação: O conceito SBE também é conhecido como ATDD (acceptance test driven development), STDD (specification test driven development) e BDD (Behaviour Driven Development) e dentre as implementações em software para a automação tem-se algumas como Cucumber, JBehave, Specflow, Specs2, … A imagem a seguir é uma tradução da extraída do livro SBE de Gojko Adzic:

SBE
No pré-game temos dinâmicas para entendimento, sempre voltadas a entender os problemas, desafios e objetivos de negócio – entrevistas e pesquisas, também Lean Canvas, Business Model, Value Proposition Canvas e Journey Maps.

Fechando o pré-game podemos ter um User Story Mapping ou técnica análoga para o mapeamento de releases, sprints, MVP, de forma a termos na visão e linguagem do cliente e usuários, quais os desejos, riscos e oportunidades.

A partir do próprio User Story Mapping, começando a ilustrar com exemplos, juntos, clientes, equipe, stakeholders, para na sequência entrarmos no game, com sprints sucessivas, com BDD compondo o refino, incorporado ao DoR.

Daí em diante, a habilidade de especificar por exemplos e construir especificação executável, manualmente ou utilizando uma ferramenta como o JBehave para automatizar este processo, permitindo testes de aceitação e funcionais, validando com frequência e mantendo uma documentação viva e sempre atualizada.

feedback-cycle1

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s