Débito Técnico

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

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

Todo pessoal pareando.

Equipe 1

Equipe 2 e o Kanban

Um desenho vale por 3 palavras

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

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

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

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

Ambiente informativo semi-digital do treinamento

Equipe que entregou mais histórias

A equipe que mais divergiu nos pairings

A equipe que mais discutiu

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

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

Neste mês de Julho estive na empresa MicroPower ministrando nosso curso UML e também o curso de Scrum.

A MicroPower é uma empresa especializada em soluções focadas em gestão do ensino/aprendizado de empresas, tendo produtos próprios para Gestão de Treinamentos e também serviços sob medida como a criação de conteúdo para treinamentos à distância.

Gostaria de parabenizar a todos da MicroPower pelo excelente nível da turma e desejar muito sucesso, principalmente na adoção das práticas ágeis/iterativas de desenvolvimento.

Turma concentrada!!!

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

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

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

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

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

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

Um dos fenomenos interessantes que tenho visto atualmente no mercado é a adoção de práticas ágeis, principalmente o Scrum, por empresas ISV de pequeno e médio porte. Já relatei alguns cases aqui como a Crivo, a YMF e a Summus. A algum tempo atrás a gente chamava os ISVs de “pacoteiros”, ou melhor, vendedores de pacotes.

Antes de mais nada digo a todos vocês que é muito bom trabalhar em ISVs. É um dos melhores ambientes para aprender sobre desenvolvimento de software, pois quando você está fazendo um produto para o mercado você utiliza quase 100% das práticas de desenvolvimento de software. Geralmente quando você trabalha para uma empresa, fazendo software sob medida, muitas coisas sobre análise de negócios, alinhamento com o mercado, concorrentes, design customizável, manuais de usuário, estrutura de distribuição e pós-venda não são problemas para você, mas para um ISV isso é o dia-a-dia do negócio. Fazer um produto para o mercado e ganhar dinheiro com isso é um desafio interessante.

A Synchro é um ISV 100% nacional que vende software para a área fiscal há 17 anos. Seus produtos atendem apuração fiscal, SPED, NF-e, CIAP e muitos outros. Eles estão presentes em São Paulo, Campinas, Curitiba e Rio de Janeiro.

No mês de janeiro a equipe da Synchro participou de uma das nossas turmas do curso Scrum da Aspercom, onde muita, mas muita conversa e discussões rolaram! No mesmo mês eles começaram sua adoção do Scrum no gerenciamento do projeto e também estão adotando outras práticas ágeis no seu processo de engenharia. Eles estão correndo bem a maratona da adoção Agile.

A adoção de práticas ágeis (como o Scrum) são decisivas para o sucesso dos ISVs. Nestes ambientes de alta competitividade qualquer ganho de market-share é importante, principalmente nesses momentos de crise. Os principais diferenciais que podem aumentar as vendas, reduzir custos e ajudar a esmagar a concorrência são alcançados com a colaboração, o foco, a transparência e a simplicidade das metodologias ágeis.

Ainda falando sobre as discussões correntes sobre o Papel do Product Owner, é interessante ver que em nesses cases citados, o Product Owner é uma pessoa de negócio, financiador (e geralmente está saindo dinheiro do bolso dele) e muito envolvido. Alguns deles tem conhecimento técnico. São orientados ao ROI da forma que o Scrum prega.

Antes de mais nada deixa eu avisar: eu estou vivo! Tirei um tempo de férias de escrever (aqui e na MundoJava), mas agora estou de volta! E para aquecer, vou relatar um projetinho divertido que participei.

Uma das maiores convicções que tenho sobre desenvolvimento de software é que não existem fórmulas mágicas, nem processos mágicos e nem certificações mágicas… O máximo de “mágico” que pode existir em desenvolvimento de software são alguns profissionais mágicos (infelizmente alguns são adeptos de magia negra). Além disso, “Processo Padrão” é uma coisa que não existe.

O projeto da DDWorks começou de maneira interessante. Numa dessas quintas-feiras de verão, um dos sócios me ligou e disse: “- Quero colocar um e-commerce no ar na semana que vêm”. (nem sei se ainda se usa a palavra e-commerce, mas ele disse assim!)

As condições são:

1. Nós não temos tempo de negociar, não temos tempo de firmar contrato, não temos tempo nem de “planejar” o projeto

2. Tem que estar no ar e vendendo até sexta-feira da semana que vem

3. Tem que ter integração com e-payment ainda a ser definido (no fim optamos pelo PagSeguro)

4. O desenvolvedor tem que estar aqui presente. Vamos dar todos os subsídios e decisões em tempo hábil

5. Já falei que tem que estar no ar na semana que vem?

Qualquer pessoa poderia falar que isso é impossível, porém, o cliente estava disposto a fazer o que fosse necessário para atingir esse objetivo, e nenhum outro fornecedor deu atenção a esse projeto. Eles acharam isso “impossível”. Eu até imagino aqueles vendedores acompanhados de gerentes de projeto (ambos de gravata) dizendo “- Vamos com calma!”, “- Precisamos planejar direitinho.”, “- Vamos detalhar mais…”. O mercado está cansado dessas ladainhas! Como seria um desafio interessante topei na hora. Traçamos alguns objetivos juntos e marcamos uma reunião de planejamento na segunda-feira às 9:00.

Planejamento Inicial de projeto é uma das coisas que mais gosto de fazer. Como o dead-line já estava definido (sexta-feira!!!) essa reunião seria importante para definirmos SOMENTE o que era necessário para VENDER. Toda e qualquer firula a mais deveria ser posta de lado. Este planejamento inicial não tomou mais de 30 minutos, pois o cronometro de 40 horas já estava ticando. O objetivo do projeto era “vender pela Internet”. Planejamentos exigem modelagem, então nós modelamos….

Para iniciar qualquer trabalho nós fizemos um Mapa de Navegação seguindo algo parecido com um diagrama de atividades, mas sem formalidade alguma. Nós precisamos desse modelo para saber o mínimo necessário para “vender”. Além disso nós também usamos esse modelo para saber quais telas eram mais complexas para iniciar o projeto por elas, diminuindo o risco. Sim, esse rascunho era nosso “Product Backlog” para os CSMs de plantão.

Como seriam só 5 dias as iterações eram diárias. Para o projeto, o fim da quarta-feira (a terceira iteração) era o momento crítico. Apesar de ter outras pessoas gerando conteúdo, imagens e modelos, somente eu estava programando no Rails.

Uma das perguntas que faço para meus alunos no curso Scrum da Aspercom é: Com relação a pessoas, o que você precisa para desenvolver software? Pare de ler este artigo e tente responder isso mentalmente. Se você perguntar para um gerente de fábrica de software ele vai responder algo como “1 analista de negócio, 2 analistas de sistemas, 4 programadores e 1 tester”. Acredite, eu já ouvi isso de um deles. Espero que você não tenha respondido isso mentalmente. Mas a resposta correta é que para desenvolver software você precisa de dois tipos de pessoas:

a. Alguém que sabe do negócio
b. Alguém que sabe desenvolver software

No caso da DDWorks, com iterações diárias, praticamente nós fizemos um desenvolvimento conjunto entre os caras de negócio e o programador (eu). Um “pair programming” do Developer com o Product Owner. A adoção do Rais foi definitiva para que cada pedaço de funcionalidade incrementado em 3 minutos fosse rapidamente testado junto ao cliente. Feedback rápido foi determinante para o sucesso. Eu acredito que o futuro do desenvolvimento de software é algo parecido com isso: programadores armados até os dentes com arquiteturas ágeis e clientes participando ativamente do projeto ao ponto de participar de “pair programming”.

Durante essa semana nós fizemos muita inspeção e adaptação. Muitas coisas nós mudamos durante o desenvolvimento. O próprio cliente teve que fazer concessões sobre alguns detalhes (eles são uma agência de design, assim, teve alguns desgastes sobre o tempo investido na “beleza” do site). Não achem que foi “fácil”, quer dizer, programar foi fácil, mas fazer cada detalhe solicitado caber no prazo e no orçamento sem comprometer o objetivo é que foi dureza. Na quarta-feira fizemos o primeiro deployment na Locaweb…. na sexta-feira o site estava no ar!!!! Acessem aí:

http://www.docstyles.com.br

(veja a página “aprenda mais” para saber o que a DDWorks faz)

Uma coisa que achei bastante interessante nesse projeto: nós não usamos Stories, não usamos reuniões, não usamos ScrumMaster, não usamos Kanban, não usamos “Test First”. Não teve qualquer besteirol Agile. Você considera esse projeto ágil?

Guarde esse princípio: Para coisas simples as soluções são simples.

Gostaria agradecer ao pessoal do Brazilian Rails. A contribuição de vocês ajudou muito e poupou um bocado de tempo.

Antes de mais nada quero me desculpar com os leitores pois o blog ficou jogado às moscas. Isso porque trabalhei muito, me meti em projetos e muitos treinamentos também.

A Crivo é uma das empresas que dá gosto de ver. No mês de outubro o Alberto, ScrumMaster, me ligou pedindo um treinamento focado em User Stories, Modelagem Ágil e Domain-Driven Design. Nas palavras dele: “Scrum nós já estamos aplicando muito bem aqui”. De fato, a Crivo possui um time muito consistente e os bate-papos durante o curso foram muito enriquecedores.

Eles possuem uma solução muito interessante que é comercializada como serviço e desenvolvida em .NET (mas sem Dataset pra cá e pra lá) Baseada na consistente formação e experiência em TI de seus sócios, a Crivo desenvolveu um software que veio a se tornar a melhor e mais completa solução para aperfeiçoar e automatizar a concessão de crédito e a administração de risco nas organizações.

Treinamentos customizados são excelentes! É interessante ver como nós já temos empresas que estão maduras em boas práticas de desenvolvimento de software, estão ganhando dinheiro com isso, têm equipes unidas e precisam somente melhorar algumas práticas pontuais.

Vamos às fotos:

Isso sim é um Scrum-Ban

Escrevendo Stories com a menor caneta do mundo

Parabéns a todos da Crivo pelo excelente treinamento e muito sucesso em 2009. Empresas como a de vocês nos dão esperança: realmente existem gestores sensatos no nosso mercado.

;)

Nas últimas semanas tivemos vários relatos de empresas do Planalto Central adotando práticas ágeis em projetos para o Governo. Na semana passada ministrei o nosso curso Scrum para o pessoal da Infraero.

Mais uma vez os questionamentos são baseados nos famosos “projetos de escopo fechado”. E após muitas discussões (construtivas) é fato que a legislação de contratação de outsourcing para o governo ferem as práticas ágeis. Porém, na minha opinião, existem maneiras de ao menos cobrar desenvolvimento iterativo dos fornecedores para reduzir o risco com entregas parciais.

Na semana passada ministrei nosso curso Scrum para uma turma de 20 pessoas do Banco Indusval Multistock.

O Banco Indusval Multistock S.A. é um banco privado com 40 anos de experiência de atuação no mercado financeiro brasileiro. Desde 1993, suas atividades encontram-se focadas em um dos segmentos que o Banco considera dos mais atrativos do mercado de crédito: crédito a empresas médias.

A equipe deles desenvolve seus softwares em PHP e busca utilizar o Scrum como mecanismo de controle de projeto para iniciar uma melhoria de seus processos, buscando uma melhor interação entre o desenvolvimento e as áreas de negócio. Este tipo de necessidade beneficia muito a adoção do Scrum, pois toda instituição financeira é bem focada na busca por resultados rápidos.

Seria muito legal se esta moda pegasse em grandes instituições financeiras como Itaú, Bradesco, Unibanco e muitos outros! Infelizmente os projetos que desenvolví para grandes bancos sempre eram escopo fechado, foco em documentação e mais alguns toques cascateiros. Uma coisa para os CIOS dessas empresas pensarem a respeito.

Na semana passada ministrei nosso curso Scrum para nossos amigos da empresa FórumAccess. A FórumAccess é um excelente exemplo de consultoria pequena que o Phillip Calçado tanto fala. É uma empresa com mais ou menos 100 desenvolvedores que já está trilhando o caminho da Agilidade de maneira intuitiva. Com o treinamento eles de fato adotarão o Scrum para gerenciar os projetos.

Mais um treinamento com uma bela paisagem!
(essa ponte é linda na foto, mas ao vivo ela estraga a paisagem)

Uma das coisas que mais me chamaram a atenção na FórumAccess é a adoção de contrato de escopo negociável, apesar das dificuldades em vender este tipo de contrato no mercado. Eles são um dos poucos exemplos de empresa que oferecem este tipo de contrato (aqui em São Paulo são pouquissimas empresas que aplicam isso).

Como o Vinícius Telles explicou muito bem na sua palestra do TDC 2008 e também no vídeo sobre desperdício de funcionalidade, seu objetivo como desenvolvedor de software não é entregar tudo, mas sim, entregar aquilo que mais agrega valor para o cliente. O contrato de escopo negociável favorece isso.

Equipe 1

Equipe 2

Escrevendo User Stories

A homepage mais feia do mundo

Todo mundo

Tudo começa no planning

Agradeço a todo pessoal da FórumAccess pela troca de informações rica, principalmente sobre como o mercado tem se comportado com os contratos de escopo negociável. Essa mudança de cultura é muito importante para melhorar nosso mercado. Eu realmente acredito que consultorias menores e mais concentradas em entregar valor são alternativas melhores que as fábricas de software gigantes e burocráticas.