Débito Técnico

Muitos de vocês já devem ter dado uma passeada no site da Aspercom e visto o novo Treinamento ScrumMaster Oficial na nossa home ou no nosso calendário. É isso mesmo! A Aspercom em parceria com a Goldentec está oferecendo o treinamento e certificação ScrumMaster em todo o Brasil na língua portuguesa.

Todos que me conhecem sabem que sempre fui contra a certificação da Scrum Alliance. Sempre critiquei as motivações das pessoas em buscar o título CSM e o fato de não ter uma avaliação final. Sempre critiquei bastante e hoje vejo que o motivo de grande parte das minhas reclamações não era culpa da Scrum Alliance e sim da postura de pessoas sobre o CSM aqui no país. Com razão ou não, estou só dando explicações e me retratando sobre a Scrum Alliance.

No mês de janeiro conheci o Michel Goldenberg, o novo CST brasileiro e um nome muito influente dentro da própria Scrum Alliance no mundo. Ele quis me conhecer e durante janeiro conversamos muito sobre o mercado Agile no Brasil e sobre como a Scrum Alliance é na verdade com as mudanças que tem acontecido na sua organização e etc…

O Michel se mostrou um CST diferente. Antes de mais nada, ele é um “Techie Guy” com muito trabalho na comunidade Scrum no mundo. Ele trabalhou como Arquiteto de Software em grandes empresas como o ING e a Bombardier e tem experiência em implementação de projetos complexos aqui no Brasil e no exterior. Ele conhece muito bem XP, e isso me chamou a atenção, pois na Aspercom defendemos o uso do Scrum recheado de boas práticas engenharia.

Por fim, o Michel me convenceu que se quero mudar o sistema e a comunidade Scrum, a melhor maneira é fazer parte disso. No ano de 2010 firmamos uma parceria para ministrar alguns treinamentos juntos. Sim, eu também estarei presente nas classes CSM da Aspercom com o Michel. Com isso, queremos ter um treinamento CSM alinhado às necessidades que mais vejo no mercado brasileiro. Nossos diferenciais estão aqui:

1. Dois instrutores experientes em implantações Agile
2. O conhecimento será prático, como todos nossos treinamentos
3. Introdução a boas práticas ágeis de engenharia
4. O foco em conhecimento e não certificação

Com essa parceria queremos principalmente melhorar a qualidade da comunidade Scrum no Brasil, que a meu ver, vai muito mal.

Outro ponto: Sabemos que um treinamento CSM é caro, principalmente no nosso caso que temos dois instrutores. Independente disso, buscaremos ao máximo melhorar o preço do treinamento: Oferecemos desconto Early Bird com preço abaixo do mercado e um bom desconto para ex-alunos Aspercom. Não só isso, vamos devolver para a comunidade parte dos nossos lucros na forma de eventos gratuitos nas cidades que visitarmos. Esses eventos serão focados em Agile, Scrum e também um outro assunto muito importante para a comunidade brasileira:Liderança Técnica. Maiores detalhes acompanhe aqui no Débito Técnico. Teremos novidades já para março em São Paulo.

A nossa agenda para as primeiras turmas já estão marcadas no calendário:

São Paulo: Dias 22 e 23 de março
Rio de Janeiro: Dias 5 e 6 de abril
Brasília: Dias 8 e 9 de abril

Sobre o Workshop Scrum

Muitas pessoas e empresas de todo o Brasil já foram treinadas por mim no treinamento Workshop Scrum. Este treinamento vai continuar no nosso catálogo cumprindo a sua função como uma opção sem certificação e mais acessível. Apesar de ter turmas abertas freqüentes em todo Brasil, o Workshop é mais direcionado a empresas médias e pequenas que querem implantar Scrum, e esta estratégia tem dado certo nos nossos clientes.

Nossa visão e missão como empresa é melhorar o desenvolvimento de software no Brasil com transparência e dedicação. Vamos continuar com outros treinamentos, mentorings, consultorias, palestras gratuitas em empresas e participação ativa em eventos. Jamais vamos virar uma empresa que só vende certificações. Se tiverem mais dúvidas ou quiserem comentar fiquem a vontade.

É bastante comum as pessoas reclamarem que a empresa que trabalha não é ágil. Da mesma forma é bastante comum culparem os gerentes, coordenadores, diretores, o cara que cuida dos processos e etc… Algumas pessoas lutam com muito afinco por mudanças e as vezes conseguem adotar uma ou outra prática do Scrum ou até contratam um treinamento. A questão é que na maioria das vezes o que vai impedir o sucesso da adoção Agile na empresa não é o seu gerente, nem seus gerentes de projeto e nem o cara que cuida dos processos: o que impede a adoção Agile na maioria das equipes que tenho contato é a falta de conhecimento de boas práticas de engenharia.

Como já havia citado aqui, design incremental é uma das práticas de engenharia que poucas equipes dominam. Poucas equipes sabem exatamente o que é um incremento. Um dos conceitos do Scrum que é bem pouco comentado e que costumo dar bastante enfoque no meu treinamento é exatamente a definição do pedaço de funcionalidade potencialmente implantável. O próprio Ken Schwaber disse no Gathering que somente 20% das equipes conseguem entregar algo potencialmente implantável ao final da iteração. Inclusive, essa é a motivação dele ter fundado a Scrum.org após sua saída da controversa Scrum Alliance.

Quando dizemos que estamos entregando algo potencialmente implantável isso nos leva a uma visão que poucas equipes Scrum tem: no andar das iterações é o cliente que decide a hora que ele quer ir para a produção, e seu software deve permitir isso. Tudo aquilo que você “incrementou” deve ser capaz de resolver algum problema de negócio sem depender de grandes investimentos em preparação de ambientes ou “Sprints de estabilização”. O que você incrementa além de atender a sua definição de PRONTO deve ser sólido, refatorável, bem arquitetado e durar para sempre. O software criado deve ser um ativo, que coloca dinheiro no bolso de alguém.

Quanto eu estou pareando com alguém ou trabalhando num incremento eu vejo algumas características na realização desse trabalho. Basicamente um incremento é:

- Documentado e especificado (usando BDD, TDD ou outros documentos)
- Analisado (parte do ciclo TDD, refactorings)
- Sólido (incremente com boas práticas OO)
- Coberto por testes (incrementos futuros não quebram o atual)
- Integrado Continuamente (há outros na equipe incrementando)
- Potencialmente Implantável (o cliente decide quando vai pro ar)

A prática dos Baby Steps

Um fato que é bastante interessante é a velocidade dos times ágeis: é um mito achar que times ágeis programam numa correria desatada e que agilistas trabalham num ritmo barulhento, frenético e alucinado. Muitas pessoas que tem contato com uma equipe ágil pela primeira vez pode até estranhar a calma, seriedade e tranquilidade que cerca esses times ágeis. Por incrível que isso possa aparecer, times realmente ágeis “aparentam” ser lentos. É comum ver eles mais pensando do que digitando. Porém, cada passo de bebê que eles dão são passos firmes, determinados, bem pensados e principalmente na direção correta. Numa equipe ágil a cada 2 ou 3 horas vários passos pequenos foram dados e cada incremento agrega valor para o projeto.

Chega ser ridículo quando vou conversar com certos empresários e eles dizem: “- Aqui já somos ágeis… é uma correria do cacete aqui!”

Mentalidade Cascateira do Programador

O maior motivador deste artigo é a minha experiência depois de ter ministrado algumas vezes o nosso novo treinamento Domain-Driven Design. Neste treinamento as atividades práticas são orientadas a testes, e tenho visto que alguns alunos penam para completar os exercícios mesmo quando nós já fornecemos os testes automatizados escritos.

Exemplo: Temos um caso de uso com 4 testes falhando para os alunos implementarem em uma hora. São 4 testes de integração, então, basta fazer cada teste passar em 15 minutos que a solucão está completa. Muitos não conseguem fazer isso, e a maior razão é não conhecer sobre Design Incremental. Eles olham aqueles testes falhando e entram em pânico. Saem cuspindo código sem rodar os testes querendo fazer todos eles passarem ao mesmo tempo. Nos últimos 5 minutos da atividade prática ainda está tudo RED e falham miseravelmente. Simplesmente não lhes parece natural fazer o primeiro teste passar, depois o segundo, depois o terceiro e assim sucessivamente. Eles não pensam em passos de bebê e nem em incrementos. Essa minha experiência é bastante relevante para a questão, e define a mentalidade cascateira:

O cascateiro é aquele desenvolvedor que espera que algo milagroso acontecerá nos últimos instantes do prazo, e tudo aquilo que não funciona passará a funcionar, seja por sorte ou intervenção divina.

Essa definição é essencialmente válida mesmo para quem diz que usa ciclos iterativos. Ciclos iterativos não necessariamente são Ágeis, pois se sua equipe ainda sofre para que tudo que foi implementado funcione ao final da iteração você ainda tem mentalidade cascateira, e precisa melhorar suas práticas de teste e integração contínua.

Você que é desenvolvedor pode fazer uma auto-avaliação prática. Acesse meu Github e baixe o projeto exemplo do treinamento Domain-Driven. Em seguida, acesse a classe CadastrarHospedeTest e tente fazer com que estes testes passem num prazo de uma hora. Pegue como exemplo a classe CadastrarQuartoTest. Depois, responda as perguntas:

1. Você conseguiu implementar em uma hora?
2. Quantas vezes aproximadamente você rodou os testes?
3. Você conseguiu fazer os testes passarem um por um?
4. De 0 a 10, como você avalia a confiabilidade do seu código?

Como eu sempre digo: Colar post-its na parede todo mundo quer, mas escrever testes automatizados ninguém quer.

Em novembro a Aspercom esteve em Francisco Beltrão - Paraná para ministrar os treinamentos de Requisitos e Scrum na Leosoft, empresa ISV com mais de 12 anos de mercado e focada em produtos de software para cooperativas de crédito.

A Leosoft é uma empresa que já utiliza Extreme Programming há algum tempo, tendo sido treinada pelo renomado Vinicius Teles. Ambos os treinamentos foram customizados para focar em práticas que fortaleceram a visão de negócios dos produtos da empresa junto ao mercado, já que cliente presente é um grande desafio para os ISVs. De norte a sul do Brasil é muito interessante ver como empresas com times pequenos e auto-organizados conseguem excelentes resultados em seus produtos e empresas.

Atividades práticas em grupo, muito comuns em treinamentos da Aspercom

Um ambiente informativo compartilhado na vida real

Gostaria de parabenizar a todos da Leosoft pelos excelentes bate-papos e trocas de experiências. Muito sucesso em 2010!

Desde algumas polêmicas que ocorreram no Scrum Gathering neste ano, tenho discutido em diversos fóruns de discussões e eventos sobre o que tem ocorrido com a nossa comunidade de desenvolvimento ágil. Eu temo pelo o que pode ocorrer com o Agile aqui no Brasil. O que matou o RUP pode também matar o Agile.

Quando eu estava no começo da minha carreira, no início dos anos 90, por incrível que possa parecer os métodos eram ágeis. O cliente e os reais usuários eram muito próximos e participavam ativamente do projeto. O ciclo, apesar de não ter formalidades iterativas, era focado em entregas frequentes. Apesar das arquiteturas fracas, a qualidade era boa e a satisfação dos usuários era maior. Trabalhei com Clipper, Visual Basic 3-6, Mumps e outras coisas da época - além de administrar redes Novell 3.12 e Lantastic. Os projetos eram divertidos, focados em resultados e na maioria das vezes o financiador ficava no seu pé. Eu me lembro do Tonhão, o gerente financeiro da Rede America Burger & Pasta, meu primeiro (e único) emprego como programador CLT. O Tonhão todas as sextas batia na minha mesa no CPD e perguntava: “-E aí Japa, tá pronto?”. Todas as sextas, religiosamente às 15:00 o Tonhão cobrava sobre aquele sistema de controle de caixa das lojas que acabou com os disquetes e com muita burocracia, pois usava comunicação via modem.

Nos meados de 1996 recebí uma ligação de um amigo meu do colégio técnico dizendo que as consultorias estavam pagando R$ 22,00 a hora para projetos do Bug do Milênio em COBOL. Bem, para a época esse valor era bastante significativo, topei na hora e lá fui eu ter a experiência de uma empresa grande. Se existe uma coisa que você pode responsabilizar sobre a bagunça que existe no mercado de TI hoje essa coisa é O BUG DO MILÊNIO. Eu estranhei muito trabalhar em consultorias nessa época. Os projetos chegavam e nem tinha uma única reunião com o cliente. Na maioria das vezes tinha um gerente-proxy entre a equipe e os clientes. Os projetos Y2K eram ainda mais peculiares. Teve projetos que o trabalho era passar uma ferramenta de detecção de problemas Y2K, ir até o código indicado pela ferramenta e fazer as alterações, mas sem recompilar e sem qualquer teste. Eu me sentia um digitador. Levei até uma bronca de um coordenador por tentar compilar o projeto para ver se nossas alterações ao menos geravam os binários. Meu coordenador gritou que aquilo não era escopo do projeto. Nesse momento eu ví que qualidade não era uma preocupação central das consultorias.

Passada a fase Y2K, começaram os projetos Internet e de sistemas periféricos de grandes implementações ERP. O problema é que o desenvolvimento de software empírico (que eu apliquei nos meus estágios e lá na Rede America) não atendia às necessidades de projetos outsourcing. Gerentes queriam controles, relatórios e Gantt Charts. A preocupação maior era a mesma dos projetos Y2K - O ESCOPO. Se você estivesse numa consultoria no final dos anos 90, você compreenderia perfeitamente o mindset do SEI com o seu CMM. Os gerentes de consultorias buscavam algo que amarrasse a equipe ao contrato com o cliente. Meio por fora de tudo isso comecei a estudar Orientação a Objetos, OMT, Booch, e mais pra frente, a UML e o RUP. Minha primeira experiência prática com o RUP foi num projeto internacional para a Phillips Medical Systems em 1999.

Esse projeto da Phillips era um sistema orçamentário empresarial que integrava vários departamentos, inclusive a matriz em Rotterdam. Foi desenvolvido em Visual Basic, Orientado a Objetos e banco de dados Oracle. Quando olhei o RUP pela primeira vez gostei de Casos de Uso, Iteratividade e o foco Arquitetural. Neste projeto a equipe variou entre 3 a 5 pessoas. No início estabelecemos uma Visão para definir o problema junto aos usuários, o ciclo iterativo era de 30 dias e tinha perto de 15 casos de uso (que escrevemos de maneira correta). Usamos o famigerado Visual SourceSafe (o supra-sumo da época) e somente uns 6 ou 7 diagramas UML foram mantidos como artefatos (além do MER). O foco sempre era entregar o produto e não preencher artefatos. A gente até tinha alguns testes automatizados, mas a maioria dos testes era manual. Entregamos o projeto após 3 ou 4 iterações e foi um sucesso! A satisfação dos usuários foi além das expectativas. A partir desse projeto, o modo que eu instancio o RUP é assim: Iterativo, Orientado ao Usuário (Casos de Uso) e centrado em Arquitetura.

Quando voltei desse projeto para a consultoria um dos meus gerentes queria saber como foi o processo. Eu comecei a falar que o cliente participou bastante e que as entregas a cada 30 dias foram determinantes para diminuir os riscos. E a pergunta que se seguiu traduz bastante o mindset de um gerente (da época ou de hoje): “- Legal, legal, Rodrigo, mas quais eram os documentos que vocês preenchiam?”. Aí eu falei que usamos a Visão, os Casos de Uso, a UML, o MER… logo em seguida veio a pergunta número 2: “- Você poderia me dar um exemplo de cada um para usar no projeto XPTO?”. Hoje eu vejo que ele estava buscando respostas fáceis. Na época eu poderia ter dado minha cópia do livro sobre Unified Process dos Três Amigos, porém, o que eu fiz foi copiar um disquete com os artefatos. Ainda hoje ainda me culpo por ter feito aquilo, mas eu era ainda um profissional inexperiente, com pouco mais de 5 anos de estrada. Colaborei para a ilusão daquele gerente por respostas fáceis. Me desculpe se você era um dos desenvolvedores do projeto XPTO na virada do ano 2000. Me desculpe se um dia, um gerente chegou para você entregando um disquete dizendo: “- Olha, o preenchimento desses artefatos garantirão o sucesso do projeto.”

Na virada do Milênio, eu ví pessoas e empresas buscando processos como o RUP e outros pela motivacão errada. Eles achavam que a maneira “falar com o usuário - implementar - entregar” era pouco controlada. O pensamento era: “Ninguém assina nada?”. Nessa época os gerentes voluntariamente queriam uma burocratização. Era proibido falar as palavras empírico e pragmático nesta época. Não importando o Manifesto Ágil publicado em 2001, aqui no Brasil o que eu ví foi adoção de processos por pura burocratização.

No ano de 2003 eu ví a primeira palestra de um “especialista” falando absurdos sobre o RUP, no melhor estilo Waterfall. Ele disse coisas do tipo “Levantar todos os requisitos na concepção”, “Modelar tudo na fase de elaboração”, e principalmente, o cara pregava descaradamente a errônea sequência Casos de Uso - UML - Codificação - Testes, e uma irracional separação de papéis que está em uso até hoje. Ele teve até tempo de mostrar como preenchia alguns artefatos. Nesse tempo eu não era tão crítico como hoje, e nem mesmo para os meus amigos que assistiram a palestra eu alertei contra as falácias daquele fanfarrão.

A cada dia que se passou desde então, ví mais e mais pessoas falando absurdos do RUP. Quando se diz RUP atualmente no mercado muitos torcem o nariz, associam com cascata, associam com artefatos, associam com ferramentas Rational, e principalmente, associam com esse pensamento burocrático da virada do milênio. Muitos dos que criticam são agilistas famosos, mas que não tem mais de 10 anos de experiência. Eu queria que a maioria desses consultores e especialistas Agile estivessem lá nos anos 90, reclamando da implementação OO nos produtos base da Microsoft, tentando entender Objective-C e vendo uma esperança OO mais simples no Delphi como alternativa. A gente acreditava que a Orientação a Objetos resolveria todos os nossos problemas, mas 15 anos depois ainda temos modelos anêmicos e pessoas sem a mínima noção do que são dependências ou mensagens querendo discutir OO em fóruns colocando sua pilha de certificações na sua assinatura de e-mail.

Em 2003-2004 eu tive o primeiro contato com o Extreme Programming num projeto J2EE para um grande Call Center Vendas, um projeto único no mundo, clusterizado, distribuído, Swing e mensageria. Sobre o XP, quer saber? Não ví quase nada de novo. Agora Casos de Uso são User Stories menores, o ciclo iterativo é mais curto, o desenvolvimento é orientado a testes (isso sim achei uma boa idéia, apesar de não compreender bem nos primeiros projetos) e a programação é em par (isso também geralmente não é uma azeitona fácil de engolir logo de primeira). Eu particularmente tenho dificuldade em parear com algumas pessoas devido ao meu déficit de atenção. Eu olhei para o XP e no primeiro momento ví que muito do que diziam do XP era algo parecido com o que a gente fazia nos anos 90, principalmente a parte do cliente presente. Todos os meus clientes no início dos anos 90 eram presentes. Comparado com a visão do desenvolvimento de software das consultorias o XP era o cúmulo da controvérsia. Já na mentalidade de um desenvolvedor de software dos anos 90, o XP faz todo sentido do mundo. Meu primeiro contato com o Scrum foi em 2005. E mais uma vez tive aquele sentimento: Sim, é bem diferente das práticas erradas do mercado, porém, não é muito diferente do RUP. Ele diz mais sobre ROI e sobre um importante Product Owner, mas também me lembro do Tonhão como um Product Owner nato nos anos 90. Em 2005 o Scrum era o cúmulo do descontrole de custos do projeto, por conta do seu escopo aberto e por conta do mindset PMBOK, mas para um desenvolvedor dos anos 90, simplesmente é o retorno aquilo que a gente já fazia: nos anos 90 não tinha pressão para se entregar tudo, mas havia pressão para resolver os problemas de negócio do cliente. E eu me lembro do Tonhão todas as sextas me cobrando aquilo que estava pronto, doido para colocar a aplicacão no ar só para ter certeza que ninguém na rede estava roubando ele.

A grande questão sobre o Agile Movement é sua mudança cultural. Infelizmente são poucas as pessoas que se divertiram fazendo software nos anos 90 - se você costuma tratar os desenvolvedores como crianças, lentamente eles se convencem que são crianças. O manifesto é um grito contra as coisas erradas do mercado. É uma emancipação dos desenvolvedores que não querem ser crianças. É uma injeção pragmática contra o pensamento pseudo-tradicionalista, controlador e traumatizado que existe hoje no mundo empresarial, especialmente na indústria do desenvolvimento de software.

O que vocês devem estar se perguntando é: O que matou o RUP e pode matar o Agile? Como eu falei, eu temo pelo movimento Agile. Assim como foi em 2003, em 2009 eu ví o primeiro pseudo-especialista Agile falando absurdos - violando valores. A partir do momento que eu vejo a comunidade Agile discutindo e dando importância demais a post-its, quadro de tarefas e cartinhas de planning poker, eu temo pelo movimento Agile. Quando eu vejo a comunidade Agile buscando certificações, preocupados em como casar Agile com CMMI ou como adaptar Agile à contratos de escopo fechado, eu temo pelo movimento Agile. Sempre que eu vejo isso no mundo Agile, me transporto a 10 anos atrás e me lembro das discussões sobre templates de casos de uso, definições de padrões de modelagem UML, pensamento linear, check-lists de artefatos, uso incorreto de ferramentas, falta de compreensão sobre fases e o pior de todos: o departamento que cuida dos processos de desenvolvimento. Resumindo, quando vejo esse mindset de besteirols e libertinagens Agile, eu me lembro do mindset burro e burocrático que contaminou o RUP.

O que matou o RUP foi a falta de entendimento, e isso é o que vai matar o Agile. Lean é o próximo da fila. Escreva aí: em 5 anos, dependendo dos ventos da economia e do clima empresarial, muitos vão estar criticando Agile do mesmo modo que hoje criticam o RUP, sem autoridade de causa. Tudo vai depender do mindset vigente no momento. Tudo depende do mindset: se você der o Scrum e XP para um “tradicionalista” ele não vai mudar seu mindset, mas sim adaptar o Scrum e o XP às suas “crenças”. Se você der o RUP para um pragmático, ele também não muda o seu mindset, mas sim, adapta o RUP à sua realidade. Você pode decidir o seu mindset: ou você realmente acredita nos 4 valores e 12 princípios ágeis e adota este estilo, ou você se enche de penduricalhos ágeis só para ficar na modinha.

Mais sobre o assunto “queda do Agile”:

Agile está morto! D-us salve o Agile! - José Papo
The Decline and Fall of Agile - James Shore
Por que dizemos não à certificação de Scrum Master - Vinicius Teles
A Completa Irrelevância do Certified Scrum Master - Philip Calçado
Flaccid Scrum - Martin Fowler

Esse artigo e a palestra que ministro com mesmo título é inspirado em “What Killed Smalltalk Could Kill Ruby, Too”, Keynote do Robert Martin (ou Uncle Bob) na RailsConf ‘09. Uma das melhores palestras que já ví. Veja abaixo:

Como havia anunciado aqui no Débito Técnico, tivemos a primeira turma aberta do Workshop Extreme Programming em São Paulo, com a participação de 5 equipes, usando as mais diversas tecnologias. O motivo da Aspercom aplicar turmas Beta de seus treinamentos é para verificar a aceitação do público geral e também para verificarmos a dinâmica do programa dentro do horário e as atividades práticas. No caso do Workshop XP, muitas dúvidas tivemos com relação à aplicabilidade do treinamento às diversas tecnologias, porém, tiramos esta preocupação com esta turma. Tudo correu muito bem e o treinamento foi um sucesso!

Iteração Inicial: Ainda muita pendência arquitetural para acertar…

4 pessoas, 2 notebooks = Pair Programming Obrigatório (e apesar do preconceito, no fim todo mundo gosta)

Paulo Calligaris, Marcelo Chisté, Willian W. Leite e Luis Cesar Teodoro: pessoal da BRQ em .NET

Leandro Faria, Carlos Lisandro, Hugo Sacramento, Elton Moura e Marcelo Costa: pessoal da UpLexis em PHP

Luiz Ricardo Batista, Alan Vidotti, Pedro Matheus, Daniel Takabayashi: pessoal da BRQ em Java

Mauricio Aniche, Paulo Henrique Martins, Willy Nakata, Murilo Cezar de Oliveira: equipe WOOF! em Java

Ricardo Almeida, Rafael Rosa, José Guilherme Ribeiro, Rodolfo Liviero da Silva e Anderson Carubelli: equipe da Gonow em Rails

Antes de mais nada, queria agradecer muito a turma pela excelente avaliação (principalmente pelos twitts) e também parabenizar a todos pelas aplicações que foram geradas. Elas me forneceram um ótimo feedback para melhorar o curso e alterar algumas coisas no sistema exemplo.

Próximas turmas…

A próxima turma aberta já está agendada para o dia 24 de outubro, sábado e com preço promocional, lembrando que você deve formar uma equipe de 4 ou 5 pessoas e escolher uma arquitetura para cumprir uma atividade prática antes do curso começar. Maiores informações:

http://www.aspercom.com.br/ead/calendar/view.php?view=day&cal_d=24&cal_m=10&cal_y=2009

No mês de agosto estive na WebGoal ministrando o nosso curso Extreme Programming. A WebGoal é uma empresa de desenvolvimento de projetos e de produtos próprios; fiquei bastante impressionado em como a empresa é dinâmica e possui uma filosofia empolgante. Eles são uma consultoria pequena focada em práticas ágeis e com muito potencial de crescimento. A primeira vez que os visitei era o dia de entrega da Sprint e lá eles comemoram com um churrasco na própria empresa. De fato é um ambiente muito legal, que me fez lembrar o Domenico DeMasi dizendo como o estilo e ambiente dos escritórios atuais influenciam na produtividade das equipes.

A WebGoal é um caso típico de uma empresa esperta que após alguns Sprints com o Scrum rapidamente notou as pernas que faltavam para um desenvolvimento ágil de verdade. Eles notaram que precisavam das práticas de engenharia do XP, destacando Testes Automatizados e Integração Contínua. É aí que nosso treinamento entrou. O Scrum e XP é a dupla que torna equipes verdadeiramente ágeis (fujam do Scrum flácido). O pessoal da WebGoal já usava muito Pair Programming, o que é muito bom, então, nas atividades práticas, os pares tiraram tudo de letra. Foi um dia muito enriquecedor, parabéns a todos da WebGoal!

Todo pessoal pareando.

Equipe 1

Equipe 2 e o Kanban

Um desenho vale por 3 palavras

Neste ano de 2009 teremos muitos eventos interessantes e muita gente boa presente nas palestras e bate papos. Estarei palestrando em quase todos eles (o ruim disso é que vou gastar muito tempo fazendo apresentações e pouco código).

JustJava 2009

Na semana que vem rola o JustJava 2009. Um dos eventos mais tradicionais da comunidade Java. Neste ano estarei levando a palestra “Requisitos Executáveis com FIT”, marcada para o dia 15/09, terça-feira às 17:30.

Evento de Aniversário do CEJUG em Fortaleza. Já faz um tempo que tenho contato com o pessoal de Fortaleza através da Fortes Treinamentos, nossa parceira no Ceará. Dessa vez o pessoal do CEJUG me fez um convite muito especial para palestrar no seu evento de aniversário que vai rolar no dia 19/09. Estarei presente com a apresentação: “O que matou o RUP pode também matar o Agile”. Se você é da região não pode perder.

Nessa minha ida a Fortaleza também estarei levando o Workshop Domain-Driven Design em Java que será no dia 18/09 com desconto para os associados do CEJUG.

Na sua segunda edição, as Jornadas Latino-Americanas sobre Metodologias Ágeis vem com força total e com presença garantida de muitas pessoas importantes da nossa comunidade Agile. Neste evento em Florianópolis estarei fazendo aquilo que faço sempre: ENSINAR. Minha apresentação na verdade será um mini-workshop sobre User Stories que vai rolar no dia 08/10.

O Encontro Ágil em São Paulo tem muitas novidades neste ano. A principal delas é a presença de Alistair Cockburn, um dos autores do Manifesto Ágil. De fato, uma oportunidade única. Estarei palestrando novamente com o José Paulo Papo sobre Auto-organização e Gestão por Metas Flexíveis.

Muitos outros eventos legais serão realizados. Entre eles eu sugiro o Dev In Rio e o Rails Summit. Infelizmente, por conta de problemas de agenda, não poderei participar do Dev In Rio, mas no Rails Summit estarei presente!

Desculpem o atraso! Mas só neste feriadão de 7 de setembro estou tendo tempo de escrever sobre a experiência do Rails Rumble, e com uma vista espetacular da Mata Atlantica, na praia da Barra do Sahy em São Sebastião.

Bem, como tinha falado no post anterior, a nossa aplicação para o Rumble não era algo para se fazer em 48 horas. Era um desafio e tanto, mais ainda para uma equipe que nunca havia trabalhado junto antes. Eram 23 user stories. Todas as outras equipes falaram que era grande demais! Porém, eu acreditava que seria possível, pois dessas 23 stories havia gordura para queimar (stories que poderiam ser cortadas sem prejuízo para o valor da aplicação).

A equipe brazilian-dojo (conte as latas de RedBull)

Logo no inicio do Rumble, para variar um pouco, tivemos alguns problemas de infra. Contas de GitHub que não entravam e Linodes com alguns problemas. Graças a Deus nossa equipe tinha o Cauê Guerra, que demonstrou muita habilidade para lidar com hospedagens Linux para Rails. Passado esse primeiro momento o Cauê falou a palavra mágica: “Vamos parear”.

Acho que o Rumble foi uma das minhas melhores experiências com Pair Programming. Isso porque esse foi o meu primeiro projeto Rails com uma equipe de programadores (meus projetos Rails anteriores foram solo). Eu aprendi muito. Parear com o Cauê foi muito legal, pois ele ensinou vários truques e também ví muitos vícios ruins eu fazia. Na nossa primeira sessão pareamos por pouco mais de 4 horas. Depois tivemos algumas outras sessões curtas, mas no sábado, teve um momento que adiantamos MUITO o projeto numa sessão em par de 10 horas. Não há dúvidas que programar em par é mais produtivo. O gargalo da programação não está na digitação. Quem diz o contrário ou nunca programou na vida ou não sabe trabalhar em equipe. Num projeto como este, cheios de integrações e incertezas, ví que os momentos que a gente não pareava era muito improdutivo. Talvez isso que vou falar aqui agora é a coisa mais nerd deste blog: no Rumble, eu e o Cauê passamos as primeiras 30 horas programando sem parar, movidos a Red Bull. O Alexandre, nosso web designer também nos acompanhou por parte do trajeto.

Um monitor adicional ajuda muito no Pairing.

Nós não terminamos a aplicação completa. Nós tivemos muitos problemas na reta final, principalmente com a integração com o GoogleMaps (a batalha do Felipe e do Cauê). Mas nem por isso tivemos um sentimento de derrota. Foi muito divertido e foi uma inter-fertilização tremenda. Das 23 stories nós entregamos 15, dropamos umas 5 e deixamos de entregar 3. Essas 3 histórias simples que deixamos para final eram as histórias que não tinham integração com nada, mas que davam todo o sentido para o site (a busca e a parte de colaboração). Mais 4-5 horas nós conseguiríamos entregar tudo, mas o Rumble é implacável com relação ao prazo. Ao final do tempo tudo é bloqueado.

Discussões de Design no amanhecer

Pessoal das outras equipes e amigos da Gonow.

Quero agradecer muito o Cauê, o Felipe e o Alexandre pela excelente experiência, onde pudemos compartilhar muito da nossa arte de desenvolver software. Quero também parabenizar a Gonow pelo patrocínio das equipes brasileiras e por ter fornecido absolutamente tudo para nós, desde as refeições até o hotel, que era a nossa “descompressão”. Tudo foi muito bem organizado.

E que venha o Rumble 2010!!!!!

No próximo final de semana, mais especificamente das 21:00hs da sexta-feira às 21:00hs do domingo, estarei participando do Rails Rumble. Para quem não conhece, o Rails Rumble é muito simples: É uma competição onde você e mais 3 amigos devem fazer uma aplicação, um website ou produto usando Rails em 48 horas. A melhor aplicação vence! Simples né?

A equipe conta com Felipe Oliveira Kenobi (nosso sensei SOA), Cauê Guerra (nosso Jedi Rails) e Alexandre Theodoro (nosso expert em Web Design). O projeto é um site para os eventos do tipo Flash Mob estendido ao conceito de redes sociais, onde um usuário poderá criar eventos, notificar seus amigos sobre o mesmo, compartilhar as experiências agregando opiniões de diversos partipantes, registrar seus momentos em diferentes mídias e torná-las acessíveis à partir de um único ponto.

Olhando pela visão tecnológica, o projeto não pretende reiventar a roda. Serão integradas plataformas pré-existentes divididas em: Conteúdo (Digg.com), Mídia (Flickr e Youtube), Calendário (sistemas como Google Calendar e Yahoo UpComing), oAuth para registro do usuário, OpenSocial Platform (Google), Maps e sistemas de microblog (Twitter). Resumindo, muitos mashups em cima de um modelo baseado em WOA.

Link para o projeto: http://r09.railsrumble.com/teams/brazilian-dojo

A participação das equipes brasileiras no Rails Rumble é um patrocínio muito legal da Gonow. Durante o evento, a Gonow estará cedendo o seu espaço e infra-estrutura para as 3 equipes participantes. Além disso, estará também fornecendo hospedagem e alimentação durante o evento. Não só isso, a Gonow também estará filmando tudo (um Big Brother Developer Brasil).

Fazer uma aplicação completa num curto espaço de tempo é um desafio técnico e também para a gestão do “projeto”. Como havia relatado aqui anteriormente, no projeto da DDWorks, tínhamos o desafio de entregar um e-commerce em 40 horas (uma semana). Trabalhamos com iterações diárias. Minha experiência nesse tipo de projeto poderá ajudar no Rumble. Basicamente, o que aprendi foi: baby steps são amigos, use histórias bem pequenas, integração contínua insana, coloque os incrementos no ar o mais rápido possível e veja bem o quanto você investe em testes. Espero que isso também ajude as outras equipes!

Neste projeto do Rumble será uma experiencia diferente. A equipe trabalhará tanto no Tech como no Business e vejo que a junção dos skills está favorecendo muito o projeto. Nós decidimos fazer iterações de 3 horas, com 30 minutos de retrospective e planning. Vamos trabalhar em pares, integrando em não mais que 30 minutos. Estamos também separando alguns momentos para descanso dos participantes. Esperamos estar vivos para comemorar no domingo com todo mundo.

É bem provável que estaremos postando muita coisa no Twitter neste fim de semana. Siga: @scaphe, @caueguerra e @rodrigoy.

Em Novembro de 2007 estive em Porto Velho ministrando sobre arquitetura e orientação a objetos para o pessoal do Tribunal de Justiça de Rondônia (TJRO).

Agora em julho, estive mais uma vez com nossos animados amigos do tribunal dessa vez para ministrar sobre práticas ágeis de gerenciamento e engenharia. O TJRO foi uma das primeiras organizações a comprar um pacote Agile completo (Scrum+XP).

O nosso novo curso Extreme Programming vem para completar o nosso renomado curso Scrum com práticas de engenharia do dia-a-dia de uma equipe ágil. Vamos as fotos das equipes…

Durante a iteração: “pares promíscuos”, muita conversa e concentração.

Ambiente informativo semi-digital do treinamento

Equipe que entregou mais histórias

A equipe que mais divergiu nos pairings

A equipe que mais discutiu

A equipe que mostrou maior comunicação/colaboração (infelizmente morreram na praia!)

Gostaria agradecer a todos do TJRO pelo excelente empenho e participação dos treinamentos como um todo. Ao fim todos gostaram das práticas mais polêmicas do Extreme Programming, como a programação em pares. É bastante comum as pessoas questionarem sobre Pair Programming, porém, quando você tem a experiência real, a sua opinião realmente muda!