Rafa Nascimento

O futuro da Agilidade não é bonito

Posted in futuro by Rafa Nascimento on 30/10/2012

Concordo com o que Jurgen Appelo diz em seu post I don’t care about “Agile”.

Muitos fatos e experiências levam-me a crer que o Agile não tem um futuro necessariamente bonito. Embora a vontade, obviamente, seja oposta, é inegável o momento controverso pelo qual a filosofia passa. Compartilho abaixo alguns fatores que chamam a minha atenção e convido-os a uma reflexão.

  1. A figura mais emblemática rumo à adoção da agilidade e à mudança cultural necessária à agilidade, o Scrum Master, é um papel cada vez menos requisitado nas empresas. No ano de 2011, uma média de 8 a 10 anúncios de emprego buscando um Scrum Master eram encontrados para a cidade do Rio de Janeiro. Hoje, nenhum é encontrado. Muitos Scrum Masters que emergiram, emergiram de vontade de ver um novo ambiente de trabalho. Poucos têm o preparo necessário para exercer o papel, que, hoje, é mesclado por muitas empresas ao cargo de desenvolvedor, ao papel de líder técnico ou até mesmo ao papel do gerente de projetos. “Mas o Scrum Master é um papel!”, muitos dirão. Sim. Segundo o PMBoK, o Gerente de Projetos também.
  2. Não houve e nem está havendo uma mudança substancial na disciplina de gerenciamento de projetos, documentada hoje em dia pelo PMI. Muitos anúncios buscando gerentes de projetos que citam os métodos ágeis passam a impressão de que o conhecimento requerido é um “backup” para o caso de aparecerem projetos que fujam aos tradicionais, guiados pelo RUP. Resta a esperança de que gerentes de projetos tradicionais incorporem os princípios ágeis e que os líderes ágeis compreendam que o conhecimento sobre gerenciamento de projetos só tem a acrescentar ao trabalho. E resta a esperança de que a nova versão do PMBoK traga uma mudança substancial na disciplina considerando-se a gestão ágil, e não apenas citações.
  3. Uma sensação de final de “oba-oba” paira no ar. O Scrum foi inegavelmente o framework ágil de maior sucesso que apareceu, o método Kanban, até então, não tem mostrado grandes resultados e nenhum dos frameworks ágeis, nem mesmo o XP, pelas experiências que tive até hoje, conseguem manter as pessoas imbuídas em manter o processo funcionando minimamente bem. No mínimo respeitando os princípios do Agile e do Lean. Isso se deve a uma adoção mecanizada dos processos e a ausência de um trabalho de mudança cultural, que é muito mais complexo e demorado. Fica a impressão de modismo. A impressão de que a agilidade não vai ultrapassar a barreira da novidade. Vale lembrar que, apesar de a filosofia ágil ter mais de 10 anos, somente entre 2006 e 2008 ela começou a adentrar grandes empresas.
  4. Muitas empresas que adotaram a agilidade, hoje, estão tendo uma “recaída”de comando-controle, basicamente, por expectativas de produtividade não atendidas. Mais uma vez, fruto da falta de mudança profunda na cultura, que faz aferir a produtividade da mesma forma como aferia-se antes da “mudança” e da subestimação do fator humano no ambiente de trabalho. Além disso, empresas famosas por seus ambientes favoráveis aos profissionais da informação e criação, como a Google e o Facebook, evitam afirmar que utilizam métodos ágeis.
  5. A crença de que a filosofia ágil é algum método milagroso que transforma todas as pessoas que são tocadas em pessoas altamente comprometidas. É fato que a atenção ao fator humano na agilidade é imensamente maior, mas pessoas que não são comprometidas com as metas da empresa estão por toda a parte. Apesar da agilidade tratar essas pessoas de forma diferenciada, com compaixão e buscando encontrar a melhor equipe e projeto para elas, em certos casos não há solução que não a dispensa do profissional. Nem sempre há final feliz. E profissionais “espertos” e imaturos existem em qualquer lugar.
  6. Foco exagerado no processo e baixo na gestão do ambiente de trabalho. Uma das formas mais efetivas de provocar uma mudança cultural é mudar o próprio ambiente de trabalho e fazê-lo fluir “no sangue”. E exemplos não faltam: Google, Microsoft, Facebook, Philips. Na minha opinião, a parte mais efetiva de uma mudança concreta rumo aos princípios do Agile e do Lean é a mudança do ambiente de trabalho e a sua adequação ao trabalho com a informação e criatividade. E mais do que fazer a transformação: garantir que as novidades são úteis e são utilizadas pelos profissionais. Cansei de ver videogames e salas de descompressão “espetaculares” disponíveis aos profissionais que são vigiadas ou só podem ser usadas fora do horário do expediente. Acreditar que as mudanças podem gerar aumento de produtividade e incentivar o funcionamento de todas as iniciativas de ambiente. Se o foco estiver todo no processo, há grandes chances de ser só mais um processo que foi experimentado pela empresa.
  7. Negligência ao histórico dos times. A filosofia ágil é baseada em experimentação. E não há experimentação se não há estado anterior e estado atual. Métricas de performance são importantes para que as ações de melhoria contínua possam ter chance de ser efetivas. Métricas de satisfação do cliente são importantes para garantir que o planejamento dos esforços está apontando para a melhor direção possível.

Enfim, se continuarmos ignorando estes e outros fatores que, talvez, nem eu perceba, definitivamente há grandes chances de a filosofia ágil ser só mais uma moda. Assim como a Qualidade Total e a mais recente Re-Engenharia.

Como medir a produtividade de times ágeis

Posted in métricas by Rafa Nascimento on 22/10/2012

Um dos mantras mais repetidos em uma cultura ágil é “melhoria contínua”. Porém, pouco se faz de fato para facilitar o surgimento de um verdadeiro fluxo de melhoria contínua em um time ágil. Na maioria das vezes, apenas retrospectivas lúdicas com dinâmicas que visam diminuir o tormento de mais uma reunião e que, com o passar do tempo, por conta de resultados superficiais, perdem o efeito “suavizante” que deveriam ter para que a reunião gere um bom plano de ação. Então, como podemos tornar nossas retrospectivas mais produtivas e factuais? Como podemos ajudar nossos times na árdua tarefa de aferir a sua própria performance? Eis a maneira que encontrei de endereçar estes problemas.

Segundo Patrick Lencioni, em seu livro The 5 Dysfunctions of a Team, um time não pode ser considerado um time de verdade se o mesmo não é capaz de aferir os seus próprios resultados e reagir conforme a informação conhecida. Isso porque não é possível melhorar o seu processo se não há um histórico no qual se basear. A melhoria contínua, enfim, só se torna realidade quando é possível concluir que aspectos do processo são passíveis de melhoria, através de métricas.

Em muitas empresas, métricas são vistas como vilãs pelos times de desenvolvimento de software. Isso porque, durante muito tempo, as métricas foram utilizadas, em grande parte, para promover verdadeiras “caças às bruxas” em times que não vinham colhendo bons resultados. Ou seja, as métricas eram utilizadas, tardiamente, para buscar culpados por falhas e insucessos em projetos. Algumas vezes, métricas eram utilizadas sem um propósito claro, e sim pelo simples fato de que elas deveriam existir, perdendo-se excelentes oportunidades de descobrir problemas antes que eles acontecessem.

Para facilitar o processo de melhoria contínua no meu time, me fiz a seguinte pergunta: o que é interessante como métrica para o meu time, e ao mesmo tempo enxuto? Que métricas deveriam estar presentes em seu dashboard? E para responder a estas perguntas, recorri ao livro Agile Project Management, de Jim Highsmith, e ao triângulo da agilidade proposto por ele.

Segundo Highsmith, projetos ágeis devem buscar o equilíbrio entre valor agregado ao negócio, qualidade técnica e as restrições tradicionais de um projeto (tempo, custo e escopo). Tendo em vista estes prismas, criei um dashboard que oferece métricas para aferir os dados de cada um deles. O dashboard, então, fica dividido em 3 partes: o quão efetivo o time está sendo em trazer valor para a empresa que comprou o projeto, o quão efetivo o time está sendo em desenvolver um produto de alta qualidade e o quão efetivo o time está sendo em entregar valor e qualidade dentro das restrições de tempo, escopo e custo do projeto.

Para o prisma de valor agregado, por exemplo, utilizo-me de métricas como velocidade (quantidade de story points que um time á capaz de entregar por iteração), lead time (tempo decorrido entre o pedido de uma feature e a disponibilização da mesma em produção) categorizado por story points, tail (tempo decorrido entre a conclusão de uma feature e a utilização da mesma pelo usuário final) e cumulative flow (representando o tempo que cada passo do processo consome durante o desenvolvimento das features).

Para o prisma de qualidade interna, realizo, por exemplo, medições como a quantidade de pares distintos que estão sendo formados por iteração, a quantidade de releases com features e com bug fixes e a quantidade de quebras do CI por iteração.


Por fim, utilizo, por exemplo, um burndown por story points do trimestre e um gráfico de alocação de horas do time categorizado por tipo de atividade para o prisma das restrições de projeto (um empréstimo da galera da Globo.com!).

Desta forma, deixo visível para o meu time a performance de cada iteração e podemos discutir de uma forma mais factual as possíveis melhorias no nosso processo. Retrospectivas lúdicas são úteis em determinadas ocasiões e momentos do time, mas há momentos em que a melhor opção é vasculhar os dados históricos para encontrarmos possíveis pontos de melhoria que talvez não seriam vistos a “olho nu”.

Esqueceram de mim

Posted in papéis, scrum by Rafa Nascimento on 11/08/2011

A principal tarefa de um Scrum Master é curta e grossa: garantir o bom funcionamento do Scrum. Existe uma tarefa implícita nesta frase, que é extremamente desafiadora: educar bons Product Owners. Muitos Product Owners ainda não conhecem seus papéis como deveriam, geralmente têm bastante experiência em projetos de software e raramente são incentivados a criar uma comunidade para que possam desafiar suas certezas em prol de uma nova realidade. Além disso, eles enfrentam a principal mudança que os métodos ágeis trazem consigo: foco nas pessoas como o verdadeiro motor durante o desenvolvimento de um produto, não no projeto. Em um primeiro momento, a cultura ágil privilegia os times de desenvolvimento de produtos, o que torna a adoção da cultura mais fácil para os desenvolvedores. Por conta da dificuldade particular de educar Product Owners, muitos acabam “esquecidos” pelos Scrum Masters e viram verdadeiros pedregulhos no caminho dos times.

Quem é o Product Owner?

O primeiro passo para se educar um Product Owner é saber quem ele é (ou quem ele pode ser). E definir quem é o Product Owner é uma tarefa do Scrum Master. Algumas características ajudam nesse desafio:

Segundo Roman Pichler, em Agile Product Management with Scrum, um Product Owner deve ser:

  • Visionário e executor;
  • Líder e membro do time;
  • Comunicador e negociador;
  • Com poder de decisão e comprometido;
  • Disponível e qualificado.

Levando em consideração tais características, podemos elencar alguns profissionais que podem se encaixar no papel:

Analista de negócio: Este profissional tem a peculiaridade de conhecer bem as regras de negócio de uma organização sendo ele um profissional de TI. Pelo forte foco no produto que a cultura ágil prega, ele acaba sendo uma boa opção por seu conhecimento das necessidades da organização. O problema é que nem todo analista de negócio sabe ou quer medir o progresso do desenvolvimento do produto e resolver, ele próprio, as barreiras de comunicação que dificultam a integração entre as partes de um produto.

Gerente de produto: Pouco explorado, este profissional é utilizado em pouquíssimas empresas. Na minha opinião, é a melhor representação de um Product Owner. É um analista de negócio, que tem responsabilidade sobre o prazo de seu produto e precisa reportar o progresso do desenvolvimento do mesmo aos seus clientes. O único perigo com este profissional é o de ser uma pessoa hiperativa que não consegue esperar que as soluções emirjam do próprio time. Esta atitude pode minar a auto-organização e a auto-gestão do time.

Gerente de projetos: Algumas empresas já tentaram elencar gerentes de projetos como Product Owners. Funciona bem, desde que o profissional consiga se desvencilhar do hábito de comando e controle que seu papel original propõe. Adotando uma mentalidade de coach, de liderança-servidora e focando no produto e na satisfação do cliente acima de tudo, o gerente de projetos também pode se tornar um bom Product Owner.

Usuário-chave: Usuários têm outros afazeres em suas rotinas que não podemos ignorar. Quando estamos falando de projetos pequenos, onde o próprio dono de um empreendimento trata com 1 ou 2 desenvolvedores, o usuário-chave como Product Owner funciona muito bem. Quando o produto começa a crescer e ficar mais e mais complexo, surgem questões tecnológicas das quais um usuário-chave não tem a mínima ideia do que significam. Sem contar que este tipo de Product Owner tem a tendência à otimização local e ignora as questões de integração com outras áreas da empresa dentro do produto. Nesse momento, um usuário-chave como Product Owner pode ser extremamente prejudicial ao produto.

Um bom Product Owner leva todos a bons sprints

Um time Scrum que não tem um bom Product Owner está fadado a fracassos. Os insulmos oridundos deste papel são tão importantes quanto o produto que está sendo desenvolvido pelo time de desenvolvimento. Em todas as experiências que tive com times ágeis, o Product Owner tinha um peso enorme sobre o progresso do time. Negativo ou positivo. Um bom Product Owner sabe motivar o time em prol da sua visão de produto e consegue, facilmente, definir o plano de ação para ter aquele produto, ao final de um projeto ou período. Um mau Product Owner é capaz de segurar o progresso do time inteiro e, mais do que isso, desmotivá-lo por sua falta de visão, clareza e segurança e colocar seu produto em sérios apuros. Sem um bom Product Owner, não há um bom time. Sem um bom time, não há um bom produto.

Coaching, não só mentoring

Para um time de desenvolvedores, o que importa é desenvolver software e ter seu conhecimento constantemente desafiado para que criem boas soluções para os problemas que encontram durante a construção de um produto. Se estamos utilizando Agile ou Waterfall, pouco importa. Desde que todos sintam-se em casa e estejam felizes em estar ali. Em minhas experiências, é relativamente fácil conduzir a adoção de um framework ágil em um time de desenvolvedores. Principalmente porque a cultura ágil favorece seu bem-estar. É um trabalho muito mais forte de mentoring, de ensino, do que de coaching.
No caso do Product Owner, a realidade é outra. Desenvolvedores, designers, testadores. Todos continuam sendo desenvolvedores, designers e testadores. Mas um Product Owner, provavelmente, era gerente de projetos ou analista de negócio. Além disso, a cultura ágil “prejudica”, à primeira vista, o seu tempo de resposta ao cliente. Ele está passando por 2 grandes mudanças: no formato do seu trabalho e no seu próprio papel dentro da cultura. Não há dúvidas: haverá resistência. E tal resistência não é quebrada somente com o mentoring em Scrum do Scrum Master. Este Product Owner vai precisar de um Scrum Master no papel de seu coach, ajudando-o a desenvolver novas competências para uma nova realidade e auxiliando-o no questionamento de suas certezas para descobrir novas certezas. Não é um trabalho fácil, nem breve, mas é fundamental.

Scrum Master: seja parceiro do seu Product Owner

Costumo dizer que, no Scrum, o gerente de projetos foi dividido em 2: Scrum Master, responsável pelo processo e pelas pessoas, e Product Owner, responsável pelo produto. Antes, um gerente de projetos era responsável por processo, pessoas e produto. Fatalmente, e não pouco frequente, seu foco se mantinha no produto, ignorando o bem-estar das pessoas e a manutenção de um bom processo de desenvolvimento do produto. Scrum Masters e Product Owners, juntos, devem representar gerentes de projetos melhores do que os representados em uma só pessoa, pois as atenções estão bem divididas. Se estes dois papéis representam um profissional, para que ambos tenham sucesso é preciso uma colaboração e parceria muito fortes. Apesar das rusgas e discussões que os prazos e negociações trazem, Scrum Masters e Product Owners trabalhando em parceria são vitais para o bem-estar e felicidade do time de desenvolvimento  e, consequentemente, para o time Scrum e, consequentemente, para o produto e, consequentemente, para a empresa e, consequentemente…

Tagged with: , ,

#soudev

Posted in time by Rafa Nascimento on 02/07/2011

O que é desenvolver software?

 

Desenvolver um software envolve muito mais processos e pessoas do que o ato de escrever instruções que programem o comportamento de um computador. Todos os passos, artefatos, ferramentas e pessoas envolvidas em um projeto de construção de um software têm igual importância. Desenvolver um software é o ato milenar de desenvolver um produto. Quando trabalhamos em um processo como tal, não basta contarmos como “sucesso” somente o cumprimento da nossa parte. Durante o desenvolvimento de um software, somos uma comunidade de profissionais com objetivos em comum. Objetivos tecnológicos em comum e objetivos de negócio também em comum. Em um time de futebol, não basta a defesa defender. Isso não configura sucesso. O ataque precisar marcar gols.

 

Um projeto de desenvolvimento de software nada mais é do que uma ferramenta que nos ajuda na organização dos nossos esforços rumo à entrega de um produto de qualidade. Um equívoco comum na área é o fato de o projeto de desenvolvimento de um software tornar-se mais importante que o próprio software sendo desenvolvido. O produto deve ser o centro das atenções. Suas funcionalidades, qualidade e satisfação do cliente. Não as datas e previsões descritas em um cronograma. Deve-se pensar em gestão de produto, e não na gestão de projeto. Deve-se buscar excelência em qualidade de produto, não excelência em cumprimento de prazos.

 

Em um ambiente ágil, colaboração é a palavra-chave para que uma comunidade de profissionais conclua a construção de um produto. Aliás, colaboração é a palavra-chave em qualquer comunidade que possui um objetivo comum. Quando mães buscam seus filhos nas escolas e conversam entre si ponderando sobre a escola, vez ou outra surge um esforço colaborativo para viabilizar reuniões com professores e diretoria que visam buscar melhorias na qualidade de ensino e tratamento de seus filhos. Estas mães formam uma comunidade. Um grupo de pessoas com um objetivo em comum: dar a melhor educação e ambiente possíveis a seus filhos. Em um projeto de desenvolvimento de software, todos, do cliente ao desenvolvedor, devem formar uma comunidade de profissionais que colaboram em prol de um único objetivo: a entrega de um software de qualidade que atenda às expectativas do cliente e de seus usuários. Meu objetivo não é ser um excelente Scrum Master. Mas, sim, ser o melhor Scrum Master para a comunidade onde me encontro. A comunidade que desenvolve o mesmo produto que estou desenvolvendo.

 

Em um ambiente ágil, todos os esforços têm igual importância. Como em uma comunidade. O usuário desenvolve software, o patrocinador desenvolve software, o gerente de projetos desenvolve software, o scrum master desenvolve software, o testador desenvolve software, o designer desenvolve software, o desenvolvedor desenvolve software, o arquiteto desenvolve software. Embora trabalhemos como profissionais especializados, fazemos parte de times. E quando isso acontece, não basta que o nosso trabalho de codificação esteja excelente e o trabalho do designer esteja muito ruim. Se estamos desenvolvendo um produto como uma equipe, precisamos ajudar nossos companheiros designers ou testers a realizarem o seu trabalho também com a mesma qualidade que realizamos o nosso trabalho, e vice-versa. Então, em vez de afirmarmos “a minha parte eu fiz direito”, por que não questionar: como posso ajudar meu companheiro de jornada? O que mais posso fazer para ajudar a construir um produto de qualidade? Não uma tela de qualidade, um código de qualidade ou um planejamento de qualidade.

Tagged with: , ,

O Caminho da Felicidade

Posted in backlog, time by Rafa Nascimento on 12/06/2011

Transparência é um dos valores do Scrum. E é um valor fundamental para que o sentimento de confiança, tão importante em projetos ágeis, cresça saudável em um ambiente ágil. Confiança nos liderados e confiança nos líderes. Confiança nos gestores. Transparência é fundamental para que o foco de um Time em um projeto de desenvolvimento de software mantenha-se única e exclusivamente no problema que é preciso resolver e no software que se desencadeará dessa solução. Perde-se muito em qualidade quando o foco está em sustentar pequenas mentiras. Defender uma realidade que ainda não existe e tentar fazer com que o Time, a todo custo, crie, enfim, a realidade que foi anteriormente pintada. Sem transparência, não há qualidade.

A ferramenta-símbolo de um ambiente ágil de desenvolvimento de software é o kanban. Um kanban ajuda a gerenciar um determinado fluxo de trabalho e, no caso de Times, o mesmo fica exposto para que o Time possa, por si só, gerenciar o seu fluxo de trabalho. É um radiador de informação. Quem quer que passe por ele, será “convidado” a conferir as informações nele contidas. Informações vivas e fáceis de serem lidas ou interpretadas. Diferentemente de um cronograma criado no MS Project, por exemplo. As informações ficam guardadas, como em uma geladeira. Só temos a informação quando a procuramos. Isso, se quisermos procurar. E, mesmo que imprimamos o cronograma e o coloquemos em uma parede, não seria tão simples ler suas linhas ou interpretar suas informações ou seu gráfico de Gantt. O valor de um kanban visual é enorme: radiador de informação. Bem como o Sol, que radia luz e calor sem que precisemos pedir.

Porém, um kanban é uma ferramenta que facilita a visualização do fluxo de trabalho em um sprint. Mas, qual seria uma maneira fácil de visualizar o posicionamento de um Time frente ao projeto em que se encontra? E se o Time quiser saber o percentual de completude de uma release, ou quanto falta para uma release terminar? E sobre o projeto como um todo? Quantos % do projeto cada release represente? E quantos % de uma release representa um sprint? Ou o quanto o Time terá que se esforçar para compensar um sprint perdido e manter uma boa entrega, segundo o próprio, de acordo com a data esperada para o término de uma release? O Product Backlog contém todas estas informações. Porém, estão guardadas em uma geladeira e não são de fácil acesso para o Time. Principalmente para os desenvolvedores e testadores, que estão focados demais em seus trabalhos para calcular todas estas informações. Talvez, sequer sintam vontade de chegar a estas informações. Afinal, quando uma release ou um projeto estiver próximo do seu fim, o Product Owner deixará claro. Ou eles já saberão de antemão, no início de um projeto ou de suas releases, as respectivas expectativas de término no calendário. Mas, e durante os sprints? E durante as releases? Como permitir que um Time monitore facilmente o seu avanço? Como Scrum Master e facilitador, partindo das necessidades que o meu Time tinha em relação ao seu avanço dentro do projeto e do tamanho da sua jornada, criei um jogo chamado “Caminho da Felicidade”, como mostra a figura abaixo.

 


O Caminho da Felicidade é baseado em um “mapa do tesouro”. Ao final do caminho indicado pelo mapa está o final do projeto, o tesouro perseguido pelo Time. A felicidade. A realização individual, coletiva e corporativa. Este caminho possui marcos em % a cada 10% de sua extensão e pequenas bandeiras vermelhas, que representam releases não-entregues. Ao final de cada sprint, o Time mede, sem se preocupar muito com a exatidão da informação, mas sim com a representação gráfica mais fiel possível de seu progresso, o quanto a velocidade atingida em seu sprint contribuiu para que o Time avançasse ao encontro do seu tesouro, em Story Points. A cada release conquistada, o caminho ganha uma bandeira verde no lugar da bandeira vermelha. A bandeira amarela representa 50% do projeto.

Este “tabuleiro” fica preso junto ao kanban do time. E se utiliza de uma peça (um ímã ou adesivo), que representa o Time no Caminho da Felicidade. É responsabilidade do Time atualizar as informações de tamanho de cada release, de acordo com informações conseguidas com o Product Owner, preferivelmente, a cada final de sprint. Desta forma, eles conseguem, também, manter-se atualizados do quanto o backlog está crescendo ou diminuindo perante as negociações do Product Owner com o cliente. Então cada sprint conquistado representa x% de avanço rumo a entrega de uma release e y% rumo a entrega de um projeto.

O Caminho da Felicidade é uma maneira lúdica, simples, eficiente e divertida de encarar o progresso e os percalços de um Time durante a sua jornada rumo ao objetivo maior, que é a entrega de um software que atenda as expectativas do cliente com qualidade. Da mesma forma que um kanban é um radiador de informação para um sprint, o Caminho da Felicidade é um radiador de informação para um Product Backlog, facilitando a visibilidade do tamanho e atualizações do mesmo para o Time.

%d blogueiros gostam disto: