Rafa Nascimento

#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.

Reunião Diária: muito maior do que se imagina

Posted in scrum, time by Rafa Nascimento on 15/05/2011

Uma Reunião Diária é muito mais do que uma simples reunião onde todos os membros do time se juntam para dizer o que estão fazendo. Se fosse tão simples quanto isso, eu diria que a Reunião Diária não tem utilidade alguma, pois simplesmente olhar para o quadro já informa tudo o que cada pessoa está fazendo. Esta reunião é uma reunião de “status report” para o próprio time. Ora, se um time se diz auto-organizável, este deve ser maduro o suficiente ao ponto de que cada um de seus membros assuma compromissos perante o time e o próprio time saiba cobrar estes compromissos. A Reunião Diária é o momento para isso.

Times iniciantes no Scrum ou no XP utilizam a seguinte fórmula para obter o real valor desta reunião e mantê-la “chamativa”:

  • 15 minutos de reunião
  • O que fiz até esta reunião?
  • O que farei até a próxima reunião?
  • O que impede meu trabalho?

O valor envolvido nesta reunião é a comunicação. E a maior utilidade dela é a possibilidade de os membros do time assumirem compromissos perante os outros membros e cobrarem compromissos anteriores. É bom lembrar: aquele grupo específico de pessoas está reunido em prol de um objetivo maior. Em um time, o sucesso é compartilhado e o fracasso também. O que o outro está realizando é tão importante quanto o que eu estou realizando. É tão parte do meu trabalho quanto o código que eu mesmo faço. Isso se chama código comunitário: todo o código gerado pelo time é de responsabilidade de cada um de seus membros. Portanto, se você fez besteira ou está enrolando para terminar uma tarefa, seja humilde o suficiente para se retratar perante o time e agir em prol do seu sucesso.

Quando um compromisso é assumido em uma Reunião Diária, isso quer dizer que, até a próxima, este compromisso estará liquidado. Se não estiver, o mínimo que os outros membros do time devem fazer é se interessar pelo que impediu o compromisso de ser honrado. Uma falha do próprio time pode ter ocasionado isso. Uma falha do ScrumMaster pode estar causando isso.

A Reunião Diária mantém-se curta para que não seja evitada. Assim, caso haja algum problema maior para ser resolvido, outra reunião, entre as partes interessadas ou todos, pode ser iniciada após o status, e todos os outros membros seguem o seu fluxo de concentração. O tamanho e a frequência desta reunião permitem que os membros do time mantenham-se focados pela maior parte do tempo no objetivo do sprint. Sua frequência diária é fruto do tamanho curto de um sprint, e permite que não haja desperdícios ou surpresas durante o mesmo, além de manter o time sincronizado.

Ou seja:

  • 15 minutos de reunião – mantém a reunião relevante e enxuta.
  • O que eu fiz até esta reunião? – O compromisso que eu assumi na última reunião deve estar liquidado nesta reunião. Se não estiver, há um impedimento ou mal-planejamento.
  • O que farei até a próxima reunião? – O compromisso é assumido perante todos os outros membros do time. Respeitar este compromisso é respeitar o time.
  • O que impede meu trabalho? – Impedimentos devem ser relatados ao ScrumMaster. A resolução de impedimentos deve ser cobrada do ScrumMaster.
Tagged with: , ,

Pulsos

Posted in scrum, time by Rafa Nascimento on 16/01/2011

Um dos desafios na utilização do Scrum é prever o quanto um time é capaz de entregar a cada sprint. Muitos tentam, em uma vaga tentativa de criar uma métrica, atribuir a 1 story point uma determinada quantidade de trabalho a ser entregue, ao invés de observar como um time desempenha seus papéis e realiza suas entregas. Por exemplo: 1 story point equivale a um cadastro com 8 campos que acessa 1 tabela na base de dados. Este tipo de abordagem não funciona, porque um time é constituído por pessoas, com diferentes experiências, percepções e problemas (pessoais ou profissionais). Individualmente e coletivamente, um time sempre apresenta características técnicas e emocionais distintas de outros times. Os membros do time A nunca levarão o mesmo tempo que os membros do time B levaram para adaptarem-se entre si. Times nunca apresentarão exatamente os mesmos conflitos ou a mesma produtividade. Enfim, em conjuntos recheados por seres humanos, pode até haver um padrão estatístico relativo à produtividade, mas nunca um padrão industrial, exato e previsível. Sempre haverá uma margem de erro. Daí, surge uma questão para reflexão: é melhor traçar um plano e subordinar sua equipe a este plano, a qualquer custo, em prol de um contrato ou meta corporativa? Ou melhor seria traçar uma meta e acompanhar o desempenho e crescimento do seu time, guiando-o rumo à missão, desfrutando de um ambiente harmonioso, feliz e de alta produtividade,  e realizar os ajustes necessários ao plano de projeto em prol da satisfação do seu cliente, oferecendo a ele um projeto transparente, sem surpresas?

Times Scrum são empíricos, assim como os bebês
Sendo o Scrum um processo empírico, seus times também terão o mesmo comportamento. Times Scrum experimentam e adaptam-se aos diferentes obstáculos encontrados durante um projeto de software. Eles não têm medo nem vergonha de errar, porque sabem que estes erros agregarão mais valor ao negócio do cliente. Em The Artful Making: What Managers Need To Know About How Artists Work, Robert Austin cita como exemplo de time empírico uma companhia de dança. Para atingir seu objetivo, o time de dançarinos testa o que foi ensaiado, grava-se, e observa o resultado por diferentes ângulos, até atingir o nível de excelência desejado. Da mesma forma funciona um time Scrum: inspecionando e adaptando. Observando todos os aspectos de suas ações e práticas e suas consequências. Não há um padrão ou boas práticas a seguir desde o início do projeto. Há um objetivo e um prazo, e o time se organiza sozinho, com a ajuda do ScrumMaster, para atingí-los. Práticas e padrões, comportamentais ou técnicos, emergem durante o desenvolvimento do software, e, é claro, funcionam muito bem – quase que exclusivamente – para aquele grupo de pessoas. Ou seja, assim como bebês aprendem errando – e erram o quanto for necessário até completar o aprendizado – um time Scrum aprende da mesma forma. Porém, com a vantagem de já possuir seu raciocínio lógico formado.

Apesar disso, é preciso, em algum momento do projeto (preferencialmente, o mais cedo possível) saber o potencial de entrega de um time por sprint, ou seja, sua velocidade. Para isso, é essencial, ao início de um projeto, focar na formação/coaching do time e na obtenção de sua velocidade média. Ao mesmo tempo em que o time já está desenvolvendo o software a partir dos requisitos do negócio, ele começa a se conhecer e se auto-organizar, ganhando um padrão de trabalho. Sem esta mentalidade, é impossível conhecer o ritmo de um time. A capacidade de entrega será sempre “o que o time conseguir entregar neste sprint”.

Um time não avança como um carro. Um time pulsa como um coração.
Uma das premissas de um time Scrum é que ele tenha um ritmo sustentável. Que ele trabalhe em um ritmo dentro do qual ele consiga manter a qualidade e completude de seu trabalho, sem prejudicar a sua saúde e bem-estar. Bem como nosso coração. Um time Scrum pulsa tal qual nosso coração pulsa. Para que estejamos saudáveis, nosso coração pulsa em um ritmo sustentável, diferente para cada ser humano, mas dentro de um padrão esperado. Dentro de uma faixa. Esta faixa deve ser percebida logo no início do projeto, quando o foco está em detectar a produtividade do time. No início de um projeto, um time deve ser “auscutado” pelo ScrumMaster, que vai ajudar o time a extrair e manter seu ritmo através da remoção de impedimentos em seu trabalho e de sua proteção contra influências externas. Um time sempre terá uma faixa de produção, seu máximo e seu mínimo de esforço ao longo da duração do projeto. Sua média será usada para manter seu ritmo sustentável. E qualquer mudança na composição do time afeta sua pulsação, seja no âmbito da produtividade, seja no âmbito psicológico. O fluxo de trabalho de um time Scrum pode ser tão previsível quanto o fluxo sanguíneo. Porém, seres humanos são compostos de emoções, que acarretam variações neste fluxo. Se um time é composto por diversos seres humanos, é fato que as emoções também afetarão seu fluxo de trabalho.

Ansiedade: o mal do século
Gerir um projeto de software é, basicamente, gerir aquisição de conhecimento. Conhecimento de negócio, sobre o objetivo a ser atingido, e conhecimento tecnológico, sobre como o objetivo será atingido. Durante todo o projeto, uma emoção está sempre presente: a ansiedade. Ficamos ansiosos pelas expectativas geradas por mudanças em requisitos, ficamos ansiosos pela proximidade do prazo, ficamos ansiosos pelo desempenho do time, ficamos ansiosos pela saída de um membro do time. Enfim, um projeto de software é estressante. Não há coração que agüente. E, se o coração de um projeto de software é o time de desenvolvimento, ele deve ser observado atentamente e cuidado. E isso só é possível conhecendo-se a pulsação por sprint do time. Sua capacidade média de entrega. Daí, deve-se estar atento ao que o time tem a dizer sobre seu trabalho diante das seguintes situações:

Pressão baixa: Se um time atinge uma pulsação abaixo do seu mínimo, fatalmente será acometido pela ansiedade dos gestores, patrocinadores ou usuários. Uma entrega era prevista e foi bem abaixo do esperado. O time tem algo a declarar. Times não deixam de performar simplesmente porque não querem performar. Algo os atrapalha, seja emocionalmente, seja profissionalmente. E, além da ansiedade externa, o time acumula sua própria ansiedade, porque sabem que estão abaixo do esperado, e porque estão sofrendo por algum fato.

Pressão alta: Se um time começa a se comprometer com sprints acima do seu histórico máximo, provavelmente está sofrendo pressão para tal. A ansiedade cresce porque o time sabe que está sob a expectativa de entregar acima do seu registro máximo, e provavelmente ele mesmo não sabe se conseguirá entregar o que se comprometeu a entregar. Seu esforço para realizar esta entrega será maior que o normal, invadindo o bem-estar do time. Provavelmente horas extras serão utilizadas para atingir o objetivo, e um novo registro máximo será instituído para o time caso ele consiga entregar em condições sub-humanas. O time conseguirá atingir tal feito por mais 2 ou 3 sprints, e daí o estresse causado pelo alto grau de ansiedade e cansaço começará a aparecer em falhas bobas e conflitos internos.

Em ambos os casos, a ansiedade por atingir ou superar expectativas leva ao estresse e até à frustração. Por isso é tão importante que o ScrumMaster esteja atento e auxilie o time na manutenção do seu ritmo sustentável. Este ritmo certamente é muito mais produtivo e criativo do que “o máximo que se pode aguentar”.

Horas extras: a descarga de adrenalina de um time
Assim como descargas de adrenalina, as horas extras devem ser usadas com cautela durante um projeto e de forma planejada. Se uma pessoa é submetida a descargas freqüentes de adrenalina, provavelmente seu coração ficará acelerado até parar. Ele cansa. Se um time for submetido a horas extras por um tempo exagerado, provavelmente ele ficará acelerado até parar. Ele cansa. Seus membros ficarão desmotivados, frustrados, produzirão menos do que o normal em determinado momento da jornada intensa e, fatalmente, deixarão o time em prol de sua saúde ou qualidade de vida. Horas extras devem ser usadas como descargas de adrenalina: com um objetivo definido e por um tempo determinado.

Sucesso? Mantenha um ritmo saudável
Sem dúvidas, o coração de um projeto está no time que o sustenta. Existirá a vontade de realizar um projeto, patrocínio para realizar um projeto, líderes para guiar sua execução. Mas tudo isso é inútil sem um time para transformar o ideal em realidade. E não basta apenas ter um time que torne os ideais realidade. Este grupo deve estar suficientemente motivado, unido e confortável para que o ideal seja atingido com qualidade. Desta forma, um time é capaz de manter um ritmo sustentável, saudável. Um ritmo que atinja a superação sem que os próprios membros do time a percebam.
Um dos maiores erros que alguns gestores cometem é assumir que o sustentável não é o suficiente. Ora, se o sustentável não é o suficiente, o insustentável é? Claro que não. O suficiente é manter um ritmo com o qual o time consiga realizar suas entregas consistentemente, corretamente, com qualidade, gerando a previsibilidade tão valorizada pelos gestores organizacionais e bem-estar para seus próprios membros. Tal qual um coração saudável.

Tagged with: , ,

Duas pizzas: o tamanho de um time Scrum

Posted in scrum, time by Rafa Nascimento on 22/11/2010

Em seu livro Succeeding with Agile, Mike Cohn conta como a Amazon.com trata a orientação encontrada no Scrum sobre o tamanho de um time. O Scrum orienta que um time deve ter um tamanho de 5 a 9 pessoas, entre Scrum Master, desenvolvedores, testadores, e qualquer outro papel que esteja responsável por entregar valor de negócio em forma de software. A Amazon.com refere-se aos seus times como “Times de 2 pizzas”, significando que um time pode ser alimentado com 2 pizzas. Apesar de engraçada, a referência é útil: se pedir almoço para um time se torna um problema, é sinal de que o time está grande demais.

Para ser justo, existem vantagens em times grandes. Times grandes incluem membros com as mais diversas habilidades, experiências e abordagens. Times grandes dificilmente estão vulneráveis ao risco de perder uma pessoa chave. Eles podem, inclusive, oferecer mais oportunidades para que os indivíduos se especializem em uma tecnologia ou parte de um software. Por outro lado, há muito mais vantagens em times pequenos, tais quais:

Menos “corpo mole”
A expressão “corpo mole”, no nosso contexto, refere-se a uma pessoa que acredita que outros farão o seu trabalho. Membros de um time pequeno são menos tendenciosos a esta atitude. O “corpo mole” foi demonstrado pela primeira vez por Max Ringelmann, na década de 20, quando ele mediu o esforço exercido por indivíduos e times pulando corda. Grupos de 3 exerceram somente 2,5 vezes (não 3) o esforço médio individual. Grupos de 8 apresentaram menos de 4 vezes a média individual. Os estudos de Ringlemann e estudos relacionados demonstraram que o esforço individual é inversamente proporcional ao tamanho do time.

Interação construtiva
Stephen Robbins, autor de Essentials of Organizational Behavior, um best-seller do comportamento organizacional, concluiu que times com mais de 10 ou 12 pessoas têm dificuldades em estabelecer um sentimento de confiança, responsabilidade mútua e coesão. Sem isso, a interação construtiva é difícil.

Menos tempo é gasto para coordenar esforços
Times pequenos gastam menos tempo cordenando os esforços de seus membros. E isso é verdade ao olhar para o tempo total de um projeto sob qualquer perspectiva. Como um exemplo simples, imagine a organização de uma reunião para um enorme time.

Todos participam
Em times grandes, há pouca participação em atividades em grupo ou discussões. Similarmente, a disparidade no nível de participação entre os membros do time aumenta. Os problemas podem impedir os indivíduos de tirar proveito de um time coeso e de alta performance.

Times pequenos trazem mais satisfação aos seus membros
Com um time pequeno, as contribuições individuais ficam mais visiveis e significantes. Isso, provavelmente, é um dos motivos para que pesquisas mostrassem que estar em um time grande é menos prazeroso para seus membros.

Especialização excessiva é menos provável de acontecer
Em um projeto grande, indivíduos estão mais propensos a assumirem papéis distintos. Por exemplo, um desenvolvedor escolhe trabalhar somente com interfaces. Isso reduz o nível do aprendizado que ocorre quando os indivíduos estão mais propensos a trabalhar além de papéis específicos.

Ainda sobre o comparativo entre times pequenos e times grandes, um interessante estudo de tamanhos de times observou 109 times diferentes. Os times pequenos tinham de 4 a 9 membros enquanto os grandes tinham de 14 a 18. Os pesquisadores chegaram a estas conclusões:

“Membros de times pequenos participaram mais ativamente em seus grupos; estavam mais comprometidos com o time; estavam mais cientes dos objetivos do time; estavam mais adaptados às personalidades, papéis e estilos de comunicação dos outros membros; e reportaram altos níveis de harmonia. Os dados também mostraram que times grandes são mais conscientes na preparação de reuniões comparados a times pequenos.” (Bradner, Mark e Hertel, 2003, 7)

Então, com um time pequeno, podemos ter muitas vantagens convincentes. Ou…podemos contratar um time enorme e ter excelentes reuniões.

Tagged with: , ,
%d blogueiros gostam disto: