Práticas Ágeis: Para Cada Tipo de Paciente, uma Dose do Remédio

  • 0

Práticas Ágeis: Para Cada Tipo de Paciente, uma Dose do Remédio

Para muitos é “ame-as ou deixe-as”. Para outros, elas são cultuadas e precisam ser seguidas à risca, quase como uma religião. Mas as práticas ágeis estão apoiadas em conceitos simples, com foco na interação das pessoas para solução de problemas e entregas de valor. Desta forma, sua adoção permite que você avalie quais melhores práticas se encaixam na sua necessidade e como as mesmas devem ser implantadas.

Particularmente, não acredito que exista uma “receita de bolo” para se utilizar em todas as situações. Existe um arsenal de práticas e metodologias que podem e devem ser utilizadas de acordo com o cenário encontrado em cada organização. Não se trata de implantar as metodologias ágeis para seguir a tendência atual, ou para solucionar todas as deficiências nas entregas de produtos ou projetos, mais especificamente os de Tecnologia. Trata-se de identificar e entender o problema que se quer resolver: falta de alinhamento estratégico, falta de comunicação com os clientes, falta de gestão do portfólio de projetos, inexistência de processo para criação de produtos, baixa qualidade da entrega, falta de processo de desenvolvimento de software, desmotivação da equipe e etc. Muitas vezes, uma combinação de vários deles ou de todos eles até. E os caminhos são diversos.

É sempre bom também contar com o patrocínio da alta gestão da empresa para uma mudança, mas, eventualmente, isso não acontece de início. Com relação às práticas ágeis, vender esta ideia para o board, nem sempre é fácil. Apesar dos conceitos simples, eles podem soar tão simples que não ganham credibilidade. E isso é normal. Então, como fazer? Bem, é preciso mostrar que funcionam! Nestes casos, vale montar um piloto e começar devagar, “comendo o mingau pelas beiradas”.

Temos alguns casos de sucesso para mostrar que a abordagem para adesão às metodologias ágeis depende de cada contexto, e que não adianta implantar indiscriminadamente, “goela abaixo”, as mais modernas práticas disponíveis de uma vez. Um caso que evidencia bem esta situação aconteceu em uma grande empresa de mídia. As práticas ágeis chegaram como uma boa novidade. Houve certo entusiasmo da alta gestão para seu uso, cuja promessa era garantir mais entregas de produtos em espaços de tempo cada vez mais curtos. Tudo o que eles queriam. No entanto, não houve patrocínio para uma mudança de cultura e processos que precisava permear todas as áreas, em não apenas a TI, no desenvolvimento de produtos. Mas foi a Tecnologia que efetivamente comprou a ideia e sua implantação, através da média gerência.

Os times foram envolvidos e se comprometeram com a mudança. As primeiras experiências não deram nem tão certo, mas o aprendizado adquirido e compartilhado mostrava claramente que o caminho era aquele. Interessante constatar o quanto as equipes de desenvolvimento identificaram-se com o novo processo e motivaram-se com ele. E esse foi apenas o início. Fundamental, porém, para embasar todas as demais mudanças que estavam por vir.

O cenário era complexo. A empresa, motivada pelas dificuldades e os desafios da indústria de mídia, passava por grandes mudanças: organizacional e estratégica, que fez com que a mesma investisse na troca de sua plataforma de publicação. A equipe de Tecnologia estava crescendo rapidamente e absorvendo novos profissionais, muitos deles mais juniores. Absorvia também novas ferramentas e não existia um processo maduro de desenvolvimento. Longe disso! A área de TI também sofria com os prazos apertados e as entregas não cumpridas. Portanto, apesar da necessidade de modernização urgente, não dava para se fazer tudo ao mesmo tempo. O risco de comprometer ainda mais as entregas e acabar de vez com a credibilidade da Tecnologia era enorme.

O início se deu com a adoção de metodologias ágeis para gerir as atividades da equipe de desenvolvimento: num primeiro momento o Scrum, com algumas pitadas do Kanban. Os resultados junto aos times foram animadores e vieram rapidamente: as entregas começaram a fluir e, cada vez mais, os clientes estavam mais próximos desta rotina, respirando os produtos. Em pouco tempo, o time de desenvolvimento virou a equipe do produto. Ótimo! Era este o ambiente desejado.

Hora de fazer mais mexidas, agora no processo de desenvolvimento: novos conceitos foram incorporados como a orientação a testes e o foco em qualidade. Mais adiante, foi criada a “cesta de indicadores de qualidade”, com o objetivo de medir o desempenho, aumentar a transparência junto ao usuário e tangibilizar melhor o aprendizado da equipe. Toda esta evolução feita paulatinamente e com a participação efetiva das equipes, exatamente para criar o estado de pertencimento e propriedade.

Desta forma o comprometimento, não apenas com o produto a ser entregue, mas com os processo e práticas garantiu que as mudanças ocorridas passassem a fazer parte da nova cultura corrente.

Mas tudo a seu tempo. Respeitando-se as limitações da empresa, da gestão e das equipes e levando-se em consideração o contexto e o momento corporativo. Não é problema se permitir fazer concessões às práticas ou métodos ou abordagens, desde que se respeite os conceitos fundamentais e o foco na conscientização de uma nova filosofia de trabalho participativa, transparente e colaborativa.


  • 0

A Culpa é da TI?

Entregas não realizadas, prazos não cumpridos, usuários insatisfeitos, oportunidades de mercado perdidas, executivos pressionando, cobrança, equipe desmotivada. Normalmente, sempre por “culpa da TI”. Este cenário é muito comum e a “necessidade” de se encontrar um culpado faz a corda arrebentar para o lado mais fraco. Este lado quase sempre é a equipe de Tecnologia, que muitas vezes, não é vista ou tida como estratégica e funciona como uma anotadora de pedidos, que precisa fazer as entregas a qualquer custo.

Nem sempre prazos apertados ou impossíveis, falta de definição dos requisitos, mudanças de escopo constantes e falta de comprometimento de outras áreas envolvidas são levados em consideração para se avaliar o melhor direcionamento para o projeto. Nada! O importante é encontrar logo o culpado e “passar o mico”. A bomba vai estourar na ponta e a ponta é exatamente quem vai fazer a entrega final, a TI. Estas equipes, muitas vezes, atuam com seus “heróis”, tentando recuperar o tempo perdido. Fazem de tudo, viram a noite, perdem os finais de semana e feriados. Mas, no final, não entregam, perdem o prazo ou geram produtos sem qualidade. O maior problema, porém, é a insistência em repetir esta sistemática. E isso se repete e se repete e se repete…  Não vai dar certo! Vai dar problema de novo e mais cobranças e desconfianças sobre a área de Tecnologia.

É isso que temos visto nas empresas por onde passamos. É um padrão. Obviamente, os CIOs se preocupam com esta situação, pois é sempre a sua área que está em xeque.  Mas, como dizia o poeta: “os heróis morreram de overdose”. A solução não está por aí. Por mais preparados que sejam os profissionais de tecnologia, é melhor deixar as missões impossíveis para os Vingadores nas salas de cinema.

Para obtermos resultados diferentes, precisamos fazer diferente! É importante olhar todo o processo e comprometer todos os envolvidos (e não apenas a TI), fazendo com que as áreas trabalhem e funcionem de forma colaborativa. Não é fácil na cultura de empresas que ainda insistem em encontrar culpados e, por isso, o trabalho precisa ser mais profundo. Ele passa por uma transformação e mexe na cultura, nas pessoas, e nos processos, para que todos entendam seu papel e se comprometam com a entrega final como uma equipe, independentemente da área em que atuam.

Parece simples, mas sabemos que não é tão fácil assim. Existem muitas questões envolvidas no ambiente corporativo: política, vaidade, metas dos executivos (normalmente, não convergentes), orçamento e etc., que acabam inibindo o comportamento desejado de colaboração e comprometimento com o mesmo fim. Muitas vezes, as equipes recebem a solução pronta a ser implementada. E este é o pior dos mundos. É muito importante que o time conheça a direção, a estratégia e tenha um propósito. Reunindo as competências corretas e, com o direcionamento adequado, a equipe vai encontrar as melhoras soluções. Ao fazer isso, conquista-se um dos maiores ingredientes do sucesso: engajamento.

O caminho para esta mudança passa por quebras de paradigmas e uso de práticas menos intuitivas, que compõem o arsenal existente de práticas ágeis. Desde que passamos a usá-las ou introduzi-las nas empresas, a realidade mudou para estas equipes. Mas, ainda assim, existe certa desconfiança sobre a utilização destas práticas: parecem frágeis, feitas “nas coxas” e soam como brincadeira – é “aquela turma dos post-its”. Afinal, as metodologias tradicionais de gestão de projetos ou de desenvolvimento de software estão aí há décadas, geram uma incrível quantidade de documentação e não deve haver nada mais robusto que isso, não é mesmo? Bem, não é bem assim. Apesar de simples (muitos simples!), as práticas ágeis requerem muita disciplina e processos estruturados para garantir as entregas periódicas. Requerem ainda transparência e muita interação com o cliente, que acaba se envolvendo de tal forma com o método de trabalho e com o produto a ser entregue, que passa a ser o primeiro a defender a equipe de Tecnologia. Ele não é mais aquele “inimigo”, que fica mudando o escopo a cada instante e culpa o desenvolvimento pelo não cumprimento de prazo. A entrega é tão dele quanto de qualquer outro no time e a colaboração flui. Além disso, as mudanças, antes tão indesejadas pela TI e sempre motivo de conflitos, passam a fazer parte do processo de trabalho, direcionando as entregas para o maior valor agregado ao produto final.

Estas mudanças culturais, processuais e de foco não estão limitadas ao ambiente de Tecnologia, ali na ponta, onde o produto ou sistema será desenvolvido. Ao contrário, precisa ocorrer em todo o “value stream”, desde seu início nas definições estratégicas e a escolha correta do portfólio (“o que fazer”). O foco é no valor a ser gerado pelo que se está entregando. Então, entender como captar este valor e medi-lo passa a ser de grande relevância e chave em todo o processo. A entrega (o desenvolvimento) também precisa ser bem feita, é claro!, e é importante ter este fluxo estruturado (o “como fazer”). Mas, a esta altura, o trabalho colaborativo já está estabelecido: uma transformação em todos os níveis, através da criação de uma cultura de participação, autonomia, engajamento, responsabilidade, transparência com muito trabalho em equipe para entrega de valor para o negócio. Simples assim.


  • 2

Compartilhando um pouco da Minha Experiência com o Agile: Um Case Especial

Tags :

Category : Bússola Digital

Em 2013, comecei uma jornada nova para mim: saí do mundo corporativo para empreender. Certamente não foi uma decisão fácil, mas aconteceu naturalmente. O Juan Bernabó, mestre e referência na evangelização das práticas pragmáticas, e que foi o nosso consultor na adoção de metodologias ágeis na Infoglobo alguns anos antes, de onde eu vim, buscava um parceiro capaz de realizar as entregas (dos projetos e produtos) e trabalhar na transformação dos ambientes. Nesta ocasião, Jesuíno Lopes e eu embarcamos neste processo (posteriormente, o Fabrício Fujikawa se juntou a nós). Nosso objetivo, à época, foi fazer da Teamware, hoje ViaDigital, uma referência neste trabalho de transição para um modelo de gestão mais moderno, garantindo às empresas (clientes) usufruir dos benefícios das entregas ágeis e da geração de valor cada vez mais rapidamente.

E foi exatamente esta a nossa grande motivação: disseminar esta nossa experiência tão rica e tão transformadora. Na verdade, senti-me na obrigação de compartilhar esta vivência! Mostrar para outras empresas que é possível construir uma área de TI diferente, estratégica, pró-ativa e inovadora, capaz de trabalhar com as áreas de Negócio de forma muito integradas, com total transparência na comunicação e com um objetivo comum. Um verdadeiro trabalho colaborativo, onde a equipe possui mais autonomia e responsabilidade, gerando um profundo engajamento e enorme motivação. E onde busca-se o que é melhor para o produto e para empresa e não para um departamento ou outro: o valor para o negócio é colocado em primeiro lugar, permitindo, assim, que as entregas sejam mais rentáveis e enxutas e, consequentemente, mais rápidas e baratas.

Vamos usar o nosso blog para apresentar cases de como isso é possível e como isso acontece. No entanto, para melhor tangibilizar esta harmonia que contei acima, com o foco no objetivo comum, alegria do trabalho colaborativo e atingimento dos resultados num curto espaço de tempo, geramos um pequeno vídeo. Nele, contamos a experiência que tivemos na entrega de uma nova versão do Site do Globo, enquanto ainda estava na Infoglobo. Foi um momento incrível, com uma tremenda equipe e um super desafio para todos os envolvidos, pois, além do prazo “impossível”, este era um projeto muito importante dentro de um grande programa, onde muitas mudanças estavam acontecendo simultaneamente.


  • 0
Simplificar: menos pode ser mais

Simplificação – A Arte de Maximizar o Trabalho Não Realizado

Olá,

Tudo bem? Li a frase do título deste post no texto 10 Product Owner Questions, que relaciona 10 perguntas importantes para Product Owners. O post sugere que Scrum Masters podem fazer essas perguntas aos POs, como uma forma de coaching.

No final, apresento o link da matéria completa e vou destacar apenas 3 perguntas: as duas primeiras falam sobre características que vemos constantemente nos projetos em que atuamos e a última porque tem a ver com trabalho colaborativo, uma filosofia que acreditamos e pregamos no dia-a-dia.

1) Como você sabe se o seu produto é bem-sucedido e entrega valor?

Sim, é uma pergunta difícil, muito difícil. Por exemplo, tente responder você em relação à última tarefa que estava fazendo. Nada fácil, não é? Daí vem a importância da pergunta: se não sabemos a resposta, de que adianta fazer o produto (ou a tarefa)?

Mesmo que não seja viável medir o sucesso do produto e sua entrega de valor, é importante exercitar este raciocínio. Repare que “não ser viável medir” é diferente de “não ter métricas”.

Por exemplo, para este texto que estou escrevendo, uma possível métrica de sucesso e de entrega de valor poderia ser o percentual de pessoas que refletiram sobre suas próprias atividades, priorizaram algumas e despriorizaram outras, a partir da sua leitura.

É claro que, na prática, medir isso seria muito difícil. Mas, a métrica existe. Percebe a diferença? (E notou que o título do artigo está alinhado com a métrica?)

2) Que funcionalidades devem ser removidas do produto? Como você sabe que elas devem ser removidas? Como você pode afirmar que uma funcionalidade não pode ser removida?

A gente costuma bater muito nesta tecla em relação às histórias do backlog, mas o que achei interessante nesta pergunta foi que ela fala sobre funcionalidades já presentes no produto. Isso mesmo: trabalho já realizado. Por que então gastar mais trabalho para remover um trabalho já desperdiçado?

O autor do texto fala que é importante remover as funcionalidades que tem um ROI negativo, e que entender as funcionalidades realmente essenciais e o quão enxutas elas podem ser, é uma habilidade fundamental para aumentar a agilidade do produto.

Fiquei pensando se a gente fazia isso em nossos próprios projetos. Daí me lembrei de um aplicativo para o qual fomos contratados para fazer a manutenção evolutiva. Recentemente, sugeri remover de uma lista de um filtro de busca cerca de 90% dos seus itens, pois eles resultavam em um resultado vazio quando eram usados como filtro.

Acho que pode ser considerado um caso que se enquadra nesta pergunta: nossa proposta foi a de enxugar uma funcionalidade já existente, removendo opções que, no fundo, não tinham utilidade e prejudicavam a experiência do usuário.

Simplificar: menos pode ser mais

Simplificar: menos pode ser mais (foto: Ana Cotta)

3) Você ficaria tranquilo deixando a equipe de desenvolvimento rodar os próximos dois sprints sem falar com você?

Apesar de parecer o contrário, uma resposta positiva para esta pergunta depende muito de uma cultura de trabalho colaborativo. Quando o PO tira férias, por exemplo, ele tem um substituto que assume bem seu lugar? Se o PO realmente ficar indisponível, a equipe de desenvolvimento consegue falar com outros stakeholders, se necessário?

Para isso, primeiramente, o PO tem que:

  • passar as histórias com um bom nível de detalhes para o time;
  • comunicar a visão e estratégia de produto para todos;
  • deixar o backlog organizado com as próximas histórias razoavelmente detalhadas e priorizadas.

Enfim, o PO tem que fazer adequadamente o seu “dever de casa”, o que é ótimo, porque ele ganha mais tempo livre para focar nas suas outras atividades: estudo de mercado e concorrência, principalmente.

Mas, acima de tudo, as pessoas envolvidas tem que trabalhar colaborativamente pelo objetivo comum e não pensando apenas na sua área de conhecimento ou no seu departamento.

 

Espero que você gostado! Leia aqui a matéria 10 Product Owner Questions e deixe seus comentários abaixo.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 0

Por que o post-it funciona tão bem nas metodologias ágeis?

Tags :

Category : Bússola Digital

Olá,

Tudo bem? Já falei um pouco sobre minha experiência com post-its no texto do Barizon “Como é que de quadros e post-its vai sair um software bom para os clientes?“. Eu uso post-it no meu dia-a-dia e entendo que não é uma solução mágica, nem se adequa a todos os cenários. Mas, nas experiências que tive, ele funcionou bem, muito bem mesmo.

Entretanto, outro dia li um post no LinkedIn, chamado “A Incrível Fábrica de Post-Its“, que me chamou a atenção para este ponto: os quadros e post-its são realmente uma das coisas mais marcantes nas metodologias ágeis. Por isso mesmo, ainda hoje são uma das mais controversas.

Então, resolvi trazer outros fatos e me aprofundar um pouco mais nas experiências que eu vivi, para alimentarmos uma discussão saudável.

Post-it gera motivação

Como integrante de time scrum, escrevi junto com meus colegas vários post-its de tarefas, o me dava uma sensação de autonomia e empoderamento muito fortes: a gente decidia o que seria feito para entregar a história priorizada.

Isso me dava muita motivação. Eu sou um profissional que preciso acreditar que o que estou fazendo tem valor. Para mim, é muito difícil fazer as coisas simplesmente porque tem que ser feitas. Acredito que a maioria dos profissionais de TI, ou melhor, não só de TI, mas da era do conhecimento, são guiados por esse tipo de motivação também.

Post-it não substitui documentação técnica

Há um mito de que quem usa os post-its é contra a documentação técnica. É engano! Se o time decidir que um artefato de documentação é importante e tem valor, o time cria um post-it para ele.

Na maioria dos projetos em que trabalhei, a gente gerou, por exemplo, um post-it para criar o diagrama de arquitetura da solução, representando as integrações entre os diversos componentes, porque a gente entendia que esse diagrama tinha vários benefícios:

  • apoiar na análise dos impactos de novas implementações ou manutenções no código existente;
  • mapear cenários de testes;
  • explicar a solução técnica para novos colaboradores do time;
  • consultas diversas no dia-a-dia.

Esse mesmo diagrama de arquitetura também ganhava um post-it para ser atualizado quando necessário. Por exemplo, num projeto, quando mudamos a solução de pagamentos online, criamos um post-it para atualizar esse diagrama.

Quadros e post-its são fáceis e todo mundo entende

Quando usamos um quadro scrum básico, o entendimento do quadro é imediato: histórias e suas tarefas, com 3 status (a fazer, fazendo e feito), por quais andam os post-its. Eventualmente, um 4o. status indesejado (impedido).

Nos times em que usei Kanban, o quadro também era simples de ser entendido. Era só mostrar o quadro, explicar as etapas e como os post-its deveriam caminhar. Pronto, com 15 minutos de conversa qualquer pessoa entendia o quadro.

Mas o bacana disso tudo é que o quadro scrum ou quadro kanban é a representação visual de um processo de trabalho. Nesse sentido, eles estabelecem um modelo mental coletivo do trabalho. Em outras palavras, todo o time tem um mesmo entendimento sobre o trabalho a ser feito. Isto é muito poderoso, porque alinha os esforços na mesma direção!

1 post-it + 1 post-it = 3 post-its

Por mais clichê que isto pareça, quem trabalhou num time ágil, já deve ter tido esse momento em que olhou para o seu quadro e “caiu a ficha“: caramba, o que a gente entrega como time é muito mais do que eu faço sozinho e é muito mais do que a soma dos nossos post-its.

Isto também dá uma motivação e orgulho de pertencer ao time difíceis de explicar em palavras. Mas a gente sente e isso aparece nas retrospectivas do time.

Os post-its organizam o trabalho da equipe

Imagine você trabalhando com 3, 4, 5 pessoas num time, todas mexendo no mesmo código-fonte, em que elas chegam em horários diferentes para trabalhar e vão embora também em momentos diferentes. Quando você começa o dia seguinte, como saber por onde começar, ou em que ponto o colega parou no dia anterior?

Os post-its respondem isso de forma muito eficaz, rápida e simples: é só olhar para o quadro e seguir o fluxo dos post-its.

Tanto quando atuei como scrum master, como quando era gestor do time, esta característica também me ajudava bastante: era só olhar para o quadro para saber o que dependia de minha ação.

Outra situação é quando você trabalha numa equipe geograficamente distribuída. Teve um projeto em que a gente estava no Rio de Janeiro, o cliente em Sorocaba e um fornecedor técnico em Miami. Além da distância, neste caso também tinha uma diferença de fuso horário. O que usamos? Quadro e post-its digitais (ferramenta Trello).

Post-its são divertidos

Pode parecer bobagem, mas para mim faz muita diferença. Você prefere trabalhar aborrecido ou trabalhar feliz?

Pequenas diversões ajudam a construir um ambiente de trabalho mais feliz. Mexer com os post-its para lá e para cá é lúdico, é divertido. Parece um jogo, em que você tem que andar com as peças para ganhar o jogo.

Mas não é um jogo em que sou eu contra um colega de trabalho. É o time todo, junto, andando com as peças. Isso é gostoso de fazer; é muito melhor do que ficar mudando o status de uma tarefa numa planilha ou num sistema.

Uma vez fiz com minha família uma “retrospectiva do ano“. No final de 2015, a minha filha mais velha pediu para a gente lembrá-la sobre como era o “jogo” que a gente tinha feito daquela vez.

Nas palavras dela, explicando por que gostou dos post-its:

“De início essa ideia de usar post-its pareceu meio simples, ainda mais com toda a tecnologia que temos hoje em dia. Mas a verdade é que escrever à mão e mover os post-its pra lá e pra cá acabou sendo bem mais dinâmico e divertido do que ficar olhando para uma tela de computador.”

Post-it só para mim?

Talvez você notado que falei muito em equipe, time, no coletivo. Será que o post-it funciona para o trabalho individual? Eu acho que sim. Eu uso, principalmente, porque acho mais prazeroso. Talvez esteja influenciado pela ferramenta digital que adoto, que dá mobilidade, tem ótima usabilidade, etc. Mas acho que usaria mesmo se fosse com post-its de papel.

 

Voltando ao artigo original que me motivou a pensar neste assunto, acho importante fechar com dois tópicos:

Post-it não gera software de qualidade: não é porque você usa quadros e post-its que você vai gerar software de qualidade. Quem faz um software bem feito é uma boa equipe de desenvolvimento. A metodologia ágil, e os quadros e post-its como suas ferramentas, ajudam a entregar valor mais rapidamente e a organizar o fluxo de trabalho para uma boa performance do time.

Agora, se o valor entregue é de fato um valor, depende muito da competência do Product Owner. Já se o software entregue está bem feito, depende da competência técnica do time de desenvolvimento, não dos post-its.

Tarefas e compromissos com datas: para isto, eu recorro à velha e boa agenda. 🙂

 

Fontes de referência

 

O que você achou? Qual a sua experiência com os post-its? Deixe seus comentários.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 0

A importância do foco no Scrum

Olá,

(Se você preferir, pode fazer o download deste artigo em MP3 e escutar no seu celular, tablet ou computador.)

Tudo bem? Uma dúvida muito comum para quem ainda não trabalhou com Scrum é: será que o time Scrum precisa mesmo ficar focado em apenas um projeto? Não dá para fazer pelo menos dois simultaneamente? Algo como “de manhã, um projeto A; de tarde, um projeto B”?

A resposta simples e pragmática é: dá, claro que dá sim, mas não funciona nada bem. Não é recomendável.

Focar em vários projetos dá a falsa impressão de que estamos usando melhor o tempo, porque afinal estamos atendendo várias demandas simultaneamente.

Mas, se analisarmos bem, na prática, num dado momento, estamos sempre trabalhando em um projeto só. Repare que no exemplo “de manhã, projeto A; de tarde, projeto B”, na verdade estamos dizendo que em cada período trabalhamos apenas num projeto. Não há mágica, pois nós não conseguimos trabalhar, de fato, em mais de uma coisa ao mesmo tempo.

Se fizermos uma análise simples de encadeamento das entregas, também chegamos à conclusão de que não há benefícios.

Vamos fazer algumas simulações com números, apenas para ilustrar: vamos supor que o projeto A demorasse 4 meses se trabalhássemos 100% de nosso tempo nele.

O projeto A leva 4 meses para ficar pronto com 100% de foco nele

O projeto A leva 4 meses para ficar pronto com 100% de foco nele

Para simplificar, vamos supor que o projeto B também levasse os mesmos 4 meses com foco integral.

O projeto B também leva 4 meses para ficar pronto com 100% de foco

O projeto B também leva 4 meses para ficar pronto com 100% de foco

Se focássemos primeiro no projeto A, e se tudo desse certo, ao final do 4o. mês, ele estaria pronto. Começaríamos o projeto B e, novamente tudo dando certo, ao final do 8o. mês, ele estaria concluído.

Foco em 1 projeto de cada vez, como prega o Scrum

Foco em 1 projeto de cada vez, como prega o Scrum

Já num cenário de focarmos 50% de nosso tempo para cada projeto, significa que duplicaremos o prazo de entrega: cada um deles levará 8 meses.

Trabalho em projetos paralelos (como não prega o Scrum)

Trabalho em projetos paralelos (como não prega o Scrum)

Nada muda para o projeto B, pois ele será concluído igualmente no 8o mês, junto com o projeto A. Na prática, porém, perdemos a oportunidade de lançar o projeto A com 4 meses de antecedência!

Percebe como não há ganho nenhum?

Isto se considerarmos que tudo correu bem em ambos os projetos, o que dificilmente acontece. A única coisa garantida neste cenário de trabalho em paralelismo é a de que deixaremos de entregar um dos projetos que poderia ter sido finalizado primeiro.

Além disso, perdemos um dos grandes benefícios do Scrum. Se focarmos em apenas um dos projetos de cada vez, graças às entregas incrementais do Scrum, sempre priorizadas por valor, pode acontecer do cliente ficar satisfeito antes mesmo do prazo inicialmente previsto.

Assim, é possível que os 4 meses originais sejam encurtados, porque, por exemplo, o cliente já ficou satisfeito com as entregas feitas até o 3o. mês.

Outro aspecto que quase sempre é ignorado é que trabalhar em modo multitarefa é desgastante e diminui, sim, a nossa performance, embora muita gente não queira reconhecer isto.

Jeff Sutherland, co-criador do método Scrum, em seu livro “Scrum – a arte de fazer o dobro de trabalho na metade do tempo“, sugere um exercício que “É simples, mas mostra o profundo impacto do foco e do fluxo. Mostra como multitarefas são árduas para o nosso cérebro, e como isso reduz o seu ritmo, mesmo que você acredite que está aumentando. Demonstra como essas atividades desperdiçam tempo e energia.

Capa do livro de Jeff Sutherland sobre Scrum

Capa do livro de Jeff Sutherland sobre Scrum

O exercício é o seguinte: escrever os números cardinais de 1 a 10, os números romanos de I a X e as letras de A a J, da seguinte forma:

Você deve fazer o exercício de duas formas: na primeira, escreva linha por linha, isto é, escreva a primeira linha:

1   I   A

Depois, escreva a segunda linha:

1   I   A
2   II   B

E assim por diante, até a décima linha. Cronometre quanto tempo você levou.

Agora, escreva coluna por coluna, isto é, escreva a primeira coluna:

1
2
3

10

Depois, a segunda coluna:

1   I
2   II
3   III

10   X

E, finalmente, a terceira coluna, a das letras. Novamente, marque quanto tempo levou.

Experimente fazer o exercício, de verdade! Eu fui 40% mais rápido quando escrevi coluna por coluna. É realmente incrível!

Sutherland relata no livro: “Simplesmente por fazer uma (coluna) de cada vez, em vez de ficar trocando um contexto pelo outro, eu cortei pela metade o tempo que levei para realizar a tarefa.

O autor prossegue mencionando o estudo de Gerald Weinberg, que quantifica a perda de produtividade em função de trocas de contexto de projetos.

Perda de produtividade por trabalhar em projetos simultâneos (por Gerald Weiberng)

Perda de produtividade por trabalhar em projetos simultâneos (por Gerald Weiberng)

A coluna “perda” significa puro desperdício!

O Fabrício foi desenvolvedor de software por muitos anos (e, para falar a verdade, ainda gosta de “meter a mão na massa”) e tem um depoimento sobre este assunto:

“Realmente, quando focamos em um projeto só no Scrum, a produtividade do time aumenta a cada ciclo. A gente vai adquirindo conhecimento sobre as regras daquele produto e vai ficando cada vez mais rápidos.

Quem já desenvolveu software moderno sabe que muitas vezes mexemos pela primeira vez com algumas APIs, componentes, classes, frameworks, durante um projeto. Cada projeto é um aprendizado novo. Ficar focado em apenas um projeto torna esse aprendizado muito mais rápido e produtivo.

Aliás, sobre essa questão do ‘aprendizado’, sempre me lembro de um treinamento em Engenharia Ágil de Software que fizemos com o Klaus Wuestefeld na Infoglobo.

Klaus Wuestefeld

Klaus Wuestefeld

Qualquer livro de engenharia de software traz uma definição sobre ‘o que é software’ parecida com esta da Wikipédia: ‘(…) é composto por uma sequência de instruções, que é interpretada e executada por um processador ou por uma máquina virtual. Em um programa correto e funcional, essa sequência segue padrões específicos que resultam em um comportamento desejado‘.

Já o Klaus, no curso, deu uma definição completamente diferente, poética até. Algo como ‘software é a expressão do aprendizado da equipe sobre os problemas a serem resolvidos‘.

O que é software (adaptado de Klaus Wustefeld)

O que é software (adaptado de Klaus Wustefeld)

Sem querer entrar no mérito de qual é certa ou errada, o fato é que a definição do Klaus fez muito mais sentido para mim quando pensei nos projetos em que já trabalhei.

Por isso, acho que quando focamos 100% em um projeto de cada vez, conseguimos aprender a ‘resolver seus problemas’ mais rapidamente e de forma mais produtiva.”

Uma última informação: o autor Cal Newport lançou no início de 2016 o livro que ele classificou como “o livro que o Facebook não quer que você leia”, no qual trata sobre concentração e foco: “Deep Work: Rules for Focused Success in a Distracted World“.

Capa do livro Deep Work

Capa do livro Deep Work

Alguns dos feitos de Newport: publicou cerca de 50 artigos acadêmicos, com mais de 2500 citações, escreveu 5 livros com mais de 200 mil cópias vendidas e criou um blog que teve 300 mil páginas visualizadas em Dezembro/2015.

Tudo isto sem trabalhar até tarde da noite e raramente trabalhando nos finais de semana. Apenas usando o foco. 🙂

Abraços,

Cláudio Barizon
Diretor de Negócios Digitais
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 4
Agenda com tarefas do dia

Como fazer o seu dia render?

Olá,

Tudo bem? Desde que me tornei um (feliz) empreendedor adepto do home office, em Setembro/2015, comecei a procurar um método para organizar bem meu dia-a-dia.

Já tinha experimentado por um tempo o método GTD (Getting Things Done), de David Allen, quando fui coordenador de TI na Infoglobo. Li seu livro Produtividade Pessoal e, na época, me agradou.

Livro Produtividade Pessoal, de David Allen

Livro Produtividade Pessoal, de David Allen

Só que desta vez eu procurava algo um pouco diferente, para eu produzir de forma mais eficaz, mas também me fizesse sentir mais dono do meu tempo, já que eu realmente tinha mais autonomia sobre ele.

Eu já conhecia o autor Cal Newport, professor de ciências da computação na Universidade de Georgetown. Pesquisando sobre o assunto, encontrei em um de seus artigos a sua metodologia de planejamento diário.

O título do artigo logo me chamou a atenção: “The Importance of Planning Every Minute of Your Work Day” (numa tradução livre, “A importância de planejar cada minuto de seu dia de trabalho“).

Ora, de imediato, discordei! Afinal, onde já se viu querer planejar cada minuto do seu dia?! Lógico que não vai funcionar!

Porém, como já conhecia o autor, e tinha me identificado com ele, resolvi ler o artigo para conhecer o método. Basicamente, ele consiste em, diariamente, planejar as suas atividades, criando e bloqueando fatias de tempo específicas para cada atividade. Durante essas fatias de tempo, concentração e foco total na tarefa definida.

Gostei muito e coloquei em prática! Veja uma agenda diária minha (as partes hachuradas mencionavam nomes que preferi não expor):

Agenda com tarefas do dia 30/11/2015

Agenda com tarefas do dia 30/11/2015

Três preocupações comuns para quem acaba de conhecer o método (eu realmente tive as duas primeiras):

1) Vale a pena mesmo investir tempo nesse planejamento? Segundo o autor, uma semana de 40 horas de trabalho bem distribuído segundo esse método equivale a uma semana de 60 horas de trabalho adhoc. Não sei quantificar, mas minha percepção é de que funciona, mesmo. Quando chego na fatia de tempo de trabalho, simplesmente a executo e não me preocupo com as outras coisas. Ou melhor, digo “não” para as outras coisas. Email fechado, redes sociais fechadas, etc. Dependendo do nível de concentração que preciso, WhatsApp no silencioso também.

2) E aquelas atividades, não planejadas, que eu sei que vão aparecer (geralmente, no meu email)? Neste caso, o autor também recomenda uma solução simples: crie uma fatia de tempo para elas. Por exemplo, 1 ou 2 horas para checar o email e encaminhar as demandas. Ele, inclusive, sugere uma estratégia para a incerteza natural dessas fatias de tempo: “process client requests; if I have downtime during this block, work on project X”.

3) Será que funciona para trabalhos de natureza criativa? Segundo o autor, sim, porque garante uma dedicação consistente de foco e esforço às atividades criativas. Além disso, a tranquilidade por saber que sua agenda está organizada permite você se aprofundar nesses seus “blocos criativos” e gerar mais valor. Eu acrescentaria que você pode também escolher o seu melhor momento do dia para trabalhar nessas atividades. Por exemplo, eu gosto de escrever mais pela manhã e tenho feito assim. E, de fato, saber que eu tenho um bloco de tempo definido para isso, mas também para as minhas outras atividades, no meu caso, me dá muita tranquilidade e prazer para escrever.

Refletindo sobre o método de Cal Newport, vejo algumas práticas parecidas com o método Scrum: bloquear tempo, foco em uma coisa de cada vez, representar visualmente o trabalho, uma divisão clara entre planejar X executar e a flexibilidade para mudanças.

Aliás, falando em falando em planejar X executar, num outro artigo o autor fala sobre planejar o dia seguinte ao final do dia anterior. Isto eu fiz umas poucas vezes e gostei também, mas confesso que ainda não consegui incorporar como hábito.

Sua metodologia na verdade é bem mais abrangente e aborda também o planejamento semanal e a longo prazo. Se você achar interessante, podemos abordar num texto futuro. Espero que tenha gostado. Veja aqui o artigo original do autor sobre o planejamento diário e deixe seus comentários. 🙂

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 1
Exemplo de Quadro Scrum

Como é que de quadros e post-its vai sair um software bom para os clientes?

Tags :

Category : Bússola Digital

Olá,

Tudo bem? Para quem nunca usou Scrum (ou outra metodologia ágil na prática), é muito comum ter essa dúvida: como é que de um quadrinho com post-its coloridos sai um software decente e, ainda mais, que agrade aos clientes e usuários?

Quando comecei a adotar o Scrum na Infoglobo, em 2008, também tinha essa desconfiança… um certo preconceito até. E não me envergonho em admitir isso, porque sei que não é uma questão de certo ou errado… apenas eu vivia dentro de um paradigma de trabalho diferente, que era uma continuação do que tinha estudado na faculdade.

Ainda bem que consegui me dar a oportunidade de trabalhar com o Scrum e, hoje, muitos anos e projetos entregues com sucesso depois, consigo ver a realidade de outra forma. Tenho plena convicção de que o método funciona bem para qualquer tipo de software e processo de trabalho. Já usei inclusive para reformar meu apartamento!

Uma de suas ferramentas mais valiosas, talvez a mais percebida por todos (os que usam e os que não usam o método) e, por isso mesmo, talvez a mais controversa, é o quadro Scrum.

Compartilho com você neste vídeo minha visão de por que um quadro Scrum funciona e promove transformações tão profundas.

Lendo o livro “Scrum – Gestão Ágil para Projetos de Sucesso”, de Rafael Sabbagh, entendi a explicação científica por trás dessa minha percepção de transparência que o quadro Scrum proporciona:

“Esse tipo de quadro é classificado como ‘irradiador de informação’, ou seja, a informação chega aos olhos de quem é importante chegar sem haver um esforço significativo para buscá-la. É muito mais eficiente, por exemplo, do que um programa de computador, que necessita de ser acessado para mostrar a informação.”

Como disse no vídeo, o quadro básico de Scrum é muito simples, composto por uma lista ordenada de histórias e tarefas, com 3 colunas: a fazer (to do), fazendo (wip) e feito (done).

Exemplo de Quadro Scrum

Exemplo de Quadro Scrum

As histórias mais importantes, que devem ser concluídas primeiro, ficam em cima. As menos importantes, ficam em baixo. Embora as histórias sejam de autoria do Product Owner (pelo menos a autoria principal), as tarefas (os post-its menores) são de autoria do time de desenvolvimento.

Isto significa que é o time que decide o que será feito para entregar a história. O Fabrício, que já participou como membro de time e Scrum Master em vários projetos Scrum, tem um depoimento interessante sobre esta questão:

“O quadro Scrum dá uma sensação de empoderamento e autonomia incríveis ao time. É muito diferente você trabalhar em algo em que você teve a oportunidade de opinar e dizer que achava que era importante fazer aquilo, do que quando você faz porque te passaram a atividade, ou para seguir um processo ou uma norma corporativa, simplesmente por seguir.

Até mesmo as atividades de documentação, QA e testes, que normalmente são atividades menos prazerosas para os desenvolvedores, tornam-se mais agradáveis desta forma.

Lembro-me de que um diagrama que fizemos em praticamente todos os projetos é o diagrama de arquitetura explicitando os componentes da solução e os pontos de conexão das integrações. O time percebe que ele é necessário: ao invés de toda hora um ficar perguntando para o outro “Qual é mesmo o nome ou IP/porta do servidor de qualidade daquela API?”, o time sente que pode performar melhor se investir um pouco de esforço em criar um diagrama simples que possa ser consultado sempre que necessário.

O quadro Scrum também é uma expressão do modelo mental coletivo do trabalho. E a gente, como membro do time, percebe que esse modelo mental coletivo é maior do que o nosso modelo mental individual. A gente sente que a equipe consegue fazer coisas que eu, sozinho, não consigo. Mas eu faço parte da equipe, faço parte dela e contribuo com ela. Tem uma parte de meu valor aí. Só que o ponto é que o valor total é maior do que a soma dos valores individuais. A gente vê isso claramente com as histórias e tarefas no quadro.

Outra coisa que eu acho muito positivo é que com o quadro Scrum o time fica muito bem organizado. Eu podia sair mais cedo e no dia seguinte, quando eu chegasse, eu sabia exatamente no quê eu deveria trabalhar, sem correr o risco de retrabalho. Se eu ficasse até mais tarde, não precisava me preocupar em mandar um email avisando para o primeiro que chegasse no dia seguinte onde parei. Era simplesmente chegar, olhar o quadro, e puxar a próxima atividade.

Por último, o quadro Scrum tem um pouco de coisa lúdica… é como se fosse um tabuleiro de jogos, em que a gente tem que andar com os post-its para a direita. Pode parecer bobagem, mas o fato é que é de certa forma divertido fazer isso… a sensação de olhar para o quadro e ver os post-its todos à direita, na coluna ‘Feito’ é muito boa. Eu acho até que essa sensação positiva é compartilhada também pelo PO e pelos stakeholders.

Tudo isso motiva muito! E trabalhar motivado é simplesmente muito bom!”

Para fechar, um alerta: o quadro Scrum é simples, eficaz e excelente instrumento de trabalho para o seu time. Mas, ele não faz mágica. São os desenvolvedores que continuam criando o software. O quadro apenas ajuda o seu time a trabalhar melhor, nas coisas certas, e encontrar sua melhor performance.

Abraços,

Cláudio Barizon
Diretor de Produtos Digitais
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 0
Retrospectiva Scrum

O que será que o próprio time acha da retrospectiva?

Tags :

Category : Bússola Digital

Olá,

Quem ainda procura por uma oportunidade de trabalhar com Scrum na prática, costumar ter muitas curiosidades. (Não estou falando de curso de Scrum, refiro-me ao dia-a-dia, a fazer parte de um time Scrum de verdade.)

Um dos ritos mais intrigantes costuma ser a retrospectiva. Particularmente, eu acho o rito mais importante, porque é nela que vejo a oportunidade concreta da melhoria contínua dos processos.

Outro dia recebi um depoimento de um analista que trabalhou com a gente no Portal do Gerenciamento das Obras do Parque Olímpico. Veja o que ele disse sobre a retrospectiva (vou deixar exatamente com as palavras dele):

Po esqueci de falar na auto avaliação, acho q é outro ponto excelente, a “lavagem de roupa suja” ajuda a ver se tem algum gargalo na equipe/processo ou ate te faz refletir como vc poderia contribuir melhor em todo o processo.

É bacana, não é?! Um ponto importante é que ele estava bem desmotivado antes de usarmos o Scrum e depois virou completamente o jogo, realizando todo o seu potencial como profissional. “Dê autonomia ao time, que ele te entrega resultados.”

É fato.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais

PS: a foto que ilustra a matéria é deste post (em Inglês) que, curiosamente, incentiva a abolir a retrospectiva. Coloquei o link aqui porque sou a favor da pluralidade de ideias. Vale conferir. 🙂


Receba nosso Boletim

Grátis, diretamente em seu email, artigos sobre métodos de startups aplicados a soluções empresariais.