Conseguimos lotar o auditório com 3 turmas, somando em torno de 80 pessoas.
Gravei a palestra na íntegra e estou disponibilizando aqui, juntamente com os slides, já que no vídeo está muito difícil de ler. Esperamos que o pessoal tenha gostado e comentários são sempre muito bem-vindos.

Para trazer estes conceitos para a realidade de desenvolvimento de software, leia esse post bem completo do blog oficial da Rational.

Aqui está o link sobre a matéria da VW na Folha que o André comentou durante a palestra.

Fui convidado pelo programa Smart Professional da IBM para ministrar um mini-curso de 3h de duração na XIII Semana de Integrada do CEATEC da PUC-Campinas.

O mini-curso tem o título “Automatizando processos Ágeis” e visa dar um direcionamento de estudo para a certificação Test 053: Rational Team Concert V3. 

Como ponto de partida, comece lendo este post do blog da Rational que expõe o RTC como alternativa viável, completa e gratuita (máximo de 10 usuários) para o desenvolvimento ágil de software.

Para tutoriais específicos sobre cada funcionalidade, entre no link abaixo que é a biblioteca completa de referências da página oficial do RTC no jazz.net:
https://jazz.net/projects/rational-team-concert/learnmore/

Alguns vídeos relacionados:

• Assista a apresentação do Smart Professional e conheça como funciona o Programa!
• Conheça a solução Rational Team Concert
• Saga de Ted,  o desenvolvedor: Episódio 1, Episódio 2, Episódio 3, Episódio 4 e Episódio 5

Gostei muito de apresentar e principalmente das perguntas e comentários sobre o meu tema do mestrado. Tenho certeza de que grandes dicas e melhorias surgirão e ajudarão muito na qualidade do meu trabalho.

Veja os slides usados aqui.

Para mais detalhes, veja artigo completo aprovado no WBMA 2011 aqui.

Espero colher mais feedbacks na mesa redonda no final do dia!

Imagem adaptada e traduzida do site http://www.agileforall.com/intro-to-agile/

Resumindo as características dos projetos que preciso:

1. Ter usado Scrum
2. Arquitetura/plataforma Web preferencialmente em Java
3. Requisitos na forma de User Stories estimadas em Story Points
4. Release 1 finalizada, no mínimo

O que eu vou precisar:

Quais tarefas serão feitas?

1. Eu farei uma análise criteriosa nas User Stories implementadas e no documento de arquitetura em relação ao comportamento excepcional
2. Novas User Stories, Testes de Aceitação e tarefas podem surgir dessa análise com o objetivo de melhorar a confiabilidade do sistema.

Resumindo, preciso fazer esse estudo de caso em pelo menos 2 projetos e estou um tanto travado para conseguir esse projetos. Portanto se você puder me ajudar entre em contato, ou comente aqui, que eu ficarei muito grato!

Se quiser saber mais detalhes sobre a dissertação, leia um artigo de 9 páginas aqui.

Mesmo já tendo apresentado algumas vezes, o nervosismo sempre acontece, principalmente pela presença de vários professores e, é claro, a expectativa quanto às críticas recebidas. Foi um ótimo teste e os comentários que recebi foram muito construtivos, principalmente os relativos à formalidade e metodologia que usarei para usar o Estudo de Caso Qualitativo. Veja aqui os slides utilizados.

Agora cheguei na fase crítica do processo: selecionar e realizar o estudo de caso. Preciso de um projeto que tenha usado Scrum, que tenha os requisitos em User Stories (e estimados em Story Points) e que tenha pelo menos a arquitetura em alto-nível documentada. Vou fazer uma análise da arquitetura e das user stories e depois entrevistar alguns envolvidos sobre as modificações sugeridas. Se você tiver algum projeto para me ajudar, por favor entre em contato. Não preciso de detalhes como o nome do cliente e o backlog completo, portanto não haverá impactos dados confidenciais de seu cliente.

Enquanto isso estou escrevendo minha dissertação e aguardando ansiosamente a avaliação do meu artigo para o AgileBrazil que deverá sair ainda hoje! Veja aqui o pdf do artigo submetido.

Ao invés de twittá-las individulamente, resolvi postar aqui mesmo.

The corporate world is a chaotic world, and the number of things that can distract a team and knock it off course are almost innumerable.

The primary purpose of Scrum is to help teams to focus on their objectives and to help them avoid getting thrown off track by other less important concerns.

Common sense, simple practices, and paying attention yield tremendous benefits.

In our industry, we tend to rely on the complicated, the aggregated, the sophisticated, the hard-to-do and intellectually challenging. Sometimes we have to make an effort to keep things simple.

The simplest solution is usually the best solution

Scrum is in essence no more than a collection of reasonable practices that are woven together with a few rules, a couple of expressions, and a good dose of common sense.

Checking “Project Dashboards,” reading status reports, and attending weekly review meetings are all mere substitutes for real involvement in project.

The best way to begin implementing Scrum is to establish daily Scrum status meetings.

Scrum makes clear to all team members what the project’s goals are and what their individual goals within the context of the project are. Another benefit of transparency is the degree to which it reduces the amount of time wasted on politics.

Scientists and engineers are by nature solitary creatures: though willing to be social, they would prefer to stick to themselves.

Scrum humanizes product development by introducing regular communication of successes and failures and by helping teams of people commit to shared goals.

Mas hoje, lendo sobre Agile Modeling, no livro Agile Modeling: Effective Practices de Scott Ambler, logo na introdução, páginas 4 e 5, me saltou aos olhos algo que já pensava e sentia e que caiu como uma luva sobre o meu atual momento de vida (casado, com quase 30 anos) e da carreira (5 anos de IBM completados na semana). Então resolvi traduzí-lo (adaptando um pouquinho) e compartilha-lo aqui, servindo também como uma forma de reativar (maaaaais uma vez) esse blog. Aí vai…

Quando os desenvolvedores de software são jovens, adolescentes ou na faixa dos vinte anos, eles geralmente se concentram em aprender e trabalhar com a tecnologia. Eles descrevem a si mesmos como programadores Perl, especialistas em Linux, programadores Enterprise JavaBeans (EJB)  ou desenvolvedores .NET. Para eles, a tecnologia é a coisa mais importante. Como a tecnologia está em constante mutação, os profissionais mais jovens têm uma tendência para apenas aprender um pouco de tecnologia, aplicá-la em um ou dois projetos, e depois começar tudo de novo aprender uma nova tecnologia ou a mais recente encarnação do que eles trabalharam anteriormente. O problema é que eles continuam aprendendo apenas sabores diferentes permanecendo sempre no mesmo nível básico todas as vezes.

Felizmente, muitos ficam conscientes disso depois de várias tecnologias – uma vez que você tenha escrito um código para controle de transações em COBOL, Java e C #, você começa a perceber que os fundamentos não mudam. O mesmo é verdadeiro para acessar banco de dados em vários ambientes, design de interface do usuário, e assim por diante. Em pouco tempo, os desenvolvedores começam a perceber que muitos dos fundamentos, que podem ou não terem sidos ensinados na escola, permanecem os mesmos, independentemente da tecnologia. Essa percepção geralmente vem quando os desenvolvedores atingem seus vinte e tantos anos ou trinta e poucos anos, normalmente é o período que as pessoas começam a se estabelecer, casar e comprar uma casa. Esta é fortuito porque estas novas demandas significam que os desenvolvedores já não conseguem investir grandes quantidades de tempo para aprender novas tecnologias, em vez disso, eles querem passar esse tempo com suas famílias. De repente, funções de maior responsabilidade como líder de projeto, gerente de projeto, e modelador se tornar atraente para eles, porque essas funções não exigem esforço constante e intensivo necessário para aprender novas tecnologias. Então, no momento em que os programadores começam a realmente aprender seu ofícioinicia-se um processo de transição para outros papéis além do de desenvolvedor. Felizmente, os novos “jovens punks” chegam e o ciclo se repete. O resultado final é que a maioria das pessoas ativas no desenvolvimento de software geralmente não são os mais qualificados para fazê-lo, e eles não sabem fazem a menos idéia.

Mais informações no http://www.agilemodeling.com/

Gimme fuel, gimme fire, gimme that which I desire, oh

Pra começar, o grande acontecimento no pré-2010 foi o grande show do Mettalica em 31/1 no Morumbi! Depois de ter ido no show de 98, esse realmente foi muito melhor! Espero que não tenha sido o último!  Fica um gostinho da música Cyanide do CD novo pra vocês!

Seguem alguns links relacionados…

• http://pt.wikipedia.org/wiki/Web_2.0
• (Inglês) http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html
• http://pt.wikipedia.org/wiki/AJAX_%28programa%C3%A7%C3%A3o%29
• http://pt.wikipedia.org/wiki/RSS
• http://pt.wikipedia.org/wiki/Rest
• (Inglês) http://www.projectzero.org
• http://www-01.ibm.com/software/br/lotus/products/connections/

Seguem alguns vídeos que serviram de inspiração…

Posso garantir que tem funcionado muito bem e de uma maneira bem simplificada eu diria que os maiores benefícios são descentralizar a comunicação por email, dar mais transparência, promover o compartilhamento de conhecimento (knowledge-sharing) e construir um sentimento colaborativo de comunidade que vai além do pessoal do projeto.

Com certeza absoluta o sucesso dessa iniciativa pode ser amplamente atribuído à ferramenta usada, no caso o Lotus Connections.

Veja o vídeo abaixo para entender suas principais funcionalidades.

Mas ferramenta não funciona se as pessoas não entenderem o seu verdadeiro valor e foi quando apareceu uma séria de animações com exemplos reais de como uma ferramentas de colaboração efetivamente.
Eis o primeiro vídeo da série que nos mostra como diminuir as trocas de email usando o compartilhamento de arquivos.

Espero que gostem e em breve coloco os outros vídeos aqui!