Rodrigo Yoshima

Encontro Agile / Mingle Day Retrospective

O evento “Encontro Agile / Mingle Day” em parceria Aspercom e ThoughtWorks foi um sucesso. Tivemos 80 pessoas, muitos bate-papos, reencontros de velhos amigos e muito mais.

Eu e o José Paulo Papo, desde os fatos recentes do Scrum Gathering, discutimos muito sobre “back to basics” na nossa comunidade Agile. Nós apresentamos a palestra “Auto-gerenciamento e Gestão por Metas Flexíveis”. Segue o Slideshare…

(a minha parte da apresentação não dá pra saber muita coisa, né? vou postar sobre o assunto em seguida)

Segue também as fotos:

IMG 7449 - IMG 7449
Palestra Agile

IMG 7452 - IMG 7452
Rodrigo Yoshima - Auto-organização

IMG 7458 - IMG 7458
José Paulo Papo - Metas Flexíveis

IMG 7457 - IMG 7457

IMG 7454 - IMG 7454
Presença de muitas pessoas da comunidade

IMG 7465 - IMG 7465
Coffe-break

IMG 7463 - IMG 7463
Paulo Caroli (ThoughtWorks), Dairton e Rodrigo Yoshima

IMG 7474 - IMG 7474
Pessoal da Stefanini/Claro

IMG 7476 - IMG 7476
Os palestrantes: Papo, Paulo, Adam e Yoshima

IMG 7478 - IMG 7478
Paulo Caroli: Uma review da vinda da ThoughtWorks para o Brasil.

IMG 7481 - IMG 7481
Adam Monago, demonstrando seu produto - fiquei realmente impressionado

Foi um prazer muito grande organizar esse evento e poder conversar com os vários ThoughtWorkers que estão na missão de abrir o escritório aqui no Brasil, que todos nós aguardamos ansiosamente.

logo tw - logo tw aspercom logo - aspercom logo

A Aspercom e a ThoughtWorks convidam você para o Encontro Agile/Mingle User Group Meeting. Este será um evento gratuito em São Paulo com mini-palestras, discussões e muito bate-papo.

Data: 30 de junho de 2009 às 19:00hs

Facilitadores:
Paulo Caroli (Agile Coach, ThoughtWorks)
Adam Monago (Gerente de Produto - Mingle, ThoughtWorks)
Rodrigo Yoshima (Instrutor Agile, Aspercom)
José Paulo Papo (Especialista Agile)

Agenda:
19:00 Auto-organização e Gestão por Metas Flexíveis (Yoshima, Papo)
19:45 Painel: Quais são seus problemas de gerenciamento de projetos?
20:15 Coffe & Bate-papos
20:50 Mingle User Group Metting (Adam Monago)
(happy hour após o evento!)

Mingle User Group Meeting - São Paulo

O encontro do Mingle User Group (MUG) do Brasil é uma oportunidade para conhecer, discutir e compartilhar experiências com o Mingle. Adam Monago, um especialista no produto juntamente com outros Agilistas experientes, demonstrarão o Mingle provendo dicas e truques em como usar o produto para gerenciamento de projetos e colaboração.

ATENÇÃO NOVO LOCAL:
Mercure Hotel São Paulo Paulista
Rua São Carlos do Pinhal, 87 - Bela Vista - MAPA
(Metrô Brigadeiro)

Inscrições/Informações: contato@aspercom.com.br

Rodrigo Yoshima

Auto-organização é Natural

Num desses meus vôos, passei numa livraria no aeroporto de Guarulhos e comprei o livro “Uma Breve História do Mundo” de Geoffrey Blainey. O livro é excelente e praticamente li tudo no vôo de algumas horas. Este livro conta a história da humanidade de uma maneira muito agradável, pois o autor tem uma excelente capacidade de resumir e contar somente os fatos mais interessantes.

Nesses momentos aonde nós da comunidade de desenvolvimento de software estamos discutindo sobre auto-organização, Scrum, Agile e outras coisas, a leitura de Blainey vem bem a calhar. Por incrível que pareça, não faz sentido as pessoas acharem que auto-organização é algo extraordinário! Para já adiantar o assunto, auto-organização é algo que a humanidade pratica a milhares de anos e de alguma forma isso se perdeu nos últimos 100 anos.

No período Paleolítico, tempo da história que durou aproximadamente 2 milhões de anos, o homem se desenvolveu vivendo em grupos pequenos de até 20 pessoas. Eram tribos nômades que saíram da Africa e se deslocavam atrás daquilo que a natureza lhes oferecia (frutas, raízes, pesca, caça e etc…). É fácil imaginar como esses grupos se auto-organizava, apesar de ter uma liderança dos mais experientes (provavelmente nas atividades de caça). Nesse período frio da história a maior responsabilidade de um ser humano era sobreviver, e era uma questão de sobrevivência desenvolver a fala. O fato do ser humano necessitar de formas de comunicação explica um pouco sobre esse modo de vida.

Nesse período havia um grande isolamento. Não houve por exemplo um agrupamento de 50 humanos num mesmo lugar, pois um grupo grande não conseguiriria subsistir dos recursos locais por um tempo maior que algumas semanas. Os grupos moravam em cavernas e temiam a noite, assim como grandes animais.

prehistoria1 - prehistoria1
Pinturas ruprestes: uma forma de “modelagem” comunicativa

Ainda na pré-história, lentamente, num período de 10 mil anos conhecido como a “Passagem”, a Terra se aqueceu, muitas geleiras derreteram aumentando o nível dos oceanos e o mapa-mundi ficou da maneira como o conhecemos hoje. A Terra começou a ter mais lugares habitáveis, teve um significativo aumento da população mundial, gradativamente o homem começou a desenvolver a agricultura e passou de nômade à sedentário. Esse período foi chamado Mesolítico caracterizado principalmente pelo domínio do fogo.

Continuando a história, com um homem sedentário e menos dependente dos humores da natureza, surgiram tribos e clãs maiores. O homem construiu casas que formavam as primeiras aldeias, mas mesmo assim havia um profundo senso cooperativo. Havia quem plantava, havia quem caçava e até a criação/domesticação de pequenos animais se desenvolveu. Como o estabelecimento do homem em locais fixos, temos o Período Neolítico. Ainda nesse período, não há qualquer razão para acreditarmos em qualquer estrutura rígida de controle: não havia relações de emprego e a formação social era simples e auto-organizada.

agricultura - agricultura

Com o domínio da fundição e outros avanços tecnológicos como a irrigação e o uso de ferramentas, já na Idade dos Metais (final da Pré-História), o homem organizou as primeiras cidades-estado e reinos onde havia comércio à base de trocas. Surgiram a navegação e as guerras. Mesmo assim, o dia-a-dia das pessoas era plantar e fazer alguns artesanatos (ferramentas, roupas, cerâmicas) em constante auto-organização geralmente em pequenas estruturas familiares. Nesse período com guerras e conquistas, surgiram talvez dois grupos não “auto-organizados”: os exércitos e os escravos. Exércitos logicamente não são auto-organizados na sua essência, pois não há sentido em ter uma reunião diária para decidir em grupo “quem vai morrer hoje”. Geralmente um general ou capitão toma essa decisão por você.

prehistoria2 - prehistoria2

Só até este ponto, cobrimos grande parte da história humana, e vemos que a dinâmica interna do trabalho produtivo (fora os militares e escravos), em linhas gerais, era o homem obedecendo a natureza sobre os momentos certos de plantar, regar e colher. Não havia “chefes” mandando aquilo que os trabalhadores deveriam fazer no seu “dia-a-dia” (não estou entrando no mérito dos abusos dos Modos de Produção). Esse período que compreende desde o Neolítico (aprox. 10.000 a.C) até a Revolução Industrial (entre os séculos XVII e XIX) o trabalho consistia basicamente em plantar, criar animais e obter meios de se proteger do frio sempre em estruturas artesanais familiares. O trabalho de lavrar ainda era responsabilidade dos lavradores e eles dominavam essa arte. Não tinha gerentes de projeto ou algo similar. Não tinha ninguém dizendo como e qual ordem as coisas deveriam acontecer. Se você vier em qualquer sítio familiar aqui em Vinhedo, de onde escrevo (bebendo um excelente vinho de garagem da produção local), você ainda vai encontrar uma estrutura descentralizada e cooperativa que ainda perdura mesmo no século XXI.

Nos primórdios da Revolução Industrial muito mudou na maneira como olhamos para o capital e para o trabalho, e sem comentar as mudanças econômicas e políticas. Resumidamente a Revolução Industrial é sinônimo de automação. Com a crescente automação da agricultura e outros avanços tecnológicos, os rigores do campo se tornaram mais amenos. As pessoas sairam das fazendas e se instalaram nas cidades. Passaram a trabalhar não só plantando, mas viveram também da manufatura nas oficinas artesanais de roupas, utensílios e máquinas - um renascimento urbano - tendência que já vinha se desenvolvendo desde a Idade Média. Mesmo com essas mudanças, guerras e variações no clima que abalam a agricultura ainda podiam fazer centenas de milhares morrerem de fome.

eraindustrial - eraindustrial
Trabalho infantil ainda era muito presente no séc. XX

As mudanças deste século foram muito aceleradas. Tivemos o impulso de duas Grandes Guerras. Pessoas como Taylor, Fayol e Ford acrescentaram muito ao pensamento industrial e econômico. Chegamos ao Mundo Global e à era da Informação.

Apesar de ter feito isso, o objetivo deste artigo não era só contar história, mas lendo o livro do Blainey, escrever me pareceu irresistível. O objetivo aqui é dizer que realmente não há desculpa plausível para não ter auto-organização entre os profissionais do conhecimento e de alta tecnologia que são os desenvolvedores de software. A auto-organização é algo que faz parte da existência humana nesses milhares de anos de existência. É algo natural para um ser inteligente e racional. A falta de conhecimento, o medo, as limitações na comunicação e as barreiras culturais nunca foram motivos para não existir auto-organização na história. Um homem do Período Paleolítico, vestindo capas de peles, fugindo do frio, temendo grandes animais e sem sequer dominar o fogo sabia se auto-organizar. É simplesmente inconcebível que um programador, lendo este blog num MacBook, esperando um vôo num aeroporto internacional e falando ao seu iPhone, precise de alguém para organizar o seu trabalho juntamente com a sua equipe de desenvolvimento.

Pense nisso, Homo sapiens…

Rodrigo Yoshima

Workshop Scrum em Belém dia 22/05

Sei que estou avisando em cima da hora, desculpem! Esse treinamento será em parceria com a Equilibrium Web. Poucas vagas! Inscrevam-se já.

Mais informações na imagem abaixo:

scrum bel  m - scrum bel  m

Rodrigo Yoshima

Scrum Gathering Brazil ‘09

Terminou hoje aqui em São Paulo o maior evento sobre Scrum do mundo. Muitas histórias para contar e muitas fotos para postar. Estavam presentes aproximadamente 240 pessoas entre programadores, gerentes de TI, ScrumMasters e PMPs. As instalações do Hyatt são as melhores da cidade e a organização do evento foi muito boa. Vamos às palestras:

Project Management as a Strategic Competency - Ricardo Vargas, PMI

O Ricardo fez uma palestra bem política, e mostrou algumas coisas que gostaria que muitos PMP’s que tive contato vissem. De qualquer forma, a apresentação foi um pouco comercial do PMI, que defende a visão “Planejamento é crucial e conduz ao resultado. Esse resultado não foi por sorte e sim por ter processos”.

Uma coisa interessante é que todo mundo está fugindo do termo metodologia e processo, preferindo as palavras framework e ferramenta. Engraçado! Nada é metodologia! Nem o PMBOK! Nem o Scrum! Ele disse que PMBOK é um guarda chuva, e que odiava as pessoas “by the book”.

ricardo vargas - ricardo vargas
Ricardo Vargas, manda soltar e manda prender no PMI.

Ele afirmou: “Uso o PMBOK como uma referência. E não existe gerenciar segundo o PMBOK.”

Apesar da palestra ser criticada por alguns, eu gostei, mas pelo fato dele não conhecer profundamente o Scrum, cometeu alguns pequenos deslizes, como responder ao Juan que achava auto-gestão ótimo, mas não acreditava muito, pois não tinha tido sucesso ainda com isso.

Eu gostei porque tem muito PMPzinho que gerencia projetinhos de R$ 250 mil e se acham o super-hiper-gerente-de-projeto, porém, quando você gerencia projetos de R$ 250 milhões ou R$ 2,5 bilhões a coisa muda de figura. Você precisa de alguém bom para gerenciar.

A palestra foi boa, mas a discussão é: será que era para ela estar num evento de Scrum? Eu não ví problema nisso, e até achei acertada a estratégia, pois muitos PMPs se sentiram em casa.

rodrigo juan - rodrigo juan
Eu e o Juan Bernabo. Foto: Manoel Pimentel

Leia o restante deste artigo »

Rodrigo Yoshima

Mais ISVs: Millenium Network

logo millenium - logo millenium

Nessa semana tive o prazer de treinar mais três animadas equipes com o nosso Workshop Scrum. A Millenium Network é uma empresa brasileira que desenvolve software de gestão para confecções e tem mais de 400 clientes espalhados em todo Brasil. Eles iniciaram a trilhar o caminho ágil como a alternativa natural para ganhar mais colaboração entre departamentos e melhorar o atendimento aos seus clientes.

No caso da Millenium, o Scrum e outras práticas ágeis de desenvolvimento de software estão inseridas dentro de um projeto tradicional que aplica PMBOK. Explicando melhor, existe um projeto de implantação do software que segue um processo prescritivo onde internamente existe o projeto de desenvolvimento de customizações. É aí que o Scrum entra.

Durante grande parte da minha carreira eu trabalhei em ISVs e nos últimos bate-papos com outros clientes Aspercom, que também são empresas de produto, vejo que o REAL desenvolvimento de software estão nesses ambientes. Se você trabalhou toda a sua carreira em consultorias desenvolvendo softwares para outros, seria legal você expandir seus horizontes e pensar em trabalhar num ISV. Você precisa aprender a administrar por longos anos a sua base de código, pensar em estratégias de deployment em muitos sites, gerenciar as manutenções, aplicar todas as práticas de SCM e além de tudo isso, aprender a atender um mercado e não um usuário específico.

Na minha ida à Fortaleza na semana passada, tive a oportunidade de conversar bastante com o Tales da Fortes (tomando umas cervejas). Ele também vive o dia-a-dia ISV, com seus benefícios e suas Via crusis. No caso dele, passam de 2.000 clientes! Você imagina o que é ter seu software instalado em mais de mil lugares diferentes, talvez com versões diferentes e usuários diferentes? Esse é só um dos problemas que eles tem que lidar. Tudo aquilo que se fala conceitualmente nas consultorias como “lidar com legado”, “diminuir a manutenção”, “desacoplar implementações” e “preparar para customizações” só é aplicado na prática mesmo dentro de um ISV.

O foco de atuação principal da Aspercom no momento são os ISVs. Estamos nos especializando nesse ramo e vemos que nessa área de atuação a adoção de Agile é mais confortável. Como disse na entrevista para o Vinicius Teles na TDC 2008, para essas empresas as práticas ágeis fazem mais sentido. São empresas menores, é mais fácil achar um bom Product Owner, já existe uma rica colaboração entre a equipe e eles aceitam melhor o escopo negociável.

Estamos lançando um novo Workshop prático de Extreme Programming completamente inovador ainda neste semestre. Notícias em breve aqui no Débito Técnico.

Rodrigo Yoshima

Reunião diária: um mecanismo de cobrança

Quando publiquei o artigo Product Owner: um desgraçado ganancioso a minha intenção foi quebrar uma visão errada que o mercado tem a respeito de Scrum e Agile em geral. Muitas pessoas que converso em clientes, eventos e listas de discussão tem uma visão muito romântica a respeito do Scrum. Muitas delas entraram em choque ao ler esse artigo que diz que o Product Owner é um cara que só pensa em dinheiro.

As pessoas tendem a achar que tudo no Scrum é romântico, não tem nada te pressionando, a colaboração é linda, o Product Owner é paciente, as coisas fluem naturalmente, o ScrumMaster é um líder terno e querido, é só colar post-its no quadro, entregar iterações, entrar em débito técnico, comer pipoca nos plannings e viver feliz para sempre.

Infelizmente o Scrum não é assim. Nós precisamos entregar o projeto! Eu sei que muitos CSMs, CSPs e CSTs podem não concordar com o que vou dizer agora, e vou deixar bem claro aqui: a Reunião Diária do Scrum é o melhor mecanismo de cobrança que existe.

meeting - meeting

Quando tive os primeiros contatos com Scrum em 2005 (e antes disso eu aplicava as práticas iterativas de gerenciamento de projetos do RUP), eu estava trabalhando num projeto internacional que seria implantado em mais de mil hospitais no Japão*. O primeiro projeto de nove dígitos a gente nunca esquece. O projeto estava indo bem com as práticas do RUP, porém, sabe como é uma criança com um brinquedo novo? Eu estava doido para aplicar o Scrum e a transição foi bem tranquila (a equipe era sênior). Nessa virada, tomei uma das decisões mais sábias da minha carreira: eu deleguei o papel de ScrumMaster para outra pessoa. Eu atuei como um membro da equipe.

screenshot - screenshot

Tomei essa decisão de não ser ScrumMaster porque vejo que muitas práticas que descem da gestão na maioria das vezes não fazem sentido para as equipes. Eu quis provar o Scrum sob todos os aspectos. Atuar como membro da equipe antes de atuar como ScrumMaster foi uma experiência valiosa. Um ScrumMaster jamais será um bom ScrumMaster se ele nunca atuou como membro da equipe num projeto Scrum.

Nos primeiros dias eu ví que as reuniões diárias mostravam uma coisa claramente: me faltava FOCO na execução das tarefas. Eu era arquiteto, e muitas vezes não cumpria as tarefas do projeto simplesmente porque estava correndo atrás de algum capricho arquitetural ou perdia o dia lendo mails e fazendo coisas na Internet. Quando eu via que estava “viajando” demais, eu lembrava que às 15:00hs teria a reunião diária, e eu não havia cumprido a tarefa sob minha responsabilidade. Eu me sentia cobrado porque a reunião diária estava se aproximando e eu não tinha trabalho nenhum para mostrar para os outros membros da equipe.

Vocês se lembram das perguntas da reunião diária:

1. O que você fez desde a última reunião diária?

2. O que você pretende fazer até a próxima reunião diária?

3. Tem alguma coisa impedindo o seu trabalho?

Nas perguntas 1 e 2 a equipe não está se reportando ao ScrumMaster! Nessas perguntas a equipe está se reportando para ela mesma de forma auto-gerenciável. E sabe o que é interessante? O comprometimento da equipe é maior com a própria equipe do que com os níveis hierárquicos superiores. Quando você está falando o que você fez para a própria equipe você sabe que eles estão no mesmo barco que você. Não há razões para constrangimentos, dissimulações e conflitos.

É muito fácil enganar um gerente de projeto que passa com um Gantt Chart perguntando “- Já terminou a tarefa? Quantos porcento ainda falta?”. Agora, não é tão fácil assim enganar os membros da própria equipe… Eles passaram o dia todo com você. Não adianta você falar que não cumpriu a tarefa porque teve problemas com o RichFaces, pois os outros membros viram que você ficou a manhã inteira procurando seu carro novo na Webmotors. Não adianta você falar que não conseguiu falar com o usuário - a equipe viu que você ficou discutindo sobre repositorios no GUJ. Não adianta reclamar que o build demora - a equipe sabe que você ficou rodando os testes só para conversar com aquela loirinha do projeto ao lado.

A reunião diária está chegando, então, mostre serviço! Por mais romântico que você queira ser com o Scrum e com a auto-organização/gestão, por debaixo dos panos o Scrum tem mecanismos de cobrança, e são mecanismos muito melhores que um gerente de projeto perguntando “percentuais de conclusão”.

* Sei que você arquiteto de plantão deve estar doido para saber como era esse projeto do Japão por dentro. Vamos lá: Usamos Domain-Driven Design, cliente Swing, JBoss e EJB3/JPA/Hibernate no servidor, integração via XML-RPC - o troço tinha que escalar. Conseguimos suportar 80 transações simultâneas numa máquina com 2 processadores (o objetivo do projeto era suportar 1.000 prescrições médicas por minuto). O maior desafio era a usabilidade: japonês gosta muito de telas TouchScreen (por isso que os botões são grandes). Outras características: segurança biométrica, assinatura eletrônica de documentos, integração com máquinas de diagnóstico por imagem e quando você ligava o japonês não dava nem pra navegar na aplicação, só decorando os labels. Foi um dos projetos mais interessantes que participei.

Rodrigo Yoshima

Ame seu código…

Um dos assuntos mais comentados no Twitter é a palestra do Robert Martin (Uncle Bob) na RailsConf. O Fábio Akita conseguiu uma declaração exclusiva do próprio Uncle Bob para os para os programadores brasileiros.

Aliás, vou aproveitar esse post para divulgar meu Twitter: http://twitter.com/rodrigoy

Assista com atenção, e passe esse recado para todos que você conhecer.

Uncle Bob Martin na RailsConf 2009 from Fabio Akita on Vimeo.

Gostei dessa parte: “seu código não tem que simplesmente funcionar…”

Fonte: http://www.akitaonrails.com/2009/05/07/railsconf-09-uncle-bob-martin

Rodrigo Yoshima

Agile Beer Drinking Fortaleza

Amigos(as) Cearenses,

Neste mês de abril estarei em Fortaleza, ministrando treinamentos em parceria com a Fortes. E como é costume, teremos um bate-papo com os agilistas de Fortaleza.

agilebeerdrinking fortaleza 1 2 - agilebeerdrinking fortaleza 1 2

Cascateiros também podem participar, afinal, são eles que dão o tom irônico desses encontros.

Veja os fatos e fotos dos encontros anteriores:

http://blog.aspercom.com.br/2008/09/22/bsb-restrospective/
http://blog.aspercom.com.br/2008/06/19/agile-beer-drinking-sao-paulo/

Rodrigo Yoshima

O que é um TIE e um BAD BEAT

Fazia um tempo que não postava nada sobre Poker, e como algumas pessoas pediram algumas peripécias das mesas segue as coisas interessantes de hoje:

Primeiro, veja este TIE (nunca aconteceu isso comigo):

TIE - tie

Note que foi bem no início do torneio (blinds em 10/20). Entre o flop e o turn algumas pessoas deram raises baixos (de 20 e 40). Quanto virou o river todo mundo checkou e eu era último. Dei um raise maior para 80 no blefe. Os outros oponentes hesitaram demais, mas acabaram pagando… tremi nas bases, mas quando o dealer apontou o TIE não acreditei… 3 pessoas com 10 e 4.

Bad_Beat - bad_beat

No mesmo torneio, já com blinds mais altos nosso amigo “SLOWPOKEDAD” já estava se despedindo da mesa com 175 fichas só. Saí com AQ e dei um raise médio para 200 fichas. Todo mundo fugiu, menos esse infeliz. Ele tinha 4 e 5, e pagou (já triste indo vestir o pijama para dormir). Quando virou A, 10 e 2 no flop já estava quase escrevendo “bye, bye, sucker” no chat. Aí vira um safado de um 3 no river. BAD BEAT total.

Sem problemas, levamos BAD BEATS nos negócios e no poker. Antes no Poker que nos negócios!!!

Se você é leitor do blog e joga poker deixe seu recado aí! Quem sabe não marcamos um jogo?

- Próxima Página »