Tag: agile

Quando usar o Domain-Driven Design (DDD)

DomainDrivenDesign

Domain-Driven Design ou Projeto Orientado ao Domínio é um padrão de modelagem de software orientado a objetos que procura reforçar conceitos e boas práticas relacionadas à Orientação a Objetos.

Isso vem em contrapartida ao uso comum do Data-Driven Design ou Projeto Orientado a Dados, que a maioria dos desenvolvedores usa sem mesmo ter consciência disso.

Data-Driven Design

Já ouvi várias vezes que os dados são a coisa mais importante em uma empresa, logo a modelagem deve sempre começar pensando-se no banco de dados. Esta é a abordagem algumas vezes chamada de database first, ou “banco de dados em primeiro lugar”.

Não é nada incomum desenvolvedores .Net, Java e C++ começarem um sistema estabelecendo os tipos que eles vão usar e o relacionamento entre eles, como se estivessem criando um Modelo Entidade-Relacionamento (MER). Esses tipos geralmente são objetos “burros”, com getters e setters, representando nada mais, nada menos, que uma tabela do banco de dados.

O problema com essa abordagem é que ela não faz bom uso dos recursos da Orientação a Objetos. Muitos acham que getters e setters são o auge do encapsulamento, mas na prática esses métodos permitem ao usuário recuperar e alterar todos os atributos. Não há ganho algum, a não ser muito código desnecessário.

Enfim, muita gente acha que está usando OO, mas as classes poderiam ser facilmente substituídas por registros ou estruturas de dados mais simples, de acordo com a linguagem utilizada.

Se você consegue ler em Inglês, uma discussão interessante sobre isso está no artigo Dance you Imps!, escrito por Rebert Martin e também conhecido como Uncle Bob.

Domain-Driven Design (DDD)

A ideia inicial do DDD é voltar à uma modelagem OO mais pura, por assim dizer.

Devemos esquecer de como os dados são persistidos e nos preocupar em como representar melhor as necessidades de negócio em classes e comportamentos (métodos). Esta é uma abordam também conhecida como como code first, ou “código em primeiro lugar”.

Isso significa que em DDD um Cliente pode não ter um setter para os seus atributos comuns, mas pode ter métodos com lógica de negócio que neste domínio de negócio pertencem ao cliente, como void associarNovoCartao(Cartao) ou Conta recuperarInformacoesConta().

Em resumo, as classes modeladas e os seus métodos deveriam representar o negócio da empresa, usando inclusive a mesma nomenclatura. A persistência dos dados é colocada em segundo plano, sendo apenas uma camada complementar.

Quando não usar DDD

Às vezes só é necessário um CRUD

DDD não é uma solução para tudo. A maioria dos sistemas possui uma boa parte composta por cadastros básicos (CRUD) e pelo menos nessa parte não há necessidade de um modelo elaborado de dados.

O DDD deve ajudar na modelagem das classes mais importantes e mais centrais do sistema de forma e diminuir a complexidade e ajudar na manutenção das mesmas, afinal este é o objetivo dos princípios de orientação a objetos.

Compartilhando dados com outros sistemas

Rotinas de integração que recebem ou disponibilizam dados para outros sistemas não devem ser “inteligentes”.

Muitos desenvolvedores acabam modelando suas classes de negócios tentando resolver as questões internas do sistema e, ao mesmo tempo, pensando em como essas classes serão expostas para outros sistemas.

Padrões como DTO (Data Transfer Object) que usam objetos “burros” são mais adequados para isso.

Considerações finais

O DDD não tenta resolver todos os problemas de todas as camadas de um sistema.

Seu foco é na modelagem das entidades principais de negócio usando a linguagem adequada daquele domínio para facilitar a manutenção, extensão e entendimento.

Particularmente, eu não seguiria à risca o padrão, até porque existem inúmeros padrões e variações de modelagem OO.

Porém, é sempre importante estudar e entender os princípios por detrás desses padrões para, dessa forma, aplicar o que funciona melhor para cada situação.

Referências

  1. DDD – Introdução a Domain Driven Design
  2. Coding for Domain-Driven Design: Tips for Data-Focused Devs
  3. Domain Driven Design Quickly (e-book gratuito)

Nota: escrevi termos como domain-driven com hífen, pois quando duas ou mais palavras formam um adjetivo composto no Inglês elas geralmente devem ser “ligadas”. No caso, domain-driven é um adjetivo de design. (Referência)

Pensando TDD

Ontem, dia 8 de outubro de 2014, ministrei uma palestra sobre TDD na Faculdade de Tecnologia de Sorocaba, durante a 21ª edição da Semana de Tecnologia, evento anual promovido pela faculdade para aproximar os alunos das práticas mais modernas do mercado.

TDD or not TDD?

Test-Driven Development (Desenvolvimento Orientado a Testes), ou simplesmente TDD, é uma disciplina de desenvolvimento ágil que, resumidamente, prioriza testes automatizados ainda na fase de projeto com o objetivo de obter software de qualidade, isto é, com código limpo e que funcione.

Indo direto ao ponto, TDD não é sobre TDD, mas sobre a disciplina e prática de como torna-se um bom Engenheiro ou Artesão de Software, dependendo da metáfora que você adota.

Embora esse assunto não seja novidade, é de muita importância para a maior parte dos profissionais de TI brasileiros, sem contar as empresas, pois infelizmente estamos de forma geral muito defasados com as melhores práticas reconhecidas no restante do mundo.

Veja, a redescoberta do TDD já tem mais de uma década e a maioria dos profissionais que encontro nunca viu um projeto que realmente aplicasse a metodologia. E o problema não é somente com relação ao TDD. Parece que somente agora empresas estão começando a aceitar certas práticas geralmente adotadas por processos ágeis, tais como testes automatizados, integração contínua, reuniões diárias, programação em par, etc.

A palestra, intitulada “Pensando TDD”, também não é necessariamente sobre TDD, mas sobre a necessidade de praticarmos o desenvolvimento de software como uma disciplina diária e não com a “lei do mínimo esforço” que, com o tempo, gera um déficit técnico tão grande que não resta alternativa a não ser literalmente jogar o software no lixo.

Material

Os slides da apresentação estão disponíveis no SlideShare e no Google Drive. Muitos deles são conceituais. Para ver comentários e informações adicionais sobre cada um, use a função de notas do SlideShare ou baixe o PPT.

Lembrando que a licença dos documentos que tenho produzido é Creative Commons. Você é livre para usar e modificar o material livremente. Só peço que cite a fonte original (meu blog, por exemplo).

Se tiver dúvidas sobre algum ponto, escreve para mim.

Agradecimentos

Por fim, gostaria de agradecer à organização do evento e à diretoria da Fatec de Sorocaba, assim como à GFT, empresa onde trabalho, por incentivar a participação em eventos e comunidades de tecnologia.

Obrigado também a todos os alunos que se mostraram muito receptivos a novos conhecimentos e suportaram a hora e meia comigo falando. Sucesso para todos vocês!

Noções sobre Processos de Desenvolvimento de Software

Este artigo é o Capítulo III da minha monografia de Especialização em Engenharia de Software. Embora seja um referencial teórico e não acrescente nada de novo, espero que o possa ser útil de alguma forma para o leitor.

Introdução

Um sistema de software é construído através de um processo de desenvolvimento, seja ele formal ou empírico. Diversos modelos de processos surgiram ao longo do tempo, dentro os quais os principais são apresentados neste capítulo.

Ao adotar processos formais e reconhecidos aproveita-se o conhecimento e a experiência dos especialistas que os criaram. Isso inclui boas práticas, listas de verificação, atividades pré-definidas, entre outros. Existe o risco de usar indevidamente o processo, executando todas as atividades propostas sem a devida reflexão, desperdiçando tempo com o que não é importante e gerando uma falsa segurança baseada apenas no fato de se usar um processo conhecido.

Por outro lado, um processo empírico depende da experiência, habilidade e conhecimento da equipe. Profissionais experientes e maduros obtêm vantagens com a liberdade desse tipo de processo porque eles já adotam boas práticas de desenvolvimento, sabem quais atividades são necessárias para completar suas tarefas e sabem como prevenir e resolver problemas.

Existem também processos de gerência utilizados durante o desenvolvimento de software. Alguns foram criados especificamente para projeto de software e outros adaptados de modelos de gerência de projetos. Alguns modelos de desenvolvimento incluem elementos de gerenciamento e vice-versa. Em decorrência disso, podem existir lacunas num projeto que executa um processo incompleto Algumas organizações adotam processos complementares, de forma a preencher essas lacunas.

Definição de modelo de processo e processo de software

Um modelo de processo é uma abstração de um processo (Sommerville, 2003, p. 36). Esses modelos representam as abordagens utilizadas no desenvolvimento de software dentro das organizações. Com base nesses modelos, diversos processos foram propostos para o desenvolvimento de software com a finalidade de se construir um produto melhor, de menor custo e mais rapidamente.

Um processo de desenvolvimento de software consiste num conjunto de atividades e resultados associados que geram um software (Sommerville, 2003, p. 7). Em geral, os processos de desenvolvimento têm como foco os aspectos técnicos, como especificação, desenvolvimento, validação e evolução do software e devem prover transparência e flexibilidade para facilitar o gerenciamento do projeto.

O processo adotado por uma organização também é uma abstração em relação ao processo executado num determinado projeto. Em geral, o processo da organização é adaptado de acordo com as necessidades específicas do projeto.

Importância do gerenciamento de projetos

Existe a necessidade de gerenciar o processo de desenvolvimento de software através de modelos, processos, atividades e ferramentas específicos. O desenvolvimento de um software ganha sentido no contexto de um negócio e de uma organização. É importante alinhar os requisitos de negócio com o produto de software e gerenciar as atividades de desenvolvimento, verificando prazo, custo e qualidade para que o projeto não termine em fracasso do ponto de vista do negócio (Sommerville, 2003, p. 60).

Os processos de desenvolvimento podem incluir atividades de gerenciamento, tal como o Processo Unificado (Rational, 2001), mas existem modelos e processos específicos para gerenciamento de projetos. É possível adotar uma combinação de processos complementares de acordo com as necessidades do projeto e da organização.

A estimação de software é importante para o gerenciamento de um projeto. Decisões como o cancelamento de um projeto podem ser tomadas com base em estimativas de custo e prazo necessários para desenvolver um determinado sistema de software. Estimativas adequadas resultam em decisões gerenciais acertadas, enquanto estimativas irreais causam prejuízo.

Além disso, dados do esforço real comparado com o esforço estimado fornecem uma importante ferramenta para ajuste das estimativas do projeto corrente e nos projetos futuros. A experiência e os dados agregados através desta comparação permitem estimar as atividades futuras com maior acurácia e atuar mitigando riscos de descumprimento de prazos acordados. Para isso, o gerente deve possuir os registros organizados das atividades concluídas.

Classificação dos modelos em relação à burocracia e à iteratividade

A estimação deve considerar o quanto o processo onera as atividades de desenvolvimento. Quanto mais atividades extras, documentação e rigor forem exigidos, maior será o fator de ajuste necessário para as estimativas.

Este estudo considera modelos mais burocráticos e com maior rigor como modelos tradicionais. Modelos com pouca burocracia, também chamados de empíricos, incluem os modelos de processos ágeis.

Kroll (2006) classifica alguns modelos num gráficos cujo eixo horizontal é o grau de disciplina adotado e o eixo vertical o nível de iteratividade. Na Figura 2, o autor posiciona o modelo de maturidade de processo CMM com grau elevado de burocracia e baixa iteratividade, enquanto os modelos ágeis com pouca burocracia e alta iteratividade. O CMMI, uma evolução do CMM, é mais iterativo e menos burocrático. Já os processos ágeis são bastante iterativos e muito pouco burocráticos.

Figura 2 – Grau de burocracia de processos tradicionais (Kroll, 2006, p. 36).

]1 Figura 2 – Grau de burocracia de processos tradicionais (Kroll, 2006, p. 36).

A Figura 3 apresenta a mesma ideia, incluindo agora o Processo Unificado. Devido a suas características de adaptação, o Processo Unificado abrange uma grande faixa do gráfico. Dependendo do projeto, ele pode ser adaptado para ser mais ou menos iterativo e disciplinado.

Figura 3 – Grau de burocracia dos processos ágeis (Kroll, 2006, p. 45).

]2 Figura 3 – Grau de burocracia dos processos ágeis (Kroll, 2006, p. 45).

Modelos de desenvolvimento e gerenciamento de software

Os modelos de desenvolvimento de software são abstrações das abordagens de desenvolvimento utilizadas nas organizações. Eles podem ser aplicados em diferentes processos individualmente, combinados e com variações.

Os modelos afetam diretamente a forma como o projeto é gerenciado. Os modelos iterativos, por exemplo, definem que haverá atividades de planejamento em cada iteração ao longo do desenvolvimento.

A compreensão dos princípios, benefícios e desvantagens desses modelos auxilia no desenvolvimento e na estimação de um software ao fornecer uma visão geral da abordagem utilizada no projeto.

Modelos incrementais

Os modelos incrementais englobam os modelos de desenvolvimento cuja constituição é de pequenos ciclos de desenvolvimento realizados de forma iterativa, ou seja, a cada ciclo novos incrementos são adicionados no software (Pressman, 2006, p. 40), que ganha funcionalidades no decorrer do projeto. Em cada iteração é produzida uma versão parcial funcional do software.

Este modelo possui vantagens em relação a um modelo sequencial de desenvolvimento. Os incrementos podem ser planejados para gerir os riscos técnicos, uma boa prática adotada por processos modernos (Campos, 2009). Ele também absorve melhor as mudanças nos requisitos, principalmente quando alguns deles ainda não foram claramente entendidos.

Dependendo das funcionalidades a serem desenvolvidas em cada incremento, atividades de gerenciamento devem realizar o respectivo planejamento, estimação e negociação dos requisitos para cada iteração.

Entretanto, o modelo incremental possui alguns problemas. Algumas funcionalidades dependem de outras, podendo ser interdependentes, por isso pode haver bloqueios no desenvolvimento. Além disso, alterações em requisitos já desenvolvidos invalidam o cronograma e as estimativas.

Modelos evolucionários

Nos modelos evolucionários o software é ajustado, melhorado e agrega novas funcionalidades, tornando-se mais completo, a cada ciclo de desenvolvimento (Pressman, 2006, p. 42). Sistemas de software precisam se adaptar com o passar do tempo. Não há como forçar um desenvolvimento linear até o produto final. A evolução gradual do produto é uma abordagem para solucionar esse problema.

Estes modelos também são iterativos, porém diferem dos modelos incrementais porque acomodam melhor situações onde apenas os requisitos básicos são entendidos, mas os detalhes somente serão conhecidos posteriormente.

Entretanto, nos modelos evolucionários é difícil estimar e planejar a quantidade de iterações necessárias para construir o produto completo, pois a maioria das técnicas de gestão e estimativa de projeto é baseada na disposição linear das atividades (Pressman, 2006, p.47).

A estimação e o planejamento em projetos que adotam o modelo evolucionário devem ser constantemente revisados na medida em que mudanças nos requisitos são detectadas. Na medida em que o projeto evolui, se houver gerenciamento adequado, os ajustes nas estimativas e o replanejamento provavelmente irão convergir para resultados mais próximos da realidade.

Modelos ágeis

O “Manifesto para o Desenvolvimento Ágil de Software” (Agile Manifesto, 2009), assinado no ano de 2001 por alguns proeminentes desenvolvedores de software, deu início um movimento emergente que busca formas de desenvolvimento de software mais ágeis. Este documento enfatiza alguns princípios já conhecidos com o objetivo de superar os desafios modernos do desenvolvimento de software (Pressman, 2006, p. 58).

Os princípios fundamentais dos modelos ágeis são:

  • indivíduos e interações em vez de processos e ferramentas;
  • softwares funcionando em vez de documentação abrangente;
  • colaboração do cliente ao invés de negociação de contratos;
  • resposta a modificações em vez de seguir um plano.

Os modelos ágeis procuram estabelecer apenas um conjunto mínimo de organização e disciplina, deixando as demais decisões a cargo da equipe. Há uma suposição de que uma equipe com experiência e diversidade de conhecimentos saberia como coordenar o seu trabalho e se auto-organizar, portanto qualquer tipo de burocracia inibiria a plena capacidade dos indivíduos. Os “agilistas” também defendem a tese que não basta apenas incluir alguns ajustes e boas práticas nos modelos tradicionais, é preciso livrar-se da “roupagem velha”.

O objetivo dos modelos ágeis em geral não é solucionar definitivamente os desafios da Engenharia de Software, mas prover o ambiente mais adequado para o desenvolvimento de software.

Além disso, os defensores e praticantes dos modelos ágeis, chamados “agilistas”, defendem a ideia de que os processos ágeis são os mais adequados para responder às altas taxas de mudanças de requisitos decorrentes da dinâmica dos negócios da atualidade.

Em contrapartida a todos os benefícios dos modelos ágeis, a correta aplicação dos diversos processos ágeis necessita de uma equipe experiente e de indivíduos capacitados e motivados. Além disso, projetos de softwares com alto grau de complexidade exigirão documentação detalhada. Tanto o cliente como os engenheiros de software podem criar barreiras técnicas e pessoais para aceitar o modo de trabalho estabelecido por alguns processos ágeis. Problemas nestes e em outros aspectos podem levar o projeto ao fracasso.

Os modelos ágeis enfatizam que a estimação das histórias de usuário e respectivas tarefas deve ser feita pela equipe de desenvolvimento, pois quem efetivamente executa o trabalho seria mais capacitado a estimá-lo do que pessoas que podem nem estar envolvidas com o projeto. Porém, delegar essa função exigirá organização, experiência e habilidade por parte da equipe. Além disso, os próprios agilistas reconhecem o fato de que desenvolvedores tendem a gerar estimativas otimistas, sendo necessário ao gerente ajustá-las posteriormente (Astels, 2002, p.70).

Em geral, adotar um modelo ágil não implica em restrições quanto à técnica de estimação, desde que a mesma atenda os princípios ágeis. Contudo, técnicas que envolvam a equipe como um todo e enfatizem a comunicação, tal como o Planning Poker (ver capítulo IV), são mais recomendadas.

Modelagem ágil

A modelagem ágil consiste em um conjunto de princípios consistentes com a filosofia dos modelos ágeis de desenvolvimento. Ela não é uma técnica ou método em si, mas estabelece uma filosofia para nortear a modelagem do sistema de software.

Adotar um processo ágil não significa que não haverá documentação, mas que esta deve ser produzida de acordo com os princípios ágeis de desenvolvimento. Ambler (2002) apresenta alguns princípios da modelagem ágil na tabela abaixo.

Tabela 1 – Princípios da Modelagem Ágil (Ambler, 2002)

Modelar com uma finalidade Somente criar diagramas, documentação e especificações se houver uma meta específica para isso.
Usar modelos múltiplos Escolher algumas das múltiplas formas de modelagem existentes que sejam necessárias e representativas.
Conservar apenas o que for necessário Atualizar os modelos no decorrer do projeto conforme as mudanças nos requisitos gera um trabalho considerável, então somente o que for realmente relevante deve ser conservado.
O conteúdo é mais importante que a representação A preocupação deve ser em transmitir a ideia e não com os formalismos de um modelo, isto é, as informações contidas nos artefatos devem ser apenas as suficientes para a situação atual.
Conhecer os modelos e ferramentas Saber como usar corretamente os modelos e ferramentas ajuda na decisão da forma como modelar um problema. Os diversos diagramas possuem características e limitações que são descartados conforme o uso.
Adaptar localmente A modelagem deve ser adaptada às necessidades do projeto e da equipe.

É possível aplicar esses princípios em qualquer modelo de desenvolvimento, mas uma contribuição que os processos ágeis trouxeram foi a ênfase em deixar de usar o “processo pelo processo”, ou seja, usar o processo apenas como um meio para atingir os objetivos da organização e não como um fim em si.

Prototipagem

A prototipagem é uma técnica que pode ser aplicada em modelos iterativos. Ela consiste em produzir uma iteração inicial do software baseada em requisitos de alto nível a fim de testar a viabilidade do projeto e a satisfação do cliente (Pressman, 2006, p. 42). Ela também serve como um mecanismo para identificação dos requisitos, pois permite uma verificação antecipada do que está sendo produzido.

Tudo o que foi produzido deveria ser descartado, pois a construção inicial rápida é geralmente desorganizada e sem qualidade. O custo de corrigir as funcionalidades e a arquitetura de um protótipo pode superar um novo desenvolvimento. A linguagem de programação e as ferramentas de prototipagem podem não ser ideais para o ambiente de produção. Entretanto, a perda pode ser minimizada incluindo o descarte no planejamento.

Existem riscos nesta abordagem. O cliente pode não entender que o protótipo deve ser descartado. Além disso, partes do sistema construídas de forma ineficiente podem permanecer no produto final.

A prototipagem aumenta a qualidade das estimativas quando ela atinge o objetivo de esclarecer os requisitos. Esta técnica é importante quando o domínio é complexo ou há dificuldades de comunicação com os usuários.

Processos de desenvolvimento de software

Modelo Waterfall

O modelo Waterfall é um modelo sequencial (ver Figura 4) de desenvolvimento que, em tese, funcionaria bem quando os requisitos fossem bem conhecidos e poucas mudanças fossem esperadas.

Figura 4 - Adaptado de Pressman (2006, p. 39).

]3 Figura 4 – Adaptado de Pressman (2006, p. 39).

Esse modelo é criticado por apresentar alguns problemas (Pressman, 2006, p. 39). Primeiramente, projetos reais raramente são sequenciais. Ajustes realizados gerariam um tipo de iteração confusa em meio às fases do modelo. Além disso, os requisitos definidos com antecedência sofrerão mudanças difíceis de absorver. Por último, o cliente somente recebe algo executável ao fim do ciclo. Pressman cita o trabalho de Bradac, que verificou que a linearidade deste modelo leva a bloqueios frequentes, ou seja, todos os participantes do projeto precisam esperar todos os demais completarem a fase atual antes de iniciar a próxima fase.

O gerenciamento de um projeto com o modelo Waterfall é mais difícil que em outros modelos. Como o planejamento, que inclui a estimação, é realizada apenas no início, não há muitos pontos de verificação e ajuste. O ajuste das estimativas exigiria atividades de planejamento durante o projeto, o que não é previsto no modelo.

Modelo Spiral

O modelo Spiral é um modelo orientado a riscos cujas iterações iniciais consistem em modelos de papel ou protótipos do software (Pressman, 2006, p. 44). Nas iterações posteriores são produzidas versões do sistema cada vez com mais funcionalidades. Um replanejamento é realizado a cada iteração levando em conta o retorno obtido do cliente.

Esse modelo é um dos mais adaptáveis e gerenciáveis, pois permite absorver com mais facilidade as mudanças nos requisitos de software ao longo do tempo devido à sua natureza iterativa e incremental. Além disso, as iterações podem ser estendidas além da entrega do produto final, incluindo novas versões do produto, finalizando apenas quando o produto for retirado de uso.

Processo Unificado

Segundo Kroll (2003, p. 32), o Processo Unificado é uma abordagem iterativa, centrada na arquitetura e dirigida por casos de uso. Este processo de gerenciamento e desenvolvimento de software foi uma tentativa de combinar as melhores características dos modelos de desenvolvimento (Pressman, 2006, p. 51).

O Processo Unificado enfatiza boas práticas de desenvolvimento (Kroll, 2003, p. 151), o que pode aumentar a qualidade das estimativas. Mitigar os riscos arquiteturais considerados mais impactantes o mais cedo possível através de provas de conceito, por exemplo, ajuda na compreensão do tamanho real do problema. Dessa forma, evita-se a falsa impressão do bom andamento do projeto enquanto os maiores desafios são deixados por último, os quais provavelmente irão invalidar qualquer estimativa. Além disso, se os riscos forem difíceis de superar, o custo de cancelamento do projeto não é tão grande como em fases mais avançadas.

Na verdade, esse processo funciona como um framework que permite a composição de processos específicos. Ele define um conjunto de atividades e produtos de trabalho que podem ser incluídos no processo de uma organização, de acordo com suas necessidades e de seus projetos. As atividades e os produtos de trabalho podem variar em quantidade, tamanho e detalhamento conforme o nível de gerenciamento desejado, além de outros fatores. O grau de burocracia pode ser ajustado de acordo com as necessidades do projeto.

O Processo Unificado pode ser adotado em pequenos e grandes projetos. Kroll (2003, p. 88) descreve aplicações do processo em projeto de apenas uma pessoa até projetos distribuídos com centenas de desenvolvedores, sendo o nível de burocracia em cada tipo de projeto compatível com a necessidade.

Extreme Programming

Beck (1999) publicou um trabalho que deu origem ao Extreme Programming (XP), um processo que utiliza uma abordagem de desenvolvimento orientada a objetos, iterativa e incremental (Novak, 2002). Ele é composto algumas fases que ocorrem a cada iteração (Pressman, 2006, p. 63).

Figura 5 - Adaptado de Presman (2006, p. 64)

]4 Figura 5 – Adaptado de Presman (2006, p. 64)

Na fase de planejamento cria-se um conjunto de histórias escritas pelo cliente em cartões de indexação, incluindo um valor associado ao negócio. O custo de cada história é definido com base nas avaliações dos desenvolvedores, conforme os princípios do modelo ágil. Algumas histórias são selecionadas para serem desenvolvidas na iteração atual.

A fase de design tem por objetivo criar uma representação simples das histórias que serão desenvolvidas na iteração. Utilizam-se preferencialmente cartões CRC (Classe- Responsabilidade-Colaborador), o único produto de trabalho que faz parte do processo. Cada história de usuário deve ter pelo menos um teste de aceitação para cada cenário identificado. O teste de aceitação de uma história de usuário tem por objetivo demonstrar que o comportamento do sistema corresponde ao esperado pelo usuário.

Durante a fase de codificação, a recomendação é não começar desenvolvendo as funcionalidades do sistema e sim codificando testes unitários para o que será desenvolvido. A codificação é realizada com a recomendação da programação em pares, onde duas pessoas trabalham juntas numa estação de trabalho. O ideal seria que, ao final de cada dia, o código produzido por cada par fosse integrado aos demais na estratégia conhecida como integração contínua.

O Extreme Programming incentiva a refatoração, ou seja, o processo de modificar um sistema de tal modo que ele não altere o comportamento externo do código, mas melhore a qualidade interna do software através de revisões arquiteturais, melhoria de desempenho, alterações no código para aumentar a clareza, entre outros (Astels, 2002, p. 149). É um modo disciplinado de modificar e simplificar o projeto que minimiza as chances de introdução de defeitos. Isso pode ser feito porque os testes automatizados garantem que as funcionalidades do sistema continuem consistentes.

O acompanhamento do progresso de desenvolvimento é realizado através dos testes de aceitação automatizados, embora não se descarte os testes de aceitação do usuário na entrega de uma versão. Dessa forma, o progresso é medido de acordo com uma visão aproximada à que o usuário possui sobre as funcionalidades que ele espera. Isso facilita o alinhamento dos objetivos do usuário com aqueles da equipe de desenvolvimento.

Scrum

O Scrum é um processo ágil de gerenciamento de projetos criado por Jeff Sutherland e Ken Schwaber na década de 90 (Schwaber, 2008). Ele é um processo empírico para desenvolvimento de produtos, isto é, não é restrito ao desenvolvimento de software, podendo ser aplicado em qualquer tipo de projeto cujas características do produto façam com que seu desenvolvimento não seja completamente previsível. Para que seja possível utilizar o Scrum, a equipe deve possuir todas as habilidades necessárias para executar as tarefas do projeto.

O Scrum foi desenvolvido sobre os pilares da transparência, onde os aspectos que afetam os resultados são visíveis para aqueles que gerenciam os resultados, da inspeção, onde os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas, e da adaptação, pois se um ou mais aspectos do processo estão fora dos limites e o produto resultante for inaceitável, o gerente do projeto deverá ajustar o processo ou o material sendo processado o mais rápido possível para minimizar desvios posteriores.

Esses pilares procuram facilitar o gerenciamento do projeto. Os riscos podem ser mitigados assim que surgem e adaptações realizadas sempre que necessário. A flexibilidade evita que o processo torne-se uma obstrução para que a equipe atenda as necessidades imediatas do negócio.

Existem apenas três papéis que os membros de uma equipe Scrum podem assumir. O Scrum Master é responsável por garantir que o processo seja compreendido e seguido, como um gerente de projeto, o Product Owner por maximizar o valor do trabalho que a equipe desenvolve, representando o cliente, priorizando e explicando as funcionalidades, e o Time é todo o pessoal que executa efetivamente o trabalho.

O Scrum Master é responsável por manter estimativas atualizadas do projeto. As estimativas do projeto como um todo e da iteração atual são parte importante dos pilares acima descritos, pois elas são geradas com base na inspeção, possibilitam a transparência e são base para a adaptação necessária.

O Scrum define apenas quatro produtos de trabalho: o Product Backlog, que consiste em uma lista dos requisitos do produto (histórias de usuário, por exemplo), podendo ser alterado a qualquer momento do projeto; o Burndown da Release, um gráfico que mostra a soma das estimativas de trabalho restantes do Product Backlog ao longo do tempo; o Sprint Backlog, uma lista de tarefas que a equipe deve cumprir para gerar o próximo incremento do produto; e o Burndown da Sprint, um gráfico da quantidade de trabalho restante da iteração atual (sprint).

Os gráficos de burndown fornecem as estimativas atualizadas do projeto. Eles são gerados a partir do backlog e da composição de dados estimados e coletados da velocidade da equipe em cada atividade ou história de usuário. Através desses gráficos o gerente pode responder a qualquer momento sobre o estado da iteração (sprint) e do projeto (release). Porém o gráfico geral do release nem sempre é produzido, pois as histórias de usuário das próximas iterações podem sofrer mudanças drásticas.

As iterações do Scrum são divididas em seis fases, descritas na Tabela 2.

Tabela 2 – Princípios da Modelagem Ágil (Schwaber, 2008)

Reunião de planejamento da release Tem o propósito de estabelecer um plano e metas para a iteração que está começando. Nessa reunião o backlog inicial do release é criado.
Sprint É a iteração em si, que gera um novo incremento do produto contendo a implementação dos requisitos elicitados através das histórias de usuário selecionadas. A indicação da duração é de uma até quatro semanas, dependendo do nível de experiência da equipe.
Reunião de planejamento do sprint Realização de planejamento da iteração.
Revisão da sprint O incremento é apresentado aos clientes para obter o feedback e outras informações necessárias ao planejamento do próximo sprint.
Retrospectiva do sprint A equipe se reúne para analisar as decisões e ações que cada um considera terem sido acertadas ou erradas, por exemplo, sobre ferramentas ou técnicas adotadas, a fim de melhorar o processo de desenvolvimento da equipe.
Daily Scrum Reunião rápida, com duração média de 15 minutos, onde cada membro da equipe expõe resumidamente o que está fazendo e se há alguma barreira a ser superada.

A estimação inicial geral e de cada iteração ocorre nas reuniões de planejamento, enquanto o controle e as atualizações das estimativas são feitos através dos gráficos de burndown.

Combinação de Extreme Programming e Scrum

Por serem processos ágeis, Scrum e a Extreme Programming compartilham de princípios comuns e podem ser usados em conjunto. Scrum é um processo de gerenciamento de projetos, enquanto a Extreme Programming é um processo de desenvolvimento de software. Esses dois tipos de processos geralmente não são excludentes. Kniberg (2006) descreve suas experiências com os processos combinados e afirma que não há conflito entre eles.

Essa combinação é um exemplo de um processo que engloba duas esferas necessárias para o desenvolvimento de um software. Processos de gerenciamento como o Scrum não definem aspectos específicos do desenvolvimento de software, enquanto processos de desenvolvimento como o XP o fazem.

Quando o processo de uma organização não aborda devidamente as áreas necessárias e restam lacunas a serem preenchidas, atividades necessárias podem deixar de ser executadas ou serem feitas empiricamente, de forma marginal ao processo e sem gerenciamento.

Test Driven Development

O Test Driven Development (TDD) é um processo de desenvolvimento de software orientado por casos de testes. A partir dos cenários de uso identificados para um sistema, codificam-se testes para cada um deles. Durante o desenvolvimento, escreve-se o código necessário para obter sucesso em cada teste. Por fim, melhora-se a arquitetura e o código em geral usando os testes para garantir que o funcionamento esperado não foi afetado (Koskela, 2008, p. 33).

Este processo procura alinhar o desenvolvimento com os requisitos de negócio através dos testes de aceitação, garantindo que o software atenderá as necessidades de negócio. Se os testes de aceitação refletem o comportamento esperado pelos usuários, então o critério de avaliação do software é o resultado da execução dos testes. Isso permite avaliar e acompanhar a qualidade do sistema de um ponto de vista semelhante ao do usuário, evitando que sejam empreendidos esforços em não conformidade com as necessidades de negócio.

O TDD pode melhorar a acurácia da estimação. Ela procura garantir que a equipe tenha o entendimento das funcionalidades através da criação precoce dos testes. Assim, como a equipe precisa que conhecer os requisitos para a criação dos testes, ela terá uma noção mais apurada do problema, o que pode levar a estimativas melhores.

Feature Driven Development

O Feature Driven Development (FDD) é um processo prático, iterativo e incremental de desenvolvimento de software orientado a objetos com foco nas características do sistema. Uma característica “é uma função valorizada pelo cliente que pode ser implementada em duas semanas ou menos” (Pressman, 2009, p. 71). A cada iteração de incremento do software algumas características que agregam valor ao produto são estimadas, selecionadas e então desenvolvidas de forma que o resultado do respectivo teste passe a ser de sucesso.

O objetivo deste processo é valorizar o produto focando as características que o cliente necessita. O foco em características facilita a compreensão do produto pelo cliente e no entendimento deste com a equipe de desenvolvimento.

O FDD pode dificultar a atividade de estimação quando as características são muito abstratas em relação ao software. A visão do produto através de características pode ser mais compreensível do ponto de vista do usuário, mas para a equipe de desenvolvimento é um desafio tentar prever o esforço de desenvolvimento necessário para uma característica descrita em alto nível.

Conclusão

Conhecer e entender os diferentes modelos e processos de desenvolvimento de software e gerenciamento de projetos é importante para uma estimação adequada. Os processos e modelos fornecem abordagens práticas para o desafio de desenvolver software de acordo com as reais necessidades do cliente.

Há uma tendência dos processos modernos em buscar flexibilidade, menor burocracia e manter o foco no produto de negócio. Isso significa diminuir o tempo que a equipe gasta com atividades desnecessárias ou sem sentido de modo a não encarecer o produto e tornar possível que a organização coloque seu foco no negócio e não em processos, técnicas ou tecnologias.

O próximo capítulo apresenta noções de estimativas, além de técnicas e modelos de estimação. As práticas e abordagens dos processos de software apresentadas neste capítulo e as noções de engenharia de requisitos apresentadas no capítulo anterior fornecerão uma base para a correta compreensão da atividade de estimação e de sua execução dentro dos processos de desenvolvimento.

O TDD está morto?

Test Driven Development (Desenvolvimento Orientado a Testes) é uma metodologia de desenvolvimento de software bastante popular, que é centrada (adivinhe) em testes.

No entanto, apesar de muito propagada, há várias críticas a essa metodologia por profissionais e pensadores de destaque.

Por esses dias rolou uma conversa bastante interessante sobre o assunto entre, nada mais nada menos, que Martin Fowler (que elaborou a ideia de Injeção de Dependência), Kent Beck (idealizador do TDD e do framework JUnit) e David Heinemeier Hansson (criador do Ruby on Rails).

Vamos analisar os pontos altos da conversa nos próximos tópicos. Mas antes, uma breve revisão sobre TDD…

Como o TDD funciona

Ao contrário do processo “tradicional” de desenvolvimento que envolve Especificação, Implementação e Testes, o TDD começa pelos testes em cima das interfaces do sistema.

A princípio todos os testes irão falhar. O objetivo do desenvolvedor é fazer com que eles sejam executados com sucesso. Em tese, isso garante o foco no que realmente deve ser feito e fornece uma medida mais real do progresso.

Os testes utilizados no TDD geralmente são Testes Unitários. Ambos os conceitos estão muito relacionados, mas não são sinônimos.

Testes Unitários

Testes Unitários são aqueles onde uma única função ou método do sistema é testada de cada vez. Em geral esses testes são automatizados.

Isso pode parecer simples, mas implica em que a rotina em questão não pode depender de outras rotinas, caso contrário o teste é sujeito a falhas de terceiros.

Dessa maneira, a fim de testar as rotinas que naturalmente possuem dependências de outras classes e métodos, de recursos como bancos de dados ou arquivos e outros, os desenvolvedores criam simulações desses elementos para que a rotina a ser testada funcione, porém não dependa diretamente desses outros elementos durante o teste.

Este é o conceito de mock, isto é, algo que imita o elemento original.

Por exemplo, um método que normalmente retorna um valor do banco de dados poderia ser substituído por um método que retorna um valor fixo num teste em particular. Cada linguagem, framework e ferramenta deve prover formas adequadas para se fazer isso, sendo inclusive uma forma de medir a qualidade da mesma.

Benefícios desta abordagem

Escrever os testes antecipadamente e então desenvolver com base neles traz várias vantagens:

  • Melhora o entendimento dos requisitos, já que para escrever o teste é necessário que o desenvolver entenda logo de início o que o sistema deve fazer.
  • Provê um objetivo claro a ser alcançado durante o desenvolvimento, isto é, fazer os testes executarem sem erros.
  • Aumenta a visibilidade do que está ou não pronto, já que os testes servem como indicadores mais confiáveis do que algo que está implementado e “só falta testar”.
  • A automação dos testes possibilita a Integração Contínua com certa garantia do funcionamento do sistema, já que todos os testes unitários podem ser reexecutados como testes de regressão sempre que necessário.

Desvantagens

Como regra geral, tudo que traz vantagens tem seus pontos negativos. Sempre temos que tomar cuidado com certos “evangelistas” que irão fazer uma tecnologia ou metodologia parecer não ter um lado negativo ou impacto zero.

Isso se aplica também ao TDD. Vejamos algumas considerações sobre ele:

Aumento do esforço

Será necessário gastar muito tempo para criar os testes e todos os mocks, além da infraestrutura de Integração Contínua. É claro que isso pode ser visto como um investimento em qualidade ao invés de uma pena a ser paga, mas na prática nem todos podem se dar a esse luxo.

Aumento da complexidade

A arquitetura acaba sempre mais complexa, usando muita Injeção de Dependências e outras técnicas de desacoplamento.

Mudanças nos requisitos são muito mais custosas, já que além do código do sistema em si, todos os testes e mocks envolvidos deverão ser reescritos.

Se o arquiteto de software não souber o que está fazendo, a arquitetura do sistema pode acabar cheia de gambiarras.

Intrusividade no código principal

Em muitas situações, será necessário programar de uma forma específica para que um certo código possa ser testado.

A arquitetura da aplicação muitas vezes acaba sendo então afetada por elementos e fatores que, de outra forma, não fariam parte de sua natureza.

Enfim, o design da aplicação acaba sendo influenciado pelos testes, o que nem sempre é desejável, já que é mais uma coisa a ser levada em conta e pode desviar o foco do arquiteto.

Testar tudo é quase impossível

Muitas tecnologias são difíceis de testar com testes unitários ou mesmo com testes de integração.

Pense na interface do usuário, por exemplo. Quantas delas possibilitam a execução da interface de forma “desacoplada”? Existem ferramentas como o Selenium para sistemas web, mas com elas também vêm diversas outras limitações e dependências.

O TDD está morto?

Vimos que todo benefício traz um custo associado. É este todo o ponto da discussão sobre o TDD estar morto. O custo de testar tudo e criar os mocks necessários para todos os testes vale a pena? Vejamos alguns comentários a seguir.

David Hansson inicia a argumentação dizendo que muitas pessoas não conseguem trabalhar com TDD porque não faz muito sentido para determinados tipos de trabalho. Ele toca no ponto da necessidade de se ter muitos mocks e que isso acaba tornando a codificação difícil.

Kent Beck aproveita o gancho e relata de casos onde a equipe não conseguia refatorar o código porque os testes estavam tão acoplados com a implementação, com dois ou três níveis de mocks, que qualquer alteração afetava inúmeros deles. Ele também afirma que há cenários onde o TDD se aplica melhor, por exemplo, quando os requisitos do software a ser desenvolvido são claros o suficiente para escrevê-los em testes diretamente. Por outro lado, há situações onde simplesmente o desenvolvedor vai descobrindo aos poucos aquilo que deve fazer. Isso é recorrente na criação de frameworks ou algoritmos que precisam analisar dados não estruturados.

Fowler argumenta ainda que a maior vantagem do TDD é um código que consegue testar a si mesmo. Só isso poderia também ser alcançado de outras formas. Ele também comenta sobre aqueles que dizem que “você não está fazendo teste unitário de verdade” porque existem algumas dependências durante o teste. Segundo ele, o importante não é a pureza de uma definição, mas que o teste funcione e seja útil, até porque há variações da definição de testes unitários.

Conclusões

É importante entender que TDD não é a “bala de prata” do desenvolvimento de software. Ele traz consigo vários desafios e problemas em potencial, principalmente se não há pessoas suficientemente experientes na equipe.

Testar é essencial, mas para cada projeto podem haver diferentes formas de testes, cujo busto-benefício deve ser avaliado para cada caso.

O teste não deve ser um objetivo em si mesmo, ainda que adotemos o TDD. Ele apenas tem o objetivo de garantir que estamos entregando o que o cliente pediu.

O tempo e o esforço que são investidos em testes também devem ser avaliado. Isso afeta diretamente a qualidade, mas a qualidade tem o seu preço. Quem irá pagar o preço da qualidade?

Quanto a testes unitários, não devemos buscar toda a pureza possível. O importante é que ele teste, ou seja, funcione para aquela situação específica.

Concluindo, o conselho em geral é: use TDD com moderação.


Para quem consegue entender Inglês, aqui vai o link do Hangout com essas grandes personalizados:

Is TDD dead?

Is TDD dead?

Test Driven Development is a very popular software development methodology focused (guest what?) on tests.

However, despite of being well known, there’s some criticism on this methodology from prominent professionals and thinkers.

A few days ago, there was a very interesting talk about this issue between Martin Martin Fowler (that elaborated the Dependency Injection definition), Kent Beck (creator of TDD and JUnit framework), and David Heinemeier Hansson (creator of Ruby on Rails).

Let’s review some highlights from that talk in the next topics. But let’s start with a brief review of TDD…

How TDD works

Different from the “traditional” development life-cycle composed by Specification, Implementation and Test, TDD begins testing the interfaces of the system.

At first, all tests will fail. The developer’s goal is to make they succeed. In theory it guarantee the focus on what really should be done and provides a concrete measure of progress.

In general, TDD adopts Unit Tests. Both are different things, but closely related.

Unit Tests

Each Unit Test tests only one function or method of the system. Often they are automated.

It seems too simple, but implies that the routine under test can’t depend on other routines, otherwise the test is subjected to third part failures.

This way, in order to test routines that naturally depend on other classes and methods, resources like databases and files, and other stuff, developers need to create simulations of these elements so the routine works without them during the test.

This is the mock idea, i.e., something that mimics the original dependencies.

For instance, a method that would normally return a value from database could be replaced by a method that returns a fixed value for a particular test. Each language, framework, and tool should provide proper ways for doing that. This is also a manner to assess the quality of these tools!

Benefits of TDD

Writing tests in advance brings various advantages:

  • Helps in the understanding of the requirements, since you have to understand them and also what the system should do in order to write down tests.
  • Provides a clear goal in the development, that is, to make all tests to pass.
  • Increases the visibility of what is or not ready, since the tests are generally more reliable indicators of progress than something “implemented, but not tested”.
  • The automation enables Continuous Integration with some level of guarantee the system won’t break, since all unit tests can be executed over and over as regression tests.

Disadvantages

As a general rule, everything has its advantages and also its negative points. We always have to take care with “evangelists” that will make some technology or methodology looks like it hasn’t problems or has zero impact.

This also applies to TDD. Let’s see some of its reservations:

Increases the effort

It’s necessary to spend much more time creating tests and mocks, not to mention the Continuous Integration infrastructure. Of course it can be considered as an investment in quality instead of a penalty, but in practice not everyone can afford the overhead.

Increases the complexity

The architecture becomes more complex since Dependency Injection and other decoupling techniques are abundantly used everywhere.

Changes in requirements are much more costly, since you need to rewrite the code of the system itself plus all the tests and mocks involved.

If the engineer don’t know well what he’s doing, the system will end with tons of kludges.

Intrusiveness in the main code

In some situations, you’ll have to code in a specific way in order the code can be tested later. The application architecture is then affected by outside unnatural factors.

In short, the design is influenced by tests, what is not desirable since is one more thing to be considered and to grab the architect’s attention.

Testing everything is almost impossible

Many technologies are hard to test independently or even in integration tests.

Think about user interfaces, for example. How many technologies allow us to run it in a decoupled way? There’s tools like Selenium for web apps, but they also brings tons of other limitations and dependencies.

Is TDD dead?

We just saw every benefit comes at a cost. This is the main point about TDD being dead. Is the cost of testing everything and creating mocks for every dependency worthy? Let’s look at some comments about the aforementioned talk.

David Hansson starts arguing that lots of people can’t do TDD because of the nature of their work. He talks about the need of numerous mocks and how it makes coding more difficult.

Kent Beck continues and tell us about situations where the team couldn’t refactor their code because the tests were so coupled to the implementation, with two or three levels of mocks, that any modification affected countless of them. He also asserted TDD fits better certain scenarios, for instance, when requirements are clear enough so you can write them in form of tests directly. On the other hand, there are situations when the developer finds out little by little what he actually should do. This is recurrent in framework development and algorithms for analyzing non-structured data.

Fowler argues the major benefit of TDD is a self-testing code. But this could be achieved in other ways. He also talks about those who say “you aren’t doing unit tests right” because of some dependencies during the test. According to him, the “purity” of the definition is not so important, but the test should work and be useful. Furthermore, there’s alternative definitions of Unit Test.

Conclusions

It’s important to comprehend TDD is not the silver bullet of software development. It brings various potential challenges and problems, mainly if there’s not enough experienced people in the team.

Tests are essential, but for each project we could have different kinds of tests, whose cost-benefit should be evaluated for each individual case.

Tests shouldn’t be the goal in itself, even in TDD. Their true goal is guarantee we’re delivering what the client really needs.

Time and effort invested in tests also should be pondered. It affects directly the quality, but the quality has its price. Who will pay for it?

About unit testing, we shouldn’t pursue only purity. The important is the test tests, that is, it works for that situation.

Finally, a general rule could be: use TDD moderately.


Here is the link of the Hangout with those great guys:

Is TDD dead?

Planning Poker existe, sem brincadeira

No último post, mencionei um tal de planning poker e um colega achou que era parte da brincadeira. Para quem não conhece, talvez a frase em questão talvez não tenha feito tanto sentido:

Coloque uma equipe de juniors num processo ágil, eles vão começar a estimar usando planning poker e provavelmente vão continuar jogando poker até o final do projeto.
Para quem já conhece é chover no molhado. Mas vamos lembrar que ainda existem muitas pessoas que desconhecem completamente os processos ágeis ou apenas ouviram falar deles. E nem sempre é culpa é do indivíduo em si, pois quantos formandos saem de um curso de Ciências da Computação sem nem ouvir falar desse assunto. Isso aconteceu comigo. O único contato com Engenharia de Software foi uma disciplina cujo conteúdo consistia em alguns capítulos do Pressman.

Infelizmente muitas universidades não contam com professores que possuem experiência de mercado, outras vezes a grade curricular não ajuda. Existem professores que ensinam o mesmo conteúdo há tantos anos que dá a impressão de que a tecnologia não evoluiu. Outros são inexperientes e adotam um livro guia, apenas resumem o conteúdo.

O que é Planning Poker?

É uma forma de criar estimativas. 

Estimação é uma atividade fundamental de todo processo ágil. A cada início de iteração (sprint), as estórias de usuário (requisitos) que serão implementadas precisam ser detalhadas e estimadas. Esta é uma tarefa realizada em conjunto por todo o time (equipe).

Com o Planning Poker a tarefa de estimar pode ser mais interessante e divertida, o entendimento dos requisitos é melhor entendido pela equipe e há motivos para se acreditar que tenha bons resultados.

Adaptei uma explicação de como a técnica funciona do site www.crisp.se, detalhada a seguir.

Estimativas sem Planning Poker

Há um problema típico com as estimativas em equipe. Vamos supor que estamos na Reunião de Planejamento do Sprint e o Product Owner diz:

Pessoal, qual o tamanho dessa estória de usuário aqui?

Então a equipe começa a pensar sobre o tamanho dessa estória (em homem-dia nesse caso):

Sem Planning Poker - Passo 1

O sr. 

A acredita que ele sabe exatamente o que deve ser feito e acha que levará 3 dias. Os senhores C são mais pessimistas. D e E estão pensando em qualquer outra coisa. Então o sr. A se antecipa e diz: “vai levar 3 dias”.

Sem Planning Poker - Passo 2

Isso deixa 

B e C confusos, duvidando de suas estimativas. O sr. E volta a si e nem sabe o que está sendo estimado, enquanto D continua cochilando. Quando o Product Owner pergunta ao resto da equipe sobre suas estimativas, todos acabam sendo influenciados por A, que respondeu primeiro, e respondem:

Sem Planning Poker - Passo 3

Estimando com Planning Poker

Agora, imagine cada membro a equipe segurando o seguinte maço de cartas:

Cartas Planning Poker

Vamos refazer a estimação. O 

Product Owner diz: “Pessoal, qual o tamanho dessa estória de usuário aqui?” Mais uma vez, a equipe começa a pensar.

Com Planning Poker - Passo 1

Desta vez, ninguém se antecipa. Cada um seleciona uma carta contendo sua estimativa e a deixa virada sobre a mesa. Depois que todos colocam suas cartas, os senhores 

D e E acordam. Eles admitem que dormiram e perguntam qual estória está sendo estimada, pois é difícil chutar estimativas dessa forma. Quando todos terminam, as cartas são viradas simultaneamente, revelando as estimativas de cada pessoa.

Com Planning Poker - Passo 2

Ops! Houve uma grande divergência. A equipe, principalmente o sr. 

A e o sr. C, precisam discutir a estória e porque suas estimativas estão tão distintas. Depois de alguma discussão, o sr. A percebe que esqueceu algumas tarefas importantes que deveriam ser incluídas na estória. O sr. C percebe que, com o design que o sr. A apresentou, a estória pode ser menor que 20. Depois de 3 minutos de conversa, um novo round de estimação é feito para a mesma estória:

Com Planning Poker - Passo 3

Houve convergência, ainda que parcial. Então eles concordam que uma estimativa de valor 5 deve estar próxima o bastante e partem para a próxima estória.

Porque essa estranha série de números?

Cartas Os números grandes tem menos granularidade. Por quê? Porque não há o número 21, por exemplo? Algumas razões:

  • Aumentar a velocidade o processo de estimação limitando a quantidade de escolhas (número de cartas).
  • Evitar a falsa sensação de precisão (acurácia) para as estimativas mais altas.
  • Encorajar a equipe a dividir grandes estórias em menores.

Uma estimativa alta (maior que 20, por exemplo), geralmente significa que a estória não foi bem compreendida. Seria uma perda de tempo discutir se a estória vale 19, 20 ou 22,5. A estória é grande e pronto. Se for necessário detalhar a estória, deve-se quebrá-la em estórias menores.

Cartas Especiais

A carta “zero” significa que a estória já foi implementada ou que ela é ínfima, consistindo talvez em alguns minutos de trabalho.
A carta “interrogação” (“?”) significa que a pessoa não tem absolutamente nenhuma ideia. Nada. É raro acontecer, mas se a frequência aumentar a equipe deve discutir mais as estórias e tentar chegar a um melhor entendimento.
A carta “xícara de café” significa: “Estou cansado demais para pensar. Vamos fazer uma pausa”.

Creative Commons O blog State of the Art de Luiz Ricardo é licenciado sob uma Licença Creative Commons. Copie, compartihe e modifique, apenas cite a fonte.