Fork me on GitHub

Viagens, opiniões e afins

by Andre Fonseca


Processo por processo não resolve. Aceite e mude.

A gente sabe quando está mais consciente de algo quando é capaz de ver as falhas dele. Hoje está na moda dizer que é ágil ou que sua empresa usa algum “método ágil”.  E por aí segue as diversas sopas de letrinhas e nomes pomposos.  A pouco tempo atrás a tábua de salvação era o Scrum que agora já é “jogado a fogueira” pelos seus antigos defensores e em seu lugar ouço muito de Kanban, lean, etc.  Eu pessoalmente não gosto de modas, prefiro seguir aquilo que me facilite a vida e torne-me mais produtivo, feliz, etc.

Antes de mais nada, deixem eu dizer qual é o significa, para mim, de ser ágil: Pelo dicionário, ser ágil é alguém que se move com facilidade e preteza; para mim ser ágil é ser rápido e resiliente as mudanças; é ir além de aceitar as mudanças… é entender que ela é uma característica da vida.  Quando falamos de TI isso fica mais focado ainda na questão de ser rápido. Gosto de usar a figura de barcos: ser ágil é ser como um pequeno veleiro que pode mudar de direção facilmente.

Frente a isso fica mais fácil entender o que vou dizer a seguir: acredito que nem 1% das empresas que dizem ser ágeis se encaixam na “minha definição”.  Penso, sinceramente, que elas apenas trocaram de nomes, no fim é exatamente as mesmas coisas só que trocaram suas roupas. Antes eram cronogramas, agora são cartões com bluetaks pelas paredes, burns downs e quadro brancos.  Antes tinhamos gerentes, agora temos os Scrum Masters.

Uma outra coisa que considero ruim é que as pessoas não conseguem entender que devemos fazer aquilo que nos torna mais feliz e produtivos. Se controle em cascata deixa a nossa equipe mais produtiva será isso que irei usar. Simples assim. Seguir os processos ips letri é bom quando a gente não está acostumado e ainda não está maduro nele. Entretanto, depois de certo tempo seguir o processo e fazer as coisas só por que dizem que deve ser feito não é nada inteligente.

Uma vez ouvi uma história dos macacos que são colocados numa jaula. Cada vez que algum deles tentava pegar uma banana, todos tomavam uma descarga elétrica. Assim, com o tempo, foram trocando os macacos um a um. Eles desenvolveram um comportamento interessante de bater naquele que tentasse acessar a banana para evitar os choques.  Mesmo tempos depois tendo desligado os choques, os novos habitantes da gaiola batiam naquele que tentava acessar as bananas reproduzindo o comportamente sem nem mais saber porque.

Isso acontece o tempo todo em nosso meio. As pessoas fazem daily meetings e nem sabem mais porque… fazem por que tem que ser assim e ponto final. Cara se na sua equipe já existe a comunicação o daily pode ser uma grande perda de tempo. Pense nisso.  Reviews e retrospectivas também podem ser perdas de tempo. O próprio XP diz que é interessante que os conflitos sejam resolvidos o quanto antes e que a comunicação deve ser permanete e fluída. Assim ter uma reunião para conversar, para mim, por si só é um contra senso.

Ultimamente, o meu time tem usado algo que se assemelha mais ao kanban: kanban é a ferramente visual e não o processo. O processo é algo mais Lean – tentamos sempre manter o fluxo de entregas de forma constante e sem interrupções.  Procuramos sempre o que é melhor para nossa produtividade. Eliminar desperdícios mesmo que isso seja parte do próprio processo como se diz no livro. Inteligência é usar algo e adaptá-lo a sua necessidades. Seguir processos sem questioná-los é escolher não evoluir e correr o risco de acertar.

Colar post it na parede não diz que você é ágil. Ser ágil, para mim, é ser adaptativo. Mudar e procurar sempre o gradiente máximo.  Toda vez que leio o manifesto ágil, vejo ali um pedido para sermos mais inteligentes e produtivos. Usar processos não é ser ágil.. trocar waterfall por scrum não vai magicamente fazer entregar mais. É algo mais perto da cultura que deve ser mexida.

 

Published by Andre, on março 15th, 2011 at 12:07 am. Filled under: agil,atualidades,scrum Tags: , , , 5 Comments

Culpa nem sempre é do processo.

Muito tenho escutado neste últimos dias sobre a questão do sucesso ou não do uso de metodologias ágeis.Principalmente com relação a entregas. Primeiro preciso dizer que não sou um doutor no assunto, nem pretendo ser, muito menos um profundo conhecedor, mas considero que tenho uma pequena vivência no assunto que me permite tecer alguns comentários sobre o assunto.

Uma das coisas que vejo que o pessoal parece não entender em minha humilde opinião, é que usar metodologia ágil você irá entregar o sistema mais rápido que usando waterfall, por exemplo. O que acontece que, primeiro, você foca no retorno ao investimento: isso significa dizer que você irá entregar não tudo desejado mais o que tiver mais valor para o seu cliente. Isso por si só já garante, na maioria dos casos, um cliente satisfeito, pois num tempo menor ele tem um produto perto do valor desejado. Outra coisa que o ágil faz, novamente em minha visão quase sem querer, é quebrar a entrega em partes. Isso faz com que o cliente tenha uma sensação melhor pois sempre tem um coisa nova chegando, uma entrega  contínua. O ágil prega essa quebra pois ele acredita que nunca se sabe de partida exatamente o que se quer e a medida que vamos vendo a coisa aparecer que temos maior clareza de objetivo e com isso vamos adaptando durante a caminhada o nosso objetivo. Um replanejamento contínuo.
A questão que ao focar nas funcionalidades que darão maior retorno imediato para o investimento  fica uma brecha para um possível erro que pode ser fatal para a sobrevivência da agilidade. Isso porque, o cliente, ou o representante do cliente, devido a um lista de coisas a fazer grande, pode se dar por satisfeito por algo que ainda está incompleto e que, pode e deve ser melhorado dependendo do negócio do produto.
A percepção desse problema está muito ligada ao tipo de negócio que estamos trabalhando. Pode ser que seu cliente só sentirá falta do resto daqui a anos e assim, sem criar grandes traumas, irá solicitar as evoluções e todos seguiremos com nossas vidas felizes e satisfeitos. A coisa piora quando estamos num mercado extremamente competitivo e cujo o peso da inovação é muito grande. Mercados onde o tempo certo faz toda a diferença entre o sucesso e o fracasso tende a aumentar em 100 vezes conflitos dessa natureza.
Voltando ao que eu disse lá em cima, não acredito que ser ágil me faça entregar mais coisa em menos tempo; acredio que ser ágil me faz entregar mais valor em menos tempo. Isso faz toda a diferença. Mas quando não respeitamos a natureza incremental do processo imbutimos uma falha nele. E não adianta dizer no futuro que o problema está no processo pois “você” o subverteu. Novamente. em muitos desses casos, o que o ágil sempre acaba fazendo é mostrar esse problema e deixá-lo evidente.
A questão que ao colocarmos um produto no ar, restrigindo mais a nosso mundo de ti e a um mercado de web, o quanto antes possível com o maior valor possível, não significa que ele esteja pronto. Significa que nosso primeiro ciclo fechou. Precisamos seguir. Continuar a incrementar nossa aplicação e, em conjunto com o cliente, criar uma coisa única para o usuário. Parar no primeiro passo e o mesmo que não fazer. Vai ficar a sensação de incompleto.
Outra coisa é que quando decidimos por entregar coisas em menos tempo o fazemos por que queremos um retorno rápido. Por meio desse retorno rápido iremos ajustar nossos processos e objetivos para melhorar ainda mais o produto. Se apenas lançarmos e partirmos para fazer outra coisa estamos perdendo uma excelente oportunidade de realizar a milha extra que todos os clientes sonham.
Sei que convencer o cara que assina o cheque que antes de partimos para o próximo projeto deixe a gente invistir mais um pouco de tempo no atual é difícil. Na cabeça dele o prédio está lá e por isso a obra terminou. Mas TI não é construção de prédios… ela é mais parecida com pintura de quadros. Uma vez li ou ouvi ou vi (não sei) que um artista nunca termina nada, ele a abandona pois, sempre acredita que possa melhorá-la. Isso não significa que a partir de agora todos nós vamos abandonar nosso projetos (não se matem ainda clientes). Significa dizer que a primeira versão nunca deve ser a definitiva. Ela por si só é inacabada. Precisa de um novo ciclo.
Somente temos idéia das interações das cores num quadro depois de pintá-lo. A experiência nos ajuda a antecipar o conhecido mas sempre teremos novidades. Sempre teremos novos usos a descobrir, etc.
Parte dessa confusão reside num mal entendimento motivado por nós. Vendemos que quando usamos Scrum, Lean, ou qualquer outra nome de processo, seremos mais rápidos, mais produtivos, maior qualidadde. Vendemos um contexto utópico. Só esquecemos de dizer que isso acontece por um processo de reciclagem. Isso mesmo reciclagem. Criamos, colocarmos no ar, coletamos os dados, esmagamos e refazemos tudo. Porém nosso cliente, que ainda possui requícios de waterfall, pensa que tudo estará na primeira entrega. Ele ainda não concebe que precisamos de mais indas e vindas.
Published by Andre, on junho 26th, 2010 at 11:08 pm. Filled under: Informática,scrum Tags: , , , , , 2 Comments

Histórias Técnicas – eles devem estar no backlog?

Jack Milusnk, em seu blog The Agile Buddy Blog, escreveu um excelente post sobre a questão da histórica técnica. Em tomei a liberdade de escrever uma versão (não tradução) em português do texto. Para quem quiser ler o texto original, acesso o post aqui. Comentários com ajuda na tradução e opiniões são bem vindo.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>
A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog.
Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:
“O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”
Então, qual é a resposta correta?
Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.
Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:
Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog. Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:”O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”Então, qual é a resposta correta? Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Published by Andre, on janeiro 21st, 2010 at 1:41 pm. Filled under: agil,scrum Tags: , , , , , , No Comments

Qual melhor dia para começar e terminar um sprint – Jack Milunksy

Pessoal, hoje li no blog Agile Buddy do Jack Milunsky um interessante e pequeno artigo em que ele reflete sob qual seria um bom dia da semana para começar e terminar o sprint.  Eu tomei a liberdade de escrever uma versão em português para vocês. Caso queiram ler o original cliquem aqui

Primeiro, que fique claro que o tamanho dos sprints sempre devem ser consistentes.De qualquer jeito, experimente 1 fazer sprints com duração de 1, 2 ou 3 semanas mas uma vez que acha o melhor cenário adote-o e siga-o. Isto é importante para definir um ritmo na empresa. Entretanto, a questão é quais dias são os melhores para começar ou terminar o sprint. Até agora, eu tenho sido um fã de começar na segunda e terminar na sexta-feira. Me parece ser uma cadência natural e os dias acabam por se tornar pontos de transição lógica.
Porém, nesta semana, houve uma discussão no forum de desenvolvimento Scrum, e um número razoável de pessoas disseram ser a favor de começar não na segunda e sim na terça; terminar na quarta e não sexta. Os motivos para isso foram os seguintes :
1 – Existem muitos feriados na segunda e sexta que acabam por interromper o ciclo e com isso o ritmo.
2 – Se tiver algum problema no sprint e ele termina na sexta, isto possívelmente forçará o time de trabalhar no final de semana – algo normalmente evitado pela comunidade ágil.
3 – Sexta feira acaba sendo um dia não muito produtivo pois o pessoal tende a se dedicar a demos, restropectivas, etc.
Pelo aprendizado, eu preciso experimentar isso.
Qual tem sido sua experiência?
Jack
Published by Andre, on janeiro 7th, 2010 at 1:23 pm. Filled under: agil,atualidades,scrum Tags: , , , , 1 Comment