Maré de Agilidade 2009/08/09
Posted by brunomaomeh in agile.Tags: agile, mare de agilidade, scrum, triadpigs, triadworks, xp
trackback
Evento bastante gratificante, com vários palestrantes/instrutores muito bons (nível altíssimo), além de todos serem muito gente boa (o mais importante)! Com certeza o melhor evento do ano, em Fortaleza. Valeu todos os centavos!
Gerenciamento Ágil de Projetos com Scrum
com Manoel Pimentel (Visão Ágil)
Foi apresentado um pouco da história do Scrum, partindo do Lean e depois demonstrado um pouco das práticas do Scrum. Depois colocado os participantes para participar da construção de um projeto (revista), dentro do clico de vida do Scrum.
Nessa prática, vivenciei como um Scrum Master deve agir dentro de um projeto, como era um projeto pequeno, não deu para fazer muita coisa, apenas dar apoio a equipe e a minha equipe era muito boa, quase não precisava de mim.
XP(eXtreme Programming) na Prática
com Renato Willi e Bruno Pedroso (SEA Tecnologia)
Iniciado com uma breve apresentação sobre o Extreme Programming (o que não era o foco do curso), mostrado os valores, princípios e práticas. Após a primeira apresentação, foi iniciado um projeto, colocado o XP na prática, onde um dos instrutores(Willi) seria o cliente e o outro(Bruno), fazendo Pair Programming com todos os alunos, seriamos os programadores. Durante o desenvolvimento do projeto foi amostrado muita parte do XP, colocando-o realmente em prática.
O melhor desse curso foi a utilização do TDD, uma prática que eu estava a tempo querendo vivenciar. Quando tentamos fazer uma refatoração no código, ficou altamente explicito o valor da criação de testes dentro de um projeto. Uma coisa que eu ainda não tinha participado. Em outras palavras, sensacional!
Palestras
Outro dia excepcional do evento, onde tivemos vários palestrantes excelentes e alto nível
As palestras começaram com o credenciamento dos participantes, após um café da manhã. Depois o Alexandre Gomes (SEA Tecnologia) falou sobre oq ele chamou de Manifesto 2.0, e comparou as empresas que vivem no molde antigo de desenvolvimento (empresas 1.0), com o novo modelo (empresas 2.0), uma comparação muito boa, demonstrando bem as diferenças e como as empresa 2.0 são melhores para a construção de um bom software. Em seguida o Manoel Pimentel (Visão Ágil) falou um pouco de Lean, mostrando todo o início da cultura ágil, de onde ela se desenvolveu. Após isso, o Bruno Pedroso e o Renato Willi (SEA Tecnologia) mostraram a aplicação das metodologias ágeis na SEA Tecnologia, como foi o sucesso deles com essa nova tecnologia e como ele conseguiram fazer essa mudança de cultura deles e dos clientes.
Um intervalo de almoço com os amigos da TriadWorks, muita conversa e divertimento durante esse momento de discontração!
Na volta do almoço, o Fabiano Milani (AdaptWorks) falou um pouco sobre como é realizado o planejamento de um software dentro de uma equipe ágil. Depois o Clavius Tales (Fortes Informática) falou sobre Governança no desenvolvimento ágil, reforçando tudo o que os outros palestrantes tinham falado sobre Agile, não sendo muito feliz em alguns dos seus comentários. Em seguida, foi hora de tests, tests, tests com o Christiano Milfont (XPCE), ele falou sobre BDD e TDD e quão importante é o desenvolvimento de testes automatizados dentro do desenvolvimento de um software. Um intervalo para o Coffee-Break para descançar-mos um pouco para a palestra que viria. A ultima palestra do evento, foi guiada por Fabio Kung (Caleum) onde ele mostrou onde mora a produtividade do Ruby on Rails, infelizmente o tempo foi insuficiente para ele demonstrar a fundo toda a produtividade do Ruby, porém ficou a deixa para quem não estudou Rails ainda, o faça o mais rápido o possível. Estarei fazendo esses estudos o mais rápido o possível.
O evento foi finalizado com um Painel com todos os palestrantes onde os ouvintes fizeram várias perguntas aos palestrantes e a principal pergunta que, ainda, não quer calar “Como é fechado um projeto em uma equipe ágil?” a melhor resposta que eu vi foi “Desde quando um projeto é fechado com escopo fixo? O cliente sempre quer alterar o projeto durante o seu desenvolvimento. As equipe ágeis apenas falam isso para o cliente antes do inicio do projeto e tentam não fechar o escopo antes de sua conclusão, e isso pode ser feito de várias maneira, uma delas seria cobrar por hora trabalhada.”.
Conclusão
O ensinamento que eu tive foi muito gratificante, porém é triste quando você percebe que seu chefe pensa que é agilista, mas não tem a menor ideia de o que seria isso. O evento me deixou bastante triste com a empresa onde trabalho, onde pensava que usávamos ao menos um pouco de Agile, mas acabei percebendo que não existe nada isso. O que me conforta é que agora eu posso tentar aplicar outras práticas Agilista na empresa que antigamente eu não teria condições de faze-lo.
O evento continua até segunda-feira, com o minu-curso Planejamento e estimativas em projetos ágeis com Fabiano Milani (AdaptWorks), bom proveito a todos que irão participar. Para mim, infelizmente acabou ontem. e segunda-feira voltarei à minha rotina normal, com novas ideias e novos planos para melhorar o meu desenvolvimento.
brunomaomeh.wordpress.com 
Oi Bruno, gostei da sua declaração sobre as técnicas de desenvolvimento ágil, porém tem algumas questões que não sei como são solucionadas nesta metodologia como a questão da documentação das funcionalidades, das regras de negócio dos sistemas, e também como é feito o acompanhamento do desenvolvimento sem um cronograma e como é determinado o prazo para a conclusão do projeto.
Antonio Carlos
sobre a documentação, nada dentro dos métodos ágeis lhe impede de ter sua documentação/diagramas.. os métodos ágeis, geralmente, vê a criação de diagramas como um esforço jogado fora.. diagramas não executa código, diagramas não é funcional.. em vez de documentar com diagramas.. é preferível documentar com testes automatizados (testes unitários, testes funcionais, etc).. programadores, geralmente, não gostam de ler diagramas.. preferem ler códigos executáveis..
lógico que muitas vezes o cliente exige uma pilha de documentos.. disso não podemos fugir.. mas podemos ensinar ao cliente que criar documentos, exige mais trabalho.. mais trabalho é igual à um software mais caro..
mas quando é realmente necessário a criação desses documentos, é mais indicado que a documentação seja feita junto com o sistema.. conforme o sistema vai crescendo, a documentação é sendo feita junto.. para que assim a documentação contenha apenas oque realmente tem no sistema e não o que “irá” ter no sistema.. desse modo, é mais fácil manter a documentação e o sistema compatíveis..
para o acompanhamento do desenvolvimento.. existe técnicas que auxiliam nisso.. uma dela é o Burn Down Chart (gráfico decrescente) que representa o trabalho que falta com relação ao tempo.. outra bastante usada é o Kanban (quadro de tarefas) onde tem mostrando oque foi desenvolvido e o que ainda falta, durante a iteração.. assim você não precisa nem olhar pra cara da equipe, para saber oque foi/está/será produzido pela equipe.. você pode transformar o ambiente de trabalho em um ambiente informativo.. essas técnicas ajudam bastante para o acompanhamento.. o cronograma é, basicamente, feito em cima das iterações.. cada iteração deverá possuir um pedaço do sistema funcional..
já a questão do prazo.. todo mundo quer um software que você fale.. “daqui a 6 meses ele estará pronto.” e que ele realmente esteja pronto nesses 6 meses.. mas todo mundo sabe que isso geralmente não acontece.. o prazo simplesmente estoura.. além disso, o cliente quando vai definir o projeto para determinarmos um prazo, ele sempre esquece de alguma coisa.. vejo 2 soluções.. 1. cria-se um novo projeto (retrabalho?) 2. modifica-se o projeto antigo (quebra de contrato?), nos 2 casos é necessário redefinir o prazo.. então se ter a idéia de um prazo fechado (escopo fixo) não é muito boa.. para compensar isso, procuramos criar iterações (com o cliente) para que em cada mês (por exemplo).. o cliente veja oque foi desenvolvido, para que ele possa validar.. e para que ele possa definir oque deverá ser produzido até o final da próxima iteração..
o maior problema disso, principalmente aqui no ceará, é que 90% dos softwares desenvolvidos, são desenvolvidos para o governo.. e como todos nós sabemos, existe toda uma cultura burocrática por trás de tudo que é feito pelo governo.. por isso não se pode ter um prazo aberto para a conclusão do projeto.. então tenta-se misturar um pouco das duas idéias.. para que assim possamos desenvolver o software com o escopo “meio fixo”..