metodologias « Fragmental

Archive for the ‘metodologias’ Category

Gerencie como um pr0n star!

Friday, May 15th, 2009

Se você não entendeu a piada com o título clique aqui.

Então tivemos o Scrum Gathering Brazil esta semana. Infelizmente eu não estava por lá mas acompanhei bastante a movimentação via twitter e conversando com amigos nos instant messengers da vida. Agora estou lendo a cobertura dos blogs.

A que mais me chamou atenção –e eu já previa isso tendo conversado com o autor durante a evento- foi a do Rodrigo Yoshima. Entre diversos comentários sobre apresentações que deixaram pontos de interrogação e exclamação na cabeça do autor eu destaco:

Usando Scrum com o Visual Studio Team Systeam - Fabio Camara [...]
- Ele acha incrível como a Regra de Pareto se aplica a projetos de software: 20% dos desenvolvedores fazem 80% do trabalho.
- Ele se questiona se vale a pena o programador testar. Para ele, o programador só deve verificar e um testador, que é mais barato, testa efetivamente. Na mesma linha ele questiona TDD para projetos que ele denomina “time-driven”. Não achei referências para esse termo, mas ele classifica como os projetos onde tudo é para ontem. Nesses projetos não há tempo para pensar em testes unitários.
- A maior divergência porém, é o papel do ScrumMaster na visão do Fabio Camara. Para ele o ScrumMaster Monta o Plano, Distribui Atividades, Obtém Feedback e Refaz o Plano. Ele deixou claro na palestra que essa é a opinião dele. Quando questionei a respeito da auto-organização do Scrum ele disse que também não acredita na auto-organização.

E o grande sumario disso (desculpe o hotlink, Rodrigo!):

Este é o tipo de coisa sobre a qual eu falei aqui, aqui, aqui, aqui e, principalmente, aqui.

Quanto mais as metodologias ágeis ganham o mainstream mas nós vamos ver este tipo de coisa. O fato de que Scrum possui certificações e selinhos só piora tudo já que dá credibilidade imediata a uma informação errada no seu princípio básico.

Isso me lembrou alguns casos. Uma vez uma amiga foi para um cliente que havia implantado Scrum há pouco tempo. Todos fizeram o cursinho e tinham selinho de CSM. O diretor do programa tem o selinho melhor, CSP, e estava no caminho do seu CST, o selinho máximo.

Ela é uma analista de negócios e quando chegou foi levada imediatamente para uma sala com todos os stakeholders e desenvolvedores. Eles olharam seriamente para ela e disseram algo como:

- Precisamos muito da sua ajuda. Precisamos de aconselhamento em como deixar a informação visível. Agora com Scrum nós precisamos deixar claro o que está acontecendo aqui no desenvolvimento para todos.
- Uh. Ok, então acho que vocês podem começar me explicando o processo de negócios, acho que posso ficar algumas horas vendo como vocês trabalham e como o sistema é usado. Depois queria conversar um pouco com o time de desenvolvimento, podemos fazer uma mini-retrospectiva e uma futurospectiva para tentar entender porque a comunicação é um problema. A partir daí nós traçamos um plano, pode ser necessário conseguirmos coaches técnicos e, talvez, um gerente de projetos com experiência em métodos ágeis…
- Er… ahm. Ta. Mas… não era bem isso que estávamos pensando. Sabe, nós já fizemos tudo isso. Tivemos uma grande reunião, acertamos os fluxos de trabalho e tal.
- É? Mas… pelo que eu vi conversando com pessoas durante as últimas semanas vocês ainda têm problemas, os desenvolvedores estão reclamando de que tudo muda o tempo todo, o pessoal de negócios reclama que vocês estão quinze meses atrasados…
- Sim, sim, sabemos disso tudo. Mas nós sabemos que com o Scrum eventualmente essas coisas vão se resolver, não estamos preocupados. O que nós não conseguimos entender é como otimizar a radiação de informações utilizando kanbans distribuído pelo chão de fábrica.
- “Otimizar..kanban…” peraí, vocês querem que eu ajude você a decidir onde colocar seu story wall?
- É, acho que você pode colocar deste jeito…
- Você tem alguma idéia do quanto vocês estão pagando por hora pra eu estar aqui?!?

Eventualmente o cliente percebeu que onde posicionar o story wall era o menor dos seus problemas. Um dos principais problemas deles é que estavam fazendo exatamente o que o Fabio Câmara sugeriu: tinham um Scrum Master que criava, gerenciava e ajustava o plano. Os desenvolvedores estavam sempre atrasados porque eles nem sabiam qual era o plano, apenas sabiam das atividades. Discussão típica:

- Estamos atrasados!
- Você está atrasado, meu time está em dia.
- Como assim?
- Eu falei que precisava de dois dias para colocar o back-end em produção, bom estamos terminando agora, com o mínimo de atraso.
- Mas o front-end não está pronto, qual a diferença?
- Isso é com o time do Beltrano. Nós aqui estamos certos. Sprint goal atingido, vamos para o bar.

Ou, na “obtenção de feedback”:

- Ok, esta tarefa aqui está demorando muito então vamos acabar entregando aquela ali atrasada.
- Você está dizendo que o projeto vai atrasar?!
- Não, não. Você me entendeu mal. Meu time está OK, nós vamos entregar em dia, não se preocupa não.
[dois dias depois]
- E aí, tudo certo?
- Tudo.
- Aquela tarefa ali… está meio atrasada, não?
- Não, não. Veja bem, ela já vai estar pronta… já já.
[final do sprint]
- Então, como estamos?
- Bom. Aquela tarefa ali atrasou. Isso fez com que o Fulano ficasse preso ajudando o Beltrano e não fizesse o trabalho dele. Mas não tem tanto problema porque ele não ia conseguir fazer o trabalho dele mesmo já que esta tarefa depende da outra.
- Então… o que vocês estão entregando hoje?
- O Domain Model, todas as classes no lugar. Ta pronto. Só falta testar.

A solução neste caso específico teve que ser meio drástica. O que queríamos fazer era remover todos os Scrum Master e devolvê-los a sua posição original (geralmente gerente de projetos e desenvolvedores sênior) mas vimos que isso ia causar problemas políticos demais. A solução mais viável foi manter os Scrum Masters -pelo menos o título- e usarmos “Gerentes de Iteração”. Iteration Manager é o termo que usamos para um papel equivalente ao Scrum Master –gerente de projetos é outra coisa- e estes caras atuavam como lideres dos times e gerentes de iteração.

Os gerentes de projeto -ainda chamados Scrum Masters por razões históricas- tinham ainda o “plano”, algo em extremo alto nível que dizia que considerando a situação atual de escopo e velocidade a funcionalidade X vai ser entregue dia Y, a Z dia W e assim por diante. Arrastar barrinhas no Microsoft Project não mudava o plano, ele era apenas um retrato da situação real e para mudar a situação real você tem que resolver seus impedimentos. Sem truques.

Outro problema foi o tal do testes. Nós sabemos que desenvolvedores profissionais testam mas neste cliente eles compartilhavam da idéia do Fábio de que testar é coisa pra recurso barato. Resultado? Os recursos caros ficavam dias produzindo código caro que não funcionava. Apos um sprint inteiro de código caro produzido se tinha que reescrever boa parte. Como é aquela história de “o barato sai caro mesmo”?

Nada disso, qualidade é algo muito caro para ser produzido por “recursos baratos”. Como o Jason Yip diz: controle qualidade é responsabilidade do time todo -ele sugere o termo “Inspetor de Qualidade” para o que normalmente chamamos de QA- e para isso os desenvolvedores precisam entrar na dança.

Sendo extremamente sincero, eu não consigo entender como um desenvolvedor experiente assume que uma metodologia ágil consiga funcionar sem testes. Você não tem sequer uma especificação dizendo o que vai construir!

A única maneira que eu vejo disso meio que funcionar é se ao invés de uma metodologia ágil você utilizar apenas mini-waterfalls a cada sprint. Fica um tempo especificando o que vai ser feito, um tempo fazendo, um tempo testando. Enxágüe e repita. Mas isto não é uma metodologia ágil, o ciclo de feedback é muito longo!

E este foi só um dos múltiplos exemplos que tivemos nos últimos dois anos. É preciso ter cuidado, muito cuidado. Scrum vêm crescendo muito como hype e é um framework, cheio de lacunas por definição. Quando alguém com bastante bagagem vê as lacunas no Scrum ele logo assume que basta enfiar o que já se usa em desenvolvimento “tradicional” e acaba criando um híbrido de modelos quase sempre extremante ineficiente.

Scrum não diz como desenvolver software? Sem problemas, nós sabemos fazer isso: escreve uma especificação no wiki, codifica, testa. Scrum não diz como compartilhar conhecimento sobre o código? Sem problemas, nós sabemos como fazer isso: antes do código ser enviado para o SCM ele tem que ser aprovado por um membro mais sênior do time. Scrum não diz como integrar código? Sem problemas: cada um cria seu branch e nós integramos no final do Sprint.

É bom notar que mesmo com as lacunas citadas o framework tem princípios bem definidos. A opinião de que o Scrum Master é o dono do plano vai de encontro com o que o Scrum prega. Pode ser a opinião de alguém experiente, você pode achar que faz sentido… só não pode dizer que isso é Scrum.

E se você soma isso ao fato de que não é preciso muita coisa para ter um certificado em Scrum o problema toma proporções gigantescas. Scrum em si não diz que é errado, digamos, escrever um documento de caso de uso de vinte páginas para cada item de backlog. E se, ainda por cima, a pessoa que sugeriu isso ainda possui um selinho dizendo que ele sabe Scrum?

Se você não tem um time experiente em metodologias ágeis então comece seguindo todas as práticas de XP. Após ganhar experiência decida o que funciona e o que não funciona –mas teste todas antes, e por um tempo considerável.

Não comece apenas por Scrum. Como falei antes você vai encontrar muitos buracos e sempre a solução mais fácil vai ser fazer o que já se fazia antes.

Repetindo um tema freqüente neste blog: eu posso programar FORTRAN em qualquer linguagem. Eu posso gerenciar waterfall e/ou comando-e-controle em qualquer metodologia.

Posted in brasil, comunidade, eventos, gerencia, metodologias, palestras, perolas, testes | 14 Comments »

Não Vai Subir Ninguém!

Tuesday, December 9th, 2008

A coisa mais comum em uma empresa é a formação de uma “tropa de elite”, contendo os principais e provavelmente mais talentosos desenvolvedores. O raciocíno é simples. Empresas em geral são uma bagunça tecnicamente, anos e anos contratando desenvolvedores sem muito critério (e não investindo nos mesmos após contratação) fez com que sejam criados sistemas que não se falam, projetos que atrasam, duplicação de esforço além dos odiosos bugs em produção que te acordam na hora em que eu estou almoçando aqui em Oz.

E é claro que as consequências são desastrosas. Não houve uma só grande empresa onde (ou para quem) eu tenha trabalhado onde não existe a elite da tropa. São aqueles technical stakeholders pessoas para quem você bate continência e tem que agradar. São aquelas pessoas que não estão envolvidas com seu projeto mas ainda assim podem acabar com ele. São parte daquele grupinho que age como a polícia e defende a “moral e bons costumes”, matando a inovação no caminho. São aqueles que estampam seu projeto com o “selo de qualidade”, onde qualidade significa concordar com eles.

Lembranças dolorosas não faltam. Certa vez eu cheguei em um projeto muito perto da ida para o ar. A estrela dentre as funcionalidades era um sistema meio estranho que categorizava conteúdo, mas como eu era novo no time deixei para lá e fui resolver os bugs que impediam o release. Na véspera do release nós percebemos que o sistema “estranho” não aguentava nem um terço dos acessos que teríamos.

O líder de desenvolvimento daquele sistema foi extremamente contra qualquer mudança no mesmo. Ele havia sido desenvolvido de acordo com os critérios passados pelo grupo de arquitetura da empresa e o arquiteto havia solicitado uma solução genérica que pudesse ser reutilizada em todos os mais de 100 produtos da empresa.

Um requisito mais que válido. Reinventar aquilo cem vezes seria um desperdício sem tamanho. Mas o projeto deveria ser entregue em alguns meses e desenvolver aquela funcionalidade “pensando no bem da nação” o fez não só atrasar e custar noites em claro bem como resultou em um sistema que sequer atendia o projeto em questão, muito menos todos os outros 99 sistemas.

O problema é que o arquiteto não fazia parte daquela equipe e não entendia seus requisitos e características. Não estava presente no desenvolvimento, não escreveu uma linha de código, não tinha comprometimento com a entrega.

Não importa o quão bom o time seja, conhecimento técnico só tem valor dentro de um contexto e neste caso o contexto é um time ou um projeto. A falta de comprometimento e de “senso de time” faz com que a “tropa de elite” seja vista mais como uma dificuldade a passar do que algo que traz auxílio. Eu não tenho idéia de quanta vezes tive que adicionar e remover caixinhas em diagramas só para agradar alguém que senta em uma torre de marfim e desce apenas para chicotear os incautos.

E em médio prazo as coisas pioram. Um fato claro é que o grupo se fecha: ninguém dos reles desenvolvedores é bom o suficiente para subir para a elite. Os desenvolvedores com potencial acabam saindo da empresa porque são tão cortados pelo time de elite que desistem e vão tentar ser arquitetos em outro lugar. A falta de abertura, o medo que os desenvolvedores têm dos “caveiras” e a auto-confiança que o grupo desenvolve (afinal eles não têm que passar por avaliação técnica nenhuma, eles são a verdade!) faz com que opiniões se tornem leis.

Recentemente eu tive um caso engraçado. Estávamos introduzindo serviços REST em uma empresa e uma das barreiras era este tipo de time. Eles eram os melhores desenvolvedores da empresa, ditavam as leis e odiavam qualquer coisa que lembrasse processamento remoto. Meu então chefe, um excelente técnico mas com uma capacidade acima do normal de perder a cabeça, e eu marcamos uma reunião com este time para apresentar a idéia.

Durante a semana anterior eu fiquei polindo slides e buscando referências para responder qualquer dúvida técnica. No dia da reunião eu estava extremamente nervoso e após 15 minutos de atraso meu chefe saiu da sala para ver porque os arquitetos não haviam chegado ainda. Eu aproveitei os minutinhos para dar uma última revisão quando comecei a ouvir gritos do lado de fora. Ao sair dei de cara com meu chefe e o arquiteto sênior discutindo calorosamente a questão dos serviços.

O arquiteto master argumentava que eles já tentaram EJB e deu errado, já tentaram WS/SOAP e deu errado e que ninguém vai usar mais serviço nenhum. Isso não funciona nesta empresa, já vimos isso e ponto final. Vendo que aquilo não ia ajudar muito eu puxei meu chefe pelo braço e voltamos para o escritório.

Não havia como desistir da tecnologia nem do projeto, então marcamos uma segunda reunião. Desta vez eu mudei todos os slides e fiz questão de não convidar meu chefe. Eu removi todos os slides que falavam de REST e a palavra “serviço”, deixei apenas o HTTP. A reunião foi ótima, o sistema estava abençoado pelo arquiteto master e podíamos seguir em frente. Qual o valor que estas duas reuniões e duas semanas de trabalho trouxeram? Elas alimentaram o ego do arquiteto, ele realmente acreditou que nós mudamos a arquitetura para o agradar. Só isso.

Este tipo de barreira cria medo entre os desenvolvedores. Ainda que você tenha uma excelente idéia para aquele seu projeto vai ter que justificar para aquela pessoa que não quer nada além de arrumar algo que justiique seu cargo. A inovação morre em meio ao medo de propôr algo e ser rechaçado.

É impressionante como este padrão de organização departamental lembra a história da humanidade. Um grupo é oprimido por um governo corrupto e injusto. O grupo é exilado (i.e. pede demissão) une forças, volta e derruba o governo. No próximo passo o grupo forma seu próprio governo, corrupto e injusto como o anterior.

Mas o que fazer? Como falei no início, as empresas são uma zona! É comum que a cada 100, 200 desenvolvedores tenhamos meia dúzia que está acima da média. A solução me parece óbvia: não concentre, distribua.

Se você tem poucos bons desenvolvedores não faz o menor sentido agrupá-los, pelo contrário! Espalhe os desenvolvedores bons entre os times e certifique-se que eles possuem autoridade suficiente para mudar as coisas. Treine seus desenvolvedores como coaches e os faça ocupar o papel de líder técnico em projetos. Crie um programa de mentoria de desenvolvedores e faça com que seus jovens talentos tenham como referencial os melhores.

E como controlar este tipo de atividade por toda a empresa? Crie comunidades de prática. Ao invés de um “departamento” de arquitetura ou de “práticas de desenvolvimento” crie uma comunidade que abrange diversos departamentos e times. Em vê de investir um bolo de dinheiro em um grupo de pessoas invista um pouquinho em cada um dos seus times, deixe eles realizarem atividades para melhorar suas habilidade durante o expediente. Em vez de criar xerifes e a cultura do medo crie uma cultura de melhoria contínua, remova as maçãs podres da sua empresa e crie mecanismos para acompanhar o desenvolvimento de todos os membros do time.

Posted in arquitetura, gerencia, metodologias | 38 Comments »

Deixa Para os Analistas de Verdade…

Sunday, November 23rd, 2008

Eu irritei bastante gente da última vez que falei sobre analistas de sistemas. Até hoje, 10 meses depois, ainda tem gente que me manda e-mail malcriado.

Muitos destes comentários falavam que eu estou desmerecendo o valor da análise. Minha resposta é que pelo contrario, o que eu estou dizendo é que análise é tão importante que não dá para misturar as coisas:

É certo que muitos clientes precisam entender seus próprios negócios antes de criar um sistema mas isso não é papel de analista de sistemas, é papel de analista de negócios. Um analista deste tipo possui capacitação em campos bem diferentes, é completamente possível que um analista de negócios seja um desenvolvedor (vamos abolir o “analista de sistemas” a partir daqui) mas neste caso ele está assumindo duas especialidades. Um analista de negócios possui um perfil não-técnico e mais especializado em um mercado como bancos, marketing, telecomunicações e etc.

Como eu falo no post citado, o problema é que pensamos que análise faz parte da profissão de desenvolvedor ou que é sua evolução. Isto não é verdade, o trabalho de analista de negócios pode resultar em algo que nem é um programa de computador. Em um caso recente o cliente queria um novo website para “automatizar processo” mas após a análise verificou-se que o que ele precisava era simplesmente melhorar seu formulário -de papel.

Eu realmente não entendo como pessoas conseguem misturar Test-Driven Development, Domain-Driven Design, metodologias ágeis e técnicas de análise de negócios em workshops de um dia.

Estou tendo a felicidade de ver um processo de ponta a ponta na pratica neste instante, participando de uma Inception, uma fase bem curta onde tentamos entender o que estamos fazendo. O projeto em si não começou, estamos apenas estabelecendo uma visão e pensando sobre a viabilidade do sistema.

O processo, segundo a metodologia que desenvolvemos na ThoughtWorks, é composto por diferentes workshops com quase todos os envolvidos do lado do cliente.

A atual equipe é composta por:

Facilitador: Alguém que conduz as atividades e mantêm o time nos objetivos. Não possui uma habilidade específica alem de “facilitação de colaboração”. No meu projeto atual o papel é executado por uma analista de negócios mas eu já vi testadores, desenvolvedores e gerentes de projeto executando esta tarefa.
Stakeholders + Analistas de negócios: Funcionários do cliente de diversas áreas envolidas e os nossos analistas que trabalham com eles.
Líder Técnico: Um profissional técnico com senioridade suficiente para responder às dúvidas que surgirem.

Note que existe algo engraçado aí: parece um time ágil ao contrário. Ao invés de cliente presente nós temos o técnico presente. Eles realizam o trabalho de definir o que o sistema vai ser, eu só estou lá para dizer o que faz ou não sentido tecnicamente. Em um mundo ideal teríamos todo o time técnico presente (considerando que um time ágil não é nunca grande), mas como somos uma consultoria e cobramos por tempo o cliente quer, obviamente, minimizar custos em um projeto que ele ainda nem sabe se vai construir.

A Inception é muito curta. Ela precisa ser curta porque, já que não pretende entregar nada alem de uma visão geral do projeto, o desperdício precisa ser minimizado. As pessoas mais experientes dizem que nenhum projeto ágil pode ter mais de duas semanas de Inception.

As entregas são freqüentes, temos um showcase por semana (i.e. 2 no total) onde são apresentados aos stakeholders que não participam dos workshops (geralmente a alta gerencia) o que desenvolvemos naquele período: definições sobre o que o projeto é e o que ele não é. Como a maioria dos processos ágeis nós usamos ferramentas de baixa tecnologia como post-its e cartões, estes são fotografados e/ou convertidos em slides.

A entrega final depende do cliente. Em geral nós sempre temos uma lista com as histórias identificadas nestas duas semanas e suas estimativas de alto nível, formando um backlog inicial para o projeto começar. Também temos o que alguns poderiam chamar de project charter, mas ao invés de páginas e páginas de documentos temos um deck de slides com basicamente a consolidação dos dois showcases.

E qual o papel do tal analista de negócios nisso tudo? Eles trabalham junto com os stakeholders para gerar uma visão única do projeto (já que possivelmente cada stakeholder que uma coisa diferente) e transformar isso em algo que possa ser executado (histórias). No meio do caminho eles ajudam a eliminar desperdício, introduzir idéias novas, validar os pedidos, conferir viabilidade e tudo mais que não faz parte do papel de um desenvolvedor e sim de alguém que, de fato, entenda do negócio do cliente.

Desde quando trabalhávamos juntos que eu converso bastante com o Antônio Carlos sobre este tipo de coisa. No nosso ambiente nós tínhamos clientes que não sabiam o que queriam e desenvolvedores que não entendem do negócio. O resultado final era que nada que ia pro ar era exatamente o que o cliente queria, seja por falha de comunicação ou porque ele mudou de idéia e “esqueceu” de avisar aos desenvolvedores.

Note que o papel do analista de negócios não elimina a necessidade de termos um cliente presente. Não existe mapeamento de requisitos ou coisas do tipo, além de usar seu expertise naquele domínio em específico, o analista de negócios age como facilitador e não como ponte entre cliente e desenvolvedores. Ele também não é um tradutor, os termos de negocio e os processos devem ser entendidos por todos os envolvidos. Após a Inception o cliente não fica de fora do projeto, só voltando para colher os frutos. Ele faz parte da equipe o tempo todo, um analista de negócios, por melhor que seja, nunca substitui seu valor.

Esta fase do processo também responde a uma eterna discussão o fato de que XP (que é a metodologia-base usada na ThoughtWorks) não tem “foco em negócios”. Nem é para ter! XP ou qualquer metodologia ágil que se preze vai focar em pontos específicos. XP não atende a todo o ciclo de vida do projeto, ele faz parte do ciclo de vida. Quando a Inception acaba começa a Iteração 0 e daí o XP entra em ação.

Update: O Guardian, que passou pelo processo descrito aqui, tem um post bem legal sobre o assunto.

Posted in comunidade, gerencia, metodologias, negocios, thoughtworks | 10 Comments »

Apresentação no FalandoEmAgile

Wednesday, October 29th, 2008

O evento foi sensacional. Tirando algumas coisas bem… interessantes… todas as apresentações tiveram um nível excelente.

Apos ficar bufando por meia-hora no palco e dar mais motivos para a minha esposa reclamar da minha falte de exercício físico eu acho que a minha apresentação foi razoável. Eu ainda estou respondendo e-mails que recebi com relação à alguns pontos tocados, pelo visto valem uma série de posts.

Foi também minha primeira experiência com apresentações sofisticadas no Keynote. Um dos problemas deste tipo de coisa é que a versão em PDF fica horrível. De qualquer forma, aí está:

A Maldição da Fábrica de Software Ágil

View SlideShare presentation or Upload your own. (tags: falandoemagile agile)

A Caelum está mais que de parabéns.

Posted in brasil, comunidade, eventos, gerencia, metodologias, palestras | 11 Comments »

Domain-Driven Design & Agile: Fechando Malas

Wednesday, October 8th, 2008

Como falei algumas dezenas de vezes estou no fim de um projeto, na verdade na minha última semana neste instante. Foi um projeto muito interessante onde pudemos aplicar diversas técnicas como Domain-Specific Languages para testes e promoção de testes de aceitação. Também foi o primeiro projeto Java sem container que participei desde 2006, apenas PicoContainer, Hibernate, JMX e um cliente JMS -sem mesmo interface de usuário.

Outro ponto interessante sobre este projeto é que foi uma reescrita de um sistema com o qual estive envolvido antes. O cliente está passando por um programa que compreende diversos projetos e muitas fases. Há alguns meses nós fomos chamados para entregar, em algumas poucas semanas, uma versão deste sistema. Na nova fase do projeto eles resolveram investir mais na qualidade deste e tivemos uns bons 3 meses para reescrever tudo. Não só o sistema foi completamente reescrito bem como teve um time diferente (no anterior erámos eu e um colega ThoughtWorker, no atual somos 5 pares entre TWers, empregados do cliente e outros terceirizados).

O problema agora é a pressa. Não, o projeto não está com pressa, nossa entrega é em uma semana e faltam poucos cartões na parede. Eu que estou. Estou saindo deste projeto com muita coisa que eu queria fazer ainda meio-acabada e nesta última semana estou me dedicando basicamente a criar tracing bullets para o desenvolvimento futuro já que quem toma conta do sistema a partir da entrega de 15/10 é o cliente. Não é fácil com tão pouco tempo.

E esta lenga-lenga foi um mea-culpa para maiores informações sobre minha viagem ao Brasil. O press-release ficou assim:

Dia 23 e 24 de outubro ocorre em São Paulo o primeiro grande evento de Agile do Brasil:
http://www.falandoEmAgile.com.br/

Ouça as histórias de empresas que tem obtido sucesso com Scrum, entenda como estas práticas podem ser implantadas em ambientes tradicionais de projetos, veja o que a indústria tem falado e feito com Agile e descubra quais serão os próximos passos a serem dados nesse mundo. Conta com o palestrante internacional David Anderson, reconhecido líder na comunidade Ágil e autor do livro “Agile Management for Software Engineering”, e com o primeiro Certified Scrum Trainer da Scrum Alliance da América Latina, Alexandre Magno. De tópicos de Scrum e CMMI até estudos de caso com Agile na Austália, Inglaterra, Estados Unidos e Brasil.

Ocorrerão mais outros eventos próximos a essas datas:

O Zen of Agile, nos dias 21 e 22, um workshop com David Anderson:
http://www.heptagon.com.br/ws-zen-agile-mgmt

O Certified ScrumMaster, dias 27 e 28 de outubro:
http://www.caelum.com.br/treinamentos/csm-certified-scrum-master/

E por três vezes Phillip Calçado, conhecido aqui no GUJ, ministrará um workshop de Domain Driven Design de 8 horas, dia 21 de outubro no Rio de Janeiro, e dias 27 e 28 em São Paulo:
http://www.caelum.com.br/treinamentos/ws-46-domain-driven-design/
http://philcalcado.com/2008/09/01/brazilian…em-agile-domain-driven-design/

Está sendo divertido montar este workshop. É algo estranho porque é maior que uma palestra e menor que um curso -ao mesmo tempo é tempo demais e tempo de menos. Eu quero começar desmistificando alguns conceitos sobre objetos, trabalhando a idéia das decisões em três níveis e só depois entrar em Domain-Driven Design. É impressionante como fica mais claro falar sobre DDD depois de quebrar mitos, numa palestra nunca se tem tempo de fazer isso.

Como falei antes, para maiores informações basta ligar para a Caelum do Rio ou São Paulo.

E com a confirmação das datas eu muito provavelmente vou estar também no último dia do Rails Summit.

Posted in brasil, cursos, domain.driven.design, domain.specific.languages, engenharia, eventos, fragmental, philcalcado.com, java, metodologias, orientacao.a.objetos, palestras, plataformas, programando, rio | 7 Comments »

Festa Retardatária

Wednesday, September 24th, 2008

Em 2003 eu liguei para o escritório da ImproveIT e falei com o Vinicius Telles. Ele certamente não se lembra disso. Perguntei sobre os cursos da empresa em XP, datas e preços. O que o Vinicius me falou na ocasião foi que não havia muita demanda para este tipo de curso e que por isso eles eram oferecidos muito esporadicamente ou apenas para empresas em turmas fechadas. Como eu falei que possuía um pequeno time e um orçamento de tamanho semelhante ele sugeriu que eu comprasse alguns livros e usasse listas de discussão.

Se eu precisasse de algo semelhante no Brasil hoje, não teria este problema. Não este, ao menos. O meu maior problema seria encontrar, no meio do mar de ofertas, quem contratar.

Apesar de estar relativamente afastado da comunidade brasileira –o que pode ser percebido pela falta de atualizações freqüentes aqui- eu acompanho listas e fóruns e pude ver como as coisas mudaram nos últimos meses. Listas de discussão sobre métodos ágeis foram invadidas por ofertas de treinamentos, cursos, coaching e mentoring. Algumas listas que eram bem interessantes viraram apenas um veículo para a divulgação de serviços.

E como aferir as credenciais dos prestadores de serviço? Boa pergunta. Algumas desta pessoas, segundo meu histórico do Gmail, estavam oferecendo cursos de levantamento de requisitos no melhor estilo waterfall há alguns meses. Outros possuem treinamentos cujo programa é apenas uma xerox do Certified Scrum Máster –se o treinamento de SCM original já possui valor real muito baixo imagina quando o mesmo conteúdo é ministrado por alguém que não possui a experiÊncia habitual dos CST.

Outros dizem que já trabalharam para 50,60…100 empresas com metodologias ágeis. Estes são meus favoritos. Supondo que o sujeito tenho começado a trabalhar com metodologias ágeis em 2001 -quando o Agile Manifesto foi assinado- e já passou em 50 empresas, ele teria passado apenas um mês em cada empresa, na média. Além do fato de que eu duvido que estes pratiquem técnicas ágeis desde 2001, em minha vida eu vi poucos projetos de apenas um mês que tenham sido relevância para o currículo de alguém. Como previsto, os agilistas retardatários estão em todo lugar, cuidado.

Existe um trecho do Phillip Krutchen no seu livro de RUP que eu acho que se aplica com perfeição para algumas coisas que eu tenho visto por aí:

A Major Misconception

Although the four phases of a RUP project (Inception, Elaboration, Construction, and Transition) are run sequentially, remember at all times that the RUP lifecycle is fundamentally iterative and risk-driven. There is a big misconception that we would like to push aside very early in our discussion: The various phases are not simply a renaming (to sound fancy or different) of the classical phases of a waterfall process. From practitioners making their first acquaintance with the RUP, we have frequently heard, “Oh, I get it! In Inception you do all the requirements, in Elaboration you do the high-level design, in Construction you write the code, and you finish the testing in Transition.”

In trying to match the RUP to their current practice, they completely miss the point of iterative development. Yes, in the early weeks or months of a project the emphasis is very likely to be more on requirements and during the final weeks or months to be more on testing and polishing. This change in focus across the lifecycle is precisely what is hinted at by the “humps” on the lifecycle iteration graph (see Figure 1.3); the height of the humps varies across the cycle. But inside each phase, you plan iterations (see how in Chapter 12), and each of these iterations includes many of the software development activities to produce tested code as an internal—and later external—release.

Muitas das pessoas que hoje oferecem serviços em métodos ágeis foram exatamente as mesmas pessoas que criaram toda a confusão sobre fases no RUP. Substituindo iterative por agile (que egloba desenvolvimento iterativo) em “In trying to match the RUP to their current practice, they completely miss the point of iterative development” vai ter exatamente o cenário atual.

Um exemplo disto é a forma como alumas pessoas tentam transformar XP em algo mítico e irreal. Em discussões recentes eu vi gente taxando o XP como inferior à coisas como Scrum porque ele “visão de negócios” ou “focada em engenharia”. Mas heim?

A parte da “engenharia” é engraçada. XP é uma metodologia para desenvolvimento de software e como de se esperar ela possui praticas que estão ligadas com… er… desenvolvimento de software!

E a paixão pelo Scrum é algo fantástico. Uma busca por “Scrum framework” no meu Gmail traz milhares de emails de listas de discussão. As pessoas adoram Scrum porque é um “framework para processo”. Muito flexível, muito pratico e te deixa adotar suas praticas de engenharia favoritas. O Scrum pode ser extremamente formal ou informal.

Uhm… onde é que eu vi isso antes?

The RUP is also a process product that provides you with a customizable process framework for software engineering. You can configure the RUP product to support small or large teams and disciplined or less-formal approaches to development. It also allows you to add your own best practices and to share experiences and artifacts with peers and experts.

O que talvez muita gente não perceba é que há sempre um jogo de compensação em metodologias ágeis. Os valores definidos no Manifesto Ágil não são facilmente atingíveis e as praticas do XP são uma forma (não necessariamente melhor ou pior) de atingi-los. Obviamente você consegue atingir os valores através de praticas diferentes mas o que eu vejo é a maioria das pessoas usando as mesmas praticas que já usavam antes, talvez com cartões ao invés de documentos Word, e esperando que seja diferente do passado.

Misturar praticas é algo sadio quando feito por alguém que entende como estas se relacionam, mas a maioria das pessoas apenas está jogando as que não entendem ou são difíceis de vender. Eu já estive em diversas empresas brasileiras onde “ágil” significava colocar cartões na parede e ficar em pé meia hora todo dia de manhã.

Mas o que eu quero dizer, que você não deve contratar pessoas para ajudar sua empresa a adotar método ágeis? De jeito nenhum. Apesar de não prestar serviços no mercado brasileiro meu trabalho consiste exatamente nisso, seria bem estranho eu advogar contra. Este texto é apenas um desabafo e um alerta.

Um alerta porque através de amigos e colegas eu já estou vendo muitas empresas jogando dinheiro fora com treinamento, consultoria e mentoring sendo prestados por pessoas que possuem pouca ou nenhuma experiência a mais que os próprios alunos.

Desabafo porque acho que finalmente entendi porque a ImproveIT saiu do mercado de consultoria e coaching.

Posted in brasil, comunidade, gerencia, metodologias, negocios | 13 Comments »

Brazilian Tour 2008: Falando em Agile, Domain-Driven Design

Monday, September 1st, 2008

Outubro vai ser um mês bem interessante. Vou entregar um dos meus projetos mais importantes até agora (pelo menos é o que nossas previsões dizem) e vou passar 15 dias entre férias e eventos no Brasil.

O motivo principal é para realizar uma apresentação no Falando em Agile 2008, mais um evento da Caelum. As inscrições estão abertas e inscrevendo-se com antecedência você consegue desconto.

Minha palestra vai ser sobre um tema que venho desenvolvendo há algum tempo: como adoções ágeis que tinham tudo para dar certo afundam. Antes de entrar para a ThoughtWorks eu já tinha vivido esta situação pelo menos duas vezes, nestes nove meses trabalhando numa grande consultoria especializada eu já vi umas três. Todas tinham um grupo de sintomas bem parecidos o quais estou tentando estruturar. Não é lá muito fácil mas acho que o resultado tende a ser bom. Se você acha que Vovô viu a uva, a web somos nozes, arquitetura BOLOVO e amigos foram piadas infames e de mau-gosto mal podem esperar pela temática desta apresentação…

Uma das coisas mais interessantes sobre o FalandoEmAgile 2008 para mim vai ser a presença do Danilo Bardusco na grade. O Danilo foi meu gerente na Globo.com antes de assumir tudo-menos-webmedia, quando passei a responder diretamente ao Antônio Carlos. Naquele momento a empresa viva diversas histórias tristes com métodos baseados em Waterfall, micro-management e consultorias CMMI 5; apesar dele não acreditar que aquilo ia dar certo no início foi sua perseverança e abertura à inovação que possibilitou aquele trabalho inicial que hoje, graças ao trabalho de todos, é referencia. O grande defeito dele é aquela mania infeliz de usar Vi quando todo mundo sabe que emacs é o único editor de texto que deveria ser utilizado. Mas eu perdôo.

Como falei, são 15 dias no Brasil. Eu ainda não sei as datas do que vou fazer mas devo ter algumas outras apresentações de palestras no Rio (certamente no RioJUG) e em São Paulo.

Como eu já estava vindo para o Brasil, acabei fechando com a Caelum uma série de oficinas em Domain-Driven Design. A idéia é cobrir os principais aspectos desta filosofia de design de uma maneira descontraída mas substancial. O primeiro post que menciona Domain-Driven Design neste blog é de 2005, e foi importado do meu antigo blog no blogger.com. Nesta época quase ninguém havia ouvido falar do conceito. Hoje ainda é algo relativamente obscuro mas um pouco mais popular. Claro que com a popularidade vem os problemas. Muita gente no GUJ, em blogs e outros fóruns está simplesmente associando Domain-Driven Design com um bom design Orientado a Objetos, ou pior ainda: com qualquer design OO.

Ao contrario do recente mito popular, Domain-Driven Design não é “voltar para Orientação a Objetos”. Orientação a Objetos foi criada como uma maneira de gerenciar dependências e criar unidades coesas e atômicas de código, não necessariamente uma forma de modelar uma Camada de Negócios. O que Domain-Driven-Design traz de volta é a possibilidade de utilizar as vantagens da Orientação a Objetos para criamos um modelo que reflita o mundo real de maneira mais íntima. Você não precisa sequer de objetos para aplicar o coração de Domain-Driven Design, ou mesmo seus Patterns.

A parte do “substancial” que falei acima é exatamente esta: não misturar Orientação a Objetos com Domain-Driven Design e sim trabalhar a relação entre eles. A parte “descontraída” é na forma de passar este conhecimento. Após alguns anos ministrando treinamentos eu não tenho a fórmula ideal para passar este tipo de conteúdo (altamente abstrato e que requer conhecimento posterior) mas eu já aprendi por tentativa e erro diversas formas em que isso não dá certo –pelo menos não comigo. Duas delas são: aulas expositivas e laboratórios. Se você não entende porque aulas expositivas não servem para este tipo de coisa pense sobre todo o conteúdo que é quase que literalmente jogado em cima de alguém numa faculdade e quanto dele é entendido (e entender não é tirar 10 na prova). O problema de laboratórios é que sempre perde-se tempo com a máquina, ou a linguagem (este não é um workshop Java ou Ruby ou C#, é um workshop sobre objetos).

Eu não tenho as datas nem preços (já encheu o saco da Caelum hoje?) mas vamos ter sessões em outubro no Rio e São Paulo, a preços acessíveis.

Posted in arquitetura, brasil, comunidade, domain.driven.design, engenharia, gerencia, guj, metodologias, orientacao.a.objetos, plataformas, programando, rio, riojug, testes | 12 Comments »

Analista Pedreiro

Saturday, August 9th, 2008

Meu post sobre Análise de Sistemas já teve 65 comentários (incluindo respostas, é claro). Acho que já descartei uns 20 comentários anônimos para este. Nem todos falavam da minha mãe, alguns tinham coisas interessantes mas infelizmente este blog não aprova comentários anônimos, sejam criticas interessantes ou xingamentos.

Esta manhã eu recebi um destes anônimos interessantes e, apesar de não o aprovar, gostaria de comentar trecho deste:

Francamente modelar com o código é o mesmo que fazer um projeto de uma casa com tijolo e cimento.

Este trecho me despertou o interesse porque há algum tempo fiz um experimento e gostaria de convidar vocês para repeti-lo. Como falei em posts anteriores Melbourne, minha cidade atual, é um lugar razoavelmente conhecido por suas boas universidades e centros de pesquisa. Como conheço alguns estudantes de graduação ou recém-formados (A ThoughtWorks possui um programa para contratar graduandos) eu conheci algumas pessoas que lecionam em universidade locais, entre eles uma simpática senhora que ensina disciplinas num curso de arquitetura e edificações local.

O dialogo foi sobre especificações, plantas e modelos.

- Imagine que a senhora pudesse, ao invés de criar um modelo em papel, construir seu projeto incrementalmente. Em dois dias a senhora tem o banheiro pronto, em três dias a varanda.
- Como numa maquete?
- Não, eles estão prontos mesmo. Você pode usar o banheiro, pode dormir no quarto, pode efetivamente utilizar o prédio.
- Mas e se eu precisar mudar algo? Isso iria ficar muito caro.
- Imagine que o custo é apenas o de dois dias de trabalho. Sem custo material. A cada dois dias você termina um pedaço da casa e mudar é tão simples quanto construir.
- Ok. Seria ótimo. Qual seu ponto?
- Isso ainda afaria requerer uma planta baixa, um modelo em papel ou AutoCAD?
- Precisaria porque eu preciso comunicar o projeto aos trabalhadores.
- Ah, sim, claro, mas imagina que construir não seja um trabalho braçal. Você tem, sei lá, robôs que sobem paredes e fazem o trabalho pesado, você só diz qual a dimensão, inclinação, que material, etc. e eles constroem. Você desenha no AutoCAD e os Robôs constroem imediatamente, daí você pode entrar no prédio e se tem algo errado em segundos você conserta. Você pode levar seu cliente para andar no prédio.
- Ok. Mas neste caso você não está eliminando o modelo gráfico.
- Não?
- Não, neste caso você automatizou a construção. O que você fez foi fazer com que o trabalho do arquiteto seja simplificado eliminando o custo da construção. Se qualquer coisa que eu mudar no modelo muda no prédio real imediatamente e sem custo o papel do modelo é ainda mais importante. Você não tem real diferença entre modelo e prédio. Você não tem transformação real entre um e outro. O modelo é o prédio.

Deste ponto eu comecei a explicar para ela como engenharia de software funciona. A conclusão que nós chegamos é que engenheiros de software possuem o poder que falta para engenheiros civis/arquitetos e ainda assim usam as ferramentas de quem não tem este poder.

Arquitetos adorariam modelar com tijolos, paredes e coisas reais. Eles não podem. Nós podemos.

Posted in arquitetura, metodologias | 41 Comments »

Patterns de Adoção Ágil

Sunday, August 3rd, 2008

Uma pergunta frequente é: Como eu introduzo Agilidade na minha empresa?

Recentemente eu fiz uma revisão do Agile Adoption Patterns. Este livro é fantástico para você conhecer diversas técnicas e seus impactos. Mais importante ainda: sem ficar preso à uma metodologia de caixinha.

Posted in gerencia, livros, metodologias | No Comments »

Uh-Éme-Éle

Friday, July 25th, 2008

Este tópico no GUJ chamou atenção, especialmente porque o li logo após um interessante texto noblog do Marcelo Araújo sobre uma outra faceta do mesmo tema: modelagem usando especificações não executáveis.

O que eu quero dizer com isso? Dada a tecnologia atual na maioria das empresas (desconsiderando o uso de coisas como DSLs ou mesmo alguma solução MDSD que, ao contrario de MDA, funcione) todos os documentos comumente utilizados para “modelagem” não são verificáveis, não são executáveis e requerem um trabalho manual enorme. Como bem disse o Emerson Macedo no post, você acaba programando duas vezes, uma na sua notação gráfica (UML) e uma na sua notação executável (Java, C#, Ruby… o que for).

Acontece que ao passar do diagrama (e diagramas aceitam qualquer besteira) para o código (onde o compilador e testes unitários são muito exigentes – fora os usuários) o tal do pseudo-modelo criado pelo “analista” no Rational Rose (porque a empresa não percebeu que o Rose foi descontinuado há anos) é completamente diferente do modelo implementado. As classes até têm o mesmo nome mas a mecânica interna é bem diferente. E por quê? Porque UML não vai te oferecer tudo o necessário para modelar. O mínimo que se espera de um modelo de um sistema é que ele seja verificável para saber se cumpre seus requisitos. Como é que eu vou saber isso com UML? Como eu testo UML?

Há algum tempo que eu me pergunto porque que se usa UML para “modelar”. Não me entenda mal, UML é uma ótima noção gráfica para Orientação a Objetos e com ela você consegue passar uma big picture muitas vezes mais rapidamente do que código; mas ela fica por aí: comunicação.

Quando modelamos o comportamento de objetos nós estamos descrevendo como este se comporta em diversas situações. Ao modelar uma determinada atividade você precisa descrever um conjunto grande de detalhes sobre esta, e UML não esta pronta para este tipo de coisa - e nem é a idéia por trás dela. Se modelar em UML fosse eficiente nós estaríamos programando em UML não em C#, Java ou o que for.

O primeiro problema ao tentar introduzir este pensamento na indústria é: mas eu não posso deixar que meus “implementadores” façam o que quiserem. Pergunta: o que raios é um implementador? Um datilografo de luxo?

Supondo que sua empresa seja a típica empresa de três letrinhas, aquelas que contratam qualquer um como “programador júnior” porque ele vai receber instruções do analista. Neste cenário eu pergunto: para que o tal programador? Que tal dar ao seu “analista” uma ferramenta mágica em que ele consiga criar um modelo abstrato e ao mesmo tempo executável? Que tal se ao invés de gastar rios de dinheiro pagando 10-reais-mais-o-busão para seus implementadores você eliminasse completamente a necessidade deles, fazendo com que o “analista” sozinho cuide do serviço?

Não precisa sacar seus milhões do banco nem pensar em como justificar o gasto com esta ferramenta no orçamento, você muito provavelmente já possui o necessário dentro da sua empresa: uma linguagem de programação decente. Faça seu “analista” usar código para expressar a modelagem. No final dá no mesmo para o nível de modelagem desejada e você ainda ganha algo verificável e executável. Economia de rios de dinheiro quase que instantânea.

Mas como assim? O “modelo lógico” é muito diferente do “modelo físico” e o “analista” não pode perder tempo com essas coisinhas de tecnologia, tem que pensar em modelar o negocio. Muito bem, duas coisas:

Analista de Sistemas não é analista de negócios. Se você não sabe o que é um analista de negócios eu recomendo que você mande um e-mail pro Paulo Vasconcellos perguntando.
Há mais de cinco anos que não há quase nenhum motivo para que uma aplicação Java ou C# não seja uma cópia de 1-para-1 de um modelo UML do tipo “diagrama de domínio”. POJO/POCO, Hibernate, IoC, Camadas, OO, AOP, EJB3, MVC… toda essa parafernália de letrinhas permite que seus objetos de negocio não tenham o menor traço de infra-estrutura. Claro que alguém vai ter que fazer a infra-estrutura –ainda que seja mínima. Caso seus “analistas” sejam de qualidade extremamente baixa eu recomendo que você contrate um bom técnico para atuar como arquiteto e líder técnico do time.

Verdade seja dita: esta não é a primeira vez que este blog trata do tema e desde a última vez muita coisa melhorou, mas ainda há muito que melhorar.

Posted in arquitetura, comunidade, engenharia, metodologias, plataformas, programando, testes | 26 Comments »

Fragmental