Débito Técnico

ISVs (empresas de produto) definitivamente é o ambiente que mais se beneficia das práticas ágeis. E o melhor de tudo isso é que a implantação é tranquila, simples e principalmente barata se comparada com outros ambientes.

Para complementar nosso portifólio de cases ISV, no mês de maio a Aurum, uma empresa direcionada para soluções no mercado jurídico com o seu produto Themis, nos contactou para trabalharmos juntos na transição Agile.

Além do treinamento para aproximadamente 15 pessoas na Aurum, tivemos excelentes sessões de coaching nos primeiros plannings, reviews e retrospectives. Em todas as nossas propostas incluímos entre 8 a 40 horas de consultoria para auxiliar as empresas nas suas implantações de processos ágeis. Com isso, acompanhamos as equipes nas primeiras Sprints, tirando dúvidas, mostrando técnicas e atuando como agente facilitador. Essa tem sido a nossa estratégia em muitos clientes e vemos que somente treinar pode deixar as equipes com muitas dúvidas que algumas horas de coaching eficiente resolvem facilmente.

No caso da Aurum foi bastante interessante como logo na primeira Sprint do projeto piloto a equipe assumiu um compromisso de melhorar também suas práticas de engenharia com uma arquitetura orientada a objetos em Delphi e testes automatizados. Pelo relato deles, a inspeção e adaptação foram determinantes para a entrega do primeiro release Agile que foi um grande sucesso.

Parabéns a todos da Aurum pela determinação e inovação. Muito sucesso!

Treinamento

Equipe no primeiro Planning do projeto piloto

Review & Retrospective Boards nas primeiras Sprints

Essa é especial para os Applemaniacos. Em maio ministrei o treinamento Scrum para a equipe da e-Deploy. Com muitas boas discussões sobre projetos, esta turma foi especial por estarem num ramo altamente em foco: aplicações mobile para a plataforma iPhone, Android entre outras.

Fiquei impressionado com o direcionamento dos produtos da e-Deploy. Realmente eles estão alinhados com as idéias novas da Web e com certeza terão sucesso com práticas ágeis.

(ao pessoal da e-Deploy, temos a pendência daquele pairing em Objective-C)

Atividades em Grupo

Sprint Planning

Muitos de vocês já devem ter alguma vez buscado por um nome de rua na Internet e caído no Apontador, um dos sites mais acessados no Brasil com mais de 10 milhões de acessos mensais. A equipe Apontador é responsável por manter no ar o portal Apontador.com.br (com foco cada vez maior em locais, avaliações e conteúdo gerado pelo usuário) e MapLink (com foco maior em mapas, trânsito e rotas), além de fornecer a base cartográfica ao Google Maps Brasil. Recentemente o Apontador foi escolhido como uma das 250 melhores empresas globais de tecnologia pela Alwayson. Tendo já iniciado a implantação Agile, o Apontador escolheu a Aspercom e nosso treinamento Extreme Programming para melhorar suas práticas de engenharia.

Como consta no nosso programa, o treinamento Extreme Programming foi reformulado para reforçar mais práticas de TDD. Na LBS Local usamos Java, VRaptor 3, JUnit, Mockito, JPA, JBehave e WebDriver numa arquitetura que está disponível no meu GitHub. Divirtam-se!

Foram dois dias muito produtivos com muita troca de experiências, pairings divertidos e muitas discussões sobre Orientação a Objetos, Agile, Cloud e Arquitetura Web.

A equipe Apontador está agora criando uma API aberta para desenvolvedores que deverá ser liberada em breve. Vem novidade por aí!

Pareando com o pessoal

Toda a turma! Parabéns a todos do Apontador

No mes de março estive em Palotina, PR, ministrando treinamentos sobre Scrum e Kanban para um grupo de 40 pessoas da CVale. A CVale é uma cooperativa de produção agropecuária cujo foco principal das suas atividades concentram-se no segmento agroindustrial, com direito a um complexo com capacidade de abater 500 mil frangos por dia.

Com os métodos ágeis tomando o mercado de norte a sul do país, a CVale no desejo de melhorar seus processos adotou práticas do Scrum na sua gestão. Porém, a empresa teve dificuldades com algumas práticas do Scrum, especificamente o Time-boxed Sprint. Como já citei aqui no blog, desde o final de 2008 tenho estudado o paradigma do ciclo contínuo com abordagens Lean e Kanban. Minha linha de estudo está baseada principalmente nos autores Alisson Vale, David J Anderson, Don Reinertsen e Alan Shalloway. No caso da CVale, uma equipe super enxuta de TI atende a diversas unidades de negócio - de uma financeira até uma beneficiadora. E por conta disso, o ritmo das demandas e a dinâmica do negócio não permitem o uso de iterações com escopo fixo, e se as iterações não se cumprem por conta de mudanças constantes usar Time-boxes leva a uma dinimuição da importância dos planejamentos e a uma certa frustração da equipe.

Com isso a Aspercom recomendou um direcionamento da empresa para a filosofia Kanban de fluxo contínuo, limitar Work In Progress e visualização do processo. Logicamente este Kanban está recheado de práticas do Scrum como o uso de um Backlog priorizado pelas áreas usuárias. A equipe também desfruta de uma excelente auto-organização e comunicação intensa.

Estarei escrevendo mais aqui no blog sobre Kanban e abordagens Lean. Sucesso a todos da CVale!

Após muito tempo na correria, finalmente tive uma folga para publicar algo aqui no Débito Técnico, principalmente sobre nossos novos clientes e cases de sucesso, principalmente de implantação Agile.

Em Março estive junto ao animado pessoal da BSA ministrando o nosso treinamento Scrum. A BSA é uma consultoria pequena que também está trilhando o caminho ágil para projetos de grandes empresas Telecom.

No treinamento da BSA aplicamos um treinamento/coaching simultâneo, onde usamos um projeto real da empresa como base para as atividades práticas do treinamento, fazendo o release planning, escrevendo stories e planejando a primeira Sprint.

Parabéns a todos da BSA e muito sucesso!

Em Janeiro (sim, já faz um tempinho) a MundoJava publicou uma edição comemorativa em homenagem aos 15 anos de uma das literaturas mais importantes da ciência do desenvolvimento de software: “Design Patterns – Elements os Reusable Object-Oriented Software” de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (ou simplesmente Gang of Four – GoF).

Nesta edição, meu artigo entitulado “Patterns no Desenvolvimento de Software Moderno” é um apanhado de conceitos sobre alguns patterns revisitados, esquecidos e novos na nossa caixa de ferramentas. Quem viu algumas palestras minhas em 2009 sabe do que estou falando: equipes ágeis estão pecando em algumas práticas OO, mesmo usando bons testes automatizados. Tem muita equipe gerando monstros monolíticos orientados a testes. Como é costume aqui no Débito Técnico, segue o chorinho do artigo:

O Design Moderno visa a Testabilidade

A maior diferença que destacamos sobre a orientação a objetos comparada com o paradigma procedural é o encapsulamento. Ao contrário do que tínhamos no modelo procedural, um design orientado a objetos não é um conjunto de algoritmos encadeados no estilo “entrada-processamento-saída”. Objetos possuem estado e trocam estímulos através de mensagens. As mensagens que o objeto responde fazem parte da sua interface pública. Como disse, uma mensagem pode ser uma simples chamada de método, assim como um estímulo remoto, assíncrono que veio de uma fila que você nem sabe qual é. Objetos possuem encapsulamento forte, e os objetivos do sistema são cumpridos com a colaboração entre eles através da troca de mensagens.

Dado esta característica dos objetos, podemos facilmente testar sua implementação através de testes de unidade. Eu me lembro muito bem quando meu professor de lógica de programação falou que um compilador só consegue detectar erros de sintaxe do meu programa, mas não erros de lógica. “A sintaxe pode ser checada pelo computador, mas não a lógica”, dizia ele. Eu creio que atualmente nós podemos desafiar esse conceito usando testes automatizados e práticas de desenvolvimento orientado a testes (TDD). É possível sim validarmos a lógica de um programa assim como o compilador (ou interpretador) faz com a sintaxe.
É uma premissa fundamental que os objetos tenham somente uma responsabilidade, assim como é importante que eles tenham um encapsulamento que proteja seu estado. Se um objeto tem uma interface pública e esta pode ser utilizada por qualquer outro componente, temos todo ferramental para concentrar testes nessa interface, e assim, conseguimos validar deterministicamente se a lógica do componente funciona.

Além disso, se escrevermos os testes antes da implementação teremos uma descrição muito clara da interface necessária. Nosso componente será simples, pois atenderá somente aquilo que nosso teste exige. Desenvolver a aplicação orientada a teste (TDD) é uma das melhores ferramentas para ter um bom design, além de nos dar segurança para evoluirmos o design refatorando sempre que necessário. Ter bons testes tira o nosso medo em mexer naquelas partes obscuras do código. Refatoração só existe de forma segura com testes.

Muitos desenvolvedores questionam como testes podem melhorar o design. Ora, a resposta é bem simples, e está relacionada com os conceitos defendidos neste artigo como coesão, acoplamento e dependências: se um design a priori é difícil de testar isoladamente (com testes unitários) consequentemente é um design acoplado e difícil de manter. A facilidade de testar os componentes é proporcional à qualidade do seu design.

É muito interessante que o Erich Gama na entrevista desta edição mencionou que a Injeção de Dependências (DI) seria um padrão digno de entrar na obra do GOF. As soluções atuais de DI garantem uma melhor testabilidade, pois todas as ligações são feitas externamente à inteligência do próprio componente, permitindo o uso de Mocks e Stubs para simular o comportamento dessas dependências durante um teste de unidade.

Tenho discutido muito sobre design de software com várias pessoas e vejo que a falta de testes é uma das piores faltas em design. É melhor ter um design ruim com testes do que ter um design bom sem testes. O design ruim com testes você pode com segurança refatorar para que ele se torne um bom design. Com um design bom sem testes você não tem nada! Concluindo, um bom design inclui testes.

No ano de 2009 eu tirei “férias” da MundoJava. Minha coluna MundoOO precisava de novas idéias e eu mesmo já estava com assuntos esgotados. Para o ano de 2010 estarei escrevendo uma outra coluna chamada MundoAgile, onde vou compartilhar sobre meu dia-a-dia como Agile Coach, e as dificuldades que tenho nas minhas implantações Scrum e XP. Espero que gostem!

Uma das coisas que mais tem me chamado a atenção no mercado é que várias empresas tem procurado a Aspercom para contratar nosso treinamento Extreme Programming. No último mês até grandes bancos solicitaram proposta de consultoria e treinamento em XP. Algumas empresas que já arrumaram suas práticas de gestão com Scrum estão buscando melhorar a qualidade interna de suas aplicações. Nosso treinamento XP foi ampliado nesse início de ano para dar mais foco em TDD, e partir de fevereiro, ele foi direcionado somente para as plataformas Java e .NET.

A Imagem é uma empresa especializada em software de informações geográficas. Sim, assim como a Scheffer, é mais uma empresa que foge totalmente de “sisteminhas web”. Sem querer ser perjorativo: software não se limita a Websites. Os clientes da Aspercom têm me mostrado ultimamente que desenvolvimento de software é algo muito vasto. É um assunto abrangente demais. Como exemplo, apesar de gostar muito do Scrum, nos últimos 8 meses tive contato com ao menos 5 empresas onde o Scrum não rola. Isso é assunto para outro post!

Sistemas de informação geográfica (GIS) auxiliam empresas em diversos aspectos. Geralmente são empresas gigantes. Esses sistemas podem auxiliar a manutenção de linhas de transmissão de energia, o projeto de um oleoduto, a construção de uma nova fábrica, logística em lugares remotos, compreender o impacto de fenômenos naturais e muito mais. Isso envolve imagens de satélite, informações geológicas e meteorológicas e muitos cálculos complexos.

O treinamento XP e TDD na Imagem foi muito divertido. Nosso treinamento tem muitas dinâmicas, muitos pairings e a colaboração exigida nas equipes para cumprir o sistema exemplo é empolgante.

Parabéns a todos da Imagem. Muito sucesso nos importantes projetos e clientes que vocês têm atuado.

No mês de fevereiro de 2010 a Aspercom esteve em Ponta Grossa ministrando treinamento para a equipe da Scheffer Logística. Antes de falar sobre o que aconteceu durante os treinamentos, assista ao video abaixo:

Eu realmente creio que modelar e implementar um domínio desses seria a tafera mais divertida do mundo. Projetos de automação como esses são desafiadores, e se você é um aficionado em orientação a objetos deve ter sentido uma vontade irresistível de modelar algumas entidades vendo este vídeo.

O treinamento da Scheffer começou normalmente, mas terminou com uma sessão de modelagem ágil, Domain-Driven Design e práticas de BDD e Design Incremental usando Fitnesse. É bastante comum um treinamento corporativo iniciar como um curso e terminar com pairings e consultoria.

A Scheffer é uma empresa nacional pioneira na tecnologia de transelevadores em armazens automatizados, um setor em franco crescimento. Foi muito interessante conversar com pessoas que trabalham com TI num domínio tão diferente. Um aspecto bastante interessante é que apesar dos métodos ágeis dizerem tanto para “abraçarmos as mudanças”, digo para vocês que existem sim projetos com escopo fixo, aonde o Scrum perde muito do seu brilho, pois usamos iterações exatamente para ter feedback e com isso, mudanças. Um projeto de automação geralmente é direcionado pelo maquinário utilizado, as restrições do escopo da automação e etc… Um cliente que tem um armazém de 20.000 metros quadrados não terá mudanças na sua forma de automação. Geralmente o projeto físico inicial (feito por engenheiros especializados) não muda, e com isso a solução do software também tende a não ter alterações vindas do negócio. Logicamente a Scheffer se beneficiará de iterações, design incremental e outras técnicas aprendidas para limitar seu próprio risco do projeto.

Parabéns a todos da Scheffer!

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

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

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

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

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

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

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

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

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

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

Sobre o Workshop Scrum

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

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

Uma discussão surgiu na lista Scrum-Brasil… Muitas pessoas postaram coisas boas, mas em linha geral, achei que alguns conceitos estavam errados (e me preocuparam bastante). A discussão está aqui:

http://br.groups.yahoo.com/group/scrum-brasil/message/5618

Um dos maiores benefícios do Scrum é organizar o backlog nos seus itens e suas prioridades. O objetivo do Scrum é matar o backlog, ou ter o maior retorno possível com os itens do backlog que são implementados Sprint por Sprint, de maneira iterativa. Como falei no post anterior, o objetivo do Sprint é ter funcionalidades potencialmente implantáveis. Mais uma vez, esse é um conceito fundamental do Scrum que muitas vezes é esquecido, essencialmente porque isso é garantido por boas práticas de engenharia.

Definição de pronto é uma premissa que visa garantir que o que está sendo entregue REALMENTE atende as necessidades do projeto, do cliente ou do mercado, levando em consideração as limitações da tecnlogia. A Definição de Pronto tem relação com a qualidade, a manutenção futura do sistema e os objetivos do produto. Logicamente isso pode variar de projeto para projeto, mas não tem relação alguma com a maturidade da equipe. Se a equipe não consegue atender ao critério definido afrouxar o critério pode ter consequências desastrosas…

Vou dar um exemplo aqui de como ter uma má definição ou ter essa definição baseada nos skills da equipe pode ser ruim. Imagine que estou fazendo um produto de software para o mercado. Esse geralmente é o ambiente ISV que tenho trabalhado. Um software desses atende centenas de usuários, deve ter uma manutenção constante e barata, ter um deployment fácil, excelente usabilidade e farta documentação do usuário e sistema.

Se você quiser fazer um exercício, prezado ScrumMaster, peço que você escreva o que você acha que deve ser a definição de pronto deste produto antes de prosseguir a leitura do artigo.

Estamos iniciando o primeiro Sprint depois de uma concepção ágil e visamos nesse primeiro Sprint entregar as funcionalidades mais importantes para nossos usuários (e espero que vocês também estejam fazendo isso nos Scrums de vocês). Bem, vamos escrever uma definição de pronto baseada na maturidade comum das equipes que vemos por aí:

Definição de Pronto 1.0:
Testado no ambiente de homologação

Na primeira iteração a equipe está super contente com o resultado. Eles conseguiram “entregar” umas 5 ou 6 histórias. O Product Owner até esboçou um sorriso no Review e a moral da equipe está no alto (primeira entrega no Green Field sempre é assim).

Inicialmente essa definição de pronto parece ser boa. Há um sentimento de valor sendo entregue. Até a quinta iteração essa definição pareceu boa, porém, a equipe percebe que ela está cada vez mais devagar. Com as funcionalidades se acumulando está cada vez mais difícil executar os testes e refatorar o sistema para entrar os itens do backlog. A qualidade está decaindo rapidamente. Este cenário é bastante conhecido e bastante citado aqui no blog: A FALTA DE PRÁTICAS ÁGEIS DE ENGENHARIA como testes automatizados, integração contínua e etc…

Esse problema foi causado porque nossa definição de pronto era baseada na maturidade da equipe, e não nas necessidades do projeto. Nesse momento é necessário contratar treinamento, chamar uma consultoria para parear com os desenvolvedores, mudar o mind-set da equipe para orientá-la a testes, aprender novas tecnologias, trocar membros da equipe e etc… No entanto, o problema MAIOR é que temos 5 iterações já implementadas sem testes que se tornaram um péssimo legado. Tudo terá que ser revisado e muitas coisas reescritas na sexta iteração (e isso vai fazer mal para a moral da equipe, acredite). Bem, com tudo isso ajustado, mudamos a definição de pronto para a sexta iteração (que na verdade será uma refatoração gigante):

Definição de Pronto 1.1:
- Implementado com boas práticas de engenharia (ex. testes automatizados)
- Implantado no ambiente de homologação

Creio que o Product Owner e o bolso dele não ficaram muito feliz com esse fato. Houve uma ruptura na Value Chain (corrente de valor) e com isso, um sentimento de falha do próprio Scrum. Porém, com a definição ajustada as entregas das próximas iterações possuem uma qualidade e confiança muito maior. Não estamos mais perdendo tempo com testes que podem ser automatizados. Os processos de integração contínua estão mostrando falhas o mais rápido possível e o design está simplificado. Durante as iterações 6, 7 e 8 a definição de pronto 1.1 mostrou ser a ideal.

Até que no início da 9a. iteração (de umas 20 previstas) o Product Owner diz que quer colocar o produto no mercado em produção. Ele quer faturar com a solução, antecipando o ROI, afinal, é isso que o Scrum promete. Isso significa que após a décima iteração a equipe terá que lidar com mais práticas SCM, e não só isso, manuais de sistema devem ser elaborados para o pessoal de suporte, assim como manuais de usuário, help on-line, materiais de treinamento e etc…

Mais uma vez, vimos que a definição de pronto não foi suficiente para atender ao conceito de funcionalidade potencialmente implantável. Mais uma vez a equipe deverá parar totalmente para melhorar seu deployment, escrever manuais, fazer transições e etc… Mais uma vez a iteração 9 será um grande refactoring para atender a nova definição de pronto:

Definição de Pronto 1.2:
- Implementado com boas práticas de engenharia (ex. testes automatizados)
- Implantado no ambiente de produção
- “One-click deployable”
- Com documentação técnica e do usuário

Há uma grande correlação entre o conceito do Value Stream do Lean e a Definição de Pronto do Scrum, e esse exemplo que coloquei aqui demonstrou claramente que o processo de desenvolvimento dessa equipe não é fluído: foram necessárias “fases” de estabilização para se ter valor, se aproximando de um estilo Waterfall. É interessante notar que um sistema Kanban pode deixar a corrente de valor mais visível que uma definição de pronto. Ter uma telinha do sistema que entra e funciona sem dar pau é uma parte bem pequena de um produto de software: não só isso irá gerar ROI. Aquilo que sai da equipe deve ser um incremento completo e não só aquilo que é importante, ou visível.

Muito se fala em equipe multi-disciplinar. É comum achar que um arquiteto, um desenvolvedor e um tester fazem um Carnaval, porém, a característica multi-disciplinar da equipe deve corrobar com aquilo que essa equipe pretende entregar. O backlog nos fala o que deve ser entregue e a definição de pronto, ortogonalmente, nos fala exatamente os critérios dessa entrega. Nesse aspecto, os itens do backlog não tem só relacão com funcionalidades, mas sim, com VALOR.