24 outubro 2008

Falando em Agile: David Anderson

David Anderson é um dos criadores do FDD, além de ser o autor de livros como Agile Management for Software Engineering e é o bacana por trás do site Agile Management.net.

O título/motivação da Palestra: How to be successful with Agile Teams

David começa fazendo uma rflexão interessante: será mesmo que somos tão espertos assim?
Vivemos numa cultura de desenvolvimento de software em que trabalhar demais é sinônimo de ser bem sucedido, em detrimento inclusive de sua vida social. Fica a dúvida no ar:
"Working harder rather than smarter" (pois é, não precisa ser assim... )
Normalmente projetos de software são sinônimo de trabalhar horas seguidas, sem dormir, resolvendo problemas com o projeto. E claro, normalmente a culpa é da equipe: desenvolvedores desajustados que não sabem trabalhar direito! shame on us!
Não deve ser assim!

Nota interessante: Barry Boehn, estudou "milhares" (sera?) de projetos e concluiu que:
Gerenciamento pobre pode ampliar os custos de um projeto de software imensamente mais rápido que QUALQUER outro fator (!!!)
Significa dizer que, normalmente, gerentes não são os principais responsáveis pelos problemas do time: atrasos, falta de comprometimento, falta de iniciativa, pouca maturidade em resolver conflitos e por aí vai...

Segundo David, um gerente do Starbucks trabalha imensamente melhor que qualquer gerente de software (!!). Pois ele conhece o negócio da empresa, tenta influenciar de maneira benéfica os seus funcionários, e conhece as atividades que são o foco principal do starbucks (seria isso um desafio? Você, gerente, conhece o que a sua empresa faz?)

Receitinha de bolo para um mundo feliz



Como não poderia deixar de ser, foi apresentado uma pequena receita de como criar um ambiente de sucesso para equipes de software. Portanto, segundo David Anderson, para criar equipes realmente eficazes e bem sucedidas você precisa de:


  • Focar em Qualidade

  • Reduzindo a quantidade de trabalho "em andamento"

  • Balancear a demanda de acordo com a capacidade

  • Priorizar


Se tudo der certo, você ainda ir para o próximo nível de ultra mega maturidade:
  • Remover a variabilidade no processo


Então vamos lá, explicando os itens:

Focar em Qualidade

Cara, pode parecer que todo mundo sabe disso, mas é mentira!!! Ninguém foca em qualidade, e isso é frustrante! "Ah, nosso projeto é focado em qualidade, mas não se preocupem, logo vocês terão tempo para produzir testes automatizados..." bulshit!
(ok, voltando)

Para os gerentes: Deêm permissão para sua equipe trabalhar com qualidade
Parece estranho? Mas não é... que tal permitir à sua equipe construir softwares sem bugs. Pergunte-lhes o que eles precisam para isso!

Segundo Peter Drucker, todo trabalhador do conhecimento é um executivo! Temos, como desenvolvedores, que tomar muitas decisões, que irão afetar o rendimento de sua empresa!!! Como assim??
Imagine uma equipe construindo um sistema... mas sem testes, e com poucas práticas de qualidade de software. Bem, na hora de desenvolver, um programador toma a decisão de não gerar um teste automatizado para uma funcionalidade nova.

Após 6 meses de desenvolvimento, um problema ocorre no software, em decorrência da decisão do programador. Sua empresa terá problemas! E problemas com dinheiro!!!
Pergunte-se o por que as funcionalidades de um sistema demoram cada vez mais para serem desenvolvidas, e perceberá que, normalmente, existe uma baixa preocupação com qualidade! E o pior: não precisamos testar, afinal de contas, o cliente precisa da funcionalidade pra ontem. Como o Marcio Marchini sempre diz: "pay me now, or pay me later"
Permita aos seus desenvolvedores fazerem a coisa certa. Qualidade não se discute
Chegar ao numero ZERO de defeitos num sistema é impossível, mas QUASE zero é perfeitamente factível. Faça com que seus desenvolvedores e testers tenham orgulho do que eles produzem! Dê uma chance à Qualidade

Crie a mentalidade "Stop the line": No momento em que problemas acontecerem eles devem ser corrigidos!

Introduza a mentalidade Test First em todas as fases de desenvolvimento, inclusive em entrevistas. Que tal criar um Exit Criteria para suas reuniões de levantamento de requisitos?

Crie uma definição de "Done" e defenda isso dentro de sua organização.

Para o primeiro estágio está bom... continua logo..

Reduzindo a quantidade de trabalho "em andamento"



Imagine um malabarista: quanto mais itens ele precisa equilibar ou jogar para o alto, maior é o risco de um acidente. O mesmo ocorre em nossos projetos.
Trabalhar em muitos itens ao mesmo tempo amplia a complexidade do projeto, e por isso existe uma enorme chance de algo dar errado. O Guilherme já escreveu algo a respeito disso em seu blog.

Quanto mais trabalhos InProgress, maior é o índice de defeitos, logo: lute contra isso!

Então, o David apresentou dois gráficos: o primeiro contendo uma equipe que trabalha minimizando a quantidade de trabalhos em andamento ao mesmo tempo, e outra equipe que não faz isso...
Segundo o cara, ele possuí vários outros estudos iguais, mas o resultado é sempre o mesmo: atrasos e um Bug rate monstruoso!!! Com uma equipe focando em qualidade e outra equipe sem essa preocupação, a quantidade de problemas no projeto é, normalmente, 30 vezes maior!!! E ai, vai tentar medir isso em sua empresa? Só a reducao de bug jah justifica pensar a respeito.

Como estimular sua equipe a criar Quase Zero defeitos

  • Meça a quantidade de trabalho em andamento

  • TDD

  • Integração Contínua

  • Crie formas de encontrar e informar sobre defeitos aos desenvolvedores de forma rápida e não burocrática

  • Crie um sistema kanbam para 'controlar seu desempenho/capacidade"



Bem, vou assitir a palestra do Alexandre Magno agora... logo mais continuo

2 comentários:

  1. Stop the line culture rules! Tratar um impedimento como algo real que precisa ser resolvido e não um... "foi pequeno imprevisto... passa outra tarefa e depois a gente vê isso...".

    A idéia de encarar um impedimento como um "problema" leva o time a trabalhar na resolução efetiva do mesmo.

    Acho isto muito válido.

    A parte da qualidade, aí puxa Drucker (http://en.wikipedia.org/wiki/Peter_Drucker), Deming (http://en.wikipedia.org/wiki/W._Edwards_Deming), Ohno (http://en.wikipedia.org/wiki/Taiichi_Ohno)... tudo isto vai te levar a coisas como Princípios de Qualidade da ISO 9000 (http://www.iso.org/iso/qmp) e Manifesto Ágil (www.agilemanifesto.org).

    Tava muito legal este evento né? Uma pena que não fui no primeiro dia, mas pude ver o pessoal da Globo.com no segundo dia e a palestra do pessoal do IME sobre o o livro da Linda Rising (http://www.infoq.com/interviews/Linda-Rising-Fearless-Change)... bom, vamos nos falando aí!

    ResponderExcluir
  2. Com certeza, o evento foi bastante interessante!

    Ouvi na semana passada um podcast na Agilcoop falando exatamente sobre o tema! Na mesma hora comprei esse livro da Linda... espero que ajuda no trabalho...
    http://agilcoop.incubadora.fapesp.br/portal/agilcast/episodios/Agilcast11-Padroes%20para%20introduzir%20novas%20ideias.mp3

    é isso ai!
    Gostei muito da tua apresentação... logo escrevo mais sobre ela... parabens pelos cases! Me deu muitas idéias de como convencer o povo lah do trabalho!

    ResponderExcluir