Agiles 2009, um GRANDE evento

Nos últimos dias 08 e 09 de Outubro tivemos a oportunidade de participar do Agiles 2009 em Florianópolis (que cidade linda). Realmente um evento ímpar para a nossa comunidade e sem dúvida está entre os melhores que já tivemos no país... ou o melhor.

O evento começou com o KeyNote sensacional de Brian Marick, um dos autores do Manifesto Ágil. Seu bom humor foi o tom de sua apresentação e seu principal foco foi sempre voltado para equipes multidisciplinares, auto-gerenciadas e, sobretudo, XP.

Várias apresentações chamaram a atenção:

A primeira delas foi a simpática Diana Larsen entitulada "TRUST – THE KEY TO AGILE TEAM COLLABORATION". Os pontos fortes foram:

• É fundamental que conheçamos as pessoas antes de trabalharmos com elas
• A credibilidade é fundamental para a confiaça entre as pessoas e isso é conseguido através do compartilhamento de informações e sentimentos
• A confiança não deve estar presente apenas no time, mas na relação que eles têm com pessoas externas

Uma segunda palestra que me chamou a atenção foi de Dave Nicolette, "Agiles Project Metrics" e uma frase resume o que foi o tom do seu discursso: "Measure just the necessary, nothing more". Outra frase de Dave que me chamou a atenção foi: "Working software is the primary measure of progress".

Joshua Kerievsky também nos deu uma aula de agilidade e arte quando comparou de maneira muito feliz os diversos estágios da arte com os diversos estágios da Agilidade. Foi ele que afirmou veementemente que muitos de nós estamos fazendo software de uma forma medieval.

Uma das palestras que mais me chamou a atenção foi a de David Hussman, um cara que tem sido mentor e coach de equipes ágeis nos EUA, Canadá, Europa, Índia, Egito, Rússia e Ucrânia. Foi recentemente agraciado com o prêmio Gordon Pask Award no último Agiles em Chicago. Fez questão de dizer que é apaixonado por música e não exitou em fazer a comparação de uma banda com uma equipe ágil.

Por fim, tivemos um belo painel com os "astros" do evento: Brian Marick, Diana Larsen, Roy Singham (ThoughWorks) e Joshua Kerievsky. Não podemos deixar de dizer que essa parte do evento teve como pano de fundo o bom humor de Brian Marick, sempre ressaltando a importância das pequenas empresas na economia mundial, o que era sempre elegantemente rebatido pelo sócio-fundador da ThoughWorks, Roy Singham. Segue foto abaixo.

Da esquerda para a direita: Brian Marick, David Hussman, Joshua Kerievsky, Roy Singham (ThoughWorks), Diana Larsen.

O ponto negativo foi saber que nós, cearenses, estamos a alguns anos atrás no tocante ao desenvolvimento ágil de sistema e, principalmente, no que se refere aos paradigmas que precisam ser quebrados por nossos profissionais.

Bom, esse foi um resumo muito rápido do que foi o evento em Floripa. Abraço.

Apresentação de SCRUM na Faculdade de Juazeiro do Norte

No último dia 19/06, eu e nosso amigo Cristiano Milfont participamos de um evento em Juazeiro do Norte onde foram feitas duas apresentações, uma de XP (Milfont) e outra de Scrum (Eu), ambas disponibilizadas no Slideshare.

Fiquei realmente surpreso com o interesse da turma e com o nível de conhecimento dos participantes, que demonstraram isso com perguntas e questionamentos bastante relevantes para os temas abordados.

Infelizmente o tempo era curto para falar tudo que gostaríamos, tanto que a segunda palestra (a qual falei sobre Scrum) terminou depois das 22:00h.

Seguem abaixo os links para acessar as duas palestras
http://www.slideshare.net/cmilfont/apresentando-extreme-programming
http://www.slideshare.net/paulofurtado/palestra-de-scrum-em-juazeiro

Esperamos novos convites para voltar a essa terra tão receptiva que é Juazeiro do Norte.

2o. Curso de Certificação Scrum Master em Fortaleza

Devido ao rápido preenchimento da turma de CSM agendada para fortaleza nos dias 25 e 26 de Junho, tivemos que abrir uma nova turma de CSM (Certified Scrum Master) nos dia 30 e 31 de Julho de 2009. O evento vai ter, novamente, total apoio do CGDT (Centro de Gestão e Desenvolvimento Tecnológico) e terá como instrutor Alexandre Magno, único Certfied Scrum Trainer do Brasil (pelo menos por enquanto, :) ).

As incrições poderão ser feitas através da Adaptworks ou através do telefone (0x11) 5585-7738.

Esperamos mais uma turma cheia em Fortaleza. Abraço.

Especificação: Documentação ou Comunicação?

Esse é um tema que já causou muita polêmica e AINDA causa, como vemos em posts como "Documentação Ágil" e "E a documentação?". Poderia citar vários outros.

Entretanto, vai aqui alguns mitos sobre documentação que ainda incomodam pessoas da nossa área:

1) A documentação serve para Especificar detalhadamente o funcionamento do sistema, pois dessa forma os Analistas de Negócio repassam algumas necessidades dos usuários para os desenvolvedores enquanto trabalham na especificação de novas funcionalidades.

Mera ilusão!!! A documentação, neste caso, está servindo como um mecanismo de comunicação entre os analistas e os desenvolvedores. Eu poderia aqui citar várias referências de profissionais que aboliram esse mecanismo de comunicação a muito tempo. Mas, em vez disso, faço as seguintes indagações:

a) Como desenvolvedor, você prefere conversar com o analista e entender as funcionalidades em 2 horas de "papo" ou prefere passar o dia lendo uma especificação de caso de uso extensa e tentar interpretar o que foi dito, ou melhor, escrito pelo Analista?

b) Como Analista (seja sincero!!), você acha que conseguiu entender perfeitamente o problema do usuário para chegar ao ponto de escrever um bolo de documentos e garantir que isso não vai mudar assim que o usuário ver o que foi implementado? Além disso, temos que ser sinceros, as pessoas que escrevem documentos de especificação não são nenhum Luís Fernando Veríssimo ou um Ariano Suassuna.

c) Como Stakeholder, você se sente a vontade para esperar que toda ou grande parte da análise seja escrita para entrar em desenvolvimento e só depois ter alguma funcionalidade do sistema pronta (ou não)?

Bom, proponho aqui (isso muitos já fizeram também) algumas ferramentas que podem substituir um documento extenso de análise: Boca, mão, pincel e quadro branco. Nesse caso, até uma foto do quadro ou um rascunho no papel podem servir para comunicação das idéias por trás de uma funcionalidade e, ao final do projeto, pode-se até criar uma documentação mais formal se for o caso

2) Deve-se ter uma documentação completa para garantir que, quando os atuais integrantes da equipe sejam substituídos, seus sucessores possam ter uma referência do que foi feito.

Ótimo!!! Mas não existe melhor documentação do que um código bem feito, e isso pode ser alcançado com algumas práticas como Programação em Par e Refatoração Contínua. No entanto, se mesmo assim houver a necessidade de uma documentação, deixe para fazer ao final do projeto, pois a probabilidade de mudanças nessa documentação será mínima.


Enfim, espero que os profissionais da área de TI possam focar muito no produto final em vez de se preocupar com atividades "burrocráticas" e desnecessárias. Não somos escritores de software, somo DESENVOLVEDORES de software.

Como usar Scrum sem ser Ágil?

Depois de uma conversa com um amigo, decidi escrever este post para esclarecer alguns pontos em relação a Scrum e Agile, segundo meu ponto de vista. Antes de apresentar os pontos de interesse, vou mostrar parte deste diálogo:

Ele: "Paulo, então ficamos combinado de entregar, ao final deste Sprint, o documento inicial de requisitos e regras de negócio?"

Eu: "Seria bom nós já entregarmos algumas funcionalidades implementadas, pois é isso que prega o Scrum"

Ele: "Nada disso, o Scrum funciona para o gerenciamento de qualquer projeto e pode ter como resultado/meta um documento com os requisitos"

Alguns podem me crucificar, mas isso me fez achar que ele, de alguma maneira, tinha razão. Realmente nós podemos ter como resultado final de um Sprint qualquer produto que dê o máximo de valor para o cliente, mesmo que seja um documento.

No entanto, apesar do o Scrum ter surgido antes do Manifesto Ágil, não consigo ver seu uso (pelo menos na área de TI) sem que esteja atrelado às premissas básicas descritas no manifesto. E uma delas é: Software funcionando é mais importante que Documentação Extensa. Se o seu cliente acha que documentação é mais importante, aconselho a leitura do post "Product Owner: Um De$graçado Ganancio$o", do nosso amigo Rodrigo Yoshima.

Dessa forma, esse simples post vem deixar clara minha opnião de que Scrum não é ágil por si só. Ele precisa das pessoas certas para ser ágil. E se estas trouxerem algumas práticas da XP como TDD, pair programming, integração contínua e o que eu chamo de AQA (Agile Quality Assurance), melhor ainda.

Confirmado primeiro curso de Certificação Scrum Master no Ceará

É com grande satisfação que comunico a todos que o primeiro curso de CSM (Certified Scrum Master) no Ceará ocorrerá nos 25 e 26 de Junho de 2009. O evento vai ter total apoio do CGDT (Centro de Gestão e Desenvolvimento Tecnológico) e terá como instrutor Alexandre Magno, único Certfied Scrum Trainer do Brasil (pelo menos por enquanto, :) ).

As incrições poderão ser feitas através da Adaptworks ou através do telefone (0x11) 5585-7738.

Esperamos turma cheia em Fortaleza. Abraço.