Arquivo da tag: agile

Participe em janeiro do meu novo curso: Produtos digitais: do marketing ao desenvolvimento

Você sabia que entre dez ideias de produtos em média apenas uma chega ao ponto de trazer retorno financeiro? O que separa essa ideia das demais não é a tecnologia usada, o produto em si ou mesmo a quantidade de dinheiro disponível, a diferença está na disposição que os empreendedores tem de ler rapidamente o mercado e de fazerem adaptações ao produto.

Normalmente ou você estuda marketing ou você estuda metodologias de desenvolvimento de software como se uma coisa funcionasse independente da outra. Neste curso estudaremos os dois juntos e integrados com muitos exemplos práticos para que você saiba como se posicionar seja para criar seu próprio produto seja para atuar em empresas de qualquer tamanho.

Continuar lendo Participe em janeiro do meu novo curso: Produtos digitais: do marketing ao desenvolvimento

Ouça a minha palestra na Jornada de Informática da UNESP Bauru e acompanhe os slides

521772_10151503001144428_977606377_n

Diferente da palestra do BABRAZIL 2011 que tinha como público alvo analistas de negócios a palestra da última sexta-feira (19/10) teve como público alvo estudantes de sistemas de informação e ciências da computação.

O objetivo da palestra foi armar esses futuros profissionais com conhecimentos sobre negócios suficientes para que possam ter uma atuação mais abrangente no desenvolvimento de produtos ou passar a executar atividades de análise de negócios em iniciativas.

A palestra é longa e o áudio não está dos melhores, contudo quem participou disse que valeu muito a pena. Convido você a assistir:

Gerenciamento de riscos: o poder é de vocês

Minha amiga chega ao trabalho e após alguns minutos se dá conta de um fato aterrador: não consegue lembrar se tirou ou não a sanduicheira da tomada. 

Você conhece a sensação, talvez o mais desagradável seja o fato de simplesmente não conseguirmos lembrar. A memória é assim: prega peças para dar sabor à vida, transforma em probabilidades o que poderia ser certeza.

Bem, os riscos fazem parte da nossa vida. Para que um risco exista basta determinarmos qualquer resultado esperado em qualquer ramo da atividade humana.

Acordo pela manhã, abro os olhos e penso: “vou trabalhar”. Pronto! Com essa frase nasceu o risco de eu não trabalhar hoje ou talvez nunca mais.

Riscos existem, podemos lidar com eles, ignorá-los (não saber da sua existência) ou simplesmente aceitá-los e as suas consequências. Ignoramos riscos que não conhecemos e aceitamos riscos que achamos pouco prováveis, como faço com o risco da minha casa ser atingida por um asteróide.

Como vamos lidar com um risco depende de uma equação simples na qual pesamos o quão ruim as coisas serão se esse risco se concretizar, qual a probabilidade desse risco acontecer de fato e por fim, qual o custo que vamos ter em lidar com ele.

Custo da ação < (Bomba / Probabilidade)

Em PT-br: o custo da ação não deve superar o custo da bomba explodir em relação à probabilidade dela explodir.

Os seres humanos que habitam o planeta hoje são descendentes dos seres humanos que souberam aplicar essa equação da melhor forma dado cada momento.

Vou usar a história da minha amiga para descrever o que podemos fazer em relação a um risco, no caso dela o risco da sanduicheira esquentar demais e causar um incêndio. Continuar lendo Gerenciamento de riscos: o poder é de vocês

Cuidado com o sênior

A região metropolitana de São Paulo não chega a ser digamos, montanhosa, contudo existem algumas subidas que desafiam quem deseja utilizar a bicicleta como meio de transporte, principalmente para quem gostaria de chegar no ponto B sem suar além da conta.

Um desses desafios é chegar à Avenida Paulista. Em termos relativos ela está lá no alto e não importa por onde você chega: você precisa subir.

Eu sou considerado um ciclista experiente, talvez não pelo tempo que pedalo nas ruas de São Paulo (dois anos), mas pela distância diária e a freqüência, são 30 km todos os dias úteis para ir trabalhar. Minha bicicleta atual está beirando os cinco mil rodados o que me transformaria em termos relativos em um ciclista urbano pleno ou sênior.

Recentemente montamos um grupo de ciclistas geeks, uma galera muito alto astral, do bem que trabalha com informática (sim, isso é possível) e que está começando a pedalar pela cidade de São Paulo.

No nosso primeiro passeio montei uma rota que incluía o caminho que eu considerava “o menos pior” (uma vez que bom não existe) para subir à Paulista.

 Passeamos pela Paulista, vimos as luzes de natal, descemos para o Ibirapuera ver a árvore e voltamos para a nossa avenida querida, foi muito divertido. Fizemos outros passeios depois desse, um na sexta-feira 13 e outro no aniversário de São Paulo.

Na semana passada o pessoal estava louco para fazer um passeio, mas eu não podia por causa de uma dor no joelho. Meus amigos insistiram, falaram que eu era o cara, mas eu sugeri que eles fossem sem mim.

Eles foram, se divertiram, superaram as dificuldades e descobriram um caminho ainda melhor para subir para a Paulista coisa de duas ruas distante do caminho que eu considerava melhor, mas que eu havia ignorado, talvez por simples acomodação.

Como eu prefiro validar as hipóteses ao invés de simplesmente discuti-las,hoje, segunda-feira, mudei o meu caminho, encontrei a rua e subi. Não é que é super leve, mão única e não tem ônibus?

A moral da história é que devemos ter muito cuidado com a palavra “Sênior”. Essa palavra não pode ser tomada como “aquele que sabe mais e que guia os outros”.  Acredito que sênior no nosso ramo tem mais a ver com aquele que aprende mais e aplica o que aprende. O passado só tem importância se ele ajuda no presente.

A inovação está nas mãos daqueles que vão e fazem.

O dia em que me tornei desnecessário

Vamos começar com uma história, mas dessa vez real:

Era uma quente terça-feira de verão em 2011. Estou em uma sala de reuniões em um edifício da av. Paulista. O evento, ou melhor, a cerimônia é a review da sprint sete de um projeto para uma instituição financeira. Na review o time de desenvolvimento apresenta o resultado do trabalho da última sprint (período de tempo dedicado ao desenvolvimento de uma parcela definida do sistema) para os clientes. Éramos onze pessoas à mesa, divididos da seguinte forma:

  • Cliente: 
    • Uma gerente de projetos
    • Dois especialistas em sistemas do cliente
    • Três clientes finais (quem vai usar o produto)
  • Fornecedor: 
    • O Scrum Master
    • Eu (agile BA/PO/whatever)
    • Três desenvolvedores (o time tem seis, mas como a review foi no cliente e não temos uma perua, não trouxemos o time todo). 

A mesa estava assim:

Copy-of-handoffs2

O primeiro fato interessante foi que os clientes (verdes) e os desenvolvedores (vermelhos) se sentaram frente a frente sem estímulo algum da nossa parte. 

Os desenvolvedores começaram a sua apresentação, iam passeando entre telas que atendiam aos padrões de layout do cliente, realizando operações que haviam sido selecionadas na última planning quando de repente uma faísca se acendeu e os clientes finais começaram a fazer perguntas e comentários e a conversa começou a rolar solta. Fiquei assistindo.

Notei que nós, “os cinzas”, que costumávamos dominar essas reuniões, ditar ritmo e assunto, estávamos quietos e só abríamos a boca quando era realmente útil para a discussão.

Notei também que o vocabulário usado pelos desenvolvedores era totalmente orientado ao negócio, não havia necessidade de tradução.

A coisa ficou realmente interessante quando o cliente final lembrou-se de necessidades importantes que estavam foram da sprint e, conseqüentemente fora a release que se aproximava.

Sabemos que isso acontece, nem todo o planejamento do mundo consegue evitar mudanças. As metodologias de gerenciamento de projetos lidam com a mudança de diferentes formas. No caso do Scrum, quando algo importante para a release é descoberto, simplesmente atrasamos a release, mas claro que ninguém gosta de atrasar uma release, se for feito, que seja o mínimo possível (uma sprint). 

A base do meu trabalho de Agile BA/PO/whatever é entender tanto do negócio quanto de como o sistema está sendo construído e em condições normais me debruço junto ao cliente final para descobrir uma forma de atender à necessidade da forma mais barata, ou seja, aproveitar ao máximo os serviços já existentes no sistema.  O que fiz nesse caso? Muito pouco.

O time de desenvolvimento fez uso do conhecimento do negócio e os clientes finais fizeram uso do seu conhecimento do sistema e chegaram às soluções em tempo recorde e com muita eficácia.

Nós “os cinzas” ficamos, novamente, só dando úteis pitacos aqui e ali e é claro, sobrou para o analista de negócios atualizar a documentação (que parece cada vez menos necessária em um ambiente assim, sendo útil apenas para a construção do manual do usuário e para apoiar o QA externo). 

 

Claudiobr_scrum_2

 

O mais interessante foi que se estamos falando da sprint sete e nossas sprints têm dez dias úteis. Falamos em aproximadamente 105 dias corridos, três meses e pouco.

Deixando de lado o fato extraordinário de se entregar uma quantidade considerável de funcionalidade em um período inferior a cinco meses dentro de critérios rigorosos de arquitetura e layout do cliente, e pasmem – em outsourcing – nosso uso do Scrum teve outro mérito impressionante: Em muito pouco tempo temos um time de seis desenvolvedores capazes tanto de entregar a solução técnica quanto de compreender e atuar sobre o domínio do problema.

Eu gostaria de poder mensurar financeiramente o valor disso, pois além dos ovos de ouro (código rodando), desenvolvemos a galinha dos ovos de ouro (o time). Continuar lendo O dia em que me tornei desnecessário

#PMI e #Agile: Negação, raiva, barganha, depressão, aceitação e… APROPRIAÇÃO.

Opa, antes de qualquer coisa, sim, eu fui GP, cheguei perto de ser PMP (me amarrava em Pilotar Microsoft Project), passava o dia perguntando “tá pronto?” e critiquei muito o agile assim que conheci até que a minha opinião foi moldada pela realidade dos projetos dos quais participei e dos produtos que gerenciei.

Dessa forma, entendo que as pessoas mudem, que as organizações mudem (afinal, estou trabalhando em uma fábrica de software que deseja realmente ser o mais agile que esta triste condição permitir), contudo, a forma com a qual o PMI “abraçou” o agile foi extremamente arrogante. 

O instituto parece ter passado por todas as fases do luto, permanecendo, claro, anos e anos na primeira, a “negação”. Acredito que a raiva, a barganha, a depressão e a aceitação se deram de forma velada. O próximo passo público foi a apropriação. Agile é do PMI agora. Eles dizem quem está capacitado.

“PMI will validate a practitioner’s ability to understand Agile principles and concepts.”

Acho que ninguém falou que os princípios ágeis quando aplicados diminuem fortemente a necessidade de alguém que se intitule gerente de projetos. Duvido que o pessoal que luta tanto por reconhecimento vá aceitar trabalhar para eventualmente desaparecer (o objetivo supremo de um bom facilitador de times ágeis).

A impressão é que a competência do PMI não está em gerenciar projetos e sim em ser uma máquina de certificar. Acredito que o próximo passo seja certificações em física quântica.

Mais informações sobre a certificação aqui.

Não perca!!! Palestra dia 27/01 19:10: Análise de Negócios em projetos ágeis – Mais Valor. Mais Rápido

“Análise de negócios é análise de negócios”, contudo, em um contexto ágil, parece que estamos fazendo análise de negócios em uma montanha russa. A boa notícia é que é realmente divertido (para quem tem estômago).

Data e Horário: 27 de Janeiro (quinta-feira), às 19:10h
(credenciamento a partir das 18:30h)

 

Principais tópicos:

  • Estamos falando de projetos nos quais a solução, ou componente da solução é software.
  • Entregar Valor.
  • Mais valor, mais rápido! Mais, mais!
  • Sim, “entregar” também é problema seu.
  • It is all about PDCA.
  • Existe lugar para o AN em qualquer projeto ágil?
  • Fábrica de software ágil… como assim??
  • Como modelamos os requisitos dentro de um contexto tão iterativo?
  • PO=~BA?!

 


Público Alvo

 Profissionais interessados em entregar mais valor mais rápido para as organizações através de soluções de software.

Palestrante

Claudio Brancher Kerber: “Cara de TI quando está no Negócio e cara de Negócios quando está na TI”. Administrador de empresas com 14 mil horas de atuação como analista de negócios de TI. Nos últimos anos abandonou os projetos waterfall e se aventurou no agile. Anda cometendo mais erros do que nunca, se sentindo cada vez mais “júnior”, só que, estranhamente, anda entregando mais software, mais valor, mais rápido.

 

As inscrições serão feitas apenas por email (escreva para eventos@saopaulo.theiiba.org).

INVESTIMENTO: R$ 70,00
Desconto de 50% (R$ 35) para pagamentos efetuados até 26/01/2011 R$ 30 p/ associados do IIBA Internacional (somente para pagamentos efetuados até 26/01/2011)

LOCAL: Fundação Carlos Alberto Vanzolini
Av. Paulista, 967, 5° Andar, Bela Vista, São Paulo (próximo ao metrô Trianon-MASP)

 

Veja aqui o PDF com o anúncio do IIBA: http://www.iiba.org.br/arquivos/convite_palestra_27_01_11.pdf