Gestão Lean – O seu kanban está ajudando a resolver o problema certo?

Vídeo da palestra que fiz em Abril,  no  ALM  Summit Brasil 2013 com o título Gestão Lean – O seu kanban está ajudando a resolver o problema certo?

A essência dessa palestra foi baseada no fato de que hoje tem sido comum muitas empresas adotarem Kanban ou alguma outra ideia derivada de Lean dentro dos seus processos e modelos organizacionais. Mas mesmo com essa avalanche de boas intenções, será que as empresas estão se concentrando na questão certa? Qual tem sido o principal motivador que tem levado a adoção de Kanban? Será que esse motivador é realmente importante para as organizações?

Essa palestra visou recuperar as ideias e práticas básicas do pensamento Lean e ligá-las à maneira como as empresas estão adotando ou deveriam adotar Kanban e seus derivados.

Quero agradecer aos amigos Rodrigo Yoshima e Celso Martins pelos grandes insights sobre Kanban e afins :-). Um grande agradecimento também aos amigos da Lambda3 pela super oportunidade de falar para comunidade Microsoft.

 

Nenhum comentário »

Categorias deste post

Kanban, Lean, Mudança organizacional

Management 3.0 – Como gerenciar uma organização complexa sem enfartar do coração

Foi publicado no portal InfoQ Brasil, a palestra Management 3.0 – Como gerenciar uma organização complexa sem enfartar do coração. Essa palestra foi gravada durante o DevCamp, evento que ocorreu em Campinas-SP durante o mês de maio de 2013.

Nessa palestra eu mostro como que a abordagem de Management 3.0 vem se tornando uma importante ferramenta para compreensão e melhoria da gestão. Também explico como que técnicas da Gestão 3.0 podem ajudar um gestor a energizar as pessoas, empoderar times, alinhar restrições, desenvolver competências, crescer a estrutura empresarial e melhorar continuamente o design da própria organização.

Veja o vídeo completo em: http://www.infoq.com/br/presentations/management-3.0-gerenciamento-organizacao.  Aproveito aqui para agradecer ao pessoal da organização do DevCamp e à super equipe editorial do InfoQ Brasil.

Screen Shot 2013-09-27 at 01.05.15

Nenhum comentário »

Categorias deste post

Management 3.0

Usabilidade ou User Experience – é questão de escolha?

Acertar na interface exposta para os usuários e no modo de interação deles com nosso produto é sempre difícil. Afinal, existem grandes barreiras conceituais para atravessar: nós não sofremos do exato problema que eles sofrem e, nenhum deles passou o tempo implementando a solução conosco.

Existem diversas técnicas criadas para ajudar a resolver esse quebra-cabeça e possibilitar uma interface satisfatória que mantenha a integridade da solução provida. Em uma procura na web, livraria ou conferências, as duas buzz-words mais populares são “Usabilidade” e “UX” (User Experience). Qual a diferença? Qual conjunto de técnicas escolher entre os dois?

Como qualquer discussão técnica sobre definições e termos, bem, não existe uma única resposta correta para a diferença. Neste artigo vou tentar esclarecer minha própria visão dos dois, o modo como penso sobre cada termo quando aplico ou leciono suas técnicas – use se for compatível com seu parecer e aproveite a área de comentários para discutir se não for!

Não sou um fanático de definições, assim antes de começar, temos que deixar claro que… Desde que mantenhamos a abordagem correta, não faz diferença alguma!

A nomenclatura do termo que usamos na hora da implementação é um problema dentro do domínio de implementação, a escolha é uma solução que resolve um problema que nós temos, mas nosso usuário não. O problema que o usuário tem é que ele quer ser feliz e eficiente ao usar o produto, independente da forma como sua criação foi organizada, de modo que a terminologia correta é qualquer terminologia que facilite uma abordagem de desenvolvimento focada e centrada no usuário (solucionando o primeiro problema) e dessa forma atinge o objetivo de satisfazer o usuário (a solução do problema 2)!

Usabilidade

De volta ao contraste dos dois termos, até tempos atrás Usabilidade era o nome utilizado para resolver qualquer problema ou questão pertinente à qualidade da interação com o Usuário: Não basta ser útil, um software tem que ser usável também! Temos varias funções no nosso produto, mas será que o usuário encontra e opera essas funções intuitivamente e com baixo custo operacional?

Com o tempo, para administrar a usabilidade, sentiu-se a necessidade de defini-la e procurar medi-la. Os Standards voltados à usabilidade foram um bom empurrão nesse sentido e, com o tempo fizeram-se disponíveis métodos, definições e listas pelas quais organizar nosso trabalho de Usabilidade nos nossos projetos. Por exemplo, Jacob Nielsen (um das autoridades nas pesquisas de usabilidade) descreve o termo como a medida da coleção de Aprendibilidade, Eficiência, Memorabilidade, Erros e Satisfação.

UX

A própria popularidade do termo tornou-se seu maior obstáculo. Ao tentar definir o termo de forma exata, acabamos com uma lista do que o termo é… E subentendes-se o que o termo não é.

Preenchendo esses espaços que as definições de usabilidade não cobrem, User Experience é uma extensão da definição de Usabilidade: Não basta ser útil, não basta ser usável, um software tem que proporcionar uma experiência positiva e intensa! O usuário encontra e opera as funções com facilidade, mas será que ele está feliz ao fazê-lo?

Se quiséssemos comparar com Usabilidade, Peter Morville (outro guru) define UX como uma coleção de atributos que inclui Usabilidade — e outras características mais como Desejabilidade, Credibilidade, e Valor.

Segundo o visto acima, UX é um termo que inclui o conceito de Usabilidade, então de modo seco pode também ser considerado um termo mais seguro.

Porém não se pode atingir um grau elevado de experiência de usuário (UX) sem atingir um grau elevado de Usabilidade. O foco da equipe de desenvolvimento deve ser nos dois simultaneamente e, nas duas áreas existem técnicas (às vezes distintas, às vezes as mesmas) que nos ajudam a trabalhar cada um dos dois em separados e em conjunto, técnicas que centram nossas decisões no bem do usuário final.

Até a próxima vez, boa sorte… E tome conta do seu User!

Sobre o autor:

Shmuel Gershon

É líder técnico na Intel Corporation em Israel, onde testa software e firmware com seu time de super-heróis. Seu dia a dia inclui diversas atividades, como criar e adaptar estratégias de testes, testar tecnologia em diversas camadas, treinar testers, ajudar amigos e fazer tudo de novo no próximo produto. Já trabalhou em empresas de diversos portes da América do Sul ao Oriente Médio, e apesar de começar sua carreira programando, descobriu que testar é o dobro da diversão. Shmuel é palestrante frequente em conferencias internacionais sobre testes (StartEast, EuroStar, SIGiST…) e sobre programação (Oredev, Goto, SWPC…), trazendo uma visão única sobre software: a convicção de que o fator mais importante na nossa busca por qualidade são as pessoas e não as tecnologias. Para conhecer mais, leia seus artigos na BetterSoftware Magazine ou no blog, onde você também encontra Rapid Reporter, aplicativo freeware que facilita relatórios e anotações durante testes exploratórios. Homepage: http://gershon.info.

Nenhum comentário »

Categorias deste post

Gestão de Produtos

Nós temos A Força! (e agora?)

Empoderar times é fundamental para se trabalhar bem com o profissional do conhecimento. É importante, pois são os times que estão em contato com o cliente, no dia-a-dia, então, eles têm muito mais condições de tomar decisões assertivas. Além disso, quando as pessoas participam das decisões, ao invés de receber soluções prontas, elas se sentem muito mais envolvidas e comprometidas com a empresa.

Mas será que basta apenas empoderar os times para que comecem a participar de decisões tão importantes que influenciam no sucesso da empresa?

A resposta é um grande, imenso NÃO!!

Por dois motivos muito simples:

  1. Seguindo o conceito da “Tabula Rasa” de John Locke, o ser humano nasce como uma folha de papel em branco, que será preenchida com suas experiências. E o comportamento aprendido pelas pessoas no mundo corporativo é: relatar um problema e esperar que a gerência aponte uma solução. Mesmo empoderados, times não sabem decidir ou têm medo de tomar uma decisão errada que poderá ter consequências desastrosas para si ou para a empresa.
  2. Um grupo de pessoas que, por acaso, trabalham juntas, não se torna um time da noite para o dia por mágica ou pelo simples fato de que foram empoderados por sua organização. Existe um longo e difícil caminho a ser trilhado para que o sucesso do time seja superior às vitórias individuais (outro comportamento aprendido no mundo corporativo).

Mas então, como tornar esta experiência um sucesso?

Com um grande, imenso apoio do time executivo!!

Antes de qualquer coisa, os times empoderados precisam sentir que o time executivo tem total confiança em suas decisões (por isso os empoderou). Se não confia, não dê o poder total, mas possibilite a criação de um ambiente onde o time consiga atingir tal poder. Isso pode ser feito com a criação e o bom uso de um “quadro de autoridades”, onde o time executivo avalia a maturidade de cada um dos seus times individualmente e concede o poder de acordo com esta maturidade. Particularmente, acredito que seja mais motivador começar atribuindo aos times um grau menor de autoridade, que será aumentado com o tempo, do que o contrário. Ou seja, é mais gratificante “conquistar o poder” do que recebê-lo e não saber o que fazer com ele.

Já vi alguns times que, uma vez empoderados, permaneceram exatamente onde estavam, esperando um direcionamento do time executivo! Este é um exemplo claro de que o time não tem maturidade suficiente para lidar com o nível de empoderamento que lhe foi dado. Aqui, o time executivo criou um novo problema, ao invés de resolver outros. Criou-se um time empacado, com medo de errar e, certamente, desmotivado por não ter o suporte adequado para suas ações. E que ainda depende do time executivo.

O maior desafio do time executivo no processo é a prática do desapego. É preciso aceitar profundamente que ele não está mais ali para decidir (dependendo do grau de autoridade do time), mas sim, para orientar. Numa organização com times empoderados, o time executivo deve, fundamentalmente, exercer o papel de Coach. O time executivo deve tentar fazer o time visualizar possibilidades. Possibilidades que, certamente, não estavam acostumados a considerar. Apenas fornecer informações para os times talvez não seja o suficiente, já que é bem provável que estes times não saibam muito bem o que fazer com tais informações.

Por fim, o time executivo deve apoiar incondicionalmente as decisões dos times empoderados. É possível que se erre, mas, com a prática do Coaching ou do Mentoring dos times e com a proximidade do time executivo o tamanho do erro pode ser minimizado e as soluções de contorno estarão mais ou menos pensadas. Afinal, as possibilidades foram avaliadas.

Todo este trabalho deve ser regado com metas desafiadoras (porém viáveis), que deverão ser negociadas (e nunca empurradas) com o time executivo. Metas são bons motivadores na formação de times, mas precisam fazer sentido para os integrantes. Todos precisam “comprar a briga”!

A palavra chave para o sucesso é: “colaboração”. É preciso haver muita colaboração entre os times empoderados e o time executivo. Dentro de um ambiente controlado pelo quadro de autoridades, o objetivo e o motivador dos times empoderados deve ser conseguir cada vez mais autoridade, mais força!

 

Sobre o Autor:

Marcelo L. Barros é um cara criativo, curioso e detalhista, que, cada dia mais se vê interessado em desvendar os mistérios desse “bicho gente”! Acredita que pessoas motivadas trabalham com maior produtividade e qualidade; que a chave para o comprometimento é fazer com que as pessoas se sintam parte do negócio; e que compartilhar o que se chamava de “poder” é algo mais poderoso do que qualquer metodologia. Desde 2004 atua como Dreamer, Thinker & Maker no grupo Emphasys. “Pau pra toda obra”, fã de Scrum, Testes do Software, Dinâmicas de Grupo e, claro, Team Growing.

https://about.me/marcelolbarros

http://agilemomentum.wordpress.com/

@MLeiteBarros

1 Comentário »

Categorias deste post

Coaching, Mudança organizacional

O que é Agile Testing?

Primeiramente para entender Agile Testing temos que dar uma olhada no Manifesto Ágil
Em um grande resumo o manifesto coloca que temos entregas de valor em um curto espaço de tempo.

Muitas práticas são utilizadas por um time ágil referente a teste. Programadores utilizam TDD (Test Driven Development) para desenvolver código com uma maior qualidade. Com ele os programadores escrevem testes para um pequeno pedaço de uma funcionalidade no ciclo do TDD (falha na primeira vez, é refatorado até possuir o comportamento esperado. Sempre que é alterado ou melhorado passa por este processo).
Esta prática não é somente usada exclusivamente por equipes ágeis, mas como uma forma inteligente de pensar no design de software e agir de forma a prevenir os defeitos futuros.

Mas TDD não é teste. É uma maneira que temos de pensar no design do software e garantir que este, se alterado, continuará a funcionar. Se alguma inconsistência for encontrada frente a alguma modificação, facilmente com um conjunto de testes que asseguram o comportamento do software, podemos detectar e alterar/refatorar o ponto de inconsistência.

Alguns acham que TDD é aplicar Agile Testing, mas ele é muito mais que isso….

Times

Dentro de uma equipe ágil possuímos, basicamente, dois times:

Time do Cliente: todos que estão do lado do negócio no projeto (product owner, business experts, business analyts). Este time escreve histórias e funcionalidades que o time de desenvolvimento entrega.

Time de Desenvolvimento: todos que entregam código são parte integrante deste time, onde o papel de cada um por ser misto ou variado. Eles transformam todas as histórias do time do cliente em software.

Estes dois times trabalham próximos uma grande parte do tempo e se transformam em um único time com um objetivo em comum: entregar valor para a organização.

 

E o testador?

Falando do conceito de time para o Time do Cliente, os testadores são membros parciais do negócio, ajudando-os a descobrir requisitos e exemplos e também ajudando o time a expressar requisitos como testes.
Testadores também são parte do Time de Desenvolvimento advogando por qualidade à favor do cliente e ajudando o time a entregar o máximo de valor ao negócio.

Muitos times não possuem membros se intitulando testadores. Entretanto o time precisa de alguém que ajude o Time do Cliente a escrever histórias e características, a escrever testes para elas, garantir que elas estão atendendo as necessidades e, automatizar os testes de regressão (para termos um feedback rápido e contínuo sobre a qualidade/saúde do software).

O que é então Agile Testing?

Agile Testing é um conjunto de práticas, seguindo o Manifesto Ágil, que incorpora todas as técnicas de teste comumente utilizadas por profissionais de teste, tendo um grande foco em automação. A principal função é de criticar o produto, ou seja, constantemente garantir que o que está sendo especificado e desenvolvido realmente atende as necessidades do cliente e irá entregar valor ao negócio.

 

O que é um Testador Ágil?

Um Testador Ágil é aquele profissional que abraça as mudanças, colabora com pessoas técnicas e de negócio e entende o conceito de usar testes para documentar requisitos e guiar o desenvolvimento.
Ele tende a ter bons conhecimentos técnicos para colaborar com o time de desenvolvimento a automatizar os testes e também para explorar o sistema a procura de comportamentos, testes e problemas.

Ser um testador ágil está ligado muito mais a atitude e comportamento do que conhecimento técnico. Ele olha para o produto como um todo, com uma visão de usuário e/ou cliente, que é o fator mais importante. Assim ele consegue tanto interrogar o Time do Cliente quanto a requisitos e funcionalidades como guiar o desenvolvimento, através de testes, exemplos e ferramentas, para que o Time de Desenvolvimento tenha também a visão do valor que cada um destes itens tem para o produto final.

 

Sobre o autor:

Embora vários títulos já exercidos no mercado (Arquiteto de Teste, Engenheiro de Teste, Analista de Teste) Elias Nogueira é essencialmente um testador: alguém com uma grande curiosidade de como o software comporta através de diversas situações/contextos.

É consultor e instrutor em qualidade de software, blogueiro e palestrante já tendo trabalhado nas mais diferentes segmentos como bancos, telecos, governo, varejo, qualidade de dado e geoprocessamento. Elias também é instrutor associado na Adaptworks no curso de Agile Testing.
Acredita que a qualidade do software é dever de todos e, quando há um papel especifico para isso, que este deve saber sobre os dois mundos do desenvolvimento de software: técnico e negócio.

http://about.me/eliasnogueira
@eliasnogueira
http://sembugs.blogspot.com

4 Comentários »

Categorias deste post

Agile, Qualidade, Técnico, Time de desenvolvimento

Planejamentos ágil e tradicional — Um é de marte, outro de vênus

agile vs tradicional planning

Plans tend to be like milk on a hot summer’s day in that regard. They go sour quicker than you expect.
Andy Hunt – signatário do Manifesto Ágil

Vira e mexe ouve-se a famigerada acusação de que no Agile não há planejamento.

Arrrrrg! Não é bem assim, isso é um mito. O que o Agile faz é dar mais ênfase no planejamento que no plano em si, mas vamos ver um pouco mais sobre as diferenças.

Um mundo de incertezas

Os dois tipos de planejamento são de mundos diferentes, mais ou menos como naquele livro “Homens são de marte, mulheres são de vênus”.

O Agile assume que estamos em um ambiente de grande incerteza e, portanto, tentar planejar previamente todo o projeto traria consigo um alto grau de especulação, já a abordagem tradicional acredita em um mundo linear com causas e efeitos muito claros e que assim, seria possível planejar com exatidão o projeto antes mesmo do início de sua execução.

Dessa forma, poderíamos dizer que “O Agile é do complexo e caótico, o tradicional do simples e complicado“.

O método cascata

O método cascata
Primeiro vamos tirar a confusão que existe entre gerência de projetos tradicional e método cascata: Apesar dos dois andarem costumeiramente de mãos dadas, o primeiro está mais relacionado com o PMBOK (Project Management Body of Knowledge)  e o segundo com uma forma recomendada pela engenharia de software tradicional.

Como na mentalidade tradicional existe a presunção de que todas as funcionalidades levantadas são indispensáveis e serão, portanto, implementadas, pouco importaria para o cliente a ordem como seriam implementadas. Dessa forma, opta-se por fazer o que parece, à primeira vista, a maneira mais inteligente e eficiente de se fazer software: por meio de etapas bem definidas, com grandes “entregas” de artefatos intermediários de uma fase para a outra.

Um dos problemas dessa abordagem é o tempo prolongado para se obter qualquer feedback, fazendo com que os problemas sejam descobertos tardiamente. Só para exemplificar, imagine que na fase de Análise um primeiro trabalho pode servir como base para completar todo o resto do trabalho antes de haver uma entrega para a próxima fase. Ao entregar o trabalho para a equipe que trabalhará na fase de Codificação, descobre-se que há um problema em todo o material entregue, devido a um problema que poderia, se houvesse um ciclo maior de feedback, ser descoberto mais cedo.

Como se não bastasse, um outro problema comum com essa abordagem é a propensão a gerar silos e pouca responsabilidade compartilhada da equipe pelo projeto. É comum nesse cenário se ouvir a “querida” frase “Fiz minha parte!”.

O planejamento tradicional

A primeira coisa que salta aos olhos no planejamento tradicional é o foco no plano, ou seja, uma vez estabelecido existe uma grande dificuldade em mudá-lo. A busca não é pelo valor para o cliente, e sim em entregar no prazo e no custo tudo que o cliente imaginou de antemão ser necessário para resolver seu problema.

Dado que vamos seguir um plano idealmente sem alterá-lo, e que todas as funcionalidades requisitadas pelo cliente precisam ser feitas, pouco importaria para o cliente a ordem em que serão desenvolvidas. Dessa forma, acaba-se dando enfoque em atividades. Você se lembra dos processos da fase de planejamento do PMBOK? Vou citar só alguns dos envolvidos com levantamento de escopo e definição do cronograma para exemplificar isso:

Coletar os requisitos;
Definir o escopo;
Criar a EAP (Para quem não sabe, EAP é a WBS, algum louco decidiu chamar de estrutura analítica de projeto);
Definir as atividades;
Sequenciar as atividades;
Estimar os recursos das atividades;
Estimar as durações das atividades;

Deu para perceber que o planejamento tradicional foca em atividades, não em funcionalidades? O problema é que normalmente não se produz valor para o cliente a cada atividade concluída, mas sim a cada funcionalidade entregue.

Ok, não é só isso, acontece que em geral as atividades não terminam antes do planejado, por algumas razões como a Lei de Parkinson (não, não é o mal de Parkinson), a Síndrome do estudante e uma extraordinária falta de incentivo para tal.

Lei de Parkinson: Diz que o trabalho ocupará o tempo disponível para ele.
Síndrome do estudante: Se houver um prazo para concluir algo, o aluno ou estudante (ou no caso o desenvolvedor) deixará para a última hora.
Falta de incentivo: Quando alguém termina cedo, costuma-se culpar essa pessoa por supostamente adicionar muito padding à estimativa ou, então, querer exigir que termine as demais atividades mais cedo também. Ou seja, em geral não há qualquer incentivo para o desenvolvedor dizer que terminou algo antes do prazo.

Outro ponto é que os atrasos são transferidos no encadeamento de atividades. A ideia de que um atraso se compensa, na média, com atividades entregues mais cedo quase nunca é verdade. Um dos motivos disso é que apenas uma combinação de resultados permite que uma atividade possa começar mais cedo, enquanto um único problema pode atrasar o começo de uma atividade. Aliás, há outro motivo para os atrasos não se compensarem na média, é que  as atividades não são eventos independentes.
Jogar uma moeda múltiplas vezes é uma atividade independente. Já no desenvolvimento de software as variações nos tempos de conclusão das atividades tendem a se repetir. Por exemplo, se criar um interface gráfica demorou mais que o estimado, há uma tendência de que outras atividades similares também levem mais tempo que o esperado.

O foco em atividades ainda leva a um outro problema: devido às atividades não serem desenvolvidas por prioridade, normalmente leva-se muito tempo para se ter algo em funcionamento e, mesmo assim, dificilmente serão as funcionalidades de maior valor para o negócio. Caso o dinheiro acabe antes do tempo ou seja preciso adiantar a data de lançamento do produto, não haverá algo muito útil para se entregar, nem tampouco é dada a oportunidade ao negócio para encerrar o projeto antes da hora se a maior parte do valor já foi entregue.

Esse último não está ligado às atividades, mas talvez seja o problema mais irritante em relação ao planejamento tradicional, as estimativas tornam-se compromissos. Estimativas são probabilidades; e compromissos não devem ser tomados sobre probabilidades. É quase como pedir para um meteorologista se comprometer com a previsão de um dia específico num futuro mais distante que um mês.

[youtube http://www.youtube.com/watch?v=RVjpVCwvnFg]

O planejamento ágil

Dada a premissa que estamos em um ambiente de incertezas (mundo da complexidade), todo ato de planejar e estimar é um ato de especulação. Isso não significa que o Agile entenda que estamos completamente no escuro, apenas que nossa visão é limitada e cada vez menos nítida conforme nos lançamos a “ver o futuro”.

Outro ponto de fundamental diferença é o foco, não mais no triângulo de ferro, escopo, prazo e custos, mas na entrega de valor. É óbvio, contudo, que prazo, escopo e custo não são desprezados, apenas deixam de ser o objetivo principal do projeto.

O que é diferente, afinal, no planejamento ágil?

Encoraja mudanças. Como o enfoque está na entrega de valor, é necessário aceitar e encorajar as mudanças caso entreguem mais valor que o planejado.

Um dos primeiros efeitos desse entendimento é que o foco passa a ser no plajenamento e não mais no plano. Isso facilita que o plano possa ser facilmente alterável.

Planejamento por funcionalidade e não por atividade. Como o Agile visa a entrega de valor, não importa a ordem pela qual as atividades são executadas, mas importa a ordem pela qual as funcionalidades são entregues, afinal, as que entregam mais valor deveriam ser priorizadas e entregues antes.

A incerteza é aceita como “parte do processo”.

O planejamento é iterativo. deve ser feito em níveis de Release, Sprint (Iteração timeboxed e incremental) e dia; evoluindo o plano de forma incremental. Em outras palavras, o planejamento é diluído pelo projeto, afinal, conforme o projeto progride, aprendemos mais sobre o projeto (o como) e sobre o produto (o que).

Estimativas não são compromissos, são estimativas.

Medida primária do progresso do projeto é software funcional (Entrega real). Consequentemente há uma contribuição maior para uma evolução apurada do planejamento.

Estabelece confiança. Entregas constantes de software funcional ajudam a estabeler a confiança entre o negócio e o desenvolvimento.

É importante saber em que mundo você está antes de escolher um tipo de planejamento, mas nunca perca de vista o foco na entrega de valor. É muito triste entregar um projeto no prazo, no escopo e no custo se no final das contas o projeto falhar no mais importante que é resolver o problema do seu cliente.

They had “achieve failure” — successfully, faithfully, and rigorously executing a plan that turned out to be utterly flawed.

Eric Ries, no Livro “Lean Startup”

Sobre o autor:

Leonardo Campos

Leonardo Campos trabalha na área de TI desde 2000, Atuou boa parte deste tempo como desenvolvedor Java, mas também desenvolveu profissionalmente com Ruby, .NET, VB, PHP e ASP. Desde do começo de 2009 vem atuando como Scrum Master e agente de mudanças na Editora Abril. É estudioso de processos e entusiasta de Lean e Agile, sendo um dos organizadores do Lean Coffee São Paulo e editor da InfoQ. Leonardo é graduado em Direito pela Universidade Presbiteriana Mackenzie e aprovado pela OAB.  E também é instrutor associado na Adaptworks treinamentos, onde ministra o treinamento de EPC (Estimating, Planning and Contracting).
LinkedIn: @leonardocampos

2 Comentários »

Categorias deste post

Agile, Release, Scrum

Gestão 3.0: A descentralização do poder nas empresas

Em maio deste ano organizamos a trilha de Management 3.0  no TDC Floripa  (The Developers Conference).  Nessa ocasião, Wagner Santos , Diretor do grupo Emphasys,  foi entrevistado pela equipe da Revista Interface  (Senior) sobre o tema:  Gestão 3.0 e descentralização do poder nas empresas. Essa entrevista foi inspirada na palestra sobre o tema “Coragem para Empoderar“.  Tanto na palestra, quanto na entrevista, Wagner comenta principalmente sobre a experiência no dia-a-dia da mudança organizacional vivida no próprio grupo Emphasys.  Confira abaixo o ótimo resultado desse material produzido pela equipe da revista.

 

Nenhum comentário »

Categorias deste post

Beyond Budgeting, Management 3.0

Um pedido: Me Convença!

Tempos atrás, como ouvinte em uma reunião sobre métodos ágeis, vivenciei a frase que, para mim, traduz a realidade ágil do país.

Um potencial cliente, incentivado pelo seu gerente de TI, nos procurou para entender o que era SCRUM. E após explicar as atividades de sua  empresa, calmamente nos desafia:

– Por favor, me convençam por que devo usar esse tal de SCRUM ou métodos ágeis!

Afff… Somos os tais “gurus da agilidade”, lutamos para aproximar as áreas de negócio das áreas de desenvolvimento de software, entendemos que essa prática agrega valor real a qualquer negócio. Mas convencer…. Ah, convencer! Quantos nos solicitam serem convencidos!

Ouvi um suspiro profundo e um discurso convicto  (eu que conheço o tom de voz, o sabia, também entediado), um “Adaptworker” contaria a história da agilidade no mundo e no Brasil, até os benefícios de se iniciar essa aproximação de áreas, pela disciplina de entregas frequentes de valor, pelo SCRUM.

E eu paralelizei o raciocínio, comecei, em minha mente, a pensar em BDD. Ou seja, viajei.

Como seria simples e lógico colocar em histórias de usuários e fazê-las testáveis, convencer aquele empresário, sobre os benefícios da agilidade para TODA a empresa dele.

 

bddciclico

Segundo confirmamos na WikipédiaBehavior Driven Development (BDD ou ainda uma tradução Desenvolvimento Guiado por Comportamento) é uma técnica de desenvolvimento Ágil que encoraja a colaboração entre desenvolvedores, setores de qualidade e pessoas não-técnicas ou de negócios num projeto de software. Foi originalmente concebido em 2003, por Dan North como uma resposta à Test Driven Development (Desenvolvimento Guiado por Testes), e tem se expandido bastante nos últimos anos.

Mas na minha mente eu criava o meta-BDD, onde o desenvolvimento e as influências de comportamento dos indivíduos que compõe aquela empresa seriam orientados a mudanças pela implantação do BDD na área de construção do software, produto chave da empresa.

O BDD me diz que, em uma linguagem que os idealizadores de um produto entendem, facilmente eu posso criar testes de comportamento de uma unidade deste produto, e um conjunto de testes interligados garantem a qualidade do software produzido.

Teste de unidade garante a qualidade de um produto de software inteiro?

Resposta objetiva: Não. Mesmo porque BDD não é sobre teste de unidade, é sobre comportamento. E como desenhar software orientado por um comportamento esperado?

Precisamos aprender sobre as vantagens de praticar BDD.

Testar é a parte óbvia. E óbvio é o benefício de “refatorar” o código no sentido de deixá-lo funcional, com assertividade e clareza, código limpo e simples. E refatoramentos podem ser feitos com segurança, pois os testes detectarão falhas.

BDD é inteligível para um leigo.

Aumenta a integração entre o idealizador do produto, os testadores e os desenvolvedores, pois todos falam a mesma língua.

Mesmo quando testadores e desenvolvedores são de equipes diferentes, eles podem trabalhar juntos para definir o design do que vai ser feito. Valorizando o Pair Programming.

Escrever User Stories é uma ótima forma de fazer isto, pois pode ser feito com a ajuda do usuário ou pelo menos validada com o usuário que vai entender o que está escrito.

BDD nos ensina mais sobre histórias de usuários e User Stories servem como Test Case, Código do teste automatizado e Design, tudo junto.

 

Do ponto de vista de desenvolvedores vemos:

– O código gerado tem menor acoplamento e maior coesão;

– O código gerado tem uma maior qualidade por ter alta porcentagem de cobertura de teste;

– É possível saber, claramente, quando uma tarefa foi concluída, pois o teste correspondente estará passando;

– Testes de regressão automatizados existem sem nenhum esforço adicional;

– A maior parte dos bugs é encontrada mais cedo, o que torna mais barato corrigí-los;

E observando todas essas vantagens, ‘re-concluo’ que TODO COMPORTAMENTO dos envolvidos e comprometidos no desenvolvimento deste produto será afetado.

 

Chegamos ao meta-BDD – paradigmas serão quebrados, agilidade será praticada, valores serão questionados e processos serão alterados.

 artificial2bsynthetic2btelepathy2band2bmind2bcontrol

E aterrissando na reunião com cliente – lembram? – ouço:

– Então SCRUM não é apenas sobre software, pode ser utilizado para influenciar a minha empresa inteira?

E eu quase gritei: “Isso!!! Estamos falando além do SCRUM, estamos falando sobre meta-BDD, que nasce no desenvolvimento de software ágil e irradia para todos.”

O cliente estava convencido e feliz com o novo horizonte! Eu apenas sorri.

Nenhum comentário »

Categorias deste post

Agile

Conheça e participe do Change Management Brasil


change-logo

Breve vídeo de anúncio do primeiro Movimento de Change Management Brasil. Esse movimento, encabeçado por André Faria, Celso Martins e Eu,  visa “Construir, reunir e socializar a informação disponível sobre change management para orientar e facilitar change agents.” A Adaptworks também apoia o movimento e torce para que mais pessoas se sensibilizem e participem da causa desse movimento. Portanto, assista o vídeo e acompanhe as inúmeras novidades que serão produzidas por esse movimento.

1 Comentário »

Categorias deste post

Mudança organizacional