As inscrições para o Porto Alegre Agile Weekend 2009 estão abertas até o dia 24 de abril.
Se você ainda não fez sua inscrição, aproveite! Já passamos dos 300, isto mesmo, TREZENTOS inscritos para este final de semana sobre Metodologias Ágeis! Venha participar conosco!
quinta-feira, 23 de abril de 2009
segunda-feira, 20 de abril de 2009
Mini-cursos estão confirmados! E ainda restam vagas disponíveis!
Os dois mini-cursos do Porto Alegre Agile Weekend 2009, que vão ser realizados nos dias 23 e 24 de abril de 2009, estão confirmados e ainda possuem vagas em aberto!
Aproveite a chance e venha aprender sobre Requisitos de Software e Teoria das Restrições!
Aproveite a chance e venha aprender sobre Requisitos de Software e Teoria das Restrições!
Entrevista com Adail Muniz Retamal sobre o mini-curso de Teoria das Restrições - dia 24 de abril de 2009 - uma atração do Porto Alegre Agile Weekend!
Antes do evento que ocorre nos dias 25 e 26 de abril, teremos dois mini-cursos. Um sobre Requisitos de Software, e um mini-curso sobre Teoria das Restrições!
Conversei com Adail Muniz Retamal sobre o mini-curso de Teoria das Restrições (TOC) que ocorre no dia 24 de abril de 2009! Leia a entrevista!
1) Adail, muitos me perguntaram se um curso falando sobre TOC não seria mais interessante em um evento para psicólogos, visto que Transtorno Obsessivo Compulsivo não é algo tão normal de ser discutido em eventos de TI. Então, para esclarecer, o que é TOC, quer dizer, a TOC que iremos trabalhar neste mini-curso do dia 24 de abril de 2009?
AMR: Boa piada, Daniel! O TOC (transtorno) e a TOC (Theory of Constraints - Teoria das Restrições) não são tão desconhecidos do pessoal de TI nem incomuns em nosso meio... Às vezes a obsessão e a compulsão só ganham nomes diferentes... :) Mas esse assunto fica pra outra hora...
Pra mim, a TOC (a das restrições) é uma filosofia prática de vida. Ah, sim, dizem por aí que é uma filosofia de gerenciamento sistêmico, para os negócios, mas essa é uma das aplicações. Quando alguém compreende os fundamentos filosóficos da TOC aprende a aplicá-la em qualquer situação, seja pessoal, familiar, profissional, emocional, racional, não importa.
O criador da TOC, o físico israelense Eliyahu Goldratt (ou apenas Eli), não se conformou com a maneira com que os negócios são tocados popularmente e começou a usar os conceitos e ferramentas da Ciência, em particular da Física. Não tem nada a ver com a Administração Científica de Taylor, mas sim com a aplicação do Método Científico e da mente de um cientista no dia a dia, seja numa empresa, seja na vida pessoal.
Aliás, este é exatamente o tema do livro mais recente de Goldratt, "The Choice", ainda sem tradução para o português (talvez será chamado "A Escolha"). Num diálogo com sua filha, Efrat, que é PhD em Psicologia, Goldratt tenta mostrar como resolver um conflito existencial fundamental: na verdade, queremos uma vida fácil ou uma vida plena?
Mas além da filosofia, a TOC tem sido aplicada com muito sucesso em Engenharia de Produção, Logística, Distribuição, Cadeia de Abastecimento, Marketing, Vendas, Contabilidade Gerencial, Engenharia de Software e TI, Gestão de Pessoas, Saúde, Educação, Serviços, Administração Pública, Psicologia Clínica e muito mais.
2) Como é esta questão de estudar TOC através de Romances? Fale um pouco sobre livros como A Meta e Corrente Crítica. Que tipo de ensinamentos estes livros trazem?
AMR: O Goldratt é um cientista e filósofo e, portanto, um discípulo de Sócrates, Platão, Aristóteles e toda a linhagem até os tempos modernos. Ele elegeu o Método Socrático como veículo de comunicação de suas idéias. Para quem não conhece, um discurso socrático é constituído por perguntas e... mais perguntas. A idéia não é dar respostas, mas provocar o pensamento e gerar conhecimento. Uma resposta pode cessar o diálogo, mas uma pergunta é um convite a ele.
Ao escrever o livro "A Meta", Goldratt sabia que as pessoas não leriam um livro técnico, mas ninguém resistiria a uma novela, um romance, uma história. Poucos vão a uma palestra, mas milhões assistem ao cinema e teatro, bem como adoram um livro com histórias.
Em seus livros, Goldratt provoca o leitor a pensar por si mesmo, a chegar nas conclusões antes de lê-las nas páginas. Os conceitos são revelados em meio a uma trama com diversos contextos, ora numa empresa, ora numa instituição de ensino, mas sempre há um drama pessoal, conjugal, familiar.
Por exemplo, em "A Meta", o drama principal é o gerente de uma fábrica que está prestes a fechar. Alex Rogo tem 3 meses para reverter a situação, senão será um caos social na pequena cidade. E como se não bastasse, sua vida conjugal está numa fase turbulenta. Ele descobre a TOC através de um ex-professor de Física, o Jonah (ou Jonas, no português).
Em "Corrente Crítica", o cenário principal é uma instituição de ensino, onde num MBA o professor Richard Silver questiona, junto com sua turma na disciplina de gestão de projetos, as atitudes e conceitos comuns nos projetos, das mais diversas áreas, e descobrem que, ao aplicar a TOC na gestão de projetos, há uma forma muito melhor de planejar e executar projetos, resultando no método revolucionário conhecido por Critical Chain Project Management (CCPM), ou Gestão de Projetos pela Corrente Crítica (no PBMOK aparece como Cadeia Crítica). O professor Silver também enfrenta dilemas pessoais e profissionais.
Há muitos livros técnicos na literatura da TOC, mas nenhum substitui a experiência literária dos romances originais. Outros autores também seguiram esse estilo e isso virou uma tradição no mundo da TOC. Eu mesmo comecei a escrever alguns artigos e até um livro nesse estilo...
3) Estes dias me comentaram se eu tinha alguma dança da chuva, já que fazia exercícios de evaporação de nuvens. Como funciona isto, quer dizer, não a dança da chuva, mas a questão de evaporação das nuvens dentro da TOC?
AMR: A TOC oferece, entre outras coisas, processos de raciocínio que permitem qualquer pessoa ou grupo responder às 3 perguntas fundamentais para uma mudança efetiva:
1) O que mudar?
2) Para o que mudar?
3) Como causar a mudança?
Para ajudar a responder cada uma usamos diagramas de causa e efeito chamados de "árvores". Mas um dos diagramas, usado em 1 e 2, é chamado de Evaporação de Nuvem, cujo nome técnico poderia ser Diagrama de Eliminação de Conflitos, pois ele permite a visualização explícita de um "problema", exposto na forma de uma contradição. Para ver um exemplo deste diagrama, acesse aqui: http://www.heptagon.com.br/intro-toc (na parte final).
Após o desenho das nuvens segue-se um processo metódico de questionamento de premissas e busca de idéias (injeções) que eliminem a contradição (conflito).
A Evaporação de Nuvem é uma ferramenta muito poderosa para ajudar uma pessoa ou um grupo a buscar soluções ganha-ganha-ganha, em vez do popular "meio-termo" ou concessão.
No meu artigo TOC em Cores (http://www.heptagon.com.br/toc-em-cores) eu falo um pouco mais sobre os diagramas clássicos.
4) Como está organizada a comunidade de TOC no Brasil? Você fundou um grupo de discussão sobre o assunto já faz algum tempo. Como tem sido esta experiência e a integração com pessoas de outras áreas, não apenas TI?
AMR: Eu comecei a falar de TOC ainda na Borland, internamente, mas depois fui abordando o tema nas minhas palestras e cursos externos. De tanto falar no assunto, as pessoas ficaram interessadas. Algumas já haviam lido "A Meta" mas não entenderam ou não praticaram os conceitos. Quando mostro pra que serve e como uso, ficam encantadas e querem aprender mais. Por isso criei, em abril/2006, o grupo TOC-Brasil (http://br.groups.yahoo.com/group/toc-brasil), para termos um fórum em português.
Ali já tivemos boas discussões sobre a TOC em geral, e também sobre a Corrente Crítica em especial. Aliás, tua brincadeira com o TOC (transtorno) tem base história, pois ocorreu nos primeiros meses do grupo, quando uma pessoa entrou pensando que era para discutir o transtorno. Quem quiser conferir o que já falei sobre o TOC e a TOC (acho que precisa se inscrever):
http://br.groups.yahoo.com/group/toc-brasil/message/76 (a msg original - leia toda a discussão)
http://br.groups.yahoo.com/group/toc-brasil/message/81 (Monk & TOC)
A comunidade TOC no Brasil ainda é bem pequena, mas o interesse tem crescido razoavelmente. A parte mais conhecida talvez seja a Corrente Crítica, devido à menção no PMBOK e difusão nos eventos de GP, além do que, projetos são bem mais divulgados por aí do que produção, distribuição e logística.
O Grupo Goldratt ainda atua de modo bem pontual no Brasil, com uma certa ênfase na região sul, mas creio que isso vai mudar a partir deste ano, com o evento da TOCICO em agosto, em Curitiba (www.taylors-oc.com). Geralmente a atuação se dá através de consultores independentes, de forma isolada ou em grupos de trabalho.
Como a TOC pode ser aplicada em praticamente qualquer área de atividade, a comunidade é bastante diversificada, com gente de variadas formações, atuações e interesses. Isso é muito bom, pois há uma troca de experiências e idéias bastante abrangente e com razoável grau de profundidade. Às vezes uma solução para um contexto pode dar idéias para aplicação em outro, como já aconteceu.
5) Quando você começou a estudar TOC, o que te levou a este caminho?
AMR: Em 2003, quando comecei a estudar a FDD (Feature-Driven Development), entrei em contato com os autores do Guia Prático da FDD, Stephen Palmer e John Mac Felsing. Após várias conversas, John percebeu que eu buscava algo mais do que uma metodologia de trabalho. Então me disse que eu pensava muito próximo a ele e que eu certamente gostaria de ler um livro chamado "Corrente Crítica", pois nele eu aprenderia algo muito importante e que me ajudaria a entender os fundamentos da FDD, da Agilidade e de outras coisas. Depois, se eu gostasse, deveria ler "A Meta".
Demorei um pouco para dar crédito, mas após algumas semanas eu consegui comprar a versão em inglês, "Critical Chain", na Amazon. Quando chegou, não larguei o livro até terminar. Nas semanas seguintes li mais alguams vezes, anotando, experimentando os conceitos e fazendo cair milhares de fichas! É claro que também saí como um louco atrás de "A Meta" e, quando achei, também devorei algumas vezes.
E como se não bastasse, após ter me encantado com a TOC, no final de 2003 David Anderson lança seu livro "Agile Management for Software Engineering: Using the Theory of Constraints for Business Results". Quando vi o livro na Amazon, comprei imediatamente! Daí em diante, a conexão entre TOC e Agile ficou para sempre estabelecida. Tanto é que o próprio Kent Beck, na segunda edição do seu livro "XP: Embrace Change" (o branquinho), dedicou um capítulo inteiro à TOC (que eu achei bem fraquinho, mas serve pra chamar a atenção). Sei também que o Alistair Cockburn (proponente da família Crystal) usa muitos conceitos da TOC em sua prática e ensino.
E quanto mais estudava, mais percebia a abrangência de aplicações e mais me aprofundava no aspecto filosófico da TOC. Hoje em dia, a TOC é meu jeito de pensar sobre a vida.
6) Neste mini-curso, qual vai ser o foco, o que as pessoas podem esperar?
AMR: O propósito do workshop é despertar a atenção e interesse das pessoas para a TOC e suas aplicações, com uma boa introdução aos processos de raciocínio. E como a audiência é um público de Agilidade, dou uma certa ênfase em formas práticas de usar a TOC nesse contexto.
Além de ganhar uma excelente visão geral, o participante já sai com uma primeira iteração com as ferramentas de raciocínio. Daí em diante é possível saber para onde ir e escolher um caminho de aprofundamento.
Quando criei esse workshop TOC Essencial a idéia era passar para as pessoas o quanto ela me ajudou e de que forma eu aprendi. Esse é meu estilo: aprendo, desmistifico e ensino.
Para quem quiser aprender um pouco mais de TOC, no caso Teoria das Restrições, fica a referência da Wikipedia em português, que é editada e mantida em parte pelo próprio Adail Muniz Retamal.
E claro, aproveite os últimos dias para se inscrever nos mini-cursos!
http://agileweekend.guma-rs.org/mini-cursos
Conversei com Adail Muniz Retamal sobre o mini-curso de Teoria das Restrições (TOC) que ocorre no dia 24 de abril de 2009! Leia a entrevista!
1) Adail, muitos me perguntaram se um curso falando sobre TOC não seria mais interessante em um evento para psicólogos, visto que Transtorno Obsessivo Compulsivo não é algo tão normal de ser discutido em eventos de TI. Então, para esclarecer, o que é TOC, quer dizer, a TOC que iremos trabalhar neste mini-curso do dia 24 de abril de 2009?
AMR: Boa piada, Daniel! O TOC (transtorno) e a TOC (Theory of Constraints - Teoria das Restrições) não são tão desconhecidos do pessoal de TI nem incomuns em nosso meio... Às vezes a obsessão e a compulsão só ganham nomes diferentes... :) Mas esse assunto fica pra outra hora...
Pra mim, a TOC (a das restrições) é uma filosofia prática de vida. Ah, sim, dizem por aí que é uma filosofia de gerenciamento sistêmico, para os negócios, mas essa é uma das aplicações. Quando alguém compreende os fundamentos filosóficos da TOC aprende a aplicá-la em qualquer situação, seja pessoal, familiar, profissional, emocional, racional, não importa.
O criador da TOC, o físico israelense Eliyahu Goldratt (ou apenas Eli), não se conformou com a maneira com que os negócios são tocados popularmente e começou a usar os conceitos e ferramentas da Ciência, em particular da Física. Não tem nada a ver com a Administração Científica de Taylor, mas sim com a aplicação do Método Científico e da mente de um cientista no dia a dia, seja numa empresa, seja na vida pessoal.
Aliás, este é exatamente o tema do livro mais recente de Goldratt, "The Choice", ainda sem tradução para o português (talvez será chamado "A Escolha"). Num diálogo com sua filha, Efrat, que é PhD em Psicologia, Goldratt tenta mostrar como resolver um conflito existencial fundamental: na verdade, queremos uma vida fácil ou uma vida plena?
Mas além da filosofia, a TOC tem sido aplicada com muito sucesso em Engenharia de Produção, Logística, Distribuição, Cadeia de Abastecimento, Marketing, Vendas, Contabilidade Gerencial, Engenharia de Software e TI, Gestão de Pessoas, Saúde, Educação, Serviços, Administração Pública, Psicologia Clínica e muito mais.
2) Como é esta questão de estudar TOC através de Romances? Fale um pouco sobre livros como A Meta e Corrente Crítica. Que tipo de ensinamentos estes livros trazem?
AMR: O Goldratt é um cientista e filósofo e, portanto, um discípulo de Sócrates, Platão, Aristóteles e toda a linhagem até os tempos modernos. Ele elegeu o Método Socrático como veículo de comunicação de suas idéias. Para quem não conhece, um discurso socrático é constituído por perguntas e... mais perguntas. A idéia não é dar respostas, mas provocar o pensamento e gerar conhecimento. Uma resposta pode cessar o diálogo, mas uma pergunta é um convite a ele.
Ao escrever o livro "A Meta", Goldratt sabia que as pessoas não leriam um livro técnico, mas ninguém resistiria a uma novela, um romance, uma história. Poucos vão a uma palestra, mas milhões assistem ao cinema e teatro, bem como adoram um livro com histórias.
Em seus livros, Goldratt provoca o leitor a pensar por si mesmo, a chegar nas conclusões antes de lê-las nas páginas. Os conceitos são revelados em meio a uma trama com diversos contextos, ora numa empresa, ora numa instituição de ensino, mas sempre há um drama pessoal, conjugal, familiar.
Por exemplo, em "A Meta", o drama principal é o gerente de uma fábrica que está prestes a fechar. Alex Rogo tem 3 meses para reverter a situação, senão será um caos social na pequena cidade. E como se não bastasse, sua vida conjugal está numa fase turbulenta. Ele descobre a TOC através de um ex-professor de Física, o Jonah (ou Jonas, no português).
Em "Corrente Crítica", o cenário principal é uma instituição de ensino, onde num MBA o professor Richard Silver questiona, junto com sua turma na disciplina de gestão de projetos, as atitudes e conceitos comuns nos projetos, das mais diversas áreas, e descobrem que, ao aplicar a TOC na gestão de projetos, há uma forma muito melhor de planejar e executar projetos, resultando no método revolucionário conhecido por Critical Chain Project Management (CCPM), ou Gestão de Projetos pela Corrente Crítica (no PBMOK aparece como Cadeia Crítica). O professor Silver também enfrenta dilemas pessoais e profissionais.
Há muitos livros técnicos na literatura da TOC, mas nenhum substitui a experiência literária dos romances originais. Outros autores também seguiram esse estilo e isso virou uma tradição no mundo da TOC. Eu mesmo comecei a escrever alguns artigos e até um livro nesse estilo...
3) Estes dias me comentaram se eu tinha alguma dança da chuva, já que fazia exercícios de evaporação de nuvens. Como funciona isto, quer dizer, não a dança da chuva, mas a questão de evaporação das nuvens dentro da TOC?
AMR: A TOC oferece, entre outras coisas, processos de raciocínio que permitem qualquer pessoa ou grupo responder às 3 perguntas fundamentais para uma mudança efetiva:
1) O que mudar?
2) Para o que mudar?
3) Como causar a mudança?
Para ajudar a responder cada uma usamos diagramas de causa e efeito chamados de "árvores". Mas um dos diagramas, usado em 1 e 2, é chamado de Evaporação de Nuvem, cujo nome técnico poderia ser Diagrama de Eliminação de Conflitos, pois ele permite a visualização explícita de um "problema", exposto na forma de uma contradição. Para ver um exemplo deste diagrama, acesse aqui: http://www.heptagon.com.br/intro-toc (na parte final).
Após o desenho das nuvens segue-se um processo metódico de questionamento de premissas e busca de idéias (injeções) que eliminem a contradição (conflito).
A Evaporação de Nuvem é uma ferramenta muito poderosa para ajudar uma pessoa ou um grupo a buscar soluções ganha-ganha-ganha, em vez do popular "meio-termo" ou concessão.
No meu artigo TOC em Cores (http://www.heptagon.com.br/toc-em-cores) eu falo um pouco mais sobre os diagramas clássicos.
4) Como está organizada a comunidade de TOC no Brasil? Você fundou um grupo de discussão sobre o assunto já faz algum tempo. Como tem sido esta experiência e a integração com pessoas de outras áreas, não apenas TI?
AMR: Eu comecei a falar de TOC ainda na Borland, internamente, mas depois fui abordando o tema nas minhas palestras e cursos externos. De tanto falar no assunto, as pessoas ficaram interessadas. Algumas já haviam lido "A Meta" mas não entenderam ou não praticaram os conceitos. Quando mostro pra que serve e como uso, ficam encantadas e querem aprender mais. Por isso criei, em abril/2006, o grupo TOC-Brasil (http://br.groups.yahoo.com/group/toc-brasil), para termos um fórum em português.
Ali já tivemos boas discussões sobre a TOC em geral, e também sobre a Corrente Crítica em especial. Aliás, tua brincadeira com o TOC (transtorno) tem base história, pois ocorreu nos primeiros meses do grupo, quando uma pessoa entrou pensando que era para discutir o transtorno. Quem quiser conferir o que já falei sobre o TOC e a TOC (acho que precisa se inscrever):
http://br.groups.yahoo.com/group/toc-brasil/message/76 (a msg original - leia toda a discussão)
http://br.groups.yahoo.com/group/toc-brasil/message/81 (Monk & TOC)
A comunidade TOC no Brasil ainda é bem pequena, mas o interesse tem crescido razoavelmente. A parte mais conhecida talvez seja a Corrente Crítica, devido à menção no PMBOK e difusão nos eventos de GP, além do que, projetos são bem mais divulgados por aí do que produção, distribuição e logística.
O Grupo Goldratt ainda atua de modo bem pontual no Brasil, com uma certa ênfase na região sul, mas creio que isso vai mudar a partir deste ano, com o evento da TOCICO em agosto, em Curitiba (www.taylors-oc.com). Geralmente a atuação se dá através de consultores independentes, de forma isolada ou em grupos de trabalho.
Como a TOC pode ser aplicada em praticamente qualquer área de atividade, a comunidade é bastante diversificada, com gente de variadas formações, atuações e interesses. Isso é muito bom, pois há uma troca de experiências e idéias bastante abrangente e com razoável grau de profundidade. Às vezes uma solução para um contexto pode dar idéias para aplicação em outro, como já aconteceu.
5) Quando você começou a estudar TOC, o que te levou a este caminho?
AMR: Em 2003, quando comecei a estudar a FDD (Feature-Driven Development), entrei em contato com os autores do Guia Prático da FDD, Stephen Palmer e John Mac Felsing. Após várias conversas, John percebeu que eu buscava algo mais do que uma metodologia de trabalho. Então me disse que eu pensava muito próximo a ele e que eu certamente gostaria de ler um livro chamado "Corrente Crítica", pois nele eu aprenderia algo muito importante e que me ajudaria a entender os fundamentos da FDD, da Agilidade e de outras coisas. Depois, se eu gostasse, deveria ler "A Meta".
Demorei um pouco para dar crédito, mas após algumas semanas eu consegui comprar a versão em inglês, "Critical Chain", na Amazon. Quando chegou, não larguei o livro até terminar. Nas semanas seguintes li mais alguams vezes, anotando, experimentando os conceitos e fazendo cair milhares de fichas! É claro que também saí como um louco atrás de "A Meta" e, quando achei, também devorei algumas vezes.
E como se não bastasse, após ter me encantado com a TOC, no final de 2003 David Anderson lança seu livro "Agile Management for Software Engineering: Using the Theory of Constraints for Business Results". Quando vi o livro na Amazon, comprei imediatamente! Daí em diante, a conexão entre TOC e Agile ficou para sempre estabelecida. Tanto é que o próprio Kent Beck, na segunda edição do seu livro "XP: Embrace Change" (o branquinho), dedicou um capítulo inteiro à TOC (que eu achei bem fraquinho, mas serve pra chamar a atenção). Sei também que o Alistair Cockburn (proponente da família Crystal) usa muitos conceitos da TOC em sua prática e ensino.
E quanto mais estudava, mais percebia a abrangência de aplicações e mais me aprofundava no aspecto filosófico da TOC. Hoje em dia, a TOC é meu jeito de pensar sobre a vida.
6) Neste mini-curso, qual vai ser o foco, o que as pessoas podem esperar?
AMR: O propósito do workshop é despertar a atenção e interesse das pessoas para a TOC e suas aplicações, com uma boa introdução aos processos de raciocínio. E como a audiência é um público de Agilidade, dou uma certa ênfase em formas práticas de usar a TOC nesse contexto.
Além de ganhar uma excelente visão geral, o participante já sai com uma primeira iteração com as ferramentas de raciocínio. Daí em diante é possível saber para onde ir e escolher um caminho de aprofundamento.
Quando criei esse workshop TOC Essencial a idéia era passar para as pessoas o quanto ela me ajudou e de que forma eu aprendi. Esse é meu estilo: aprendo, desmistifico e ensino.
Para quem quiser aprender um pouco mais de TOC, no caso Teoria das Restrições, fica a referência da Wikipedia em português, que é editada e mantida em parte pelo próprio Adail Muniz Retamal.
E claro, aproveite os últimos dias para se inscrever nos mini-cursos!
http://agileweekend.guma-rs.org/mini-cursos
sexta-feira, 17 de abril de 2009
Associados InternetSul possuem desconto no Porto Alegre Agile Weekend 2009
Se você é associado da InternetSul, aproveite os descontos disponíveis para o Porto Alegre Agile Weekend 2009! Realize a sua inscrição com 20% de desconto!
quinta-feira, 16 de abril de 2009
Trevisan Tecnologia patrocina o Porto Alegre Agile Weekend 2009
A Trevisan Tecnologia, pioneira no desenvolvimento de aplicações móveis, é mais uma patrocinadora do Porto Alegre Agile Weekend 2009, com uma cota prata!
E você, já fez a sua inscrição no evento!? Aproveite!
quarta-feira, 15 de abril de 2009
Globo.com patrocina o Porto Alegre Agile Weekend 2009
Mais uma empresa vem ajudar na organização do Porto Alegre Agile Weekend 2009 através de patrocínio! A Globo.com assume uma cota Ouro e vai estar presente no evento apresentando seu caso de sucesso no uso de Metodologias Ágeis, muito presente na comunidade e eventos pelo Brasil.
Aproveite para fazer a sua inscrição e participe do Porto Alegre Agile Weekend 2009!
terça-feira, 14 de abril de 2009
Para os PMP's! Participar do Porto Alegre Agile Weekend 2009 ajuda na renovação da sua certificação!
A cada três anos os certificados PMP (Project Management Professional) precisam renovar sua certificação e para tanto precisam acumular PDU's (Professional Development Unit). No total 60 PDU's a cada três anos.
Uma boa notícia? Participar do Porto Alegre Agile Weekend 2009 permite que você PMP acumule16 PDU's pela participação no evento.
Se você participar dos mini-cursos que ocorrem nos dias 23 e 24 ainda consegue arrecadar 8 PDU's por dia de mini-curso!
Então é isto, aproveite e faça sua inscrição no Porto Alegre Agile Weekend 2009! E não deixe de conferir os mini-cursos!
Descontos para associados SEPRORGS no Porto Alegre Agile Weekend 2009!
Associados do SEPRORGS ganham desconto para a inscrição no evento e também na inscrição nos mini-cursos. Confira!
Descontos para associados ASSESPRO-RS no Porto Alegre Agile Weekend 2009!
Associados da ASSESPRO-RS ganham desconto para a inscrição no evento e também na inscrição nos mini-cursos. Confira!
quinta-feira, 9 de abril de 2009
Neogrid patrocina o Porto Alegre Agile Weekend 2009!
A Neogrid, empresa especializada em Soluções e Consultoria em Supply & Demand Chain é mais uma parceira para o Porto Alegre Agile Weekend 2009!
Aproveite as inscrições para o evento!
Mini-Curso do Porto Alegre Agile Weekend 2009 - Requisitos de Software: Uma Abordagem Ágil
Dia 23 de abril ocorre o curso Requisitos de Software: Uma abordagem Ágil. O GUMA-RS conversou com Luiz Parzianello, instrutor deste curso, para entender um pouco mais sobre o assunto.
Você pode fazer a inscrição neste treinamento e encontrar mais informações a respeito no site do evento.
Aqui vão as perguntas:
1) O título do mini-curso é Requisitos de Software, Uma Abordagem Ágil. Diversos sites de crítica às Metodologias Ágeis comentam, por exemplo, que XP não trata requisitos. Só que quando se trabalha com XP, construímos User Stories e definimos Testes de Aceitação. O que são estes caras?
Resumidamente, as User Stories representam os requisitos funcionais de um sistema em um alto nível de abstração, sendo elaboradas com um modelo bem próximo da linguagem coloquial. Tipicamente, ela possui em sua estrutura elementos como "Quem" irá utilizar o recurso, "O que" se pretende fazer com o mesmo, "Por que" este recurso de sistema é necessário, "Como" saberemos que fizemos o trabalho de forma correta (Critérios de Aceitação) e "Quanto" pesa o problema em nossa bagagem... Para quem se deu conta, só faltam o "Quando" e "Onde" do 5W2H, que, ao meu ver, são contemplados durante o planejamento de releases e iterações bem como com a adição de comentários técnicos durante o planejamento detalhado das mesmas (durante sua iteração ou na iteração anterior). Muita gente diz que a User Story serve como lembrança do que deve ser feito, não devendo ser encarada de uma forma burocrática. No entanto, as User Stories possuem uma estrutura adequada para tornar o planejamento e controle de projeto mais objetivos, baseados em números mais realistas. Além disso, tenho observado que sua estrutura permite uma rápida captação de requisitos funcionais, além de ser suficiente para passar em auditorias baseadas em COBIT, por exemplo. Dedicarei um bom tempo explorando essa estrutura durante o curso, mostrando para os alunos como podemos aprimorar a escrita das User Stories como base num modelo linguístico de análise de problemas. Quanto àqueles que falam mal deste tipo de abordagem, é interessante ver como os mesmos se tornam cada vez menos competitivos no mercado de trabalho... Mas isso é um direito que eles tem e que não devemos brigar contra!
2) Na questão de estimativas dos requisitos, não é melhor estimar em horas diretamente? Ou em dias? Porque estimar relativamente? Como os alunos poderão ver isto sendo tratado dentro do mini-curso?
Essa é uma pergunta que sempre gera muita discussão... Uns dizem que o ser humano tem mais facilidade para comparar duas coisas entre si (abordagem relativa) do que estimar algo diretamente em sua unidade de medida (abordagem absoluta). Os defensores da abordagem relativa apreciam técnicas como Planning Poker para diminuir a variabilidade das estimativas e amenizar a influência de alguns membros da equipe sobre outros. Em contrapartida, acredito que a maioria das pessoas possuem o paradigma do tempo tão forte em suas mentes que não concebem dimensionar um problema sem pensar numa escala de tempo, tornando completamente sem sentido uma abordagem de Story Points, por exemplo. Tentando sair do paragima do tempo, a fim de compreender e também aceitar o pensamento relativo baseado em medidas adimensionais, criei uma técnica que mescla as duas abordagens. Ela inicia com uma estimativa grosseira baseada em escala de tempo (aceitando a natureza das mentes não treinadas para o pensamento relativo) e migra para a comparação de problemas utilizando um conceito da indústria de classes ABC. Para que isso funcione, a técnica deve ser utilizada durante a realização de workshops de requisitos, prática extremamente valiosa pouco utilizada pela grande maioria das empresas. Durante o curso, apresentarei as duas abordagens tradicionais e a versão integrada de ambas.
3) Você tem uma formação muito ligada a programação neuro-linguística. Será tratada alguma coisa sobre isto no treinamento? E sobre ISO? Algum assunto estará relacionado?
Costumo apresentar as técnicas que aprendi durante minha formação e estudos sobre PNL no Curso de Capacitação em Engenharia de Requisitos, um treinamento mais aprofundado com pouco mais de 40h de duração. Mesmo, apesar de ter dedicado duas aulas ao tema (6 a 8 horas), relacionando diretamente as práticas de comunicação com o aumento da produtividade em captação e análise de requisitos pela exploração das linguagens verbal e não-verbal, é muito difícil transmitir tudo aquilo que aprendemos em centenas de horas de treinamento. Pretendo fazer referência ao assunto e mostrar alguns exemplos para deixar claro como a PNL é um assunto sério e valioso para qualquer profissional que trabalhe com requisitos de software. Quanto aos temas ISO, PMBoK, CMMI, etc., abordo os mesmos somente na formação completa, deixando de fora estes assuntos no mini-curso.
4) Para fazer o levantamento de User Stories. É uma tarefa do analista de sistemas e neste ponto o time fica aguardando o fim do levantamento de requisitos para poder estimar?
Sobre este ponto, posso vir a contrariar o pensamento de alguns agilistas, mas vamos lá... Alguns autores defendem que o Cliente ou Product Owner deve escrever suas próprias histórias a fim de se comprometer com aquilo que está solicitando e ter uma noção clara do esforço necessário para o desenvolvimento de cada demanda (estimado pela equipe). No entanto, tenho observado que até mesmo analistas de negócio e de sistemas, treinados na arte da captação e análise de requisitos, tem dificuldade de se expressar corretamente na especificação de requisitos funcionais, motivo pelo qual faço sempre a mesma pergunta: o que podemos esperar de nossos usuários se nossos analistas são demonstram fragilidade na captação, análise e especificação dos requisitos? Para mim, o cenário ideal para tratar dos requisitos de software deve ser dividido em duas partes: uma captação e análise em nível de negócios e uma captação e análise em nível técnico. Digo isso pois tenho observado que os melhores resultados de captação e análise de requisitos de software tem sido obtidos de entrevistas feitas sob a responsabilidade de um analista de negócios, treinado em técnicas de comunicação e percepção humana, identificação de valor para o negócio, controle de reuniões, etc. A única questão básica neste ponto é que ele não tem todo o tempo do mundo para fazer isso e deve estar sempre com a mente sintonizada nos desperdícios da espera e superprodução. Portanto, ele deverá fazer essa atividade em pequenas frações de até 2h e transferir seus resultados para a equipe técnica a fim de identificar riscos na complexidade e capacidade de realização de cada requisito (os workshops de requisitos). Deve ficar claro que nunca o cliente e usuários-chave devem se afastar da equipe de desenvolvimento durante esta fase de captação e análise de requisitos, pois a falta dos mesmos pode dar margem ao fortalecimento de crenças sem fundamento em membros da equipe, levando à especificação de recursos desnecessários para o sistema (o contrário também é verdadeiro - usuários pedindo coisas sem sentido). Entendam essa estratégia da seguinte forma: como muita informação é transmitida pela comunicação não-verbal do solicitante, podemos deixar passar diversas deleções, distorções e generalizações (maiores riscos) com muita gente falando ao mesmo tempo ou pressionando o cliente ou usuários com diversas perguntas de diferentes níveis de abstração. O analista de negócios pode atuar de forma efetiva como um primeiro filtro de eliminação das demandas de sistema não aderentes ou não justificadas para o negócio. Com isso, ele pode perfeitamente, em conjunto do cliente, elaborar esboços de User Stories, sem entrar à fundo nos critérios de aceitação e, muito menos, na definição de tamanho ou complexidade (tarefa de toda a equipe de desenvolvimento).
Por fim, gostaria de deixar o convite para que Analistas de Sistemas e de Negócios, Gerentes de Projeto e Scrum Masters, participem deste curso pois muitas das coisas que serão tratadas em sua programação, não são facilmente encontradas na literatura convencional do tema. Vou iniciar com a percepção do projeto como um todo, entendendo sua verdadeira natureza associada ao processo de negócio e seus desperdícios, resultando numa definição objetiva do escopo do projeto. Passarei pela definição do escopo detalhado utilizando User Stories, com estimativas de tamanho baseadas em Story Points, até chegar no planejamento de recursos e cronograma baseados na capacidade produtiva da equipe de desenvolvimento. Lembrem-se que as estatísticas internacionais concluíram que mais de 64% das funcionalidades de nossos produtos de software quase nunca são utilizadas e que mais de 50% dos problemas encontrados nos sistemas são decorrentes da má compreensão dos requisitos. Se você quer melhorar o seu processo de desenvolvimento, comece melhorando a qualidade de seus pedidos!
Você pode fazer a inscrição neste treinamento e encontrar mais informações a respeito no site do evento.
Você pode fazer a inscrição neste treinamento e encontrar mais informações a respeito no site do evento.
Aqui vão as perguntas:
1) O título do mini-curso é Requisitos de Software, Uma Abordagem Ágil. Diversos sites de crítica às Metodologias Ágeis comentam, por exemplo, que XP não trata requisitos. Só que quando se trabalha com XP, construímos User Stories e definimos Testes de Aceitação. O que são estes caras?
Resumidamente, as User Stories representam os requisitos funcionais de um sistema em um alto nível de abstração, sendo elaboradas com um modelo bem próximo da linguagem coloquial. Tipicamente, ela possui em sua estrutura elementos como "Quem" irá utilizar o recurso, "O que" se pretende fazer com o mesmo, "Por que" este recurso de sistema é necessário, "Como" saberemos que fizemos o trabalho de forma correta (Critérios de Aceitação) e "Quanto" pesa o problema em nossa bagagem... Para quem se deu conta, só faltam o "Quando" e "Onde" do 5W2H, que, ao meu ver, são contemplados durante o planejamento de releases e iterações bem como com a adição de comentários técnicos durante o planejamento detalhado das mesmas (durante sua iteração ou na iteração anterior). Muita gente diz que a User Story serve como lembrança do que deve ser feito, não devendo ser encarada de uma forma burocrática. No entanto, as User Stories possuem uma estrutura adequada para tornar o planejamento e controle de projeto mais objetivos, baseados em números mais realistas. Além disso, tenho observado que sua estrutura permite uma rápida captação de requisitos funcionais, além de ser suficiente para passar em auditorias baseadas em COBIT, por exemplo. Dedicarei um bom tempo explorando essa estrutura durante o curso, mostrando para os alunos como podemos aprimorar a escrita das User Stories como base num modelo linguístico de análise de problemas. Quanto àqueles que falam mal deste tipo de abordagem, é interessante ver como os mesmos se tornam cada vez menos competitivos no mercado de trabalho... Mas isso é um direito que eles tem e que não devemos brigar contra!
2) Na questão de estimativas dos requisitos, não é melhor estimar em horas diretamente? Ou em dias? Porque estimar relativamente? Como os alunos poderão ver isto sendo tratado dentro do mini-curso?
Essa é uma pergunta que sempre gera muita discussão... Uns dizem que o ser humano tem mais facilidade para comparar duas coisas entre si (abordagem relativa) do que estimar algo diretamente em sua unidade de medida (abordagem absoluta). Os defensores da abordagem relativa apreciam técnicas como Planning Poker para diminuir a variabilidade das estimativas e amenizar a influência de alguns membros da equipe sobre outros. Em contrapartida, acredito que a maioria das pessoas possuem o paradigma do tempo tão forte em suas mentes que não concebem dimensionar um problema sem pensar numa escala de tempo, tornando completamente sem sentido uma abordagem de Story Points, por exemplo. Tentando sair do paragima do tempo, a fim de compreender e também aceitar o pensamento relativo baseado em medidas adimensionais, criei uma técnica que mescla as duas abordagens. Ela inicia com uma estimativa grosseira baseada em escala de tempo (aceitando a natureza das mentes não treinadas para o pensamento relativo) e migra para a comparação de problemas utilizando um conceito da indústria de classes ABC. Para que isso funcione, a técnica deve ser utilizada durante a realização de workshops de requisitos, prática extremamente valiosa pouco utilizada pela grande maioria das empresas. Durante o curso, apresentarei as duas abordagens tradicionais e a versão integrada de ambas.
3) Você tem uma formação muito ligada a programação neuro-linguística. Será tratada alguma coisa sobre isto no treinamento? E sobre ISO? Algum assunto estará relacionado?
Costumo apresentar as técnicas que aprendi durante minha formação e estudos sobre PNL no Curso de Capacitação em Engenharia de Requisitos, um treinamento mais aprofundado com pouco mais de 40h de duração. Mesmo, apesar de ter dedicado duas aulas ao tema (6 a 8 horas), relacionando diretamente as práticas de comunicação com o aumento da produtividade em captação e análise de requisitos pela exploração das linguagens verbal e não-verbal, é muito difícil transmitir tudo aquilo que aprendemos em centenas de horas de treinamento. Pretendo fazer referência ao assunto e mostrar alguns exemplos para deixar claro como a PNL é um assunto sério e valioso para qualquer profissional que trabalhe com requisitos de software. Quanto aos temas ISO, PMBoK, CMMI, etc., abordo os mesmos somente na formação completa, deixando de fora estes assuntos no mini-curso.
4) Para fazer o levantamento de User Stories. É uma tarefa do analista de sistemas e neste ponto o time fica aguardando o fim do levantamento de requisitos para poder estimar?
Sobre este ponto, posso vir a contrariar o pensamento de alguns agilistas, mas vamos lá... Alguns autores defendem que o Cliente ou Product Owner deve escrever suas próprias histórias a fim de se comprometer com aquilo que está solicitando e ter uma noção clara do esforço necessário para o desenvolvimento de cada demanda (estimado pela equipe). No entanto, tenho observado que até mesmo analistas de negócio e de sistemas, treinados na arte da captação e análise de requisitos, tem dificuldade de se expressar corretamente na especificação de requisitos funcionais, motivo pelo qual faço sempre a mesma pergunta: o que podemos esperar de nossos usuários se nossos analistas são demonstram fragilidade na captação, análise e especificação dos requisitos? Para mim, o cenário ideal para tratar dos requisitos de software deve ser dividido em duas partes: uma captação e análise em nível de negócios e uma captação e análise em nível técnico. Digo isso pois tenho observado que os melhores resultados de captação e análise de requisitos de software tem sido obtidos de entrevistas feitas sob a responsabilidade de um analista de negócios, treinado em técnicas de comunicação e percepção humana, identificação de valor para o negócio, controle de reuniões, etc. A única questão básica neste ponto é que ele não tem todo o tempo do mundo para fazer isso e deve estar sempre com a mente sintonizada nos desperdícios da espera e superprodução. Portanto, ele deverá fazer essa atividade em pequenas frações de até 2h e transferir seus resultados para a equipe técnica a fim de identificar riscos na complexidade e capacidade de realização de cada requisito (os workshops de requisitos). Deve ficar claro que nunca o cliente e usuários-chave devem se afastar da equipe de desenvolvimento durante esta fase de captação e análise de requisitos, pois a falta dos mesmos pode dar margem ao fortalecimento de crenças sem fundamento em membros da equipe, levando à especificação de recursos desnecessários para o sistema (o contrário também é verdadeiro - usuários pedindo coisas sem sentido). Entendam essa estratégia da seguinte forma: como muita informação é transmitida pela comunicação não-verbal do solicitante, podemos deixar passar diversas deleções, distorções e generalizações (maiores riscos) com muita gente falando ao mesmo tempo ou pressionando o cliente ou usuários com diversas perguntas de diferentes níveis de abstração. O analista de negócios pode atuar de forma efetiva como um primeiro filtro de eliminação das demandas de sistema não aderentes ou não justificadas para o negócio. Com isso, ele pode perfeitamente, em conjunto do cliente, elaborar esboços de User Stories, sem entrar à fundo nos critérios de aceitação e, muito menos, na definição de tamanho ou complexidade (tarefa de toda a equipe de desenvolvimento).
Por fim, gostaria de deixar o convite para que Analistas de Sistemas e de Negócios, Gerentes de Projeto e Scrum Masters, participem deste curso pois muitas das coisas que serão tratadas em sua programação, não são facilmente encontradas na literatura convencional do tema. Vou iniciar com a percepção do projeto como um todo, entendendo sua verdadeira natureza associada ao processo de negócio e seus desperdícios, resultando numa definição objetiva do escopo do projeto. Passarei pela definição do escopo detalhado utilizando User Stories, com estimativas de tamanho baseadas em Story Points, até chegar no planejamento de recursos e cronograma baseados na capacidade produtiva da equipe de desenvolvimento. Lembrem-se que as estatísticas internacionais concluíram que mais de 64% das funcionalidades de nossos produtos de software quase nunca são utilizadas e que mais de 50% dos problemas encontrados nos sistemas são decorrentes da má compreensão dos requisitos. Se você quer melhorar o seu processo de desenvolvimento, comece melhorando a qualidade de seus pedidos!
Você pode fazer a inscrição neste treinamento e encontrar mais informações a respeito no site do evento.
quarta-feira, 8 de abril de 2009
TargetTrust patrocina o Porto Alegre Agile Weekend 2009
A T@rgetTrust, empresa de TI especializada em Treinamento e Tecnologia é uma das patrocinadoras do Porto Alegre Agile Weekend 2009!
Aproveite as inscrições do evento! Preços especiais para associados SUCESU-RS e estudantes!
Inscrições para Grupos Disponível no Agile Weekend 2009!
Muitas pessoas pediram e a organização do Porto Alegre Agile Weekend 2009 atendeu!
A partir de hoje, você consegue se inscrever no evento com valores diferenciados para grupos!
Os descontos também serão aplicáveis para os mini-cursos! Ainda estamos com vagas no curso de Requisitos de Software e também no curso de Teoria das Restrições! Aproveite!!
A partir de hoje, você consegue se inscrever no evento com valores diferenciados para grupos!
Os descontos também serão aplicáveis para os mini-cursos! Ainda estamos com vagas no curso de Requisitos de Software e também no curso de Teoria das Restrições! Aproveite!!
terça-feira, 7 de abril de 2009
Conheça os palestrantes do Porto Alegre Agile Weekend 2009
A programação do evento está disponível para sua consulta! Aproveitando, já temos uma página com informações sobre os palestrantes. Acompanhe as novidades do evento!
As inscrições seguem abertas!
As inscrições seguem abertas!
sábado, 4 de abril de 2009
Parabéns! 5 anos de GUMA-RS!!
Há cinco anos (4 de abril de 2004), foi o dia em que assisti uma palestra do Klaus Wuestefeld e Guilherme Lacerda em um evento do RSJUG (na época eu era coordenador do RSJUG) e 4 de abril de 2004 foi o dia em que Guilherme Lacerda e eu resolvemos criar um Grupo de Usuários de Metodologias Ágeis no RS. O Grupo iniciou com o nome de XP-RS, tratando de eXtreme Programming que era a Metodologia que eu e o Guilherme estávamos focando na época. Dia 5 de abril de 2004 foi quando criamos a lista de discussão do grupo.
Ao longo do tempo conhecemos algumas pessoas como por exemplo Luiz Parzianello, que trouxe novos conceitos e fez com que por exemplo eu iniciasse meus estudos de Toyota de forma efetiva.
A primeira reunião ocorreu em 14 de agosto de 2004. Olha a foto aí:
Esquerda Superior: Daniel Wildt, Sandro Mossmann, Daniel Pohren, Franco dos Santos, Luiz Parzianello; Esquerda Inferior: Maykel Tres, Celso Lorenzetti, Dax Reis, Ilo Paiz
Neste processo realizamos o eXtreme Day em dezembro de 2004 e durante 2004 mesmo outros dois eventos. E aí a coisa engrenou, depois começamos a aparecer em eventos tipo FISL, eventos locais, semanas acadêmicas, sempre trazendo a comunidade para discussão.
Um tempo depois fechamos uma parceria com a SUCESU-RS e criamos o GUMA-RS, o Grupo de Usuários de Metodologias Ágeis do RS. Nesta época, nós já estávamos olhando não apenas para XP, mas também para Scrum, Lean Development, FDD, Crystal, MSF for Agile, Getting Real e por aí vai! Então o grupo não estava mais olhando apenas para uma metodologia mas olhando para Metodologias Ágeis em geral e discutindo isto e praticando em projetos e equipes diversas.
E cinco anos depois, estamos ainda aqui, divulgando e mostrando Metodologias Ágeis para a indústria de software do RS e dos outros estados do Brasil.
A comemoração? Essa vem no final do mês!! Venha participar do Porto Alegre Agile Weekend 2009!
Participe da lista de discussão!!
Ao longo do tempo conhecemos algumas pessoas como por exemplo Luiz Parzianello, que trouxe novos conceitos e fez com que por exemplo eu iniciasse meus estudos de Toyota de forma efetiva.
A primeira reunião ocorreu em 14 de agosto de 2004. Olha a foto aí:
Esquerda Superior: Daniel Wildt, Sandro Mossmann, Daniel Pohren, Franco dos Santos, Luiz Parzianello; Esquerda Inferior: Maykel Tres, Celso Lorenzetti, Dax Reis, Ilo Paiz
Neste processo realizamos o eXtreme Day em dezembro de 2004 e durante 2004 mesmo outros dois eventos. E aí a coisa engrenou, depois começamos a aparecer em eventos tipo FISL, eventos locais, semanas acadêmicas, sempre trazendo a comunidade para discussão.
Um tempo depois fechamos uma parceria com a SUCESU-RS e criamos o GUMA-RS, o Grupo de Usuários de Metodologias Ágeis do RS. Nesta época, nós já estávamos olhando não apenas para XP, mas também para Scrum, Lean Development, FDD, Crystal, MSF for Agile, Getting Real e por aí vai! Então o grupo não estava mais olhando apenas para uma metodologia mas olhando para Metodologias Ágeis em geral e discutindo isto e praticando em projetos e equipes diversas.
E cinco anos depois, estamos ainda aqui, divulgando e mostrando Metodologias Ágeis para a indústria de software do RS e dos outros estados do Brasil.
A comemoração? Essa vem no final do mês!! Venha participar do Porto Alegre Agile Weekend 2009!
Participe da lista de discussão!!
sexta-feira, 3 de abril de 2009
Último dia para fazer inscrições no Porto Alegre Agile Weekend 2009 com desconto!
Aproveite! Faça a sua inscrição e aproveite os preços com desconto! A partir do dia 4 os preços sofrem um ajuste!
Venha comemorar os 5 anos do GUMA-RS no Porto Alegre Agile Weekend 2009!
Venha comemorar os 5 anos do GUMA-RS no Porto Alegre Agile Weekend 2009!
quinta-feira, 2 de abril de 2009
Hoje a aula era de eXtreme Programming
Hoje na faculdade ensinei práticas e a base do eXtreme Programming para meus alunos da disciplina de Metodologias Ágeis. Estamos na quinta aula e já discutimos cultura, mudança cultural, toyota, lean, scrum e agora chegou a hora do XP.
Rodamos até uma eXtreme Hour e foi como sempre muito esclarecedora para uma série de características que um time busca quando trabalha com Metodologias Ágeis!
Semana que vem iniciamos o pré-game, vamos desenvolver um produto. Aguardem novidades deste projeto.
Falando da aula novamente...
Temos grandes nomes falando em eXtreme Programming no Brasil, e para mim as referências são claras: Klaus Wuestefeld, Vinícius Teles e Guilherme Lacerda. Estes foram os primeiros caras que ouvi e falei ao vivo, e seguem sendo para mim referências.
O Vinícius agora está em outra, mas foi durante muito tempo foi referência em consultoria, treinamento e divulgação do Extreme Programming no Brasil.
Na época do último FISL em 2008, tive a oportunidade de organizar um evento do GUMA-RS e aproveitar a presença do Vinícius Teles em Porto Alegre, e foi muito legal ver o Vinícius palestrando em um evento do grupo. Enfim, Vinícius fez uma palestra muito legal, sincera, transparente, e direta.
A oportunidade anterior foi em 2004 no Extreme Day que realizamos na UFRGS, que contou com a presença do Klaus também e nomes da nossa comunidade Gaúcha ligada a Metodologias Ágeis.
E se você tem interesse em ver esta apresentação que o Vinícius realizou em 2008 em um evento do GUMA-RS, ele repetiu a dose no The Developers Conference:
Quer ver mais sobre eXtreme Programming? Participe do Porto Alegre Agile Weekend 2009!
Rodamos até uma eXtreme Hour e foi como sempre muito esclarecedora para uma série de características que um time busca quando trabalha com Metodologias Ágeis!
Semana que vem iniciamos o pré-game, vamos desenvolver um produto. Aguardem novidades deste projeto.
Falando da aula novamente...
Temos grandes nomes falando em eXtreme Programming no Brasil, e para mim as referências são claras: Klaus Wuestefeld, Vinícius Teles e Guilherme Lacerda. Estes foram os primeiros caras que ouvi e falei ao vivo, e seguem sendo para mim referências.
O Vinícius agora está em outra, mas foi durante muito tempo foi referência em consultoria, treinamento e divulgação do Extreme Programming no Brasil.
Na época do último FISL em 2008, tive a oportunidade de organizar um evento do GUMA-RS e aproveitar a presença do Vinícius Teles em Porto Alegre, e foi muito legal ver o Vinícius palestrando em um evento do grupo. Enfim, Vinícius fez uma palestra muito legal, sincera, transparente, e direta.
A oportunidade anterior foi em 2004 no Extreme Day que realizamos na UFRGS, que contou com a presença do Klaus também e nomes da nossa comunidade Gaúcha ligada a Metodologias Ágeis.
E se você tem interesse em ver esta apresentação que o Vinícius realizou em 2008 em um evento do GUMA-RS, ele repetiu a dose no The Developers Conference:
Quer ver mais sobre eXtreme Programming? Participe do Porto Alegre Agile Weekend 2009!
quarta-feira, 1 de abril de 2009
Aproveitando o dia... algumas coisas que se acha na internet. Parece verdade, mas não é...
Hoje é primeiro de abril e vale lembrar de algumas histórias e posts famosos relacionados a esta data e o assunto Metodologias Ágeis.
Um deles pode ser a super versão do Mingle. Conheça o Mingle Proj-o-matic.
Fora isto, existe uma conferência famosa, a Waterfall 2006, que revolucionou o mercado.
Você lembra de alguma outra?
Uma não relacionada a 1 de abril, mas que poderia estar, é sobre o WAgile, uma dica que recebi de um amigo.
Existem outras várias histórias que poderiam estar classificadas aqui como primeiro de abril, mas que infelizmente são reais. Loucuras que verificamos em times tentando usar Metodologias Ágeis sem acompanhamento. Estas para ouvir vocês vão precisar estar no Porto Alegre Agile Weekend 2009 e assistir a palestra de abertura e também a discussão no "Eu Odeio Métodos Ágeis".
Um deles pode ser a super versão do Mingle. Conheça o Mingle Proj-o-matic.
Fora isto, existe uma conferência famosa, a Waterfall 2006, que revolucionou o mercado.
Você lembra de alguma outra?
Uma não relacionada a 1 de abril, mas que poderia estar, é sobre o WAgile, uma dica que recebi de um amigo.
Existem outras várias histórias que poderiam estar classificadas aqui como primeiro de abril, mas que infelizmente são reais. Loucuras que verificamos em times tentando usar Metodologias Ágeis sem acompanhamento. Estas para ouvir vocês vão precisar estar no Porto Alegre Agile Weekend 2009 e assistir a palestra de abertura e também a discussão no "Eu Odeio Métodos Ágeis".
Assinar:
Postagens (Atom)