Débito Técnico

Em dezembro a Aspercom treinou 20 pessoas da Remaza e SGIweb em práticas ágeis de gerenciamento de projetos com o nosso treinamento Scrum. Creio que o consórcio Remaza dispensa apresentações. A SGIweb é o empreendimento das Empresas Remaza focado no segmento tecnológico em produtos e serviços de software.

O produto principal da SGIweb são produtos e soluções para Procurement e B2B integradas com ERP e vendidas como serviços entre mais de 65.000 empresas participantes. Para maiores informações, visite o site do WebSupply em www.websupply.com.br. Foi muito legal ministrar este treinamento, principalmente porque a SGIweb é uma empresa com mais de 20 anos de mercado e que está inovando seus processos nas práticas Agile com vigor.

Mais um ISV para o portfólio da Aspercom, que em 2009 consolidou sua posição como a principal empresa em treinamentos corporativos e consultoria em Scrum, Extreme Programming e práticas Agile no setor. Que venha 2010!

Em novembro a Aspercom esteve em Francisco Beltrão - Paraná para ministrar os treinamentos de Requisitos e Scrum na Leosoft, empresa ISV com mais de 12 anos de mercado e focada em produtos de software para cooperativas de crédito.

A Leosoft é uma empresa que já utiliza Extreme Programming há algum tempo, tendo sido treinada pelo renomado Vinicius Teles. Ambos os treinamentos foram customizados para focar em práticas que fortaleceram a visão de negócios dos produtos da empresa junto ao mercado, já que cliente presente é um grande desafio para os ISVs. De norte a sul do Brasil é muito interessante ver como empresas com times pequenos e auto-organizados conseguem excelentes resultados em seus produtos e empresas.

Atividades práticas em grupo, muito comuns em treinamentos da Aspercom

Um ambiente informativo compartilhado na vida real

Gostaria de parabenizar a todos da Leosoft pelos excelentes bate-papos e trocas de experiências. Muito sucesso em 2010!

Quem ler esse título vai achar que eu enlouquecí depois do “O que matou o RUP pode matar o Agile“, mas o objetivo desse post é mais uma vez falar sobre mindset. Eu vejo que a grande dificuldade em entender práticas e metodologias vem de conflitos de mindset. Vou escrever mais sobre isso aqui no blog, pois vejo que combater prática contra prática ou metodologia contra metodologia é muito pouco produtivo. Os mindsets explicam tudo, apesar de ser bastante empírico escrever sobre isso. É dificil escrever sobre mind-set de maneira prática e útil sem descambar para um blá-blá-blá poético e filosófico.

Nesse artigo vou comentar sobre a polêmica que o José Papo criou primeiramente no seu Twitter. Não satisfeito postou também na Scrum-Brasil. Segue o link para a animada discussão “Scrum e PMBOK - determinadas incompatibilidades filosóficas”:

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

A discussão estava indo como sempre vai: uns defendendo, outros criticando, até que passou pela questão “certificação”. Hoje existem muitos PMPs que também são CSM, e vejo que isso é bem natural - quem tem um mindset que busca certificações é esperado que colecione-as. O Luiz Aguiar postou algo interessante, falando que agilistas de verdade não ligam para certificações. Isso é interessante para esse artigo, pois, vou falar aqui que muitos que gerenciam projetos de verdade a lá PMBOK também não ligam…
Leia o restante deste artigo »

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.

;)