Atualizando seu WordPress

Atualizar seu Wordpress nunca foi tão simples

Link deste post

Retrospectiva do #AgileBrazil 2010 – Parte 3

Segundo dia de conferência, acordei meio mal e perdi o keynote do Philippe Kruchten, só cheguei a tempo para ver aquele joguinho sem vergonha entre Brasil e Portugal que passou no auditório principal e no stand da Thoughtworks, que vergonha. Mas vamos ao que interessa.

Pelo menos eles não brigaram :) Foto de austinhk

Jogo e o kanban-sketch da Aspercom

Deveria ter aproveitado as duas horas de nervosismo para trabalhar no projeto que o Rodrigo Yoshima da Aspercom (que levou uma mini-vuvuzela para ficar assustando o Guilherme Silveira) propôs para fazermos num estilo Rails Rumble. A idéia era criar um site parecido com o yuml.me, mas para quadros kanban batizado de kanban-sketch, onde você manda os cartões e fases via URL e ele monta um board bonitinho. Eu acabei fazendo uma brincadeirinha com Sinatra, que eu nunca havia metido a mão antes, e até que saiu alguma coisa. Eu montei o suficiente para fazer o parse da URL e montar alguns objetos em memória com os dados, só faltou gerar o HTML, mas essa é a parte "fácil". Dado que investi apenas 3 horas no projeto, não foi um resultado ruim, você pode ver o fonte no meu GitHub, só não vale falar mal :) Pretendo voltar a falar sobre o assunto futuramente.

Trabalhando nesse projeto conheci o João Vitor, que faz parte do RailsMG, o grupo de usuários Ruby do qual o Daniel Lopes da Área Criações faz parte, e tem agitado vários encontros em Belo Horizonte. Foi ele quem mais trabalhou no projeto e teve a sorte, extremamente merecida, de ganhar o prêmio que o Yoshima estava sorteando para quem participasse, um vale-compras de US$ 150 na Amazon, nada mal. Quem colocou a mão no saco para fazer o sorteio foi o Klaus :)

Rodrigo Yoshima e João Vitor, e depois Klaus fazendo o sorteio

Relatos - Codezone e James Lewis

A tarde assisti ao relado do Codezone (vulgo Leandro Silva, que também trabalha na Locaweb) intitulado "Como vi o Scrum ser rechaçado em uma grande empresa", que foi bacana, e eu adoro relatos de casos reais.

Codezone evangelizando Agile :) Foto do Fernando Meyer

Na sequência assisti à palestra do James Lewis da Thoughtworks, chamada "Agile Adoption Anti-Patterns", que segui a mesma linha do Codezone, mas ao invés de tratar de um caso específico, ele relatou padrões que identificou em vários casos onde a adoção/implementação de metodologias ágeis falhou ou teve problemas. Vou caçar os slides da palestra e publicar aqui, acho que vale a pena refletir sobre esses padrões.

Ver alguém relatando os erros e acertos do seu trabalho é algo que ensina muito, é uma das formas mais legais de se aprender algo, especialmente quando estamos falando de coisas bastante abstratas como metodologias de trabalho.

Klaus Wuestefeld

Para fechar com chave de ouro, Klaus Wuestefeld fez o keynote final intitulado "Learning and Coolness - Beyond XP", que teve um alto grau de "duracaralhisse" (tradução dele de coolness) :) Esse termo foi utilizado para definir um dos valores propostos pelo Klaus para projetos XP. Coolness é fazer com que cada projeto seja tão legal e interessante que motive a equipe a trabalhar bem sem precisar de controles externos e dúzias de ferramentas "motivacionais".

O outro valor foi "learning", que se trata de encarar o desenvolvimento de software como um processo de aprendizado ao invés de um pastelaria. Se fizermos isso o projeto fluirá naturalmente e processo ficará ainda mais leve.

No fundo, tudo que ele falou é uma questão de atitude ao invés de processos, e concordo com a abordagem dele, embora alguns detalhes do que ele relatou me fazem pensar se o Beyond XP que ele propõem é viável com projetos ou equipes grandes ou então com equipes pouco maduras, mas as idéias básicas são ótimas.

Já havia visto uma versão dessa palestra no Encontro Ágil de 2009 no IME-USP, e o Klaus, assim como o David Hussman, é muito carismático.

Encerramento

Depois do Klaus, a organização fez vários sorteios e colocou no palco todos aqueles que ajudaram na realização do evento. Eles foram heróis e definitivamente merecem nossos agradecimentos e aplausos. No finzinho eles passaram um vídeo com o keynote principal do Agile Brazil 2011, Ken Schwaber, co-criador do Scrum, que deu um "oi" e falou que estará aqui no Brasil nos próximos meses dando alguns cursos (acredito que o Professional Scrum Developer com o Giovanni Bassi) e que está animado para o próximo ano. Pelo que entendi parece que vai ser em Belo Horizonte, mas não sei se essa informação está correta.

Com isso encerro o relato das apresentações oficiais, no próximo post farei um wrap-up com minhas impressões sobre o evento, até lá. Leia também a parte 1 e a parte 2 da restrospectiva.

 

Permalink | Leave a comment  »

Link deste post

Como vi Scrum ser completamente rechaçado em uma grande empresa

Esse foi o tema da minha apresentação na Agile Brazil 2010 em Porto Alegre, como havia relatado em outro post aqui no blog.

Um pequeno review

O evento foi muito bacana, teva ótima organização, boas palestras, tudo muito legal mesmo. Parabéns ao Danilo Sato, ao Hugo Corbucci, à Mariana Bravo e aos demais organizadores.

Palestras

As palestras foram boas, mas em geral não trouxeram nada de muito novo. Mesmo o keynote do Martin Fowler, que tocou no assunto de deploy contínuo, não trouxe nada de muito novo. O Guilherme Silveira, da Caelum, havia blogado em março e feito uma apresentação em maio sobre esse tema no evento Maré de Agilidade, em BH.

Gostei bastante do tutorial do Paulo Caroli, da ThoughtWorks, sobre Agile Card Wall; da palestra do Franscico Trindade, também da ThoughtWorks, sobre Coaching de Guerrilha; achei interessante a palestra do Manoel Pimentel, da Visão Ágil, sobre Coaching para Liderança de Equipes Ágeis, mas fiquei um pouco entediado com suas dinâmicas; e infelizmente, não pude ver o workshop do Rodrigo Yoshima, da Aspercom, e do Phillip Calçado, da ThoughtWorks, sobre Modelagem Ágil, porque eles baleiraram a sala!

O keynote do Klaus Wuestefeld foi bem divertido – feito no Notepad! – e, como sempre, subversivo!

Networking

Mas apesar das boas palestras, a parte mais interessante mesmo, na minha opinião, foram os papos informais nos intervalos das palestras, almoço e final do dia. Papos informais são uma excelente maneira de trocar experiências, ter insights e conhecer pessoas talentosas. Rolou de tudo: liderança de times ágeis, auto-gerenciamento, débito técnico, desafio de lidar com sistemas legados, gerenciamento de iterações, Kanban, métricas, e por aí vai. Muito proveitoso.

Dicas de reviews

Sugiro fortemente que você leia os reviews feitos pelo Rafael Rosa, um dos meus colegas de Locaweb que também estiveram por lá.

Outra dica de leitura é o review que o Alan, também da Locaweb, fez do curso de CSPO que ele fez na prévia da conferência.

Link deste post

DevOpsDays – Agilidade em todos os níveis

Sexta passada estive no evento DevOpsDays, que aconteceu em Santa Clara (Califórnia), no escritório central do LinkedIn. O termo DevOps (criado por Patrick Debois) surgiu no final do ano passado, mais ou menos na época em que Andrew Schafer e Paul Nasrat deram uma palestra na Agile 2009 sobre Infraestrutura Ágil.

Onde Surgiu DevOps?

DevOps tem vários signifcados. O mais óbvio deles, como o próprio termo já diz, significa a união de Desenvolvedores (devs) e Operadores (ops) de Sistemas (também conhecidos como SysAdmins).

Em startups, é muito comum que não exista separação entre Devs e Ops. Nessas empresas, os técnicos sabem tanto escrever o software como dar manutenção e administrar os servidores de produção. Conforme as empresas crescem, começa a surgir a necessidade de especialização nas áreas de desenvolvimento e sysadmins (DBAs, Storages, Rede, Linux, Windows, etc). Problemas começam a surgir quando criam-se silos e a empresa fica dividida entre aqueles que criam o software e aqueles que mantém tudo funcionando em produção. Essa divisão pode ser muito nociva para a empresa, uma vez que os profissionais, ao invés de colaborarem para o sucesso da empresa, ficam num jogo de apontar o dedo um para o outro, na busca de um culpado que, convenhamos, pouco importa para o negócio.

DevOps tem o objetivo de trazer os conceitos e boas práticas aprendidas pelos Engenheiros de Software Ágeis para o mundo dos SysAdmins. Não só isso, DevOps também procura clarear para os desenvolvedores as preocupações (justas) e práticas dos SysAdmins. O principal trabalho do SysAdmin é manter tudo no ar. Qualquer coisa a mais que o desenvolvedor quiser, coloca em risco o trabalho o SysAdmin. O desenvolvedor tem que entender isso e trabalhar como parceiro do SysAdmin. Ele tem que se preocupar para que nada quebre em produção e estar disponível para ajudar o administrador caso algo dê errado. Faz parte do trabalho de devs e ops estarem alinhados e colaborarem um com o outro.

O vídeo abaixo, criado por Patrick Debois, foi exibido no início do DevOpsDays e vale a pena ser visto:

Cultura

Uma das grandes preocupações dos Administradores está relacionada com os requisitos não funcionais de um sistema. Requisito não funcional seria tudo aquilo que existe “por traz dos panos”, coisas que o cliente nem sabe que existe, mas que é fundamental para o sucesso do negócio. Alguns exemplos de requisitos não funcionais são: backup, monitoração, escalabilidade, balanceamento de carga, segurança. 89% das start-ups concentram todos os seus esforços em requisitos funcionais. Isso porque, segundo a filosofia ágil, precisamos entregar valor para o cliente o mais rápido possível. Isso faz com que os times foquem nas funcionalidades dos produtos e, algumas vezes, negligenciem a infra-estrutura que suportará o crescimento deste. Um dos grandes desafios é saber o momento de dedicar tempo para os requisitos não funcionais. Mas tanto desenvolvedores quanto sysadmins têm a obrigação de levantar essas necessidades para o PO e este, por sua vez, tem que ser muito perspicaz em ouvir os argumentos técnicos e ceder tempo de desenvolvimento é pró da evolução do produto.

Se formos refletir bem, DevOps não tem nada de novo em relação ao que foi dito há quase 10 anos, quando surgiu o Manifesto Ágil. O manifesto propunha que o cliente e o time trabalhassem juntos, numa relação de confiança e cumplicidade. DevOps propõe que esse “trabalhar junto” se estenda para todos os envolvidos. Não só quem faz o produto, mas também quem mantém (SysAdmins), quem vende (Comercial), quem divulga (Marketing), quem atende o cliente (suporte técnico). Todos têm que se conversar, se respeitar e principalmente, trabalharem juntos.

Em muitos casos, esse tipo de comportamento não é comum. Por isso, vestir a camisa de DevOps exige grandes mudanças culturais. Como foi bem dito no DevOpsDays, não se muda a cultura, se muda o comportamento. E essa mudança normalmente tem que partir da liderança. Se o gerente tem um comportamento de ficar acusando outros gerentes ou  membro de outros times, naturalmente os seus subordinados agirão da mesma forma. Se ao invés disso, o líder confiar nas pessoas e estiver presente nos momentos de tensão, sempre disposto a colaborar e a ouvir, seu time o seguirá, gerando um clima saudável de compromisso entre as áreas da empresa.

Infraestrutura como Código

Com o surgimento do Cloud Computing, fica cada vez mais fácil para uma empresa administrar e escalar a sua infra-estrutura de servidores. Hoje a nuvem permite que o único hardware de uma start-up seja a máquina de café. Todo o resto pode ser administrado remotamente, em máquinas criadas na Internet. Idealmente, essas máquinas não deveriam nunca ser acessadas. Tudo que for feito nelas deveria ser feito de forma automática. Hoje, já existem ferramentas de Gerenciamento de Configuração (Configuration Management ou CM) como o Chef, Puppet ou CFEngine que permitem que todo software (pacote) instalado em um servidor seja controlado de longe usando templates, receitas, papéis e outros artefatos, configurados e testados previamente. Isso significa que toda infra-estrutura de um produto pode estar mapeada em linhas de código, com testes e tudo mais.

Imagine a situação de um sistema de loja virtual que comece a crescer rapidamente. Um único servidor de Apache começa a não dar conta da enorme quantidade de requisições de clientes. O procedimento normal seria instalar um outro servidor, configurar todos os pacotes nele, coloca-lo atrás de um balanceador de carga e dividir o tráfego entre dois servidores. Mas se esse tráfego dobrar de novo? O SysAdmin terá que configurar outras duas máquinas? E se isso acontecer bem na época de Natal, onde as vendas explodem? Ele terá tempo hábil para configurar as novas máquinas? Claro que não. Essa estrutura tem que escalar de forma automática. Hoje, isso é possível! Podemos detectar automaticamente o aumento nos acessos e provisionar uma nova máquina para atender a demanda. Mais ainda: quando essa demanda cair, podemos excluir um dos servidores com baixa utilização para economizarmos recursos. Isso é Cloud!

Esse “céu encantado” só é possível se Dev e Ops trabalharem juntos. O deploy de uma aplicação precisa ser automatizado. Uma vez que o código em produção estará rodando em vários servidores, todas essas máquinas precisam ser atualizadas quando surgir uma nova funcionalidade. Se forem 20.000 máquinas (como é o caso do Facebook) isso só é possível se for de uma forma automática e muito bem organizada, inclusive com a possibilidade de rollback caso algo não dê certo por algum motivo.

E isso não é tudo

Essas ideias são apenas uma introdução a DevOps. O assunto é novo e muito pouco explorado. Se quiserem saber mais, separei algumas referências importantes:

1. Blog do Patrick Debois
2. Operações no Twitter
3. Site do DevOpsDays
4. Theo Schlossnagle – Scalable Internet Architectures
5. Adam Jacob, John Willis – Infrastructure Automation With Chef
6. Lee Thompson, Alex Honor – Getting Fast: Moving Towards a Toolchain for Automated Infrastructure
7. John Willis, Damon Edwards – The Infrastructure Philharmonic: How Out of Tune are Your Operations?
8. Andrew Clay Shafer – Change Management: A Scientific Classification
9. John Allspaw – Ops Meta-Metrics: The Currency You Use to Pay For Change
10. Perhaps DevOps Misnamed

Fotos do Evento

Após o DevOpsDays, fomos todos para um bar em Montain View conversar mais sobre o assunto. Foi muito divertido e “produtivo”. Seguem as fotos.

Link deste post

"Hackeando" meu HTC Hero

Salve!

Depois de muito procrastinar decidi que estava na hora de atualizar o Android do meu HTC Hero.

Eu o comprei há uns 9 meses, na época paguei um preço bem salgado (R$ 2.000) e ainda ter me arriscado comprando o bichinho no Mercado Livre (pela GSMTech). No fim deu tudo certo e não me arrependo, ele é muito bom sob vários aspectos:

• A bateria dura relativamente bastante - uns 4 dias com uso normal, 1 dia com uso intenso (wi-fi ou 3G navegando o dia todo, como quando estou em eventos)
• Tela com boa resolução, dá para ler textos numa boa
• Boa sensibilidade ao toque
• Pequeno e leve (mais leve que um iPhone)
• Teclado do Sense é maravilhoso
• O Sense faz o Android ficar muito mais amigável
• Botões físicos úteis, especialmente o back e search
• Bluetooth funciona bem com meu headphone
• Boa recepção de wi-fi
• Integração total com os aplicativos do Google, especialmente o GMail
• Funciona muito bem como modem 3G conectado ao meu note Ubuntu via USB
• Navega bem em sites com Flash

A única coisa realmente ruim no telefone é a câmera, que apesar de ter 5 Megapixel, é horrível, as fotos ficam ruins e precisa de muita luz para ficar meia-boca. Tirando isso, nada a reclamar. Como ele é bem bonitinho e diferente, todos me perguntam que modelo de celular eu estou usando e tal.

Por que mudar?

Mas porque diabos escolhi fazer isso hoje e não antes? A gota d'água foi a Amazon anunciar que lançou o Kindle for Android, antes do prazo inicial que era Julho. Particularmente nunca gostei da idéia do Kindle, mas comprar livros pela Amazon é muito prático, e ultimamente tenho preferido livros digitais, por questões ecológicas, econômicas e de peso, afinal, é muito bom poder levar dúzias de livros no bolso.

Um dos motivos para adiar o update é que a HTC enrolou muito para lançar novas versões para o Hero. Quando o comprei, estava usando a versão mais nova, a 1.5, mas depois de 1 mês eles lançaram a 1.6 e logo em seguida a dois 2.0, 2.1 e a 2.2 Froyo já está rodando em alguns lugares, mas ainda não chegou aos celulares mais velhinhos. Sem querer entrar no mérito se o Android está se fragmentando ou não (isso vale outro post), a evolução do ambiente tem sido muito rápida, e o Kindle só é compatível com a versão 1.6 ou superior, ou seja, era atualizar ou ficar sem o software.

Cozinhando ROMs

Voltando a vaca fria, só agora em Maio a HTC começou a soltar as atualizações para o 2.1, mas apenas em alguns lugares do mundo, e é aí que entram os ROM Cooks. Cooks são os caras que ficam brincando de fazer novas ROMs, hackeando as oficiais e adicionando coisas novas à elas. Eles estão criando ROMs com as versões mais novas há tempos e já estão trabalhando para liberar as 2.2, esses caras são loucos e eficientes. Você pode acompanhar o que eles fazem no fórum xda-developers, na sessão de desenvolvimento.

Com uma ajudinha do Jonas Alves (que conheci num dos encontros do Guru-SP e depois reencontrei numa palestra da Caelum), eu conheci a VillainROM, que é um das mais profissionais do mercado. A versão 10.3 deles é feita em cima do release oficial da versão 2.1 da HTC, que inclui o HTC Sense atualizado. Para quem não sabe, o Sense é uma modificação da interface do Android feita pela HTC para deixar ele com uma carinha mais bonita, e tem um esquema de múltiplas home screens que podem ser customizadas com widgets (se mordam de inveja povo do iPhone).

Ok, decidi que iria atualizar meu Hero, já havia escolhido a ROM, mas agora faltava saber como fazer a atualização. Os cooks tem uma linguagem própria, e sinceramente não estou no pique de aprender mais uma dúzia de gírias para conseguir fazer uma atualização de telefone. Sendo assim, corri para o velho e bom YouTube e procurei vídeos sobre rooting de telefones, e o primeiro hit foi o vencedor.

Tutorial em vídeo de 10 minutos

Um cara tem um site chamado The Unlockr que ensina como desbloquear dúzias de telefones, e ele tem tutoriais e vídeos para fazer isso com o Hero. Em 10 minutos ele mostrou tudo que eu perdi horas tentando entender em dezenas de posts do fórum e tutoriais.

O processo básico tem dois passos:

1. Conseguir acesso root ao seu aparelho
2. Instalar uma nova ROM

Por mais assustador que isso pareça, o processo é bastante simples, basta seguir os tutorias e pronto. Cada vídeo abaixo tem um tutorial com as instruções, então não tem muito o que errar. Mas atenção no primeiro vídeo, porque as instruções do vídeo mudaram, há um aviso vermelho avisando sobre isso, mas é só seguir as instruções escritas que fica tudo bem. Seguem os vídeos e os respectivos tutoriais.

Tutorial para fazer root (vídeo acima)

Tutorial para instalar uma ROM customizada (vídeo acima)

Depois de fazer isso é só configurar a conta do Google, deixar ele sincronizar tudo, e depois configurar o Access Point para utilizar o 3G, é a única coisa que ele não conseguiu configurar sozinho. Para isso basta entrar em Settings > Wireless & Networks > Mobile Networks > Access Point Names, clicar em Menu e colocar a configuração da sua operadora, que basicamente é o gateway do AP e depois o usuário e senha padrão. No caso da Oi, a operadora que escolhi, o gateway é "gprs.oi.com.br", o username é "oi" e a senha é "oi", nada complicado. Se quiser o esquema para outras operadoras, veja esse tópico no fórum da Info.

Outro motivo que me fazia adiar o procedimento era porque alguns tutoriais diziam que era necessário fazer parte do update com o HTC Sync, o software de sincronização e backup oficial da HTC, que só funciona no Windows :( Porém, como os vídeos acima mostram, tudo que você precisa é copiar os arquivos para o SD Card do telefone, e isso você pode fazer com qualquer sistema operacional, no meu caso eu usei o Ubuntu.

Além de conseguir instalar o Kindle e ainda consegui criar duas caixas postais no GMail, uma particular e outra para o trabalho, o que vai facilitar e muito minha vida. Eu tentei fazer alguns dos updates automáticos mas tive alguns probleminhas, então vou deixar para resolver isso em outro momento. Assim que tiver novidades eu aviso.

Viva o Android!

Atualização em 01/07/2010: tudo andando bem, o Kindle for Android é ótimo, mas o consumo de bateria está absurdo :(

Permalink | Leave a comment  »

Link deste post

Resumo do Curso CSPO – Primeiro dia

Já faz algum tempo que não publico nada aqui no meu blog, bem acho que inicialmente preciso compartilhar a minha felicidade de estar já a três meses na Locaweb, que além de uma empresa competitiva no ramo de serviços de internet (Líder na prestação de serviços hospedados de TI), também é um excelente lugar para trabalhar.

Entre os vários benefícios e atrativos que a empresa oferece, tais como um excelente ambiente de trabalho, desafios constantes e etc., ela também investe pesado em treinamento e aprecia ter pessoas ligadas a comunidade de software no seu quadro de colaboradores.

Nesse espírito de investir nos seus funcionários a Locaweb custeou a ida de algumas pessoas para o Agile Brazil 2010 em Porto Alegre e além disso possibilitou que algumas pessoas fizessem alguns cursos e é aí que eu entro, eu fui um dos premiados a fazer o curso do CSPO (Certified Scrum Product Owner)!

O curso foi excelente, ministrado pelo Alexandre Magno com o parceria do Luiz C. Parzianello, apesar de o formato do curso com dois “Mestres de Cerimônia” não tenha ficado tão bom quanto o esperado, a integração dos assuntos abordados pelos dois foi excelente!

Para saber mais informações de como foi o dia a dia do curso, recomendo a leitura do post de um amigo que fiz lá o André Nascimento e de meu amigo locaweber Rafael Rosa Fu.

A partir de agora vou repassar um pouco do resumo que fui fazendo ao longo do curso, espero que aproveitem!

• PO – todas as empresas tem problemas com esse papel do Scrum.

Uma das primeiras frases do Alexandre Magno no curso foi que o papel do PO é um papel que merece mais atenção nas empresas pois ainda muita falta de experiência para executá-lo.

• No início havia muito foco no papel do time.

Focava-se muito esforços no papel do time (Integrantes do time + Scrum Master) e agora é o momento de focar-se mais no papel do PO.

• Nada adianta um bom time se o produto está sendo desenvolvido errado.

Aqui o recado é que não adianta ter ótimos técnicos no seu time e um Scrum Master excelente em facilitação, se o produto desenvolvido não estiver focado nas necessidades do cliente.

• Pouco adianta práticas de engenharia para o produto errado.

Vale o mesmo recado da sentença anterior, TDD, Pair Programming, Continuos Integration pouco terão valor se o produto está errado no aspecto de negócio.

• Devemos focar mais esforço no negócio.

Nossos esforços devem estar mais direcionado a atender as necessidades de negócio.

• Pouco material técnico e mais práticas para deixar as pessoas mais focadas (curso).

Aqui foi uma frase que me chamou atenção, onde o Alexandre Magno deixou claro que o foco dele seria nas práticas e não em apostilinhas!

• Discussão do gerente de produto na (sua) empresa. Quais são as atribuições do Gerente Produto?

Neste momento tivemos uma excelente discussão de qual seria o papel do Gerente de Produtos, se quiser saber a conclusão faça o curso !

• Onde o GP e o PO se encontram (papéis)?

Outra excelente discussão, onde falamos muito sobre a intersecção do papel do PO e do cargo Gerentes de Produtos.

• Scrum foi pensado para projetos e não para empresas.

O Magno deu um recado que apesar de muito claro, tem muita gente que ainda não compreende que é o Scrum foi pensado para projetos e não para gestão de empresas! Ele foi bastante enfático nesse momento.

• PO é um papel do projeto e não da empresa… o GP é um cargo na empresa.

Mais um recado muito claro do Magno, o PO é um papel e o gerente de Produtos é (deveria ser) um cargo na empresa.

• A necessidade de um PO inicia quando o projeto inicia, não antes!

Não deveria ter PO eternos na empresa, a necessidade de um PO inicia quando o projeto inicia e não antes!

• Se não há projeto, não há Product Owner.

Resumindo: “Se não há projeto, não deveria haver Product Owner!”

• Time de alto desempenho as vezes não entregam valor por causa do PO ruim.

Um cruzado de direita do Magno, mesmo tendo um time de alto desempenho é muito provável não entregar nada de valor caso o PO for muito ruim.

• No mundo perfeito, todo PO será do cliente.

O ideal seria que o PO sempre fosse do cliente, ou seja, muito ligado ao produto, mas nem sempre isso é possível.

• De nada adianta um PO do cliente se ele não priorizar, ou priorizar mal.

Porém de nada adianta um PO do cliente se ele não for hábil para priorizar ou na pior das hipóteses priorizar mal.

• Mais difícil é encontrar lideres com objetivos do que times auto gerenciados.

Esta sentença para mim está muito ligada ao que o Magno disse no início do curso, muito foi focado no time, agora é muito mais fácil encontrar times auto-gerenciados do que lideres com objetivos bem definidos.

• O comum é lideres com time sheeting do que com objetivos claros.

Em muitas empresas que se auto denominam “Ágeis”, na verdade é comum encontrar liderem com um o gráfico de gantt e planilhinha de horas!

• PO deve ter um cuidado com o product backlog.

O product backlog deve ser um filho para o PO, que deve cuidar, proteger, defender !

• PO desenvolve a visão do produto e os passos para atingir o objetivo da visão.

A tão falada visão do produto deve ser desenvolvida pelo PO assim como os passos para atingir o objetivo determinado na visão.

• O macro management fica na mão do PO.

O macro management fica a cargo do PO, verificando as features e os releases numa perspectiva macro para atingir o objetivo do produto.

• O passos para atingir o objetivos das estórias (micro management) fica a cargo do time.

Já o micro management fica com o time, ou seja, os passos (tarefas) para atingir o objetivo da sprint.

• O PO tem que realmente ser um porco do projeto (é difícil ser porco em dois projetos).

O recado aqui é que é difícil dar o sangue (couro no caso do porco, ) em mais de um projeto, o PO sempre tem que se perguntar se será capaz de focar no projeto antes de ingressar nele.

• Scrum é incompleto e não precisa somente de práticas de engenharia, existem outro pontos (análise de risco, controle).

Aqui um recado do Parzianello, todos sabemos que o Scrum é incompleto, mas não é somente pela falta de práticas de engenharia, na verdade também lhe falta análise de risco e outras disciplinas ligadas ao negócio.

• Scrum é controle! (reunião diária, review, definition of done).

Apesar de soar muito estranho, mas Scrum é controle! Reunião diária, Review, Definition of Done, são provas que há sim, muito controle no Scrum, o que não tem é Comando!

• É interessante o time ter um integrante como Scrum Master exclusivo.

Sempre que possível é interessante ter um protetor do Scrum e do time, esse papel responde pelo nome de Scrum Master, mas claro, se o time for maduro a ponto de achar interessante que esse papel possa ser executado por um integrante do time não há problemas.

• Quais são os seus valores?

Aqui mais uma discussão aberta pelo Magno: Qual são seu valores? O que realmente importa para você?

• Dá para estimar o valor e o tempo com práticas ágeis?

Mais uma discussão sobre a possibilidade de se fazer estimativas de valor e de prazo com práticas ágeis, mas com certeza deverá haver uma quebra de paradigmas de quem for fazer a estimativa, bem como de quem for recebê-la.

• Product roadmap com práticas ágeis tem que quebrar paradigmas.

Ainda relacionado com a sentença anterior, deve-se quebrar paradigmas para se executar, receber e interpretar um product roadmap com práticas ágeis, caso contrário será difícil ter sucesso no projeto.

• Todo o ambiente de projeto deveria entender o que é Scrum para ter sucesso (principalmente patrocinadores e clientes!).

Essa é mais uma sentença auto explicativa, para ter sucesso todo mundo tem que compreender o Scrum!

• Premissa para o PO: você realmente tem disponibilidade para esse papel?

Ou seja, ou você estará disponível, envolvido ao projeto, caso contrário esse papel de PO NÃO é para você. Simples assim!

• Atribuições do PO

Definir a visão (com workshops etc.)
Manter o product backlog
Maximizar o ROI
Gerenciar, planejar release
Define as metas
Leva as informações do projeto para fora (divulgar o projeto)
Gerenciar conflitos de cliente, prioridades
Fazer gerenciamento macro
Bastante coisa, não?

• Meta: ou atingiu ou não atingiu!

Simples, atingiu a meta ou não atingiu a meta, não existe meia meta!

• PO sem poder de decisão ou com baixa disponibilidade ou que não foi preparado para exercer o papel.

Com um PO nessas condições será praticamente impossível ter um projeto de sucesso, ou se mitiga esses riscos ou é melhor nem iniciar o projeto.

• PO deve estar próximo no momento de quebrar tarefas.

E muito importante o PO estar próximo (sempre que possível) quando se for quebrar as tarefas, para auxiliar o time, para que essa atividade tenha o máximo de precisão possível.

• QA junto com PO para descobrir estórias e definir critérios de aceitação.

Outra dica do Magno, ter o QA próximo do PO no momento de descoberta de estórias e na definição dos critérios de aceitação.

• A cada review deve ser apresentado o que foi gerado para entregar aquele release!

Esse foi um soco de esquerda, a cada review o time deve apresentar o que foi gerado para entregar aquele release, mas também é importante que o PO tenha em mãos tudo para o próximo release que será desenvolvido.

• Retrabalho nível 2 – problemas intrínsecos do projeto nível 1

Aqui eu não me lembro, assim que eu lembrar atualizo aqui (poxa, o curso era de manhã!)

• Prestar atenção e conhecer Lean!

Apesar de neste momento o Magno e o Parzianello estarem falando de Lean, fica a dica de também prestarem atenção ao Kanban.

• Proteger receita e diminuir custo.

Aqui uma dica no Parzianello que fez a diferença, nós sempre pensamos no produto para aumentar as receitas ou lucros, mas muitas vezes poderíamos estar focados em proteger a receita atual e diminuir o custo. Esta discussão iniciou quando eu trouxe um problema enfrentado pelo meu time, sobre como eliminar o legado e entregar valor, nós não conseguíamos ver a possibilidade disso, mas na verdade o que nós queriamos era proteger a receita da empresa (manter os produtos atuais) porém diminuir o custo (software funcionando, manuteníveis, extensíveis com o mínimo possível de bugs), resumindo entregando valor sim!

• As vezes não é debito técnico, mas sim melhoria tecnológica.

Ainda na discussão anterior, as vezes não podemos encarar tudo como débito técnico, mas sim melhoria tecnológica que na verdade também é entrega de valor.

• Técnica Elevator Statement para definir a visão do produto.

Aqui fizemos uma excelente dinâmica para definir uma declaração que define a visão do produto, mais informações no curso.

• Desenvolver o product vision box.

Outra dinâmica show, foi o desenvolvimento do product vision box, o melhor, além da técnica e a explicação do Magno é claro, foi a integração com as outra pessoas que estavam fazendo o curso conosco. Foi um momento super descontraído e divertido!

E assim terminamos o primeiro dia do CSPO e agora fico devendo o segundo post, até lá!

Link deste post

Precificação: ciência e arte (3/3)

No primeiro post dessa série de 3 posts sobre precificação falamos sobre o livro Don’t just roll the dice, a usefully short guide to software pricing, leitura obrigatória para quem trabalha com software ou serviços de internet. Em seguida falamos sobre o livro Smart Pricing: How Google, Priceline, and Leading Businesses Use Pricing Innovation for Profitability:

Capa do livro Smart Pricing

Esse livro foi scrito por Jagmohan S. Raju e Z. John Zhang, dois professores da Wharton University of Pennsylvania, onde ministram o cusro Pricing Strategies: Measuring, Capturing, and Retaining Value.

Jagmohan S. Raju

Z. John Zhang

Já falamos sobre:

• Introdução: as três formas de se definir preço e porque precificação pode ser considerado o santo graal da lucratividade.
• 1. “Pay As You Wish” Pricing: sobre o caso do álbum que a banda inglesa Radiohead deixou disponível para download, ou seja, deixar que o consumidor defina o preço.
• 2. Why the Best Things in Life Are Free: a base desse capítulo é a busca do Google, que é gratuita. E que o Google ganha “vendendo” a atenção de seus visitantes que fazem buscas em seus mecanismos de busca para os anunciantes, esses sim, pagantes.
• 3. The Art of Price Wars: como os chineses se tornaram mestre na arte da guerra de preços.

E no segundo post da série falamos sobre:

• 4. Thinking small: Muhammad Yunus, economista e banqueiro bengali que em 2006 foi laureado com o Nobel da Paz, provou o valor dos centavos com a prática da concessão de microcrédito.
• 5. The Automatic Markdown: aqui explica-se o conceito do leilão holandês, ou descendente. Nesse tipo de leilão, ao contrário do leilão tradicional, também conhecido como inglês ou ascendente, o leiloeiro inicia o leilão com um valor alto e o reduz continuamente. A primeira pessoa que aceitar o lance corrente obtém o item. A motivação de compra é o receio de perder a oportunidade de comprar o item.
• 6. Name Your Own Price: Aqui o exemplo é a Priceline.com, que permite que o cliente diga quanto quer pagar por um ticket de avião ou quarto de hotel, a data e o local e a Priceline se incumbe de encontrar alguma oferta nessas condições.

Vamos agora aos capítulos finais:

7. Subscribe and Save: Pricing for Marketing Profitability

Serviços como acesso a internet, telefonia, TV a cabo são as opções que vêm à mente quando pensamos em assinatura. Logo lembramos também de itens físicos como jornais e revistas que podem ser comercializados por assinatura. Nesse capítulo, os autores falam sobre o serviço Subscribe and Save da Amazon.

Subscribe and Save da Amazon

A Amazon oferece 15% de desconto mais taxa de envio gratuita se o cliente pedir a entrega mensal, bimestral, trimestral ou semestral de qualquer item do site. É o sistema de assinatura aplicado a qualquer coisa física. Afinal, nós compramos vários itens de nosso dia-a-dia com regularidade. Por que não deixar essas compras no automático?

Para o cliente a principal vantagem é não precisar mais se preocupar com certas compras. Para a Amazon as vantagens são muitas, pois ganha uma receita recorrente que não varia tanto quanto a receita de compras eventuais.

8. The Snob Premium

Aqui a idéia é cobrar caro pela exclusividade. Um bom exemplo é o cartão Amarican Express Centurion, que tem taxa anual de US$ 2.500, mais uma taxa inicial de US$ 5.000. Não é a toa que só existem 17.000 pessoas com um cartão desses.

American Express Centurion

Outro exemplo apresentado no livro é o Trump Tower, na esquina da Rua 56 com a Quinta Avenida, empreendimento do empresário americano Donald Trump.

Trump Tower

Para tornar o Trump Tower um empreendimento exclusivo, Donald Trump resolveu assumir um grande risco: ele pôs os apartamentos à venda por preços acima do mercado, com “os mais altos preços pagos por um homem” (fonte: Trump: The Saga of America’s Most Powerful Real Estate Baron). Um apartamento de 4 quartos era vendido por US$ 5 milhões, o que ainda era muito dinheiro em 1983. A teoria de Trump era que as pessoas que estão na estratosfera do mercado são insensíveis a preços, mas são muito sensíveis sobre suas companhias e seus status. Liberace comprou o primeiro apartamento, seguido por Johnny Carson.

9. Pay If It Works

Esse modelo de precificação é baseado no conceito de preço baseado em performance. Um bom exemplo disso é o AdWords do Google, onde o anunciante paga apenas quando seu anúncio for clicado. Outro exemplo são os serviços de internet que oferecem o trial antes de a pessoa contratar o serviço.

O que me chamou a atenção nesse capítulo foi um modelo de preço baseado em performance para um remédio. Velcade é um remédio para tratamento de mieloma múltiplo, um tipo de câncer ósseo incurável. Cada ciclo de tratamento custa US$ 4.500.

Velcade

O remédio estava sofrendo duras críticas do National Institute for Health and Clinical Excelence (NICE), que provê aconselhamento para o sistema de saúde inglês.

O laboratório responsável pelo Velcade decidiu então oferecer um reembolso total para qualquer paciente que não tiver uma redução de 25% nas paraproteínas produzidas pelo câncer após 4 sessões de tratamento.

10. Conclusion

Conseguir definir o preço certo é tanto uma ciência como uma arte. Como qualquer prática de administração, as melhores decisões de precificação não dependem apenas de teoria, mas de prática, instinto e um profundo conhecimento do seu cliente.

Outros posts de interesse sobre o tema

• Precificação: ciência e arte (1/3) e (2/3), de junho de 2010, são os dois primeiros dessa série de 3 posts sobre precificação.
• Sobre produtividade, de fevereiro de 2009 e Atualização sobre o tema produtividade, de abril de 2010, que falam sobre a métrica de receita por funcionário de algumas empresas americanas.
• How is your business health?, de junho de 2009, sobre a importância de conhecer os números de seu produto. Cada dia que passa fica mais claro pra mim que nunca sabemos o suficiente ou, melhor dizendo, que sempre dá para saber mais de nossos produtos analisando seus números.

Link deste post

Autenticação 802.1x em redes ethernet

Alguns amigos tiveram dificuldades para autenticar no servidor Radius, isto porque o servidor dhcp somente liberava ip via autenticação, por este motivo resolvi criar este post. Basicamente você vai utilizar wireless over ethernet, pois o responsável pela autenticação no Radius será o wpa_supplicant. Os procedimentos abaixo são baseados em Debian, caso você utilize outro SO, [...]

Link deste post

Retrospectiva #AgileBrazil 2010 – Parte 2

Na quinta-feira começou a conferência propriamente dita. Sob o ponto de vista prático (credenciamento, brindes, coffee-breaks, etc) tudo correu bem, só posso elogiar a organização, e então começaram as palestras. Nesse dia assisti à 4 palestras e corri falei com muita gente, vamos lá.

Foto do camarada Fernando Meyer

Martin Fowler

O keynote do Martin Fowler - cientista chefe da Thoughtworks, ou melhor, as três mini-palestras que ele deu, foram legais, ele é um bom orador e o conteúdo era bastante relevante, mas quem acompanha o blog dele há algum tempo (você acompanha, certo?) não hou nenhuma surpresa ou novidade. O mais interessante é o modo como ele organiza e apresenta os conceitos, mas mesmo assim foram tópicos mais ou menos básicos. O segundo talk, sobre Débito Técnico foi bem interessante, e você pode ler mais sobre o assunto nesse post do blog dele, não se esqueça de ver o link sobre Design Payoff.

Alisson Vale

Na sequência pretendia assistir ao workshop de planejamento de releases do Philippe Kruchten, mas quando cheguei a sala já estava lotada. Em todo caso me disseram que foi legal. Voltei ao auditório principal e assisti à minha segunda opção (eventos com várias tracks tem algumas vantagens), a palestra "Kanban: Em busca de um ritmo sustentável" do Alisson Vale.

A palestra foi bem legal, ainda que básica. O que mais valeu para mim foi conhecer a Limited WIP Society, que é um grupo que discute o uso de Kanban aplicado ao desenvolvimento de software, e o site deles tem várias informações interessantes, incluindo uma lista de ferramentas para Kanban eletrônico, um dos mais interessantes me pareceu o flow. Outra coisa legal que ele mostrou foram alguns fluxos alternativos, para "situações avançadas", uma pena que ele só pode passar rapidamente por eles. Kanban é um assunto muito interessante e acho que vale alguns posts só sobre ele, mas só depois que eu estudar mais o assunto :)

David Hussman

Depois do almoço no Panorama (um big restaurante dentro do próprio prédio, recomendo) assisti à palestra do David Hussman da DevJam, "Produtos e Pessoas sobre Processo e Dogma", que foi a mais legal do evento. Nem tanto porque o conteúdo era inédito, mas sim porque ele é uma figura, muito divertido, e concordo com os conceitos que ele apresentou. O ponto alto foi quando ele apresentou a Dude's Law, que define que o valor de uma técnica qualquer é dado por:

Value = Know Why / Know How

Nesse caso o valor da técnica aumenta quando sabemos melhor o porque ela é necessária/útil e não só por sabermos executá-la. Se você viu as últimas palestras do Akita vai notar que ele fala exatamente a mesma coisa, exceto pela fórmula, o nome da lei e o desenho engraçado, mas o conteúdo é o mesmo.

Com base nisso ele falou que o ideal é não transformarmos as metodologias, ágeis ou não, e suas técnicas em dogmas, devemos entender claramente seu valor antes de utilizá-las e só utilizá-las porque tem valor, não porque alguém disse que tem que ser assim. Voltando ao Akita, recomendo ler o último artigo que ele escreveu para o Gestão 2.0, que também trata desse assunto.

Outra coisa bacana que ele falou foi sobre o Checklist Manifesto, criado por Atul Gawande, que eu já havia ouvido falar pelo blog do Joca, mas na época não parei para ler com cuidado ou considerar com a devida atenção. Vou caçar mais informações e ler mais sobre o assunto para voltar a falar aqui.

Manoel Pimentel

Na sequência, assisti à palestra do Manoel Pimentel, do Visão Ágil, "Coaching para Liderança de Equipes Ágeis". Foi legal, o Manoel é um bom orador e esclareceu algumas dúvidas que tinha em relação à coaching. Uma coisa legal é que ele comentou sobre o uso da técnica dos 6 Chapéus do Pensamento, criada por Edward De Bono na década de 80, como uma ferramenta de facilitação para tomar decisões, fazer discussões e etc. Eu descobri essa técnica há algum tempo através da Bluesoft e do próprio Visão Ágil, e temos utilizado a técnica nas retrospectivas da equipe e tem ajudado bastante. Já cheguei a fazer algumas apresentações sobre o tema e pretendo revisitar o tema em breve.

Fim do dia

Depois de todas essas palestras eu estava exausto e meio gripado, então fui tomar um ar. Entre as palestras, no almoço e nos coffee-breaks eu consegui conversar com várias pessoas e revi vários camaradas, como o povo da Thoughtworks Brasil, do .NET Architects, da Stefanini, da Bluesoft e o Thiago da Inspira, onde fiz um workshop sobre Ruby e Rails no ano passsado.

No geral foi um bom dia, bastante proveitoso, só que acabei destruído. Leia também a parte 1 e a parte 3 da restrospectiva.

Permalink | Leave a comment  »

Link deste post

Retrospectiva #AgileBrazil 2010 – Parte 2

Na quinta-feira começou a conferência propriamente dita. Sob o ponto de vista prático (credenciamento, brindes, coffee-breaks, etc) tudo correu bem, só posso elogiar a organização, e então começaram as palestras. Nesse dia assisti à 4 palestras e corri falei com muita gente, vamos lá.

Foto do camarada Fernando Meyer

Martin Fowler

O keynote do Martin Fowler - cientista chefe da Thoughtworks, ou melhor, as três mini-palestras que ele deu, foram legais, ele é um bom orador e o conteúdo era bastante relevante, mas quem acompanha o blog dele há algum tempo (você acompanha, certo?) não hou nenhuma surpresa ou novidade. O mais interessante é o modo como ele organiza e apresenta os conceitos, mas mesmo assim foram tópicos mais ou menos básicos. O segundo talk, sobre Débito Técnico foi bem interessante, e você pode ler mais sobre o assunto nesse post do blog dele, não se esqueça de ver o link sobre Design Payoff.

Alisson Vale

Na sequência pretendia assistir ao workshop de planejamento de releases do Philippe Kruchten, mas quando cheguei a sala já estava lotada. Em todo caso me disseram que foi legal. Voltei ao auditório principal e assisti à minha segunda opção (eventos com várias tracks tem algumas vantagens), a palestra "Kanban: Em busca de um ritmo sustentável" do Alisson Vale.

A palestra foi bem legal, ainda que básica. O que mais valeu para mim foi conhecer a Limited WIP Society, que é um grupo que discute o uso de Kanban aplicado ao desenvolvimento de software, e o site deles tem várias informações interessantes, incluindo uma lista de ferramentas para Kanban eletrônico, um dos mais interessantes me pareceu o flow. Outra coisa legal que ele mostrou foram alguns fluxos alternativos, para "situações avançadas", uma pena que ele só pode passar rapidamente por eles. Kanban é um assunto muito interessante e acho que vale alguns posts só sobre ele, mas só depois que eu estudar mais o assunto :)

David Hussman

Depois do almoço no Panorama (um big restaurante dentro do próprio prédio, recomendo) assisti à palestra do David Hussman da DevJam, "Produtos e Pessoas sobre Processo e Dogma", que foi a mais legal do evento. Nem tanto porque o conteúdo era inédito, mas sim porque ele é uma figura, muito divertido, e concordo com os conceitos que ele apresentou. O ponto alto foi quando ele apresentou a Dude's Law, que define que o valor de uma técnica qualquer é dado por:

Value = Know Why / Know How

Nesse caso o valor da técnica aumenta quando sabemos melhor o porque ela é necessária/útil e não só por sabermos executá-la. Se você viu as últimas palestras do Akita vai notar que ele fala exatamente a mesma coisa, exceto pela fórmula, o nome da lei e o desenho engraçado, mas o conteúdo é o mesmo.

Com base nisso ele falou que o ideal é não transformarmos as metodologias, ágeis ou não, e suas técnicas em dogmas, devemos entender claramente seu valor antes de utilizá-las e só utilizá-las porque tem valor, não porque alguém disse que tem que ser assim. Voltando ao Akita, recomendo ler o último artigo que ele escreveu para o Gestão 2.0, que também trata desse assunto.

Outra coisa bacana que ele falou foi sobre o Checklist Manifesto, criado por Atul Gawande, que eu já havia ouvido falar pelo blog do Joca, mas na época não parei para ler com cuidado ou considerar com a devida atenção. Vou caçar mais informações e ler mais sobre o assunto para voltar a falar aqui.

Manoel Pimentel

Na sequência, assisti à palestra do Manoel Pimentel, do Visão Ágil, "Coaching para Liderança de Equipes Ágeis". Foi legal, o Manoel é um bom orador e esclareceu algumas dúvidas que tinha em relação à coaching. Uma coisa legal é que ele comentou sobre o uso da técnica dos 6 Chapéus do Pensamento, criada por Edward De Bono na década de 80, como uma ferramenta de facilitação para tomar decisões, fazer discussões e etc. Eu descobri essa técnica há algum tempo através da Bluesoft e do próprio Visão Ágil, e temos utilizado a técnica nas retrospectivas da equipe e tem ajudado bastante. Já cheguei a fazer algumas apresentações sobre o tema e pretendo revisitar o tema em breve.

Fim do dia

Depois de todas essas palestras eu estava exausto e meio gripado, então fui tomar um ar. Entre as palestras, no almoço e nos coffee-breaks eu consegui conversar com várias pessoas e revi vários camaradas, como o povo da Thoughtworks Brasil, do .NET Architects, da Stefanini, da Bluesoft e o Thiago da Inspira, onde fiz um workshop sobre Ruby e Rails no ano passsado.

No geral foi um bom dia, bastante proveitoso, só que acabei destruído. Leia também a parte 1 e a parte 3 da restrospectiva.

Permalink | Leave a comment  »

Link deste post