Tag Archives: Agile

Professional Scrum Developer Java

Monday, 6 June 2011 Written by Felipe Rodrigues
Leave a comment

Muito tem se falado de Scrum para gestão de projetos de software, de forma que a maioria das empresas estão buscando adotar este framework. Há graus diferentes de adoção no mercado mas todos eles precisam de profissionais qualificados para ajudá-los na sua trajetória.rutoreQuando se adota Scrum em um projeto de software, nunca podemos negligenciar as práticas de engenharia de software, necessárias para assegurar a qualidade e a produtividade da equipe, assim como reduzir o custo de manutenção do software produzido. Essas práticas não são tão difundidas quanto às práticas de gestão do Scrum, mesmo quando todas as empresas que usam Scrum para software devem utilizá-las.

Diante disso, a Crafters traz o curso de Professional Scrum Developer para o Brasil e América Latina. Um curso oficial da Scrum.org, entidade mantida pelo co-criador do Scrum, Ken Schwaber e montado especificamente para a plataforma Java. Este curso oferece ao participante o conhecimento das práticas de engenharia recomendadas pela comunidade Scrum de todo o mundo, baseado na experiência e vivência de seus instrutores e criadores. Os alunos aprenderão:

Read more →
 

Prefira metas à advinhação

Monday, 14 February 2011 Written by Felipe Rodrigues
17 Comments

Um bom profissional deve ter uma ideia muito clara de quanto tempo ele demora pra realizar um tarefa. Isso pode separar os profissionais dos amadores. Dessa forma, é de se esperar que os bons profissionais consigam estimar quanto tempo vão demorar pra executar uma atividade ou outra, porém, mais do que isso, é preciso que os profissionais se responsabilizem pelos resultados em um projeto.

O que tenho visto ao longo de anos de consultoria na gestão de projetos é que em muitos times, as estimativas são usadas para compor cronogramas e definir deadlines. Isso é um problema grave, pois o time será cobrado fortemente, resultando num ciclo vicioso de super-estimativas, Síndrome do Estudante e mais cobranças.

Outro ponto desfavorável é que na maioria dos casos, independente de quais são as estimativas dos desenvolvedores, os prazos são impostos, pois já vem pré-definidos. Isso permite que os desenvolvedores se acomodem, pois não tem nenhuma responsabilidade sobre o prazo decidido. Sempre há exceções, mas no geral é assim que acontece. Não podemos nos comprometer com prazos definidos por terceiros.

Definindo metas ao invés de adivinhar

A abordagem que eu sempre busco é ser pró-ativo. Não acho que devamos deixar o resultado das coisas nas mãos de algum fator externo. Uso esse mesmo conceito para estimativas. Posso tentar “adivinhar” em quanto tempo irei concluir algo, baseado em vários fatores como histórico, sentimentos e outros dados.

Quando eu tento adivinhar, estou simplesmente assumindo que o resultado é incerto. Dizendo que talvez eu acerte, talvez eu não acerte e isso depende de uma série de fatores. Se eu não acertar, tudo bem, afinal de contas, era apenas uma estimativa. Não preciso me comprometer para atingir uma adivinhação. Se eu errar, foi porque não previ algo que estava por vir e isso afetou o resultado. Coitado de mim, fui pego de surpresa. Isso não é ser pró-ativo.

A outra opção é definir uma meta clara de tempo para a conclusão daquela atividade. Simples assim. Vou usar minha experiência, histórico, sentimentos e outros dados. A diferença aqui é que também vou acompanhar a evolução do meu trabalho para saber se vou atingir a meta ou não. Terei a preocupação de buscar melhores caminhos para chegar ao meu objetivo. Minhas decisões e ações serão direcionadas para que eu atinja a minha meta.

Crie metas SMART

Num exemplo mais claro, ao estimar uma atividade de tamanho X, posso tentar adivinhar, baseado em histórico, que demoraria 2 semanas pra terminar. Ao definir uma meta, posso levar em consideração o fato de que o ideal seria que eu terminasse em 1 semana apenas. Penso o seguinte, ignorando a estimativa de 2 semanas, o que posso fazer para conseguir concluir essa atividade em 1 semana?

Da mesma forma, poderíamos dizer que ao invés de 1 ou 2 semanas, a minha meta é terminar em 4 semanas, já que não há mais nada pra fazer e não será necessário ter esse resultado antes disso. Podemos assim aplicar o conceito do Último Momento Responsável, disseminado pelo Lean como LRM (Last Responsible Moment).

Metas devem ser SMART

Temos ainda que analisar se essa meta é viável ou não. É bom que todas as metas sigam o padrão SMART: Specific, Measurable, Attainable, Realistic e Time-Boxed.

Para conseguir definir uma meta SMART, precisamos ter um histórico, precisamos de experiência e de muita atenção. Mas definir uma meta é muito diferente de simplesmente dizer quanto tempo você leva pra realizar algo. É assumir a responsabilidade em relação ao resultado. Uma meta SMART é uma meta em que as pessoas acreditam que conseguirão atingir. É realista.

Quando iniciamos uma jornada em direção à uma meta, devemos medir nosso progresso constantemente, para saber se a meta continua realista e possível. Por isso sua meta precisa oferecer forma para medir a evolução.

Precisamos garantir que a meta seja relacionada à algo específico. Facilitamos o trabalho de realização, organização e acompanhamento de uma meta quando restringimos a quantidade de variáveis e contextos que influenciam uma meta. Dessa forma, precisamos buscar ser específicos em relação à meta.

A parte da estimativa na prática se refere à definição de um período de tempo em que se deseja atingir a meta. Para saber se a meta é realista e possível de ser atingida, precisamos usar toda a nossa base de histórico e experiência, para questionar a meta. Isso acontece após a definição da meta.

Esses conceitos tem se mostrado muito eficientes quando aplicados em times de desenvolvimento de software, principalmente em conjunto com outras práticas ágeis. Em alguns lugares, a aplicação ou ausência desse mind-set foi determinante para o sucesso ou fracasso de projetos.

E na sua empresa, os desenvolvedores definem metas ou adivinham quanto tempo irão levar? A gestão respeita a avaliação do time em relação às metas de um projeto?

Read more →
 

Equilíbrio P/CP

Wednesday, 1 December 2010 Written by Felipe Rodrigues
11 Comments

Como sempre, vivo lendo o livro dos 7 hábitos das pessoas altamente eficazes. Esse livro me acompanha já há alguns anos e constantemente volto a ele, como que pedindo socorro para lidar com as situações do dia-a-dia. Ele parece com um livro de auto-ajuda, mas não deve ser subestimado. É um livro que pode mexer intimamente com aqueles que tem a humildade e abertura necessária.

Um dos conceitos que tenho explorado bastante ultimamente foi algo que aprendi neste livro. É preciso manter um equilíbrio entre Produção e Capacidade Produtiva. Todo nosso trabalho pode ser justificado como um esforço para produzir algo. Esse “algo” é a nossa produção. A nossa disposição, força e vontade para gerar produção é a nossa Capacidade Produtiva. Dessa forma, manter o equilíbrio entre a Produção e a Capacidade Produtiva é dar manutenção em nossa disposição, força e vontade, sem perder de vista o que estamos produzindo.

No mundo do desenvolvimento de software, de um lado temos a nossa Produção: O software a ser desenvolvido. De outro lado temos a nossa Capacidade Produtiva: A força, vontade e disposição da equipe de desenvolvedores. Em algumas empresas, entre a Produção e a Capacidade Produtiva, temos um gerente de pessoas ou mesmo um gerente de projetos. Meu intuito aqui não é discutir se o gerente deve existir ou não. Mas considerando que ele exista, quero chamar a atenção para o fato de que ele pode estar sabotando a produção da equipe, simplesmente por ignorar a necessidade do equilíbrio entre P/CP.

Tenho acompanhado alguns times de desenvolvimento de software e feito coaching com alguns profissionais da área. Um ponto em comum entre eles é o atrito entre Gerência e Equipe. Isso ocorre por vários motivos diferentes e, não importa os motivos, o resultado é sempre o mesmo. A equipe chateada e a gerência também. Isso é uma realidade perde-perde. Todos saem perdendo. A equipe não produz o que poderia, ou produz de forma forçada e a gerencia tem que se desdobrar para que a equipe produza, forçando ainda mais. É um ciclo vicioso.

O que acontece é que se não mantemos a Capacidade Produtiva, desestimulamos a Produção. Como nesse caso a Capacidade Produtiva é a vontade das pessoas, devemos buscar manter um bom relacionamento, prezando pelo bem estar e conforto no trabalho. Precisamos saber ouvir melhor o que a equipe tem pra dizer. Precisamos lembrar que é a equipe que tem a capacidade de produzir software e por isso, precisamos cuidar pra estimular a força, vontade e disposição. Mas não é isso que acontece.

Tenho visto muitas empresa definirem diretrizes arbitrárias, regras de arquitetura rígidas e até mesmo imposto práticas incoerentes com as crenças da equipe. Já vi coisas do tipo: “Se não fizer assim, vamos te demitir”. Pessoas com medo de defender suas opiniões, pois podem ser demitidas. A gerencia, forçando a equipe a seguir regras que foram definidas por quem não produz o software.

Bom, isso afeta a capacidade produtiva. O resultado? Menos produção. Disposição, força e vontade são afetados e aí o que conseguimos com isso são pessoas sem comprometimento e apáticas em relação ao trabalho. Pessoas apáticas reforçam a crença da gerencia de que precisam forçar ainda mais. É um ciclo vicioso.

Esses dias, um gerente me perguntou como é que se faz pra romper esse ciclo vicioso. Ele reconheceu que era uma questão cultural. É preciso romper o ciclo vicioso e isso, muitas das vezes, é doloroso. É preciso se apoiar em princípios. É preciso viver segundo o caráter. Tratar os adultos como adultos e não como crianças que precisam de cuidado. Não é na base de ameaças que vamos motivar alguém. Há um post do Giovanni Bassi sobre Desobediência que retrata um pouco do problema com a imposição. Auto-organização e obediência cega, são conceitos que não co-existem. Impor não é ágil.

A situação é tão grave que em muitos casos, não há mais relações sociais e nem humanas, apenas ordens e obrigações. Em outros casos essas relações existem, mas estão totalmente abaladas. É um cabo de guerra. Temos que buscar restabelecer as relações humanas e sociais nesses ambientes. Ambos tem que ceder.

É preciso entender que problemas na Produção são oportunidades para melhorar a Capacidade Produtiva. Isso mesmo, problemas P são oportunidades CP. O gerentes precisam encarar os problemas das equipes como oportunidades para melhorar o relacionamento. É preciso investir em Capacidade Produtiva para usufruir da Produção. É assim com carros, máquinas, investimentos, etc. Com pessoas também é assim.

Stephen Covey friza:

Ao reconhecer que o equilíbrio P/CP é fundamental para a eficácia em uma realidade interdependente, conseguimos valorizar nossos problemas, ao considerá-los oportunidades para aumentar a CP.

Isso pode determinar se um gerente é de fato um líder ou apenas um chefe.

Você já viu isso nas empresas em que trabalhou? Tem sugestões pra resolver esse tipo de problema?

Read more →
 

O que vem depois do Agile?

Saturday, 27 November 2010 Written by Felipe Rodrigues
8 Comments

Após uma aula entusiasmada na Academia do Agile sobre liderança e coaching, cheguei em casa e me deparei com um tweet que apontava para um post do Dhanji falando sobre como eles tem experimentado com agile no Google. No post ele descreve algo que ele chama de “Cowboy Methodology”. Ele também afirma que a predominância no Google é a ausência de metodologias.

Dhanji afirma:

There are exceptions of course, many Google teams use various degrees of XP, Scrum, or something else entirely. However, these are few and far between in my experience. The lack of methodology predominates. This is not to say that software does not get written on time, nor is it to say that good code is not produced but the process under which it is, is largely non-existent.

Nesse caso, o que podemos dizer sobre a necessidade real de utilizar agile ou não em um projeto? Vi esse mesmo questionamento em tweets de pessoas que haviam acabado de ler o artigo.

Minha impressão é que muitas pessoas ainda acham que basta adotar algumas práticas de engenharia e pronto. Estamos usando agile. Seguir uma receita que contém várias práticas não determina que você está usando Agile ou não. Utilizar Scrum não quer dizer que sua empresa é de fato ágil. Ultimamente, tenho ouvido frases como: “Nós usamos Scrum na minha empresa, mas não posso dizer que somos ágeis de fato. ”

Isso ocorre pelo simples fato de que, mesmo algo simples como Scrum pode ser “camuflado” para satisfazer uma cultura rígida. Tem faltando cultura real nas empresas e isso minimiza em muito os efeitos do uso do Scrum, XP ou qualquer outra metodologia. A cultura é a essência da agilidade e não pode ser substituída.

O meu entendimento é que Scrum, XP e qualquer outra metodologia é muito útil no início. Serve como um impulso inicial, que revelará onde e como podemos corrigir nossa postura e como podemos buscar resultados melhores. No entanto é preciso muito cuidado e atenção para que, ao longo do caminho, identifiquemos quais são as mudanças culturais necessárias para que a agilidade possa de fato emergir.

Uma vez que essa cultura ágil esteja consolidada, aí podemos partir em busca de um processo único, adaptado e adequado à nossa realidade. Acredito que seja isso que esteja acontecendo com o Google. Vários dos princípios que compõe a agilidade já fazem parte do mind-set dos Googlers. Escolher e participar da formação das pessoas, faz com que esse tipo de possibilidade exista dentro do Google. Não é necessário seguir algo prescrito, quando temos maturidade suficiente para decidirmos o nosso próprio caminho. Nisso consiste a agilidade.

Considerando que o mercado enxerga “Agile” como um substantivo que descreve um conjunto de metodologias que apesar de empíricas são prescritas de forma generalizada sem considerações dos contextos em que serão aplicadas. Dessa forma posso seguramente afirmar que o que vem depois do “Agile” é a verdadeira agilidade. A diferença é sutil e, por isso, é preciso que validemos constantemente nossas decisões, práticas e processos, segundo os princípios e valores nos quais acreditamos.

E pra você? O que vem depois do Agile? Compartilhe sua opinião.

Read more →
 

Um case de implantação de Agile

Thursday, 18 November 2010 Written by Felipe Rodrigues
Leave a comment

Uma empresa não se faz somente de capital inicial e nem apenas de conhecimento técnico. Uma empresa é composta por pessoas. Cada pessoa conta com crenças, limitações e experiências que contribuem para a formação de seu caráter e perfil profissional.

Na Crafters nós buscamos reunir um grupo de pessoas que tenham interesses comuns, crenças compatíveis e muita experiência real. Não nos interessa apenas buscar currículos impressionantes com muitos números. Queremos pessoas reais, que conhecemos e que estejam envolvidas com as comunidades das quais participamos. Isso nos permite manter um grau de expertise e alinhamento raro no mercado.

Proposta Inicial da Wareline

Há mais ou menos 2 anos atrás, uma empresa chamada Wareline nos procurou para que ajudássemos a migrar seu ambiente de desenvolvimento para a plataforma Java com foco na web. Apesar de continuar no suporte e evolução da aplicação desktop, eles queriam desenvolver um produto inovador. Algo novo e que sobrepusesse à concorrência. Queriam algo muito além do que já tinham feito.

Decidiram assim que iriam desenvolver seu principal produto, um ERP hospitalar, mas agora, voltado para o ambiente Web. Dentre as diversas tecnologias, escolheram a plataforma Java. Propusemos a utilização da linguagem Groovy e do framework Grails, visando assim minimizar a curva de aprendizado.

Considerando que boa parte dos desenvolvedores não conheciam a nova tecnologia, havia o risco de atrasos e erros nas estimativas de forma que um processo tradicional de desenvolvimento só prejudicaria o  projeto. Não havia margem para erros e desperdícios. O projeto precisava ser impecável.

Nesse contexto, sugeri a adoção de algumas práticas de engenharia mais atuais. Práticas que surgiram conforme a necessidade do cliente e não porque faziam parte de alguma metodologia, mas porque agregavam valor naquele momento.

O processo

Iniciou-se então a definição de um processo de desenvolvimento de software customizado e adequado para a Wareline. Muitos dos envolvidos nem sabiam que era um processo baseado em premissas do Agile. Só ficaram sabendo muito tempo depois. Isso porque conseguimos chamar a atenção apenas para aquilo que era importante. Desenvolver software que funciona.

Neste processo haviam práticas de Scrum, Feature Driven Development, Extreme Programming, Domain Driven Design, Behavior Driven Development e algumas outras coisas. O objetivo era que o processo minimizasse os riscos e aumentasse a visibilidade sobre o andamento do projeto. Isso foi alcançado.

O levantamento de requisitos era feito utilizando conceitos do BDD. Utilizando user stories que se transformavam em especificação executáveis dentro do framework. Havia ainda um quadro kanban que determinava um processo puxado de desenvolvimento. O uso de iterações e algumas das cerimonias do Scrum, como Daily Scrum, Review e Retrospectiva também são utilizados.

Do FDD, trouxemos o conceito de inspeção de código, muito útil pra alinhamento e nivelamento do código produzido, já que nem todos eram muito acostumados com a tecnologia. Para que a inspeção tivesse um efeito mais adequado, utilizado uma definição de pronto, ou DoD (Definition of Done). Consistia num checklist que determinava quando uma funcionalidade poderia ser considerada pronta.

Problemas no andar da carruagem

Com a aplicação da inspeção, a equipe começou a perder muito tempo inspecionando o que estava pronto. O tempo de inspeção consumia várias horas da equipe, pois após a inspeção, havia muita discussão sobre qual seria a forma correta de se fazer algo. Isso começou a prejudicar a velocidade da equipe.

Para resolver esse problema, começamos a utilizar algumas práticas. Uma delas foi a programação em par. Agora os profissionais deveriam programar com um co-piloto ao lado. Além disso, os pares deveriam ser trocados a cada período de 4 horas. Isso garantia mais alinhamento sobre o que deveria ser feito e sobre qual era a melhor solução para cada funcionalidade.

Mesmo com a programação em par, acontecia de alguns pares caminharem em direções diferentes do que os outros achavam. Isso refletia um problema no entendimento do domain que estava sendo tratado. Iniciamos então o uso de diagramas de fluxo de informações similares aos propostos pelo Domain Driven Design. Esses diagramas deveriam ser elaborados de forma colaborativa entre os membros da equipe, buscando o alinhamento no que diz respeito ao que o Domain realmente é. Essas duas práticas fizeram total diferença no projeto.

Adaptação acima de tudo

Implementar agile não é algo que requer experiência e estudo. Não basta termos uma certificação e muito menos basta ler o Scrum Guide (apesar de necessário). É preciso vivência. Os profissionais da Crafters tem vivido de agile há um bom tempo já. Participaram de implementações grandes e pequenas de processos. Isso é fundamental.

Minha primeira implantação de agile aconteceu por volta de 2005 em um projeto da IBM e foi totalmente baseado em XP. Antes disso eu já estava atento às mudanças de paradigma propostas pelo Agile e participava de alguns projetos que já utilizavam desse paradigma.

Com essa experiência já vi muitos projetos irem por água abaixo ao tentar implantar agile. Alguns porque focaram muito em práticas de engenharia e esqueceram da gestão. Outros fizeram o oposto, focaram em gestão e esqueceram da engenharia. É preciso ter equilíbrio. Não basta seguir as regras “by the book”, é preciso se adaptar muito rápido e, a adaptação já começa a partir da concepção do processo. Só assim para termos sucesso em um ambiente tão complexo quando esse do desenvolvimento de software.

Read more →
 

Lean – Do desperdício ao desenvolvimento de pessoas

Wednesday, 1 September 2010 Written by Felipe Rodrigues
Leave a comment

Reduzir o desperdício ou otimizar qualquer forma de trabalho é um grande desafio, pois não basta apenas eliminar tarefas julgadas como desnecessárias, mas sim, trata-se de uma grande mudança na mentalidade das pessoas para que seus comportamentos sejam melhores e também “mais enxutos”. É disso que trata o Pensamento Lean (Lean Thinking).

Lean é um conceito cunhado a partir das experiências oriundas do ambiente organizacional vivido ao longo dos anos pelo TPS (Toyota Production System), mas que ganhou notoriedade na década de 90 por meio da publicação de livros e de experimentações em outras companhias ao redor do mundo. Esse texto visa apresentar um pouco da essência e principalmente de três importantes pilares do Pensamento Lean.

Na realidade é difícil conceituar o que é Lean, mas para ajudar esse entendimento, é necessário antes compreender que:

  • Lean não é apenas um processo,
  • Lean não é um conjunto de técnicas,
  • Lean não é apenas redução de custos,
  • E por último, Lean não é tangível.

Por essas ideias expostas a acima, fica claro que na verdade Lean é uma verdadeira filosofia, dessa maneira, sua adoção permite uma mudança no jeito de pensar de toda uma organização e, consequentemente altera o comportamento de todas as partes da mesma.

Para sustentar essa mudança de pensamento e de comportamentos, o pensamento Lean possui 3 grandes pilares, são eles:

  • Eliminar o desperdício – Este pilar tem como objetivo reduzir atividades que não agregam valor e focar nas que realmente agregam valor para o resultado final. É importante observar que a percepção do o que é ou não é valor, é totalmente relativo de um contexto para outro, mas de maneira geral, a principal visão a ser seguida é: Por quais atividades do processo de criação/produção o cliente está disposto a pagar?
  • Melhorar Continuamente – Por meio do aprendizado contínuo é que se torna possível a melhoria contínua.  Esse aprendizado tem como ideia base o ciclo PDCA (Plan, Do, Check, Action), que é aplicado na esfera de produto (resultado) e de processo (forma de trabalho). Por isso, para garantir a melhoria contínua, é realizada de maneira sistemática uma profunda reflexão (Hansei) para identificar os pontos de alavancagem para melhoria (Kaizen) na organização.
  • Respeitar as pessoas – Esse talvez seja o mais importantes dos pilares Lean. Por meio do Respeito às Pessoas, os demais pilares se tornam possíveis.  É possível citar dois exemplos dessa importância do respeito às pessoas:
  1. Quando existe respeito pelos clientes da empresa, busca-se gerar o maior retorno possível para seus investimentos financeiros e principalmente, melhorar a percepção de tempo despendido pelos clientes durante uma experiência de consumo.
  2. O segundo exemplo de respeito é quando se contribui para o desenvolvimento das pessoas que colaboram com a organização. Esse respeito também ocorre por meio da valorização dos talentos individuais, de modo que os mesmos não sejam desperdiçados em atividades que não agregam valor para a empresa.

Esse texto apenas abordou o supra-sumo de toda a filosofia por trás do Lean, pois devido a grandeza desse pensamento, é necessário um considerável tempo de experimentações para que se crie uma verdadeira (e consistente) cultura de longo prazo dentro de uma organização. É importante ressaltar que para criar verdadeiras mudanças num todo, é necessário que cada pequena parte desse todo, adote e seja a mudança dentro do sistema, por isso, você que também faz parte de um todo, responda para si mesmo: Sua vida é Lean?

__

Manoel Pimentel,  @manoelp, é Engenheiro de Software, com 15 anos na área de TI, atualmente trabalha como Coach PPC) em Agile e Lean para empresas do segmento de serviço, financeiro e bancário. É Diretor Editorial da Revista Visão Ágil e já escreveu sobre agile para portais e revistas do Brasil e exterior.  Também possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.

Read more →
 

Seja Empreendedor

Tuesday, 27 July 2010 Written by Felipe Rodrigues
Leave a comment

Há alguns anos a Fratech iniciou suas atividades na área de TI. Tivemos sucessos e fracassos ao longo de 4 anos e meio de atividades. Fizemos barulho ao realizar o Java Brasil, ao participar do início e manutenção da comunidade Visão Ágil, ao trazer o InfoQ para o Brasil e ao lançar uma das primeiras formações completas para Agile do mercado. Temos cases interessantes de implantação de Agile e mentoring técnico e agora temos focado em software craftmanship para clientes (Isso quer dizer que se você quer desenvolver um software, pode nos procurar que podemos lhe ajudar a desenvolvê-lo).Semente O importante de se notar neste caso é que resultando em falha ou sucesso, tudo que fizemos foi com muita intensidade e paixão. Isso é o mais importante, pois o mercado acaba por perceber seu empenho e recompensá-lo. Tudo o que fizemos na Fratech ao longo destes anos foi feito com espírito empreendedor. É sobre este espírito que quero falar agora.

Estimular o Progresso Econômico

Empreendedorismo possui uma ampla gama de significados, o que pode dificultar o entendimento sobre o que é empreender. Vou trabalhar com algumas citações para tentar expressar o que é ser empreendedor. Ao começar pela origem da palavra, vou utilizar a citação do wikipedia:

A palavra empreendedor (entrepreneur) surgiu na França por volta dos séculos XVII e XVIII, com o objetivo de designar aquelas pessoas ousadas que estimulavam o progresso econômico, mediante novas e melhores formas de agir.

Gosto de destacar que esta palavra tem por objetivo definir pessoas que estimulam o progresso econômico, sejam em um bairro, cidade, estado, país ou no mundo todo. Recentemente temos visto exemplos de todos os tipos. Pessoas que tem influenciado uma multidão de pessoas, fundamentado em seu sucesso na inovação e na forma de conduzir seus negócios. Este é o caso da empresa 37signals, que basicamente criou um novo modelo de negócios, focado em praticar o empreendedorismo. Sei de várias empresas que acharam nichos de atuação baseados nisso. A 37signals estimulou o progresso econômico no mundo todo. Os governos normalmente estimulam a prática do empreendedorismo. Nós também deveríamos estimular, se quisermos participar de um país com mais igualdade social e renda per capita equilibrada. O fato é que quanto mais empresas de sucesso, mais empregos, mais dinheiro na mão dos consumidores e menos risco, aumentando os investimentos externos. Simples assim. Por isso, devemos estimular, apoiar e dar preferencia àqueles que empreendem. Marcelo Bevenuto descreve:

O empreendedor é aquele que detecta uma oportunidade e cria um negócio para capitalizar sobre ela, assumindo riscos calculados.

Devemos respeitar a coragem dos empreendedores, pois são pessoas que deixaram a comodidade para buscar um ideal diferente, enfrentando riscos.

Fazer acontecer

Outra citação interessante define o empreendedor como alguém prático e pro-ativo. Robert Menezes diz:

Empreendedorismo é a arte de fazer acontecer com motivação e criatividade.

O empreendedor precisa ser criativo, pró-ativo e prático. Tem que ser um bom gerente e um ótimo líder. Tem que saber definir metas e objetivos e se manter fiel a eles. Tem que viver baseado em princípios corretos, para que seja capaz de aumentar seu círculo de influência e assim ser capaz de fazer cada vez mais. Jeff Trimmons diz:

O empreendedor é alguém capaz de identificar, agarrar e aproveitar oportunidade, buscando e gerenciando recursos para transformar a oportunidade em negócio de sucesso.

Para ter sucesso em um empreendimento, é preciso cultivar habilidades dignas de um empreendedor. É preciso ser persistente e visionário, é preciso acreditar, além de ter um bom conhecimento da área em que pretender atuar.

Empreendedor 2.0

Para que um empreendimento dê certo, antes de mais nada, é preciso de pessoas comprometidas. Essas pessoas podem não ser tão visionárias quanto o empreendedor inicial, mas devem ser empreendedoras também. Devem querer participar ativamente do processo. Devem ter uma postura 2.0. Para que tudo isso aconteça, o empreendedor deve estimular a participação ativa das pessoas. Deve criar uma relação de confiança, que permita a segurança e conforto dos envolvidos. Deve definir, coletivamente, uma missão para o empreendimento. Deve esclarecer quais são as expectativas para os resultados de todos os papéis. Deve compartilhar sua visão para com os demais e dessa forma, receber em troca o comprometimento e afinco. Obviamente, deve ter a sorte de encontrar pessoas que correspondam a este esforço. Chamo isso de empreendedorismo 2.0, porque para atender a essas premissas, é preciso se desvincular de alguns métodos tradicionais. Os métodos tradicionais normalmente focam o controle absoluto por parte de uma pessoa, com o pretexto de permitir uma melhor análise dos riscos e controle sobre a situação. O problema é que isso inibe a criatividade e participação das outras pessoas, o que ao meu ver é fundamental para o sucesso de um empreendimento. Práticas mais flexíveis e que permitam respostas rápidas à mudança não exigem que você saiba o que irá acontecer no futuro com muita antecedência, pois você é capaz de se adaptar rapidamente. Isso permite que o controle e coleta de métricas seja colocado em segundo plano, facilitando a ênfase na captação de ideias e soluções para os problemas do dia-a-dia. Soa bem ágil aos ouvidos, não é?

Seja empreendedor

Esta mensagem se destina àqueles que por alguma razão não estão satisfeitos com o seu trabalho atual e que adorariam mudar de perspectiva. Vocês deveriam começar a empreender a partir de hoje. Não precisam nem largar os empregos imediatamente, mas deveria iniciar a partir de hoje. Escolher uma das muitas ideias em sua cabeça e começar a amadurecê-la. Definir um plano estratégico de ação, imaginando como seriam os primeiros meses de seu novo empreendimento. Pergunte-se: Qual tipo de pessoa eu quero trabalhando comigo? Qual o salário eu quero lhes pagar? O que eu quero fazer? Como eu quero fazer? Para qual tipo de cliente? Qual o tipo de ambiente de trabalho eu quero? Qual será a minha perspectiva daqui à 6 meses? O objetivo destas perguntas não é obter respostas verdadeiras ou garantir que as coisas irão acontecer da forma que você respondeu. O objetivo é conduzir você a imaginar o futuro de seu empreendimento, permitindo contemplar e avaliar seus objetivos e metas, para assim, definir quais são os fundamentos de seu empreendimento. uma vez definidos os fundamentos, trabalhe nos princípios e filosofia. Tenha personalidade. Seja persistente e visionário. Estimule o progresso econômico. Seja empreendedor.

Read more →
 

Liderança e Agile

Monday, 22 March 2010 Written by Felipe Rodrigues
Leave a comment

Como estamos próximo ao início da primeira turma da Academia do Agile, a pesquisa referente aos temas que serão tratados se intensifica. O primeiro módulo tratará sobre implantação e liderança de equipes ágeis. Neste post tentarei expressar a diferença entre liderança, gerenciamento e produção. Frequentemente confundimos esses papéis. Algumas vezes achamos que aqueles que vão à frente são os líderes. Outras vezes achamos que aquele que organiza e dá ordens é o líder. Em minha experiência, nenhum dos dois casos reflete liderança. Homem olhando engrenagens Imagine o caso em que precisamos apoiar uma escada em uma parede e subi-la. Alguém pode pegar a escada, apoia-la em uma parede e começar a subir. Outro pode simplesmente segurar a escada, para que ela não balance ou caia. Uma terceira pessoa pode dizer: “Ei, a parede certa é esta aqui.”. Qual destes é o líder? O primeiro indivíduo tem um papel importante na execução e tem méritos por isso. Teve a iniciativa de pegar a escada, sem que ninguém o mandasse fazer isso. Ele sabia que precisava subir e imaginou: “Preciso de uma escada.”. Esse tipo de pensamento é fundamental para que tenhamos eficiência na execução de qualquer projeto. Porém isso não é liderança, é produção. O primeiro indivíduo é um produtor. O segundo indivíduo, identificou que o primeiro precisava de suporte e facilitação. Decidiu, por iniciativa própria apoiá-lo. Segurou a escada sem que ninguém o mandasse. Mais uma demonstração de iniciativa. A diferença aqui é que este é o organizador, ou gerente se preferir. O papel dele é facilitar o trabalho dos produtores. Cuidar para que consigam realizar as tarefas sem que os obstáculos os atrapalhem. O terceiro indivíduo tem a visão da situação, conhece o objetivo real e é capaz de determinar a direção em que devemos caminhar. Mais do que isso, apesar de não fazer parte da ação, é capaz de influenciar as pessoas a olharem para a direção certa. Este é o papel do líder. Imagino que muitos que leem este artigo ainda relutam, achando que o líder deve ser também o facilitador, porém, quando o líder está muito envolvido na execução, é fácil cair em uma armadilha que Stephen Covey, em seu livro Os 7 Hábitos das Pessoas Altamente Eficazes, chama de “A Armadilha do gerenciamento”. Stephen explica que quando confundimos liderança com gerenciamento, nos afundamos em um mar de situações a serem resolvidas. Essas situações acabam sugando toda a nossa energia e logo, não temos tempo para liderar de fato a equipe e trabalhar os aspectos menos visíveis, como cultura, princípios e visão das pessoas envolvidas. Segundo Peter Drucker, “Gerenciar é cuidar para que façam as coisas do jeito certo. Liderar é cuidar para que façam as coisas certas.”. Citando Stephen Covey em uma analogia sobre isso,

“Gerenciamento determina o grau de eficácia necessário para subir mais rápido a escada do sucesso. A liderança determina se a escada está apoiada na parede certa.”.

Vale notar que ambos são importantes, e complementares e talvez, em alguma situação, possa ser executado pela mesma pessoa. No entanto, é importante frisar que um gerenciamento excelente não compensará um má liderança.

Liderança no Agile – Scrum Master não é um líder

Com essa divisão clara das responsabilidades, podemos nos perguntar como a liderança seria refletida em relação ao agile. Com todo o conceito de auto-gerenciamento e equipes auto organizadas, vemos que o papel de gerente como uma pessoa externa se dissipou. Cada um dos membros da equipe agora são responsáveis por gerenciar e produzir. Isso consiste no direto de ter as condições necessárias para executar o trabalho, porém também consiste na responsabilidade de cuidar para que o outro também tenha. Apesar disso, a grande maioria das metodologias definem a necessidade de alguém para focar na organização. Alguém que seja responsável por resolver impasses e facilitar a remoção dos obstáculos. Este é por vezes chamado de Scrum Master ou de coach (no sentido de técnico). Este papel é um papel de gerenciamento, conforme definido acima, e não um papel de liderança. Isso fica bem claro quando reafirmamos o que é liderar. Liderar é definir claramente objetivos e metas estratégicas. Para definir esse tipo de objetivo e meta, é preciso contextualização, planejamento estratégico, visão ampla do todo. Líder Um Scrum Master se limita aos impedimentos da equipe, logo, não pode ser um líder, mas sim um gerente. Alguém que cuida para que tudo siga o protocolo. Alguém que reforça a necessidade de cumprir as metas. Mas então quem é o líder neste caso?

O líder

Ao meu ver, o líder é o cliente, ou product owner. É ele quem define quais são as prioridades e quais são as metas e objetivos de um projeto. O cliente define o que é necessário alcançar e a equipe é livre para definir como trabalhar para alcançar estes objetivos. Não podemos de forma alguma cometer o erro de afirmar que exista uma liderança técnica em uma equipe, pois a parte técnica expressa o como fazer, e não o que fazer. Podemos ter gerentes técnicos, que facilitam, suportam e orientam como fazer algo de forma correta. Mas é preciso que entendamos que o objetivo real é definido pelo cliente/P.O.. Qualquer prática empregada no processo que expresse a execução é meramente definida por questões de gerenciamento. O líder neste caso, precisa confiar que o gerenciamento fará o melhor para alcançar as metas e assim, eliminar esta preocupação de sua mente, ficando livre para focar na estratégia. O líder deve ainda ser capaz de repensar a direção definida quando houver alguma mudança. E a equipe deve ser capaz de responder à esta mudança de forma ágil. Isto é agilidade. Gostou? Aprenda mais sobre implantação e liderança de equipes ágeis na Academia do Agile.

Read more →
 

Manifesto TI 2.0

Thursday, 11 March 2010 Written by Felipe Rodrigues
Leave a comment

Nós da Fratech temos acompanhado um pequeno movimento que aos poucos vem ganhando força. Até o momento ele possui vários nomes e ainda está para ser centralizado. Alguns o chamam de Manifesto 2.0, outros o chamam de Pensamento 2.0, há ainda aqueles que dizem que é um “Movimento Anti-Corporativista”. O interessante é que este movimento tem partido de grandes nomes do agile no Brasil.

Manoel Pimentel, Editor Chefe da Revista Visão Ágil, é um dos pioneiros do Agile no Brasil e recomenda, em seu post no blog da Visão Ágil, não cresça:

…caso você esteja iniciando uma empresa nesse momento, permita lhe dar uma pequena sugestão: “Não Cresça!”.

Ele explica o motivo:

Essa minha humilde opinião é oriunda da constatação de que as empresas ditas como “grandes” têm uma complexidade de funcionamento e de pensamento tão evidente, que simplesmente é muito difícil ou até mesmo impossível fazer as coisas certas acontecerem nessas organizações.

Vinícius Manhães Teles da ImproveIt desabafa em um post oriundo de uma discussão na lista da Visão Ágil:

O que uma empresa produz é resultado de como ela está estruturada. Quem tem autoridade para dizer como deve ser a estrutura de uma empresa é quem está no topo. Então, a estrutura de qualquer empresa é, no fim das contas, o resultado do modo de pensar, da mentalidade, de quem está no comando. A mentalidade da maioria dos empresários, diretores e gerentes no mundo inteiro é, com raríssimas exceções, arcaica e incompatível com o trabalho de desenvolver software. Quando o topo da empresa não entende o tipo de mentalidade necessária para se desenvolver software de forma bem sucedida, não há santo que possa fazer milagre. E eu garanto, a maioria absoluta das pessoas que estão no comando das empresas não entende uma vírgula do que significa desenvolver software. Isso inclui, certamente, a maioria absoluta dos CIOs. Não é à toa que eles buscam recorrentemente coisas como CMMI, PMBOK, MPS.BR, ITIL etc, todos absolutamente incompatíveis com a NATUREZA do desenvolvimento de software.

Em contra-partida, Alexandre Magno concorda que é necessária uma mudança radical, em sua palestra sobre Utilização de Scrum no alto gerenciamento da empresa.

…Na comunidade tem gente muito boa aplicando Scrum em projetos de TI. Mas isso não é suficiente para mudar a cultura das empresas…

…quando o Scrum é aplicado em uma única área, esta área sofre pressão das outras áreas ao seu redor…

Mas lembra:

Os altos executivos tem a mente aberta e querem resultados, independente da metodologia

Isso que nos leva a acreditar que o problema é falta de confiança por parte dos executivos em relação às pessoas. Isso ficou bem claro no evento Scrum Gathering, quando Ricardo Vargas do PMI relatou:

…seria ótimo se todos fossem pig (comprometidos com o resultado), mas a grande verdade é que a maioria das pessoas são chicken (não se importam com o resultado), só querem saber do salário no fim do mês…

Alexandre Gomes, Diretor da Sea Tecnologia e figura muito respeitada no meio de desenvolvimento de Software, discorda e vai além, apresentando o conceito um pouco mais a fundo, em seu post sobre o Manifesto 2.0:

Vemos então dois momentos históricos bem distintos, dois modelos de pensamento bem claros ou, como temos dito, duas escolas bem definidas. E o melhor (ou pior) é que não se trata de um evento exclusivo da TI. Pelo visto, é algo de dimensões ainda não muito definidas pra nós, também presente em outras áreas do conhecimento. Especulamos que chamarão isso no futuro de algum nome. Talvez pós-modernidade, realismo-moderno, whatever. Não vale a pena tentar definir um nome pra isso agora. Melhor observar, aprender e ter a sobriedade para colher seus melhores frutos.

Dentre vários pontos importantes, Alexandre menciona a visão dos Recursos Humanos no modelo tradicional e como isso passa a ser tratado como gestão de Pessoas no modelo 2.0

Na visão tradicionalista, profissionais são vistos como máquinas, com comportamentos determinísticos, produtividade contínua e de fácil substituição.

A nova visão, felizmente, já compreendeu que profissionais não são máquinas, mas pessoas que sofrem de alegria, tristeza, motivação, depressão, cansaço, empatia e vários outros aspectos que influenciam em seu trabalho. Por isso, é tão complexo extrair métricas precisas de sua produtividade. Afinal, cada dia é um dia, cada projeto é um projeto e cada equipe é uma equipe. Na mesma linha, a substituição de profissionais também não é matemática. A sinergia entre os membros de uma equipe são fatores ímpares para sua motivação e produtividade. Trocar seis por meia dúzia pode por toda a dinâmica do grupo abaixo.

Como conclusão, percebemos uma grande sinergia da comunidade ágil em busca de um novo modelo da gestão, que preza:

  • mais qualidade e flexibilidade do que comportamentos determinísticos
  • mais conforto e humanidade do que números de medição de produtividade
  • mais reflexão e pensamento do que atividades repetitivas

 

Este é o modelo 2.0 que vem surgindo em meio ao movimento Ágil no Brasil e que acredito ter suas próprias vertentes no mundo.

Read more →
 

Domain Driven Design – Quando o gavião come a barata?

Saturday, 5 September 2009 Written by Felipe Rodrigues
6 Comments

Há algum tempo (mais ou menos 4 anos) venho estudando e aplicando Domain Driven Design em diversos projetos. Normalmente meu trabalho nos projetos é planejar e construir a arquitetura dos sistemas ou avaliar e corrigir arquiteturas criadas por outras pessoas. Não precisa nem dizer qual dos dois eu prefiro né?

Para que eu possa expressar melhor o motivo que me levou a especialização em Domain Driven Design preciso voltar ao meu primeiro curso de Orientação a Objetos. Lá estava eu (há 7,5 anos atrás) com experiência em linguagens como C, Pascal, Object Pascal (Delphi), mas sem nenhuma noção do que era um “objeto”. Após uma breve explicação dos conceitos, vieram os exemplos de meu professor:

Lê-se: “Gavião é uma Ave que é um Vertebrado que é um Animal” e “Barata é um Inseto que é um Invertebrado que é um Animal”.

Quando eu comecei a entender essas relações eu imediatamente comecei a pensar nas diversas interações entre esses objetos. E comecei a pensar em como expressar as situações utilizando esses objetos. Como exemplo, pense na seguinte situação:

“O Gavião normalmente come a Barata.”

Uma forma de expressar isso em orientação a objetos seria:

Que resultaria em :

Pronto… código muito simples e de fácil compreensão. Isso não passa de orientação a objetos. O importante é entender a quantidade de práticas envolvidas neste exemplo e que só pude perceber depois que comecei a estudar Domain Driven Design.

O processo

Implementar Domain Driven Design implica modificar a cultura de desenvolvimento de software que hoje está impregnada nas maioria das empresas. Domain Driven Design significa desenhar software de acordo com o domínio (conjunto de informações e situações) relacionado ao problema que o software se propõe a resolver.

Esse domínio deve ser definido já no começo do projeto, pelo menos de forma superficial, para que você saiba o objetivo do software. Depois disso começa o aprofundamento no domínio. É importante lembrar que sua arquitetura e seu ambiente de desenvolvimento deve preparado para evolução, protegido por integração contínua e TDD para garantir a evolução do domain. Práticas de desenvolvimento ágil são muito úteis para isso.

Em algum momento na caminhada iremos começar a desenvolver software e consequentemente trabalhar com o domain, aprofundando o conhecimento da equipe. Existem algumas dicas para obtenção do conhecimento, exploração de conceitos ocultos e implicitos, para garantir que o domain reflita a situação em um nível aceitável.

O fator fundamental é dialogar muito com os domain experts (pessoas que possuem experiência no processo de negócio do qual o domain trata). Sem os domain experts não é possível realizar domain driven design (Alguém ve alguma semelhança com agile?) São eles que vão determinar quais são as informações e situações que o domain deve tratar. Isso exige postura por parte de quem desenvolve, já que a pessoa que desenvolve deve ser a mesma que irá obter o conhecimento.

Voltando ao nosso exemplo, a frase “O Gavião normalmente come a Barata.” representa uma explicação ou definição do domain expert e portanto deve fazer parte do domain. Essa situação de negócio pode ser expressada graficamente da seguinte forma:

Esse é um exemplo simples, mas com esse tipo de notação pode-se expressar processos de negócio complexos, o que ajuda muito na visualização do domain. É importante observar que nesta notação bem simples, temos todos os conceitos explicitos. Isso nos dá o gancho para o próximo item que é a criação de uma linguagem comum para o time.

Ubiquitous Language

Um importante conceito do Domain Driven Design é a criação e manutenção de uma linguagem comum, tanto para o cliente quanto para o time de desenvolvimento. A premissa diz que ambos devem expressar o negócio da mesma forma e isso visa melhorar a comunicação e o entendimento entre as partes.

Essa linguagem comum deve estar presente no dia-a-dia da equipe incluindo a obrigação de ser expressada em documentos e no código também. No nosso exemplo o código expressa exatamente o conceito antes comunicado pelo Domain Expert (a frase “O Gavião normalmente come a Barata.” ), comunicada pelo diagrama:

image

Isso é conseguido através de algumas técnicas de Supple Design (um dos mais interessantes conceitos de Domain Driven Design) e é facilitado com a aplicação da técnica de Fluent Interface.

Refactoring

Pensando na situação do exemplo, “O Gavião normalmente come a Barata” nos deixa com muitas dúvidas sobre esse contexto. De onde veio a barata? De onde veio o gavião? O que acontece quando o gavião come a barata? O que o domain expert quer dizer com “normalmente”? Onde está o wally?

Podemos aprofundar nosso conhecimento a partir do momento que o domain expert responder essas perguntas. Mas essas perguntas podem gerar novas perguntas e consequentemente, mais conhecimento a ser expressado. Continuando no exemplo:

Pergunta de desenvolvedor:

- Por que você (o domain expert) diz que “O Gavião NORMALMNETE come a Barata”? O que quer dizer “normalmente”?

Resposta do Domain Expert:

- O Gavião normalmente come a barata, mas tem vezes em que a barata consegue escapar do gavião.

Pergunta de desenvolvedor:

- Então a barata luta para não ser comida?

Resposta do Domain Expert:

- Sim. A barata tenta se esconder na hora em que o gavião começa a sobrevoa-la. Se a barata escapa então o gavião procura outra presa. Se a barata não consegue então o gavião come a barata. Mas isso é tão obvio que eu nem falei antes.

Nesse momento nosso conhecimento sobre o processo de negócio é mais profundo. Isso exige um refactoring em nossa ubiquitous language. Devemos modificar os documentos, a forma de falar, os diagramas e o código. Vejamos como ficaria nesse caso:

Nesse pequeno exemplo pudemos identificar a variação entre um conceito solto do processo e um pequeno detalhe “óbvio” que o domain expert não mencionou porque era obvio. Quantos problemas você já enfrentou porque deixou passar algum “detalhe óbvio”? Agora que temos o processo de negócio refatorado podemos partir para a implementação do código:

Percebam que na hora de implementar o código, vários detalhes aparecem (as ações gaviao.comeu?() e gaviao.caçar()). Por isso é fundamental que o dialogo com os domain experts sejam constantes. O conhecimento evolui e nossa imaginação pode dar direções diferentes para uma situação, por isso validar o conhecimento com o domain expert é muito importante. Além disso podemos melhorar a implementação desse código (técnicamente falando) de várias formas. Talvez o do…while não seja a melhor opção para expressar este caso. Isso deve sempre ser realizado em inspeções de código, trazendo uma visão de fora para verificar a clareza e eficiência do código. Alguém se dispõe a otimizar esse algorítimo?

Conclusão

Praticar Domain Driven Design é algo deve ser feito em equipe, com foco em negócio e nas situações do ponto de vista dos domain experts. O DDD foca em expressar negócio em forma de software para que possamos minimizar complexidade desnecessária e consequentemente custos de produção e manutenção. A orientação a objetos, apesar de um conceito isolado ao DDD, vem para ajudar na implementação de um bom design orientado a domínio. O DDD por outro lado oferece um processo que facilita muito a aplicação de Orientação a Objetos na forma mais pura e por isso eu costumo dizer que Domain Driven Design oferece a nós desenvolvedores um caminho de volta à orientação a objetos. Confiram em breve mais artigos sobre DDD e sua práticas aqui no blog. ;-)

Read more →