Baixe o app para aproveitar ainda mais
Prévia do material em texto
Agile Toolkit Prof. Pedro Paulo Oliveira Propriedade Intelectual Saint Paul Educacional LTDA Visão do produto Ao definir a concepção de um produto, é importantíssimo que seja definida e divulgada a visão do produto. A seguir, entenderemos algumas práticas que o mercado utiliza para definir a visão de um produto. Elevator Pitch Elevator Pitch é uma espécie de diálogo breve e objetivo que um indivíduo utiliza para falar a respeito de um produto, serviço ou uma organização, demonstrando seus benefícios e valores, despertando o interesse do interlocutor. Para utilizar essa técnica basta preencher o template a seguir (Figura 1) para que a visão de um produto, por exemplo, seja comunicada. Figura 1: Template Elevator Pitch. Propriedade Intelectual Saint Paul Educacional LTDA Visão do produto Modelo Kano O modelo de Kano é uma técnica que busca a melhoria de processos, produtos ou serviços ou, até mesmo, a definição e concepção de um produto. O foco está no cliente, ou seja, o que o cliente precisa? O que ele deseja? A partir da distribuição dos itens que geram alta satisfação aos clientes/usuários, é possível, por exemplo, definir a visão de um produto. Figura 2: Modelo Kano. Propriedade Intelectual Saint Paul Educacional LTDA MVP (Minimum Viable Product) A ideia por trás do Minimum Viable Product (em português, Produto Minimamente Viável) é, como pode ser visto na Figura 3, desenvolver uma versão de teste do projeto, com o mínimo de investimento financeiro e de tempo, mas capaz de entregar os mesmos valores do produto finalizado. Dessa forma, a ideia pode ser testada e, se aprovada, toda a estrutura necessária para o desenvolvimento é aplicada. Visão do produto Figura 3: MVP (Paulo Caroli). Propriedade Intelectual Saint Paul Educacional LTDA Escrita de itens de Product Backlog A partir do momento que se tem definida a visão de um produto, times Ágeis geralmente iniciam a fase de definição de itens de Product Backlog (times Scrum). Um item de Product Backlog pode ser qualquer coisa que esteja em um Product Backlog. Como você já sabe, Product Backlog é uma lista priorizada de coisas a serem feitas para um produto, que pode ser histórias de usuário, caso de uso, funcionalidades, features, etc. História de usuário Histórias de usuário (user stories) descrevem seus requisitos de forma ágil. Para discutir seus detalhes, é necessária a comunicação face a face entre o time e o cliente, encorajando o trabalho em conjunto. Cada história segue um ciclo de vida, normalmente nascendo como um épico (histórias grandes), sendo detalhada de acordo com sua prioridade. Elas são textuais, não necessitam de ferramenta específica, são compreensíveis por todos do desenvolvimento ou do negócio e são descritas em cartões, também chamados de cartões de história (story card). Outras formas de documentação complementares podem ser utilizadas juntamente. O XP não impede isso desde que sejam úteis e necessárias, tais como protótipos ou diagramas. Alguns exemplos de histórias de usuário: “Como um contador, eu quero registrar uma movimentação de patrimônio”, “Como uma leitora, quero pesquisar livros por categoria”. Propriedade Intelectual Saint Paul Educacional LTDA Escrita de itens de Product Backlog 7 Dimensões do Produto Basicamente, esta técnica tem como objetivo facilitar o levantamento de informações fundamentais para a criação de um produto, analisando-o sob sete dimensões (aspectos) diferentes, a saber: Atores Interfaces Ações Dados Regra de negócio Ambiente Qualidade A seguir, vamos entender o que quer dizer cada uma dessas dimensões. Como exemplo, utilizamos a construção de um aplicativo móvel para ler um jornal digital. Atores (personas) são todos os usuários que, de alguma forma, interagem com o produto. Exemplo: leitores de jornal digital para tablets. Propriedade Intelectual Saint Paul Educacional LTDA Interfaces são todas as telas, os fluxos ou as aplicações que precisam ser construídas para atender a uma necessidade de negócio. Exemplo: interface contendo uma biblioteca atualizada com as edições de um jornal digital. Escrita de itens de Product Backlog Ações (verbos) são tudo o que os usuários desejam fazer ao interagir com a aplicação. Exemplo: comprar uma edição do jornal digital. Conforme Figura 4, note que, neste momento, já podemos dar forma a algumas user stories ou épicos. Por exemplo: Figura 4: User story Dados são qualquer input, arquivos, dados da base, entre outros, que são fundamentais para o funcionamento da aplicação. Exemplo: jornal digital (PDF, HTML). Propriedade Intelectual Saint Paul Educacional LTDA Escrita de itens de Product Backlog Regras de negócio servem para suportar as necessidades de negócio e devem ser implementadas na aplicação. Exemplo: as edições avulsas só poderão ser compradas via cartão de crédito. Ambiente é (ou são) todas as plataformas ou sistemas que serão utilizados para suportar a aplicação. Exemplo: aplicação WEB com suporte para flash. Qualidade é (ou são) todos os requisitos que precisam ser contemplados em uma aplicação para atender às necessidades dos usuários. Exemplo: a leitura do jornal poderá ser feita off-line. Propriedade Intelectual Saint Paul Educacional LTDA Mapeamento e priorização Story Mapping O Story Mapping, desenvolvido originalmente por Jeff Patton, é uma ferramenta poderosa para descobrir a solução certa para seus usuários e para evoluir à medida que se obtêm insights. É o processo de visualização do seu produto desde a visão inicial até as atividades dos key users e prováveis releases (Figura 5). Um Story Mapping proporciona um mapeamento multidimensional do seu produto, fornecendo uma estratégia de desenvolvimento para um aprendizado rápido. Figura 5: Story Mapping. Propriedade Intelectual Saint Paul Educacional LTDA Mapeamento e priorização Técnica MoSCoW A técnica MoSCoW é muito utilizada para priorização de escopo, priorização de requisitos, classificação de mudanças, etc. Aplicando essa técnica, consegue-se, por exemplo, classificar e priorizar funcionalidades com base no seu valor de negócio. Atualmente, o Dynamic Systems Development Method (DSDM) Consortium tem os direitos de propriedade intelectual da técnica MoSCoW, os quais foram doados pelo seu criador Dai Clegg. O M em MoSCoW quer dizer Must Have (Deve Ter), ou seja, tudo que é imprescindível para o produto. São aquelas funcionalidades fundamentais da sua aplicação, sem as quais a aplicação perderia totalmente o sentido. O S quer dizer Should Have (Deveria Ter), ou seja, tudo o que é importante ter no seu produto, mas que não é imprescindível. São funcionalidades que, se porventura não forem desenvolvidas, não farão com que o produto perca o seu valor de negócio. O C quer dizer Could Have (Poderia Ter), ou seja, tudo o que seria bom ter, mas não é importante. É mais ou menos como a cerejinha do bolo. Na maioria das vezes, clientes aceitam comer bolo sem cereja, até porque bolos sem cerejas são mais baratos. O W quer dizer Won’t Have for Now (Não Terá por Enquanto), ou seja, tudo o que não será desenvolvido por enquanto, pois as features classificadas com Won’t Have for Now não geram valor de negócio no momento. Propriedade Intelectual Saint Paul Educacional LTDA Estimativas e métricas Story Points Story Points são uma unidade de medida para expressar o tamanho geral de uma história do usuário, por exemplo. Quando estimamos com Story Points, atribuímos um valor em pontos para cada item (Figura 6). O valor bruto que atribuímos não é importante. O que importa são os valores relativos. Uma história que recebeu uma estimativa (tamanho) de dois pontos deve ter o dobro de estimativa de uma história que recebeu um ponto. O número de Story Points associados a uma história representa o seu tamanho. Figura 6: Story Points. Propriedade Intelectual Saint Paul Educacional LTDA Estimativas e métricas Planning Poker Planning Poker combina a opinião de especialistas e a analogia em uma abordagem agradávelpara estimar, a qual resulta em estimativas rápidas e confiáveis. Cada equipe pode estimar de forma independente. O Product Owner participa do Planning Poker, mas não estima. Logo no início, cada membro do time que irá desenvolver a história de usuário recebe um baralho de cartas, tendo cada carta os seguintes valores: 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100 (parecido com a escala de Fibonacci). Para cada história de usuário a ser estimada, um facilitador, que geralmente é o Product Owner, lê a descrição e explica o item para os membros do time. Após serem esclarecidas as dúvidas de negócio, cada membro apresenta sua carta com base no seu entendimento do tamanho da história. Se todos apresentarem cartas com valores similares − por exemplo, 8 −, a estimativa de tamanho fica em 8 pontos e o time passa para a próxima história de usuário. Caso haja divergência no entendimento, ou seja, um membro do time apresentou 13 e outro apresentou 2, é feita uma discussão para se chegar a um consenso de por que cada membro escolheu cada carta. A partir dessa discussão, é realizada uma nova rodada de estimativas até se chegar ao tamanho da história. Propriedade Intelectual Saint Paul Educacional LTDA Estimativas e métricas Velocity Velocidade é uma medida da taxa de progresso de uma equipe. É calculada somando a quantidade de Story Points atribuída a cada história de usuário que a equipe concluiu durante a iteração. Se a equipe completou três histórias, cada uma estimada em cinco pontos, então sua velocidade seria de 15 pontos. Se a equipe completou duas histórias de cinco pontos, sua velocidade seria de 10 pontos. Se uma equipe completou 10 pontos da história na última iteração, nosso melhor palpite é que eles completarão 10 pontos da história nesta iteração (empirismo). Como os pontos da história são estimativas de tamanho relativo, essa afirmação continua sendo verdade se eles entregam duas histórias de cinco pontos ou cinco histórias de dois pontos. Throughput Throughput é uma medida que determina quantos itens (história de usuário, por exemplo) foram entregues (prontas) em uma quantidade de tempo. Olhando pela perspectiva de vazão (ou saída), é possível afirmar que o Throughput é uma medida que determina o quanto determinado fluxo é capaz de processar. Propriedade Intelectual Saint Paul Educacional LTDA Estimativas e métricas Lead Time Para a indústria, Lead Time representa a latência entre a iniciação e a execução de um processo. No setor de bens industriais, a redução de tal métrica representa um aspecto-chave da manufatura enxuta (lean manufacturing). No contexto de desenvolvimento de software, pode-se considerar o Lead Time como o número de dias entre o início e o fim do processo de entrega de um item de trabalho (por exemplo, história do usuário, bugs, etc.). CFD (Cumulative Flow Diagram) CFD é um tipo de visualização que trata essencialmente de entradas e saídas. Como o próprio nome pode sugerir, o Cumulative Flow Diagram é uma excelente forma de compreender o fluxo de trabalho ao longo de um processo, afinal o gráfico pode nos dar um panorama geral do que está acontecendo durante o desenvolvimento de um projeto ou produto. O CFD é um instrumento de muito valor no processo de monitoramento em projetos ágeis, pois usando-o você poderá rapidamente analisar: quanto de trabalho foi realizado, quanto de trabalho está em progresso e quanto de trabalho ainda precisa ser feito. Propriedade Intelectual Saint Paul Educacional LTDA Referências bibliográficas Highsmith, Jim. 2004a. Agile Project Management:Creating Innovative Products. Addison-Wesley Professional. COHN, Mike. 2005. Agile Estimating and Planning. Prentice Hall PTR Johnson, Philip M., Carleton A. Moore, Joseph A. Dane, and Robert S. Brewer. 2000. Emprically Guided Software Effort Estimation. IEEE Software 17(6):51–56. Obrigado
Compartilhar