Adapte o processo como um grande chef de cozinha!… WTF!?!?!?

Olá,

Sim, você não leu errado no título do post, é chef de cozinha mesmo, mas eu explico.

Para quem me conhece pessoalmente vai pensar “Mas é claro que ele tinha que falar de comida, mas o que isso tem a ver com métodos ágeis?”

Bom, eu gosto de cozinhar, ou ao menos tentar, nunca matei ninguém até hoje ou mandei para o hospital. Mas para todos aqueles que gostam de cozinhar, acredito que o começo de “carreira” de chef amador é basicamente o mesmo. Pegamos uma receita que gostamos, que seja fácil de fazer, compramos os ingredientes, expulsamos todo mundo da cozinha e mãos à obra. Com um pouco de sorte insistência conseguimos sair com algo razoavelmente decente da cozinha.

Na parte do “mãos à obra” seguimos a receita em todos os seus pontos e vírgulas, se tivermos um termometro digital a gente usaria para verificar se a temperatura do formo está exatamente igual a mencionada, precisão britânica nas gramas de farinha, no tamanho da colher de chá de fermento, enfim, queremos fazer tudo perfeito para que a receita saia um sucesso.

Depois de um tempo fazendo receitas, começamos a ter a necessidade de adaptar elas, deixar elas com a nossa cara, usar ingredientes que gostamos mais do que outros. E é aí que entra o grande truque, o mesmo truque que devemos usar quando adaptamos um processo de desenvolvimento de sistemas para a nossa equipe/projeto/empresa. Modifique, adapte, mas sempre tenha claro quais são essas modificações e seus porquês, e nunca perca de vista o objetivo final.

Quando estou fazendo uma receita de bolo de cenoura, posso modifica-la para usar farinha de trigo integral no lugar da branca, ou fazer a cobertura com chocolate amargo no lugar de achocolatado, mas o resultado final ainda tem que ser um bolo de cenoura, não posso modificar a receita e esperar que saia um frango assado no final.

Grandes chefs de cozinha conseguem adaptar receitas para os ingredientes que eles tem a disposição, sem perder as características principais do prato. Quando modificamos o Scrum, por exemplo, não podemos nos esquecer dos objetivos dele, e quando o modificamos, temos que saber o porque dessas modificações, precisamos lembrar que, assim como em uma receita, essas modificações podem nos obrigar a alterar outras coisas que não foram previstas.

Mas mantendo nosso foco no objetivo final, com a experiência adquirida, vai ficando mais fácil ver onde e como devemos modificar as coisas. Começamos a fazer essas modificações de maneira mais instintiva, assim como os chefs modificam suas receitas. Aprenda novas técnicas e misture-as com as que você já conhece, sem se preocupar com os nomes, um ótimo exemplo disso é o post do Rafael sobre FDD, User Stories e Boards na Engenharia de Requisitos, e use-as com sabedoria nas suas adaptações.

Mas lembrem-se, no final, uma receita de bolo de cenoura não pode terminar como um frango assado…

Gordon Ramsay

Anúncios

FDD, User Stories e Boards na Engenharia de Requisitos

Olá caros, tudo bom?

Hoje vou falar sobre junções de técnicas de diferentes métodos que auxiliam na Engenharia de Requisitos. Venho usando essa junção há algum tempo e obtendo bons resultados.

Vamos começar por FDD.

Feature Driven Development é uma metodologia ágil criada por Peter Coad e Jeff de Luca em 1997, utilizada em um projeto de um grande banco em Singapura.

O FDD oferece uma estrutura interessante:

  • DMA (Desenvolver um Modelo Abrangente): Análise Orientada por Objetos
  • CLF (Construir a Lista de Funcionalidades): Decomposição Funcional
  • PPF (Planejar por Funcionalidade): Planejamento Incremental
  • DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos
  • CPF (Construir por Funcionalidade): Programação e Teste Orientados por Objetos

No passo CLF, eu uso a estratégia criada do modelo ARO para escrever nos Products Backlogs. Vamos conhecer mais sobre o modelo:

<ação> <resultado> <objeto>

Exemplos:

  • <calcular> o <total> de uma <venda>
  • <calcular> a <quantidade total vendida por um varejista> para uma <descrição de produto>.

As funcionalidades são granulares, de acordo com a regra de que uma funcionalidade não levará mais do que duas semanas para ser completada, mas não tão granulares ao nível de “getters” e “setters” (os métodos de acesso aos atributos de uma classe). Duas semanas são um limite superior; a maioria das funcionalidades levam muito menos tempo do que isso. Quando um passo de uma atividade de negócio parece maior do que duas semanas, o passo é quebrado em passos menores, que então tornam-se funcionalidades. by Heptagon

Nos últimos projetos que atuei, construi meu Product Backlog, escrevendo as funcionalidades seguindo a descrição ARO. Interessante informar que, descrevendo deste modo, a percepção inicial sobre a funcionalidade é mais fácil de ser “sacada” pelo Time e também mais fácil de ser descrita pelo P.O (ou o Time do P.O).

Tendo como base que o Product Backlog é uma lista de desejos, acho interessante escrever o desejo no modelo ARO. Quando faço entrevistas com os clientes e usuários, vejo que eles tem uma visão interessante do objetivo que desejam alcançar. O que faço é quebrar estes objetivos em ações menores, e vai ficando fácil enquadar isto numa descrição no modelo ARO.

Em projetos que necessitam de um Pré Planning/Pré Game, popular o Product Backlog desta maneira é interessante pois facilita na explicação para o Time e ajuda-os a estimar. Pensando em Agile, não devemos nos alongar em coisas que não serão feitas agora (foco no ROI). Usando o modelo ARO para compor a lista inicial do Product Backlog ajuda, pois não necessita da mesma profundidade de análise e tempo que uma User Story.

O modelo ARO se mostra indiferente ao tamanho. Você pode usa-lo para descrever Funcionalidades menores (inferiores a duas semanas) ou Épicos. Os exemplos abaixo ilustram isso:

  • calcular o total de uma venda
  • calcular a quantidade total vendida por um varejista para uma descrição de produto.

O primeiro exemplo cai bem num Épico, pois é mais vago, está mais aberto para discussão e entendimento. O segundo exemplo cai bem para uma funcionalidade que está em vias de entrar em uma Sprint, pois já define um papel interessado, um cálculo definido e um objeto mais conciso.

Do FDD, eu também gosto de usar a Feature Breakdown Structure. A FBS é um modelo de estruturação de funcionalidades, igual a WBS.

A FBS é uma forma visual e interessante de modelar suas funcionalidades de acordo com a Modelagem de Negócios do Produto/Empresa.

A utilização dos conceitos de Funcionalidade do FDD e a FBS são de grande ajuda para fases iniciais do Projeto e para auxiliar em estimativas.

Para saber mais, dou a dica de dois posts: Um da VersionOne explicando mais sobre a FBS e estimativas e outro da Flylib explicando mais sobre uma fase de Pré Game, utilizando FBS e Funcionalidades.

Para o topo do Backlog, eu geralmente quebro as Funcionalidades, usando o modelo de User Stories:

As a [type of user]

I want to [perform some task]

so that I can [reach some goal]

Isso me facilita muito evoluir no entendimento da funcionalidade, reconhecer os reais usuários, as necessidades e o valor de negócio de uma User Story. Mantendo o padrão Agile, geralmente eu crio as User Stories apenas quando necessário. Em alguns projetos isto quis dizer:

  • No decorrer da Sprint
  • Uma Sprint de antecedência
  • Duas Sprints de antecedência

E vou atualizando minha FBS:

Pra quem utiliza Story Mapping, a FBS é uma mão na massa. Você pode montar suas Releases, Sprints, pinçar as funcionalidades e User Stories necessárias para atingir os objetivos e exibi-las no Map:

by Agile Product Design 

Pra quem usa Boards (ou mesmo o Método Kanban), pinçar as Funcionalidades e/ou as User Stories fica bem interessante, exibindo a decomposição, o avanço do entendimento e a evolução do desenvolvimento.

Eu submeti uma proposta de palestra sobre este tema para o Agile Brazil, vou torcer para entrar.

E você, o que acha desta miscelânia?