A preguiça, o medo e o otimismo.

Somos seres humanos, logo somos cheios de "defeitos de fabricação". Disso quase ninguém duvida. Está programado no nosso DNA, fruto de anos e anos de evolução e seleção natural. Por isso, somos capazes de fazer coisas boas e ruins ao mesmo tempo. Ironicamente, é esse mix de defeitos e qualidades que nos torna únicos e molda a nossa humanidade, fazendo com que  sejamos, por exemplo, mesquinhos e solidários, egoístas e amorosos, medrosos e companheiros,  invejosos e prestativos, e por aí vai...

É óbvio gostamos de nossos amigos e familiares exatamente da forma como são, com todo o conjunto de imperfeições e qualidades que possuem e é por isso que perdoamos os seus pequenos  "desvios de comportamento" (ok, ok, sei que às vezes não são tão pequenos assim). Entretanto, quando o assunto é trabalho, as coisas precisam ser diferentes. Acredito que para alcançar a excelência, um profissional (e não apenas de software) precisa monitorar 3 vícios de comportamento; são eles: a preguiça, o medo e o otimismo.

A Preguiça

Qual ferramenta devemos usar sempre? Java ou .Net? Linux ou Windows? Que padrão podemos utilizar em todos os projetos? Vamos trabalhar de forma ágil ou tradicional? A equipe irá trabalhar com SCRUM ou com o guia PMBOK embaixo do braço? Essas (e outras) questões são corriqueiras nas rodas de profissionais. Na verdade, é a manifestação da já famosa "preguiça mental". Nosso cérebro (preguiçoso) insiste na procura da "bala de prata", ou seja, uma maneira única e universal capaz de solucionar todos os problemas.

A explicação é simples: se encontramos uma maneira única para tratar todas as situações liberamos tempo e energia para outras tarefas mais interessantes, seja no trabalho ou fora dele. É por causa desse vício de comportamento que muitas soluções são descartadas de imediato, simplesmente por estarem "fora do padrão" ou por não respeitarem uma regra qualquer que deveria ser seguida à risca, não importando o contexto da situação no momento.

Monitore esse mau hábito constantemente. Saiba que geralmente há mais de uma solução para solucionar um mesmo problema. Estude diversos padrões, tecnologias e métodos. Posso ser fã de DDD mas isso não significa que irei utilizar a técnica em todos os projetos que terei que tocar ao longo da carreira. O mesmo acontece com o universo das metodologias: podemos trabalhar com métodos ágeis e aplicar outras metodologias ao mesmo tempo, obtendo assim resultados muito melhores e adaptados à realidade do negócio em que estamos inseridos. Preste atenção ao contexto, isso é o mais importante. Explore a diversidade.

O Medo

"Agile não presta, é só um modismo da garotada". "PMBOK só serve para aumentar a burocracia no projeto". "Vai usar .Net? Tá maluco!" Essas e outras pérolas são ouvidas diretamente no trabalho, na faculdade, nos fóruns e em outros eventos comuns de TI. É simplesmente o medo falando mais alto. A ciência já sabe: nós dominamos (e populamos) nosso planeta porque somos uma espécie medrosa. Por exemplo, se um antepassado das cavernas visse uma sombra remotamente parecida com um tigre ele não pensaria duas vezes: "daria no pé", mesmo que fosse apenas um coelho inofensivo. Qualquer eclipsezinho solar e todo mundo já se reunia chorando para pedir perdão pelo "fim do mundo" próximo.

Não se engane: esse instinto do "lute ou fuja" está em você, somos descendentes diretos desses medrosos que se multiplicaram aos montes porque são avessos a riscos já de berço.

Esse medo pode ser resumido em uma única palavra: ignorância. Temos medo daquilo que não conhecemos; achamos mais fácil repudiar qualquer fato novo potencialmente ameaçador (lembra do tigre?) do que analisar e estudar com calma a novidade que se apresenta. Lute contra isso! Não diga que métodos ágeis são ruins sem estudar sobre o assunto. Não critique o PMBOK sem entender o contexto e a proposta do PMI. Não acredite que ferramentas e tecnologias possam mandar nas pessoas, a ponto de determinar a qualidade de um design de software. O antídoto para enfrentar o medo é o conhecimento. Acostume-se a pensar "fora da caixa".

O Otimismo

Procuro levar a vida com leveza, otimismo e bom humor. Quem me conhece sabe. Porém, ser otimista demais em projetos de desenvolvimento é arriscado. Sistemas são complexos e imprevisíveis, pequenas mudanças geralmente ocasionam consequências impossíveis de serem previstas em plenitude. Prazos se perdem facilmente se a equipe não olhar de perto problemas e obstáculos.  Programas se tornam incompiláveis se não houver preocupação constante com merges e commits. A "lei de Murphy" é a regra, não a exceção em projetos. Por isso, uma atitude mais defensiva é sempre desejável.

Acredite, o seu componente de software não irá funcionar só porque você deseja que funcione. Os riscos não irão deixá-lo em paz só porque você está fazendo "pensamento positivo" ou pensando que "o universo conspira a seu favor". O Cosmos não se interessa pelo seu projeto; é melhor deixar essas coisas de lado e se preparar para evitar que coisas ruins aconteçam de forma racional e isenta. É preciso ter um plano para se preparar para os obstáculos que invariavelmente invadem todos os projetos de sistemas.



Conclusão: vigie sua preguiça, controle seu medo e não seja demasiadamente otimista. Assim, irá se tornar um profissional muito mais produtivo, inteligente, flexível, inovador e responsável.

Tenho certeza que você irá se surpreender com os resultados.

Até a próxima!

Palestra na Rio Info 2010

Fala Pessoal,
Tudo bem?

Estarei fazendo uma oficina na Rio Info 2010, junto com meu amigo e mestre Armênio Cardoso, nessa próxima quarta-feira, dia 01/09/2010. Vamos abordar a construção de um aplicativo Java Mobile utilizando o Agile como pano de fundo.

Quem quiser ir na oficina me avise aqui no blog (ou por email) que eu envio a senha para efetivar o convite. Temos um limite de convidados que podemos chamar.

Cliquem aqui para saber mais sobre a oficina e sobre a Rio Info 2010.

Abraços,

Os limites do Agile

Quais são os limites para o desenvolvimento ágil de software? Essa é, provavelmente, uma pergunta que passa pela cabeça de muitas pessoas (inclusive na minha). Infelizmente, não há respostas fáceis para essa questão e, para piorar um pouco, há alguns mal entendidos clássicos a respeito do tema, que ofuscam a nossa mente, e que eu gostaria de ajudar a esclarecer.

Muitos profissionais do nosso meio (desenvolvedores, professores, conferencistas, etc) têm as seguintes ideias (a meu ver equivocadas) sobre Agile:

- É bacana, mas apenas para projetos de pequeno porte.

- Tem a desvantagem de produzir código de baixa reusabilidade.

- Agile e modelos de qualidade são excludentes entre si.

Creio que essas ideias surgem pois tais pessoas têm uma visão muito pequena sobre a realidade da cultura ágil atual. A maioria delas olha para os processos individualmente, como se Agile fosse SCRUM ou XP ou LEAN ou FDD ou WHATEVER. Ora, nenhum profissional sério acredita que qualquer um desses métodos irá, sozinho, resolver todos os problemas e situações que o moderno desenvolvimento de software exige. Realmente nenhum deles tem esse poder. Agile é algo bem mais abrangente do que isso...

Agile é um conjunto de práticas, processos, ferramentas, princípios e valores que formam um arcabouço útil para desenvolver projetos de qualquer porte. É pura Engenharia de Software. Duvida? O SEI, criador do CMMI, não. Publicou um relatório convocando a comunidade de qualidade de software a utilizar práticas ágeis para atender as áreas de processo do modelo CMMI. O título é: "CMMI or Agile: Why not embrace both?". Sugestivo, não?

As técnicas mais quentes da Engenharia de Software atual estão presentes nos métodos ágeis. TDD, DDD, integração contínua, automação do desenvolvimento e testes, cliente on-site, time-boxed iterations, desenvolvimento iterativo, etc. Todas essas técnicas nasceram no seio das comunidades ágeis e estão sendo consumidas por todos os tipos de projetos (os grandes inclusive rs).

Acredito que o que falta para o Agile conseguir mais respeito nas rodas "intelectuais" do mundo do software é um maior número de links entre a Engenharia de Software e as técnicas e práticas ágeis mais utilizadas. Algo que da minha parte pretendo contribuir com a minha futura dissertação de mestrado.

Pesquisa Agile.

Laurie Williams, uma professora da North Carolina State University, vem conduzindo uma pesquisa para descobrir quais as práticas e os princípios que são mais utilizados pelas equipes ágeis.

A pesquisadora também convida os participantes a repensarem os princípios e práticas, propondo sugestões de melhoria (quando aplicável). 

Vejam os cinco princípios considerados mais importantes até o momento:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Working software is the primary measure of progress.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
5. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

E as cinco práticas mais importantes:

1. Short iterations (30 days or less)
2. Continuous integration
3. “Done” criteria
4. Automated tests are run with each build
5. Automated unit testing

Você pode conferir as atualizações da pesquisa aqui.

Caso queira participar da pesquisa é só vir aqui.

Curso agile pronto

Fala pessoal!
Tudo bem?

O curso agile ficou pronto e já saiu do forno... Montei um compacto das melhores práticas de engenharia do XP com as práticas de gestão de projetos do Scrum.

Modéstia à parte, ficou bem bacana. hehehe

Quem quiser conferir clique aqui.

Abração e qualquer dúvida é só postar que eu respondo. :)

Agile Project Management

Debates fervorosos acontecem, atualmente, na comunidade de gestão de projetos de sotware. O grande centro das discussões encontra-se na questão sobre qual seria a melhor metodologia a ser aplicada no gerenciamento desses projetos. Devemos seguir as boas práticas do PMBOK ou aplicar uma abordagem ágil, utilizando métodos como Scrum e XP? Minha resposta: devemos sempre adotar o que for melhor para cada projeto em particular.

Não devemos gerenciar projetos no estilo "by the book". Procurar por cartilhas que nos digam exatamente o que fazer é um caminho perigoso e que tem poder de levar um projeto ao fracasso. Um profissional sério deve se aprofundar no conhecimento dos frameworks e metodologias existentes no mercado para, como um médico, diagnosticar um quadro geral e indicar o tratamento mais adequado. É preciso entender a situação primeiro para depois poder traçar uma estratégia coerente, um plano de ação que seja eficaz para o case específico.

E por que não mesclar as técnicas para preencher as lacunas que cada método possui?

Podemos estar gerenciando com foco no PMBOK e mesmo assim aplicar técnicas ágeis como abordagem iterativa, cliente-onsite e reuniões de retrospectivas. Analogamente, podemos utilizar Scrum e aplicar técnicas como gestão de riscos e construção de uma visão para o produto. Conhecer mais ferramentas dá maior poder de escolha para o gestor, evitando vícios como a incessante procura pela "bala de prata" das metodologias, comportamento que engessa a atuação de qualquer profissional (não apenas de gestão).

Sendo assim, independente do método utilizado, há sempre dois pontos que são os mais importantes em qualquer projeto (especialmente os de software): pessoas e comunicação. Qualquer abordagem que priorize os complexos relacionamentos que existem entre os interessados de um projeto, facilitando a comunicação entre os envolvidos e buscando dar mais autonomia e responsabilidade às pessoas tem muito mais chance de terminar com sucesso.

Scrum e a Gestão Ágil

É consenso de que em projetos ágeis de software não há lugar para o gestor do tipo sabe-tudo,  aquele que controla o projeto por completo, assumindo a total responsabilidade pelo seu sucesso ou fracasso. Esse papel é frequentemente desempenhado pelos profissionais que seguem a cartilha do PMI, criando pouco (ou nenhum) espaço para adaptação e colaboração.

Por outro lado, há sim a necessidade de um modelo de gestão. É um erro achar que projetos ágeis se auto-gerenciam, como corretamente apontam Mike Cohn e Ken Schweber no artigo "The Need for Agile Project Management":

"One of the common misperceptions about agile processes is that there is no need for project management, and that agile projects run themselves. It is easy to see how an agile process’ use of self-organizing teams, its rapid pace, and the decreased emphasis on detailed plans lead to this perception."

Para gerenciar projetos, o Scrum trabalha com o modelo de gestão compartilhada, distribuindo responsabilidades entre os vários papéis presentes na equipe do projeto, a saber:

1 - Product Owner 

• Responsável pela Visão do produto.
• Controla o Product Backlog.
• Monitora o projeto contra os objetivos de ROI e Visão.
• Prioriza e refina o Product Backlog, medindo o seu sucesso.

2 - Scrum Master

• Monitora o processo para garantir o sucesso da equipe.
• Permite que o time se auto-organize.
• Remove obstáculos.
• Blinda o time contra perturbações externas.
• Promove rápidas reuniões diárias.
• Organiza as reuniões de planejamento, retrospectiva e revisão de cada Sprint.

3 - The Team

• Seleciona e desenvolve as estórias do Sprint Backlog
• Expande as estórias em tarefas mais detalhadas.
• Completa 100% de cada tarefa escolhida.
• Gerencia e auto-organiza o próprio trabalho.
• Diariamente inspeciona o projeto para atingir os objetivos do Sprint

Cada papel dentro da Gestão Ágil direciona esforços para entrega frequente de valor e antecipação do ROI do projeto. Em projetos tradicionais espera-se a finalização completa do projeto para se ter retorno sobre o investimento aplicado; em Scrum gera-se valor a cada pequeno incremento durante o tempo, retornando o investimento muito antes da entrega do release final e oferecendo oportunidades reais de lucro antecipado.

 

Na Gestão Ágil a responsabilidade pelo sucesso de cada projeto depende da colaboração e do comprometimento de cada um dos papéis da equipe, o que diminui o risco de se ter o destino da empreitada nas mãos de uma única pessoa.

Afinal, para que servem as reuniões diárias?

O objetivo principal da prática da reunião diária no Scrum e no XP é o de fornecer um momento para que cada membro da equipe saiba como está o andamento da iteração e se o trabalho está fluindo de acordo com o planejado para o sprint.

Cada membro do time responde a apenas 3 perguntas:

- O que fez ontem?
- O que irá fazer hoje?
- Houve algum bloqueio/impedimento?

As reuniões devem ser rápidas (10 -15 min, em média) e, por isso, são sempre realizadas em pé. Desse modo, evita-se o alongamento desnecessário e improdutivo.

Alguns cuidados, porém, devem ser tomados em sua condução:

- Ela não é uma reunião de prestação de contas com o "chefe". Ela é feita para o time! Deve acontecer todos os dias, no mesmo horário, independente da presença do líder ou qualquer papel parecido (aliás, é um bom termômetro faltar a uma reunião para saber se ela acontece mesmo sem a sua presença - caso você esteja no papel do Scrum Master);

- Não se deve perder muito tempo discutindo os pontos apontados. O objetivo é trazer visibilidade das tarefas e bloqueios para, após a reunião, o líder tomar as medidas necessárias para sua resolução;

- As perguntas não devem ser feitas, apenas as respostas serão dadas. Assim, as respostas são direcionadas a todos e não apenas a quem fez as perguntas.

- O melhor horário para sua realização é pela manhã. Caso seja impossível a realização nesse horário pode ser feita à tarde (sugiro que apenas como última opção).

Essas reuniões são de vital importância para o sucesso de um projeto evolutivo e ágil. A inspeção diária substitui a necessidade de uma documentação mais "pesada" para o projeto. Apenas os artefatos essenciais serão atualizados, como o status das tarefas e o Burndown Chart.

Muitas equipes iniciantes no mundo ágil negligenciam as reuniões diárias. Não caia nessa!

Veja o que diz James Shore:

"você deveria seguir o processo à risca antes de começar a adaptá-lo. Todas as práticas ágeis existem por razões bem fundamentadas. Entenda a essência de cada uma delas para poder, em um momento mais avançado, adaptar o processo à sua própria realidade."

Agilidade em Empresas Públicas

Como professor, tenho tido oportunidade em treinar pessoas de várias empresas públicas e autarquias federais. Gente do BNDES, da Petrobrás, da Finep, do IBGE, que vem dedicar seu tempo para aperfeiçoar habilidades em várias assuntos de software e TI.

Durante um desses cursos, em uma discussão sobre Scrum , uma questão apareceu para gerar uma certa polêmica : é possível aplicar métodos ágeis nessas empresas?

O primeiro impulso seria naturalmente responder não à pergunta, porém vamos analisar um pouco mais...

É certo que em muitas dessas empresas a burocracia pode ser excessiva e as pessoas podem estar paralisadas por processos antiquados. Também é verdade que a estrutura de poder nessas organizações, fortemente montada sobre uma estrutura hierárquica, pode dificultar o papel do Scrum Master em blindar "blindar" a equipe contra interferências externas.

Meu aluno Gilberto Martiniano, que trabalha com muitos contratos governamentais, expõe bem essa questão:

"Muito provavelmente será necessário a criação oficial desse cargo na estrutura funcional (com os devidos adicionais e descrição de obrigações, deveres, direitos e poderes) de forma a viabilizar as funções desse papel. No entanto, a ameaça da interferência externa é sempre um risco a se considerar nos projetos dentro de organizações do Governo."

Incentivos para a equipe também são difíceis de implementar, já que são de responsabilidade de "chefias" constituídas em "feudos", com constantes disputas de poder.

Porém, há vantagens também...

O horário mais tranquilo, por exemplo, favorece as práticas ágeis energizadas. O profissional sabe que raramente fará horas extras e pode se dedicar mais dentro do período de 8 horas de trabalho. No setor bancário a carga horária é ainda mais reduzida, ficando em 7 horas diárias. Dentro desse período mais "humano", as pessoas poderiam programar em par com muito mais frequência, pois o cansaço do trabalho mais concentrado é compensado pela certeza que haverá tempo para a vida após o trabalho.

No mundo privado é normal as pessoas trabalharem 11/12 horas por dia (às vezes até mais do que isso, como em bancos de investimento). Não há como implementar o trabalho energizado nessas condições...

Outra vantagem do setor público é o maior incentivo para treinamento e capacitação - na maior parte das vezes feito no próprio horário de trabalho. Meus alunos de empresas públicas chegam descansados - no período matutino - para absorver novos conhecimentos e depois vão para seus trabalhos cumprir a jornada restante de trabalho (sim, conta tempo de trabalho normal o dia de aula). Os cursos são pagos pelas empresas e contam, inclusive, para a ascensão na carreira da organização.

Enquanto isso, seus colegas do mundo privado chegam exaustos para o curso da noite (alguns dormem de bater com a cabeça na mesa), depois de uma jornada intensa de atividades. Pagam os cursos do próprio bolso e têm muita dificuldade para chegar no horário estipulado para as aulas.

Concluindo, percebemos que implantar a agilidade em empresas públicas pode ser perfeitamente possível. Haverá resistências e problemas para enfrentar, da mesma forma que há desafios a serem enfrentados em empresas privadas.

Apenas serão outros desafios...