Ricardo Serradas

Olá pessoal,

Esse post é fruto de um susto muito grande que tomei depois de abrir o link que o André Nascimento postou em seu twitter, uma subpágina do site do PMI onde ficou exposto o posicionamento do Instituto à respeito dos métodos Ágeis. A página em questão pode ser acessada neste endereço.

Acho que a falta de argumentos e conhecimento em relação à cultura ágil os levou a escrever essa série de textos sem fundamento. Fiz a tradução de cada um deles para que pudéssemos discutí-los melhor:

Agile é uma cura milagrosa?

Apesar da badalação, Agile não é uma cura para tudo. Contudo, não que ela seja uma metodologia que não seja adequada para tocar um projeto, mas é a cultura corporativa que pode não ser propícia para os riscos e problemas que podem surgir com Agile.

Observação: Concordo quando dizem que Agile não é a cura para tudo, o próprio movimento Ágil é ciente disso. Porém, até aqui fiquei esperando quais riscos e problemas que o Agile poderia (veja, sendo Agile o causador) trazer para dentro de uma corporação…

Tudo junto agora

Gerenciamento de projetos Agile funciona melhor quando os times estão localizados no mesmo escritório.

Não importa que metodologia você usa, é sempre muito melhor ter as equipes num mesmo espaço físico em ocasiões como reuniões de kickoff e reviews periódicos.

Observação: Qualquer metodologia, framework ou modo de trabalho, que seja, funciona melhor se os membros do time estão num mesmo espaço físico. Mas denovo, fiquei esperando argumentos provando que Agile não funciona com membros do time dispostos em escritórios diferentes.

Uma questão de confiança

Para a Agilidade funcionar, os gerentes de projeto precisam sentir-se confortáveis em delegar muita responsabilidade para os membros do time, os quais também devem confiar uns nos outros.

Então você poderá esperar um pouco para aplicar metodologias ágeis, até que a confiança tenha sido estabelecida em toda a equipe.

Observação: penso algumas coisas à respeito dessa colocação:

                – Não há um Gerente de Projeto delegando confiança, atividades, ou qualquer que seja a coisa dentro de um time ágil. O que há, de uma forma geral, é um “dono do projeto”, o qual expõe suas necessidades para o time, para que os membros deste definam a melhor forma de atendê-las.

                – Supondo que o GP exista e que estivéssemos num cenário que trabalha sob o modelo comando-controle: delegar uma tarefa à alguém não é, de fato, delegar responsabilidade? Quanto tempo o GP vai esperar para delegar uma tarefa à alguém que ele acabou de contratar? Existe um período para “aquisição de confiança” para um membro recém-contratado, onde ele fica no escritório só de papo com o GP até que a confiança “nasça”? Se executar determinada tarefa não exige responsabilidade, que valor ela tem para o negócio/produto?

Está disposto a adaptar-se?

Metodologias ágeis sozinhas não vão levar uma organização ao sucesso, mas vão identificar diversas questões e problemas que precisam ser abordadas para que os projetos sejam melhores entregues.

Observação: Sim, de fato. E que mal há nisso? Na verdade, pergunto-me: isso não é MUITO bom? Acho que toda e qualquer organização deve estar disposta e ser capaz de adaptar-se, pois o mercado é mutante e, se não houver adaptação, a corporação vai ficar para trás, assim como se um time não se adaptar às necessidades do produto, ele não terá sucesso.

Quem fez CSM, viu o exemplo da Sogra? Nesse exemplo, o trainer diz que o Scrum é a sogra que entra na casa do casal, que é chata e vai apontando todos os problemas, os móveis empoeirados, as louças empilhadas, etc. Mas quem tem que arrumar isso? O casal (time)!

Disponibilidade para experiências

Sua organização valoriza experimentações? Agile conta com um baixo custo de experimentação, permitindo uma exploração iterativa e adaptável. Simulações, prototipações e testes ajudam a recolher informações valiosas sobre o projeto.

Observação: acho que esse ponto está paralelo com o abordado anteriormente. Para adaptar-se, é necessário experimentar, inspecionar novos resultados. Se não houver experimentos, como vamos saber se há algo que pode nos ajudar mais do que o que já temos hoje? Parafraseando o exemplo da sogra: como vamos saber se comprar uma máquina de lavar louças vai ser mais produtivo do que ficar lavando louça a louça se não a experimentarmos?

Equipe de “Jogadores”

Se os membros do seu time focam principalmente em objetivos individuais, as tecnicas ágeis baseadas em grupo provavelmente não serão uma boa opção.

Observação: Esse é um dos pontos os quais mais me decepcionaram. Esqueça metodologia, se você tem um time cheio de membros individualistas, você não tem um time! E digo mais: seu projeto será um fracasso. Um time se caracteriza por todos os seus membros terem um objetivo comum e estarem comprometidos com isso.

Uma mente aberta

As técnicas Ágeis não são convencionais e costumam ser difíceis de aprender.

Organizações ou times sem desejo em investir no aprendizado das técnicas necessárias provavelmente vão achar que o Agile é inadequado.

Observação: Definitivamente, não entendi esse ponto. Gostaria que exemplificassem uma técnica ágil de difícil aprendizado. Um dos princípios de Agilidade é simplicidade! E digo mais: acho um ponto muito negativo em companias que não têm interesse em investir na evolução dos seus colaboradores.

Invasão de privacidade

Técnicas ágeis são baseadas nos princípios de confiança e sinceridade, logo os membros do time devem aderir à transparência e estarem dispostos à abrir mão da sua privacidade.

Observação: Essa, definitivamente, não entendi. Se você, que está lendo esse artigo, é membro de um time ágil e perdeu sua privacidade por conta disso, comente esse post e conte-nos sua experiência. Por exemplo: se você se sente incomodado porque enquanto você está pareando com um colega de time você não pode parar para navegar no orkut, facebook ou twitter, sinto muito, mas lhe falta senso profissional.

“By the book”

Defensores do Agile alegam que uma dependência excessiva de metodologias pode sufocar a dinâmica e a evolução do projeto.

Se sua organização exige a adesão estrita à alguma metodologia de gestão de projeto fortemente estabelecida, então Agile não trará muitos benefícios.

Observação: Devo concordar com essa colocação e ao mesmo tempo concluír com ela que o projeto terá sua evolução e dinâmica sufocados. Contudo, técnicas de design iterativo e incremental não fariam mal algum à esse tipo de gestão, certo? J

Quais são suas prioridades?

As curtas iterações que o Agile proporciona ajudam a trazer resultados mais rapidamente – especialmente em termos de “Time to Market” e ROI. No entanto, isso requer refinamento constante do escopo do projeto.

Se os requerimentos do sistema fazem parte do contrato, então técnicas ágeis podem não ajudar muito.

Observação: Bom, algo tem grandes chances de variar. Se o “escopo” é fechado, é muito provável que custo ou tempo de projeto não serão fixos. Logo, não há problema nenhum em aderir à práticas ágeis quando seus requerimentos já estão estabelecidos, basta ter em mente essa variação de algum desses outros índices.

Vale o risco?

Agile oferece técnicas de gerenciamento de risco. Mas se a sua empresa ou cliente pedem um ambiente de projeto consistente e estável, então os métodos ágeis não devem ser seguidos.

Observação: Gostaria de entender porque, ao se aderir práticas Ágeis, o ambiente de desenvolvimento deixa de ser consistente e estável.

Concluindo tudo isso, eu vejo que minhas observações são questionamentos, pedidos de justificativas para cada uma dessas afirmações absurdas. Acho que se procurassem um pouco mais por fundamentos para cada um desses trechos, não teriam publicado tal página.

Bom, essa é minha humilde e rápida opinião. Sintam-se à vontade para comentar, criticar e questionar!

[]’s

Ricardo Serradas

Olá a todos!

O foco neste post é falar sobre a segunda parte do Agile Brazil 2010, onde os palestrantes apresentaram seus trabalhos e onde pude conhecer muita gente boa da comunidade ágil do Brasil.

O keynote de abertura foi de ninguém menos que Martin Fowler, um dos idealizadores do manifesto ágil. Sinceramente, ele não trouxe nenhuma novidade à nossa comunidade mas claro, falou com muita propriedade de assuntos de seu domínio, focando principalmente em práticas de engenharia de software voltadas ao desenvolvimento ágil. Muito bacana!

A grade de palestras ficou um pouco corrida, com muito paralelismo. Muitas vezes palestras que tinham tudo para ser de ótima qualidade rolavam ao mesmo tempo. Isso me desapontou um pouco. Mas o que vi foi muito bom! Dou um destaque especial para a palestra do Alexandre Gomes (@alegomes) e do Renato Willi (@rwilli), onde falaram sobre Desenvolvimento Ágil no Governo, onde demonstraram domínio do assunto e souberam reter a atenção do público com maestria.

E claro, com uma diversidade grande de palestras como essa, algumas deixaram sim à desejar, ou pelo conteúdo que era pouco atrativo, ou pela capacidade do palestrante de chamar a atenção do público.

Durante o evento, tive a oportunidade de conhecer pessoalmente uma galera de presença na comunidade ágil e de desenvolvimento de software, como:

André Nascimento – @alnascimento
Daniel Oliveira – @dfaoliveira
Igor Abade – @igorabade
Rafael Noronha – @rafanoronha
Rodrigo Vidal – @rodrigovidal

Entre outros. É super interessante a experiência de trocar idéias com esses caras através de grupos (como o DotNetArchitects), redes sociais (como Twitter) e depois conhecê-los pessoalmente e poder trocar idéias já como amigos de longa data! Foi um prazer conhecer vocês, pessoal!

Infelizmente, devido ao horário do meu vôo na sexta, não pude participar do keynote de encerramento que, acompanhando a hashtag do evento (#AgileBrazil), deve ter fechado com chave de ouro!

Abaixo, algumas fotos que tirei durante o evento:

 

Michel Goldenberg ministrando o curso de CSM	Rodrigo Yoshima falando sobre Engenharia de software no curso de CSM
Turma de CSM no Agile Brazil 2010	O evento estava começando. Hall principal. Olha nós no telão!
Galera da Stefanini em peso no evento!	Martin Fowler no seu keynote
Alexandre Gomes e Renato Willi ministrando sua palestra	Galera de peso no stand da Microsoft pareando para completar um desafio em .Net
Igor Abade em sua palestra sobre Desenvolvimento Ágil com Visual Studio	Daniel Wildt e Aleckssandro Tavares: PMBOK num time ágil, como fica?

 

Enfim, o Agile Brazil 2010 foi nota 10! Em 2011 estarei presente novamente!

[]’s

Ricardo Serradas

Olá a todos!

Post épico este! Tanto por ser o primeiro fora de São Paulo quanto por ser o primeiro que faço através de um dispositivo móvel.

Estou em Porto Alegre, Rio Grande do Sul para participar do Agile Brazil 2010. Aqui tenho tido contato com feras do mundo do Desenvolvimento de Software e de Agilidade. O evento é dividido em dois dias de cursos (terça e quarta) e dois dias de palestras (quinta e sexta) e conta com grandes nomes como Giovanni Bassi, Alexandre Magno, Michel Goldenberg, Rodrigo Yoshima, o próprio Martin Fowler, entre outros.

Os dois primeiros dias foram muito legais. Cheguei aqui na segunda e, ao sair pra jantar com alguns amigos, descobrimos no dia seguinte que na mesa ao nosso lado jantava Martin Fowler. Olha a oprtunidade de conseguir um autógrafo desperdiçada.

No dia seguinte começaram os cursos de CSM, CSPO E XP. eu participei do CSM, que acabou hoje. O curso foi bem legal e foi diferente dos cursos de CSM que já aconteceram pois, além da aula tradicional sobre o Scrum Master ministrada pelo Michel Goldenberg, algumas boas práticas de Engenharia de Software com foco no mundo ágil foram mostradas pelo Rodrigo Yoshima.

Ao final do dia, no jantar, fomos comer num lugar muito interessante: o “D’Gato” Churrasquinhos. É mole?

Abaixo, algumas fotos:

Victor Cavalcante, Giovanni Bassi e Alexandre Magno À esquerda e Rodrigo yoshima à direita, no coffee-break

Michel Goldenberg ministrando o curso de CSM

Michel novamente no curso

Bom, como estou sem computador, estou impossibilitado de fazer um post mais detalhado e de postar fotos da minha câmera também. Então, assim que estiver de posse do meu computador denovo, faço um post mais completo.

[]‘s
Ricardo Serradas