»
S
I
D
E
B
A
R
«
Maçãs podres
Feb 21st, 2009 by Joca

O termo maçã podre, apesar de bastante forte, serve para descrever uma situação bastante delicada na formação e gerenciamento de times. Chamamos de maçã podre (rotten apple) a pessoa que destoa negativamente do resto do time e que, com seu comportamento, poderá estragar a equipe.

A InfoQ falou bastante sobre esse tema da maçã podre do ponto de vista técnico, o under-performer, aquele que é ou está tecnicamente abaixo do resto da equipe. Esse post da InfoQ é um resumo de um thread na lista Scrum Development no Yahoo! Groups que gerou mais de 100 mensagens sobre o tema.

Agora, o que fazer quando nos deparamos com uma maçã podre do ponto de vista comportamental? Alguém que é tecnicamente bom, mas que tem problemas de comportamento? Tecnicamente essa pessoa pode ter bastante para contribuir para o time mas seu comportamento faz com que o time não consiga ter um bom relacionamento com essa pessoa.

Nesses casos há dois caminhos a seguir. O mais simples é tirar essa pessoa do time. Essa é uma solução fácil tanto para o time quanto para o seu líder. A tendência numa situação dessas é o time isolar a pessoa difícil até que ela, por vontade própria ou por decisão do chefe, saia do time.

O caminho mais difícil, mas que certamente trará mais benefícios para a equipe, é ajudar essa pessoa difícil a se integrar ao time ao ponto de essa pessoa deixar de ser uma maçã podre.

É fácil receber no time pessoas fáceis de lidar. O desafio é receber uma pessoa difícil e ajudá-la a se integrar ao time. Os valores do time devem ser mais fortes que os valores da pessoa difícil ao ponto de os valores do time serem absorvidos e assumidos pela pessoa difícil.

Conversas francas com todo o time e com a pessoa difícil é um bom caminho. A transparência é essencial. Se houver boa vontade e disposição tanto do time quanto da maçã podre, há boas chances de a situação ser revertida.

Vale lembrar que, na maioria das vezes, uma maçã podre não quer ser maçã podre. Ela pode não se dar conta de que seu comportamento é prejudicial para o time. Ela pode ter tido experiências anteriores onde seu comportamento seria considerado normal. Por isso vale investir em ajudar o time e a pessoa difícil a se entenderem. Contudo, não dá para tentar indefinidamente fazer com que as coisas se ajeitem. É importante definir um prazo para reavaliar a situação e, caso ela não tenha se resolvido, talvez não haja outra opção a não ser tomar uma decisão mais difícil: dispensar uma ou mais pessoas do time.

Be the first to like.

Não se nasce especialista
Feb 12th, 2009 by Joca

Consegui achar mais um tema que une a natação com gestão de produtos, métodos ágeis e desenvolvimento de sistemas, a questão de como se tornar muito bom em alguma coisa. Afinal, nascemos com um dom, ou com prática poderemos ser muito bom em algo?

Há uns 4 meses atrás li um artigo sobre natação em:

http://www.totalimmersion.net/2007articles/january/expert.html

Que me levou ao artigo “The Expert Mind” da Scientific American. O mote das duas é que dá para se transformar em um especialista do assunto desde que:

  • se pratique bastante (10 anos);
  • a prática seja consciente, ou seja, que o praticante entenda o que está fazendo;
  • se tenha um bom guia (treinador, coach, mentor, etc.) e;
  • se tenha um ambiente propício.

Recentemente esse tema voltou à tona com o novo livro do Malcom Gladwell, autor de “The Tipping Point: How Little Things Can Make a Big Difference” e “Blink: The Power of Thinking Without Thinking“, chamado “Outliers: The Story of Success“.

Curiosamente a receita de sucesso é mais ou menos a mesma: para se transformar em um especialista em algum assunto (natação, programação, gestão, aplicação em bolsa, etc.) deve-se:

  • praticar bastante (ao invés de 10 anos Gladwell propõe 10.000 horas – em 10 anos seriam uma média de 4 horas por dia útil);
  • praticar de forma consciente, ou seja, o praticante deve entender o que está fazendo;
  • ter um bom guia (treinador, coach, mentor, etc.) e;
  • ter um ambiente propício.
Be the first to like.

Liderança flexível
Dec 26th, 2008 by Joca

Flexibilidade nunca é demais. Hoje li um post muito interessante, entitulado “I Follow My Rules, You Follow Yours“, escrito por Jurgen Appelo, CIO de uma empresa holandesa chamada ISM eCompany e adepto das metodologias ágeis.

Fala da importância da flexibilidade na liderança. A princípio é um texto falando sobre metodologias ágeis de desenvolvimento, mas ao ler percebi que há ótimas dicas de liderança em geral e não somente liderença de times ágeis:

  • não é necessário ter regras e procedimentos para tudo, apenas para aquilo que importa;
  • é bom que as pessoas do time façam certas coisas de formas diferentes, isso motiva os membros do time e os ajuda a conhecer outras formas de fazer a mesma coisa;
  • inventar e seguir novas regras é uma forma de evolução não só do indivíduo, como de todo o time.

Vale a leitura!

3 people like this post.

UX ágil
Dec 26th, 2008 by Joca

Recentemente li dois posts sobre como “encaixar” UX em times que estão usando metodologias ágeis. Um deles é o “Agile UX: Como trabalhar com os designers” do Guilherme Chapiewski que trabalha na Globo.com. O outro é o “Agile UX: como integrar UX e desenvolvimento” do Antonio Carlos Silveira do Yahoo! Brasil.

Como o próprio Antonio apontou bem, essa preocupação sobre como integrar UX em um time de desenvolvimento de software que segue alguma metodologia ágil existe desde o início das metodologias ágeis. Alguns posts sobre o tema:

Aliás a busca por Agile UX no Google retorna muitas e muitas páginas dedicadas ao tema.

Um exemplo interessante é a apresentação abaixo, da Leisa Reichert que ela apresentou na Web 2.0 Expo Berlin:

Sem dúvida há várias maneiras de se integrar UX e metodologias ágeis e o correto é escolher a maneira que se adapta melhor à sua situação e disponibilidade de recursos (tempo, dinheiro e pessoas).

Contudo, queria adicionar meus 2 centavos a essa conversa. Apesar de ser importante termos especialistas em UX, pessoas que conheçam a fundo sobre arquitetura da informação, design de interação, design visual e todos os temas relacionados à experiência do usuário, acredito que UX deve ser uma preocupação de todas as pessoas do time. Não há razão alguma para o PO e os membros do time não se preocuparem com o tema e deixarem tudo nas mãos de um especialista. E se esse especialista um dia não estiver disponível? Se ele estiver ocupado cuidando de outras coisas? Ou mesmo se não tivermos um especialista em UX no time?

Não estou querendo dizer que UX não é um tema complexo, que requer muito estudo e prática, mas acredito que todos nós devemos conhecer os conceitos básicos de UX.

Vou citar duas situações exemplo que ilustram bem a importância de todo o time se preocupar com UX:

  1. Feedback: imagine que você tem em sua aplicação uma determinada função que não é executada na hora e que pode levar até 2 horas para acontecer. Na interface você implementa o comendo que executa essa função só que não informa o prazo. O usuário certamente vai se perguntar o que aconteceu, se a função foi de fato executada. Um solução é avisá-lo desse prazo logo após o comando ser invocado. O ideal é avisar antes mesmo de ele invocar o comando que executa a função.
  2. Opções: imagine que você está desenvolvendo um formulário de pagamento com opções de pagamento por cartão de crédito. Você recebe o protótipo com um select que permite escolher entre Amex, VISA e Mastercard. Você implementa esse protótipo. Na hora de colocar em produção você recebe a informação de que inicialmente o sistema só irá aceitar Mastercard. Você edita o select e remove as outras opções. A sua interface vai ficar com um select de uma opção só! O correto aqui seria remover o select enquanto houver uma opção só.

Ou seja, não é necessário ser um especialista em UX para ajudar no desenvolvimento e melhoria de UX dos sistemas que seu time cuida. Leia, estude, informe-se, afinal conhecimento nunca é em excesso!

Be the first to like.

Systemantics ou A Bíblia dos Sistemas
Dec 6th, 2008 by Joca

Outro dia me deparei com um post no blog da 37signals sobre sistemas complexos que trazia uma citação de John Gall:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.


Fuçando um pouco descobri que esse John Gall, um pediatra, escreveu em 1978 um livro chamado “Systemantics, How Systems Really Work and Especially How They Fail” com um conjunto de leis que regem quaisquer tipos de sistemas, que podem ser desde de programas de computador até o corpo humano, o universo, uma cidade, uma empresa, etc.



O livro é uma espécie de paródia ou crítica à teoria de sistemas que foi criada por Ludwig von Bertalanffy, um biólogo austríaco, no início do século passado.



Systemantics teve uma segunda edição, “Systemantics: The Underground Text of Systems Lore”:



E na terceira edição foi rebatizado como “The Systems Bible: The Beginner’s Guide to Systems Large and Small”:



Apesar de ser uma paródia, no estilo das Leis de Murphy, ou mesmo por ser uma paródia, as leis de Systemantics fazem refletir, principalmente quando as lemos pensando em desenvolvimento de sistemas e produtos de internet.

Além da citação do início desse post, gosto particularmente das leis abaixo, que refletem muito a forma de pensar das metologias ágeis:

  • The Functional Indeterminacy Theorem (F.I.T.): In complex systems, malfunction and even total non-function may not be detectable for long periods, if ever.
  • The mode of failure of a complex system cannot ordinarily be predicted from its structure.
  • The larger the system, the greater the probability of unexpected failure.
  • Colossal systems foster colossal errors.
  • Choose your systems with care.


As 5 primeiras leis são bem interessantes também:

  • The Primal Scenario or Basic Datum of Experience: Systems in general work poorly or not at all. (Complicated systems seldom exceed five percent efficiency.)
  • The Fundamental Theorem: New systems generate new problems.
  • The Law of Conservation of Anergy [sic]: The total amount of anergy in the universe is constant. (“Anergy” = ‘human energy’)
  • Laws of Growth: Systems tend to grow, and as they grow, they encroach.
  • The Generalized Uncertainty Principle: Systems display antics. (Complicated systems produce unexpected outcomes. The total behavior of large systems cannot be predicted.)


Uma lista mais completa das leis pode ser encontrada em:

http://en.wikipedia.org/wiki/Systemantics

E nos links abaixo há a lista de leis com alguns comentários:

http://www.laetusinpraesens.org/docs/systfail.php
http://www.draftymanor.com/bart/systems1.htm
http://www.ece.osu.edu/~fasiha/systemantics

Fecho esse post com uma lei específica sobre evolução que é bem apropriada aos sistemas desenvolvidos usando metodologias ágeis:

As evolution is the only system known to produce intelligent behaviour, it is to be preferred.

Be the first to like.

Por que pareamento é, no mínimo, tão produtivo quanto trabalhar sozinho?
Oct 20th, 2008 by Joca

Obie Fernandez falou na sua palestra no Rails Summit Latin America 2008 sobre porque pareamento é, no mínimo, tão produtivo quanto trabalhar sozinho:

Quando está trabalhando em par se trabalha o dia todo. Pois ao trabalhar sozinho, você vê o seu e-mail, lê blogs e etc. E essas coisas não acontecem com programação em par. Ao fim de um dia de programação em par você está cansado. Pois você realmente pensou e trabalhou o dia todo, mas você fica contente, pois sabe que teve o trabalho realizado.

Para ver a transcrição completa da apresentação, acesse o blog do Sylvestre Mergulhão.

Existem vários estudos científicos sobre pareamento. Uma das mais conhecidas estudiosas sobre o assunto é a Laurie Willians. Veja um vídeo que ela fez para mostrar a estudantes as vantagens de programação em pares:

Be the first to like.

Sobre gestão de desenvolvimento de produtos de tecnologia
Oct 7th, 2008 by Joca

Esse post é só para fazer um link para um texto muito interessante do Akita sobre vários temas que ele e eu temos conversado ultimamente sobre gestão de desenvolvimento de produtos de tecnologia:

Off-Topic: O Manifesto Ágil, ou Como se Tornar o Google

Be the first to like.

Necessidade de impor a colaboração
Oct 4th, 2008 by Joca

Quando lemos sobre como funciona a colaboração e o auto-gerenciamento em times que adotaram metodologias ágeis, sobre como tudo funciona de forma democrática, ficamos com a impressão que os desenvolvedores foram os primeiros a abraçar esses conceitos e que o difícil foi fazer a alta gerência aceitar.

Paul Glen, um consultor sobre liderança de geeks que disponibiliza vários artigos sobre o tema, escreveu um artigo entitulado “Sometimes It Takes a Tyrant to Support Collaboration” onde ele explica que muitas vezes a colaboração precisa ser defendida pelo líder em função de alguns tipos de comportamentos que são prejudiciais ao grupo. Ele dá também algumas formas de lidar com esse tipo de comportamento.

Eu gostaria de ir um pouco além e escrever sobre o que, ao meu ver, seriam as causas desses comportamentos inadequados que podem por em risco a colaboração em um time que adotou metodologias ágeis.

Há dois aspectos do trabalho de desenvolvimento de sistemas não colaborativo que tenho visto como sendo as raízes desses comportamentos inadequados:

  • falsa sensação de poder: o trabalho técnico isolado dá uma falsa sensação de poder. Se somente uma pessoa sabe fazer determinado trabalho técnico, ela começa a se sentir indispensável e acredita que seu emprego está garantido. Por outro lado, gerentes não gostam de se sentir reféns. É natural que o gerente queira que mais pessoas conheçam o trabalho de outras pessoas do time para que, na ausência de uma dessas pessoas, o time não fique capenga. As metodologias ágeis pressupõem a colaboração, chegando ao ponto de usar a programação pareada. Isso é um risco para aqueles que acham que o fato de só eles saberem determinada parte do sistema é uma garantia de emprego.
  • deficiências escondidas: o trabalho técnico isolado dá a oportunidade de esconder deficiências. Um desenvolvedor que tenha alguma deficiência, por não ter seu código revisto por outras pessoas pode facilmente esconder suas deficiências. Esse é outro cenário que um gerente não quer ver. Deficiênciais técnicas podem ser danosas não só do ponto de vista de produtividade, ou seja, algo demorar mais para ser feito do que deveria, mas também do ponto de vista de qualidade, pois código feito por desenvolvedores que escondem deficiências tem um potencial enorme de dar defeito. As metodologias ágeis, por meio da intensa colaboração que deve ser praticada, expõe as deficiências, o que também pode ser uma ameaça para alguns desenvolvedores.

Quando da implementação de metodologia ágil, pode acontecer de uma ou mais pessoas do time se sentirem ameaçadas pelos efeitos da colaboração em função dos aspectos acima e, numa situação como essa, acabarem optando por procurar outro emprego. Esse é um risco conhecido. Ken Schwaber, um dos criadores do Scrum, menciona que é esperado até 20% de turn over quando da implementação de metodologias ágeis. Ele também menciona que até 40% da gerência pode ir embora. Já comentei sobre o tema da mudança de papel do gerente nas metodologias ágeis.

Por isso, apesar de soar estranho, às vezes é mesmo necessário ser um ditador para garantir que a colaboração prevaleça em seu time.

Be the first to like.

Top 10 Agile Team Management Practices
Jun 10th, 2008 by Joca

Mike Griffiths from Leading Answers just wrote an interesting post where he explains the top 10 team practices for managing an agile team:

  1. Empower them
  2. Listen to them
  3. Trust them to get the job done and solve problems
  4. Judge when to step in / away
  5. Create a productive workspace for them
  6. Provide support for them
  7. Encourage reflection and adaptation
  8. Reward and recognize them
  9. Communications
  10. Align objectives and promote people

To get an explanation of each of those best management practices, please access Mike’s One-Page Best Practice Summary.

Be the first to like.

What's the ideal sprint length? Part II
Jun 1st, 2008 by Joca

I already talked about this issue previously, but I recently read a post about the same topic at InfoQ that brings more insights to the question:


Forces that tend to Shorten

  • No Changes: The rule of no scope changes during the current sprint. This means the organization must be able to wait on average 1 1/2 sprints before asking for a change.
  • Closure: The end of a sprint creates a good feeling, it’s a chance to celebrate the team’s accomplishments before starting all over again (Ilja Preuss).
  • Feedback: This is the chance to reflect on the work completed and how the team performed. More frequent feedback means smaller course corrections each time. (Ilja Preuss)
  • ROI: Every sprint provides an opportunity to deploy new features. (Ilja Preuss)
  • Reliability of Commitment: With shorter sprints it’s easier to tell if the commitment can be meet. With longer sprints team the team is more likely to over-commit, thinking they should be able to get that story done. (Paul Oldfield).

Forces that tend to Lengthen

  • Getting to “Done”: In some environments it can be technically challenging to get a story finished in a short sprint. (Ash Tengshe).

Be the first to like.

»  Substance: WordPress   »  Style: Ahren Ahimsa