Iterações: qual o tamanho?

iteracoes-qual-o-tamanho-rodrigo-zambon-mundo-agilAntes de falar de iterações, vou falar um pouco de escopo e começar com um dado publicado pela Standish Group que diz respeito ao uso das funcionalidades em softwares. Apenas 20% das funcionalidades são utilizadas com frequência, sendo que 80% foram poucas ou nenhuma vez utilizadas1.

A pergunta aqui é: por que isso acontece?

Não só em software, mas em diversos projetos, percebemos que entregamos coisas desnecessárias para o cliente, itens que agregam tão pouco valor que se não estivessem ali, ninguém sentiria falta.

A definição do escopo na abordagem tradicional é feita no início do projeto, e procura-se esgotar o processo. Muitos stakeholders, classificados em uma longa planilha, são ouvidos. As expectativas são levantadas e muitos imaginam que fazendo uma boa definição de escopo o projeto será um sucesso.

Porém na prática isto é um pouco diferente, ou seja, o mapa não é o território2. O quanto antes você encarar a sua realidade melhor. Por isso, no início do projeto, determinar o tamanho das suas iterações pode ser crucial para o sucesso de todo projeto. Pense sempre em primeiro lugar no retorno sobre o investimento do cliente e em segundo, na mitigação dos riscos.

Abraçar cegamente o plano e só ter contato com o cliente no final do projeto certamente é uma estratégia ultrapassada por vários motivos, e como exemplo posso citar os dois principais: só entregar o produto no final e ainda correr o risco de entregar um produto obsoleto.

As iterações mais curtas permitem a equipe do projeto obter feedback mais cedo e consequentemente revisões periódicas com os clientes. Isso irá permitir, primeiro saber se estamos indo para o lugar certo e em segundo se estamos de fato atendendo às necessidades de nossos clientes. A abordagem tradicional atrasa esse tipo de vantagem, até quase sempre, serem irreversíveis. E mais fácil mudar no início onde os custos são mais baratos.

Uma outra vantagem de se ter iterações curtas e adaptadas a realidade do seu projeto é aumentar o foco da equipe. Na abordagem tradicional, faz-se um esforço imenso para se definir é documentar todo o escopo do projeto. Produz-se uma extensa documentação, muitas vezes em processos alucinatórios. Já participei de times que tentavam planejar prazos 5, 6 anos depois da data atual. Acredite 5 ou 6 anos do momento presente em que estamos. Sem dúvida um exercício de futurologia.

Tentar definir todo o escopo antes de se quer iniciar o projeto é um erro. Precisamos levar em consideração no mínimo a premissa que o mundo dos negócios está em constante transformação, muda-se muito rápido. Os cenários que temos hoje, certamente não serão os mesmos que teremos daqui a 5 anos. As necessidades poderão ser outras, mas nós ainda esperamos que os planos não mudem, ou que mudem pouco.

Por isso, empenhe-se nas duas ou três primeiras iterações a estabelecer um período adequado para as iterações restantes. Lembre-se de seguir com o período estabelecido até o final do projeto. Uma boa dica é reservar um tempo para o não planejando e ir ajustando esse tempo com o time. A tendência é que este tempo diminua com a evolução do projeto e com a maturidade do time.

1. Para saber mais sobre este dado leia o post publicado pelo Mike Cohn em https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used

2. O Mapa não é o território é um dos 5 principais pressupostos da Programação Neurolinguística. O Mapa que no caso é o nosso plano de projetos dificilmente corresponderá ao campo em que vamos executar nosso projeto. O cenário é incerto. Contém riscos, cultura organizacional, mudanças tardias e outras causas que podem tirar o projeto do trilho. Para Robert Dilts os melhores mapas são aqueles que nos oferecem mais escolhas.

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Estimativas ágeis

mundo-agil-rodrigo-zambon-agilidade-estimativa-burndownRecentemente fui chamado para facilitar mais um treinamento de MS Project, e eu recusei. Algumas empresas se orgulham de ostentar na parede um belo gráfico de gantt para representar as relações entre as tarefas, os recursos necessários e a cronologia de entrega dos pacotes.

É impressionante a precisão. Em umas das minhas visitas consegui identificar que daqui a exatos 8 meses, ou seja, no dia 22 de novembro o recurso John Doe estará fazendo cotações de preços para compra de cadeiras, sendo que estará alocado part time no projeto e que para concluir esta atividade, ele depende do layout da sala. Vale lembrar aqui que todos os requisitos desta cadeira estão devidamente definidos aliás, todos os requisitos deste projeto já estão definidos.

Estimativas como as descritas acima são comuns e apresentam um alto grau de precisão, porém o percentual de acerto é baixíssimo. Outras questões são as seguintes: será que os requisitos permanecerão os mesmos? Será que daqui a 8 meses, ao invés de cadeiras não seria melhor comprar bancos ou sofás? E se o projeto for abortado, de que valeu todo aquele esforço de planejamento?

Estimativas sem acurácia são frequentes no planejamento tradicional. Por exemplo, se eu afirmo em meu cronograma, que determinado pacote de trabalho será entregue no dia 02, essa é uma estimativa de alta precisão, independente do dia real de entrega. Entretanto se ele ficar pronto no dia 15, essa estimativa foi completamente sem acurácia e errada.

Muitas de nossas estimativas são passadas sem se calcular o mínimo de esforço necessário para concluir a tarefa. Às vezes, passamos para agradar o cliente, ou não o perder. Talvez porque queiramos agradar o gerente ou até por medo de sair do projeto.

Uma das características do Gerenciamento Ágil de Projetos é que podemos começar o projeto com os requisitos que temos disponíveis. Podemos montar o nosso backlog à medida que avançamos no projeto. O esforço inicial de coleta de requisitos no gerenciamento tradicional leva tempo, e um esforço considerável da equipe, dependendo da complexidade do projeto.

O produto é construído em ciclos de iterações, e em cada um destes ciclos é apresentada uma pequena parte do produto. A primeira sprint, certamente representará o que gera mais valor para o cliente, pois o backlog é priorizado de acordo com o ROI. Os itens na parte superior do backlog são mais detalhados e permitem maior compreensão por parte do time.

O mais comum para se estimar tempo no scrum, mesmo que de forma relativa, são os story points. Na verdade, estão mais voltados para o esforço, do que propriamente tempo. O time de desenvolvimento é o único responsável para definir o tamanho das estórias. As melhores pessoas para estimar o esforço é quem desenvolve o produto. Parece obvio, mas isso é ainda muito ignorado em projetos. Acredite!

Uma alternativa para identificarmos o trabalho que ainda precisa ser feito, e também uma forma visual de acompanharmos o desempenho do time é o gráfico de sprint burndown. O gráfico mostra a quantidade de pontos de estórias no eixo y e no eixo x os dias relativos a sprint atual.

Muitos times ágeis optam por não marcar a linha ideal para evitar cobranças desnecessárias.

Vamos tornar o Mundo mais Ágil. Até o próximo artigo!

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Responder a mudanças mais que seguir um plano

rodrigo-zambon-mundo-agil-responde-mudancas-mais-seguir-plano-artigo-manifesto-agil-declaracao-interdependenciaO título deste artigo é muito familiar, pois trata-se um valor ágil. Está escrito no manifesto. Não significa que não vamos ter um plano, ou ainda que não vamos segui-lo. A questão chave é que se tivermos que escolher entre aplicarmos uma mudança para gerar valor para o cliente, ou seguir cegamente um plano, vamos optar sempre pela primeira opção.

A princípio isso, para o gerenciamento tradicional isso pode soar um pouco estranho: Mas nunca teremos o escopo fechado? Como vou entregar a composição de custos deste projeto ao meu cliente? Mudar sai caro, vou ter que mudar toda hora? E a definição dos requisitos, não está fechada? Mas nós temos a assinatura no termo de abertura.

As mudanças são inevitáveis dentro de um projeto. O gerenciamento tradicional foca no acompanhamento do plano, e principalmente nas restrições de escopo, tempo e custos. O sucesso é medido pela adequação a estas variáveis, deixando para segundo plano a satisfação e o valor para o cliente. No gerenciamento ágil, estamos focados em receber e assimilar as mudanças da melhor forma, conscientes de que elas irão acontecer.

No ágil, vamos inverter a prioridade. A meta é gerar valor e entregar sempre produtos com qualidade. De preferência ao final de cada sprint, para que o cliente possa participar da construção do produto e oferecer feedback frequente. No gerenciamento tradicional a entrega é feita no final e a prioridade é seguir o plano, guiado pelas restrições.

A adaptação do processo e a inspeção do produto são pilares fundamentais para as boas práticas ágeis. Ao final de cada sprint, o time se reúne com o cliente para obter as considerações e ouvi-lo. As mudanças podem ocorrer neste momento, mas precisamos desconstruir o mito de que não há controle. O Product Owner participa e conversa. Negocia se o que o cliente está pedindo faz ou não sentido. Não é só entregar o que o cliente quer, vamos entregar o que ele precisa.

Trazendo para o cenário prático, o que vai determinar um de seus diferenciais no gerenciamento de projetos é a sua capacidade de se adaptar as mudanças. O quão rápido você consegue reagir e flexibilizar seu time para atender uma demanda não antes prevista?

A Declaração de Interdependência diz que “Esperamos incertezas e gerenciamos levando-as em conta, por meio de iterações, antecipação e adaptação.”, ou seja não vamos seguir um plano obsoleto só porque está escrito lá, se tivermos que mudar, isto será feito conforme necessário.

Ainda na Declaração de Interdependência temos a seguinte afirmação “Entregamos resultados confiáveis, engajando os clientes em interações frequentes e propriedade compartilhada”. Isto amplia a participação do cliente, engajando como parte do time, como um colaborador. Diferente do tradicional que o cliente só participa no início quando impõe um requisito, e no final quando recebe o produto, no ágil ele é parte fundamental na construção.

Para finalizar, segue abaixo a conhecida pirâmide das restrições no gerenciamento tradicional e a mudança para o gerenciamento ágil:

pirmaide-tradicional-agil-rodrigo-zambon-mundo-agil

Restrições são importantes variáveis, mas não são a meta do projeto.

Vamos tornar o Mundo mais Ágil. Até o próximo artigo.

Para saber mais:

Manifesto Ágil: http://agilemanifesto.org/

Declaração de Interdependência: http://pmdoi.org/

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Ágil precisa ser os dois: iterativo e incremental

rodrigo-zambon-mundo-agil-agile-iterativo-incrementalBom, o guia Scrum nos fala que “O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.”, mas o que vem a ser uma abordagem iterativa e incremental.

Muita gente usa estas palavras sem saber a correta definição. O texto abaixo publicado no site do Mike Cohn é um bom referencial para entendermos a diferença dos termos.

Boa leitura!

O texto abaixo foi originalmente publicado no informativo mensal de Mike Cohn. Se você gostar do que você vai ler, faça sua inscrição para ter este conteúdo entregue na sua caixa de entrada antes de ser postado no Blog.

Scrum, como todos os processos ágeis, é iterativo e incremental. Uma vez que estas palavras são usadas com muita frequência e sem definição, vamos defini-las.

O processo iterativo é aquele que progride através de refinamentos sucessivos. A equipe de desenvolvimento apresenta uma parte de um sistema, ciente de que está incompleto ou deficitário em algumas (talvez muitas) partes. A equipe então refina estas partes até o produto apresentar um nível satisfatório. A cada iteração, o software é melhorado através da adição de um maior nível de detalhe.

Por exemplo, numa primeira iteração, uma tela de pesquisa pode ser codificada para suportar apenas o tipo mais simples de pesquisa. A segunda iteração pode adicionar critérios de pesquisa adicional. Finalmente, uma terceira iteração pode adicionar tratamento de erros.

Uma boa analogia, é escultura. Em primeiro lugar, o escultor seleciona uma pedra de tamanho apropriado. Em seguida, escultor vai esculpir a forma geral na pedra. Neste ponto, pode-se talvez distinguir a cabeça e o torso, e discernir que o trabalho final será o de um corpo humano e não de um pássaro. Em seguida, o escultor refina seu trabalho adicionando detalhes. No entanto, o escultor não vai ter nenhuma área completa até todo o trabalho estar completo.

O processo incremental é aquele em que o software é construído e entregue em pedaços. Cada peça, ou incremento representa um subconjunto completo de funcionalidades. O incremento pode ser pequeno ou grande, talvez variando de uma simples tela de login a um conjunto altamente flexível de telas de gerenciamento de dados.

Cada incremento é totalmente codificado e testado, e a expectativa comum é que o trabalho de uma iteração não precisará ser revisitado. Um escultor incremental iria pegar uma parte do trabalho e se concentrar inteiramente sobre ele até que seja concluído. Ele pode selecionar pequenos incrementos (primeiro o nariz, olhos, boca e assim por diante) ou grandes incrementos (cabeça, tronco, pernas e depois os braços). No entanto, independentemente do tamanho do incremento, o escultor incremental tende a terminar esse trabalho completamente.

Scrum e Ágil são tanto incrementais, quanto iterativos. Eles são iterativos quando se planeja o trabalho de uma iteração, para ser melhorado em iterações subsequentes. Eles são incrementais porque o trabalho concluído é entregue ao longo do projeto.

Para melhor ilustrar as diferenças entre iterativo e incremental, vamos considerar a construção de um site de forma iterativa, mas não de forma incremental. Para fazer isso, a equipe iria construir um pouco de cada parte do site – alteração de perfil, busca, anúncios, etc. A equipe, então, vai rever todas as partes, melhorando cada uma delas.

A equipe deve rever todas as partes, aplicando as melhorias, desta forma todo o site está ficando um pouco melhor.

Em seguida, vamos considerar o desenvolvimento do mesmo site com uma abordagem puramente incremental, não um processo iterativo. Se um site de namoro fosse construído de forma incremental, o time iria construir um perfeito sistema de gerenciamento do perfil antes de começar qualquer outra parte do site. Depois, eles então, iriam construir a segunda área – pesquisa – e passariam para a terceira área. Cada área funcional concluída deve ficar perfeita, antes de se iniciar a próxima.

Nem iterativo e nem incremental são bons isoladamente. Mas juntos – como eles estão no Scrum – são fantásticos.

Texto Original: https://www.mountaingoatsoftware.com/blog/agile-needs-to-be-both-iterative-and-incremental

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Revolução ágil

rodrigo-zambon-mundo-agil-agile-revulocao-agilComo você está gerenciando seus projetos? Eles estão ocorrendo forma de simples e leve ou você está apegado a planos e mais planos desatualizadoss, documentos desnecessários e reuniões intermináveis? Sinto muito, mas se você conduz projetos assim, está correndo um sério risco de ficar obsoleto.

É verdade que a natureza do trabalho está mudando. Os modelos startups estão aí para nos mostrar exatamente isso. A criatividade e a inovação são características destas empresas que buscam atender o cliente rapidamente e ao menor custo possível. Ou seja, interpretam o mercado, identificam necessidades e respondem com muito mais rapidez. As grandes corporações criam suas próprias startups, para responder com agilidade questões pontuais, pois a estrutura pesada e burocrática não fornece condições.

Os novos produtos ou serviços lançados por startups muitas vezes são oferecidos a um custo mais baixo e com qualidade equiparada. A disrupção ocorre quando estas empresas atingem fatias de mercado ora negligenciadas, criando um mercado totalmente novo. Recentemente o Institulo Gallup publicou que apenas 29% dos consumidores são fieis as organizações. Os outros 71% estão abertos a consumir em qualquer outro lugar.

Criar novos mercados e novas soluções em cenários como os de hoje é um desafio. O mundo do desenvolvimento de produtos é cada vez mais dinâmico e incerto e geralmente os erros ocorrem porque somos lentos demais nas tomadas de decisões. A inércia dos líderes de projetos pode custar caro na hora de decidir.

O Gerenciamento de Projetos precisa passar por uma transformação, para responder mais rápido as mudanças e atender as expectativas de um cliente que é influenciado diariamente pelo mercado, seja através de novas ofertas e soluções inovadoras. Precisamos resistir à tentação de colocar mais um artefato, mais um documento, mais uma planilha que em muitos casos não agrega valor no produto a ser entregue.

Formulários de controle de mudanças, comitês gestores, escritórios de projetos com indicadores desnecessários, e por aí vai, torna-se um caminho muito longo para um possível aceite de uma mudança. Pode ser que quando finalmente for aceita, já tenhamos que mudar de novo. O quadro atual não vai esperar você percorrer esse caminho.

Na fase de planejamento temos um outro agravante: será que precisamos ter todos os detalhes na fase inicial para começar a executar? Acredito que não. Coletar requisitos e ouvir as expectativas dos clientes é extremamente importante, mas o mais importante são os feedbacks iniciais para direcionar sempre o projeto para o sucesso. Requisitos mudam, e a mudança é muito bem-vinda, caso seja para gerar mais valor para o cliente.

Por último, seja criterioso na escolha do líder do projeto. Ele não pode mais ser escolhido aleatoriamente, não pode ser aquele funcionário cumpridor da burocracia, seguidor de um plano muitas vezes obsoleto. Não pode mais ser uma pessoa cumpridora de cronograma. Uma qualidade essencial é saber manejar a sua equipe, reconhecer que não conseguirá fazer nada sozinho e que times motivados entregarão melhores resultados. Uma outra qualidade é ter destreza para remover os obstáculos que impedem seu time de alcançar os objetivos.

O pensamento adaptativo, e a flexibilidade irão ajudar você a mudar seu modelo mental do tradicional ao ágil.

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

A educação do futuro é ágil: eduScrum

rodrigo-zambon-mundo-agil-agile-educacao-futuro-eduscrumNeste artigo vamos fugir de temas técnicos para falar um pouco sobre a educação do século XXI. Como um professor holandês uniu educação e scrum.

Recentemente participei do Business Transformation Summit, evento que encoraja os participantes a pensarem sobre as transformações que podemos fazer, a fim de nos adaptarmos aos desafios que estão por vir. Não foi um evento onde o speaker fala, fala e fala e a plateia apenas escuta, foi um evento colaborativo, prezando pela cocriação de ideias e amplos debates.

Um dos temas abordados foi a reflexão de como será a educação no século XXI. Será o aluno o protagonista do seu próprio aprendizado? A educação a distância é o futuro? Por que estudar com início e fim definidos e com disciplinas pré-estabelecidas? Precisamos de horário ou vamos estudar no nosso tempo?

Não temos resposta para as perguntas acima, para alguns mais ortodoxos isto ainda é uma realidade distante que não pode ser mudada, para outros a mudança precisa ser feita levando-se em conta principalmente que a informação não é mais privilégio de poucos.

Aliar as práticas ágeis de gerenciamento de projetos ao aprendizado pode ser um meio para respondermos algumas das perguntas acima. Foi exatamente isto que um time de professores holandeses liderados pelo professor Willy Wijnands fez: adaptaram o scrum a sala de aula.

Pode ser que você não seja familiar com o Scrum, mas provavelmente você tem alguma experiência aprendendo ou ensinando algo, seja em escolas ou faculdades. O eduScrum junta educação ao scrum.

Scrum é framework, inicialmente criado para gerenciar projetos no setor de tecnologia, entretanto pode ser aplicado em praticamente todas das áreas de conhecimento. Sutherland, um dos criadores do scrum, atribui como características do framework: a capacidade de autocorreção, a evolução constante e uma fortíssima adaptabilidade.

O eduScrum é apresentado aos alunos no primeiro dia de aula, e a primeira coisa a se fazer é escolher as equipes, ou seja, com quem querem trabalhar. O importante não é aprender a trabalhar sozinho, mas sim trabalhar juntos. Após a definição dos times cada um faz a sua apresentação, enfatizando os pontos fortes e o que tem a contribuir com a equipe.

O professor atua como o Scrum Master, ele é coach dos alunos. Ele identifica através dos quadros Scrum onde está a dificuldade e explica rapidamente algum conceito mais complexo, às vezes, escolhe algum item da coluna “concluída” e faz um breve teste oral. Os alunos simplesmente abrem seus livros e começam a aprender sozinhos, ou melhor a ensinar uns aos outros.

No Brasil, o framework eduScrum já foi utilizado em 3 turmas do terceiro semestre do Curso Superior de Sistemas para Internet, do Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Sul (IFRS), conforme descrito pelos professores Karen Selbach Borges, Marcelo Augusto Rauh Schmitt e Silvana Marx Nakle. No artigo os autores puderam comprovar na prática os benefícios da aplicação do eduScrum.

Para saber mais:

Informações sobre Scrum: http://www.scrumguides.org/ Neste site você pode fazer o download do Guia do Scrum: um guia definitivo para o Scrum – As regras do jogo.

Artigo dos professores Karen Selbach Borges, Marcelo Augusto Rauh Schmitt e Silvana Marx Nakle: http://www.cinted.ufrgs.br/ciclo23/arti-aprov/127902.pdfOs professores estão desenvolvendo um software para auxiliar na aplicação do eduScrum.

Site Oficial do eduScrum: http://eduscrum.nl/ No site você pode fazer o download do Guia eduScrum

O Bussines Transformation Summit foi um evento realizado em São Paulo nos dias 07 e 08 de outubro deste ano sobre transformação em diversas áreas de conhecimento. O evento foi idealizado por José Davi Furlan e Leandro Jesus.http://www.businesstransformation-br.org/

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.