Uma Visão Geral de Diferentes Métodos Ágeis

 

Nesse artigo vamos apresentar uma visão geral de alguns métodos ágeis de gestão de projetos de desenvolvimento de software. O leitor poderá notar que praticamente todos esses métodos usam rodadas (sprints, ciclos, iterações) de trabalho para criar partes menores de um produto maior e completo. A escolha e priorização dessas partes menores – criadas em cada rodada - leva sempre em consideração o que é mais útil, prioritário e gera mais valor para os clientes.

As abordagens ágeis aqui tratadas e descritas nesse artigo em suas linhas gerais, parecem provar que existe uma diversidade de ideias e preferências presentes no campo da engenharia de software e do gerenciamento de projetos. Mas, como na frase de Bob Marley, essas diferenças não derrubam o ágil, ao invés disso, ajudam a levantá-lo.

 

“Seja diferente:

Não derrube.

Ajude a levantar...”

(Bob Marley)

Scrum – Dentro desse método ágil, um projeto é divido em ciclos chamados de Sprints. Um Sprint representa um Time Box (período de tempo, tipicamente de 2 a 4 semanas) dentro do qual um conjunto de atividades deve ser executado. Tudo que vai ser implementado em um projeto é mantido em uma lista de itens chamada de Product Backlog. No início de cada Sprint, faz-se uma Sprint Planning Meeting (reunião de planejamento do Sprint), em que o Product Owner prioriza os itens do Product Backlog e a equipe seleciona os itens que serão implementados durante o Sprint que se inicia.

Os itens alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog. Para tratar do que foi feito no dia anterior, identificar gargalos e priorizar o trabalho do dia que se inicia, a equipe realiza uma reunião chamada Daily Scrum Meeting. Ao final de um Sprint é realizada uma reunião de revisão chamada de Sprint Review Meeting, na qual a equipe apresenta os itens implementados e o projeto é avaliado com relação aos seus objetivos. Finalmente, é também realizada uma reunião de retrospectiva, chamada de Sprint Retrospective Meeting, para avaliar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.

Os principais papéis no Scrum são o Product owner, que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings, o Scrum Master, que é o responsável por facilitar o trabalho de toda a equipe, principalmente no que diz respeito à compreensão dos conceitos do Scrum, e a equipe (Scrum Team) que trabalha com os itens priorizados do  Product Backlog  e se compromete a entregá-los ao final de um Sprint.

XP (eXtreme Programming) – É um método ágil no qual o desenvolvimento de software é feito em iterações de curto período de tempo (1 ou 2 semanas) onde a equipe desenvolve um conjunto de funcionalidades. No início da iteração os desenvolvedores e clientes se reúnem para priorizar as funcionalidades. Essa reunião chama-se jogo de planejamento e nela já devem estar criadas as User Stories (Estórias de Usuário). Se uma estória for muito grande, deverá ser dividida em tarefas com menor duração. O planejamento é importante para que sempre se faça o que é mais importante e prioritário. O XP segue um conjunto de práticas que auxiliam no alcance de um projeto bem sucedido e incluem, por exemplo, o cliente sempre presente, programação em par, metáforas, TDD, refatoração, código coletivo, padronização de código, design simples, integração contínua e releases curtos. No XP também são adotadas reuniões diárias de curta duração, feitas com as pessoas de pé, para alinhamento do projeto e discussão de problemas, chamadas de Stand Up Meetings (Reunões de Pé).

Users Stories (Estórias de Usuário) são escritas pelos clientes com “coisas que o software precisa fazer”, substituindo documentos detalhados de requisitos e são usadas para criar estimativas de tempo para a reunião de planejamento além de auxiliar na criação dos critérios de testes de aceitação.

Spike Solutions se refere ao uso do programa mais simples possível para explorar soluções potenciais. É usado para determinar quanto trabalho será necessário para resolver ou contornar um problema de software.

Programação em par – Dois programadores fazendo o trabalho juntos em um único computador para revisão do código, redução de falhas e melhoria da qualidade.

Metáforas – São elementos usados no computador que simulam “coisas” que existem no mundo físico (lixeira, porta, janela, pasta, etc). As metáforas melhoram a comunicação e o entendimento de partes do código que executam determinadas funções representadas por elementos do mundo físico com os quais os desenvolvedores e clientes estão familiarizados.

TDD (Test Driven Development ou Desenvolvimento Orientado à Testes) – Primeiro se escrevem os testes, antes de implementar o sistema (conjunto de componentes integrados). Cada componente é testado individualmente para garantir sua correta operação. Depois disso, os componentes são integrados para formar o sistema e então testados, buscando-se encontrar erros que resultem de interações não previstas nos testes individuais.

Refatoração – Uma técnica usada pelas equipes para melhorar continuamente a estrutura do código quando uma nova funcionalidade é introduzida, tornando-o mais claro e fácil de ser compreendido, mas sem mudar o comportamento das funcionalidades.

Código coletivo – Isso significa que o código fonte não tem dono e ninguém na equipe de desenvolvedores precisa solicitar permissão para modificar o mesmo.

Padronização de código – Isso significa que existe um jeito certo de fazer as coisas no projeto e todos na equipe devem seguir essas regras definidas para desenvolver o software.

Integração contínua – Isso significa que não se deve esperar muito tempo (1 semana ou mais) para integrar uma nova funcionalidade com a versão atual do sistema.

Releases curtos – Isso significa que os releases são pequenos pedaços do produto que está sendo desenvolvido no projeto.

DSDM (Dynamic Systems Development Method) – É uma metodologia ágil de desenvolvimento de software iterativa e incremental que enfatiza o envolvimento constante do usuário. Assim sendo, em cada rodada no método, partes do software (funcionalidades ou componentes funcionais do sistema) vão sendo entregues.

É importante ter a compreensão que para iniciar o ciclo de desenvolvimento iterativo no DSDM o projeto precisa estar construído em uma base sólida, com fundamentos que incluem, por exemplo, um estudo de viabilidade e um plano geral de desenvolvimento.

A estrutura de trabalho do DSDM possui fases que são descritas a seguir:

Pré-Projeto: Essa fase deve garantir que os projetos estejam prontos para começar com base no objetivo e nas metas de negócios.

Antes de iniciar a construção das funcionalidades, o projeto no DSDM considera que deve ser feita uma análise de viabilidade e também deve ser elaborada uma análise do negócio. Como resultado se obtém o relatório de viabilidade, a lista de requisitos do sistema e o plano geral de desenvolvimento.

Após a conclusão destas duas fases, o sistema é desenvolvido iterativamente e incrementalmente, em um modelo evolucionário que considera o seguinte:

Iteração do modelo funcional: Tem foco na criação, a partir dos requisitos identificados no estágio anterior, de protótipos funcionais que determinam as funcionalidades a serem implementadas, que resultarão desta iteração. Isso feito, a lista de requisitos é atualizada, removendo-se os itens entregues e refazendo a lista de prioridades dos requisitos remanescentes.

O sistema é construído exatamente de acordo com o design e as funções consolidadas e integradas nos protótipos.

Na fase de implantação, ocorre a entrega das funcionalidades (ou componentes funcionais do sistema) desenvolvidas, devidamente prontas e funcionando para utilização pelos usuários finais. Inclui também o treinamento dos usuários e a entrega da documentação do projeto relacionada às funcionalidades que estão sendo entregues.

Pós-Projeto: Esta fase garante a eficiência e eficácia do projeto, através de manutenções, melhorias e ajustes.

FDD (Feature Driven-Development) – é um método ágil e iterativo para desenvolvimento de software que combina gestão de projetos com boas práticas de engenharia de software. No FDD o projeto é dividido em “features” (funcionalidades) definidas como pequenas partes de um projeto completo.

No FDD é feito um mapeamento sobre que partes do software os desenvolvedores serão capazes de criar, dividindo as solicitações maiores e complexas em uma série de conjuntos menores e, em seguida, é elaborado um plano que estabelece como concluir cada um desses conjuntos menores ao longo do tempo.

Os principais papéis do FDD são os seguintes:

Gerente de Projetos (Project Manager) – É o administrador do projeto, que faz os relatórios de progresso e gerencia o orçamento, os equipamentos, os recursos, etc.

Arquiteto Chefe (Chief Architect) – É o responsável pelo design geral do sistema.

Gerente de Desenvolvimento (Development Manager) – É o membro da equipe que lidera as atividades de desenvolvimento do dia-a-dia.

Programador Chefe (Chief Programmer) – É um programador experiente que já passou algumas vezes por todo o ciclo de vida de desenvolvimento de software.

Proprietários de classe (Class Owners) - São desenvolvedores que estão trabalhando como membros de pequenas equipes de desenvolvimento sob a orientação de um Programador Chefe.

Especialistas em Domínio (Domain Experts) - São usuários, patrocinadores, analistas de negócios, ou todos esses especialistas combinados, conhecidos por possuir a base de conhecimento na qual os desenvolvedores dependem e confiam para entregar o sistema correto.

O FDD é multifuncional, iterativo e altamente colaborativo e possui cinco (5) etapas básicas:

Desenvolver um modelo geral – Com orientação do Arquiteto Chefe, a equipe desenvolve um modelo geral que serve de base para a criação da lista de funcionalidades a ser desenvolvida no projeto.

Construindo a lista de funcionalidades - Usando o modelo da etapa anterior, a equipe ou o Programador Chefe constrói uma lista de funcionalidades considerando o que será útil para os usuários e poderá ser concluído ao longo de um cronograma de liberação de funcionalidades.

Planejamento por funcionalidade - Os planos são colocados na ordem em que as funcionalidades serão implementadas. As equipes são então selecionadas para desenvolver cada conjunto de funcionalidades.

Design por funcionalidade - Nesse estágio, o Programador Chefe escolhe as funcionalidades para o desenvolvimento e faz a alocação destas para as equipes. Geralmente, uma equipe deve contar com as seguintes funções/papéis: Gerente de Projeto, Arquiteto Chefe, Gerente de Desenvolvimento, Especialista de Domínio, Proprietário de Classe e Programador Chefe.

Construindo por funcionalidade - As equipes trabalham para fazer a codificação das funcionalidades, os testes e a documentação completas de cada funcionalidade. As funcionalidades concluídas pela equipe e avaliadas pelo cliente são liberadas.

Embora os métodos sejam diferentes, há muitas semelhanças entre eles.

É perfeitamente possível notar que nos métodos estudados existe a ideia da rodada de trabalho, em que partes menores vão sendo feitas e incorporadas para formar um todo. Os nomes dessas rodadas de trabalho (Sprint, ciclo, iteração) podem variar de método para método, mas a filosofia é nitidamente comum à todos.

A duração dos Sprints, ciclos ou iterações é de poucas semanas. Além disso, a maior parte dos métodos ágeis foi idealizada para o trabalho com equipes pequenas.

Há uma etapa de avaliação inicial que tem como propósito a tarefa de responder as seguintes perguntas: - O que vamos fazer? Como vamos dividir esse problema grande em partes menores? As respostas ajudam a criar a lista de funcionalidades do software que será desenvolvida.

Outro aspecto presente em quase todos os métodos aqui apresentados é que, ao invés de elaborar um plano completo e que abranja todo o projeto, o planejamento é feito para cada rodada de trabalho. Se analisarmos em linhas gerais, será possível notar que no Scrum esse plano é o planejamento do Sprint (Sprint Planning). No XP existe o chamado jogo de planejamento que utiliza as estórias de usuário, os critérios dos testes de aceitação e elabora o plano da iteração. No FDD o planejamento é feito por funcionalidade, uma vez que os planos são colocados na ordem em que as funcionalidades serão implementadas.

Outro ponto que merece ser destacado é que cada método, a sua maneira, permite que seja criado um fluxo contínuo de desenvolvimento de software.

Espero que você leitor que me acompanha tenha gostado desse conteúdo. Deixe seu comentário. Bem, é isso aí. Até a próxima!

As 12 Descobertas de Reifer

Será que a foto que vemos logo abaixo prova que o Scrum, em particular, e o Agile, em geral, não são isso tudo? Não é bem assim. 

No início da falação e intensa divulgação sobre os métodos ágeis todos queriam ser ágeis e mostrar que estavam a favor da novidade. Ninguém queria ficar para trás e isso levou as pessoas a fazer vista grossa para certos exageros. A frase na capa do livro de Jeff Sutherland, lançado em 2014, é uma prova disso. A frase dizia o seguinte: “Scrum, the art of doing twice the work in half the time.” (Scrum, a arte de fazer o dobro do trabalho na metade do tempo).

Mais recentemente o Disciplined Agile Consortium (Consórcio do Ágil Disciplinado) em uma de suas apresentações divulgou o slide acima, que diz o seguinte:

.............................................

You are promised: Scrum, the art of doing twice the work in half the time. (Jeff Sutherland)

You actually get: 

Recent study of 3,000+ teams within 155 organizations found:

Teams adopting agile (mostly Scrum) saw productivity increases of 7 to 12 % in average.

Teams adopting prescriptive scaling frameworks, the most popular of which is SAFe, saw productivity increases 3 to 5% in average.

.............................................

Te prometeram: Scrum, a arte de fazer o dobro do trabalho na metade do tempo. (Jeff Sutherland)

Você realmente obteve:

Um estudo recente com mais de 3.000 equipes em 155 organizações descobriu:

As equipes que adotaram o Agile (principalmente o Scrum) tiveram aumentos de produtividade de 7 a 12% em média.

As equipes que adotam estruturas de trabalho prescritivas ágeis em escala, a mais popular das quais é o SAFe, viram a produtividade aumentar de 3 a 5% em média.

.............................................

Não vejo isso como uma crítica aos métodos ágeis em geral e ao Scrum em particular, mas sim um alerta ao exagero que as novidades costumam causar nas pessoas.

Mas então quais foram os benefícios obtidos pelas organizações que adotaram métodos ágeis de gerenciamento de projetos? É o que o trabalho de Donald Reifer procurou responder.

O texto a seguir teve como base o artigo de Reifer, publicado no website Infoq.com, com o título “Quantitative Analysis of Agile Methods Study (2017): Twelve Major Findings” (Um estudo da Análise Quantitativa de Métodos Ágeis (2017): Doze Principais Achados), que pode ser encontrado acessando o link no final desse artigo.

De qualquer modo, é evidente que os métodos ágeis trouxeram benefícios para os projetos e para as empresas que os adotaram, como é tratado no próprio artigo de Reifer, na descrição das suas 12 descobertas, que tiveram como base uma extensa pesquisa que envolveu a análise dos resultados de 1.500 projetos concluídos que usaram métodos ágeis e outros 1.500 que usaram abordagens tradicionais.  Vejamos, então, um resumo sobre as 12 descobertas de Reifer relacionadas aos métodos ágeis aplicados aos projetos:

Descoberta no. 1 – Os métodos ágeis continuam a ser a abordagem predominante usada para desenvolvimento de software. Mais de 70% das organizações pesquisadas reportaram que têm usado métodos ágeis operacionalmente por períodos que vão de três a treze anos.

Descoberta no. 2 – O método ágil mais popular usado atualmente continua a ser o Scrum ou um derivado do Scrum chamado LeSS (Large Scale Scrum). Outros métodos ágeis empregados, mas encontrados em porcentagens muito menores na população da pesquisa, incluem o AUP (Agile Unified Process), o XP (Extreme Programming) e o FDD (Feature-Driven Development).

Descoberta no. 3 – Trabalhar com métodos ágeis em grandes projetos não é uma tarefa fácil. As organizações que buscam esses grandes desenvolvimentos estão usando uma metodologia ágil em escala (48%) ou uma metodologia híbrida (52%). Isso representa uma mudança em relação ao cenário de dois anos atrás, quando o uso do ágil em escala era cerca de metade do que é hoje.

Descoberta no. 4 – A taxa de reversão do Agile diminuiu. Apenas 10% daqueles que abandonaram os métodos ágeis reverteram (ou seja, decidiram voltar) para os métodos tradicionais. Os outros 90% de organizações que abandoram os métodos ágeis passaram a usar abordagens híbridas ou mesmo caseiras para preencher o vazio.

Descoberta no. 5 – Os ganhos de produtividade ágil foram estabilizados. Com base em dados de 1.500 projetos tradicionais concluídos e outros 1.500 projetos ágeis também concluídos, os ganhos médios de produtividade alcançados durante o desenvolvimento por equipes que usam métodos ágeis foram de 7 a 12% melhores do que para as equipes que usam métodos tradicionais. Essas melhorias ainda são notáveis, especialmente em grandes organizações, onde esses ganhos se traduzem em economia de milhares de horas por pessoa.

Descoberta no. 6 – As economias de custo do Agile também se estabilizaram. Os custos ágeis, medidos em termos de $/unidade produzida, continuam a ser entre 5 a 12% menores do que os custos medidos da mesma forma em um projeto tradicional. Os dados revelam que as reduções de custo obtidas com o uso de métodos ágeis durante os últimos três anos se estabilizaram à medida que as empresas espalharam o uso desses métodos por toda a organização.

Descoberta no. 7 – A maneira como o tempo e o esforço são distribuídos durante o desenvolvimento de software usando métodos ágeis difere daquela experimentada em projetos tradicionais. A principal razão para essa diferença é que as equipes que usam métodos ágeis concentram seus esforços na criação de um produto funcional em curto espaço de tempo, em vez de, por exemplo, gastar tempo na criação de documentação. Os desenvolvedores ágeis criam e revisam o código de trabalho com o usuário, em vez de – como nos métodos tradicionais - dedicar 50% do esforço e 40% do tempo à geração de requisitos e especificações de design antes do início da codificação. Em vez de tentar obter as especificações certas antes de começar a codificar, os desenvolvedores ágeis gastam até 80 por cento de seu tempo e esforço desenvolvendo um software funcional que possam demonstrar para os clientes.

Descoberta no. 8 – O Agile melhora a capacidade de cumprir os prazos do cronograma. A análise dos dados pesquisados mostrou que o Agile fornece às empresas a capacidade de cumprir prazos apertados em 75 a 90% do tempo, em comparação com o desempenho médio de 40 a 60% que as empresas experimentam em projetos similares gerenciados por métodos tradicionais. No entanto, é importante entender que o conteúdo típico entregue em desenvolvimentos ágeis (ou seja, a porcentagem de funcionalidades que foram prometidas e realmente entregues) varia de 80 a 90% contra 95 a 100% para desenvolvimentos orientados a planos ou tradicionais. Nos projetos pode acontecer a situação da não entrega de todas as funcionalidades prometidas. Nos projetos ágeis isso é esperado porque as equipes oferecem as funcionalidades que o cliente considera mais importantes. Quando prazos ou mudanças de escopo se tornam um problema, as funcionalidades de prioridade mais baixa são acumuladas (voltam para o backlog) e aquelas de prioridade mais alta são desenvolvidas e entregues. Em contraste, os desenvolvimentos tradicionais seguem uma filosofia do “tudo ou nada”, em que os atrasos são a norma.

Descoberta no. 9 – A qualidade é melhor nos métodos ágeis do que nos métodos tradicionais. Nos próximos 3 anos espera-se que a qualidade ágil exceda a qualidade obtida nos métodos tradicionais em um fator de 6 a 12%. A qualidade do software melhora tanto durante o desenvolvimento quanto no pós-lançamento, porque é trabalhada pela equipe à medida que o software funcional é gerado.

Descoberta no. 10 – O valor ágil continua sendo difícil de quantificar. Os métodos ágeis enfatizam o fornecimento de valor a seus usuários/clientes, fornecendo continuamente produtos de software funcionais ao longo do ciclo de vida de desenvolvimento. O valor é comumente medido em termos do benefício financeiro e/ou competitivo que as organizações recebem por seus esforços e investimento. Embora haja alguma orientação disponível para o planejamento de valor, pouca ajuda é oferecida sobre como quantificar o valor derivado desses esforços. Em vez disso, o termo às vezes é usado para transmitir moral e outras medidas de valor importantes, mas não facilmente quantificáveis.

Descoberta no. 11 – O Àgil continua a fornecer vantagem competitiva aos seus usuários. Muitas organizações parecem acreditar que os métodos ágeis podem representar uma vantagem competitiva quando aproveitam ao máximo seus pontos fortes e contrabalanceiam seus pontos fracos. Os métodos ágeis não apenas fornecem recompensas de produtividade, custo e tempo de colocação do software no mercado, mas também fornecem aos usuários a capacidade de atrair e reter talentos.

Descoberta no. 12 – Os impactos do Agile nas práticas de contratação governamentais podem ser importantes. O impacto dos métodos ágeis não se limita às práticas de desenvolvimento. Quando o ágil é usado no contrato, o impacto do método se reflete na forma como o trabalho é planejado, cronogramas e orçamentos são alocados, requisitos são capturados e gerenciados, o progresso é revisado e o desempenho geral do contrato é determinado. Se o governo e os fornecedores estabelecerem uma estrutura de gerenciamento colaborativo para o desenvolvimento, ambos podem trabalhar de acordo com os planos acordados para atingir as metas compartilhadas com um mínimo de atraso e atrito. Quando tal estrutura não é criada, conflitos ocorrem devido às diferenças na forma como cada um conduz seus negócios. Essas incompatibilidades geralmente resultam em gargalos, atrasos e desconfiança devido a seus desalinhamentos.

Para mais detalhes acesse:

Reifer, D. J. (2017) Quantitative Analysis of Agile Methods Study (2017): Twelve Major Findings. Available at: https://www.infoq.com/articles/reifer-agile-study-2017/  Accessed: 10 February 2021.  

.............................................

As “Inocentes Mentiras" do Marketing

   

O professor Rafael Sampaio, em seu livro “Propaganda de A a Z”, publicado pela editora Campus em 1996, afirma que “a melhor política é ser absolutamente honesto em tudo o que se diz e se mostra ao consumidor. Um consumidor frustrado com uma promessa exagerada, decepcionado pelo não atendimento das expectativas criadas por um comercial ou revoltado com a mentira contada por um anúncio, não apenas deixa de comprar ou repetir a compra do produto/serviço, como forma uma imagem negativa da marca e tende a fazer comentários negativos a respeito delas para um grande número de pessoas”.  

Eu concordo plenamente. Todavia, observando o mundo a minha volta, essa afirmação do professor Sampaio parece que ficou pertencendo aos velhos manuais enferrujados de boas maneiras. Mas, afinal de contas, a propaganda e o marketing estão cheios de mentiras?   

Os mais antigos devem se lembrar de propagandas que mentiam na maior cara de pau. “Esse modelo fará de você uma miss” é um exemplo desse tipo de propaganda aplicado a roupas femininas. Esse tipo de expediente acabou sendo proibido e condenado pelas regras de ética e conduta profissional dos publicitários. Apesar disso, ainda podemos nos deparar com vários exemplos de propagandas enganosas, que não deixam de ser mentirosas, como, por exemplo aquelas que costumam propalar os efeitos milagrosos de determinadas químicas, como produtos para emagrecimento ou crescimento capilar, sem mencionar seus efeitos colaterais prejudiciais à saúde das pessoas que delas se utilizam. Há muitos outros casos e essas tentativas de convencimento a qualquer custo e sem maiores preocupações estão presentes em muitas situações.

“Com o Scrum você faz o dobro do trabalho na metade do tempo”. Nossa, um verdadeiro milagre! Essa foi mais uma típica mentira de marketing aceita pelas pessoas. O Scrum foi vendido da mesma forma como se vendem remédios para calvície e emagrecimento. Parece que, por alguma razão, as pessoas queriam acreditar nesse milagre. Da mesma forma que as pessoas desejam muito recuperar seus cabelos e emagrecer, existe o desejo de conseguir ser mais eficiente no trabalho, fazendo o dobro na metade do tempo.

Mas, o tempo passa e a dura realidade acaba mostrando sua face, o que significa que em algum momento essas mentiras podem ser desmascaradas. Mesmo assim, não é tão simples para um indivíduo admitir que foi enganado. Por causa disso, muitas vezes as pessoas fingem que as tais mentiras nunca existiram e que foram apenas mensagens motivacionais sobre uma novidade. Mensagens apressadas, aparentemente inocentes e despreocupadas, que não passariam de pequenos deslizes da natureza humana. Pobres de nós, ansiosos por uma mentira conveniente e temerosos pelas inconvenientes verdades. Pelo menos, sabendo disso, que fiquemos atentos para as próximas!

Vamos voltar à foto acima em nosso próximo artigo: “As 12 Descobertas de Reifer” tendo como base uma análise quantitativa de métodos ágeis. Então, é isso aí, até a próxima.

Orientação de TCC Online