Lançamento do portal InfoQ Outubro 25, 2008
Posted by Felipe Rodrigues in Notícias.Tags: agile, Eventos, fratech, infoq, java, soa
add a comment
No próximo dia 01 de Novembro a Fratech realizará o evento de Lançamento do portal InfoQ Brasil. A idéia é oferecer ao público uma prévia do conteúdo do portal através de apresentações de novidades e opinião dos editores.
Buscamos nomes muito interessantes para cara Queue, como Fabio Akita para falar de Ruby, Yara Senger para falar de Java, Alexandre Gomes em SOA, Wagner Santos em Architecture e Manoel Pimentel e Victor Hugo em Agile.
Além dos editores brasileiros, contaremos ainda com a presença do Floyd Marinescu, criador e fundador do InfoQ.com (e antes disso do portal The Server Side) e de Heather Van Cura, gerente no JCP (Java Community Proccess) que falar sobre como o JCP funciona e como ele pode influenciar o mundo open source com padrões.
O evento acontecerá no auditório da Faculdade Anhembi Morumbi, parceira da Fratech já faz algum tempo, localizado na Rua Casa do Ator, 275.
Contamos com a presença de todos aqueles que como eu, esperam que a infoQ Brasil venha para contribuir para a comunidade brasileira de desenvolvimento de software.
Compareça e saiba mais sobre como funciona a InfoQ Brasil e quais são as possibilidades desta nova iniciativa.
Acesse www.fratech.net/infoq para mais informações. =)
Sobre o autor:
Felipe Rodrigues
Mude! Outubro 20, 2008
Posted by Francisco Trindade in Uncategorized.Tags: agile, praticas, principios
add a comment
Semana passada estive presente no Rails Summit Latin America, que foi realizado em SP (por sinal, ótimo evento 
), e uma das coisas que chamaram a minha atenção foi o que o Chad Fowler falou em sua palestra:
Experiência real é igual à mudança. Para a maioria das pessoas, 9 anos de experiência equivalem a 9 anos fazendo o seu trabalho do mesmo jeito, mas experiência conta somente se você está aprendendo continuamente como trabalhar melhor
Isso me chamou a atenção porque frequentemente se vê pessoas tentando utilizar metodologias ágeis como se fossem receitas prescritivas, como “eu utilizo Scrum, ou XP, ou FDD, etc..”.
Não me canso de repetir isso, mas como o Manifesto Ágil já dizia:
We are uncovering better ways of developing software by doing it and helping others do it.
Então não tenha medo de mudar e tentar coisas novas, nem de adaptar as práticas ágeis para o contexto que você se encontra. A melhor maneira de desenvolver software é a que funciona para você. Mude!
Um abraço,
Francisco
Sobre o autor:
Francisco Trindade
Visão Ágil – Edição 05 Outubro 16, 2008
Posted by Victor Hugo Germano in Uncategorized.5 comments
Saudações a todos!!
Sim, demorou um bocado, mas conseguimos!
Nestes últimos meses conseguimos reformular a revista, tentando apresentar ainda mais conteúdo e qualidade para os leitores e para a comunidade Ágil brasileira.
Com a incrível participação do Felipe Rodrigues, que nos ajudou muito com os seus dons artísticos, apresento a todos vocês: Visão Ágil Edição 5
Nesta edição você vai encontrar:
Artigos:
- Confiança: O caminho para a Agilidade
- Lean: A arte de eliminar o desperdício
- Os 7 pecados capitais de um time Ágil
- As 5 doenças do gerenciamento de projetos – Causa 5
- Como construir um Backlog Orientado a Negócio
Entrevistas:
- Ian Roughley – Líder do projeto Struts2
- Marcio Marchini – CTO da Audaces Automação
Comunidade:
- Maré de Agilidade agita o Distrito Federal
Leia, comente, divulgue!!!
Um abraço e bom proveito!!
Victor Hugo Germano
Editor – Visão Ágil
Desenvolvendo bons produtos através do Poka-Yoke Outubro 16, 2008
Posted by Manoel Pimentel in Lean.Tags: Ferramentas, Lean, Scrum, toyota
3 comments
- Para controle, pois quando o mesmo é ativado, a linha de produção é interrompida automaticamente para que o problema detectado possa ser resolvido.
- Para advertência, apenas usando algum tipo de alarme visual para sinalizar às pessoas envolvidas, que algo precisa ser revisado para evitar um problema maior.
- TDD (Test-Driven Development) – Talvez essa seja a prática de maior aplicação como Poka-Yoke pela comunidade ágil mundial, pois na essência, com TDD podemos capturar quando ocorre um erro no código, parar o desenvolvimento, corrigir o erro e atualizar o teste unitário para que o mesmo possa prevenir futuras ocorrências daquele referido erro.
- Inspeção de Código - Outra forma que também julgo ser uma importante implementação de Poka-Yoke, é a inspeção de código feita entre os membros da equipe, que apesar de ser baseada em atitudes, é uma interessante maneira de verificar, antes de promover uma funcionalidade ao Build que será entregue, se o código produzido, está dentro dos padrões escolhidos para o projeto, se está seguindo boas práticas, se está feito da maneira mais simples possível, ou se está em acordo com o teste desenhado previamente para aquela funcionalidade.
- Gestão de Impedimentos através de KanBan – Talvez não seja um mecanismo com a finalidade de parar um Lead Time de um projeto, porém, a atitude de manifestar algum impedimento visualmente através do quadro informativo, têm um impacto psicológico muito forte na equipe, fazendo com que o mesmo sirva como uma forma de alerta de que algo precisa ser resolvido dentro do projeto, antes que se torne um problema mais grave.
- Feedback Contínuo – Para concluir essa breve lista, acredito que através das cerimônias como Sprint Review ou a Sprint Retrospective, podemos ter fotografias muito nítidas de como está a qualidade do produto que está sendo desenvolvido e de quão eficiente e eficaz está o nosso processo de desenvolvimento, portanto, conforme o resultado dessa fotografia, podemos criar um Kaizen, que é outro conceito Toyota, que trabalha com a aplicação de pontos de melhoria contínua no produto ou no processo. Inclusive, através desse feedback contínuo, podemos exercitar também o Hansei, outra idéia muito importante da filosofia Japonesa (Aka Toyota), que consiste em fazer uma profunda auto-reflexão para identificar quais foram as falhas e os pontos de melhorias num processo ou num produto.
Sobre o autor:
Manoel Pimentel, CSP
É Engenheiro de Software, com mais de 15 anos na área de TI, atualmente trabalha com como Coach em metodologias para importantes empresas do segmento de serviços, indústrias e bancário. É Diretor Editorial da Revista Visão Ágil, Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.
Contatos: manoel@visaoagil.com
Projeto Ágil, de Nível Nacional e no Governo! O Case Encceja. Outubro 14, 2008
Posted by Renato Willi in Experiências, Notícias, Scrum.Tags: agile, case, encceja, governo, inep, mec, Scrum, xp
10 comments
É verdade! E não é que os tempos estão mudando mesmo? No último dia 06 de outubro, entrou no ar o Encceja: Exame Nacional para Certificação de Competências de Jovens e Adultos. Ou, da forma mais fácil como nos descreveram, tipo um supletivão do governo.
Nossa história com o projeto começou quando eu e o Bruno fomos chamados pelo Fábio Petrillo, Coordenador Geral de Sistemas de Informação do INEP para ajudarmos o pessoal a trabalhar com Metodologias Ágeis. Não houve esforço nenhum para o Petrillo comprar a idéia, pois ele já acreditava em Agile e já tinha trabalhado com isso antes. Já leu os livros que eu li, os que você já leu e mais um monte que a gente nem ouviu falar ainda. É um cara que sabe das coisas.
O desafio pra gente era com a equipe, pois não seria legal chegar com “pose” de consultor pedindo pra eles fazerem as coisas de uma forma completamente diferente e depois ir embora deixando eles com o pepino na mão. Eles tinham que ver muito rápido benefícios nas práticas adotadas, e ver que estávamos do lado deles, senão a consultoria e o projeto iam afundar. Não sabíamos por qual prática começar, nem como abordar o pessoal.
Restavam 11 semanas de projeto e o prazo não era negociável por força de lei. A equipe começou com Danielzim, Cláudio Alberto e Sandro. Depois entraram Robert (JBoi Seam), Vitor e Kelly.
O desafio inicial era enorme. O projeto já tinha um módulo administrativo funcionando, com algumas fraquezas, e tínhamos que migrar o banco, desenvolver a inscrição web e refazer o módulo administrativo. Ao longo do projeto, a idéia da migração do banco e do redesenvolvimento do módulo administrativo foram abandonados. Ainda bem! A inscrição web já tinha por si suficientes desafios. Tinha que resolver diversos problemas legados de outras inscrições.
Cláudio Alberto pilotando o sistema apresentado pela equipe, para dar feedback ao cliente. Atrás: Bruno, Vitor, Petrillo, Robert e Daniel
Começamos levantando tudo em estórias e planejando iterativamente. A equipe tem muito mérito pois absorveu as práticas de forma surpreendentemente rápida. Também são muito habilidosos e desenvolveram as coisas bem rápido. No começo eu e o Bruno achamos as estimativas otimistas demais, que acabariam se frustrando, mas eles conseguiam cumpri-las muito bem. Havia receios por parte deles em relação à não utilização de casos de uso com toda descrição do sistema. Acredito que há até hoje! 
)
O Kanban começou numa porta de armário. Falta de espaço não pode servir de desculpa pra não começarmos a utilizá-lo. Depois foi pra um quadro chique, com product burndown e tudo mais.
Ao longo do projeto, o Cláudio foi fazendo a interface com o cliente a cada versão gerada e também levantava casos de teste, pois o cliente tinha restrições em estar presente. O feedback gerou diversas alterações que melhoraram bastante o sistema e também permitiram que escopo fosse cortado dessa release. Foi bom pra todos. O pessoal desenvolveu testes automatizados e também se ajudou em pares. Inclusive, pra eles isso foi um ponto forte destacado: a integração da equipe de desenvolvimento.
Par que nada, esta foi uma triple do pessoal, pra resolver problemas na automação de testes.
Uma das últimas stand-up meetings do projeto, falando dos testes e ajustes finais.
Após o sistema entrar em produção, a equipe já estava gerando versões com naturalidade e confiança pra ir corrigindo detalhes e disponibilizando versões a cada dia – graças às builds semanais. Na última visita que fizemos a eles, dia 8, já havia cerca de 20 mil inscritos (Rodando no JBoss – cha chim!!$$$), e consideramos o projeto um grande case de sucesso com agile.
Claro que ainda há muito o que aprender, aliás, essa é a moral da história: sempre há! Agora o desafio é espalhar a cultura no resto do departamento. Já sabemos que outro projeto vai começar a adotar metodologias ágeis, o Enem. Em breve, de um jeito ou de outro, todos acompanharemos os resultados – acredito que seja com muita alegria, como no case do Encceja.
Abraço a todos, parabéns ao INEP pela coragem e parabéns à equipe pelo ótimo trabalho!!!
Willi
PMBok x Agile: análises e manuais Outubro 4, 2008
Posted by Bruno Pedroso in Business, Pensamentos.add a comment
Aqui estou com o “CMMI – Guidelines for process Integration and Product Improvement” na minha frente, tendo acabado de ler o excelente post do Willi sobre PMBok e Agile. (Me lembro agora como fiquei impressionado com a estruturação desse livro. Cada referência é feita com uma precisão cirúrgica. Cada coisa tem um código, cuidadosamente atribuído e utilizado para remeter aos tópicos citados. )
A discussão sobre se “é possível aplicar PMBok/RUP/CMMI/MPS.Br com Agile” não faz mesmo muito sentido, no fim das contas. Todas essas siglas do time das metodologias tradicionais, não passam de diferentes visões a respeito do processo de desenvolvimento. Tratam-se de modos diferentes de se entender um “mundo” específico: o de projetos de desenvolvimento de software (Eu sei, não se aplicam apenas ao desenvolvimento de software, mas isso não é importante agora).
Modo de entender também específico, diga-se de passagem. São visões essencialmente analíticas, que procuram clarear as coisas “destrinchando” ou “separando” seus elementos, numa estratégia “dividir e conquistar”. O oposto seria o entendimento sintético, onde se parte de vários elementos e compõe-se um todo, como fazemos ao concluir um texto: juntamos tudo o que foi dito para se reconstruir a idéia geral novamente.
Sob esse ponto de vista, conjuntos de conhecimento como PMBok e CMMI seriam muito bem apresentados em um MapaMental.
(conteúdo tirado da wikipedia)
Cá pra nós, trata-se de uma bela análise de todos os elementos necessários à grande maioria dos projetos de software. Alguns vão descordar com o meu “necessário”. Muitas dessas coisas podem não ser realmente necessárias… Será? Peguemos alguns elementos como exemplo.
- Controle de mudanças do escopo
“Ora, em meu projeto ágil eu não preciso fazer controle das mudanças do escopo.”
Como não? E o que é que estamos fazendo quando não permitimos, de jeito nenhum, mudanças no backlog ao longo de um sprint? Só permitimos que novas tarefas entrem no planejamento a partir de uma reunião com toda equipe. Pra que? Pra que se possa controlar as mudanças no escopo, oras. Se a equipe não tiver controle sobre as mudanças no planejamento, não poderá lidar com elas.
- Gerênca de riscos
“Não tenho um plano de riscos em meu projeto ágil.”
Pode ser. Mas dizer que não há gerência de riscos já é demais. Os riscos são gerenciados o tempo todo. Pelo product owner ao escolher histórias durante o planejamento; pela equipe ao estimar; pelo coach ao cultivar a disciplina em se escrever testes automáticos. Todos avaliam os riscos de cada passo ao longo do projeto.
Dê uma olhada na estrutura de tópicos desses livros. São análises extremamente detalhadas, completas e estruturadas. Trata-se de um trabalho de mestre. Identificar, estruturar e descrever cada um desses elementos foi sem dúvida um trabalho notável e de grande valor para nossa indústria. Obrigado.
O problema não está exatamente na análise que essas abordagens fazem. As análises são espetaculares. O problema é que, no dia a dia de um projeto, essas análises são inúteis.
É como comprar um manual de direção de automóveis que faz uma análise detalhada de todas as técnicas para se apertar a embreagem, o momento ideal para se passar as marchas, etc. Por mais detalhado e acertado que esteja o manual, não ajuda nada levá-lo no colo na hora de dirigir. Nem adianta estudar cada detalhe e tentar lidar com tudo de uma vez.
No momento de dirigir, o que importa não são os detalhes, mas o todo. Tentar visualizar, compreender e controlar cada um dos elementos envolvidos é ao mesmo tempo inútil e desgastante. É coisa demais.
Isso nos leva diretamente ao argumento do Willi. Ninguém disse que se precisa aplicar tudo o que está nos livros. Pelo contrário, os capítulos iniciais de todos eles afirmam categoricamente que tudo deve ser adaptado, escolhido, filtrado. O problema é que nenhum deles explica como as coisas devem ser escolhidas, nem tampouco adaptadas. As práticas precisam ser modificadas para o seu projeto especificamente. Mas como? Problema seu.
Dessa forma, a leitura subliminar que se faz é que os projetos devem ser gerenciados sob todos os aspectos. Quanto mais detalhes se consegue visualizar e documentar, mais maduro seu processo é. Sobre isso cria-se uma escala de mérito totalmente deturpada, baseada em inspeções, avaliações, provas, exames e outras atrocidades. Elementos artificiais, que contribuem apenas para enviesar ainda mais o processo de melhoria, cuja preocupação maior passa a ser o certificado que se ganha no final. (Não me parece muito um sinal de maturidade… :-/ )
XP e Scrum, ao contrário, não fazem leituras analíticas. Lidam com questões práticas que se sustentam através de uma cadeia de valores explícita e coerente, reflexo das necessidades reais de projetos reais. Você adora cálculos geométricos complicados e instrumentos de precisão. Ótimo, mas para levantar a parede reta seu pedreiro precisa é do fio de prumo.
Pra ser honesto, no livro mais importante sobre XP (na minha opnião), KentBeck faz também uma leitura analítica: XP divide-se em valores, princípios e práticas. Mas veja que nesse caso não se trata de uma análise do processo de desenvolvimento em si. A análise feita refere-se ao modelo de pensamento utilizado para sustentar as práticas.
Essa sim é uma análise relevante. Ela privilegia não uma visão específica de como se deve fazer software, mas uma estrutura de decisão que nos auxilia a definir como as coisas devem ser adaptadas em cada caso. Diferentemente dos livros citados acima, aqui a forma como as coisas devem ser adaptadas é clara e coerente.
O próprio Kent Beck ressalta que os princípios apresentados em seu livro não são os únicos possíveis. Organizações particulares podem cultivar outros valores, outros princípios. E elas devem fazê-lo! O que se coloca é que se deve utilizar uma cadeia de raciocínio análoga para se definir como deve ser o dia a dia dos projetos. Entenda seus valores, expresse seus princípios e deles derive as práticas a serem seguidas.
“Para dirigir, use as duas mãos ao volante.” Isso expressa o princípio da direção defensiva, que se sustenta sob o valor Segurança. Agora, se prefere cultivar o valor do Conforto, então deixe o braço esquerdo escorado na janela, é muito melhor. Qual dos dois valores é mais importante agora? Eis um framework para tomada de decisões realmente útil.
Então, sintetizando 
, o problema de PMBok/RUP/CMMI/MPS.Br não está exatamente na análise que é feita, mas na leitura (propositalmente?) induzida de que se tratam de manuais de direção. Não são. São instrumentos teóricos maravilhosos. Mas se vc está interessado em dirigir bem, deixe-os em casa e veja as coisas da forma ágil.
(Artigo publicado originalmente no eXPressoCapital)
Sobre o Autor:
Bruno Pedroso
Bruno Pedroso é Bacharel em Ciência da Computação pela UnB, onde atualmente desenvolve seu projeto de mestrado em engenharia de software. Desenvolvedor com mais de 10 anos de experiência, atua hoje como coach de projetos e coordenador da área técnica da SEA tecnologia, dando grande enfoque à aplicação de valores e princípios XP.
Visão Ágil
Manoel Pimentel
Alisson Vale
Victor Hugo Germano
Ricardo Almeida
Jose Papo
Felipe Rodrigues
Rodrigo Yoshima
Fábio Aguiar
Guilherme Lacerda
Renato Willi
Francisco Trindade
Clavius Tales
Vinícius Manhães Teles
Bruno Pedroso
Rodrigo de Toledo
Emerson Macedo
Rodrigo Branas
