gerencia « Fragmental

Archive for the ‘gerencia’ Category

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 »

Rastreabilidade em User Stories

Friday, July 18th, 2008

Pergunta na XP-Rio:

Me ajudem no seguinte, no processo unificado, espera-se que todos os casos de uso gerem algum tipo de artefato dentro do projeto. Na verdade, com os casos de uso espera-se chegar em classes que juntas formarão o sistema. Dentro da metodologia existe artefatos que quando feitos, permitem mapear todos os artefatos gerados a partir de um caso de uso. A matriz de rastreabilidade.

Gostaria de saber como o XP permite chegar as classes (código) a partir das User Stories. Por exemplo, dado uma User Stories, quais são as classes geradas para atender essa User Stories?

O XP permite isso? Como é feito?

Provavelmente a primeira coisa a se perguntar é: por que eu precisaria deste dados? Alguns modelos de processo como CMMI definem rastreabilidade, que geralmente é definida nesta linha:

Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases.)

- Gotel O.C.Z and Finklestein A.C.W (tirado da Wikipedia)

A necessidade parece justa e real, é preciso saber quais partes do software são afetadas por mudanças no negocio e vice-versa. O grande problema desta métrica é que transformações de modelo não são mais tão drásticas há algumas décadas. Ao utilizar qualquer tecnologia relativamente comum (Java, Ruby, .Net, Python, JavaScript…) não existe motivo técnico para que o software não modele o negocio em uma relação próxima de 1-para-1, desta forma saber qual parte de um código realiza qual tarefa torna-se bem simples.

Outro problema é que eu nunca vi um artefato de rastreabilidade, seja qual for, que não ficasse defasado. Se você abraça uma metodologia ágil sabe que refactoring faz parte da vida.

Mesmo com todos os problemas que esta métrica possui eu entendo que existem casos onde seu uso se faz necessário –especialmente por equipes tentando introduzir agilidade em ambientes tradicionais. Supondo que exista uma necessidade justificável para algum controle deste tipo, metodologias ágeis em geral possuem um mecanismo muito mais eficiente que documentos ou mesmos sistemas: testes.

Toda história, todo cartão, deve ter um critério de aceite. O critério de aceite traz o que o cliente considera ser o mínimo para que a história seja considerada concluída. Por exemplo:

História: Como administrador eu quero criar um novo grupo para que possa aplicar permissões à diversos usuários de uma só vez.
Critérios de Aceite:

O novo grupo criado deve possuir o usuário que o criou como seu administrador

O novo grupo não deve conter outros membros

O novo grupo não deve ser visível na listagem de grupos

Cada um destes critérios via um teste unitário e/ou funcional que é executado como parte da integração contínua. Para saber exatamente quais classes e códigos são afetados por cada um deles é simples: use uma ferramenta de test coverage como o Emma e execute apenas os testes de aceitação para aquele cartão. A ferramenta irá gerar relatórios como estes:

[class, %]	[method, %]	[block, %]	[line, %]	[name]
25%  (1/4)!	25%  (3/12)!	40%  (3012/7446)!	25%  (3/12)!	com.sun.tools.javac.v8.resources
94%  (16/17)!	49%  (41/83)!	48%  (1111/2292)!	45%  (201.1/450)!	com.sun.tools.javac.v8
88%  (45/51)!	61%  (242/397)!	54%  (3070/5729)!	52%  (809.6/1563)!	com.sun.tools.javac.v8.tree

Classes que possuem alguma cobertura foram afetadas pelo teste, logo são parte da execução daquela história. Não é difícil escrever um script que –talvez como parte do build- processe estes relatórios e gere o artefato de rastreabilidade que seu processo te obrigar a fazer. Melhor ainda: este artefato nunca estará desatualizado.

Só não se esqueça que melhoria contínua é um conceito importante. Se o artefato de rastreabilidade é algo tão ineficiente a obrigação de um desenvolvedor que perceba isto é mostrar para sua organização que o valor desta pratica é nulo. Não se acomode.

Posted in comunidade, gerencia, metodologias, programando, testes, você.pergunta | 14 Comments »

User Stories: Não Crie Godzillas!

Thursday, July 10th, 2008

Hoje de manhã eu acabei iniciando um debate interessante com o Antônio Carlos via twitter. Tudo começou quando o Fernando Meyer postou uma foto dos cartões que ele usa para planning poker. O meu primeiro comentário foi sobre as cartas com valores exorbitantes como 40 e 100.

Qual o problema destes valores?

Eles são um sintoma de um problema. São um bad smell. Dado que toda história tem algum valor para o usuário do sistema, como alguém pode ter no mesmo sistema, na mesma iteração, duas histórias que valem 2 e 100? Existem tarefas que realmente envolvem tão pouco esforço que o numero é baixo. Mudar um texto para itálico, por exemplo, mas se isso é um dois o que seria tão grande a ponto de ser (40/2 =) 20 vezes mais trabalhoso e ainda assim ser considerado uma história?

Possibilidades:

Histórias mal formuladas: O analista de negocio cria histórias que não possuem valor nenhum e/ou histórias que não são atômicas.
Incerteza: Os desenvolvedores fazendo a estimativa de tamanho da história não tem idéia de como fazer aquilo e chutam o tamanho para o alto, o mais alto que conseguirem.

O primeiro problema é muito comum –tem um post nos rascunhos sobre minhas experiências recentes com este. Analistas –especialmente os com experiência em desenvolvimento- tendem a pensar em tarefas que são decomposições funcionais e não partições verticais dos sistemas. Invés de pensas no ponta-a-ponta da tarefa eles criam histórias apenas sobre um pedacinho específico. No outro lado da moeda o analista não consegue particionar o sistema em histórias. No final os cartões trazem histórias gigantescas.

É fácil estimar histórias pequenas. Na verdade o princípio que move as estimativas de métodos ágeis é que é muito mais fácil estimar alo pequeno do que algo grande. O problema é que estimar o tamanho uma história grande é muito difícil.

A solução neste caso provavelmente passa por ter histórias melhor definidas. É claro que vão existir histórias que são tão simples que até um 2 é muito para elas, nesse caso use algo menor como um numero abaixo da sua menor história “normal” (quase sempre isso quer dizer 1).

A segunda causa é bem simples de resolver, creio. A incerteza é algo comum, especialmente antes de executar algumas histórias para saber onde se pisa. Neste caso ao invés de se chutar a estimativa para a Lua com um 100 você pode começar usando uma carta que deixa claro que não se consegue estimar este cartão com as informações atuais:

E prosseguir criando um spike com objetivo de obt6er mais dados sobre aquela tarefa. Estimar um spike é bem mais simples do que uma história.

Mas e para estimarmos em alto-nível estas histórias enormes, confusas e distantes? Algo assim não é história, é um épico. Neste caso estimativas de alto nível são aceitáveis enquanto o épico estiver no backlog mas antes de serem agendados os épicos são desmembrados em histórias.

Posted in comunidade, metodologias | 5 Comments »

Agile Software Deployment?

Friday, June 20th, 2008

A melhor coisa sobre meu trabalho atual é que, como consultores, tentamos sempre pensar fora da caixa. Isso não é fácil numa consultoria, você pode imaginar, já que o mercado tende à empresas de três letrinhas que não se interessam tanto em otimizar ou melhorar e sim em cobrar por hora.

Um desses momentos recentes me fez passar por algo que eu nunca havia visto na pratica: como fazer deployment (instalação) e administração de software de maneira ágil?

O cliente em questão possui times ágeis em diversos segmentos há alguns anos. Durante o andamento de um projeto enorme surgiram algumas dificuldades em gerenciar ambientes e versões do software. Apesar de toda a agilidade os testadores ainda precisam que versões específicas, com bases de dados específicas, estejam instaladas em ambientes para homologar o sistema. Para piorar mesmo os desenvolvedores precisam ter uma instância de uma search engine (algo como o Lucene) e popular esta engine para que seja usável demora por volta de 10 horas.

Era preciso controlar qual desenvolvedor possui acesso à qual instalação da search engine e quais as versões instaladas em quais ambientes. No passado já ocorreu algumas vezes de um deployment para QA demorar mais que o esperado pela confusão generalizada de ambientes e isso atrasar o release para produção em uma semana.

A primeira proposta que eles tiveram foi clássica: vamos automatizar tudo. Construir um mega-sistema que controle o que está instalado onde, avise por email os responsáveis, tenha um controle de workflow, se integre ao sistema de QA, seja parte do IBM Tivoli, faça café… e seja extremamente caro.

Uma outra proposta surgiu do “grupo de governança” da empresa: ninguém faz deployment de nada sem ser autorizado. Toda vez que alguém precisa subir algo para QA ou outro ambiente precisa usar o Jira, toda vez que alguém precisar de uma modificação numa instancia da search engine precisa usar o Jira. Todos os pedidos são aprovados pelas pessoas competentes.

Aí começa o trabalho da nossa equipe: como ter o benefício esperado sem ter que vender a empresa pra comprar o sistema ou passar 20% do tempo preenchendo formulários?

O início deste trabalho foi feito seis meses atrás e foi parte do meu primeiro projeto aqui. Apos analisarmos o sistemas vimos que ele era estupidamente complexo sem a menor necessidade. O débito técnico foi se acumulando com o passar dos anos e uma coisa simples como instalar um WAR no Tomcat estava levando mais de duas horas, e trabalhando em par! Um dos grandes problemas era que das duas horas uma você gastava andando pelo corredor perguntando para outras pessoas o que fazer no caso X, qual a versão que está no servidor Y, etc.

A primeira coisa a se fazer era resolver o débito técnico. Não há solução que agüente mais de um mês em pé com aquela quantidade de problemas para resolver (incluindo um build que durava mais de quarenta minutos). Para isso os donos do negocio aceitaram alocar 10% dos pontos de uma iteração e, conforme a previsão, a maioria dos problemas graves se solucionou em cinco meses.

Enquanto isso, para amenizar o problema de maneira imediata, nós resolvemos usar um quadro-branco com a configuração dos ambientes. Quando a pressão do release passou o quadro foi para no wiki interno, numa grande tabela que qualquer um editava. Para o problema das instâncias de search engine nós criamos tokens: cada instancia tinha um cartão. Se você precisa de uma instancia você vai até uma parede e pega um cartão, adiciona as configurações daquela instancia na sua máquina e cola o cartão no seu monitor.

Simples e eficiente, a solução do cartão dura até hoje. O mesmo não se pode dizer do wiki. Enquanto o grupo de usuários era pequeno o wiki serviu de maneira ótima, após passarmos de algumas dezenas de pessoas -e diversos sub-projetos e spikes rodando em paralelo- ele se tornou inviável. O problema é que a tabela não comporta mais todos os dados de maneira eficiente e qualquer tentativa de organizar em sub-páginas faz com que as pessoas “esqueçam” de atualizar o wiki. Solução? Seguir o exemplo do que deu certo: cartões!

Acima você pode ver uma das paredes de cartões para nosso controle de mudanças e versões. O cartão rosa, no topo, tem o nome do ambiente. Cada um dos cartões azuis abaixo deste representa um dos componentes, os post-it laranja indicam as versões que foram instaladas. Os amarelos indicam qual instancia da search engine é usada em qual ambiente.

Os outros post-its colados nos cartões são meta-dados, eles indicam, por exemplo, que um serviço está inativo:

Esta solução tem funcionado nos últimos meses de maneira exemplar. Na verdade ela funciona tão bem que o problema agora é convencer os analistas de negocio que o problema do deployment não está solucionado e que eles ainda precisam investir nele.

Uma das conseqüências dessa técnica é que as duas pessoas que ficavam alocadas 100% do tempo gerenciando ambientes estarão em breve voltando a desenvolver as histórias e gerar valor de negócios ao invés de dar suporte aos desenvolvedores.

Muitas vezes você não precisa de milhões de dólares nem de burocracia, basta pensar fora da caixa.

Posted in arquitetura, engenharia, gerencia, metodologias, plataformas, thoughtworks | 13 Comments »

A Completa Irrelevância do Certified Scrum Master

Tuesday, May 27th, 2008

Semana passada o Richard Durnall me chamou para assistir a uma aula que ele deu na University of Melbourne. O Rich é o guru local de Lean e é uma figura.

A aula foi interessante. O curso é o mestrado em alguma das 343.435 ramificações de Tecnologia da Informação, basicamente uma escolinha para CIO-wannabe. Para se ter uma idéia todas as perguntas da sessão foram sobre implantação de ERPs, você via claramente que nenhum dos estudantes tinha a mínima vivencia na indústria e acreditavam piamente nas suas Info Corporate da vida.

A matéria era sobre comparação de metodologias e o Rich não foi o único. Antes dele apresentou um senhor, que é professor da instituição e arquiteto do maior banco da Austrália, onde inclusive tenho conta (brr…). A palestra do senhor arquiteto foi sobre como ele participou da salvação de um projeto de data mining usando o bom e velho waterfall. O único ponto diferente de uma lição clássica sobre como não fazer software foi sobre o uso de técnicas de Six Sigma para avaliação e priorização dos requisitos.

Quando chegou a vez do Rich apresentar Agile/Lean foi um contraste enorme. Na sessão de perguntas:

- Você falou sobre estes métodos ágeis e sobre como eles…er.. não ligam para requisitos. O [cara defendendo waterfall] apresentou um caso real de um grande banco. Você realmente acha que as técnicas de algo como agile podem competir com Six Sigma? [nota: uh?]
- Então, na minha apresentação eu fui bem ralo e essa é uma palestra introdutória, então foi bom você perguntar isso. Eu trabalhei na [top 5 montadora de automóveis], na [maior empresa aérea do mundo] e em alguns bancos. Nas duas primeiras empresas eu fiz parte da implantação de Six Sigma, inclusive eu sou Black Belt. O que eu vi deste processo foi [...] e por isso que agile/lean é uma boa escolha.

Agora pense que em vez de “Six Sigma Black Belt” ele tivesse dito algo como “inclusive eu sou Agile Software Specialist e os problemas de Six Sigma são [...]“. Teria o mesmo efeito?

Outro caso recente e interessante foi no Australian Architecture Fórum em Sydney. O Halvard estava apresentando uma palestra extremamente interessante sobre governança de projetos SOA onde a única ferramenta é um wiki. Em algum momento alguém levanta:

- Ok, ok, isso aí é muito Web 2.0, muito legal mas não é aplicável no meu cenário.
- E qual seu cenário?
- Eu trabalho em um banco, faço parte do grupo de controle de serviços de segurança. Isso de REST, wiki é muito legal mas vocês não entrariam num banco de modo algum!
- Uhm.. interessante você falar disso porque segurança em serviços é uma das minhas áreas de estudo… eu concluí meu Ph. D. em SOA na Universidade de Sydney e meu foco é exatamente segurança. Na verdade, na ThoughtWorks a maioria dos clientes são bancos e, inclusive, tivemos hoje de manhã o arquiteto principal do banco [top 5 banco australiano] falando exatamente sobre como usaram este tipo de técnica para governança num projeto que participei.

Imagine que ele tivesse falado “Eu sou um Wiki Certified Contributor e um RESTafarian Official Gold Partner”. Teria o mesmo efeito?

Por que das historinhas? Para argumentar numa discussão que eu tive com o grande Juan Bernabó sobre a total e completa ausência d sentido em algo como Certified Scrum Master. O Juan argumentou que certificações são valorizadas -e requeridas- pelas empresas. Meus pontos são:

Eu não conheço nenhuma pessoa que acredite que um curso de dois dias, sem sequer uma avaliação final –pagou, passou na pratica- deva ser valorizada. Se nós sabemos que a certificação não tem valor por que a venderíamos de outra forma? Agile não é sobre trazer valor e melhorar praticas?
O mercado também quer porque quer e acha que precisa de cronogramas detalhados, requisitos esmiuçados e projetos que terminam em uma grande fase de testes. Nós sabemos que isso não traz valor não fazemos apologia a este tipo de coisa, por que com certificação seria diferente? Por que ao invés de combater a ineficiência e a busca por respostas fáceis nós criamos e glorificamos nossos próprios selos?
Uma certificação emitida por si mesmo não vale nada. A menos que alguém já acredite que Scrum traz algum valor essa certificação é como acreditar que o Inri Cristo é Jesus porque ele afirma o ser.

Em resumo, eu acho o curso que é dado com o CSM ótimo. Ele abre mentes e é uma fantástica introdução. E só. O certificado emitido por este curso não tem qualquer valor real e propagandear o contrario, ajudando empresas a continuar glorificando certificações sem sentido, vai contra a primeira linha do Manifesto Ágil:

We are uncovering better ways of developing
software by doing it and helping others do it.

O debate completo está aqui.

Posted in australia, comunidade, eventos, gerencia, metodologias, negocios, thoughtworks | 20 Comments »

Trilha de Livros: Desenvolvedor

Tuesday, May 20th, 2008

Esta então é a prometida lista de livros para desenvolvedores. Claro que não é nenhuma lista exclusiva ou “o guia definitivo”, apenas minha recomendação de leitura, partindo do principio que você já sabe programar em uma linguagem como Ruby, C# ou Java.

Este guia é bem genérico, sem tentar se especializar em nada e sem tentar abranger mais que o mínimo necessário. Espere modificações nesta lista.

Operating Systems: Design and Implementation: Este ode não ser o melhor livro sobre Sistemas operacionais –ou pelo menos não o mais didático- mas eu gosto bastante. A maioria dos conceitos básicos de um Sistema Operacional está presente mesmo nas máquinas virtuais e seja como for, antes de abstrair você precisa entender como seu computador funciona. Claro que se você cursou SO na faculdade e, principalmente, se lembra de como memória virtual, filesystems e demais funcionam pode passar por este item –eu acho que uns 5% dos desenvolvedores que conheço se enquadram nisso, entretanto.
Fundamentals of Object-Oriented Design in UML: Este livro ensina métricas e princípios básicos para desenvolvimento de sistemas Orientados a Objetos. Se você passou por projeto estruturado provavelmente conhece o autor e algumas de suas métricas.
Head First Design Patterns: Uma introdução suave aos Design Patterns. A vantagem em começar com este ao invés do clássico (que é o próximo na lista de qualquer modo) é que você não tem que lidar logo de cara com Smalltalk e C++. Aprender um conceito não-tão-simples quanto Design Patterns enquanto tenta entender uma sintaxe fora do dia-a-dia é criar complexidade acidental.
Design Patterns: Elements of Reusable Object-Oriented Software: Apesar de não ser indicado ao iniciante eu não acredito que voc6e consiga ir muito longe sem ler este livro. Pelo menos as narrativas são fundamentais para entender as motivações e a evolução do conceito de patterns. A falta desta leitura faz com que pessoas cometam erros grotescos.
Agile Software Development, Principles, Patterns, and Practices: (em versão Java ou .Net) este livro traz uma visão bem pratica sobre alguns aspectos mais teóricos da Orientação a Objetos. Como u organizo pacotes? Qual o problema em ter dependências e como me livro delas? Devo sempre retornar null? O que significa herança na pratica?
Refactoring: Improving the Design of Existing Code: Conforme você for entendendo mais sobre design de software vai sentir uma vontade enlouquecedora de apagar todo o seu sistema e começar de novo. Antes de sair por aí cometendo carreiracídio leia este livro, ele vai te ensinar a fazer pequenas mudanças que melhoram a qualidade do sistema e identificar código que fede.
Patterns of Enterprise Application Architecture: A maioria dos patterns que você teve contato até aqui tratam de design em um nível micro. Como classes interagem, como elas colaboram e como gerenciar seus problemas. Este livro, entretanto, fala sobre padrões em um contexto mais amplo, sobre arquitetura de software.
Domain Driven Design: Os livros até então falam de sotware pelo software. Como criar uma classe, como gerenciar dependências entre classes… mas ninguém te mostrou o que deve ser uma classe e o que não deve. Eric Evans supre esta demanda mostrando uma abordagem simples e eficiente para criar domínios que se aproximam do mundo real.
POJOs in Action e/ou Applying Domain-Driven Design and Patterns: With Examples in C# and .NET: É normal que exista uma certa dificuldade em levar estes conceitos para o dia-a-dia. Estes livros não são indispensáveis mas eles ajudam bastante a entender como aplicar conceitos, ainda que algumas vezes de maneira “não canônica” mas ainda assim eficaz.
The Pragmatic Programmer: From Journeyman to Master: Infelizmente muitas vezes, especialmente em consultorias de três letrinhas e faculdades McDonald’s, não temos um ambiente sadio para nos ensinar como programadores profissionais se comportam. Este genial livro traz uma boa parcela deste conhecimento condensado. Eu adicionaria o The Art of UNIX Programming, especialmente para aqueles que vêm de uma cultura drag’n'drop para o mundo real
Ship it! A Practical Guide to Successful Software Projects Este livro é bem interessante para entender como um desenvolvedor utiliza ferramentas simples como controle de versão e issue tracker. Ótimo par aquém está profissionalizando uma empresa.
Agile and Iterative Development: A Manager’s Guide Antes de você se dedicar a estudar mais uma metodologia de desenvolvimento em específico uma boa idéia é ler este livro, que traz um apanhado de diversas metodologias e as compara.

Posted in Uncategorized, gerencia, metodologias, negocios, palestras, rest, ws-*/soap | 28 Comments »

Australian Architecture Forum 2008

Thursday, May 1st, 2008

Falando em coisas agitadas, fui convidado para palestrar no Australian Architecture Forum 2008. O título é “Lightweight SOA Through Web Widgets” e falar de SOA com REST num evento onde vai estar presente o impagável Jim Webber é algo bem diferente.

Como meu Google Analytics diz que ese blog é acessado por pessoas aqui na Austrália fica o convite.

Posted in arquitetura, australia, comunidade, engenharia, eventos, metodologias, plataformas, rest, soa, thoughtworks, você.pergunta, web | 4 Comments »

Retrô

Tuesday, April 15th, 2008

Mensagem na Agile-Brasil:

Saudações,

Estamos implementando a Retrospectiva de release em nossa equipe de desenvolvimento. Já fizemos 4 retrospectiva, mas acho que está faltando algo a ser feito. Primeira vou demonstrar como estamos fazendo.

Basicamente é o seguinte, um pouco antes de concluir uma release (aqui chamamos de versão) enviamos um e-mail para todos os colabores com as seguintes questões:
* O que foi bom durante a versão e devemos continuar a fazer?
* Quais as lições aprendidas na ultima versão?
* O que podemos fazer para melhorar?
* O que mantivemos de mais importante? (coisas que começamos a fazer recentemente e que foi importante)
* O que podemos mudar para a próxima versão?
* O que podemos adicionar ou tirar de todos o processo de desenvolvimento?
* Ocorrências na versão 2.19b que não se enquadram nos tópicos acima.

Ao retornarem, separamos o que realmente é útil e colocamos em um documento para ser discutido na reunião. O que não é considerado útil é conversado com o colaborar para explicar o porque não será considerado no documento o que ele passou, as vezes, a pessoa que redigiu o texto acaba explicando o que quis dizer e passa a ser útil.
As questões acima são respondidas por todos, inclusive pelo gerente da equipe. Tudo vai para o documento, algumas coisas são elevadas a um tópico maior que é de discussão. Normalmente são coisas que devemos discutir durante a retrospectiva para saber a opinião de todos.
Durante a reunião é lido o documento e firmado alguns pontos.

Normalmente o documento chega a 4 páginas e a retrospectiva dura em média 1h30min. Não é um processo tão ágil, desde o envio do e-mail até a retrospectiva, normalmente passam 2 dias.

Gostaria de saber a opinião dos nobres membros dessa lista sobre como estamos fazendo a retrospectiva.
Sugestões, alterações no nosso sistema são bem vindas.
Se puderem, descrevam como fazem a retrospectiva em suas empresas, isso pode agregar muito.

Atenciosamente

Evandro

Métodos ágeis são baseados em ciclos curtos com feedback constante e a retrospectiva é uma das partes mais importantes. Eu perguntaria o porque do documento mas seja qual for a resposta sugiro que este formato seja alterado imediatamente.

Um dos grandes benefícios em usarmos cartões (ou post-its se você preferir) é ter a informação escrita em algo que pode ser facilmente alterado, manuseado e, principalmente, rasgado. Um cartão de história não é uma descrição funcional, é um convite ao dialogo entre os membros do time.

Quantas vezes você revisa um documento antes de enviar para seu chefe? Quantas vezes você não tira aquelas alfinetadas que estão entaladas na sua garganta mas você não teria coragem de escrever num documento? Quantos workflows seus documentos passam?

Isso não pode acontecer numa retrospectiva. As pessoas devem se sentir à vontade para levantar pontos e criar um processo de envio de emails e confecção de documentos a ser discutido –além de extremamente ineficiente por si só- inibe o fluxo do feedback.

Existem diversas maneiras de fazer retrospectivas mas a minha preferida é a mais simples de todas que conheço.

Arrume um quadro branco e um numero razoável de canetas. Se não tiver quadro-branco arrume 3 cartolinas e post-its grandes.
Divida o quadro em 3 partes: Deu Certo, Precisa Melhorar e Dúvidas. Nota: a menos que você viva num ambiente muito sem-graça não use estes nomes. Seja criativo, use ícones, sei lá.
As pessoas escrevem seus pontos nas respectivas seções(pequenas, uma frase. Lembre-se: convite ao dialogo!)
Depois de todos os pontos escritos cada pessoa explica brevemente porque escreveu aquilo ali. É na verdade uma tentativa de venda do ponto para ser votado
Depois de descritos os pontos as pessoas pegam as canetas e votam nos pontos que consideram relevantes.
Discutem-se os pontos mais votados, até o tempo acabar.

Uma das coisas mais importantes é que para cada item discutido devem haver pontos de ação. Quem conduzir a retrospectiva (e a sugestão é que o condutor varie a cada semana) deve estimular as pessoas participando da discussão a enumerar medidas praticas que podem ser tomadas e associar um responsável por estas. Na próxima retrô antes do ponto 1 acima o condutor pergunta aos responsáveis se as medidas foram tomadas.

Este formato não requer preparação e é bem eficiente. Eu já participei de retrospectivas assim em times com mais de vintes pessoas e em menos de uma hora os pontos relevantes eram endereçados. Uma outra coisa importante é que retrospectiva é um processo. Realizar uma única retro não vai dar o feedback necessário, você precisa manter as retrospectivas acontecendo com freqüência para que o funcione.

Posted in comunidade, gerencia, metodologias | 5 Comments »

Sem Respostas Fáceis

Monday, April 7th, 2008

O Guilherme Chapiewski causou uma bela confusão com seu último post. Uma chuva de comentários debate: O Scrum Master deve ser técnico?

Eu já conversei com o Guilherme sobre isso algumas vezes e sei o que ele quis dizer, mas acho que colocou de uma forma meio confusa. Para mim o ponto é: o Scrum Master deve ser um gerente de projetos/facilitador/babá em tempo integral?

Após alguns anos nessa estrada dá para entender porque algumas pessoas se preocupam tanto em afastar o papel de gestor (seja Scrum Master of Universe ou qualquer outro termo que você preferir) do papel de técnico. Muitas vezes técnicos quando postos no papel de gestor não conseguem tirar a mão da graxa e isso atrapalha o andamento das coisas. Eu já tive gerentes de projeto que afundaram todo um release porque pegavam para si tarefas técnicas e não conseguiam exercer suas tarefas oficiais.

Isso acontece bastante mas não quer dizer que vá acontecer sempre, ou que não possa ser resolvido. Dizer que o gestor não pode exercer tarefas técnicas e ponto final é ignorar a característica empírica de um processo ágil.

Quem assume que isso é uma verdade absoluta está buscando respostas fáceis ao invés de tentar resolver o problema. Isso não é diferente em nada do cidadão que usa todos os templates, artefatos e papeis do RUP no seu projeto, ou daquele que acredita que um selo como CMMI ou MPS.BR traz qualidade.

Seguir à risca todos os documentos possíveis ou acreditar piamente que um selo traz qualidade é buscar respostas fáceis.

Desde outubro que eu não trabalho com Scrum. A ThoughtWorks não possui exatamente uma metodologia de trabalho, nós entendemos que agilidade é um processo empírico:

The empirical model of process control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs.

Cada projeto é um projeto, cada time é um time e aplicar uma receita de bolo, seja ágil ou não, é ruim. No meu projeto atual temos um time de desenvolvedores do mesmo nível. O papel de gestor de projetos fica com o tech lead e isso basicamente quer dizer que ele é quem perde 1/2 do dia em reuniões e é quem pede cerveja para a retrospectiva de sexta-feira. No resto do tempo está na máquina dele com o Eclipse aberto.

A diferença é que ele atua como tech lead, não como desenvolvedor. Ele não pode se comprometer com uma tarefa grande, ou em programar em par. O que ele faz é (1) ter certeza que possui entendimento sobre o que está sendo feito e dar sua posição sobre isso e (2) servir como palavra final quando algum assunto técnico atinge um impasse.

Eu pedi demissão da Globo.com um pouco antes do projeto acabar. Alem de atuar como Scrum Master e líder técnico da equipe eu ainda tinha que resolver algumas milhares de coisas relacionadas à minha viagem. Mesmo assim eu não abdiquei da minha responsabilidade de líder técnico. Eu desenhei com o Guilherme os WebServices que utilizávamos e não só sabia como eles funcionavam bem como enchi o saco dele para que tal coisa fosse desse jeito e não do outro. Eu trabalhei na primeira versão do framework JavaScript que criamos com o Tiago e depois fizemos algumas sessões de pair programming nas últimas alfinetadas.

Nas primeiras iterações eu ainda consegui pegar tarefas para mim, com o tempo isso foi ficando impossível mas eu não deixei de ser o líder técnico do projeto por isso. Assumir o papel de gestor do projeto me deixou com tempo fragmentado mas quanto mais ágil seu processo (e sua empresa) menos você precisa assumir o papel de gestor. Quando a empresa não requer muita burocracia desnecessária não há muito à facilitar, quando o time se gerencia não há muito há resolver.

Como o Antônio comentou no blog é muito bom chegar ao nível de ter essas discussões, pensar sobre o que é feito, mas é melhor ainda quando percebemos que processos ágeis são sobre pessoas e adaptação. Eu diria que um time não precisa muito mais de um Scrum Master Power Turbo do que de um tech lead, ambos são papeis importantes. Se você coloca seu tech lead como gestor de projeto e o impede de exercer suas funções técnicas você tem que ter uma estratégia para substituir essa perda.

Você pode ter certeza que as práticas que você mais odeia em uma metodologia de desenvolvimento não-ágil não foram criadas por pura maldade dos autores (bem, não sempre…). Estas práticas fizeram (e fazem) sentido nos cenários experimentados. Elas foram úteis e resolveram problemas. A grande questão é que não é porque uma coisa faz sentido em um cenário que ela deve ser aplicado à todos, ou sequer à maioria.

Cuidado para não ficar preso às respostas fáceis. Cuidado para não transformar processos empíricos em processos prescritivos. Cuidado para não tentar programar FORTRAN em qualquer linguagem.

Posted in comunidade, gerencia, metodologias, programando, thoughtworks | 8 Comments »

Par de Jarros

Sunday, April 6th, 2008

Metodologias ágeis pensam sempre em times de especialistas generalistas. Isso é algo fantástico.

É óbvio que ter um especialista em banco de dados Oracle no time aumenta bastante a capacidade técnica, é óbvio que ter o James Gosling como programador Java aumenta a produtividade nesta linguagem mas é mais que óbvio que a grande, grande maioria dos projetos de software hoje em dia não precisam de especialistas extremos, precisam de gente boa o suficiente na tecnologia.

Isso nos coloca confortáveis para ao invés de um DBA dedicado termos apenas bons desenvolvedores, que ainda que não saibam diferenciar todos os tipos de tablespace possíveis conseguem fazer o sistema funcionar de forma razoável –e razoável significa dentro dos requisitos funcionais e não-funcionais.

Não consigo lembrar de nenhum projeto que eu tenha participado nos últimos três anos que não envolvesse mais de uma linguagem de programação, geralmente Java com Ruby, C++, JavaScript, C#, Bash e/ou PERL (alem das DSLs: HQL, SQL, etc.). Nos bons times não havia “desenvolvedor C#”, havia desenvolvedor, e isso significava que o cara usava as ferramentas que melhor servissem para o trabalho.

Mas o que isso quer dizer do ponto de vista do desenvolvedor? Quer dizer que ele vai ser exposto à tecnologias diferentes, o que é ótimo, mas também quer dizer que ele terá que abandonar algumas das suas preferências pessoais em favor do time, o que pode não ser tão bom.

Em um time ágil, todos os membros devem estar comprometidos com o projeto. Não tem essa de “a minha parte está feita, falta Fulano terminar a dele”, todos são responsáveis e todos vão ajudar. Se você foi contratado como programador SQL e precisamos de uma mão para terminar de escrever testes em Selenium é sua obrigação para com o time se voluntariar.

Mas isso, como tudo na vida, tem dois lados. Existem pessoas que não ligam para a tecnologia utilizada, elas gostam do projeto em si, mas no mundo do desenvolvimento existem muitas pessoas –e geralmente pessoas muito boas- que possuem suas preferências. O cara não gosta de programar em Ruby, ele prefere Java. Se o time precisar ele escreve Ruby mas por ele fazia tudo em Java -ele não acredita que Ruby tenha a mesma qualidade, ou algo do tipo.

Lembre-se que o manifesto ágil coloca pessoas acima do processo, se o processo diz que o desenvolvedor deve ser bombril multi-uso mas a pessoa não se sente a vontade nessa área você como gestor tem obrigação de fazer algo a respeito.

O que fazer? Deixar este desenvolvedor apenas nos projetos Java? Se isso for uma opção tudo bem, mas e em times pequenos? Eu vejo essa situação como um contrato entre as partes:

O desenvolvedor deve saber que sua preferência de linguagem/tecnologia/plataforma/framework/biblioteca não necessariamente é a melhor para o caso e/ou não é viável na atual situação.
O desenvolvedor deve se comprometer a utilizar a tecnologia em questão quando o time necessitar que ele o faça –e ele tem o direito de dizer até 3 palavrões por linha de código escrita
O gestor tem que garantir que o desenvolvedor tenha direito à expressar sua opinião quanto às escolhas do grupo
O gestor tem que saber que essa pessoa não está confortável nessa posição e fazer o possível para que isso seja amenizado

Da mesma maneira que o gestor do projeto ou do time sabe que não pode arriscar seu sucesso por uma birra do desenvolvedor com a linguagem, ele sabe que é muito difícil encontrar bons desenvolvedores e manter um ambiente de trabalho agradável. Na minha experiência o que eu mais vi foram casos onde o desenvolvedor cumpre a parte dele no contrato acima mas o gestor não. O gestor trata todos os desenvolvedores como iguais, ignorando completamente o caráter pessoal e social de um projeto de desenvolvimento.

O que “amenizar” significa depende do seu contexto. Você pode tentar mudar a pessoa de equipe, pode fazer com que ele tenha a opção de pegar outras tarefas que não seriam imediatamente executadas, oferecer treinamento… O que você não pode fazer é que o processo –ágil ou não- vença à razão e você tenha um desenvolvedor completamente desestimulado e frustrado na sua equipe, que enquanto você não olha está em um site de empregos.

Não deixe que para aquele desenvolvedor agile signifique trabalhar com algo que você não gosta.

Posted in gerencia, metodologias, plataformas, programando | 3 Comments »

Fragmental