XP é só o começo…

Como praticante de eXtreme Programming desde 2003, não me considero nenhum pioneiro do assunto no Brasil. Antes disso eu já acompanhava o xispe.com.br e via que já existia gente usando XP na prática, coisa que ainda demorei mais de um ano para conseguir.

O interessante mesmo é ver como de lá pra cá muita gente abraçou XP. E se fosse para fazer uma retrospectiva do que eu notei de lá pra cá, eu chamaria atenção que:

• O aumento da comunidade pode significar tanto que XP funciona quanto que as pessoas estão frustradas com seus projetos de software atuais. E eu acredito nas duas opções.
• Muita gente está buscando adaptar XP a processos engessados, ao invés de simplesmente abraçar seus princípios.
• XP abriu as portas para uma série de outras iniciativas ágeis. Scrum é a principal delas.
• O Brasil continua atrasado no que diz respeito a desenvolvimento de software em geral.

Em resumo, me parece que aos poucos a mentalidade dos profissionais de software está mudando e um futuro mais Ágil é inevitável. Que XP seja mesmo só o começo…

O que desenvolvimento de software e governo têm em comum?

Resposta rápida:

Ambos tendem a empregar mais pessoas do que o necessário.

Ok, aqui vai a explicação detalhada. Você já reparou quanta gente está interessada em trabalhar em cargos públicos hoje em dia? Nos últimos anos o governo abriu mais de 180.000 postos para servidores públicos em diversas áreas, e sobram candidatos. O governo oferece bons salários e quem paga é o povo com serviços públicos cada vez mais burocráticos e menos eficientes. É o Estado inchado que o povo xinga mas está doido para fazer parte.

O mesmo acontece com desenvolvimento de software. Todo mundo indo trabalhar nas empresas de 3 letrinhas, e ao mesmo tempo reclamando que a maioria dos projetos de sofware é mal gerenciado, planejado, controlado ou executado. Para poder contar com um grande número de pessoas na ilusão de se entregar software mais rápido, surge a necessidade de processos mais pesados que acabam muitas vezes em atrapalhar mais do que ajudar. E ainda assim muita gente considera trabalhar em grandes empresas um bom negócio.

Felizmente no desenvolvimento de software já existem muitas empresas se dando conta que eficiência pode ser alcançada com menos processo e uma menor quantidade de profissionais bem qualificados trabalhando em equipes auto-gerenciáveis. E pro governo, alguém vê alguma saída?

O primeiro podcast a gente nunca esquece…

Finalmente, depois de algumas semanas, consegui me encontrar com o Eduardo Fiorezi no Skype para gravarmos um podcast sobre Scrum, XP, TDD, Coding Dojo etc. E mal o podcast foi publicado e já está rolando uma discussão interessante com o Vinícius Teles sobre a relação entre XP e Scrum.

Confira o post sobre o podcast ou baixe-o diretamente aqui.

Mais uma vez quero agradecer o Eduardo pelo convite, e espero participar de outros podcasts em breve

Por que desenvolvimento ágil compensa?

Se você quer a resposta simplificada:

Desenvolvimento ágil compensa porque ele faz com que o software gere valor de negócio durante toda sua existência, enquanto no modelo tradicional a tendência é que depois da versão 1.0 este valor apenas diminua.

Se quiser uma explicação melhor:

Abrace as mudanças no seu software

Um dos maiores fatores de estress em projetos de software é a mudança desordenada no escopo. As funcionalidades mudam durante o projeto com mais frequencia do que a equipe gostaria, e isso se reflete negativamente por todos os lados.

A questão é que a maioria das pessoas que já se envolveram com projetos de software sabem que as mudanças fazem parte (e a minoria se engana achando que não), porém dificilmente as pessoas se preparam para quando isso acontece. E os resultados mais comuns disso são: cliente insatisfeito, desenvolvolvedores frustrados e prazos/custos estourados. Isso sem mencionar a qualidade do produto final.

Por isso proponho 2 tarefas para melhorar este cenário:

• Defina datas para as mudanças acontecerem

Duas coisas que incomodam os desenvolvedores são: interrupções e trabalho jogado fora. Uma maneira fácil de evitar isso é educar o cliente* para que faça seus pedidos apenas em datas pré-definidas. Obviamente o cliente vai continuar pedindo alterações a qualquer momento, mas é preciso deixar claro quando que estas alterações serão trabalhadas e o qual será o impacto delas.

Se o cliente começar a ficar insatisfeito com o quanto ele precisa esperar para ter suas mudanças, é sinal que estas datas precisam estar mais próximas uma das outras.

• Automatize seus testes

Agora é a vez dos desenvolvedores fazerem a sua parte. Uma vez que as mudanças do cliente já são esperadas, é preciso fazer com que estas mudanças no software não signifiquem queda na qualidade. E é aí que entram os testes automatizados. Poder verificar facilmente todas as funcionalidades do sistema a qualquer momento é o que dá confiança para um desenvolvedor mudar qualquer coisa a qualquer momento.

O impacto de uma mudança de requisito pode ser maior ou menor, e os testes permitem verificar com mais clareza como a mudança se reflete no resto do sistema. Isto acontece porque uma vez que uma parte do software é modificada e todos os testes são executados, todos os pontos onde esta mudança causou problema são descobertos na hora. E com este feedback rápido os desenvolvedores poderão verificar se suas estimativas estavam corretas e se a implementação está correndo como o planejado.

Em resumo

Permitir que mudanças de escopo sejam bem-vindas num projeto de sofware precisa ser um esforço tanto de cliente quanto desenvolvedores e a palavra-chave para diminuir o estress é disciplina. Quanto mais previsíveis forem os clientes e mais testes automatizados forem escritos, melhor serão aceitas as mudanças.

* Definição de cliente: aquele que define os requisitos do software, não necessariamente aquele que está pagando.

The Rise of Agility

A revista eletrônica Rational Edge, da IBM, traz na sua edição de março uma série de artigos sobre desenvolvimento ágil.

No question, use of the word “Agile” — as in Agile software development — has grown exponentially over the past six years. Since the Agile Manifesto with its handful of signatories made its way onto the Web, thousands of IT consultants and development teams have approached the concept of Agility with enthusiasm and good intentions. Yet, despite this popularity, true Agile development methods are not part of standard practice by the mainstream. This month, we consider “the case for,” “the confusion over,” and the “future of” the Agile phenomenon. (Hint: we’re optimistic.)

Vale a pena conferir a lista de artigos.

XP Checklist #1: Jogo do Planejamento

Visão Geral do Jogo do Planejamento:

É preciso conhecer o problema, levantar os requisitos, estimar o esforço e definir as entregas. A colaboração tanto da Equipe de Desenvolvimento quanto do Cliente é fundamental nesta etapa que será o ponto de partida para um novo ciclo de desenvolvimento.

Objetivo:

Definir os requisitos (User Stories) de maior valor, que deverão ser entregues no final da Iteração ou Release.

Participantes:

• Cliente
• Equipe de Desenvolvimento
• Coach

Pontos principais:

• Um objetivo concreto deve ser definido para a próxima Iteração/Release
• A próxima Iteração/Release deve compreender o que há de mais valioso para o Cliente
• Os requisitos devem ser representados em User Stories utilizando a linguagem do Cliente
• O Cliente deve ter a chance de adicionar ou remover User Stories
• As User Stories devem ser compreendidas pela Equipe de Deenvolvimento
• A Equipe de Desenvolvimento pode quebrar ou unir User Stories com ajuda do Cliente
• Um Glossário pode ser mantido para guardar o significado dos termos mais relevantes
• No Planejamento da Iteração é desejável que as User Stories sejam quebradas em Tarefas técnicas pela Equipe de Desenvolvimento
• O Cliente deve priorizar as User Stories
• A Equipe de Desenvolvimento deve estimar cada User Story/Tarefa
• Equipe de Desenvolvimento e Cliente discutem o que pode ser implementado na próxima Iteração/Release
• A velocidade da equipe deve ser atualizada com base na última Iteração/Release:
  • Velocidade = (Total de Pontos) / Iteração ou Release

Resultados esperados:

• O Cliente estará comprometido a disponibilizar mais informações sempre que necessário
• O Cliente estará comprometido a dar seu feedback durante o desenvolvimento
• A Equipe de Desenvolvimento estará comprometida a entregar o que há de mais valor para o Cliente ao final da Iteração/Release
• A velocidade da Equipe de Desenvolvimento será conhecida

eXtreme Programming Checklists

Pretendo começar uma série de posts inspirados no Scrums Checklists, um minibook que resume as principais práticas de Scrum em poucas páginas, numa mistura de TO-DO List, Perguntas Frequentes e Guia de Consulta Rápida. O objetivo não é servir como fonte de aprendizado inicial, mas sim ajudar as pessoas no dia-a-dia de seus projetos.

A intenção é seguir o mesmo formato só que desta vez tratando de eXtreme Programming. Estas checklists serão voltadas para os principais papéis de quem trabalha com XP:

• Desenvolvedores: aqueles que constroem o software (programadores, analistas, testadores, documentadores etc);
• Clientes: aqueles que definem os requisitos (não necessariamente aqueles que estão pagando);
• Coaches: aquele que trabalham para manter XP funcionando 100% o tempo todo.

Em cada checklist pretendo abrir o espaço dos comentários para incluir novas informações ou dúvidas. Na versão em papel dos minibooks também existe um espaço para anotações e convenções definidas pela equipe, mas por enquanto não imagino como incluir algo do gênero na versão deste blog.

Quem puder colaborar com experiências, materiais, críticas, sugestões ou dúvidas será muito bem-vindo.

Update: Confira as checklists disponíveis:

1. Jogo do Planejamento
2. Desenvolvimento Orientado a Testes

Fazendo o treinamento de Scrum Master (de novo)

Na última semana tive a oportunidade de fazer o treinamento Certified Scrum Master mais uma vez. O evento que deveria acontecer em São Paulo foi trazido na última hora para Florianópolis e fui convidado para ajudar como facilitador. De quebra aproveitei o curso todo mais uma vez, e a experiência foi muito boa.

Este treinamento trouxe um dia dedicado somente a Gerência Ágil de Projetos, e com certeza este foi o ponto alto do curso. Além de fazer comparações entre abordagens tradicionais (PMI, por exemplo) com abordagens ágeis, pudemos aprender bastante com a experiência de mais de 20 anos da Martine Devos no assunto.

Isso significa que em breve escreverei mais posts relacionados a gerência de projetos de software. Até lá, continuarei em Floripa, mantendo a baixa taxa de atualização deste blog

Mais treinamentos Certified Scrum Master no Brasil

Tenho notado nas últimas semanas um aumento considerável de pessoas que chegam até este blog procurando informações sobre Scrum. Então aqui vai uma boa notícia: novos treinamentos Certified Scrum Master em outras partes do país: Florianópolis, Brasília, Rio de Janeiro e São Paulo.

Todos ocorrerão na mesma época, entre final de março e começo de abril e vale lembrar que o número de vagas é bem restrito, uma vez que o treinamento é muito mais prático do que teórico. Mais informações no site da TeamWare.